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

И это не предел – модель можно детализировать еще глубже. Основное правило – детализировать процесс до уровня, достаточного для:

• решения ваших задач и

• решения своих задач другими участниками на следующих фазах проекта.

Нижний уровень определяет задачи исполнителей и требования к данным

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

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

• провести совещание с разработчиками, чтобы выяснить, какая информация им понадобится в ходе разработки и тестирования ПО;

• позаботиться о документировании соответствия между пунктами требований и компонентами программного продукта. Это позволит гарантировать соответствие ПО потребностям исполнителей процесса.

Информация этого уровня используется для генерации в среде BPMS процессных приложений, которые будут управлять ходом работ и автоматизировать ввод и обработку данных.

Не забудьте предусмотреть в модели всю информацию, которая может понадобиться для последующей разработки ПО.

Взгляд со стороны исполнителя

Те, кто непосредственно выполняет работу, обычно концентрируются на своих задачах (обязанностях, действиях, процедурах) и на шагах, из которых состоит выполнение этих задач. Шаги определяют, как выполняется работа.

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

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

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

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

Моделирование снизу вверх

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

Моделирование сверху вниз

Сегодня все чаще моделирование процессов используется для:

• совершенствования масштабных, сквозных и кросс-функциональных бизнес-процессов, а также для

• управления эффективностью таких бизнес-процессов.

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

Золотое правило моделирования

Главное правило – определить цель моделирования и исходя из этого выбирать оптимальный подход. Выбрав определенный подход, попробуйте применить альтернативный подход на небольшом участке, чтобы перепроверить результат. Например, выполните ограниченный анализ снизу вверх, чтобы убедиться в полноте модели, разработанной сверху вниз. Если задействована сервис-ориентированная архитектура (SOA)[68]68
  Service-Oriented Architecture. – Прим. пер.


[Закрыть], то подход снизу вверх может пригодиться при разработке интерфейсов к имеющимся сервисам.

3.5. Сбор информации о процессе

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

• прямое наблюдение;

• интервью;

• опросы;

• модерируемые совещания;

• веб-конференции.

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

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

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

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

Сбор письменных ответов на опросную форму также требует минимального отвлечения сотрудников. Обычно этот способ используется для сбора данных.

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

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

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

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

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

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

В качестве экспертов предметной области могут выступать:

• менеджеры высшего звена, определяющие динамику бизнеса на верхнем уровне;

• менеджеры среднего звена, определяющие механизмы мониторинга и контроля;

• рядовые сотрудники, непосредственно выполняющие работу, описываемую моделью.

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

3.6. Фреймворки и референтные модели

Проект моделирования может включать в себя разработку множества моделей, которые представляют ценность и по отдельности, и как часть комплексной картины. Использование фреймворков[69]69
  Framework – типовая (стандартная) структура или схема. – Прим. пер.


[Закрыть] и референтных моделей[70]70
  Reference model – общеизвестная типовая модель. – Прим. пер.


[Закрыть] повышает ценность и эффективность использования набора моделей как единого целого. Существует ряд широко известных фреймворков и референтных моделей.

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

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

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

• архитектурный фреймворк федеральных ведомств США FEAF[71]71
  Federal Enterprise Architecture Framework. – Прим. пер.


[Закрыть];

• архитектурный фреймворк Министерства обороны Великобритании MODAF[72]72
  Ministry of Defense Architecture Framework. – Прим. пер.


[Закрыть];

• архитектурный фреймворк Министерства обороны США DoDAF[73]73
  Department of Defense Architecture Framework. – Прим. пер.


[Закрыть];

• архитектурный фреймворк TOGAF[74]74
  The Open Group Architectural Framework. – Прим. пер.


[Закрыть].

Ценность этих фреймворков двоякая: во-первых, они помогают справиться с экстремальной сложностью подобных организаций, а во-вторых, служат базой для сравнения разных проектов внутри одного ведомства. TOGAF, последний фреймворк в приведенном списке, является универсальной версией комплексного фреймворка, поддерживаемого организацией The Open Group. Большинство этих внешне различных фреймворков являются либо производными фреймворка, предложенного Джоном Захманом (John Zachman) в 1987 году, либо разработаны под влиянием его идей.

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

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

SCOR® и DCORSM

Консорциум The Supply Chain Council (SCC) разработал референтную модель под названием SCOR[75]75
  Supply Chain Operations Reference – референтная модель операций в цепочке поставок. – Прим. пер.


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

Референтная модель DCOR[76]76
  Design Chain Operations Reference – референтная модель операций в цепочке проектирования. – Прим. пер.


[Закрыть], также принадлежащая SCC, структурирует последовательность операций в исследованиях и разработке.

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

Референтные модели рассматриваются также в разделе 9.1.4.

3.7. Методы и средства моделирования

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

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

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

Распространенным сегодня стало также использование программ для рисования или моделирования в сочетании с проектором и большим экраном. У такого способа есть несколько преимуществ. Модель видна всем участникам и может редактироваться прямо в ходе обсуждения. Не требуется переносить модель в другое программное средство после завершения сессии; ее можно быстро и легко отправить по электронной почте.

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

Средства моделирования рассматриваются также в разделе 10.3.

3.8. Валидация и имитационное моделирование

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

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

• Прогноз эффективности будущей схемы процесса в различных ситуациях (при изменении числа транзакций в единицу времени, числа исполнителей и т. п.).

• Определение факторов, сильнее всего влияющих на эффективность процесса.

• Сравнение эффективности различных вариантов процесса в одних и тех же условиях.

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

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

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

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

Имитационное моделирование рассматривается также в разделах 5.9 и 6.13.

3.9. Ключевые понятия

Модели процессов

• Являются упрощенным представлением действий.

• Служат средством отображения различных аспектов бизнес-процесса.

• Применяются для описания, анализа и проектирования процессов.

• Полезны в качестве документа для целей обсуждения, обучения и координации; проектирования и составления требований; в качестве инструмента анализа.

• Могут отражать текущее («как есть») состояние процесса, одно или несколько предложений по изменению и финальное состояние «как будет».

• Могут требовать проверки правильности посредством имитационного моделирования.

Точки зрения

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

• Например, процессная модель может отражать точки зрения: организации в целом, бизнес-процесса, операции (потока работ).

• Каждой точке зрения соответствует свой оптимальный тип модели и уровень детализации.

Нотации

• Существует множество различных нотаций и методов моделирования.

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

• Некоторые нотации более универсальны, чем другие, и способны удовлетворить широкий спектр потребностей моделирования.

• Иногда целям проекта лучше соответствует не какая-то одна нотация, а комбинация нескольких.

Фреймворки

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

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

Сбор информации о процессе

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

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

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

Глава 4
Анализ процессов

Вступительное слово: Элис Олдинг (Elise Olding), Gartner Inc.

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

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

Между этими полюсами располагается множество методов анализа, нацеленных на повышение эффективности неструктурированной работы и коллективной работы – такие как анализ социальных сетей[77]77
  SNA – social network analysis. – Прим. пер.


[Закрыть], анализ матриц принятия решений или наблюдение за тем, как выполняется работа[78]78
  Shadowing work participants. – Прим. пер.


[Закрыть]. Это часто упускается из виду, из-за чего бытует мнение, что анализ процессов – это нечто относящееся к уровню исполнителей. Мы должны об этом говорить, чтобы поднять анализ процессов на уровень руководства.

Анализ процессов – это средство достижения цели, но не сама цель! Итогом работы должно быть создание ценности для организации. Одна из самых распространенных ошибок – останавливаться на анализе «как есть» слишком надолго, документируя каждую подробность. Я сталкивалась с организациями, у которых модели процессов заполняли комнаты от пола до потолка, а их бизнес-партнеры не желали эти схемы рассматривать. И не удивительно! Их изучение заняло бы несколько недель; даже я была ошарашена объемом.

Я задала несколько простых вопросов: «Какие проблемы вы обнаружили? Исходные значения каких показателей вы зафиксировали? Какие тенденции или вопросы стали очевидными в результате этой работы? Какие рекомендации по быстрым улучшениям вы выработали?» К сожалению, убедительных ответов на эти вопросы не было. Организация сбилась с пути и забыла, в чем заключается цель: в ценности для бизнеса.

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

На каком бы уровне вы ни проводили анализ, от оценки возможностей предприятия до подробного анализа «как есть», не упускайте из виду ценность для бизнеса. Всегда спрашивайте себя: «Окупится ли дальнейшая работа?» Помните о создании ценности для бизнеса и используйте методы, адекватные поставленной задаче. Постоянно думайте о том, целесообразно ли продолжать анализ, углубляясь в подробности дальше.

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