При поэтапной модернизации выбирают конкретный участок для обновления. Сначала выясняют, какие части можно менять отдельно, какие связаны между собой и что необходимо сохранить.
Разберите, что действительно используется
Инвентаризация начинается с функций и данных. Какие операции выполняются каждый день? Какие отчёты нужны в конце периода? Кто работает в системе, какие права ему необходимы и с какими другими программами идёт обмен?
Важно увидеть не только экраны, но и действия вокруг них. Например, сотрудник может выгружать таблицу, исправлять её вручную и загружать обратно. Если этот шаг не учесть, новая версия формально повторит интерфейс, но не сохранит рабочий процесс.
Для данных описывают состав и связи: что используется сейчас, какая история нужна, где находятся документы. Выясняют, кто предоставляет доступ и подтверждает правильность переноса.
Выберите границу первого изменения
Условный пример: компания принимает заявки в старом кабинете, а подтверждение заказа и расчёты ведёт в учётной системе. Первым этапом можно рассмотреть обновление подачи заявки, оставив расчётную часть на прежнем месте. Границы проверяют по фактическим связям.
Для выбранного модуля нужно описать начало и конец процесса: какие данные он получает, что изменяет и кому передаёт результат. Если старые и новые части работают одновременно, отдельно определяют, где сотрудник меняет каждое значение и как изменение попадает в другую часть.
Если участок нельзя отделить без переделки связанных функций, объём пересматривают до начала работ.
Проведите тестовый перенос
Сначала выполняют тестовый перенос на отдельной копии с ограниченным доступом, по возможности используя обезличенные данные.
Сверяют не только количество строк. Проверяют связи записей, статусы, даты, суммы, вложения и исключения. Например, заказ может быть частично выполнен или отменён; такие состояния тоже должны корректно отображаться после переноса.
Затем ответственный сотрудник проходит согласованные сценарии: находит старый заказ, создаёт новый, меняет допустимые сведения, получает нужный отчёт. Совпадение общей суммы не заменяет проверки отдельных операций.
Заранее договоритесь о переключении и возврате
В плане перехода фиксируют последовательность действий, ответственных и условия, при которых новая часть начинает обслуживать рабочие операции. Также определяют, когда прекращаются изменения в старой системе и как переносятся сведения, появившиеся после тестовой копии.
Допустимый простой согласуется для конкретного проекта. Иногда возможна параллельная работа отдельных частей, иногда потребуется окно остановки. Нулевой простой нельзя обещать до проверки архитектуры, данных и ограничений внешних систем.
План отката должен учитывать не только резервную копию, но и новые операции после переключения. Заранее определяют, как сохранить их при возврате и кто принимает решение. Иначе без учёта могут остаться уже принятые заказы.
Принимайте этап по рабочему результату
В предложении связывают результат этапа, состав работ, оценку и границы ответственности. Приёмка включает сверку данных и пользовательских сценариев. Согласуют передачу кода, результатов проверок и инструкций, поддержку и регулярные расходы на инфраструктуру и лицензии.
Возможная польза — меньше повторных действий, уточнений или задержек в выбранном процессе. Её проверяют сравнением до и после, а не объявляют достигнутой в момент запуска. Если изменение не решает исходную задачу, важно разобраться в причине, прежде чем расширять модернизацию.
Обновление можно начать с одного участка, не заказывая замену всей системы заранее. Принцип АИС Сокол: «До результата — без доплат за наши ошибки». Новые требования к объёму согласуем отдельно.
Расскажите, какой процесс нужно улучшить и какие данные и действия обязательно сохранить. На первом разговоре определим, что требуется выяснить для оценки этого этапа.
