Все было бы хорошо, если бы этих всеобъемлющих процессных фреймворков не было множество, каждый из которых следует собственной идеологии, методам описания процессов, да и понятия "процесс" в них понимается по-разному (процессы-практики, процессы-workflow). Вот девять процессных фреймворков, которые можно обнаружить на предприятии (где меньше, где больше -- меня не волнует тут точное число, я обсуждаю сам принцип):
1. Система управления качеством (часто этот процессный фреймворк офорлен по версии ISO 9000). Рулит им ответственный за качество, его наличие используется для вписывания в тендерную документацию, к делу (то есть собственно управлению качеством продукции и услуг) имеет отношение редко.
2. Отраслевая программа управления качеством (например, система ПОКАС у мирных атомщиков). Рулит тоже ответственный за качество, но этот фреймворк используется для отчета госрегуляторам, не более. Ежели особо приставучих регуляторов нет, то сводится к отраслевой системе техрегулирования. Если есть -- получите обязательную отдельную систему, существенно отличающуюся "по понятиям" от ISO 9000.
3. Отраслевая система техрегулирования (безопасность + экология + охрана труда), безусловно требующая описания всех процессов.
4. Система управления проектами (чаще всего по мотивам PMI PMBoK). Рулит ответственный за внедрение проектного управления. Имеет непосредственное отношение к производству. Часто это -- организация в организации, включая собственные финансы и даже собственные инженерные силы. Отдельной сертификации не имеет, но это уже не за горами.
5. Реинжининирг бизнес-процессов -- всевозможные программы улучшения жизни на предприятии, которые делаются на основе "процессного подхода". Разрабатываются обычно отдельной службой, до внедрения дело доходит время от времени. Любимое слово "change management" -- но это слово пустой звук, когда им занимаются аналитики и консультанты (внешние и внутренние) всех мастей. Возглавляет этот реинжиниринг какая-нибудь служба по развитию, руководствующаяся классификацией процессов типа приведенной в http://globalbestpractices.pwc.com/Home/ProcessFrameworks.aspx?FW=Process+classification+framework. Провозглашаемые цели -- снижение затрат или освоение новых сфер деятельности, редко -- "налаживание регулярного менеджмента" (ибо этот менеджмент налаживают менеджеры, а не аналитики).
6. Айтишные workflow -- это не "процессы" в традиционном их представлении, а пошаговые процедуры, в которых обязательно участвуют компьютеры. Тем не менее, эти workflow выдаются за полноценные процессы. Выполняются в жизни (ибо поддержаны софтом), или не выполняются любой ценой (ибо поддержаны софтом). Существенно отличаются от процессов из "реинжиниринга бизнес-процессов".
7. Системная инженерия -- все чаще и чаще в контракты вписывается выполнение стандарта ISO 15288, в котором собственный процессный фреймворк. Нужно ли говорить, что он просто добавляется к уже существующим? Аналог такого фреймворка для софтостроителей может быть ISO 12207, а также модели зрелости CMMI. Как ни странно, сюда же (а не к проектному управлению! ибо затрагиваются и способы работы, а не только способы планирования и контроля исполнения) я отношу процессные фреймворки SCRUM, eXtreme programming и прочие Agile -- хоть они свои "процессы" норовят обозвать "практиками", сути дела это не слишком меняет.
8. Технологические процессы -- главный инженер озабочен тем, чтобы на выходе производства был конкретный продукт, бухгалтер -- конкретные отчетные документы, и т.д. В их процессных фреймворках мало внимания уделяется организационной стороне вопроса (процессным ролям прежде всего), но эти фреймворки есть, они воплощены в технологических картах и рабочих инструкциях.
9. Представления менеджеров о должном в организации работы. Не документированы, хотя проводятся в жизнь не хуже, чем любой другой процессный фреймворк. Способов проведения в жизнь два: непосредственный процессный инструктаж на рабочих местах ("делай вот так, и впредь только так"), а также закрепление в распорядительной документации.
Все эти девять процессных фреймворков отражают интересы разных стейкхолдеров, имеют разное отношение к реальной жизни организации, весьма похожи по содержанию, и в то же время имеют существенные расхождения, о которых мало кто подозревает. У восьми нянек процессных фреймворков процессная жизнь предприятия без глазу.
Рекомендации PraxOS по выправлению процессного коленвала:
1. Признать наличие всех этих фреймворков и их важность, найти ответственных за них на предприятии (стейкхолдеров), посадить их за общий стол. Задать вопросы -- "по чьим процессам будем жить"? Принять административные решения по итогам обсуждения (нам ведь не нужно столько начальников, желающих порулить мимо менеджеров -- но по "процессным" линиям?).
2. Определить, какой из этих фреймворков является метафреймворком для остальных (предложение PraxOS -- это фреймворк системной инженерии. Как минимум, в нем в явном виде помянуты процессы всех остальных фреймворков, как способ признания важности специальных точек зрения, а также уделено повышенное внимание междисциплинарному подходу, дающему шанс договориться. А еще в нем есть специальное место для процессной работы -- процесс "управление моделью жизненного цикла").
3. Договориться о процессе "управление моделью жизненного цикла", ибо процессы для разных систем жизненного цикла разные -- и нужно понять сначала, о каких системах, которыми занимается предприятие, вообще идет речь. Повесить на стенку картинки основных моделей жизненного цикла (названия систем, стадии их эволюции и разделяющие их развилки принятия решений). Добиться, чтобы у всех стейкхолдерах в их презентациях и документах были одни и те же картинки жизненных циклов основных поставляемых систем.
4. Договориться о форме представления процессной модели -- "корпоративная архитектура" (не только потому, что все эти процессы в конечном счете будут поддержаны со стороны IT. Просто объект очень сложный, и IT нужно, чтобы организовать аналог ручки и бумажки для записи такого сложного объекта, как процессная модель предприятия во взаимосвязи с оргструктурой, ресурсами, персоналом и т.д.).
5. Если очень-очень нужно для сертифицирующих организаций, то порождать для них наборы выписок из "корпоративной архитектуры" в любимом сертифицирующими организациями формате (для чего иметь формальный -- т.е. документированный -- мэппинг из представленных в корпоративной архитектуре объектов в объекты соответствующей сертификационной процессной дисциплины. Думайте об этом мэппинге аналогично мэппингам ISO 15926/Gellish).