Коллектив авторов - Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0

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

Поскольку процессное управление полностью независимо от управления по оргструктуре, оно требует другого подхода к операциям и других менеджеров [169] В отличие от других глав CBOK, в данной главе не разделяются роли менеджера и владельца процесса . – Прим. ред. . Эти менеджеры должны отвечать за итоговые качество и производительность одного или нескольких процессов (в зависимости от размера и сложности). Поскольку менеджеры процессов отделены от обычной организационной структуры, они должны отчитываться перед собственным руководством. Это позволит им оставаться независимыми от рутинных операционных проблем, возникающих на уровне оргструктуры.

Работу менеджера процесса следует оценивать исходя из достижения установленных специально для него целей. Главной его заботой является процесс и его улучшение, что подразумевает осознание руководителями подразделений того, что они должны взаимодействовать друг с другом с целью оптимизации таких показателей процесса, как суммарные затраты времени и денег, итоговое качество и удовлетворенность потребителей. Разумеется, для этого компания должна описать процессы и начать измерять показатели, за которые менеджеры процессов будут отвечать. Технологии BPMS дают возможность начать получать такую информацию и тем самым начать управлять процессом.

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

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

В терминах, предложенных выше, процесс пересекается с оргструктурой на уровне действий (потоков работ) – там, где работа разбита на части, выполнение каждой из которых поручено определенному бизнес-подразделению. Это точка, где сходятся процессное и организационное управление и соответствующие менеджеры.

Эти связи формируют своего рода карту выполнения процесса, переводя ее с концептуального уровня на физический: работа перестает быть чистой идеей, теперь ее можно «пощупать». В этот момент менеджер процесса должен сформировать группу из руководителей подразделений, участвующих в процессе, – комитет, который будет отвечать за совершенствование процесса в целом и в каждом отдельном подразделении. Члены комитета должны рассматривать предлагаемые изменения, чтобы убедиться в отсутствии негативного воздействия на их подразделение или на процесс. Создание такого комитета по управлению процессом должно быть официально закрепленной обязанностью менеджера процесса.

В связи с тем, что процессный подход очень сильно отличается от привычного для большинства руководителей, менеджер процесса обязан объяснить, из чего этот подход состоит, как составные части сочетаются друг с другом и как они управляются. И честно говоря, этого невозможно добиться с помощью примитивных средств моделирования; лучшим средством организации такой информации и управления ею является BPMS. В этом случае компания получает информацию и о сквозных бизнес-процессах целиком, и об их детализации на уровне подразделений. Берутся под контроль все компоненты, составные части и т. д., а также участки, на которых они создаются, используются, дорабатываются, собираются в более крупные узлы. Вдобавок появляется возможность выявлять проблемные места, осуществлять мониторинг и получать отчеты по процессам и потокам работ. Основные правила, влияющие на качество и сроки процесса, становятся явно определены, и их можно настраивать с целью оптимизации операций.

Но главное, что комитету по управлению процессом дает BPMS, – это единая база для приоритизации проектов изменений, их оценки, анализа последствий с помощью имитационного моделирования и для мониторинга прохождения процесса от подразделения к подразделению.

Разумеется, комитет по управлению процессом может обойтись и без BPMS, но в этом случае объем работы существенно вырастет и отчетность перед руководством будет запаздывать.

Процессная модель предприятия является основой BPM. Большинство организаций много выиграет, если возьмет за основу классификации процессов универсальную или отраслевую референтную модель. Референтные модели процессов бывают:

• общими, пригодными для разнообразных компаний и организаций (процессный фреймворк APQC PCF, референтная модель операционной цепочки создания ценности VRM);

• специфичными для отрасли (референтная модель цепочек поставки SCOR);

• специфичными для области процессов (библиотека по IТ-инфраструктуре ITIL) [170] Information Technology Infrastructure Library . – Прим. пер. ;

• специфичными для технологии (SAP).

Модели APQC PCF и VRM могут подойти множеству организаций. Модель SCOR в большей степени ориентирована на организации, имеющие дело с цепочками поставок. Существует также множество отраслевых моделей. Так, у APQC есть специализированные версии для различных отраслей промышленности, например для фармацевтики. Классификация процессов может являться составной частью отраслевой архитектуры более высокого уровня, как, например, eTOM для телекоммуникационных компаний. Встречаются также модели для определенных областей: например, ITIL описывает общие процессы IТ-поддержки организации. Наконец, существуют описания процессов, предназначенные для поддержки определенных технологий – обычно для крупномасштабных ERP. Так, SAP в ходе эскизного проектирования процессов пользуется определенной готовой структурой.