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

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

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

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

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

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

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

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

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

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

Пока собрался попросить у Гугла приглашение, пока они его прислали (месяца два пришлось ждать), пока нашлось свободное время разобраться и поэкспериментировать… в результате только сейчас дозрел поделиться впечатлениями.

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

Теперь в подробностях. Сначала ссылки на первоисточники - о чем собственно идет речь. (Поскольку продукт в бета-тестировании, все пока по-английски.)

• О сервисе
• Где использовать

Цитирую: “Google Wave - это онлайновое средство коммуникации и совместной работы в реальном времени”. Понятно? Мне лично ни черта. Поэтому расскажу на что это похоже, отталкиваясь от привычных вещей. Google Wave состоит… гм… из Waves. Буду называть их “гугл-волнами” или просто волнами. Сам сервис, чтобы не путаться, буду называть “GW”.

Итак, что такое гугл-волна? Представьте себе текст MS Word. Теперь представьте, что:

• Он хранится на сервере Гугл и вы обращаетесь к нему из браузера через страничку GW.
• Сильно урезан в части форматирования, но минимально необходимые вещи имеются: шрифты, цвета, поля, заголовки, списки, вставка картинок. Можно прикреплять файлы, как к email.
• В нем постоянно включен режим отслеживания изменений (наглядно видно что, кто и когда менял).
• Насыщен комментариями, вопросами-ответами, обсуждениями. Только не на полях, как в Word, а прямо в тексте блоками, выделенными рамками, и с теми же возможностями форматирования, что и в основном тексте.
• Текст и комментарии создаются, правятся, удаляются любым участником, так что при желании можно все подчистить и получить на выходе аккуратный текст. Но все ходы записываются и есть кнопка replay, показывающее что с документом происходило.
• Участник - это создатель волны и те пользователи GW, кого он пригласил в волну.
• Под реальным временем подразумевается вот что: если кто-то из участников что-то делает с волной, а у вас в это время открыто окно GW, то вы видите как он набирает буковки.
• Совместная работа в самом полном смысле этого слова: запросто я могу вводить текст в один раздел и одновременно другие участники - заполнять свои разделы, и при этом мы будем подбрасывать друг другу комментарии, замечания и вопросы. Никакой блокировки, никаких конфликтов благодаря реальному времени (правда, я не пытался их провоцировать).

Законный вопрос: настолько ли это лучше комбинации MS Word +электронная почта, чтобы осваивать еще одно средство? Полагаю, да. GW избавляет от вопросов типа “где последняя версия документа?” или “внесены ли в него мои последние правки?”. Кейт Свенсон справедливо указывает (тут и тут), что мы все подвержены “наркотической зависимости от email”, и GW - правильное лекарство от этой болезни.

Первые волны, на которых я экспериментировал:

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

С чем еще можно сравнить гугл-волну:

• С дискуссией на форуме. Волна с большим числом комментариев становится на него похожа. Поддерживается иерархия комментариев (комментарии к комментариям). Разница в том, что в любой момент можно отредактировать и основной текст, и любой комментарий.
• С фото-сайтом. Можно опубликовать фотографию в новой волне и обсуждать ее в кругу друзей.
• С хранилищем документов (Document Management System) вообще и с wiki, в частности. Похоже коллективной работой. Непохоже наличием реального времени в GW и тем, что обсуждение ведется не на отдельной страничке, как в wiki, а прямо в тексте. И то, и другое по моему плюс. Простая до тривиальности модель доступа: участник может все, остальные ничего. Отсутствие оглавлений и жесткой классификации, только тэги. Вывод: wiki - для нетленки, волна - для пены дней.
• С багтрекингом. Там тоже есть кейс, к которому цепляются файлы и по которому ведется обсуждение. Непохоже отсутствием в GW какой-бы то ни было структуры - чистый ad-hoc. В багтрекинге же без структуры не обойтись.

Еще плюсы:

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

Теперь минусы вместе с вопросами. (Возможно, какой-то минус - это на самом деле минус не GW, а мне, потому что не так понял или не смог разобраться.)

• Нет уведомления об изменениях в ваших волнах. Правда, если страница GW открыта в одной из вкладок браузера, то в заголовке появляется “Google Wave (3)”, что означает, что в волнах, за которыми вы следили, появились три изменения. Но надо постоянно держать страницу открытой. На странице идей народ массово высказывает по этому поводу свое неудовольствие. Есть мнение, что Гугл таким образом хочет “убить” email. Но по-моему, это врядли. Думаю, они реалисты и понимают, что это дополнение, а не замена. Так что надеюсь, в финальной версии возможность уведомления появится. По почте и по RSS. Кстати, мне лично второй вариант нравится больше, ведь страница Google Reader у меня и так постоянно открыта.
• Так же абсолютно необходим постоянный адрес (URL) волны. Пообсуждали-поредактировали, зафиксировали (запретили дальнейшие изменения) и получили HTML-страницу, на которую можно сослаться из письма или из блога. Пока я не вижу, как гугл-волну сделать частью Паутины. А концептуально это очень круто: при помощи GW можно было бы добавить ad-hoc функциональность везде, где ее не хватает. SAP со своим Gravity (BPMN-дизайнер для GW) добился той же цели, но при помощи плагина. Мне кажется, логичнее поступать наоборот: к примеру, вставить ссылку на волну в поле Link задачи MS Project, а не делать из Project плагин GW. <updated>URL волны отображается в адресной строке браузера, когда выбираешь волну. Так просто!</updated>
• Почему-то нет возможности оформить нумерованный список. Мелочь, но странно: маркированный список в панели форматирования есть, а нумерованного нет.
• Самая главная проблема: чтобы все это у вас реально заработало, необходимо, чтобы все те, с кем вы собираетесь общаться или совместно работать, были пользователями GW. Это барьер, и довольно высокий. Для сравнения, чтобы начать пользоваться гугловыми картами, этого не требуется, не говоря уж о поисковике. И чтобы отправить почту через gmail, тоже не требуется чтобы получатель имел почтовый ящик тоже обязательно у гугла. В гугловом фотобанке picasaweb  я могу дать доступ к моему приватному альбому, послав “секретную” ссылку на него по почте. Можно было бы в GW реализовать тот же подход - это даст возможность разово подключить к конкретной волне случайного участника без постоянного аккаунта. Впрочем, уверен, что ребята в гугле что-то придумают в плане облегчения доступа к GW. Не забываем: пока речь идет о версии сервиса для ограниченного тестирования.

Как стать пользователем GW? Для начала, у вас должен быть гугловый почтовый ящик (@gmail.com). Дальше самый простой путь - обратиться к кому-то, у кого уже есть GW. У каждого из нас есть по 25 приглашений. Можно обратиться непосредственно к гуглу, но приготовьтесь к тому, что придется ждать. Не исключено, что за это время гугл сделает сервис общедоступным. Приглашение же от существующего пользователя приходит практически сразу.

<updated>Полезные ссылки:

• Google Wave 101
• The Complete Guide to Google Wave
• Ultimate List of Google Wave Gadgets and Tools
• How to Install a Google Wave Gadget Extension

Happy waving!</updated>

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

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

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

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

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