Управление бизнес-процессами. Практическое руководство по успешной реализации проектов
Шрифт:
Шаг 2. Определение компонент BPM
Одно из первых решений, которые нужно принять на этапе разработки, – какие компоненты автоматизированного BPM требуются – речь идет о принятии решения по необходимым инструментам. Вполне может оказаться, что на данной стадии решение окончательно утверждается, а не принимается. Некоторые инструменты уже могли быть приобретены для предшествующих этапов проекта (например, инструмент моделирования процессов и компоненты управления), а другие были рассмотрены на этапе инноваций (например, модуль-машина бизнес-правил или процессов).
Автоматизированное решение
1. Модуль (машина) рабочих потоков.
2. Модуль бизнес-правил.
3. Интеграция (интеграция приложений предприятия – EAI).
4. Интегрированная система управления документами.
5. Мониторинг бизнес-деятельности (BAM).
Остальные компоненты автоматизированного решения – инструмент моделирования и управления процессами, имитационное моделирование, учет затрат по типам деятельности и сбалансированной системы показателей. Эти компоненты больше ориентированы на моделирование и конфигурирование процессов, и в данной главе не рассматриваются. На рис. 19.4 показаны все компоненты.
При автоматизации процессов главный вызов, стоящий перед проектом, заключается в получении данных, требующихся для этого процесса. Такие данные могут быть разбросаны по нескольким старым системам. Исходя из доступности данных, проект должен определить, какие компоненты автоматизированного BPM предполагается применять для разработки решения.
Шаг 3. Решение повторно использовать, приобрести, создать или отдать в аутсорсинг
Следующее решение в проекте относится к подходу, который будет принят в отношении источника различных компонент ПО: сделать или купить. Ниже перечислены возможные варианты.
Повторно использовать имеющуюся систему
Основные достоинства:
• синергия и экономия на объемах;
• система известна и уже зарекомендовала себя.
Основной недостаток или проблема:
• система не отвечает всем сегодняшним требованиям или не обеспечивает достаточной гибкости для вероятных новых требований.
Купить готовый к применению стандартный продукт, который можно сконфигурировать
Многие поставщики решений BPM сегодня предлагают «каркас» приложений, которые предназначены стать опорными стартовыми точками для организаций. От них не ожидается полного решения, но они обеспечивают простую конструкцию, которую организация может расширять (конфигурировать) под свои конкретные требования. Если такое «рамочное» решение существует и в целом удовлетворяет требованиям бизнеса, это может дать существенные преимущества организации (и проекту). Примеры подобных «каркасных» решений: обработка страховых требований возмещения ущерба, различные приложения связи и обработка заявок на кредиты.
Основные достоинства:
• вероятность получить пригодный продукт или стартовый пункт;
• решение, которое отвечает конкретной ситуации в организации и на рынке;
• обеспечена поддержка продукта.
Основные недостатки или проблемы:
• дополнительные
• важно, чтобы начальная «каркасная» конфигурация отвечала требованиям организации, в противном случае она моментально устаревает (конфигурирование похоже на укладку бетона в арматуру: сначала он текучий, но потом застывает в камень);
• разработка системы по несформировавшимся требованиям, что может ограничить гибкость в будущем.
Разработать новую систему
Разработка специализированной системы. Если это вообще возможно, то, как правило, подобного развития событий нужно избежать.
Основное достоинство:
• систему можно целиком настроить и сконфигурировать для данной организации.
Основные недостатки или проблемы:
• значительные расходы и время разработки, а также текущие эксплуатационные затраты;
• риски проекта включают задержку сроков сдачи, низкое качество и повышенные расходы.
Аутсорсинг приложений
Этот вариант приобретает все более широкое распространение и должен быть серьезно изучен.
Основные достоинства:
• используются существующие знания и процессы разработчика;
• синергия и экономия на объемах.
Основные недостатки или проблемы:
• расходы по передаче стороннему подрядчику;
• недостаточная гибкость.
(См. Приложение L, где более подробно рассматривается аутсорсинг бизнес-процессов).
Количество систем
Автоматизированное решение почти наверняка будет содержать не один компонент, например модуль-систему рабочих потоков, автоматизированный модуль бизнес-правил и систему управления документами. В ситуации с несколькими автоматизированными компонентами следует обратить внимание на тот факт, что с ростом количества систем существенно растет число интерфейсов, как и объем усилий, необходимых для разработки и поддержки этих интерфейсов.
Шаг 4. Обновление функционально-технических спецификаций
Должен быть структурированный подход к спецификациям (функциональным, техническим и системным или проектировочным), разработке и тестированию решения BPM, как это изображено на рис. 19.5. V-схема показывает «недостающие звенья» между самими спецификациями и техническими условиями и тестированием. В недостающих звеньях, представленных на этом рисунке, зачастую скрываются коренные причины провалов многих проектов разработки систем в прошлом.
В левой части рисунка показаны бизнес-требования и соответствующая документация по разработке, а в правой части – тестирование, которое должно подтвердить соответствие продукта группы разработчиков этим требованиям и документам разработки. Проблема заключается в обеспечении соответствия ожиданиям с точки зрения бизнеса, и именно бизнес определяет, удалось ли этого достичь. Прямоугольники над пунктирной линией относятся к функциональным возможностям, а ниже этой линии – к техническим аспектам.