Alternative title: “Micromanagement”.
The typical first BPM project issue: how deep to dig into a business process details?
We were engaged into a process called “Purchase order by the three-tier agreement” in one of our first projects. Here is the brief:
- A three-tier agreement is concluded by and between the buyer, the manufacturer and the supplier - manufacturer’s authorized partner.
- The agreement is designed as a framework: it specifies prices, terms and conditions, but not the items to be purchased nor the volume. Each purchase shall be specified by a separate specification containing items and quantities. When signed such a specification enforces contractual obligations to all parties.
- The process is managed by the supplier and there were no intention to directly attach the buyer or manufacturer to BPMS. The whole process runs inside supplier’s organization yet there were such activities as “send the specification to manufacturer for signature” or “ship the goods to buyer”.
The process consists of four majour phases:
- Agreeing the order.
- Signing the specification.
- Delivery.
- Payments and deal closure.
Let’s consider the first phase “Agreeing the order”. Despite terms and conditions are set by the agreement, the bargaining may happen here, e.g. the buyer may request an additional discount for a large order or tougher delivery terms tied to the internal project schedule. In such cases the account manager should agree on the conditions within the organization and with the manufacturer; if the buyer requested too much then a compromise acceptable for all parties should be found. Several iterations may be necessary lasting for months. It’s a delicate work highly depending on account manager’s skills. And this is the key point of the process - the remaining activities are pure routine.
The first version of the process diagram looked like this:
Then it became more compliacated. First, if the manufacturer made a counter-offer that we found acceptable then we should only agree it with the buyer on the next round; the same is true with respect to buyer’s counter-offers. Then it was rightly pointed out that the process may be speed up if negotiations with the manufacturer and the buyer was made in parallel. And so on.
Let me skip the evolution of the process and proceed directly to the resulting diagram:
The key point of this process is that there is a single performer: account manager. No one else cares about where we are inside. Agreeing started / agreeing ended successfully / agreeing failed - that’s all the business (the process owner) is interested in.
I’ve seen process diagrams similar to the first one several times. For example, there was customer’s process of accepting goods to the warehouse with about twenty activities, all performed by a storekeeper. It doesn’t make sence. You get cumbersome scheme prone to frequent changes yet the details do not add value to the process.
Target BPM on the overall process performance and cross-functional problems which are responsible for poor performance in most cases.
It is not easy - you must be ready to find yourself under crossfire if your studies affect existing borders between organization departments. But don’t go the path of least resistance and don’t use BPMS to document a sequence of activities performed by a single person.
У меня в практике был случай, когда заказчик хотел получить внедренный бизнес-процесс с различными шагами для одного и того же исполнителя.
Исполнителями в этом процессе были временные работники, как правило - студенты (ночью они регистрировали различные обращения пользователей и отвечали на некоторые вопросы). Хотя выполняемые работниками операции были не сложными, организация испытывала серьезные проблемы с обучением сотрудников, т.к. текучесть кадров у них была огромной. Кроме того, сотрудники часто ошибались, т.к. за время обучения не успевали нормально изучить должностные инструкции.
Поэтому заказчик хотел, чтобы при клике на задание исполнители получали форму, в которой содержалась бы детальная инструкция для действий сотрудника непосредственно в данный момент, которые он выполнял бы прямо в процессе чтения этого текста. (А обучение сотрудников и должностные инструкции заказчик хотел вообще отменить)
Использовать только одну форму (и только один шаг процесса) было нельзя, т.к. в процессе были “развилки”, кроме того, иногда задания “уходили” и другим сотрудникам.
Андрей
Если речь идет о системе типа service desk, то у нас тоже был такой опыт. Обращение пользователя - раздача поручений - контроль и т.п. Разработав прототип при помощи BPMS, пришли к четкому выводу, что для таких задач лучше использовать готовые системы учета рекламаций (problem tracking).
Впрочем всегда возможны варианты, и сравнивать опыт безусловно полезно.
Толя, но по большому счету одним шагом “согласовать заказ” не обойдешься. Точнее, обойдешься, конечно, в том смысле, что и без BPMS обойтись можно. Но если аккаунт-менеджер работает с этим шагом не один день и даже не один месяц, то необходим как минимум какой-то внешний процесс-напоминалка, который АМ может сам инициировать с этого шага. Причем, не однократно, а несколько раз, пока ведется согласование. Например, заказчику надо позвонить через неделю, а потом еще через три дня…. Иначе все придется держать в голове или просто дополнительные шаги процесса останутся в виде стикеров?
Completely agree. Too often people go down the road of trying to model all sorts of internal state that is not relevant to the group. It is overkill, and it is costly because it causes people busywork in keeping this finely details status up to date.
I am pretty sure you and most the readers will already know this, but in an effort to be precise, one might want to consider a slightly different measure. A step should be included if it is relevant to the group. In some cases there are sequential actions in a row done by the same person yet they are still relevant. Think in terms of “declarations”. A declaration is a speech act that by its utterance changed the state of a group. If an activity is terminated by such an utterance, it is possible that multiple declarations might be made in a row. For example, a person may write an article, declare that they are done writing, then immediately transition into a task of laying out the article. This is two tasks in a row by the same person, but it is reasonable to do this, because others in the group will use the declaration of completion of the writing as an indicator that it is OK to start reviewing the document. Or it may simply be an indicator that tells them that they do not need to find another writer. In most cases you would not model a sequence of tasks by one person because nobody else cares, but there are some exceptions where it is relevant to the group.
I think that both Anatoly’s diagrams are anti-patterns. Previous comments gave a good explanation about the second case. Also, there are many different considerations (e.g. be ready for future changes, avoid mixing of added-value and mechanical activities, etc.) to present some work currently done by the same “person” into a set of activities.
I would like to use the first diagram as a “stress test” for BPMN - how a middle-man management can be expressed as a process. This pattern (called MMM) is an example of decentralised coordination. See http://improving-bpm-systems.blogspot.com/2009/07/blog-process-anti-pattern-one-man-show.html
Thanks all commenters for the valuable input. Didn’t expect this pattern will attract much attention.
Russian-speaking commenters pointed out the cases where several activities scheduled to the same person make sense. Amikheev’s case is BPMS serving as a tutor to a poorly-qualified employee (”a student”). This is a valid case indeed, just let’s be carefull and not apply this technique to activites performed by “knowledge workers” where it may do more harm than help. Another threat: if you pay too much attention on how “To Do Things Right” you tend to lose focus on how “To Do The Right Things”.
Julia Wagner argued that it’d be nice if BPMS served as a reminder for a participant e.g. to make a phone call to the buyer after we send him a proposal. It’s an interesting point: should we stretch BPMS to replace personal caledar services? Forum/discussion services? Document storage services? As for me, I enter my appointments and tasks into Outlook which is later synchronized with my pocket PC so I get all reminders from my phone. Ideally we should be able to initiate a personal calendar entry or a discussion thread from a process activity. BPMS vendors are working on this but we are far from standartization here. Unless it can be done in “one-clieck” we should be carefull and not become “integration maniacs”. And making a “silver bullet” from BPMS replacing services like calendar, discussion, data/content storage and others is even worse (although there may be valid cases).
Keith has made a very true note that we do need several activities if a process reaches a milestones or changes it’s state some other way and this change is of interest for other participants. In fact I was close to this point when noted that in the example considered the business owner is not interested in anything but process start / process results.
So I must agree with Alexander’s note that both diagrams may be anti-patterns - it depends on process “profile”. And appropirate profiles can be defined better now with your input.
Добрый день!
Анатолий, благодарю Вас за блестящий антипаттерн.
Поскольку сталкиваюсь с ним постоянно, придумал даже фирменное название - “Сам шучу и сам смеюсь”. Очень хорошо действует, когда контрагент настаивает на высокой степени детализации
Однако, всегда хочется найти баланс между тотальной опроцедуренностью в системе (взял авторучку, если её нет, согласовал увеличение бюджета и т.д.) и единственным статичным экраном “Бизнес-процесс нефтяной компании”.
Попробую предложить вариант решения. Вот схема:
1. Процесс находится на некоторой стадии, и это - театр одного актера;
2. Но этот актер расходует единственный невосполнимый ресурс предприятия - время. Поэтому есть предложение учитывать его работу над задачей по довольно простой схеме (я нарисовал внутри стадии процесса жизненный цикл задачки, и совершенно не важно, какой бизнес-объект обрабатывается). Принципиальных выходов два: сдвинули стадию или завершили процесс.
3. История обработки пишется на протяжении всей “игры” нашего актера. В нашем случае она позволяет шефу видеть, в каком состоянии работа с задачей, а самому исполнителю не запутаться в очередности обработки. Полагаю, анализ такой истории - прекрасный материал для оптимизации шаблонов процессов;
4. Артефакты, которые возникают в процессе работы над задачкой, фиксируются в карточке задачи или в другой подсистеме, не важно. Но, как Вы справедливо заметили, не нужно делать для них отдельных шагов. На Вашей схеме “Спец. условия согласованы” - как раз пример такого реквизита.
Итог: Цепочка процесса - это эстафета. Нет передачи эстафетной палочки, значит нет и сдвижки шага процесса. При этом:
1. исполнитель получает удобный инструмент управления очередностью задачек;
2. руководитель может увидеть, чем занят его подопечный в режиме онлайн;
3. копится статистика по времени фактической обработки задачами.
Вот такие мысли…
Спасибо за замечательный пост.
Прошу прощения, схемку не так приложил (было бы здорово, если можно было в комментариях картинки прикладывать).
Вот по этой ссылке - картинка
http://img197.imageshack.us/img197/6448/selfishjoke.gif
Контрагент сначала наставивает на высокой степени детализации а потом сам не может разобраться в процессе
На мой вгляд если подряд идут задачи одной организационной роли - их нужно всетаки объеденять. BPM - это оптимизация и постоянные изменения. Если потребуется, процесс можно детализировать.
LaptevDMV: Задачи одной бизнес-роли, идущие подряд, безусловно, нужно объединять. Насколько я понял, об этом и пишет Анатолий.
Я лишь пытаюсь предложить инструмент, который позволит:
* исполнителю удобно управлять очередью задач, не сдвигая шаг процесса,
* руководителю получать отчет о работе над задачами on-line, не беспокоя работника шаблонным “что Вы сейчас делаете”?
Эвристическим путём пришёл в 2004 г. к мнению, что детализацию можно останавливать на уровне оперирования объектами типа “документ” (иногда - сообщение). Действия одного пользователя (роли в рамках Swim Lane в UML) без переходов между Swim Lanes также довольно хорошо объединяются с помощью Use Case. Для последовательности действий одной роли детализация бывает важна, если есть ожидания в некоторых состояниях (например, пока выполняется какая-либо протяжённая во времени работа).