Как понять, что старую IT-систему уже можно отключать?

Отключать старую программу можно не тогда, когда новая система выглядит готовой на презентации, а когда компания способна выполнить в ней обычную работу, разобрать исключение и найти нужные данные без возврата к старому окну. Без этой проверки «переключение» часто превращается в месяцы двойного ввода и растущей путаницы.

Почему старая система живёт дольше, чем планировали

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

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

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

Сначала разделите текущую работу и историю

Старую программу не всегда нужно выключать физически в день перехода. История может быть нужна бухгалтерии, службе поддержки или для разбора старых договоров. Но доступ к архиву — не то же самое, что право продолжать вести там новые операции.

Полезно заранее обозначить три режима:

• Рабочая система. Здесь появляются все новые операции и принимаются решения на сегодня.
• Архив для чтения. Здесь ищут старую информацию, но ничего нового не создают и не исправляют задним числом без отдельного правила.
• Закрытая система. Доступ отключён, данные сохранены по требованиям компании и закона, путь восстановления известен ответственным.

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

Пять проверок перед отключением

1. В новой системе прошёл полный обычный цикл. Не отдельный импорт и не демонстрация. Нужна живая операция: от первого ввода до результата, который видит следующий участник процесса. Для разных компаний это может быть заказ, заявка, производство, договор или обращение клиента.

2. Разобрано хотя бы одно реальное исключение. Что происходит, если заказ отменили, документ вернули на доработку, данные пришли дважды или сотрудник ошибся в обязательном поле? Если на этот вопрос отвечают «потом разберёмся», старая система быстро станет запасным выходом.

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

4. Сотрудники знают новый маршрут. Инструкция на 80 страниц редко помогает в напряжённый день. Лучше короткая памятка по ролям: что теперь делаю я, куда смотрю при ошибке, кому пишу, если правило не работает. Первые дни после запуска особенно важны: привычка формируется быстрее, чем хороший регламент.

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

Не измеряйте готовность количеством перенесённых строк

Миграция может завершиться со статусом 100%, но переход всё равно не состояться. Перенесённая база — это библиотека; рабочая система — это привычка принимать решения по её данным. Между этими вещами есть дистанция.

Проверяйте не только количество записей, но и несколько конкретных ответов. Может ли руководитель найти актуальный статус? Может ли сотрудник исправить обычную ошибку по понятному правилу? Может ли следующий отдел начать работу без звонка тому, кто «знает, как было раньше»? Если хотя бы один ответ отрицательный, полезнее доработать маршрут, чем объявлять полное переключение.

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

Как провести сам день переключения

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

Перед переключением стоит договориться о четырёх простых вещах:

1. какие операции прекращаем принимать в старой системе и с какого момента;
2. какие цифры или списки сверяем до и после перехода;
3. куда сотрудник сообщает о проблеме и какой ответ получит;
4. кто вправе принять решение о временном откате.

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

Какие ошибки продлевают двойную работу

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

Третья ошибка — оставить у старой программы «временного» владельца без срока. Так появляется параллельная поддержка, которая постепенно съедает время команды и доверие к новому решению. Четвёртая — не объяснить, зачем меняется порядок. Сотрудник не обязан радоваться новой кнопке; он должен понимать, какую лишнюю работу или ошибку она убирает.

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

Что делать, если уверенности всё ещё нет

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

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

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

Короткий чек-лист

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

Отключение старой системы — не техническая церемония. Это момент, когда компания перестаёт жить на двух картах одновременно. Чем яснее правила, маршруты и ответственность до этого дня, тем меньше шансов, что новая система станет просто ещё одним окном на рабочем столе.