В своей недавней заметке “BPM Skills” Адам Дин написал:
Самое ценное, что вы можете добавить к своему предложению в части BPM, это квалификация.
У меня есть возражение.
По моему опыту, самая большая проблема BPM-инициатив это целеполагание. Люди выбирают цель для BPM-проекта - т.е. конкретный бизнес-процесс - на основе интуиции или политики, но не тщательного анализа.
Ни одна система не может сама определить для себя цель. Поэтому только BPM-квалификации для успеха BPM недостаточно.
Конечно это зависит от того, что понимается под BPM-квалификацией, поэтому уточню: чтобы проект BPM был успешен, необходимо разбираться в анализе производительности компании, структурировании цепочки создания ценности, выявлении критических бизнес-проблем, установлении связей между бизнес-проблемами, процессными проблемами и проблемами производительности конкретных работников. Полагаю, для большинства эти компетенции лежат за пределами BPM.
Как я уже говорил здесь на блоге, это ничейная полоса между бизнес-консалтингом и процессным консалтингом: бизнес-консультанты знают что в итоге должно быть сделано, но имеют слабое представление о том, как стратегические цели достигаются при помощью методологии и технологии BPM. Специалисты по BPM либо ждут, что заказчик сам выберет процесс, либо помогают ему расплывчатыми рекомендациями типа “выберите низко висящий фрукт”.
Но послушайте: какая доля возможных процессов способна повлиять на итоговые цифры в балансе компании? Теория Ограничений постулирует, что в системе обычно есть небольшое число узких мест (или даже всего одно). Следовательно, результаты проекта BPM будут заметны на уровне компании только если он был нацелен на одно из этих немногих процессов - узких мест (или даже на единственный). В противном случае успех проекта BPM будет чисто локальным: он увеличит производительность звена, но производительность цепочки создания ценности останется прежней, так как она ограничена каким-то другим звеном.
После того, как примерно год назад мы пришли к этому логическому выводу, мы разработали недостающую методологию системного выявления оптимальной цели для проекта BPM, основанную на идеях Гэри Раммлера и Элиа Голдратта. Мы применяем ее в проектах, предваряющих проекты BPM, где дается ответ на вопрос, который задает каждый руководитель, оценивающий BPM: “что я получу от этого вашего BPM в рублях”?
Конечно, методология не дает прямого ответа на этот вопрос - в конце концов, потенциал для улучшения у каждой компании свой - но мы можем заранее рассказать как и где мы его отыщем. Такой подход потенциальных спонсоров вполне устраивает.
Большая часть работы в этих проектах делается самим клиентом - рабочая группа обычно включает от 15 до 20 человек, от руководства до ключевых специалистов. Мы ставим правильные вопросы, а ответы - их собственные.
Замечательный побочный результат такой работы - воодушевленная команда. После того, как удается выполнить сложную и ответственную задачу выявления узких мест в компании, они рвутся их ликвидировать при помощи BPM. Это самые лучшие условия для проекта BPM, какие только можно себе представить.
Hi Anatoly,
I think I’m agreeing with you here. I see BPM Skills not as “product skills”, but experience.
“One needs to be professional in analysing company performance, structuring enterprise value chains, identifying critical business issues, connecting business issues to process issues to personal performance issues for a BPM project to be successful”
The emphasis is on the professionalising customer personnel, the way they work - not the software offering.
Regarding “BPM folks either expect that a customer will pick the target process or assist him”
I think “expect” is not quite the right word… I think the word is “accept” (or “unfortunately accept”)
“BPM folks unfortunately accept that a customer will pick the target process or assist him”
I would love to arrive at a customer, that have their own experienced internal business consults and process consults.
I would love to be in a situation where the customer has analysed, identified and defined the right target for a BPM.
But usually - this is not the case.
It would be naive to think that I could turn away a customer until they get their act together.
My standard quote is: “If they were an efficient organisation – they wouldn’t need BPM”
The point I was trying to make was that there seems to be a lot of emphasis on “BPM software technology can solve your problems”.
We are investing a lot into the software solutions, and not into creating good internal business consults and process consults.
People cause projects to succeed, not technology.
People need skills to make the project succeed.
The problem is that these skills come from experience…
Cheers,
Adam
День добрый, Анатолий.
В посте Вы говорите о разработанной методике предпроектного анализа. Могли бы Вы детальнее расказать о ней. Если это конечно не коммерческая тайна
Согласен на любую форму представления, возможно это будет ответ к этому посту, а возможно это будет отдельный пост.
Спасибо. Давно слежу за вашим блогом. Впечатляет.
Adam
OK, please count my post as refinement, not objection
Сергей
Спасибо за оценку.
В двух словах: четыре сессии с интервалом в одну неделю, по 5-6 часов каждая. Каждая сессия начинается примерно с полутора часов лекционных, потом “генерация” - работа в группах и обсуждение наработанных группами результатов. В течении недели результаты приводятся в удобочитаемый вид, и следующая сессия. На выходе отчет с процессной архитектурой верхнего уровня, процессами - бутылочными горлышками, критериями оценки их эффективности и ожидаемый эффект от их усовершенствования.
От заказчика требуется серьезный commitment: речь ведь идет о том, чтобы оторвать руководителей и ведущих сотрудников от текущих дел примерно на 15% рабочего времени в течении месяца.
Излагать шесть лекционных часов в письменно - не говоря уже о методике “генерации” - это не на статью в блоге, а скорее на книгу. Лучше в понедельник свяжитесь со мной по скайпу: anatoly.belychook
Добрый день, Анатолий.
Особо согласен с фразой “что я получу от этого вашего BPM в рублях”. Очень часто заказчики задают этот вопрос, а ответ на него не всегда очевиден. Например, в ряде случаев приходится говорить об абстрактном повышении управляемости процессов, иногда - достижение каких-то числовых показателей ставит заказчик, как требование (например, увеличение количества обрабатываемых заявок в единицу времени), но эти показатели слишком специфичны, чтобы можно было потом на них опираться.
Для выделения узкого горлышка необходима большая предварительная работа, которую заказчик оплачивать не готов, но без которой поставить правильные цели нельзя. Насколько я понял, ваша методика, упомянутая в статье, как раз должна решать этот вопрос. Хотелось бы обсудить с вами подробности, если это возможно, т.к. есть мысли и идеи, которые вы, возможно уже проходили.
С уважением,
Иван.
Иван
Спасибо за отзыв.Этой заметке уже больше трех лет. За это время мы еще кое-что для себя поняли в этой области, а именно: нельзя перепрыгивать через ступеньки на шкале зрелости.
Системный подход к процессной архитектуре компании в целом - это третий уровень. Попытка перескочить на него, не научившись управлять отдельным процессом, слишком рискованна. Сначала люди должны на примере отдельного, но достаточно значимого процесса, понять с чем вообще этот BPM едят. Только тогда они будут подготовлены к тому, чтобы проецировать приобретенный опыт на всю деятельность организации.
Анатолий,
Да, я вижу, что заметка старая, но эта тема сейчас актуальна для нас. Возможно, вы посоветуете что-то из более нового материала?
Понятно, что переход к бизнес-процессам по всей компании разом невозможен, надо тренироваться и тренировать заказчика на отдельных небольших процессах, но тут как раз и возникает вопрос правильной идентификации этого процесса.