Истоки BPMS

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

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

Бизнес-процессы

Определение бизнес-процесса, которое дает один из авторов концепции реинжиниринга бизнес-процессов Майкл Хаммер:

Бизнес-процесс — это организованный комплекс взаимосвязанных действий, который в совокупности дают ценный для клиента результат.

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

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

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

Концепция бизнес-процесса

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

Иллюстрация проблем, возникающих в такой системе, на каноническом примере процесса продажи товара:

●     отдел продаж стремится максимально снизить цену и сроки, чтобы убедить клиенты купить товар и выполнить свой план по продажам;

●     технологи, поставленные перед фактом подписанного договора, говорят что произвести товар с заданными в спецификации характеристиками или в установленные контрактом сроки невозможно;

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

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

Схемы бизнес-процессов — это особо ценная форма интеллектуального капитала компании. Но, как показал опыт 90-х годов, накопление его идет слишком медленными темпами и обходится слишком дорого.

Проблемы реинжиниринга бизнес-процессов

Теоретически внедрить бизнес-процесс можно двумя способами: либо разработав его «с чистого листа», либо критически переработав существующую практику. Первому подходу соответствует английский термин engineering (конструирование), второму — re-engineering (повторное конструирование, перестройка).

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

Реинжиниринг бизнес-процессов подразумевает вполне определенную последовательность шагов:

1.   Анализ существующей бизнес-практики, на жаргоне реинжиниринга он называется составлением схемы «as-is» («как есть»).

2.   Проектирование оптимальной схемы бизнес-процесса, называемой «to-be» («как будет»).

3.   Планирование и фактический переход от первого ко второму.

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

Характерные проблемы из практики (в том числе отечественной) реинжиниринга бизнес-процессов:

Потеря фокуса

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

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

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

Неустранимый разрыв между «as-is» и «to-be»

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

Из-за высокой ответственности такого шага его планирование занимает очень много времени (по принципу «семь раз отмерь, один отрежь»). В сочетании с особенностями упомянутого выше «системного подхода» это приводит к тому, что результаты анализа устаревают быстрее, чем он заканчивается. Устаревают из-за того, что за месяцы, ушедшие на «as-is» и «to-be» анализ и на планирование перехода, успевает поменяться бизнес-окружение, представление самого бизнеса об оптимальном бизнес-процессе, а зачастую успевает смениться и собственник бизнеса.

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

Инструмент непрямого действия

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

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

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

BPMS как решение проблем реинжиниринга

BPM-система эффективно решает перечисленные выше проблемы:

На выходе — не «картинки», а работающая система

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

Схема бизнес-процесса в BPM предельно конкретна

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

BPM — средство изучения бизнес-процессов

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

Непрерывный реинжиниринг собственными силами

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

Различие подходов суммируются в следующей таблице:

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

Системы документооборота

Системы управления документооборотом исторически развивались от отслеживания местонахождения и состояния документов к поддержке совместной работы над документами, составлению и контролю маршрутов их движения. В сегодняшних ECM-системах (Enterprise Content Management, управление корпоративным контентом) коллективную разработку и исполнение документов обеспечивают модули Workflow.

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

Кроме того, между ECM/Workflow и BPM есть существенные технологические и методические отличия:

BPM как ответ на ограниченность систем документооборота

Типичные проблемы, с которыми сталкиваются предприятия и организации при внедрении систем документооборота:

●     Сложная и трудоемкая интеграция с корпоративными системами. Документы «оборачиваются» сами по себе, а корпоративные системы живут сами по себе.

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

●     Ограниченная производительность и масштабируемость.

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

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

Интеграция приложений

Дилемма, постоянно стоящая перед пользователями информационных систем: что предпочесть, программные решения от одного доверенного поставщика («Single Vendor») или же набор решений, лучших каждое в своем классе программного обеспечения («Best of Breed»),— естественно, от разных поставщиков.

В разные годы баланс предпочтений пользователей смещался то в одну, то в другую сторону. Так, для 80-х годов была характерна «лоскутная автоматизация» — множество АРМов от разных поставщиков. К 90-м этот подход себя исчерпал и все поверили во всемогущество ERP: предполагалось, что, внедрив ERP-систему, предприятие удовлетворит если не все, то почти все свои потребности; соответственно, подход «Single Vendor» стал выглядеть более предпочтительным.

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

●     ведение отношений с заказчиками (CRM — Customer Relations Management);

●     управление персоналом (HR — Human Resources);

●     бизнес-анализиподдержкапринятиярешений (BI — Business Intelligence, DSS — Decision Support System);

●     бюджетированиеифинансовоепланирование (Performance Management, Budgeting, Forecasting);

●     оперативное управление производством (MES — Manufacturing Enterprise System).

В результате, по оценке Gartner Group, сегодня ERP-система в среднем покрывает 40% потребностей предприятия против 70% в прошлом. Нынешние заказчики все меньше склонны ждать всеобъемлющего решения от одного поставщика и все больше внимания уделяют интеграции приложений.

Сервис-ориентированная архитектура

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

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

Сервис-ориентированная архитектура как раз и указывает такой способ: нужно «обернуть» функции существующих приложений при помощи вебсервисов, превратив их тем самым в стандартные «строительные блоки», которые можно будет использовать самыми разнообразными способами. Управление последовательностью вызовов вебсервисов и передачей данных между ними называется «дирижированием вебсервисами» (Web Service Orchestration).

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

Уникальность вебсервисов как технологии интеграции в том, что она активно поддерживается как Microsoft, так и противостоящим лагерем сторонников Unix, Linux, Java. В результате вебсервисы — это наилучшая технология, для интеграции приложений Microsoft .NET и Java.

Однако, при всей перспективности SOA надо заметить, что повсеместный переход на эту архитектуру пока не состоялся. Если взять, например, 1С как наиболее распространенную в России корпоративную систему, то сегодня обратиться к ней через вебсервисы не удастся. Поэтому прагматичные вендоры BPM предлагают спектр интеграционных возможностей: вебсервисы, JDBC (Java DataBase Connectivity) для доступа к базам данных, JCA (Java Connection Adapters) для доступа к бизнес-объектам.

Бизнес-процессы и базы данных

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

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

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

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

Появление BPMS как нового класса системного программного обеспечения по значимости сравнимо с появлением в начале 80-х коммерческих DBMS (СУБД) общего назначения. С появлением BPMS жестко зашивать схему конкретного бизнес-процесса в коды программы или использовать частные, нестандартные механизмы описания бизнес-процессов ERP-систем, стало столь же нерациональным, что и использование для хранения данных внешних файлов вместо СУБД.