Применение правил выделения процессов

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

После применения одного из вышеупомянутых правил в сети функций и работ организации выделен один процесс (рис. 1.29). Границы процесса обозначены жирной линией, а функции, попавшие в данный процесс, закрашены белым цветом.

Рис. 1.29. Результат выделения процесса, соответствующего требованиям одного правила

Если при выделении процессов применить несколько правил одновременно, то достаточно часто может встретиться ситуация, когда границы процессов, выделенных по различным правилам, могут не совпасть (рис. 1.30). На этом рисунке результаты выделения процесса по трем правилам изображены тремя разными границами: сплошной линией, штриховой и штрихпунктирной. Функции, однозначно попавшие в состав процесса, остались белого цвета, а «спорные» функции имеют вертикальную штриховку. При выделении процессов в организации именно эти спорные функции приводят к разногласиям между владельцами процессов, они требуют длительного согласования и увязывания процессов между собой. Они же создают проблемы при попытке отработать механизм выделения процессов на пилотном проекте. Владелец пилотного процесса, пользуясь правом первопроходца, решает спорные проблемы взаимодействия в свою пользу.

гих, смежных процессов, разногласия появятся снова, но исправить их будет уже сложнее, так как сотрудники пилотного процесса уже работают по новой схеме.

Рис. 1.30. Применение нескольких правил при выделении процессов приводит к несовпадению границ выделенных процессов

Пример 1.15. В одной небольшой организации с численностью работающих менее 100 человек было выделено 5 процессов. Согласование взаимодействия между ними вызвало такие жаркие споры между владельцами, что в течение полутора месяцев они не могли договориться между собой. Согласование было проведено с помощью волевых решений генерального директора, который собрал назначенных владельцев процессов у себя на совещание в выходной день.

Попытки увязать правила и процессы между собой могут привести к неоднозначной ситуации. Ничего страшного в этом нет. В ходе описания процессов придется решать много проблем, так как на бумагу выкладывается то, к чему «все привыкли, все знают, но никто не хочет ничего менять». Не нужно бояться изменений. Изменения приносят выгоду организации, если они хорошо просчитаны экономически. Проект описания процессов организации длится от нескольких месяцев до года, и его результатом должна быть не модель процессов, а разработанная и внедренная система эффективного управления организацией.

Для решения же проблем с увязыванием взаимодействия процессов из практических соображений можно порекомендовать следующее:

а)              отдать приоритет выделению процессов, совпадающих с рамками структурных подразделений, имеющих собственные планы и бюджеты. В этом случае владельцем процесса становится руководитель данного подразделения и меньше возникает проблем в организации взаимодействия и распределения ответственности за результаты процессов;

б)              выделить процессы по границам подразделений в первом приближении. При согласовании описаний процессов, придется искать компромиссное решение для границ процессов и ответственности их владельцев. При этом первоначально установленные границы процессов могут измениться.