Почему ОТМ? Часть 4 — Экспедиционная

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

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

1266554285_3

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

Суть вопроса.

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

attachment-php-attachmentid-29803-stc-1-d-1309201180

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

Покупка_Продажа1

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

Как определить цену?

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

p_1323123660_1323123693

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

6(1)

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

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

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

Как будем делить наши деньги?

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

Сделка

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

За спрос денег не берут!

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

sledstvie-vedut-kolobki-serija-11339186344-4fd25ca88eb94

Зачем это нужно? Чтобы не оставлять историю переговоров с клиентом в электронной почте и блокнотах отдельных сотрудников, а фиксировать основные моменты в некоем формализованном виде, чтобы при необходимости подвергнуть накопленную базу разностороннему анализу. С этого и начинается построение эффективной CRM системы для экспедитора. Самая главная мысль здесь в том, что CRM система в логистике неотделима от оперативной деятельности и является важной ее частью, а особенно радует то, что мысль эта нашла отражение в ОТМ, в частности в объекте Запроса (Quote).

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

medium_ad3fe6003a631fc31f30feb3dffdd0b3

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

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

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