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

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

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

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

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

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

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

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

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

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

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

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

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

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

Третий уровень — структурированное описание, в котором марка, количество жил, сечение и напряжение выделены в отдельные атрибуты. Только такой вариант позволяет системно валидировать объект: например, для сечения 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 или воспользоваться формой обратной связи на нашем сайте.