Наказывать сотрудника можно, конечно, только с согласования его руководителя. Наказание должно распространяться и на руководителя. Или вообще только на руководителя.
Впрочем, если компания динамично развивается, то фокус в коммуникациях постепенно переходит от административно-вертикальных к процессно-горизонтальным.
На этом уровне взаимодействия появляются следующие системные понятия:
• Заявка (см. рис. 66) – это работа, которую сотрудник должен выполнить в соответствии со своим функционалом. Как правило, заявка является входом большинства стандартных бизнес-процессов. Есть следующие типы заявок:
• От поставщика, когда заявку сотрудник может получить от внутреннего или внешнего поставщика.
• От руководителя, когда заявку сотрудник может получить от своего руководителя. Это называется процессом, который запускается в «ручном» режиме.
• Полномочия, когда сотрудник может самостоятельно инициировать бизнес-процесс (это означает действовать в соответствии с полномочиями).
• Бизнес-процесс – устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности (последовательность работ), которая по определенной технологии преобразует входы (ресурсы) в выходы (продукты, услуги), представляющие ценность для внешнего (внутреннего) клиента.
• Внутренний поставщик – сотрудник, который уполномочен в соответствии со своей должностью инициировать заявку и запустить бизнес-процесс.
• Внутренний клиент – сотрудник, который принимает результаты выполненной работы.
• Вход бизнес-процесса – условие, инициирующее старт бизнес-процесса.
• Выход бизнес-процесса – зафиксированное достижение результата бизнес-процесса, сигнализирующее о передаче ответственности за дальнейшие действия следующей должности (внутреннему клиенту).
«Продавцы вовремя не выставили счет по нашей заявке», «Производственники "динамят" наш запрос на повторный монтаж», «Маркетологи забыли позвонить и спросить у клиента», «Сотрудники службы работы с претензиями позвонили клиенту только через 3 месяца после жалобы» – эти и другие примеры жалоб подразделений друг на друга можно услышать в большинстве организаций.
Связанные едиными бизнес-процессами подразделения назначают друг другу заявки, но, не понимая механизмов эскалации, одно подразделение думает, что оно передало заявку, в то время как второе подразделение считает, что никакой заявки не было. Часто это приводит к функциональным ямам, когда вместо слаженной горизонтальной работы подразделений заявки превращаются в задачи и решаются только через вышестоящих руководителей, из-за чего теряется время и проигрывается конкурентная борьба. Например, часто встречается подобная ситуация.
Сотрудник отдела маркетинга обратился к сотруднику PR-отдела для организации интервью. PR-специалист, обремененный поставленной от своего непосредственного руководителя задачей, отказал сотруднику отдела маркетинга. Маркетолог в итоге обратился к своему руководителю, рассказал об отказе PR-отдела (возможно, немного приукрасив ситуацию). Руководитель отдела маркетинга сразу обратился к коммерческому директору, который, не разобравшись, отчитал начальника отдела PR. После этого отношения между отделом маркетинга и PR были испорчены еще сильнее и все коммуникации между ними проходили только через их непосредственного руководителя – коммерческого директора.
Во избежание функциональных ям надо регулярно прописывать горизонтальные кросс-функциональные бизнес-процессы и, так как всего прописать нельзя, имеет смысл обучить сотрудников правилам эскалации в случае, если происходит понятийный сбой.
Мы рекомендуем следующие правила эскалации:
• Если следующий в цепочке бизнес-процесса исполнитель С2 не может выполнить заявку и сообщает об этом внутреннему клиенту С1 (предыдущий исполнитель процесса), то сначала внутренний клиент С1 должен приложить все усилия, чтобы заявка была выполнена в установленные сроки.
• После этого внутренний клиент С1 должен письменно зафиксировать случай непринятия заявки в срок, чтобы потом была возможность проанализировать систему и внести улучшения. Об этой записи обязательно должен быть уведомлен исполнитель заявки С2.
• После этого внутренний клиент С1 должен письменно обратиться к руководителю исполнителя М2, который определяет приоритеты его работы.
• Если и после обращения к руководителю М2 заявка не выполняется, то внутренний клиент С1 должен обратиться уже к своему непосредственному руководителю М1, чтобы он обратился к менеджеру М2.
• Если и после этого заявка не выполняется, то цикл повторяется, но уже на следующем уровне управления.
Эффективное горизонтальное взаимодействие возможно при понятных всем сотрудникам структуре бизнес-процессов и зонах ответственности. Это работает только при налаженной системной структуре бизнес-процессов организации.
Если же зоны ответственности размыты или отсутствуют, непонятно, кто несет ответственность за выполнение той или иной функции, и основная нагрузка ляжет тогда на более простое административное вертикальное взаимодействие. Менеджеры будут загружены оперативкой и «ручным» управлением системой.
Для того чтобы регулярно делегировать полномочия и наводить порядок в организации, мы рекомендуем планировать в графике менеджеров с помощью настройки цикла регулярного менеджмента мероприятия для наведения порядка и наладки кросс-функциональных мостиков – бизнес-процессов[30].
Впрочем, часто можно встретить случай, когда менеджер саботирует делегирование полномочий и лично обрабатывает все входящие заявки, делегируя их своим подчиненным через поручения. Тогда путь бизнес-процесса может выглядеть, как показано на рис. 70.
В такой схеме руководитель занят обработкой заявок и принятием решений – кому из своих сотрудников какую задачу поставить. Такие решения он мог бы и не принимать, делегируя полномочия сотрудникам, но почему-то он этого не делает. К тому же процесс вместо 2 итераций передачи информации проходит в 4 итерации, что увеличивает затраты и снижает эффективность. А причиной этому может быть всего лишь желание менеджера остаться незаменимым. Хотя часто бывает, что просто «нет времени» на наведение порядка и делегирование полномочий. Однако теперь благодаря главам 3 и 6 мы с вами знаем, что делать с такими словами, как «нет времени»!
В крупной корпорации на одну из первых сессий по управлению ожиданиями между функциональными менеджерами больше всех не хотел идти руководитель юридического департамента. Он работал по 14 часов 6 дней в неделю и был очень занят, а здесь целый день нужно было потратить на формирование договоренностей. В начале сессии каждый из менеджеров на листе флипчарта написал цели, процессы и проекты своей должности. А потом каждый дал обратную связь остальным с помощью специальных обозначений.
Директор юридического департамента собрал максимальное число стрелочек вниз, означающих необходимость делегировать процесс согласования договоров, который он держал под «ручным» управлением, а многие договоры правил лично. Для него это оказалось настоящим откровением, и прямо на сессии он дал обязательство описать и делегировать бизнес-процесс согласования договоров, что и произошло сразу после сессии. Через месяц скорость согласования договоров увеличилась в 2 раза[31].
Итак, как лучше взаимодействовать в соответствии с иерархией и процессами, мы разобрались. Настала очередь следующего, очень непростого вида взаимодействия – в соответствии с тем, чего еще нет: проектами.
На этом уровне взаимодействия важны следующие понятия:
• Проект – временное предприятие, направленное на создание уникального продукта, услуги или результата. То есть проект – это создание того, чего еще нет, для достижения того, что еще не достигнуто, но чего очень хочется достичь, – цели. Одним из результатов проектов всегда является создание новых или улучшение существующих процессов организации. То есть после проектного взаимодействия команда переходит к процессному взаимодействию.
• Проектная задача – мероприятие, назначаемое членам проектной команды в соответствии с принятым и согласованным с административными руководителями исполнителей планом проекта.
• План проекта – принятый план мероприятий проекта, согласованный с руководителем проекта, членами команды проекта и административными руководителями исполнителей.
• Руководитель проекта – уполномоченный сотрудник, имеющий право назначать и контролировать выполнение проектных задач членами проектной команды в соответствии с планом проекта или выделенными временны`ми ресурсами. Руководитель проекта – это не первое лицо и не топ-менеджер, так как иначе его стиль управления будет считаться обычным административным управлением.
• Матрица проектов – список инициированных проектов развития компании, находящихся на контроле генерального директора.
Список проектов развития в виде матрицы проектов – это один из обязательных результатов стратегической сессии. Но одно дело – договориться о том, что нужно делать, и совсем другое – сделать это.
Существует множество подходов к проектному управлению – PMBOK, Agile, P2M, Scrum, PRINCE2 и др. Но при использовании любого или даже нескольких из них часто возникает конфликт с другими уровнями взаимодействия. И первая ошибка – это конфликт между проектными задачами и оперативной работой сотрудников в виде просьб, задач и заявок. Ведь ресурсы всегда ограничены, и один из главных – рабочее время сотрудников.
Увы, часто мы встречаем ситуацию, когда непосредственный руководитель сотрудника, участвующего в проекте, изменяет приоритеты выполнения проектных задач, откладывая их, сдвигая сроки и не оповещая об этом руководителя проекта. Именно это часто является причиной распространенной традиции делать проекты в последний момент. Эффективное же управление проектами подразумевает регулярный ритм достижения запланированных результатов проекта.