Обработка концептуализированных знаний: тезисы KMCONF'18
Компании разных отраслей имеют различные представления о том, что является для них знаниями и как ими необходимо управлять. Благодаря этому сформировалось несколько классов программных продуктов, обладающих различной функциональностью, но объединенных общим названием «Система управления знаниями». Среди них можно выделить:
- Системы Service Desk, содержащие базы типовых решений проблемных ситуаций и описание обслуживаемой инфраструктуры;
- Корпоративные порталы, предназначенные для коммуникации между сотрудниками, организации обсуждений, поиска экспертизы;
- Ресурсы для обучения персонала.
Безусловно, все эти продукты работают с информацией, представляющей корпоративные знания. Однако по форме представления такая информация остается представленной в виде текстов, диаграмм, видео. Смысл информации в такой форме способен обрабатывать человек, но не автоматизированная система. Функционал подобных продуктов, безусловно, полезен и необходим, но мы считаем внедрение таких инструментов только первым шагом на пути развития средств управления знаниями в организации.
При формировании любого сложного массива информации возникает вопрос о том, как ее структурировать. Статьи в базе решений Service Desk привязываются к определенным продуктам, версиям, типам пользователей; файлы на корпоративном портале распределяются по дереву папок, помечаются специальными тегами. Подобные метаданные с той или иной степенью корректности отражают концептуальную модель предметной области, которую используют сотрудники организации, когда мыслят и говорят о своей деятельности.
Концептуальная модель включает набор понятий, значение которых одинаково понимается всеми сотрудниками компании или их группой, а также набор возможных свойств и связей, с помощью которых конструируются высказывания о конкретных объектах или событиях. Например, в концептуальную модель, используемую сотрудниками службы техподдержки, входят такие понятия (концепты), как «пользователь» и «продукт». Эти понятия используются для типизации объектов реального мира - конкретных пользователей и продуктов, и, таким образом, являются знаками (символами), маркирующими множества подобных объектов. В качестве примера понятий, используемых для отражения свойств и связей объектов, можно привести выражения «использует» (в контексте «пользователь использует продукт»), «установлен на», «имеет версию» и др.
Пример концептуальной модели для службы техподдержки
Если для службы техподдержки конструирование концептуальной модели выглядит тривиальной задачей, а сама модель является достаточно стабильной на протяжении длительного времени, то для многих предметных областей интуитивное создание такой модели обречено на неудачу. Для составления сложных концептуальных моделей необходима аналитическая работа, включающая типизацию объектов и связей, выделение оснований их классификации, выявление значений классификационных фасетов и др. По ходу деятельности компании модель постоянно изменяется, отражая изменение внутренних корпоративных практик и внешних условий.
Такие модели невозможно спроецировать на структуру реляционной базы данных без существенных искажений. Например, часто возникают ситуации, когда один и тот же объект относится одновременно к нескольким классам, особенно если рассматривать сразу несколько точек зрения разных функциональных подразделений компании. Так, объект, который служба эксплуатации классифицирует как «трансформаторная подстанция», для экономистов и бухгалтеров является «основным средством». Подстанции могут обладать одним набором свойств, основные средства - другим, а для каждого конкретного объекта этих классов задается множество значений свойств из объединения этих наборов. Указанное обстоятельство приводит к тому, что практически любая автоматизированная система, в которой модель предметной области неявно отражена в структуре базы данных, изначально строится с существенными допущениями, искажающими структуру хранимой информации по сравнению с представлениями, существующими у пользователей и отраженными в нормативных документах организации. По ходу эксплуатации такие модели усложняются, накапливая подобные искажения, а также унаследованные элементы структуры. Практические неудобства работы с подобными системами в определенный момент превышают выгоды от их использования, и автоматизированная система выводится из эксплуатации вместе со всем накопленным в ней опытом.
Изменить эту практику можно путем выдвижения на первый план концептуальной модели, которая должна:
Строиться независимо от конкретных автоматизированных систем, отражать представления организации о предметной области ее деятельности, а не практику автоматизации;
- Формализоваться в соответствии со стандартом онтологического моделирования (OWL);
- Поддерживать ведение жизненного цикла модели;
- Быть доступной как в человеко-читаемом, так и в машинно-читаемом виде.
После построения такой модели и создания репозитория для ее хранения, можно выстраивать вокруг нее всю дальнейшую практику корпоративной автоматизации. Представление концептуальной модели, содержащееся в репозитории, будем называть информационной моделью, поскольку она непосредственно определяет структуру информации, обрабатываемой корпоративными системами. Любая вводимая в эксплуатацию автоматизированная система должна обладать возможностями мэппинга (сопоставления) элементов структуры используемых в ней данных на элементы модели. В идеальном случае, каждая система должна быть готова к изменению модели, и автоматически корректировать структуру хранимой информации (а также состав нормативно-справочной информации) по мере их изменения в центральном репозитории. В терминах ИТ это означает переход от централизованного управления мастер-данными и НСИ к управлению информационной моделью. В нашей практике имеются успешные примеры создания подобных ИТ-архитектур.
Разумеется, подобная трансформация является сложным и длительным мероприятием, функциональным заказчиком которого должен выступать не ИТ-блок, а бизнес-подразделения. Достичь понимания необходимости такой трансформации, мобилизовать необходимые ресурсы и скоординированно осуществить все необходимые мероприятия - нелегко, поэтому промежуточным шагом может стать реализация логической витрины данных, прикладной функционал которой может быть представлен пользователям в составе Системы управления знаниями. Принцип логической витрины данных подразумевает, что все имеющиеся данные остаются в своих источниках, над которыми строится система поиска и извлечения информации по формализованным критериям.
Структура накопленной информации
Любая крупная компания накапливает огромный объем информации, каждая единица которой может быть отнесена к определенным активам, процессам, сотрудникам - то есть элементам того контекста, в котором функционирует организация. Для того, чтобы сделать накопленную информацию доступной для использования, необходимо структурировать ее путем привязки к этим элементам. Для этого, в свою очередь, необходимо построить концептуальную модель предметной области, отразить ее в корпоративных автоматизированных системах и представить в соответствии с ней сведения о конкретных объектах и событиях, участвующих в бизнес-процессах компании.
Рассмотрим пример. Пусть компания эксплуатирует различное оборудование, одним из видов которого являются комплектные трансформаторные подстанции. Информация обо всем, что связано с каждой конкретной трансформаторной подстанцией, рассеяна во множестве автоматизированных систем и источников. В одном месте хранится проектная документация на электрическую сеть, в составе которой она функционирует, в другом - информация о приобретении, установке подстанции и вводе в эксплуатацию, в третьем - сведения об авариях, ремонтах и обслуживании, в четвертом - о параметрах ее функционирования. Часть этой информации представлена в виде файлов, часть - хранится в виде записей в системах ведения бухучета, ТОиР, диспетчерской системе. Вся перечисленная информация, бесспорно, является корпоративными знаниями, которые должны использоваться в деятельности компании. Доступность и связанность этой информации может сыграть решающую роль, например, при составлении программы ремонтов оборудования.
При решении конкретных практических задач, связанных с эксплуатацией активов, могут возникать задачи поиска информации по сложным сочетаниям критериев, например: «необходимо найти эксплуатационную документацию на комплектные трансформаторные подстанции марки XXX напряжением 6 кВ, которые введены в эксплуатацию до 2005 года, пусконаладку которых выполнял подрядчик ООО «Альфа». Другим примером могут быть запросы, связанные с поиском по цепочкам взаимосвязей нескольких информационных объектов: «необходимо найти контрагентов, участвовавших в тендерах на поставку комплектных трансформаторных подстанций, проведенных в интересах АО «Энский горно-обогатительный комбинат». Цепочка связей здесь имеет вид: контрагент - тендер - предмет закупки, тендер - заказчик.
Очевидно, что для выполнения подобных поисковых запросов необходимо:
- Наличие концептуальной модели, в терминах которой может быть сформулирован запрос. В первом из приведенных выше примеров в модели должны быть определены понятия: «Документация» (делящаяся на проектную, эксплуатационную и др.), «Актив» (подклассом которого является трансформаторная подстанция), «Подрядчик» и др. В автоматизированных системах должны существовать каталоги объектов каждого типа, то есть конкретных документов, подрядчиков и др. Часть таких каталогов относится к мастер-данным или нормативно-справочной информации (НСИ), часть - к оперативным данным, постоянно изменяющимся по ходу деятельности компании.
- Наличие системы, индексирующей информацию, находящуюся во всех корпоративных системах и хранилищах, и формирующей метаданные, описывающие каждую найденную единицу информации, в соответствии с концептуальной моделью и НСИ.
- Наличие в данной системе интерфейса, позволяющего пользователю легко сформулировать запрос для поиска нужных данных.
Отметим, что подобную поисковую систему нельзя построить с применением только полнотекстового поиска, поскольку в искомом элементе данных может вообще не содержаться никаких слов; к тому же, алгоритмы полнотекстового поиска всегда возвращают не точный, избыточный набор результатов.
Решением является построение системы, которая в отличие от алгоритмов полнотекстового поиска работает со смысловыми характеристиками информации. Именно этот принцип положен в основу разработанного нами продукта «АрхиГраф.СУЗ». Существует широкий круг функциональных задач, для решения которых необходим именно такой подход. Кроме широкого круга задач, связанного с поиском информации по сложным комбинациям критериев или цепочкам взаимосвязей, можно выделить задачи, связанные с поддержкой принятия решений.
В системах мониторинга обстановки и поддержки принятия решений от автоматизированной системы требуется мгновенно провести комплексный анализ определенной проблемной ситуации, учесть все возможные факторы и выдать варианты ее решения, и при необходимости обосновать их, показав всю цепочку рассуждений. Принципиальное отличие от систем, предназначенных только для поиска информации, состоит в том, что в этом случае система сама получает (выводит) новые факты на основе поступившей информации. Нами выполнены проекты по созданию подобных систем на платформе АрхиГраф.СУЗ, в том числе в области медицины. Такой функционал выходит за рамки традиционного представления о продуктах класса «Система управления знаниями», и близок, скорее, к экспертным системам. Однако фактически в таких системах происходит автоматизированная обработка концептуализированных знаний, то есть прямое и непосредственное использование экспертных знаний, преобразованных в машинно-обрабатываемую форму с использованием концептуальной модели и стандартов онтологического представления информации.
В корпоративной ИТ-инфраструктуре СУЗ может выступать и одним из компонентов сложной автоматизированной системы, выполняющей самые разные управленческие функции - например, формирование отчетов и контроль ключевых показателей, управление рисками или обслуживание ситуационного центра. В таких случаях СУЗ становится инструментом, который использует аналитик для исследования данных и управления информационной моделью системы.
С технической точки зрения перечисленные результаты достигаются использованием стандарта OWL для хранения концептуальной модели и, возможно, фактических данных (хотя для этой цели могут использоваться и другие noSQL хранилища), средства автоматизации получения логических выводов (reasoner), интеграционных компонентов для организации сбора данных из разных источников, а также интерфейсных компонентов для конструирования правил и создания поисковых запросов. Компонентная архитектура автоматизированной системы может иметь следующий состав:
Диаграмма моделе-центричной ИТ-архитектуры
Рисунок 1. Компонентный состав Системы управления знаниями, использующей онтологическую информационную модель, автоматизацию логического вывода и принцип логической витрины данных
При любом сценарии использования концептуализированных знаний компания получает экономический эффект, сопровождающийся изменением организационных процессов и развитием культуры владения информацией. Такой эффект может быть огромен и достигается за счет:
- увеличения информированности при принятии управленческих и оперативных решений, как следствие - повышения качества решений, снижения потерь из-за допущенных ошибок;
- ускорения выполнения бизнес-процессов за счет снижения затрат времени на поиск информации;
- снижения возможных потерь из-за ухода ключевых сотрудников, являющихся носителями важнейшей информации, и повышения скорости и качества обучения новых сотрудников.
Таким образом, предлагаемый нами подход к управлению знаниями состоит прежде всего в том, чтобы перейти от работы с данными в автоматизированных системах к работе с собственно знаниями - то есть обеспечить смысловую, а не только технологическую обработку информации. Это означает, что системы должны не просто хранить определенную информацию - они должны «знать» ее смысл. Такой подход, реализованный в составе Системы управления знаниями, позволяет пользователям строить сложные поисковые запросы и получать на них 100% верные ответы, осуществлять навигацию между взаимосвязанными информационными объектами. В составе систем поддержки принятия решений этот подход позволяет реализовать получение логических выводов на основе правил, сформулированных экспертами, то есть непосредственно применять экспертные знания для получения новых фактов.