1. Учет рабочего времени с момента выхода на линию.

Применяются различные подходы организационного и технического характера, например, водители выполняющие заказные случайные перевозки обязаны по приходу на АТП открыть автомобиль и включить зажигание (возможно попутно завести, прогреть, продиагностировать готовность ТС). С организационной точки зрения это несложно и вполне оправданно, а с технической дает возможность учета по событию “Зажигание” четкий момент появления водителя на АТП. Заказ может поступить в течение дня, однако водитель таким образом уже зафиксирован на работе .

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

Третий пример: автомобили вообще не на АТП, а на отстое у места жительства каждого агента. В этом случае руководитель вообще не в состоянии никаким ручным методом зафиксировать время начала рабочего дня у агента, особенно, если агенты в 26 городах страны! В этом случае используется засечка момента начала рабочего дня на основе механизма пользовательских точек интереса. Это типичные проблемы больших торгово-производственных предприятий с региональным распределением торговых представителей (агентов).

2. Учет рабочих процессов на протяжении дня. Еще интересней (и сложнее) варианты использования функций GPSBOX для учета рабочих процессов внутри рабочего дня. На рис.1  показаны оплаченные перевозки грузовых такси. В течение дня автомобили могут быть заказаны несколько раз на мелкие заказы или единожды на весь день. В этом случае технологии используются уже для рассчета стоимости обслуживания (по факту). Алгоритм, который использует уже в программе 1С, основан на продолжительности (чч:мм) или протяженности (км) рейса, а также географическом месте начала и (или) окончания рейса — тарифные зоны. Учитываются даже тарифные зоны всех остановок ТС для особых случев и конфигураций рейсов. Эти данные поступают из системы GPSBOX  по каждому автомобилю, что позволяет осуществлять достоверный биллинг заказов и приводит к повышению доверия заказчиков.

Картинка также наглядно показывает загруженность автопарка и то какие ТС пользуются наибольшим спросом.

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

1. количество доставок/ посещений в день;
2. самая первая доставка дня/самое первое агентское посещение;
3. самая долгая, самая быстрая и средняя доставка/посещение;
4. суммарная длительность в доставках/посещениях и различные отношения ее к пробегу, к всему рабочему времени и т.п.

Если в некий отчетный период вы в состоянии приложить к этой статистике и финансовые показатели эффективности водителя/курьера или агента — вы можете эффективно управлять персоналом на основе реальных показателей. Это и должно быть целью любого руководителя!

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

Поэтому мы всегда подстраховываем этот процесс и можем создать такую БД ТД. Разработана полностью документированная методика, доступная Закзачику, благодаря которой БД порядка 200-1000 шт. точек доставки Заказчик может создать сам, ежеденевно уделяя процессу 40-60 минут. Кроме того, мы обладаем возможностями организовать процесс массовой обработки данных для больших БД ТД ( около 10 тыс. записей). Создание качественной базы данных ТД размерности около 10 тыс. записей занимает примерно 2-2.5 месяца.

методика создания и поддержки базы данных точек доставки описана и доступна пользователям Заказчика. Проводится обучение.

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

Кроме  того, в большинстве случаев в транспортном бизнесе точное местоположение  каждого клиента часто неизвестно сотрудникам клиента (логистам), хотя известно водителям. Этот парадокс* рождается из-за некачественного описания  используемых АДРЕСОВ, что оставляет место для неоднозначностей и ошибок. Водитель, обучаясь точкам доставки методом “проб и ошибок” в итоге знает куда везти оперируя десятками точек в день, однако руководящие им логисты, оперирующие тысячами точек виртуально, не в состоянии  знать где в точности  расположена каждая точка доставки. Это означает, что создать БД ТД с чистого листа без определнной методики они чаще всего не способны.

*) У этого парадокса есть и неприятная сторона: ведение бизнеса начинает полностью зависеть от знаний водителя, он, а не менеджмент логистики становится носителем знаний из-за который зависит качество доставки. Это зачастую делает невозможным элементарные действия по замене или увольнению водителей, не дает возможность управлять качеством процесса. Водитель становится малоуправляемым и искусственно переоцененным ресурсом компании.
p.s. Описание возможных проблем декодирования адресов выходят за рамки этого раздела,  некоторые будут собраны в разделе ошибки (ссылка).