В апреле мне довелось выступить на AppsForum 2012 с докладом о долгожданном и очень востребованном сегодня модуле ОТМ — Fleet Management. Модуль управления парком транспортных средств стал логичным развитием функциональности системы начиная с версии ОТМ 6.0. Сейчас, к версии 6.2 модуль начинает приобретать законченный вид и по моему опыту работы с рядом клиентов вполне отражает актуальные задачи управления как авто, так и железнодорожным парком.
Универсальные инструменты позволяют создать любое специализированное решение и одинаково успешно выстраивать процессы относительно тягачей и прицепов или контейнеров и платформ, либо вагонов. Модуль управления парком интегрируется в базовые процессы ОТМ на всех этапах – от заказа до оплаты и позволяет добавлять функции, необходимые для работы с собственным транспортом в случае необходимости его привлечения. Таким образом используется единый подход как к собственным, так и привлеченным ресурсам, что позволяет комбинировать их наиболее выгодным образом при выполнении общего массива заказов.
Поступательное движение.
Если уж совсем честно, то Fleet Management в ОТМ не стал абсолютной новинкой последних версий, поскольку элементы управления подвижным составом были в ОТМ всегда и при умелом использовании вполне успешно решали основные задачи собственного парка. Все началось, конечно, со справочника подвижного состава и его иерархической структуры, на которой потом и выстроилась вся логика.
Вложенность справочника позволяет детализировать подвижной состав до нужной степени — от профиля по виду транспорта до конкретных моделей и наконец единиц подвижного состава и всех их характеристик. При этом надо отметить, что в логике автоматического планирования и оптимизации ОТМ по-прежнему использует только определенный уровень детализации — группу ПС, где заданы вместимость, грузоподъемность, габариты и температурный контроль.
Когда начинается знакомство с возможностями оптимизации ПС в ОТМ как правило у всех возникает один и тот же вопрос — как именно и по каким алгоритмам происходит оптимизация? Ведь прежде чем начать доверять результатам, которые выдает система, нужно убедиться в том, что она «рассуждает» правильно.
На самом деле все не так уж сложно: в ОТМ всего два алгоритма оптимизации. Базовый алгоритм основан на сравнении веса и объема грузов с вместимостью и грузоподъемностью транспортного средства. ОТМ будет пытаться консолидировать груз, чтобы максимально заполнить, например, машину. Если одина машина заполнена — берем следующую, возможно уже меньшего размера. Разумеется система стремится уменьшить количество необходимых машин и берет максимально вместительные из тех, что возможны по данному направлению. Можно заранее определить, что, например, по городу нужно брать маленькие машины, а для региональной доставки — самые большие.
Этот алгоритм можно при желании дополнить и более интеллектуальным, а именно 3D-оптимизацией. Тогда ОТМ будет еще и учитывать внутренние габариты машины и размещать в ней грузовые места согласно их размерам — длине, ширине и высоте. Также есть и раличные варианты ориентации грузовых мест, например, для паллет есть всего два варианта как их можно повернуть в кузове. И наконец, нужно определить можно ли ставить паллеты одну на другую и какие при этом не страшно поместить в нижний слой.
В итоге можно долго играть с высотой паллет и загрузкой машины получая различные варианты:
Или вот так:
Как правило после отладки основных правил и ограничений загрузки получается некий стабильный результат и эти картинки в системе уже никто никогда не смотрит. Но вернемся собственно к управлению парком собственных транспортных средств.
В чем прогресс?
Разумеется вместе с новым модулем расширилась и справочная база, появились новые данные, на которых затем стоятся различные бизнес-функции. Кроме того что значительно расширилась карточка собственно транспортного средства, появились и такие полезные объекты как тягач, который может перемещаться отдельно от прицепа, и, конечно, водитель, без которого собственно далеко не уедешь.
Сам по себе факт отсутствия этих справочников можно было легко обойти. Например, на проекте в Техстройконтракте мы отлично завели водителей как контактные лица и назначали их на перевозки вручную. Точно также вручную действовали и с собственными полуприцепами — назначали их на рейс, а потом ничто не мешает дописать обновление статуса доступности и следующей ожидаемой точки. Одним словом сделать минимальную автоматизацию и «подсказки» для диспетчера можно даже на самых минимальных возможностях. Но надо признать, что это все из области скорее «информирования», а не «автоматизации».
Поэтому главное что нужно отметить в появившемся Fleet Management — это возможность создания как модели жизненного цикла транспортных средств, так и модели транспортной сети в разрезе транспортных ресурсов, которые доступны в различных ее точках.
В ОТМ можно создать свою модель жизненного цикла транспортных средств в привязке к точкам. Это реализуется с помощью создания групп, которые характеризуют состояние ТС и содержат те ТС, которые в данный момент времени находятся в этом состоянии. Правила перемещения ТС из одной группы в другую уже в процессе работы нужно настраивать индивидуально. По этим правилам будет определяться какие ТС сейчас доступны.
Функции массовой обработки позволяют оптимизировать назначение водителей и подвижного состава с учетом базовых критериев: доступность, удаленность, стоимость. Это и есть в буквальном смысле автоматизация, поскольку на входе у нас массив спланированных рейсов, который должен быть распределен по доступным ресурсам, а на выходе — уже готовые результаты назначения. Рейсы группируются по признаку выполнения одним водителем и транспортным средством. Маршрут каждого рейса дополняется данными о точках базирования транспортных средств и водителей и пустом пробеге, который добавляется при их назначении.
В итоге получаем примерно следующее:
Решение этой задачи — выстроить рейсы друг за другом таким образом, чтобы за свою рабочую смену водитель успел выполнить их как можно больше и как можно меньше при этом ездил «пустым».
В OTM маршрут конкретного рейса формируется динамически в процессе планирования в зависимости от географической удаленности точек друг от друга. При планировании подачи порожнего транспортного средства на склад и его возврата на базу есть возможность тарификации пустого пробега и оптимизации выбора доступных ТС по критерию минимизации стоимости.
В результате стало возможным решение такой традиционной железнодорожной задачи, как подбор оптимальной подачи с учетом наличия доступных вагонов на станции отгрузки:
При недостатке вагонов на текущей станции осуществляется подбор с соседних с учетом:
- Доступности вагонов на соседних станциях
- Удаленности станций базирования
- Стоимости перегона
- Стоимости возврата порожнего
После запуска автоматического назначения вагонов на 10 отправок с нашей станции мы получаем готовый вариант решения задачи — сколько вагонов и с каких соседних станций нужно перегнать, чтобы вывезти заявленный груз. При чем в нашем случае на наглядном примере видно, что ОТМ отдает предпочтение более близкой станции, т.к. стремится минимизировать пустые пробеги.
Решение этих на первый взгляд простых задач — эффективная езда по кругу с минимальными потерями времени и ресурса подвижного состава. Если на небольшом объеме, который легко охватить одним взглядом, это можно сделать и вручную, то когда счет идет на десятки и сотни рейсов в сутки, типичные шаги можно с уверенностью отдать ОТМ.