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


 
Зачет по BPM

Литература:

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

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

Современные переводные журнальные статьи малополезны для отечественного читателя, намеренного ознакомиться с основами BPM, поскольку в них рассматриваются специфические, углубленные задачи. Например, статью о BAM (Business Activity Monitoring) читатель, не усвоивший что такое BPM, просто не поймет, поскольку информация в BAM поступает из BPM. А понимание BPM, в свою очередь, невозможно без понимания концепции бизнес-процесса. Есть и откровенно неудачно переведенные термины, например «деловой процесс». Для получения общего представления о BPM надо начинать с публикаций примерно трехгодичной давности, в которых эти основы рассматривались. Кроме того, нужно учесть, что соответствующее программное обеспечение пока недешево. Мало кто имеет реальную возможность его опробовать, а потому некоторые участники форумов подменяют практический опыт работы с BPM собственными догадками. Да и в отношении методологии BPM — процессного подхода к управлению — российские специалисты пока накопили очень мало опыта.

Свою лепту в сумятицу, связанную с BPM, вносят маркетинговые приемы производителей, расширительно толкующих и переопределяющих термины. Можно вспомнить, как в свое время все СУБД в одночасье стали «реляционными». Нечто похожее наблюдается и сейчас: о наличии BPM-систем в их продуктовых линейках заявляют многие поставщики, хотя это не всегда обосновано. Например, в качестве BPM позиционируются столь разные продукты, как дизайнер бизнес-процессов (IDS Scheer ARIS), промежуточное ПО для координации Web-сервисов (Oracle BPEL) и ориентированная на работу с персоналом BPM-система (Fujitsu Interstage).

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

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

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

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

Что такое бизнес-процесс

Не стоит искать ответ, отталкиваясь от здравого смысла и правил русского языка: «если взять бизнес и процесс, то на пересечении должно получиться…» Не уподобляйтесь плохому студенту на экзамене, лучше обратитесь к первоисточникам. Термин «бизнес-процесс» в современный управленческий лексикон был введен Дэвенпортом и Хаммером в 1990 г. [TD90], [MH90], [MH93] в рамках зарождавшейся в тот момент методологии реинжиниринга бизнес-процессов. Термин этот впоследствии прижился, методология получила определенное признание, и пытаться его теперь переопределять означает только вносить путаницу.

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

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

Увы, эта фундаментальная идея бизнес-процесса осознается не всегда и не везде. В результате, например, для перехода к процессному управлению организуется новое структурное подразделение. Это бессмысленно, необходимо изменение организации работы существующих и изменения образа мышления управленцев, в том числе путем изменения принципов стимулирования. Или в результате анализа схемы существующих бизнес-процессов («as-is») на свет появляется диаграмма с названием «Бизнес-процессы бухгалтерии» — это полное выхолащивание идеи бизнес-процесса!

BPM — это не ПО

Как следует из [WIKI], BPM — это управленческая методология. Следует различать BPM как методологию реорганизации и оптимизации бизнес-процессов и программное обеспечение как инструментарий, часто используемый с этой целью. Такое программное обеспечение вообще-то следует называть BPMS (Business Process Management System), или BPM-системой, но зачастую его именуют просто BPM.

Разница тут примерно такая же, как между бухгалтерским учетом, воспринимаемым в качестве управленческой методологии, и бухгалтерской программой. В быту то и другое можно называть просто «бухгалтерией», но контекст всегда позволяет понять, о чем идет речь. Продолжим аналогию: теоретически, можно вести бухгалтерский учет и без компьютера, но на практике вряд ли кто-то будет так поступать. Шансов встретить BPM без BPMS — больше, но в перспективе (при наличии доступного специализированного ПО) подобное применение окажется столь же нецелесообразным. И еще: сейчас есть специалисты по бухгалтерскому учету и по бухгалтерским программам, но точно так же могут существовать специалисты по управленческим и по программным аспектам BPM. Естественно, для успешной реализации BPM-проекта нужны и те, и другие.

Новизна BPM

Иногда можно услышать, что BPM существовал всегда. В подобных утверждениях используется чересчур расширительная трактовка термина, которая мешает уловить суть того, что возникло в управлении бизнес-процессами относительно недавно и сейчас обозначается этой аббревиатурой. Новый подход начал развиваться приблизительно с 2000 года, а всплеск числа публикаций о BPM пришелся на 2003 год. BPM сменил популярный в 1990-е реинжиниринг бизнес-процессов [BPM3], отличаясь от него следующим:

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

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

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

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

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

BPM и Workflow

С употреблением этих терминов возникла немалая путаница [TAX]. Сам по себе термин "Workflow" означает «последовательность работ, составляющих процесс», но его принято использовать и для обозначения функции управления потоком работ в традиционных системах документооборота. Также рассуждая абстрактно, Business Process Management есть расширение Workflow, но в BPM больше внимания уделяется, во-первых, автоматически выполняемым шагам бизнес-процесса, т.е. межсистемному взаимодействию, во-вторых, мониторингу бизнес-процессов, т.е. сбору статистики выполнения бизнес-процессов.

Теоретически, BPM-системы должны равно хорошо координировать задачи, выполняемые как людьми (human-to-human flow), так и автоматизированными системами (system-to-system flow). Однако на практике сегодняшние BPM-системы лучше справляются либо с тем, либо с другим [GAP]. В частности, стандарт BPEL в его нынешнем виде описывает координацию вызовов Web-сервисов и не рассматривает взаимодействие с людьми [BPELP].

Системы, ориентированные на координацию выполняемых людьми работ, иногда называют Workflow-системами (еще одно значение этого термина), а специалисты Gartner обозначают их термином Pure-Play BPM. Термин «BPM-система» иногда используется в узком смысле — «система, ориентированная на интеграцию»; в Gartner такую систему называют Integration BPM. Встречается также собирательный термин «BPM и Workflow-системы».

Компоненты BPM

Распространенная ошибка — воспринимать BPM-систему как еще одну «рисовалку бизнес-процессов». Действительно, визуальный редактор (дизайнер) бизнес-процессов, являющийся компонентом BPM-системы, мало чем отличается от традиционного инструментария реинжиниринга бизнес-процессов (средств рисования IDEF- или DFD-диаграмм). Но в BPM-системе рисование схемы бизнес-процесса является не завершающим этапом работы, а ее началом.

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

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

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

Часть шагов бизнес-процесса может выполняться автоматически: например, выписка счета. Можно предусмотреть дополнительные средства контроля: например, если процесс задержался на каком-то шаге дольше установленного регламентом времени, то по SMS автоматически отправляется уведомление менеджеру.

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

Дизайнер, «движок» и монитор являются стандартными компонентами BPM и соответствуют управленческой практике: разработка схемы бизнес-процесса, исполнение и анализ. Лучшие BPM-системы помимо этих компонентов могут включать в себя модули BRE (Business Rule Engine), BAM (Business Activity Monitoring) и другие [CHECK]. Существуют и программные продукты, реализующие отдельные компоненты BPM — например, только проектирование бизнес-процессов.

BPM и корпоративные системы

BPM не заменяет, а дополняет такие корпоративные приложения, как ERP, CRM, системы бюджетирования. Отметим, что BPMS следует относить не к прикладному, а к системному (по аналогии с DBMS) или промежуточному программному обеспечению. Как и в DBMS (где сначала определяется схема данных, а затем в нее заносятся сами данные), в BPMS сначала определяется схема, а уж потом в соответствии с нею создаются экземпляры бизнес-процессов. Схема данных в первом случае и схема бизнес-процесса во втором могут быть произвольными — в зависимости от предметной области.

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

Достоинства BPM раскрываются в полной мере, когда на предприятии имеется не одна, а несколько корпоративных систем. С такой ситуацией сталкиваются и корпорации, приобретающие компании с уже сложившейся информационной инфраструктурой, и предприятия, растущие потребности которых не может удовлетворить единственная ERP-система, — необходимы CRM-системы, системы бюджетирования и оперативного управления производством. Даже если предприятие обходится без них, сделав ставку на ERP-систему одного поставщика, то есть еще программное обеспечение «клиент-банк», САПР и АСУТП, которые не входят в состав ERP. Плюс к тому у большинства организаций имеются приложения собственной разработки, автоматизирующие некие специфические функции.

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

В области интеграции технология BPM пересекается с SOA (Service-Oriented Architecture). Отсутствие стандарта на взаимодействие систем разных производителей до сих пор делало интеграцию занятием, перспективным преимущественно для самих интеграторов и пугавшим заказчиков неприемлемо высокими расходами и рисками. Как известно, «unhappy customer easily produces unhappy developer», то есть «неудовлетворенный заказчик с легкостью делает неудовлетворенным разработчика». В результате отрасль пришла к пониманию необходимости решения этой проблемы. SOA обеспечивает стандарт на интерфейсы и среду, в которой такие интерфейсы могут публиковаться и вызываться, а BPMS — смысловую нагрузку и правила, согласно которым системы должны передавать друг другу информацию и управление.

Речь, конечно, не идет о возврате к «лоскутной автоматизации» — набору слабосвязанных программ и дублирующих друг друга баз данных. Но понятно, что путь создания единой всеохватывающей системы является тупиковым, приводит к появлению неповоротливых нежизнеспособных монстров. Современная архитектура — двухуровневая. Внизу находятся тесно интегрированные системы, внутри которых располагается единая база данных с присущими ей классическими «короткими» транзакциями. На верхнем уровне системы связываются друг с другом при помощи BPMS в рамках «длинных» транзакций.

Преимущества такой архитектуры становятся очевидными при рассмотрении задачи, состоящей в интеграции цепочки «поставщики — потребители» и создании «виртуальной корпорации». Идея проста: рамки бизнес-процесса раздвигаются, и вслед за границами функциональных подразделений рушатся границы предприятий. Считается, что на Западе предприятия уже научились отстраивать бизнес-процессы, и сегодня актуальной для бизнеса стала интеграция между компаниями [AGENDA]. С технической точки зрения интеграция гетерогенных корпоративных приложений на основе бизнес-процессов выполняется с помощью композитных приложений (composite applications) [COMP], которые представляют собой пользовательские интерфейсы одновременно к бизнес-функциям корпоративных приложений и к «движкам» BPM.

Ресурсы по BPM

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

Проблематика BPM периодически обсуждается на форуме sql.ru

Этого, конечно, слишком мало. Но этого мало, и к сожалению пока что не сформировалось сообщество профессионалов в этой области. А заняться такому сообществу было бы чем. Например, в свое время Workflow Management Coalition (www.wfmc.org) была организована на общественных началах (хотя и не без спонсорской помощи) с конкретной целью: выработать общепринятый глоссарий, и эта задача была решена. Затем, также в рамках WfMC, были разработаны референтная модель Workflow-системы и стандарт XPDL. Кстати, первый вопрос к будущему BPM-сообществу: кто должен создавать русский BPM-глоссарий?

Литература

[TD90] Thomas H. Davenport, James E. Short. “The New Industrial Engineering: Information Technology and Business Process Redesign.” Sloan Management Review, 1990.

[MH90] Michael Hammer. “Reengineering Work: Don't Automate, Obliterate!” Harvard Business Review, 1990.

[MH93] Michael Hammer, James Champy. “Reengineering the Corporation: A Manifesto for Business Revolution.” Harper Business, 1993.

[WIKI] Wikipedia: The Free Encyclopedia. “Business Process Management.” www.wikipedia.org.

[BPM3] Howard Smith, Peter Fingar. “Business Process Management: The Third Wave.” Meghan-Kiffer Press, 2002.

[TAX] Jim Sinur, Toby Bell. “A BPM Taxonomy: Creating Clarity in a Confusing Market.” Gartner Research, 2003.

[GAP] Jim Sinur. “The Gap Between IBSs and Pure-Play BPM Is Narrowing.” Gartner Research, 2003.

[BPELP] “WS-BPEL Extension for People — BPEL4People.” A Joint White Paper by IBM and SAP, 2005.

[CHECK] Jim Sinur, David W. McCoy, Toby Bell. “Creating a BPM and Workflow Automation Vendor Checklist.” Gartner Research, 2003.

[AGENDA] Майкл Хаммер. “Бизнес в ХХI веке: повестка дня. Что необходимо сделать каждой компании, чтобы стать лидером рынка в текущем десятилетии.” Добрая книга, 2005.

[COMP] Massimo Pezzini. “Composite Applications Head Toward the Mainstream.” Gartner Research, 2003.

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