Наверх

Когда регламентировать

Время чтения: 4 минуты
5
Когда регламентировать

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

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

  • Повышение качества и снижение стоимости работ. Достигается фиксацией в регламенте "лучших практик", в идеале своих собственных, но возможно использование и стороннего опыта. Правда к подобным вещам нужно очень осторожно подходить и оценивать: близость культуры (в первую очередь управленческой, но исполнительская тоже имеет большое значение), масштабы бизнеса (скажем, эксперименты с оргструктурой, относительно безболезненные для малого бизнеса, для крупного могут стать смертельными), специфику отрасли (об этом вроде бы не забывают, но для порядку упомянем тоже), конкурентные отношения (слепое повторение за конкурентом - верный способ оставаться позади).
  • Управляемость. Нормируя состав работ, ресурсопотребление и требования к результату, удается повысить точность планирования и упростить контроль качества.
  • Прозрачность. Это вторичная цель (т.е. не является самоцелью). В наибольшей степени прозрачность модели процесса, отраженной в регламенте, служит для повышения управляемости. Но прозрачность также может быть полезна и для исполнителей - понимать, какую ценность для бизнеса создает их деятельность. Хотя нередка и противоположная ситуация - исполнитель может быть заинтересован в сохранении своей деятельности в "черном ящике", чтобы удержать статус незаменимого.
  • Масштабируемость. Хорошо организованная регламентирующая документация упрощает обучение новых сотрудников. Но это только в простейших случаях расширения компании. Гораздо более важной оказывается роль регламентов при тиражировании существующей структуры на сеть открываемых филиалов.

Ранее высказывалась точка зрения, что модель процесса должна быть полной и должна иметь взаимно-однозначное отображение на реальный процесс. Очевидно, что этот подход гарантированно обеспечит достижение поставленных целей. Очевидно также и то, что построение и актуализация моделей постоянно меняющихся процессов - дело ресурсоемкое, сколь оптимально бы оно ни было организовано.  Является ли тотальное моделирование единственным вариантом?

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

  • Повышение качества и снижение стоимости работ. Если речь о лучших практиках, то естественной границей регламента служит реально существующий опыт. Фантазии "а как бы было правильно в случае..." уже излишни.
  • Управляемость. Нормировать можно только устоявшиеся процессы. Если процесс постоянно меняется под влиянием требований бизнеса, то втискивать его в прокрустово ложе норм пока еще рановато.
  • Прозрачность. Для обеспечения высокой степени прозрачности часто хватает "взгляда сверху", без детализации до уровня отдельных действий исполнителей. Исключение составляют только особо критичные процедуры, коих обычно не бывает много.
  • Масштабируемость. Здесь, как и в случае с прозрачностью, важны взгляд сверху на деятельность целиком и высокая детализация описания критичных процедур. Разница только в том, что масштабируемость предъявляет меньше требований к оперативности обновления, но больше - к адекватности моделей.
  • Глядя на список, возникают естественные вопросы - а как же быть с деятельностью, выпадающей из поля действия регламентов? Кто будет отвечать за их качество, стоимость и т.д.? Думаю, самым правильным выходом было бы всегда выделять владельцев процессов, даже если зафиксированная модель процесса состоит буквально из одного только названия.

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

    Чтобы прочитать эту статью до конца,
    или зарегистрируйтесь

    Комментарии 5


    Для обеспечения высокой степени прозрачности часто хватает "взгляда сверху", без детализации

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

    Поясни, пожалуйста, эту мысль.


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



    Одна деталь, чтобы не делать далеко идущих выводов: между "не зафикисировано в регламенте" и "разрешено поступать, как угодно" есть заметное различие Также я не имел ввиду, что вопросами "а как правильно?" вообще не надо задаваться. Кончено надо, но фиксировать возникающие идеи на уровне регламента можно только после того, как они будут опробованы и признаны эффективными.


    К повышению качества и снижению стоимости, наверное, стоит добавить еще снижение временных затрат (они не всегда явно перекладываются в денежные).

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

    Андрей, все верно, именно это я и имел ввиду - уровень регламентации должен определяться поставленными целями, а не жаждой формализации.
    Чтобы прокомментировать, или зарегистрируйтесь