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

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

ОК, сказано-сделано. Лет через 10 - к середине 80-х - появились коммерческие СУБД, в которых, в принципе, было все нужное для жизни. Появление 1) СУБД и 2) стандартного SQL стало мощным толчком для разработки бизнес-приложений - прошло еще лет пять, и буйным цветом расцвели ERP, чуть позже - CRM, PLM и прочие.

Правда нельзя сказать чтобы СУБД так уж гладко вошли в жизнь программистов. Сегодняшняя молодежь уже не представляет, что данными можно управляться как-то по-другому, а в свое время было достаточно много критиков, заявлявших “вот еще, придумали какие-то СУБД на нашу голову. Да я на ISAM-файлах сделаю алгоритм, который уделает вашу СУБД.”

Но победила точка зрения, что структурирование данных подчиняется своим законам и в общем-то не зависит от алгоритмов обработки. Грамотно спроектированная БД позволяет реализовывать хоть такие алгоритмы, хоть эдакие - в отличие от “программ, работающих на ISAM-файлах”. Кое-кто и посей день тащится от этой идеи. И вправду изящной, и что важнее - правильной, но не окончательной.

Сначала некоторое уточнение внесло ООП, в котором на вопрос “что важнее - члены или методы класса” ответ однозначный: методы. Данные могут быть структурированы любым способом, главное - поведение объекта. Это отличается от подхода к разработке корпоративных систем, в котором алгоритмы пляшут от данных, и который, если разобраться, восходит еще к мейнфреймам и коболу. В результате получили: с одной стороны - СУБД с приматом данных, с другой - ОО-алгоритмы с приматом поведения. Пришлось создавать науку под названием Object-Relational Mapping, чтобы технологично связать одно с другим.

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

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

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

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

Примерно в это же время наметился кризис в разработке приложений: давнее соперничество между концепциями “best of breed” и “single vendor” закончилось победой первой за неявкой противника. Ведь сегодня single vendor-ов уже фактически нет, а то, что преподносится в качестве таковых софтверными мега-вендорами, является слабосвязными наборами программных продуктов, собранными в результате слияний и поглощений.

Чтобы сделать из этого набора настоящий single vendor программный продукт, надо переписать, во-первых, каждый новый поглощаемый кусок, чтобы он органично встраивался в нашу мега-систему. И что еще хуже, придется что-то пере/до-писать и в той части, куда мы встраиваемся. Ясно, что с ростом масштаба мега-системы переваривание каждого нового кусочка требует все больших затрат - грубо говоря, они растут по квадрату от размеров системы. Так никаких ресурсов не хватит - даже у самого мощного вендора. Что мы собственно и наблюдаем.

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

Идеи BPMS и SOA естественным образом дополняют друг друга: реализация SOA превращает ERP и другие корпоративные системы в контейнеры функций, доступных извне, например, через WS API, а BPMS является естественным потребителем этих функций, использующим их для построения бизнес-процессов.

Но эта идея не пришлась по вкусу производителям корпоративных систем - ведь она грозит упростить их продукты и превратить в товар массового потребления с соответствующим увеличением конкуренции и падением маржи. “Открытость к интеграции” в их интерпретации - вещь весьма оригинальная: “Из нашей системы можно вызвать все что угодно. - А как вызвать извне вашу систему? - А зачем это вам?!”. Молодцы, чо! Представили себе зоопарк систем, каждая из которых готова вызывать функцию соседа, но не дает вызвать свою… душераздирающее зрелище.

Но впрямую отрицать идею инструментального управления бизнес-процессами все же чревато - заказчики не поймут - и производители ERP и CRM стали встраивать процессные движки в свои системы. Можно из них извлечь пользу? Безусловно. Способны ли они заменить специализированные BPMS? Сомнительно. Вспоминаются 90-е годы, когда в России были буквально сотни бухгалтерских программ. Многие из них работали на собственных самопальных СУБД, и это преподносилось как достоинство: “купив нашу программу, вы сможете не только автоматизировать бухгалтерию, но сами разрабатывать базы данных для любых задач”. Ну и где сейчас эти самопальные СУБД?

В конечном итоге, разработка прикладного и системного (инструментального и промежуточного тож) софта - это разный бизнес, с разными законами выживания и преуспевания. Чтобы быть конкурентоспособным на рынке DBMS или BPMS, их надо продавать не конечным пользователям, а разработчикам приложений. А кто будет покупать процессный движок у SAP или 1С, чтобы разрабатывать приложения? Правильно - никто. Разработчикам, уже работающим на этих платформах, покупать незачем - они его получают вместе с платформой. А остальным это и в голову не придет.

Из-за этого шансов успешно конкурировать с независимыми разработчиками BPMS у разработчиков прикладных систем нет, в долгосрочной перспективе. Прогресс в этой области не останавливается: надо обеспечивать поддержку стандартов (BPMN, WS, REST), надо реализовывать модную функциональность (мобильность, социальность, облака), надо или реализовывать самим, либо обеспечивать бесшовную интеграцию с дополнительными сервисами (BRMS, CEP, BAM)… надо или участвовать в гонке, или сходить с дистанции. SAP тянул собственную СУБД много лет, но в итоге с дистанции сошел.

В общем, история продолжается. Оставайтесь на связи, будет интересно.

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

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

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

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

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

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

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

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

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

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

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

Но потом сталкиваешься с проблемой: руководители такого типа склонны не ставить задачу, а диктовать решение. Мы ожидаем, что нас позвали разобраться с проблемой и предложить решение, а оказывается, на нас смотрят как на “автоматизаторов”.

» читать дальше

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

Качество докладов было на высоте. Особенно мне понравились:

• Роман Ткачев (операционный директор БиАй Телеком, партнера Lombardi в России) рассказал про проекты в банке ВТБ-24 и в ритейловой компании. Отличный программный продукт, грамотный консалтер - мы вправе были рассчитывать на интересный доклад, и мы его получили. В кулуарах задал Роману пару ключевых вопросов. Во-первых, заплатили ли клиенты деньги за лицензию? Ответ - да. Вопрос, на мой взгляд, важный, так как проводит грань между инициативным пилотом, выполняемым поставщиком за свой счет и фактически без обязательств со стороны клиента, и следующей ступенью - продуктивным пилотом, выполняемым за деньги клиента и в условиях, когда клиент уже четко осознал, что ему это нужно. Второй вопрос - на каком уровне поддерживались проекты, конкретно - кто выступал в роли спонсора. Ответ - в ВТБ-24 проект поддерживался на уровне председателя правления банка. Это еще один ключик, позволяющий отличить “игрушечный” проект с сомнительными перспективами от реального. В общем, я рад за коллег из BI Telecom. Роман согласился, что ему стоило бы акцентировать эти моменты в презентации - что ж, так бывает, что самое интересное для аудитории для докладчика оказывается само собой разумеющимся.
• Алексей Будин (директор компании “Элевайз”, отечественного разработчика BPM-системы ELMA) живо и убедительно представил два взгляда на BPMS: со стороны заказчика и со стороны поставщика. Судя по презентации, система выглядит достаточно симпатично. А наличие интеграции с 1С (подтвержденной сертификатом “1С-совместимо”) является серьезным конкурентным преимуществом на отечественном рынке. Ведь поставщики импортных BPMS об интеграции с 1С не беспокоятся, а для среднего бизнеса в России 1С - практически стандарт. Поскольку мы тоже ориентируемся в основном на средний бизнес, сделал для себя вывод, что стоит познакомиться с этой системой поближе.
• Алексей Бойко (руководитель методического центра по проектированию бизнес-процессов КЭС-Холдинг) поделился опытом внедрения процессного управления в крупном энергетическом холдинге. Выдающееся достижение - то, что удалось заразить этой идеей высшее руководство. Причем видно, что для них это не увлечение, а систематическая работа по организации бизнеса сверху-вниз на принципах BPM. Для каждого бизнес-процесса верхнего уровня назначен владелец на уровне вице-президента, и в соответствии с утвержденным положением, владелец процесса отвечает в том числе за дизайн процесса. Наличие владельца процесса - это отличный критерий чтобы определить, является ли процессное управление для компании преходящим увлечением и поводом поговорить или же образом жизни. Алексей отдельно остановился на том, как повлиял на их планы кризис: они отказались от “ковровых бомбометаний” и перешли работе адресной, малыми силами, в сжатые сроки. Похоже, они сами не поняли как им повезло: кризис случился в самый подходящий для них момент, буквально заставив их начать работать так, как собственно и рекомендуется теоретиками BPM. Если бы не кризис, они бы наверное продолжали действовать в духе старого доброго реинжиниринга, и мы бы имели шанс услышать доклад из серии “как мы дошли до документирования четвертого уровня бизнес-процессов и поняли, что до шестого мы не дойдем никогда”. А так благодаря кризису получился такой “Lean поневоле”. С другой стороны, систематически пройти два уровня процессов сверху-вниз безусловно полезно. Из доклада осталось не до конца понятно как они расставляют приоритеты процессам - похоже, интуитивно-волевым способом. Если так, то им стоило бы подойти к этому более систематически - попробовать применить TOC, на основе экспертных оценок определить потенциал улучшения процессов. Да, и до использования BPMS (а следовательно, до детального моделирования и поддержки исполнения процессов в реальном времени) они еще не дошли. А я все-таки не очень верю в BPM без BPMS. Это как бухгалтерия без компьютера - теоретически возможно, в рамках обучения полезно, но в практической работе смысла не имеет.
• Самым солидным мне показался доклад Александра Башкова (менеджер бизнес-приложений компаний “Тетра Пак”). До этого я про компанию не знал ничего, кроме названия, теперь знаю - это один из лидеров в управлении бизнес-процессов в мировом масштабе. Александр очень хорошо рассказал как организовано процессное управление на уровне глобальной компании, и что особенно интересно, про кастомизацию на региональном уровне. Известно, что компании, достигшие выдающихся достижении в области управления бизнес-процессами, зачастую добровольно делятся своим опытом - я слышал такие истории про Toyota, Xerox, Motorolla. Поэтому я задал вопрос Александра после его доклада, и он подтвердил, что действительно, в их компании такое тоже практикуется. Так что если ваша компания вынашивает амбициозные планы в области BPM, я настоятельно советую попробовать обратиться к Тетра Пак за опытом. И пожалуйста напишите здесь в комментариях, что из этого вышло.

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

Аудитория производила впечатление подготовленной - и вопросы, и кулуарные разговоры были содержательными. Диссонировали, на мой взгляд, только вопросы представителя Академии при госслужбы при Президенте РФ: как-то странно на конференции по BPM спрашивать у докладчика чем BPMS отличается от Sharepoint.

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

Хорошо, что есть площадка семинаров BPMS.ru, где можно отвести душу - вдумчиво разобрать доклад, высказать свое мнение, подискутировать с грамотными коллегами. Кстати, очередной семинар состоится через неделю, регистрация, как обычно, на livents.ru.

Бизнес похож на войну, война похожа на шахматы. Конечно любая аналогия хромает, но почему бы не поиграть в аналогии для развлечения?

Бизнесмен: мы принимаем решения на основе предварительной оценки окупаемости или возврата на инвестиции (ROI).

Шахматист: конечно надо считать когда и сколько материала - пешек, фигур - ты выиграешь в результате того или иного хода. Мы тоже считаем комбинации. Только у нас партия состоит не из одних комбинаций. Бывают ходы вынужденные, когда думаешь не о том, чтобы побольше съесть чужих пешек и фигур, а о том, чтобы не съели твои. Бывают ходы, улучшающие позицию. Бывает, что жертвуют материалом, чтобы улучшить позицию  - “получить игру”. Ведь если позицию не развивать, то просто не будет возможности развернуть атакующую комбинацию и ни до какого ROI дело вообще не дойдет.

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

Бизнесмен: у нас тоже есть стратегия компании.

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

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

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

Военный: мы тоже считаем темпы операций. Классический пример: время мобилизации и развертывания в начале войны стали краеугольным камнем знаменитого плана Шлиффена немецкого Генштаба на войну, которую потом назвали Первой мировой. Загонять противника “под флажок” мы тоже умеем: наводнить его штабы противоречивой информацией и дезинформации, совершать ходы, которых он не ожидает, чтобы он не успевал переваривать информацию и в результате постараться добиться паралича управления войсками.

Бизнесмен: так, кажется я начинаю понимать что это за business agility, о которой в последнее время столько разговоров…

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

Сторонники BPM любят подчеркивать, что, в отличие от типичных ИТ-проектов, проекты BPM дают быструю финансовую отдачу. Например, по данным Gartner, которые приводит Джим Синур, половина проектов BPM демонстрируют возврат инвестиций на уровне 20% и больше. Он встречал «сумасшедшие» показатели в 220% и даже 360%, которые ему пришлось отбросить, чтобы не исказить среднее.

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

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

Рассмотрим предприятие, на котором внедрена ERP-система. Пусть даже она не охватывает планирование (напомню, «P» в ERP означает «Planning»), но управленческий учет в области финансов, отношений с контрагентами и материальных запасов налажен - судя по всему, это типичная картина. BPM вовлекает в работу в рамках сквозного бизнес-процесса не только традиционных пользователей в виде бухгалтеров и финансистов, но и менеджеров, конструкторов, снабженцев, производственников, маркетологов. Традиционная корпоративная система «пассивна»: она способна ответить почти на любой вопрос, но только если знаешь как спросить. С помощью BPM она становится активной: раздает задания исполнителям в соответствии с утвержденными схемами бизнес-процессов, контролирует сроки, инициирует эскалации и т.д. Причем все действия в рамках процесса отражаются в соответствующих объектах единой базы данных. В результате вместо «кладбища корпоративных данных» мы получаем эффективный инструмент повышения качества услуг, увеличения продаж и быстрого реагирования на изменяющиеся условия ведения бизнеса.

Как показал Э.Голдратт в своей книге «Necessary but Not Sufficient» (в русском переводе «Цель-3»), большая часть обычно декларируемой эффективности ERP –  повышение прозрачности и производительности, привлекательность для инвесторов, сокращение материальных запасов – иллюзорная. Для достижения итоговых экономических результатов корпоративная система – условие необходимое, но недостаточное. Да, ERP обладает потенциалом повышения экономической эффективности компании. Но только когда ERP дополняется BPM, этот потенциал превращается в реальность.

Далее, предположим, что внедрение ERP обошлось в один миллион, а проект BPM – в двести тысяч. Если мы признали ERP-систему необходимой, то достигнутый в итоге экономический эффект по справедливости следует отнести к суммарным понесенным затратам. А если отнести отдачу только к затратам на BPM, то мы как раз и получим те самые «сумасшедшие» 220 и 360% возврата на инвестиции. Если прибегнуть к аналогии из области телекоммуникаций, то ERP – это бэкбон, а BPM – решение для последней мили. Никому ведь, кажется, не приходит в голову улучшать показатели эффективности услуги предоставления интернета за счет игнорирования затрат на бэкбон?

И конечно полный абсурд – пытаться обойтись без бэкбона. Бывает, недобросовестный интернет-провайдер обещает клиенту подключение на скорости 10 Мбит/с, умалчивая о том, что это только скорость канала до его сети, а реальная скорость подключения клиентов к интернету в десять раз меньше. А бывает, что заказчик говорит: «Я слышал, что ERP – это уже не круто, и вообще там проблемы с окупаемостью. Вы говорите, что BPM – это такая замечательная вещь, может, мне лучше вместо ERP внедрить BPM?» Увы, «вместо» не получится, только вместе! BPM, под который не подведен фундамент в виде корпоративной информационной системы – это старый добрый документооборот: слабо структурированные данные, которые невозможно обработать, найти или извлечь в нужное время и в нужном виде.

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

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

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

Конечно, нельзя однозначно сказать какой путь лучше – внедрение единой системы от одного поставщика («single vendor») или интеграция различных систем («best of breed»). Но все же тенденция последних лет – рост популярности второго подхода. Связано это, во-первых, с совершенствованием и удешевлением технологий интеграции - ESB, MDM. А во-вторых, единая система оказывается миражом, недостижимым идеалом: как только вы наконец-то внедрили ERP, оказывается, что вам необходим CRM, система клиент-банк, ПО для мобильных сотрудников, работающее на смартфонах или, предположим, ПО для мониторинга автотранспорта через GPS+GPRS. И вы опять возвращаетесь к ситуации нескольких систем.

Выводы:

1. Экономический эффект проекта BPM определяется тем, сколько до этого предприятие потратило на создание корпоративной системы: чем больше эта сумма, тем больший возврат инвестиций может продемонстрировать BPM. Но эти цифры – лукавые, ведь вы просто отнесли львиную долю затрат на проект ERP, а большую часть полученного роста доходов и сокращения издержек – на проект BPM.
2. Чтобы реально повысить отдачу от инвестиций, надо рассматривать не отдельные проекты ERP или BPM, а вложения в совершенствование управления или, если хотите, в трансформацию бизнеса. Прочность цепи определяется прочностью слабейшего звена: если вкладывать только в ERP, то вы получите информационный бэкбон, не дотягивающийся до потребителей. А если вкладывать только в BPM, то первые успехи сменятся разочарованием, когда информационные потоки от бизнес-пользователей упрутся в неэффективную корпоративную систему.

Учтите, что слабым звеном могут быть не технологии, а люди. Толку от внедрения самых совершенных систем не будет, если сотрудники не готовы творчески пересматривать то, как они работают. Много ли у вас в компании сертифицированных специалистов по теории ограничений (Theory of Constraints), бережливому производству (Lean) и шести сигмам (Six Sigma)? Движущей силой внедрения системы управления бизнес-процессов и корпоративных информационных систем могут быть только хорошо мотивированные и подготовленные специалисты. Причем не только ИТ-специалисты, но и специалисты по современным методам управления. А что, в свою очередь, приводит в движение этих людей? Очевидно, высшее руководство компании.