Почему такая, казалось бы, прогрессивная идея как BPM, буксует?. Рынок BPM-продуктов и услуг совершенствуется, технология просто «прорывная»… а где очереди за BPM-системами? Где вал успешных внедрений?

Анализируя причины, по которым проекты BPM терпят неудачу даже там, где есть и деньги и желание, Глен Смит в своей статье «How (not) to Fail at BPM» приводит 10 ошибок, которых следует избегать при реализации BPM-проектов:

1. Без поддержки бизнеса (бизнес-спонсора) BPM превращается в очередную «игрушку» для ИТ. Если, к тому же, бизнес-собственник не участвовал в выборе BPM-системы, то она вообще может не отвечать его потребностям. И он вообще имеет к ней малый интерес. Система в таком случае может использоваться для внутренних проектов, но едва ли получит широкое применение.
2. Если бизнес принимает решение о покупке системы без привлечения ИТ (случай, обратный предыдущему), , то могут возникнуть сложности с интеграцией системы с внешними приложениями. Следует помнить, что BPM – не отдельно стоящее решение, а слой поверх существующих приложений и инфраструктуры.
3. Неудачно выбранный проект, не приносящий ощутимую выгоду бизнесу. Следует помнить, что BPM должен дать выгоду акционерам. В противном случае, даже если удастся реализовать все как задумано, не будет ожидаемого возврата инвестиций. Это наиболее распространенная ошибка.
4. Попытка объять необъятное на первом же проекте. BPM- нововведение для организации. Следует выбирать для первого шага достаточно простой и понятный процесс. Это может расходиться с предыдущим утверждением, однако это позволяет снизить риски. Это может быть процесс одного департамента, что поможет избежать кросс-функциональных проблем. Либо можно параллельно запустить несколько небольших процессов, объединив их позже.
5. Большое количество внешних зависимостей, что требует достаточно сложных технических решений. По возможности оставьте проблемы интеграции для последующих итераций. Если вам удастся доказать состоятельность BPM, то легче будет получить финансирование для решения этих проблем. Если в организации есть зрелая SOA, то используйте это для создания всех внешних интерфейсов .
6. Плохо определенные критерии успеха. До начала проекта необходимо оценить существующую эффективность и ожидаемую выгоду. По завершении проекта руководство захочет оценить результат и определиться, стоит ли продолжать работу. Снижение стоимости – это наиболее распространенный показатель, хотя существуют и такие как бизнес-возможности, гибкость и готовность к изменениям.
7. Отсутствие наглядных измерений и отчетов. Часто разработчики уделяют недостаточно внимания инструментам анализа. Следует уделить достаточно внимания ключевым измерениям до того, как начнете проект BPM. Это позволит оценить выгоду и ROI от BPM.
8. Отсутствие спонсора из числа руководителей. Проект потребует задействовать ресурсы помимо основной проектной команды, таких как ИТ-ресурсы, бизнес-экспертов. Наличие спонсора из числа руководства обеспечит своевременное получение этих ресурсов.
9. Экономия на обучении. BPM потребует новых знаний и в части разработки, и в части бизнес-анализа. Многие компании экономят на обучении сотрудников, считая, что достаточно обучить пару человек, которые затем обучат остальных. Но имейте в виду, что эти обученные сотрудники имеют слишком мало опыта (в лучшем случае, один проект), что недостаточно для обучения других.
10. Отсутствие собственной команды разработчиков. На первом этапе, для быстрого развертывания BPM, полезно будет воспользоваться сторонними услугами. Но в дальнейшем, для быстрого реагирования на изменения, необходима собственная команда.

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

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

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

Интересная дискуссия на эту тему развернулась на блоге Анатолия Белайчука в ответ на его заметку «10 причин, по которым рынок BPM не оправдывает ожиданий».

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

=WJ

Комментарии