Маргинальный подход к моделированию бизнес-процессов

В 2002 году под заголовком «Современные методы описания функциональных требований к системам» на русском языке была выпущена книга Алистера Коберна «Writing Effective Use Cases» (скачать русскую версию в djvu можно по этой ссылке)
Книжка эта, конечно, в первую очередь о требованиях, но и не только о требованиях. В действительности, автор излагает подход к моделированию процессов, позволяющий не использовать графическую нотацию. Я предвижу праведный гнев бизнес-аналитиков. Однако считаю совершенно необходимым поделиться с экспертами, занимающимися бизнес-процессами, данным подходом к их моделированию.
Сначала слово Коберну:

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

В концептуальном плане подход Алистера Коберна очень силен. Система, как контракт, защищающий интересы участников, непрерывно разворачивающая история преследования действующими лицами своих целей и т.п. – отличные идеи. Однако в этом сообщения я буду говорить о конструктивном наполнении вариантов использования, т.е. об описании конкретных сценариев в виде последовательностей шагов.

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

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

Правило 1. В любом процессе необходимо выделить основной сценарий, определить типичный ход событий, линейную последовательность шагов, наиболее быстро приводящую главное действующее лицо к цели. По сути, мы должны определить на нашей карте кратчайший путь от начала процесса, до его успешного завершения. Шаги этого пути надо выписать в обыкновенный список. Не надо никаких стрелок от первого шага ко второму и от второго к третьему. Шаги следуют друг за другом. Не надо никаких квадратиков со скругленными краями, внутрь которых засовывается описание действия с аббревиатурами и сокращениями. Простой набор нумерованных текстовых строк, следующих друг за другом в линейном порядке.
Правило 2. Любой сход с трека основного сценария оформляется как Исключение. Исключение – это не обязательно плохо. Это просто уход процесса с основного пути, т.е. некоторое отклонение от типичного хода событий. Там где раньше, после задания с именем А вы хотели нарисовать оператор исключающего ИЛИ и две стрелки, первая ведущая к заданию B, а вторая к заданию С вам следует поступить иначе. Например, задания A и B включить в основной сценарий, а переход к заданию С считать исключением. Безусловно, развитие процесса через задание B должно приводить вас к завершению сценария быстрее, чем развитие сценария через задание C. Для обработки исключений мы создаем отдельные сценарии, описывающие развитие процесса в случае возникновения данного исключения. Сценарий обработки исключения может завершиться возвратом к одному из шагов основного сценария или же просто завершиться.
Правило 3. Дальнейшее построение процесса осуществляется рекурсивно. Т.е. в сценарии обработки исключений, так же могут возникнуть исключения и для их обработки мы должны разработать необходимые сценарии.

Еще несколько правил:

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

и т.д. Интересующихся отсылаю к книжке Алистера Коберна, а я подведу итог.

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

  1. Разработка бизнес-процесса приобретает итерационный характер. Вам не зачем описывать его сразу целиком. Начните с разработки основного сценария, типичного хода событий, оставив на потом обработку исключений. Проектируйте не вглубь, а вширь. Это позволит запустить процесс существенно раньше того момента, когда аналитик выяснит все многочисленные детали и нюансы. Не спешите «программировать» обработчики редко встречающихся исключений. Скорее всего, придуманный вами сценарий для обработки таких событий будет неправильным. Включите на такие шаги процесса людей, экспертов в предметной области. Пусть они разберутся с несколькими конкретными случаями. Потом вы обобщите их опыт в модели бизнес-процесса.
  2. Откажитесь от «карты сокровищ». Простой список из 5-7, в крайних случаях 12-15 активностей – вот модель бизнес-процесса, которую сумеют воспринять ваши пользователи. Да, возможно на каких-то шагах возникнут исключения, но описания процессов их обработки столь же просты, как и описание основного сценария. Наша команда уже много лет использует такие описания и практически все вопросы к сценариям это вопросы не по форме изложения, а по существу процесса.
  3. Автоматизировать разработку вариантов использования существенно проще, чем создать графический редактор, реализующий BPMN. Просто удивительно, что поставщики ПО предпочитают разрабатывать сложные и дорогостоящие графические редакторы вместо простого веб-приложения, обеспечивающего совместную работу с простыми и понятными описаниями бизнес-процессов. Задача построения картинки по структурированным данным является довольно простой, как впрочем, и задача создания работающего приложения. Задача унификации картинок, их централизованного хранения и обработки и уж тем более генерации по ним выполняемого кода на порядок сложнее.
  4. Варианты использования – это отличный способ описания процессов для adaptive case management. Т.к. для создания элементов процесса, описанного в виде вариантов использования не надо обладать знанием BPMN, с таким описанием может справиться любой пользователь. А именно пользователь является у нас ключевой фигурой в адаптивном кейс-менеджменте.

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

Маргинальный подход к моделированию бизнес-процессов: 20 комментариев

  1. Максим, Вы пишите, что “не встречали серьезных рекомендаций по взаимному расположению действий, заданий и соединяющих их потоков…”. Совершенно верно. Я тоже не встречал, но, полагаю, это “упущение” связано с тем, что такие рекомендации, как правило, выходят за рамки методологии. Возьмите, например, методологию ARIS с ключевой моделью eEPC для описания бизнес-процессов. Ну если бы методология занялась этими вопросами, то документация выросла бы в разы и заняла бы же даже не пару тысяч страниц. 🙂 Именно поэтому при внедрении методологии ARIS на каждом отдельном предприятии разрабатывались отдельные документы, которые назывались условно “Соглашения о моделировании”, в котором определялись требования не только по тому, как соединять квадратики, но и как их располагать на странице, как их именовать, как именовать стрелки-коннекторы. Кстати, в инструменте был инструмент для автоматического выравнивания нарисованных диаграмм в соответствии с определенными правилами, назывался он, вроде, Layout. Что касается меня, то я так и не смог с помощью этого инструмента автоматически построить ни одной диаграммы, но опять же, скорее всего, по причине моих слишком завышенных требований к “юзабилити” технологических карт, которые сложно было уложить в “прокрустово ложе” этого инструмента. Поэтому я всегда рисовал ручками и требовал понятных диаграмм от своих коллег. Если же брать родоначальников — SADT или IDEF0, то там рекомендации были даны и достаточно жесткие. Куда понятнее?
    А подход А. Коберна действительно интересен.

    1. Я думаю, что “перегруженность” методологий – это одна из системных проблем современного подхода к управлению процессами. Меня опять упрекнут в айтишности, но проблема в том, что подход идет от представления, а не от объектов. Конечно, в рамках BPMN 2.0 стандартизируют XML-схему представления BPMN моделей, но это пока очень робкий шаг к нормальному положению дел в BPM. Разрыв между теми кто придумывает процессы, теми кто разрабатывает ИТ-решения и теми кто исполняет процессы будет пока и дальше существовать.

  2. Упрекнут, как не упрекнуть 🙂 Сами ведь подставляетесь.

    Коллеги, то, что программистам графические модели не нужны – это очевидно. Программисты чтят код, и это хорошо.

    Но проблемы управления бизнес-процессами лежат посередине между ИТ и бизнесом. Решать их по отдельности пытались – ничего не вышло. Попытка обойтись без ИТ = мертвые бумажные схемы, устаревающие быстрее, чем их рисуют. Попытка обойтись без бизнеса = автоматизация не до конца понятых или заведомо неоптимальных бизнес-процессов. Будем продолжать скакать на дохлой лошади?

    Решить их можно только сообща, т.е. найдя компромисс, который устроит обе стороны. Графические нотации – это и есть такой компромисс. Не надо пренебрежительно относиться к бизнес-аналитикам и к бизнесу вообще. Чужая работа всегда кажется легче своей, а на самом деле им “достается” побольше, чем программистам.

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

    “Bridging business-IT divide” для BPM (и BPMS, как составной части BPM) – это не опция, а квалифицирующий признак: если этого нет, то вы занимаетесь чем угодно, только не BPM. По крайней мере в том смысле, какой этой дисциплине придают основоположники. Прежде чем критиковать BPM, убедитесь что вы занимаетесь именно BPM, а не тем, что выдает за BPM тот или иной вендор (не будем показывать пальцем).

    Теперь что касается методологии проектирования процессов. В нотации и не должно быть рекомендаций по ее применению! Странно даже их там искать. В частности, разработчики BPMN сознательно проектировали ее так, чтобы оставить простор для *разных* способов использования. Это осознанное проектное решение!

    Но в других источниках таких рекомендаций достаточно. Просто надо сходить на тренинг, прочесть книгу, послушать толкового консультанта. К примеру, Брюс Силвер совершенно определенно говорит какими возможностями BPMN, с его точки зрения, пользоваться стоит, а какими – нет.

    Есть нотация, а есть методология. В частности, “Правило 1” в процессной методологии известно как “happy path”. Это, извините, азы.

    Призывать отказываться от “карты сокровищ” – это тоже ломиться в открытую дверь. Посмотрите на Lombardi Blueprint (у других вендоров есть аналоги) – там та же идея, только дальше эволюционировавшая.

    Так что я не уверен, что Коберн сегодня так уж интересен. Ну разве что в плане истории. Те же use cases, к слову, сегодня обрели новую жизнь в agile методологиях – там они известны как “stories”.

    А в процессной методологии за прошедшее время появились такие, например, интересные (и эффективные!) вещи, как process discovery или большой и малый циклы совершенствования процессов.

    1. Анатолий, мне очень нравится то, что мы смотрим на управление процессами с разных точек зрения. Возможно это именно то, что необходимо для более глубокого понимания.
      И комментарий Ваш, как всегда, обстоятелен, спасибо.

      Теперь по существу отношений ИТ, бизнес-аналитиков и прочих подразделений. Я по-прежнему решительно не понимаю, кого Вы называете бизнесом. Кто это: акционеры, топ менеджеры, взаимодействующие с клиентом подразделения, управление персоналом, внутренний аудит, финансы, продажи, маркетинг или кто-то еще? Какой-то очень странный персонаж этот бизнес. В нашей компании термином «бизнес» обычно пользуются молодые аналитики, когда не помнят фамилию автора конкретного требования и не могут обосновать его целесообразность. Ладно, давайте считать «бизнесом» кого-либо из многочисленных shareholder-ов проекта или продукта. Я не верю в то, что эти люди лучше понимаю графические модели. Впрочем, не верю в это не только я. Позволю себе ссылку на перевод статьи Семь заблуждений из области исполнения бизнес-процессов c BPMS.Ru 🙂

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

      Если в компании нет десятка людей, понимающих процессы компании и на регулярной основе отображающих их в модели, то и приступать к моделированию в BPMN не следует. Хотя бы просто потому, что бизнес-кейс у этого деяния не сойдется. И второе, зачастую процессное подразделение создается внутри крупной организационной структуры, для собственных нужд руководителя. Это своего рода штаб внутри армии. И как любой штаб основное его назначение – помогать главнокомандующему (но уж никак не влиять на него). Внутри подразделения это может быть полезная функция, но для кросс-функционального взаимодействия такой штаб вряд ли когда-нибудь дорастет. У соседней армии есть свой главнокомандующий и свой штаб. Честно говоря, такие «штабы» меня несколько угнетают, потому как до process discovery и циклов совершенствования им как до Луны. Их бы научить чему-нибудь простому и приземленному. Вот кейс-менеджмент, например, легко и доходчиво.

    2. Насчёт “бизнес лучше понимает язык графических нотаций” был свидетелем анекдотической ситуации: после разбора процесса генеральный директор даёт распоряжение описать всё как можно детальнее в текстовом документе, на что получает возражение одного из владельцев бизнеса: “Какой текст? Нарисуйте нам схему!” (обычно имелась в виду DFD диаграмма). Следующему генеральному директору нужны были таблицы (за неимением возможности “пощупать” процесс), ибо ни текст, ни рисунки он не воспринимал. 🙂

  3. Максим

    Я рад, что Вас не задевают мои местами комментарии. Идет нормальная продуктивная полемика.

    “Бизнес” в моем понимании это люди, участвующие в основных бизнес-процессах либо заинтересованные в их результатах. (Основной процесс – это процесс, создающий ценность, в отличие от вспомогательного, который создает стоимость.) Руководство, линейные менеджеры, ключевые специалисты. Не относятся к “бизнесу” ИТ, бухгалтерия, кадры.

    По поводу статьи – это уже не первый случай, когда оппоненты в споре приводят в качестве аргумента цитаты из моих статей или (как в данном случае) из статей, которые я перевожу для bpms.ru 🙂 Боюсь, Вы увидели в этой статье то, что хотели. Да, не следует ожидать, что люди бизнеса или аналитики смогут отрисовать схему процесса во всех необходимых подробностях. (Вообще, схема процесса зачастую больше говорит о ее авторе, чем о процессе.) Да, не следует ожидать, что схема процесса, кто бы ее не нарисовал, автоматически превратится в промышленную систему без участия программистов.

    Но Вы, как мне кажется, упускаете из виду разницу между “понимать” и “рисовать”. От бизнеса не требуется только первое. Но и это не мало.

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

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

    Процессное подразделение, о котором Вы говорите,- это плохая практика. Попытка внедрить процессное управление путем создания еще одного функционального подразделения. Заседание для отмены всех заседаний. 🙂

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

    Относительно “десятка людей, понимающих процессы и на регулярной основе отображающих их в модели” – типа “научитесь плавать, тогда мы вам воду нальем” 🙂 Не согласен, плавать можно и нужно учиться в воде, а не на берегу. Сразу ставя себе цели управления ответственными процессами при помощи исполняемых схем процессов. Это цель и достижимая, и весомая.

  4. 100% соглашусь с Анатолием, что бизнес и айтишник разные люди с разной культурой и мозгами. И моделирование в контексте их разности (бизнеса и ИТ) это компромис и взаимопонимание.

    Re: До сегодняшнего день, мне не доводилось видеть программного решения, реализующего такой подход. Но я не перестаю надеяться, что в обозримом будущем мои мечты о таком инструменте сбудутся.

    Что же касается этого вопроса, то инструменты есть. Возможно они не такие “зрелые” как “настоящие” BPMS, но они есть. Смещается и акцент от моделирования к написанию кода процесса. Мне как “программисту” этот подход также ближе, но читать модели, обсуждать с заинтересованными сторонами проще чем обсуждать код!

    Это как ER-диаграммы. Я уже больше десяти лет работаю с RBDMS и делал “заказные софты” еще в институте на третьем курсе и долго не мог понять зачем этот ERWin, но после того как победил в себе эту спесь всегда рисую ER-ки, моделирую БД в средстве для моделирования.

    С BPMN же столкнулся много позже, когда пытался нарисовать модель нескольких довольно простеньких процессов на стыке подразделений. Оказалось, что никакие ER-ки, SADT и UML-ки не могли передать полную картину, и тщательно погуглив попал на BPMN.

    Что до инструментов, мне на сегодня известно две реализации машины процессов под программистов – SimPEL и Ruote. Погулите, посмотрите у меня в блоге и составьте мнение.

    Т.е. я бы отделял моделирование и реализацию процессов. Однако в аббревиатуру BPMS такой подход как-то не сильно влазит.

    PS

    Научить бизнес своему жаргону пытались, думаю, неоднократно. Интересный подход в одной из интересных реализаций библиотек модульного и интеграционного тестирования Cocumber. Предполагается, что тесты пишутся человеческим языком, типа “Если сложить 2 и 2 должно получится 4”. Естественно все это не бесплатно, т.к. всю эту красоту нужно дополнительно программировать. Выглядит крайне красиво, но что-то я очень сомневаюсь, что пишет тесты бизнес.

    1. Мне тоже очень нравятся ER-диаграммы. По роду деятельности через меня проходит много небольших систем. С разработчиков мы требуем описание структуры базы данных в виде ER-диаграммы. Правда опыт показывает, что они не всегда актуальны и поэтому приходится автоматически создавать ER-диаграмму по реальной базе данных. Если в базе несколько десятков таблиц, то такой подход вполне обоснован. Хотя для обсуждений, все же больше подходит картинка с основными сущностями и отношениями, например, в виде онтологий. Её можно и почеркать и в презентацию вставить.

      Наши бизнес-аналитики с ER-диаграммами не работают. Они используют ежедневную копию БД реальных систем. Их можно понять. Во-первых, в основных системах компании сотни (если не тысячи) таблиц. Во-вторых, конкретные данные в настроечных (референсных) таблицах имеют значение. Вся логика в крупных системах именно на этом и построена. А для не очень подготовленного заказчика у нас припасены различные формы, которые он заполняет ну, например, для определения параметров услуги.

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

  5. Использe. подход, рекомендованный Коберном, регулярно. Результаты в Use Case определяю как превосходные. Однако сталкивался с экспоненциальным возрастанием сложности и трудоёмкости при попытках углубления в детали (не зря автор рекомендует придерживаться определённого уровня детализации). Потому сам пользуюсь и рекомендую другим останавливаться на логическом уровне манипуляций с документами и сообщениями при текстовом описании Use Case.

    1. Сергей, рад Вас приветствовать в своем блоге.
      И согласен с вашей оценкой use case-ов Коберна. А вы не пытались найти или разработать какой-нибудь инструмент для работы с use case-ами?

      1. Спасибо, я рад присоединиться к данной дискуссии.
        Для работы с Use Case предпочитаю использовать Rational Rose, документы со списками действий ассоциирую с пиктограммой.
        Наверное, не совсем понял вопрос о разработке инструмента. Может, имеется в виду некоторая методика?
        Например, считаю незаслуженно обойдёнными в моделировании процессов другие возможности UML:
        1. Диаграммы классов для описания предметной области;
        2. Диаграммы состояний для описания переходов объектов, когда процессы являются действиями по изменению состояний объектов;
        3. Диаграммы последовательности (трудоёмко для различных сценариев, но позволяет выявлять различные сущности, которые обычно пропускаются на начальных этапах моделирования процессов, и которые затем нужно вводить в описания процессов, что ведёт к их неоднократной переделке).
        Как раз вчера на семинаре у Анатолия затрагивали тему сложности понимания процессов и участвующих в них объектов без изначального моделирования статических диаграмм (например, используется DFD). При знании UML и его использовании многие подобные проблемы, на мой взгляд, уходят.

  6. Максим,
    Мне очень блика тема выявления процесса. Понравилось, что Вы вспомнили методологию Кобурна. Мы ей пользуемся при разработке схем процессов в BPM. Она помогает, но, к сожалению, не обеспечивает 100% результата.
    Разрабатывая схему BPM, мы сперва создаем текстовое описание. На основании этого описания мы рисуем Happy path и т.д. Далее по трем правилам. Однако есть нюансы.
    Вы рассказываете про «идеальный» случай, когда Аналитик описывает процесс, который хорошо знает. Тогда методика Кобурна, как нить в лабиринте, выведет нас к выходу. Я больше сталкиваюсь с ситуацией, когда Аналитик работает со слов SME, а последний сам не знает, забыл или паче не хочет рассказать о возможном варианте. Что делать, как искать другие варианты.
    Кроме того, методология Кобурна не позволяет находить Исключительные ситуации. Что делать, если Клиент отзывает свой заказ? Продолжать ли процесс, когда истекло отведенное для него время? Что делать, если случился форс-мажор. Готовой методики выявления исключительных ситуаций нет. Пока что есть список вопросов, наработанных практическим опытом, хочется его систематизировать.
    Казалось бы Вы правы, все равно создавать модель в графическом редакторе или сделать текстовое писание. Но разница есть. Что бы ее оценить, следует понять – для чего мы готовим описание процесса.
    Смею утверждать, что Вы строите модель процесса, что бы реализовать функциональную систему. Слово функциональная не ругательное, оно отражает факт, что человек играет активную координирующую роль, а машина только автоматизирует некоторые операции. Если схема что-то упустила, человек подправит. Вы и сами об этом пишете: «…именно пользователь является у нас ключевой фигурой в адаптивном кейс-менеджменте». Да и сам Кобурн это подтверждает, так как строит Вариант использования. Из самого слова понятно, Вариант это один из многих способов.
    Мы строим процессные системы, где система играет активную роль, направляя действия человека. Но тогда система должна всегда знать что и когда делать. Для этого необходима схема, которая учитывает все варианты исполнения.
    Итак, вернулись в начало, как построить качественную модель. Я вижу только путь быстрого прототипирования и верификации. Анатолий выше описал последовательность, не буду повторять. Мы для прототипирования используем BPM. Один из наших процессов работает более года без изменений. Надеюсь, мы смогли выявить все варианты его исполнения.

    1. Игорь, Вы затронули очень интересную тему: что делать, когда заказчик не знает что делать. Вообще, тема взаимодействия в ходе разработки/улучшения процесса выходит на передний план. Чуть раньше я писал, что об этом заговорили в проекте Activiti: http://wp.me/pRljZ-4g Какие они дадут ответы, пока не понятно. Мне кажется, что это как раз точки, в которых в процесс надо включать бизнес-аналитика, запуская тем самым процесс обновления бизнес-процесса. Т.е. мы объединяем процесс и процесс его разработки. при типичном развитии событий в процессе действуют рядовые исполнители. При возникновении непредусмотренного исключения автоматически формируется задача на улучшение процесса.

      Как Вам такой подход?

    2. “Что делать, как искать другие варианты.
      Кроме того, методология Кобурна не позволяет находить Исключительные ситуации. Что делать, если Клиент отзывает свой заказ? Продолжать ли процесс, когда истекло отведенное для него время? Что делать, если случился форс-мажор. Готовой методики выявления исключительных ситуаций нет. Пока что есть список вопросов, наработанных практическим опытом, хочется его систематизировать.”

      Игорь, Вы правы – опыт является неоценимым помощником для проектирования исключительных ситуаций. Я после описания happy path использую несколько проходов для рассмотрения возможных ситуаций на каждом элементе текстового списка, разделяя его на исключения/альтернативы и действия в случае возникновения ошибок.

      Для этого считаю наличие у бизнес-аналитика воображения из важнейших качеств. Желательно также наличие опыта программирования с точки зрения развитой логики.

    3. “Я вижу только путь быстрого прототипирования и верификации”

      в случае отсутствия реального инструмента (софта), который позволяет адаптировать бизнес-процесс в ходе его исполнения, видимо – да. Но тем самым подтверждается тезис о необходимости систем Adaptive Case Management, способных делать такую адаптацию бизнес-процессов “в реальном времени”. А иначе и приходится уповать на “идеальный” процесс, который “работает более года без изменений” – пока только такие процессы и получается реально автоматизировать

  7. Максим,
    любой процесс, как было уже сказано выше, имеет happy path – это такая зеленая улица, когда все со всем согласились, все все сделали вовремя и все счастливы. Но не надо быть семи пядей во лбу, чтобы предусмотреть стандартные отклонения от “счастья”. К примеру, варианты решения “да-нет” всегда очевидны. Другой момент, когда вариант “да-нет-не знаю”. Вот это “не знаю” – это та самая нестандартная ситуация. Хотя в данном случае, если аналитик вообще предусмотрел это “не знаю”, то ситуация уже контролируема. Что делаем в случае “не знаю”? Варианты: инициируем процесс принятия решений, делегируем полномочия и т.д. Все, о чем я пока говорю, попадает в определение BPM, и не нуждается в кейс-менеджменте.
    Теперь о том случае, когда поведение процесса не было предугадано заранее. К примеру, работу аэропорта парализовал вулкан. Опа! В процессе про вулкан ничего не сказано. Билеты, обязательства, багаж – все зависло. А что вы будете делать в этом случае? Просто создаете на лету активности и переписываете процесс? Вариант. Но не единственный. А как насчет инициировать процесс принятия решения? Оба варианта являются основанием для пересмотра процесса (возможно, как Вы предлагаете, запустить процесс усовершенствования процесса – хорошая мысль).
    Вопрос: как часто возникают ситуации, не предусмотренные моделью процесса? Если часто – меняйте аналитика либо что-то надо поправить в консерватории. Если же это действительно исключительные ситуации, случающиеся крайне редко, то пользоваться возможностью искусственно прервать (протолкнуть, вернуть…) процесс можно только при наличии администраторских полномочий. Но это не кейс-менеджмент, а обычное исключение.

    1. “Хотя в данном случае, если аналитик вообще предусмотрел это «не знаю», то ситуация уже контролируема”

      Контролируема может и контролируема, но никак не автоматизируема – средствами обычного BPM. Отодвигаемся в сторону от компьютера с его BPM-игрушками и беремся за телефон, чтобы “контролировать ситуацию” – со всеми вытекающими последствиями, в том числе и с последствиями для такого BPM

      “Что делаем в случае «не знаю»? Варианты: инициируем процесс принятия решений, делегируем полномочия и т.д. Все, о чем я пока говорю, попадает в определение BPM, и не нуждается в кейс-менеджменте”

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

      Это как сравнивать простую HTML-страницу, которая содержит сразу все нужное и ненужное, и HTML-страницу с AJAX, которая подгружает данные на страницу по мере необходимости.

      Так и ACM “проявляет” процесс по мере его исполнения

  8. “Правило 1. В любом процессе… определить … линейную последовательность шагов, … Шаги следуют друг за другом. ”

    – в общем случае часть шагов следует друг за другом, а часть исполняется независимо друг от друга

    “Правило 2. Любой сход с … оформляется как Исключение…развитие процесса через задание B должно приводить вас к завершению сценария быстрее”

    – в общем случае, видимо, медленнее, исключение на то и исключение, чтобы заканчивать процесс быстрее, например, неподписание договора заканчивает
    процесс быстрее, чем его подписание

    “Правило 3. Дальнейшее построение процесса осуществляется рекурсивно”

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

    “Следуя методу описания вариантов использования, мы получаем описание процесса в виде простых списков. Каждый список, кроме самого верхнего, прикреплен
    к конкретному шагу какого-то другого списка”

    – да, совершенно верно, в таком виде кейс напоминает блог с иерархическими сообщениями. Реальный софт, в котором таким образом реализован Adaptive Case Management, это, например, PayDox Case Management
    Было очень интересно увидеть реализованными в данном продукте принципы, изложенные в данной статье – реализация в виде collaborative business process
    management на инструментарии социальных сетей типа блогов и форумов, представляющих кейсы как последовательности сообщений 2-х типов – контрольные точки (case milestones) и информационные, наличие библиотеки шаблонов (case pattern library), позволяющей одним кликом активизировать новый кейс с готовым
    набором контрольных точек, исполнителей и файлов, возможность контролировать сроки исполнения и др

    “Автоматизировать разработку вариантов использования существенно проще, чем создать графический редактор, реализующий BPMN. Просто удивительно, что
    поставщики ПО предпочитают разрабатывать сложные и дорогостоящие графические редакторы вместо простого веб-приложения, обеспечивающего совместную работу
    с простыми и понятными описаниями бизнес-процессов”

    – сказано точно, добавлю, что, видимо, в этом и состоят известные проблемы внедрения BPM-приложений – помогая в учете и контроле они противодействуют, а не помогают коллективному взаимодействию, обычному при управлении бизнес-процессами в “ручном” режиме. В этом смысле, боюсь, что BPEL4People уже мало поможет (его появление – это попытка сделать “Adaptive” BPEL), а ACM, видимо, решает проблему – но с другого конца, через collaboration

    “Варианты использования” в терминологии данной статьи – это фактически паттерны, шаблоны в терминологии ACM и BPM

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

    Популярные (используемые повторно) кейсы копировать в библиотеку шаблонов, при необходимости редактировать и дополнять и использовать снова для
    исполнения похожих кейсов. Именно так это реализовано в PayDox Case Management. Собственно, такая технология формирования, последовательной оптимизации и использования шаблонов (вариантов использования) и определяет адаптивность подобной системы управления, отвечающей своему названию Adaptive Case Management

    “Но я не перестаю надеяться, что в обозримом будущем мои мечты о таком инструменте сбудутся”

    – мечты иногда сбываются. Давайте верить в это! 🙂

    Да, и напоследок – название “Маргинальный подход” – это гениально. Все действительно новое и впоследствии очевидно эффективное поначалу кажется
    маргинальным. Гениальное простым становится позже – сначала кажется примитивным

  9. Здравствуйте. Когда я читаю про эти ваши “адаптивные управления кейсами”, меня тоже не покидает ощущение дежа вю.

    вспомнил, где видел:

    http://sbpm2009.fzi.de/submission/p1.pdf
    http://projects.kmi.open.ac.uk/super/SWSIP09Cabral.pdf

    http://dip.semanticweb.org/documents/Hepp-et-al-Semantic-Business-Process-Management-Using-Semantic-Web-Services-for-Business-Pro.pdf
    http://lsdis.cs.uga.edu/lib/presentations/WWW2003-ESSW-invitedTalk-Sheth.pdf
    http://www.heppnetz.de/files/mhepp-et-al-SemanticBusinessProcessManagement.pdf

    http://udoo.uni-muenster.de/downloads/publications/2076.pdf
    http://www.www2009.org/proceedings/pdf/p1135.pdf

    http://videolectures.net/eswc08_hoffman_sb/

    http://www.ibis-thome.com/fileadmin/website/PDF/deu/Artikel/Semantic_Business_Process_Analysis.pdf
    http://protege.stanford.edu/conference/2005/submissions/demos/demo-Diez.pdf

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

    > Просто удивительно, что поставщики ПО предпочитают разрабатывать сложные и дорогостоящие графические редакторы вместо простого веб-приложения, обеспечивающего совместную работу с простыми и понятными описаниями бизнес-процессов. Задача построения картинки по структурированным данным является довольно простой, как впрочем, и задача создания работающего приложения. Задача унификации картинок, их централизованного хранения и обработки и уж тем более генерации по ним выполняемого кода на порядок сложнее

    вот это как раз реализовано: страничка семантической вики, из которой автоматически строится форма, которую можно заполнять, показывается карта процесса. пример такой вики видел где-то на сайте университета Дрездена.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *