У каждого бизнес-процесса есть владелец, отвечающий за его эффективность и имеющий полномочия добавлять или убавлять ресурсы, чтобы управлять эффективностью. Взгляд на процесс со стороны его владельца включает:
• бизнес-контекст;
• описание бизнес-процесса;
• границы бизнес-процесса, в рамках которых выполняется анализ и внедряются изменения.
Этот взгляд находит отражение в моделях сквозных[67] бизнес-процессов: основных, вспомогательных, управляющих.
Модели бизнес-процессов:
• отражают события, действия и результаты основных процессов, их подпроцессы и их взаимодействие с окружением;
• обычно также описывают вспомогательные и управляющие процессы и то, как они обеспечивают основные процессы и как взаимодействуют с ними.
3.4.3. Модели потоков работ
Взгляд со стороны операционного менеджера
Операционные менеджеры – это руководители, отвечающие за контроль эффективности работы и за ее неуклонное повышение. Их взгляд отражают модели потоков работ.
Модели потоков работ обычно описывают, что должно быть сделано для выполнения процесса. Это модели более детальные по сравнению с моделями процессов предприятия и моделями бизнес-процессов. Модели потоков работ разбиваются на действия (их также называют задачами или процедурами). Действия в модели потоков работ выполняются «функциями»: должностями, подразделениями, системами. Модель описывает связь действий с процессом и с функциями.
На этом третьем уровне детализации легко понять, какие действия выполняет функциональное подразделение. А группируя действия снизу вверх на уровень бизнес-процесса, легко разобраться, как вся выполняемая работа вписывается в процесс и какой вклад каждое действие вносит в создание конечной продукции процесса.
Модель потока работ дает лишь базовое представление о бизнес-операции. Этого понимания зачастую бывает недостаточно для решения проблем, сокращения издержек или автоматизации. В таком случае надо перейти на следующий уровень детализации.
3.4.4. Шаги выполнения задачи
И это не предел – модель можно детализировать еще глубже. Основное правило – детализировать процесс до уровня, достаточного для:
• решения ваших задач и
• решения своих задач другими участниками на следующих фазах проекта.
Нижний уровень определяет задачи исполнителей и требования к данным
На четвертом уровне задач представители бизнеса и IТ-специалисты обычно обладают достаточно детальной информацией, чтобы привязать правила к задачам, выполняемым людьми и системами, а данные – к экранным формам, отчетам и развилкам.
В качестве специалиста по бизнес-процессам вы можете стать участником проекта, в котором следующей стадией будет разработка прикладного ПО. Чтобы обеспечить разработчиков всем необходимым, следует:
• провести совещание с разработчиками, чтобы выяснить, какая информация им понадобится в ходе разработки и тестирования ПО;
• позаботиться о документировании соответствия между пунктами требований и компонентами программного продукта. Это позволит гарантировать соответствие ПО потребностям исполнителей процесса.
Информация этого уровня используется для генерации в среде BPMS процессных приложений, которые будут управлять ходом работ и автоматизировать ввод и обработку данных.
Не забудьте предусмотреть в модели всю информацию, которая может понадобиться для последующей разработки ПО.
Взгляд со стороны исполнителя
Те, кто непосредственно выполняет работу, обычно концентрируются на своих задачах (обязанностях, действиях, процедурах) и на шагах, из которых состоит выполнение этих задач. Шаги определяют, как выполняется работа.
На этом уровне детализации аналитик может указать шаги, которые должны быть выполнены для получения результата рассматриваемого действия. Для каждой задачи указываются: стартовое событие, шаги, критерий выполнения, руководящие принципы, используемые материалы и средства (включая программное обеспечение), результаты, индикаторы корректного выполнения и люди, к которым можно обращаться в ходе работы и которых надо поставить в известность о ее завершении.
Например, сотрудник отдела продаж страховой компании должен ввести в систему информацию о новом владельце полиса. На рассматриваемом уровне модели этой задаче дается название и перечисляются шаги, которые сотрудник должен пройти, чтобы ее выполнить.
Другой пример: производство в варианте «сборка под заказ». Заказчик размещает заказ через сотрудника отдела продаж. В этом случае аналитик должен выяснить, как составляются требования к заказной продукции. В предположении, что сборка производится из стандартных деталей, аналитик также должен описать, как составляется перечень деталей и доступных опций, как определяется порядок сборки, заказ деталей и как выполняется сама сборка.
3.4.5. Моделирование снизу вверх и сверху вниз
Есть несколько подходов к моделированию: сверху вниз, снизу вверх, от середины в обе стороны. В некоторых методах рекомендуется применять итерационный подход. Выбор подхода определяется целями и масштабом проекта.
Моделирование снизу вверх
Исторически модели процессов в основном разрабатывались с целью локального усовершенствования функции в пределах одного подразделения. Зачастую оказывалось, что процесс не документирован, и первым делом надо было выяснить, как в действительности ведутся дела. Для подобных проектов, нацеленных на уровень потоков работ и требующих глубокой детализации, подход снизу вверх является оптимальным.
Моделирование сверху вниз
Сегодня все чаще моделирование процессов используется для:
• совершенствования масштабных, сквозных и кросс-функциональных бизнес-процессов, а также для
• управления эффективностью таких бизнес-процессов.
Некоторые проекты трансформации начинаются с создания новой бизнес-модели, а затем определяется, что надо сделать, чтобы ее внедрить. Все более распространенным становится также комплексный подход, отталкивающийся от модели процессов предприятия, увязывающей бизнес-процессы с бизнес-стратегией. Для таких проектов оптимальным является моделирование сверху вниз.
Золотое правило моделирования
Главное правило – определить цель моделирования и исходя из этого выбирать оптимальный подход. Выбрав определенный подход, попробуйте применить альтернативный подход на небольшом участке, чтобы перепроверить результат. Например, выполните ограниченный анализ снизу вверх, чтобы убедиться в полноте модели, разработанной сверху вниз. Если задействована сервис-ориентированная архитектура (SOA)[68], то подход снизу вверх может пригодиться при разработке интерфейсов к имеющимся сервисам.
3.5. Сбор информации о процессе
Существуют разные способы сбора информации для целей моделирования. Возьмите на вооружение один или несколько из следующих:
• прямое наблюдение;
• интервью;
• опросы;
• модерируемые совещания;
• веб-конференции.
3.5.1. Прямое наблюдение
Прямое наблюдение – это хороший способ задокументировать подробности существующего процесса. Наблюдение способно выявить действия и задачи, которые иначе остались бы неизвестными, и оно способно обнаружить вариации и отклонения в работе.
Однако, поскольку прямое наблюдение неизбежно ограничивается относительно небольшой выборкой, оно может не выявить всего диапазона вариаций от группы к группе и от одного местоположения к другому. Также существует риск того, что исполнитель будет делать не то, что он делает обычно, а то, что, как ему кажется, вы хотите увидеть.
3.5.2. Интервью
Интервью помогает создать чувство ответственности за результат и причастности к работе над бизнес-процессом. Плюсом является также минимальное отвлечение участника от его обычных обязанностей.
Однако планирование и проведение интервью суммарно могут потребовать больше времени по сравнению с другими методами. Впоследствии может оказаться сложно свести все взгляды в единую систему. Этот метод, как правило, предполагает повторные вопросы исполнителям, и иногда с его помощью не удается выявить все выполняемые в процессе действия.
3.5.3. Опрос и письменные ответы
Сбор письменных ответов на опросную форму также требует минимального отвлечения сотрудников. Обычно этот способ используется для сбора данных.
