Компаниям перед внедрением панели, RAG, AI-агента или сквозной автоматизации.
Данные до технологии
Аудит готовности данных и интеграций
Проверяю, можно ли строить панель, RAG, ИИ-агента или автоматизацию на текущих источниках: качество, идентификаторы, владельцы, права, обновление и интеграционные разрывы.
В интересах собственникаАртефакты остаются у компанииБез неподтверждённых обещаний
Короткий вход
Выберите задачу и оставьте один удобный контакт
Без загрузки документов, реквизитов компании и длинного брифа. Подробности, доступы и критерии проекта согласуем только после первичного ответа. Срок и точный объём подтверждаются после проверки исходного контура, а не обещаются до обследования.
Разбор решения
Как обнаружить потери данных до построения отчёта
Учебный пример: в CRM 100 закрытых заказов. Для 82 найдена однозначная связь с учётной системой, для 8 — несколько кандидатов, для 10 — ни одного. Красивый отчёт по 82 заказам ещё не описывает весь портфель.
Сохраните записи, которые не удалось связать
Обычное соединение таблиц по совпавшему ключу может незаметно убрать 18 заказов. Отчёт должен сохранять исходные 100, а неоднозначные и отсутствующие связи показывать отдельными категориями. Сначала проверьте формат идентификаторов, область их уникальности и период выгрузки. Совпадение названия клиента само по себе не подтверждает связь заказа и оплаты.
Проверьте связь один ко многим
Несколько платежей по одному заказу — не обязательно дубль. Нужно определить, как учитывать частичную оплату, возврат и один платёж на несколько заказов. После соединения сверяют не только число строк, но и контрольные суммы: размножение заказа на строки платежей может завысить выручку. Формулу и правила распределения утверждает владелец показателя.
Разделите готовность для поиска и для управленческого вывода
Источник может подходить для поиска отдельной карточки, но быть непригодным для вывода о доле оплаченных заказов. В примере покрытие однозначной связи — 82%, а качество остальных 18% неизвестно; это не «готовность данных на 82%» для любой задачи. Для разрешения блокера назначают владельца ключа, реестр исключений и повторную сверку на той же дате среза.
Опишите идентичность и время отдельно
Зафиксируйте ID операции, время события, время выгрузки и версию исправления. Владелец показателя определяет, пересчитывается ли прошлый период. До этого нельзя молча прибавлять исправленную запись как новую операцию.
Пример записи в реестре качества данных
Учебный образец. Перенесите структуру в рабочий документ и замените исходные условия своими.
- Контроль
- Заказы CRM → документы учёта, одинаковая дата среза, исходная совокупность 100.
- Результат
- 82 однозначных, 8 неоднозначных, 10 без связи; исключения не удаляются из знаменателя.
- Блокируемый вывод
- Доля оплаченных заказов по всему портфелю до разбора 18 исключений.
- Повторная проверка
- Владелец справочника исправляет ключи; аналитик сверяет количество заказов, суммы и частичные оплаты.
Контракт обновления: что делать с запоздавшей записью
Учебная выгрузка заказов поступает ежедневно. Сумма сходится сегодня, но завтра источник может передать исправление за вчера. Проверка одной выгрузки ещё не доказывает устойчивость обновления. Результат аудита — проверенный договор обновления с владельцем, контрольными суммами и поведением при пропуске. Красивый отчёт по одной дате этого договора не заменяет.
| Проверка | Наблюдение в учебном примере | Решение и доказательство |
|---|---|---|
| Повтор выгрузки | Та же операция и версия пришли повторно. | Контрольная сумма результата не меняется; повтор отмечен. |
| Исправление | Тот же ID имеет принятую более позднюю версию. | Заменить вклад по согласованному правилу, сохранить историю основания. |
| Запоздавшая операция | В новом файле событие прошлого периода. | Отдельно показать пересчёт периода и причину изменения. |
| Неполная поставка | Отсутствует часть ожидаемых файлов. | Срез помечен неполным; отсутствие строки не становится нулевым оборотом. |
Практический разбор
Пример карточки готовности данных: сделки и оплаты
Учебная задача — ответить, какие закрытые сделки оплачены. Здесь наличие выгрузок ещё не означает готовность: нужно определить смысл статусов, устойчивое сопоставление и работу с частичной оплатой.
| Проверяемое свойство | Контрольная выборка | Решение по результату |
|---|---|---|
| Определение показателя | Сделка закрыта, но платёж частичный или возвращён. Зафиксировать дату среза и правила расчёта. | Владелец финансового показателя согласует формулу; модель не выбирает определение сама. |
| Связь систем | Одна оплата на несколько заказов, несколько оплат на заказ, разные названия клиента. | Нужны ключи и правила распределения. Неразрешённые связи идут в отдельный реестр исключений. |
| Полнота | Сравнить число записей и контрольные суммы источника с выгрузкой за один период. | Пропуски измерены и объяснены. При неполной выгрузке вывод по всему портфелю не принимается. |
| Свежесть | Платёж появился после обновления витрины. Проверить время события и время загрузки. | В отчёте видна дата актуальности; просроченный источник помечается, а не маскируется уверенным ответом. |
| Доступ | Пользователь одного подразделения запрашивает сделки другого. | Применяются права источника; контрольная проверка не раскрывает чужие суммы и карточки. |
По каждому свойству фиксируются число проверенных записей, исключения, владелец исправления и повторная проверка. Универсальная оценка «данные готовы на 80%» не заменяет решения по конкретным блокерам.
Пример не содержит реальных данных компании и не задаёт универсальный допустимый процент ошибок. Выборка, пороги и цена исключения определяются для целевого решения.
Коротко
Что решает этот формат
Аудит данных отвечает не на вопрос «есть ли у компании база», а на вопрос «можно ли по этим данным принимать и проверять решение». Проверяются происхождение, определения, идентификаторы, полнота, частота обновления, владельцы и права. Результат показывает, какие сценарии можно тестировать сейчас, что требует подготовки и где интеграция лишь ускорит несогласованность.
Кому подходит
Когда работа имеет практический смысл
Руководителям, у которых 1С, CRM, Excel и BI показывают разные версии результата.
IT-командам перед интеграцией нескольких систем и переносом данных.
Собственникам, которым нужно понять реальную стоимость подготовки AI-проекта.
Когда формат не подходит
- если нужен только технический экспорт одной таблицы
- если нет владельца бизнес-определений показателей
- если компания ожидает автоматически исправить данные без изменения процессов ввода
Исходная проблема
Что обычно мешает получить управляемый результат
Одинаковые сущности имеют разные идентификаторы и не сопоставляются между системами.
Показатель имеет несколько формул, а выбор версии зависит от автора отчёта.
Данные обновляются без владельца, журналов и контроля пропусков.
Что входит в работу
Конкретные действия и проверяемые результаты
Инвентаризация
Фиксирую источники, сущности, владельцев, способы доступа, частоту и критичность.
Профилирование качества
Проверяю полноту, уникальность, форматы, идентификаторы, дубли и типичные исключения.
Маршрут данных
Показываю, где данные появляются, изменяются, агрегируются и теряют контекст.
План готовности
Разделяю обязательные исправления, допустимые ограничения и подготовку к конкретному сценарию.
Матрица решения
Как выбирается глубина работы
| Ситуация | Что проверяем | Решение |
|---|---|---|
| Нужен дашборд | Определения KPI, период, источник и сверка | Словарь показателей и data pipeline |
| Нужен RAG | Версии документов, доступ, структура и актуальность | Реестр источников и правила индексации |
| Нужен AI-агент | Контекст, права, идентификаторы и запись результата | Контракт данных и действий |
| Нужна интеграция | Владельцы, API, частота, ошибки и повторная доставка | Интеграционная схема и журнал |
Порядок работы
От вопроса до принятого результата
- 01
Целевой вопрос
Определяем, какое решение должны поддерживать данные и как будет проверяться ответ.
- 02
Карта источников
Собираем системы, сущности, доступы, владельцев и маршруты изменения.
- 03
Контрольная выборка
Проверяем реальные и сложные случаи, расхождения и пропуски.
- 04
План подготовки
Фиксируем блокеры, быстрые исправления, архитектуру и следующий тест.
Реалистичные ожидания
Первый контур ограничивается одной задачей и ключевыми источниками. Срок расширяется, если требуется восстановить определения, владельцев или интеграционные зависимости между подразделениями.
Как формируется оценка
Стоимость зависит от числа систем, сущностей, способов доступа и глубины профилирования. До начала фиксируется контрольная выборка и вопрос, относительно которого данные признаются готовыми или неготовыми.
Результат
Что остаётся у клиента
Материалы можно проверить, использовать внутри компании или передать другой команде.
- реестр источников и владельцев
- карта ключевых сущностей и идентификаторов
- профиль качества и исключений
- схема обмена и точек контроля
- матрица прав и чувствительности
- план подготовки под выбранный сценарий
Типовая ситуация
Как выглядит задача на практике
Компания хочет корпоративного помощника и панель собственника, но документы лежат в нескольких папках, а сделки и оплаты нельзя устойчиво сопоставить. Аудит отделяет две задачи, показывает общие источники и формирует минимальный план данных без преждевременной закупки платформ.
Границы ответственности
- Аудит не очищает весь исторический массив автоматически.
- Качество оценивается относительно конкретной задачи.
- Доступ к production согласуется отдельно и не всегда необходим.
- Персональные данные используются только в минимально необходимом объёме.
FAQ
Вопросы до старта
Нужно ли давать доступ ко всем системам?
Нет. Начать можно с описания, обезличенных выгрузок и контрольной выборки. Прямой доступ требуется только если без него нельзя проверить критичное свойство.
Что значит «данные готовы»?
Это значит, что для выбранной задачи известны источник, определение, владелец, права, частота, допустимые пропуски и способ проверить результат. Готовность всегда контекстна.
Аудит включает интеграцию?
Нет. Он формирует требования и план. Настройка API, очередей, преобразований и мониторинга относится к следующему этапу.
Можно проверить только документы для RAG?
Да. В этом случае фокус смещается на версии, структуру, метаданные, права, актуальность и вопросы, на которые документы должны отвечать.
Что делать с плохими историческими данными?
Определить, какая история действительно нужна, выделить критичные поля и правила исправления, а затем изменить процесс появления новых данных. Полная очистка без цели редко оправдана.
Следующий шаг
Начнём с одной проблемы и критерия результата
Документы на первом шаге не нужны. Если формат не подходит задаче, это будет зафиксировано до начала работ.