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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проблема контекста

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

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

Проблема ценности