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