Джон Джестон - Управление бизнес-процессами. Практическое руководство по успешной реализации проектов
Это являлось средством управления и контроля организацией своей операционной деятельности. Такое распределение работ и проверка состояния в сочетании с мониторингом бизнес-деятельности позволяли точно калибровать время согласно циклу процесса, что применялось для отладки/рационализации процессов, как описано на следующем шаге.
8. Последний шаг обеспечивал поддерживаемую устойчивость функционирования. Именно здесь осуществлялся мониторинг «фактической» обработки транзакций и собирались данные о реальном времени обработки, затратах, объемах и проблемах («узкие места», переизбыток укомплектования персоналом). Информация подвергалась постоянному мониторингу и анализу, вводилась обратно в имитационное моделирование, учет затрат по типам деятельности и далее в планирование персонала для уточнения необходимого числа работников.
Данная информация также использовалась для формирования сведений о показателях эффективности работы для хозяев процессов, руководства, коллективов работников и персонала.
Результаты
Финансовые результаты данной организации показали значительное сокращение коэффициента расходов по отношению к выручке (с 70 % до 40 % за три года). Разумеется, были и другие выгоды, например повышение удовлетворенности клиентов и персонала и самый высокий в отрасли показатель времени работы с клиентом.
Типовой анализ разрывов процессов
Анализ разрывов процессов выявляет различия между итогами этапа понимания и этапа инноваций, и должен содержать следующее:
1. Общий анализ влияния изменений процессов на организацию.
2. Варианты внедрения и замечания.
3. По каждому отдельному процессу:
• краткое описание процесса с этапа понимания;
• краткое описание выбранных новых процессов с инновациями;
• сводка основных различий между двумя версиями процессов;
• любые проблемы процессов;
• влияние соответствующих метрик;
• общее обсуждение влияния изменений и замечания.
4. Оценку сформулированного общего влияния.
5. Определенные сроки проекта.
6. Определенное влияние и требования обучения.
7. Выявленные вопросы управления изменениями.
8. Определенное влияние на структуру организации и требования.
9. Риски процессов и внедрения.
Приложение F
Этап разработки
Сверочный список: этап разработки
Данный сверочный список дает общее представление о возможных исходных данных на входе, конкретных результатах на выходе и шлюзах данного этапа.
Возможные данные на входе
С этапа понимания:
• модели действующих процессов.
С этапа инноваций:
• перечень согласованных задач процессов;
• модели и документация новых процессов;
• имитационные модели;
• разрывов процессов;
• выбранного решения;
• план проекта (подробно) для этапов персонала и разработки;
• уточненный и оптимизированный комплекс выгод;
• начальные требования бизнеса.
С этапа персонала:
• формирование измерений ролей (задач);
• показатели эффективности функционирования;
• документация для обучения.
Прочие входные данные:
• перечень связанных проектов с целью определить синергию и пересечение;
• архитектура предприятия или ИТ.
Конкретные результаты на выходе:
• общее описание решения;
• подробные требования бизнеса;
• документация выбора программного обеспечения;
• технические требования на программное обеспечение и структура;
• разработка и конфигурирование ПО;
• программы-скрипты и результаты тестирования ПО;
• технические спецификации аппаратного обеспечения и его наличие;
• программы-скрипты и результаты тестирования аппаратного обеспечения;
• программы-скрипты и результаты интеграции;
• подробности выявленных выгод (с этапа реализации ценности);
• распространение результатов.
Возможные шлюзы:
• конфигурация разработки и тестирования программного и аппаратного обеспечения не та же самая, что будет в реальной обстановке;
• анализ заинтересованных лиц и сторон;
• понимание масштаба перемен;
• способность организации изменяться;
• принятие BPM организацией;
• технические трудности;
• трудности с тестированием.
Компоненты автоматизированного решения
Компоненты автоматизированного решения BPM
Мы считаем, что есть девять составляющих – автоматизированных блоков полностью автоматизированного решения BPM (рис. П .11).
Кейс: у нас уже есть все компоненты
Нам приходилось видеть крупные организации, где имелись все девять автоматизированных компонентов-модулей, но эти организации не понимали, как объединить их в решение BPM, а иногда не понимали, зачем объединять.
Вывод. Без понимания BPM в руководстве организации, без схемы, опыта и профессионализма BPM автоматизированные компоненты либо не будут применяться, либо использоваться неоптимально.
Означает ли это, что каждое решение BPM должно быть автоматизировано? Конечно, нет. Степень автоматизации может быть от нуля до почти полной автоматизации. Уровень автоматизации зависит от потребностей организации.
Автоматизированные блоки рассмотрены ниже более подробно.
1. Средство моделирования и разработки процессов – инструмент моделирования организацией своих процессов и подпроцессов. Он не требует инструмента технологии BPM, поскольку моделирование можно выполнить, используя несколько продуктов Microsoft (или даже карандашом на бумаге, если пожелаете, но это будет дольше и значительно менее гибко). Технологически оснащенный инструмент моделирования гораздо эффективнее. Имеющиеся инструменты лежат в широком диапазоне: от простейших неразвитых средств, описывающих процессы в простом формате без связей с другими процессами до чрезвычайно сложных и развитых инструментов, строящих связи между процессами, подпроцессами, с общей картиной организации, обобщенными цепочками создания ценности и повторным применением подпроцессов. Все это осуществляется на основе технологии центрального хранилища на сервере.
Основные достоинства:
• возможность нескольким специалистам моделирования использовать и модифицировать модели в любой момент в любом месте, что сокращает сроки, улучшает согласованность и снижает затраты;
