Что-то мы друг друга не понимаем. Может о разных вещах говорим?

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

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

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

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

>>>> дела обстоят хуже, поскольку их владельцы хуже разбираются, как управлять деятельностью именно как сервисом
> Мне кажется, все не так страшно. Создавать фреймворк не требуется…
Речь не о том, чтобы абсолютно все сначала создавали некий абстрактный фреймворк, а потом еще и выстраивали свою деятельность в соответствии с ним. Я имел в виду, что ИТ такой фреймворк уже есть, многие ИТ-руководители с ним знакомы и руководствуют им при выстраивании ИТ-сервиса. А в других областях таких фреймворков может не быть, и там от руководителей требуется определенный талант, чтобы в отсутствие фреймворка (т.е. подсказки) создать хорошо функционирующий сервис. К сожалению, не часто это получается.

>>>> сервисный процесс - это всегда отдельный пул в терминах BPMN
>> Почему? Я его вижу как подпроцесс. Вызывается синхронно. Никаких проблем.
Вызывается синхронно, но исполняется не вполне синхронно. Т.е. вызывающий процесс дает заявку на сервис, эту заявку кто-то принимает синхронно по отношению к вызывающему процессу (если этот процесс не полностью автоматизирован), а дальше заявка на сервис ложится в базу заявок, сервис исполняет ее по своей логике (аналогия с паттерном производственного заказа), в процессе может произойти еще какое-то общение между сервисом и вызывающим процессом в случае каких-то нестандартных ситуаций, в конце сервис сообщает, что он завершил обработку заявки, и вызывающий процесс тогда продолжается. Т.е. все-таки ситуация отличается от той, когда мы просто вызываем подпроцесс, который полностью исполняется внутри определенного подразделения, и выстраивание которого отдается полностью на откуп его руководителю.
Я изобразил, что я имею в виду: https://docs.google.com/open?id=0B8N0PG6hk_54ajF3U09BaVkta28

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

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

>> сервисный процесс - это всегда отдельный пул в терминах BPMN
Почему? Я его вижу как подпроцесс. Вызывается синхронно. Никаких проблем.

В таком подходе есть следующие особенности, из-за которых это не всегда работает - в особенности, в России:
1) Серис для процессов, которые его вызывают, представляется черным ящиком с определенными интерфейсами и установленным SLA. Т.е. вмешиваться в его устройство при построении вызывающих его процессов нельзя - иначе это будет уже не внутрисервисный подход.
2) Из п. 1 следует, что кто-то должен отдельно организовать бизнес-процессы самого сервиса. Обычно это отдают на откуп самому его владельцу. В случае с ИТ это работает (хотя тоже не всегда ), поскольку есть такой фреймворк по организации ИТ-сервиса, как ITIL, и ИТ-руководители в большей степени, чем другие, являются приверженцами процессного или сервисного подхода. С сервисами типа логистического или еще какого-то дела обстоят хуже, поскольку их владельцы хуже разбираются, как управлять деятельностью именно как сервисом.
3) Поскольку сервисный процесс - это всегда отдельный пул в терминах BPMN, возникает следствие из теории ограниченных систем, о котором вы сами много рассказывали: сглаживаются пики входной загрузки сервиса, но снижается удовлетворенность потребителя (в данном случае, внутреннего).

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

Предложенное Вами терминологическое деление мне нравится. Что касается внесения в стандарт - вряд ли, BPMN сознательно сделан методологически нейтральным. Внесите во внутренний стандарт моделирования.

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

2) Схема получается более хрупкой - есть риск получить непредсказуемый кейс вместо подпроцесса. Вообще есть потенциально интересный подход к моделированию, когда все, что делается внутри подразделения, отдается на откуп его руководителю - как хочет, так и организует, при условии что выдерживает SLA. И процессный подход соблюден, и нет жесткости, в которой иногда упрекают BPM. Вот только на практике применить его пока не получалось.