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

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

1. Процесс находится на некоторой стадии, и это - театр одного актера;
2. Но этот актер расходует единственный невосполнимый ресурс предприятия - время. Поэтому есть предложение учитывать его работу над задачей по довольно простой схеме (я нарисовал внутри стадии процесса жизненный цикл задачки, и совершенно не важно, какой бизнес-объект обрабатывается). Принципиальных выходов два: сдвинули стадию или завершили процесс.
3. История обработки пишется на протяжении всей “игры” нашего актера. В нашем случае она позволяет шефу видеть, в каком состоянии работа с задачей, а самому исполнителю не запутаться в очередности обработки. Полагаю, анализ такой истории - прекрасный материал для оптимизации шаблонов процессов;
4. Артефакты, которые возникают в процессе работы над задачкой, фиксируются в карточке задачи или в другой подсистеме, не важно. Но, как Вы справедливо заметили, не нужно делать для них отдельных шагов. На Вашей схеме “Спец. условия согласованы” - как раз пример такого реквизита.

Итог: Цепочка процесса - это эстафета. Нет передачи эстафетной палочки, значит нет и сдвижки шага процесса. При этом:
1. исполнитель получает удобный инструмент управления очередностью задачек;
2. руководитель может увидеть, чем занят его подопечный в режиме онлайн;
3. копится статистика по времени фактической обработки задачами.

Вот такие мысли…
Спасибо за замечательный пост.

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.

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

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.

Если речь идет о системе типа service desk, то у нас тоже был такой опыт. Обращение пользователя - раздача поручений - контроль и т.п. Разработав прототип при помощи BPMS, пришли к четкому выводу, что для таких задач лучше использовать готовые системы учета рекламаций (problem tracking).

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