Как стать автором
Обновить

Цифровая трансформация в логистике. Часть 1. Как за копейки контролировать расход топлива на 200 автомобилях

Уровень сложностиПростой
Время на прочтение3 мин
Количество просмотров1.7K
Всего голосов 7: ↑4 и ↓3+5
Комментарии15

Комментарии 15

 Как за копейки контролировать расход топлива на 200 автомобилях

Можно подробнее.

1) Сколько стоит система GPS+датчик в баке +система сбора и хранения данных с 200 автомобилей?

2) Сколько человек занималось данной задачей, сколько часов и какая у них зарплата?

3) Сколько времени ушло на привязку 1С?

4) Сколько всего получилось копеек?

На самом деле "бюджет 0", но внезапно

на каждом ТС стояла GPS-система, отслеживающая движение, и в каждом баке стоял датчик уровня топлива (ДУТ). Оба значения передавались постоянно.

напоминает известные анекдоты про миллионеров вида "сначала я очень успешно торговал семечками, а потом умерла тетя и оставила мне миллион долларов". :)

Наверное, хороший анекдот. Но в этом кейсе неприменим. В решении использовалось то, что уже было. С точки зрения экономики - затраты уже учтены в другой задаче несколько лет назад, повторно их учитывать некорректно. Но если взять за базу некую условную ситуацию, что ДУТ и GPS не было бы, то мы бы их купили и установили. И даже на 200 ТС в условиях такого крупного предприятия это в рамках погрешности месяца.

Поэтому да, бюджет 0, и семечками торговать не пришлось. Особенности учёта больших компаний.

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

  1. В предпоследнем абзаце стоимость указана. Если погуглить - от 20 тыс. за ТС. В компании из кейса платили больше, т.к. ставили несколько лет назад, под другие задачи, и предложений на рынке было меньше. Это за ТМЦ, работы, настройку и сопровождение. Хранение на стороне облачного решения. Им платили разово, немного, и опять же под другие задачи.

  2. Больше всего - лин-менеджер. Плюс эксперты и разработчик 1с. Если выделить время чисто под задачу - часов 100 суммарно. С учётом того, что задача в третьем приоритете, делалась несколько месяцев без отвлечения от основных, поэтому считать затраты на ЗП некорректно.

  3. Связь с 1с уже была. Тащили пробеги с GPS. Остальные 99% информации вежливо игнорировали.

  4. Дополнительных затрат, которые хоть как-то бы отразились на capex и opex, не было. С учётом размера компании и приоритета задачи, все было реализовано в пределах итак заложенных переменных затрат.

Вы не ответили на вопросы. Что все уже было это понятно. Но Вы заявляете это как продукт для других. А у других этого нет. Вы это делали вне основной работы. т е если бы не делали то бездельничали? А если не бездельничали, то тогда явно перерабатывали. В любом случае начальство не доглядело или ему наплевать , чем вы занимаетесь.

Но главные затраты будут в сопровождении этой системы. или вы это тоже делаете за копейки?

--------------------

Но пусть будет бесплатно.

Но в Вашем решении датчик в топливном баке - это лишнее. Все что Вы выявили можно определить по GPS. Более того можно реализовать это на смартфонах водителей. Тогда не надо вообще ничего на автомобили ставить.

Смарты - обманывают.

И как по ГСН посчитать реальный расход топлива?

Лет много назад, тут был цикл статей про железный ГСН и войну водителей с ним.

В Иваново, некоторые маршруты, особенно по выходным вечером, катаются исключительно виртуально по Яндекс.Картам, но реалистично: останавливаются на перекрёстках и остановках, переменная скорость.

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

Сопровождение на уровне - Восстановить, если источники данных отвалятся. За два года не отвалились.

Была идея считать расход через пробег по GPS, но сразу отказались. Он правильно считается при выполнении нормативов. По факту же внешних факторов уйма: температура воздуха, перегруз/недогруз, техсостояние ТС и далее по списку.

Несколько раз GPS программно отправлял ТС в Австралию. Почему - непонятно. Но средняя скорость у БелАЗа вырастала до 400 км/ч.

Ненадёжно. Поэтому данные забирали именно с ДУТ.

Смартфоны для GPS тоже нормальная история. Но их не было и это были бы разовые затраты. Тут было бы больше проблем с их обслуживанием, когда они начали бы ломаться. Это уже проходили. Конкретно в этом кейсе надежнее встроенные системы.

Относительно датчика в баке.

Я не против такого датчика, просто в вашей статье все примеры (где спали водители, где они были и что ели пили) это не про топливо. Все ваши примеры - это выявление аномалии в маршрутах, а не в расходе топлива. Если водитель спал то топливо не расходовалось. но и скорость движения равна нулю.

Относительно GPS. Сейчас в машинах ставят трекеры. Про смартфон я написал как вариант удешевить установку GPS и решить проблему сбора данных по системе IoT.

GPS приемник можно поставить внешний, если в смартфоне он плохой. Чтобы получить точные координаты надо ставить свои реперные станции.

----------------------

Данных чуть больше 1 миллиона в день. 72 тысячи строк на 15 параметров.

Это очень странно. У Вас не ракеты, а автомобили. Какие 15 параметров и 72 тысячи строк и миллион в день? Если Вы правильно сделаете систему сбора , то не будете захламлять эфир и забивать диски ненужными данными.

Навскидку:

Система GPS в среднем даст вам координаты с ошибкой 10 метров. Если Вы не используете эти данные для управления авто, то данные можно накапливать и предварительно обрабатывать на борту. При этом нет надобности передавать каждую точку координат. Значение расхода топлива можно передавать в среднем на км.

Нештатные ситуации для конкретной машины можно выявлять программой на борту и только в этом случае беспокоить диспетчера. В программу 1С все данные можно выгружать одним пакетом в конце смены через IoT. 200 пакетов в день для всех 200 авто.

В итоге нет надобности передавать и обрабатывать большие объемы данных.

Но объем этих данных настолько огромный, что разбор даже по одному ТС за смену занимал бы около часа. Куда уж тут разбираться со всеми. Нужно человек 30 на фултайм.

Не вижу ТЗ проблемы и алгоритма решённой проблемы.
Только абстрактное: сгруппировали, определили, нашли, подключили к 1С.

П.С. Топик ни о чём.

Количество семплов много больше размерности вектора признаков. Можно решать любым способом - хоть статистически, хоть ML-классификаторами

Статистически проще крутить куб любым способом, и смотреть вот это - водитель-аутлаер на средней машине, или машина-аутлаер. ML придется точить заранее на каждый из случаев.

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

А я прочел первую статью с интересом. И надеждой, что не последняя, так как мне интересны кейсы с логистикой пеших курьеров. Вдруг автор и про них что-то напишет интересного

Планировалась серия кейсов по авто и ж/д логистике в условиях крупных промышленных предприятий.

С курьерами не работал, но отдельно пофилософствовать можно. Решений много и некоторые хорошо адаптируются.

Заголовок не соответствует содержимому: "Цифровая трансформация в логистике". Цифровой трансформации здесь нет, только интеграция программного решения и автоматизация отчетности по движению ГСМ на основе данных с навигационного терминала и датчика уровня топлива. И это не логистика, это обычный мониторинг транспорта. Логистика решает вопросы планирования и маршрутизации (будущее), мониторинг - наблюдения в реальном времени (сейчас) и работу с историческими данными (прошлое): отчеты, сводки, дашборды. Тема очень интересная, но, к сожалению, в статье все очень поверхностно.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории