Софтуер за управление на 10 камиона: какво се променя спрямо Excel

Накратко

При около десет камиона проблемът не е само в повече редове във файла. Едновременно се увеличават:

• поръчките;
• шофьорите;
• превозните средства;
• телефонните обаждания;
• промените;
• документите;
• хората, които трябва да знаят един и същ статус;
• рискът две решения да се припокрият.

Excel може да продължи да бъде отличен инструмент за анализ и подкрепа. Той става крехък, когато от него се изисква едновременно да бъде база данни, оперативен план, многопотребителска система, история, средство за комуникация и архив.

Десет камиона не са „два пъти“ по пет

Да приемем средно по три дейности за превозно средство:

• 5 камиона → около 15 дейности;
• 10 камиона → около 30 дейности.

Но нарастването на сложността не е линейно. С повече превозни средства се увеличават:

• пресичанията между наличностите;
• замените;
• часовите прозорци;
• комуникациите;
• възможностите за грешка;
• участващите хора.

Ако двама оператори променят плана, компанията трябва да знае коя информация е актуалната.

Основното ограничение на Excel: оперативната конкуренция

Съвременна споделена електронна таблица може да се редактира от няколко души. Следователно проблемът не е просто, че „Excel не е многопотребителски“. Въпросът е, че общата таблица не управлява автоматично значението на процеса.

Пример:

• Лука сменя шофьора на ред 38;
• Марта променя часа на същата поръчка;
• шофьорът получава промяната по WhatsApp;
• клиентът се обажда на трети колега;
• някой дублира реда, за да не загуби старата версия.

Файлът може да съдържа всичко, но не е задължително да прилага правила за:

• идентичност на поръчката;
• статус;
• роли;
• разпределения;
• версия;
• известия;
• отношения между обектите.

Софтуерът за управление създава структура около данните.

Планът трябва да се превърне в споделен статус

При десет камиона планът не може да бъде само графично представяне. Той трябва да е резултат от структурирани обекти.

Една поръчка трябва да съдържа:

• кой е клиентът;
• къде е товаренето;
• къде е доставката;
• кога;
• кое превозно средство е разпределено;
• кой шофьор е разпределен;
• в какъв статус се намира;
• какви оперативни промени са настъпили;
• кои документи са свързани, ако системата ги управлява.

Дневният план показва тези връзки. Той не трябва да е единственото място, където те съществуват.

Роли и отговорности

При малък автопарк всички може да се познават и да разговарят директно. Но с увеличаването на работата е полезно да се определи кой какво може да прави.

Минимален пример:

Оператор

• създава/редактира поръчки;
• планира;
• актуализира оперативните статуси.

Администрация

• преглежда приключените поръчки;
• намира необходимите референции и документи;
• не променя непременно плана за деня.

Шофьор

• вижда собствените си дейности;
• актуализира предвидените статуси;
• не вижда целия план или данните на други хора, ако не е необходимо.

Собственик/отговорник

• вижда общата картина;
• проверява показателите;
• управлява потребителите/разрешенията според продукта.

Ролите намаляват грешките и помагат също за спазване на принципа за достъп до данни според необходимостта.

Управление на изключенията без загуба на официалната версия

При десет камиона изключенията са нормални:

• закъснение при товарене;
• клиентът не работи;
• шофьорът не е на разположение;
• превозното средство е в сервиз;
• спешна поръчка;
• промяна на местоназначението;
• анулиране;
• липсващ документ.

Процесът трябва да различава разговор от решение.

Пример:

„Клиентът може да премести часа на 17:00“ е разговор.

„Разтоварването в 17:00 е потвърдено“ е оперативна информация, която трябва да се запише в официалния източник.

Ако и двете останат само в чат, човекът, който започва следващата смяна, трябва да възстанови контекста, като чете съобщения.

Комуникация с шофьорите

Повече камиони означават повече комуникация един към един. Система за шофьори или структуриран канал може да намали повтарящите се телефонни обаждания.

Полезна информация:

• последователност на дейностите;
• адреси;
• референции;
• часове;
• оперативни бележки;
• промени;
• статус на дейността.

Целта не е телефонът да бъде премахнат. Сложният проблем винаги ще изисква разговор. Целта е телефонното обаждане да не се използва като база данни.

Ако приложението обработва лични данни или геолокация, трябва да се оценят GDPR, принципите за свеждане на данните до минимум и, когато е приложимо, трудовите правила за дистанционно наблюдение. Тези оценки не зависят от броя камиони.

Данни и отчети, които стават полезни

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

Прости показатели:

Поръчки по клиент

Помага да се разберат търговските зависимости и обемите.

Поръчки по ден/седмица

Показва пиковете и организационния капацитет.

Препланирани дейности

Ако твърде много дейности се преместват всеки ден, може да има проблем с първоначалните данни, капацитета или процеса.

Изключения

Класифицирането на малък брой причини помага да се разбере дали повтарящите се проблеми са „чакане при клиента“, „превозно средство“, „непълна поръчка“, „промяна от клиента“ и т.н.

Липсващи документи

Ако работният процес включва POD/прикачени файлове, знанието какво липсва избягва търсенията в края на месеца.

Тези данни не заменят счетоводството, контрола на разходите или нормативните проверки, но подобряват оперативното управление.

Оперативна приемственост и зависимост от хората

Много полезен въпрос:

Ако утре човекът, който управлява файла, не дойде на работа, може ли колега да разбере деня за 10 минути?

Ако отговорът е не, компанията има организационен риск.

Цифровизацията трябва да намали знанията, които са „само в главата“ на някого, чрез:

• общи основни данни;
• прости правила;
• споделени статуси;
• история;
• индивидуален достъп;
• минимално документирани процедури.

Не е нужно да се създава бюрокрация. Достатъчни са няколко повтаряеми правила.

Кога Excel все още може да остане

Преминаването към софтуер за управление не означава забрана на Excel.

Excel остава отличен за:

• ad hoc анализи;
• бюджети;
• симулации;
• временни таблици;
• сверявания;
• експорти и проверки;
• персонализирани отчети.

Полезното разграничение е:

Софтуер за управление: текущ оперативен източник. Excel: инструмент за анализ/подкрепа.

Проблемът се връща, когато ръчно променен експорт отново се превърне в „истинската версия“ на плана.

План за преход за 4 седмици

Седмица 1 — картографиране и почистване

• изброяване на процесите;
• избор на необходимите полета;
• почистване на клиенти и обекти;
• почистване на шофьори и превозни средства;
• определяне на малък брой статуси.

Седмица 2 — конфигуриране и проба

• импортиране на основни данни;
• създаване на реални тестови поръчки;
• тестване на промени и анулирания;
• тестване на потребители и разрешения;
• проверка на експортите.

Седмица 3 — пилотна група

• 2–3 камиона или част от дейността;
• събиране на проблеми;
• коригиране на процедурите;
• избягване на ненужни персонализации.

Седмица 4 — дата на преминаване

• всички нови поръчки влизат в новата система;
• старият файл става временен оперативен архив/резервно копие, а не конкуриращ се източник;
• кратка ежедневна проверка за една седмица.

Сроковете са примерни: сложността, интеграциите и качеството на данните може да изискват много повече време.

Контролен списък: 10 камиона надраснаха ли Excel?

• Няколко души променят ли плана?
• Има ли конкуриращи се версии?
• Разпределенията изписани ли са като свободен текст?
• Промените за шофьорите остават ли в чатове?
• Трудно ли е да се разбере кои поръчки са отворени?
• Собственикът ли е единственият, който разбира файла?
• Трябва ли на шофьорите да се звъни за всеки детайл?
• Липсват ли роли и разрешения?
• Възстановяването на историята отнема ли часове?
• Няма ли последователен експорт/архив по клиент?
• Не се ли измерват повтарящите се изключения?

Ако много отговори са „да“, проблемът не е самото число 10: сложността е надраснала структурата на електронната таблица.