Отчасти тут виновато слабое владение техникой BPM: оркестровки недостаточно, надо владеть межпроцессным взаимодействием, см. паттерн “внутренний заказ” и заметку “Межпроцессное взаимодействие через данные”. Например, люди путают use-case со схемой процесса и пытаются запрограммировать “процесс продаж”. Если бизнес и можно “запрограммировать”, то только многопоточной программой, т.е. сетью взаимодействующих друг с другом процессов. За этим добро пожаловать на http://bpmntraining.ru

Но иногда нужно прибегать не к технике, а к управленческим решениям типа: “Сотрудники подразделения X не нуждаются в регламентации их действий? Очень хорошо; регламентация и поддержка ее системой - это помощь, а не обуза. Тогда пусть будет так: устанавливаем SLA (соглашение об уровне сервиса) для всех подпроцессов, за которые вы отвечаете в рамках сквозных процессов компании, и систему наказаний/поощрений, привязанные к этим SLA. Крутитесь как хотите.”

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

Это, а не детальная регламентация выписки счета, и есть настоящий BPM.

И тут пошли замечания и сопротивление.

1. Оказалось, что каждому придется в системе работать за себя, а все хотят руководить и контролировать других
2. Никто не хочет, чтобы их система подгоняла и контролировала своевременность выполнения работ, но при этом хочет, чтобы система других подгоняла
3. Линейные руководители не хотят обращать внимание на автоматические письма из системы о нарушении сроков работ исполнителями, являющимися их подчиненными сотрудниками
4. Исполнители вообще против, чтобы им кто-либо устанавливал сроки, которые надо соблюдать
5. Никто не хочет соблюдать схему процесса, даже содержащую все необходимые вариации. Каждый считает своим долгом придумать свое исключение из утвержденного регламента - какие то шаги хотят пропускать, какие то добавлять, повторять или менять местами
6. Никто не задумывается, что с документами процесса надо работать аккуратнее, что нельзя все время добавлять новые версии одного документа вместо исправления в документе, присоединенном к процессу
7. Никто не хочет обучаться системе, а хотят ей сразу пользоваться. А потом удивляются, что не понимают, что от них хочет система
8. Никто не хочет читать сообщение на экране с подробным описанием что нужно делать на данном шаге процесса, а лепят не думая первое попавшееся в списке действие и продолжают процесс. Потом удивляются - куда все пропало и не понимают, где сейчас задача?
9. Никто не хочет пользоваться еще одной “дополнительной” корпоративной системой, хотя им вовсе не требуется вводить логин и пароль
10. Наровят по старинке дублировать процесс по электронной почте…

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

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

Вот я сижу и думаю, чем это вызвано и как с этим бороться? Руководство заняло выжидательную позицию…
Неужели опять ждать “смену поколений”?

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

А “chief process officer” - это интересно. Спасибо.

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

Внешние консультанты не виноваты. Классики MRP-II многократно повторяют: чего-то добиться можно только если это будет проект “Do It Yourself”. Но с какого-то момента заказчики предпочли не обращать на эти предостережения внимания, а верить в обещания консультантов “сделать все под ключ”. Того, кто сам рад обмануться, обмануть ведь не трудно.

Такой специалист вроде называется ИТ-директор. В больших корпорациях на западе сейчас появилась еще модная должность “chief process officer”. Или Вы под инфраструктурой понимаете нечто большее, чем ИТ?

Если серьезно, то пафос этого пункта в значительной степени направлен против временщиков, к которым ты явно не относишься.