Почему ОТМ? Часть 3 — Интеграционная

Еще одна порция веских доводов почему стоит выбрать именно ОТМ в качестве прочного фундамента для построения эффективной системы управления перевозками. Честно говоря я уже собиралась назвать эту часть «Заключительной», но вдруг обнаружила, что предыдущие статьи не раскрывают очень важную тему взаимодействия ОТМ с внешним миром, поэтому не стану спешить закрывать серию «Почему ОТМ?», а открою часть третью — интеграционную.

nav_wheel_lg

Логотип ОТМ 5.5

Прежде чем углубиться — посмотрите внимательно на этот замечательный логотип ОТМ. К сожалению в живой системе его уже не увидишь на стартовой странице, поскольку Oracle благополучно избавился от этого наследия G-Log начиная с версии OTM 6.0. Забавно, но новые пользователи как правило начинали с того, что пытались нажимать на «кнопки» этого «колеса». Мне нравится что этот логотип имеет смысловую нагрузку, а не просто красивые картинки — здесь все модули системы, и их совокупность представляет собой интегрированную логистическую платформу.

ОТМ — отдельно и в комплекте.

Хотя Oracle и позиционирует ОТМ как Standalone («отдельностоящее») приложение, всеже крайне редко доводится внерять его совершенно отдельно, без привязки к другим системам — учетным или прикладным. В данном случае под Standalone подразумевается то, что ОТМ полностью самодостаточен и для его полноценной работы никакие другие приложения не требуются. Простой пример обратной ситуации — модули OeBS Purchasing (Закупки) и Inventory (Запасы), которые жить друг без друга не могут, хотябы потому, что Закупки никак не сможет начать работать без того, чтобы в модуле Запасы не завести справочник товарных позиций.

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

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

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

Интеграция — управлять потоками данных.

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

Но прежде чем начать принимать и обрабатывать собственно заказы на перевозку в ОТМ нужно заполнить целый ряд более или менее статических справочников — так называемых «мастер данных». В терминах методологии ОТМ эта часть внедрения называется Business Modeling — моделирование бизнеса. Создание и обновление этих справочников — более половины успеха. Такие мастер данные как расположения, поставщики услуг, позиции груза, ставки жизненно необходимы для выполнения основных функций ОТМ. Как правило эти справочники содержат огромное количество данных, которые постоянно дополняются и обновляются, поэтому первый вопрос который возникает как при первичной настройке, так и в процессе эксплуатации – это как корректно и просто загрузить эти массивы данных в систему. ОТМ предлагает загрузку через файлы формата CSV, которые очень легко и удобно готовить используя Excel и быстро загружать.

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

c22

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

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

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

Принимать и отдавать.

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

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

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

Своевременно уведомлять.

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

Актуальность и полнота данных в результате.

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