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

3. Слой интеграции с другими системами и базами данных, содержащими информацию.

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

• знакома ли такая картина конечным пользователям и воспринимается ли она логично (т. е. похожа на другие системы и представлена логичной последовательностью картинок на экране);

• у различных типов пользователей будут разные потребности и способы взаимодействия с системой (например, работники, контролеры, менеджеры и т. д.).

Слой обработки связан с операциями, которые должна выполнять система. Необходимо, чтобы она разрабатывалась людьми, хорошо понимающими бизнес и цели проекта. Важный вопрос – документация, и при растущей популярности разработки пилотных инструментов (RAD и BPM) налицо крепнущая тенденция не документировать вообще, или делать это не столь подробно, как следует. Разработчики утверждают, что документация неявно присутствует в конфигурации системы, и ее можно там посмотреть. Вид системы дает представление о том, что было сконфигурировано, но не объясняет, почему была выбрана именно такая конфигурация. Не видя решений, определивших конфигурацию, трудно вносить изменения в будущем с какой-либо степенью уверенности, что они будут согласованы с выбранными ранее вариантами процессов.

Слой интеграции/данных более технический, поскольку связан с интерфейсами других систем. Требуются глубокие технические знания, а также четкое понимание систем, с которыми связаны автоматизированные решения BPM.

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

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

Следует ли организации сначала перейти на новую систему, а затем вносить изменения, или сначала внести изменения в существующую систему, а затем осуществлять переход на новую? Часто второй вариант предпочтительнее, поскольку, как показали многие проекты и организации, оказалось невозможным вносить изменения в систему, уже заполненную данными.

Выполняя подобный целевой анализ, важно различать важность, которую заинтересованные стороны придают своим требованиям. Очень практичен в этом смысле подход MoSCoW в DSDM (динамичная методика разработки систем, см. www.dsdm.org), который разбивает приоритет требований на следующие категории:

• M – строго обязательно;

• S

– нужно, если вообще возможно;

• C – можно, если не влияет ни на что другое;

• W – не будет (в данном выпуске), но хотелось бы иметь впоследствии.

Путь 1. Традиционный (SDLC) подход к разработке

На рис. 19.6 показаны шаги, которые выполняются в традиционном подходе к разработкам решения BPM по методу цикла разработки ПО (SDLC).

Хотя такой подход проверен, апробирован и зарекомендовал себя при разработке решений, он необязательно лучший или наиболее подходящий подход к проекту BPM. Самый целесообразный подход зависит от сценария, организации и объема проекта.

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

Возможно, более удачен подход быстрой разработки приложений.

Путь 2. Быстрая разработка приложений

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