Я начинаю порядок в данных с вопроса: одинаково ли компания понимает одно слово

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

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

Данные ломаются раньше, чем появляется ошибка

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

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

Справочник — это договорённость, а не техническая таблица

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

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

Нужен не главный сервер, а главный смысл

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

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

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

Как начать без месячного совещания

1. Выберите один объект, вокруг которого сейчас больше всего ручных уточнений.
2. Соберите по одному человеку от тех ролей, которые его создают, меняют и используют.
3. Спросите: что это такое, когда оно появляется, какие у него состояния и кто вправе их менять.
4. Зафиксируйте не только идеальную схему, но и спорные места.
5. Проверьте правило на трёх живых примерах, включая отмену или исправление.

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

Не прячьте разногласие в поле «комментарий»

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

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

Признак хорошего результата

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

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