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

Атрибутивный состав ≠ шаблон описания

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

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

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

Разница между атрибутивным составом и свободным описанием принципиальна. Свободное описание («мужчина сорока лет, высокий, с бородой») — это строка, понятная человеку, но бесполезная для машинной обработки, фильтрации и точного поиска. Структурированные данные, напротив, разбиты на отдельные атрибуты (фамилия, имя, дата рождения, рост) — как в паспорте гражданина. Именно такое представление делает справочник инструментом, а не архивом текстов.

Основные функции атрибутивного состава

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

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

Рассмотрим эволюцию полноты описания на примере кабеля.

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

Второй уровень — описание с частично выраженной структурой: здесь уже присутствует ГОСТ, но параметры все еще представлены одной сплошной строкой с перечислением.

Третий уровень — структурированное описание, в котором марка, количество жил, сечение и напряжение выделены в отдельные атрибуты. Только такой вариант позволяет системно валидировать объект: например, для сечения 2,5 кв.мм можно программно проверить, соответствует ли указанное напряжение допустимому диапазону согласно ГОСТу.

Рассмотрим другой пример. Шаблон описания класса «Автомобили легковые».

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

Распределение по типам данных (строка, число) позволяет системе применять специфические операторы сравнения и математические функции. Это дает возможность валидировать вводимые значения уже на этапе заполнения и строить корректные аналитические отчеты без ручной обработки данных.

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

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

Типовые ошибки проектирования атрибутивного состава в НСИ

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

1. Избыточность или недостаточность атрибутов. Первая крайность — шаблон, содержащий более 30 атрибутов. Такое случается, когда конечные пользователи включают в описание все параметры, которые встречали в паспортах изделий, нормативных документах и технических регламентах. Впоследствии фиксируются когнитивная перегрузка пользователя при вводе данных, появление смежных по смыслу полей (например, «диаметр фланца» и «присоединительный размер»), что ведет к путанице и некорректному заполнению. В итоге большая часть атрибутов остается пустой, а качество данных снижается. Вторая крайность — шаблон из двух-трех атрибутов, который по сути является не описанием объекта, а просто наименованием. Такой способ может быть применим для обобщенного учета, но для полноценного справочника он бесполезен: объект не идентифицируется, дубли множатся, а качественная аналитика становится невозможной.
2. Неполноописанные и неидентифицируемые записи. Со временем в справочнике неизбежно накапливаются записи разной степени детализации — это порождает неявные дубли, которые система не может сопоставить из-за разницы в объеме описания. Кроме того, появляются т.н. фантомы: записи, созданные под конкретную разовую потребность (например, для проведения одной закупки), по которым нет никаких данных. Такие записи не могут участвовать в аналитике и блокируют корректное сопоставление объектов.
3. Отсутствие маркировки обязательности заполнения. Если все атрибуты в шаблоне необязательны, качество данных предсказуемо падает. Один пользователь заполняет 15 полей, другой — только три. Система не может сопоставить такие записи между собой, и на выходе пользователь получает множество дублирующих позиций, которые формально отличаются только объемом описания, а по сути описывают один и тот же объект.
4. Отсутствие стандартизации. Классический пример — позиции с разными наименованиями одного и того же материала: «искусственная кожа», «экокожа», «полиуретановая кожа». Для пользователя это синонимы, а для реляционной базы — три разные сущности. В результате справочник увеличивается в объеме за счет умножения дублей.

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

Для каждого справочника это сочетание индивидуально: универсального решения для всех классов объектов не существует.

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

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

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

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

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

Эксперты SOFROS в своей практике применяют инструмент, который позволяет снять субъективность этого выбора, — матрицу обязательности. Ее суть заключается в том, что каждый потенциальный атрибут оценивается по тому, скольким бизнес-процессам и подразделениям он действительно нужен. Чем больше процессов опирается на конкретную характеристику, тем выше ее приоритет.

Рассмотрим пример с бумагой для оргтехники.

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

• нужен ли он для идентификации объекта?
• требуется ли он согласно нормативно-технической документации?
• востребован ли он хотя бы одним из физических подразделений?

Каждое совпадение дает один балл.

Возьмем атрибут «Формат (A4, А3, А5)». Он нужен всем трем подразделениям, фигурирует в НТД и критичен для идентификации объекта. Итого четыре балла — атрибут обязателен. Атрибут «Белизна» необходим для идентификации и указан в нормативных документах, но для операционной работы подразделениям не критичен. Два балла — опционально. Атрибут «Влажность» требуется только по НТД, подразделениям не нужен. Один балл — тоже опционально. Атрибут «Страна происхождения»: не фигурирует в НТД, не нужен подразделениям и не влияет на идентификацию. Ноль баллов — такой атрибут можно не включать в шаблон.

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

Как разработать адекватные шаблоны описаний: «шестишаговая методология SOFROS»

Прежде чем шаблон описания будет утвержден и перейдет в продуктивную среду, его необходимо оценить по нескольким критериям:

• Бизнес-ценность — решает ли атрибут конкретную задачу или останется мертвым грузом, который никто не будет заполнять.
• Заполняемость — можем ли мы физически получить эти данные: если требуется указать химический состав сплава, а поставщик в сертификате дает только марку стали, такой атрибут обречен стать «мертвым».
• Уникальность — гарантирует ли набор атрибутов однозначную идентификацию объекта.
• Минимализм — нет ли в шаблоне дублирующих и/или избыточных полей.
• Стандартизация — обеспечен ли единый формат заполнения, включая порядок слов в наименовании и согласованность описательных характеристик.

В экспертизе SOFROS сформирована «шестишаговая методология», которая позволяет проектировать атрибутивный состав системно, а не методом проб и ошибок.

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

Второй шаг — приоритизация атрибутов с применением матрицы обязательностей. Каждый потенциальный атрибут оценивается по тому, скольким бизнес-процессам и подразделениям он нужен.

Третий шаг — создание прототипа (MVP) шаблона. Специалисты разрабатывают базовую модель описания для класса объектов.

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

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

Шестой шаг — финальная калибровка модели и утверждение. После всех итераций шаблон фиксируется как эталонный и передается в эксплуатацию.

Формирование атрибутивного состава — это не административная задача по заполнению полей, а проектирование информационной модели справочника предприятия. Качество данных закладывается именно на этапе проектирования шаблона.

Если допущены ошибки в архитектуре атрибутов, никакие последующие процедуры очистки и MDM-алгоритмы не обеспечат достоверную аналитику и бесперебойную интеграцию. Интересны детали? Смотрите запись вебинара «Формирование атрибутивного состава в нормализации НСИ» на нашем канале RuTube и в ВК Видео.

Подпишитесь на нас в социальных сетях Telegram и ВКонтакте, чтобы не пропустить новые полезные материалы, а также специальные акции для участников мероприятий. Если у вас остались вопросы, вы можете обратиться к менеджерам SOFROS для консультации по телефону +7 (495) 825-16-15 или воспользоваться формой обратной связи на нашем сайте.

Развитием этого направления активно занимается и компания SOFROS: сервис SOFROS AI/ML в связке с обновлением 1C:MDM позволят сократить рутинные операции и исключить влияние человеческого фактора на процессы управления мастер-данными.

1С:MDM 2.5.13. Ключевые изменения

Первым значительным улучшением в новом релизе стало расширение домена МТР (материально-технические ресурсы). Добавлен новый элемент — справочник «Производители», который позволяет более детально описывать источники поступления товаров и материалов. Одновременно с этим была доработана система банковских счетов с добавлением поля кода страны, которое теперь автоматически подтягивается при заполнении реквизитов. Эти изменения могут показаться техническими деталями, но они создают необходимую основу для более сложных процессов интеграции и синхронизации данных между системами.

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

Управление процессами ETL. Развитие подсистемы

Одним из значимых достижений в развитии 1C:MDM стало создание подсистемы управления процессами ETL (Extract-Transform-Load). Эта подсистема позволяет строить автономные конвейеры обработки данных, которые самостоятельно извлекают информацию из внешних источников, преобразуют ее в требуемый формат и загружают в целевые системы. Ключевая особенность подхода заключается в том, что все это может быть реализовано практически без написания кода — через визуальный конструктор и пошаговые схемы.

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

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

Генеративный искусственный интеллект как инструмент нормализации

Интеграция генеративного искусственного интеллекта с 1C:MDM представлена через систему интеллектуальных ассистентов. Эти ассистенты настраиваются под специфические задачи нормализации и призваны сократить время работы экспертов по управлению мастер-данными. Традиционно очистка, проверка и сопоставление данных требуют часов работы высокопрофессиональных специалистов. Использование ИИ-ассистентов позволяет минимизировать ручные ошибки и освободить ресурсы команды для более стратегических задач.

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

Подсистема интеллектуальных ассистентов в 1C:MDM поддерживает подключение практически к любым языковым моделям — как облачным, так и развернутым в локальной среде. В новом релизе добавлена поддержка языковой модели «Алиса AI» от «Яндекс», а также реализованы новые шаблоны промптов. Система предоставляет инструменты RAG (Retrieval Augmented Generation), которые позволяют моделям искусственного интеллекта выполнять поиск по базам знаний и в интернете, даже если модель изначально не имела такой возможности, значительно повышая качество генерируемых ответов и рекомендаций.

Управление изменениями НСИ

Расширение управления изменениями НСИ (нормативно-справочной информации) представляет собой решение для организации совместной работы между различными конфигурациями 1С. Это расширение позволяет подключать базу 1C:MDM к другим решениям фирмы 1С и синхронизировать справочники между системами через механизм заявок на изменение.

В свежем релизе расширение получило поддержку новых сценариев интеграции. Была добавлена функция запрета на изменение справочников во внешних базах, что предотвращает конфликты при синхронизации. Введен режим запрета дублирующих элементов, который обеспечивает целостность данных при работе с несколькими источниками. Архитектурное улучшение заключается в том, что расширение теперь публикует собственный сервис интеграции и не требует публикации систем-подписчиков. Это означает, что достаточно один раз опубликовать сервис MDM, и затем можно подключить к нему любое количество внешних систем.

В качестве транспортного механизма для передачи данных между системами используется 1С:Шина — специализированное решение для асинхронного обмена сообщениями. Оно обеспечивает надежную доставку данных и позволяет системам работать независимо друг от друга, что критично для распределенных архитектур. Также компания SOFROS предлагает собственное решение для интеграции систем-подписчиков через DATAREON Platform.

Практический сценарий: нормализация НСИ с использованием ИИ-ассистентов и сервисов

Практическое применение всех этих инструментов можно продемонстрировать на примере сквозного процесса нормализации элементов справочника «Номенклатура». Сценарий начинается с того, что в «1C:ERP Управление предприятием» находятся элементы справочника номенклатуры, которые содержат неполную или неструктурированную информацию. Через расширения «Управления изменениями НСИ» и «Интеграция с 1С:Шина» (или «Интеграция с DATAREON Platform») эти элементы отправляются в 1C:MDM в виде заявок на изменение. Процесс формирования заявок проходит все стадии специально-настроенного ETL-процесса.

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

Весь процесс от отправки заявки до полной нормализации занимает в среднем две-три минуты, хотя время может варьироваться в зависимости от выбранных моделей искусственного интеллекта, количества характеристик в классе товара и объема обрабатываемых заявок. После завершения нормализации данные могут быть отправлены обратно в 1С:ERP через 1С:Шину или DATAREON Platform, где они автоматически обновляют данные справочника «Номенклатура».

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

SOFROS AI/ML — сервис, расширяющий возможности нормализации данных для 1C:MDM 2.5.13

Компания SOFROS развивает собственный сервис SOFROS AI/ML. SOFROS AI/ML предоставляет специализированные модели машинного обучения и бизнес-процессы для решения задач атрибутивной нормализации, извлечения данных, поиска семантически близких элементов и обогащения данных. Сервис реализован в виде расширения для 1C:MDM и cервера интеграции AI/ML и интегрирован с библиотеками искусственного интеллекта универсальными алгоритмами ETL-процессов и бизнес-процессами.

В основе сервиса лежит интеграционный сервер AI/ML, который реализует микросервисы для моделей машинного обучения и искусственного интеллекта, обеспечивает их оркестрацию и предоставляет API для взаимодействия с моделями.

Одним из инновационных дополнений стала реализация MCP-сервера, который предоставляет инструменты для построения различных бизнес-ассистентов и агентов. Этот сервер обеспечивает доступ к моделям, содержащимся в SOFROS AI/ML, и позволяет настраивать гибридные сценарии для агентских систем, систем аналитики данных и кодовых агентов.

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

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

От рутины к стратегии

Релиз 1C:MDM 2.5.13 в сочетании с сервисом SOFROS AI/ML представляет собой качественный скачок в подходе к управлению мастер-данными. Вместо того чтобы тратить часы на ручную очистку и нормализацию данных, бизнес теперь может построить автоматизированные конвейеры, которые работают 24/7 и постоянно улучшают качество информации. ИИ-ассистенты и модели машинного обучения берут на себя рутинные операции, позволяя специалистам сосредоточиться на стратегических задачах и исключительных случаях.

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

Интересны детали?

Смотрите запись вебинара «Новая функциональность 1C:MDM 2.5.13 и современные подходы в задачах нормализации данных» на наших площадках:

Rutube

VK Видео

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

Если у вас остались вопросы, вы можете обратиться к менеджерам SOFROS для консультации по телефону +7 (495) 825-16-15 или воспользоваться формой обратной связи на нашем сайте.

Организации нередко начинают борьбу с дублированием записей с применения простых алгоритмов, основанных на сравнении текстовых строк в предположении, что похожие строки соответствуют одной и той же сущности. Технически такой подход сводится к разбиению строк на подпоследовательности или токены, подсчёту числа совпадающих фрагментов и вычислению метрик сходства (расстояние Дамерау — Левенштейна, Джаро — Винклера, token ratio и аналогичных). Для каждой неканонической записи выбирается эталон с максимальным значением метрики. Однако подобные методы демонстрируют точность не выше 30–40 % ввиду низкой дискриминационной способности.

Рассмотрим конкретный пример: два прутка с обозначениями «ПК-РВХ» и «ПК-ПВХ» представляют собой различные единицы номенклатуры (круглого и квадратного сечения соответственно). Ошибочное отождествление таких позиций неизбежно приведёт к отгрузке некорректной номенклатуры и нарушению спецификации, что создаёт риски на производстве или в строительстве.

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

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

Сервис SOFROS AI/ML: открытое API для работы с моделями машинного обучения

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

Ни один метод не решает задачу самостоятельно. В связи с этим в сервисе нормализации SOFROS AI/ML применяется гибкое сочетание всех перечисленных подходов. Гибридный метод позволяет одновременно обрабатывать большое количество записей с высокой точностью.

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

В контексте MDM-системы (Master Data Management) интеллектуальный сервис встраивается в существующий контур и автоматически обрабатывает все входящие данные. Для сотрудников процесс остаётся привычным: они работают в основной системе, однако каждая запись проходит интеллектуальную обработку — приводится к единому корпоративному формату, извлекаются и нормализуются атрибуты, проверяются значения по справочным данным, осуществляется валидация и контроль логических связей. В итоге в MDM поступает корректная запись, которую эксперт только утверждает. Далее запись становится доступной для всех взаимосвязанных систем, использующих единый номенклатурный справочник.

Важно подчеркнуть: интеллектуальный сервис нормализации SOFROS AI/ML не заменяет MDM-систему, а расширяет её возможности, снимая рутинную нагрузку с экспертов и автоматизируя нормализацию, проверку и структурирование данных.

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

Модель семантического поиска: генерация с дополнительной выборкой

Модель семантического поиска решает задачу нечёткого и смыслового поиска с использованием алгоритмов больших языковых моделей (LLM). Она позволяет находить элементы, сходные по смыслу с исходным запросом (например, наименования НСИ, характеристики или значения характеристик), и ранжировать найденные результаты по степени релевантности.

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

Затем в работу включается BERT-энкодер — локально установленная языковая модель, осуществляющая векторизацию текста. Каждый текст преобразуется в вектор — набор чисел, отражающий его смысловое содержание. Если два текста близки по смыслу, их векторы располагаются рядом в векторном пространстве. Для оценки близости используется косинусная мера или скалярное произведение векторов.

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

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

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

На последнем этапе подключается специально обученная модель — реранкер. Первичный поиск по векторной базе может возвращать зашумлённые результаты: элементы могут быть близки по общему смыслу, но не всегда точно соответствовать запросу. Реранкер выполняет вторую ступень фильтрации. Он принимает пару «запрос — документ» и оценивает, насколько найденный документ действительно релевантен запросу, выдавая точную оценку вероятности в диапазоне от 0 до 1. Для этого используется специализированная языковая модель — кросс-энкодер, которая анализирует запрос и найденный документ совместно, что позволяет лучше улавливать тонкие смысловые различия.

Таким образом, модель объединяет несколько технологий: Sentence Transformers для построения смысловых векторов, FAISS для быстрого поиска по векторной базе, нейросетевой реранкер для точной сортировки результатов, а также многопоточность и механизмы кэширования (обычного и «горячего») для ускорения обработки. Такая архитектура позволяет использовать модель в качестве готового движка для систем «вопрос-ответ», поиска сходных сущностей, номенклатуры, характеристик, значений характеристик и других категорий элементов, где требуется быстрый и точный семантический поиск.

Модель контекстного поиска: вызов инструментов веб-поиска

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

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

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

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

Для неизвестных или неполных характеристик формируется запрос к LLM. Взаимодействие с языковой моделью выполняется через библиотеку Ollama. Модель получает системную инструкцию, описывающую формат работы и ожидаемый результат, а также вопрос пользователя или сформированный внутренний запрос. На основе этой информации LLM определяет нужные характеристики и возвращает структурированный ответ.

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

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

Затем полученная информация сохраняется в кэш. Это позволяет при повторных запросах к тем же товарам или характеристикам быстро возвращать уже найденные данные без повторного обращения к LLM и веб-поиску.

В итоге модель представляет собой связку локального кэша, большой языковой модели (через Ollama) и механизма вызова инструментов веб-поиска. Такая архитектура обеспечивает быстрое получение характеристик товаров, их дообогащение данными из интернета, выявление новых свойств и возврат результата в структурированном машиночитаемом виде.

Классификация персонально идентифицируемой информации (PII)

Классификация PII (Personally Identifiable Information) — это систематический процесс разделения персонально идентифицируемой информации на категории в зависимости от уровня чувствительности, критичности, потенциальных рисков для субъекта данных при компрометации, а также требуемых мер защиты. Такая классификация позволяет унифицировать подходы к обработке, хранению, доступу и уничтожению PII в соответствии с законодательством (например, GDPR, CCPA, Федеральный закон № 152-ФЗ) и политиками информационной безопасности организации.

Цели применения классификации PII

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

Интересны детали?
Смотрите запись вебинара на нашем канале:

Rutube

VK Видео

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

Так появился SOFROS OneView – программный продукт на базе DATAREON Platform, предназначенный для оптимизации мониторинга сообщений интеграционной платформы. Название выбрано не случайно: просмотр всей интересующей информации действительно доступен в одном окне.

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

Архитектурная автономность и отказоустойчивость как ответ на вызовы рынка

По мере эволюции ИТ-ландшафта любое предприятие, особенно если оно стремится к масштабированию, неизбежно сталкивается с фрагментацией данных мониторинга. Классический сценарий: вслед за развитием внутреннего контура появляется контур DMZ (демилитаризованной зоны) – для взаимодействия с внешними сервисами, который зачастую представляет собой второй независимый кластер DATAREON Platform. Параллельно растет плотность интеграционных потоков внутри адаптеров, что делает поиск инцидентов силами первой линии поддержки все более сложным. Специалистам приходится манипулировать множеством фильтров в разных вкладках браузера, упуская целостную картину проблемного обмена.

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

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

SOFROS OneView состоит из веб-приложения (с разделением на Frontend и Backend) и собственной аналитической базы данных ClickHouse, дополненной Redis и PostgreSQL для хранения пользователей и их ролевой модели.

Frontend отвечает за корректное отображение данных, а Backend взаимодействует с API «Центра мониторинга и администрирования» DATAREON Platform, реализуя оптимизированные процедуры сбора и чтения данных без оказания избыточной нагрузки на ядро платформы. Централизация достигается путем конфигурационного указания URL всех серверов целевых кластеров (или единого адреса промежуточного прокси) в конфигурационном файле продукта и созданием выделенной служебной учетной записи с ограниченными правами.

Высокая доступность данных мониторинга обеспечивается тем, что хранилище SOFROS OneView функционирует независимо от состояния контролируемых узлов. Даже при деградации или полной остановке работы DATAREON Platform исторические данные и логи, собранные до инцидента, остаются доступными для анализа. Безопасность доступа реализуется через гибридную модель: поддерживается интеграция с Active Directory с наследованием доменных политик сложности паролей и блокировок либо используются внутренние учетные записи продукта с настраиваемыми ролями.

Отдельно стоит отметить механизмы масштабирования, заложенные в конфигурацию модуля извлечения данных. Предусмотрена возможность настройки степени параллелизма для обеспечения оптимальной работы ПО с учетом характеристик оборудования, можно задать индивидуальные интервалы опроса для событий, тел сообщений, диагностики и логов. Также экспортер может быть ограничен конкретными нодами кластера – это позволит развернуть несколько экземпляров backend-части, направив каждый из них на свою группу узлов, что критически важно для масштабирования мониторинга в высоконагруженных ИТ-контурах.

В планах – расширение функционального охвата SOFROS OneView. Прорабатывается внедрение мониторинга доступности адаптеров, систем и сервисов, что позволит отслеживать состояние не только интеграционных потоков, но и самих компонентов ландшафта. Ведется разработка подсистемы нотификаций, благодаря которой пользователи смогут получать оповещения по проблемным обменам с гибко настраиваемыми правилами срабатывания. В части визуализации прорабатываются дашборды – настраиваемые графические панели для оперативного контроля ключевых метрик.

Данные под контролем: от хронологии событий до аналитики производительности

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

1. Первый, свернутый режим «по потоку», агрегирует разрозненные технические события в сквозной маршрут от источника до получателя. Перед специалистом не мелькают десятки записей, заслоняющих суть, – он сразу видит проблемный обмен и может мгновенно его локализовать.
2. Второй, детализированный режим, раскрывает полную хронологию: события со всех модулей выстраиваются в последовательную цепочку – от поступления сообщения на веб-адаптер или файловый адаптер, через обработку в сервисе процессов, до записи в целевую систему. Это позволяет оперативно идентифицировать, на каком именно шаге алгоритма произошел сбой: ошибка связи с СУБД, некорректная трансформация тела сообщения, пользовательское исключение, зафиксированное через Logger.Debug, и т.д.

Мониторинг охватывает не только события, но и логи. Система подтягивает как пользовательские данные (записи, оставленные разработчиком внутри конфигурации бизнес-процесса), так и системные логи с адаптеров – с указанием модуля, логгера и уровня логирования.

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

Отдельного внимания заслуживает хранение данных. Срок жизни тел задается индивидуально для каждого типа данных (TTL), и по его истечении записи автоматически удаляются самой базой данных, высвобождая дисковое пространство. Параллельно работает механизм архивирования: данные с настраиваемой глубиной (по умолчанию – один год в оперативном хранилище и до трех лет в архивных таблицах) ежедневно переносятся в сжатом виде в то или иное хранилище. Благодаря колоночной архитектуре ClickHouse средний коэффициент компрессии достигает 5-7 раз.

Помимо оперативного мониторинга, SOFROS OneView предоставляет инструменты для ретроспективного анализа. Так, раздел «Обзор статусов» позволяет оценить соотношение успешных, ошибочных и находящихся в обработке сообщений в разрезе источников и получателей. Модуль сбора сведений о производительности формирует метрики объема и средней скорости обработки данных, прошедших через платформу за произвольный интервал. Детализация по интервалам дает возможность выявить, какой именно обмен создает пиковую нагрузку на сервис обработки процессов. Все эти данные критически важны для сайтинга и принятия решений о наращивании мощностей или оптимизации интеграционных цепочек.

От миграции с SAP PI до сотен потоков в горной добыче: практическая проверка

Универсальность SOFROS OneView подтверждается разноплановыми проектами. Один из показательных примеров – импортозамещение мониторинга SAP PI. В рамках этого проекта зарубежное интеграционное решение полностью заменила DATAREON Platform, а SOFROS OneView, в свою очередь, обеспечил привычную для ИТ-команд заказчика глубину диагностики. Помимо базового замещения функционала, продукт был настроен под специфические запросы, например, минимизацию времени расследования инцидентов.

Другой пример – внедрение SOFROS OneView в крупной компании горноруднодобывающей отрасли. Здесь масштаб измерялся сотнями информационных систем и сотнями интеграционных потоков, обслуживающих непрерывное производство. Именно в таких условиях архитектурные решения SOFROS OneView раскрываются в полной мере. Механизм ограничения экспортера конкретными нодами позволяет распределить нагрузку по сбору данных в кластере, не создавая «бутылочного горлышка». Индивидуальные интервалы опроса для разных типов сущностей дают возможность гибко балансировать между актуальностью информации и оптимизацией ресурсов. Сквозная трассировка в едином окне избавляет первую линию поддержки от необходимости перекрестного анализа данных из разных модулей, а функция сравнения версий тел сообщений кратно ускоряет поиск первопричины сбоя.

Выводы

SOFROS OneView – это не просто альтернативный интерфейс мониторинга, а самостоятельный программный продукт, закрывающий критический разрыв между растущей сложностью интеграционных ландшафтов и возможностями их эксплуатации. Архитектурная независимость хранилища от контролируемых кластеров гарантирует доступность данных мониторинга именно в те моменты, когда они наиболее востребованы, – при расследовании инцидентов.

Централизованная агрегация событий, логов и тел сообщений в хронологическом порядке устраняет необходимость ручного сопоставления разрозненных сведений, делая первичную диагностику доступной специалистам без глубокого знания внутренней маршрутизации платформы. Гибкие механизмы масштабирования модуля извлечения данных, настраиваемые политики хранения и аналитический инструментарий на базе ClickHouse обеспечивают стабильную работу продукта в ИТ-контурах любого объема – от компактных инсталляций до распределенных систем с сотнями потоков данных.

Регистрация в реестре отечественного ПО и подтвержденная практикой способность замещать мониторинг зарубежных решений делают SOFROS OneView стратегическим элементом импортонезависимого интеграционного стека. А планы по развитию продукта – включая инфраструктурный мониторинг доступности адаптеров, гибкую систему нотификаций и настраиваемые дашборды – закладывают фундамент для перехода от реактивного наблюдения к проактивному управлению интеграционной средой компании любого масштаба.

Интересны детали?

Смотрите запись вебинара «SOFROS OneView: мониторинг сообщений интеграционной платформы» на наших площадках:

Rutube

VK Видео

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

Если у вас остались вопросы, вы можете обратиться к менеджерам SOFROS для консультации по телефону +7 (495) 825-16-15 или воспользоваться формой обратной связи на нашем сайте.

Современный подход – применение технологий искусственного интеллекта и машинного обучения. Гибридные модели классификации, семантический поиск на основе языковых моделей, интеллектуальная экстракция характеристик – эти инструменты позволяют не просто автоматизировать процесс нормализации, но и обогащать данные, обучаясь на реальных примерах работы пользователей.

В этой статье мы разберем, какие задачи решают современные AI/ML-инструменты, почему они эффективнее традиционных методов и как их внедрение трансформирует управление данными в организации.

Причины деградации нормативно-справочной информации

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

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

Что ещё может ускорить деградацию данных?

• Организационные изменения – создание новых компаний, слияния и поглощения – также порождают новые информационные системы и, как следствие, множество дублей справочной информации
• Человеческий фактор играет немаловажную роль в деградации данных. Пользователи допускают опечатки, используют различные сокращения и вариации написания одного и того же наименования. Один сотрудник может записать «алюминиевый профиль», другой – «ал. Профиль», третий – «профиль алюм.», и в результате система содержит несколько идентичных элементов с разными написаниями.
• Неполнота НСИ. На начальных этапах внедрения системы принимаются обоснованные решения о заполнении расширенного набора характеристик. Однако по мере развития проекта контроль качества неизбежно ослабевает, что приводит к частичному заполнению данных и потере полноты информации.
• Устаревшие наименования и обозначения становятся проблемой, когда меняются ГОСТы и стандарты. Одни и те же элементы справочников могут быть заведены по-разному в зависимости от версии стандарта. Кроме того, попытка точного соответствия спецификациям поставщиков создает дополнительные сложности, так как разные поставщики часто используют разные обозначения для одной и той же номенклатуры.

Примеры задач, решаемых с использованием сервиса SOFROS AI/ML

SOFROS AI/ML помогает компаниям перейти от разрозненной и трудоемкой работы с нормативно-справочной информацией к управляемому, масштабируемому и интеллектуальному процессу повышения качества данных. Сервис автоматизирует ключевые операции с НСИ, снижает нагрузку на экспертов и повышает точность, полноту и сопоставимость корпоративных справочников. Подробнее о том, что представляет собой сервис SOFROS AI/ML.

Интеллектуальный поиск и семантическая фильтрация данных

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

Автоматическая классификация и категоризация

SOFROS AI/ML автоматически распределяет данные по заданным категориям: отраслям, регионам, типам организаций, группам продукции, классам материалов и другим признакам. Это ускоряет обработку больших массивов НСИ, снижает количество ручных операций и обеспечивает единый подход к классификации данных в рамках корпоративных стандартов.

Извлечение характеристик, шаблонизация и нормализация

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

Повышение качества и полноты данных

SOFROS AI/ML помогает системно улучшать качество НСИ, делая данные более точными, полными, структурированными и пригодными для дальнейшего использования в бизнес-процессах. Для дообогащения характеристик могут использоваться как внутренние корпоративные источники, так и открытые данные из интернета. Это позволяет дополнять карточки объектов недостающими параметрами, уточнять описания и повышать ценность справочной информации для пользователей и смежных систем.

Валидация результатов нормализации

Сервис обеспечивает проверку качества нормализации на основе обученных датасетов и технологий повторной нормализации, включая подход Leave-one-out. Такой механизм позволяет сравнивать результаты обработки с эталонными или ранее подтвержденными данными, выявлять отклонения и повышать доверие к результатам как автоматической, так и ручной нормализации.

Выявление и устранение дубликатов

SOFROS AI/ML помогает находить полные и неочевидные дубликаты в справочниках НСИ, включая записи с различиями в написании, структуре, порядке слов или наборе характеристик. Это позволяет сократить избыточность данных, повысить точность справочников и снизить риски ошибок в закупках, учете, аналитике и интеграционных процессах.

Контроль полноты и корректности выделения характеристик

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

Интеграция с корпоративными системами

SOFROS AI/ML может встраиваться в существующий ИТ-ландшафт клиента и работать совместно с MDM-системами, инструментами анализа данных, BI-платформами и ERP-решениями. Уже реализованы сценарии интеграции с BI-системами и бесшовного взаимодействия с SAP-ландшафтом. Это позволяет использовать возможности AI/ML непосредственно в привычных бизнес-процессах без необходимости создавать отдельный изолированный контур обработки данных.

Результат для бизнеса

В результате SOFROS AI/ML становится не точечным инструментом для одной операции, а технологической платформой для комплексной работы с НСИ. Сервис поддерживает полный цикл повышения качества данных: от интеллектуального поиска, классификации и извлечения характеристик до нормализации, валидации, дообогащения и устранения дублей.

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

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

Оцените актуальность AI/ML для задач нормализации данных в вашей компании. Пройдите короткий опрос за 2 минуты и получите полезный материал с практическими сценариями применения AI/ML для качества и нормализации данных.

Интересны детали?
Смотрите запись вебинара на нашем канале:

Rutube

VK Видео

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

Сервер DATAREON AI/ML поставляется с моделями классификации и извлечения (экстракции) информации. Скрипты моделей реализуются на языке Python.

Модель классификации. Наивный байесовский классификатор

Модель классификации представляет собой гибридный классификатор, предназначенный для определения класса нормативно-справочной информации (НСИ). Основная задача модели — по текстовому наименованию номенклатурной позиции выявить наиболее вероятный класс классификатора на основе статистики встречаемости слов, устойчивых словосочетаний, шаблонов и сходных токенов, характерных для данного класса.

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

Далее производится разбиение текста на токены (слова и n-граммы) различных уровней. Используются как отдельные слова (униграммы), так и последовательности из нескольких слов: биграммы, триграммы и n-граммы большей длины. Это позволяет учитывать не только отдельные слова, но и контекст их употребления. Например, отдельное слово может встречаться в разных классах, тогда как устойчивое сочетание из двух или трёх слов может служить характерным признаком конкретного класса. Для каждого токена также может быть построена специальная маска (например, слово «дом123» преобразуется в маску, где цифры заменяются на специальный символ). Данный механизм способствует обобщению сходных токенов и распознаванию однотипных значений, различающихся только числовой частью.

Полученные токены проверяются с использованием нечёткого поиска на основе расстояния Дамерау-Левенштейна. Этот механизм позволяет оценить степень сходства двух слов и учитывать опечатки, перестановки символов, пропущенные или лишние буквы. Расстояние Дамерау-Левенштейна отражает минимальное количество операций (вставки, удаления, замены или перестановки соседних символов), необходимых для преобразования одного слова в другое. Слово, содержащее ошибку, как правило, характеризуется небольшим расстоянием Дамерау-Левенштейна и может быть распознано моделью как близкое совпадение.

Для ускорения нечёткого поиска применяется хеширование. Токены преобразуются в хеши и распределяются по специальным сегментам (хеш-бакетам), где группируются потенциально сходные слова и словосочетания. Это позволяет не сравнивать каждый токен со всеми словами из обучающей выборки, а быстро находить наиболее близкие по смыслу варианты. Указанный подход существенно ускоряет работу классификатора при большом количестве классов и значительном объёме накопленной статистики.

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

На следующем этапе используется наивный байесовский классификатор (NB — Naive Bayes). Он вычисляет вероятность встречаемости каждого токена в том или ином классе и на основе формулы Байеса определяет вероятность принадлежности номенклатурной позиции конкретному классу.

В модели классификации могут применяться различные варианты наивного байесовского классификатора:

• Мультиномиальный вариант учитывает частоту встречаемости токенов и хорошо подходит для текстов, в которых важна повторяемость слов.
• Категориальный вариант сравнивает распределение категорий и признаков.
• Комплементарный наивный байесовский классификатор эффективен при несбалансированных классах, когда одни классы представлены значительно большим количеством примеров, чем другие.
• Бернуллиевский вариант учитывает не только наличие токена в классе, но и его отсутствие, что может быть полезно для классов с характерным набором обязательных либо, напротив, нехарактерных признаков.

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

На последнем этапе выполняется взвешивание результатов. Достоверные токены (точные совпадения) получают больший вес, тогда как токены с ошибками или нечёткими совпадениями штрафуются. Например, точное совпадение может иметь вес 1, а сходное слово с одной ошибкой — пониженный коэффициент (например, 0,5). Для n-грамм также могут задаваться отдельные веса, поскольку длинные устойчивые словосочетания часто являются более надёжным признаком класса, чем отдельные слова. Дополнительно могут учитываться априорные вероятности классов: если некоторый класс встречается в данных значительно чаще других, он может получать небольшое преимущество при прочих равных условиях.

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

Для оценки качества работы модели рассчитываются стандартные метрики классификации. В первую очередь формируется матрица ошибок, показывающая, сколько объектов каждого фактического класса было отнесено моделью к каждому предсказанному классу. На основе матрицы ошибок вычисляются точность (precision), полнота (recall), F-мера и коэффициент корреляции Мэтьюса (Matthews correlation coefficient).

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

Модель экстракции. Извлечение именованных сущностей

Модель экстракции предназначена для выделения сущностей и их свойств из наименования номенклатуры. Например, из строки «Модель iPhone 12, 128 ГБ» модель может извлечь две характеристики: «iPhone 12» как модель и «128 ГБ» как объём памяти.

Для решения этой задачи используется библиотека spaCy с собственной моделью распознавания именованных сущностей (NER — Named Entity Recognition). spaCy выступает в качестве основного инструмента обработки текста: она выполняет токенизацию строки, анализирует текстовую структуру и позволяет обучать модель на пользовательских данных. В сервисе применяется собственная обучаемая модель, настраиваемая под конкретные классы номенклатуры и их характеристики. В процессе обучения в модель добавляются размеченные примеры, указывающие, какие фрагменты строки являются значениями характеристик и к каким сущностям они относятся. После обучения модель используется для прогнозирования на новых наименованиях и возвращает найденные характеристики.

Модель выдаёт не единственный вариант разбора, а несколько возможных вариантов с оценками вероятности. Метод лучевого поиска (beam search) позволяет сравнить эти варианты и выбрать наиболее качественный результат. Такой подход особенно полезен в неоднозначных случаях, когда один и тот же фрагмент строки может интерпретироваться по-разному в зависимости от контекста, класса номенклатуры или набора доступных характеристик.

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

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

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

Реализован механизм «горячего» кэширования, позволяющий хранить на диске практически неограниченное количество классов (ограниченное лишь ёмкостью дискового пространства). При этом в оперативную память загружаются только те классы, с которыми ведётся работа в текущий момент. Такой механизм загрузки по требованию обеспечивает рациональное использование ресурсов системы, не перегружает память и позволяет одновременно работать с большим количеством классов номенклатуры. Благодаря этому модель может масштабироваться на крупные справочники и использоваться в промышленных сценариях обработки НСИ.

Лицензирование и интеграционные сценарии

Лицензирование сервера DATAREON AI/ML осуществляется отдельно от лицензирования платформы DATAREON.

Сервер DATAREON AI/ML может быть использован в различных интеграционных сценариях. Для выполнения задач классификации, нормализации, семантического поиска и обогащения данных компания SOFROS разработала инструмент — сервис SOFROS AI/ML.

Интересны детали?
Смотрите запись вебинара на нашем канале

Rutube

VK Видео

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

Сегодня мы не классическая техническая поддержка. Мы полноценно работаем с интеграционным контуром заказчика.

О том, как SOFROS помогает клиентам не терять эффективность из-за технических сложностей в условиях кризиса, рассказал Николай Лямин, руководитель отдела сопровождения компании.

Вызовы рынка

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

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

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

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

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

Почему классическая модель техподдержки не работает

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

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

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

3 ключевых вектора сопровождения

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

1. Управление инцидентами и проблемами

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

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

Поэтому для таких сценариев в SOFROS организована поддержка в режиме 24/7, а все задачи, связанные с критически важными обменами, рассматриваются в приоритетном порядке.

2. Управление изменениями

Второй вектор — управление изменениями. Интеграционный контур нельзя рассматривать как статичную конструкцию: он постоянно развивается вместе с бизнесом.

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

SOFROS работает с заказчиками как над изменением существующих обменов, так и над разработкой новых, необходимых бизнесу в текущий момент. Такой подход позволяет сопровождать не «завершенный проект», а живую, меняющуюся среду, которая должна ежемесячно адаптироваться к новым задачам компании и требованиям рынка.

3. Управление знаниями

Третий вектор — управление знаниями. На практике именно эта часть часто оказывается недооцененной, хотя от нее напрямую зависит устойчивость сопровождения.

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

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

Базовая услуга направления: комплексное постпроектное сопровождение

На основе этих трех векторов в SOFROS была сформирована базовая услуга направления — комплексное постпроектное сопровождение.

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

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

SOFROS консультирует заказчиков по следующим вопросам:

• как определить рамки проекта;
• какую методологию выбрать с учетом бизнес-задач;
• как подготовить команду к внедрению;
• какой функционал уже присутствует в информационных системах и как использовать его более эффективно;
• кто должен выступать владельцем процессов и отвечать за конкретные обмены;
• каким должно быть архитектурное решение.

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

— Этот формат не является классическим проектом со стороны исполнителя, где предусмотрены большая проектная команда, руководитель проекта, кураторы и жесткая каскадная модель. Работа выстраивается в том ритме, который удобен заказчику. Сам заказчик реализует проект своими силами, а мы выступаем в роли консалтингового партнера и сопровождаем команду на всех ключевых этапах.

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

Клиентский опыт

На текущий момент у SOFROS уже около десяти подобных проектов. По оценке компании и по отзывам клиентов, такой формат показывает хорошие результаты: внедрение осуществляется силами заказчика, а SOFROS обеспечивает необходимое сопровождение.

Сейчас в компании сформированы два основных подхода к взаимодействию.

1. Первый — абонентский формат. Как правило, он оказывается более выгодным для заказчика. В этом случае за клиентом закрепляется выделенная команда, которая регулярно взаимодействует с ним, проводит встречи, обучает, передает знания и компетенции, а также готовит набор примеров для более быстрого старта.
2. Второй — формат тандемной работы. В этом случае заказчик в целом действует самостоятельно, но при возникновении сложных интеграционных задач, когда требуется найти решение или реализовать конкретный обмен, подключает специалистов SOFROS. Далее проектная команда, на основании технического задания, помогает реализовать необходимое интеграционное решение.

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

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

Интересны детали?

Смотрите запись вебинара «Интеграционный контур в условиях кризиса» на наших площадках:

ВК Видео

Rutube

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

Хотите увидеть, как выглядит аудит интеграционного ландшафта на практике? Заполните заявку и получите пример отчёта по ссылке.

Если у вас остались вопросы, вы можете обратиться к менеджерам SOFROS для консультации по телефону +7 (495) 825-16-15 или воспользоваться формой обратной связи на нашем сайте.

В эпоху стремительной цифровизации бизнеса и усложнения ИТ-ландшафтов, гибкость и надежность интеграционных систем становятся ключевым фактором успеха. DATAREON Platform, будучи отечественной low-code платформой для управления корпоративными данными, постоянно эволюционирует, чтобы отвечать вызовам времени, и даже самые небольшие, но продуманные изменения в ее функционале за прошедший год способны кардинально упростить и обезопасить вашу ежедневную работу с данными.

Изменения в релизах 3.1.0.0 – 3.1.0.1

Одним из первых значимых изменений стало подключение к «1C:Предприятие» по протоколу REST. Ранее подключение осуществлялось только по протоколу TCP, но начиная с версии 3.1.0.0 добавилась возможность использования REST. Теперь в коннекторе появилась отдельная кнопка «Использовать протокол REST», позволяющая настроить всевозможные параметры интеграции, включая использование HTTP/HTTPS и указание порта REST-сервера. Все это в разы упростило взаимодействие с одной из самых распространенных в корпоративном секторе ERP-систем.

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

Конфигурация портала может настраиваться в формате объектов JSON, а его содержимое – как непосредственно в интерфейсе, так и с помощью low-code механизмов. В дальнейшем она может кастомизироваться бесконечное количество раз путем тонкой настройки точечных параметров.

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

Кроме того, модифицирован импорт структур: теперь DATAREON Platform поддерживает выгрузку данных в формате WSDL, XML, JSON, Swagger из структуры внутренних данных платформы.Процесс импорта стал интуитивно понятным – через интерфейс типа данных с возможностью выбора файла метаданных, содержимое которого автоматически преобразуется во внутреннюю структуру платформы.

Дополнительные улучшения:

• внутреннее хранилище DATAREON DB – специализированная база данных для хранения служебных и бизнес-данных, интегрированная с управлением пользователями и хранилищем сообщений;
• перевод компонентов на .NET 6.0 – повышение производительности и совместимости;
• поддержка бинарных данных в импорте и экспорте конфигураций – теперь можно сохранять и загружать данные не только в текстовых, но и в бинарных форматах;
• валидация типа обработчика при подключении к внешним системам – проверка соответствия обработчика требованиям системы повышает надежность интеграции;
• валидация шаблонов при загрузке – проверка корректности и соответствия ожиданиям системы снижает количество ошибок.

Изменения в релизах 3.1.1.1 – 3.1.1.6

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

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

Реализована возможность импорта структур данных из файлов формата YAML в структуры типов данных. Это позволяет загружать метаданные из YAML-файлов аналогично другим форматам.

«Центр мониторинга» и модуль Credential получили расширенный функционал в области управления пользователями и безопасности:

• отдельные права для перезапуска, запуска и остановки сервисов;
• контроль количества попыток ввода неверного пароля;
• настройка срока действия пароля и учетной записи.

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

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

Дополнительные улучшения:

• запуск портала на Linux – ранее сервис был доступен только на Windows;
• модуль горячего восстановления научился корректно обрабатывать сценарии с двумя серверами кластера, повышая отказоустойчивость DATAREON Platform;
• функция исправления конфигурации теперь проверяет согласованность всех ее частей перед применением изменений;
• появилась возможность просмотра очередей остановленных систем и сервисов;
• добавлена поддержка установки платформы на операционную систему Ubuntu 24.04.

Изменения в релизах 3.1.2.0 – 3.1.2.3

Заключительный на 2025 год набор изменений в релизах 3.1.2.0 – 3.1.2.3 был сфокусирован на усилении защиты, расширении инструментария обработки данных и предоставлении большей гибкости в управлении инфраструктурой.

Добавлен расширенный функционал настройки параметров безопасности как в «Центре настройки», так и в сервисе «Управление пользователем». В DATAREON Guard появились возможности:

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

Аналогичные настройки добавлены в сервисе «Управление пользователями». Для активации проверок необходимо установить параметр в значение True и задать регулярное выражение.

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

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

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

Важным шагом стала реализация доменной авторизации. Теперь пользователи могут входить в DATAREON Guard и «Центр настроек», используя учетные данные Active Directory. Аналогичная возможность была добавлена и для модуля Credential. Настройка сводится к указанию адреса и порта сервера Active Directory и активации соответствующего переключателя. После этого при создании пользователя в системе достаточно указать его доменное имя, а пароль будет проверяться непосредственно в AD, что повышает безопасность и упрощает управление учетными записями в гетерогенных средах.

Дополнительные улучшения:

• реализована возможность экспорта и импорта конфигурации без параметров подключения (логинов, паролей, адресов), что повышает безопасность при переносе настроек между различными средами;
• добавлена проверка целостности дистрибутива при запуске, которая завершает работу платформы при обнаружении посторонних файлов;
• процесс переноса сервисов между серверами усовершенствован за счет синхронизации содержимого рабочих очередей, что гарантирует сохранность всех сообщений и заданий;
• в маршруты добавлена настройка автоматического удаления сообщений, для которых не определен получатель, что предотвращает накопление «мусорных» данных и «засорение» очередей;
• расширены возможности работы с сертификатами – пароль для сертификата теперь можно не только задать вручную, но и динамически получать из модуля Credential по имени пользователя;
• введена концепция групп серверов, позволяющая объединять серверы кластера в пользовательские группы с жесткой привязкой сервисов, что обеспечивает локализацию нагрузки и точный контроль за распределением сообщений;
• для разработчиков плагинов программируемого коннектора добавлена возможность прикрепления произвольных файлов с доступом к ним из кода, что централизует хранение ресурсов и упрощает сопровождение;
• обеспечена поддержка Content-Type и Text-Plane для веб-сервисов в формате текста;
• настроена поддержка запросов с Joy в обработчике PostgreSQL.

Подводя итог, можно констатировать, что 2025 год в развитии DATAREON Platform был посвящен не только очевидным крупным фичам, но и глубокой, кропотливой работе над улучшением фундаментальных элементов платформы. Каждое нововведение, каждое изменение работают на общую цель – сделать DATAREON Platform более мощным, безопасным и удобным инструментом для построения надежных систем управления корпоративными данными.

Интересны детали?

Смотрите запись вебинара «Главные изменения в DATAREON Platform за последний год, которые вы могли не заметить» на наших площадках:

VK Видео

Rutube

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

Если у вас остались вопросы, вы можете обратиться к менеджерам SOFROS для консультации по телефону +7 (495) 825-16-15 или воспользоваться формой обратной связи на нашем сайте.

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

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

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

Почему логистика первой чувствует боль «плохих данных»

Каждый директор по логистике знает, насколько хрупкой бывает цепочка поставок, когда в ней появляются информационные разрывы. Несопоставимые справочники номенклатуры, разные описания одной и той же позиции в ERP, WMS, TMS и закупочных системах, отсутствие единых кодов у поставщиков… Все это не просто неудобство, это – прямые потери:

• закупки растягиваются из-за того, что товар ищут по устаревшему или ошибочному ГОСТу;
• склады переполняются излишками, потому что системы считают разными товарами то, что по сути идентично;
• перевозчики получают некорректные спецификации, и груз невозможно сформировать вовремя;
• управляющие центры не могут планировать потребности, потому что данные из филиалов противоречат друг другу.

SOFROS постоянно сталкивается с такими примерами в проектах. Один из ярких случаев – промышленная компания, которая потеряла контроль над закупками комплектующих в зарубежных филиалах: одно и то же изделие фигурировало в системе под десятками наименований, на разных языках и в разных форматах. Сверка занимала недели, а логисты работали буквально по ощущениям. После внедрения централизованной системы управления НСИ на базе платформ DATAREON и 1С:MDM  поток данных стал структурированным, сопоставимым, многоязычным – и затраты времени на обработку заявок сократились кратно.

Другой пример – производственная компания, которая регулярно сталкивалась с задержками поставок: отдел снабжения искал материалы по старым номерам ГОСТ, которые давно утратили актуальность. В логистике это превращалось в реальную боль: срывы графиков, перераспределение перевозок, нервозность в цехах. Выстроенный компанией SOFROS процесс актуализации нормативных документов полностью снял проблему.

Почему логистика напрямую зависит от интеграции

Современный логистический контур практически никогда не ограничивается одной системой. WMS, TMS, ERP, системы работы с перевозчиками, портал поставщиков, аналитика, инструменты прогнозирования – их становится все больше. И каждая из них требует качественного обмена данными.

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

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

Low-code платформа DATAREON, на которой SOFROS строит интеграционные и MDM-решения, полностью импортонезависима и позволяет формировать конфигурации под разные задачи – от ESB до EDW и PIM. Это особенно важно в условиях продолжающегося импортозамещения: логистике требуется архитектура, которая не привязана к одному вендору и легко адаптируется при замене систем.

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

Для логистики особенно критичны четыре характеристики данных:

1. Качество – отсутствие ошибок и дублей.
2. Точность – корректные свойства товаров, грузов, упаковок.
3. Актуальность – соответствие реальному состоянию цепочки поставок.
4. Доступность – данные приходят вовремя туда, где принимается решение.

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

• закупки консолидируются, повышая экономию;
• склады загружаются оптимально;
• планирование перевозок становится прозрачным;
• аналитика отражает реальную картину;
• бизнес получает возможность быстро перестраивать цепочки.

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

Логистика в 2026-м: год интеграции, нормализации и единого пространства данных

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

И это именно то направление, где SOFROS обладает уникальной экспертизой и готовностью доводить проекты до результата – от диагностики и построения архитектуры до внедрения и обучения.

Мы уверены: логистические подразделения, которые в новом году сделают ставку на системное управление данными, получат стратегическое преимущество – скорость, точность и устойчивость всех операций.

Новогоднее послание логистам от команды SOFROS

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

Пусть 2026-й станет для вас годом:

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

Команда SOFROS искренне желает вам успешного, продуктивного и технологически зрелого года. Если в 2026-м вы будете готовы перейти на новый уровень работы с данными – мы рядом и знаем, как помочь.

С Новым годом! Пусть ваши данные будут чистыми, цепочки поставок – устойчивыми, а бизнес – максимально гибким.

Подкаст: «Качество данных как основа бизнеса».

Вы знаете, мой профессиональный путь начался довольно классически —  с участия в проектах по внедрению ERP-систем. Это масштабные и комплексные истории, охватывающие практически все ключевые функции предприятия: финансы, производство, управление продажами, логистику, работу с персоналом. И каждый из этих блоков требует глубокой экспертизы. Но довольно быстро я столкнулась с интересной проблемой: очень сложно найти специалистов, которые одинаково глубоко разбираются во всех этих областях. Обычно это либо узкие эксперты, которых непросто сбалансировать между собой, либо более универсальные специалисты с широким кругозором, но не всегда владеющие нюансами.

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

Со временем я все чаще видела, как компании переходят от больших универсальных систем, в которые пытались включить все функции предприятия, зачастую даже не соответствующие классу этой большой ERP-системы, к более гибкой композитной либо микросервисной архитектуре. Когда каждое приложение закрывает свою задачу, и в целом архитектура становится гибкой и адаптивной. Это логично — бизнес меняется, рынки меняются, нужно быстро реагировать.

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

Но вот когда таких систем становятся десятки, интеграционных потоков — сотни, а требования к данным растут, вся эта «ручная сборка» начинает сыпаться. Где-то теряются данные, где-то появляются расхождения, сложность поддержки резко возрастает. Я много раз наблюдала, как со временем эти проблемы превращаются в серьезные издержки для бизнеса. И вот именно этот накопленный опыт и привел нас к выбору специализации компании SOFROS. Мы поняли, что интеграция приложений, нормализация данных, управление нормативно-справочной информацией — это не вспомогательная настройка. Это стратегически важная часть ИТ-системы компании. И от того, насколько здесь все выстроено, зависит в итоге гибкость бизнеса, его устойчивость и возможность быстро принимать решения на основе качественных данных.

Мы активно участвовали в создании таких продуктов как «1С:MDM», которая, наверное, знакома всем слушателям, и платформы Datareon, хорошо знаем архитектуру и возможности этих продуктов. Сегодня мы работаем как интегратор, который реализует в основном на базе этого программного обеспечения законченные решения по интеграции, нормализации данных и управлению НСИ.

И мы абсолютно уверены в качестве этих продуктов. К примеру, Datareon Platform уже сегодня по функционалу не уступает западным аналогам, а во многих случаях даже их превосходит. А самое главное — бизнес все чаще понимает: без грамотной интеграции приложений и управления качеством данных уже невозможно обеспечить устойчивый рост. И именно здесь сегодня кроется основной запрос наших клиентов. Это компании, которые уже построили сложные ИТ-ландшафты и сейчас приходят к необходимости все это системно объединить, чтобы не терять данных, скорости и управляемости.

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

На мой взгляд, ключевым фактором, повлиявшим на изменение роли интеграции приложений и управления НСИ, стало постепенное повышение зрелости корпоративных ИТ-заказчиков. Еще 10 лет назад подобные темы воспринимались как второстепенные. Для бизнес-подразделений приоритетом было автоматизировать «свои» функции: финансовый директор фокусировался на управленческом учете, директор по закупкам — на системах снабжения, производственники — на MES и APS. Лишь ИТ-директора, как правило, осознавали, что фундаментальной задачей становится именно управление данными и интеграция приложений. Но убедить бизнес инвестировать в это было непросто.

Кроме того, долгое время в корпоративной среде доминировала философия ERP как единой платформы: в нее старались включить не только учетные, но и операционные, и аналитические функции. В таких условиях потребность во внешней интеграции приложений минимизировалась, а управление НСИ фактически «делегировалось» самой ERP-системе. Однако со временем стало очевидно, что специализированные системы справляются со своими задачами значительно эффективнее, чем универсальные. И это подтолкнуло рынок к переходу на композитные архитектуры, более гибкие и адаптивные к задачам конкретного бизнеса. Все чаще использовался так называемый микросервисный подход, и он постепенно становится новым стандартом. А вместе с этим на первый план выходят вопросы интеграции и управления справочной информацией.

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

Одновременно стала очевидной необходимость централизованного управления НСИ. В композитной среде одни и те же справочники — номенклатура, контрагенты, классификаторы и т.д. — используются во многих приложениях, причем с разной глубиной и структурой. Без механизма сопоставления, выверки и дедупликации данные начинают «разъезжаться», что, безусловно, создает серьезные риски для бизнеса. Поэтому возникает потребность в отдельном специализированном программном обеспечении для управления НСИ и ведения эталонных записей.

Таким образом, на сегодняшний день интеграция приложений, нормализация данных и управление НСИ перестают быть «вспомогательными задачами». Они становятся обязательным условием устойчивого развития цифрового ландшафта, особенно при переходе к гибким, масштабируемым и управляемым ИТ-архитектурам. Этот эволюционный сдвиг, «автоматизация-цифровизация-датацентричность», произошёл, наверное, уже на всех уровнях, в том числе на самом высоком государственном. В этом году у нас на смену «Цифровой экономике» пришёл нацпроект «Экономика данных».

Нацпроект Экономика данных намного шире, чем наша специализация, включает в себя много программ инфраструктурных (обеспечение кибербезопасности, бесперебойного доступа к интернету, подготовку кадров для ИТ-отрасли, цифрового госуправления, развитие отечественных платформ, ПО, перспективных разработок и ИИ). Однако появление такого нацпроекта в целом иллюстрирует то, о чем я говорила ранее, повышение зрелости в области управления данными в масштабе государства, а не отдельного предприятия. Что безусловно приведет к большей вовлеченности предприятий в проблематику повышения качества данных.

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

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

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

Третье — это актуальность. Данные должны своевременно обновляться. Старая информация может быть даже опаснее, чем ее отсутствие: она приводит к неверным решениям. И, наконец, четвертое — доступность. Все, кто принимает решения в компании, должны легко получать нужную им информацию — быстро, удобно, без лишних барьеров.

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

• «шуруп 3х20»,
• «винт 20 мм»,
• «шуруп короткий».

Для человека понятно, что это один и тот же товар. А вот для системы это три разных позиции. И что в итоге? Те же самые комплектующие заказываются у разных поставщиков, теряется эффект консолидации закупок. В одном месте накапливаются излишние запасы, в другом — дефицит. Растут затраты на хранение, логистику, появляется риск устаревания материалов.

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

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

Конечно, примеров из практики у нас накопилось немало. Вот, например, один из наших крупных клиентов — компания, которая занимается строительством масштабных промышленных объектов в разных странах. И у них была очень серьезная нагрузка именно на этапе управления проектами: планирование работ, закупка материалов, оборудования, комплектующих — все это требовало больших трудозатрат.

Откуда бралось, казалось бы, столько ручной работы? Дело в том, что сами проекты вначале проектировались на русском языке, а дальше часть закупок и операций шла уже в других странах, на других языках. Причем не просто с переводом, а с учетом местных стандартов и особенностей. Одни и те же материалы в разных странах могут называться по-разному, попадать под разные ГОСТы или стандарты.

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

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

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

Мы включили в проект управления НСИ специальный процесс отслеживания и актуализации нормативных стандартов. Система автоматически отслеживает изменения ГОСТов, и таким образом проблема полностью ушла. На самом деле, таких примеров масса. И каждый из них наглядно показывает одну важную мысль: отсутствие системной работы с данными — это не просто неудобство. Это прямые издержки бизнеса — будь то время сотрудников, срывы сроков, потери в закупках или даже стратегические риски при масштабировании.

На самом деле сегодня практически все компании понимают: качественные данные нужны. Но вот добиться этого на практике сложнее, чем кажется. И тут дело далеко не только в технологиях. Я бы выделила несколько основных барьеров.

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

Вторая группа барьеров — экономические барьеры. Такие проекты как наши требуют вложений: это и лицензии, и специалисты, и обучение персонала. Проблема в том, что эффект не всегда можно быстро посчитать в деньгах. Здесь помогает фокус на конкретных зонах потерь — например, в закупках или логистике. Мы, например, часто предлагаем моделировать экономический эффект заранее: сколько времени тратят сотрудники на сверку данных до проекта и сколько — после.

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

Решение этих проблем — либо выстроить мотивацию для людей, которые вводят данные и ведут их, либо выделить специализированную команду, которая возьмет на себя ответственность за чистоту данных.

И, наконец, четвертый вызов — это уже внедрение аналитики. Очень часто только при запуске BI-систем или отчетности становится видно: данные из разных источников не бьются, отчеты противоречат друг другу, бизнесу сложно доверять этим цифрам. И тут компании начинают понимать: пока не наведешь порядок в данных, никакая аналитика не заработает. По сути, проблема почти всегда не в самих данных, а в подходах к их сбору и управлению. И начинать тут лучше не с технологий, а с реальных, понятных бизнес-проблем. Когда компания видит, что нормализация данных — это не про ИТ, а про экономию, надежность процессов и устойчивость бизнеса, тогда появляется настоящая мотивация меняться.

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

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

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

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

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

Второе — независимость от вендоров благодаря правильной архитектуре, даже, я бы сказала, благодаря правильному ИТ-ландшафту. Современные подходы в построении ИТ-инфраструктуры, такие как композитная и микросервисная архитектура, помогают нашим заказчикам становиться более независимыми от конкретных поставщиков ПО. Использование интеграционных платформ управления данными, в том числе на базе наших решений, позволяет избавиться от эффекта vendor-lock — той ситуации, когда замена одного системного решения на альтернативное становится чрезмерно сложной и рискованной. Микросервисная архитектура со стабильным интеграционным контуром и системой управления мастер-данными (MDM) позволяет нашим клиентам легко адаптировать функциональные решения, менять их на аналоги от других вендоров при необходимости и быть гибкими в условиях меняющегося рынка.

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

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

Как я говорила ранее, одномоментно такой переход выполнить невозможно. Эти системы внедрялись пятилетками, если не десятилетками, и, соответственно, десятилетиями эксплуатировались. В них много подсистем, блоков, масса функций предприятия: HR, финансы, ТОРО, CRM, MES и проч. Невозможно единоразово все это заново проектировать, готовить макеты, внедрять по щелчку — вчера ты был на западной системе, а сегодня уже работаешь на отечественной. Такие переходы осуществляются поподсистемно, начиная с критических операционных подсистем либо с учетных. Например, сначала идет подсистема финансов либо управления продажами. Она проектируется, разрабатывается макет, готовится опытная эксплуатация, проходит опытно-промышленную эксплуатацию и только потом передается в промышленную эксплуатацию. Но при этом все остальные подсистемы пока остаются на незамещенном ПО. Что в итоге мы имеем? Работу предприятия не остановить. Тот же финансовый блок должен откуда-то получать данные: это же учетная система, которая учитывает транзакции по факту осуществления хозяйственной деятельности. А другие аспекты хозяйственной деятельности ведутся в других подсистемах.

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

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

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

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

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

Платформа, которую мы предлагаем клиентам, построена именно по такому принципу — это low-code решение, позволяющее легко создавать и поддерживать разные конфигурации: ESB, MDM, EDW, PIM — все на единой отказоустойчивой базе. Это не только снижает затраты на поддержку, но и упрощает работу с данными.

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

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

Во-первых, она написана с нуля и полностью импортозамещенная, то есть в ней нет никаких open source компонент, и риск каких-то «внезапных» закладок в современном мире равен нулю.

Во-вторых, эта платформа low-code. На практике это означает, что привлечение программистов, разработчиков на внедрении может быть минимальным.

И в-третьих, на единой платформе можно построить набор конфигураций для разных аспектов управления данными: EDW, MDM, PIM, ESB.

Когда мы говорим о цифровой зрелости бизнеса, важно понимать: все строится на данных. Особенно важна в этом ключе нормативно-справочная информация — НСИ. Это такой фундамент, на котором держатся все основные системы — закупки, логистика, HR, CRM и другие.

Эффективное управление НСИ,  когда данные ведутся по единым правилам, без дублей, с актуальной и проверенной информацией. Что это дает бизнесу? Во-первых, меньше ошибок: нет повторных записей, некорректных данных, что снижает риски срывов поставок или лишних затрат. Во-вторых, ускорение процессов: сотрудники работают с одной версией данных и не тратят время на уточнения. В-третьих, качество управленческой отчетности становится выше: решения принимаются на базе достоверных цифр. И, конечно, снижаются затраты на исправление ошибок и интеграцию новых систем. Под «чистыми данными» мы понимаем информацию без ошибок и дублей. Достичь этого помогает современное управление НСИ — чаще всего через системы MDM, которые централизуют данные.

Есть несколько подходов: централизованная НСИ, когда есть единый источник правды и все централизуется в отдельной системе НСИ; аналитическая НСИ — сбор данных из разных приложений с последующим сводом; и гармонизированная НСИ, которая объединяет оба вышеупомянутых подхода, автоматически выявляя дубли и синхронизируя информацию. Главное-  эффективное управление НСИ -это не только задача ИТ, а стратегический приоритет бизнеса. Это инвестиция в стабильность и развитие, которая дает реальные конкурентные преимущества.

Эффективная культура управления качеством данных — это когда данные воспринимаются как стратегический актив, а управление их качеством становится частью ежедневной работы всей компании. Чтобы построить такую культуру, важно начать с нескольких ключевых шагов.

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

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

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

Очень хотелось бы мне вам дать универсальный ответ — вот перечень компетенций, и все. Но, как это часто бывает в реальных проектах, все зависит от задач, которые стоят перед командой внедрения. Datareon Platform — это low-code платформа, а не no-code. Это принципиальное различие: она действительно позволяет многое делать быстро, с минимальным объемом кода, но все же не исключает работу с логикой, структурами данных и иногда — с кодом.

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

• наличие аналитических способностей,
• понимание, как устроена ИТ-архитектура предприятий,
• и самое главное — умение спроектировать интеграционный процесс: какие данные откуда берутся, куда передаются, в каком виде и по какому триггеру.

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

• опыт программирования обработчиков и пользовательских алгоритмов — например, на 1С, C#, SQL;
• умение работать с коннекторами — 1С, REST API, программируемые плагины, базы данных, веб-сервисы;
• знание форматов данных — XML, JSON;
• опыт настройки компонентов платформы — сообщения, банк данных, кластер серверов и прочее.

Но тут я хочу подчеркнуть: все это довольно типовые навыки. Они вполне распространены на рынке, и найти специалистов с нужным профилем вполне реально. И, конечно, если таких компетенций пока не хватает, всегда можно пройти обучение. У нас в компании SOFROS есть собственные курсы: они основаны на реальных кейсах и нашей практике внедрений. То есть если вам нужно оперативно включить специалиста в проект, это часто оказывается быстрее и полезнее, чем универсальное обучение от вендора, хотя, конечно, и оно доступно, включая сертификацию — ее проводит только вендор.

Резюмируя: Datareon Platform — это гибкий инструмент. И требования к специалистам определяются задачами проекта: в одних случаях это просто грамотный аналитик с пониманием архитектуры, в других — уже инженер с кодом и API. Но в любом случае все это решаемо, и специалисты на рынке есть, а обучение всегда под рукой.

В  целом low-code платформа в любом случае позволяет все сделать своими силами, однако, как правило, ресурсы ограничены, а результат нужен к определенному сроку, да и иногда предприятиям нужен какой-то свежий взгляд со стороны. В этом случае, конечно, нужно обращаться к провайдеру. Мы, к примеру, своим клиентам предлагаем разные формы сотрудничества: от внедрения «под ключ» и дальнейшую поддержку, вплоть до 24/7, до обучения и поддержки внедрения, где наше участие минимально.

Интересны детали?

Слушайте  запись подкаста  «Качество данных как основа бизнеса» на  площадках:

Вконтакте

На сайте Tadviser — Качество данных как основа бизнеса. Подкаст с Анной Салиховой, гендиректором компании SOFROS

Подпишитесь на нас в социальных сетях Telegram

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

Если у вас остались вопросы, вы можете обратиться к менеджерам SOFSROS для консультации по телефону +7 (495) 825-16-15 или воспользоваться формой обратной связи на нашем сайте.