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

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

Почему перенос одним махом не работает

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

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

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

В-третьих, он не оставляет пути назад. Если через два дня всплывает фундаментальный изъян, остаётся лишь продавливать дальше или полностью откатываться, и оба варианта дорогие. Поэтапный перенос всегда оставляет часть бизнеса на твёрдой почве. Это одна из закономерностей, которые повторяются в застопорившихся проектах внедрения систем: виноват редко инструмент, а обычно попытка изменить всё в один день.

Справочные данные раньше транзакционных: правило, на котором держится вся последовательность

Ваши данные бывают двух видов. Справочные данные: клиенты, поставщики, товары или услуги, сотрудники, план счетов. И транзакционные данные: счета, заказы, заказы на закупку, движения запасов, поступления оплат.

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

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

На практике порядок такой:

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

Исторический архив: вопрос, который экономит недели

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

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

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

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

Параллельная работа: необходима, но опасна, если оставить её открытой

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

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

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

Взгляд Origami

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

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

Сигнал, который говорит, что переход удался

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

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

В следующих частях

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

Источники