Модернизация устаревших систем: что делать и с чего начать

Что считать устаревшей системой

Устаревшая система не обязательно старая по возрасту. Это программа или набор файлов, которые ещё работают, но мешают расти: менять дорого, трогать страшно, подключить к новым каналам нельзя. Это может быть самописная учётная программа, давно настроенная конфигурация 1С, CRM на сервере в офисе или связка Excel-таблиц, которую ведёт один сотрудник.

Сразу разделите две проблемы. Первая техническая: платформа не обновляется, нет исправлений безопасности, код никто не читает. Вторая бизнесовая: процессы изменились, а система осталась прежней. Лечатся они по-разному, и путаница между ними — частая причина неудачных проектов.

Признаки, что откладывать уже дорого

Ни один признак в отдельности не приговор. Тревожно, когда их несколько и они повторяются из месяца в месяц.

• Мелкая правка занимает недели и стоит дороже, чем ожидали
• Систему до конца понимает один человек, и он может уйти
• Платформа не получает обновлений, в том числе по безопасности
• Нельзя подключить оплату через Click или Payme, Telegram, сайт или маркетплейс вроде Uzum
• С ростом базы отчёты строятся долго, программа зависает
• Данные переносят вручную из файла в файл
• Сотрудники ведут параллельные таблицы, потому что «в системе неудобно»

Три пути: доработать, заменять по частям или переписать

Выбор зависит от того, насколько здорово ядро системы, как сильно изменился бизнес и сколько у вас времени и денег. Универсального ответа нет, но разницу между вариантами стоит понимать заранее.

• Доработка: обновить платформу, переписать самые слабые места, добавить API. Быстрее на старте и дешевле, подходит, когда ядро в порядке, а проблемы локальны. Не спасёт, если сама технология мертва.
• Поэтапная замена: новые модули строятся рядом и по одному забирают функции старой системы. Дольше по календарю, зато бизнес не останавливается и риск распределён.
• Переписывание с нуля: новая система создаётся целиком, затем одномоментный переход. Оправдано, когда доработки бессмысленны, а процессы всё равно придётся перестраивать. Самый рискованный вариант.

Почему переписывание с нуля чаще всего срывается

Новая система почти всегда занимает больше времени, чем планировали, а бизнес за это время не стоит на месте: появляются новые товары, акции, способы оплаты. Команда оказывается в положении, когда нужно поддерживать две системы сразу.

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

Пошаговый план модернизации

Рабочая последовательность выглядит так. Она подходит для любого из трёх путей и защищает от главных ошибок.

• Опишите, что система делает, кто ею пользуется и какие процессы на ней держатся
• Проведите аудит: качество кода, документация, технологии, архитектура, состояние данных
• Выделите слои: что оставить, что обернуть через API, что заменить
• Сравните стоимость поддержки старой системы на несколько лет вперёд с затратами на модернизацию и рисками каждого пути
• Начните с одного модуля, где боль самая заметная, а риск небольшой
• Запустите старую и новую части параллельно, сверяйте результаты
• Переключайте пользователей группами и только потом отключайте старую часть

Данные и скрытые правила: что нельзя потерять

Данные — самая ценная часть старой системы: история клиентов, заказов, цен, взаиморасчётов. Перенос готовят заранее: проверяют дубли и мусор, определяют соответствие полей, делают пробный перенос на копии, сверяют итоги. Обязательно предусмотрите откат, чтобы при ошибке можно было вернуться к прежнему состоянию, не потеряв рабочий день.

Бизнес-правила фиксируйте письменно прямо в ходе работ. Попросите бухгалтера, склад и менеджеров рассказать, что они делают руками «вне системы». Эти рассказы часто ценнее самого кода. Такой документ нужен при любом варианте и остаётся у вас, даже если подрядчик сменится.

Telegram-бот: новый слой вокруг старой системы

Часто самая быстрая польза от модернизации — не замена ядра, а новый интерфейс для клиентов и сотрудников. Представьте магазин в Ташкенте: заказы приходят из директа Instagram, из Telegram и по телефону, а учёт идёт в старой программе, куда менеджер вручную переписывает всё подряд. Заменять учёт целиком дорого и рискованно.

Вместо этого рядом ставят Telegram-бота: он показывает каталог, принимает заказ, предлагает оплату через Click или Payme и передаёт данные в старую систему через API, файл обмена или промежуточную базу. Старое ядро работает, как работало, а ручной ввод исчезает. Тот же бот может отправлять менеджеру остатки, а курьеру статус доставки. Если со временем модули переедут на новую платформу, бот останется прежним, поменяется только то, что за ним.

Именно такие задачи мы в markdev разбираем в разработке Telegram-ботов для бизнеса в Узбекистане: сначала смотрим, как устроена текущая система и куда к ней можно подключиться, и лишь потом предлагаем объём работ.

Типичные ошибки

Большинство проблем возникает не из-за технологий, а из-за порядка действий.

• Решать «переписываем» до аудита, только потому что старый код не нравится
• Не описывать бизнес-правила и надеяться, что команда всё вспомнит
• Делать большой переход в один день, без параллельной работы
• Переносить данные без пробной копии и плана отката
• Не привлекать сотрудников, которые работают в системе каждый день
• Считать только стоимость разработки и забывать про цену простоя и ручного труда

Чек-лист перед стартом

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

• Список процессов, которые держатся на системе, и их владельцы
• Список интеграций: оплата, склад, сайт, Telegram, маркетплейсы
• Описанные исключения и ручные операции
• Резервная копия данных и проверенный способ восстановления
• Выбранный первый модуль и критерий, по которому поймём, что он удался
• Ответственный со стороны бизнеса, а не только разработчик