Когда организация решает заменить информационную систему, первым делом спрашивают про данные. Перенесутся ли. Не потеряются ли. Сойдётся ли всё после переноса.

Это разумный вопрос. И он же — самый удобный способ не задать другой.
Данные видно. Их можно посчитать, выгрузить, сверить, подписать акт. С данными спокойно: они либо есть, либо нет.

Сложнее с тем, что не выгружается.

За пятнадцать-двадцать лет в систему врастает не только информация. В неё врастает способ работы. Кто что проверяет, прежде чем пропустить документ дальше. Когда процесс нельзя закрыть. Почему один статус блокирует другое действие. Какое исключение обрабатывается не по регламенту, а по памяти.

Ничего из этого не лежит в таблицах. Это лежит в том, как таблицы связаны между собой.

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

Её нет целиком ни в одной голове. Каждый сотрудник держит свой кусок и обычно не догадывается, что держит. Регистратор знает, что вот этот документ нельзя проводить, пока не пришёл ответ из смежного подразделения, — но не считает это знанием. Для него это просто «как надо».

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

Обычно в организации есть несколько человек, которые «знают, как всё устроено». На них держится больше, чем кажется, и держится тихо — пока они на месте. Миграция — ровно тот момент, когда их знание нужно сильнее всего, а удержать их труднее всего: переход выматывает, и часть из них уходит именно тогда. Вместе с ними уходит то, что они так и не успели никому передать, потому что не считали это знанием.

Тяжёлой, некрасивой, унаследованной. Рядом с ней новая выглядит очевидным шагом вперёд: чистый интерфейс, понятные модули, современный стек.

Но возраст системы говорит не только об отсталости. Он говорит и о том, что эта система пережила. Сколько решений через неё прошло. Сколько раз её достраивали под реальный процесс, а не под придуманный.

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

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

И ломается не всё сразу. Часть связей рвётся тихо и проявляется недели спустя: отчёт, который собирался из трёх систем, перестал сходиться; выгрузка, которую никто не запускал руками, потому что она шла сама; обмен, о котором знал один человек, а он в отпуске. На приёмке всё было в порядке — просто в тот день именно этот сценарий не запускали.

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

Технически миграция может пройти безупречно. Все записи на месте, справочники сошлись, акт подписан. А организация при этом начинает работать хуже: медленнее, с большим числом ручных операций, с тихим возвратом в Excel и переписку. Не потому что потеряли данные. Потому что потеряли логику, которая делала эти данные работой.

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

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

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

Не то, что он числится в возможностях новой системы. И не то, что его в принципе можно выполнить. Процесс сохранён только если он реально выполняется — за прежнее время, прежними силами, без того, чтобы половина работы переехала в Excel, почту и звонки в обход. Если то же действие теперь требует трёх лишних шагов и одного человека сверху — процесс не сохранён. Он деградировал, просто это не записано ни в одном акте.

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

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

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

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

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

В обычном продукте цена ошибки невелика: что-то сломалось — откатили, поправили, выкатили заново. В критической системе так не выходит. Нельзя на неделю «откатить» приёмное отделение или начисление выплат, чтобы посмотреть, как было раньше. Решения здесь часто без кнопки «отменить» — и именно поэтому их стоит проверять до, а не после.

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

Поэтому взрослый разговор о миграции начинается не с вопроса «что мы перенесём», а с вопроса, который звучит почти неприлично прямо: что мы не имеем права потерять — и откуда мы знаем, что мы это знаем?

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

Доказать, что логика выжила, нельзя на красивом экране. Можно — на трудном случае. Не «заведите запись и проведите документ», а: вот пациент с нестандартным маршрутом, вот данные с ошибкой из смежной системы, вот случай, который надо восстановить на дату двухлетней давности. Проходит — хорошо. Спотыкается — вы увидели это до, а не после.

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

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

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