Технический долг не виден в отчетности, но он определяет масштаб потерь при сбоях. В статье разбираем причины и влияние на операционную устойчивость бизнеса
Технологический долг в ИТ редко виден в финансовой отчетности, но все чаще проявляется в операционных сбоях. Отказ устаревшего сервера с ключевой учетной системой, остановка «временного» сервиса, через который проходят счета и сделки, или уход единственного специалиста, поддерживающего критичную платформу, приводят к простоям, срыву обязательств и внеплановым затратам.
В материале рассмотрим, как технологический долг формируется в трех плоскостях — кадровой, процессной и технологической — и почему фокус только на замене серверов и обновлении ПО не решает проблему. Отдельное внимание уделим разделению инженерной и бизнес‑оценки техдолга, расчету стоимости простоя и сравнению сценариев «плановое обновление» и «реакция по факту аварии». Речь пойдет о том, как с помощью ИТ‑аудита и консалтинга превратить общее ощущение «у нас все устарело» в структурированный перечень рисков, их стоимости и приоритетов поэтапного снижения.
Что такое технологический долг
Технологический долг в ИТ — это совокупный эффект прошлых компромиссов, благодаря которым компания когда‑то могла внедрять решения быстрее или дешевле, но сегодня несет повышенные риски и дополнительные расходы. Фактически речь идет о решениях формата «сделаем сейчас, а привести в порядок успеем потом», которые принимались один, два, пять лет назад и теперь проявляются в виде ограничений для бизнеса.
Чаще всего экономия происходила на архитектуре, отказоустойчивости, документации, подборе и развитии команды, настройке процессов.
В результате организация расплачивается простоями ключевых сервисов, аварийными работами «вручную» и тем, что ИТ становится узким местом для роста.
В финансовой отчетности технологический долг не отражается: в ней видны только серверы, лицензии и текущие расходы. По этой причине финансовый блок зачастую не воспринимает его как отдельную категорию, хотя именно техдолг уменьшает прибыль, увеличивает потери и со временем способен влиять на оценку компании: из‑за него вы теряете деньги, можете сорвать обязательства перед клиентами и стоимость «ремонта по факту аварии» оказывается значительно выше, нежели выполнить эти работы в плановом режиме.
Уместно рассматривать технологический долг как кредит под проценты. Каждый раз, когда компания откладывает обновление критичного сервера или модернизацию устаревшего решения, она по сути продлевает действие этого кредита еще на один период. Проценты накапливаются в виде все более дорогих проектов, чтобы исправить ситуацию, усложняющейся поддержки и возрастающих рисков простоя.
С ИТ‑инфраструктурой и бизнес‑сервисами ситуация аналогична: чем дольше компания откладывает работу с технологическим долгом, тем выше цена вопроса и тем жестче могут быть последствия.
Три источника техдолга: люди, процессы, технологии
В 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‑плана двое суток простоя — это еще довольно мягкий сценарий. На этом фоне техдолг перестает быть страшилкой айтишников и превращается в очень простой управленческий выбор: заплатить один раз за решение или регулярно платить сопоставимые суммы за последствия.
Один сервис, три слоя технологического долга
Рассмотрим типичный пример внутреннего сервиса, который изначально запускался «для удобства» — систему, через которую проходят счета, закрывающие документы и часть коммуникации с клиентами.
Со временем такой сервис из вспомогательного превращается в один из ключевых элементов операционной деятельности компании.
С точки зрения людей сервисом фактически управляют один–два сотрудника, которые знают всю историю его внедрения, неформальные обходные решения и «костыли».
Знания концентрируются у узкой группы, и работоспособность критичной функции по сути зависит от их постоянной вовлеченности и доступности.
С точки зрения процессов обращения по ошибкам и доработкам этого сервиса, как правило, поступают в рабочие чаты и фиксируются нерегулярно.
Формальных SLA по срокам реакции и устранения инцидентов нет, и многие договоренности строятся на личных контактах и устных обещаниях.
С точки зрения технологий сервис продолжает работать на инфраструктуре, которая задумывалась как временная: на устаревшем сервере без отказоустойчивой схемы, с нерегулярными резервными копиями и без отдельного тестового контура.
По отдельности каждое из этих решений когда‑то воспринималось как допустимый компромисс ради скорости внедрения.
В совокупности они формируют серьезный бизнес‑риск: достаточно одного серьезного сбоя или выпадения ключевого сотрудника, чтобы остановился значимый для компании участок операционной деятельности.
Именно так выглядит технологический долг на практике — как набор небольших уступок, которые постепенно складываются в крупную проблему.
Почему техдолг дорожает каждый месяц
Техдолг — это не что‑то статичное, что можно «заморозить» и потом спокойно к нему вернуться.
Это именно кредит: вы его уже взяли, и проценты по нему капают каждый день, даже если вы делаете вид, что ничего не происходит.
Железо дорожает, новые модели стоят дороже старых, валютные качели никуда не деваются.
Лицензии и подписки тоже не стремятся дешеветь, а условия вендоров со временем, как правило, становятся жестче, а не мягче.
Работа людей тоже стоит все дороже: хороших ИТ‑специалистов на рынке не прибавляется, инфраструктуры усложняются, и любой проект миграции требует все больше квалификации и времени. То, что три года назад можно было сделать «малой кровью», сегодня превращается в тяжелый переезд на несколько недель.
Отдельная статья «процентов» — безопасность. Старые версии фреймворков, библиотек и операционных систем перестают получать патчи, а требования к защите данных и результаты внешних проверок становятся все жестче. Закрывать новые уязвимости на старом стеке зачастую дороже, чем один раз запланированная миграция.
Похожая ситуация с legacy‑монолитами. Система, которую три года назад еще можно было относительно безболезненно распилить или хотя бы обложить тестами, за это время обрастает интеграциями и бизнес‑логикой. Каждое изменение по ней требует все больше усилий, и цена любого рефакторинга растет гораздо быстрее инфляции.
Каждый новый инцидент на старом сервере, вокруг неактуального сервиса или «героического» сотрудника — это не просто разовая проблема, а как раз те самые проценты по кредиту.
Вы платите за аварийные выезды, овертаймы, разовые костыли, но само тело долга никуда не девается — наоборот, риск следующей, еще более дорогой аварии только растет.
Откладывание решения здесь не экономит деньги.
Оно лишь переносит платеж на будущее, добавляя к нему надбавку за риск и за усложнившуюся за это время инфраструктуру.
Зачем здесь ИТ‑аудит и консалтинг
Чтобы вообще начать что‑то делать с техдолгом, его сначала нужно вытащить на свет. Не в формате «у нас все старое и все плохо», а в виде очень приземленного списка: где у нас риски по людям, где по процессам, где по технологиям и что именно там может хлопнуть.
По‑нормальному это делается через ИТ‑аудит. По сути, это инвентаризация техдолга и честная оценка того, во что вам обходится «ничего не менять». Мы раскладываем картину на две части: инженерная оценка — сколько стоит починить, и бизнес‑оценка — во сколько обойдется не чинить.
Дальше уже работает консалтинг: мало просто увидеть проблему, нужно договориться, в каком порядке вы этот долг будете платить. Где критичный риск и надо делать вчера, где можно заложить изменения в план работ, а где вообще хватает минимальных доработок и не нужно «переписывать все с нуля».
Наш опыт очень простой: большинство клиентов тянут с техдолгом до тех пор, пока их не «клюнет жареный петух». Устаревший сервер падает, старый сервис окончательно ломается, единственный человек, который все знает, уходит — и компания платит в разы больше, чем стоило бы плановое решение.
ИТ‑аудит как раз нужен, чтобы прийти не после аварии, а до нее. Спокойно посчитать, где риск оправдан, а где вы играете в русскую рулетку, и зафиксировать это на языке денег, а не эмоций.
С точки зрения ИТ‑команды результат нормального аудита — это не только презентация для собственников.
Это вполне конкретный план работ:
- перечень рисков по ключевым сервисам и системам;
- архитектурные «долги» и варианты их закрытия;
- список провалов в документации;
- приоритизированные изменения в процессах поддержки и эксплуатации.
При этом задача аудита — не «убедить всех срочно переписать все на новом стеке ради моды».
Цель — честно показать, где достаточно минимальных изменений и дисциплины, а где без серьезного рефакторинга или миграции риск уже неадекватен бизнесу.
Вместо вывода: техдолг как элемент устойчивости
Для промышленности, ритейла и опта разговор о техдолге давно вышел за рамки чисто ИТ‑повестки. Реальная устойчивость бизнеса определяется не тем, сколько систем вы успели запустить за последние годы, а тем, насколько прозрачно описаны критичные сервисы, где вы опираетесь на «временные» решения и есть ли у компании план, что делать в первый час серьезного сбоя.
В этом контексте ИТ‑аудит техдолга — это не поиск «крайнего админа» и не витрина красивых диаграмм. Это инструмент, который дает руководству понятную картину: какие сервисы и процессы действительно могут остановить операционку, какие «тестовые» решения давно стали точками отказа и куда разумно вкладываться в первую очередь. ИТ‑директору такой аудит дает язык разговора с советом директоров в категориях риска и стоимости простоя, а не в терминах «нужны новые сервера и еще один инженер».
Если вы понимаете, что инфраструктура и процессы поддержки складывались «как придется», логичным первым шагом будет не очередной ИТ‑проект, а честная диагностика техдолга. Даже ограниченный по масштабу аудит ключевых систем, бэкапов и DR‑сценариев дает основу, чтобы планировать не только рост, но и устойчивость бизнеса в год, когда цена одной ошибки заметно выросла.
Выбор редакции
Публикации, которые получают больше внимания и попадают в Сюжеты РБК
Рекомендации партнеров: