Все о системах управления бизнес-процессами
 
Почитать
Поговорить
Побродить
Завершить


Вход в систему

Забыли пароль?


     
BPM в действии

Литература:

Анатолий Белайчук, Юлия Вагнер

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

О необходимости практических упражнений

Процессное управление, как способ радикального повышения конкурентоспособности бизнеса в современной, ориентированной на клиента экономике, в последнее время завоевывает все больше сторонников. Сама идея процессного управления не нова — всплеск интереса обусловлен появлением нового инструментария и методологии под названием BPM, Business Process Management (см. врезку «Новое оружие бизнеса»).

Принципы, на которых построены BPM-системы, сильно отличаются от традиционных представлений о разработке программных продуктов (см. врезку «Что умеют BPM-системы»). Это вызывает споры между специалистами, живые дискуссии в прессе и на форумах в интернете. И камнем преткновения в этих обсуждениях часто является отсутствие примеров реальных процессов. Большинство статей ограничиваются теорией либо приводят схемы абстрактных процессов. Этим недостатком, увы, страдает и наша предыдущая статья [EX06].

Складывается впечатление, что практика BPM у нас в стране отсутствует вовсе. На самом деле это не так — положительные примеры автоматизации бизнес-процессов есть. Просто компании, у которых таковые имеются, не стремятся сделать их достоянием широких масс. И это объяснимо: ведь бизнес-процессы предприятия — это закрытая информация, ноу-хау; то, что позволяет получить конкурентное преимущество.

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

В чем заключается бизнес

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

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

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

Поставщик (наша компания) принимает заказ и размещает у Производителя программного обеспечения — американской компании. (Чтобы не создалось ложного впечатления: поставка программного обеспечения — это только часть деятельности дистрибьютора; просто все остальное — консалтинг, техническую поддержку, обучение — мы оставляем «за кадром».)

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

С точки зрения BPM эта картина интерпретируется следующим образом:

  • рамочный трехсторонний договор соответствует шаблону бизнес-процесса
  • спецификация соответствует экземпляру бизнес-процесса

Итак, рассмотрим бизнес-процесс под названием «Рамочный договор покупки».

Проблемы и возможности

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

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

Люди искушенные знают, что «экскаватор всегда где-то рядом», и поэтому поиск инноваций становится у них навязчивой идеей (как сказал глава Интел Энди Гроув, «выживают только параноики»). BPM — это и есть такой «экскаватор»: раз увидев его в деле, не понимаешь, как ты до сих пор мог работать по-другому. У нас такой опыт был, поэтому мы отчетливо видели и свои проблемы, и связанные с ними возможности.

Стандартная рекомендация тем, кто задумался о внедрении BPM — найдите для пилотного проекта бизнес-процесс, который явно плохо управляется. Симптомом этого может быть, например, постоянные «разборки» между подразделениями и их руководителями на планерках и собраниях.

Но в нашем случае говорить о том, что процесс управлялся плохо, не приходилось; скорее он управлялся слишком дорого. Специфика рассматриваемого процесса:

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

В результате получаем набор противоречий:

  • Поручить процесс низкооплачиваемым сотрудникам невозможно из-за наличия сложных шагов (п.3) и высокой ответственности (п.5).
  • Держать выделенных квалифицированных исполнителей слишком дорого, принимая во внимание неравномерность процесса (п.4).
  • Если привлекать квалифицированных специалистов время от времени, то из-за сложности процесса (п.1) и из-за того, что они неоднократно будут отвлекаться на другие дела за время его исполнения (п.2), появится риск потери контроля, что недопустимо (п.5).

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

Кликните для увеличения

Цели проекта BPM

Чего мы хотели добиться, начав управлять процессом при помощи BPM:

  1. Гарантировать автоматическую передачу заданий между исполнителями по мере прохождения процесса, избавить их от необходимости держать в голове последовательность шагов.
  2. Повысить взаимозаменяемость исполнителей и облегчить обучение новых сотрудников.
  3. Обеспечить автоматический контроль за сроками исполнения процесса, расставив контрольные точки и организовав автоматическое уведомление руководства в случае задержки.
  4. Дать руководителям средства самостоятельного мониторинга процесса — с собственного компьютера, а не задавая вопросы исполнителям по телефону или на планерке.

Бизнес-процесс в подробностях

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

Рисунок 1. Схема бизнес-процесса "Рамочный договор покупки"

(Условные обозначения и термины см. во врезке «Пояснения к используемому инструментарию».)

Участники процесса:

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

Весь процесс по-крупному разбивается на четыре этапа:

  1. «Прием и обработка заказа»
  2. «Согласование спецификации»
  3. «Отгрузка товара»
  4. «Расчеты»

Прием и обработка заказа

Старт процесса

Бизнес-процесс начинается с того, что представитель филиала Покупателя обращается к нам с запросом о приобретении программного продукта. Запросы могут поступать по факсу, электронной почте или телефонному звонку — их, как и все входящие, принимает Секретариат.

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

Заявка на приобретение

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

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

Достигнутые договоренности исполнитель фиксирует в системе через следующую веб-форму:

Кликните для увеличения

Рисунок 2. Экранная форма согласования условий заказа

Нажав на кнопку «СОГЛАСОВАНО», исполнитель активизирует следующий шаг процесса. Если договоренности достичь не удалось («НЕ СОГЛАСОВАНО»), процесс завершается.

Согласование спецификации

Формальная спецификация, составленная в соответствии с достигнутыми коммерческими договоренностями, подписывается всеми сторонами. Менеджер по дистрибуции согласовывает спецификацию с Производителем, а Аккаунт-менеджер — с головным офисом Покупателя.

Согласование Спецификации выделено в подпроцесс:

Рисунок 3. Подпроцесс "Согласование спецификации"

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

Этот подпроцесс иллюстрирует два преимущества работы с BPM-системой:

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

Как видно из схемы, у подпроцесса два варианта выхода: «Продолжить» и «Не подписано». В зависимости от того, как завершился подпроцесс, основной процесс (рис. 1) либо продолжается по стрелке "Продолжить", либо прекращается.

Отгрузка товара

Размещение заказа

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

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

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


В частности, полученный от Производителя счет будет ожидать поступления денег от Покупателя, после чего активизируется шаг «Платеж производителю»

Подготовка товара к отгрузке

Подготовка товара также выделена в отдельный подпроцесс:

Кликните для увеличения

Рисунок 4. Подпроцесс "Подготовка товара к отгрузке"

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

Отгрузка

Система переходит к этому шагу после завершения подготовки к отгрузке товара и сопроводительных документов. На рис. 1 видно, как стрелки из этих шагов сходятся к условию «AND». В этот момент происходит передача ответственности между службами. Обычно это чревато задержками, поиском ответственного, документов и т.п. — использование BPMS подобные проблемы полностью исключает.

Расчеты

Производятся платежи и подводятся итоги сделки, при этом процесс дважды распараллеливается и затем сходится (рис. 1). Процесс завершается закрытием сделки. На этот момент реквизиты процесса содержат полную информацию о сделке. Эта информация попадает в архив, где ее можно просматривать и анализировать.

BPM-система хранит всю информацию о текущих и завершенных процессах в обычной реляционной базе данных. (Как правило, BPM-системы дают возможность выбирать среди реляционных СУБД ведущих поставщиков.) Эта база данных накапливает ценную статистику: время, затрачиваемое на выполнение процесса, нагрузка на исполнителей, объем сделок в денежном измерении и в различных разрезах, например по филиалам Покупателя.

Анализ этих данных — предмет отдельной методологии BAM (Business Activity Monitoring), которую мы здесь рассматривать не будем. Заметим только, что от данных о выполнении бизнес-процессов через систему ключевых показателей (KPI, Key Performance Indicator) можно перебросить мостик к системе сбалансированных показателей (BSC, Balanced Scorecard).

Управление бизнес-процессом или его автоматизация?

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

Преобладающее мнение аналитиков: путь «от бизнеса» правильнее, но по факту чаще практикуется подход «от ИТ» [BPM20]. В результате в проектах BPM зачастую преувеличивается значение автоматизации в ущерб управлению.

Типичная картина: качеству пользовательского интерфейса к шагам бизнес-процесса и интеграции процесса с существующими системами придается значение большее, чем срокам разработки. При этом зачастую не осознается тот факт, что работоспособную схему бизнес-процесса на практике невозможно разработать ни с первой, ни со второй итерации. По оценкам аналитиков, для того чтобы достаточно точно смоделировать существующий («as-is») бизнес-процесс, команде, не обладающей опытом, обычно требуется от 8 до 12 итераций; по мере накопления опыта число итераций снижается до 3-4 [GA05]. Не говоря уже об оптимизации бизнес-процесса. Наш собственный опыт подтверждает правильность этих оценок.

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

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

Оптимальный баланс между управлением и автоматизацией зависит от конкретики бизнес-процесса.

В нашем случае внедрение BPM шло «от бизнеса», и сформулированные выше цели относятся к управлению бизнес-процессом. Рассмотрим теперь актуальность для данного процесса задач автоматизации:

  • Автоматизация документооборота.

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

  • Автоматизация подготовки документов.

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

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

  • Интеграция с автоматизированными системами.

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

Например, на шаге «Документы на отгрузку» сотрудник финансовой службы должен зарегистрировать накладную, счет, счет-фактуру в бэкофисной учетной системе. Мы могли бы разработать композитное приложение, которое возьмет уже существующие данные из контекста бизнес-процесса, дополнит их данными, введенными пользователем с экрана, и через программный интерфейс сохранит данные в учетной системе.

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

  • Интеграция с контрагентами.

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

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

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

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

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

Оцениваем результаты

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

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

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

Это не фотография, это кино

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

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

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

Но ведь и пользователь не виноват: не может он, в силу объективных причин, выполнить такие условия. Просто бизнес сегодня меняется слишком быстро. Слияния, поглощения, изменения стратегии — например, вы внедряете ERP-систему, и за время проекта несколько раз меняется генеральный директор. Повлияет это на требования к системе? Еще бы!

А конкуренты с Запада и Востока, мгновенно меняющие правила игры на рынке, а новые схемы бизнес-партнерства (вспомним хотя бы аутсорсинг) и экзотические управленческие методологии — TQM, Six Sigma, Lean Manufacturing и многие, многие другие, причем любая из них может быть «спущена сверху» прямо завтра! И в этих условиях вы требуете от менеджеров «зафиксировать требования»? Полноте, вы наверное шутите.

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

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

Роскошь индивидуального подхода

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

Если решать задачу автоматизации такой компании традиционными методами, то пытаться рассматривать все возможные комбинации даже не придет в голову — такая задача была бы явно неподъемной. Поэтому отдел ИТ, комбинируя готовые решения и собственные разработки, создает некую «усредненную» систему, предоставляющую общую для всех процессов функциональность. Детали же и особенности процедур взаимодействия с конкретными производителями или работы конкретных каналов продаж — только в головах менеджеров по продажам и менеджеров по продуктам.

«Легковесный», на взгляд некоторых, подход BPM позволяет разрабатывать для взаимодействия с каждым поставщиком и заказчиком индивидуальное решение, и это не может не сказаться благотворно на бизнесе. В связи с этим на ум приходит старый афоризм: «В жизни надо делать только то, что дается легко. Но делать это надо изо всех сил!»

Собственная и внешняя разработка

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

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

  • Нижний уровень — уровень бизнес-функций. Они относительно устойчивы (меняются не слишком часто) и универсальны (применимы в различных моделях бизнеса). А следовательно, реализующие их программы могут тиражироваться, что делает экономически оправданным разработку их «на стороне», независимыми поставщиками программного обеспечения.
  • Верхний уровень — уровень бизнес-процессов. Здесь, напротив, высока изменчивость и много специфики конкретного предприятия. Менять бизнес-процессы, находя лучшие решения в условиях изменяющегося мира, надо постоянно, а следовательно — собственными силами. Внешних консультантов экономически целесообразно привлекать для разового большого усилия, здесь же речь идет о постоянной и планомерной работе, для которой надо наращивать собственную компетенцию и иметь собственные ресурсы.
  • Эти два уровня связаны между собой сервис-ориентированной архитектурой (SOA) и промежуточным программным обеспечением, таким как ESB (Enterprise Service Bus).

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

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

Синтез смежных технологий

Иногда можно услышать мнение: «BPM — это тот же документооборот». Или: «это все затеяно ради измерения показателей эффективности». На самом деле в BPM соединились предшествующие достижения в нескольких областях:

  • моделирование и реинжиниринг бизнес-процессов (BPM — Business Process Modelling, BPR — Business Process Reingeneering)
  • электронный документооборот (Electronic Workflow)
  • интеграция корпоративных приложений (EAI — Enterprise Appications Integration)
  • мониторинг эффективности бизнеса (BPM — Business Performance Management, BI — Business Intelligence, BSC — Balanced ScoreCard)

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

Итоги

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

  • В процессах, протекающих с высокой интенсивностью (сделки заключаются часто) по каждой сделке необходимо все сделать вовремя и в полном объеме. Постоянный риск того, что в запарке будут нарушены сроки или другие условия договора.
  • В нерегулярных процессах (сделки совершаются редко) необходимо помнить все детали, для этого постоянно приходится обращаться к договору. Большие трудозатраты, высока вероятность накладок.
  • Менеджер, отвечающий за работу с конкретным контрагентом, в любой момент может заболеть или уволиться. Тому, кто его заменит, необходимо в деталях освоить специфичный для этого партнера формат взаимодействий. Затраты времени и денег на обучение, на начальном этапе высока вероятность ошибки.


Второй результат — уменьшение непроизводительных трат рабочего и календарного времени:

  • Не нужно тратить время на написание должностных инструкций, на обучение менеджеров, а самим менеджерам — на «проталкивание» процесса. Задание, которое получает исполнитель, максимально конкретизировано:
    • данные из предыдущих шагов
    • реквизиты, которые надо заполнить
    • страничка текстовых инструкций
    • варианты продолжения процесса, материализованные в кнопках на веб-странице
  • Задания больше не «вылеживаются» на столах у исполнителей. С точки зрения исполнителя, задания приходят к нему неизвестно откуда и неизвестно куда уходят после того, как он нажал на кнопку продолжения процесса. Маршрут известен движку BPM-системы и бизнес-аналитику, нарисовавшему схему бизнес-процесса — эта роль вполне по плечу, например, исполнительному директору.

И наконец, результаты стратегические:

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

Литература

[EX06] Анатолий Белайчук. “Зачет по BPM”. Открытые системы. #1/2006.

[BPM20] Bruce Silver. “Make Way for BPM 2.0”. BPMInstitute.org. 2006.

[GA05] Michael James Melenovsky. “Business Process Management's Success Hinges on Business-Led Initiatives”. Gartner, Inc. 2005.

Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права | Версия для печати