Результаты тренинга «Практика BPMN» 11.12.10

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

Начнем с первого процесса. Первоначально он назывался «Обновление релизов», но в итоге был переосмыслен как «Внедрение обновления учетной системы».

Исходная постановка задачи:

Имеется унифицированное ПО, разработанное сторонним разработчиком (на базе 1С:УПП), унифицированная методология ведения учета, унифицированная НСИ – справочники, содержание которых должно быть одинаковым на всех предприятиях холдинга (15 предприятий). Изначально на всех предприятиях стоит одинаковая версия ПО. В процессе задействованы:

  1. Разработчик (сторонняя организация) – периодически выпускает новые релизы по нашим заявкам
  2. Центральная служба сопровождения (ЦСС) – ОДНО специальное центральное подразделение в управляющей компании в Москве, которое управляет взаимодействием с разработчиком и с региональными службами сопровождения.
  3. Региональные службы сопровождения (РСС) – МНОЖЕСТВО региональных подразделений, каждое при конкретном предприятии холдинга.

Ни ЦСС, ни РСС не имеет права модифицировать конфигурацию ПО. Все изменения в ПО производятся централизовано, при этом обеспечивается единообразное содержимое унифицированных справочников на множестве площадок и использование одного и того же релиза унифицированного программного продукта всеми площадками. При этом в БД каждой площадке присутствует масса специфической для этой площадки информации (проводок, содержимого неунифицированных справочников и т.д.).

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

ЦСС проводит вторую фазу тестирования и, если она завершается успешно, сообщает об этом разработчику, публикует релиз на общем ресурсе холдинга и оповещает все РСС о необходимости тестирования нового релиза.

РСС проводят третье тестирование – на своих данных и со своей спецификой. При этом на одних РСС тестирование может быть успешным, а на других закончиться аварийно. Если хотя бы на одном РСС тестирование выявило проблемы, вся процедура установки релиза прерывается на всех предприятиях и информация о выявленных ошибках передается разработчику. Диспетчеризацией и отслеживанием сроков тестирования занимается ЦСС.

Если все РСС сообщили в ЦСС об успешном тестировании, ЦСС рассылает специальное оповещение о фиксации релиза. После чего релиз устанавливается на «боевую» БД на всех предприятиях холдинга, а разработчик получает оповещение об успешной фиксации.

Идеология фиксации релизов срисована с идеологии фиксации распределенных транзакций службы MS DTC. :)

Имеется один нюанс, на который обращаю внимание. Если в течение отведенного срока с какой-нибудь РСС не поступит сообщение ни об успешно проведенном тестировании, ни об ошибках (иногда такое случалось на ранних стадиях запуска этой схемы), ЦСС «по умолчанию» считает, что тестирование проведено УСПЕШНО. Если же предприятие потом сталкивается с проблемой установки релиза потому что своевременно не провело тестирование, то эта проблема требует в 10-20 раз более высоких затрат времени и денег для ее устранения. И эти расходы несет виновное предприятие, при этом в работе данного предприятия могут возникнуть перебои из-за того, что программа просто перестала работать. Такой «драконовский» регламент позволил вымуштровать РСС и заставить регионы всегда проводить тестирование своевременно.

В каждом РСС и в ЦСС имеется своя «тестовая версия» с реальными данными, которые копируются из «боевой БД». На этой версии производится тестирование. Однако, к моменту завершения тестирования актуальность данных в «боевой» БД уходит во времени вперед. Поэтому требуется последующее повторное наложение на боевую БД.

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

Как видим, процесс достаточно хорошо формализован и обладает вполне понятной ценностью для бизнеса.

Схема процесса в первом, эскизном приближении:


Процесс «Обновление релизов»

Проблемы этой диаграммы:

  1. Чрезмерная сложность. Впрочем, для начальной стадии разработки это нормально: структура процесса – понимание того, как надо процесс разбивать на подпроцессы – обычно приходит только после того, как попытка разместить все шаги процесса на одном уровне приводит к «спагетти» типа изображенного выше.
  2. Автор перемудрил с сообщениями и циклами по объектам. Непонятно, как сообщения о завершении тестирования РСС найдут «свои» потоки в циклах по объектам, которые их дожидаются. Это распространенная ошибка, а правильное решение – выполнять всю работу, которую автор вынес в отдельный пул, в рамках подпроцесса внутри цикла по объектам.
  3. В данной задаче не имеет смысла объединять в один процесс тестирование РСС и фиксацию релиза – это приводит к лишнему усложнению. Если рассматривать их как два независимых подпроцесса, то мы избавимся от необходимости синхронизации при помощи сообщений при переходе от тестирования к фиксации – заметное упрощение.
  4. Можно придраться и к постановке задачи: в ней не учитывается различие между релизом и билдом. Согласно схеме, если обнаруживается ошибка, процесс завершается, т.е. предполагается, что после того, как разработчики ее исправят, мы запустим новый экземпляр процесса. В жизни обычно все происходит иначе: после исправления ошибки разработчики выпускают новый билд, но все же работа продолжается над тем же самом релизом с той же самой запланированной функциональностью. В итоге, после энного числа билдов, релиз доводится до работоспособного состояния и внедряется. С точки зрения бизнеса нам было бы интересно знать суммарное время, потраченное на внедрение релиза. Более правильной была бы схема, в которой обнаружение ошибки приводит к завершению не процесса, в всего лишь очередной итерации цикла.

Опуская все поиски и промежуточные версии – в итоге группа пришла к следующей структуре процесса на верхнем уровне:


Процесс «Внедрение обновления учетной системы»

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

Подпроцессы «Тестирование ЦСС» и «Управление тестированием РСС» могут закончиться либо успехом, либо выявлением ошибки. Мы могли бы проверить результаты этих подпроцессов при помощи развилок «или-или» после завершения первого и второго подпроцесса, но предпочли более изящные способ – прикрепленное событие «ошибка». В случае неудачи тестирования на любом этапе мы сообщаем разработчику по электронной почте, что мы ждем от него новый билд с исправленными ошибками, и идем на новый круг тестирования.

Соответственно, подпроцессы тестирования, обнаружив ошибку, должны отправить по электронной почте сообщение разработчику с описанием выявленной ошибки и сгенерировать событие «ошибка». Вот как это делается в подпроцессе «Тестирование ЦСС»:


Подпроцесс «Тестирование ЦСС»

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

Тестирование РСС – подпроцесс более сложный: в нем надо предусмотреть таймер, который будет ограничивать время тестирования (5 дней) и прерывать все потоки тестирования, когда время истекло или один из процессов выявил ошибку. В общем случае это делается при помощи сообщений, транзакций и компенсаций. Но в данной задаче дело сильно упрощается благодаря тому, что в работе никогда не бывает одновременно больше одного релиза. Это позволяет использовать для коммуникаций сигналы и обойтись одним пулом.

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

В данном же случае все процессы тестирования РСС запускаются по отмашке «дирижера» – подпроцесса «Управление тестированием РСС»:

Подпроцесс «Управление тестированием РСС»

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

В отдельном потоке контролируется срок, и когда он истекает, управляющий процесс генерирует сигнал «истекло время тестирования РСС». Получают сигнал потоки тестирования РСС, которые к этому моменту не завершились:


Подпроцесс «Тестирование РСС»

Когда возникает сигнал «истекло время тестирования РСС» от управляющего процесса или сигнал «тест РСС не прошел» из другого потока тестирования РСС, исполнение шагов подпроцесса «Работа РСС по тестированию» немедленно прекращается, и управление переходит к обработчику соответствующего сигнала.

Что касается обработчика сигнала, группа рассмотрела несколько вариантов:

  • Просто завершить процесс – негуманно. Представьте себе, что вы выполняете задачу, скажем, «Тестировать функционал». Вы ее выполнили, нажали на кнопку, и тут портал BPMS сообщает вам, что задача, которую вы пытаетесь завершить, больше не существует. (Именно это произойдет, если пока вы работали над задачей, истекло время или в другом потоке тестирования была выявлена ошибка.) Мягко говоря, пользователь будет в недоумении.
  • Информировать пользователя по email, что подпроцесс прерван аналогично тому, как мы информируем разработчика – тоже плохо, ведь он в данный момент работает не с почтой, а BPM-порталом. Если взамен прерванной он тут же получит задачу «Истекло время теста РСС», это будет более понятно.
  • Но тут возникает другая проблема: а что, если он вообще думать забыл о тестировании? Пока он не войдет в портал и не кликнет по заданию, подпроцесс будет оставаться активным. Чтобы от этого застраховаться, мы поставили на информирование таймер в 1 час.

С отправкой и обработкой сигнала «тест РСС не прошел», надеюсь, все ясно.

Итак, в итоге мы получили четыре диаграммы вместо одной. Но посмотрите, насколько прозрачной стала логика! Число шагов на одной диаграмме близко к оптимальному: от 6 до 9 (не считая подпроцесса «Управление тестированием РСС», где их всего два), никаких проблем с дальнейшими усовершенствованием процесса нет.

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

Более интересной группа сочла идею расширить рамки процесса – ведь внедрение релиза это на самом деле «хвост» процесса, который начинается с потребности в доработке учетной системы (возможны и другие стимулы к выпуску нового релиза, но мы сосредоточились на этом одном).

На первый взгляд процесс выглядел просто:

  1. Рассмотреть заявку на доработку
  2. Запланировать доработку
  3. Выполнить доработку
  4. Внедрить доработку

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


Процесс «Доработка учетной системы»

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

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

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

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

И последнее замечание относительно объекта данных, обозначенного на схеме как «БД заявок на доработку»: при использовании BizAgi BPMS ее даже не придется специально создавать. В этой системе реализовано очень удачное решение: каждому процессу соответствует определенная таблица в БД, и для каждого нового экземпляра процесса система автоматически создает новую запись в этой таблице. Нетрудно заметить, что «БД доработок» – это и есть процессная таблица бизнес-процесса «Заявка на доработку учетной системы».

Вообще же все схемы, разработанные на этом тренинге, готовы к исполнению BPMS. Правда не каждой BPMS, поскольку не каждая BPMS поддерживает сообщения и сигналы. (А по правде говоря, таких BPMS на удивление мало.) Но в BizAgi BPMS все схемы будут работать. Но это уже тема для следующего тренинга «BPM103: Исполняемый BPMN».

Запись опубликована в рубрике Отчет. Добавьте в закладки постоянную ссылку.

12 комментариев: Результаты тренинга «Практика BPMN» 11.12.10

  1. Кузин Сергей говорит:

    Молодцы коллеги, грамотно отработали! Поздравляю!

  2. Сергей Кузин говорит:

    Странно, но предыдущий комментарий не был добавлен. Повторяю..

    Есть ряд замечаний и вопросов:

    1. Процесс «Внедрение обновления учётной системы»:
    1.1. Стартовое событие можно было бы изменить на Message, раз уж процесс стартует при получении сообщения о готовности релиза;
    1.2. Почему на шагах с e-mail стоит скрипт, а не отправка сообщения?
    1.3. Между шагом «e-mail: ожидаем новый билд» и развилкой добавил бы промежуточное событие ожидания сообщения о выпуске билда;
    2. Процесс «Управление тестированием РСС»: добавил бы исключения к шагу «Тестирование РСС», иначе диаграмма неполна и возникает путаница со следующей диаграммой.

  3. Анатолий Белайчук говорит:

    Сергей

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

    Относительно предложения добавить исключение к подпроцессу «Тестирование РСС». Вопрос: это исключение будет относиться к циклу или к одному из потоков в цикле? Причем какой бы вариант ответа на этот вопрос ты не дал, есть ли уверенность, что другие читатели диаграммы, включая такого специфического «читателя», как движок BPMS, ответят на него так же?

    Поэтому лучше не надо. Причем в буквальном смысле не надо, т.е. не требуется. Прелесть представленной схемы в том, что в ней каждый поток подпроцесса «Тестирование РСС» всегда так или иначе завершается – либо тем, что тестирование успешно вышло, либо одним из двух сигналов. Все потоки завершаются, цикл по объектам в процессе «Управление тестированием» тоже завершается без приключений, процесс анализирует были ли ошибки и идет по одному или другому маршруту.

    По-моему, все стройно и логично. А вот если прикрепить обработчик события к циклу по объектам, тогда путаница действительно возникнет.

  4. Кузин Сергей говорит:

    Анатолий, правильно ли я понимаю, что в «аналитическом» стиле стиле моё предложение, скажем, с промежуточным событием ожидания билда, было бы вполне корректно, но вот если я после этого стал бы моделировать «исполняемую» диаграммму, то аналитическая была бы изменена на ту, которая приведена выше? То есть по факту сначала моделируем «бизнес модель» = «аналитическая», затем трансформируем в «модель» = «исполняемая», совсем как модели в RUP?

  5. На тренинге был рассмотрен предложенный мною бизнес-процесс.

    Прежде всего, я хочу поблагодарить Анатолия Белайчука за тот существенный объем знаний, который он сумел передать нам всего за два занятия.

    Вот мое резюме:

    1. Анатолий Белайчук – талантливый преподаватель (без ложной скромности).

    2. BPMN – это не так просто как может показаться на первый взгляд. Она требует к себе уважительного отношения. Нужно понимать много нюансов, чтобы некая совокупность квадратиков, кружочков и линий смогла принять очертания исполняемого процесса, причем исполняемого ТАК КАК БЫ НАМ ХОТЕЛОСЬ.

    3. BPMN содержит массу возможностей для «просто рисования», которое позволяет получить достаточно понятный бизнес-процесс, но который при этом не будет исполнимым. Лично меня это в некоторой степени смущает и сбивает с толку, потому что я изначально был нацелен на построение только исполнимых шаблонов БП.

    4. Один и тот же процесс, оформленный «для объяснения людям» и «для исполнения» может выглядеть по-разному. И иногда процесс «для исполнения» может оказаться уже менее понятным для менеджеров и бизнес-аналитиков, поскольку содержит технические и технологические включения, связанные с функционированием движка BPMS и с используемой моделью данных.

    5. Так же как в программировании, для BPMN существует «плохой стиль» и «хороший стиль». И для BPMN «хороший стиль», возможно, даже еще более важен, чем для программиста при написании программы. Имея опыт работы программистом, я могу утверждать, что вероятность ошибки при написании текста программы существенно меньше, чем при составлении схемы в нотации BPMN. И причина тут кроется в том, что BPMN оперирует большим количеством задач, исполняемых ОДНОВРЕМЕННО. При написании программного кода, конечно же, тоже приходится сталкиваться с асинхронной обработкой, распараллеливанием, использованием потоков… Но не в таких объемах. Приходится перестраивать мозг на новый стиль мышления, в котором параллельная обработка используется не от случая к случаю, а, может статься, даже более активно, чем последовательная. Нужно хорошо понимать взаимодействие потоков параллельных вычислений – явное, неявное, через обмен сигналами, сообщениями, через генерацию событий и через «модель поведения» шаблона BPMN, по разным ветвям которого разошлось множество «токенов». Я вижу, что в нотации BPMN заложен огромный потенциал для описания параллельных вычислений – такой, которого нет ни в каких других известных мне инструментариях. Им нужно научиться правильно пользоваться. Этот потенциал может иметь значение далеко за пределами одних только «бизнес-процессов» (ну, это уже очень личное мнение).

  6. Анатолий Белайчук говорит:

    Андрей

    Спасибо за участие и за отзыв. Я его продублировал в «Отзывах».

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

    И похоже, авторы BPMN тоже это понимают – развитие стандарта идет в направлении более полной поддержки механизмов межпроцессного взаимодействия.

    И да – мозги надо перестраивать. Но по мне это кайф! А главный кайф – в получаемых результатах, в диаграммах не «as is» и не «to be», а «AS REALLY IS».

  7. Анатолий Белайчук говорит:

    Сергей

    Да, все правильно.

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

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

  8. Анатолий Белайчук говорит:

    Андрей

    Еще одно замечание вдогонку. Цитирую: «вероятность ошибки при написании текста программы существенно меньше, чем при составлении схемы в нотации BPMN».

    Утверждение не вполне корректно, так как тут сравнивается программирование ОДНОГО ПОТОКА с составлением МНОГОПОТОЧНОЙ диаграммы в BPMN. Если сравнивать яблоки с яблоками, т.е. многопоточное программирование там и там, то BPMN будет смотреться намного выигрышнее. Ну просто представьте себе мысленно как будет выглядеть программный код для рассматриваемой задачи – как насчет вероятности ошибки в такой программе? :-o

  9. Кузин Сергей говорит:

    Анатолий, спасибо за комментарий.

    RUP, разумеется, я привёл в качестве примера вовсе не для ругательства :-)

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

    Кстати, в RUP «мосты» между моделями также остаются, да и двустороннюю трассировку тоже никто не отменял :-)

  10. Анатолий Белайчук говорит:

    Я бы не назвал это «разрывом» – там ведь нет какой-то «красной линии», с одной стороны от которой диаграмма понятна аналитику, а с другой – нет. Каждый может знать BPMN чуть-чуть, или более-менее, или отлично. Просто типичный аналитик знает чуть-чуть, а для того, чтобы сделать процесс исполняемым, этого недостаточно.

    И что, это проблема BPMN? Не думаю. Скорее наоборот – достоинство BPMN в том, что и в такой ситуации на его основе удается обеспечить обратную связь с бизнесом.

    Сложен не BPMN – сложен бизнес. Чудес не бывает.

  11. Анатолий, по поводу вероятности ошибок при параллельных вычислениях я полностью с Вами согласен. Вероятность ошибок в моем случае возрастала лишь потому, что мои мозги не успели переключиться с алгоритмического «последовательного» представления исполнимых шагов на «параллельное». Для качественной работы с BPMN мозги нужно радикально перестроить – вот, что я хотел подчеркнуть.

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

  12. Анатолий Белайчук говорит:

    Дискуссия с Андреем в итоге привела к статье: http://mainthing.ru/ru/item/368/