Аналитика без очереди в IT: что показывает кейс Datacor

Datacor разрабатывает софт для дистрибьюторов технических газов.

Компания рассказала в блоге AWS, как дала клиентам своего продукта TrackAbout самостоятельную аналитику по аренде на Amazon Quick Sight.

Основную работу в проекте сделали до появления дашборда: данные об активах собрали из разрозненных систем в одну модель.

Без такой модели любой BI-инструмент отвечает на вопрос директора с той же скоростью, что и аналитик, у которого этот запрос стоит в очереди.

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

Баллон уезжает к клиенту, и с этого дня по нему начисляется аренда.

Если баллон месяцами стоит пустым на складе клиента, а счёт по нему не выставлен, компания теряет деньги, и ни одна система не сообщает об ошибке.

Чтобы управлять таким парком, владельцу нужны ответы на три вопроса.

Какая доля парка реально работает у клиентов?

Где фактическая ставка ниже прайса и почему?

Сколько начисленной аренды компания так и не собрала?

По словам Datacor, до проекта данные для этих ответов лежали в несвязанных системах, а получить их можно было только через IT. Отчёты, которые IT успевало собрать, давали ограниченную картину по утилизации парка, соблюдению ставок и возврату выручки.

Типовой сценарий: компания покупает BI-лицензию и сразу строит дашборды поверх сырых выгрузок.

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

Вторая типовая ошибка - интеграции «точка-точка».

Каждая система выгружает данные в BI своим скриптом.

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

Третья ошибка пришла вместе с генеративным AI.

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

е меняется поле, падает один коннектор с понятной ошибкой, а отчёты продолжают работать на последних корректных данных.

Поверх модели мы фиксируем словарь метрик: формулы, владельцев, допустимые значения. Словарь нужен и людям, и AI.

Когда мы добавляем вопросы на естественном языке, модель (GigaChat, YandexGPT или Claude - в зависимости от требований к контуру) получает определения метрик через RAG и через MCP читает только подготовленные витрины. К сырым таблицам у неё доступа нет.

Все запросы проходят через LLM & Security Gateway, поэтому видно, кто что спросил и какие данные ушли в модель. В такой архитектуре AI-ассистент для аналитики - последний и относительно дешёвый шаг.

Основной объём работы приходится на модель данных и словарь метрик.