Шаг 4. Обновление функционально-технических спецификаций

Шаг 4. Обновление функционально-технических спецификаций

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

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

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

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

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

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

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

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

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

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

5. Разделите функциональную схему и техническую разработку.

6. Определите последствия разработки и добейтесь согласия по ним.

7. Как указано в главе 14, важно применять архитектуру гибко. Например, что делать, если появилось срочное бизнес-требование, а решение не укладывается в архитектуру? Один из вариантов – дать возможность проработать требование и установить строгие правила работы с таким исключением (например, решение должно быть выведено из эксплуатации в течение Х месяцев или соответствовать архитектуре в течение N месяцев). Такой механизм «клапана скороварки» очень важен, поэтому окончательный тест архитектуры – способ обработки исключений. Отвергать или игнорировать все исключения может показаться выигрышным подходом, однако это ведет к конечному проигрышу, поскольку люди будут все больше игнорировать архитектуру.

8. Критично включение требований к программному и аппаратному обеспечению, поскольку в большинстве случаев между ними есть взаимозависимость.

Кейс: неверный «быстрый путь»

Оператор связи хотел ввести новую систему для поддержки биллинговых процессов и обслуживания клиентов, и разработал требования только на основе действующей бизнес-модели: предоставление услуг наземной связи населению. Когда нам показали исходные спецификации, мы указали, что они полностью лишают систему гибкости. Исходя из обобщенной бизнес-модели, мы предложили оператору пойти по пути создания системы на основе переменного комплекса бизнес-параметров, а не жесткого программирования функциональности в системе. Например, вместо обеспечения услуг только населению, следует предусмотреть и другие типы клиентов: предприятия и дистрибьюторы, а вместо только одной роли организации (провайдер услуг) – допустить различные типы (сетевой оператор и дистрибьютор). Оператор совет проигнорировал, и после двух крупных перемен в его стратегии система стала безнадежно сдерживать бизнес; в такой степени, что была упущена редкая возможность увеличить долю рынка, и огромные усилия прилагались для сохранения рентабельности.

Вывод. Проведите анализ «что если…», чтобы убедиться, что ваши требования выдержат предполагаемые изменения.

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

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

В области BPM ведущая роль сегодня принадлежит следующим стандартам:

• BPEL (язык исполнения бизнес-процессов). Сейчас это главный язык исполнения, который компонует бизнес-процессы, используя веб-сервисы, и позволяет интегрировать и связывать различные приложения BPM;

• BPML (язык моделирования бизнес-процессов). Непосредственно конкурирует с BPEL как мета-язык моделирования бизнес-процессов;

• BPMN (спецификации обозначений моделирования бизнес-процессов). Стандарт обозначений (т. е. комплекс пиктограмм и графических изображений) для моделирования бизнес-процессов. Главная цель этого стандарта – применение общих графических средств моделирования в инструментах моделирования бизнес-процессов и приложениях BPM; таким образом, BPMN является дополняющим для других стандартов BPM;

• Wf-XML (расширенный язык разметки – XML – для рабочего потока). Обеспечивает взаимодействие и совместимость между модулями-машинами BPM, давая возможность исполнять длительные бизнес-процессы, задействованные на нескольких машинах-модулях;

• XPDL. Язык определения бизнес-процессов, который описывает полный процесс и может использоваться для интеграции компонентов BPM при моделировании, исполнении и контроле процессов в рамках продукта. XPDL также широко применяется в продуктах BPM с открытым исходным кодом.