Софтуер за управление на 5 камиона: кои функции наистина са нужни

Накратко

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

Подходящият софтуер за управление не бива да превръща фирмата в мултинационална корпорация. Той трябва да гарантира шест неща:

1. всяка поръчка съществува само веднъж;
2. всички виждат коя версия е актуална;
3. камионът и шофьорът са свързани с дейността;
4. промяната не остава затворена в чат;
5. дейността може да бъде приключена и открита отново;
6. фирмата може да извлече собствените си данни.

Ако тези шест условия работят добре, за автопарк от пет камиона това вече е огромна крачка напред спрямо Excel + телефон + WhatsApp.

Защо 5 камиона вече са достатъчни, за да се изгуби контролът

Нека си представим обикновен ден:

• 5 камиона;
• 5 шофьори;
• 3 средни дейности на превозно средство;
• 15 дейности общо;
• 2 променени адреса;
• 1 закъснял клиент;
• 1 шофьор, който приключва по-късно от предвиденото;
• 1 спешна поръчка, добавена в 11:00.

Проблемът вече не е „да се запомнят 15 доставки“. Той е да се поддържат последователни всички връзки:

поръчка ↔ клиент ↔ адрес ↔ час ↔ камион ↔ шофьор ↔ статус ↔ документ

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

Минималната операционна система на автопарка

За автопарк от около пет камиона е полезно софтуерът да се мисли като споделено оперативно табло, а не като ERP.

Минималните области са:

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

Всичко останало идва след това.

1. Данни за многократна употреба

Ежедневното повторно въвеждане на едни и същи данни е източник на грешки.

Системата трябва да позволява да се запазят поне:

Клиент

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

Място за товарене/доставка

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

Шофьор

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

Превозно средство

• регистрационен номер или идентификатор;
• тип;
• характеристики, нужни за планирането;
• наличност.

Все пак основните данни не бива да се превръщат в безразборно хранилище на лични данни. Събирайте това, което е необходимо за процеса, и управлявайте отделно данните/документите, които изискват различна защита или цели.

2. Структурирани поръчки

Всеки превоз трябва да има разпознаваем запис.

Практични полета:

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

Записът трябва да различава постоянната информация от временните бележки. Ако „разтоварване на порта 3“ винаги важи за този обект, това може да е информация в основните данни. Ако важи само днес, то принадлежи към поръчката.

3. Дневен план

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

Полезният изглед веднага отговаря:

• какво все още трябва да се назначи?
• какво ще прави всеки камион?
• кой шофира?
• каква е последователността?
• кои дейности имат критични часове?
• кои са променени?
• кои са завършени?

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

4. Свързани шофьори и превозни средства

Да се напише „Mario / 123AB“ в бележка е различно от това реално да се назначат обект шофьор и обект превозно средство.

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

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

За нормативните проверки обаче фирмата трябва да продължи да използва данните и системите, изисквани от приложимите правила, включително тахографа, когато това се изисква.

5. Комуникиране на промените

Истинската стойност се появява, когато нещо се промени.

Ако клиентът премести доставката от 14:00 на 16:00, идеалният процес е:

1. офисът актуализира поръчката;
2. планът отразява новата информация;
3. шофьорът получава/вижда актуализацията в предвидения оперативен канал;
4. промяната остава проследима, ако системата пази история/одитни данни;
5. не съществуват две конкуриращи се версии.

WhatsApp може да продължи да се използва за разговори и спешни случаи, но не бива да е единственият архив на оперативното решение.

6. Статус и приключване на дейността

Едно МСП трябва да определи малко на брой ясни статуси.

Пример:

за планиране → планирано → назначено → в ход → завършено

Добавяйте статуси само ако имат реални оперативни последици, например „проблем“ или „анулирано“.

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

Правилото е: всеки статус трябва да отговаря на въпроса „какво трябва да се случи след това?“.

7. Документи и прикачени файлове

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

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

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

Какво не е непременно нужно в началото

За пет камиона не е задължително да започнете с:

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

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

Дигитализиран обичаен ден

07:00 — начало

Диспечерът отваря плана и вижда:

• 12 вече планирани дейности;
• 2 за назначаване;
• 1 неналичен камион;
• оперативните бележки за деня.

08:15 — нова поръчка

Пристига имейл. Операторът създава поръчка, като използва вече записаните клиент и обект.

09:00 — смяна на шофьор

Шофьор не може да продължи. Дейността се преназначава. Всички виждат новата комбинация.

11:30 — промяна на часа

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

16:30 — приключване

Завършените дейности преминават в правилния статус. Евентуалните документи се свързват с курса според процеса на фирмата.

Край на деня

Утрешният план започва от вече структурирани данни, а не от възстановяване на чатове.

Какви данни да се измерват с пет камиона

Не са нужни петдесет KPI. Може да са достатъчни:

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

Ако даден показател не води до решение, той може да бъде премахнат.

Контролен списък: подходящ ли е софтуерът за управление за 5 камиона?

• Мога ли бързо да създам поръчка?
• Могат ли клиентът и обектът да се използват повторно?
• Виждам ли веднага непланираните поръчки?
• Мога ли да назнача камион и шофьор, без да дублирам данни?
• Появява ли се промяната при човека, който трябва да я изпълни?
• Мога ли да търся стари поръчки?
• Мога ли да експортирам данните?
• Имат ли различните потребители отделни акаунти?
• Поддържа ли системата полезна история на промените?
• Могат ли да се свързват документи, без да се бърка архивиране с нормативно съхранение?
• Мога ли да работя, без да купувам ненужни модули?
• Може ли персоналът да го използва след разумно обучение?