Техдолг — это когда в ИТ годами жили по принципу «и так работает». Поставили временный сервер — и на него легла вся 1С. Запустили маленький внутренний сервис — и через два года через него идут счета и заявки клиентов. Поддержка живет в рабочих чатах, а разбираться во всем умеет один «незаменимый айтишник». Пока ничего не падает, кажется, что это экономия. Пока не случается первый большой простой.
Меня зовут Дмитрий Бессольцев, я руковожу компанией ALP ITSM. Уже 30 лет мы приходим в бизнес, где ИТ стало критичным для денег и операций, но внутри осталось много решений «на коленке», принятых в спешке.
В этой статье простым языком расскажем:
- что такое техдолг и почему это не только про «старое железо»;
- как он копится в людях, процессах и технологиях;
- почему каждый отложенный «неприятный» проект потом обходится дороже;
- и как подойти к разбору техдолга так, чтобы не переписывать все с нуля, а сделать реалистичный план, который бизнес действительно потянет.
Что такое технологический долг
Технологический долг в ИТ — это совокупный эффект прошлых компромиссов, благодаря которым компания когда‑то могла внедрять решения быстрее или дешевле, но сегодня несет повышенные риски и дополнительные расходы. Фактически речь идет о решениях формата «сделаем сейчас, а привести в порядок успеем потом», которые принимались один, два, пять лет назад и теперь проявляются в виде ограничений для бизнеса.
Чаще всего экономия происходила на архитектуре, отказоустойчивости, документации, подборе и развитии команды, настройке процессов.
В результате организация расплачивается простоями ключевых сервисов, аварийными работами «вручную» и тем, что ИТ становится узким местом для роста.
В финансовой отчетности технологический долг не отражается: в ней видны только серверы, лицензии и текущие расходы. По этой причине финансовый блок зачастую не воспринимает его как отдельную категорию, хотя именно техдолг уменьшает прибыль, увеличивает потери и со временем способен влиять на оценку компании: из‑за него вы теряете деньги, можете сорвать обязательства перед клиентами и стоимость «ремонта по факту аварии» оказывается значительно выше, нежели выполнить эти работы в плановом режиме.
Уместно рассматривать технологический долг как кредит под проценты. Каждый раз, когда компания откладывает обновление критичного сервера или модернизацию устаревшего решения, она по сути продлевает действие этого кредита еще на один период. Проценты накапливаются в виде все более дорогих проектов, чтобы исправить ситуацию, усложняющейся поддержки и возрастающих рисков простоя.
Другая наглядная метафора — стоматология. Пока зуб не болит, создается иллюзия, что лечение можно отложить без последствий. Однако каждый месяц ожидания делает вмешательство дороже и сложнее, а на каком‑то этапе «лечение» уже невозможно — остается только удаление.
С ИТ‑инфраструктурой и бизнес‑сервисами ситуация аналогична: чем дольше компания откладывает работу с технологическим долгом, тем выше цена вопроса и тем жестче могут быть последствия.
Три источника техдолга: люди, процессы, технологии
В IT‑управлении принято выделять три ключевых слоя: люди, процессы, технологии.
Техдолг накапливается во всех трех, а не только в «железе» и версиях ПО. Когда компании смотрят только на инфраструктуру, они упускают риски, связанные с кадровыми решениями и незрелыми процессами. Если слабое место есть хотя бы в одном блоке, техдолг уже растет; если во всех трех — вопрос лишь в том, когда случится авария и сколько она обойдется.
Люди: один «незаменимый» специалист
Знакомая многим картина, когда ключевые сервисы завязаны на одного ИТ‑сотрудника. Он знает все настройки, обходные решения и историю системы. Для бизнеса это выглядит удобно, но по сути создает критическую зависимость. Болезнь, отпуск или уход такого человека могут привести к остановке важных операций — от счетов до отчетности.
Отсутствие распределения знаний и планирования компетенций — это тоже форма техдолга.
Процессы: поддержка через чат
Во многих компаниях ИТ‑поддержка строится вокруг чатов и личных договоренностей. Четких регламентов, SLA и приоритизации нет. Пока масштабы невелики, схема работает.
Но при росте бизнеса заявки теряются, все «горит» одновременно, а время восстановления нельзя ни спрогнозировать, ни контролировать.
Каждый перенос настройки процессов «на потом» добавляет техдолг в этом слое.
Технологии: временное, которое стало постоянным
Частый сценарий: пилотный сервис запускают на старом сервере, без отказоустойчивости и нормальных бэкапов — «временно, посмотреть».
Со временем на нем начинают работать критичные процессы, но архитектура и инфраструктура остаются «тестовыми». К этому добавляются устаревшие серверы без поддержки и версии ПО, которые вендор больше не обновляет. Обновление кажется сложным и рискованным, поэтому его годами откладывают.
Такие временные решения и отложенные обновления и составляют основной массив технологического техдолга.
Когда «временная» CRM останавливает весь опт
Расскажу историю одной из компаний, на ее примере наглядно видно к чему приводит игнорирование работы с технологическим долгом.
В 2017‑м это была небольшая оптовая компания: склад 200 м², пара машин, пять человек. Заказы шли по телефону, отгрузки собирали в Excel, документы выбивали в 1С — неудобно, но терпимо. Когда доросли до нескольких десятков клиентов и небольших сетей, завели Bitrix24 «на попробовать», чтобы не терять заявки и хоть как‑то видеть воронку.
Через пару лет CRM стала нервной системой бизнеса. Через нее проходили входящие заказы, задачи склада и водителей, окна поставки, согласования по ценам и отсрочкам, переписка с ключевыми клиентами. Фактически, если Bitrix не работает, компания не видит заказы, обязательства и текущие операции. Но под всем этим оставался тот же «временный» фундамент: офисный сервер, «какие‑то» бэкапы, самописные интеграции с 1С без документации и без тестового контура.
По деньгам картинка выглядела прилично. В сезон компания делала 1,5–1,9 млн ₽ выручки в месяц, то есть 70–90 тысяч ₽ в день. На этом фоне сервер за 120 тысяч и «потом как‑нибудь перенесем в облако» выглядели разумной экономией.
Пока однажды в пятницу, в конец месяца, сервер не перестал грузиться после обновления. CRM не поднялась, попытка восстановиться из резервной копии провалилась — бэкапы были, но не проверялись. В результате два с лишним дня компания жила фактически в режиме частичного паралича:
- менеджеры не видели заявки, историю клиентов и договоренности по отсрочкам;
- склад не видел актуальные резервы и сроки годности, не понимал, что уже обещано конкретным клиентам;
- логист не видел маршруты и окна поставки, машины стояли или ездили по «бумажным» спискам;
- бухгалтерия не могла вовремя закрыть документы и выставить счета.
За эти два дня часть поставки в сети встали, часть заказов ушла конкурентам, по нескольким ключевым клиентам бизнес получал жесткую обратную связь и угрозы «пересмотреть сотрудничество». Плюс появились жалобы в соцсетях и на профильных площадках — и потом эти скриншоты еще долго всплывали в переговорах.
Если посчитать деньги, получается неприятная арифметика. При дневной выручке 70–90 тысяч ₽ простои и срывы заказов в пиковые дни легко выливаются в 200–300 тысяч ₽ недополученной выручки и штрафов за несколько суток.
Отдельная боль — репутация. Один из клиентов открыто поставил под вопрос продолжение сотрудничества после срыва поставок, несколько партнеров параллельно начали тестировать альтернативных поставщиков «на всякий случай». Это уже та часть потерь, которая в отчетах не отражается, но потом неожиданно вылезает в виде снижения лояльности и меньшего потока заказов.
Теперь смотрим на вторую сторону уравнения — сколько стоило бы «сделать по уму». Перенос CRM в облако с нормальным SLA, регулярные проверяемые бэкапы, документация по интеграциям с 1С, минимальный План аварийного восстановления (Disaster Recovery plan) и тестовый контур для обновлений обошлись бы в диапазон 150 000–500 000 ₽ разово плюс 50 000–100 000 ₽ в год на инфраструктуру и сопровождение. Конкретная цифра зависит от зоопарка накопленных интеграций, но порядок именно такой: один «нормальный» проект стоит как один‑два серьезных инцидента.
Кейс Grow Food и другие публичные истории с многодневными простоями показывают, что проблема не уникальна: даже крупные компании с ИТ‑командами и бюджетами на порядок выше иногда лежат по двое суток и больше. Для небольшого оптовика без DR‑плана двое суток простоя — это еще довольно мягкий сценарий. На этом фоне техдолг перестает быть страшилкой айтишников и превращается в очень простой управленческий выбор: заплатить один раз за решение или регулярно платить сопоставимые суммы за последствия.
Один сервис, три слоя технологического долга
Представим внутренний сервис, который когда‑то запускали «для удобства» — например, систему, через которую идут счета, закрывающие документы и часть клиентской коммуникации.
С точки зрения людей:
- функцию сопровождает один–два человека, которые знают все костыли и обходные пути;
- команда завязана на личную компетенцию этих людей и их доступность 24/7.
С точки зрения процессов:
- заявки на исправление ошибок в сервисе падают в чат, фиксируются как попало;
- SLA на исправление багов и простои нигде не описаны, все держится на «договорились по‑человечески».
С точки зрения технологий:
- сервис стоит на старом сервере, который изначально заводили как временный;
- отказоустойчивости нет, бэкапы делаются нерегулярно, тестового контура нет.
Каждое отдельное решение когда‑то казалось мелочью, компромиссом ради скорости.
Но в сумме они превращаются в серьезный бизнес‑риск: достаточно одной аварии или ухода ключевого сотрудника, чтобы критичный кусок операционной деятельности остановился.
Это и есть техдолг во всей красе: сумма мелких уступок, которая неожиданно вырастает в большую проблему.
Почему техдолг дорожает каждый месяц
Техдолг никогда не стоит на месте.
Оборудование дорожает, валютные риски никуда не деваются, новые модели железа стоят дороже старых. Лицензии и подписки на программное обеспечение тоже растут в цене.
Стоимость работ ИТ‑специалистов и подрядчиков увеличивается: рынок испытывает дефицит квалифицированных людей, а сложность инфраструктур только растет.
Проект, который можно было сделать «малой кровью» три года назад, сегодня превращается в тяжелую миграцию.
Каждый новый инцидент по старому серверу, неактуальному сервису или «героическому» сотруднику — это уже не просто проблема, а проценты по тому самому кредиту.
Вы платите за аварийные выезды, овертаймы, разовые костыли и параллельно увеличиваете риск того, что в следующий раз все обойдется еще дороже.
Откладывание решения не экономит деньги — оно лишь переносит платеж на будущее с надбавкой за риск.
Зачем здесь ИТ‑аудит и консалтинг
Чтобы начать разбираться с техдолгом, его сначала нужно выявить и описать.
Не в формате общих жалоб «у нас все старое и все плохо», а в виде конкретного списка: какие долги по людям, по процессам и по технологиям у вас уже накопились.
Системный ИТ‑аудит как раз и работает как инвентаризация техдолга и оценка рисков.
Он помогает:
- выявить критичные точки отказа по людям, процессам и технологиям;
- оценить вероятность и последствия инцидентов;
- перевести эти последствия в деньги и понятные бизнесу сценарии.
Дальше в дело входит ИТ‑консалтинг: нужно не просто «увидеть проблему», а построить план ее поэтапного погашения. Определить, что чинить в первую очередь, где достаточно минимальных доработок, а где нужен пересмотр архитектуры.
Для вас как компании результат ИТ‑аудита в этой картине мира — это не страшилка про «все пропало», а ясная карта:
- где именно копится ваш техдолг;
- во что он выльется, если ничего не делать;
- сколько будет стоить плановое, контролируемое «лечение» вместо аварийных операций.
Наш опыт простой: большинство клиентов тянут с техдолгом до тех пор, пока не случиться ЧП с убытками и простоями. Правильной мыслью будет считать устранение технологического долга конкурентным преимуществом, поскольку если у вас все работает, а конкурента нет — поток клиентов направлен в вашу сторону. ИТ‑аудит как раз нужен, чтобы прийти не после аварии, а до нее и спокойно посчитать, где риск оправдан, а где вы уже играете в русскую рулетку вместо управляемого решения.
Заключение: с чего начать прямо сейчас
Техдолг — это как кредит, который вы уже взяли на ИТ, только без графика платежей. Пока все работает, кажется, что можно подождать еще месяц. Но каждый новый сбой на старом сервере или «временном» сервисе добавляет к этому долгу проценты в виде простоя, потери клиентов и нервов команды.
Если вы по описанию узнали свой бизнес — один «незаменимый» айтишник, сервера «еще живые», процессы поддержки в чатах, — начните не с глобальной реформы, а с маленькой ревизии. Выпишите, какие системы для вас критичны, где нет нормальных бэкапов и плана Б, и прикиньте, сколько будет стоить хотя бы день простоя каждой из них. Часто уже одно это упражнение показывает, что запланированный аудит и наведение порядка стоят дешевле, чем одна неудачная пятница в конец месяца.
Если сейчас как раз думаете, с кем в это заходить, посмотрите чек‑лист по выбору ИТ‑подрядчика: важно не только, сколько стоит час работы, но и как партнер относится к бэкапам, DR и техдолгу. В кризисный момент это разница между «посидеть ночью с ноутбуком» и «объяснять клиентам, почему два дня ничего не работало».