Суть BPM заключается в итерационной и эволюционной оптимизации. Подход BPM не в том, чтобы потратить много времени на анализ и перепроектирование, стремясь сразу охватить все 100 %. Он предполагает, что вы быстро выполняете первое приближение к истине, затем обнаруживаете в процессе ошибки и разрывы и начинаете новую итерацию. При таком подходе процесс постоянно эволюционирует, изменения проходят быстро и серьезные проблемы исправляются в первую очередь. В результате график отдачи во времени сдвигается влево – самый большой эффект достигается уже на ранних этапах проекта.
Применяя этот подход к процессам, компания быстро выполняет первую итерацию, охватывающую процессы верхнего уровня и их взаимодействие, а последующими итерациями уточняет модель. В результате проекты, в рамках которых различные подразделения детально прорабатывают свои фрагменты, развиваются в общей системе координат.
Этот подход также требует от команды добраться до действий выше по потоку, обеспечивающих входящие ресурсы для того участка, который подвергается переделке, и до действий ниже по потоку, чтобы проанализировать потребление ими результатов своего участка. Вы должны дойти и до самого начала, и до самого конца.
Таким способом мы проверяем, как производимые изменения повлияют на то, что находится вне нашего подразделения.
Проверка выявит возможные нарушения в работе вниз по потоку и дополнительные требования к подразделениям выше по потоку работ. Эта дополнительная информация расширит кругозор команды и позволит избежать решений, которые навредят другим подразделениям или приведут к серьезным перебоям в работе.
Вдобавок, выведя проект на уровень процессов, компания сможет совершенно по-новому взглянуть на качество и стоимость. Каждое подразделение оказывает воздействие на качество и должно управлять им в своих границах, но итоговое качество обеспечивается взглядом от процесса, который позволяет рассматривать проблемы качества в комплексе и устранять их.
Взаимодействовать с другими группами внутри компании, которые потенциально могут быть затронуты изменениями, команда проекта тоже должна исходя из процессного подхода. Это позволит избежать связанных с изменениями проблем и поднять на более высокий уровень измерение эффективности и контроль качества, тем самым экономя время, деньги и страхуясь от перебоев в работе и неожиданных проблем с качеством. Для многих это станет первой попыткой найти первопричину проблем, лежащую за границами подразделения.
9.1.2. Начало работы: важность лидерства; план лидерства BPM
Процессное управление нельзя рассматривать в терминах традиционной организационной структуры. Оно не сводится к оргструктуре, так как процесс пересекает оргструктуру поперек. Он петляет через множество подразделений, каждое из которых добавляет какой-то компонент в конечную продукцию или услугу. Процесс не ограничивается каким-то одним местонахождением или одной компанией – комплектующие, узлы или услуги, необходимые для выпуска продукции, могут закупаться на стороне, их изготовление может передаваться на аутсорсинг.
Поскольку процессное управление полностью независимо от управления по оргструктуре, оно требует другого подхода к операциям и других менеджеров[169]. Эти менеджеры должны отвечать за итоговые качество и производительность одного или нескольких процессов (в зависимости от размера и сложности). Поскольку менеджеры процессов отделены от обычной организационной структуры, они должны отчитываться перед собственным руководством. Это позволит им оставаться независимыми от рутинных операционных проблем, возникающих на уровне оргструктуры.
Работу менеджера процесса следует оценивать исходя из достижения установленных специально для него целей. Главной его заботой является процесс и его улучшение, что подразумевает осознание руководителями подразделений того, что они должны взаимодействовать друг с другом с целью оптимизации таких показателей процесса, как суммарные затраты времени и денег, итоговое качество и удовлетворенность потребителей. Разумеется, для этого компания должна описать процессы и начать измерять показатели, за которые менеджеры процессов будут отвечать. Технологии BPMS дают возможность начать получать такую информацию и тем самым начать управлять процессом.
Кроме того, менеджер процесса сможет достичь поставленных перед ним целей только при условии, что у него есть полномочия для работы с руководителями подразделений всех уровней и возможность обращения к высшему руководству в случае возникновения проблем с сотрудничеством.
9.1.3. Где пересекаются процессы и оргструктура
Как подчеркивается повсеместно в CBOK, процесс можно разложить на составные части, относящиеся к различным уровням, – назовем их бизнес-функциями, подпроцессами, действиями потоков работ, задачами, шагами. Число уровней и названия могут варьироваться в зависимости от компании, здесь нет никаких стандартов. Не важно, сколько уровней декомпозиции у вашего процесса и как они называются, – важно, чтобы они были формализованы.
В терминах, предложенных выше, процесс пересекается с оргструктурой на уровне действий (потоков работ) – там, где работа разбита на части, выполнение каждой из которых поручено определенному бизнес-подразделению. Это точка, где сходятся процессное и организационное управление и соответствующие менеджеры.
Эти связи формируют своего рода карту выполнения процесса, переводя ее с концептуального уровня на физический: работа перестает быть чистой идеей, теперь ее можно «пощупать». В этот момент менеджер процесса должен сформировать группу из руководителей подразделений, участвующих в процессе, – комитет, который будет отвечать за совершенствование процесса в целом и в каждом отдельном подразделении. Члены комитета должны рассматривать предлагаемые изменения, чтобы убедиться в отсутствии негативного воздействия на их подразделение или на процесс. Создание такого комитета по управлению процессом должно быть официально закрепленной обязанностью менеджера процесса.
В связи с тем, что процессный подход очень сильно отличается от привычного для большинства руководителей, менеджер процесса обязан объяснить, из чего этот подход состоит, как составные части сочетаются друг с другом и как они управляются. И честно говоря, этого невозможно добиться с помощью примитивных средств моделирования; лучшим средством организации такой информации и управления ею является BPMS. В этом случае компания получает информацию и о сквозных бизнес-процессах целиком, и об их детализации на уровне подразделений. Берутся под контроль все компоненты, составные части и т. д., а также участки, на которых они создаются, используются, дорабатываются, собираются в более крупные узлы. Вдобавок появляется возможность выявлять проблемные места, осуществлять мониторинг и получать отчеты по процессам и потокам работ. Основные правила, влияющие на качество и сроки процесса, становятся явно определены, и их можно настраивать с целью оптимизации операций.
Но главное, что комитету по управлению процессом дает BPMS, – это единая база для приоритизации проектов изменений, их оценки, анализа последствий с помощью имитационного моделирования и для мониторинга прохождения процесса от подразделения к подразделению.
Разумеется, комитет по управлению процессом может обойтись и без BPMS, но в этом случае объем работы существенно вырастет и отчетность перед руководством будет запаздывать.
9.1.4. Обратить внимание на процессные фреймворки и отраслевые референтные модели
Процессная модель предприятия является основой BPM. Большинство организаций много выиграет, если возьмет за основу классификации процессов универсальную или отраслевую референтную модель. Референтные модели процессов бывают:
• общими, пригодными для разнообразных компаний и организаций (процессный фреймворк APQC PCF, референтная модель операционной цепочки создания ценности VRM);
• специфичными для отрасли (референтная модель цепочек поставки SCOR);
• специфичными для области процессов (библиотека по IТ-инфраструктуре ITIL)[170];
• специфичными для технологии (SAP).
Модели APQC PCF и VRM могут подойти множеству организаций. Модель SCOR в большей степени ориентирована на организации, имеющие дело с цепочками поставок. Существует также множество отраслевых моделей. Так, у APQC есть специализированные версии для различных отраслей промышленности, например для фармацевтики. Классификация процессов может являться составной частью отраслевой архитектуры более высокого уровня, как, например, eTOM для телекоммуникационных компаний. Встречаются также модели для определенных областей: например, ITIL описывает общие процессы IТ-поддержки организации. Наконец, существуют описания процессов, предназначенные для поддержки определенных технологий – обычно для крупномасштабных ERP. Так, SAP в ходе эскизного проектирования процессов пользуется определенной готовой структурой.
