Наверх

Почему Workflow "не тянет"

Время чтения: 6 минут
7
Почему Workflow

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

Джон Пайк,

руководитель Process Factory

Многим из тех, кто имел дело с 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 «не тянет», потому что игнорирует требование вовлечения людей.

Перевод BPMS.RU

Источник: BPMS.RU

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

Комментарии 7

Системы BPM, не интегрированные в ECM проигрывают именно из-за того, что не всегда наследуют функцции WF. В ЕСМ оставяют функции WF и дополняют из функциями и сервисами BPM. Очень даже здорово запустить в БП задание пользователю и обработать созданный пользователем документ функцией XSLT, чтобы сформировать удобный для размещения на сайте документ. А затем в том же БП разместить документ на портале. Игнорирование наследия WF обедняет BPMS.
 

Александр, боюсь Вы не совсем верно ухватили суть статьи... BPMS "на генетическом уровне" унаследовали не только функционал WF, но и все его (или ее) "наследственные заболевания". Автор упирает на то, что современные "паттерны" WF и BPM реализуют очень ограниченное число видов взаимодействия "человек-человек". Приведен пример только одного вида взаимодействия "А дает задание, Б его выполняет". На самом же деле видов взаимодействия "человек-человек" гораздо больше, возьмите ту же игру в гольф. И прорыв в этой области (имею в виду WF и BPM, не игру в гольф) возможен только с появлением технологии (точнее идеологии), которая бы как раз отражала если не все, то большое количество моделей взаимодействия. Автор, например, связывает свои надежды с KIBPM.

Думаю, приведенный Вами пример с созданием и обработкой документа функцие XSLT не имеет отношения к вопросу, который поднял в статье автор.
 

Семейный "скелет в шкафу" никого не интересует. Спонтанность мысли не всегда приветствуется, особенно в процессах E-Supply Chain. Представьте, заказчик не играет в гольф, а кропотливо отслеживает ход исполнения заказа. Ему вовсе не интересен ход спонтанной мысли поставщика, решившего запустить более приоритетный заказ. Даже если Система научится подсказывать, какие заказы можно притормозить, чтобы получить наибольшую прибыль, выгоды он не получит. Такой поставщик долго не протянет., репутация побежит впереди его демпинговых предложений. К SOA придираются только потому, что нельзя все свести к единой спецификации преобразований. Нужно создавать функциональные запросы и преобразования, а затем интегрировать их в БП. Если рассматривать SOA как панацею в интеграции данных, то это утверждение в корне неверно.

Александр, давайте не будем отходить от темы и все, что есть в этой жизни, сводить к XML и XSLT-преобразованиям. Думаю, согласитесь с тем очевидным фактом, что цепочки поставок - это частный вид взаимодействия, причем не столько отдельных исполнителей, сколько коллективов таких исполнителей (я имею в виду юридических лиц). Если же заглянем "внутрь" компании, то обнаружим не только взаимодействие вида (я уже упоминал это) "А дает задание, Б его выполняет", но и такие виды взаимодействия, как "дружеский совет", "обращение к более опытному товарищу", "мозговой штурм", "нагоняй", "вызов на ковер", "рекомендация", "отправка на n-ное количество букв" и массу других.Такие виды взаимодействия отражают природу человека (читай здесь спонтанность, способность к творческому озарению, способность прийти на помощь). Скажу по секрету, "очеловечивание" взаимодействия "человек-система", и что более важно (хотя и кажется на первый поверхностный взгляд бредовым) "человек-человек" - одна из глобальных тенденций. Появление Web 2.0, Social Computing (ICQ, Wiki, Blogs, Skype) как раз является отражением этой тенденции.
 

Для дружеского общения в серьезных ECM используется модуль коллективной работы с чатом, конференциями, опросами и рейтингами. Из модуля есть доступ к документам и БП ECM. В нем же ведется и проектная работа с графиками работ и ресурсами. Из модуля открывается доступ через SOA к корпоративным приложениям. Модуль построен по технологии портала. Весь WEB сейчас развивается с использованием метаданных. Метаданные и помогают решать взаимодействие "человек - человек".

А что используется для серьезного общения в дружеских (точнее дружественных) ECMS?

Максим Галимов 23 января 2008

Мыслить в идеологии SOA — четко представлять себе сервисы и понимать, что потоки работ/данных между ними могут быть произвольными (в определенных рамках, конечно).

Мыслить в идеологии BPM — отталкиваться в первую очередь от потоков работ, четко представляя себе все возможные ветвления и зависимости, а обработчики (в частном случае сервисы) подчинять этим потокам.

Мыслить в идеологии Workflow — отталкиваться от потоков работ, ориентируясь в первую очередь на исполнителей-людей (роли и т.д.).

Существуют задачи, которые лучше решаются с той или иной позиции.

Но с учетом того, что документооборот на 80% бумажный, и все неавтоматизированные операции нужно контролировать людьми, первым и наиболее заметным шагом в сторону автоматизации управляемости процесса будет внедрение workflow.

Но использовать только одну идеологию для полноценной автоматизации взаимодействий в компании невозможно. Как и все три враз не дадут полноценного эффекта.

Чтобы прокомментировать, или зарегистрируйтесь