Реклама на портале

Роль информационных технологий в становлении бизнес-процессов. “Главным преимуществом ИТ-отдела является понимание бизнес-процессов компании”

| 23.05.2018

Одна из типичных задач, так или иначе с завидной периодичностью «падающих» в ИТ, - требование по оптимизации бизнес-процессов. И, как ни странно, зачастую именно это заставляет коллег «изобретать велосипед», хотя вроде бы все велосипеды изобретены до нас... Из данного посыла и родилась статья - краткое практическое пособие по оптимизации бизнес-процессов, предложенное человеком, который реализовал подобные преобразования на процессах, охватывающих деятельность более 1000 сотрудников.

С чего начать?

Как и любое преобразование, оптимизация бизнес-процессов начинается с постановки цели. Чего мы хотим добиться в результате оптимизации? Что должно получиться в итоге и что не должно произойти ни при каких обстоятельствах? Ответы на эти вопросы помогут сформулировать цель оптимизации процессов. Отмечу, что цель может быть общей и для всех процессов, и для каждого. Как правило, можно выделить подцель - с указанием конкретных измеримых параметров того, что должно быть оптимизировано. Например: «Целью проекта оптимизации бизнес-процессов является уменьшение времени выпуска изделия со 100 до 80 часов, при уменьшении процента брака с 7 до 3%». Это конкретная цель. Для каждого процесса можно поставить и свою цель, коррелирующую с общей. Например, одной из подцелей может быть «Снижение срока проектирования нового изделия с 12 до 10 часов путем оптимизации процесса проектирования изделий». Тут, правда, большой отдельный вопрос: за счет чего и как выполнять поставленные цели (скажем, снижение срока проектирования запросто может отразиться на балансе «скорость - качество»).

После того как поставлены цели, необходимо определить объекты оптимизации. Иными словами, определить, что оптимизируем, а что - нет. Причин явно выделять объекты оптимизации может быть несколько: во-первых, это бизнес-приоритеты. Где «больнее болит» - там, очевидно, и надо прилагать максимум усилий. Во-вторых, затраты - где больше расходов, там, вероятно, найдется простор для оптимизации. В-третьих, временные характеристики. В-четвертых, метрики, указывающие на удовлетворенность заказчика. И так далее.

Следующий вопрос, который следует решить до оптимизации, - приоритет процессов на оптимизацию и желаемые сроки внедрения оптимизаций, а также сроки оценки последствий оптимизации. Указав эти сроки, мы делаем очень важную вещь, а именно формируем ожидания по последовательности оптимизационных работ. Кроме того, следует непременно установить период оценки последствий оптимизации. Это весьма существенный параметр, который позволит задать пределы оценки ретроспективы. Проще говоря, нам необходимо установить срок, в течение которого мы будем анализировать последствия внедрения по итогам оптимизации. Почему это важно? Потому что обычно оптимизация бизнес-процессов дает эффект не мгновенный, а протяженный во времени. И оценивать его следует в некоем «коридоре» от завершения оптимизации до принятого некоторого значения. Также надо отметить, что обычно данный период совпадает с периодом сопровождения оптимизированного процесса (и зачастую, при серьезных оптимизациях, период постоценки может быть расширен).

Для того чтобы приступить непосредственно к оптимизации, для начала нужно бизнес-процессы описать. Проще всего это сделать, проведя ряд интервью со всеми участниками и составив таким образом некое «ментальное» описание процесса, которое впоследствии может быть переведено в «вещественную» форму (например, в план процесса в нотации IDEF0 или блок-схем). Собственно, данная репрезентация и станет отправной точкой для оптимизации.

Как найти точки оптимизации?

Рассмотрим теперь, какими способами можно найти точки оптимизации процесса. Самый простой и быстрый способ определить точки оптимизации - помочь найти их людям в ходе интервью. Как правило, у каждого из них есть что сказать и что улучшить. Все эти моменты я стараюсь записывать и впоследствии учитывать при оптимизации.

Следующий способ -зафиксировать свои соображения и идеи по ходу интервью. Зачастую получается, что во время интервью возникают различные гипотезы, которые я стараюсь фиксировать и обрабатывать позднее (как вариант - проговорить их сразу же, но тогда есть риск уйти в обсуждение гипотез, а не в работу по сути).

Еще один вариант - на этапе обработки результатов внимательно «пройти» всю цепочку работ, выявляя узкие места и намечая возможные направления оптимизации. Кстати, он эффективен, когда речь идет о хорошо знакомой аналитику области. В сфере незнакомой предложить что-то действительно стоящее - достаточно сложно.

Очередной способ - обсудить результаты на собрании экспертов. То есть собирается команда экспертов в предметной области (работников организации, и, возможно, приглашенные эксперты), которые намечают точки оптимизации процессов. Как разновидность этого способа я практиковал привлечение не только экспертов, но и руководителей различных рангов. Получалось неплохо с точки зрения экономии времени и эффективности конечного результата.

На этом этапе кроме формирования идей важно выполнять их анализ на реализуемость и на расходы, которые следует предусмотреть на изменения, вкупе с возможной выгодой. Между прочим, проводить идеи по оптимизации сквозь «сито реальности» очень полезно. Во-первых, работа с «ситом» позволит лучше сформировать и понять критерии оптимизации. Во-вторых, прогоняя через «сито», мы выносим на обсуждение экспертов и руководства идеи, которые могут принести определенный эффект.

В ряде случаев я фиксировал идеи «из отбраковки» и предлагал ознакомиться с ними экспертам. С одной стороны, в «отбраковку» могло попасть что-то дельное. С другой - элементы идей могли пригодиться при обсуждении оптимизации процессов. И с третьей - я демонстрировал логику «сита», чтобы снять вопросы типа «почему эта идея не в скопе».

Важно отметить, что для оптимизации процессов необходимо выбирать «правильную» нотацию (способ описания) бизнес-процесса. Ведь процесс, описанный в определенной нотации, может оказаться непригодным для дальнейшей трансформации «де-юре». Например, потому что он в силу выбранной схемы не содержит важной информации или, наоборот, имеет избыточное описание. И если второй случай (избыточное описание) чреват легким раздражением, то первый (недостаточность информации) в худшем варианте способен породить повторный виток описания. Поэтому очень важно, приступая к описанию бизнес-процессов с целью оптимизации, выбирать схему, которая будет необходима и достаточна для дальнейшей работы.

Карта оптимизации и тестирование

После того как найдены точки оптимизации, следующим шагом станет непосредственно построение карты предполагаемой оптимизации. Карта включает, во-первых, описание (схему) оптимизированного процесса, во-вторых, перечисление выгод от оптимизации и, в-третьих, краткий перечень мероприятий по оптимизации.

Карта оптимизированного процесса выносится либо на суд внутренних экспертов, либо сразу на защиту. Зависит от ситуации - в моей практике были случаи, когда с участниками процесса обсуждались отдельные оптимизации, которые после сводились в одну карту. Она, в свою очередь, представлялась на защите всем заинтересованным лицам, анализировалась и утверждалась. А бывало, что карта оптимизированного процесса в целом изначально разрабатывалась с участниками процесса - экспертами - и представлялась руководству в формате презентации. При этом универсального рецепта, как действовать в той или иной ситуации, - нет, все зависит от самой ситуации, целей организации, целей аналитика и его влияния на формат работы.

Важной точкой в вопросе оптимизации процессов лично я считаю «прогон» (моделирование) измененного процесса. Делается он так же, как в разделе «Как описать процесс?». Поэтому не буду повторять ранее изложенное, просто скажу, что «прогон» измененного процесса целесообразно делать путем сбора всех ключевых сотрудников процесса и последовательного моделирования движения работ по процессу, с разными возможными входными данными, вариациями и т. д. Эту операцию следует выполнять до момента защиты процесса. Операция очень полезна, потому что позволяет выявить вероятные узкие места, вскрыть не увиденные ранее противоречия и т. д. Кроме того, в результате такого моделирования могут и должны быть внесены корректировки в измененный процесс. А это, кроме того, что решает основную задачу - оптимизацию процесса, создает и задел для решения дополнительной задачи, а именно вовлечения сотрудников в ценность оптимизации и получаемых выгод.

Как внедрять изменение?

Самый интересный вопрос, который мне часто задавали: а что происходит после того, как сформирована и утверждена карта оптимизированного процесса? Я всегда отвечаю, что происходит «магия». На самом деле происходит самый интересный момент - внедрение изменений в процесс. Как я уже говорил, в данную карту, помимо самого процесса, резонно включить перечень мероприятий по внедрению изменений. А их, в свою очередь, целесообразно обсудить с всеми участниками и экспертами. А также утвердить у руководства. Фактически перечень мероприятий представляет собой прообраз плана трансформации бизнес-процесса. Для того чтобы он принял законченный вид, нужно облечь его в формат плана и принять к исполнению.

Тут возникает следующий тонкий момент, связанный с приоритизацией: какие процессы оптимизировать первыми, какие - вторыми, а какие не стоит вообще (например, потому что они не важны).

После того как проведена приоритизация, приступают непосредственно к реализации изменений. Хорошей идеей, с моей точки зрения, является вынесение деятельности по внедрению оптимизаций в процессы в отдельный проект с постпроектным мониторингом. В какой-то мере такие мероприятия могут гарантировать как конкретный результат, так и ретроспективу того, что получилось в итоге. Кроме того, подобный подход в теории обеспечит расстановку контрольных точек, бронирование ресурсов, контроль изменений онлайн.

Еще важный момент, особенно при оптимизации больших процессов. Нередко получается так, что изменения в одном процессе могут быть растянуты во времени или требовать значительных усилий. Здесь целесообразно, кроме выделения очередности внедрения изменений в процессы, выстроить очередность изменений в больших процессах и придерживаться ее, согласно расставленным приоритетам. Это позволит сделать оптимизацию более гладкой и, как косвенный итог - управлять ожиданиями руководства относительно скорости и результата оптимизации процессов.

Я считаю, что в ходе внедрения измененного процесса как минимум необходимо подготовить наглядные пособия для сотрудников:

Схему процесса в целом . Полезно довести до всех или почти до всех ключевых участников процесса. Почему? Потому что сотруднику обычно важно не просто работать, а понимать, к чему приводит его работа, для чего она нужна вообще. Я часто при презентации схемы стараюсь найти «выходы» из процесса на дивиденды организации и продемонстрировать, как труд каждого сотрудника влияет на их же прибыль.

Регламент работы сотрудника, он же «ролевая инструкция» . Тут очень подробно написано, кто что делает на каком шаге. И в идеале - что делать в непонятных ситуациях (схема эскалации, заморозки решения и т. д.);

Ответы на часто задаваемые вопросы (это может быть некоторая онлайн пополняемая база знаний).

Предположим, мы подготовились к внедрению: есть смоделированный процесс, есть материалы и согласованная схема мероприятий... Вроде бы - бери и делай. Но и в период внедрения требуется соблюсти определенные правила. Их несколько.

Внедрение изменений в процесс должно получить официальный статус. Для этого необходимо выпустить приказ или распоряжение об изменении процесса, в котором, в частности, должны быть зафиксированы полномочия ответственных за изменение и роль аналитика процесса, а также список участников и их конкретные действия. Особенно это актуально для крупных государственных организаций - там без приказа, скорее всего, не будет вообще ничего.

Внедрение обязательно должно включать работу с участниками процесса, которых затрагивает и не затрагивает изменение. На встрече происходит презентация схемы участникам процесса («как было», «как будет» и ключевые изменения), обозначаются даты, план мероприятий и ответственные (в идеальном варианте данные работы необходимо включать в приказ, для обеспечения их проведения).

Необходимо заранее подготовить регламенты. Они могут быть частью приказа, на них может быть ссылка в приказе, но они должны существовать. В регламентах должно быть написано, что теперь должен делать применительно к процессу каждый его участник, как будет оцениваться его работа и кто этим займется (на практике часть «кто и как оценивает» обычно вызывает ступор - именно поэтому ее надо проработать максимально подробно).

Внедрение необходимо делать, заручившись поддержкой сотрудников, участвующих в процессе. Можно и «по-жесткому»: без поддержки, но эта схема работает, только если управление в принципе построено на жесткой вертикали.

И про людей

Еще один весьма актуальный вопрос, который следует затронуть: как работать с сопротивлением, возражением, страхом? Не секрет, что любое организационное изменение (а изменение процессов - это именно оно) обычно вызывает стресс и панику среди рядовых сотрудников. И если с ним ничего не сделать, то могут возникнуть последствия, связанные с ухудшением климата в коллективе. И, соответственно, ухудшение производительности в целом, вплоть до саботажа.

Как не допустить этого? Во-первых - до начала проекта открыто его анонсировать. Довести до каждого сотрудника, особенно до тех, кто непосредственно работает в трансформируемых процессах, цели и задачи реорганизации.

В самом начале необходимо познакомить команду проекта с сотрудниками, выстроить между ними открытый диалог. Причем это не просто слова: люди, как правило, склонны к персонализации. В итоге - если команда трансформации найдет общий язык с сотрудниками, которые задействованы в процессах, сами изменения будут восприниматься легче и их внедрение, вероятно, не будет сопровождаться сопротивлением.

В ходе изменений нужно держать в фокусе внимания не только само изменение, но и людей. Универсального рецепта на этот случай нет, но общие рекомендации дать можно. Важно, как минимум постоянно быть в контакте с ключевыми участниками процесса - совместно вырабатывать план трансформации, делать шаги, оценивать итоги.

Если в результате трансформации должны быть проведены кадровые перестановки, их следует готовить заранее. Если перестановки связаны с перемещением, то разъяснить тем, кого перемещаем, как это будет происходить, когда и что они выиграют и что, возможно, потеряют. Если перестановки связаны с увольнением, оно также должно готовиться заранее, с точки зрения юридических оснований, компенсаций и т. д. Увольнения важно не замалчивать, и в любой момент времени быть готовым дать ответ на вопрос «почему ушел такой-то сотрудник?».

Необходимо помнить о том, что лучшее лекарство от коллективного страха - максимальная прозрачность ситуации для любого, находящегося в ней.

Сложнее дать рекомендации по работе с противодействием, хотя общие рекомендации тоже, безусловно, есть. Во-первых, надо выявить возможные и фактические источники противодействия. Во-вторых, постараться вовлечь их в инициативную группу по изменению - зачастую такого рода признание снимает противодействие, превращая противника в союзника. В-третьих, разъяснять личные выгоды для каждого противодействующего (тут важно не покупать лояльность, а именно демонстрировать реальные выгоды). В-четвертых, на всякий случай быть готовым к тому, что противодействующий покинет компанию (например, в знак протеста).

Ключевые слова: ,

Горячие темы: Бизнес в цифре

ИТ эксперт. Высшее техническое образование. Публикуется в ИТ-прессе с 2001 года, с IT Manager сотрудничает с 2009 года. Основные интересующие темы: отношения ИТ и бизнеса, облака, технологии ИТ для бизнеса, управление, проекты, консалтинг, СПО.

Современный бизнес в некоторой степени отличается от бизнеса предыдущих поколений, если говорить о мире в целом, и в корне, кардинально – от предпринимательской деятельности в нашей стране, где было достаточно просто выполнять свою работу и производить определенный «плановый» продукт, без оглядки на внутреннюю эффективность. Но изменение политической ситуации в стране, мировой технический прогресс вместе с конкуренцией изменили вектор построения компаний, по сути, вынудив предпринимателей новой эры концентрировать свои усилия, в первую очередь, на продуктивности работы. Произошло сразу несколько серьезных преобразований бизнеса, бизнес-инструментов и бизнес-систем, одним из которых стало появление таких понятий, как процессное управление и бизнес-процессы.

О том, почему процессное управление сегодня – самый продуктивный метод управления бизнес-цепочками внутри компании, какую роль бизнес-процессы и их автоматизация играют в компаниях, каким образом, собственно, возможно автоматизировать процессы и что дает с точки зрения результативности система автоматизации бизнес-процессов компании – поговорим в сегодняшнем материале.

Развитие бизнес-процессов в современном мире

В некотором смысле бизнес-процессы существовали еще на заре предпринимательской деятельности. Интуитивно люди, которые занимались торговлей, уже выстраивали некоторые упорядоченные наборы последовательных действий, чтобы достигнуть какого-то результата в плане экономической эффективности. Тогда для них, скорее всего, это выглядело просто логичным или удобным способом организации своей предпринимательской деятельности. Поэтому термин «бизнес-процесс» вошел в употребление, означая нечто понятное на интуитивном уровне любому, кто занимается бизнесом.

Изначально бизнес процессы фактически представляли собой инструкции, фиксировавшие наиболее корректное описание того, как надо выполнять определенные действия. Технически это были разрозненные регламенты того, как компания выполняет те или иные процедуры. Позже предприниматели осознали необходимость работы с этими документами на более глубоком уровне. Это был первый опыт исследования бизнес-процессов, чтобы повысить их продуктивность.

В 20-х годах XX века процессы начали описывать не только словами и последовательностью, но простейшими блок-схемами с графическим оформлением взаимосвязей на подобии: «если сделать так – будет это, если сделать иначе, будет то». Потом пришло время связанных алгоритмов, вместе с которыми бизнес-процессы, как элемент управления эффективностью и предприятием в целом, все более формализуется и закрепляется в качестве MUST HAVE во всех отраслях предпринимательской деятельности.

С приходом компьютерной эры и открытием новых возможностей в части технического сопровождения бизнес-процессов, начались попытки перевода бизнес процессов в электронный вид, формирования устойчивых горизонтальных и вертикальных связей между различными процессами, а вместе с этим и первые попытки автоматизации небольших участков деятельности.

Все это и являлось прародителем будущей тотальной автоматизации бизнес-процессов, направленной на повышение эффективности компании. Впоследствии целый ряд разработчиков, увидевших потенциал автоматизации бизнеса и возможность разработки решения, которое можно будет внедрять фактически неограниченное количество раз в разных компаниях, вышли на рынок автоматизации и стали предлагать бизнесу различные решения в области бизнес процессов, применимые для любых функциональных уровней бизнеса.

Началось тотальное моделирование бизнес-процессов, появились электронные системы контроля и учета, качества, развились процедуры стандартизации и регламентирования нормативных показателей и путей минимизации отклонений от них.

Так сформировалась и продолжила свое развитие идея о необходимости строить ориентированный на результат бизнес, опирающийся на определенные стандарты. Фактически, это был ответ на вызов времени и необходимости повышать свою конкурентоспособность, это «ответ на вызов потребителей» и логичное развитие компаний и рынка.

Бизнес-процесс как ключ к успеху

Любая коммерческая компания ориентируется на единственный результат – заработок денег. Для достижения этой цели в компании, в зависимости от сферы ее деятельности и размера, осуществляется определенное количество действий. Все они при этом должны иметь определенный конечный результат, а совокупность этих результатов в итоге приводит компанию к реализации поставленной задачи и получению прибыли. Поэтому любая компания независимо от вида ее бизнеса, отрасли, географии и других характеристик будет представлять собой систему взаимосвязанных бизнес-процессов независимо от того, чем эта компания занимается.

Любой бизнес-процесс в компании, в свою очередь, имеет владельцев и цепочку участников, совместная работа которых в рамках определенного запланированного стандарта обеспечивает достижение нормативного результата. Помимо этого каждый процесс имеет заданные точки контроля, по которым владельцы процессов могут контролировать промежуточные результаты и при необходимости принимать управленческие корректирующие меры.

Именно в совокупности результатов различных процессов компании и заключается цель основной деятельности.

Сегодня управление бизнес-процессами стало не просто важной, а скорее неотъемлемой частью бизнеса эффективных предприятий. Сложно представить себе по-настоящему прогрессивную и экономически эффективную компанию, система организации которой не базировалась бы на процессном подходе к бизнесу. Составными частями бизнес-процессов регламентируются нормативные производственные показатели, расходы финансовых и производственных ресурсов, продуктивность персонала и фактически экономический потенциал предприятия.

Параллельно бизнес-процессы стали выполнять и еще одну важнейшую функцию: нейтрализацию влияния человеческого фактора. Независимо от степени технической оснащенности компании или уровня технического прогресса в компаниях все равно работают люди, а не роботы, поэтому на определенном организационном уровне влияние человеческого фактора проявляется в любом случае. Для того чтобы возникла возможность нормативного контроля действий персонала, в бизнес-процессах прописываются ключевые показатели эффективности для сотрудников компании, степень их ответственности и фактической продуктивности в рамках рассматриваемого процесса. Таким образом, обеспечивается органическое функционирование системы, в которой «все на своих местах» и контроль ведется не только за итоговой результативностью процесса, но и за вкладом в процесс каждого включенного в него звена бизнес цепочки.

С аналитической точки зрения система бизнес-процессов становится источником индикаторов, метрик и знаний для менеджмента организации, поскольку позволяет не только контролировать текущий статус, но и формировать прогнозы и сценарии для повышения эффективности компании в перспективе. Аналитика бизнес процессов, или как это принято называть в экономической литературе – исследование бизнес процессов, позволяет максимально детально рассматривать бизнес с точки зрения ориентира на продуктивность. Менеджмент при правильном подходе к модернизации процессов может постепенно улучшать практически все ключевые показатели компании:

  • Улучшить производственный процесс с точки зрения его скорости, стоимости и качества продукции;
  • Повысить продуктивность и эффективность персонала, а также вытекающие из этого вопросы личной финансовой мотивации и общего фонда расходов труда на персонал;
  • Оптимизировать административный блок процессов и расходов операционного характера;
  • Повысить качество внутренней структуры, порядка документооборота и внутренней операционной дисциплины в компании;
  • Улучшить качество внешних и внутренних коммуникаций компании.

Вообще, процессный подход предполагает постоянное улучшение и стремление к бесконечной оптимизации компаний, поэтому перечислить все функциональные центры, работу которых можно улучшать на основе аналитики процессов этих центров – невозможно. Поэтому необходимо в первую очередь руководствоваться логикой и ориентироваться на специфику конкретной организации, здраво оценивая реальный потолок улучшения того или иного процесса. Улучшение ради улучшения не имеет никакого смысла с точки зрения повышения экономической эффективности. Индивидуальные особенности конкретного бизнеса гораздо лучше определят необходимость и правильный путь для оптимизации, чем шаблонные улучшения, пропитанные философией бесконечного повышения эффективности.

Автоматизация бизнес процессов как путь в будущее

Эра цифровой экономики дала бизнесу множество новых возможностей для повышения собственной процессной эффективности. Ведущие бизнес-аналитики активно трудились над разработкой темы процессного управления и оптимизации бизнес процессов в последние десять лет. Было разработано множество различных подходов и принципов управления компаниями, основанных на методике бизнес-процессов, и каждый из них заслуживает особого внимания. Они могут обладать разной степенью эффективности для конкретной компании, поскольку в какой-то мере зависят от вида бизнеса, масштаба и других характеристик экономики предприятия, но все они позволяют сделать вывод, что автоматизация бизнес процессов – это самый короткий путь к прогнозируемой модели управления и развития бизнеса.

На этом пути автоматизация бизнес процессов дает возможность повысить конкурентоспособность через увеличение продуктивности конкретного участка бизнес цепочки, облегчая ряд совершенно стандартных операционных процедур:

  1. Автоматизация упростит вопросы учета и отчетности, первичного бухгалтерского учета, ввода больших массивов информации, контроля товарных остатков и прочих математически/вычислительных процедур, которые традиционно являются преимущественно ручным блоком трудоемких операций. Чаще всего это достигается внедрением в практику использования автоматизированных IT-технологий, ориентированных на обработку документов и самостоятельное проведение операций, замены ввода данных на различные элементы сканирований и прочие упрощения таких рутинных процедур.
  2. Автоматизация процессов позволяет сократить или оптимизировать основные издержки предприятия. Основными расходными статьями традиционно являются производственный процесс и персонал компании, а автоматизация процессов даст возможность выделить основные узкие места и ключевые неэффективные звенья кадрового состава, а также добиться снижения расходов за счет исключения этих составляющих из операционной деятельности.
  3. Автоматизация процессов дает возможность повышать качество выпускаемой продукции за счет соблюдения нормативных требований и реализации мероприятий внутреннего контроля.
  4. Автоматизация процессов дает возможность высвободить интеллектуальный ресурс управленческого звена и ключевых специалистов компании, перенаправив их усилия с выполнения трудоемких и рутинных ручных операций на развитие компании.



Главный принцип любой автоматизации заключается в том, что она должна быть интегрирована на все уровни организационной структуры, связанные с данным (автоматизированным) бизнес-процессом. Нельзя автоматизировать процесс документооборота, не включив в него курьерскую службу компании и секретариат. Или, например, автоматизировать какой-либо цикл производственного процесса, но не автоматизировать вопросы логистики или работы с рекламациями клиентов. Если бухгалтеры продолжают считать платежки руками на калькуляторе, имея автоматизированный процесс согласования счетов и визирования оплаты, то бизнес процесс можно считать автоматизированным не полностью. А это, в какой-то мере, лишает его смысла вообще, потому что в случае возникновения ошибки (человеческий фактор), отследить ее вовремя не получиться, и она повлияет на последующие процессы.

Компании сталкиваются с разными сложностями при автоматизации бизнес процессов в зависимости от своих внутренних особенностей.

Например, ведение ручной бухгалтерии и разрозненного финансового учета табличного вида, по сути, тоже имеет определенное количество процессов внутри своей структуры, но внедрение комплексной автоматизации в это рабочее поле вызовет определенные проблемы, обусловленные не только техническими особенностями, но и противодействием со стороны персонала.

Поэтому проекты по автоматизации бизнес процессов почти всегда разрабатываются с нуля, так как невозможно, не погружаясь в специфику компании, определить те проблемы, которые могут всплыть в отдельно взятой организации. Случаются ситуации, когда менеджмент принимает решение об автоматизации, не приняв в расчет, что компания к ней попросту не готова, и реализовать проект не представляется возможным в принципе. Для того чтобы этого избежать, следует отчетливо представлять цель, которую необходимо достичь в результате автоматизации, определить, какие ресурсы нужны для достижения цели, какой персонал будет вовлечен в реализацию автоматизированного бизнес процесса, и какие рыночные тенденции могут оказать влияние на бизнес процесс в краткосрочной перспективе.

Только проработанная стратегия автоматизации процесса может обеспечить конечный результат и исключить риск работы ради работы. Всем известны примеры полной неработоспособности бизнес-процессов после их «автоматизации» или ситуации, когда невозможно завершить проекты по автоматизации из-за внутренних факторов. Поэтому немного остановимся на типичных проблемах, с которыми сталкиваются компании:

  1. Ошибки при переносе процесса в автоматизированную систему – самая частая проблема, вызванная желанием сэкономить. Неопытные менеджеры, чаще всего сами держатели процесса, пытаются перенести свою работу в информационное поле и автоматизировать. В результате – потеряны детали, нарушена или вообще не соблюдается логика, нет последовательности автоматических действий, а весь автоматизированный процесс можно назвать разве только «костылем». Это логичный результат, потому что профессионалы продаж не могут быть профессионалами в области построения автоматизированных бизнес процессов. Такая работа требует особой квалификации и опыта, а результат может быть достигнут только совместными усилиями узких специалистов и владельца процесса. Если речь идет о процессе распространяющимся за рамки одного подразделения или компания решила автоматизировать сложный процесс (закупочный, производственный и т.п.), то только квалифицированная команда способна детально исследовать процесс «как есть» и создать работоспособную автоматизированную схему.
  2. Саботаж автоматизации – это проблема, которая делит пальму первенства с ошибками при переносе процесса в автоматизированную систему. Команда, понимая, что автоматизированный процесс высвобождает у них временной ресурс, начинает мешать внедрению автоматизации, руководствуясь инстинктом самосохранения или элементарным нежеланием что-то менять в работе и учиться новому. Эту проблему достаточно сложно нивелировать на сто процентов, хотя при грамотном менеджменте и наличии реальных планов на ресурс в лице персонала, можно донести до команды, почему менеджмент принял решение об автоматизации, и какую роль в дальнейшем будет играть тот или иной специалист. Конечно, это не сработает, если ключевая цель автоматизации – сокращение издержек на персонал (а для многих компаний персонал по-прежнему остается самым дорогостоящим звеном).
  3. Техническая неподготовленность персонала – проблема, которая проявляется, как правило, либо в самом начале автоматизации, либо, наоборот, когда проект закончился и уже запущен. Вопрос торможения автоматизации в связи с техническими затруднениями, по сути, меньшее из зол, с которым можно столкнуться в этой сложной работе, поскольку всегда есть возможность произвести обучение персонала и создать в компании внутреннюю систему наставничества во избежание таких проблем в будущем.
  4. Не рассчитали свои силы – проблема инвестиционного характера. Планы на автоматизацию формулировались колоссальные, ресурсы компании были посчитаны неверно, и поэтому в какой-то момент стало очевидно, что на реализацию проекта не хватает ресурсов. Что делать? Оптимизировать сам процесс внедрения (время, скорость), искать ресурсы (заемные, отсрочки), менять условия (добиваться скидок, менять подрядчиков, сокращать объемы команд) и искать возможности для завершения процесса автоматизации любыми доступными способами, если он в итоге сулит компании прибыль.

Если указанные выше ошибки бизнесу удалось преодолеть, поскольку проблемные ситуации были проработаны заранее, перед ним встанет вопрос, как правильно отрегулировать автоматизированный бизнес процесс. Рассмотрим свойства таких бизнес-процессов поподробнее:

  • Автоматизированный бизнес процесс должен обладать целью и задачами, которые компания решает в рамках этого бизнес процесса. Это значит, что любой пользователь процесса и менеджер компании, взглянув на бизнес процесс, может понять, какова конечная цель бизнес процесса, какие задачи необходимо выполнить, а также кто возьмет на себя ответственность за их выполнение на пути к этой цели. Например, если автоматизированный бизнес процесс – кросс-сейл товарных остатков прошлого года, то глобальная цель такого проекта заключается в том, чтобы распродать залежавшийся товар. Задачи на пути к достижению этой цели: формирование товарного ассортимента, написание скрипта на сайт, прикрепляющего товары по особому алгоритму в рекомендации покупателям, е-мейл рассылка по установленным правилам, установление скидок на товар прошлой коллекции и прочие действия, за каждым из которых закрепляется ответственный специалист или подразделение.
  • Четкий автоматизированный процесс должен быть отрегулирован во времени. Это фактически главный принцип процессного управления: все действия и организация работы должна укладываться в какое-то регламентное время. Соответственно, говоря о первом примере с распродажей остатков, у такого проекта должен быть определен диапазон активности и скорость продуктивности. Диапазоном будет ограничено время начала работы и подведения результатов по процессу в целом, а скорость продуктивности (также измеряемая временем) даст возможность анализировать вклад каждого звена процесса в общий результат, контролируя при этом нарушение сроков исполнения работ, не обоснованное объективными причинами.
  • Автоматизированный бизнес процесс должен иметь разделение на этапы и точки контроля. Это помогает контролировать ход выполнения процесса в зависимости от его стадии или фазы, распределять ответственность между участниками процесса и дополнительно оперативно анализировать процесс на этапе неполного завершения. Важно заметить, что внутри этапов команде предоставлена максимальная свобода действий и последовательности их активностей, но на точках контроля требуется жесткая отчетность по нормативному результату этапа и беспрекословное соблюдение назначенных сроков.
  • Система нормативов автоматизированного бизнес процесса должна содержать достаточно сведений для возможности контролировать ход процесса. Процесс обязательно регламентируется набором документов и отчетностью. Совокупность этих элементов управления процессом позволяет команде искать выходы из затруднительных ситуаций в рамках установленного поля, а не просто следуя инструкции.
  • Автоматизированный бизнес процесс можно рассмотреть не только с точки зрения указанных ранее аспектов, но и в разрезе используемых для его реализации ресурсов: рабочих часов, финансов, оборудования, технологий и прочего. Все эти вопросы должны быть изначально продуманы и рассмотрены на этапе внедрения бизнес процесса с учетом неких прогностических изменений ситуации, чтобы гарантировать завершение бизнес-процесса запланированным результатом.
  • Ответственные за исполнение и результативность бизнес процесса люди. Насколько бы ни была совершенной система автоматизации бизнес-процессов, ей нужен живой контролер, способный смотреть на ситуацию глобально и критически. Поэтому любой автоматизированный бизнес процесс должен быть обеспечен ответственными за его исполнение сотрудниками, задача которых заключается не только в предметной функции, но и в контроле ключевых точек процесса.
  • Информирование участников – важнейший элемент взаимосвязанной системы бизнес процессов, который является также и инструментом контроля. Наибольшую продуктивность показывают системы автоматического информирования обо всех происходящих в бизнес процессе действиях, построенные по принципу точек, на которых система сама генерирует уведомления и информирует особый список участников. Конечно, ручное информирование тоже работает, но требует дисциплины и очень часто дает определенные сбои.


Исходя из вышеперечисленного, очевидно, что автоматизация бизнес процессов, вне зависимости от локации, отрасли, рынка или направления бизнеса, то есть для любой компании – это принципиально новый уровень ведения бизнеса. Переоценить выгоды от внедрения автоматизированных бизнес-процессов невозможно, поскольку в эпоху жесточайшей конкуренции и цифровой экономики они становятся абсолютной необходимостью для тех компаний, которые хотят сохранить и приумножить свою долю рынка. Внедряя у себя автоматизированные бизнес процессы, компания не просто получает в свой актив определенный набор очевидных преимуществ по сравнению с конкурентами, она выводит свой бизнес на принципиально новый уровень ведения бизнеса. Отчасти этот процесс можно назвать мировоззрением, ориентированным на внутреннюю результативность и повышение эффективности. В двадцать первом веке ручной труд больше не является основой экономики, и компании могут ускорить свое развитие, увеличить продуктивность и скорость своей работы, улучшить показатели качества обслуживания или снизить затраты за счет интеллектуальных достижений человечества в области автоматизации бизнес-процессов.

Как выбирать персонал

На различных стадиях развития ИТ-отделу нужны разные люди. Эффективная команда, поддерживающая существующие бизнес-процессы, может не являться таковой при решении задач второго и третьего уровней, поэтому требования к руководителям ИТ-отделов и сотрудникам на разных уровнях зрелости неодинаковы.

На первом уровне нужны специалисты с хорошими техническими знаниями, умеющие оперативно искать проблемы в существующей ИТ-инфраструктуре или быстро пишущие «заплатки» для бизнес-приложений. Руководителю достаточно иметь техническое образование и понимать, что делают его сотрудники. На этапе отбора персонала следует обращать внимание на наличие сертификатов, подтверждающих технические навыки сотрудников. Имеющиеся программы сертификации практически по всем областям современных ИТ-технологий существенно облегчают процедуру подбора специалистов.
На втором уровне руководителю необходимо понимать бизнес-процессы компании, чтобы искать пути их улучшения. Сотрудники ИТ-отдела должны уметь общаться с представителями бизнеса и транслировать их пожелания в ИТ-проекты. Далеко не все сотрудники и руководители, успешно зарекомендовавшие себя на первом уровне, способны безболезненно перейти на второй. Программы развития личностных компетенций и оценка сотрудников по комплексным показателям могут помочь перейти на второй уровень без больших потерь. Тем не менее если компания работает в высококонкурентном бизнесе, то применение стратегии Shape up or ship out («Или развиваем, или увольняем») неизбежно.

На третьем и четвертом уровнях наличие бизнес-образования становится критическим фактором для ИТ-руководителя. Необходимо понимать возможные стратегии развития компании, технологии маркетинга и управления поставками, а также уметь считать возврат от инвестиций в ИТ-проекты и в некоторых случаях хорошо знать производственный процесс.
ИТ-менеджер должен общаться с правлением компании на одном языке.

Техническая грамотность сотрудников отходит на второй план, так как большинство проектов выполняется с помощью внешних ИТ-компаний, которые берут на себя и поддержку продукта. В динамично развивающихся компаниях ИТ-технологии меняются достаточно часто, и знания конкретных продуктов будут уже не актуальными через один-два года.

В этом случае на первый план выходят личностные компетенции сотрудников, их готовность постоянно обучаться и расширять кругозор. Они должны эффективно общаться как между собой, так и с внешними компаниями.

Целеустремленность и способность принимать решения приобретают первостепенное значение (по сравнению с техническими знаниями) для найма сотрудников в такой отдел. В данной ситуации при поиске новых сотрудников существенно возрастает роль отдела HR. Решающее слово о найме новых людей должно быть за ним, а не за руководителем того или иного ИТ-отдела.

Для того чтобы сфокусироваться на задачах третьего и четвертого уровней зрелости, на этом этапе часто используют аутсорсинг ИТ-процессов первого и иногда второго уровня. Наиболее часто встречается аутсорсинг центров поддержки пользователей и некоторых простых бухгалтерских приложений.

Как измерять эффективность

Теперь рассмотрим, чем различаются принципы оценки эффективности работы ИТ-отдела, находящегося на разных уровнях зрелости.

На первом уровне , когда инвестиции в ИТ минимальны и основная финансовая составляющая – это зарплата сотрудников, эффективность ИТ-отдела можно оценивать по соотношению числа ИТ-сотрудников и общего количества работников компании. Приемлемой считается такая цифра: один ИТ-специалист на 50–80 человек, в зависимости от размера компании.
На втором уровне зрелости, когда стоимость ИТ-отдела начинает в большей степени определяться инвестициями в ИТ-технологии, имеет смысл ориентироваться на более комплексный показатель, такой как стоимость ИТ (люди + + технологии) в процентах от оборота компании. В этом случае для типичной не-ИТ-компании можно ориентироваться на цифру 1–3% от оборота. Для высокотехнологичных бизнесов сумма бывает больше.

На третьем уровне зрелости необходимо считать возврат от инвестиций. В этом случае компания сама определяет процент, ради которого она готова внедрить тот или иной проект. Скорее всего, в финансовом отделе эти цифры уже известны. На четвертом уровне речь может идти о получении новой доли рынка. В этом случае руководители бизнеса определяют, получение какой дополнительной доли рынка может считаться успехом, и оценивают эффективность инвестиций в ИТ на основании этого показателя.

Пирамида зрелости ИТ-отдела с учетом показателей эффективности его работы представлена на рис. 2.

Особенности больших компаний

Крупные мультинациональные компании имеют некоторые особенности принципов построения ИТ-отделов. Работая в высококонкурентных секторах рынка, они вынуждены постоянно думать о снижении издержек, независимо от того, на каком уровне зрелости находится ИТ-отдел. В связи с этим такой показатель, как количество сотрудников ИТ-отдела, всегда остается актуальным.

К сожалению, задачи минимизации операционных издержек и развития бизнеса являются противоречащими друг другу, и для одновременного достижения обеих целей требуются определенные действия. В настоящий момент практикуются два подхода.

  • Централизация.
  • Виртуализация.

Централизация – обслуживание географически распределенной компании одним или несколькими ИТ-бэк-офисами. Это позволяет существенно сократить количество ИТ-сотрудников, исключая дублирование функций в разных отделениях компании. Основной задачей при централизации является сохранение ИТ-сервисов на приемлемом уровне, так как некоторое ухудшение качества при этом неизбежно.

Виртуализация – создание команды, географически распределенной, но работающей в единстве. Для взаимодействия сотрудников внутри такой команды применяются современные средства коммуникации и совместной деятельности.
Финансовую выгоду в данном случае дает использование сотрудников в экономически более «выгодных» регионах, где ниже зарплаты и дешевле аренда офисов. При реализации такой стратегии следует уделять особое внимание построению эффективной системы взаимодействия разных частей команды.

В настоящий момент централизация используется подавляющим числом крупных компаний. Виртуализация начинает медленно набирать обороты – по мере развития и распространения недорогих технологий общения и совместной работы.

Модель ИТ-отдела как сервисного приложения компании уходит в прошлое. Зарождается новая философия инноваций и эффективности. Этот гипотетический ИТ-отдел недалекого будущего представляется небольшим по составу, более рассредоточенным и зависимым от поставщиков услуг. По-прежнему сохранится потребность в многопрофильных специалистах, не только обладающих глубокими познаниями в области ИТ, но и способных создавать на их основе новые продукты и решения. ИТ-руководители видятся не просто управляющими инфраструктуры, а лидерами инновационных процессов, умеющими перестроить соответствующим образом свой отдел. ИТ должны стать если не флагманом, то полноправным партнером в проведении экономических инновационных процессов. Рассмотрим детально отличительные черты и принципы работы постмодернистского ИТ-отдела.

ИТ-отдел будет отвечать за проведение инновационных процессов всей компании Добрая половина сорокалетней истории использования ИТ в коммерческой деятельности была в основном потрачена на автома­тизацию работы предприятия. Данный процесс может продолжаться и далее, однако ограничиться этим в условиях современного бизнеса уже невозможно. Вопрос о том, как использовать ИТ, чтобы отстоять и расширить свое место на рынке, стоит как никогда остро.

Соединив систему широкополосной связи, интернет-технологии, соответствующее программное обеспечение, мобильные телефоны и PDA, ИТ-специалист создает новые возможности и решения, которые крайне востребованы компаниями и их клиентами. ИТ-отделы не могут больше заниматься исключительно удовлетворением потребностей внутренних клиентов. Их основной задачей должна стать разработка инноваций, которые принесут прибыль компании и привлекут новых внешних клиентов. Переход к сервисно-ориентированной архитектуре (Service-Oriented Architecture, SOA) усилит потенциальные возможности ИТ-отдела активно участвовать в инновационной деятельности, так как предполагает понимание ИТ-персоналом основ функционирования компании.

Основным принципом руководства ИТ-отделом станет внедрение сервисной модели предоставления услуг ИТ-руководители располагают множеством механизмов для управления инфраструктурой и отдельной продукцией. Существуют широко распространенные системы, позволяющие контролировать практически любой аспект деятельности ИТ-отдела, начиная с библиотеки ITIL и заканчивая такими комплексными программами по разработке приложений, как CMMI и проектный менеджмент - РМР-сертификация. Представлены также некоторые общие практики, которые лежат в основе стратегии управления ИТ-отделом большинства организаций. Например, последнее исследование Forrester показывает, что у 70% респондентов внутри компании есть формальный комитет управления ИТ.

ИТ-функции будут более разобщены, их придется организовывать в единое целое Можно сказать, что процесс расформирования ИТ-отделов уже обозначился, особенно в крупных компаниях, где многие ИТ-функции, такие, как компьютерная служба помощи и текущее обслуживание программного обеспечения, исполняются аутсорсерами. Судя по всему, многие ИТ-должности станут звеньями в цепи предоставления расширенных услуг, сформированной на современных произ­водственных цепях поставки. Именно поэтому для сотрудников ИТ-отдела сейчас важны такие навыки, как управление взаимоотношениями и руководство проектами.

Исчезнут младшие ИТ-должности ИТ-отделу потребуются квалифицированные кадры, однако ИТ-руководителям будет достаточно сложно найти нужных им работников. Навыки, которые могут исчезнуть из ИТ-отделов в процессе автоматизации или в связи с применением аутсорсинга: программирование, оперативное управление, компьютерная помощь сотрудникам. А ведь на младшие ИТ-должности, как правило, нанимаются сотрудники именно с такими навыками.

ИТ-руководитель должен сделать шаг вперед ИТ-руководители, которые по инерции продолжают обслуживание своих компаний по традиционной схеме - построение инфраструктуры, разработка пакета программного обеспечения и его поддержка, либо будут вынуждены выполнять все возрастающий объем работы, либо обречены на увольнение. Но для того чтобы выжить в дальнейшем, необходимо стать ИТ-руководителем-реформатором:

    новатор - бизнесу нужна новая генерация руководителей, которые смогут не просто управлять ИТ, но с их помощью изменить компанию к лучшему;

    лидер - ИТ-директорам скоро придется сделать выбор: либо взять на себя новые функции, либо уступить лидерство другому топ-менеджеру;

    экономист - ИТ-директора должны исполнять сразу две роли - борца за снижение затрат и новатора, и возникает соблазн отказаться от одной;

    профессионал - ИТ-директор должен одинаково хорошо разбираться и в бизнесе, и в информационных технологиях, отличая технологии, повышающие эффективность, от новомодных игрушек;

    дипломат - дальновидные ИТ-директора знают, как учесть разные требования и представить удовлетворяющую всех информацию в понятных всем финансовых терминах.

Первое правило управления бизнес-процессами гласит: важно определить как роль управления информационными технологиями, так и то, как структурные подразделения могут взаимодействовать друг с другом.

Второе правило - сближение ИТ и бизнеса: руководители сферы ИТ должны быть вовлечены в координацию этапов процесса между разными департаментами, которым необходима поддержка со стороны ИТ.

Вывод: на место директора информационной службы (СIO) должен прийти директор по процессам (СРО).

Но недостаточно просто сменить название должности. Руководство компании и начальники бизнес-подразделений ожидают от человека, занимающего этот новый пост, знания потенциала инноваций, который предоставляют новые ИТ-приложения и технологии, и умения перенести их в бизнес-процессы. Компетентность СРО заключается в том, чтобы сочетать управление процесса­ми со знанием ИТ. Структуру и организацию управления бизнес-процессами, а также то, в какую категорию надлежит отнести бывшего СЮ, а ныне директора по процессам (СРО), можно представить в виде трехуровневой модели:

    на первом уровне, директорском (так называемый C-level management, включающий генерального директора - СЕО, директора по оперативному управлению - СОО, СIO, финансового директора - CFO и др.), принимаются решения о стратегически важной деятельности. В центре внимания здесь находятся ключевые компетенции, используемые компанией для производства продукции. Одна из главных обязанностей СРО - определять основной курс управления бизнес-процессами, создавать и внедрять необходимые методы, инструменты и платформы;

    на втором уровне протекают бизнес-процессы, связанные с ИТ, причем критическое значение здесь имеет децентрализация. СPО должен обеспечить доступность знаний о децентрализованном процессе для всех сотрудников, задействованных в нем и ответственных за этот процесс, а также возможность централи­зованно его улучшать, делая управление процессом обязанностью каждого сотрудника;

    третий уровень вновь выводит на первоначальный этап: результаты исполнения бизнес-процессов собираются, оцениваются и подготавливаются для того, чтобы руководство могло принимать решения и вносить коррективы. Выявленные при этом потребности в технологическом усовершенствовании в сочетании со вторым и третьим уровнем ведут к формированию новых принципов построения организации и новой технологической архитектуре. Внутри процесса такие хорошо известные технологии, как системы управления потоками работ (workflow) и системы интеграции приложений предприятия (ЕAI-системы), объединяются и комбинируются с интеграционными платформами и платформами приложений.

Очевидно, что ориентация на процессы требует от ИТ-менеджеров иных подходов к своей работе. Изменения на рынке, требования по конкурентоспособности и развитие технологий ведут к постоянной реструктуризации бизнес-процессов, которая в свою очередь требует более широких навыков и знаний, нежели только умения нести ответственность за ИТ-системы. Директор по процессам должен иметь новые должностные обязанности.

Обязанности директора по процессам - СРО

1. Определять и описывать значимые бизнес-процессы и анализировать их на основе аспектов деятельности предприятия.

2. Выявлять и устранять «узкие» места (простои, ненужные задержки и т.п.), постоянно оптимизировать процессы.

3. Создавать интегрированные, общекорпоративные бизнес-процессы, которые пересекают границы структурных подразделений и сливаются в полную цепочку создания добавленной стоимости, включающую и внешних партнеров.

4. Организовывать управление бизнес-процессами таким образом, чтобы ответственные за процессы сотрудники отчитывались за отдельные процессы и подпроцессы.

5. Обеспечивать интеграцию внутренних и внешних программных приложений.

6. Разрабатывать и внедрять высокопроизводительные, ориентированные на работу в реальном времени ИТ-платформы, включая аппаратное и программное обеспечение.

7. Устанавливать систему непрерывного мониторинга производственных процессов, в том числе системы отчетности.

8. Развивать системы технологически и организационно.

Таким образом, новый директор информационной службы становится агентом изменений в компании, обеспечивая гибкие, динамичные и построенные на сотрудничестве процессы и системы. Для лиц, выполняющих эту роль, особенно важны четыре управленческих навыка:

    коммуникационные навыки. Организационные изменения могут происходить только при поддержке со стороны внутренних и внешних партнеров. Следовательно, партнеров необходимо держать в курсе событий, ведь основополагающим фактором успешного внедрения изменений является взаимодействие;

    процедурное мышление. Потенциальный СРО должен уметь анализировать цепочку создания добавленной стоимости, используя свою компетентность в области технологий, бизнеса и организационного управления, и понимать всю эту цепочку в тер­минах динамичных процессов;

    социальные умения. Долгосрочный успех в управлении бизнес-процессами возможен только в том случае, когда сотрудники ощущают себя членами одной команды, особенно если СIO намерен ввергнуть их в процесс перемен. При формировании ко­манд и назначении ответственных за процессы (владельцев процессов) в ходе управления изменениями необходимо принимать во внимание личностные аспекты;

    мотивация и настрой на инновации. В будущем ключевым навыком для СЮ станет умение создавать во всей организации, начиная от производственного подразделения и заканчивая отделом маркетинга и высшим звеном руководства, настрой на инновации и оптимизацию.

Новый уровень ответственности СIO диктуется сегодняшними требованиями бизнеса - CGO (Chief Governance Officer) - директор по корпоративному управлению. Он отвечает за организацию эффективного взаимодействия всех отделов друг с другом и развитие системы коммуникаций в организации. Поле деятельности для CGO не ИТ, а БТ - технологии для бизнеса. Внедрять нужно только те новые технологии, которые позволяют решать задачи, стоящие перед бизнесом. Для этого современный CIO (Chief Integration Officer) должен хорошо ориентироваться в бизнес-процессах и предлагать способы их оптимизации, повышающие отдачу от инвестиций в ИТ.

Документ разработан для руководителей отделов программирования, директоров компаний, занимающихся разработкой собственного программного обеспечения, директоров по качеству, директоров по развитию, аналитиков бизнес-процессов.

Описываются общие подходы к повышению качества выпускаемых программных продуктов. Описанные методы анализа также применимы и к разовым работам по улучшению программ, так называемым «кастомизациям» существующего программного обеспечения.

Бизнес-процессы организации

Любая организация, выполняя свои функции, представляет себе, какие из них являются основными, какие обеспечивающими или дополнительными. Начиная с 2000 года, большинство методических рекомендаций определяет так называемый процессный подход к деятельности любых организаций. Для того, чтобы понять, что обозначает этот термин, необходимо определить понятия Процесс, Функция.

Функция – это элементарное действие (совокупность действий), выполняемое группой сотрудников (одним сотрудником), предназначенное для переработки информации, материалов с целью получения новой информации или новых свойств материалов. Проще говоря, функция, это действие, преобразующее некоторый вход в выход.

Процесс – это конечная последовательность функций, в общем непрерывная, имеющая владельца процесса, цели процесса, регламент и ресурсы, входной и выходной поток информации, материалов.

Отличие функции от процесса существенно и, помимо организации (владельца, цели и т.п.) заключающееся в том, что процесс является непрерывным, а функция имеет начало и окончание. В качестве примера можно привести процесс управления качеством, которые в общем случае начинает выполняться сразу после появления организации и не прекращается до ее закрытия. Одним из выходов процесса управления качеством является поток «записей по качеству». Пример функции – это распечатанный документ, заготовки, собранный автомобиль и т.п. – во всех этих случаях есть начальная информация, материал, который перерабатываясь, превращается в конкретный документ или изделие.

Очевидно, что даже если в организации не определены процессы, они существуют в том или ином виде.

Задачей любого менеджера, в соответствии с современными представлениями об организации, является определение всех процессов (бизнес-процессов) организации в соответствии с определением процесса, а именно описать:

1. Цели и задачи бизнес-процесса (прагматические характеристики);

2. Владельца (хозяина) бизнес-процесса;

3. Последовательность выполняемых функций;

4. Поток входной/выходной информации (материалов);

5. Используемые ресурсы;

6. Регламент бизнес-процесса (руководящие, описательные документы, стандарты).

При анализе бизнес-процессов менеджер (аналитик) должен определить основные производственные бизнес-процессы и вспомогательные. Например, основными производственными процессами являются: сборка автомобилей для сборочного завода, процесс разработки ПО для программистской организации, прокачка газа для газотранспортного предприятия. Вспомогательные (обеспечивающие) процессы, как правило, очень похожи во всех организациях и описаны в стандарте ИСО 9001:2008. Это такие процессы как: управление (включающее управление персоналом), закупки, продажи, складское хранение, контроль (обеспечение) качества продукции и др.

Общность процессов

Все бизнес-процессы организаций известны и определены стандартом ISO 9001:2008.

Список бизнес-процессов включает в себя:

1. Производство;

2. Управление;

3. Документирование;

4. Управление закупками;

6. Корректирующие и предупреждающие действия;

7. Управление качеством;

8. Управление жалобами клиентов.

Уникальность программистских организаций

Описанные выше требования к бизнес-процессам относятся к любой организации. Однако, у компаний, занимающихся разработкой программного обеспечения, основным производственным процессом является именно процесс разработки программного обеспечения. Уникален не только основной процесс (как, впрочем, и в любом другом производстве), но и обеспечивающие процессы, в частности процесс контроля качества продукции (в том числе тестирование).

Известные программистские организации (Микрософт, Моторола, IBM, ORACLE) уделяют вопросам качества программного кода огромное значение. Как правило, на проверку правильности программ уходит в 5-10 раз больше ресурсов, чем на их производство. В этом как раз и заключается уникальность таких организаций. Трудно себе представить, чтобы измерение детали после токарной обработки занимало в 10 раз больше времени, чем сама обточка этой детали.

Необходимость таких усилий определяется необходимостью увеличения технологичности процесса создания ПО. Не секрет, что большинство программистов считают свой труд сродни искусству. Именно для повышения технологичности и разрабатываются известные стандарты разработки ПО, такие как SW-CMM, внутрифирменные стандарты и методики программистских организаций. Как правило, внутрифирменные методики разработки ПО строго засекречены, и каждая компания использует собственные методики. Однако общее есть и во внутрифирменных методиках. Описанию этого «общего» и посвящен следующий раздел, в котором говорится только об организациях, разрабатывающих ПО.

Уникальность процесса производства

Руководителям различных уровней организаций известно, что главный метод повышения рентабельности предприятия заключается во всемерном увеличении производительности труда. На машиностроительных предприятиях приветствуется изобретательская и инновационная деятельность, позволяющая резко увеличивать производительность труда. Например, на заводах ручные операции заменяют роботизированными, производство новых изделий после их ручной обработки в начале производства стараются производить с использованием новых инструментов и технологий (иногда мотивируя рабочих простым уменьшением норм времени и материалов).

Как поступить с производством ПО? Ведь программа – это не кусок железной заготовки, которую можно обрабатывать сначала напильником, потом токарным резцом вручную, а потом с помощью робота. В институтах преподаватели часто учат программистов именно искусству программирования (с точки зрения надежности, оптимальности, быстродействия кода, например). В результате на производство приходят единичные «люди искусства», которые программируют быстро и даже корректно, но на которых нельзя положиться в критических производственных ситуациях, потому что их максимум производительности никак не совпадает с максимумом потребностей клиентов.

Большая часть оставшихся выпускников производит «сырой» продукт, который подчас страшно отдавать клиенту. Развивать бизнес, основываясь на тех или других типах программистов нереально и все чаще российские руководители программистских организаций задумываются над вопросами технологичности производства ПО.

Первые шаги в этом направлении, как правило, натыкаются на полное отсутствие российских методик и технологий, непонятность западных методологий, большую ресурсоемкость подобных работ. Данная статья предназначена как раз для помощи руководителям программистских коллективов в выборе стратегии инновации через увеличение технологичности программистского труда.

Итак, как уже было определено выше, существуют и иностранные, и локализованные стандарты, позволяющие даже при прямом их использовании существенно повысить производительность труда. А при известных затратах на разработку собственной методики удается повысить производительность (а вместе с ней и надежность, и эффективность, и безопасность, и стоимость ПО) на порядок. Эти стандарты перечислены в Источниках, в начале статьи.

С чего начать разработку собственной фирменной методики производства ПО?

Естественно с целей, которые должны достигаться применением данной методики. В настоящей статье мы делаем упор на качество программного кода, поэтому рассмотрим только те цели, которые связаны с увеличением качественных характеристик ПО, остальные цели мы рассмотрим в следующих публикациях.

В области качества программного продукта цели ставятся достаточно стандартные. Это:

1. Уменьшение сроков и стоимости разработки;

2. Корректность кода;

3. Исключение ошибок;

4. Повышение надежности;

5. Повышение эффективности автоматизируемых функций;

Все эти цели (или подцели) полностью соответствуют целям более высокого уровня:

1. Уменьшение издержек производства и технической поддержки;

2. Увеличение прибыли;

3. Увеличение производительности труда;

4. Захват большей доли рынка;

5. А также различных социальных целей, как работников предприятия, так и клиентов.

Известно, что технология разработки любого продукта включает в себя методику и инструмент, обеспечивающий выполнение методики. В свою очередь, методика включает в себя описание жизненного цикла программного продукта, регламент его производства, шаблоны проектных и организационных документов и записи по качеству. Помимо производственной методики, как уже упоминалось выше, должны быть стандартизованы обеспечивающие (поддерживающие) процессы. Ниже мы также определим обеспечивающие процессы, специфические для программистских организаций.

Большинство компаний-производителей программ, так или иначе, стандартизуют жизненный цикл. Но для целей улучшения качественных характеристик ПО необходимо детализировать соответствующие стадии и этапы разработки программ в соответствии с действующими стандартами. Как правило, все методики предусматривают следующие стадии работ (их названия могут отличаться значительно, однако последовательность работ примерно одинакова, и определена в стандартах):

1. Определение требований клиента (клиентом могут быть и внутренние структуры организации);

2. Системное проектирование (разработка требований, спецификаций, анализ и синтез будущей системы с точки зрения элементного состава, межэлементных и внешних связей, границ системы, функциональных требований и т.п.);

3. Техническое проектирование (детализация требований, спецификаций, проектирование и разработка отдельных элементов и т.д.);

4. Разработка системы;

5. Верификация (тестирование, опытная эксплуатация и т.п.);

6. Выпуск системы (релиз, версия);

7. Сопровождение системы.

Параллельно с процессом производства ПО выполняются следующие процессы:

Общие для любого производства:

  1. Управление;
  2. Управление качеством;
  3. Документирование;
  4. Управление закупками/продажами;
  5. Управление маркетингом;

Специфические для производства ПО:

  1. Управление конфигурацией;
  2. Управление требованиями;
  3. Тестирование (модульное, интегральное, нагрузочное и т.п.).

Эти, последние процессы определяются достаточно подробно стандартами. Именно эти процессы и их взаимодействие мы и будем рассматривать далее.

Управление конфигурацией

Основы процесса Управление конфигурацией определены локализованным в России стандартом: ГОСТ Р ИСО 10007-2007. К сожалению, локализованный стандарт в силу языкового (и процессного) барьера нетривиален в своем применении, поэтому мы попытаемся в упрощенной форме изложить его требования. Благодаря такому изложению любая компания может построить процесс управления конфигурацией в течение 2-3 месяцев.

Начнем с терминологии, причем приведем термин конфигурация в контексте действующих российских компаний, не противореча в то же время стандарту.

Базовая конфигурация - целостная совокупность данных о продукте, прошедшая процедуру утверждения и принятая в качестве базового описания конфигурации (эталона). Базовые конфигурации периодически обновляются, образуя новую базовую линию в последующий момент времени путем учета истории авторизуемых изменений. Например, часто программистские компании выпускают версии своих продуктов под номерами 3.02, 3.03, … 3.10… 4.00. При этом подразумевается, что целая часть числа обозначает базовую конфигурацию программного продукта, десятые и сотые части – обозначают промежуточные версии программного продукта, отличающиеся от базовой конфигурации исправленным кодом (вследствие устранения ошибок), добавлением небольших модификаций для конкретного предприятия-клиента или для группы предприятий.

Управление конфигурацией – действия, направленные на формирование базовой конфигурации и контроль над изменениями конфигурации (версии).

Как и все процессы, процесс Управления конфигурацией состоит из следующих подпроцессов:

1. Планирование;

2. Идентификация конфигурации;

3. Управление изменениями;

4. Аудит конфигурации.

Нет смысла в такой небольшой статье описывать подробно действия, выполняемые в каждом из подпроцессов. Все они описаны подробно в указанном стандарте.

Главное, что следует понимать – это то, что базовыми конфигурациями (если хотите, версиями) продукта необходимо управлять. Большинство специалистов знают, какой хаос происходит обычно в программистских коллективах, причем с возможностью параллельного развития продукта этот хаос возрастает в степенной функции.

Управление требованиями

Целями процесса Управления требованиями является получение окончательного продукта, соответствующего актуальным требованиям заказчика на момент выпуска этого продукта. Если говорить проще, то процесс Управления требованиями предназначен для отслеживания постоянных изменений требований заказчика, учета новых требований в производимом продукте и выпуске соответствующего продукта.

Большинство специалистов любого производства скажут, что такое невозможно, ведь требования к продукту могут меняться на противоположные уже по ходу производства, что исключит выполнение таких критериев качества, как стоимость и сроки разработки продукта. Но в том и заключается окончательный результат процесса Управления требованиями – ведь если требования изменились на противоположные относительно начала работ, следовательно, заказчику уже не нужен продукт с начальными характеристиками и требованиями. Какой смысл производить то, что уже не нужно?

В процесс Управления требованиями входят следующие подпроцессы:

1. Планирование;

2. Определение начальных требований;

3. Выявление пропущенных требований (например, тех, которые заказчик предполагал в силу своего собственного контекста);

4. Проверка требований на: выполнимость (принципиальную возможность или в рамках заданных бюджетов), корректность, непротиворечивость (в общем случае в списке требований всегда присутствуют противоречивые требования, которые необходимо или исключить или выбрать оптимальное соотношение между ними), тестируемость (возможно ли в результате работы доказать, что требования выполнены, в случае если протестировать требования невозможно, их детализируют до уровня когда возможность тестирования появляется);

5. Отслеживание требований. В случае изменения требований, проводится специальная процедура изменения требований, в результате которой, как правило, часть работ по идентификации требований необходимо выполнить повторно;

6. Проверка выполнения требований в продукте (верификация, валидация).

Процесс Управления требованиями подробно описан в стандарте SW CMM, Уровень 2.

Тестирование

Процесс Тестирование проводится постоянно и частично включен в другие обеспечивающие процессы, обсуждаемые выше. Однако его выделение в отдельный процесс необходимо, т.к., как правило, программный продукт является сложной системой и проверка качества производимого продукта только в рамках отдельных процессов не приведет к желаемому результату – удовлетворению потребителя.

Процесс тестирование также состоит из подпроцессов:

1. Планирование;

2. Разработка отдельных тестов для каждого требования, подсистемы, модуля и т.п.;

3. Управление изменениями тестовых процедур и тестов по мере изменения требований;

4. Тестирование отдельных элементов (требований) системы;

5. Интегральное тестирование, нагрузочное тестирование (если предусмотрено техническим заданием).

На первый взгляд, это нетрудоемкий процесс, однако, необходимо понимать, что перед реализацией элементов системы сначала разрабатываются сами тесты с целью доказательства правильности реализации требований, затем тесты модифицируются с модификацией требований, затем проводятся тесты по подсистемам и только потом интегральное тестирование.

Помимо линейного тестирования (элементы-подсистемы-система) обязательно необходимо разрабатывать стандарты многоуровневого тестирования. Например, в программистской организации должны быть предусмотрены следующие уровни тестов:

1. Разработчика (программист проверяет собственный код);

2. Независимого разработчика (проверку исполнения алгоритмов проводит программист, не занимающийся данной реализацией);

3. QA (Quality Assurance) – проверку кода осуществляет специальная тестовая группа в соответствии со стандартными правилами;

4. Пользовательский (до выпуска продукции необходимо, чтобы тестирование провел специалист предметной области, например, бухгалтер).

По оценкам специалистов Motorola, ORACLe трудоемкость (затраты) тестирования должны составлять не менее 100% от трудоемкости (затрат) на собственно кодирование.

Существует нормальное распределение отношения затрат к количество выявленных ошибок. Из этого распределения следует, что после некоторой суммы затрат на тестирование, дальнейшие затраты на выявление каждой ошибки растут экспоненциально. Обычно эта зависимость возникает после затрат, превышающих в 5-10 раз затраты на производство кода. То есть, оптимальное соотношение тестирование/производство должно составлять от 1 до 5.

Выводы

Таким образом, если процессы управления требованиями и конфигурацией являются для некоторых специалистов чем-то новым, то, как тестировать, вроде бы все знают. На практике же получается совершенно обратное: после реализации стандартных процессов и процедур в рамках Управления требованиями и конфигурацией, затраты на эти процессы становятся минимальны (хотя их исполнение предотвращает появление серьезных ошибок на 80-90%), а на тестирование тратится совершенно недостаточно ресурсов, что приводит к тому, что оставшиеся 10-20% ошибок не выявляются процедурами тестирования и продукт выпускается «сырой». Это, в свою очередь, приводит к тому, что продукт не устраивает потребителя, исправление ошибок в «чужом» коде превосходит все разумные затраты и в конечном итоге предприятие откладывает большую часть этих ошибок до реализации новой базовой конфигурации продукта.

Очевидно, что это приводит уже к потере качества продукта, потере клиентской базы и, как следствие, к потере прибылей компании.