Когда регламентировать
К тому, чтобы заставить регламенты отражать действительность, есть разные подходы. И зависят они, на мой взгляд, от поставленных целей.
К тому, чтобы заставить регламенты отражать действительность, есть разные подходы. И зависят они, на мой взгляд, от поставленных целей. Чтобы разговор был предметным, сразу оговоримся, какими могут быть цели регламентации деятельности:
- Повышение качества и снижение стоимости работ. Достигается фиксацией в регламенте "лучших практик", в идеале своих собственных, но возможно использование и стороннего опыта. Правда к подобным вещам нужно очень осторожно подходить и оценивать: близость культуры (в первую очередь управленческой, но исполнительская тоже имеет большое значение), масштабы бизнеса (скажем, эксперименты с оргструктурой, относительно безболезненные для малого бизнеса, для крупного могут стать смертельными), специфику отрасли (об этом вроде бы не забывают, но для порядку упомянем тоже), конкурентные отношения (слепое повторение за конкурентом - верный способ оставаться позади).
- Управляемость. Нормируя состав работ, ресурсопотребление и требования к результату, удается повысить точность планирования и упростить контроль качества.
- Прозрачность. Это вторичная цель (т.е. не является самоцелью). В наибольшей степени прозрачность модели процесса, отраженной в регламенте, служит для повышения управляемости. Но прозрачность также может быть полезна и для исполнителей - понимать, какую ценность для бизнеса создает их деятельность. Хотя нередка и противоположная ситуация - исполнитель может быть заинтересован в сохранении своей деятельности в "черном ящике", чтобы удержать статус незаменимого.
- Масштабируемость. Хорошо организованная регламентирующая документация упрощает обучение новых сотрудников. Но это только в простейших случаях расширения компании. Гораздо более важной оказывается роль регламентов при тиражировании существующей структуры на сеть открываемых филиалов.
Ранее высказывалась точка зрения, что модель процесса должна быть полной и должна иметь взаимно-однозначное отображение на реальный процесс. Очевидно, что этот подход гарантированно обеспечит достижение поставленных целей. Очевидно также и то, что построение и актуализация моделей постоянно меняющихся процессов - дело ресурсоемкое, сколь оптимально бы оно ни было организовано. Является ли тотальное моделирование единственным вариантом?
Попробуем очертить грань, до которой регламентация эффективна - т.е. уже результативна, но еще достаточно проста.
Глядя на список, возникают естественные вопросы - а как же быть с деятельностью, выпадающей из поля действия регламентов? Кто будет отвечать за их качество, стоимость и т.д.? Думаю, самым правильным выходом было бы всегда выделять владельцев процессов, даже если зафиксированная модель процесса состоит буквально из одного только названия.
Возможно, я учитываю не все цели, которые могут побудить к регламентации. Соответственно и необходимая глубина регламентации в некоторых случаях может оказаться иной. Поэтому, если кто имеет дополнить - присоединяйтесь :)
Комментарии 5
Если есть успешный и проверенный временем способ выполнять операции некоторого процесса - его можно описать в регламенте. Но в описываемом процессе всегда найдутся детали, которые "плавают" от случая к случаю, всегда найдутся исключительные ситуации, с которыми пока еще просто не сталкивались. Мысль в том, чтобы не придумывать, как бы поступать в таких случаях, а просто отказаться от их регламентации.
Одна деталь, чтобы не делать далеко идущих выводов: между "не зафикисировано в регламенте" и "разрешено поступать, как угодно" есть заметное различие Также я не имел ввиду, что вопросами "а как правильно?" вообще не надо задаваться. Кончено надо, но фиксировать возникающие идеи на уровне регламента можно только после того, как они будут опробованы и признаны эффективными.
К повышению качества и снижению стоимости, наверное, стоит добавить еще снижение временных затрат (они не всегда явно перекладываются в денежные).
А вообще, регламентация может как раз сильно стукнуть по эффективности (увеличить затраты). Но на нее идут ради повышения управляемости. Типичный пример - процессы разработки ПО. Пока не стоит проблема управляемости - выгодно применять гибкие методологии с минимумом регламентации. Но как только возникает задача макисмально четко управлять процессом - вперед выходят формальные методологии.