Давайте займемся самым, пожалуй, сложным и важным вопросом менеджмента: когда нужно и когда не нужно вводить системы?

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

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

В отсутствие системы решение принимает конкретный человек применительно к конкретному случаю. Такие решения «по случаю» я буду называть решениями ad hoc, или ручным управлением.

Так, например, если у нас есть должность и грейд, мы принимаем человека на данную должность, а его зарплата определяется вилкой грейда – это формализованная система. А вот определять конкретное значение внутри вилки грейда мы будем применительно к конкретному случаю, т. е. ad hoc. Можно, если очень захотеть, и данное решение регламентировать – выстроить систему, позволяющую формальным образом выбирать ступеньку оклада внутри вилки грейда. Тогда мы сужаем круг решений ad hoc, расширяя поле действия системы.

Как много нужно регламентировать? Этот вопрос является для менеджмента фундаментальным. Есть простой ответ: в маленькой компании значительную часть решений можно принимать ad hoc, а в большой стоит по максимуму регламентировать. Когда решения принимают тысячи людей, мы просто вынуждены упорядочить их деятельность с помощью регламента. А там, где решения принимают один-два человека по единичным случаям, нет смысла городить системы.

Притягательный в своей простоте, этот ответ, к сожалению, не особо полезен. Возьмем крупную компанию. Есть области, в которых решения очевидно стоит регламентировать: штатное расписание, объем затратных статей в бюджете… Столь же очевидно, что, например, выбор вида лампочек регламентировать не стоит – пусть закупщик в рамках отведенного бюджета сам выбирает подходящие лампочки. Но таких очевидных случаев – процентов 20. А вот остальные 80 % решений в принципе регламентации поддаются, хотя могут быть отданы на откуп менеджменту. Как же определить, где водить регламенты, а где – нет? Регламентировать все по максимуму, чтобы работа была четкой? Или, наоборот, регламентировать по минимуму и тем самым уменьшить количество бюрократии и обеспечить гибкость? Или сделать так: сначала регламентировать по минимуму, а потом вводить регламент только там, где появляется проблема: нет проблемы – нет правила; возникла проблема – не только решаем ее, но и вводим регламент на будущее? Или же так: вначале регламентировать по минимуму, а потом по мере наработки типовых решений оформлять их в регламент («асфальтировать протоптанные дорожки»)? Или сначала все зарегламентировать, а потом, по мере повышения квалификации менеджеров, все больше решений отдавать им на откуп?

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