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

И это не предел – модель можно детализировать еще глубже. Основное правило – детализировать процесс до уровня, достаточного для:

• решения ваших задач и

• решения своих задач другими участниками на следующих фазах проекта.

На четвертом уровне задач представители бизнеса и IТ-специалисты обычно обладают достаточно детальной информацией, чтобы привязать правила к задачам, выполняемым людьми и системами, а данные – к экранным формам, отчетам и развилкам.

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

• провести совещание с разработчиками, чтобы выяснить, какая информация им понадобится в ходе разработки и тестирования ПО;

• позаботиться о документировании соответствия между пунктами требований и компонентами программного продукта. Это позволит гарантировать соответствие ПО потребностям исполнителей процесса.

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

Не забудьте предусмотреть в модели всю информацию, которая может понадобиться для последующей разработки ПО.

Те, кто непосредственно выполняет работу, обычно концентрируются на своих задачах (обязанностях, действиях, процедурах) и на шагах, из которых состоит выполнение этих задач. Шаги определяют, как выполняется работа.

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

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

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

Есть несколько подходов к моделированию: сверху вниз, снизу вверх, от середины в обе стороны. В некоторых методах рекомендуется применять итерационный подход. Выбор подхода определяется целями и масштабом проекта.

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

Сегодня все чаще моделирование процессов используется для:

• совершенствования масштабных, сквозных и кросс-функциональных бизнес-процессов, а также для

• управления эффективностью таких бизнес-процессов.

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

Главное правило – определить цель моделирования и исходя из этого выбирать оптимальный подход. Выбрав определенный подход, попробуйте применить альтернативный подход на небольшом участке, чтобы перепроверить результат. Например, выполните ограниченный анализ снизу вверх, чтобы убедиться в полноте модели, разработанной сверху вниз. Если задействована сервис-ориентированная архитектура (SOA) [68] Service-Oriented Architecture . – Прим. пер. , то подход снизу вверх может пригодиться при разработке интерфейсов к имеющимся сервисам.

Существуют разные способы сбора информации для целей моделирования. Возьмите на вооружение один или несколько из следующих:

• прямое наблюдение;

• интервью;

• опросы;

• модерируемые совещания;

• веб-конференции.

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

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

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

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

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

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