Very common case: an employee performs the task, his boss checks the work and may return it back for correction. It’s usually modelled like this:
I recommend slightly more sophisticated diagram:
The content of two jobs “Do” and “Redo” may not differ at all, it’s about task names. Now what’s the point:
- Within the first scheme an employee sees a task in his list: “Do It. He does, then presses the button and… after 15 minutes he sees the same task belonging to the same process instance. It’s confusing, especially if he managed to work on some other things during these 15 (or 30, or 130) minutes.
- The second diagram is also better from monitoring perspective: it’s easy to calculate the number of “Redo” executions and the total time spent for them and then focus on bringing them to zero. OK, the number of redo’s can be calculated within the first scheme too - by subtracting the number of process instances from the number of task executions. Yet the total time spent (i.e. unjustified costs) won’t be so easy to calculate within the first scheme.
So that’s the pattern: almost trivial yet (or therefore?) widely applicable.
Сталкиваюсь с этой проблемой в своей практике. Согласен, вторая схема дает большое преимущество.
Анатолий, а если чуть расширить задачу, и посмотреть на другие варианты, а именно - сотрудник может не понять задачу, ему может не хватить информации/ресурсов для ее выполнения, etc. В этом случае сотрудник отклоняет задачу, а руководитель, скорректировав условия, возвращает обратно. В этом случае стоит ли делать еще один вид задания, или можно использовать уже введенные виды заданий?
Андрей
Согласен, такая постановка задачи имеет смысл. Надо предусмотреть в процессе атрибут “задание выполнено” и дать возможность сотруднику завершать задание, оставляя его в положении false. Тут сработают обе рассмотренные схемы.
Но если считать, что такая ситуация возможна в любой точке процесса, то схема процесса превратится в сущий кошмар. Может, исполнитель с начальником в рабочем порядке между собой договорятся? В конце концов, телефон никто не отменял.
Не стоит также забывать про встроенный в большинство BPM-систем механизм делегирования: пользователь имеет возможность передать свое задание другому. Подчиненному, если задание для него самого слишком простое, или начальнику, если, наоборот, он не может с ним справиться.
И еще как правило есть возможность добавить к задаче произвольные комментарии, которые увидят исполнители последующих шагов.
А.Б.
Anatoly-
this is a good case where, in some cases, the software vendor can add value to the generic BPMN. One vendor, for example, automatically tracks “redo” effort if you route back to the same activity. Both approaches will work, and managing it manually gives you more precise control. But if software vendors will look more to how to answer interesting process improvement questions these kind of features would be “baked in”…
Scott
I agree, the feature you refer to should be not a competitive advantage but a must-have. People do stupid mistakes all the time: you press the wrong button or pick the wrong value from a dropdown list because your mouse got crazy for a second and oops - the process picks the wrong route and you can’t do anything about it. There must be an opportunity to roll it back.
BTW, there is another vendor who implemeted it differently: each activity has a “commit transaction” flag. If it’s set to false then you can roll it back to the beginning. Smart but probably too smart for the circus
А у нас в компании руководитель никто иной как исполнитель процесса, имеющий подпроцессы, в которых свои исполнители. Когда мы перешли на процессно ориентированную систему руководства все стало на свои места в вопросах организационной структуры. Соответственно вынос задач руководителя в отдельные задачи в нашем случае лишен всякого смысла
Добавлю - а вот администратор как раз и занимается контролем исполнения. А в вашей схеме вы попутали администратора, отвечающего за контроль с руководителем, отвечающего ЗА РЕЗУЛЬТАТ, соответственно имеющий право давать указания внутри процесса вплоть до изменения алгоритма с целью достижения положительного результата в конечной точке процесса, ведь именно он несет ответственность…
Илья
Слишком тонкий комментарий к незатейливому посту, в котором речь идет о сугубо технических материях.
Можете переименовать “руководителя” во что угодно, я не возражаю
Цель ясна поста, просто нигде не нашел поста про принципы выделения процессов, а хотелось бы узнать вашу точку зрения. Везде принцип выделения процессов как бог на душу положит или иными словами путем некоего аналитического умозаключения консультанта, хотя может я не прав? Считаю что процессы нужно выделять не по академическому принципу предметной области бизнеса, а по руководителям. Соответственно объединять процессы с общей предметной областью знаний (профессии) и закрепить за ними соответствующего руководителя с соответствующим образованием и опытом. Как то это тема вообще нигде не затрагивается, хотя исполнителем процессов являются люди. Вот и написал сюда потому как некуда больше а тут вроде краем затронуто
Признаю, есть такая недоработка. То есть методология-то имеется, но здесь на блоге о ней сказано всего несколько слов: http://mainthing.ru/ru/item/402/. Чуть больше тут: http://b-k.ru/solutions/express/
Структурировать по руководителям мне представляется неудачной идеей: получим вместо процессного функциональное управление. Руководителей в качестве владельцев процессов назначать надо обязательно, но отталкиваться следует не от функционального деления, а от цепочки создания ценностей.
Насчет цепочки создания ценностей согласен полностью.