Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0 - Коллектив авторов
Шрифт:
Интервал:
Закладка:
5.6.2.2. Определение действий в рамках нового процесса
Как было сказано выше, бизнес-модель следует рассмотреть на нескольких уровнях детализации, чтобы убедиться в отсутствии нежелательных последствий вниз по потоку работ, в том числе для внешних групп.
Такую возможность предоставляет разработанная модель «как будет», включающая уровни подпроцессов, бизнес-функций, действий в подразделении, потоков работ и сценариев.
На данный момент из модели «как будет» исключены работы, не добавляющие ценности. Помимо этого, анализ моделей «как есть» и сопутствующей информации породил набор функциональных и нефункциональных бизнес-требований, список бизнес-правил, на которые необходимо обратить внимание (и которые, вероятно, будут использоваться в новой схеме), список требований к данным и описание функциональности IТ-приложений – существующей и требуемой. Также в результате проведенного анализа «как есть» у команды проектировщиков появился список существующих бизнес-проблем, ограничений на возможные изменения, целевые показатели эффективности, операционные регламенты и т. д. В результате у команды сложилось представление о том, как реально работает бизнес, что реально должны делать люди, выполняющие то или иное действие, и что им для этого нужно.
5.6.2.3. Проектирование изменений уровня задач и сценариев
Разумеется, все уровни процессной иерархии должны отвечать требованиям, выявленным в ходе анализа моделей «как есть». В версии модели, с которой начинается проектирование уровня задач и сценариев, избыточная работа на всех уровнях иерархии исключена. Но это только начало проектирования нового процесса. Теперь надо привязать проблемы из матрицы проблем и возможности из матрицы возможностей к конкретным процессам, действиям, задачам на соответствующих уровнях процессной иерархии, в конечном итоге дойдя до нижних уровней работы и автоматизации.
Проектирование должно добраться до уровня потоков работ в подразделениях и составляющих их задач и сценариев. Истинные причины всех проблем необходимо установить, проанализировать и устранить. Сначала проектировщики должны выяснить, где и как проблема себя проявляет и каковы критерии, по которым происходящее идентифицируется как ошибка или проблема. Затем, используя эту информацию, анализируются действия выше по потоку работ на соответствующем уровне детализации с целью определить, где проблема возникает и как она развивается. Вооружившись этим знанием, можно исключить многие проблемы, а чтобы возможные оставшиеся проблемы своевременно обнаруживались и устранялись, предусмотреть измерение соответствующих показателей. В тех же случаях, когда истинные причины проблемы находятся за рамками проекта, необходимо спроектировать способы борьбы с нею – ограничить возможные последствия, повысить качество и т. п. – в тот момент, когда поток работ пересекает границу рассматриваемой области бизнеса. Это потребует дополнительной работы и, следовательно, повлечет за собой дополнительные затраты, но устранять проблемы на входе обычно намного дешевле, чем в конце потока работ.
На этом этапе в новой модели также реализуются возможности усовершенствования, представленные в матрице возможностей. Проект следует доработать так, чтобы обеспечить их реализацию, и должны быть определены все необходимые для этого изменения. В процесс необходимо встроить средства измерения эффективности, которые позволят измерить реальный эффект и сравнить его с ожидаемым.
Новая модель не должна включать бесполезные действия, известные проблемы должны быть устранены или смягчены, возможности усовершенствования реализованы. Команде следует также выбрать между конкретным усовершенствованием и эволюционным подходом к изменениям.
Теперь команда должна составить список показателей, задающих критерии оптимальности новой модели, и представить его на утверждение руководству. Утвержденные показатели закладываются в основу измерения эффективности, и по ним оценивается успешность проекта. Тут следует проявить осторожность, чтобы не пообещать слишком много. Команда должна рассмотреть все пункты списка и убедиться, что новый проект отвечает всем требованиям.
На следующем этапе выделяются последовательности действий, выполняемых по определенному событию, в определенное время или в результате принятия того или иного варианта решения. Они группируются в сценарии. В ходе выполнения сценария результаты выполнения одних действий определяют, какой вариант продолжения процесса из имеющихся возможных будет выбран и какие группы действий будут выполняться следующими.
Вся работа разбивается на последовательности действий, приводящих к определенным значениям данных или решениям, которые диктуют выбор той или иной последовательности. Принятие решения сводится к стандартным вопросам со стандартным набором вариантов ответов. Такой подход позволяет избавиться от лишних уровней согласования и принятия решений. Все правила и логика маршрутизации становятся явными, их легко проверить и проконтролировать путем измерения в контрольных точках.
Однако изменения, сделанные до сих пор, включая рассматриваемый этап, еще не гарантируют эффективности процесса. В большинстве компаний результатом эволюции формальных и неформальных правил является их избыточность, противоречия, расхождения в определениях, нестабильность и проблемы с качеством. Поэтому бизнес-правила должны быть критически оценены на предмет необходимости и нормализованы.
Но модель процесса все еще может содержать разрывы, поэтому команда должна обратить внимание на потоки и на развилки и, по возможности, их упростить. Одновременно следует постараться избавиться от ручной работы везде, где возможно. Если используется BPMS, «белые пятна» можно заменить сгенерированными BPMS-приложениями. Если проектирование ведется с использованием традиционного ПО для моделирования процессов, необходимо обсудить с IТ возможности автоматизации и реалистичные сроки.
Отметим, что передача работ другой организации или на аутсорсинг – это не то же самое, что их устранение. Изменится отнесение затрат, но они не исчезнут и останутся в поле зрения компании.
Мы рекомендуем параллельно вести проектирование нескольких версий модели «как будет» и обкатывать на них весь спектр идей от скромных усовершенствований до фундаментальных преобразований. Полученные результаты следует тщательно рассмотреть и включить лучшие находки в новую модель.
Итак, в результате произведенных изменений мы упорядочили бизнес-операции. Если применяется BPMS, то это подходящий момент, чтобы воспользоваться имитационным моделированием, чтобы замерить показатели исходной версии «как есть» и новой версии и оценить возможный эффект изменений. Если его окажется недостаточно, команда может разработать еще одну версию с целью дальнейшей оптимизации.
Следующее, чем должны заняться разработчики, – это контроль выполнения действий и потоков работ. Сюда входят списки задач, возможность переназначения работ, а также измерение длительности, объема выполненной работы и контроль других существующих в компании нормативов.
В случае использования BPMS списки задач, назначение исполнителей, учет графиков рабочего времени, отчетность и т. п. встраиваются в приложения, которые генерирует BPMS, и таким образом обеспечиваются автоматизированный контроль и мониторинг эффективности, см. главу 10 «Технологии BPM». Если BPMS отсутствует, необходимо совместно с IТ решить, что можно предпринять в этой области. Модель должна соответствовать имеющимся IТ-средствам.
На завершающей стадии проектирования новой бизнес-модели определяются требования к информационным системам и к экранным формам. Если используется BPMS, это не составляет труда, поскольку вся нужная информация уже содержится в модели. В случае более традиционной поддержки со стороны IТ на этой стадии относительно высокоуровневый проект бизнеса детализируется до конкретных действий. Также конкретизируется до действий движение документов, здесь могут найти применение системы управления контентом.
С помощью аналитиков IТ-подразделения определяется, какие данные должны отображаться на каждом экране. Источники этих данных, такие как новые документы, звонки клиентов, унаследованные приложения, внешние партнеры и т. п., определяются и привязываются к точкам ввода данных. Также определяются точки контроля качества данных. На этой основе формируется картина использования данных унаследованных приложений, составляются требования к их модернизации и интеграции. Здесь же формируются требования к интерфейсам с источниками данных, к преобразованию и использованию данных.
