Анатолий Белайчук,

президент «Бизнес-Консоль», bell@b-k.ru

Юлия Вагнер,

начальник отдела технической поддержки «Бизнес-Консоль», julia@b-k.ru

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

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

В «рамках»

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

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

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

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

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

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

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

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

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

Весь процесс можно разбить на четыре этапа: прием и обработка заказа, согласование спецификации, отгрузка товара, расчеты.

Бизнес-процесс начинается с того, что представитель филиала покупателя обращается с запросом о приобретении программного продукта (по факсу, электронной почте или просто как телефонный звонок). Его принимает секретарь. Получив такой запрос, секретарь запускает новый экземпляр бизнес-процесса, занося в стартовую Web-форму содержание запроса и контактную информацию о филиале покупателя. Аккаунт-менеджер ведет переговоры с покупателем и производителем, согласуя условия поставки, скидки и дополнительные условия. Хотя на схеме это выглядит как один шаг, в нем содержится вся коммерческая работа и длиться он может от нескольких дней до нескольких месяцев. От этого шага зависит, состоится ли сделка. Достигнутые договоренности исполнитель фиксирует в системе через Web-форму. Затем приступают к согласованию спецификации. Формальная спецификация, составленная в соответствии с достигнутыми коммерческими договоренностями, подписывается всеми сторонами. Менеджер по дистрибуции согласовывает спецификацию с производителем, а аккаунт-менеджер — с головным офисом покупателя. Согласование спецификации выделено в подпроцесс — во-первых, чтобы сделать схему более наглядной, а во-вторых, для повторного использования в других процессах. Этот подпроцесс иллюстрирует два преимущества работы с BPM-системой. Обычно переход ответственности от одного исполнителя к другому неизбежно связан с проволочками. BPM-система оказывает сильное дисциплинирующее воздействие: в каждый момент времени у бизнес-процесса «есть фамилия, имя и отчество». Задание, уходя от одного работника, сразу же появляется в списке заданий ответственного за следующий шаг, который знает о своей ответственности за бизнес-процесс и за неоправданные задержки. Далее, поскольку файлы документов прикрепляются к процессу и передаются вместе с отметкой о выполнении очередного шага, BPMS заменяет систему документооборота. У подпроцесса есть два варианта выхода: «продолжить» и «не подписано». В зависимости от варианта основной процесс либо продолжается по стрелке «Продолжить», либо прекращается.

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

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

Управлять или автоматизировать

К внедрению BPM компании подходят по-разному. Если процесс контролируется бизнес-руководителями, акцент делается на управлении бизнес-процессом. Если в основу ложится ИТ-подход, то основное внимание уделяется интеграции разнородных автоматизированных систем (передача и синхронизация данных, «оркестровка» Web-сервисов) и минимизации усилий пользователя при работе с системой. По мнению большинства аналитиков, путь «от бизнеса» правильнее, но на практике чаще встречается подход «от ИТ» [Bruce Silver. Make Way for BPM 2.0. BPMInstitute. org. 2006]. В результате в проектах BPM зачастую преувеличивается значение автоматизации в ущерб управлению. Например, качеству пользовательского интерфейса применительно к шагам бизнес-процесса и интеграции с существующими системами придается больше значения, чем срокам разработки. При этом зачастую не осознается тот факт, что работоспособную схему бизнес-процесса на практике невозможно разработать ни с первой, ни со второй итерации. По оценкам аналитиков, для того чтобы достаточно точно смоделировать су ществующий («as-is») бизнес-процесс, команде, не обладающей опытом, обычно требуется от 8 до 12 итераций; по мере накопления опыта число итераций снижается до 3—4 [Michael James Melenovsky. Business Process Management’s Success Hinges on Business-Led Initiatives. Gartner, Inc., 2005]. Не говоря уже об оптимизации бизнес-процесса. Наш собственный опыт подтверждает правильность этих оценок.

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

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

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

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

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

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

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

Но пользователь не может в силу объективных причин выполнить такие условия. Бизнес сегодня меняется слишком быстро: слияния, поглощения, смена стратегии, меняющиеся пра вила игры на рынке, новые схемы бизнес-партнерства (вспомним хотя бы аутсорсинг), управленческие методологии — TQM, Six Sigma, Lean Manufacturing — и многое, многое другое.

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

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

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

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

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

Оптимальное соотношение между коробочными продуктами, собственными и заказными разработками, — это один из главных пунктов стратегии каждого ИТ-директора. BPM в связке с SOA, вместо подхода к автоматизированной системе как к единому монолитному блоку, предлагает архитектуру, в которой четко выделены два уровня: бизнес-функций и бизнес-процессов. Бизнес-функции относительно устойчивы (меняются не слишком часто) и универсальны (применимы в различных моделях бизнеса), следовательно, реализующие их программы могут тиражироваться, что делает экономически оправданным разработку их сторонними независимыми поставщиками программного обеспечения. Изменчивость бизнес-процессов, напротив, высока, и здесь много специфики конкретного предприятия. Менять бизнес-процессы надо постоянно и лучше всего — собственными силами. Внешних консультантов экономически целесообразно привлекать для разового большого усилия. Здесь же речь идет о постоянной и планомерной работе, для которой надо наращивать собственную компетенцию и иметь собственные ресурсы. Уровни бизнес-функций и бизнес-процессов связаны сервис-ориентированной архитектурой (SOA) и промежуточным программным обеспечением, таким, как ESB (Enterprise Service Bus).

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

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

В BPM соединились предшествующие достижения в нескольких областях: моделирование и реинжиниринг бизнес-процессов (Business Process Modelling, Business Process Reingeneering), электронный документооборот (Electronic Workflow), интеграция корпоративных приложений (Enterprise Appications Integration), мониторинг эффективности бизнеса (Business Performance Management, Business Intelligence, Balanced ScoreCard). В результате, например, от классического документооборота BPM отличается наличием развитых средств моделирования, средств интеграции, основанных на открытых стандартах, коротким циклом разработки и прямым выходом на анализ эффективности. Прорывные идеи, как правило, появляются на стыке различных областей знания.

***

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

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

Новое оружие бизнеса Пока менеджеры и ИТ-специалисты спорят об эффективном управлении, ведущие мировые компании уже пустили в ход «оружие нового поколения» — системы управления бизнес-процессами, или BPMS (Business Process Management Systems). Отделы, начальники, должностные инструкции — к этому все привыкли и это не вызывает вопросов. У каждого подразделения свой план, своя отчетность, свои итоговые показатели. Но нередко бывает так, что каждое подразделение отчитывается об успехах, а предприятие в целом убыточно. Имея перед собой разные цели, подразделения лишь косвенно заинтересованы в конечном результате. Угроза потери рынка заставляет руководителей изменять свои взгляды на ведение бизнеса, и границы между компаниями и между подразделениями внутри компаний начинают осознаваться как препятствия для эффективной работы. Ломая их, компании выстраивают свою деятельность на основе бизнес-процессов. Основополагающий принцип процессного управления заключается в том, что во главу угла ставится общая цель, достижение которой является смыслом деятельности. Результат работы оценивается не по скорости выполнения исполнителем своих обязанностей, а по тому, как завершился весь процесс. Исчезают перекосы в показателях, возрастает эффективность управления. До недавних пор понятие бизнес-процесса у многих ассоциировалось исключительно с реинжинирингом, который предусматривал радикальный переход к новой системе управления. Концепция управления бизнес-процессами отличается от реинжиниринга тем, что предлагает начинать управление бизнес-процессами с имеющегося состояния, непрерывно улучшая их. Такая модель соответствует циклу Шухарта-Деминга, также известному как цикл PDCA (Plan, Do, Check, Act — планируй, делай, проверяй, воздействуй). Цикл PDCA еще называют жизненным циклом процесса, что подчеркивает важность непрерывного улучшения как обязательного условия «жизни». Выполнить это условие легче, имея соответствующее программное обеспечение, так называемые BPMS-, или BPM-системы. Что умеют BPM-системы Для BPM-системы необходимы три компоненты: средства моделирования схем бизнес-процессов, исполнительный «движок» бизнес-процессов, средства мониторинга. Для моделирования в BPM-системах используются графические дизайнеры бизнес-процессов, схожие с инструментарием, применяемым бизнес-аналитиками в проектах реинжиниринга. При этом схемы процессов в BPM ближе к Workflow-диаграммам, что делает их более интуитивно понятными, чем DFD- и IDEF0-диаграммы. Некоторые системы позволяют импортировать и экспортировать схемы из других редакторов, например из Microsoft Visio или IDS Scheer ARIS. Чтобы сделать схемы, нарисованные в разных дизайнерах, одинаково понятными всем, разработана стандартная нотация BPMN (Business Process Modeling Notation) [Business Process Modeling Notation, Version 1.0. Object Management Group/Business Process Management Initiative. 2004. www.bpmn.org]. Стандарты BPEL (Business Process Execution Language) [Business Process Execution Language for Web Services, Version 1.1. OASIS Web Services Business Process Execution Language (WSBPEL) Technical Committee. 2003. www.bpelsource.com] и XPDL (XML Process Definition Language) [Process Definition Interface — XML Process Definition Language, Version 2.00. Workflow Management Coalition. 2005. www.wfmc.org] регламентируют форматы для хранения схем бизнес-процессов; и тот и другой являются подмножествами XML. Готовая схема в виде XML-файла загружается в BPM Engine, после чего можно запускать экземпляры процессов. Процессы выполняются шаг за шагом, при этом назначаются задания пользователям или группам, определенным для каждого шага процесса. У исполнителей в персональном списке заданий появляется строка с названием шага, а сам список заданий формируется и поддерживается BPM-системой. Мониторинг процесса дает возможность оперативно отслеживать, на каком шаге находится процесс и кто является ответственным за его выполнение, а также проводить статистический анализ исполнения процесса с помощью ключевых показателей эффективности (KPI). Для того чтобы процесс мог успешно существовать и развиваться, его необходимо постоянно улучшать, что влечет изменение схемы процесса. Выполнить изменения схемы можно при помощи графического дизайнера, не прибегая к программированию. Однако говорить о том, что можно обойтись совсем без программиста — преувеличение. Хотя BPM-система и позволит запустить на исполнение бизнес-процесс, только что нарисованный бизнес-аналитиком, взаимодействовать с ним вам придется через довольно примитивные экраны пользовательского интерфейса, которые система сгенерировала автоматически. Для интеграции с внешними системами и создания качественного пользовательского интерфейса программировать все же придется, и тут многое зависит от возможностей конкретной BPM-системы. На вопрос о том, может ли BPMS заменить собой ERP, CRM, MES-систему, следует дать отрицательный ответ, поскольку BPM, прежде всего, — это системное, а не прикладное программное обеспечение, и поэтому корректнее сравнивать его с СУБД, а не с ERP. Кроме того, подход к автоматизации на основе BPMS ставит задачу не заменить существующие системы, а придать им новое качество за счет совместного использования. BPM-система позволяет связать воедино всех обитателей «информационного зоопарка», воспользовавшись заложенными в нее возможностями интеграции на уровнях данных и приложений. Еще одна область применения BPMS — это интеграция бизнес-партнеров, так называемая B2B (Business-to-Business) интеграция. Оценить эту возможность по достоинству пока могут немногие, но актуальность задач B2B растет, и возможности BPMS здесь будут востребованы.