Фундамент данных до ИИ: исправления, которые окупаются за два квартала

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

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

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

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

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

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

Стандартные ресурсы Google Analytics 4 по умолчанию хранят данные на уровне пользователей и событий 2 месяца, а максимум 14 месяцев; более длительное хранение данных о событиях доступно только в платной версии 360. Стандартные отчёты строятся на агрегированных таблицах и продолжают показывать старые итоги, поэтому потеря остаётся незаметной, пока кто-нибудь не построит сравнение год к году или воронку в разделе исследований и не обнаружит, что более ранний период пуст. Увеличение срока хранения в настройках защищает только те данные, которые ещё не удалены.

Надёжное решение заключается в экспорте в BigQuery, который копирует исходные события в хранилище, принадлежащее компании. Стандартные ресурсы могут передавать до 1 млн событий в день через ежедневный экспорт. У потокового экспорта нет ограничения по объёму, и он стоит $0,05 за гигабайт, что, по оценке Google, соответствует примерно 600 000 событий. При таких тарифах счёт за хранение для компании среднего размера невелик по сравнению с ценой планирования пикового сезона без поведенческих данных за прошлый год.

У этого исправления есть встроенный срок. Каждый месяц ожидания означает месяц истории событий, которую уже не восстановить, а для цикла планирования 2027 года понадобится полная картина пикового сезона 2026 года.

Электронное выставление счетов превращает справочник клиентов в вопрос соблюдения требований. В Германии компании, оборот которых за предыдущий год превысил 800 000 €, с 1 января 2027 года должны выставлять внутренние счета между компаниями (B2B) в структурированном электронном формате, а все остальные компании последуют за ними с 1 января 2028 года; принимать такие счета обязательно с 1 января 2025 года. В Великобритании правительство объявило, что с апреля 2029 года все счета с НДС должны будут выставляться в электронном виде, подтвердило Peppol в качестве сети обмена и сообщило, что подробная дорожная карта внедрения будет представлена вместе с Бюджетом 2026 года, который ожидается 28 октября.

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

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

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

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

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

До конца ноября установите срок хранения событий в GA4 на 14 месяцев для каждого ресурса и свяжите каждый ресурс с BigQuery, чтобы пиковый сезон 2026 года сохранился полностью.

К концу декабря проведите проверки уникальности и полноты идентификаторов клиентов, товаров и заказов во всех системах и устраните дублирующиеся коды товаров до того, как на них будет опираться какая-либо функция ИИ или торговый каталог.

Для любого немецкого юридического лица до 1 января 2027 года подтвердите, превышает ли оно порог в 800 000 € и готовы ли его счета и справочник клиентов, а подготовку к британскому требованию планируйте на той же модели данных, как только будет опубликована дорожная карта.

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

К июню 2027 года выберите первый сценарий применения ИИ на основе сверенных данных и измерьте его исходный уровень по тем же записям.