Человек взял задачу: обновить кассы в десяти магазинах. Утром половина не работает.

Когда проснулся - объяснил честно. Начал обновлять, пришел коллега с вопросом - помог. Потом второй. Потом еще несколько. Время ушло, не успел дойти до конца списка - уснул.

Он не саботировал задачу. Он помогал людям. Каждому конкретному человеку он сделал хорошо. Компании - сделал очень плохо.

И это был не технический сбой. Это было решение линейного ИТ-сотрудника, у которого не существовало другой системы координат.

Почему прямая поддержка работала

Сеть около 80 магазинов. Около десятка ИТ-специалистов на всю компанию. Все друг друга знают, у каждого есть свой айтишник, которому можно позвонить или написать. Никакой бюрократии - просто люди помогают людям. И это работало. По-настоящему работало.

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

Новые сотрудники пришли - но к ним не обращались. У них не было личных связей, их никто не знал. Старые специалисты работали в режиме 24/7: помогали вечером, помогали в выходные, были доступны всегда. Обучить новых времени не было - всё время уходило на прямые обращения.

Кто-то из старых не выдержал такого ритма. Встал и ушел. Знания не передал - просто не успел, да и никто специально не просил.

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

Что на самом деле стоит теневая поддержка

Теневая поддержка не была медленной. В этом и был её главный обман.

Обращений было много: 20 с лишним групповых чатов, десятки прямых сообщений и звонков в любое время суток. Пользователь писал знакомому айтишнику - и получал ответ быстро. Это ощущалось как скорость. На деле это была скорость за чужой счет: за счет личного времени специалиста, за счет накопленного выгорания, за счет задач, которые в этот момент не решались.

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

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

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

Почему единое окно не работает само

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

Ввели. И сразу получили волну сопротивления.

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

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

Это классическая ловушка внедрения. Инструмент правильный. Логика верная. Но поведение людей его не принимает - и система разваливается не потому что плохо устроена, а потому что никто не управлял переходом.

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

Что сделали

Право и ответственность - одновременно

Первое, что зафиксировали: ИТ-сотрудники имеют право не отвечать на прямые обращения вне рабочего времени и вне единого окна. Это не пожелание - это правило.

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

Это важное разграничение. Нельзя просто запретить людям быть отзывчивыми. Но можно сделать так, чтобы отзывчивость в обход системы имела измеримые последствия.

Механика заявки

На каждую зарегистрированную заявку в течение 60 минут назначался ответственный и фиксировалась крайняя дата решения. Не "скоро разберемся" - конкретное имя и конкретная дата. 99% заявок закрывались в оговоренный срок - это и стал измеримый результат.

Всем сотрудникам выдали памятку на А4: как подать обращение, как получить номер, как эскалировать, если не устраивает срок или приоритет. Один лист, без лишних слов.

Эскалация без обходных путей

Порядок эскалации проговорили на всех уровнях и закрепили.

Если рядовой сотрудник шел к CEO напрямую - CEO отправлял к своему руководителю. Без обсуждения, без разбора по существу.

Если прямой подчиненный CEO всё же приходил с номером заявки - CEO пересылал её в ИТ. После этого разбирали: а нужно ли было вообще доходить до CEO? Почти всегда выяснялось одно из трех: заявке не назвали срок, срок не устроил и человек не пошел по стандартному пути эскалации, или в изменении срока отказали - но не объяснили почему.

Каждый такой разбор был сигналом для ИТ: где процесс не доработан. Не виноватый, а дыра в системе.

Через несколько недель прямые подчиненные CEO поняли: всё решается без его участия. ИТ устраняло процессные дыры по результатам разборов - сроки стали называть сразу, отказы объяснять. Обращения к CEO прекратились сами - не потому что запрещено, а потому что незачем.

Загрузка стала видна

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

Реакция более 90% сотрудников была одинаковой: мы не думали, что столько обращений. Нам казалось, вы сидите и ничего не делаете - а наша одна заявка висит.

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

Новые решают, старые учат

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

Старые специалисты вышли из режима 24/7. Освободившееся время пошло именно туда, куда не доходило раньше: на передачу знаний и разбор нестандартных случаев.

Лидеры мнений - не препятствие, а инструмент

Несколько сотрудников до последнего отказывались работать через систему. При этом именно они были лидерами мнений в своих командах - их слова формировали поведение окружающих.

Административный приказ здесь не работает. Можно заставить человека формально соблюдать правило - и при этом получить молчаливый бойкот и волну скептицизма в курилке.

Работали индивидуально. Садились, показывали конкретно: вот твоя заявка через систему, вот скорость решения, вот прозрачность. Люди видели реальную выгоду для себя - не абстрактную пользу для компании, а конкретное удобство в своей работе.

После этого те же лидеры мнений начали говорить коллегам: иди в единое окно, там реально быстрее решают. Не потому что их попросили. Потому что сами убедились.

Результат

Два месяца до полной стабилизации. SLA 99% - 99% заявок закрывались в оговоренный срок. Управляемая очередь. Прозрачная загрузка по каждому специалисту. Маршрутизация без участия CEO.

Но главный результат - другой.

Компания перестала зависеть от того, чей номер телефона ты знаешь. Новый сотрудник получает такой же сервис, как тот, кто работает пять лет. Заявка с критичной проблемой идет по приоритету - а не по тому, успел ли ты дозвониться до нужного человека в нужный момент.

Когда ИТ-сотрудник уходит в отпуск или покидает компанию - сервис не падает. Потому что он держится на системе, а не на конкретном человеке.

Вывод

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

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

Для CEO вывод жестче: если любая эскалация приходит сразу к первому лицу, компания не ускоряет решение. Она просто переносит невыстроенный процесс на уровень CEO.

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

#cio #итибизнес