![]() ![]()
![]()
![]()
![]() ![]()
|
|||||||||
|
|||||||||
Литература: Анатолий Белайчук, Юлия Вагнер В статье в деталях рассматривается BPM-реализация бизнес-процесса компании-дистрибьютора программного обеспечения и обсуждаются полученные результаты. О необходимости практических упражненийПроцессное управление, как способ радикального повышения конкурентоспособности бизнеса в современной, ориентированной на клиента экономике, в последнее время завоевывает все больше сторонников. Сама идея процессного управления не нова — всплеск интереса обусловлен появлением нового инструментария и методологии под названием BPM, Business Process Management (см. врезку «Новое оружие бизнеса»). Принципы, на которых построены BPM-системы, сильно отличаются от традиционных представлений о разработке программных продуктов (см. врезку «Что умеют BPM-системы»). Это вызывает споры между специалистами, живые дискуссии в прессе и на форумах в интернете. И камнем преткновения в этих обсуждениях часто является отсутствие примеров реальных процессов. Большинство статей ограничиваются теорией либо приводят схемы абстрактных процессов. Этим недостатком, увы, страдает и наша предыдущая статья [EX06]. Складывается впечатление, что практика BPM у нас в стране отсутствует вовсе. На самом деле это не так — положительные примеры автоматизации бизнес-процессов есть. Просто компании, у которых таковые имеются, не стремятся сделать их достоянием широких масс. И это объяснимо: ведь бизнес-процессы предприятия — это закрытая информация, ноу-хау; то, что позволяет получить конкурентное преимущество. Чтобы восполнить этот пробел, мы расскажем о реальном бизнес-процессе, работающем под управлением BPM-системы. У нашей компании есть опыт автоматизации управления бизнес-процессами у заказчиков, принадлежащих самым разным отраслям. Но разглашать информацию о них мы не вправе, поэтому предлагаем вашему вниманию один из наших собственных бизнес-процессов. В чем заключается бизнесОдно из направлений деятельности нашей компании — дистрибуция программного обеспечения. В свою очередь, это направление распадается на работу с различными поставщиками и заказчиками. Мы рискнули начать внедрять процессное управление с канала продаж, являющегося одним из наиболее важных с точки зрения дохода и деловой репутации компании. В качестве Покупателя в нем выступает один из крупнейших российских банков. Точнее, Покупатель выступает в двух лицах — головного офиса и филиалов:
Поставщик (наша компания) принимает заказ и размещает у Производителя программного обеспечения — американской компании. (Чтобы не создалось ложного впечатления: поставка программного обеспечения — это только часть деятельности дистрибьютора; просто все остальное — консалтинг, техническую поддержку, обучение — мы оставляем «за кадром».) Поскольку такие закупки осуществляются на регулярной основе, три стороны — Покупатель, Производитель и Поставщик — заключили рамочный Договор о покупке. Это обычная коммерческая практика для подобных ситуаций: в рамочном договоре оговариваются цены, условия поставки и оплаты, но он не содержит конкретных обязательств о приобретении определенной номенклатуры в определенном количестве. Обязательства конкретизируется в Спецификациях, которые составляются на каждый отдельный заказ. Форма Спецификации также определена рамочным договором. После подписания всеми сторонами, Спецификация с юридической точки зрения становится неотъемлемой частью договора, и у сторон появляются предметные контрактные обязательства. С точки зрения BPM эта картина интерпретируется следующим образом:
Итак, рассмотрим бизнес-процесс под названием «Рамочный договор покупки». Проблемы и возможностиПроблемы — двигатель прогресса. Какие у вас будут стимулы к движению вперед, если все идет хорошо? Любая проблема, если посмотреть на нее под правильным углом зрения, это возможность что-то совершить, куда-то продвинуться и в личном, и в общественном смысле. Это известно всем поставщикам ИТ-решений: сумел найти проблему заказчика — считай, полдела сделано. Однако это не так-то легко из-за отсутствия эталона: как вы узнаете, что у вас есть проблема, если у вас нет хорошего образца для сравнения? Например, если вы всю жизнь копаете землю лопатой и стали в этом деле квалифицированным специалистом, то вы будете считать что у вас нет никаких проблем … до тех пор, пока не увидите как работает экскаватор. Люди искушенные знают, что «экскаватор всегда где-то рядом», и поэтому поиск инноваций становится у них навязчивой идеей (как сказал глава Интел Энди Гроув, «выживают только параноики»). BPM — это и есть такой «экскаватор»: раз увидев его в деле, не понимаешь, как ты до сих пор мог работать по-другому. У нас такой опыт был, поэтому мы отчетливо видели и свои проблемы, и связанные с ними возможности. Стандартная рекомендация тем, кто задумался о внедрении BPM — найдите для пилотного проекта бизнес-процесс, который явно плохо управляется. Симптомом этого может быть, например, постоянные «разборки» между подразделениями и их руководителями на планерках и собраниях. Но в нашем случае говорить о том, что процесс управлялся плохо, не приходилось; скорее он управлялся слишком дорого. Специфика рассматриваемого процесса:
В результате получаем набор противоречий:
Как всегда, когда нет системного решения, его заменяет «агрессивный менеджмент»: кто-то из руководства компании вынужден был лично контролировать процесс, постоянно «накачивая» исполнителей. Это непродуктивно, это постоянный риск потери контроля и, как следствие,— изматывающий стресс.
Цели проекта BPMЧего мы хотели добиться, начав управлять процессом при помощи BPM:
Бизнес-процесс в подробностяхОтправной точкой для моделирования бизнес-процесса послужил рамочный договор, благо в нем зафиксированы все ключевые аспекты процедуры: порядок согласования спецификации, сроки поставки и оплаты, оплата после фактической поставки и т.п. Затем мы прошлись по всей цепочке: проанализировали кто, что, в какой последовательности делает. После этого было нескольких циклов моделирования и пробной эксплуатации, в ходе которых схема уточнялась и конкретизировалась, и в результате мы пришли к следующей схеме (увеличить): Рисунок 1. Схема бизнес-процесса "Рамочный договор покупки" (Условные обозначения и термины см. во врезке «Пояснения к используемому инструментарию».) Участники процесса:
Весь процесс по-крупному разбивается на четыре этапа: Прием и обработка заказаСтарт процесса
Заявка на приобретение
Рисунок 2. Экранная форма согласования условий заказа Нажав на кнопку «СОГЛАСОВАНО», исполнитель активизирует следующий шаг процесса. Если договоренности достичь не удалось («НЕ СОГЛАСОВАНО»), процесс завершается. Согласование спецификацииФормальная спецификация, составленная в соответствии с достигнутыми коммерческими договоренностями, подписывается всеми сторонами. Менеджер по дистрибуции согласовывает спецификацию с Производителем, а Аккаунт-менеджер — с головным офисом Покупателя. Согласование Спецификации выделено в подпроцесс: Рисунок 3. Подпроцесс "Согласование спецификации" Сделано это, во-первых, для того, чтобы сделать схему более наглядной, а во-вторых, для повторного использования в других процессах. Этот подпроцесс иллюстрирует два преимущества работы с BPM-системой:
Как видно из схемы, у подпроцесса два варианта выхода: «Продолжить» и «Не подписано». В зависимости от того, как завершился подпроцесс, основной процесс (рис. 1) либо продолжается по стрелке "Продолжить", либо прекращается. Отгрузка товараРазмещение заказа
Традиционно в подобных ситуациях операции выполняют последовательно, чтобы не запутаться. Это еще одно стандартное преимущество BPMS:
Подготовка товара к отгрузке
Рисунок 4. Подпроцесс "Подготовка товара к отгрузке"
Отгрузка
РасчетыПроизводятся платежи и подводятся итоги сделки, при этом процесс дважды распараллеливается и затем сходится (рис. 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. Оцениваем результатыОценки проектов в области автоматизации со стороны бизнеса и ИТ редко совпадают. Но если обычно бизнес по отношению к проектам автоматизации часто выражает скепсис, то в случае BPM-проекта ситуация сплошь и рядом обратная. Менеджеры и собственники проявляют энтузиазм, наконец-то получив в свое распоряжение адекватный их ожиданиям инструмент. А ИТ-специалисты пребывают в некотором недоумении: как столь скромная по масштабу разработка в принципе может дать значимые результаты? Но ведь дает же! Высокий к.п.д как раз и является привлекательной стороной технологии BPM: за счет выстраивания правильных приоритетов в своей работе, упорядочения документооборота, интеграции людей и автоматизированных систем удается достичь значимых результатов при умеренных трудозатратах. И этот новый уровень производительности радикально меняет подход к автоматизации: Это не фотография, это киноРассказывая о философии BPM, часто сталкиваешься со следующей реакцией со стороны ИТ-специалистов: подумаешь, мы то же самое можем запрограммировать в своей системе (вариант: уже запрограммировали). Разумеется, рассмотренную задачу вполне можно решить традиционными средствами автоматизации, не прибегая к помощи BPM. Но тут упускается один важный момент: динамика. Традиционными методами можно решить задачу однократно, но как быть, если заведомо известно, что постановка задачи — схема бизнес-процесса — будет меняться, скажем, с частотой раз в месяц? С большой вероятностью программист в этой ситуации встанет в позу обиженного и попросит пользователя (читай — бизнес) сначала самому определиться, сформулировать четкие и однозначные требования, и с ними уже обращаться. Программист не виноват — его так учили, так написано в умных книгах, стандартах, методологиях разработки программного обеспечения. Но ведь и пользователь не виноват: не может он, в силу объективных причин, выполнить такие условия. Просто бизнес сегодня меняется слишком быстро. Слияния, поглощения, изменения стратегии — например, вы внедряете ERP-систему, и за время проекта несколько раз меняется генеральный директор. Повлияет это на требования к системе? Еще бы! А конкуренты с Запада и Востока, мгновенно меняющие правила игры на рынке, а новые схемы бизнес-партнерства (вспомним хотя бы аутсорсинг) и экзотические управленческие методологии — TQM, Six Sigma, Lean Manufacturing и многие, многие другие, причем любая из них может быть «спущена сверху» прямо завтра! И в этих условиях вы требуете от менеджеров «зафиксировать требования»? Полноте, вы наверное шутите. Методология BPM изначально рассматривает схему бизнес-процесса как нечто постоянно меняющееся позволяет эффективно управлять процессом изменений и создавать адаптивные системы, без задержки перестраивающиеся вслед за изменениями требований. BPM и традиционная разработка с жестким кодированием элементов бизнес-процесса соотносятся друг с другом так же, как кино и фотография: вроде и там и тут одни те же фотокадры, но впечатления от просмотра абсолютно разные. Роскошь индивидуального подходаВернемся к бизнесу дистрибьютора и вспомним, что рассмотренный выше бизнес-процесс — это всего лишь один производитель и один, пусть очень важный, заказчик. Но типичный компьютерный дистрибьютор работает с десятками производителей, каждый из которых навязывает свой стиль работы, и через несколько совершенно различных каналов продаж: через партнеров, через филиалы, поставки крупным клиентам и т.д. Если решать задачу автоматизации такой компании традиционными методами, то пытаться рассматривать все возможные комбинации даже не придет в голову — такая задача была бы явно неподъемной. Поэтому отдел ИТ, комбинируя готовые решения и собственные разработки, создает некую «усредненную» систему, предоставляющую общую для всех процессов функциональность. Детали же и особенности процедур взаимодействия с конкретными производителями или работы конкретных каналов продаж — только в головах менеджеров по продажам и менеджеров по продуктам. «Легковесный», на взгляд некоторых, подход BPM позволяет разрабатывать для взаимодействия с каждым поставщиком и заказчиком индивидуальное решение, и это не может не сказаться благотворно на бизнесе. В связи с этим на ум приходит старый афоризм: «В жизни надо делать только то, что дается легко. Но делать это надо изо всех сил!» Собственная и внешняя разработкаОптимальное соотношение между собственными разработками, готовыми и заказными разработками — это «вечно-зеленая» тема и один из главных пунктов стратегии каждого ИТ-директора. Крайности — только свое или только покупное — зачастую оказываются губительны. Связка BPM-SOA дает путеводную нить. Вместо взгляда на автоматизированную систему как на единый монолитный блок предлагается архитектура, в которой четко выделены два уровня:
BPM ориентирован именно на такое разделение труда. Инструментарий BPM, и в части моделирования схемы бизнес-процесса, и в части разработки пользовательских интерфейсов к шагам бизнес-процесса, нацелен на минимизацию трудозатрат, что позволяет вести такие разработки собственными силами даже предприятием с одним-двумя штатными ИТ-специалистами. Исходя из этой стратегии, проекты BPM, по нашему мнению, должны выполняться не «под ключ», а с серьезным вовлечением специалистов заказчика и передачей ему компетенции: в случае BPM вы покупаете не рыбу, а удочку. Синтез смежных технологийИногда можно услышать мнение: «BPM — это тот же документооборот». Или: «это все затеяно ради измерения показателей эффективности». На самом деле в 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-каналы | Карта сайта | Авторские права | |||||||||
|