Интересуетесь BPM? Свободны вечером в среду 7 октября? Приходите обсудить за чашкой кофе очередной BPM-проект. Регистрация тут.

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

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

Вроде очевидно? Не будем торопиться с выводами.

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

И вот яркое выступление на TED Video, объясняющее эту загадку: “Dan Pink on the surprising science of motivation“.

Конспективно:

Дэн начинает с описания несложной задачи, требующей, тем не менее, определенной изобретательности,- “the candle problem”. Экспериментаторы взяли две группы людей, предложили каждому решить эту задачу и измерили время, которое они потратили. При этом люди из одной группы решали задачу “за так”, а во второй группе пообещали денежную премию тем, кто окажется в числе 25% лучших по скорости.

Как вы думаете, насколько более успешной оказалась вторая группа? Ответ: если в нормальных условиях люди решают задачу за 5-7 минут, то при наличии материального стимулирования они тратят на нее на 3.5 минуты больше.

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

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

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

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

Итак, понятно чего делать не надо: надо перестать следовать управленческим стереотипам, сложившемся в XX веке с его массовым производством. Они не применимым к любой деятельности, в которой наличествует хотя бы минимальная творческая составляющая. А что тогда надо делать? Заметим, что до сих пор речь шла исключительно о материальном стимулировании - то есть о деньгах. Стимулирование никто не отменяет, но вместо внешней мотивации кнутом и пряником необходимо включить внутренние мотиваторы:

1. Самостоятельность (autonomy): стремление человека самому распоряжаться собой - нечто прямо противоположное идее менеджмента. Пример: сотрудники Google имеют право 20% своего времени заниматься чем пожелают. Результат: примерно половина новых продуктов рождаются именно в эти 20% времени, которым сотрудники могут распоряжаться самостоятельно.

2. Мастерство (mastery): стремление человека постоянно совершенствоваться в чем-то, что для него важно.

3. Предназначение (purpose): стремление человека тем, что он делает, служить чему-то большему, чем он сам.

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

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

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

И еще одна ассоциация, которая у меня возникла - с рассуждениями Голратта на тему себестоимости. Он справедливо замечает, что вся современная методика учета затрат и само понятие себестоимости идет с начала XX века, массового производства и преимущественно сдельной оплаты труда. В тех условиях непропорциональные затраты составляли примерно 20% и поэтому их можно было рассматривать как накладные расходы и распределять их пропорционально прямым трудозатратам.

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

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

Хотя единого общепринятого определения BPM пока не выработано, большинство специалистов согласны с тем, что BPM – это сочетание управленческой методологии и софтверного инструментария. Однако что есть методология BPM и есть ли у BPM своя собственная методология?

Для начала зададимся вопросом: какие методологии в области управления бизнес-процессами на сегодняшний день завоевали себе место под солнцем?

• Среди консультантов и людей бизнеса более всего на слуху Lean Six Sigma – продукт синтеза методологий Lean и Six Sigma.
• Lean – это методология бизнес-трансформации, выросшая из TPS (Toyota Production System – Производственная система Тойоты). Ее ключевые идеи – увеличение ценности для заказчика за счет сокращения всех видов потерь и повышения равномерности производственных и бизнес-процессов.
• Six Sigma (Шесть Сигм) – методология, разработанная в компании Моторолла и нацеленная на повышение ценности для заказчика за счет уменьшения дефектов и вариаций производственных и бизнес-процессов на основе использования строгих методов математической статистики.
• TOC (Theory of Constraints, Теория ограничений) рассматривает бизнес как систему взаимозависимых по входам-выходам процессов. Ключевая идея здесь сводится к тому, что производительность цепочки процессов равняется производительности самого медленного его звена, и методология в основном рассматривает следующие из этого выводы. Хотя эта методология уже по охвату, она привносит оригинальные и ценные с практической точки зрения идеи, поэтому неудивительно, что они завоевали широкое признание, в том числе в рамках Lean Six Sigma.
• Еще можно вспомнить получившую широкую известность TQM (Total Quality Management). Но эта методология уже стала частью истории, хотя основные ее идеи можно найти в тех же Lean и Six Sigma, а также в стандартах качества серии ISO 9000.

Плюс к этому отдельные компании и аналитики продвигают собственные, иногда достаточно интересные методологии. Но пожалуй только TQM, Lean, Six Sigma и TOC достигли уровня мэйнстрима, т.е. вокруг них оформились сообщества, по ним написано много книг, доступны учебные курсы. А с учетом того, что эти мейнстримовые методологии в значительной степени пересекаются между собой (а Lean и Six Sigma вообще сливаются в единое целое), мы вряд ли увидим, что какая-то новая методология внезапно завоюет всеобщее признание.

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

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

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

Какие практические выводы из этого следуют для компании, задумывающейся о реализации программы BPM?

1. Позаботьтесь о технологической и методологической составляющих вашего проекта. В части технологии вы должны определиться с BPMS, выработать соглашения по стилю моделирования бизнес-процессов, утвердить стандартный жизненный цикл бизнес-процесса. Аналогичным образом, в области методологии вы должны знать, например, по каким принципам, в рамках какой процедуры и кто конкретно выбирает процесс для очередного проекта в рамках программы BPM. Как фиксируются метрики процесса до начала проекта и как контролируется достижение целевых показателей по его окончании? Кто обеспечивает видимость процессов и возможность их повторного использования другими процессами? Кто отвечает за то, чтобы разрабатываемые процессы не оставались разрозненными островками субоптимизации, а соединялись в единую цепочку создания ценности?
2. Обопритесь на готовую BPMS и готовую методологию. Разработка собственной методологии, как и разработка собственной BPMS, уведет вас слишком далеко от конечных целей проекта – повышения эффективности вашего бизнеса. Не забывайте, что, как показывает история, разработка собственной оригинальной методологии под силам только таким гигантам, как Тойота (Lean), Моторолла (Six Sigma) или Ксерокс (TQM). Встаньте на плечи этих гигантов – потратьте время на литературу и учебные курсы, наймите консультантов с опытом внедрения процессного управления с использованием BPM. Причем этот совет ни в коем случае не означает призыва отказаться от творческого начала и слепо копировать чужой опыт. Ведь все методологии излагают только общие принципы и оставляют более чем достаточно места для адаптации их к условиям вашего конкретного бизнеса. И все они подчеркивают важность накопления собственной, а не приобретения чужой компетенции. Так что вам понадобятся талантливые и мотивированные личности, начиная с собственников и руководителей верхнего уровня компании, и у вас будет достаточно задач, адекватных их амбициям.

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

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

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

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

Альтернативное название: “Микроменеджмент”.

Типичное затруднение первого BPM-проекта: “на какую глубину копать”, до какого уровня детализировать бизнес-процесс?

В одном из первых наших первых проектов мы занимались процессом под названием “Заказ по трехстороннему договору”. Суть дела:

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

По-крупному процесс состоял из четырех этапов:

1. согласование заказа
2. подписание заказа
3. поставка товара
4. оплата и закрытие заказа

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

В первом приближении схема процесса выглядела так:

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

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

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

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

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

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

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

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

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

По регламенту. Если время вышло, а докладчик закругляться не собирается, то председатель должен прервать его словами: “отведенное регламентом время закончилось, сколько еще вам надо?” и, получив ответ, обратиться уже к аудитории: “ну как, дадим?”. Это способствует атмосфере взаимного уважения.

Переходя к существу доклада - нам был представлен уникальный, без преувеличения, опыт тотального внедрения процессного управления (и процессного мышления) в компании численностью 700 человек. К тому же мы получили “два доклада в одном”: помимо основной темы использования Runa WFE нам рассказали про реализацию управление бизнес-процессов средствами 1С. Сравнение получилось интересным и поучительным.

Закрытость корпоративных систем ставит перед тяжелым выбором: либо использовать встроенные в них средства workflow и бороться с их ограничениями, либо использовать внешние BPMS и бороться с проблемами интеграции. Компания Руна сделала выбор оригинально: взяла на вооружение и то, и другое. В принципе, наверное, это правильно. Было бы совсем здорово, если бы они навели мосты между внешней и внутренней BPMS. Может быть, это сделать проще, чем интегрировать внешнюю BPMS на уровне функций?

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

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

Осталось у меня и несколько вопросов по докладу:

1. Использование Runa WFE с jBPM и вообще технологическим стеком jBOSS. Особенно с учетом того, что выходит 4-я версия jBPM, которая мне представляется весьма интересной. В частности, в ней jBPM переходит к нотации, близкой к BPMN.
2. Привязка к бумажным документам. Непонятно почему нельзя обойтись без них, непонятно даже - рассматривалась ли вообще безбумажная альтернатива. Вместо того, чтобы гонять в процессе бумажные документы, можно было собирать структурированную информацию, передавать электронные задания, а бумаги печатать на основе собранных данных только там, где это абсолютно необходимо (например, командировочное удостоверение, с которым сотрудник поедет  в чужую организацию). Но зачем в виде документов нужны заявление на отпуск или авансовый отчет - я не понимаю. Вроде мы рассматривали не колхоз “сорок лет без урожая”, а прогрессивную организацию! Естественно, в результате возникла масса проблем - ну не рассчитаны BPMS на такую работу.
3. Докладчик упомянул, что в какой-то момент возникли проблемы с масштабированием, которые были успешно решены. Хотелось бы получить подробности, но понятно, что все рассказывать в подробностях - никакого регламента не хватит.

Еще возник вопрос философского плана, не столько к докладчику, сколько к самому себе: нет ли связи между отмеченной неохотой расширять использование системы и ее “бесплатностью”? (Runa WFE - Open Source разработка.) Что дешево достается, то ровно настолько же и ценится.

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

Очередной семинар BPMS.ru пройдет в среду 24 июня; время и место прежние. Андрей Михеев расскажет про практические применения своего детища Runa WFE.

Регистрация была организована через livents.ru, но он лежит уже больше недели (кстати, кто-нибудь знает что с ним?), записывайтесь через контактный адрес на bpms.ru.

Обращаю внимание почтеннейшей публики, что 8 июля, т.е. всего через две недели, мы проведем еще один семинар, чтобы потом сделать длинную паузу до осени (скорее всего до октября).

Не могу удержаться и не утащить к себе на память цитату из: Madhav N. Sinha, “Winning back angry customers”, Quality Progress, American Society for Quality Control, November 1993. Отдельные пункты из этого списка цитируются часто, но в полном виде он производит гораздо более сильное впечатление.

1. Потребитель, недовольный продукцией или услугами, в среднем сообщает об этом 9-10 другим людям. В то же время, если жалоба должным образом удовлетворена и фирма разрешила возникшую у него проблему, то он информирует об этом только 5 человек.
2. На 1 зафиксированную жалобу приходится 19 неудовлетворенных потребителей, которые предпочли не обращаться с жалобой.
3. Привлечение нового потребителя обходится в 5-10 раз дороже удержания существующего.
4. Для преодоления у потребителя негативного впечатления от 1 случая требуется 12 позитивных.
5. Большинство компаний тратят 95% времени на устранение последствий возникших проблем, и всего лишь 5% на поиск причин.
6. Предпринимая попытку рассмотрения жалоб потребителя, более чем в 50% случаев компания только усиливает негативное впечатление о себе.

Конечно уместны вопросы о представительности статистики и о применимости ее к тому или иному рынку. Надо думать, за прошедшие 15 лет потребители стали еще более требовательными (если угодно - капризными), более информированными (в том числе благодаря Интернету) и менее склонными сносить плохой сервис. Если что и позволяет компаниям в некоторых случаях пренебрегать качеством сервиса, так это то, что “у других еще хуже”. Ну или локальная монополия.

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

Тут как в прыжках с шестом - выгоднее 10 раз улучшать мировой рекорд по 1 сантиметру, чем один раз сразу на 10. В идеале надо иметь программу таких улучшений, т.е. просчитывать на несколько ходов вперед и отслеживать шаги конкурентов. А вывод из приведенной выше статистики заключается в том, что поле для такой игры есть!

Новый пост на блоге Джима Синура: “Business Process Management Grows Value While Saving Costs“. Он говорит как здорово убивать двух зайцев одним выстрелом:

1. BPM уменьшает затраты

2. BPM увеличивает доходы

Идея не нова, но Джим еще приводит некоторые конкретные аргументы, благодаря которым заметку стоит прочесть.

Однако, при всем моем к нему уважении, осмелюсь заявить, что этот список не полон - в нем не хватает:

3. BPM ускоряет реакцию

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

Вообще говоря, есть три способа конкурировать:

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

2. Следом приходят те, кто обеспечивает лучшее качество.

3. И наконец, когда ни концепеция, ни качественное производство больше не являются секретом, все начинает решать стоимость.

Обратите внимание: второй список соответствует первому, если его расположить в обратном порядке!

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

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

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

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

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

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