Миф о всесильном менеджере

05.07.18

Архитектура

Не будем заниматься изменениями, потому что мы - не менеджеры.

Разница восприятия

 

Существует забавная разница в восприятии возможности изменения бизнес-системы между «низами» и «верхами».

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

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

Но в самом начале возражение было одно: мы – не менеджеры. У нас нет власти, а у менеджера – есть. Только он может все поменять. Только он понимает, что и как надо поменять в процессах, мотивации, целях, управлении и автоматизации. А мы – маленькие (ну и там еще много прилагательных было).

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

Но их основное возражение было парадоксальным – у нас нет власти. Власти в собственном отделе.

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

Менеджер обложен со всех сторон. Пробежимся кратко по составляющим его отдела, как бизнес-системы.

 

Цели

 

Цели деятельности отдела почти всегда поставлены свыше. Обычно это – банальный план каких-нибудь показателей. Иногда есть стратегические цели, или даже принципы, которым должна удовлетворять работа отдела. Но почти всегда эти цели – внешние.

Менеджер, конечно, занимается трансформацией целей – не транслирует их «один к одному» своим подчиненным. Но выбирать цель он не может.
Толковый менеджер, конечно, понимает, что существование двух целей одновременно – вполне нормально, если не болтать лишнего. Я не говорю о коррупции или воровстве, только о благих намерениях. Но вести «двойную бухгалтерию» целей очень трудоемко, нужна сильная воля и наличие собственной, личной цели.

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

Поэтому, в основном, приходится работать на цель, поставленную извне. Минус одна степень свободы.

 

Процессы

 

С процессами ситуация немного лучше, но они тоже, зачастую, вне власти менеджера.

Первая причина – засилье всевозможных стандартов, вроде ISO. Толку от них никакого, но отделам менеджмента качества, да и аудиторам, надо что-то кушать, поэтому «формализованные бизнес-процессы» получили достаточно широкое распространение. Радует, что пока русским людям «работать по процессу» не близко, поэтому бумажка с квадратиками мирно пылится в столе руководителя до следующего аудита.

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

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

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

Если все делать правильно, то внутрь лезть не будут, отдел будет черным ящиком. Понятно, что не все менеджеры используют такое положение во благо компании, но в целом этот способ неплох. Его даже рекомендуют в некоторых практиках, например – в «Русской модели управления» Прохорова (кластеризация системы управления) или том же Scrum (немного с другой идеологией, но смысл тот же).

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

 

Автоматизация

 

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

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

Вторая причина – усложнение решений и их доработки. Если в 1С УПП, например, можно было достаточно недорого реализовать очень широкий спектр функциональности, то в ERP это сделать намного сложнее. Особенно помня о том, что в УПП не было процессов, а в ERP они являются основой идеологии и методологии. Ну и банально дорого стало делать доработки.

Третья причина – самозащита внутренних ИТ-отделов. Там такой же менеджер сидит, со своими целями, процессами, автоматизацией, мотивацией и т.д. Ему, как правило, глубоко плевать на достижение целей другими подразделениями, хотя его доход иногда зависит от выполнения плана продаж или прибыли. Но мостика между своей работой и прибылью компании он не проводит, поэтому старается от работы просто отпинаться.
Четвертая причина – комбинация третьей и неумения менеджера ставить задачи. Допустим, менеджер толковый, и понимает, на обычном русском, чего хочет добиться.

Говорит: мои люди слишком много времени тратят на обработку документов в системе, сделайте что-нибудь, автоматизируйте.
Начальник ИТ говорит – давай тех.задание, что тебе надо поменять.
Я тебе как ТЗ напишу – отвечает менеджер – я ж не специалист, вы-то на что.
Мы на то, чтобы целей руководства достигать – отвечает ИТшник – ну и людям помогать.
Так помогите мне, ё-моё – возмущается менеджер.
Помогаю, чем могу. Подсказываю, что надо ТЗ написать. – не унимается начальник ИТ.

Компетенций у менеджера не достаточно для того, чтобы написать ТЗ. Он чего-то напишет в итоге, программисты сделают (хихикая про себя), а жизнь лучше не станет.

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

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

 

Система мотивации

 

Область, столь же консервативная, как и цели. Почти полностью закрыта от влияния менеджера.

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

И это самый большой парадокс, лично для меня. Система мотивации – самый сильный инструмент управления. Она способна вобрать в себя почти все элементы бизнес-системы – цели, процессы, автоматизацию, систему управления, затраты и т.д., вплоть до увольнения менеджера за ненадобностью. Хотя, может в последнем пункте дело.

Факт остается фактом – за редкими исключениями, вроде опционов или нормальной сдельной оплаты, система мотивации не является инструментом управления, оставаясь придатком.

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

 

Что в итоге?

 

В большинстве случаев – почти ничего. Менеджер становится тем, кем и задуман – элементом системы, пусть и с «руководящими полномочиями». У него, как и у рядового сотрудника, масса ограничений, правил, систем, требований и целей, с которыми он ничего не может поделать. А, нет, может – следовать правилам, учитывать ограничения, достигать целей.

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

Но изменения менеджеру практически недоступны. Он тоже в цепях, хотя и не сидит на галерах с веслами.

Вернемся к тому, с чего начали: рядовые сотрудники считают, что только менеджер может что-то изменить. Увы, не может.

Многие рядовые сотрудники, ощущая внутри жажду перемен, или желание оставить след в истории, или просто чем-то интересным позаниматься, руководствуясь мнением «менеджер может», пытаются стать менеджерами. Тратят несколько месяцев или лет, становятся, и только тогда понимают, что мечте осуществиться не дано. Но, раз путь пройден, не возвращаться же? Становятся обычными менеджерами, без надежд на изменения.

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

 

В чьих руках система?

 

Кто же те злодеи, которые опутывают правилами и ограничениями менеджеров и рядовых сотрудников? Высшее руководство? Собственники и акционеры? Внешние консультанты?

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

Процессы кто пишет? Обычные люди. Кто-то потом утверждает, согласовывает, разумеется. Но пишут обычные, рядовые сотрудники. Только цель у них не «качественный процесс», а «утвержденный процесс» — чтобы от них самих отстали.

Автоматизацию кто делает? Обычные программисты. ИТ-директор будет надувать щеки, говоря, что это он все решения придумывает, но по факту он только визы ставит, и мешает двигаться нормальной автоматизации.

Систему мотивации кто пишет? Рядовые сотрудники HR. Если нет, то директор. Просто назначает оклады, и дает небольшие премии. Кто мешает рядовым сотрудникам HR создавать системы мотивации? А когда никто не мешает, почему такую ерунду пишут? Просто берут шаблон, подставляют свои должности, просят менеджеров придумать показатели, а ИТ-отдел – автоматизировать. Цель – та же, что и у процессников: чтобы от них отстали.

В итоге, если разобраться, обычным людям мешают обычные люди, менеджерам мешают другие менеджеры, и все вместе мешают друг другу. Или по-другому – никто никому не мешает.

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

См. также

Архитектура решений Программист Платформа 1С v8.3 Бесплатно (free)

В статье расскажу про относительно уникальное явление на рынке. EmplDos - полноценный сервис, который в качестве Backend использует платформу 1С. Речь пойдёт не только о технической и архитектурной стороне вопроса, а ещё и о всех трудностях и граблях, которые пришлось и до сих пор приходится преодолевать на пути к успеху.

14.10.2024    4093    0    comol    28    

28

Кейсы автоматизации Платформа 1С v8.3 1С:Документооборот Бесплатно (free)

Компания «Уралхим» использует 1С:Документооборот не только для хранения и согласования документов, но и для централизованного управления НСИ между 47 системами (не только на 1С); для бэкенда к мобильным приложениям охранников; и в качестве сервиса заказа справок для сотрудников. О деталях реализации нестандартных решений, разработанных в компании «Уралхим» на базе 1С:Документооборот, пойдет речь в статье.

02.08.2024    3535    0    Novattor    1    

16

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    2218    0    slavik27    7    

15

Отчеты и дашборды Бизнес-аналитик Бухгалтер Пользователь Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

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

11.12.2023    2946    0    Serg_Tangatarov    2    

16

Архитектура решений Программист Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    5679    0    ivanov660    10    

35

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    2994    0    user1754524    15    

17

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

29.08.2023    3550    0    ke_almaty    0    

15
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. CheBurator 2712 29.07.18 01:03 Сейчас в теме
Принцип простой: если вы нанимаете меня на работу как специалиста - идите нх..уй и не советуйте мне как работать. Примерно так. То есть: когда лично я прихожу на проект в стороннюю компанию - я говорю так: я посмотрю, исследую и прочее - если мне будет непонятно/сомнения - я сам обращусь к вам за пояснениями (а так как я "параноик" - то я стремлюсь утрясать ВСЕ сомнительные для меня вопросы), если вы нанимаете меня как специалиста и начинаете давать мне указания и не следуете моим рекомендациям - идите нх..уй.

Если придерживаться такого принципа на разных уровнях то имхо все становится прозрано и понятно.
Беда в одном - у нас 80% мненеджеров и попадающих пож это определение в силу своих должностных полномочий - никакие не менеджеры, а максиум простые рядовые исполнители. Это ни хорошо, ни плохо - это жизнь. с этим приходится мириться. И все что надо имхо - это отфильтровать 20% ВМЕНЯЕМЫХ. Но эти вменяемые должны иметь РЕАЛЬНУЮ МОТИВАЦИЮ - деньгами, профитами, бонусами, итд. Если "менеджер" и реальный менеджер в результате имеют не сильно отличающееся "вознаграждение" - то смысл реальному менеджеру париться и рвать ж-пу...?

В итоге все в таких отношения и видим то что видит автор и описывает в этой статье.
Как-то так я вот сумбурно описал...
TeMochkiN; +1 Ответить
Оставьте свое сообщение