Не секрет, что отдельные виды деятельности в некоторых процессах повторяются. В большинстве случаев, при проектировании того или иного процесса, эта деятельность включается в описание процесса, как его неотъемлемая часть. Например, порядок взятия в работу назначенного на специалиста объекта, порядок организации согласования, порядок распределения работ между несколькими группами специалистов, порядок контроля сроков. Список можно продолжать. Эту деятельность не назвать процедурой, т.к. слишком мал объем выполняемых работ и выход сам по себе не несет никакой практической пользы. Но они активно используются при построении процедур процессов.
По сути, подобные виды деятельности определены сложившимися правилами работы в компании. Например, в некоторых компаниях немыслимо привлечение ресурса без согласования с его непосредственным руководителем. И данное правило будет распространяться на все процессы, требующие назначения работ, без исключения. С его учетом можно описать деятельность по назначению и распределению работ в группе специалистов.
Таким образом, задумавшись и описав "запчасти" один раз, мы можем использовать их при проектировании других процессов. При этом будет гарантировано единообразие, что снизит вероятность бардака в голове участников процессов. Кроме того, сведение простых действий в единый источник позволит существенно упростить и описания процессов и их обновление, если вдруг одна из "запчастей" поменяется.
Сложность в этом подходе пока видится одна – при слишком детальном описании "запчастей" может получиться так, что в определенных процессах потребуется специфика, лишняя для других процессов, которые используют эту же запчасть. Например, для процесса управления инцидентами может быть важен контроль срока взятия в работу назначенного объекта, а для процесса управления проблемами – нет. Подобных сложностей можно избежать, выбрав приемлемый уровень детализации и вынося в "каталог запчастей" только действительно общую часть видов деятельности.Кстати, сама по себе идея стандартизации видов деятельности не нова. Например, в документе Process assessment model (PAM): Using COBIT 5, один из разделов Policies and Standards носит название Standardised procedures и описывается как A document outlining the procedures that should be followed in all implementations of the processes.
Описанный прием очень часто реализуется на EPC диаграммах. Как только вы понимаете, что в нескольких процессах, с их уникальными процедурами или операциями, появляются не уникальные, однозначно повторяющиеся цепочки – вы их схлопываете в отдельный процесс или процедуру и дальше работаете с ними через процесс-интерфейсы. Самое неприятно в появлении таких вот неприкаянных толи процедур, толи процессов – это то, что абсолютно не понятно куда их встраивать в единой процессной модели компании. Обычно они сваливаются в обеспечивающие процессы и объединяются в группу процессов с названием «Управление операциями».