«Да он у нас всё знает»
Обычно такие истории начинаются даже с уважения.
«Слава у нас красавчик.
Всё держит.
Во всём разбирается.
Без него бы давно всё развалилось».
Это не сарказм.
Во многих компаниях действительно есть такие люди.
Те, кто:
— настраивал инфраструктуру еще при переезде в новый офис;
— внедрял CRM;
— подключал телефонию;
— “временно” поднимал сервер;
— чинил 1С по ночам;
— знает, почему склад печатает документы только через один конкретный компьютер.
На таких людях бизнес держится годами.
И проблема в том, что со временем компания начинает путать:
«у нас всё работает»
и
«у нас один человек постоянно удерживает всё от развала».
Сначала это вообще не выглядело проблемой
Компания — дистрибуция оборудования.
Около 90 сотрудников.
Склад.
Отдел продаж.
Логистика.
Удаленные менеджеры в регионах.
IT внутри росло как у большинства бизнеса:
не по проекту, а по жизни.
Появилась новая задача — докрутили.
Открылся филиал — добавили VPN.
Нужна интеграция — сделали “временно”.
Переехали — серверную собрали из того, что было.
И всем этим много лет занимался один системный администратор.
Не потому что собственник экономил “назло”.
Просто схема выглядела рабочей.
Человек был толковый.
Редко беспокоил руководство.
Всё действительно работало.
Ну… почти всё.
Проблемы были. Но они казались бытовыми
Иногда падал VPN.
Иногда зависала телефония.
Иногда ночью не проходил обмен между CRM и 1С.
Но Слава всё быстро поднимал.
Причем часто — молча.
В этом вообще коварство хороших специалистов.
Они слишком хорошо компенсируют системные проблемы.
Бизнес перестает видеть масштаб зависимости.
Потому что снаружи всё выглядит как:
«Ну иногда что-то чинят».
Хотя внутри инфраструктура уже давно держится на ручном управлении.
Когда человек знает всё — это сначала удобно
Потому что быстро.
Не нужно документации.
Не нужны регламенты.
Не нужны лишние согласования.
Спросили — сделал.
Попросили — настроил.
Возникла проблема — починил.
Со временем у такого сотрудника в голове оказывается половина бизнеса.
Доступы.
Пароли.
Схемы интеграций.
Резервные настройки.
Старые костыли, про которые все забыли.
Логика работы сервисов.
Особенности телефонии.
Права доступа.
Непонятные скрипты с названиями вроде final_new2.bat.
И самое опасное — никто больше этого не знает.
Потому что «зачем, если есть человек».
Потом сотрудник увольняется
Не со скандалом.
Без мести.
Без красивого хлопанья дверью.
Просто устал.
Нашел работу спокойнее.
Без ночных звонков.
Без режима “всегда на связи”.
Передал дела как смог.
Рассказал основное.
Оставил файл с паролями.
Пожал руки.
Ушел.
В этот момент компания была уверена, что всё нормально.
Потому что системы ведь продолжали работать.
Настоящие проблемы начались через четыре дня
В понедельник утром перестала работать IP-телефония.
Сначала подумали — провайдер.
Потом выяснилось, что слетел сертификат на старом сервере голосового шлюза.
Новый подрядчик запросил доступы.
Оказалось:
— часть паролей не подходит;
— сервер находится не там, где думали;
— резервный аккаунт привязан к старой корпоративной почте;
— сама схема телефонии собиралась кусками с 2019 года.
Пока разбирались — отдел продаж полдня сидел без звонков.
Но это было только начало.
Через день «отвалился» склад
Система перестала корректно проводить остатки.
Документы зависали.
Обмен между 1С и CRM работал через старый скрипт, который запускался вручную по расписанию.
Об этом вообще никто не знал.
Новый специалист нашел задачу в планировщике Windows с комментарием:
«НЕ ТРОГАТЬ!!!»
Это, кстати, один из самых реалистичных элементов любой старой инфраструктуры.
Там всегда есть что-то с пометкой:
— «не менять»;
— «иначе ломается»;
— «непонятно как работает, но работает».
К середине недели началась управленческая паника
Не потому что всё окончательно рухнуло.
А потому что никто не понимал масштаб зависимости.
Вот это самое неприятное чувство для бизнеса.
Когда:
— система вроде живая;
— люди вроде работают;
— но любая новая проблема превращается в расследование.
Собственник впервые начал задавать вопросы:
— где вообще находятся критичные сервисы;
— кто имеет доступ;
— что резервируется;
— как быстро можно восстановиться;
— сколько еще таких скрытых схем внутри компании.
И оказалось, что ответа нет.
Виноватых вроде нет
Сотрудник не делал ничего специально.
Наоборот.
Много лет он удерживал систему в рабочем состоянии.
Проблема была не в человеке.
Проблема была в модели управления.
Бизнес годами жил в логике:
«Главное, чтобы работало».
А всё остальное откладывалось:
— документация;
— прозрачность;
— стандартизация;
— резервирование знаний;
— понятная архитектура.
Потому что это всегда кажется вторичным.
До момента, пока человек не уходит.
Самая дорогая зависимость — та, которую не замечают
У компании ушла почти неделя на стабилизацию процессов.
Не потому что инфраструктура была ужасной.
А потому что никто не видел её целиком.
Каждая система по отдельности выглядела терпимо.
Но между ними были десятки невидимых связей:
— старые интеграции;
— ручные сценарии;
— костыли;
— временные решения;
— сервисы, о которых вспоминали только в момент сбоя.
Это как старое здание, где проводку десятилетиями наращивали кусками.
Пока свет горит — всё выглядит нормально.
Но попробуй найти, где именно коротит.
Очень многие компании живут в режиме «незаменимого человека»
Причем не только в IT.
Просто в инфраструктуре это особенно опасно.
Потому что бизнес может пережить сложного сотрудника.
Но плохо переживает непрозрачность.
Когда процессы:
— нигде не описаны;
— завязаны на память;
— держатся на привычке;
— понятны только одному человеку.
Компания становится уязвимой не из-за технологий.
А из-за отсутствия системы.
После таких историй бизнес меняет не серверы
Меняется отношение.
Появляется понимание, что:
— знания должны храниться в компании, а не в голове сотрудника;
— инфраструктура должна быть понятной;
— доступы должны контролироваться;
— процессы должны быть воспроизводимыми;
— бизнес не должен зависеть от одного “героя”.
Потому что героизм — плохая основа для стабильной операционки.
Сегодня человек есть.
Завтра — отпуск.
Больничный.
Выгорание.
Увольнение.
И если вместе с ним из компании уходит понимание, как устроен бизнес — проблема началась сильно раньше заявления “по собственному”.