Автоматизация деятельности транспортно-экспедиционной компании

Наша программист сейчас в отпуске, когда выйдет будет заниматся внедрением технологии одного очень крупного ритейлера, так что увы, как вариант можете нанять за зарплату программера или привлечь его на оутсорсинг

Частично согласен. Разработчики стараются охватить максимально возможное число описания БП. Чтобы на вопрос потенциального заказчика «А это есть?» был положительный ответ.

Сегодня был на ТР-2013, посмотрел предложения по автоматизации деятельности. Для управления автопарком (такая у вас специализация?) есть готовое предложение, пользует парк колы с примерно 5 т ед техники. Название разработчика растворилось сразу после озвучки стартового пакета)))))

Пётр, вы абсолютно правы.

бОльшая часть компаний и отдельных технических специалистов смотрят на проблему глазами программиста.
Если грубо — «Функциональность есть — хорошо».
Мало кто задумывается об удобстве клиента и его бизнес-процессах.

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

Мы в разработке нашего решения ориентируемся именно на конечные бизнес-потребности клиентов.
Интеграция с системами трекинга делается не для «тучи всевозможных отчётов», а для упрощения контроля план-фактов, для сокращения трудозатрат сотрудников на оперативный контроль.
Например, пусть есть заказ с погрузкой в точке X, в 9.00, такого то числа.
Применяя классические системы трекинга, логист вынужден контролировать где находится конкретный водитель, сопоставлять где то в другом месте информацию по заказу, контактные данные и т.д.
А на самом деле, логисту требуется, для качественного выполнения своей работы, не мониторить водителя на карте, а обеспечить беспечить бесперебойность работы. И если случился сбой, то максимально оперативно этот сбой устранить.
То есть ПО должно не заставлять человека смотреть на карту, а уведомлять, если что то пошло не так — водитель задерживается под загрузку, движется не в нужном направлении.
То же самое и по топливу — нужен не отчёт, а контроль соответствия того, что потрачено ровно столько топлива, сколько и закуплено, и потрачено оно должно быть в рамках бизнес-задач, заказов.
ПО само должно уведомить контролирующего сотрудника, что «водитель Вася» заправил по топливной карте 500л, а в бак попало 400л.

Можно обсудить более подробно — буду рад ответить на вопросы.

Что же это у вас за объём такой? Тогда Access :0)