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

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

Процессный паттерн: Почтовое отделение

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

Теперь рассмотрим более сложную ситуацию: документы приходят в компанию обычной почтой по официальному почтовому адресу компании и попадают не напрямую на стол участнику того или иного процесса, а в общую канцелярию.

В качестве примера снова обратимся к банковской деятельности, на этот раз к процессу выдачи кредита юридическому лицу. Рассмотрим только начальный этап процесса:

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

Первая, наивная версия схемы процесса:

Рис.1. Документы клиента магическим образом попадают в «его» процесс.

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

Применим паттерн «Обработка входящих»:

Рис.2. Паттерн «Обработчик входящих»: к какому экземпляру процесса относятся эти документы?

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

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

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

Рис.3. Какие сообщения относятся к процессу A, а какие к процессу B?

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

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

Рис.4. Маршрутизация входящих документов.

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

Рис.5. Паттерн «Почтовое отделение»: централизованная обработка всех входящих и исходящих.

И еще: в коммуникациях между «почтовым отделением» и прикладными процессами вместо сообщений (BPMN message) предпочтительнее использовать сигналы (BPMN signal), как показано на рис.5.

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

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

И последнее. По опыту обсуждения предыдущей заметки, я жду комментаторов, которые скажут примерно следующее: “Давайте упростим все это дело, избавившись от традиционной почты. Электронное письмо попадет прямо к нужному адресату, а документы можно приложить к нему в отсканированном виде.”

Во-первых, не всегда и не везде можно заменить оригинал копией.

Но главное, вы не имеете права сказать бизнесу: “ваша процедура слишком сложная, я не могу ее реализовать при помощи BPMN/BPMS, поэтому вы должны ее упростить”. Да, вы можете и должны предупредить его, что реализовать его процедуру в том виде, в каком он хочет ее видеть, будет сложнее и дороже, но это не должно быть для вас непреодолимом препятствием!

Не надо давать бизнесу скороспелые советы - поверьте, ему приходится решать проблемы и находить компромиссы, имея дело с материями более сложными, чем BPMN.

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

07.07.11 | Статьи | , ,    

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

  1. Сергей Ладнич 08.07.11 13:02

    Анатолий, а если клиент не вставит «в ответ на ваш исходящий № …», то организовывается процесс “Разбирательство……”. Я правильно понял?

  2. Anatoly Belychook 08.07.11 13:27

    Сергей

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

  3. Kalyan 08.07.11 18:58

    Very nice and simple explaination of the concepts, Mr.Anatoly. Loved reading it

  4. Procesje 13.07.11 21:12

    Anatoly,

    (here I am again ;-)

    If business has more important issues to solve, then why bother getting insight in their process? That means you will give no advice (is that better then lightweigt advice?)

    It sounds to me like: Anatoly, i’ve noticed that you have two ears. Have a dobry day.

    Regards,

    Procesje

  5. Julia 18.07.11 11:29

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

    И еще: обработчик событий посылает сигнал о поступлении дополнительных документов в процесс А. И при этом ВСЕ процессы А срабатывают на этот сигнал.

  6. Anatoly Belychook 18.07.11 11:35

    Julia

    По поводу названий: спасибо за замечание, это погрешность перевода с английского на русский.

    По поводу сигнала: он принимается *стартовым* событием, какие тут “все процессы А”?

  7. Julia 18.07.11 11:46

    Сорь, с сигналом ошиблась: для старта процесса работает. Перепутала с промежуточным событием.

  8. Maxim Miroshnichenko 31.01.12 11:22

    Возможно, я не до конца понимаю сути задачи, но у меня вопрос следующий: А что, если типов процессов А и В будет не два, как в этом примере, а много больше, как в реальной жизни. Мало того, эти типы процессов меняются (дополняются и изменяются) часто. Все время помнить о том, что в процессе на рис 3 под названием “Входящий документооборот” необходимо поддерживать исходящие от развилки ветки в актуальном состоянии довольно проблематично. Есть ли паттерн проектирования, который помог бы избежать подобного затруднения?

  9. Anatoly Belychook 31.01.12 11:31

    Максим

    Спасибо за очень хороший вопрос. Действительно, тут есть проблема. Решение (паттерн) для нее имеется, скоро опубликую. Следите за обновлениями: http://mainthing.ru/feed/

  10. Maxim Miroshnichenko 31.01.12 12:10

    спасибо большое!

  11. Игорь 28.03.12 17:18

    Анатолий, добрый день!
    Смущает использование артефакта Data Object для “БД исходящих документов”. Разве это не должно быть Data Store? Как я понимаю DO существует только в период жизни экземпляра процесса (в данном случае процесса “Исходящий документооборот”), а нам нужно получить доступ к информации об уже отправленном исходящем документе, т.е. вне периода жизни экземпляра процесса. ИМХО в этом случае уместно использовать DS. Разве нет?

  12. Anatoly Belychook 01.04.12 08:19

    Игорь

    Абсолютно справедливое замечание, в BPMN 2.0 дело обстоит точно так, как Вы написали.

    Просто на момент написания этой заметки Bizagi Modeler поддерживал только BPMN 1.2. В рамках этой версии все изображено корректно.

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

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