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

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

5.2.1. Модель процесса не является моделью бизнес-архитектуры

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

Таким образом, модели способностей являются концептуальными и отвечают на вопрос, «что» такое наш бизнес. На нижних уровнях детализации модели способностей определяют все действия, которые должны быть предусмотрены, чтобы бизнес приносил результат. Процессные модели, с другой стороны, отвечают на вопрос, «как» устроен наш бизнес – они описывают то, как результат, продукция или услуга создаются и доставляются клиенту. Процессные модели концентрируются на физических действиях и на управлении ими и, таким образом, на производительности.

Сочетание моделей этих двух видов дает перекрестный взгляд. Любая работа должна быть обеспечена определенной бизнес-способностью – это вопрос результативности[95]. Затем можно проследить последовательность выполнения работ и усовершенствовать управление. Исключая ненужную работу и автоматизируя все, что возможно, проектировщик добивается максимальной производительности[96].

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

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

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

5.2.2. Отправная точка

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

На втором уровне проекта BPM решаются специфические проблемы и достигаются конкретные результаты. Обычно это менее масштабные проекты, нацеленные не на процессы, а на потоки работ. В этом принципиальное различие между используемыми в данной главе терминами «процесс» и «поток работ».

Проектирование процесса начинается с изучения того, как бизнес работает сегодня – что он делает, где, как и зачем. Это исследование документированных и недокументированных действий, составляющих процесс. Но важно понимать не только как бизнес работает, но и как он должен работать, по мнению высшего руководства. Что делается не так и почему? Где возникают проблемы при передаче ответственности между подразделениями, при принятии решений? Где бизнес-правила не задокументированы и допускают вольную трактовку? В процессе сбора информации рабочая группа изучает документацию, имеющуюся у бизнес-подразделений, у группы бизнес-архитектуры (если есть) и у IТ. Изучение документации позволяет сформулировать перечень вопросов для последующих интервью и рабочих совещаний с руководителями и персоналом.

Примечание: бо́льшая часть документов окажется полностью или частично устаревшей. Причем зачастую никто не может сказать наверняка, что в них актуально, а что нет. Динамическая природа бизнеса требует усилий по поддержанию в актуальном состоянии документов, описывающих бизнес и информационные системы, но в большинстве компаний не отдают себе в этом отчета. Пример: мы перепроектировали часть бизнеса одной крупной компании и попросили показать последние бизнес-модели. Модели, которые нам дали, были датированы 2000 годом. Мы попросили актуальные, но нам ответили, что они остаются актуальными, так как бизнес не менялся. В результате мы провели интервью с персоналом, обновили модели и передали их той группе, которая дала нам модели десятилетней давности.

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

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

5.2.3. Стандарты сбора информации

Любому проекту масштаба предприятия или сквозного процесса понадобятся специалисты по BPM и специалисты в других дисциплинах. В рамках CBOK мы будем говорить о первых. Масштабная инициатива означает несколько команд и в каждой команде несколько людей, проводящих интервью или рабочие совещания. Разные люди будут изучать действия, правила, проблемы и т. д. Опыт показывает, что обязательным условием успеха является согласованность информации, собираемой разными группами. В противном случае качество информации будет сомнительным, часть информации может отсутствовать и точную картину бизнеса составить не удастся.

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

Чтобы этого добиться, сбор информации необходимо стандартизовать – определить, какую информацию от кого следует требовать, как ее проверять, организовывать и хранить, порядок ее использования и обновления.

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

Использование BPMS вынуждает разрабатывать стандарты – иначе от моделей и информации, хранящейся в репозитории, не будет пользы. Если стандарты отсутствуют, рабочая группа не соберет всю необходимую информацию или оставит ее непроверенной. Если стандарты наличествуют, необходимо предусмотреть проверки информации на качество и на соответствие стандартам. В проектах BPM, использующих BPMS, разработка стандартов начинается со знакомства со стандартом, предлагаемым поставщиком ПО. Он становится отправной точкой, за которой следует адаптация к внутренним операционным стандартам, к IТ-стандартам, обеспечивающим совместимость BPMS с существующей IТ-инфраструктурой, и к принятому в компании формату. Стандарты BPM необходимы с точки зрения состоятельности информации, доступа к ней в соответствии с установленными правами и т. д. Если же речь идет о совместной работе команд и подразделений, распределенных по земному шару, то стандарты становятся жизненно необходимыми.