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