В шапке
Особенности проектов автоматизации бизнес-процессов

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

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

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

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

Я разделяю точку зрения, согласно которой процесс - это последовательность функций по преобразованию процессного объекта (подробнее см. тут:  http://analyst.by/news/processes-for-business-analists-1),  а бизнес-процесс – это специальным образом выделенные фрагменты процессов организации (см. тут: http://analyst.by/articles/protsessyi-dlya-analitikov-chast-2-protsessyi-i-biznes-protsessyi)

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

  • Большое количество заинтересованных лиц
  • Сложность выявления всех требований (полнота требований)
  • Противоречивые требования заинтересованных сторон
  • Определение ответственных со стороны бизнеса за внедрение
  • Сложность  коммуникаций
  • Постоянные изменения процессов
  • Необходимость постоянного обучения пользователей
  • Сложность внесения некоторых изменений в информационную систему

Рассмотрим эти особенности подробнее.

Большое количество заинтересованных лиц

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

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

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

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

Сложность выявления всех требований (полнота требований)

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

Одна  из них заключается в том, что часто в таких проектах подменяют потребности и технические характеристики продукта (об этом в статье Изменения требований в проектах http://project-management.zis.by/upravlenie-izmenenijami/upravlenie-izmenenijami-trebovanij-k-produktam-proekta.html). Одна из крайностей заключается в том, что пользователи, как правило, рассказывают команде проекта не то, какие проблемы должен решать продукт, а то, как продукт должен работать. При этом команда проекта не выясняет, в чем состоит истинная потребность пользователя. Либо другая крайность – команда проекта проектирует продукт, исходя из своего понимания потребностей пользователя, пропуская этап их анализа.

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

Третья причина в том, что потребности очень трудно обнаружить и вытянуть из головы потребителя.

Противоречивые требования заинтересованных сторон

Разные заинтересованные стороны проекта (например, заказчик проекта, пользователи продукта) имеют, как правило, разные интересы в проекте и разные потребности. Для решения формулирования противоречий можно использовать «грозовые тучи» Голдратта, а для поиска решений противоречий можно использовать ТРИЗ (теорию решения изобретательских задач).

Определение ответственных со стороны бизнеса за внедрение

В проекте нужно ответить вопрос о том, что мы автоматизируем – деятельность подразделений или  процессы?

Если руководство компании принимает решение о том, что автоматизироваться будут подразделения, то ответственность за внедрение будут нести руководители подразделений.

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

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

За что они отвечают?

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

Сложность  коммуникаций

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

С кем руководителю проекта приходится коммуницировать часто:

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

(По коммуникациям в проекте можно почитать статью: http://project-management.zis.by/kommunikacii-v-proekte/trudnosti-perevoda.-o-kommunikacijah-v-proekte.html )

Постоянные изменения процессов

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

Необходимость постоянного обучения пользователей

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

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

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

Сложность внесения некоторых изменений в программные продукты

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

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

Удачи вам в автоматизации процессов! 

Комментарии (2)
Макс Якубович2014-10-13 09:36:53
Игорь, приветствую. В принципе согласен, оценить эк эффективность на старте проекта достаточно непросто. ЕЁ приходится переоценивать по мере продвижения проекта и уточнения прогнозов по стоимости затрат и выгод. В методологии Prince2 даже выделена отдельная тема - Экономич-е обоснование проекта.
Igor Sintsov2014-10-13 08:07:40
еще можно добавить сложность оценки экономической эфффективности от автоматизации
Войти как