Все о системах управления бизнес-процессами
 
Почитать
Поговорить
Побродить
Завершить


 
BPM без бизнеса

Литература:

Автор: Юлия Вагнер

Оригинал статьи: http://www.osp.ru/os/2012/02/13014103/?from_mail=1

(авторский вариант)

Управленческая дисциплина Business Process Management изначально подразумевала под собой основу в виде методологии управления, однако постепенно этот термин стал использоваться шире, охватив технологическую области, что снизило интерес к нему со стороны бизнеса. В результате, появившийся было у бизнеса шанс получить источник повышения конкурентного преимущества, подкрепленный современными средствами автоматизации, грозит превратиться в призрака с приклеившимся ярлыком «серебряная пуля», а передовое ПО, которое вполне может претендовать на звание революционного, - в очередного «питомца» в ИТ зоопарке.

В начале 90-х годов идея, что любой деятельностью эффективней управлять, если управлять ею как процессом, без легко проникла в сознание бизнес-сообщества и, действительно, бизнес всегда мыслил категориями процессов, а термин «управление бизнес-процессами» только оформил де-юре сложившееся де-факто представление. Однако для претворения идеи в жизнь необходима была методическая основа, которая и   появилась в виде концепции реинжиниринга бизнес-процессов. Руководствуясь лозунгом Майкла Хаммера: «Реинжиниринг: не автоматизируйте, уничтожайте!», энтузиасты ринулись на функциональную пирамиду, с твердым намерением уличить подход «as-is» в недостатках, раскрыть глаза на открывающиеся в связи с грядущими переменами возможности подхода «to-be» и построить настоящий процессный рай. На практике оказалось, что as-is, как таковой, мало кого интересует, а описание to-be – это не болоее чем увлекательный процесс погони за собственным хвостом: пока одно описали, другое изменилось, и так до бесконечности. В результате, до процессного рая попросту не доходили руки.

Осознав бесперспективность такой работы, тот же Хаммер пересмотрел свои идеи и предложил менее радикальный, но более действенный способ перехода к процессному управлению, положив в его основу идею постоянного усовершенствования. Этот подход и был назван Business Process Management.

Волна BPM могла бы не стать такой мощной, если бы не совпала с появлением нового класса программного обеспечения – BPMS (Business Process Management Suite), превращающего схемы процессов в исполняемый код. Именно это позволило не только изложить, но и реализовать идею постоянного усовершенствования -- процессы компании описываются и автоматизируются в системе BPMS в том виде, в котором они реализованы в жизни, а после этого, основываясь на результатах анализа статистики поведения процессов, процессы постепенно совершенствуются.

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

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

Уровень процессной зрелости определяется многими факторами. Наиболее распространенной шкалой зрелости принято считать шестиуровневую модель зрелости Gartner (Gartner BPM Maturity Model). Ее адаптированный вариант предложил в своем докладе на конференции CNews «BPM 2011: Инновации и реалии» 6 октября 2011 года Анатолий Белайчук, президент компании Бизнес-Консоль (http://events.cnews.ru/events/2011/06_10_11.shtml) (Подробно о модели зрелости в блоге А.Белайчука  http://mainthing.ru/ru/item/298/). Согласно данному определению, зрелость BPM можно оценивать в трехуровневой системе измерения, где Уровень 1 – это описание и моделирование процессов, Уровень 2 – управление отдельными бизнес-процессами и Уровень 3 – управление сетью сквозных бизнес-процессов. Нулевой уровень – отсутствие процессности – можно считать точкой начала координат.

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

Рисунок. Модель зрелости BPM

 

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

Увлечение автоматизацией не позволяет организации подняться выше второго уровня зрелости.

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

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

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

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

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

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

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

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

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

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

Для многих это очевидно, но, несмотря на это управление процессами постепенно переползает в ИТ-департаменты. Наиболее распространенные сценарии могут выглядеть следующим образом:

  1. Методология может получить техническое поражение еще до начала проекта. Потенциально у BPM есть две точки входа в организацию – «от бизнеса» и «от ИТ». В случае, когда точкой входа является ИТ, посылом изначально является BPMS, и проект, если он состоится, будет нацелен на автоматизацию, а не бизнес-цели.
  2. Сползание в технологическую плоскость может начаться тогда, когда организация достигает уровня 2, на котором автоматизация процессов становится необходимостью. В этот момент встает вопрос выбора программного обеспечения, что является областью компетенции ИТ. Понятно, что при выборе ПО организация стремится получить как можно большую функциональность, и задача ИТ на этом этапе – продемонстрировать бизнесу все потенциальные возможности BPMS. Но на сегодняшний день уровень развития систем BPMS настолько высок, что у не специалистов в области ИТ, возникает ощущение, что работать с подобными системами могут только специалисты ИТ. Возникает противоречие: потенциальный бизнес-пользователь поручает ИТ-специалистам найти систему с максимально возможным набором возможностей и, в итоге, выбирает танк там, где хватило бы обычного внедорожника, после чего приходит к выводу, что управлять этим танком может только специально обученный человек (ИТ-специалист). Иными словами, системы BPMS давят бизнес своим функционалом. Бизнес делегирует право на свою часть работы, а вместе с ней и управление процессами в отдел ИТ.
  3. Добиваться повышения производительности процесса или всей системы процессов можно разными способами – за счет привлечения дополнительных ресурсов, избавляясь от не добавляющих ценности действий или неверно организованной работы, или за счет автоматизации. Некоторые меры требуют принятия управленческих решений, которые, в свою очередь, требуют тщательного анализа, иногда – сложных согласований и консультаций. Результаты таких мер могут быть не так очевидны и легко измеримы, как результаты автоматизации. Повышение производительности за счет автоматизации – это наиболее очевидный и масштабируемый результат, позволяющий забыть о необходимости остальных мер.

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

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

Комментарии
#1 Кирилл Курышев, 29.03.2012 15:48

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

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

Я сейчас немного соприкасаюсь с модельно-ориентированным подходом к проектированию систем управления. И надо сказать, что идеальный BPM в моем представлении во многом соответствует данному подходу, за счет создания исполняемой модели процесса. Однако, слишком много мест остаются в BPM-системах вендоров, где не до конца интегрированы между собой разные аспекты поведения процесса. И здесь возникает противоречие. С одной стороны запрограммировать можно все что угодно, и значит функциональные возможности системы возрастают, с другой стороны кодом сложнее управлять, и самое главное аналитиков сложнее научить программировать чем рисовать. В качестве подтверждения моих слов приведу пример из области моей практики: Oracle BPM 11, по словам Артема Варкулеевича, сделал огромный шаг (по сравнению с Oracle BPM 10) в сторону визуального моделирования не только логики выполнения процесса, но и модели данных, и организационных аспектов выполнения процесса (я уж молчу про экранные формы)....мне кажется, что в аналитикам с таким инструментом работать проще и BPM будет оставаться в бизнесе а не в IT.

Извините, если увел разговор в сторону, но каждый имеет право судить об объективном с своей колокольниzwinker

#2 Сергей Кузин, 29.03.2012 18:13

В статье снова просматривается принимаемое "по умолчанию" предположение, что бизнес, а не ИТ должен моделировать бизнес-процессы.

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

Пункт 1 влечёт за собой либо создание разнобойно-бестолковых самоизобретённых описаний, ведущих к пункту 2, либо привлечение специалистов со знанием нотаций и передачу им работы по моделированию (то есть передачу ответственности в сторону ИТ).

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

Пункт 3 ведёт к сопротивлению и дискредитации BPM инициатив.

#3 Сергей Кузин, 29.03.2012 18:16

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

#4 Юлия Вагнер, 30.03.2012 14:47

Кирилл, Сергей, спасибо за комментарии.
Кирилл, соглашусь, что схема, возможно, не очевидная. Я поясню.
Синяя линия - это уровень 0, все процессы на начальной стадии относятся именно к этому уровню зрелости. Со временем часть процессов доходит до уровня 1, но часть так и остаются на уровне 0 - это зеленая линия. Далее (коричневая) - часть процессов достигают второго уровня,но часть так и остается на уровнях 0 и 1. Т.е. на каком бы уровне зрелости не находилась организация, часть процессов будет всегда оставаться на более низких уровнях. И это правильно.

Сергей,
твой взгляд мне понятен, и я отдаю должное твоему опыту общения с руководителями и собственниками. Но должна тебе сказать, что это не норма.
Проблема ведь не в неумении моделировать в какой-то нотации. Проблема в отсутствии понятий о менеджменте как о науке. Делают, как подсказывает интуиция. Но, слава богу, далеко не все.Среди моих знакомых есть несколько собственников неслабых бизнесов. Так вот это люди с весьма неслабым базовым образованием, но при этом все имеют либо MBA, либо другие дополнительные дипломы. И у них как-то сразу срабатывает "надо разобраться", когда с ними о BPM разговариваешь (в смысле нотаций и технологий), а не "это слишком сложно". И у них нет проблемы с изучением нотаций.
К тому же, для описания процессов на том уровне, которого требует их позиция, совершенно не надо знать всех тонкостей, скажем, BPMN. Они описывают процессы верхнего уровня. А вот аналитик, который тоже является в данном случае представителем бизнеса, должен уже обладать необходимыми знаниями хотя бы одной нотации. Иначе он просто не соответствует занимаемой должности.
Тот факт, что часто аналитиками становятся выходцы из ИТ говорит только лишь о недостаточности образования у аналитиков "со школьной скамьи" и о инновационности мышления и привычке обучаться и разбираться во всем новом у айтишников.
По пункту 3 скажу только, что таким и не нужен BPM.
BPM вообще не ширпотреб. Это эксклюзив.
Шарфик от Louis Vuitton не одевают для того, чтобы скрыть засаленный воротник куртки "от подземного перехода". BPM не прикроет кретинизм.

#5 Сергей Кузин, 30.03.2012 15:25

Юля,
наличие у некоторых руководителей (как я понимаю, эксклюзивного меньшинства)желания "надо разобраться" в BPM действительно подтверждает отсутствие важнейших знаний в менеджменте даже у них (раз ранее уже не разбирались). И подтверждает моё утверждение 1.

"Они описывают процессы верхнего уровня" - да, и именно про подобные "описания" я утверждаю, что они малопригодны. Это п. 2.

Совершенно согласен со своим же п. 3 )))))

Итак, я бы оставил для обсуждения 3 вопроса:
а) для чего бизнесу нужно моделирование бизнес-процессов?
б) аналитик с его возможностями в использовании нотаций относится к бизнесу или к ИТ? Или занимает некоторое промежуточное положение между ними?
в) почему BPM - эксклюзив?

#6 Анатолий Белайчук, 01.04.2012 09:50

Сергей

Мне кажется, ты сам себя запугал zwinker

Бизнес не должен моделировать, но он обязан свободно читать модели, которые создает аналитик, понимать их и давать адресные поправки, замечания, предложения.

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

#7 Сергей Кузин, 02.04.2012 10:31

Анатолий, разве? ;-)

Цитирую: "Если придерживаться положения, что моделирование процессов – это прерогатива бизнеса, то можно сказать, что BPMS является переводчиком с языка бизнеса на язык ИТ."

Именно "... моделирование процессов - это прерогатива бизнеса..." и вызывает у меня возражения.

А то, что бизнес "..обязан свободно читать модели, которые создаёт аналитик..." - я обеими руками "за", но такое очень редко встречается. Гораздо чаще слышу в ответ "многа букафф/картинок, ниасилил..." :-)

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

Разве это решает вышеприведённую проблему?

#8 Юлия Вагнер, 02.04.2012 14:47

Сергей,

так ты уже ответил на свой вопрос б)? Т.е. аналитика ты относишь к ИТ?
Я настаиваю, что "моделирование процессов – это прерогатива бизнеса".

Вячеслав Зайцев - дизайнер или портной? Если дизайнер, то не должен отличать реглан от кармана и оперировать только категориями "красиво" и "не красиво"? А если отличает, то тогда уже портной? Или все-таки профессионал?

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

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

#9 Сергей Кузин, 02.04.2012 17:29

Юля, в п.п. б) я задал вопрос о том, к кому относится бизнес-аналитик. И хотел получить на него Ваш ответ. Свой я дал.
Тезис о том, что "моделирование процессов – это прерогатива бизнеса", я пока не разделяю, а почему - описал выше. Возможно, ошибаюсь.

На вопрос из п.п. а) ответа не вижу.

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

#10 Анатолий Белайчук, 03.04.2012 09:01

Сергей

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

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

Это дает основание для умеренного оптимизма, но конечно же не для торжества.

Стакан наполовину полон или наполовину пуст?

#11 Юлия Вагнер, 03.04.2012 10:45

С Анатолием согласна на 100%. И когда я говорю "эксклюзив", то как раз имею в виду, что BPM как раз для тех, кто "способен". А тем, кто не хочет напрягаться, вообще не надо заморачиваться. Жили же как-то без этого - ну и славненько!

#12 Алексей Машанов, 09.04.2012 22:44

Для начала представлюсь, меня зовут Алексей, работаю руководителем группы процессного контроля в компании с матричной структурой управления со штатом 3000 человек.

Год назад у нас стартовал проект по внедрению этого самого ПУ. За это время я миллион раз думал над вопросом «должен ли бизнес уметь читать или даже писать бизнес-процессы или нет?». Я понимаю, что буду субъективен, а возможно жёсток. Но чем чаще я слышал различные вариации «не должен», «мне некогда» и т.п., тем чаще я задавал вопрос «а зачем вы (функциональные топ-менеджеры) тогда вообще нужны?». Я сам топ-менеджер. И прекрасно понимаю, что достаточно часто в каждой функции есть некий «генерал», который «мыслит стратегически» и не его царское дело разбираться в этих квадратиках и ромбиках. Но сейчас, когда мы, худо-бедно, описали порядка 40 бизнес-процессов, я воочию убедился, что никакой «стратегии» в управлении процессами функций (и тем более – межфункциональными процессами) нет и в помине. Подавляющее большинство процессов построено по технологии «так сложилось исторически». Когда начинаешь сравнивать реальные процессы в разных городах или даже у разных сотрудников, то можно только удивляться, как при таком уровне вариативности мы вообще получаем хоть какой-то результат. Логики зачастую просто нет. Как правило, сотрудники на местах как то сами выкрутились, а «генерал» и рад (хотя при первом же аудите в случае чего свалит всё на тех, кто делал «не так как я написал»). Нет, в большинстве случаев у «генерала» есть «правая рука» - толковый смышленый парень или девчурка, которая как раз детально знает и бизнес-процессы, и в 1С (в отличие от «генерала») лазит с завязанными глазами, и с коллегами о корректировке бизнес-процесса договаривается за 5 минут, и, идя по коридору, не царапает стенки своими растопыренными пальцами.
Поэтому прежде, чем отвечать на вопрос «должен ли бизнес-генерал уметь читать бизнес-процесс?», надо ответить – на вопрос «а что он вообще должен то?». Он приносит по миллионному контракту каждый квартал? Он выдает по одной гениальной стратегии каждый месяц? Аналогичных вопросов можно задать массу. Я думаю, что главная проблема в том, что, как правило, «генералы» обладают в организации определенной властью, которая позволяет им завышать собственную стоимость. Впрочем, это право любого бизнеса определять насколько «великими» и далекими от реального бизнеса будут его «генералы». Думаю, это зависит от размера бизнеса. Наверное, в Газпроме, Лукойле или Альфа-банке уровень топ-менеджеров несколько отличаются от уровня топов среднестатистической российской компании. Так или иначе, «генерал» или «подполковник» или «майор», но именно представитель бизнес-функции должен детально знать, а значит уметь не только читать, но и писать бизнес-процессы. В противном случае, не совсем понятно для чего они (функции) нужны? И кто тогда должен писать их процессы? Бизнес-аналитик, которого всё чаще используют как психотерапевта? А не слишком ли дорого и нелогично?
В нашей компании функциональные менеджеры – это «технологи». Да, они топ-менеджеры. Да они участвуют в стратегическом планировании и разного рода великих проектах. Но на момент старта они вместе со своими «правыми руками» были включены в проект внедрения процессного управления, прошли все нужные тренинги и тестирование, научились не только читать, но и писать (причем как блок-схемы, так и сами инструкции!). И ничего зазорного в этом нет. Да, стонут, да времени на это все как всегда нет. Но то, сколько дури и нестыкух мы выявили за все это время, с лихвой окупает все трудозатраты. И мы все больше уверены в том, что в текущей (крайне нестабильной) ситуации на рынке, именно заставить великих топ-менеджеров спуститься на землю и вылизать свои бизнес-процессы – это один из эффективнейших приемов найти внутренние резервы и повысить свою конкурентоспособность. А то, что потом топ-менеджеры станут владельцами («генералами») бизнес-процессов, а все изменения будут разрабатывать и согласовывать с ними их «правые руки» (менеджеры бизнес-процессов) – это ничего страшного. Скелет то уже задан. Заодно «генералы», как минимум, поймут трудоемкость и стоимость для бизнеса и людей любых изменений, которые порой совершаются топами просто ради изменений и обозначения своей важности и гениальности.

А вообще, тема «должен или не должен» сильно напоминает анекдот про деваху, которая потребовала от своего мужика не только «в койку», но и разговоров о чем то высоком, интеллектуальном. Но споткнувшись на первом же вопросе, была отправлена «в койку». Поэтому ни столько не принижая роль топ-менеджеров в любой организации, я бы, перефразируя этот анекдот, сказал бы: «дорогой топ-менеджер, а давай-ка посмотрим насколько четко у тебя выстроены бизнес-процессы? Опаньки, а что за бардак? Твои сотрудники работают по инструкциям 2006года? Это они плохие? Нет – это ты не организовал нормально работу, и поэтому сейчас за них будешь сидеть и писать бизнес-процессы. Заодно узнаешь много нового». Смех смехом, но поверьте за год проекта я выслушал ни одну и ни две исповеди «генералов» на тему «я конечно подозревал, что у меня с процессами не все здорово, но что ваще полный бардак я даже представить себе не мог. Как они вообще работают?» В любом случае, любой «генерал» может притащить генеральному директору идею на миллион долларов, и тогда в ближайший квартал писать его процессы …. буду я. Ничего личного – бизнес smile.
ЗЫ. Некая неприязнь к топ-менеджерам, озвученная мной выше, не является моим принципиальным отношением к этим достойным сеньорам. Как я уже сказал – я сам топ-менеджер. И прекрасно знаю как «депутатская ксива» прозволяет бить баклуши. Поэтому моя неприязнь распространяется исключительно на тех, кто потерял чувство меры. В нашей компании таких не осталось. В том числе – благодаря опыту работы (попытки безделья) в нашем проекте. Поэтому очень рекомендую. Возможно вы не получите идеальных процессов. Но увидите своих топ-менеджеров в полевых условиях, и как на лакмусовой бумажке удивитесь как мало они знают о реальной деятельности своих сотрудников. Видели по телевизору, как толстых кабинетных сотрудников МВД заставляли сдавать нормативы ГТО? Вот, примерно, то же самое. «Парня в горы тяни, рискни… Не бросай одного его» (с) В.Высоцкий

#13 Анатолий Белайчук, 10.04.2012 11:19

Алексей

Жму руку!

Вам бы с этим на конференции выступить - фурор гарантирован. И/или на семинаре BPMS.ru. Ведь таким опытом мало кто в России располагает.

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

Удачи

#14 Юлия Вагнер, 10.04.2012 14:20

Алексей
не могу даже слов подобрать!Бальзам на душу smile

Комментарий просто убойный. Боюсь только, что не все "топы" смогут его прочесть. Как там у Сергея... "многа букафф/картинок, ниасилил..."
Так что еще один эксклюзив - только для тех, кто способен осилить.

#15 Алексей Машанов, 12.04.2012 23:55

Анатолий, я Вам тоже жму руку!
Жаль, что давно не общались :(.
Хотя как сказать - посмотрел записи Ваших вебинаров - это реально круто!

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

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

Юлия, ничего страшного. Я ж не для них писал, даже здорово, что не прочитают. Буду пользоваться этим приемом шифровки и впредь smile.
Кстати, испытывая постоянные вопросы одного из заказчиков проекта "Сколько сделали? Сколько осталось? Скажите ТОЧНО!" для себя мы придумали некую методику измерения уровня процессного управления. Она небесспорна (мягко говоря), запускаем только с 1 мая (но методика уже утверждена), да и как не крути - интеллектуальная собственность. Поэтому здесь пока выкладывать не буду, но Вам если интересно вышлю, Вы ж наши Учителя!

#16 Анатолий Белайчук, 13.04.2012 00:38

И все-таки, Алексей, если представится возможность и будете в Москве - выступите на семинаре, просим!

#17 Юлия Вагнер, 13.04.2012 11:38

Алексей,
конечно интересно! Особенно то, как это сработает. Понятно, что результат будет не сразу. Но, возможно, что Вы воспользуетесь предложением Анатолия (и, естественно, я к нему присоединяюсь!), и уже с результатами выступите на семинаре.
К сведению: материалы семинаров нигде не публикуются и не записываются. Так что все, что скажете, останется только между слушателями.
Так что просим!

#18 Андрей Клабуков, 18.03.2013 11:43

to Алексей Машанов,
Подписываюсь
Под
Каждым
Словом!
Пожалуй, распечатаю Ваш пассаж и повешу в рамку на стену, как эталон. Придется, правда другим листочком сверху прикрыть, во избежание (не все разделяют, к сожалению)...
Но еще раз Спасибо, Единомышленник, за то что заочно поддержал ту ТЗ, что в голове вертится, но на язык пока так и не попала

Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права