В своей недавней заметке “BPM Skills” Адам Дин написал:

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

У меня есть возражение.

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

Ни одна система не может сама определить для себя цель. Поэтому только BPM-квалификации для успеха BPM недостаточно.

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

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

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

После того, как примерно год назад мы пришли к этому логическому выводу, мы разработали недостающую методологию системного выявления оптимальной цели для проекта BPM, основанную на идеях Гэри Раммлера и Элиа Голдратта. Мы применяем ее в проектах, предваряющих проекты BPM, где дается ответ на вопрос, который задает каждый руководитель, оценивающий BPM: “что я получу от этого вашего BPM в рублях”?

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

Большая часть работы в этих проектах делается самим клиентом - рабочая группа обычно включает от 15 до 20 человек, от руководства до ключевых специалистов. Мы ставим правильные вопросы, а ответы - их собственные.

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

Бизнес-процессы иногда называют «генетическим кодом организации».

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

В рамках этой аналогии BPM – это генная инженерия:

• мы расшифровываем геном организации (анализ и моделирование бизнес-процессов)
• мы идентифицируем отдельные хорошие и плохие гены (процессные паттерны и антипаттерны)
• мы удаляем плохие гены, заимствуем хорошие у одних живых организмов и прививаем их другим

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

Этим летом я заявился о намерении проводить тренинги по BPMN. И вот наконец подготовительная работа выполнена, график определен и запущен сайт, который так просто и называется: bpmntraining.ru. На нем есть вся информацию: что, где, когда, зачем и почем. (А если вдруг не вся, то на нем же можно задать вопрос.)

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

Уместен вопрос: зачем нужен “живой” тренинг, если в интернете есть масса материалов? - Это так, но интернет не научит вас, как применять BPMN к задачам, встречающимся в реальной жизни. Я занимаюсь этим последние пять лет - вы можете либо потратить примерно столько же, либо за 3 дня на тренинге получить необходимые знания и закрепить их в рабочих навыках.

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

Фактически речь идет о двух способах решения задач:

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

Какое-то мутноватое получается объяснение, не так ли? Добавляет путаницы то, что английские “template” и “pattern” зачастую оба переводят как “шаблон”, и смысл при этом частично теряется.

Думая о том, как это можно объяснить “на пальцах”, нашел аналогию в шахматах:

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

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

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

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

Паттерны в BPM - это типовые фрагменты процессов или межпроцессного взаимодействия (некоторые примеры).

Уместно спросить: от чего больше пользы? Мое мнение - от паттернов:

• Шаблоны специфичны (один процесс - один шаблон), паттерны универсальны. Хороший паттерн можно использовать в самых разных бизнес-процессах независимо от отраслевой специфики.
• Польза от шаблона на практике оказывается меньше ожидаемой. Как правило, позаимствовать удается только магистральный путь (happy path), а дьявол оказывается в деталях - в обходных путях, в обработке нештатных ситуаций.
• Эффект от использования правильного паттерна может быть очень большим. Например, в нашей практике был случай, когда процесс, изображенный на 6 склеенных друг с другом листах формата А4, за счет использования правильного паттерна удалось свести к изящной конструкции из 15 процессных шагов.
• Что касается антипаттерна, его польза в том, что в нужный момент он предостережет вас от ошибки. Цена ошибки теоретически может быть любой, и иногда реально большой.

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

Прихожу к выводу, что надо активнее предлагать услугу экспресс-анализа бизнес-процессов, предваряющую проект 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 как проекта, обеспечивающего высокую отдачу. Чтобы выстроить небольших кандидатов в ряд, важно сначала создать концептуальную модель бизнес-процессов верхнего уровня для поиска наиболее перспективных возможностей.”

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

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

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