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

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

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

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

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

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

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

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

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

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

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

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

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

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

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