Процессы являются составными «блоками» структуры современного предприятия. Результатом оптимизированного процесса, в котором люди и ресурсы используются эффективно, становится успешное достижение целей этого процесса; частично оптимизированные процессы становятся причиной неэффективности. В контексте бизнеса, различие между оптимизированными и частично оптимизированными процессами означает различие между использованной или упущенной возможностью, различие между устойчивым (экономическим) ростом и постепенным упадком. Оптимизированный процесс - управляемый процесс. Эдвард Деминг (Edward Deming), пионер движения управления качеством, в 50-ых отметил: «Для того, чтобы быть оптимальной, система должна быть управляемой. Ответственность органов управления состоит в стремлении к оптимизации системы и сохранении ее оптимизированной в течение некоторого периода времени. Дополнительная ответственность органов управления состоит в изменении границ системы для лучшего служения ее цели». Под «системой» Деминг понимал взаимозависимую совокупность функций, действий и подпроцессов. Он полагал, что ключевой задачей управления является оптимизация взаимосвязей между процессами, людьми, и ресурсами для достижения целей организации. Ничто существенно не изменилось с тех пор кроме степени автоматизации, которая стала доступна после внедрения компьютерных систем. Не удивительно, что с сегодняшней высокой степенью зависимости от информационных технологий (IT) практически в каждом процессе организации обращаются к системам BPM, которые позволяют оптимизировать процессы автоматически или вручную и гибко управлять ими по прошествии длительного периода времени. «BPM всегда было направлено на оптимизацию бизнес-процессов, прогнозирование и реагирование на изменения», считает Питер Линкин (Peter Linkin), который занимается внедрением BPM уже на протяжении 20 лет: сначала в Hewlett-Packard, затем в Vitria, а в настоящее время в BEA Systems, где он занимает пост старшего директора по продуктовому маркетингу. «С помощью BPM решений осуществляется управление и организация потока бизнес-процессов, путем введения основной интеграции связующего программного обеспечения, как для автоматизированных процессов, так и для процессов, осуществляемых сотрудниками вручную. Характеристикой полноценной BPM системы является то, что она должна позволять управлять автоматизированными процессами и процессами, выполняемыми вручную попеременно».
Корни BPM
Требование к представлению оптимизированных процессов с помощью информационных технологий старо как необходимость использования компьютеров в работе предприятия. «В некотором смысле, BPM всегда был с нами» - комментирует Джон Диллон (John Dillon), директор по EMEA (Европа, Ближний Восток и Африка) маркетингу в web Methods, который работал с BPM решениями большую часть десятилетия. «Автоматизация процессов стала причиной, по которой использование компьютеров вошло в бизнес более 40 лет назад для того, чтобы сократить затраты на повторное выполнение некоторых задач вручную. Когда я был разработчиком, я, по сути, прописывал процессы. С того времени изменился только подход: от сложного кодирования до более гибких решений, основанных на интеграции». Если наследие BPM, как философии управления, берет свое начало в 50-е, то предшественники системы программного обеспечения BPM впервые появились в 70-е. «Истоками BPM являются традиционные потоки работ (workflow), продукты по управлению промышленными процессами и автоматизированные производственные системы», - говорит Дэвид Мак Говеран (David McGoveran), президент Alternative Technologies и признанный ведущий эксперт в области BPM. «BPM возник, когда специфические процессно-ориентированные системы применялись, в общем, ко всем процессам. Я работал с первой промышленной BPM системой, называемой FastTrack, которая стала доступной в 1981 году, и была понятной при использовании в полупроводниковой промышленности и дискретном электронном производстве. Самые ранние управленческие решения относительно потоков работ, которые начали появляться в течение этого периода, выстраивались вокруг управления документооборотом. Например, Digital Equipment Corporation разработали продвинутую систему электронной почты, позволяющую маршрутизировать сообщения электронной почты и управлять ими, которая, в конечном счете, переросла в средство автоматизации коллективной работы». В Hewlett-Packard в это же время тоже разрабатывалась система управления документооборотом, которая на протяжении десятилетия эволюционировала в workflow-продукт, а затем в систему BPM. Линкин (Linkin) вспоминает: «В самом начале, когда в середине 90-ых я работал в Hewlett-Packard, я столкнулся с концепциями BPМ. Первоначально Hewlett-Packard сосредоточились на маршрутизации электронных сообщений и управлении ими. Организации хотели направлять документы для утверждения по электронной почте различным людям в определенной последовательности. Эта функция полностью отводилась электронной почте. В конце 90-ых, Hewlett-Packard выпустили AdminFlow - элементарное решение для автоматизации документооборота».
Темные Годы
Несмотря на приобретенные в 80-ых преимущества, BPM начал колебаться с появлением Реинжиниринга Бизнес-процессов (BPR), который доминировал в философии управления и вычислительной обработке данных в масштабе предприятия на протяжении большой половины 90-ых. Концепцией BPR является радикальное перепроектирование бизнес-процессов, ведущее к усовершенствованию выполнения бизнес-процессов, существенному сокращению стоимости и затрат на трудовые ресурсы. Несмотря на то, что многие организации внедряли BPR в 90-ых, они пришли к тому, что большинство процессов не достаточно эффективно для того, чтобы их бизнес был конкурентоспособным, поэтому организации стали фокусироваться на внедрении «лучших практик» с использованием ERP-приложений. «В начале 90-ых, ERP-приложения стали ядром вычислительной обработки данных в масштабе предприятия», - объясняет Мак Говеран (McGoveran). «ERP-приложения предлагали готовые модели бизнес-процессов, но этот подход не был обращен на управление бизнес-процессами. Установка ERP-системы означала внедрение BPR – изменение существующих процессов для того, чтобы они соответствовали «лучшим практикам», использующим IT (информационные технологии). Приверженцы BPR придерживались традиционного представления о бизнес-процессе как о конвейере, что препятствовало развитию BPM систем. На практике гибкость и исключительное течение процесса игнорировались не в такой значительной степени, чтобы возникла необходимость устранения этого игнорирования. «Лучшие практики» сосредотачивают внимание на обычной деятельности, а не на деятельности, отличающей Вас от ваших конкурентов». К сожалению, такое понимание подхода не входило в господствующую тенденцию того времени, а вместо этого средства массовой информации пестрили историями о BPR проектах, которые превышали отведенный на них бюджет или сроки разработки. «Из-за BPR, как только Вы говорили: «BP …», - клиент заявлял: «это мне не подходит». Такая ситуация отбрасывала длинную тень на развитие рынка BPM,» - вспоминает Линкин (Linkin). По словам Джонатана Аирея (Jonathan Airey), вице-президента и главы XML Integration business в Software AG, движение BPR дало BPM необходимые предпосылки. «Фактом является то, что лица, в настоящее время принимающие управленческие решения в рамках BPM, вероятно участвовали в прошлом в BPR проектах. На мой взгляд, BPR стал верным действием, предпринятым в ответ на неправильную причину (организационная децентрализация) и без соответствующих инструментов. Единственный способ рассмотрения BPM состоит в том, что BPM является решением, обеспечивающим необходимую дополнительную возможность для комплексных прикладных задач».
Начало Возрождения
С появлением в середине 90-ых электронного бизнеса (интернет-бизнеса), компании столкнулись с тем, что у них стало меньше возможностей и больше ответственности. Теория BPR отставала в следовании главной бросившей ей вызов концепции – приспособляемости, что впоследствии подтвердили авторы «Реинжинринга корпорации» («Reengineering the Corporation») Джеймс Чампи (James Champy) и Майк Хаммер (Mike Hammer): «Мы изменили свою точку зрения потому, что при реинжиниринге более важным, чем изменение хода производственной деятельности, является рассмотрение процессов в качестве «сердца» организации». Подобное понимание имело существенные последствия для IT. Поскольку потребность в соединении бизнес-приложений стала более очевидной, появился новый рынок программного обеспечения – EAI (Enterprise Application Integration). Однако, сначала большинство продавцов EAI не испытывали потребности в BPM. «Даже притом, что EAI господствовал на рынке, и все были от этого в восторге, ничего на рынке не говорило о BPM», - комментирует Мак Говеран (McGoveran). «Было несколько научных статей, в которых рассматривались эти проблемы (включая статьи Ming-Chien Shan из лаборатории HP), но никто на рынке не использовал эти идеи. Я консультировался в HP и понял, что они развили технологии, которые можно было применить к зоне наилучшего восприятия EAI (которая развивалась быстрыми темпами), потокам работ (которые находились в стадии стагнации) и бизнес-процессам». И Джон Диллон (John Dillon) и Питер Линкин (Peter Linkin) в то время работали в HP. «В карьере всегда есть выдающиеся моменты», - говорит Диллон (Dillon). «Для меня таким моментом стало участие в «проекте Монтана» (Montana project) от HP. У нас была технология, которая являлась двигателем автоматизации и переключения состояний между приложениями, но не оценкой роли в бизнесе. Для решения проблем HP заключили контракт с Джеком Траутом (Jack Trout), известным консультантом по маркетингу. После рассмотрения всей технической документации и презентаций, он ответил: «Все, о чем Вы говорите это изменения, управление изменениями в информационных системах». Таким образом, созданный продукт был назван ChangEngine, и был призван помочь в формировании рынка BPM». Vitria широко известен как еще один продавец-первопроходец BPM систем. Питер Линкин (Peter Linkin), который присоединился к Vitria от HP в конце 90-ых, добавляет: «Дал Скин (Dale Skeen) из Vitria заслуживает множество похвал за идею связующего программного обеспечения для управляемых процессов. В то время как остальная часть рынка говорила о направлении и преобразовании сообщений, у него было свое видение объединения EAI, BPM и того, что мы теперь называем программное обеспечение BAM. На мой взгляд, Vitria была единственной компанией, которая действительно осознала всю мощь и дальновидность BPM. HP и Vitria предсказали, что в случае с BPM для того, чтобы люди начали понимать чем является BPM и какие выгоды можно из него извлечь, потребуется 10 лет, как для изобретения лампочки».
Вехи и Указатели
Сегодня, есть более глубокое понимание интеграции центральных характеристик процесса и BPM в среде IT и менеджеров. Все еще кажется, что философия BPM принимается на рынке неохотно. «В этом присутствует четко выраженный вызов в будущем», - объясняет Диллон. «Множество организаций считают, что проводят успешную интеграцию бизнес-процессов. Уровень обслуживания отделами систем информатизации (IS) оценивается, как приемлемый. Создание более гибкой структуры организации не признается реальной проблемой бизнеса. Основная идея должна быть провозглашена громко и ясно: Почти каждая проблема в бизнесе возникает из-за нарушения хода какого-либо бизнес-процесса. Мы редко сталкиваемся с проблемой, возникшей не из-за не правильно текущего бизнес-процесса». Этот опыт отражает Правило Джурана (Juran\'s Rule) в философии управления: 85 процентов проблем, возникающих в бизнесе, случаются из-за не правильно текущих бизнес-процессов. «Бизнес-процессы не имеют положительного результата потому, что происходит что-то непредвиденное или возникают исключительные ситуации», - продолжает Диллон (Dillon), иллюстрируя важность управления исключительными ситуациями в BPM по аналогии. «Что фактически делают пилоты? Сегодняшние коммерческие авиалайнеры настолько автоматизированы, что автопилот и дистанционное управления могут позаботиться практически обо всем. Но кто хочет быть пассажиром «самолета, который может справиться самостоятельно практически с каждой ситуацией»? Что происходит, когда рейс попадает в плохие погодные условия? Что происходит, когда двигатель выходит из строя? Что происходит, когда во время приземления выходят из строя шасси? В этих исключительных, экстремальных условиях пилоты проявляют все свои навыки и демонстрируют свою реальную ценность. То же самое происходит при управлении бизнес-процессами – ваши действия должны быть достаточно гибкими для того, чтобы контролировать возможные исключительные ситуации прежде, чем они перерастут в кризис». Путь к BPM должен быть четко обозначен для большинства менеджеров по двум причинам. Во-первых, BPM - неотъемлемая часть бизнес контекста. «Ключевой точкой отсчета для BPM стал момент помещения его в контекст отрасли», - разъясняет Линкин (Linkin). «Прежде всего, департаменты IT могли бы оценить всю силу BPM, но они воспринимали его как роскошь, так как ключевым вопросом для них было поддержание определенного набора приложений в рабочем состоянии. Тем не менее, BPM становится необходимым, когда регулятивные изменения или федеральное законодательство вынуждает промышленность изменять свой бизнес-процессы, или когда крупные игроки промышленного рынка, например крупные автомобильные производители или розничные продавцы, определяют порядок взаимодействия с поставщиками. Такая ситуация благоприятствует появлению мотивированных союзников». Во-вторых, появление BAM снова обозначило важность бизнес-процессов и помогло перефокусировать внимание. «Для менеджера BAM обладает интуитивной привлекательностью», - продолжает Линкин (Linkin). «Само понятие прогнозируемого предприятия требует, чтобы технология BAM предсказывала вероятные будущие события и обеспечивала выбор управленческих решений относительно этих событий. Даже если такое видение сегодня кажется футуристическим, оно дает мощный толчок бизнесу». Тем не менее, развитие BAM как отдельной категории является проблематичным. «BAM не является обособленной единицей», - предостерегает Аирей (Airey). «Использование BAM без BPM не решает всех проблем. Концептуально, BAM всегда был частью BPM». Мак Говеран (McGoveran) соглашается: «Сегодня есть две отдельные категории, но это не имеет смысла, поскольку BAM присущ BPM. Вспомните старое изречение: если что-то не возможно измерить, то этим не возможно управлять». Сближение двух технологий кажется неизбежным, если видение и BPM и BAM будет осознано; в этом случае BAM, может оказаться катализатором, ускоряющим принятие BPM.
Два Пути для Путешествий
Существуют и другие катализаторы. Стандарты, такие, как: Web Services и BPEL, переносят внимание далеко от основной технологии к более высоким слоям интегрирующих масс, вроде гармоничного сочетания процесса. Диллон (Dillon) объясняет: «Отчасти BPM был возрожден Web Services и движением за SOA. Помните, до недавнего времени инструменты BPM должны были сочетаться с собственными системами интеграции. Концептуально, Web Services избавляют от этой головной боли». Аирей (Airey) также полагает, что стандарты играют важную роль в формировании видения BPM. «Будущее BPM - в стандартах, связывающих процессную модель бизнеса с моделью данных IT; в комбинации BPEL и OWL. Это и есть уравнивание бизнеса и IT, о котором так часто говорят. Для стандартов является важным достижение этой цели потому, что структура и архитектура связующего программного обеспечения становится независимой». Мак Говеран (McGoveran) считает, что это - взаимосвязь между различными моделями, дающими реальную выгоду. «Мы должны понимать взаимосвязь между моделями данных и процессными моделями. Кажется, между моделями данных и моделями бизнеса существует некоторая напряженность. Все эти развивающиеся мировоззрения необходимы, но сами по себе они не достаточны для достижения BPM. За прошедшие 10 лет, мы перешли от развития, основанного на централизации данных, до развития, основанного на объекте, но отошли от первопричины - определения бизнес-процесса. Разработчики должны больше сосредотачиваться на процессе». Новое поколение развитых инструментов может нам помочь. «Внедрение BPM зависит от бизнеса, но из-за того, что технология очень сложна, процесс внедрения, вероятно, будет более шероховатым», - говорит Линкин (Linkin). «Мы только что выпустили инструмент, позволяющий разработчикам графически сгруппировать услуги в бизнес-процесс или подпроцесс. Но та же самая технология может быть использована и для процессов более высокого уровня, которым требуется непрерывное управление». Такое развитие процессного управления делает возможным применение к BPM метода восходящего проектирования, но, в конечном счете, должен быть применен нисходящий метод. Мак Говеран (McGoveran) объясняет: «Web Services помогают, но они отражают только низший уровень и могут исказить полную картину бизнес-процессов. Вам нужно сгруппировать все услуги в бизнес-процессы и управлять ими. В конечном счете, Вам стоит нанять менеджера, но не разработчика. С помощью BPM решений уровень обобщения процесса должен подняться настолько, чтобы подпроцессы могли быть рассмотрены бизнес-аналитиком независимо от сложности инфраструктуры. Процессы также должны быть независимыми: формулировка процесса должна быть отдельной от ресурсов, с помощью которых он осуществляется. Только тогда исполнительный директор будет способен использовать панель инструментов в реальном времени и будет способен вносить изменения в бизнес-процесс для того, чтобы не упустить благоприятные возможности». Мак Говеран (McGoveran) верит, что в будущем начальная инфраструктура IT будет построена на основе архитектуры центрального (главного) процесса потому, что это особенно важно для IT и бизнеса. Соединение бизнеса и IT в целях оптимизации процесса - это доктрина, отстающая от BPM. Это то, что ни одно предприятие не может позволить себе игнорировать. Существует более чем один путь для достижения цели, и, конечно же, на этом пути нас ждут тупики и неудачи, мешающие нам в создании полноценной системы BPM, которая формируется топ-менеджерами для оптимизации работы. Но, по крайней мере, каждый может выбрать наиболее подходящий ему путь.
Об Авторе
Тони М. Браун - главный редактор BPM.com. Он также является редактором Technology For Finance, ведущего онлайн ресурса для технологии финансовых услуг. До этого, в течение четырех лет Тони был главным редактором Business Integration Journal. Он также консультирует клиентов на интегрированном рынке в вопросах стратегий коммуникаций и маркетинга.