Ваш ИТ-бюджет уходит на поддержку. Вот куда на самом деле идут деньги.
В прошлом году вы наняли двух разработчиков. Вы ждали новых функций, более быстрых релизов и современного клиентского портала. Через двенадцать месяцев один разработчик тратит большую часть времени на то, чтобы десятилетняя интеграция с биллингом не ломалась при каждом обновлении у поставщика. Второй латает инструмент отчётности, который никто не помнит, как создавали. Нужные вам функции по-прежнему в роадмапе и отстают от графика на полгода.
Это не проблема штата. Это проблема систем. Приложения и инфраструктура, на которых работает ваш бизнес, создавались для компании вдвое меньше нынешней, на инструментах, актуальных в момент внедрения. Их никто не перестроил, потому что подходящего окна для этого так и не нашлось. Теперь стоимость поддержки растёт с каждым кварталом, а разрыв между тем, что умеют ваши системы, и тем, что от них нужно бизнесу, становится всё шире.
По данным исследований Deloitte и Gartner, 60-80 процентов типичного ИТ-бюджета компании среднего бизнеса уходит на эксплуатацию и поддержку: продление лицензий, патчи, поддержку legacy-систем и стабильность продакшена. На всё остальное остаётся 20-40 процентов: новые функции, автоматизацию, улучшения безопасности и проекты, о которых на самом деле просило руководство.
Почему затраты на поддержку продолжают расти
Нагрузка на поддержку в B2B-компаниях среднего бизнеса - не результат плохих решений. Это естественное следствие того, что системы годами строили под давлением сроков, по одной. Каждая система имела смысл в момент внедрения. Проблема в том, что никто не возвращался, чтобы провести рефакторинг, объединить или заменить их по мере того, как менялся бизнес.
1. Системы строили для компании поменьше
Интеграция с CRM, которая работала для 20 менеджеров по продажам, ломается на 80. Инструмент отчётности, работавший с одной базой данных, теперь опрашивает шесть. Внутренний дашборд, который загружался за две секунды, грузится тридцать, потому что объём данных вырос в десять раз. Ни одна из этих систем не отказала. Они проработали достаточно долго, чтобы стать несущими, а потом выросла нагрузка.
2. Окна для перестройки так и не нашлось
Каждый квартал выбор один и тот же: потратить три месяца на перестройку интеграции с биллингом или продолжать её латать и выпустить функцию, о которой просил совет директоров. Патч выигрывает каждый раз, потому что потребность бизнеса сиюминутная, а перестройка выглядит спекулятивной. За пять лет патчи накапливаются в систему, которую никто полностью не понимает и которую все боятся трогать.
3. Те, кто это строил, ушли
Подрядчик, написавший исходную интеграцию, ушёл два года назад. Сотрудник, который дорабатывал ERP, перешёл в другую компанию. Консультант, настроивший облачную инфраструктуру, больше не работает с вами по договору. Каждый уход уносит с собой незадокументированные знания, и каждый новый человек неделями разбирается, что построил предшественник, прежде чем сможет это поддерживать.
4. Привязка к поставщику с каждым годом повышает цену перехода
Чем дольше работает система, тем глубже она интегрируется со всем вокруг. Форматы данных закрепляются. Рабочие процессы опираются на конкретное поведение инструмента. Другие системы начинают зависеть от его выходных данных. Через три года переход - это уже не проект на выходные. Это многомесячная миграция с реальным риском для бизнеса. Поэтому продление подписывается, цена растёт, а привязка становится крепче.
Что показывают данные
Исследование Developer Coefficient от Stripe показало, что разработчики тратят в среднем 42 процента рабочего времени на технический долг и поддержку, а не на новую разработку. Для команды из четырёх инженеров это почти две полные ставки, которые уходят на поддержание работы существующих систем вместо создания того, что бизнесу нужно дальше.
Для компаний среднего бизнеса с 10-15 legacy-приложениями отраслевые бенчмарки оценивают прямые затраты на поддержку в $400,000-$800,000 в год. Эта цифра охватывает только видимые расходы: контракты на поддержку от поставщиков, хостинг, работу по патчам и реагирование на инциденты. В неё не входит упущенная выгода от функций, которые не были созданы, интеграций, которые не были завершены, и автоматизации, которая не была внедрена.
Именно накопительный эффект делает эту проблему структурной, а не бюджетной. Каждый год отложенной модернизации добавляет сложности. Каждый новый патч создаёт зависимость. Каждый обходной путь становится процессом, который кто-то должен поддерживать. К тому моменту, когда компания замечает закономерность, стоимость модернизации уже вдвое выше, чем была бы три года назад.
У вас эта проблема, если
Эти закономерности видны и без формального аудита:
- Новые функции стабильно делаются в три-пять раз дольше исходной оценки
- Ваша инженерная команда тратит больше дня в неделю на незапланированную поддержку и тушение пожаров
- Как минимум одна критически важная система зависит от единственного человека, который её создал или доработал
- В продакшене есть системы без документации, без тестов и без понятного владельца
- Продления контрактов с поставщиками дорожают на 10-20 процентов в год, а переход кажется невозможным
- Новые сотрудники месяцами выходят на продуктивность, потому что у кодовой базы нет пути онбординга
- Ваша команда строит обходные пути вместо устранения первопричин, потому что исправление слишком рискованно
- Вы не можете дать руководству ясный ответ, какая доля ИТ-расходов уходит на поддержку, а какая на новые возможности
Если подходит больше трёх пунктов, поддержка съедает большую долю ваших ИТ-ресурсов, чем осознаёт большинство заинтересованных лиц.
Что компании пробуют в первую очередь (и почему это не работает)
Нанять больше разработчиков
Если добавить людей в среду, перегруженную поддержкой, новые разработчики тоже будут тратить 40 процентов времени на долг. Вы получаете 60 процентов ресурса каждого нового сотрудника для новой работы, минус период адаптации, когда текущая команда обучает его незадокументированным системам. Арифметика редко даёт тот прирост продуктивности, на который рассчитывало руководство.
Переписать всё с нуля
Полное переписывание - самый дорогой и самый рискованный подход. Оно занимает больше времени, чем планировалось, стоит больше, чем заложено в бюджет, а старая система должна работать параллельно, пока не будет готова новая. Многие переписывания в компаниях среднего бизнеса застревают на 60-70 процентах готовности, потому что заканчивается бюджет или посреди проекта меняются требования бизнеса. Частичное переписывание оставляет две системы на поддержке вместо одной.
Игнорировать и сосредоточиться на функциях
Это выбор по умолчанию. Он работает квартал-другой. Потом сбой на день кладёт биллинг. Или в библиотеке, которую никто не обновлял три года, обнаруживается уязвимость. Или ключевой инженер, на котором держится система, подаёт заявление об уходе. Проблема не ждёт удобного момента, чтобы стать срочной.
Практичный подход: диагностировать, расставить приоритеты, модернизировать поэтапно
Шаг 1. Опишите, что у вас на самом деле есть
Составьте список всех приложений, интеграций, баз данных и инфраструктурных компонентов в продакшене. Для каждого запишите: кто его создал, кто его поддерживает, какой бизнес-процесс от него зависит, когда его последний раз обновляли и что произойдёт, если он откажет. Большинство компаний обнаруживает системы, о которых забыли, и зависимости, которые никто не задокументировал.
Шаг 2. Измерьте нагрузку на поддержку
В течение двух-четырёх недель отслеживайте, куда на самом деле уходит время инженеров. Разделите часы на категории: плановая разработка функций, незапланированная поддержка, реагирование на инциденты и сокращение технического долга. Соотношение покажет, какая часть ваших ресурсов работает продуктивно, а какую съедает прошлое. Показывайте эти данные руководству в долларах, а не в часах.
Шаг 3. Оцените системы по риску и упущенной выгоде
Для каждой legacy-системы оцените два параметра. Риск: какова вероятность сбоя в ближайшие 12 месяцев и его влияние на бизнес? Упущенная выгода: что могла бы создать команда, если бы эта система не требовала постоянной поддержки? Системы с высокими оценками по обоим параметрам - ваши приоритеты для модернизации. Системы с низкими оценками по обоим могут подождать.
Шаг 4. Начните модернизацию с самой ценной системы
Выберите одну систему. Оформите модернизацию как проект с определённым бюджетом, сроками и измеримым результатом. Это не переписывание. Это точечная перестройка компонента, который отнимает больше всего времени на поддержку или создаёт наибольший риск для бизнеса. Завершённый проект модернизации даёт аргументы и опыт для следующего.
Шаг 5. Выделите поддержку в отдельную статью бюджета
Сделайте поддержку видимой. Отделите её от общего ИТ-бюджета, чтобы руководство видело соотношение и отслеживало его во времени. Поставьте цель: если сегодня на поддержку уходит 75 процентов, стремитесь к 60 процентам через 12 месяцев. Цифра не обязана дойти до нуля. Она должна перестать расти.
Если ваша команда не может посчитать, какая доля её времени уходит на поддержку, а какая на новую работу, с этого и стоит начать. Запросите бесплатную диагностику - мы поможем вам составить эту картину за 30-45 минут.
На какие вопросы должна ответить диагностика технического долга
Полезная оценка - это не код-ревью. Она связывает системы с бизнес-процессами и отвечает на вопросы:
- Какие системы несут на себе выручку, операции и комплаенс?
- Какие из них отнимают больше всего часов поддержки относительно своей ценности для бизнеса?
- Где единые точки отказа: люди, поставщики или незадокументированные компоненты?
- Сколько стоит модернизация по сравнению с ещё 24 месяцами поддержки?
- В каком порядке проводить модернизацию, чтобы высвободить максимум ресурсов?
Результат - роадмап модернизации с приоритетами, под который руководство может планировать бюджет, а не список оценок качества кода, непонятных никому за пределами инженерной команды.
Чем помогает Fill System
Fill System работает с B2B-компаниями, которые переросли свои системы быстрее, чем за ними успела инфраструктура. Ловушка поддержки - один из самых явных сигналов: команда занята, бюджет потрачен, а бизнес не движется вперёд.
Наша бесплатная первичная диагностика выявляет самые затратные зоны поддержки и системы, которые нужно модернизировать в первую очередь. Если по итогам диагностики начинается внедрение, наши команды веб- и мобильной разработки и DevOps и облака берут перестройку на себя: объём работ определяется после диагностики, а потолок бюджета согласуется до начала работ.
Следующий шаг
Ваш ИТ-бюджет многое говорит о компании. Если большая его часть уходит на поддержание работы и совсем немного на создание того, что будет дальше, разрыв будет расти, пока что-нибудь не заставит начать этот разговор.
Запросите бесплатную диагностику и узнайте, где ваши расходы на поддержку выше всего и какие ресурсы освободит их модернизация.
Читайте также
Куда на самом деле уходит ваш ИТ-бюджет?
Запросите бесплатную диагностику и получите четкую картину, что исправить в первую очередь - без обязательств.