Process framework что это

Обновлено: 06.07.2024

Американский центр качества и производительности (APQC) давно известен своим фреймворком PCF (Process Classification Framework, писали о фрейморках здесь ).

Летом 2020 года APQC представил собственную методологию процессного управления.

В основе методологии APQC находится жизненный цикл управления бизнес-процессами из пяти шагов:

  1. Идентификация, структурирование и приоритезация бизнес-процессов
  2. Моделирование и документирование бизнес-процессов
  3. Мониторинг и контроль бизнес-процессов
  4. Анализ, улучшение и интеграция бизнес-процессов
  5. Управление и поддержка бизнес-процессов

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

Данный жизненный цикл базируется на 7 практиках, или основополагающих принципах, которые аналитики APQC выделили из опыта реализации множества проектов:

  1. Взаимосвязь со стратегическими целями

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

  1. Формализованы роли и правила процессного управления

При внедрении процессного управления в повседневную практику компании решающую роль в успехе играет определение правил и распределение ответственности и полномочий между:

  • топ-менеджментом,
  • владельцами процессов,
  • процессными аналитиками,
  • руководителями,
  • рядовыми сотрудниками.
  1. Прозрачная модель процессов организации

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

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

  1. Регулярная оценка эффективности бизнес-процессов

Регулярная оценка показателей эффективности бизнес-процессов (PPI) позволяет идентифицировать отклонения и своевременно предпринять корректирующие действия. Анализ PPI помогает оценить эффективность инициатив по улучшению бизнес-процессов.

  1. Целенаправленная оптимизация бизнес-процессов

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

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

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

Читайте также: