Невидимое соединение: как Шереметьево перестроило багажные операции на отечественном ПО

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

Ведомости сообщили 16 июня 2026 года, что крупнейший международный аэропорт России Шереметьево перевёл управление перевозкой трансферного багажа между терминальными комплексами на отечественное программное обеспечение компании Рексофт (Reksoft). Система обслуживает движение между северной группой с терминалами Би и Си (B and C) и южной группой с терминалами Ди, И и Эф (D, E and F).

Генеральный директор разработчика Александр Егоров рассказал о переходе, а заместитель генерального директора по информационным технологиям АО МАШ Дмитрий Ильин подтвердил его. Стороны не раскрыли стоимость. Эксперт Анастасия Безрукова оценила сопоставимый проект полного цикла — от исследований и разработки до промышленного ввода — в 350–700 млн рублей. Для компаний в России этот пример показывает, как локализация критической технологии превращается в задачу надёжности, управления поставщиком и доказуемой операционной готовности.

Багажная система является производством с минутным тактом

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

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

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

Связь двух терминальных групп создаёт особый риск

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

Для трансфера важна непрерывность владения. На каждом участке должно быть понятно, какая система и какая смена отвечают за вещь. Передача между зонами не может опираться на предположение, что следующая сторона уже получила сообщение. Нужны подтверждённое событие, единое время и возможность восстановить последовательность после сбоя.

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

Отечественный код не отменяет ответственности за архитектуру

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

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

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

Миграция должна начинаться с двойного наблюдения

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

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

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

Единая модель событий соединяет цифровое и физическое

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

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

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

Маршрутизация обязана объяснять исключение

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

Объяснимость не означает раскрытие сложной формулы. Работнику достаточно увидеть факты: назначение изменилось, до закрытия осталось определённое время, автоматический путь недоступен, рекомендована ручная доставка. Такое сообщение позволяет проверить решение и действовать одинаково в разных сменах.

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

Наблюдаемость должна отвечать на операционный вопрос

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

Показатели должны иметь пространственное и временное измерение. Средняя скорость за день скрывает десятиминутную остановку конкретного коридора в момент нескольких коротких стыковок. Нужны распределения, самые длинные задержки и сравнение одинаковых интервалов нагрузки.

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

Ручной режим является частью основной системы

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

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

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

Кибербезопасность должна сохранять движение, а не только закрывать доступ

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

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

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

Поставщик становится участником круглосуточной эксплуатации

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

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

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

Экономику нужно считать через предотвращённый сбой

Оценка 350–700 млн рублей охватывает широкий полный цикл и не раскрывает фактическую цену проекта Шереметьево. Для инвестиционного решения важна структура: разработка, оборудование, интеграция, испытания, обучение, резерв, сопровождение и последующие изменения. Дешёвое внедрение может создать дорогую эксплуатацию, если каждое изменение требует уникальной работы.

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

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

Испытания должны воспроизводить неудобную реальность

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

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

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

Люди должны понимать состояние, а не устройство кода

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

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

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

Показатели должны соединять чемодан, рейс и систему

Техническая доступность в процентах не показывает пассажирский результат. Система может формально работать, но медленно доставлять приоритетные вещи. Нужны показатели своевременной погрузки, пропущенных стыковок, ручной обработки, неопределённых статусов и времени полного восстановления.

Ежедневная панель операционной готовности

1. доля трансферного багажа, доставленного к нужному рейсу до закрытия погрузки;
2. время прохождения между северной и южной терминальными группами по диапазонам;
3. число предметов без подтверждённого положения дольше установленного порога;
4. доля ручных перенаправлений и основные причины исключений;
5. ошибочные повторы, неверные назначения и исправления после погрузки;
6. длительность отказов, время обнаружения и время возврата накопленного потока;
7. обращения пассажиров и стоимость последующей доставки по каждой тысяче вещей.

Показатели следует связывать, а не оптимизировать по отдельности. Ускорение конвейера бессмысленно, если растёт число неверных маршрутов. Снижение ручной работы опасно, если система скрывает неопределённость. Общая цель — своевременная и доказуемо правильная доставка.

Первые сто дней определяют качество эксплуатации

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

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

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

Урок выходит далеко за пределы аэропорта

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

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

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