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

Так ли уж нужна онтология для эффективной работы с данными?

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

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

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

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

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

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

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

Когда компании всерьез задумываются о построении онтологии, они обычно сначала выбирают и внедряют систему управления основными данными (Master Data Management, MDM) — именно ее концепция и идеология берется за основу дальнейшей работы. Системы MDM предполагают наличие определенной, ясно понимаемой модели данных с контролем дублирования, верификацией заполнения и так далее. Внедрение MDM помогает компаниям приступить к выстраиванию и оптимизации их структур данных.

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

За счет чего окупаются инвестиции и усилия в области онтологии?

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

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

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

Построение онтологических моделей — это проект или процесс?

Построение модели — это всегда процесс, потому что модель эволюционирует — изменяется, модифицируется. Некоторые модели «отмирают», другие заменяются, и т.д.

Простой пример — описания мониторов. Лет 30 назад в числе их параметров были размер экрана электронно-лучевой трубки (ЭЛТ), кривизна экрана и пр. Когда наступила эра плоских мониторов, величина кривизны экрана стала ненужной. У вышедших затем на рынок ЖК-мониторов появился ряд дополнительных характеристик. И так далее. Если сравнить мониторы с ЭЛТ и нынешние мониторы, то выяснится, что одинаковых характеристик у них совсем немного: размер экрана, его разрешение, потребляемая мощность и, может, что-нибудь еще. Как видим, модель данных, описывающая мониторы, существенно изменилась, причем всего за каких-то 20-30 лет…

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

Специалисты какого профиля и уровня квалификации требуются для построения онтологических моделей?

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

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

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

Каковы наиболее значимые результаты работ в области онтологии?

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

Какова цена ошибок при проведении работ в области онтологии?

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

Какого рода инструменты помогут провести онтологию успешно и эффективно? Каким требованиям они должны отвечать?

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

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

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

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

Нужен ли Low-Code для проведения онтологии?

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

Каких дальнейших эволюционных шагов следует ожидать от онтологии и инструментов для ее проведения?

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