Чаще всего ОТМ воспринимается как прикладной инструмент для планирования и организация перевозок, в том числе путем прямого взаимодействия с поставщиками услуг. Вовлечение поставщиков на всех этапах может значительно повысить эффективность транспортной логистики и снизить трудозатраты самих экспедиторов. Но, с другой стороны, каждодневное взаимодействие с клиентами еще более важная составляющая экспедиторского бизнеса.
Рассказ о концептуальных моментах экспедирования в ОТМ можно найти в специальном посте Почему ОТМ? Часть 4 — Экспедиционная. А здесь речь пойдет о рутинных процессах взаиморасчетов с клиентами, от оперативности, прозрачности и точности которых во многом зависит уровень доверия к экспедитору и соответственно уровень удовлетворенности клиента. Итак, биллинг в ОТМ.
Внутри или снаружи?
Счет на оплату, который получает клиент транспортно-экспедиционной компании — это только вершина айсберга. За точным, обоснованным и своевременным счетом стоит отлаженная система приема и обработки заказа, тарификации с учетом всех условий договора и корректировок по факту исполнения перевозки. Выставление счетов — это неотъемлемая часть процесса экспедирования и, если говорить об автоматизации, взаиморасчеты с клиентами являются обязательной функцией системы управления перевозками (TMS — Transportation Management System). В случае с ОТМ функциональность взаиморасчетов как с поставщиками, так и с клиентами условно объединена в модуле Freight Payment, Billing and Claims. Почему условно? Потому что несмотря на то, что это отдельный модуль, сам по себе без базовой функциональности ОТМ он не работает, а является ее продолжением и логическим завершением.
Но ведь существует и отдельная категория систем для организации расчетов с клиентами — Billing System, а по-русски «биллинговая система» или «автоматизированная система расчётов». Можно даже предположить, что они совершенно универсальны и применимы в любом бизнесе безотносительно его специфики. Но это предположение довольно быстро отпадет, если разобраться для чего такие системы изначально создавались. Настоящие системы биллинга появились в сфере телекоммуникаций, где обслуживание огромного числа абонентов фиксированной и мобильной связи, интернета и цифрового телевидения просто невозможно без автоматизации массовых однотипных операций. При чем сами эти операции и тарифные сетки по таким видам услуг, как правило, довольно простые и односложные (по принципу «Вкл./Выкл»). Но ведь основное требование к таким системам не сложность и гибкость, а высокая производительность. Также системами биллинга можно с натяжкой назвать системы для розничной торговли, позволяющие оперировать огромной номенклатурой товаров, различными прайс-листами, а также системами скидок по акциям или программам поддержки лояльности покупателей.
Решения для биллинга, которые ориентированы на телекоммуникации или розничную торговлю, не могут в полной мере соответствовать необходимой для экспедирования специфике: сложные алгоритмы расчета тарифов, основанные на географии, расстояниях, зонах, физических параметрах груза; тарификация может зависеть от тарифов покупки (цен подрядчиков); момент выставления счетов определяется событиями исполнения перевозок. Все это возможности TMS.
Выделение биллинга в самостоятельную систему, с которой впоследствии придется интегрировать TMS, повлечет ряд сложностей и рисков как технического характера, так и функционального. С технической точки зрения единая система всегда надежней и предпочтительней чем несколько систем, объединенных через интеграцию. Тут, конечно, на меня могут с негодованием наброситься любители интеграционных шин и прочей обвязки, но с логикой не поспоришь: хотя средства интеграции становятся все лучше и, если подойти с умом, позволяют добиться почти незаметных обменов между системами, но если есть возможность их вовсе избежать, то однозначно стоит ее использовать. С функциональной точки зрения для создания полноценной системы тарификации и биллинга придется продублировать значительную часть функционала, изначально присущего TMS. Это серьезно усложнит архитектуру решения, перегрузив ее многоходовыми обменами между, как минимум, тремя системами: биллинг, транспорт и бухгалтерия. А если еще сюда прибавить CRM с вводом заказов, то я за такое рискованное предприятие даже не стала бы браться.
Одним словом, законное место расчетов с клиентами для экспедитора внутри TMS, а никак не снаружи. Далее предлагаю подробно рассмотреть как это работает внутри ОТМ.
Подбираем тариф
Если обратиться к толковому словарю, то термин «тарификация» — это вовсе не расчет стоимости, как можно подумать, а «определение тарифа на основе той или иной классификации объектов обложения или оплаты«. И на самом деле — в случае достаточно сложной тарифной базы с разнообразными сроками действия, условиями и базисами расценок поиск именно того тарифа, по которому нужно произвести расчет, превращается в отдельную задачу. В ОТМ она решается с учетом всевозможных ограничений и даже если вдруг их не хватает, то можно добавить свои собственные. Не раз говорила на презентациях для клиентов и напишу здесь: еще ни разу я не встречала тарифа, который невозможно было бы настроить в ОТМ. А настроив один раз дальше можно автоматизировать загрузку и обновление — все что нужно для поддержания тарифной базы в актуальном состоянии.
Актуальное состояние тарифной базы означает, что для обработки поступающих заказов будут подбираться только действующие тарифы, а устаревшие будут закрыты по срокам действия и их можно будет применить только для случаев пересчета заказов из прошлых периодов. Срок действия тарифа — это один из базовых фильтров, которые применяются при автоматической тарификации в ОТМ.
Также к базовым можно отнести фильтр по направлению («откуда-куда»), которое может задаваться на различных уровнях детализации географии: точка-точка, точка-регион, регион-регион и, наконец, страна-страна. Регион здесь — это транспортная зона или множество точек с, как правило, одинаковой стоимостью доставки до них. И, наконец, наибольший уровень абстракции — тарифы по тарифным зонам. Тарифная зона представляет собой перечень направлений между транспортными зонами. Объединение этих направлений в зону означает что по ним всем будет применяться одна тарифная сетка.
Тарифы по различным направлениям объединяются под тарифными соглашениями по видам услуг (это могут быть разные виды транспорта или разный уровень обслуживания одним и тем же видом транспорта, например, обычная автоперевозка или экспресс).
Клиент — это самый важный фильтр для экспедитора с точки зрения управления тарифной базой. Конечно, ОТМ позволяет вести свой набор тарифов под каждого клиента, но это совсем не то, чего нам хотелось бы с точки зрения управляемости, прозрачности и порядка. Гораздо разумнее сделать несколько версий одной и той же тарифной сетки, которые будут отличаться определенным набором условий: скидки, надбавки, наличие дополнительных услуг. Принципы создания этих «версий» могут быть очень разными, например, по категории клиента: обычный или привилегированный. Затем всю нашу клиентскую базу мы разбиваем на группы в зависимости от того, какая тарифная сетка должна применяться к их заказам. Некоторые особо важные клиенты останутся на индивидуальных тарифах, другие окажутся на неких общих, стандартных условиях, третьи — на общих, но более выгодных. Далее чтобы переключить клиента с одной базы на другую достаточно будет просто перевести его из одной группы в другую.
Если мы хорошо поработали над созданием тарифной базы, то для каждого заказа клиента ОТМ автоматически будет находить единственный актуальный и подходящий по всем условиям тариф.
После того, как нужный тариф найден, по нему остается рассчитать плановую стоимость перевозки. Поскольку тарифные базисы и конструктор формул в ОТМ — это весьма обширная тема, то лучше оставим ее для отдельного поста. А здесь продолжим с того места, когда из заказа спланировали перевозку, а в ней уже рассчитана стоимость всех услуг (основной и дополнительных).
Выпускаем по мере готовности
Итак, у нас уже есть детализированная стоимость и в теории уже прямо сейчас можно на основе перевозки выпустить счет, в который скопируется вся структура стоимости, а также пройдет начисление НДС.
Но обычно сразу никто счета не выпускает: во-первых, это приведет к неизбежным корректировкам по факту выполнения (хотя ОТМ умеет и это), а во-вторых, это не соответствует реальной практике, когда окончательные счета и акты выставляются по факту выполнения перевозки или даже еще позже.
Остается выяснить когда перевозку можно считать выполненной или, другими словами, когда возникает обязательство клиента перед экспедитором. Это может быть фактическое завершение перевозки (выгрузка на точке доставки), может быть момент передачи копий сопроводительных документов в электронном виде, а может — момент передачи оригиналов этих документов. По разным клиентам это могут быть разные события, при наступлении которых меняется соответствующий статус перевозки, а это уже и будет сигналом к автоматическому выпуску счета по этой перевозке.
Счета могут выпускаться в он-лайн режиме (сразу при смене статуса перевозки) или этот процесс можно поставить на график, например, раз в сутки будет производиться массовый выпуск счетов по перевозкам в определенном статусе по разным группам клиентов. И наконец, всегда можно перейти в полуавтоматический режим, когда пользователь с помощью различных фильтров создает необходимую выборку (за период, с определенным статусом, по одному или группе клиентов) и запускает по ней выпуск счетов. Этот вариант подойдет и для перерасчетов за прошлые периоды, когда нужно довыставить счета за дополнительные услуги, возникшие по факту.
Собираем воедино в нужный момент
Счета, которые мы получили на предыдущем этапе, — это не совсем то, что обычно выставляется клиенту, если только речь не идет об оплате единичной отправки. Чаще (при регулярных отправках) приходится иметь дело с консолидированным актом и счетом за определенный период. Значит эти «первичные» счета нужно объединить за неделю, месяц или иной промежуток времени и сформировать пакет документов на оплату: акт оказания услуг, реестр перевозок (детализация) к акту и счет.
Если период четко установлен (закреплен в договоре с клиентом), то достаточно один раз поставить на график процесс создания консолидированных счетов и в нужный момент документ всегда будет готов к отправке — клиенту по электронной почте, в личный кабинет и в учетную систему для регистрации факта оплаты. А если отправки нерегулярны, то в любой момент первичные счета за произвольный период можно собрать вручную воспользовавшись различными фильтрами.
Пожинаем плоды
А после проведения расчетов в учетной системе и разнесения полученных сумм оплат по этим счетам возможна передача информации об оплате обратно в ОТМ в виде статуса и/или суммы оплаты. Это полностью завершает цикл продаж и обеспечивает полный порядок во взаиморасчетах с клиентами. На основе объективных первичных данных можно строить отчеты о дебиторской задолженности, обновлять расчетные показатели, такие как оперативный баланс клиента. Но главным остается то, с чего мы начали — прозрачность выставляемых счетов и отсутствие ошибок, которые могут навсегда подорвать доверие клиентов и репутацию «культурного» и внимательного экспедитора.