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

Коллапс продолжался больше недели после открытия нового терминала аэропорта. Поскольку Хитроу – ключевой европейский транспортный узел (в аэропорту каждые 45-50 секунд взлетают и приземляются самолеты), багажный кризис вызвал проблемы по всей Европе и даже по миру, а потерянные чемоданы развозили хозяевам еще 2 месяца. 

Эта история в авиаиндустрии послужила поводом для множества уроков. И произошло все, в том числе, и из-за ошибок при трансформации ключевых процессов аэропорта. О том, как сегодня строится управление Enterprise-архитектурой международного аэропорта «Шереметьево», и какое место в ней занимает база знаний, рассказал Юрий Золотых, главный эксперт службы цифровой трансформации аэропорта, в рамках конференции TEAMLY.

Если ваш бизнес мал…

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

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

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

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

Enterprise-архитектура

Методология TOGAF, которая сейчас является де-факто стандартом описания Enterprise-архитектуры, изначально предлагает многомерный подход. Архитектурный 3D континуум означает охват всей функциональной структуры, процессов и архитектурных доменов. И все это должна объединять база знаний.  

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

Пример:

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

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

• досмотр на входе в аэропорт (служба безопасности аэропорта);

• регистрация пассажира и багажа (авиакомпания или служба аэропорта);

• досмотр на входе в “чистую зону” (служба безопасности аэропорта);

• сортировка багажа (багажная система аэропорта вылета);

• предоставление услуг маломобильным пассажирам, если это требуется (службы аэропорта);

• доставка пассажиров на борт воздушного судна (хендлинг аэропорта: подача автобусов, трапов, телетрапов);

• погрузка багажа на борт (хендлинг);

• перелет (авиакомпания, аэропорт вылета и аэропорт прилета обмениваются информацией о пассажирах и багаже);

• выгрузка и сортировка багажа (хэндлинг аэропорта прилета уже знает, чей багаж прилетел и куда он должен дальше следовать);

• доставка пассажиров в терминал (хэндлинг аэропорта);

• выдача багажа пассажиру (аэропорт).

Если вы следуете с пересадкой, или ваш рейс задерживается, например, по погодным условиям, то и ваш багаж, совершая не менее “увлекательное” путешествие между терминалами, попадает на склад, пока вы ждете посадку…

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

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

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

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

Например, мы модифицируем алгоритм обработки багажных сообщений двух типов: сообщений о регистрации (BSM) и сообщений об обработке (BPM) багажа и хотим знать, какие системы и интеграции между ними это может затронуть. 

В нашем случае эти две сущности передаются в 26 интеграциях. Добавляем на схему системы-источники и системы-получатели. Это 17 информационных систем. Полученная схема содержит 91 связь. 

И это лишь две простые с виду сущности. Кстати, именно из-за проблем в интеграции багажных систем и возник коллапс в Хитроу. 

Вот схема текущей Enterprise-архитектуры с точки зрения интеграции информационных систем, в которых регистрируются сущности — архитектурные артефакты.

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

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

1. Найдя интересующий вас термин в словаре, вы легко можете найти связанные с ним сущности.

2. Уточняете, в каких информационных системах найденные сущности учитываются (регистрируются, модифицируются).

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

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

Важные аспекты внедрения

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

• Классифицируем объекты предметной области и тем самым выделяем сущности, которые будут элементами архитектуры, т.е. архитектурными артефактами;

• начинаем ведение реестров сущностей, устанавливаем связи между ними;

• разрабатываем и анализируем архитектурные схемы;

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

База знаний в Enterprise-системе нужна всем, а значит… никому!

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

Рекламная пауза

Посмотрите, какие фичи появились в осеннем обновлении нашей платформы для совместной работы и управления знаниями, документами и задачами TEAMLY. Для управления задачами, документами, целями и спринтами подойдут "умные таблицы" с двумя видами отображения: табличными и канбан. А текстовую рутину можно отдать на откуп AI. Улучшенные настройки прав позволят еще эффективнее работать с платформой внутренним и внешним пользователям.