Все о системах управления бизнес-процессами
 
Почитать
Поговорить
Побродить
Завершить


Вход в систему

Забыли пароль?


     
BPM: причины неудач

Почему такая, казалось бы, прогрессивная идея как 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

Комментарии
#1 Анатолий Белайчук, 21.04.2009 15:08

Мутный какой-то текст. По пунктам:

1) Банальность, подходит для любой статьи в жанре "XXX: причина неудач".
2) Если уж на то пошло, BPM это вообще не приложение.
3) Опять, таки относится к любому проекту. Где специфика именно BPM?
4) Кросс-функциональных проблем не надо избегать, их надо решать! Иначе о значимом бизнес-результате можно забыть.
5) Первая здравая, хотя и не слишком оригинальная мысль.
6) На минуточку забыли про увеличение продаж.
7) Первый проект должен быть убедительным на субъективном уровне. Измерениями можно заниматься на втором, а на первом это приведет к потере концентрации и темпа.
8) Перепев п.1. Доводим число причин до круглого счета?
9) Если бы! По нашим меркам, пара – это уже много. Позовем лучше консультантов, пусть они нам попляшут-попоют. Да и не получишь откат на обучении. «Зачем нам кузнец? Не, нам кузнец не нужен!»
10) Вторая дельная мысль.

Итого: КПД=20%. (Какой-то я сегодня недобрый...)

#2 Юлия Вагнер, 22.04.2009 13:22

А если бы был добрый, то можно было б до 30 доторговаться? ))))
- Ты кто?
- Добрая фея
- А чего с косой
- Да настроение что-то не очень smile

Глен не причины, а ошибки попытался описать, но это не принципиально. Намешал он в кучу какой-то мусор и дельные вещи - получилось действительно довольно мутно.
Пытался донести мысль о том, что BPM - совместное решение бизнеса и ИТ, но неубедительно. Указал на проблему выбора первого процесса, но тут же начал себе противоречить: процесс должен показать реальную выгоду, но при этом пусть он будет такой ма-а-аленький, сбоку, никого не трогает и основной бизнес не затрагивает, да еще и попроще бы... И как тогда бизнес эту выгоду почувствует? Если какому-то сотруднику ххх, стол № ууу, департамент ZZZ вдруг стало проще выполнять свою работу, то руководитель проникнется отеческой нежностью и расплывется? Ага, ждите! Пока он лично не почувствует выгоду - деньги ли, контракты, "кликну мышкой и мне все видно" (об этом говорит КАЖДЫЙ руководитель!)- ни о каком успехе даже не мечтайте.
Еще. Человеку всегда больше нравится то, к чему он лично приложил руки. В случае с BPM - в схему процесса. Даже если ее нарисует кто-то другой, а шеф просто поправит пару стрелочек - и вот оно, чувство сопричастности! А об этом у Глена ни слова. Может он где-то в глубине души об этом думает, но скрывает?
На мой взгляд, ценность тут больше в том, что проблема наружу вытянута.

Для того чтобы добавить комментарий, вам нужно войти в систему или зарегистрироваться

Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права | Версия для печати