5.6. Проектирование процессов и потоков работ – модель «как будет»

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

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

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

Приступая к перепроектированию, команда должна смотреть на схему «как есть» как на модульную. Каждое действие выполняется независимо, но оно связано с другими действиями входами и выходами. Выполняемая в нем работа контролируется руководителем и бизнес-правилами. IТ обеспечивает работу, предоставляя информационные системы и данные. Все в целом можно рассматривать как отдельный интегрированный модуль или сервис, в терминах SOA. Процесс при таком взгляде представляется в виде гибкой структуры взаимосвязанных сервисов, каждый из которых дает на выходе некий результат или компоненту итогового продукта. Такой модульный взгляд позволяет идентифицировать части процесса, способные обеспечить самый большой эффект либо немедленно, либо в долгосрочной перспективе, и относиться к ним дифференцированно.

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

Такая модульность обеспечивается определенным подходом к работе. Целостность модуля обеспечивается неизменностью его входов и выходов (только качество результата может улучшаться). Проектировщики могут менять модуль как угодно при условии, что его входы и выходы остаются неизменными. Если же выходы меняются, то воздействие такого изменения распространяется дальше по потоку, и возникает необходимость рассматривать как очевидные, так и скрытые последствия.

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

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

Группа, отвечающая за проектирование бизнеса, должна иметь представление о технических аспектах проектирования, создания и внедрения бизнес-усовершенствований. Аналогично группа от IТ должна иметь представление о подходах к трансформации бизнеса. Ограничения и доступные варианты будут сильно различаться в зависимости от того, опирается ли проектирование процесса на генерацию BPMS-приложений, на разработку информационной системы на. NET или на унаследованную систему на языке COBOL. Так как эти ограничения скажутся на проектировании новых бизнес-моделей и поддерживающих их приложений, их необходимо выявить и описать в начале проектирования.

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

Какую бы методологию ни выбрала процессная команда, в ней должны быть предусмотрены следующие ключевые действия.

• Проектирование нового процесса на соответствующую глубину детализации (согласно процессной иерархии).

• Выявление действий в рамках нового процесса, описание потока работ и зависимостей.

• Описание сценариев процессной работы и выделение модулей на основе этих сценариев.

• Описание потребностей в данных.

• Описание бизнес-правил.

• Описание передачи ответственности за процесс между функциональными группами.

• Определение показателей успешности изменения и эффекта с точки зрения потребителя.

• Определение целевых уровней показателей нового процесса.

• Определение и проектирование бизнес-отчетности и отчетности по эффективности.

• Оценка величины разрыва между текущим и желаемым положением дел.

• Разработка требований и спецификаций изменения бизнеса и информационных систем.

• Проектирование на физическом уровне.

• Анализ и проектирование IТ-инфраструктуры.

• Имитационное моделирование, тестирование и приемка.

• Автоматическая генерация или разработка IТ-приложений.

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

• Комплексное тестирование, включающее использование новых и унаследованных приложений и правил.

• Разработка и реализация плана внедрения.

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