Крайне распространенная ситуация: сотрудник выполняет задание, руководитель проверяет и имеет возможность отправить обратно на исправление. Обычно ее моделируют так:
Я рекомендую чуть более изощренную схему:
При этом содержание заданий “Сделать” и “Переделать” может не отличаться, т.е. разница только в названиях. В чем смысл:
- В первом случае сотрудник видит у себя в списке задач, условно говоря, “Сделать дело”. Делает его, жмет на кнопку и… через 15 минут снова видит у себя эту же задачу, относящуюся к этому же экземпляру процесса. Это сбивает с толку, особенно если за эти 15 (или 30, или 130) минут он успел позаниматься какими-то другими делами.
- Еще вторая схема лучше с точки зрения мониторинга: в ней легко посчитать число переделок и потраченное на них время и бороться за то, чтобы свести их к нулю. Положим, число переделок можно подсчитать и в первой схеме - просто вычесть из числа исполнений задачи число экземпляров процессов. Но суммарное потраченное время (т.е. неоправданные затраты) в первой схеме подсчитать будет затруднительно.
Вот такой получился паттерн: почти тривиальный, но зато (или как раз поэтому?) потенциально широко применимый.
Сталкиваюсь с этой проблемой в своей практике. Согласен, вторая схема дает большое преимущество.
Анатолий, а если чуть расширить задачу, и посмотреть на другие варианты, а именно - сотрудник может не понять задачу, ему может не хватить информации/ресурсов для ее выполнения, 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/
Структурировать по руководителям мне представляется неудачной идеей: получим вместо процессного функциональное управление. Руководителей в качестве владельцев процессов назначать надо обязательно, но отталкиваться следует не от функционального деления, а от цепочки создания ценностей.
Насчет цепочки создания ценностей согласен полностью.