Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Девять процессных фреймворков предприятия

Процессный фреймворк -- это набор взаимосвязанных описаний процессов, обеспечивающих тот или иной аспект деятельности организации. Например, ISO 15288 -- это именно процессный фреймворк, описывающий обязательные процессы жизненного цикла по версии системной инженерии, так этот стандарт себя самоназывает. Понятие процессного фреймворка (иногда говорят "процессной архитектуры") стало уже общепринятым.

Все было бы хорошо, если бы этих всеобъемлющих процессных фреймворков не было множество, каждый из которых следует собственной идеологии, методам описания процессов, да и понятия "процесс" в них понимается по-разному (процессы-практики, процессы-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).
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 4 comments