сервер тмс что это
Два слова из трёх букв: TMS и VCS
Все три устройства относится к группе инфраструктурного оборудования, т.е. видеоконференцию вы и без них запустите, но они весьма полезны для решения задач, которые выходят за рамки обеспечения связи точка-точка.
TANDBERG Management Suite или TMS
Как следует из названия, это программный комплекс (хотя он может поставляться и в виде собранного 1-u сервера) для управления терминалами и серверами видеосвязи. На нём можно генерировать адресные книги для терминалов, управлять их обновлениями, строить отчеты по использованию, осуществлять переключение между серверами многоточки и т.д. Коротко: система, управляющая всей вашей сетью видеосвязи.
Что примечательно, умеет управлять и сторонними терминалами (конечно же, не в таком объеме как своими родственниками). Дело в том, что этот продукт разрабатывался компанией, которая была несколько лет назад поглощена TANDBERG. Очевидно, что продукт разрабатывался для видеоконференций в целом. После поглощения этот функционал решили не убирать.
TANBERG VCS Control
VCS расшифровывается как Video Control Server (не путать с сервером многоточечной связи). И если отбросить громкие слова, то являет собой sip-сервер и контроллер зон H.323 в одном флаконе. Заточен под видеосвязь и может соединять устройства из обеих этих сетей. Также, очень полезен при стыковки со сторонними приложениями: ip-телефонией, Cisco Unified Communications, Microsoft OCS и т.д.
TANDBERG VCS ExpressWay
А это гораздо более занятная железяка (точнее приложение): оно служит для преодоления фаерволов. Фаерволы, как известно, созданы для того, чтобы не пускать. В первую очередь, снаружи. Соответственно, если попробовать соединиться из-за фаервола с удаленным терминалом, то вас скорее всего увидят и услышат, а вот в вашу сторону пакеты не пойдут, и вы будете грустно смотреть в тёмный молчаливый экран. Такой вот он протокол RTP.
Что делает ExpressWay: он отдает входящие пакеты по порту, который был инициализирован устройством, находящимся за фаерволом, и, соответственно, по этому соединению может бегать, что угодно в обе стороны. Очевидно, ExpressWay располагается в публичной сети.
Как это выглядит
На рисунке показано, как устройства общаются друг с другом. TMS я рисовать не стал, но он подразумевается: без него рулить этим зоопарком весьма затруднительно. 
Когда это нужно
GIS-LAB
Географические информационные системы и дистанционное зондирование
Основы работы динамических TMS-сервисов
Содержание
[править] Введение
Для создания тайлового кэша существует различное программное обеспечение, например, утилиты gdal2tiles и mapproxy-seed, TileMill, QTiles. Процесс создания тайлового кэша называется сидированием (seeding) и заключается в нарезке растров на каждом масштабном уровне на тайлы заданного размера. Данная процедура весьма требовательна к объёму жесткого диска и может занимать очень много времени. Например, время создания тайлового кэша на территорию Казахстана вплоть до 16 масштабного уровня (профиль global-mercator) при средней наполненности слоёв составляет 2-3 дня, поэтому на практике данный способы используется для подготовки кэшей карт небольших территорий или для создания кэшей определённых масштабных уровней.
Чтобы разобраться с тем, как организована работа современных тайловых серверов (TileCache, MapProxy, tWMS) (фактически работающих в смешанном режиме), попытаемся написать собственный динамический TMS-сервер.
[править] Архитектура динамического TMS-сервиса
Логику любого динамического TMS-сервиса можно упрощённо представить в виде следующей схемы:
Из данной схемы следует, что для создания сервиса необходимы инструменты, позволяющие следующее:
[править] Выбор инструментов
Для решения 1 и 5 задачи подходит любой Веб-фреймворк. Поскольку наши требования к его функциональности достаточно скромные, то нет нужды использовать что-то вроде Django или Pyramid, вполне можно обойтись любым микрофреймворком, таким как Flask или Bottle. Остановимся на последнем.
2-я задача довольно простая, решим её самостоятельно без привлечения сторонних библиотек.
Для решения 3-й и 4-й задачи воспользуемся Mapnik-ом. Заметьте, что Mapnik в данном случае выступает не только в роли рендерера, но и в роли библиотеки, умеющей извлекать данные из хранилища. Полный список форматов, которые умеет читать Mapnik, доступен здесь. Mapnik вообще очень универсальный инструмент, позволяющий, в частности, отрисовывать объекты и без предоставления прямого доступа к хранилищу.
[править] Установка и настройка Mapnik
Mapnik присутствует в репозиториях Debian GNU/Linux 7.0 и поэтому его установка сводится к выполнению следующей команды:
Информацию об установке Mapnik на другие платформы можно найти на странице Mapnik Installation.
Чтобы убедиться в том, что Mapnik установился успешно, выполните команду (в используемой версии Debian модуль называется mapnik2, в других версиях или на других платформах может быть использовано имя mapnik):
Если в ответ на эту команду не последует никаких сообщение об ошибках, значит Mapnik установился корректно.
Создадим файл mapnik-config.xml и поместим в него следующее содержимое:
Проверим, что наш *.xml файл составлен корректно. Для этого в той же директории создадим файл test.py и поместим в него следующий код:
После чего выполним его:
Представленный код считывает настройки Mapnik-а из файла mapnik-config.xml и отрисовывает карту в файл altay.png, расположенный в этой же директории. Откройте его (если операция выполняется на сервере без графического интерфейса, то просто сделайте симлинк в директорию /var/www/ и откройте изображение в браузере), он должен выглядеть следующим образом:
[править] Установка Bottle
Подробнее об установки Bottle здесь.
Мы создали директорию tms с ключом —system-site-packages. Это сделано для того, чтобы в виртуальном окружении были доступны системные библиотеки, в частности Mapnik.
Установим HTTP-сервер Waitress:
[править] Создание собственного TMS-сервера
Переходим в директорию нашего виртуального окружения tms:
и создаём в ней файл tms.py, в котором и будет располагаться код будущего TMS-сервера.
[править] Извлечение координат тайла из URL
В Bottle, как и в большинстве подобных фреймворков, присутствует удобный механизм диспетчеризации URL (роутинг), основанный на принципе сопоставления. Более подробную информацию можно найти в документации. Данная возможность позволяет по виду URL выбрать необходимую функцию, которая будет обрабатывать поступивший запрос, поэтому прежде всего нам нужно определится каким образом будет выглядеть URL запрашиваемого тайла. Согласно спецификации URL тайла должен выглядеть следующим образом:
Открываем файл tms.py и пишем в него:
Согласно представленному коду любой URL, имеющий шаблон:
Таким образом на данном этапе мы имеем функцию tms, внутри которой доступны значения масштабного уровня, координат тайла и типа сервиса.
[править] Получение охвата тайла в единицах измерения карты
Чтобы вычислить охват тайла в единицах измерения карты, вначале нужно определить размеры самого тайла. Согласно статье Основы конфигурирования тайловых сеток размер одного тайла на z-м масштабном уровне равен:
Зная информацию о координатах начала отсчёта тайловой сетки (minx, miny) легко посчитать охват любого тайла в единицах измерения карты. Предположим, мы хотим определить охват тайла (3,2). Для наглядности воспользуемся следующим рисунком:
Тогда искомый охват запишется следующим образом:
Или в общем виде для тайла (i,j):
Для тайловой сетки с перевёрнутой осью y, имеющей начало отсчёта в точке (minx, maxy) охват тайла будет вычисляться несколько иначе:
Охват карты, которую мы будем рендерить нашим сервисом (можно подсмотреть в статье Основы конфигурирования тайловых сеток):
Отразим всё выше сказанное в виде Python-кода, поместив его внутрь функции tms:
[править] Отрисовка тайла
После того как мы вычислили интересующий нас охват, мы должны извлечь интересующие данные из хранилища. Но поскольку мы решили использовать Mapnik, который умеет напрямую работать с хранилищем PostGIS, то этот этап будет выполняться автоматически «за кадром». Добавляем следующий фрагмент кода в нашу функцию tms:
[править] Запуск сервера
Запускаем наш сервер:
[править] Результаты работы
Запрашиваем тайлы по различным URL и смотрим, что получилось.
TMS-система: что это и как выбрать подходящую?
Управлять грузоперевозками можно по-разному. Кто-то до сих пор обходится электронными таблицами, а кто-то следит за грузами через ERP-систему. Однако функционала большинства подобных систем часто не хватает, чтобы полноценно управлять логистикой в компании.
Оптимальное решение – интегрировать ERP-систему с TMS (transportation management system – системой управления грузоперевозками). В этой статье вы поближе познакомитесь с понятием TMS-системы: что это такое и по каким критериям стоит подбирать вариант для компании.
Что такое TMS?
TMS – важная часть управления цепью поставок. Это набор инструментов, который позволяет поставщикам, перевозчикам и заказчикам автоматизировать логистические процессы, сокращать расходы на перевозки и экономить время.
Качественная TMS дает компании следующие преимущества, помогая:
Почему выбрать подходящую TMS-систему сложно?
Сложности при выборе TMS-системы примерно те же, что и при выборе любого другого масштабного программного решения. Чтобы адекватно оценить трудозатраты и финансовые вложения, нужно время, и сторонам не всегда удается договориться из-за недопонимания.
Дело в том, что представители отдела, которому требуется программное решение (в данном случае – отдела транспортной логистики), зачастую достаточно далеки от сферы IT. Поэтому требования к ПО сотрудники формулируют своими словами, а разработчик не всегда погружен в бизнес компании. Из этой ситуации есть два выхода:
Как выбрать TMS-систему?
Сейчас с цепями поставок по всему миру работают десятки TMS-систем: от международных гигантов вроде SAP и Oracle до небольших решений от стартапов. Их количество растет все быстрее, поэтому отталкиваться стоит не от раскрученного бренда, а от функционала системы и задач компании.
Вот 5 критериев, по которым мы рекомендуем выбирать TMS-систему.
1. Облачные технологии
Большинство современных TMS-систем работают с облачными технологиями. Это позволяет участникам цепи поставок оперативнее получить доступ к процессам и качественнее синхронизирует данные, а работа с грузоперевозками становится значительно прозрачнее.
Но есть нюанс: прежде, чем внедрить облачную TMS, убедитесь, что ее серверы расположены на территории России – этого требует законодательство РФ. В обратном случае у компании могут возникнуть проблемы, если органы надзора решат провести проверку.
2. Гибкость
TMS-система – это не «коробочное» решение, которое достаточно внедрить и запустить. У каждой компании своя специфика грузоперевозок, поэтому одна и та же система может работать для двух клиентов совершенно по-разному. Поэтому при выборе TMS-системы важно понимать, готовы ли разработчики подстроить ее под задачи компании.
Стоит также убедиться, что разработчики будут постоянно поддерживать и совершенствовать продукт. Некоторые ограничиваются внедрением TMS и стартовыми доработками, после чего закрывают проект и оставляют исходники у себя. Компания в таком случае уже не сможет поменять функционал системы, если логистические процессы изменятся в будущем.
3. Функционал «из коробки»
В продолжение вышесказанного: функционал, который TMS предлагает на старте, тоже важен при выборе системы. Разработчики не всегда готовы кардинально переработать механизм TMS или добавить новый модуль, без которого обходились все предыдущие клиенты.
К примеру, одна из важнейших опций качественной TMS – маршрутизация. Многие системы не предлагают ее на старте, вместо этого разработчики настраивают обычное отслеживание груза из пункта А в пункт Б. Однако это не поможет водителю построить маршрут, перестроить его из-за непредвиденных обстоятельств или рассчитать расход топлива.
4. Компетентность сотрудников
Как уже говорилось выше, создатели TMS-системы должны понимать не только собственный продукт, но и разбираться в бизнес-процессах клиента. Недопонимание между разработчиками и логистами во время сотрудничества так же опасно, как и на старте.
Например, если отдел логистики ведет статистику на уровне продукта, ему нужно получать данные о каждом бренде отдельно: отслеживать счета, накладные и так далее. Разработчики TMS должны понимать, сможет ли система обеспечить подобную детализацию.
5. Сроки
Внедрение TMS-системы – трудозатратный и долгий процесс. На первый взгляд может показаться, что чем быстрее заработает новое решение, тем лучше для компании. Но это не так.
Если разработчик называет слишком короткий срок (например, 2-3 месяца), велика вероятность, что они предложат «коробочное» решение и не станут погружаться в бизнес-процессы. И наоборот: если внедрение занимает около года, это слишком долго.
Хороший средний показатель – 5-7 месяцев.
Какую TMS-систему выбрать?
Облачных TMS с серверами в России не так много. Один из наиболее оптимальных вариантов – система Artlogic. Она обеспечивает полный и прозрачный контроль над логистическими процессами и позволяет снизить расходы на грузоперевозки на 10-15%.
На данный момент Artlogic пользуются такие крупные игроки российского сегмента FMCG, как Johnson & Johnson и Bacardi.
Пользуется ли ваша компания TMS-системой или только планирует ее внедрить? Расскажите об этом в комментариях и поделитесь статьей с коллегами. Также рекомендуем подписаться на обновления нашего блога, чтобы не пропустить новые полезные материалы о логистике и грузоперевозках.
Основы работы динамических TMS-сервисов
Содержание
Введение
Для создания тайлового кэша существует различное программное обеспечение, например, утилиты gdal2tiles и mapproxy-seed, TileMill, QTiles. Процесс создания тайлового кэша называется сидированием (seeding) и заключается в нарезке растров на каждом масштабном уровне на тайлы заданного размера. Данная процедура весьма требовательна к объёму жесткого диска и может занимать очень много времени. Например, время создания тайлового кэша на территорию Казахстана вплоть до 16 масштабного уровня (профиль global-mercator) при средней наполненности слоёв составляет 2-3 дня, поэтому на практике данный способы используется для подготовки кэшей карт небольших территорий или для создания кэшей определённых масштабных уровней.
Чтобы разобраться с тем, как организована работа современных тайловых серверов (TileCache, MapProxy, tWMS) (фактически работающих в смешанном режиме), попытаемся написать собственный динамический TMS-сервер.
Архитектура динамического TMS-сервиса
Логику любого динамического TMS-сервиса можно упрощённо представить в виде следующей схемы:
Из данной схемы следует, что для создания сервиса необходимы инструменты, позволяющие следующее:
Выбор инструментов
Для решения 1 и 5 задачи подходит любой Веб-фреймворк. Поскольку наши требования к его функциональности достаточно скромные, то нет нужды использовать что-то вроде Django или Pyramid, вполне можно обойтись любым микрофреймворком, таким как Flask или Bottle. Остановимся на последнем.
2-я задача довольно простая, решим её самостоятельно без привлечения сторонних библиотек.
Для решения 3-й и 4-й задачи воспользуемся Mapnik-ом. Заметьте, что Mapnik в данном случае выступает не только в роли рендерера, но и в роли библиотеки, умеющей извлекать данные из хранилища. Полный список форматов, которые умеет читать Mapnik, доступен здесь. Mapnik вообще очень универсальный инструмент, позволяющий, в частности, отрисовывать объекты и без предоставления прямого доступа к хранилищу.
Установка и настройка Mapnik
Mapnik присутствует в репозиториях Debian GNU/Linux 7.0 и поэтому его установка сводится к выполнению следующей команды:
Информацию об установке Mapnik на другие платформы можно найти на странице Mapnik Installation.
Чтобы убедиться в том, что Mapnik установился успешно, выполните команду (в используемой версии Debian модуль называется mapnik2, в других версиях или на других платформах может быть использовано имя mapnik):
Если в ответ на эту команду не последует никаких сообщение об ошибках, значит Mapnik установился корректно.
Создадим файл mapnik-config.xml и поместим в него следующее содержимое:
Проверим, что наш *.xml файл составлен корректно. Для этого в той же директории создадим файл test.py и поместим в него следующий код:
После чего выполним его:
Представленный код считывает настройки Mapnik-а из файла mapnik-config.xml и отрисовывает карту в файл altay.png, расположенный в этой же директории. Откройте его (если операция выполняется на сервере без графического интерфейса, то просто сделайте симлинк в директорию /var/www/ и откройте изображение в браузере), он должен выглядеть следующим образом:
Установка Bottle
Подробнее об установки Bottle здесь.
Мы создали директорию tms с ключом —system-site-packages. Это сделано для того, чтобы в виртуальном окружении были доступны системные библиотеки, в частности Mapnik.
Установим HTTP-сервер Waitress:
Создание собственного TMS-сервера
Переходим в директорию нашего виртуального окружения tms:
и создаём в ней файл tms.py, в котором и будет располагаться код будущего TMS-сервера.
Извлечение координат тайла из URL
В Bottle, как и в большинстве подобных фреймворков, присутствует удобный механизм диспетчеризации URL (роутинг), основанный на принципе сопоставления. Более подробную информацию можно найти в документации. Данная возможность позволяет по виду URL выбрать необходимую функцию, которая будет обрабатывать поступивший запрос, поэтому прежде всего нам нужно определится каким образом будет выглядеть URL запрашиваемого тайла. Согласно спецификации URL тайла должен выглядеть следующим образом:
Открываем файл tms.py и пишем в него:
Согласно представленному коду любой URL, имеющий шаблон:
Таким образом на данном этапе мы имеем функцию tms, внутри которой доступны значения масштабного уровня, координат тайла и типа сервиса.
Получение охвата тайла в единицах измерения карты
Чтобы вычислить охват тайла в единицах измерения карты, вначале нужно определить размеры самого тайла. Согласно статье Основы конфигурирования тайловых сеток размер одного тайла на z-м масштабном уровне равен:
Зная информацию о координатах начала отсчёта тайловой сетки (minx, miny) легко посчитать охват любого тайла в единицах измерения карты. Предположим, мы хотим определить охват тайла (3,2). Для наглядности воспользуемся следующим рисунком:
Тогда искомый охват запишется следующим образом:
Или в общем виде для тайла (i,j):
Для тайловой сетки с перевёрнутой осью y, имеющей начало отсчёта в точке (minx, maxy) охват тайла будет вычисляться несколько иначе:
Охват карты, которую мы будем рендерить нашим сервисом (можно подсмотреть в статье Основы конфигурирования тайловых сеток):
Отразим всё выше сказанное в виде Python-кода, поместив его внутрь функции tms:
Отрисовка тайла
После того как мы вычислили интересующий нас охват, мы должны извлечь интересующие данные из хранилища. Но поскольку мы решили использовать Mapnik, который умеет напрямую работать с хранилищем PostGIS, то этот этап будет выполняться автоматически «за кадром». Добавляем следующий фрагмент кода в нашу функцию tms:
Запуск сервера
Запускаем наш сервер:
Результаты работы
Запрашиваем тайлы по различным URL и смотрим, что получилось.
Звезда TMS
Считается, что системы управления транспортировками (Transportation Management Systems, TMS) входят в класс систем управления цепями поставок (Supply Chain Management, SCM), которые, в свою очередь, являются частью систем управления предприятиями (Enterprise Resource Planning, ERP). Хотя вопрос о соотношении систем различных классов достаточно сложный и неоднозначный…
Нам представляется, что рынок информационных систем – это бесконечная вселенная, живущая по своим правилам. В ней появляются и исчезают планеты, звезды и целые системы, а для удобства ориентирования выделяются созвездия. Как раз сейчас мы рассматриваем созвездие SCM – систем (рис. 1), предназначенных для управления цепями поставок, которые делятся на SCE (системы исполнения цепей поставок) и SCP (системы планирования цепей поставок). В планирование цепей поставок входят решения по прогнозированию, планированию материальных потоков и оптимизации цепей поставок, а исполнение цепей поставок включает в себя системы управления складом (WMS-системы), системы управления глобальными торговыми операциями (GTM-системы) и системы управления транспортировками (TMS-системы) – нашу самую яркую звезду в этом созвездии… А где-то далеко-далеко светится ERP, которая в данной, безусловно удобной классификации является фактически параллельной вселенной (хотя практически, конечно, это не так, ведь сквозной бизнес-процесс, ведущий к светлой цели быть №1 или входить в Top-10, пролегает и через TMS, и через ERP, затрагивая СX и множество других интересных точек).
Магический квадрант
Что же такое TMS-системы? Это класс информационных систем, которые отвечают за планирование и исполнение физического перемещения груза через всю цепь поставок. Чтобы получить представление о рынке этих систем, давайте посмотрим на так называемый «магический квадрант» Gartner, посвященный TMS-системам (рис. 2).
Независимое аналитическое агентство Gartner фокусируется в своем исследовании на тех информационных системах по управлению транспортировками, которые поддерживают сквозной процесс управления транспортными операциями, используя различные схемы отгрузок, включая автомобильные, железнодорожные, интермодальные перевозки, авиа- и морские перевозки, мультимодальные перевозки, перевозки с использованием собственного или стороннего парка транспортных средств. При этом системы должны работать как с крупными, так и с мелкими грузами, до уровня посылок. Отметим также, что, как правило, компании-поставщики и потребители транспортных услуг используют TMS-решения для управления процессами по закупке транспортных услуг на долгосрочный период, планирования и исполнения перевозок и расчетов с контрагентами. Возможны дополнительные функциональные возможности, которые позволяют повысить как эффективность планирования за счет консолидации загрузки транспортных средств, маршрутизации, выбора вида транспортировки и перевозчика и т. п., так и качество исполнения — например, помогают проводить тендеры на перевозки, отслеживать перевозки и выверять расчеты с контрагентами.
«Магический квадрант» Gartner, которым это агентство иллюстрирует свои аналитические отчеты о различных классах информационных систем, устроен так, что в левый нижний сегмент попадают нишевые игроки, в левый верхний — претенденты на лидерство, в правый нижний — дальновидные игроки, так называемые визионеры, а в правый верхний — наиболее комплексные системы по функциональным возможностям и полноте стратегии развития, т. е. лидеры рынка. При анализе TMS-систем Gartner исследует такие параметры, как «широта» и «глубина» TMS-решений, их удобство и возможность адаптации под требования конечных пользователей, возможность поддержки сквозного процесса SCE-платформы, партнерская экосистема, качество и объем внедрений, глобальная стратегия развития решения и вывода его на рынок.
Как видите, именно Oracle Transportation Management с точки зрения Gartner является абсолютным лидером рынка на данный момент.
Выбор решения
Каждая компания, ставя перед собой стратегические цели по развитию бизнеса, рано или поздно сталкивается с задачей выбора информационной системы для автоматизации деятельности компании с целью повышения эффективности ведения бизнеса, минимизации затрат и повышения качества предоставляемых услуг. Но достаточно ли для получения ожидаемого результата просто автоматизировать бизнес-процессы или же необходимо учитывать иные факторы, влияющие на эффективность работы каждой компании?
Когда вы выбираете информационную систему, то основным заказчиком являются бизнес-пользователи компании, которые будут в конечном счете основными пользователями системы. При этом необходимо привлекать департамент информационных систем, чтобы понять, как будущая информационная система будет встроена в единый ИТ-ландшафт компании.
Процесс выбора информационной системы можно сделать одно- или двухшаговым. Одни компании предпочитают сначала выбирать разработчика информационной системы с точки зрения своих бизнес-требований, после чего рассматривают его партнерскую сеть на предмет выбора подрядчика. Другие компании стараются в рамках одного процесса выбрать и поставщика информационной системы, и исполнителя. Существует стандартный процесс выбора информационных систем, состоящий из восьми этапов и занимающий, как правило, несколько месяцев. Вот эти этапы.
А ведь вышеприведенный список лучше бы не сокращать, а, напротив, расширить. Во-первых, большую пользу могут принести так называемые референс-визиты или референс-звонки к успешным клиентам, уже внедрившим интересующие вас решения. Во-вторых, имеет смысл попросить партнеров разработать демо-примеры по предварительно предложенному сценарию. Но здесь важно чувство меры: не имеет смысла требовать включить в демо-пример всю функциональность решения и все свои процессы. Лучше определить критически важные для вас аспекты и сосредоточиться на них. Наиболее выигрышные моменты своей системы поставщик решения не забудет показать в любом демо-процессе. Также можно провести предварительное обследование предприятия своими силами или силами партнеров/вендоров. Результатом такого обследования, как правило, является определение целевой архитектуры информационной системы с учетом задач и узких мест процессов компании, последовательности внедрения и высокоуровневой оценки выгод для бизнеса. Например, специальная бесплатная программа предварительного обследования есть у Oracle (Oracle Insight).
Oracle Transportation Management
Как для предварительного анализа рынка, так и для непосредственного ознакомления с решениями вы можете взять на вооружение «эталонный» список возможностей TMS-решений, которым пользовалось агентство Gartner при составлении своего отчета.
Разберем лишь самые интересные возможности. Например, инструмент Oracle In-Memory Logistics Command Center — стратегическое моделирование транспортной сети — предоставляет средства для выполнения быстрого моделирования альтернативных сценариев логистической сети с использованием реальных оперативных данных, правил и ограничений. Инструмент Oracle In-Memory Logistics Command Center, полностью интегрированный с Oracle Transportation Management, как раз позволяет оптимизировать работу логистических операций, пользуясь анализом «что, если» (рис. 3).
Oracle In-Memory Logistics Command Center и Oracle Transportation Management построены на единой схеме данных — управляют одной и той же нормативно-справочной информацией, одинаковыми бизнес-объектами, заказами, перевозками. Logistics Command Center загружает всю схему операционной логистической сети и проигрывает анализ сценария «что, если» — например: что, если у перевозчиков тарифы повысятся на 20 %.
Очень красивая функциональность — оптимизация загрузки с помощью 3D-моделирования. Oracle Transportation Management содержит шаблоны загрузки и ориентации груза в трейлере, позволяя планировать оптимальную загрузку транспорта. Например, решение просчитывает, какая будет загрузка транспортного средства, процент утилизации транспортного средства с учетом ограничений и правил размещения груза вертикально вдоль или поперек, горизонтально вдоль или поперек, в ширину или в длину (рис. 4).
Инструменты базовых настроек решения позволяют настроить разные параметры пользовательского интерфейса: язык (поддерживаются 16 языков), единицы измерения (вес, объем, длина, ширина, скорость, расстояние), форматы данных, валюту и т. д. Мобильная версия решения также поддерживает локальные настройки.
Все эти возможности реализованы Oracle в рамках единой платформы, решение построено на современных интернет-технологиях, обеспечивая максимальную гибкость и масштабируемость системы.
Отдельно хочется отметить доступность данного решения как облачной услуги Oracle Transportation Management Cloud. В высококонкурентной среде компании все чаще начинают детальнее просчитывать совокупную стоимость владения информационных систем, и многие клиенты Oracle уже воспользовались услугой использования системы по подписке, которая позволяет исключить большие инвестиции на начальном этапе внедрения системы, сократить цикл внедрения и минимизировать риски по сопровождению системы.
Работа над ошибками
Попытка начать исследование рынка уже на этапе презентации и демонстрации — не единственная ошибка, часто встречающаяся при выборе решений. Другая проблема появляется, когда заказчики пытаются найти универсальную систему, которая решит все проблемы. Например, заказчик может включить в список требований к TMS-системе вспомогательную функциональность управления ремонтами транспортных средств, которая обычно входит в ERP-систему, а именно в блок управления активами предприятия, техобслуживанием и ремонтами.
Еще две взаимосвязанные ошибки — отсутствие ИТ-стратегии и отсутствие согласованности информационной системы и бизнеса. Нельзя выбирать бизнес-систему — в данном случае TMS-систему — без привлечения соответствующего бизнес-подразделения, т. е. логистического отдела. Кроме того, при выборе бизнес-системы нужно понимать, каким станет ИТ-ландшафт предприятия после внедрения системы и как он будет изменяться в своем развитии, более того, нужно понимать, куда вообще идет бизнес этой компании.
Также следует помнить, что управление транспортировками – сквозной процесс, поэтому система должна поддерживать отраслевые стандарты и иметь открытые интерфейсы для легкости ее интеграции с другими системами компании, например системами исполнения заказов сбыта, финансовыми системами, системами управления взаимоотношениями с клиентами и т. д. Недостаточная проработанность вопросов интеграции до выбора системы — причина того, что на многих проектах до 30 % затрат могут составлять затраты на интеграцию систем.
И еще одна серьезная ошибка — неверная оценка срока выбора системы, которая может быть как слишком оптимистичной, так и, напротив, «резиновой». Срок должен быть четким и адекватным.
Мы надеемся, что теперь вы готовы к выбору TMS-системы, не будете повторять чужих ошибок и сможете правильно выбрать и внедрить звезду TMS, которая засияет на вашем ИТ-небосклоне.