Представьте две команды поддержки.

У первой — сотни закрытых заявок в месяц, героические графики загрузки, полные очереди. У второй — метрики в разы лучше, а отчёты почти пустые.

Кто работает лучше? Очевидный ответ — первая. Правильный — вторая: у второй проблемы просто не доехали до заявки.

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

Отсюда системная несправедливость: функциональная модель ITIL оплачивает реакцию, а не предотвращение. Тот, кто гасит пожары до возгорания, в отчёте выглядит бездельником. А иногда — и «не загруженным работой».

Как это устроено: из моей практики.

Когда я руководила техподдержкой критических госинформсистем (20 000+ пользователей, 3 000+ юрлиц, 40 000+ заявок в год), мы не «обрабатывали поток заявок».

Мы работали до заявки: · вводный ВКС для руководителей каждого нового участника, вводимого в систему — не презентация системы, а разбор того, как встроить её в их внутренний процесс. Это стык, который формально не принадлежит никому: «наша система — ваш процесс». Обе стороны правы, а пользователь между ними; · живой телефон как канал первого контакта, а не последнее средство; · методические материалы живым языком под аудиторию — не в базу знаний, а в руки. Результат: FCR 90%, повторные обращения 1%. Это не «очень хорошая первая линия». Это результат того, что значительная часть проблем никогда не стала заявкой — она была закрыта до входа.

И вот что важно. Помощь новым участникам с випнетами и выстраиванием их внутренних процессов не входила ни в чей функционал. Никто не обязан был это делать. Мы делали — потому что видели: иначе на выходе получим поток однотипных заявок и потерянное доверие к системе на старте.

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

Что делать руководителю поддержки: 1. Считать не только закрытые, но и предотвращённые заявки. Хотя бы экспертно: сравнить входящий поток однотипных заявок до и после профилактики. 2. Заложить профилактику в регламент как функцию — с именем владельца, а не как добрую волю конкретного человека. 3. Помнить: профилактика невидима, пока её носитель на месте. Ушёл человек — потоки заявок возвращаются, и никто не поймёт, почему «раньше было спокойнее».

Организация, которая поняла это, оформляет стык как функцию. Организация, которая не поняла, — платит дважды: сначала невидимым трудом человека, потом возвращением хаоса.

А теперь вопрос к руководителям: у вас в команде есть человек, который закрывает проблемы до заявки? Вы знаете, кто это, и что произойдёт, когда он уйдёт?

#управление #процессы #техподдержка #SLA #профилактика #экспертизаборисовской