Как построить устойчивую ИТ-инфраструктуру с минимальными рисками

Комплексный подход

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

Реализовать кастомную интеграцию ИТ-систем в логистике (да и в любой бизнес-сфере) — это как самому вырезать кусочки пазла из картона. Получается сложный, трудоемкий и дорогой процесс, который сопряжен со сложностями как на этапе разработки, так и с рисками на этапе эксплуатации. Это могут быть ошибки, потерям данных, задержки при работе системы или даже остановка бизнес-процесса. И всё это в купе с высокой стоимостью владения таким решением. Как и любой индивидуальный проект, кастомизация стоит значительно дороже, потому что каждый раз приходится изобретать новое решение. Это требует работы высококвалифицированных специалистов и само по себе занимает больше времени.

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

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

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

Интеграция ИТ-систем фактически включает в себя 3 уровня:

1. Интеграция людей. Это сама по себе сложная задача — нужно собрать специалистов из разных отделов, возможно даже из разных компаний, которые будут работать над интеграцией, объяснить им цель интеграции, собрать с каждого из них требования и договориться еще о формате взаимодействия. На одном из наших последних проектов для логистической компании мы в принципе должны были состыковать людей, которые работали в разных часовых поясах. То есть у нас были условные 3 часа в день, когда все участники процесса были доступны.
   
2. Интеграция процессов. Должна быть выстроена единая логика бизнес-процессов, т.к. логика самих шагов в бизнес-процессах может не соответствовать друг другу в разных системах. То есть процессы будут называться похоже, но шаги в разных системах могут быть разные, и задача интегратора — их увязать между собой.
   
3. Интеграция данных. Объясню на примере. Есть такое понятие как «транспортный вагон». Это объект данных. Когда мы говорим о вагоне, разные стороны в бизнесе понимают его по-разному. Когда о вагоне говорит логист, ему важно знать его ширину, длину, вместимость, грузоподъемность. Когда бухгалтер — ему важно видеть амортизацию накопленную, кто ответственный за этот объект. А когда технический директор — ему важно видеть, какие нормативы должны быть по техобслуживанию, какая наработка у вагона, какие бывают типовые дефекты. Даже когда мы говорим об одном понятии, оно может не соответствовать друг другу в разных системах. И эти объекты надо синхронизировать между системами, что не всегда возможно. Либо должна быть налажена логика конвертации — как из одной системы получить данные для другой. Для таких задач интеграторы уже разрабатывают таблицы соответствий, таблицы ключей и трансформаторы.

Наши выученные уроки и рекомендации для логистических компаний

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

Поделимся некоторыми выученными нами уроками и лучшими практиками:

1. Как понять объем интеграции и оценить объем проекта. За годы работы нами выработана методология определения объема, сроков и трудоемкости интеграции. Важно понимать, что интеграция систем всегда строится на основании бизнес-процессов. Сами интегрируемые объекты можно условно разделить на два больших блока — транзакционные данные (т.е. бизнес-документы и бизнес-события) и нормативно-справочные данные (справочники, классификаторы, таксономии и пр.). Сначала бизнес-аналитики или бизнес-консультанты исследуют и определяют целевой бизнес-процесс компании, как он должен быть (to-be), затем определяются информационные системы, в которых процесс должен выполняться или учитываться. И уже исходя из точек интеграций процесссов определяются сначала интегрируемые события и документы, от которых уже в свою очередь определяются интегрируемые справочники и классификаторы. Например, рассмотрим процесс транспортировки. Сам процесс условно можно разделить на 2 блока: планирование и исполнение. Как правило, каждый из этих блоков единого процесса реализуется в разных ИС. В системе планирования формируются заявки, определяются сроки и маршруты, подбираются исполнители. А в системе исполнения происходит мониторинг и диспетчеризация транспортировки, расчет фактических расходов.

2. Ориентируйтесь на международные и отраслевые стандарты.

Есть разные типы стандартов. Одни — это отраслевые или международные бизнес-стандарты, в которых описаны общие принципы и логика процессов, схемы и структуры бизнес-данных (EDIFACT, BSP-RDM, ISO 23354, ISO 23355 и др.). А есть технические стандарты — они показывают, как передавать данные (SOAP, REST, oDATA, ODBC). Это протоколы на уровне технического обмена.

Команда проекта может попытаться реализовать собственными силами описанную логику стандартов, опираясь на существующую документацию. Но все эти протоколы довольно масштабные и комплексные, т.е. сходу разобраться и учесть все нюансы будет крайне сложно и трудоемко и наверняка чревато множеством ошибок и большими сроками работ. Другой подход — взять готовое решение, которое уже есть на рынке. Лучше использовать готовые решения, модули интеграции для систем, которые у вас уже используются и коннекторы. Они поддерживают протоколы на уровне логики и техники. У многих поставщиков различных программ есть готовые модули интеграции, например, с теми же решениями 1С.

3. Определите единого ответственного/архитектора для курирования интеграции, владельца реестра интеграционных точек, систем и сервисов и ответственного за определение общих правил и подходов к интеграции. Также этот человек должен отвечать за синхронизацию сроков и слаженную работу всех команд интеграции. Иногда это могут быть два разных человека —технический архитектор и менеджер по интеграции. Менеджер по интеграции отвечает за интеграцию людей, а технический — за техническую часть, процессы и данные. В крупных компаниях даже за каждой интегрируемой системой может быть закреплен свой ответственный/менеджер.

По нашему опыту, компании часто недооценивают сложности интеграции и оставляют всю задачу полностью на ИТ-специалистов / программистов. Но такое работает только на маленьких масштабах и простых задачах, и то как правило в таком случае сроки «плывут», а сами технические решения не оптимальны, т.к. кто-то из ИТ-команды знает только определенную программу и инструмент и исходит из того, как он умеет работать, а не как оптимально в целом.

4. Сфокусируйтесь на всестороннем тестировании интеграции.

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

Не забывайте про тестирование различных вариаций сценариев. В бизнесе всегда есть множество нюансов. Например, когда документы создаются, а потом их нужно отменить/скорректировать/перепровести/разбить на несколько и т.д. И сложность тестирования интеграции — определить все возможные вариации бизнес-процесса и протестировать их все, создать различные корректировочные сценарии. При этом как правило ИТ-команда может не знать всех вариаций процесса и протестировать только самые простые и очевидные сценарии. Это задача бизнес-аналитиков или бизнес-консультантов — определить все возможные корректировочные сценарии. Чтобы понять всю вариативность интеграции, надо понять всю вариативность бизнес-процессов.

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

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

Читайте также

Что такое deepfake и почему это проблема?

Какие методы обнаружения deepfake существуют? Какие возможности могут предоставить большие языковые модели (LLM) для генерации и обнаружения дипфейков? Расскажем о технологии aIDeepfake для борьбы с фальсифицированным контентом.

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

7. Используйте специализированные интеграционные шины или онлайн-сервисы информационного обмена. Специализированные интеграционные шины (ESB) — это по сути ПО-посредник между различными ИТ-системами. Оно нужно для унифицированного способа обмена данными между системами, при этом неважно, какое аппаратное или программное обеспечение есть в компании, какая стоит операционная система и с каким форматом данных он работает. В таких инструментах,как правило реализованы почти все пункты, описанные выше. Они будут поддерживать разные стандарты и протоколы, будут выступать в роли единой базы всех интеграций, будут поддерживаться различные инструменты трансформации данных, гибкие правила маршрутизации передаваемых данных. На уровне этих инструментов поддерживается мониторинги, контроли целостности, все протоколы безопасности и шифрования.

Сейчас существуют российские аналоги (1С:Шина) и много open-source продуктов. Шина — это хороший инструмент, но он также создает доп.трудности — ИТ-команда бизнеса должна уметь ей пользоваться и поддерживать её. Поэтому шину имеет смысл начать использовать, когда понимаете, что у вас будет достаточно большой объем интеграций или количество интеграции будет увеличиваться. Если мы говорим об интеграции двух-трех небольших систем, смысла использовать шину нет.

Кейс производственно-логистической компании

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

• Нет возможности автоматической проверки полноты и корректности переданной информации
  
• Нет возможности настройки и администрирования правил создания и изменения объектов в удобном графическом формате
  
• Передача данных о расчёте себестоимости поступает в ограниченном виде что приводит к большому объёму ручных корректировок при обработке.

Для учёта производственной деятельности и учета себестоимости в компании использовался SAP ERP. А для учета общехозяйственной деятельности, закупки оборудования, оплаты товаров и услуг, а также ведения бухгалтерской и налоговой отчётности — система 1С: «Бухгалтерия предприятия». Передача данных осуществляется посредством файлов в общей папке, в которой для каждого вида операций назначена специальная папка. Очередь обработки файлов проверяется путём переноса обработанных файлов в специальную папку.

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

Компания остановилась в итоге на базовом варианте.