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

• Каковы затраты на внедрение новой модели (включая обучение, программное обеспечение и т. д.)?

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

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

5.9. Имитационное моделирование

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

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

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

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

5.10. Выводы

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

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

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

Проектирование процесса ведется при участии высшего руководства, владельца процесса и других заинтересованных сторон.

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

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

• Проектировать от действий, добавляющих ценность.

• Выполнять работу там, где это наиболее оправдано.

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

• Объединять процессы в кластеры.

• Уменьшать число передач ответственности между подразделениями.

• Уменьшать размер пакетной обработки.

• Предоставлять доступ к информации там, где она больше всего нужна.

• Вводить информацию один раз и давать к ней доступ везде.

• Перепроектировать процесс, прежде чем переходить к автоматизации.

• Проектировать исходя из желаемых показателей эффективности.

• Стандартизировать процессы.

• Рассматривать возможность перехода к удаленной совместной работе и аутсорсингу.

Проектирование процессов включает следующие действия.

• Моделирование с помощью специального программного обеспечения.

• Определение действий, составляющих процесс.

• Определение правил, диктующих ход процесса.

• Определение точек передачи ответственности.

• Определение метрик.

• Сравнение и бенчмаркинг.

• Имитационное моделирование и тестирование.

• Разработка плана внедрения.

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

Глава 6

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

Вступительное слово: Дэвид МакКой (David McCoy), управляющий вице-президент и почетный аналитик, Gartner

(© Gartner, Inc. 2012.)

Где-то между 2000 и 2001 годами, когда мы с Роем Шултом (Roy Schulte) руководили командой, представившей миру его концепцию мониторинга бизнес-действий (Business Activity Monitoring, BAM), мы обнаружили, что идея мониторинга «бизнес-действий» в реальном времени с помощью обработки событий, применения фильтров и аналитики вызывает большой интерес. Мне запомнилась одна наша презентация – первая в истории полномасштабная презентация BAM. Мы выступали совместно на одной из наших конференций, и аудитория была сильно ориентирована на технологии – вплоть до того, что несколько участников представляли компании, занимающиеся автоматизацией производственных процессов. Мы пытались донести мысль, что если что-то работает в производственном цеху, то это может сработать и в бизнесе. Сейчас, спустя 10 с лишним лет, мы видим, что BAM стал у BPM-экспертов дежурной темой и продать организации идею мониторинга эффективности процессов в реальном времени не так уж сложно. Однако, хотя BAM и завоевал место под солнцем, для многих концепция управления эффективностью бизнес-процессов в целом остается загадкой, и то, как эта деятельность осуществляется в большинстве компаний, оставляет желать лучшего.

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

Рассмотрим пример, который я описал в своем блоге[100]. В течение года мне часто приходится путешествовать вверх и вниз по горе Блад в штате Джорджия (США). Когда я еду вверх, то показатель «мили на галлон» резко падает. Но когда я еду вниз, позволяя силе тяжести на крутом уклоне делать свое дело, то показатель мгновенного расхода «мили на галлон» зашкаливает. В последней поездке мне удалось загнать этот показатель на отметку 99, упершись в предел, который программисты считали нереальным для автомобиля со средним расходом 25 миль/галлон. Это иллюстрация классического провала в управлении эффективностью процессов: ограниченность поля зрения.

Если бы мне пришлось разбить процесс путешествия на гору Блад на два подпроцесса – Подъем и Спуск, то тогда ограниченность поля зрения диктовала бы: «Выполняй только Спуск! Подъем обходится слишком дорого». Это звучит явно нелепо, но что получается, когда мы смотрим на наши бизнес-процессы, ограничив поле зрения? Мы совершаем точно такую же ошибку. Мы не воспринимаем сквозной процесс как объект измерения; вместо этого мы рассматриваем фрагменты процесса как изолированные и заслуживающие собственных метрик, измерений и оценок эффективности. Но, хотя в измерении эффективности фрагмента процесса нет ничего плохого, если такое измерение не является элементом целостного фреймворка – сквозного взгляда на процесс, – вы будете принимать квазиоптимальные решения, столь же многообещающие, как и идея перевалить через гору Блад, выполняя только спуск. Это ошибка контекста; исправляется она путем правильного восприятия процесса от начала до конца, процесса верхнего уровня в противоположность фрагментам процесса.

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