Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

BPMN для людей и для роботов

Как в различных реализациях BPMN выглядит шаг процесса, выполняемый людьми? Чисто для иллюстрации возьмем процесс “От обращения до заказа” (Inquiry to Order) с шагами “Сделай это” (Do This, системный), “Согласуй договор” (Negotiate Contract, человеческий), “Сделай то” (Do That, системный) и смоделируем при помощи нескольких популярных инструментов.

itp commerce Process Modeler for Microsoft Visio:

Пример диаграммы itpc commerce Process Modeler

В отличие от остальных представленных продуктов, itp commerce не имеет процессного “движка”, только имитационное моделирование.

TIBCO Process Studio:

Пример диаграммы TIBCO Business Studio

Название swimlane (”Sales Manager”) у TIBCO - это просто лэйбл, не оказывающий какого-либо влияние на исполнение процесса. “Настоящий” исполнитель задается в виде атрибута задачи и на диаграмме не отображается.

Еще один подводный камень: у TIBCO студия позволяет намного больше, чем движок. Не удивляйтесь, если в момент загрузки диаграммы на сервер для исполнения у вас появится куча ошибок - это не ошибки в вашей диаграмме, а несовместимости студии и движка.

Oracle BMPS (также известный как BEA AquaLogic BPM или ALBPM):

Пример диаграммы Oracle BPMS

По умолчанию ALBPM использует собственную нотацию - для того чтобы приблизиться к BPMN, надо поменять визуальную тему, но даже и после этого соответствие BPMN остается не идеальным.

Зато, в отличие от TIBCO, студия и движок здесь состыкованы идеально. Приятно также и то, что помимо полноразмерных движков (их два - standalone и J2EE-based), есть еще движок встроенный непосредственно в студию. Эдакая “песочница”, позволяющая аналитику или разработчику быстро и без хлопот погонять процесс на своем компьютере.

Имя swimlane “SalesManager” четко определяет исполнителя. Это так называемая “абстрактная роль”, которой при загрузки диаграммы в движок ставятся в соответствие реально существующие пользователи, группы, роли.

И “герой” нашего парада - Intalio BPMS:

Пример диаграммы Intalio BPMS

Один прямоугольник превратился в четыре, и к ним добавились шесть стрелок. Да еще pool вместо ожидаемого swimlane. Воля ваша, но я пребываю в полном шоке. Причем что характерно: формально - 100% BPMN, по существу - издевательство.

Единственно, где это хоть как-то может прокатить,- STP (straight-through processing), в котором человек - это довесок к автоматическому на 95% процессу. Только если возникла исключительная ситуация и процесс отклонился от магистрали, человек должен его разрулить.

Ну а если мы имеем дело с “нормальным” бизнес-процессом, в котором людьми выполняется большинство шагов - представили себе во что превратится процессная диаграмма? Страшный кошмар. Просто не представляю - как можно предлагать такое человеческим существам? Программисты может это и проглотят, они ведь наполовину роботы :) но как быть с аналитиками и вообще с людьми бизнеса?!

Исключительно в тему - реплика известного независимого аналитика Sandy Kemsley в Intelligence Enterprise “BPM Focus Turns to People in the Process“. Только у нее все политкорректно, мол “кто-то кое-где у нас порой”:

It may seem obvious that you have to consider the people who are part of a business process, but there are many SOA-centric IT groups that really don’t consider people as first-class process citizens. Rather, they are viewed as being there only to handle specific exception steps when things go wrong in straight-through processing.

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

Для меня лично дать возможность IT и бизнесу разговаривать на одном языке - это не одна из многих фич, а родовой признак BPMS; если этой “магии” нет, то все остальное не в счет. К сожалению, реализация человеческих шагов в варианте Intalio делает эту систему чисто ИТ-шным инструментом, хотя они сами и утверждают, что она исключительно дружественна по отношению к бизнес-аналитикам. Очевидно потому, что на 100% соответствуют BPMN. Ага, только это BPMN для роботов, а не для бизнес-аналитиков.

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

02.02.09 | Статьи | , ,    

Комментарии (32)

  1. st 02.02.09 15:07

    а что Oracle со своим BPA и IBM?

  2. Anatoly Belychook 02.02.09 16:02

    В каком смысле “что”? Oracle BPA - это лицензированный у IDS Scheer моделер, у IBM сразу несколько продуктов гордо носят лэйбл “BPM”. Вообще целью этой заметки не было представить исчерпывающий обзор BPMN-моделеров - это совершенно безнадежное предприятие, тысячи их!

  3. Dmitry Gusev 02.02.09 16:18

    > Один прямоугольник превратился в четыре, и к ним добавились шесть стрелок. Да еще pool вместо ожидаемого swimlane. Воля ваша, но я пребываю в полном шоке. Причем что характерно: формально - 100% BPMN, по существу - издевательство.

    А представляете в каком шоке пребывает организация?
    Ведь в ее деятельности действительно каждой стрелочке/блоку BPMN от Intalio соответствует действие/документ.

    И не понятно кому вылезет боком то, что первые три диаграммы это скрывают.

  4. Anatoly Belychook 02.02.09 17:04

    Дмитрий

    Они не скрывают, они грамотно разделяют уровни абстракции.

    Разумеется, и в ALBPM, к примеру, вам тоже придется описать человеческую задачу более детально, чем просто нарисовав один квадрат. Но - и это очень важно - описание схемы процесса и деталей реализации шага, будь то системного или человеческого, в “правильной” (на мой личный вкус) BPMS разделены по уровням. Аналитик нарисовал схему из квадратиков - программист нарисовал/запрограммировал внутренности квадратиков.

    То, что у Intalio и то, и другое вынесено наверх, на мой взгляд является фатальной проектировочной ошибкой. Возможно, ошибкой не Intalio, а BPEL4People, но сути дела это не меняет. Сводить человека к вебсервису - себе дороже выйдет, никогда вы не переделаете мозги бизнес-аналитикам, чтобы для них такой взгляд стал естественным.

  5. Dmitry Gusev 02.02.09 17:29

    Лично я из этих диаграмм не вижу веб-сервисов вообще.

    Зато я вижу, что Sales работает с 4 документами и выполняет, как минимум, 2 операции, значимые для процесса.

    > у Intalio и то, и другое вынесено наверх

    Опять же я не вижу, чтобы на диаграмме Intalio было видно программирование или что-либо с этим связанное. Программист может также как и в других случаях, как вы выразились, “нарисовать/запрограммировать внутренности квадратиков” :)

    Зато в случае с диаграммой от Intalio я, как аналитик, могу увидеть, с какими функциями ИС сопряжен этот процесс, а в первых двух случаях - не могу.

  6. Anatoly Belychook 02.02.09 17:52

    Дмитрий, боюсь Вы не уловили суть дела. ОК, это я нечетко ее изложил.
    Как бы там ни было, нет тут ни 4 документов, ни 2 операций. Четыре квадратика на диаграмме Intalio - это фактически один шаг “согласовать контракт”, перегруженный сугубо технологическими подробностями:
    Negotiate Contract Before - это вызов веб-сервиса движка BPEL4People, создающего задание для определенного исполнителя.
    Negotiate Contract Create - движок генерирует форму для пользователя, получившему уведомление о задании и надумавшему его выполнить.
    Negotiate Contract Complete - пользователь выполнил задание, нажал соответствующую кнопку в веб-интерфейсу, движок BPEL4People посылает обратное уведомление в движок BPEL, исполняющее основное задание.
    Negotiate Contract After - движок BPEL стоит на этом шаге, дожидаясь уведомления от движка BPEL4People.

  7. Ismael Ghalimi 02.02.09 19:51

    Anatoly,

    Great article, and very good points regarding the Intalio product, and it’s uncanny ability to make many things a lot more complex than they should be. We fixed it with the upcoming 6.0 release, to be made available later this week. Here is a screenshot of how Intalio|Designer supports human workflow patterns now, I think you’ll like it better than the old way:

    http://www.intalio.com/wp-content/uploads/workflow-implicit-or-explicit-participants.png

    Best regards
    -Ismael

  8. AS 02.02.09 22:48
  9. Anatoly Belychook 03.02.09 12:10

    Ismael

    Great to see your comments here. Thank you for staying tuned on customers’ concerns.

    So you hide human task implementation details into a subprocess. Good move - it resolves the major issue noted here and makes the business logic clear. The negative side effect if I got it right will be compromised subprocesses: now there will be “real” subprocesses and “pure technical” ones for human tasks.

    Anyway, let me wish your company a big success with the upcoming release, you must have hot time these days.

    Kind regards
    Anatoly

  10. Anatoly Belychook 03.02.09 12:57

    Alexander

    It’s OK to see human internals at hospital surgery but our case is like meeting a man on a street with his belly wide open :)

    I agree, Intalio makes a heroic job. However with all my sympathy to them I have a personal minimal set of requirements:

    1) The modeling tool must be simple enough for an ordinary business analyst being able to draw a process diagram - i.e. it shouldn’t be much harder to learn and to use than typical Visio drawing tool. Implementation details of either system or human tasks should be hidden e.g. in a separate “perspective”. Analysts don’t care whether it’s BPEL-based or not. The BPMN standard may permit using pools for internal participant instead of swimlanes to satisfy certain BPMS vendors needs but let’s get to the ground: swimlanes were invented by Geary Rummler long before BPM. We are not going to make an army of analysts forget their traditional vision and accept ours, are we?

    2) It should also be simple enough for an ordinary business person to read the diagram without systematic training. It happened in my practice several times that an executive pointed out a mistake in the process diagram presented by a team of analysts, consultants and developers. It saves you tremendous amount of time, money and efforts when it happens. And after all this is exactly “bridging business-IT gap”, one of the biggest BPM promises.

    3) Analyst’s and developer’s perspectives should be two layers of a single process description. No generation, transformation and/or conversion and roundtripping problem that they cause.

    4) Zero coding is a must for initital stages of BPM project. An analyst should be able to execute a process diagram without developer’s help. It means that there must me a kind of automatically generated prototype of BPM application. From my exeperience, this is the only way to validate the process model before investing into UI and system interactions development. Again, such validation can save you 3-5 cycles of your development which means a lot of time and money. The production system is quite different story: I don’t buy the idea of production UI made by a mouse click. I can see very clearly in every our project that end users need highly polished UI that can only be built manually.

    AB

  11. AS 03.02.09 14:12
  12. Anatoly Belychook 03.02.09 15:39

    Alexander

    Our concerns slightly differ: you are talking about the best BPM system one can think of while I’m only worrying about the best I can get from existing BPMS today or tomorrow.

    The time lag between DBMS and BPMS technologies is about 20 years - it gives the rough idea about when BPM standards may become stable. We are at 1989 of DBMS calendar today: SQL-92 is 3 years ahead and ODBC will become mainstream in 10 years. This makes me pessimistic about BPM standards to become stable any time soon. Is BPMN the last standard? I’m not sure and hence BPMN compliance isn’t the top priority for me.

  13. Dmitry Gusev 03.02.09 16:05

    > Дмитрий, боюсь Вы не уловили суть дела. ОК, это я нечетко ее изложил.
    > Как бы там ни было, нет тут ни 4 документов, ни 2 операций. Четыре квадратика на диаграмме Intalio - это фактически один шаг “согласовать контракт”, перегруженный сугубо технологическими подробностями:

    Постараюсь изложить свой комментарий на английском, чтобы не показаться невежливым к нашим англоязычным коллегам :)

    Ok, I understand your point of view. But don’t you think the four steps are not just technological details which analyst can skip? I agree, there could be some implementation details like BPEL assignment statements that could be thrown away of the process’ diagram.

    But how would you tie your process with not only people involvled to the process, but with other IT assets?

    This is not such an obvious thing how the Sales from the example above will interact with the process. Sales doesn’t have any pluggable interface to control his behaviour.

    I mean, you as a process analyst should know exactly _how_ Sales will interoperate with the process, and this is meaningful for IT utilization also. Using such details from the diagram above I can see there is no some enterprise application involved to the process and this is a manual task.

    And, by the way, from this point of view it sounds reasonable to hide these implementation details to the subprocess.

  14. Anatoly Belychook 03.02.09 17:08

    Dmitry

    Sorry but you are broadening the scope of the discussion. All I wanted to show is this: *any* atomic human task transforms into 4 activities and 6 flows when implemented in Intalio. This is unacceptable from analyst’s perspective. The key word here is *any*, the content of the process example is irrelevant. If you admit that a process may have human tasks then you are in trouble; higher percentage of human tasks means tougher troubles.

    Please don’t be so focused on enterprise applications, interfaces, connectors etc. Let’s assume for example that there is an activity named “dig a hole in the ground”. Are you going to develop a computer interface to an excavator for this task? Come on, let’s better assign a human task to the manager carrying necessary information (where, how wide/deep the hole should be) and let him just press “done” button on the activity web form when it’s done.

    Generally speaking, neigther analyst nor process owner do *not* need to know exactly how sales guy or other employee performs his task. People aren’t robots - did you hear the term “knowledge worker”? And process management isn’t about this - it’s about the sequence of tasks, the outcome they provide and resources they consume, including time. As a process owner or analyst I don’t care whether he/she makes phone calls to the customer to agree the contract, meet him personally etc. on the condition that it’s done successfully under given time constrains.

    We can also talk about system activities and/or details of sales manager everyday duties but it’d be another topic.

  15. Keith Swenson 04.02.09 18:55

    Consider carefully what is being modeled and what the purpose of the diagram is, and you will find a clue to how flexible and adaptable the diagram is.

    Many BPM systems are drawing a picture of the flow of bytes between systems. The diagram make explicit when a bundle of bytes is transferred from one place to another. You can theoretically model anything with a picture of the data that is sent and received.

    Other BPM systems draw a picture of the responsibility that the people carry, and purposefully hide the detail of how the information is transmitted around the system. In these systems a person will be assigned responsibility for doing a task, but the system then “takes care” of communicating this to the user, as well as allowing for a variety of different interaction modes. Consider an email message: you put the address of the recipient, but you do not have to specify exactly what systems send bytes to other systems: that is actually very complex and is a distraction to your goal.

    There is no right-and-wrong here: There are some people concerned about how bytes flow through the system and they want to be able to see that. But there are others who want to be able to easily represent and modify responsibilities; the detail of how messages are going to be sent is not just a distraction, but actually a hindrance to achieving their goals.

    While you are looking at how representations compare, you might want to consider this standard example process adopted by OMG ten years ago:

    http://www.xpdl.org/nugen/p/troubleticketscenario/leaf.htm

    -Keith

  16. Anatoly Belychook 05.02.09 00:14

    Keith

    Thanks for the link and for sharing your opinion here. But sorry can’t fully accept it.

    Sure there are people more interested in activities flow (let me call them analysts for simplicity) and those more interested in bytes flow (developers). Of course both aspects should be covered by a process model.

    Basically we have two options here:
    1) “tasks-and-bytes” diagram presents both aspects visually like Intalio does;
    2) “tasks-only” diagram models graphically only tasks flow and hides bytes flow elsewhere e.g. in task attributes or a screenflow.

    If we were robots then richer diagram would automatically mean better diagram so we’d take “tasks-and-bytes”. But business people and business analysts are unable to work efficiently with this kind of diagrams - at least those I know. So if we want to have them onboard we must take “tasks-only”. Developers may prefer “tasks-and-bytes” but they are able to use “tasks-only” too. So there is no symmetry.

    And if we don’t have analysts and developers in one team working on the same process model then we fall back to old good “process automation” with analyst-developer handout of paper process diagrams. Some people may call it BPM but isn’t it stupid to invent a new acronym (let’s pretend BPM is relatively new) and then use it for things we were doing for decades? For me, if it doesn’t help bridging business-IT gap then it isn’t BPM.

    – AB

  17. Julia Wagner 05.02.09 18:25

    But who needs a diagram generally? Or rather, whether it essential for developer? He’ll go a back way more likely – at first will program actions, and then will present them in the form of the diagram to show them to analytics. Therefore if you are not care the processes should be design by analysts you should not be care of their existence at all. Then it is possible to tell simply: «hi, traditional program development, goodbye BPM!»

  18. Александр 04.09.09 10:35

    Интересны Ваши публикации.Хотелось бы познакомиться с пракимчески реализованными проектами.Александр.

  19. Anatoly Belychook 04.09.09 11:04

    Приходите на семинары bpms.ru, они задуманы как раз для разбора кейсов.

  20. Кузин Сергей 21.10.09 12:14

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

  21. Anatoly Belychook 21.10.09 14:52

    Сергей, простите, что значит “полагаю”? Попробуйте, убедитесь. Весь сюрприз как раз в том и заключается, что нельзя. Раз уж Ismael Ghalimi (глава компании) в своем комментарии это не опроверг, то наверное так оно и есть. Хотя некоторые шаги к улучшению положения они предприняли.

  22. Кузин Сергей 21.10.09 16:30

    Попробовал, конечно, до того, как написать предыдущий пост - получилось.

    http://imglink.ru/show-image.php?id=30b615a950ef64e01cd686cc84f521e3

  23. Кузин Сергей 21.10.09 16:37
  24. Anatoly Belychook 21.10.09 16:45

    Спасибо. Что ж, это конечно большой прогресс по сравнению с тем, что было в прошлой версии, с которой я экспериментировал. Как и обещал Исмаэль, они упрятали четыре шага в нечто типа подпроцесса. Но все равно получилось слегка извращенно. К примеру, с какой стати шаг “do that” становится активным сразу после “do this”?

  25. Anatoly Belychook 21.10.09 16:48

    Второй вариант еще лучше. Остался один вопрос: зачем тут message flow, когда по существу это передача управления, т.е. control flow? Очевидно из технологических соображений. Впрочем согласен, с этим уже можно работать. Еще раз спасибо.

  26. Кузин Сергей 21.10.09 17:26

    Насколько я помню, между пулами в BPMN взаимодействие между пулами как раз и отображается с помощью message flow. Так что первая картинка была “более правильной”. И мне кажется, что в задании “Do That” должно быть изображение задания. ожидающего сообщения (не нашёл в Intalio, но вроде бы есть в Visual Paradigm).

    Что касается control flow, то в BPMN 1.1 сразу попалась следующая цитата:

    BPMN does not use the term “Control Flow” when referring to the lines represented by Sequence Flow or Message Flow.
    The start of an activity is “controlled” not only by Sequence Flow (the order of activities), but also by Message Flow (a
    message arriving), as well as other process factors, such as scheduled resources. Artifacts can be Associated with
    activities to show some of these other factors. Thus, we are using a more specific term, “Sequence Flow,” since these
    lines mainly illustrate the sequence that activities will be performed.

    Кстати, использовал Intalio Designer 5.2.1.158, скачанный 25.02.2009, что по дате довольно близко к времени выхода статьи. И, если не затруднит, подскажите, пожалуйста, откуда появился пример из Intalio?

  27. Anatoly Belychook 21.10.09 17:36

    Конечно между пулами может быть только message flow. Только зачем тут отдельный pool?

    Я имел в виду sequence flow.

    Да, я использовал версию 5. Думал, Вы использовали версию 6. Пример сделан в соответствии с документом Intalio, описывающем как следует моделировать шаги, исполняемые людьми. Кажется я догадываюсь почему у Вас так просто получилось: нарисовать можно все что угодно, но не все движок способен исполнить.

  28. xtlan 21.10.09 22:13

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

  29. Gustavo Gomez 05.11.09 14:48

    Anatoly,
    if you look at the BPMS out here you will find different paradigms in place:
    1. Some of them are Visual Programming tools: they were developed from an IT perspective, assimilating an “activity” with a “procedure” and defined its “parameters” as variables that go in and out of the activity (e.g., black box). Forget about bridging IT and business gaps and judge the productivity increases yourself.
    2. Other tools look at the process layer from the business perspective, and people are therefore first class citizens. Then they define how to aggregate and present them with the appropriate information so that they can perform their task more efficiently. This approach corresponds more to what you are looking for.
    Regards
    Gustavo

  30. Anatoly Belychook 05.11.09 15:06

    Gustavo

    Thank you for the input. Generally agree with your comment but I’d like to note that declared paradigm is one thing and implementation is the other. I guess there is no vendor not pretending to bridge “the gap” (BTW, it suddenly has become obsolete - the new talk is about “closing the gap”) and to treat human users with due respect. Yet even a brief look at the product sometimes says more than declarations - in fact this was the point of the original post.

    -AB

  31. Александр 09.02.12 04:21

    А что мешает в Intalio “нарисовать” процесс аналогично предыдущим примерам?

  32. Anatoly Belychook 09.02.12 08:47

    Александр

    Нарисовать можно - работать не будет.

Комментирование закрыто

Copyright © 2008-2024 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии