Читать онлайн «Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0». Страница 44

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При этом надо отдавать себе отчет, что «окончательная» модель не будет реализована никогда, так как при таком подходе взгляд на желаемое будущее постоянно пересматривается по мере появления новых концепций, новых технологий, новых программных продуктов и т. п. Также это представление корректируется, чтобы учесть требования конкурентоспособности, открывающиеся бизнес-возможности, влияние глобализации и т. д. То есть конечная цель не является неподвижной, вследствие чего путь и этапы его прохождения постоянно эволюционируют. Таким образом компания управляет конкретными изменениями и одновременно не теряет из виду общее направление движения и причины, по которым оно выбрано[97].

При этом подход к реализации каждой версии на этом эволюционном пути – такой же, как и к изменению, нацеленному на конкретное усовершенствование.

Компании работают, исполняя процессы. Процессы работают так, как диктуют бизнес-правила. Таким образом, эффективность компании напрямую зависит от качества процессов и правил. Но сегодня к ним добавляется еще один элемент: способность компании воспринимать изменения и быстро к ним адаптироваться. Наиболее конкурентоспособные компании способны управлять всеми тремя составляющими и рассматривают свои операции как нечто постоянно меняющееся, текучее.

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

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