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

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

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

Подробнее о том, как разрабатываются модели процессов, см. в главе 3 «Моделирование процессов».

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

Многие задаются вопросом: почему я должен беспокоиться о модели «как есть»? Я изменяю компанию, почему просто не сосредоточиться на будущем состоянии? Ответ прост: потому что, прежде чем менять процесс, необходимо его понять. Вы не сможете просто создать концептуальную будущую модель бизнеса и рассчитывать на ее реализацию, не обеспечив возможность перехода от текущего состояния к будущему.

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

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

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

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

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

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

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

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

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

Мы рекомендуем проектной команде рассматривать эту информацию также и со стратегической точки зрения. Обычно обследование сосредотачивается на нуждах проекта и не предполагает, что информация его переживет. Или же просто ее никто не будет обновлять, и она устареет. С распространением BPM на основе BPMS ситуация меняется. Информацию из любого проекта можно занести в единый корпоративный репозиторий с тем, чтобы в итоге получить полный процессно-ориентированный взгляд на компанию и ее операции – на то, как она работает в реальности, а не просто по чьему-то мнению.

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

• Для процессов – подпроцессы и их взаимодействие.

• Для подпроцессов – бизнес-функции/сценарии и подразделения, которые их выполняют.

• Для потоков работ в рамках бизнес-подразделения – выполняемые действия (может детализироваться на более низкие уровни, чтобы показать задачи, из которых состоит действие).

Примечание: эти уровни декомпозиции модели составляют процессную иерархию.

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

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

• Метрики (численность сотрудников, объем выполняемой работы, частота ошибок), привязанные к точке операции, в которой они измеряются.

• Используемые IТ-приложения и где они используются.

• Основная функциональность каждого IТ-приложения.

• Данные – где хранятся, как вводятся и как используются.

• Правила – писаные и неписаные.

• Процедуры принятия решений с вероятностями исходов.

• Нормативы качества/продолжительности/производительности и т. п.

• Политика внутреннего аудита и прочие требования.

• Требования к измерению эффективности.

Примечание: это не полный перечень той информации, которая должна собираться в ходе разработки моделей процессов «как есть». Эта же информация должна рассматриваться как основная при создании модели бизнеса предприятия.

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

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