Примечание:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<< | >>
Источник: Коллектив авторов. Свод знаний по управлению бизнес‑процессами: BPM CBOK 3.0. 2016

Еще по теме Примечание::

  1. Примечания
  2. Примечание 3.1.
  3. Примечание 1.1.
  4. Примечание 7.1.
  5. Примечание 7.3.
  6. Примечание 7.4
  7. Примечание 7.2.
  8. Примечание 2.2.
  9. Примечание 2.1
  10. Примечания
  11. Примечания