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

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

В отечественной литературе принят термин “владелец процесса”.

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

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

Отчасти тут виновато слабое владение техникой 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” - это интересно. Спасибо.