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

К моменту начала проекта у «Морвенны» накопился заметный технический долг по различным контурам учёта, включая судовой модуль.

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

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

К моменту подключения РАУ ИТ интеграция между береговой системой и судовыми базами была разработана сторонним подрядчиком и со временем перестала стабильно отрабатывать в условиях открытого моря. В работе проявлялись типичные для распределённых систем проблемы:

• обмен мог «останавливаться» на ошибках, а восстановление требовало ручных действий;
• в данных появлялись дубли и ошибки;
• возникали битые ссылки и рассинхронизация объектов, из-за чего снижалось качество аналитики;
• часть пользовательских сценариев (особенно связанных с номенклатурой в закупках) оставалась неудобной и провоцировала ошибки.

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

Проект разворачивался не «с нуля», а в существующем ландшафте. Это означало, что:

1. Обмен нельзя было «выключить» и переписать заново без существенных рисков для операционной деятельности. Поэтому выбран путь эволюционной доработки с сохранением текущей архитектуры.
2. Масштаб оказался больше, чем типовой проект: одновременно работали десятки контуров и окружений.

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

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

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

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

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

Чтобы снизить риск ошибок на пользовательском уровне, РАУ ИТ сделала практичные улучшения интерфейса, в частности — более удобные формы ввода и поиска номенклатуры. Это не только повышает скорость работы экипажа и береговых специалистов, но и уменьшает вероятность создания некорректных позиций в обход правил.

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

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

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

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

Компания получила возможность начать комплексную модернизацию ИТ-ландшафта
Проект стал точкой входа в системное развитие ИТ-ландшафта: РАУ ИТ не только доработали судовой модуль и обмен, но и помогли сформировать понятный план дальнейшего развития ИТ-систем компании, который можно реализовывать последовательно и без потери управляемости. За счёт документации, описанных процессов и передачи решения ИТ-департаменту «Морвенна» получила возможность развивать контур самостоятельно — силами собственного штата — и снизить риск зависимости от подрядчика.

Заказчик перешёл к внутренней поддержке и снизил стоимость сопровождения
Благодаря РАУ ИТ, после передачи документации и упорядочивания процессов Морвенна внедрила и расширила роли специалистов техподдержки и аналитики. Собственная команда сопровождения обходится дешевле, чем постоянное привлечение внешнего подрядчика.