Вторая часть оставила вам список на одну страницу: критичные файлы, их ответственные, что от них зависит и есть ли у них резервные копии. Этот список говорит, что переносить. Эта часть говорит, что нельзя переносить как есть.

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

Почему очистка должна идти до переноса, а не после

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

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

Пять недостатков, которые есть почти в каждой таблице

Это не экзотические ошибки; это естественный результат инструмента, который разрешает всё. Большинство из них вы найдёте в собственном файле:

  • Один контрагент под несколькими именами. Один и тот же клиент встречается трижды: один раз под торговым названием, один раз под именем владельца и один раз в виде сокращения, набранного кем-то в спешке. В файле это соседние строки, понятные любому читателю. В системе они становятся тремя разными клиентами, у каждого свой остаток и своя история, так что карточка отношений распадается, и ни одна из трёх не даёт полной картины. Тот же недостаток касается номенклатуры и поставщиков.
  • Смешанные форматы дат. В одном столбце одна дата записана как день/месяц, другая как месяц/день, а третья — текстом, например после праздника или конец месяца. Пока столбец читают только люди, это проходит, но любая сортировка, расчёт срока или отчёт по времени на основе этого столбца уверенно выдаст неверный ответ, а это опаснее, чем видимая ошибка.
  • Числа, хранящиеся как текст. Сумма, введённая со значком валюты внутри ячейки, количество с единицей измерения в той же клетке или число, начинающееся с лишнего пробела. Глазу это кажется числом, а машине — нет, поэтому оно не суммируется, не сравнивается и не переносится; и обычно это обнаруживается в первом финансовом отчёте после переноса.
  • Столбцы, которые никто не может определить. Столбец под названием примечания, статус или temp, добавленный много лет назад для цели, которая давно исчезла, иногда заполненный, иногда пустой. Обычно он переезжает, потому что никто не решается его удалить, и попадает в систему как поле без определения и без ответственного, продолжая появляться на экранах и сбивать с толку тех, кто придёт после вас.
  • Цветные ячейки со смыслом. Самый опасный пункт списка. Жёлтый означает просрочено, красный — приостановлено, зелёный — оплачено. Это не форматирование, это данные, но данные, хранящиеся в цвете и в памяти того, кто его применил. При экспорте файла текст переносится, а цвет теряется, и вы лишаетесь информации, по которой ежедневно вели бизнес, без единого предупреждения.

Единственное правило: любой смысл вне ячейки должен стать полем

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

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

Взгляд Origami

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

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

Практический порядок очистки

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

  • Начните с основных данных, а не с операций. Клиенты, номенклатура и поставщики — короткие списки, которые используются снова и снова, и их очистка автоматически исправляет тысячи строк, которые позже будут к ним привязаны. Счета и заказы идут потом.
  • Введите один идентификатор на сущность. Постоянный код или номер, который никогда не меняется и никогда не используется повторно; затем сопоставьте с ним каждое старое название и сокращение. Особенно для клиентов точные юридические реквизиты покупателя — не прихоть, поскольку требования к электронным счетам Управления по закяту, налогам и таможне (ZATCA) определяют, что должен содержать налоговый счёт; связь между движением и его счётом мы описали в статье электронные счета на заводе и складе.
  • Разделите каждую составную ячейку. Количество в одном столбце, единица измерения в другом; сумма в одном, валюта в другом; имя в одном, номер мобильного в другом. Правило: одна клетка для одного сведения.
  • Унифицируйте форматы до любого импорта. Один формат даты во всём файле, числа без символов внутри ячейки и единый формат номеров мобильных телефонов. Работа однообразная и скучная, но делается один раз.
  • Записывайте решения по очистке на отдельном листе. Что с чем объединили, что удалили и что остаётся под сомнением. Когда через два месяца кто-то спросит, куда делся конкретный клиент, ответом будет этот лист; без него команда теряет доверие ко всему переносу.
  • Не удаляйте оригинал. Сохраните файл до очистки как закрытую копию только для чтения. Очистка требует суждений, а суждениям нужна точка отсчёта, к которой можно вернуться.

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

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

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

Источники