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

SWOT-анализ используется для выявления сильных и слабых сторон процесса, см. раздел 3.3.4 выше.

5.5.2. Приоритизация процессов

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

● процессы взаимодействия с клиентами;

● процессы, оказывающие большое влияние на доходы;

● процессы, обеспечивающие деятельность, представляющую большую ценность для бизнеса;

● кросс-функциональные процессы, нуждающиеся в координации.

Еще один способ приоритизации – с помощью матрицы 2 × 2, показанной на следующем рисунке.

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

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

Идентифицировать процессы для последующей приоритизации и выстроить их в систему в соответствии со стратегией и целями организации помогают процессные фреймворки. В контексте анализа процессов полезными могут быть фреймворки уровня предприятия, например SCOR и APQC PCF, см. раздел 4.8 выше.

5.5.3. Определение рамок проекта и глубины анализа

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

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

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

5.6. Методы сбора информации

Методы сбора информации включают:

● изучение имеющейся документации по процессу;

● интервью с лицами, имеющими отношение к процессу, в очном, заочном или групповом формате;

● пошаговое прохождение процесса или прямое наблюдение за тем, как он фактически выполняется;

● отчеты о результатах или транзакциях по процессу (эти данные могут подтверждать или не подтверждать информацию, полученную в ходе интервью с заинтересованными сторонами);

● аудиторские отчеты, показывающие существующие в организации контрольные точки;

● автоматическое выявление процессов по журналам информационных систем (process mining).

5.6.1. Изучение документации

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

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

5.6.2. Письменное анкетирование