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

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

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

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

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

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

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

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

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

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

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

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

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

По мере дальнейшего совершенствования технологии BPM данный подход набирает мощный импульс и обладает крупными бизнес-достоинствами.

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

Вопросы, которые необходимо учесть:

• совместимость – все ли системы могут общаться друг с другом, в частности, интерфейсы и платформы;

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

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

Наконец, убедитесь, что среда тестирования аппаратуры в точности такая же, как и будущая эксплуатационная среда. Многие системы прекрасно тестировались в «лабораторных» условиях и «сыпались» в реальной эксплуатационной обстановке, потому что условия не совпадали.

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

Техническую операцию, заключающуюся в определении одной или более характеристик данного продукта, процесса или услуг согласно установленной процедуре.

(Воспроизводится с разрешения Центрального секретариата МОС с веб-сайта Международной организации стандартизации www.iso.org.)

Более подходящее определение тестирования программного обеспечения:

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

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

Требуют учета следующие весьма серьезные аспекты:

• важно помнить, что на подготовку и планирование нужно отвести более половины всего времени тестирования, а остальную часть – на фактическое проведение тестов;

• почти невозможно и весьма нежелательно выполнять 100-процентное тестирование, поскольку затраты и сроки будут нереальны. Лучше практиковать структурированный подход, добиваясь максимума эффективности при минимуме усилий. Руководитель тестирования должен всегда определять глубину тестирования, количество ошибок и «объем тестов».

Можно выделить следующие типы тестирования {57}:

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