KIMM: Онтологии, протоколы, AI и оркестратор

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

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

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

Disclaimer: поскольку до сих пор у меня не было возможности построить системы 4 уровня и выше, то всё нижеприведённое является моим видением возможных подходов.

Позволю себе предложить классификацию систем информационного обмена KIMM (Knowledge & Information Maturity Model)

Уровень 0: Стихийный

Уровень 1: Формальный

Уровень 2: Фрагментированный

Уровень 3: Систематизированный

Уровень 4: Аналитический

Уровень 5: Когнитивный

Уровень 6: Оркестратор

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

Создание и поддержание в актуальном состоянии онтологий предприятия - это достаточно трудоёмкая работа, в которую могут быть вовлечено десятки и сотни людей. Да, есть специализированные системы, типа Palantir, которые позволяют строить и поддерживать онтологии на предприятии. Но можно обойтись и подручными средствами. Ведь нам что нужно?

Формат - это, пожалуй, самое простое из этого списка. Уже давно существуют OWL, RDF и другие текстовые форматы описаний онтологий. Выбор - дело вкуса.

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

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

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

Я поисследовал рынок готовых систем (благо, с AI уровня Deep Research это сегодня несложно) и пришёл к выводу, что ничего подобного, позволяющего быстро построить у себя систему 5-6 уровня, нет. И вряд ли будет, поскольку система должна быть тесно связана с инфраструктурой организации и требует глубокой настройки под конкретную организацию.

Не буду лукавить, лично я пока не построил ни одной системы 4 и 5 уровней. Надеюсь, ещё построю ). Однако, где бы я не работал и с какими бы заказчиками не имел дело, я ещё ни разу не видел даже систему 3 уровня, не говоря уже о 4 или 5. У абсолютного большинства предприятий до сих пор не решён вопрос с элементарными протоколами и регулярными отчётами.

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

На рынке много инструментов, подходящих для конкретных задач:

Но проблема в том, что все эти инструменты не интегрированы между собой. Чтобы построить систему 4-5 уровня, придётся комбинировать их вручную, писать кастомные интеграции и дорабатывать под свои процессы.

И, кажется, что ещё довольно долго не будет, потому что:

Если вы хотите двигаться в сторону зрелости по модели KIMM, вот с чего я бы начинал:

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

Стартуем с малого:

Используем подручные средства:

Добавляем автоматизацию для поддержания актуальности:

Внедрение продвинутых уровней KIMM (4-6) кажется не просто апгрейдом инструментов, а культурной и технологической революцией. Вот ключевые вызовы, которые видны уже сейчас:

Что происходит:

Возможное решение:

Что происходит:

Возможное решение:

Что происходит:

Возможное решение:

Что происходит:

Возможное решение:

Что происходит:

Как избежать:

Вопрос к вам:

Какой уровень KIMM у вашей компании? И какие инструменты вы уже используете?