Управление бизнес-процессами. Практическое руководство по успешной реализации проектов

Джестон Джон

Типовой анализ разрывов процессов

Анализ разрывов процессов выявляет различия между итогами этапа понимания и этапа инноваций, и должен содержать следующее:

1. Общий анализ влияния изменений процессов на организацию.

2. Варианты внедрения и замечания.

3. По каждому отдельному процессу:

• краткое описание процесса с этапа понимания;

• краткое описание выбранных новых процессов с инновациями;

• сводка основных различий между двумя версиями процессов;

• любые проблемы процессов;

• влияние

соответствующих метрик;

• общее обсуждение влияния изменений и замечания.

4. Оценку сформулированного общего влияния.

5. Определенные сроки проекта.

6. Определенное влияние и требования обучения.

7. Выявленные вопросы управления изменениями.

8. Определенное влияние на структуру организации и требования.

9. Риски процессов и внедрения.

Приложение F

Этап разработки

Сверочный список: этап разработки

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

Возможные данные на входе

С этапа понимания:

• модели действующих процессов.

С этапа инноваций:

• перечень согласованных задач процессов;

• модели и документация новых процессов;

• имитационные модели;

• разрывов процессов;

• выбранного решения;

• план проекта (подробно) для этапов персонала и разработки;

• уточненный и оптимизированный комплекс выгод;

• начальные требования бизнеса.

С этапа персонала:

• формирование измерений ролей (задач);

• показатели эффективности функционирования;

• документация для обучения.

Прочие входные данные:

• перечень связанных проектов с целью определить синергию и пересечение;

• архитектура предприятия или ИТ.

Конкретные результаты на выходе:

• общее описание решения;

• подробные требования бизнеса;

• документация выбора программного обеспечения;

• технические требования на программное обеспечение и структура;

• разработка и конфигурирование ПО;

• программы-скрипты и результаты тестирования ПО;

• технические спецификации аппаратного обеспечения и его наличие;

• программы-скрипты и результаты тестирования аппаратного обеспечения;

• программы-скрипты и результаты интеграции;

• подробности выявленных выгод (с этапа реализации ценности);

• распространение результатов.

Возможные шлюзы:

• конфигурация разработки и тестирования программного и аппаратного обеспечения не та же самая, что будет в реальной обстановке;

• анализ заинтересованных лиц и сторон;

• понимание масштаба перемен;

• способность организации изменяться;

• принятие BPM

организацией;

• технические трудности;

• трудности с тестированием.

Компоненты автоматизированного решения

Компоненты автоматизированного решения BPM

Мы считаем, что есть девять составляющих – автоматизированных блоков полностью автоматизированного решения BPM (рис. П .11).

Кейс: у нас уже есть все компоненты

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

Вывод. Без понимания BPM в руководстве организации, без схемы, опыта и профессионализма BPM автоматизированные компоненты либо не будут применяться, либо использоваться неоптимально.

Означает ли это, что каждое решение BPM должно быть автоматизировано? Конечно, нет. Степень автоматизации может быть от нуля до почти полной автоматизации. Уровень автоматизации зависит от потребностей организации.

Автоматизированные блоки рассмотрены ниже более подробно.

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

Основные достоинства:

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

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

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