Перейти к содержимому

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

Управление бизнес-процессами (BPM) — это концепция управления, рассматривающая деятельность организаций через призму процессов (или административных регламентов в случае органов государственного и муниципального управления). В ней принимается, что цели организации достигаются через описание, проектирование, контроль процессов и их непрерывное совершенствование. Методы и подходы BPM нацелены на достижение нового уровня конкурентоспособности и взаимоотношений с клиентами, поставщиками и сотрудниками.

См. также: От функционального менеджмента к процессному, Учитесь видеть бизнес-процессы, Руководство по улучшению бизнес-процессов.

Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0. – М.: Альпина Паблишер, 2016. – 480 с.

Свод знаний по управлению бизнес-процессами. Обложка

Скачать конспект (краткое содержание) в формате Word или pdf

Купить книгу в Ozon

Глава 2. Управление бизнес-процессами

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

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

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

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

BPM отвечает на вопросы какая, где, когда, зачем и как выполняется работа и кто отвечает за ее выполнение. Многие организации полагают, что визуализации и пониманию бизнес-процесса способствует графическое представление действий в виде прямоугольников, связанных друг с другом в диаграмме с дорожками (рис. 1). На самом деле, она просто показывает «кто что делает». Хотя такая информация может быть очень полезной, в то же время она оставляет без ответа массу вопросов:

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

Рис. 1. Традиционная диаграмма с дорожками

Рис. 1. Традиционная диаграмма с дорожками

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

Чтобы обеспечить целостность процесса и возможность непрерывного совершенствования, управление бизнес-процессом должно осуществляться по замкнутому циклу (рис. 2).

Рис. 2. Цикл Деминга

Рис. 2. Цикл Деминга: «Планирование — действие — проверка — корректировка» (PDCA)

Назначение стадии «Проверка» цикла PDCA — измерить показатели эффективности процесса и сравнить их с ожидаемой эффективностью. Бизнес-процесс — это совокупность действий, создающих определенную ценность (продукцию или услугу) для потребителя. Это определение содержит как внутренний аспект (набор действий), так и внешний (ценность для потребителя), так что лучше всего контролировать показатели эффективности процесса с обеих точек зрения. Показатели эффективности, оцениваемые извне или с точки зрения потребителя, принято называть результативностью, они призваны отвечать на вопрос: «Делаем ли мы то, что надо?» Показатели эффективности, оцениваемые изнутри, принято называть производительностью. Они отвечают на вопрос: «Делаем ли мы так, как надо?»

Согласованное и проактивное управление бизнес-процессами требует существенных инвестиций в развитие способностей компании. Бизнес-процессы можно разделить на три категории.

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

Развитие способностей, относящихся к управлению бизнес-процессами предприятия, следует шкале уровней процессной зрелости (рис. 3).

Рис. 3. Процессная зрелость

Рис. 3. Процессная зрелость

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

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

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

BPM не предписывает определенный фреймворк, методологию или набор средств.

Информационные технологии во внедрении BPM играют не основную, а обеспечивающую роль.

Внедрение BPM является стратегическим решением и требует твердой поддержки со стороны высшего руководства.

Глава 3. Моделирование процессов

Моделирование бизнес-процессов — это набор действий, создающих представление существующего или предполагаемого бизнес-процесса. Статические модели отображают единственное, не меняющееся во времени состояние процесса:

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

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

Нотация — это стандартизованный набор символов плюс правила, определяющие, что они означают (рис. 4–9). Некоторые средства дают возможность перевести нотацию моделирования в исполняемый язык.

Рис. 4. Распространенные процессные нотации

Рис. 4. Распространенные процессные нотации

Рис. 5. Простая диаграмма BPMN

Рис. 5. Простая диаграмма BPMN

Рис. 6. Традиционная диаграмма с дорожками

Рис. 6. Традиционная диаграмма с дорожками

Рис. 7. Блок-схема

Рис. 7. Блок-схема

Рис. 8. Диаграмма IDEF

Рис. 8. Диаграмма IDEF

Рис. 9. Диаграмма потока создания ценности

Рис. 9. Диаграмма потока создания ценности

Рассмотренные ниже подходы (рис. 10) могут применяться в проектах моделирования и усовершенствования. Они позволяют проанализировать процессы со стороны предприятия в целом.

Рис. 10. Специализированные подходы к моделированию процессов

Рис. 10. Специализированные подходы к моделированию процессов

Подробнее о системной динамике, см., например, Моделирование системной динамики в iThink. Аббревиатура SIPOC расшифровывается как supplier (поставщик), input (вход), process (процесс), output (выход), и customer (потребитель). Это шаблон документирования процессов, принятый в методологии «шесть сигм» (см. Пит Панде, Ларри Холп. Что такое «шесть сигм»?).

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

  • Модель процессов предприятия
  • Модели бизнес-процессов
  • Модели потоков работ
  • Шаги выполнения задачи

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

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

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

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

Анализ процессов может инициироваться непрерывным мониторингом или определенными событиями:

  • Стратегическое планирование
  • Проблемы эффективности
  • Новые технологии
  • Слияние / поглощение / выделение активов
  • Нормативные требования

Анализ процесса может выполнять и один человек, но наилучший результат дает создание кросс-функциональной команды (рис. 11). BPM-профессионалы, принимавшие участие в масштабных проектах перепроектирования процессов, знают, что погружение вглубь одного процесса обычно не дает необходимого понимания. Рассмотрение действий и потока работ в рамках только одного процесса не может служить основой для совершенствования. Необходимо также изучить, как изменение одного процесса влияет на другие процессы, составляющие сквозной процесс. Чтобы правильно выбрать рамки проекта и средства, аналитик должен принять во внимание контекст процесса и его ценность для заказчиков и для других процессов. В подробностях эти аспекты рассматриваются ниже.

Рис. 11. Роли и обязанности команды аналитиков

Рис. 11. Роли и обязанности команды аналитиков

Действия, относящиеся к анализу процессов:

  • Бизнес-контекст
  • Организационный контекст (культура)
  • Метрики эффективности
  • Взаимодействие с заказчиком
  • Передача ответственности
  • Бизнес-правила
  • Производительность
  • Узкие места
  • Вариации (см. Контрольные карты Шухарта)
  • Затраты
  • Вовлечение персонала
  • Контрольные точки процесса

Сбор информации: интервьюирование, наблюдение, исследование. Анализ бизнес-среды: бенчмаркинг. Анализ информационных систем: анализ потоков данных, бизнес-правила, документация и перспективы дальнейшего использования.               Анализ процесса: моделирование, анализ затрат по действиям (см. Метод АВС: попроцессное калькулирование затрат), анализ корневых причин (см. Уильям Детмер. Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию), анализ чувствительности (см. Анализ чувствительности в Excel), анализ рисков (см. Управление рисками в компании). Завершающий этап анализа — подготовка отчета и другой документации по его результатам.

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

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

Глава 5. Проектирование процессов

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

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

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

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

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

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

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

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

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

Проектирование процессов и потоков работ — модель «как будет» (рис. 12).

Рис. 12. Действия по проектированию процесса

Рис. 12. Действия по проектированию процесса

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

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

Глава 6. Управление эффективностью процессов

Вступительное слово Дэвида МакКойя, управляющего вице-президент Gartner. Легко измерять эффективность процессов и управлять ею в теории, но, когда требуется осязаемый результат, мы зачастую терпим неудачу. Иногда неудача обусловлена используемыми технологиями: плохо интегрированные системы, устаревшая инфраструктура, негибкие программные продукты, невозможность обработки событий — все это ведет к неудаче. Но я думаю, что основная сложность — это триединая проблема контекста, ценности и угла зрения.

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

Рассмотрим сквозной процесс «от резюме до выхода на работу» — процесс найма на работу, который начинается с вакансии и заканчивается первым днем на работе. Является ли продолжительность цикла адекватным показателем? Это ошибка ценности; процесс подбора персонала должен заботиться не о скорости, а о качестве.

Если ваш процессный угол зрения таков, что заказчики — это стадо, то это отразится на ваших процессах. Коварство угла зрения здесь в том, что процесс порочен в корне: «В моей картине мира ты — источник дохода, который я должен максимизировать». Будет ли такой процесс работать в конечном счете? Приведет ли он к успеху, даже если очень хорошо им управлять? С одной стороны, вы генерируете денежный поток, но с другой — некоторых клиентов вы доводите до бешенства».

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

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

Процесс должен оцениваться с точки зрения вклада в конечную продукцию или услугу. Для такой оценки хорошо подходят техники «бережливого производства». Целью является доведение до совершенства того, что следует делать, а не просто того, что мы делаем сейчас (см. Джеймс Вумек. Бережливое производство).

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

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

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

О какой характеристике эффективности идет речь? — Например, затраты? По сравнению с чем? — Качество? Качество чего? Как оно определяется? — Время цикла на единицу продукции?

С чем измерения сравниваются и что они включают? Например, речь идет только о скорости или о скорости при заданном качестве?

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

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

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

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

Что необходимо измерять? Операционная эффективность: объем транзакции, время реакции на событие, очередь ожидания по подпроцессам, время обработки реакции на событие, количество ошибок обработки, количество отклонений от нормальной обработки, потери — время, ресурсы, проблемы с торговыми партнерами и соисполнителями. Финансы: стоимость каждого подпроцесса — персонал, сырье, возвратные платежи, общие и административные расходы, стоимость реализованной продукции — процесс, включающий стоимость внешней работы, — работа, переданная другому процессу и возвращенная назад; отходы; экономия от внедрения нового решения. Законодательство: соответствие законодательству; предоставление отчетности — своевременно и в полном объеме. Выявление проблем: проблемы передачи ответственности; качество базы данных — дубликаты записей и т.п.; результаты проверок и аудитов, простой из-за ожидания дополнительной информации. Потребительский опыт взаимодействия: удовлетворенность клиента от взаимодействия с компанией через отдел продаж, веб-портал, телефон; ошибки в заказах; решение проблем. Качество: мониторинг качества с использованием шести сигм, TQM; проверка/аудит сборочных узлов продукции или компонент услуг; проверка/аудит конечного продукта — ошибки и брак.

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

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

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

Карта потока создания ценности — техника, используемая в бережливом производстве для визуализации потока создания ценности в процессе. В ходе создания карты выявляется семь видов потерь (рис. 13).

Рис. 13. Семь потерь — карта потока создания ценности в методологии бережливого производства

Рис. 13. Семь потерь — карта потока создания ценности в методологии бережливого производства

Учет затрат по действиям (activity based costing, ABC) — это методология, которая относит затраты на выполняемые действия, а не на продукты или услуги (подробнее см. Метод АВС: попроцессное калькулирование затрат). Метод ABC превращает косвенные затраты в прямые. Он дает возможность сравнивать операции до и после усовершенствования процесса. Он показывает, что будет в случае отказа от проекта (сценарий бездействия) и какие процессы создают ценность (необходимы для привлечения и удержания клиента или приведут к экономии в операционной деятельности). ABC обычно используется там, где накладные расходы и цена ошибки высоки, процесс показал свою неэффективность.

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

Контрольная карта — это то, как процесс говорит с нами.
Ирвин Бёрр (Irving Burr), 1953

Контрольные карты, также известные как карты Шухарта, представляют собой мощную и повсеместно используемую технику для слежения за тем, что отклонения бизнес-процесса не превышают статистически допустимых (рис. 14; подробнее см. У. Эдвардс Деминг. Выход из кризиса, Д. Уилер, Д. Чамберс Статистическое управление процессами, Пример построения контрольной карты Шухарта в Excel).

Рис. 14. Контрольная карта Шухарта

Рис. 14. Контрольная карта Шухарта

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

[Суммарное отклонение] = [Случайное отклонение] + [Систематическое отклонение]

Для минимизации или устранения систематических отклонений могут предприниматься корректирующие действия. Когда все систематические отклонения устранены и приняты меры, препятствующие их повторению, формула превращается в: [Суммарное отклонение] = [Случайное отклонение], что означает стабильный и предсказуемый процесс. Вывод: никогда не прекращайте использовать контрольные карты.

Майкл Хаммер назвал «семь смертных грехов измерения» в своей книге Быстрее, лучше, дешевле:

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

Измерение напрямую связано с количественной оценкой данных в соответствии с принятыми стандартом и качеством (точность, полнота, непротиворечивость и актуальность). Метрика – есть результат экстраполяции или математической обработки результатов измерений. Индикатор — это упрощенное представление измерения или метрики, служащее определенной цели.

Глава 7. Процессная трансформация

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

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

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

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

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

Так как BPM-трансформация носит глубокий и всеобъемлющий характер, критически важно использовать в ней управление изменениями (рис. 15).

Рис. 15. Деятельность по планированию управления изменениями

Рис. 15. Деятельность по планированию управления изменениями

Глава 8. Процессная организация

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

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

Гэри Раммлер рассматривает три объекта управления на каждом из трех уровней организации (рис. 16).

Рис. 16. Три уровня организации

Рис. 16. Три уровня организации

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

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

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

Рис. 17. Потребность в кросс-функциональном сотрудничестве по процессам

Рис. 17. Потребность в кросс-функциональном сотрудничестве по процессам

Глава 9. Управление процессами предприятия

В управлении сквозными бизнес-процессами за несколько последних десятилетий наблюдались три волны прогресса (рис. 18).

Рис. 18. Три волны прогресса в управлении сквозными бизнес-процессами

Рис. 18. Три волны прогресса в управлении сквозными бизнес-процессами

Во время первой волны акцент делался на сборе статистической информации, необходимой для улучшения работы и качества продукции. Во время этой второй волны процессы сначала подвергались ручному реинжинирингу, а затем в ходе однократного проекта бетонировались в потрохах современных ERP и других автоматизированных систем. Несмотря на то что сейчас реинжиниринг бизнес-процессов Хаммера и Чампи в первую очередь ассоциируется с сокращениями, именно эта технология позволила компаниям разрушить барьеры между подразделениями и сконструировать сквозные бизнес-процессы, пронизывающие функциональные «анклавы». Третья волна BPM высвободила бизнес-процесс из бетонных оков и сделала его центром внимания и основным элементом информационных систем и бизнес-систем. С точки зрения автоматизации процессы стали гражданами первого сорта. Ключевым требованием при проектировании стала изменчивость. Лозунги третьей волны — обратная связь через результат, гибкость и адаптивность. Ответом стали системы управления бизнес-процессами (BPMS), ядро которых имеет дело с процессами, в отличие от ERP-систем, имеющих дело с данными и приложениями.

К сожалению, часто в BPM игнорируют «М» — менеджмент. Знаменитый вопрос светила в области процессов Эндрю Спани: «Что BPM реально поменял в поведении или в руководстве?» Это вопрос прямо в яблочко подлинной трансформации бизнеса. Бывает, что BPMS используют всего лишь как новую версию интеграции корпоративных приложений или традиционной автоматизации потоков работ. В сегодняшнем мире глобализации и экстремальной конкуренции управление (буква «М» в ВРМ) должно распространяться на всю цепочку создания ценности, а не только на предприятие! Стоящий перед нами вызов — это огромный скачок от BPM предприятия к BPM цепочки создания ценности.

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

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

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

Глава 10. Технологии BPM

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

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

Технологии BPMS включают составляющие, важные как для бизнеса, так и для IT. Можно выделить следующую базовую функциональность (рис. 19):

  • моделирование процессов;
  • имитационное моделирование;
  • описание бизнес-правил и управление ими;
  • отчетность по эффективности;
  • генерация приложений (обычно с некоторыми ограничениями);
  • сервис-ориентированная архитектура (SOA) / интеграция корпоративных приложений (EAI);
  • корпоративная сервисная шина (ESB).

Рис. 19. Функциональность BPM

Рис. 19. Функциональность BPM

Расположение функции по вертикали отражает принадлежность к бизнесу (вверху) или к IТ (внизу).

Основные технологии BPM:

  • Анализ бизнес-процессов (BPA).
  • Моделирование архитектуры предприятия (EA).
  • Системы управления бизнес-правилами (BRMS).
  • Системы управления бизнес-процессами (BPMS).
  • Мониторинг бизнес-действий (BAM).
  • Сервис-ориентированная архитектура (SOA) и интеграция корпоративных приложений (EAI).
  • Корпоративный репозиторий BPM (внешний по отношению к BPMS).

Архитектура BPM — это схема того, как сочетаются друг с другом различные компоненты BPM (рис. 20).

Рис. 20. Базовая технологическая архитектура BPM

Рис. 20. Базовая технологическая архитектура BPM; чтобы увеличить картинку, кликните на ней правой кнопкой мыши и выберите опцию Открыть картинку в новой вкладке

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

Если вы автоматизируете процесс с помощью BPMS, вы можете легко определить для него SLA и KPI. Регулярно производя замеры, вы можете отслеживать тренды и измерять повышение эффективности.

Литература на русском языке

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

Хаммер М., Чампи Д. Реинжиниринг корпорации. Манифест революции в бизнесе. М.: Манн, Иванов и Фербер, 2011

 

1 комментарий для “Свод знаний по управлению бизнес-процессами”

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *