Мне представляется, что роль KPI в проектах BPM преувеличена.

Распространенная точка зрения: если вы не замеряли показатели бизнес-процесса до выполнения проекта BPM, то вам не с чем будет сравнивать полученный результат, и следовательно, будет трудно доказывать эффективность проекта. В недавней заметке на Process Maker Blog “Top 3 BPM Software Pitfalls to Avoid” отсутствие контрольных замеров KPI названо самой распространенной ошибкой проектов BPM. В то же время в следующей заметке Process Maker Blog на эту тему “Are KPIs Necessary for BPM Success?” Ami пишет: “I imagine that a BPM project can be wildly successful without KPIs”. Что, с точки зрения формальной логики, означает отрицательный ответ на поставленный вопрос - KPI не является необходимостью.

Так в каких же именно ситуациях KPI не является необходимостью?

1. Если ставится задача не тонкой настройки процесса, а трансформации бизнеса

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

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

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

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

2. Если речь идет о запуске, а не о развитии проекта BPM

Когда речь заходит о KPI и о BAM, мы обычно говорим заказчикам: “чтобы дело дошло до аналитики, сначала нужно очень серьезно поработать”.

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

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

Правда, при рассмотрении более широкого контекста возникает вопрос: на что лучше направить усилия процессной команды - на дальнейшее “вылизывание” этого процесса или на то, чтобы заняться другим, в котором еще “конь не валялся”?

3. Если у компании проблемы с управляемостью

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

Тормоза и руль - это прямой канал управления, а спидометр и показатель остатка топлива - обратный. Прямой канал управления важнее обратного. Если у вас нет претензий к тормозам и к рулю, то можно порассуждать об эргономике приборной панели. Если такие претензии есть - никакой дизайн панели не спасет. А как вы оцениваете качество тормозов - замеряете тормозной путь? Да нет же - по ощущениям: “держат - не держат”.

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

Мы ведь не приказываем стрелке спидометра переместиться на отметку “90″ - мы жмем на газ или на тормоз, т.е. пользуемся прямым каналом управления. Точно так же, чтобы добиться улучшения итоговых показателей, необходимо активно воздействовать на бизнес-процессы, а через процессы - на сотрудников.

4. Если первоочередной целью проекта является выявление бизнес-процесса

Как-то один знакомый директор поделился: “Понимаешь, бизнес вроде идет, но я все меньше понимаю как мы работаем. И это начинает меня беспокоить.”

Очевидно, беспокойство вызывает ненадежность такого положения дел. Руководитель понимает, что бизнес уязвим: изменение внешних условий, уход ключевого менеджера - и здравствуй, кризис! Хотелось бы не магии, а науки. Точнее, не только магии (лидерство - вещь магическая), но и науки. BPM - это научная организация труда в XXI веке.

Выявление бизнес-процесса - это точная наука и при этом увлекательнейшее занятие. От “happy path” к разбору нестандартных ситуаций, от примитивных блок-схем к взаимодействию асинхронно протекающих бизнес-процессов и пониманию механики взаимодействия различных служб внутри компании. Это не “to be” и не “as-is”, это “as really is”.

Практика доказала, что есть только один способ получить схему процесса “as really is” - исполнять то, что нарисовано. “What you model is what you run”  - это принцип работы BPM-системы. Простое же “рисование” схемы процесса - бесплодное занятие. Для сертификации по ISO годится, для принятия управленческих решений - нет.

Что может быть хуже отсутствия карты местности для военачальника? Только карта с ошибками.

5. Если руководитель непосредственно вовлечен в проект

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

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

Для контраста, случай из нашей практики. На совещании по результатам пилотного проекта BPM директор сказал: “За то время, пока мы выполняли проект, три заказа, которые по всем признакам должны были стать убыточными, стали прибыльными.” (Оптимизированный бизнес-процесс гарантировал точность калькуляции и быстроту составления спецификации, что для них является ключом для успешных переговоров с заказчиком.) Думаете, его убедили бы KPI? Сомневаюсь.

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

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

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

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

Резюме

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

Кто-то может возразить: “но если KPI - вещь полезная, то зачем от него отказываться, хуже ведь не будет”. Именно что будет хуже. Заниматься чем-то ненужным можно только за счет того, чтобы не заниматься чем-то нужным. Время в проекте BPM - ценный ресурс; неоправданные задержки приводят к потере энтузиазма заинтересованных лиц. Проект начинает тормозить, в результате еще сильнее снижается энтузиазм и т.д.

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

(Эта заметка развивает предложенную концепцию стэка управленческих компетенций.)

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

BPM позволяет справиться с этой проблемой за счет:

1. непосредственно исполняемых схем бизнес-процессов (”What You See Is What You Run”)
2. быстрого прототипирования и коротких циклов разработки

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

То есть ИТ-консультанты пытаются повторять мантры, услышанные от бизнес-консультантов, типа: “SOA-решения от компании XYZ повышают мобильность и конкурентоспособность бизнеса!” Но это производит впечатление только на представителей ИТ-службы заказчика. У людей же бизнеса подобные пассажи вызывают в лучшем случае недоумение, а зачастую - резкое отторжение.

Логично ожидать, что эту проблему решат консультанты по BPM (в терминологии SAP - БП-эксперты). Взаимно перекрываясь, три уровня консалтинга (ИТ, BPM, бизнес) целиком охватывают матрицу корпоративных компетенций:

Но для этого надо, чтобы консультанты понимали друг друга и знали чего друг от друга можно ожидать. К сожалению, по моим наблюдениям сегодня это не так. Для начала, существует разрыв между бизнес-консультантами и консультантами по BPM:

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

Короче, первые знают “зачем”, но слабо представляют себе “как”, вторые - наоборот. Хотя бизнес-консультанты в массе хорошо представляют себе что такое бизнес-процессы и признают их роль в трансформации бизнеса, они слабо представляют себе что такое BPM и чего от него можно ожидать. Заказчику самостоятельно связать одно с другим непросто и конечно, он предпочел бы, чтобы между консультантами, работающими на уровне бизнес- и BPM-консалтинга, было бы взаимопонимание.

Может быть, консультанту по BPM просто освоить смежную область, стать по совместительству бизнес-консультантом и таким способом закрыть проблему? Эту идею следует отвергнуть:

• Консультанту по BPM определенно полезно разбираться в смежной области. Например, мы в проектах BPM используем концепцию цепочки создания ценности и принципы Теории ограничений. Но использовать и разбираться на уровне консультанта - это разные вещи. Ценится ведь бизнес-консультант не только досконально разбирающийся в той или иной концепции, но и обладающий кругозором, позволяющий ему определить какая концепция показана данному конкретному заказчику. Дотянуться до этого уровня консультанту по BPM нереально.
• К тому же не будем забывать, что помимо собственной области управления бизнес-процессами, консультант по BPM обязан разбираться в смежных областях ИТ - BPMS, бизнес-правила, SOA, интернет-технологии, корпоративная архитектура, разработка баз данных и бизнес-приложений.
• Даже если найдется такой супер-консультант, который разбирается и в BPM, и в ИТ, и в бизнес-концепциях, то как отнесется к нему потенциальный заказчик? По моим наблюдениям, к таким супер-специалистам заказчики относятся с недоверием - интуитивно они подозревают, что если его знания так широки, то они не могут быть глубоки. То есть его таланты и труд не будут оценены по достоинству.

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

Бессмысленно сетовать на разрыв между бизнесом и ИТ до тех пор, пока мы не преодолели разрыв на уровне консалтинга!

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

Определенные подвижки в этом направлении видны: например, интерес к конференциям по BPM только растет. Бизнес- и ИТ-консультанты, которые на них приходят, получают представление о том, что можно получить от BPM и от специалистов по BPM.

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

(Эта заметка развивает предложенную концепцию стэка управленческих компетенций.)

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

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

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

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

Например, вот так:

Или так:

Но, желательно, не так:

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

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

(Эта заметка развивает предложенную концепцию стэка управленческих компетенций.)

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

Рассмотрим в качестве примера концепцию клиенто-ориентированности:

• она присутствует в TQM (качество как соответствие ожиданиям клиента)
• она присутствует в реинжиниринге (радикальное усовершенствование бизнес-процесса, понимаемого как последовательность действий, дающих на выходе ценный с точки зрения клиента результат)
• она присутствует в методологии Раммлера-Брахе, системе Тойоты и Lean (цепочка создания ценности для клиента)
• и при этом сейчас появляется новая концепция Outside-In, в которой в очередной раз утверждается примат клиенто-ориентированности

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

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

То есть что происходит:

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

Получается, важнее кто делает, а не то, как это называется.

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

(Эта заметка развивает предложенную концепцию стэка управленческих компетенций.)

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

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

Например, EPM (Enterprise Performance Management), BI (Business Intelligence) и BSC (Balanced Score Card) - это все полезные вещи, но они дают только канал обратной связи. Для сравнения, BPM дает каналы и прямой, и обратной связи - роль последнего выполняет BAM (Business Activity Monitoring).

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

BI и BSC - это всего лишь панель приборов; чтобы заставить компанию совершить маневр, вам необходим BPM. С другой стороны, BPM относится ко второму, а BSC - к третьему уровню стэка. Поэтому комбинация BPM/BAM и BSC должна быть неплохой идеей.

(Эта заметка развивает предложенную концепцию стэка управленческих компетенций.)

В свое время я обратил внимание на то, что о бизнес-процессе и процессном подходе так или иначе говорится в методологиях TQM, Lean, Шесть сигм. В книгах по Six Sigma или Lean можно обнаружить целые разделы, в которых фактически пересказываются базовые принципы проектного управления и/или BPM. О процессах также любят порассуждать поставщики систем ERP и CRM.

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

Оборотная сторона этого тезиса - BPM не нужна собственная методология!

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

Ведь кому-то ближе философия Lean, кому-то - Теория ограничений, а кто-то заявляет, что это все устарело, и пропагандирует Outside-In. И очень хорошо - BPM подходит к любой из них, для любой из них он может сыграть роль “приводного ремня”.

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

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

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

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

К чему это приводит?

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

Для сравнения посмотрим на смежную область программного обеспечения для бизнеса и ИТ-консалтинга.

ИТ-шников тоже есть за что критиковать, и их обещания тоже надо делить на 4 (если не на 16), но есть существенное отличие: информационные технологии структурированы. Есть общепринятый т.н. стэк информационных технологий, который выглядит примерно так:

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

Но ведь примерно это зачастую происходит при выборе концепций бизнеса и менеджмента! Поэтому для них крайне полезно ввести понятие стэка управленческих компетенций. (Мне кажется, термин “компетенция” тут более уместен, чем “технология”, поскольку в бизнесе и менеджменте по сравнению с ИТ сильнее гуманитарная составляющая.)

Некоторые примеры:

• управление отношениями с клиентами, производственное планирование, бюджетирование находятся на уровне функционального управления (относясь к продажам, производству и финансам соответственно)
• BPM находится на уровне процессного управления (не путать с программным обеспечением BPMS, которое принадлежит уровню промежуточного программного обеспечения стэка ИТ)
• система Тойоты, Lean, Шесть сигм и Теория ограничений находятся на уровне концепций

Взаимосвязь между уровнями тут та же, что и в ИТ: нижний уровень без верхнего лишен смысла, верхний без нижнего - технологичности.

• Глядя сверху-вниз, нижний уровень является для верхнего обеспечивающим. Это “приводной ремнень”, преобразующий абстрактные идеи в конкретную деятельность конкретных людей, тем самым доводя эти идеи до практического результата.
• Глядя снизу-вверх, верхний уровень - это то, что придает смысл деятельности нижнего уровня и повышает его отдачу.

Проиллюстрирую эти взаимосвязи примерами:

• Нормальная компания не может существовать, если она не обладает компетенциями в области продаж, производства или оказания услуг (функциональный уровень).
• Компании, достигшей определенного размера и уровня зрелости, необходимо прилагать дополнительные усилия для координации деятельности функциональных подразделений в рамках сквозных бизнес-процессов или проектов (уровень процессного и проектного управления). Иначе функциональные подразделения все больше и больше начинают работать не на клиента, а на себя.
• Теория цепочки создания ценностей (уровень концепции) задает цель для проектов в области бизнес-процессов (уровень процессного и проектного управления). Дело ведь не только в том, чтобы все делать как положено и без простоев (”do things right”), но и в том, чтобы делать то, что востребовано (”do the right things”). Процессное управление, лишенное концептуального уровня, тяготеет к тому, чтобы бесконечно шлифовать бизнес-процесс, не задаваясь вопросом - а то ли вообще этот процесс дает на выходе?
• Теория ограничений (уровень концепции) предлагает алгоритм (”пять шагов”) поиска и выбора такого бизнес-процесса, усилия по повышении производительности которого дадут максимальную отдачу с точки зрения итоговых показателей компании, т.е. прибыли в настоящем и в будущем. Без концептуального уровня процессная инициатива вырождается, например, в анализ и моделирование бизнес-процессов на шести уровнях иерархии - занятие само по себе увлекательное, но бесплодное с точки зрения итоговых показателей.

Итак, компетенции нижних уровней обеспечивают реализацию компетенций верхних уровней. Уместен вопрос: а есть ли польза от компетенций верхних уровней в отсутствие нижних?

Полагаю - есть, но ограниченная:

• Вы можете начать внедрять процессное управление, не имея полноценного управленческого учета, но ваши успехи на этом пути окажутся ограниченными (если вообще они будут): вы быстро выясните, что любой бизнес-процесс оперирует бизнес-объектами, поддерживаемыми базами данных и корпоративными системами. Например, если вы возьметесь за процесс “от обращения до заказа”, не имея CRM-системы (обеспечивающей функциональную компетенцию), то через некоторое время вы обнаружите, что в рамках проекта BPM вы разрабатываете собственную CRM-систему. (Что, кстати, иногда бывает оправдано, но все же надо отдавать себе отчет, что собственная разработка, скорее всего, будет уступать готовым CRM-системам по функциональности.) BPM - это в основном для тех, у кого ERP и CRM уже есть, а счастья еще нет.
• Вы можете начать внедрять Lean, не обладая компетенцией в области процессного управления. В этом случае вы можете добиться успехов на уровне отдельных подразделений, но при попытке распространить эту методологию на компанию в целом у вас возникнут проблемы, так как ключ к разрешению противоречий между подразделений - это кросс-функциональные бизнес-процессы и BPM.

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

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

Вероятный сценарий:

1. Предположим, что некая компания A добилась впечатляющих успехов в трансформации своего бизнеса. Сведения об этих успехах стали достоянием публики.
2. Консультанты, принимавшие участие в проекте компании A, обобщили опыт, превратив его в новую методологию X, и стали интенсивно рекламировать себя и методологию X, действительно принесшую успех компании A. Примерно по этой схеме появились на свет TQM (Ксерокс), Lean (Тойота), Шесть сигм (Моторола).
3. Компания Q решила воспользоваться методологией X и повторить успех компании A. Но книги, посвященные X, достаточно скупо освещают необходимость ее обеспечения компетенциями Y и Z - во-первых, потому, что для компании A это слишком очевидно, чтобы об этом говорить, а во-вторых, любые предварительные условия негативно отразятся на продажах услуг, связанных с X.
4. В результате проект компании Q проваливается. Успех A и провал Q объясняется тем, что у A наличествовали компетенции нижних уровней, а Q решила не тратить время на их приобретение, а идти к “успеху” кратчайшим путем.

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

Резюмируя, обещанные рекомендации:

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

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

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

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

Но, подозреваю, главный вопрос - как быть, если жизнь берет за горло? Что ж, “выживают только параноики”. У остальных вечно получается так, что сначала слишком рано, а потом вдруг уже слишком поздно.

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

Следующие заметки развивают предложенную концепцию стэка управленческих компетенций:

• Отделить бизнес-методологию от процессной дисциплины
• Прямой и обратный каналы управления
• Выбор между компетенциями одного уровня
• Собственная или заемная компетенция
• Разрыв между бизнес- и ИТ-консалтингом

НИСКУ - это Национальный Институт Сертифицированных Консультантов по Управлению (niscu.ru), контакт у нас установился на круглом столе CNews. Взаимный интерес возник закономерно: упрощенно, управленческий консалтинг говорит что надо делать, а BPM-консалтинг - как.

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

Семинар позиционирован как дискуссионный и назван “Бизнес-технология BPM”. В термине Business Technology, который активно раскручивается Forrester, на мой взгляд, есть смысл. Ведь сейчас у нас, с одной стороны, есть бизнес- и управленческий консалтинг, которым не хватает технологичности, а с другой - ИТ, информационные технологии, которым не хватает ориентированности на бизнес-результат. BPM, по идее, призван работать на стыке между бизнесом и ИТ и таким образом, стать бизнес-технологией. Вот и обсудим, как этого достичь на практике, во взаимодействии с консультантами по управлению.

Семинар состоится 15.12.09. Информация о семинаре и регистрация.

На следующий день, 16.12.09 - очередной семинар BPMS.ru “Внедрение BPM в полиграфической компании“. Компания  Элевайз поделится опытом своего самого масштабного, на сегодняшний день, BPM-проекта. Во избежание недоразумений: заявленный в качестве оппонента Анатолий Белайчук - это не я, а Анатолий Константинович, зав.кафедрой корпоративных информационных систем РосНОУ, и мы с ним не однофамильцы

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

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

Но потом сталкиваешься с проблемой: руководители такого типа склонны не ставить задачу, а диктовать решение. Мы ожидаем, что нас позвали разобраться с проблемой и предложить решение, а оказывается, на нас смотрят как на “автоматизаторов”.

» читать дальше

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

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

Так что давайте с пониманием относиться к тому, что пользователи не всегда ведут себя так, как нам бы хотелось.