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

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

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

5.6.2.3. Проектирование изменений уровня задач и сценариев

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

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

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

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

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

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

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