Литература:

• Статьи
• Обзоры
• Форумы
• Стандарты
• Книги
• Авторы

Автор: By Jon Pyke, CEO, The Process Factory

Оригинал статьи: http://www.ebizq.net/hot_topics/bpm/features/7462.html?page=1

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

Что ж, теперь эти дискуссии закончились, демаркационные линии проведены; и перед нами лежит ясная дорога.

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

Но и BPM тоже изменился. Вместо того, чтобы стать расширением концепции Workflow, BPM теперь воспринимается как system-to-system технология, использующаяся исключительно для развертывания SOA решений. Я сознательно упрощаю, но ведь действительно складывается впечатление, что BPM становится ИТ-решением, в противоположность решению для бизнеса, каковым он по сути должен являться. Где-то по дороге один из ключевых элементов бизнес-процесса – человек – выпал из повестки дня. Тот факт, что большинство бизнес-процессов (около 85% согласно Forrester) включают в себя бумажный документооборот, был выпущен из виду. Подумайте на минуту о BPEL –разработка данного конкретного стандарта ничего не говорит вам об общем направлении, в котором движется BPM? Причем имейте в виду: многие вендоры будут рассказывать вам, что их BPM-продукт поддерживает взаимодействие между людьми, но при этом они будут подразумевать под этим простую работу типа выполнения заданий и заполнения форм. От этого до поддержки совместной работы и управления взаимодействием, о которых пойдет речь ниже, путь неблизкий.

Корень бед в том, что многие Workflow продукты изначально имели изъяны, и в итоге BPM унаследовал эти проблемы на генетическом уровне. Что же было не так с Workflow? Это очень просто, если вдуматься: большинство Workflow продуктов были рассчитаны на то, что работа передается от одного исполнителя к другому. Один пользователь вводит подробности запроса о кредите, другой его утверждает. Но бизнес так не работает!

Этот порочный взгляд вероятно стал основной причиной, по которой Workflow так и не достиг того успеха, которого он заслуживал по мнению ученых мужей. Просто предлагаемые решения оказались недостаточно гибкими, так как большинство процессов не соответствуют такому стилю работы. Парадоксальным образом, по этой же причине BPM так хорошо подходит для мира SOA и system-to-system процессов. Системным процессам необходима жесткость; там же, где в игру вовлечены люди, все решает гибкость.

Почему же нам так нужна гибкость?

Чтобы облегчить понимание этой концепции, проведу простую аналогию.

Предположим, вы играете в гольф. Использование подхода BPM – это как если бы вы всегда попадали в лунку с первого удара. Впечатляет: 18 ударов, и раунд заканчивается за 25 минут.

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

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

Предсказуемые виды процессов проще и достаточно хорошо реализованы в BPM-системах. Это одна из причин, почему термин Business Process Management зачастую неправильно употребляется – это происходит в тех случаях, когда его воспринимают как технологию, нацеленную исключительно на интеграционные задачи. Если принять во внимание тесную связь с SOA (SOA нуждается в BPM, но обратное утверждение не верно), то такой BPM стоило бы переименовать в Services Process Management (SPM).

Изобретение BPEL4People вряд ли решит проблему – он не сулит ничего, кроме повторения недостатков Workflow, а сложность и стоимость внедрения останутся такими же высокими, какими они всегда и были. Каждый, кто готовил бизнес-обоснование для приобретения SOA/BPM знает – результирующее предложение получается безнадежным.

Понимание того, что существует два уровня бизнес-процессов («полупроводниковые» и «бумажные») выводит нас на путь, ведущий к решению. Ключевой момент: необходимо осознать, что непредсказуемость «бумажной» составляющей не сводится к ad-hoc процессам или к обработке исключений (расспросите об исключениях кого-нибудь с опытом Six Sigma, и вы очень быстро поймете, что я имею в виду). Я говорю о неструктурированных взаимодействиях между людьми – в частности, между людьми умственного труда. Неструктурированные и непредсказуемые взаимодействия могут происходить и в действительности происходят постоянно – и дальше будет только хуже! Появление Web 2.0, Social Computing (ICQ, Wiki, Blogs, Skype), SaaS (Software as a Service) и т.д. и т.п. уже оказывает и будет оказывать в дальнейшем сильное влияние на то, как мы ведем бизнес и как им управляем.

Следующим логическим шагом станут такие основанные на процессах технологии, которые будут учитывать потребности людей и поддерживать врожденную «спонтанность» человеческой мысли; есть сильное искушение назвать такое потенциальное изменение парадигмы «Knowledge Intensive Business Processes » (KIBPM).

KIBPM делится на две основных категории, которые со временем возможно сольются, и вендоры, которые осознают этот потенциал, смогут незаметно вырваться вперед. На простейшем уровне мы имеем case-management, на втором – управляем взаимодействием между людьми. Я сомневаюсь, что сегодня на рынке есть много BPM-продуктов, способных пережить такое тектоническое изменение требований. Определенно не смогут продукты, основанные на BPEL и SOA; более того, любому продукту, вышедшему на рынок более пяти лет назад, потребуется серьезное хирургическое вмешательство, чтобы он смог дать ответ на предстоящий вызов.

Итак, почему же Workflow «не потянул»? Да потому, что он основывался на фатальном предположении, что процесс моделируется просто «от А к B к С…». Но как мы знаем, бизнес так не работает. BPM имел успех благодаря наследию, полученному от Workflow. Но и BPM «не тянет», потому что игнорирует требование вовлечения людей.

Об авторе

Jon Pyke - одна из наиболее влиятельных фигур в BPM-секторе. В настоящее время - руководитель Process Factory, в прошлом - технический директор Staffware, нынче известного как TIBCO. Более 12 лет - это значительный стаж, позволяющий считать автора одним из основателей BPM, как культуры. Он автор многих определений, которые используются в BPM. Как основатель и председатель Workflow Management Coalition (WfMC), следит за разработкой стандартов. 

Комментарии