Let’s consider a fairly typical business process:
- Сustomer requests a proposal.
- We prepare and send the proposal.
- Customer makes a decision.
- In a positive case a contract is concluded.
The first version of the process diagram:
Figure 1. Proposal to Contract
After sending the proposal we will contact the customer periodically about the order.
What’s wrong with this diagram:
1. The customer may bypass the proposal stage and place the order directly.
This problem can be solved by the alternative process start:
Figure 2. Alternative start: bypassing the proposal
2. The time interval from the proposal to the order, first, can be lengthy, and secondly, is beyond our control. And most importantly, it’s practically impossible to decide whether to continue waiting for the order or to abandon it and end the process.
Suppose we are waiting for the answer to our proposal for three months and get no order. Finally we decide to end the process and the order comes the very next day - is it possible? Sure thing. Yet our scheme does not allow this scenario.
The solution is to present “Request to Proposal” and “Order to Contract” as two separate workflows:
Figure 3. “Hello Again”: Proposal and Contract
“Request to Proposal” process ends by formal proposal acceptance or rejection.
Within this scheme a customer may submit an order next week or a year after receiving the proposal. Or contact without the proposal. When the manager receives the order he figures out whether it’s based on a particular proposal and checks its validity (the proposal may already expire). If there is a valid proposal then the contract work starts. Otherwise products/services, prices and delivery terms should be agreed first.
“Hello Again” pattern should be used at the point of a business process where the control is passed to external agent (e.g. customer) which has no obligations towards us. At such point the process should be split into two separate workflows connected by data.
The process diagram can be improved by providing automatic transition from the proposal to contract work. It may be accomplished by ending first process with a signal that starts another one:
The solution is to present “Request to Proposal” and “Order to Contract” as two separate workflows:
Figure 4. Alternate start: automatic start of the contract workflow
Let’s proceed from the contract conclusion to execution.
We are currently involved in a project at the company doing geodetic works on a prepaid basis. The number of contracts concluded in their business practice is more than the number of contracts fulfilled - some customers delay advance paiment, others don’t make it at all.
The case is similar to Request to Proposal: 1) the process control goes to the client for undefined time, 2) despite the formally signed contract there is no material obligations until the advance payment is made.
Let’s apply “Hello Again” pattern again by splitting the contract conclusion and execution into separate workflows:
Figure 5. “Hello again”: Contract and Execution
When an advanced payment is received the contract is identified by the invoice number and/or customer name and the execution begins.
Once again it’s little bit more complicated in real life: 1) contracts with trusted customers doesn’t require advanced payment, 2) in some cases the company begins execution before obtaining the advance payment at it’s own risk. These scenarios are implemented in the diagram:
Figure 6. Alternative starts: without advance payment, at our own risk
In both alternative scenarios, when the work is completed we should wait for payment. It’s possible that it doesn’t happen but unlike the above situation with the proposal and contract, there is a material obligation. Therefore the pattern “Hello Again” does not apply - we can’t just say goodbye to the customer and hope that someday he will pay. So we’ll wait a while and if money doesn’t come the deal will close with a loss and we will consider going to the court.
In this case the process ends by the signal “No payment”. Here we use the “Cutoff The Ends” pattern that will be considered in the next article.
Добрый день, я бы не стал совсем убирать цикл “справиться о решении”, в отдельных случаях необходимо вести сделку более плотно
- отправили кп
- клиент посмотрел, оценил, деньги ждёт через квартал
- за это время конкуренты подсуетились и предложили своё КП
- ………
Скорее всего это отдельный процесс мониторинга выставленных КП
Олег
Нет возражений - вполне можно в исходном процессе предусмотреть мониторинг выставленного КП в течении какого-то определенного времени. Например, до объявленного заказчиком срока подведения итогов, Если он есть, этот срок.
У меня вообще все очень упрощенно показан этот процесс. Можно попытаться отправить заказчику сначала проект КП, получить его реакцию, доработать и отправить окончательный вариант. Можно предусмотреть возможность корректировки его уже после отправки “окончательного” варианта и т.п.
Суть моего предложения в том, что в конце концов процесс подготовки КП надо завершать, а не длить его бесконечно. Или до того, как заказчик примет решения - это в сущности то же самое.
Завершить этот, но быть готовым открыть новый процесс.
Лучше не в исходном процессе, а в отдельном процессе
Думаю что данная ситуация встречается довольно часто
как раз 3 процесса
Подготовка КП
Мониторинг - периодические контакты с клиентом
Реализация контракта
То что упрощено - согласен, принцип понятен, дальше нюансы конкретных процессов
Все зависит от того, насколько жестко мы хотим организовать мониторинг:
- если по какому-то определенному плану и с напоминаниями исполнителю, то реализовывать надо в том же процессе
- если по принципу “менеджер сам вспомнил - позвонил - отчитался о результате звонка”, то в отдельном
Если мониторинг делать отдельным процесса, то в промежутке между двумя контактами с клиентом у нас не будет процесса, который бы “помнил”, что пора снова с ним связаться.
если КП в базе, с признаками - мониторинг, ответственный
то почему нельзя запускать копии процессов по таймеру на ответственного ?
Можно, почему нельзя.
По сути, Вы предлагаете сделать “процесс для бедных” в виде записи в базе и программы, которая такие записи периодически сканирует.
Смысл?
Скорее для “богатых”
Впрочем готов согласиться, в этом контексте это не имеет смысла
Анатолий, смотрю уже не первую вашу статью, и везде вижу очень упрощенные примеры. Хотя и больших, достаточно важных процессов.
И в этом статье не вижу того блока, который идет всегда при решении школьных задач - “Дано” с описанием начальных условий, ограничений и т.п.
Старик Деминг придумал когда-то цикл управления - PDCA. Во всех ваших примерах звучит только “Do”, остальные элементы процесса не видны. Не описываете Вы их и при словесном описании процесса.
Я не очень хорошо разбираюсь в BPMN, поэтому хотел уточнить - это ограничение самого стандарта (всё становится слишком сложным),. или вы принципиально упрощаете?
Александр
Этот блог и эта статья вообще-то не для школьников. С интересом познакомлюсь с Вашими статьями, следующими шаблону школьных задач.
Относительно упрощенных примеров - пожалуй сочту за комплимент. Действительно, я пытаюсь выделить из мешанины схем реальных процессов некоторые простые, притом повторяющиеся паттерны, которые можно было бы освоить и использовать при решении новых задач. Выкладывать решения реальных задач с десятками потоков работ и сотнями задач, во-первых, не вижу смысла - чему на них можно научиться? А кроме того, это было бы противозаконно - ни одна компания не обрадуется тому, что схемы ее основных процессов выложены в свободный доступ.
Цикл PDCA применительно к моделированию процессов выглядит так:
P - определить метрики и целевые показатели процесса и на их основе разработать схему процесса
D - исполнять процесс согласно утвержденной схеме, накапливать статистику исполнения
C - анализировать статистику на предмет достижения целевых показателей
A - вносить коррективы в процесс на основе выявленных расхождений и неоптимальностей
К BPMN это прямого отношения не имеет - цикл останется тем же самым вне зависимости от используемой нотации.
Вы, похоже, под PDCA понимаете нечто иное, но я не улавливаю что именно.