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

Почему интеграционные проекты срываются по срокам

Оценки интеграции обычно оптимистичны, потому что объём работы скрыт до её начала. Постоянно повторяются четыре причины.

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

Варианты интерфейсов

Выбор интерфейса зависит от того, что поддерживает исходная система и насколько свежими должны быть данные. Веб-сервисы REST и SOAP остаются самым распространённым путём для современных продуктов ERP и CRM. Они поддерживают обмен запросами и ответами и удобны для мониторинга, но требуют, чтобы исходная система предоставляла нужные операции.

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

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

Сопоставление данных и качество данных

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

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

Безопасность и аудит

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

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

Тестирование и откат

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

Эксплуатация после запуска

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