Альтернативное название: “Микроменеджмент”.
Типичное затруднение первого BPM-проекта: “на какую глубину копать”, до какого уровня детализировать бизнес-процесс?
В одном из первых наших первых проектов мы занимались процессом под названием “Заказ по трехстороннему договору”. Суть дела:
- Имеется трехсторонний договор, по которому Покупатель приобретает товары у Производителя при посредничестве авторизованного партнера.
- Договор оформлен как рамочный: он оговаривает цены, условия и сроки, но не объемы закупок. Каждая закупка должна оформляться отдельным заказом, который уже содержит конкретные номенклатуры и количества и который после подписания влечет контрактные обязательства для всех сторон по договору.
- Задача управления процессом была поставлена партнером, что совершенно естественно, так как за логистику отвечал в основном он. При этом задача подключения к BPM-системе покупателя или производителя не ставилась. Т.е. процесс от начала до конца протекал как бы внутри организации партнера, но при этом в нем наличествовали такие шаги, как “отправить заказ на подпись поставщику” или “отгрузить товар заказчику”.
По-крупному процесс состоял из четырех этапов:
- согласование заказа
- подписание заказа
- поставка товара
- оплата и закрытие заказа
Рассмотрим первый этап “согласование заказа”. Несмотря на то, что в договоре прописаны, казалось бы, все условия, время от времени возникали нестандартные ситуации: например, покупатель требовал дополнительную скидку за особо крупный заказ, или более жесткие сроки поставки, привязанные к срокам его внутреннего проекта. В такой ситуации аккаунт-менеджер должен был согласовать условия внутри своей компании и с производителем, а если покупатель захотел слишком многого - попытаться найти компромисс, который устроил бы все стороны. Иногда приходилось делать несколько итераций, и в результате процесс затягивался на месяцы. Это деликатная работа, в которой все определял профессионализм аккаунт-менеджера. По сути, именно на этом этапе решалось, состоится сделка или нет, а все остальное - как говорится, дело техники.
В первом приближении схема процесса выглядела так:
Затем схема стала усложняться. Во-первых, если в ходе согласования с производителем он сделал встречное предложение и мы приняли его за основу, то на следующей итерации с ним согласовывать уже не надо; аналогично и с покупателем. Далее было справедливо замечено, что процесс теоретически можно ускорить, если согласовывать его с производителем и покупателем не последовательно, а параллельно. Это тоже отразили в схеме. И так далее.
Избавлю вас от описания эволюции процесса и перейду сразу к схеме, к которой мы пришли в итоге:
Все дело в том, что в этом процессе один исполнитель - аккаунт-менеджер. И никому, по большому счету, не интересно на каком шаге в данный момент находится процесс. Согласование в процессе / согласование закончилось положительным или отрицательным результатом - вот все, что интересует бизнес в лице владельца процесса.
Схемы, похожие на первую, мне потом приходилось встречать неоднократно. Например, у одного заказчика была схема процесса приема товара на склад, в которой было порядка двадцати шагов, и все они выполнялись кладовщиком. Все это ни к чему. Вы получаете громоздкие схемы процессов, которые в силу своей переусложненности подвержены частым изменениям. А главное - такая детализация не добавляет ценности процессам компании.
Нацеливайте BPM на показатели процесса в целом и на проблемы, возникающие на стыках между службами, которые гробят эти показатели.
Это нелегко - будьте готовы к тому, что, когда вы начнете влезать в проблемы взаимоотношения служб компании, вы окажетесь под перекрестным огнем . Но все же не поддавайтесь соблазну пойти по пути наименьшего сопротивления и не опускайтесь до документирования средствами BPMS последовательности шагов, выполняемых одним сотрудником.
У меня в практике был случай, когда заказчик хотел получить внедренный бизнес-процесс с различными шагами для одного и того же исполнителя.
Исполнителями в этом процессе были временные работники, как правило - студенты (ночью они регистрировали различные обращения пользователей и отвечали на некоторые вопросы). Хотя выполняемые работниками операции были не сложными, организация испытывала серьезные проблемы с обучением сотрудников, т.к. текучесть кадров у них была огромной. Кроме того, сотрудники часто ошибались, т.к. за время обучения не успевали нормально изучить должностные инструкции.
Поэтому заказчик хотел, чтобы при клике на задание исполнители получали форму, в которой содержалась бы детальная инструкция для действий сотрудника непосредственно в данный момент, которые он выполнял бы прямо в процессе чтения этого текста. (А обучение сотрудников и должностные инструкции заказчик хотел вообще отменить)
Использовать только одну форму (и только один шаг процесса) было нельзя, т.к. в процессе были “развилки”, кроме того, иногда задания “уходили” и другим сотрудникам.
Андрей
Если речь идет о системе типа 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. Для последовательности действий одной роли детализация бывает важна, если есть ожидания в некоторых состояниях (например, пока выполняется какая-либо протяжённая во времени работа).