Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0

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

Автоматизированное выявление бизнес-процессов

Этот подход основан на анализе фактического исполнения процесса. Тактика при этом может варьироваться. Это может быть простое наблюдение за работой исполнителей, непрерывно обращающихся к различным пунктам меню существующей информационной системы, с целью создания полной процессной модели. Несколько сложнее наблюдать за работниками умственного труда (штатными сотрудниками и фрилансерами), совместно выполняющими задание, с целью выявления альтернативных путей выполнения фрагментов процесса. Еще один распространенный вариант – воссоздание процессной модели по записям в аудиторских журналах информационных систем. По нашему мнению, такой подход дополняет адаптивный кейс-менеджмент (ACM)[90], в котором процесс, за исключением желаемых конечных и промежуточных результатов, остается неструктурированным.

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

5.0. Введение

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

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

Проектирование процесса представляет собой проект, которым, как и любым другим проектом, необходимо управлять. Но, несмотря на критическую важность формального проектного управления, в этой главе оно не рассматривается, так как это отдельная и самостоятельная компетенция. Читателям, интересующимся этой темой, мы предлагаем обратиться к материалам Института проектного управления (PMI)[91].

В данной главе мы рассмотрим все шесть наборов действий, приведенных на рис. 5.1, но при этом мы не будем ни ограничиваться только ими, ни структурировать главу согласно этому списку.

5.1. Что такое проектирование процесса

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

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

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