Хабрахабр

Поиск узлов дисперсии управления (как перестать делать тупую работу и передать её другому)

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

То есть даже если решение трижды правильно — нужно, чтобы его правильность как минимум поняли исполнители. Почему всё может пойти через задницу? В первую очередь потому, что решение выработал человек, который не имел компетенции, полномочий или просто не был поддержан теми, кто будет это всё внедрять.

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

Фактор кирпича

Значит, мы сгоняли к деду Ицхаку Адизесу. У него есть целый университет управления. Надо сказать, что это был уже не первый университет управления, который мы встречали, но именно там нам дали и теорию, и практические инструменты. Потому что хватит делать всё на коленке, есть научная организация труда, и Адизес — пророк её. Учитывая зашкаливающий уровень пафоса, всё это реально отдавало религией, но, как оказалось — работает. По крайней мере, в сравнении с тем, что у нас было.

В малом и (как у нас уже) среднем бизнесе этот капи обычно есть у учредителя. Итак, в теории нам нужна штука, которая называется CAPI — это собранные в одну кучку власть, полномочия и авторитет. И обижаться смысла нет: это же его бабки, и даже если он не учёл чьё-то мнение, пускай транжирит и развлекается. В смысле, он может творить, что хочет, на потребу своей чёрной душе. Учредитель не может быть неправ в силу особенностей организма. Всё, что он решает, всегда железно обосновано хотя бы этим фактом.

А дальше появляется две проблемы:

  1. Во-первых, когда решение спускается на уровень ниже, начинаются споры. Да, в рамках подразделения руководитель подразделения может делать, что хочет. Но при проекте, который затрагивает две команды — начинаются тёрки. И тут нет того, кто может вынести окончательное решение…
  2. … поэтому все бегают через верх со всеми более-менее значимыми вопросами. То есть инфраструктура принятия решений получает архитектуру «колесо и спицы» с незаменимым центральным хабом.

Он же точка отказа. Он же «автобусный» (в нашем случае, «мотоциклетный») фактор. В российской практике это называется «фактор кирпича» — определяется он тем, какому количеству людей в компании надо сбросить кирпич на голову, чтобы оная компания не смогла продолжить существование.

В модели «все бегают через верх» достаточно одного такого кирпича.

Есть два способа не делать тупую повторяющуюся работу: Второй вопрос связан с повторяющимися процессами.

  1. Написать скрипт и потом его тупым и повторяющимся образом поддерживать.
  2. Или перепоручить эту работу кому-то, кто способен её сделать, и при этом его время стоит меньше всего.

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

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

С теорией определились. Осталось нарисовать сову!

Процедура выбора выглядит так.

Идём к самому главному — учредителю. Предположим, появилась задача по тому, что надо сделать листовку для выставки. Он — вы чего, упоролись? Говорим: ты будешь делать листовку или делегируешь? Спрашиваем его: будешь сам или делегируешь? Конечно, делегирую, у меня вот гендир дистрибуции в управлении. Аня делегирует на руководителя команды дизайна Любу. Он — конечно, делегирую, вот у меня руководитель корпоративного подразделения Аня в подчинении. Верстальщик: мне делегировать некому, поэтому я буду делать. Люба делегирует эту задачу верстальщику. Я всё, что хотите могу сделать, только дайте техзадание, фотографии и поесть.

Человеку надо три компонента, которые он не может произвести сам. То есть человек нашёлся. Идём к учредителю: ты будешь делать ТЗ? По каждому из них снова запускаем ту же механику выбора. И так далее.

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

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

  1. Полномочия
  2. Ответственность

Полномочия — это когда человек имеет право принять решение. Ответственность — это когда он полностью отвечает за результат этого решения.

Иначе это не делегирование, а совместная работа. То есть какой бы результат вам ни принёс подчинённый, вы с ним заранее согласны. И в нашей цепочке «кто будет делать листовку» появился бы не ваш подчинённый, а вы лично. Я не говорю, что это плохо — просто это немного другое. И отвечали бы вы лично (хотя всё рано за действия подчинённого отвечаете вы как руководитель).

Точнее, сначала можно делегировать только «нет», но потом, когда человек справляется с работой — давать и право на «да». Когда вы даёте кому-то полномочия, то должны давать не только возможность говорить «нет», но и «да».

Потому что страшно. Если перестраховаться, получится человек, который знает, почему и когда надо отказать в проекте, но не знает, за какой нужно цепляться и делать. У меня даже есть в книге глава есть про испорченный телефон — "«Не “Идите в ж…”, а “Добро пожаловать”» – как информация искажается при передаче". У нас в культуре всегда было право «да» и право на ошибку, но мы передавали это устно, и вот в какой-то момент что-то пошло не так. Вот у нас тоже задумывалось «добро пожаловать», но в ряде случаев получилось другое. Её очень любят цитировать журналисты, их это слово приятно греет.

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

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

Включая очень страшные положительные. Так вот, если вы делегируете человеку принимать решение, то это должно быть любое решение. Это полномочия.

Ещё нужны власть и компетентность

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

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

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

Он несёт ответственность за результат. Когда люди объединяются в проектную команду, у них есть формальный руководитель. Для этого он должен быть достаточно убедительным, или же иметь для всех премию и дебафф за выполнение или срыв проекта. Чтобы он стал фактическим руководителем, ему нужна фактическая власть. Или же придумать что-то ещё. Или же оказать поддержку им.

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

То есть знания для принятия решения. Следующая важная вещь — компетентность. А открываем после того, как клиент прямо попросит — или просто во время процесса объяснения? Например, вот задача: все ли игры мы открываем в магазине в принципе?

Я могу принять такое решение сам, но тогда продавцы упрутся и не будут открывать игры сами, когда это нужно. С моей точки зрения — открываем все, то есть каждый артикул в магазине должен быть открытым (читай — если в магазине 800 SKU, то будет примерно 700 единиц брака-уценки). Поэтому вот что я должен сделать: найти опытного старшего точки, чтобы получить взгляд из магазина. И закупщик будет на меня злиться. Найти ещё кого-то, кто может дополнить решение информацией. Найти закупщика. А потом использовать механику демократуры.

Бизнес-термин несколько отличается от политического. Демократура — это тоталитарная демократия. До принятия решения есть процедура, где мнение каждого учитывается и вносится в решение. Решения принимаются демократически одним человеком в дисперсионной структуре, а потом исполняются тоталитарно в иерархической. Или же этому человеку внятно объясняется, почему так делать не надо.

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

Но голоса всех могли бы переломить сюжет ситуации. Руководитель — диктатор.

Промежуточный итог

С теорией пока всё. Мы научились выделять группы людей, которые могут по отдельному проекту не бегать через верх, а договариваться между собой. Осталось посадить их за стол и убедиться, что они друг друга не поубивают. Для этого нужен уже практический инструмент реализации этих CAPI-команд.

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

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»