Negative outcome

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

Представим себе большую корпоративную структуру. 3 и более слоя управления. Внизу происходит какая-то дичь, причем по ней очевидно (участникам), что она = дичь, так быть не должно. Херня какая-то. Или просто логически, или неудобно, или неэффективно, или даже нарушение прописанных правил.

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

Но ничего не делается, и сделано не будет.
Почему так происходит?

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

Итак, линейному менеджменту надо пойти и адресовать дичь

Вариант раз:

• дичь адресуется, сжигается какое-то время и ФОТ, чтобы разобраться в ситуации
• ситуацию требуется исправлять. На это надо нарезать бюджеты и время
• возникает вопрос, а какого хера оно таким стало. Крайними за это будет линейный менеджмент
• фиксируются показатели проебов. То есть, какое-то время эти показатели уже были не оптимальными, «почему не почесались раньше»
• кто-то текущее положение дел уже реализовывал, значит вопрос качества того анализа и компетенций (и кто-то расстроится, возможно даже пострадает)
• надо править дичь, изменять работу, править цепочки. Это время+ФОТ на анализ, предложение, внедрение
• стопудово что-то пойдет не так, риски (меняем неоптимальность на неопределенность)
• — 1) дичь не исправляется, стало или однохренственно, или хуже: негативный сценарий, с кого-то спросят за всю возню + пиздюли
  — 2) дичь исправляется, значит надо идти формализовывать кейс, брать на себя ответственность за описание best practice; неплохо, но тоже пачка работы
  — 3) дичь нельзя исправить, требуется эскалация или пере-проектирование: разбор полётов, пиздюли от руководства, поиск виноватых, следом прилетает пачка жирных инициатив сверху (доп.работа)

Вариант два:

• первые три пункта из предыдущего варианта
• дичь обмазывается какими-то ситуативными костылями и припарками, которые надо на ходу придумать
• процессы и кросс-чеки усложняются
• на конечный персонал падает тарелка лишней работы
• линейному менеджеру надо куда-то прислонить эту лишнюю работу людей, потому что свободного времени и ФОТа в процессах заложено не так много, а остальные показатели никто не отменял
• поскольку дичь уже подсвечена и даже адресована, это системный риск что за костыли и припарки потом с кого-то спросят (какого хрена там происходит)
• внутри-корпоративный риск: Вася знает что у Пети не всё хорошо в процессах и есть проблема, это Петина управленческая уязвимость (корпоративные тёрки иногда бывают очень жесткими, в ход идут любые средства)

Вариант три:

• нихера не делать, живите как хотите

Достаточно очевидно, что в третьем варианте негативный выход только один, по сути: «мы вон там работаем с косяками, щито поделать».

Инициатива нагибает инициатора в любом из случаев.
Значит, инициативы не будет. Это тупо невыгодно линейщикам.

В выборе между кучкой геморроя побольше, и кучкой геморроя поменьше, скорее всего будет выбран вариант status quo, «нихера не делать». Сиюминутная выигрышная стратегия, и так до тех пор, пока это best alternative.

Знаете Тайлера Дёрдена? Художественный фильм про двух парней, один из которых по работе занимался оценкой денег для корпорации.

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

А второй парень так, мыло варил, морды бил, хулиганил по-мелочи.

Знаете, когда всё изменится?
Когда проблема из проёба станет блокером. Что-то встанет раком.

За каждым подвигом стоит чей-то проёб.
Исключения редки.

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

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

С точки зрения «проектирования как надо» это опять приводит нас к механизмам контроля и обратной связи; но не только к самим механизмам, а к вдумчивому анализу outcomes и побочных явлений.

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

Что тут важно: если занимаются отдельные люди, то это их работа (бессмысленно спрашивать «почему»), на них же лежит управление цепочкой и весь change management; он может быть дорогим и непростым. Линейщики им заниматься не будут, потому что — показано выше, коллизия с собственными же интересами, и куча острых углов.

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

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

Hope that helps.

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

Есть два канала обратной связи с полей. Куда поле и линейщики обязаны сложить все свои потенциальные (будущие) блокеры

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

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

За перфоманс канала и ситуации «заявка валялась там 2 месяца» идут дрючить поддержку, у них свои KPI на этот счет.

— нештатные ситуации и затыки, что-то из ряда вон выходящее. Туда попадают в основном две категории: «хитровыдуманная хрень» и «качественный просос» (не количественный). Также «всё остальное», то есть unknown unknowns. Ни фига не штатное.

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

Каких-то системных выводов я из этого делать не буду, подход и подход, просто как референс.