Инвентаризация данных для ИИ: как оценить готовность компании

Зачем вообще нужна оценка готовности данных под ИИ

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

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

Без карты данных ИИ-команда часто начинает с интеграций наугад. Подключили CRM, потом вспомнили про 1С, добавили выгрузки из Excel, а позже выяснилось, что идентификаторы клиентов везде разные. В итоге строится не ИИ, а набор временных мостиков между системами. Это дорого и почти всегда заканчивается тем, что пилот не получается довести до устойчивого режима.

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

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

• выбрать 1-2 use case, которые опираются на доступные данные, а не на «мечту»
• понять, какие источники критичны и где нужна интеграция, а где достаточно регулярной выгрузки
• назначить владельцев данных и согласовать правила доступа, чтобы не застрять на согласованиях
• определить, какие наборы требуют очистки и стандартизации в первую очередь
• заранее отсечь идеи, где данные юридически недоступны или слишком нестабильны

Такой подход экономит месяцы. Вы начинаете с того, что реально можно сделать, и улучшаете данные под конкретные задачи, а не пытаетесь «улучшить все сразу».

Что подготовить перед стартом инвентаризации

Перед стартом важно договориться, зачем вы делаете инвентаризацию. Без цели вы получите толстую таблицу «про все», которая не помогает выбрать use case и тянет за собой бесконечные интеграции.

Сформулируйте цель одним предложением. Чаще всего это одно из трех:

• выбрать 1-2 use case для пилота
• оценить объем интеграций и трудозатрат
• быстро понять качество данных в ключевых системах

Если целей несколько, задайте приоритеты: что нужно решить сейчас, а что можно отложить.

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

Третий шаг - назначить ответственных и «владельцев решения». ИТ поможет выгрузить данные и объяснит архитектуру, но бизнес должен объяснить смысл полей, правила и то, что считается ошибкой.

Обычно хватает трех ролей: владелец со стороны бизнеса (принимает решения по приоритетам), представитель ИТ (понимает системы и интеграции) и безопасность/комплаенс (ограничения по доступам и хранению). Если у компании есть требования по технологическому суверенитету и прозрачности цепочки поставок, безопасность лучше подключать с самого начала.

Наконец, выберите простой формат фиксации. На старте лучше всего работает один «живой» реестр (таблица или легкий каталог), который можно обновлять каждый день. Полезно вести и доску задач, чтобы видеть статус по источникам. Важно, чтобы формат позволял фиксировать минимум: источник, владельца, формат, частоту обновления, доступы и короткую оценку качества. Тогда на следующем шаге вы честно сопоставите данные с будущими use case.

Как связать будущие use case с конкретными данными

Инвентаризация данных для ИИ начинается не с таблиц, а с ясных задач. Иначе вы соберете «все данные компании», а затем выяснится, что для пилота не хватает пары ключевых полей или согласованного доступа.

Выберите 3-5 задач, где эффект понятен бизнесу и результат можно проверить за 1-2 месяца. Хороший признак - у задачи есть измеримый показатель: быстрее обработка, меньше ошибок, ниже простой, выше точность прогноза.

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

Простая схема привязки use case к данным

Для каждой задачи пройдите короткую цепочку:

• Решение: что должен делать ИИ (предсказывать, классифицировать, искать аномалии, подсказывать следующий шаг)
• Сущности: на каких объектах это делается (например, «заказ» и «отгрузка»)
• Признаки: какие поля нужны (даты, статусы, суммы, категории, параметры, география)
• Цель: что считается «правильным ответом» (например, факт просрочки или причина возврата)
• Проверка: как вы поймете, что стало лучше (метрика качества модели и бизнес-метрика)

Так быстро видно, какие данные критичны, а какие просто «хорошо бы иметь».

Что значит «достаточно данных» для пилота

Для пилота редко нужен идеальный сбор «в озеро». Обычно достаточно минимума: один главный источник «правды» по сущности (пусть даже через выгрузки), 3-10 ключевых полей, понятная целевая метка или правило разметки и период истории, где данные сопоставимы (например, 6-12 месяцев).

Пример: вы хотите предсказывать простои оборудования в цехе. Базовый минимум - журнал простоев (время, причина), данные о работе оборудования (наработка, режимы) и привязка к конкретной единице. «Желания» вроде погодных данных или закупочных цен разумнее отложить, пока пилот не покажет эффект.

Если вы работаете с интегратором, такая карта «задача -> сущности -> минимум данных» помогает сразу оценить объем интеграций и не распыляться. Это особенно важно, когда параллельно планируются инфраструктура и контуры данных.

Карта источников: где живут данные на самом деле

Карта источников - это список мест, где данные реально хранятся, а не где «по идее» они должны быть. Для ИИ это критично: модель можно обучить и запустить только на том, что вы сможете регулярно получать, обновлять и объяснять.

Начните с корпоративных систем. Обычно ключевые справочники и операции живут в ERP и CRM, бухгалтерии и платежных системах, сервис-деске. В отраслевых компаниях добавляются специализированные платформы: в медицине - EHR/EMR, в образовании - LMS. В реестре важно записать не только название системы, но и какие сущности там есть (клиенты, обращения, счета, назначения, оценки), и в каком виде их можно выгрузить.

Дальше идут «невидимые» источники, которые часто сильнее всего влияют на качество: Excel-файлы на общих дисках, сканы договоров, переписка в почте и мессенджерах, журналы, которые потом кто-то переносит вручную. Часто именно там находятся причины отказов, комментарии и уточнения. Без них данные из учетных систем выглядят «правильными», но остаются неполными.

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

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

Когда список собран, сделайте по каждому набору короткую пометку: где он дублируется и где находится «единственный источник правды». Например, клиент может быть и в CRM, и в бухгалтерии, но «истиной» для ИИН/БИН и реквизитов является бухгалтерия, а для истории контактов - CRM. Такая пометка снижает риск утонуть в интеграциях и спорить неделями, какие цифры считать правильными.

Владельцы данных, доступы и ограничения

Чтобы инвентаризация не превратилась в бесконечные согласования, заранее договоритесь о ролях и правилах. Иначе у вас будет карта источников, но не будет права взять данные, а значит пилот не запустится.

Практичный минимум - разделить три роли, которые часто путают:

• Владелец данных: отвечает за смысл, правила использования и кому данные можно показывать
• Хранитель (обычно ИТ): отвечает за систему, где данные лежат, и за техническую выдачу доступа
• Пользователь данных: команда, которая строит отчеты, модели или использует данные в процессе

Дальше зафиксируйте две точки ответственности: кто утверждает доступ и кто разрешает изменения. Утверждение доступа - это не только «дать логин», но и решить, можно ли копировать выгрузки, делать обезличивание, хранить датасет в отдельном контуре. Разрешение изменений важно потому, что ИИ быстро выявляет «ломающие» правки: переименовали поле, поменяли справочник, изменили частоту обновления - и модель начинает ошибаться.

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

Запишите текущий способ выдачи доступа, потому что он определяет скорость пилота. У одних это только готовые отчеты, у других - ручные выгрузки раз в неделю, у третьих - прямой доступ или API. Например, в больнице данные по обращениям могут быть доступны только как ежемесячный отчет, и тогда use case «прогноз загрузки на завтра» не взлетит без изменения процесса.

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

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

Форматы, обновления и связи между наборами данных

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

По форматам полезно сразу разделить «удобные» и «сложные». Таблицы (Excel, CSV, базы данных) и структурированные сообщения (например, JSON) обычно быстрее всего идут в пилот. Документы (PDF, сканы), изображения, аудио и видео почти всегда требуют распознавания или разметки, а значит времени и бюджета. Часто помогает простая пометка: «подходит для быстрого прототипа» или «нужна подготовка (OCR, классификация, разметка)».

Частота обновления влияет на выбор use case не меньше, чем формат. Зафиксируйте режим простыми словами: онлайн, каждый час, ежедневно, раз в неделю, раз в месяц, вручную по запросу. Если есть задержка (например, выгрузка появляется только на следующий день), это тоже стоит отметить.

Объем и рост помогают заранее не «утонуть» в инфраструктуре. Не нужны точные цифры. Обычно достаточно оценки: «10-20 ГБ в месяц», «около 2 млн строк», «пики в конце квартала», «сезонность в период приемной кампании».

Самое частое место, где ломаются интеграции, - связи между наборами. Для каждой ключевой сущности (клиент, сотрудник, устройство, договор, заявка) запишите, какой идентификатор есть в каждой системе и насколько он надежен. Если в одной базе это ИИН, а в другой - внутренний ID без соответствия, связка будет дорогой.

Проверьте себя коротким списком:

• есть ли единый идентификатор для клиента/контрагента (ИИН/БИН, номер договора, лицевой счет)
• одинаково ли заполнены даты, суммы, единицы измерения и валюты
• есть ли стабильные справочники (коды филиалов, статусы, номенклатура) или все пишут «как привыкли»
• где встречается свободный текст (комментарии, обращения, описания) и на каком языке он обычно
• есть ли «переименования» полей и кодировок между системами (например, разные коды регионов)

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

Быстрая оценка качества данных без сложной аналитики

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

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

Проверяйте на примерах, а не на ощущениях. Возьмите 50-200 строк из каждого источника и посмотрите, что происходит с ключевыми полями.

Мини-проверки, которые быстро находят проблемы

Быстрые сигналы обычно такие:

• пропуски в обязательных полях (ИИН/БИН, SKU, телефон, дата события)
• дубликаты клиентов или товаров, отличающиеся одной буквой
• странные значения (даты в будущем, отрицательные суммы, нереальные возраста)
• несогласованные справочники (один и тот же статус по-разному назван в разных системах)
• «скачки» обновления: процесс ежедневный, а данные появляются раз в месяц

Дальше полезно сравнить одно и то же поле в разных системах. Например, «адрес поставки» может отличаться в CRM и в логистике, а «категория товара» - в ERP и каталоге. Если расхождения частые, use case вроде персонализации или прогнозирования спроса будет давать спорные результаты, даже при хорошей модели.

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

Шкала качества и уровень риска

Чтобы сравнивать источники, заведите простую шкалу 1-5 по каждой метрике и общий риск (низкий/средний/высокий). Например, для данных из сервис-деска качество 4/5 и риск низкий, а для Excel-файлов от разных отделов качество 2/5 и риск высокий.

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

Пошаговый процесс: как провести инвентаризацию за 2-4 недели

Чтобы инвентаризация не растянулась на месяцы, задайте рамки: 2-4 недели, один владелец процесса, понятный шаблон карточки набора данных и один общий реестр. Цель на этом этапе - не идеальная документация, а ясность: какие данные доступны, в каком они состоянии и что будет сложно подключать.

Неделя 1: быстро собрать картину

Проведите короткие интервью (30-45 минут) и соберите то, что уже есть: регламенты, описания систем, реестры, схемы интеграций. Фиксируйте не только систему, но и владельца, который может дать доступ и объяснить смысл полей.

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

Неделя 2: заполнить карточки наборов и сделать мини-проверки

Для каждого приоритетного набора заполните карточку: что это за данные, ключевые поля, формат (таблица, файл, журнал), частота обновления, идентификаторы для связки с другими наборами. Не пытайтесь описать все сразу: лучше 10 наборов подробно, чем 100 названий без деталей.

Параллельно возьмите небольшую выборку и сделайте 3-5 проверок качества: доля пустых значений в ключевых полях, дубликаты по идентификатору, странные диапазоны (например, даты в будущем), несоответствие справочникам, резкие скачки по объему.

Неделя 3-4: оценить интеграции и выбрать пилоты

Отметьте, как данные можно получить: есть API, прямой доступ к БД, только ручные выгрузки или требуется согласование через безопасность. Это часто важнее, чем «идеальность» набора: хорошие данные бесполезны, если их можно получать раз в месяц в Excel.

Чтобы не утонуть в интеграциях, сведите итоги в короткий список решений:

• какие 1-2 use case реально запустить на данных, доступных сейчас
• какие источники критичны и что блокирует доступ
• где нужны быстрые исправления (справочники, обязательные поля, единые идентификаторы)
• кто делает исправления и в какие сроки
• какой способ регулярной загрузки будет первым (даже если это временная выгрузка)

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

Типичные ошибки, из-за которых тонут в интеграциях

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

Ошибка 1: считать, что данные «есть», если они «где-то в Excel»

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

Ошибка 2: не закрепить владельца и потом ждать доступ

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

Часто проблемы выглядят так: берут «все, что нашли», вместо минимального набора под конкретный сценарий; оценивают данные только по объему, игнорируя пропуски, дубли и разные справочники; путают отчетную витрину с первичными данными и теряют детали; не учитывают, что данные обновляются по-разному; сразу строят сложную интеграцию, хотя хватило бы выгрузки по расписанию.

Ошибка 3: пытаться интегрировать все сразу

Желание «сразу сделать правильно» приводит к попытке соединить ERP, CRM, учет, колл-центр и еще пару витрин одновременно. На практике лучше выбрать один use case, минимальный набор источников, доказать ценность и только потом расширять периметр.

Ошибка 4: надеяться, что модель «сама разберется» с качеством

Модель не исправит системные ошибки: разные единицы измерения, разъехавшиеся справочники, смешанные даты, пропуски в ключевых полях. Проверка на 100-200 строк часто показывает, что заметная часть данных требует чистки или уточнения бизнес-правил.

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

Чеклист и следующие шаги: от карты данных к пилоту ИИ

Когда карта готова, важно быстро понять, какие наборы реально пригодны для пилота, а какие сначала потребуют работы. Этот шаг превращает инвентаризацию из «таблицы ради таблицы» в план действий.

Короткий чеклист по каждому набору данных:

• Источник и границы: где данные живут и что входит в набор (период, подразделение, система)
• Владелец: кто отвечает за смысл и качество, кто подтверждает трактовку полей
• Доступы и ограничения: кто дает доступ, какие есть юридические или регуляторные запреты
• Формат и обновление: таблицы, файлы, логи; как часто обновляется и насколько стабилен формат
• Качество: пропуски, ошибки, дубликаты, единые справочники

Дальше сделайте простую матрицу готовности. Здесь не нужны споры о процентах: трех уровней достаточно, чтобы выбирать пилот и оценивать объем работ.

Правило выбора пилота: минимум интеграций, максимум ценности. Ищите use case, который опирается на 1-2 набора данных с «высоким» уровнем и понятными владельцами. Например, если вы хотите пилот по прогнозу потребности в запасных частях, но данные о ремонтах в одной системе, справочники в другой, и половина записей без кода изделия, это плохой первый проект. Логичнее стартовать там, где уже есть цельный набор: продажи и остатки в одном контуре или заявки в сервис-деске с понятными полями.

Следующие шаги до внедрения:

• зафиксировать 1-2 пилотных use case и метрику успеха (время, деньги, качество решения)
• оформить владельцев и правила доступа (кто утверждает, кто выдает, сроки, журналирование)
• починить критичные поля: справочники, единицы измерения, ключи для связей, правила заполнения
• согласовать минимальный контур интеграций и расписание обновления данных для пилота
• подготовить тестовый выгрузочный контур и краткое описание полей

Интегратора имеет смысл подключать, когда пилот уже выбран и понятно, какие системы трогаем и какие ограничения по доступам. Тогда проще оценить сроки, риски и нужную архитектуру. Об инфраструктуре (серверы, хранилище, GPU, контуры безопасности) стоит говорить сразу, если данные чувствительные, нужен on-premise или пилот планируется масштабировать.

Если нужен партнер, который закрывает и инфраструктуру, и интеграции, и поддержку, можно привлекать GSE.kz (gse.kz) как системного интегратора. У них есть опыт построения контуров данных и ИИ-инфраструктуры на базе собственных серверов и рабочих станций, а также круглосуточная техническая поддержка - это полезно, когда пилот упирается не в модель, а в доступы, безопасность и стабильную доставку данных.