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

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

Так что если хотите принять участие в профессиональном разговоре на тему BPM - регистрируйтесь и приходите.

Этот контент доступен на языках: English.

Нынешний финансовый кризис отрасли BPM не угрожает: ведь чтобы был кризис, надо чтобы сначала был бум, а у BPM его не было.

Этот бум призывали, называя BPM “The Next Big Thing”. Кто-то сделал на ожидание бума серьезные ставки - я имею в виду в первую очередь независимых разработчиков BPMS (”pure-plays”). Хотя и поставщики ПО широкого профиля (”stack vendors”) тоже врядли удовлетворены финансовыми результатами приобретения BPM-активов.

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

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