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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как в различных реализациях BPMN выглядит шаг процесса, выполняемый людьми? Чисто для иллюстрации возьмем процесс “От обращения до заказа” (Inquiry to Order) с шагами “Сделай это” (Do This, системный), “Согласуй договор” (Negotiate Contract, человеческий), “Сделай то” (Do That, системный) и смоделируем при помощи нескольких популярных инструментов.

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

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

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

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

Такое асинхронное взаимодействие процессов подразумевает наличие между ними буферов, в которых накапливаются задания, передаваемые от процесса-заказчика к процессу-исполнителю. В рассматриваемом примере это “Производственные заказы” и “Плановые остатки сырья и комплектующих”. Технически буфер может реализовываться по-разному: очередью сообщений, записями таблицы базы данных или объектами ERP-системы, находящимися в определенном состоянии. Естественно, внутреннее устройство буфера желательно скрыть, создав сервисы для работы с ним - добавления, просмотра, извлечения.

Современные BPMS позволяют и моделировать, и исполнять подобные схемы, и в этом их коренное преимущество перед традиционными workflow-системами. Другое дело, что аналитики осваивают такие схемы с большим трудом - см. например Bruce Silver, “BPMN to Requester: Get Outta My Pool”. Основная сложность тут не в нотации, а в развитии “асинхронного мышления”. Вы должны научиться вычленять из того, что бизнес преподносит вам как единый процесс, отдельные асинхронные процессы. Помогают разобраться в этом ответы на два вопроса: 1) с каким бизнес-объектом связан экземпляр процесса и 2) с какими событиями связаны начало и завершение экземпляра процесса.

Например, даже в таком относительно простом процессе, как прием сотрудника на работу, мы видим набор бизнес-объектов: 1) позицию штатного расписания, 2) заявку руководителя в кадровую службу о необходимости замещения вакантной позиции штатного расписания, 3) вакансию, объявленную по определенному каналу поиска кандидатов, 4) кандидат, 5) принятый сотрудник. Связаны они между собой не как 1:1, и их жизненные циклы не синхронны. Например, кандидаты присылают резюме, не заботясь о том, если ли у предприятия для них вакансия - дело кадровой службы оценить для какой вакансии (каких вакансий) его стоит рассматривать. Поэтому одним процессом вам врядли удастся обойтись; сколько их получится в итоге - зависит от конкретики вашего бизнеса.

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

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

Как-то сидя на лекции Переслегина и слушая его пророчества - апокалиптические, но все же при этом каким-то непонятным образом оптимистические - задал себе вопрос, который теперь меня не отпускает: а что по-крупному даст наша отрасль в обозримом будущем? Скажем, в ближайшие 10-20 лет (ближе загадывать неинтересно, дальше - бесполезно)? ”По-крупному” - имеется в виду такого, что бы всерьез изменило нашу жизнь.

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

1. Мобильные телефоны - бесспорно. Как мы раньше без них встречи назначали? А если еще в незнакомом месте - вообще мрак.
2. Интернет: паутина, почта, социальные сети, дистанционное обучение и т.д. (Или интернет на первом месте? Ладно, неважно.)
3. Компьютерное проектирование, станки с ЧПУ, роботизированное производство. Где-нибудь еще пользуются кульманами?
4. Бухгатерские программы - пожалуй, тот объем работы, который они сейчас делают, люди вручную уже и не осилят.
5. Компьютерные игры. Изменили сознание уже не одному поколению - засчитываем однозначно.
6. Навигатор в кармане - с натяжкой. Это скорее все же космос, чем компьютер.
7. Всяческие базы данных, хранилища нужных и ненужных документов? Опять-таки с натяжкой. Иногда кажется, что можно было бы и без них обойтись.
8. Глобальные финансы, биржи и т.п. Неочевидно. Ну да, по компьютерным проводам быстрее чем по телеграфу, но так ли это принципиально?
9. Автоматический перевод. Уже практически состоялся. Литературного перевода от компьютера ждать не надо, но уже сейчас американцы читают русские или китайские сайты и понимают что там написано.
10. Вещи в быту незаметные, но которые не стоит недооценивать: оружие. Хотя вояки на удивление мало взяли от ИТ. Системы наведения, криптография, “эшелоны” всякие… и все, что ли?

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

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

1. Машина времени

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

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

Кстати, можно совместить одно с другим: представьте себе тысячи добровольных Шерок-Холмсов, сидящих дома и выслеживающих, скажем, угонщика машины. Опять-таки, нечто подобное уже делается: в Штатах гражданам предложили стать виртуальными рейнджерами - следить за мексиканской границей со своего компьютера и докладывать властям о нарушениях. Желающих будет более чем достаточно. А что - все лучше, чем шпионить за соседями в окошко.

2. Всеобщая идентификация

RFID уже проникают в нашу жизнь, а в перспективе - каждая тряпка что на нас надета, каждая мелочевка на нашем столе будет способна ответить: “это я!”. (Читали у Лема: “это мы, опилки!”?) А если теперь это совместить с глобальными сетями, базами данных и односторонней машиной времени - вот тут-то матрица нас поимеет по полной!

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

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

3. Распознавание речи

Реально полезная вещь, и вроде уже решение близко. А то записывать научились, но ведь прослушивать записи - это мучение, а расшифровывать - еще хуже. Вот у нас в институте лекции по матану читал Кудрявцев - один-в-один по своему учебнику. Ну и смысл ходить на лекции? Я быстро понял, что учебник читаю раз в 5 быстрее.

Вот сейчас сижу, стучу по клавиатуре, наживаю себе артроз. Нафига, спрашивается? Лучше бы я сидя в массажном кресле надиктовал, а потом поправил текст в редакторе.

Конечно, в результате, как сейчас молодое поколение (да и не только они) предпочитает аудиокниги, так следующее разучится уже и писать. Но зато риторика расцветет, и люди снова научатся говорить.

4. Смерть шахмат

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

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

Определение:

• Процессом масштаба предприятия (”enterprise process”) или, что то же самое, сквозным (”end-to-end process”) называется бизнес-процесс, замкнутый по входу и выходу на внешнего заказчика и проходящий через более чем одно подразделение верхнего уровня.

Аксиома:

• Инициатива BPM окупится только если вы беретесь за сквозные процессы.

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

Типичные ошибки:

1. BPM-вендоры любят иллюстрировать возможности своих продуктов на вспомогательных процессах типа “Прием на работу” или “Отчет о командировочных расходах” и тем самым провоцируют заказчиков заниматься тем же самым. Для тренировки сгодится, но за подобными процессами просто слишком мало денег, чтобы оправдать затраты на проект масштаба компании. А иным проект BPM не может быть по определению.
2. Половина потенциальных клиентов предлагает заняться процессом “Заключение договора”. Тут с ценой вопроса все в порядке, но это, как бы сказать, не вполне процесс. Правильнее рассматривать его как фрагмент сквозного процесса “Продажа товара/услуги”. Ведь заказчика интересует конечный результат, т.е. показатели процесса в целом, и не факт, что именно этот фрагмент процесса критичен. (Такое сужение “рамки” и называется субоптимизацией.)
3. И совсем тяжелый случай: “Вот у нас тут есть процесс, мы его хорошо знаем и уже автоматизировали, давайте для сравнения сделаем его в BPM.” То есть давайте устроим соревнование лучшего с хорошим. Если вы хотите, чтобы ваш проект оценило руководство, вы обязаны не просто реализовать какой-то процесс в BPM, но добиться в результате этого существенного улучшения его показателей. Врядли вы этого добьетесь на процессе, с которым уже основательно поработали.

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

Применительно к позаказному производству, процесс ”От заказа до оплаты” укрупнено может состоять из подпроцессов получения аванса, производства, отгрузки, расчетов:

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

Но бизнес не работает по принципу “раз-два-три”!

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

Технически такая схема работы реализуется не одним синхронным, как на приведенной диаграмме, а несколькими асинхронно исполняемыми процессами, которые обмениваются друг с другом данными и/или сообщениями. Такую схему можно нарисовать в BPMN и исполнить средствами BPMS, и на мой взгляд, это - коренное преимущество BPMS от традиционных систем workflow. Но подробнее о правильной схеме - в следующий раз, а пока замечу, что асинхронность характерна не только для рассматриваемого, а вообще для сквозных бизнес-процессов.

Определения:

• Последовательность и логика выполнения задач в рамках одного процесса называется оркестровкой (”process orchestration”).
• Логика асинхронного, координируемого при помощи сообщений выполнения нескольких процессов называется хореографией (”process choreography”).

Теорема:

• Сквозные бизнес-процессы моделируются хореографией, а не оркестровкой.

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

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