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

Следующее решение в проекте относится к подходу, который будет принят в отношении источника различных компонент ПО: сделать или купить. Ниже перечислены возможные варианты.

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

• синергия и экономия на объемах;

• система известна и уже зарекомендовала себя.

Основной недостаток или проблема:

• система не отвечает всем сегодняшним требованиям или не обеспечивает достаточной гибкости для вероятных новых требований.

Многие поставщики решений BPM сегодня предлагают «каркас» приложений, которые предназначены стать опорными стартовыми точками для организаций. От них не ожидается полного решения, но они обеспечивают простую конструкцию, которую организация может расширять (конфигурировать) под свои конкретные требования. Если такое «рамочное» решение существует и в целом удовлетворяет требованиям бизнеса, это может дать существенные преимущества организации (и проекту). Примеры подобных «каркасных» решений: обработка страховых требований возмещения ущерба, различные приложения связи и обработка заявок на кредиты.

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

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

• решение, которое отвечает конкретной ситуации в организации и на рынке;

• обеспечена поддержка продукта.

Основные недостатки или проблемы:

• дополнительные расходы (хотя, в конце концов, может оказаться экономией средств);

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

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

Разработка специализированной системы. Если это вообще возможно, то, как правило, подобного развития событий нужно избежать.

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

• систему можно целиком настроить и сконфигурировать для данной организации.

Основные недостатки или проблемы:

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

• риски проекта включают задержку сроков сдачи, низкое качество и повышенные расходы.

Этот вариант приобретает все более широкое распространение и должен быть серьезно изучен.

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

• используются существующие знания и процессы разработчика;

• синергия и экономия на объемах.

Основные недостатки или проблемы:

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

• недостаточная гибкость.

(См. Приложение L, где более подробно рассматривается аутсорсинг бизнес-процессов).

Автоматизированное решение почти наверняка будет содержать не один компонент, например модуль-систему рабочих потоков, автоматизированный модуль бизнес-правил и систему управления документами. В ситуации с несколькими автоматизированными компонентами следует обратить внимание на тот факт, что с ростом количества систем существенно растет число интерфейсов, как и объем усилий, необходимых для разработки и поддержки этих интерфейсов.

Должен быть структурированный подход к спецификациям (функциональным, техническим и системным или проектировочным), разработке и тестированию решения BPM, как это изображено на рис. 19.5. V-схема показывает «недостающие звенья» между самими спецификациями и техническими условиями и тестированием. В недостающих звеньях, представленных на этом рисунке, зачастую скрываются коренные причины провалов многих проектов разработки систем в прошлом.

В левой части рисунка показаны бизнес-требования и соответствующая документация по разработке, а в правой части – тестирование, которое должно подтвердить соответствие продукта группы разработчиков этим требованиям и документам разработки. Проблема заключается в обеспечении соответствия ожиданиям с точки зрения бизнеса, и именно бизнес определяет, удалось ли этого достичь. Прямоугольники над пунктирной линией относятся к функциональным возможностям, а ниже этой линии – к техническим аспектам.

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

Сколько раз приходилось слышать о ситуациях, когда бизнес вырабатывает спецификационные требования, технический персонал перерабатывает их в технические функциональные спецификации на языке, малопонятном бизнесу, и чтобы уложиться в сроки, дает бизнес-подразделению три дня на утверждение. Бизнес-подразделению не просто трудно понять технический язык, ему нужно одновременно вести обычную деятельность, поэтому уложиться в трехдневный срок практически невозможно. Чтобы избежать задержек, бизнес-подразделение утверждает функциональные спецификации, не отдавая себе отчет о последствиях. Группа разработчиков теперь создает новую систему BPM и сдает ее бизнес-подразделению. На стадии тестирования заинтересованные стороны заявляют, что система не отвечает их ожиданиям, утверждая, что «это не то, что они хотели!» Ответ группы разработчиков: «Это не так. См. с. 179 утвержденных технических условий разработки». Бизнес-подразделение отвечает: «Но это совсем не то, что мы имели в виду», после чего проект переходит на стадию переделывания, а это, в свою очередь, ведет к затягиванию сроков, увеличению затрат и упущенным потенциальным бизнес-возможностям.

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

Риски можно минимизировать несколькими способами:

1. Проведите анализ «что если…».

2. Проведите имитационное моделирование.

3. Определите, что не входит в объем проекта.

4. Бизнес-требования разрабатываются на этапе инноваций, а функциональная схема – на этапе разработки. Однако чрезвычайно важно обеспечить тесное сотрудничество бизнеса с техническим персоналом и совместно составить функциональную схему. У бизнес-подразделения должна быть возможность утвердить документ, полностью осознавая последствия и обеспечив соответствие и содействие требований бизнес-стратегии и целям. Хороший способ добиться понимания бизнес-требований – составить их, исходя из процессной точки зрения.