Softver za upravljanje s 5 kamiona: koje su funkcije stvarno potrebne

Ukratko

S pet kamiona mala tvrtka još može djelovati „upravljivo iz glave“. U stvarnosti su pet vozila, pet vozača, dvadesetak naloga, dva klijenta koji mijenjaju termin i jedan izostanak dovoljni da u jednom danu stvore desetke operativnih kombinacija.

Pravi softver za upravljanje ne smije pretvoriti poduzeće u multinacionalnu kompaniju. Mora osigurati šest stvari:

1. svaki nalog postoji samo jednom;
2. svi vide koja je verzija ažurirana;
3. kamion i vozač povezani su s aktivnošću;
4. izmjena ne ostaje zatvorena u razgovoru;
5. aktivnost se može zatvoriti i ponovno pronaći;
6. tvrtka može dohvatiti vlastite podatke.

Ako ovih šest uvjeta dobro funkcionira, za vozni park od pet kamiona to je već velik korak naprijed u odnosu na Excel + telefon + WhatsApp.

Zašto je 5 kamiona već dovoljno da se izgubi kontrola

Zamislimo jednostavan dan:

• 5 kamiona;
• 5 vozača;
• 3 prosječne aktivnosti po vozilu;
• 15 aktivnosti ukupno;
• 2 promijenjene adrese;
• 1 klijent koji kasni;
• 1 vozač koji završava kasnije od predviđenog;
• 1 hitan nalog dodan u 11:00.

Problem više nije „zapamtiti 15 isporuka“. Problem je održati dosljednima sve odnose:

nalog ↔ klijent ↔ adresa ↔ vrijeme ↔ kamion ↔ vozač ↔ status ↔ dokument

Ako je svaki na drugome mjestu, tvrtka ovisi o pamćenju dispečera.

Minimalni operativni sustav voznog parka

Za vozni park od oko pet kamiona korisno je o softveru razmišljati kao o zajedničkoj operativnoj ploči, a ne kao o ERP-u.

Minimalna područja su:

• klijenti i lokacije;
• nalozi;
• vozači;
• vozila;
• dnevni plan;
• status aktivnosti;
• mogući privici;
• pretraživanje povijesti.

Sve ostalo dolazi kasnije.

1. Ponovno upotrebljivi matični podaci

Svakodnevno ponovno upisivanje istih podataka izvor je pogrešaka.

Sustav bi trebao omogućiti spremanje barem sljedećega:

Klijent

• službeni naziv tvrtke;
• operativni kontakti;
• mogući interni kodovi;
• trajne bilješke koje su stvarno potrebne.

Mjesto utovara/isporuke

• puna adresa;
• operativni kontakt, ako je potreban;
• ponavljajući vremenski termini/sati;
• korisne napomene za pristup;
• moguće reference klijenta.

Vozač

• ime;
• operativni kontakt;
• dostupnost;
• informacije potrebne za dodjelu.

Vozilo

• registarska oznaka ili identifikator;
• vrsta;
• značajke potrebne za planiranje;
• dostupnost.

Ipak, matične podatke ne treba pretvoriti u neselektivno spremište osobnih podataka. Prikupljajte ono što je procesu potrebno te odvojeno upravljajte podacima/dokumentima koji zahtijevaju drukčiju zaštitu ili svrhu.

2. Strukturirani nalozi

Svaki prijevoz trebao bi imati prepoznatljiv zapis.

Praktična polja:

• klijent;
• referenca naloga;
• datum;
• utovar;
• isporuka;
• vremenski prozori;
• roba/količina u potrebnim podacima;
• operativne upute;
• moguća naknada, ako je sustav vodi;
• status;
• relevantne bilješke i privici.

Zapis mora razlikovati trajne informacije od privremenih bilješki. Ako „istovar na vratima 3“ uvijek vrijedi za tu lokaciju, može biti podatak u matičnoj evidenciji. Ako vrijedi samo danas, pripada nalogu.

3. Dnevni plan

S pet kamiona plan mora biti čitljiv u nekoliko sekundi.

Koristan prikaz odmah odgovara:

• što još treba dodijeliti?
• što će raditi svaki kamion?
• tko vozi?
• koji je redoslijed?
• koje aktivnosti imaju kritične termine?
• koje su se promijenile?
• koje su dovršene?

Plan ne smije pokušavati zamijeniti obveze povezane s vremenom vožnje, odmorom, radnim vremenom ili drugim regulatornim ograničenjima. Mora pomoći operateru organizirati rad i učiniti vidljivima ograničenja kojima tvrtka odluči upravljati u procesu.

4. Povezani vozači i vozila

Upisati „Mario / 123AB“ u bilješku razlikuje se od stvarne dodjele entiteta vozača i entiteta vozila.

Strukturirana povezanost omogućuje da se:

• vide sve aktivnosti vozača;
• vide sve aktivnosti kamiona;
• izbjegnu očite dvostruke dodjele;
• promijeni resurs bez ponovnog pisanja naloga;
• stvori dosljedna povijest;
• izrade korisne statistike.

Za regulatorne provjere, međutim, tvrtka mora nastaviti koristiti podatke i sustave koje zahtijevaju primjenjiva pravila, uključujući tahograf kada je potreban.

5. Komuniciranje izmjena

Stvarna se vrijednost pojavljuje kada se nešto promijeni.

Ako klijent pomakne isporuku s 14:00 na 16:00, idealan postupak je:

1. ured ažurira nalog;
2. plan odražava novu informaciju;
3. vozač primi/vidi ažuriranje u predviđenom operativnom kanalu;
4. izmjena ostaje rekonstrukcijska ako sustav čuva povijest/revizijske podatke;
5. ne postoje dvije konkurentske verzije.

WhatsApp se i dalje može koristiti za razgovore i hitne slučajeve, ali ne bi trebao biti jedina arhiva operativne odluke.

6. Status i zatvaranje aktivnosti

Malo ili srednje poduzeće trebalo bi definirati mali broj jasnih statusa.

Primjer:

za planiranje → planirano → dodijeljeno → u tijeku → dovršeno

Statuse dodajte samo ako imaju stvarne operativne posljedice, primjerice „problem“ ili „otkazano“.

Previše statusa stvara zbrku. Premalo ih onemogućuje razumijevanje onoga što nedostaje.

Pravilo je: svaki status mora odgovoriti na pitanje „što se treba dogoditi dalje?“.

7. Dokumenti i privici

Povezivanje dokumenta s nalogom može izbjeći beskrajne mape i pretraživanja. No potrebno je razlikovati:

• operativni privitak u sustavu za upravljanje;
• dokument relevantan za porezne/pravne svrhe;
• moguću obvezu digitalnog čuvanja prema primjenjivim pravilima.

Činjenica da je PDF učitan u oblak ne znači automatski da su ispunjeni mogući zahtjevi čuvanja za taj dokument. Za dokumente koji podliježu posebnim obvezama, ispravan postupak treba provjeriti sa savjetnicima i službenim izvorima.

Što nije nužno potrebno na početku

Za pet kamiona nije obvezno krenuti s:

• naprednim motorom za optimizaciju;
• nadmetanjem prijevoznika;
• skladištem podataka;
• složenom poslovnom inteligencijom;
• vlastitom telematikom;
• potpunim računovodstvom;
• desecima integracija;
• automatizacijama temeljenima na UI-u;
• poslovnim tijekovima odobravanja za velika poduzeća.

Ako neka od tih funkcija rješava stvarni problem, može imati smisla. Bit je ne kupiti je zato što „izgleda profesionalno“.

Digitalizirani tipični dan

07:00 — otvaranje

Dispečer otvara plan i vidi:

• 12 već planiranih aktivnosti;
• 2 za dodjelu;
• 1 nedostupan kamion;
• operativne bilješke dana.

08:15 — novi nalog

Stiže e-poruka. Operater stvara nalog koristeći klijenta i lokaciju koji su već evidentirani.

09:00 — promjena vozača

Vozač ne može nastaviti. Aktivnost se ponovno dodjeljuje. Svi vide novu kombinaciju.

11:30 — promjena termina

Klijent pomiče vrijeme isporuke. Nalog se ažurira, a vozač dobiva novu informaciju.

16:30 — zatvaranje

Dovršene aktivnosti prelaze u ispravan status. Mogući dokumenti povezuju se s vožnjom prema postupku tvrtke.

Kraj dana

Sutrašnji plan počinje od već strukturiranih podataka, a ne od rekonstruiranja razgovora.

Koje podatke mjeriti s pet kamiona

Nije potrebno pedeset KPI-jeva. Može biti dovoljno:

• nalozi po danu/tjednu;
• dovršene naspram otvorenih aktivnosti;
• nalozi po klijentu;
• broj izmjena/iznimki;
• ručno uneseni naspram uvezenih naloga;
• nedostajući dokumenti, ako se vode;
• broj aktivnosti po vozilu/vozaču kao operativni podatak, a ne kao zamjena za provjere vremena vožnje/rada.

Ako pokazatelj ne vodi odluci, može se ukloniti.

Kontrolni popis: je li sustav za upravljanje primjeren za 5 kamiona?

• Mogu li brzo stvoriti nalog?
• Mogu li se klijent i lokacija ponovno koristiti?
• Vidim li odmah neplanirane naloge?
• Mogu li dodijeliti kamion i vozača bez udvostručavanja podataka?
• Prikazuje li se izmjena osobi koja je mora izvršiti?
• Mogu li pretraživati stare naloge?
• Mogu li izvesti podatke?
• Imaju li različiti korisnici zasebne račune?
• Čuva li sustav korisnu povijest izmjena?
• Mogu li se dokumenti povezati bez miješanja arhiviranja s regulatornim čuvanjem?
• Mogu li raditi bez kupnje nepotrebnih modula?
• Može li ga osoblje koristiti nakon razumne obuke?