Бывает, что решение не выполняется. Или выполняется так феерично, что лучше бы за задачу вообще никто не брался. Так случается в любой компании, и, конечно, так регулярно случается у нас. Задача была уменьшить количество таких ситуаций на важных проектах.
Почему всё может пойти через задницу? В первую очередь потому, что решение выработал человек, который не имел компетенции, полномочий или просто не был поддержан теми, кто будет это всё внедрять. То есть даже если решение трижды правильно — нужно, чтобы его правильность как минимум поняли исполнители.
Чаще случается, что не хватает каких-то кусков власти или ответственности. И мы тут на десятом году развития компании внезапно нашли работающую модель для того, чтобы понимать сразу, чего не хватает. То есть так же лажать, но чуть реже.
Фактор кирпича
Значит, мы сгоняли к деду Ицхаку Адизесу. У него есть целый университет управления. Надо сказать, что это был уже не первый университет управления, который мы встречали, но именно там нам дали и теорию, и практические инструменты. Потому что хватит делать всё на коленке, есть научная организация труда, и Адизес — пророк её. Учитывая зашкаливающий уровень пафоса, всё это реально отдавало религией, но, как оказалось — работает. По крайней мере, в сравнении с тем, что у нас было.
Итак, в теории нам нужна штука, которая называется CAPI — это собранные в одну кучку власть, полномочия и авторитет. В малом и (как у нас уже) среднем бизнесе этот капи обычно есть у учредителя. В смысле, он может творить, что хочет, на потребу своей чёрной душе. И обижаться смысла нет: это же его бабки, и даже если он не учёл чьё-то мнение, пускай транжирит и развлекается. Всё, что он решает, всегда железно обосновано хотя бы этим фактом. Учредитель не может быть неправ в силу особенностей организма.
А дальше появляется две проблемы:
- Во-первых, когда решение спускается на уровень ниже, начинаются споры. Да, в рамках подразделения руководитель подразделения может делать, что хочет. Но при проекте, который затрагивает две команды — начинаются тёрки. И тут нет того, кто может вынести окончательное решение…
- … поэтому все бегают через верх со всеми более-менее значимыми вопросами. То есть инфраструктура принятия решений получает архитектуру «колесо и спицы» с незаменимым центральным хабом.
Он же точка отказа. Он же «автобусный» (в нашем случае, «мотоциклетный») фактор. В российской практике это называется «фактор кирпича» — определяется он тем, какому количеству людей в компании надо сбросить кирпич на голову, чтобы оная компания не смогла продолжить существование.
В модели «все бегают через верх» достаточно одного такого кирпича.
Второй вопрос связан с повторяющимися процессами. Есть два способа не делать тупую повторяющуюся работу:
- Написать скрипт и потом его тупым и повторяющимся образом поддерживать.
- Или перепоручить эту работу кому-то, кто способен её сделать, и при этом его время стоит меньше всего.
Скрипт часто стоит дорого, поскольку дорого стоит время людей, которые его пишут. Кроме того, есть много неповторяющихся или неалгоритмизируемых задач, для которых нужен человек. Его надо выбрать.
Именно так выглядит матмодель принятия решения. Поэтично она звучит «решение принимается как можно ближе к клиенту». В терминах экономики — при минимальной стоимости времени участников. Таких участников, у которых есть минимально достаточные власть, полномочия и компетенции решить задачу.
С теорией определились. Осталось нарисовать сову!
Процедура выбора выглядит так.
Предположим, появилась задача по тому, что надо сделать листовку для выставки. Идём к самому главному — учредителю. Говорим: ты будешь делать листовку или делегируешь? Он — вы чего, упоролись? Конечно, делегирую, у меня вот гендир дистрибуции в управлении. Спрашиваем его: будешь сам или делегируешь? Он — конечно, делегирую, вот у меня руководитель корпоративного подразделения Аня в подчинении. Аня делегирует на руководителя команды дизайна Любу. Люба делегирует эту задачу верстальщику. Верстальщик: мне делегировать некому, поэтому я буду делать. Я всё, что хотите могу сделать, только дайте техзадание, фотографии и поесть.
То есть человек нашёлся. Человеку надо три компонента, которые он не может произвести сам. По каждому из них снова запускаем ту же механику выбора. Идём к учредителю: ты будешь делать ТЗ? И так далее.
В итоге выясняется, что сделать листовку может тёплая компания из верстальщика, менеджера корпоративного отдела, пиарщика и фотографа. Обратите внимание, в этом примере нигде нет руководителя, который утверждает эту листовку. Потому что раз он решил делегировать свой кусок работы подчинённому, то доверяет результату.
Это довольно необычный момент. Оказалось, что мы ещё и неправильно делегировали. Точнее, не было методологии, и всё делалось интуитивно, а потом расшаталось. Когда ты поручаешь кому-то кусок работы, то даёшь две вещи:
- Полномочия
- Ответственность
Полномочия — это когда человек имеет право принять решение. Ответственность — это когда он полностью отвечает за результат этого решения.
То есть какой бы результат вам ни принёс подчинённый, вы с ним заранее согласны. Иначе это не делегирование, а совместная работа. Я не говорю, что это плохо — просто это немного другое. И в нашей цепочке «кто будет делать листовку» появился бы не ваш подчинённый, а вы лично. И отвечали бы вы лично (хотя всё рано за действия подчинённого отвечаете вы как руководитель).
Когда вы даёте кому-то полномочия, то должны давать не только возможность говорить «нет», но и «да». Точнее, сначала можно делегировать только «нет», но потом, когда человек справляется с работой — давать и право на «да».
Если перестраховаться, получится человек, который знает, почему и когда надо отказать в проекте, но не знает, за какой нужно цепляться и делать. Потому что страшно. У нас в культуре всегда было право «да» и право на ошибку, но мы передавали это устно, и вот в какой-то момент что-то пошло не так. У меня даже есть в книге глава есть про испорченный телефон — "«Не “Идите в ж…”, а “Добро пожаловать”» – как информация искажается при передаче". Её очень любят цитировать журналисты, их это слово приятно греет. Вот у нас тоже задумывалось «добро пожаловать», но в ряде случаев получилось другое.
Вахтёр на входе в здание боится впускать лишних людей: его не хвалят за правильно пропущенных, но ругают за прошедших. Пример — инцидент с охраной во Внуково, которые не пустили скорую к умирающему мужчине за линию.
Право «нет» всегда понятное. Право на «да» сложнее. Это как юрист, который говорит не почему это сделать нельзя, а как это сделать правильно, и сколько стоит эта услуга из меню развлечений административного кодекса.
Так вот, если вы делегируете человеку принимать решение, то это должно быть любое решение. Включая очень страшные положительные. Это полномочия.
Ещё нужны власть и компетентность
Первый из оставшихся компонентов — власть. Власть от полномочий отличается тем, что полномочия — это право что-то делать или не делать, а власть — это возможность убеждаться, что результат будет сделан.
То есть когда ты обращаешься к человеку с задачей, а он почему-то тебе не отказывает и делает её хорошо. Мы называем это системой двух морковок — спереди и сзади. Например, если контрагент сдал проект за неделю до дедлайна — премия. Если позже дедлайна — неполная оплата. Кстати, отлично работает для ремонта-инженерки и сайтов.
Часть власти — это право наказывать и поощрять за результаты. Вторая часть власти — возможность убедить человека помогать без задействования других рычагов, то есть авторитет.
Когда люди объединяются в проектную команду, у них есть формальный руководитель. Он несёт ответственность за результат. Чтобы он стал фактическим руководителем, ему нужна фактическая власть. Для этого он должен быть достаточно убедительным, или же иметь для всех премию и дебафф за выполнение или срыв проекта. Или же оказать поддержку им. Или же придумать что-то ещё.
Авторитет гораздо эффективнее материальных стимулов (ведь в компании все хотят примерно одного), поэтому нужна процедура договаривания с проектной группой. Про неё отдельно позже. Результат — проектная группа вырабатывает общее решение и назначает диктатором по внедрению руководителя проекта.
Следующая важная вещь — компетентность. То есть знания для принятия решения. Например, вот задача: все ли игры мы открываем в магазине в принципе? А открываем после того, как клиент прямо попросит — или просто во время процесса объяснения?
С моей точки зрения — открываем все, то есть каждый артикул в магазине должен быть открытым (читай — если в магазине 800 SKU, то будет примерно 700 единиц брака-уценки). Я могу принять такое решение сам, но тогда продавцы упрутся и не будут открывать игры сами, когда это нужно. И закупщик будет на меня злиться. Поэтому вот что я должен сделать: найти опытного старшего точки, чтобы получить взгляд из магазина. Найти закупщика. Найти ещё кого-то, кто может дополнить решение информацией. А потом использовать механику демократуры.
Демократура — это тоталитарная демократия. Бизнес-термин несколько отличается от политического. Решения принимаются демократически одним человеком в дисперсионной структуре, а потом исполняются тоталитарно в иерархической. До принятия решения есть процедура, где мнение каждого учитывается и вносится в решение. Или же этому человеку внятно объясняется, почему так делать не надо.
Как можно принять решение демократически одним человеком? О, это тоже прекрасное изобретение научной организации труда. Мне очень нравится пример одного строителя, который решил уволить своего сотрудника за то, что тот появился на проходной пьяный. За провинившегося вступилась вся бригада — все хотели, чтобы начальник его «отмазал» и не применял ТК. Тогда он задал простой вопрос:
— Нужны двое, кто за него поручится. Придёт пьяный ещё раз — лишу премии.
Как это ни странно, тут же бригада из стадии «начальник олень» перешла к стадии конструктива. И поняла, что он напьётся, и очень быстро. И надо решать сейчас.
Руководитель — диктатор. Но голоса всех могли бы переломить сюжет ситуации.
Промежуточный итог
С теорией пока всё. Мы научились выделять группы людей, которые могут по отдельному проекту не бегать через верх, а договариваться между собой. Осталось посадить их за стол и убедиться, что они друг друга не поубивают. Для этого нужен уже практический инструмент реализации этих CAPI-команд.
Сама эта история позволяет запускать маленькие проектные группы между отделами и подразделениями. И даёт возможность каждому повлиять на решение. А это чертовски важно, когда компания становится большой и продолжает расти.
Автор: Сергей Абдульманов
