5.6.2.1. Проектирование процесса «как будет»

На первом шаге проектирования рассматриваются изменения на уровне процесса в целом. Будут ли какие-то компоненты верхнего уровня (подпроцессы) добавлены или ликвидированы? Изменения на этом уровне добавляют или удаляют большие области работы.

Это относится ко всем уровням процессной иерархии (см. рис. 5.3): тип изменения на верхнем уровне определяет степень воздействия на нижние. В конечном итоге изменение будет спроектировано и внедрено на уровне потоков работ, подразделений и отдельных задач, то есть проектирование охватывает все уровни процессной иерархии (рис. 5.5).

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

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

• В чем цель этого процесса, подпроцесса, потока работ или действия?

• Не является ли он избыточными или похожим на уже имеющийся?

• Какие здесь есть проблемы, какие возникают вопросы к качеству и к контролю и почему они возникают?

• Почему необходим этот шаг?

• Какова его цель?

• Где он должен выполняться?

• Когда он должен выполняться?

• Кто лучше всех подходит для его выполнения?

• Адекватен ли уровень автоматизации?

• В чем основные проблемы?

• Как их можно устранить?

• Как сделать процесс максимально результативным (делать только то, что нужно)?

• Как сделать процесс максимально производительным (устранить лишние действия)?

• Как можно устранить выявленные лишние действия?

• Каким стандартам необходимо соответствовать?

• Как осуществляется мониторинг и контролируется достижение целевых показателей эффективности?

• Какие факторы ограничивают возможности изменения процесса, подпроцесса, потока работ, действия или сценария?

Примечание: приведенный список вопросов не претендует на полноту. Это лишь пример того, на что команда должна обращать внимание при проектировании изменений.

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

Если создаваемая ценность определена, значит, работа вносит свой вклад в продуктивную деятельность – «делает то, что надо»[98]. Таким способом мы избавляемся от работы, которая стала ненужной, но о производительности здесь речи не идет.

На этом первоначальном этапе создается фундамент новой модели. Если используется система BPMS, то на этом этапе в ней появляется новая модель.

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

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