Пример:

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

В рассматриваемом примере мы как минимум должны предусмотреть три варианта:

1. платеж поступил
2. покупатель уведомил об отказе от оплаты
3. платеж или отказ не поступил в указанный срок

В BPMN специально для такой ситуации предусмотрена конструкция под названием “исключающая развилка, управляемая событиями” (exclusive event gateway):

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

К большому сожалению, поставщики BPMS склонны относиться к event gateway как к излишеству. Мне известно несколько систем, разработчики которых декларируют приверженность BPMN, но не поддерживают эту конструкцию.

Боюсь, это ошибка с их стороны - ведь задача обработки альтернативных сообщений никуда не денется! В отсутствие event gatway единственный путь - использовать параллельную развилку (parallel gateway). Но тут возникает проблема “гашения” остальных путей при приходе одного из сообщений, которую приходится решать при помощи искусственных конструкций в диаграмме и/или написания программного кода. Конечно, ни о визуальной наглядности процесса, ни о следовании стандарту речь при этом уже не идет.

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

Пока конкретная BPMS не поддерживает event gateway, нормально работать с сообщениями (message flow) в ней невозможно. Оркестровка в ней поддерживается, хореография - нет. На мой взгляд, такая система - это старый добрый workflow вне зависимости от наличия на нем лэйбла BPMN.

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

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

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

В самом деле, представим себе бизнес-процессы, составляющие типовую цепочку создания ценностей компании:

1. от идеи до продукта
2. от продукта до обращения
3. от обращения до заказа
4. от заказа до оплаты
5. после продажи

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

В современной экономике ограничителем, как правило, является рынок. Но в чем именно он нас ограничивает - в интенсивности первичных обращений (п.2)? Или может в нашей способности доводить обращение до заказа (п.3)? А может нам стоит обратить особое внимание на послепродажные процессы (п.5)? Ведь можно прекрасно отработать “на отлично” в рамках процесса продажи (п.4), но потерять и этого, и еще 10 потенциальных клиентов, потому что не отработан процесс работы с рекламациями.

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

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

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

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

• дать необходимую теоретическую подготовку в области BPM, цепочки создания ценностей, теории ограничений, гибких методологий (Agile)
• направлять и модерировать совещания рабочих групп и мозговые штурмы
• оформить полученные результаты в виде документов

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

А толчком к выводу в начале этой заметки - активнее продвигать изложенные идеи - стали опубликованные тезисы доклада аналитика Гартнер Билла Россера “Gartner Identifies Seven Major Guidelines to BPM Project Success” к предстоящей конференции по BPM (русский перевод на BPMS.ru). Цитирую:

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

Золотые слова!

18 февраля - очередной семинар BPMS.ru. Роман Ткачев (BI Telecom) обещает поделиться сокровенным

Следующий семинар BPMS.ru предварительно запланирован на 25 марта.

Тем временем, 12 марта пройдет очередной (третий) круглый стол CNews по BPM. Предыдущий прошел относительно недавно (в ноябре) - может показаться, что они зачастили. Но CNews постоянно мониторит свою аудиторию и реагирует на спрос. По их словам, интерес к 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 превращается в занятие, не завязанное на итоговые показатели компании. Методология нужна обязательно, но пусть она остается отдельной компетенцией. Пусть управленческие методологии развиваются и время от времени сменяют друг друга, а дисциплина управления бизнес-процессами пусть развивается сама по себе, оставаясь нейтральной по отношению к методологиям.