Как решить: дорабатывать ИТ-систему или менять целиком

Почему компании застревают в старых ИТ-системах

Статистика говорит, что только 35% компаний успешно завершают цифровую трансформацию. А в традиционных отраслях (нефтегазовая и автомобильная промышленность, фармацевтика и т.д.) этот показатель падает до 4–11%. По данным McKinsey, 17% ИТ-проектов заканчиваются настолько плохо, что даже ставят под угрозу само существование компании. Ошибки при модернизации могут дорого обойтись: например, Hershey’s потеряла $100 млн на неудачной замене ERP-системы.

Причин этому много. Часто бизнес боится менять систему, потому что это сопровождается большими затратами и рисками. При этом поддержка устаревших решений может быть еще дороже, а доработки превращаются в борьбу с устаревшим кодом. Такая ситуация напоминает автомобиль с высоким пробегом: формально он работает, но требует все больше вложений, а новые задачи уже не «тянет».

Когда систему стоит дорабатывать

Важно понимать, что не всегда старая система это приговор. Если архитектура стабильна, технический долг (временные решения из-за которых сложно внедрять новые функции) контролируем, а нагрузка растет умеренно, ее можно просто модернизировать.

Удачный пример — компания Shopify. Она  не стала полностью переписывать свою монолитную систему, а модернизировала ее. Это позволило масштабировать платформу без риска для бизнеса управляемость и ключевую экспертизу внутри компании. 

Помните, что если новые задачи можно реализовать через микросервисы, то нет необходимости трогать всю систему. Еще один показатель — стабильный пользовательский сценарий. Если система спокойно справляется с рутинными задачами, а количество пользователей не растет кратно, значит ее можно оставить. 

Архитектура VC интерфейс

Необходимо различать архитектурные и интерфейсные проблемы. Если ядро системы стабильно, а пользователи жалуются на неудобство, переписывать ее полностью не стоит. Улучшение UX, внедрение API или клиентских приложений часто решает проблему без рисков для бизнеса.

Пример из практики: когда мы работали с Taker (сервис доставки еды), в приложении на первом экране был только один элемент — текстовое поле, куда внимательный пользователь должен был вручную ввести район. Мы же просто добавили карту и геолокацию, что привело к кратному росту заказов без переписывания ядра.

Постепенная модернизация в динамичных отраслях

В e-commerce и других быстро меняющихся сферах, постепенная модернизация помогает бизнесу не отставать от рынка. Например, у той же компании Taker была самописная система, которая не справлялась с ростом. И наша команда пошла по пути поэтапной модернизации: мы вынесли модули, внедрили несколько контуров (разработка, тестирование, эксплуатация), и за два года повысили надежность, при этом не останавливая бизнес.

Если бы компания меняла систему «с нуля», она бы потеряла темп. Но в отраслях с меньшей динамикой (например, в логистике) такие риски ниже, и тогда логичнее сразу переходить к новой системе.

Тем не менее, даже при доработке важно четко представлять, как она будет происходить и оценивать свои возможности: как технические, так и финансовые. Потому что по данным McKinsey, 60% ИТ-проектов выходят за рамки бюджета из-за недооценки сложности миграции.

Когда замена — это здравое решение

Если ИТ-система сдерживает рост, значит пора принимать радикальные меры. Вот по каким признакам это можно понять:

• Технический долг стал неуправляемым, а каждое изменение вызывает баги;
• Отсутствует модульность, а архитектура несовместима с задачами бизнеса;
• На доработку одной функции уходит неделя вместо пары часов.

Например, если компания выходит на новый рынок, а архитектура не поддерживает нужную локализацию, то текущую систему проще заменить, чем адаптировать.

Еще иногда экономически выгоднее рассмотреть вариант не создания системы с нуля, а покупки готового решения. Лицензионное ПО тоже отличный вариант.

Гибридный путь: не разрушать, а эволюционировать

История знает множество провалов, связанных с полной заменой систем. Например, Hershey’s решила заменить ERP-систему из-за Y2K, но потеряла $100 млн, сорвала поставки и снизила стоимость акций. А Knight Capital Group лишилась $440 млн за один день из-за неудачной новой торговой платформы.

Порой компании бросают старую систему ради «идеального» нового решения, но получают те же проблемы: потерю экспертизы, затянувшиеся сроки, сбои на старте. Примеры: Netscape, IBM, HealthCare.gov.

При этом в e-commerce мы видим много успешных компаний, которые пошли путем постепенной модернизации. Например, Shopify, Walmart и Booking.com выносят отдельные сервисы, внедряют API и переводят модули на новые технологии. Такой подход требует времени и дисциплины, но он снижает риски и позволяет бизнесу не останавливать процессы.

Чек-лист для бизнеса: менять или дорабатывать ИТ-систему

Чтобы принять обоснованное решение о модернизации ИТ-системы, опирайтесь на следующие вопросы: 

• Насколько система критична для бизнеса? Можно ли «приостановить» ее? 

Помните, что, условно, заменить простую систему планирования отпусков -- легко. А вот BI-систему гораздо сложнее. 

• Каков объем технического долга и можно ли его локализовать? Где больше всего происходит проблем? 
• Есть ли ресурсы и время на параллельную разработку?
• Справится ли команда с задачей? Сможет ли она написать новое хорошее решение? Или новое решение будет не лучше старого?
• Есть ли на рынке готовые решения, которые реально подходят бизнесу? Есть ли замена, которая будет выгоднее по финансам?

Если при проектировании с нуля вы выбрали бы принципиально другую архитектуру — это также аргумент в пользу замены системы. Но если текущая платформа позволяет реализовывать ключевые процессы, то проще и выгоднее идти по пути последовательных улучшений. Ключевым критерием должно оставаться не техническое совершенство самой платформы, а ее способность надежно поддерживать достижение бизнес-целей.