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

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

Процессный паттерн: Обработчик входящих

Рассмотрим процесс выдачи банковской карты клиенту:

Рис. 1. Выдача банковской карты с «пассивной» задачей «Выдать карту».

Обратим внимание на задачу «Выдать карту». Бизнес-сценарий: после того как карта изготовлена, клиент в течение 45 дней должен прийти в отделение банка и получить ее. Если считать, что в среднем клиент приходит за картой через 10 дней, и что отделение выдает по 100 карт в день, то у банковского клерка скопится очередь из 1000 задач.

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

Чтобы избавиться от «пассивных» задач, следует добавить в схему процесса ожидание наступления события – клиент обратился за картой:

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

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

Заметим, что с сообщением «заявление клиента» такой проблемы не возникает, так как старт на диаграмме не является частью экземпляра процесса. Старт – это «фабрика процессов», и она одна.

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

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

Это делает отдельный процесс «Обращение за выдачей карты»:

Рис. 3. Процесс «Обращение за выдачей карты» как образчик паттерна «Обработчик входящих».

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

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

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

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

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

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

01.07.11 | Статьи | ,    

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

  1. Alberto Manuel 02.07.11 12:31

    Anatoly:

    A very important improvement opportunity:

    After the credit card is issued, send it directly to the customer. The customer activates the card using the security codes the bank provided to communicate with the bank channels (the are not the codes to operate with the card).

    It eliminates one moment of truth, It eliminates the annoying of getting back to the bank .

    Cheers,

    Alberto Manuel

    http://twitter.com/albertomanuel

  2. Anatoly Belychook 02.07.11 13:19

    Alberto

    Thank you for the suggestion. It’s pretty obvious but it won’t always work. Enough to say that legislature differs from country to country so client’s signature may be necessary to confirm the card delivery. The case in question isn’t imaginatory. I’m sure the bank considered the opportunity you propose yet had serious reasons not to take it.

    Anyway the post wasn’t about optimal bank practices but about a common process pattern.

  3. Анатолий, великолепный пример на определение границы между BPMS и другими информационными системами банка. Давайте внесем в задачку еще пару подробностей из реальной банковской деятельности:

    Во-первых, большинство банков являются многофилиальными и карту выдают в конкретном офисе. Это важное условие, так как наличие записи о выпущенной карте не всегда позволяет её получить. Клиент пришел в одно отделение, а карта находится в другом. Обычно, клиент указывает отделение банка, в котором хотел бы получить карту при её заказе, однако, он может и передумать. Я уж не говорю про «зарплатные» проекты, когда карты возят по офисам. Другой момент: хороший банк не будет ждать клиента 45 дней, а свяжется с ним намного раньше, чтоб напомнить о выпущенной карте. Т.е. БД карт начнет генерировать вспомогательные процессы.

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

    PS: «плохой» программист загонит «БД карты» во внутрь BPMS и вот оттуда информацию по карте уже точно никто не достанет.

  4. Anatoly Belychook 03.07.11 07:44

    Максим

    Вы пугаете, а мне не страшно :) Повторюсь: этот пример я взял не из головы, а из BPMN-тренинга в одном из банков. На практическом занятии они сами выбрали этот процесс и сами смоделировали as-is. Ну да, очевидно, этот банк относится не к 90, а к 10 процентам.

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

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

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

    Что касается плохого программиста, то это оружие массового поражения. Но согласитесь, наличие BPMS ограничивает распространение этого оружия :)

    И почему это “оттуда информацию точно никто не достанет”? Оттуда достать информацию больше шансов, чем из корпоративной системы. Я представляю какие проблемы вы испытываете с автоматизированными системами без программных интерфейсов, но автоматически переносить эти страхи на BPMS не следует - BPM без интеграции с унаследованными системами не бывает, и в BPMS с программными интерфейсами дело обстоит намного лучше, чем скажем в ERP.

    Мне кажется, Вам пора попробовать BPMS в деле. Иначе страхи будут накапливаться, пока не превратятся в фобию ;)

  5. Alberto Manuel 03.07.11 12:38

    Hello Anatoly:

    I do not want to ruin your objective, but I found more interesting discussing how to improve the process, rather than figure it out how to design it in BPMN.

    Going back to the regulation and the need of get a customers signature, the bank can send a letter with an delivery receipt. This complies with the regulation and turns the process more lean.

    Cheers,

    Alberto Manuel

    http://twitter.com/albertomanuel

  6. Anatoly Belychook 03.07.11 12:52

    Alberto

    You can’t imagine how awful the post service is in some countries :)

    OK, one may improve this particular process but it’s impossible to eliminate every moment of truth in every process - this is why design is more interesting than process optimzation for me.

    The story isn’t about communications between bank and its clients, it’s about generic process pattern. Most people don’t understand what a message flow reaching an intermediate event in the middle of a process diagram really means.

    Thank you
    Anatoly

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

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

  8. Anatoly Belychook 03.07.11 21:13

    Максим

    Поясните пожалуйста о какой BPMS Вы говорите и на каком основании делаете вывод о не очень хорошем положении дел.

    По-моему, у Вас сложилось ложное представление. В тех BPMS, с которым работаем мы, программные интерфейсы в наличии. И, повторюсь, в этом типичная BPMS принципиально отличается от типичной корпоративной системы: для первой это обязательное требование (без интеграции нет BPM), для вторых программные интерфейсы, в понимании разработчиков, это возможность использовать их системы не так, как они (разработчики) задумали и - о ужас - обращаться к ним из “чужих” программных средств; inside-out - пожалуйста, outside-in - ни-ни.

    О стандартизованности API различных вендоров правда говорить не приходится, но где они вообще есть, стандартные API? Есть ODBC/JDBC, но это относительно низкоуровневые интерфейсы, CRUD. На уровне приложений все проприетарно.

  9. Я пытаюсь разобраться с Process API от Oracle BPM.
    Стандартные API существуют, тот же WS HumanTask, но BPM, как направление в целом, движется в в сторону проприетарных интерфейсов

  10. Procesje 05.07.11 22:32

    - Your first purchase will be for free if you pick up the card within 2 days
    - Make the request of a credit card so expensive that people don’t want a card
    - Just stop providing credit cards
    - Accept that the process just works this way because of law.

    And what is actually the problem? Too expensive, too slow, bad customer experience? If there isn’t any problem why bother modelling the process at all?

    Regards,

    Procesje

  11. Anatoly Belychook 05.07.11 22:43

    OMG did anyone care to figure out what the post was actually about?!

  12. Procesje 05.07.11 23:06

    I assumed it was about improving a process (see twitter of Gary C) , but probably it is just about showing a process pattern in a BPMN model.

  13. Anatoly Belychook 06.07.11 07:19

    There is no business issue in this point hence no room for serious process improvement.

  14. Bruce Silver 07.07.11 17:03

    Anatoly, this thread is hilarious. In America we have a saying: Let no good deed go unpunished.

  15. Procesje 07.07.11 19:55

    Bruce,

    Maybe the most hilarious thing is people spending a lot of time on modelling a process in BPMN without the intention to improve it.

    Or is that not what you mean :-)

  16. Anatoly Belychook 07.07.11 21:02

    Procesje

    Not Bruce but dare to answer :)

    1) It’s purely a matter of professional skill: whether one know how to model process in BPMN or do not. Your recommendation regarding process optimisation should not depend on what you can model with BPMN and what you can not, right?

    2) What shall go first: process optimisation or process control? I’m more inclined to the latter: start with as-is, more or less, gain the control over the process with a help of BPMS/BAM and then look for improvement/optimization opportunities.

    3) What is process optimization, anyway? In old days I believed it’s tuning a process here and there. Now I know that re-evaluating process scope gives much, much more than “process knitting”.

    Oh my, am I writing a new post here?

  17. Procesje 08.07.11 12:44

    1)I agree, but my actual point is that I see a lot of companies spending a lot of time on modeling their processes ending up in a lot of process models that are never used for more than “being a model”. It is like drawing building plans with no intention to build or change a house. That is why I think it is better to spend your time on other process-things than modeling. Should I start the “Process Model Liberation Front”? ;-)

    2) I agree that the final objective must be to control/manage an organization in a process oriented way (at least if you think bpm is a good idea) . And what do you need for that? Processes. Then see if these processes meet their goals. If they do, why bother improving them? If they don’t: analyse, find the problem and improve them.
    What I see a lot is that companies have a lot of process models, but don’t know what their real processes are and didn’t think about the right measurements to really see process performance.
    So yes, the goal is to manage, but I wouldn’t like to manage useless processes. What brings us to point 3.

    3) I don’t like the word optimization. It indeed sounds like tweeking the process a little bit. In my opinion it is about really being aware of your processes and their contribution to your organization goals. And to let your processes be valuable, improvement can mean a lot of things:

    - Skip a whole process
    - Making control more strict in a process
    - Don’t steer strict anymore, but train your people to do what is best for your customers
    - Better informationmanagement
    - Delete useless business rules
    - …..

    Conclusion: In my opinion a process model is only useful when you experienced bad process performance and you decided to improve that process. Stop modeling, start improving (would be on the flag of the PMLF ;-)

    I think we agree on a lot of things. Good luck with your new post ;-)

  18. Anatoly Belychook 08.07.11 13:20

    Procesje

    It’s a pleasure to have this discussion with you.

    So your point is that a lot of people model processes but don’t go any further - nor to executable processes neither to process improvements. I agree.

    Now what shall we do about it? Is there a better way to process control/management/improvement that doesn’t need modeling? ACM? Sure - for certain processes but not for all. Something else?

    I meet theese people all the time at my trainings. But I won’t say that their modeling activities is totally fruitless. Does it pay for the efforts spent? Sometimes yes, sometimes no. Probably yes for those who respect Pareto’s law.

    What I’m trying to do is enlightning them - showing the power of executable processes models. For many of them it’s unbelievable. Just too good to be true. But they do it with their own hands at the training so it’s hard to deny. Nobody says it doesn’t make sence. For most of them it’s not easy to change the paradigm and get beyond pure modeling. It’s in the organization culture after all. But I’m optimistic in belief that right ideas finally get the right people.

  19. Procesje 08.07.11 13:38

    Anatoly,

    Modelling is absolutely not fruitless if you do it with the right purpose: to build or change the house! So the onlything I do lately is, like you, helping organisations take the next step.

    And sometimes automation (wfm/acm) is the next step and than it is very great that the process model can be brought “alive” by the modeller himself in tools like Bizagi. Lombardi, BPMone, Pega etc.

    Then a model is not just a model anymore, but your guide for improvement.

    Should I change the name into UAOPMF (Usefull application of process model front) ;-)

  20. Anatoly Belychook 08.07.11 14:01

    I’m in! :)

  21. Aliya 09.11.11 10:51

    Добрый день!
    Я пытаюсь разобраться с данной нотацией. Спасибо за Ваши материалы.
    У меня мелкий вопрос по модели (рис.3): возможно, задачу “выдать карту” логичнее поместить в пул “Обращение за выдачей карты” (с переименованием названий пулов). Т.к. фактически это единая цепочка, где успешное завершение одной задачи инициирует выполнение другой

  22. Anatoly Belychook 10.11.11 12:58

    Aliya

    Спасибо, хороший вопрос.

    С точки зрения техники можно и так.

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

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

  23. Aliya 10.11.11 13:46

    Тогда зачем выносить в отдельный пул задачу “Найти карту”? Не проще ли поместить ее перед задачей “Выдать карту” на модели, изображенной на рис. 2?

    Спасибо

  24. Anatoly Belychook 10.11.11 14:06

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

    С каким конкретно экземпляром процесса (их могут быть тысячи одновременно находящихся в работе) вы свяжете эту задачу, когда к кассиру пришел клиент?

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

  25. Первый рисунок со структурой процессов выдачи карты изначально некорректный - в реальности надо учитывать ВСЕ процессы, связанные с решением этой задачи. Например, перечень операций мог бы выглядеть так:
    1. принять и проверить заявление на выдачу карты;
    2. ввести данные в информационную систему банка;
    3. проверить заявителя (скоринг, СБ и т.п.);
    4. сформировать пакет заявлений;
    5. рассмотреть пакет заявлений (выходами могут быть как положительные, так и отрицательные решения);
    6. сформировать заказ (задание) на изготовление пакета карт (по одной никто делать не будет. Тем более, что не у каждого банка есть свое производство карт);
    7. получить (физически) карты и проверить на соответствие заказу (+ возможно промежуточное хранение на складе банка);
    8. переместить карты в территориальные отделения (ежедневная доставка одновременно с инкассацией);
    9. хранить карты в территориальном отделении (не говоря уже о их инвентаризации);
    10. при обращении клиента проверить у него документы и найти карту в пачке карт (либо найти ее в списке аннулированных по срокам карт);
    11. оформить документы на выдачу карты (и учесть в базе данных банка);
    12. выдать карту клиенту;
    13. ежемесячно (еженедельно) отобрать карты с просроченным сроком действия;
    14. оформить документы на утилизацию просроченных карт;
    15. утилизировать карты (вернуть в центральный офис)…

    Это отдельные операции, которые можно сгруппировать в процессы.

    Так вот, процесс “выдачи карты” должен включать:
    10. при обращении клиента проверить документы и найти карту в пачке карт (либо найти ее в списке аннулированных по срокам карт);
    11. оформить документы на выдачу карты;
    12. выдать карту клиенту.

    На мой взгляд, некорректно показывать процесс “обращения” отдельно от процесса “выдачи” (они НЕРАЗРЫВНО связаны). Тем более сначала просто “забывать” про него. Потом вспоминать и создавать “часто встречающиеся” процессные паттерны.

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

    Проблема в том, что надо сначала понять структуру процессов системным образом, а потом уже заниматься моделированием на уровне Work Flow.

    Далее. Тезис Анатолия: “…потеряется сквозной процесс “от заявления до выдачи карты”. Вы не сможете ответить на вопрос “сколько времени занимает исполнение процесса?”. Пардон, это надуманный “сквозной” процесс. Реально его нет, как видно из вышеизложеного. А время замерить проще простого: “Дата оформления заявления” - “Дата выдачи”!

  26. Anatoly Belychook 20.11.11 08:05

    Владимир

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

    Если бы я рисовал блок-схему, мне бы пришлось изобразить на ней 15 перечисленных Вами задач (а реально даже больше) и это сделало бы ее нечитаемой. А в BPMN я могу (и должен) на верхнем уровне изобразить подпроцесс “Рассмотреть заявление”, который включает в себя Ваши действия с 1 по 5.

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

    В третьих и главных, BPMN-диаграмма отличается от блок-схемы тем, что это “закон прямого действия”. Не примерная схема того, из чего состоит процесс, а строгая, непосредственно исполняемая вещь: что нарисовано, то и делаю, “What You Model Is What You Run”. Задача “Выдать карту” нормально бы смотрелась в рамках основного процесса, если бы это была блок-схема. А в BPMN мы получим задачу, которую исполнитель не имеет возможности исполнить! Не может кассир (предположим, что карту выдает он) исполнить задачу “Выдать карту”, так как для этого нужно чтобы перед ним стоял клиент, а кассир не имеет возможности привести клиента в офис банка. Это неправильно - людям надо ставить только такие задачи, которые они могут исполнить.

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

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

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

  27. Анатолий

    мне кажется ,что с точки зрения бизнеса следующие действия представляют собой единый процесс, выполняемый локально 1-2 сотрудниками банка (нюансы лучше спросить у банкиров):
    10. при обращении клиента проверить у него документы и найти карту в пачке карт (либо найти ее в списке аннулированных по срокам карт);
    11. оформить документы на выдачу карты (и учесть в базе данных банка);
    12. выдать карту клиенту.

    Если идет обращение по еще не выпущенной карте, это частный случай п. 10 - скорее всего, операционист сначала смотрит в базе, выпущена ли карта, а только потом идет ее искать в пачке.
    Пул, который у Вас назван “Выдача банковской карты” изначально некорректно упрощен, поэтому и пришлось показывать “Обращение за выдачей карты” отдельным пулом.
    Что мешает сразу создать пул под названием: “Обслуживание клиента при обращении за выдачей банковской карты” и показать в нем все операции 10-12.

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

    Не понял, чем собственно BPMN диаграмма отличается принципиально от грамотно описанной схемы Work Flow в eEPC или любой другой нотации, содержащей события. Только тем, что ее “понимают” некоторые движки некоторых программ? Событиями EPC можно показать и приход сообщения, и таймер “45 дней” и т.п. Схема будет на 100% корректной с точки зрения описания “реально выполняемого процесса”. Просто она не сможет автоматически транслироваться в исполняемый код.

    Что касается “блок-схемы” с ромбиками, то я их не использую ;-)

    Если есть заинтересованные господа “банкиры”, предлагаю описать группу процессов, а потом декомпозировать их на операционный уровень.

  28. Anatoly Belychook 20.11.11 19:47

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

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

  29. Привет, Анатолий!

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

    Примеры на тренингах, с которыми “соглашаются” представители компаний и “боевые” описания процессов - далеко не одно и то же!

    “Что есть выдача карты”? - вот вопрос. Выдача карты без обработки обращения как процесс лишена всякого смысла….

    Вот когда герой Ильфа и Петрова в порыве душевной доброты разбрасывал сушки из корзины - это процесс можно описать без “обращения за выдачей” ;-)

  30. Дмитрий Пинаев 21.11.11 15:45

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

    Хитрый ход! Чтобы сделать форму запрашивающую реквизиты клиента и отыскивающую нужный экземпляр первого процесса, нам пришлось создать вспомогательный процесс.
    А как-нибудь еще можно реализовать такой функционал?

  31. Дмитрий,
    А чем не нравится мой вариант представления процесса “Обслуживание клиента при обращении за банковской картой”?
    Если его рассматривать в целом, то никакой вспомогательный процесс будет не нужен.
    Вообще, этот процесс у Анатолия нужен для бизнеса или чтобы “рассчитать” время сквозного процесса? Но рассчитать время сквозного процесса можно без таких сложностей…

  32. Anatoly Belychook 21.11.11 23:36

    Дмитрий

    Спасибо что заглянули.

    Дело не в том чтобы прицепить форму, дело в асинхронности этих действий относительно основного процесса и в том, что такие обращения соотносятся с основным процессом не как 1:1, а как М:1. А раз так, это отдельный пул, и не надо искать какие-то другие варианты.

    Владимир

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

    Aliya

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

  33. Дмитрий Пинаев 21.11.11 23:41

    Владимир,
    мне твой вариант - всем нравится. Процесс Анатолия нужен для третьего - для обеспечения технической возможности поиска нужного экземпляра в BPMS (который нужно продолжить) когда клиент приходит за картой.
    С т.з зрения рассчитать время процесса, оно (время) будет даже более некорректным в во втором варианте Анатолия, т.к., смею предположить, что в процессе “Выдача…” не учтется время на операцию Find car

  34. Anatoly Belychook 21.11.11 23:46

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

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

  35. Дмитрий Пинаев 21.11.11 23:46

    Анатолий, приветствую!
    да, я понял в чем дело.
    Просто разбивать процесс в угоду технике, имхо, не слишком красиво (этим и вызваны вопросы Алии и Владимира). Поэтому и спросил, а есть ли другие варианты технически?

  36. Anatoly Belychook 21.11.11 23:50

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

  37. Дмитрий Пинаев 21.11.11 23:53

    >>Без паники, все учтется как надо во всех вариантах.
    не понимаю: экземпляр процесса “Выдача…” будет висеть незавершенным все время, пока не придет сообщение Request, потом мы пойдем дальше. В итоге да, получим полное время процесса “Выдача…” включая время простоя (пока клиент не шел за картой), но чистое операционное то время - нет. Как система поймет, что к операционному времени процесса “Выдача…” нужно будет добавить M операций “Find card”?

  38. Дмитрий Пинаев 21.11.11 23:58

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

  39. Anatoly Belychook 21.11.11 23:59

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

  40. Anatoly Belychook 22.11.11 00:07

    >> не технарям такое показывать на мой вгляд нереально

    Завершающая часть моего тренинга по нотации называется “Межпроцессное взаимодействие”. Мы сначала пытаемся решить довольно банальную задачу приема на работу по конкурсу с несколькими резюме от нескольких соискателей в рамках одного процесса. И так пытаемся, и эдак… и все как-то не так получается. И тогда я демонстрирую решение с двумя взаимодействующими пулами. Реакция аудитории всякий раз одна и та же - нечто вроде катарсиса. Я у них спрашиваю: проще стало или сложнее? Стандартный ответ: дело не в этом, так ПРАВИЛЬНЕЕ.

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

  41. Anatoly Belychook 22.11.11 00:10

    Да, а что касается программирования в BPMN многопоточных задач, рекомендую http://mainthing.ru/ru/item/396/

  42. Дмитрий Пинаев 22.11.11 09:00

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

  43. Anatoly Belychook 22.11.11 11:09

    >> глядя на полное время, нельзя сказать хорошее оно или плохое…

    Согласен. Но тут простой принцип: все, что есть на схеме процесса, можно легко замерить. Хочешь - от начала до конца (карта выдана), хочешь - от начала до промежуточного события (карта изготовлена). Т.е. укоротить отрезок, на котором замеряется время, всегда можно. А вот расширить отрезок, если на схеме процесс завершается не дойдя до своего логического конца, значительно труднее. Поэтому надо тянуть его по-максимуму - там разберемся какая метрика в итоге будет востребована. Вполне возможно что обе.

  44. Дмитрий Пинаев 22.11.11 11:23

    Ясно.

  45. Дмитрий Пинаев 22.11.11 11:42

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

  46. Anatoly Belychook 22.11.11 11:57

    Можно, можно. Но не нужно.

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

    А тут получится - 1000 задач на 40 страницах веб-интерфейса, с которыми ничего сделать нельзя, и среди них разбросаны несколько (или несколько десятков) задач, пришедших из других процессов, которые таки надо брать и делать.

    Не завидую я и тому кассиру, и тому, кто предложит ему работать в таком режиме.

    И еще, повторяю: человек может прийти до того, как карточка готова. У кассира задачи нет, он возьмет паспорт, не найдет задачи, пожмет плечами и скажет “ничего не знаю”. В моей же схеме система ему даст четкий ответ: то ли от человека вообще не было заявления, то ли ему отказали, то ли он пришел слишком рано, то ли он пришел во-время, но мы не успели.

  47. Дмитрий Пинаев 22.11.11 12:15

    >>И еще, повторяю: человек может прийти до того, как карточка готова. У кассира задачи нет, он возьмет паспорт, не найдет задачи, пожмет плечами и скажет “ничего не знаю”. В моей же схеме система ему даст четкий ответ: то ли от человека вообще не было заявления, то ли ему отказали, то ли он пришел слишком рано, то ли он пришел во-время, но мы не успели.
    да, верно.

  48. Дмитрий Пинаев 22.11.11 12:45

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

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

  49. Anatoly Belychook 22.11.11 13:04

    Дмитрий

    Учите матчасть :)

    Сообщение - это точка-точка, сигнал - это широковещательная коммуникация.

    Соответственно, если сообщение направляется в середину процесса (в промежуточный обработчик события “сообщение”), как в данном случае, то необходимо указать Id конкретного экземпляра процесса, в который сообщение должно быть послано. Этот Id берется из базы данных карточек к выдаче - основной процесс записывает туда свой Id вместе с информацией об очередной карточке и о ее получателе.

  50. Дмитрий Пинаев 22.11.11 15:29

    Анатолий, ну собственно и учу с Вашей помощью ;)

  51. Привет, коллеги!

    Цитирую Анатолия: “… В моей же схеме система ему даст четкий ответ: то ли от человека вообще не было заявления, то ли ему отказали, то ли он пришел слишком рано, то ли он пришел во-время, но мы не успели…”

    Операционист возьмет паспорт клиента, введет ФИО в базу и получит полную информацию о статусе (готова, не готова, просрочена и т.п.). “Висящий” экземпляр “супер-мега сквозного” процесса ему, вообще говоря, не нужен. Нужно ли это начальнику отделения? Например, сколько карт было выдано каким сотрудником. Думаю, что тоже не нужно.

    Далее, “тянуть” экземпляр “супер-мега сквозного” процесса от приемки заявления через все производственные и логистические этапы с практической точки зрения абсурдно. Именно абсурдность примера меня и смутила. Долго не мог понять практической целесообразности такой “многопоточности”. Сейчас пример Анатолия понял, но практического смысла в нем все равно не вижу.

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

    Желательно приводить реальные примеры, решившие конкретные практически задачи клиента…. Космические крейсера в эту категорию тоже не попадают ;-)

  52. Anatoly Belychook 22.11.11 20:47

    >> Операционист возьмет паспорт клиента, введет ФИО в базу и получит полную информацию о статусе (готова, не готова, просрочена и т.п.).

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

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

    >> Нужно ли это начальнику отделения? Например, сколько карт было выдано каким сотрудником. Думаю, что тоже не нужно.

    И ошибаетесь. Например, в Сбере от этого зависит размер зарплаты операционистов - знаю от человека, эту самую зарплату получающего.

    >> Далее, “тянуть” экземпляр “супер-мега сквозного” процесса от приемки заявления через все производственные и логистические этапы с практической точки зрения абсурдно.

    Вообще-то продолжительность от обращения клиента до полного его удовлетворения - это ключевой показатель качества процесса. И вдруг “абсурдно с практической точки зрения”?! Я в шоке.

    >> Часто Вы интересовались у банка, на каком этапе находится Ваша карта - на бумаге или уже в производстве?! Отслеживали этапы “прохождения” вашей карты через интернет-сайт банка?

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

    >> Желательно приводить реальные примеры, решившие конкретные практически задачи клиента

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

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

    Реализовали ли они эту схему в системе BPMS? Нет, этот банк пока не имеет видов на исполняемые схемы процессов, их интересует сугубо моделирование процессов в BPMN для целей описания и регламентирования. Не проверял, но у меня нет сомнений, что они его зарегламентировали примерно в том виде, как тут показано.

  53. Anatoly Belychook 22.11.11 20:59

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

  54. “…Вообще-то продолжительность от обращения клиента до полного его удовлетворения - это ключевой показатель качества процесса. И вдруг “абсурдно с практической точки зрения”?! Я в шоке…”

    Показателей может быть много. Для их расчета и мониторинга внедрение BPMS - один из возможных вариантов, причем весьма недешевый.

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

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

  55. Anatoly Belychook 23.11.11 19:26

    >> BPMS - один из возможных вариантов, причем весьма недешевый

    Вроде мы обсуждали логику процесса, а не цену софта?

    >> Бизнесу нужны эффективность, а не мода.

    Оставьте пожалуйста менторский тон.

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

    Я большие корпоративные системы и разрабатывал, и внедрял. А Вы?

  56. Привет, Анатолий!

    ОК. Не буду учить Вас на “лыжах кататься” (это про “менторский” тон).

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

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

    По данному примеру у меня вопросов больше нет.

    С уважением,
    Владимир Репин

  57. Julia Wagner 24.11.11 14:06

    Привет всем участникам!

    Владимир,
    твое предложение
    > 10. при обращении клиента проверить у него документы и найти карту в пачке карт (либо найти ее в списке аннулированных по срокам карт);
    > 11. оформить документы на выдачу карты (и учесть в базе данных банка);
    > 12. выдать карту клиенту.
    если я правильно тебя поняла, касается не принципа взаимодействия процессов, а детализации процесса выдачи карты (его части). Не вижу проблемы - шаг, названный Анатолием “Найти карту” может быть не одним шагом, а несколькими, в том числе и п.10 может быть выполнен там же.
    Пункты 11 и 12 могут быть выполнены только в случае успешного поиска, поэтому их выполнение относится к части “Выдать карту”, которая тоже может быть детализирована, и содержать даже большее количество действий.
    Предлагаю абстрагироваться от деталей и оставить два действия “Найти” и “Выдать”.
    Если ты считаешь принципиальным, чтобы эти действия были в одном процессе, то это вариант, который предлагает Aliya - вынести шаг “Выдать карту” в процесс “Обращение за выдачей”. Тогда, как предлагает Анатолий, ожидание ответа, что карта выдана, оставить в процессе “Выдача банковской карты”.
    А вот разделить эти процессы - это уже принципиальный вопрос. Тут действительно другой процесс. Анатолий назвал его “Выдача банковской карты”, но на самом деле этот процесс имеет более глубокий смысл. Это, по сути, процесс, отслеживающий состояние карты. Карта заказана, изготавливается, выдана, а дальше будет следовать еще один автомат: закончилась, утеряна и т.д. Я бы и рассмотрение заявления вынесла в другой процесс, т.к. на жизненном пути карты может быть заявление о ее утере, обмене и т.д.

  58. Привет, Юля!
    Спасибо за разъяснения. Стала более понятна мысль Анатолия.

  59. Фёдоров Игорь 22.12.11 12:55

    Анатолий,
    Как учил философ Кант, предмет, произведенный априорным синтезом воображения, есть предмет идеальный, несуществующий. Процесс, описывающий изменение идеального объекта сам является идеальным, существует только в голове аналитика. Пытаться моделировать идеальный процесс, да еще в нотации BPMN несколько опрометчиво.
    Хотите пример, пожалуйста. Клиент обратился в компанию с просьбой выдать кредитную карту (Рис 2). Вполне естественно описать основной процесс в виде BPMN диаграммы (пул «Выдача банковской карты»). Но что есть пул, который называется Клиент? Я предположу, что клиент есть частное лицо. Пул изображает процесс, который происходит в голове клиента. Не кажется ли Вам, что мы начинаем вторгаться в область высшей нервной деятельности. Клиент инициирует основной процесс посылкой сообщения, затем принимает сообщение, что карта готова. Но сообщение это не электронная почта. Видимо, клиенту доступны чтение мыслей на расстоянии и перемещение предметов в пространстве силою мысли.
    Вот если бы Вы сказали, что моделируется процесс B2B, я бы согласился, тогда такая конструкция имеет право на существование. Но и тут я бы был осторожен. Ответьте пожалуйста, как один процесс посылает сообщение в нужный экземпляр другого процесса, когда они не связанны родственными отношениями?
    В BPM всё как в Unix, родительский процесс знает номер процесса потомка и наоборот. Но что бы послать сигнал другому процессу, нужно знать его реальный ID. На рисунке 2 изображен процесс, посылающий сигнал потомку, тут все нормально (с учетом предыдущего замечания о B2B взаимодействии). Но на рисунке 3 есть пул «Обращение за выдачей карты», который не связан «родственными» отношениями с другими процессами. Здесь начнутся сложности. Вообще говоря, BPMN предлагает решение этой задачи, но увлекшись аналитическим моделированием идеальных процессов, мы забываем о реальных сложностях и проблемах.

  60. Anatoly Belychook 22.12.11 13:13

    Игорь

    Спасибо за цитату из Канта. Впечатлен.

    По поводу пула “Клиент” - это ни в коем случае не процесс. Пул в BPMN изображает либо процесс, либо внешнюю сущность. В данном случае мы имеем дело со вторым вариантом.

    По поводу Id процесса замечание совершенно верное: чтобы послать сообщение другому процессу, нужно знать его Id. Но для этого вовсе не обязательно эти два процесса должны быть связаны родственными отношениями.

    Так, процессы, изображенные на рис.3, взаимодействуют через данные: основной процесс “Выдача банковской карты” записывает в БД карт к выдаче не только реквизиты карты (включая ФИО клиента), но и собственный Id! Это дает возможность вспомогательному процессу, в случае успешной идентификации записи в БД, относящейся к данному клиенту, извлечь Id из базы и успешно послать сообщение туда, куда следует.

    Так что возвращаю мяч обратно - автор вовсе не увлечен аналитическим моделированием и в курсе реальных сложностей, а вот отдельные комментаторы похоже чересчур увлеклись философией ;)

  61. Фёдоров Игорь 23.12.11 17:25

    Уважаемый Анатолий,

    Стартовое событие в основном процессе - поступление сообщения (message) от клиента.Поясните пожалуйста, как Клиент посылает это сообщение из “внешней сущности”? Если процесса Клиент нет, то послать сообщение некому. Значит ваша модель работать не будет - не чем стартовать основной процесс.

    Даный паттерн применяется для B2B, где есть процесс Клиент, который работает в BPM и может посредством сообщения стартоывать экземпляр процесса у заказчика.

  62. Anatoly Belychook 23.12.11 17:45

    Игорь

    Сообщения в BPMN могут использоваться двояко:

    1) Как средство межпроцессного взаимодействия. В этом случае за пунктирной стрелочкой в исполняемой среде стоит вполне конкретный механизм типа message queue, обеспечивающий доставку сообщения из одной указанной точки в другую.

    2) Как средство документирования взаимодействий с внешним миром, который моделируется пулами-внешними сущностями, иначе называемыми black box. В этом случае за пунктирной стрелочкой никакой исполняемой семантики не стоит, фактически она играет роль комментария к схеме.

    Кто-то рисует исполняемые диаграммы BPMN, кто-то аналитические… это нормально. Внешняя сущность есть элемент аналитической диаграммы, но диаграмму на рис.3 легко превратить в исполняемую - достаточно выкинуть пул “Клиент” и сообщения, идущие в/из него, и заменить message start на none start. А вот диаграмму на рис.2 так легко в исполняемую не превратить.

  63. Илья Логинов 10.04.12 16:03

    У Анатолия ангельское терпение. То отбивает нападки о правильности выдачи карты, а не по теме статьи, для которой предметная область была выбрана как пример. То замечания программистов, которые думают что схемы нужны программистам, и отправку сообщения клиентом никак не воспринимают обращение клиента через окошка операциониста или иным способом, ведь в реальной жизни не все можно автоматизировать, а прелесть нотации в том что она описывать может все задачи в том числе ручные, заменив массивы текстовых инструкций, в которых работник может утонуть при ознакомлении. Чувствуется преподавательский опыт! Сам когда то вел семинары и лекции, в аспирантуре) Еще один спорщик пытался доказать что нужно описывать процессы в общей куче, а не современной нотацией, к которой потому и пришли, что удобно распараллеливать процессы,…

А что вы думаете?

Captcha

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