Kako izbjeći gubitak naloga između e-pošte, WhatsAppa i telefonskih poziva

Ukratko

E-pošta, WhatsApp i telefon nisu "pogrešni alati". To su vrlo učinkoviti komunikacijski kanali. Problem nastaje kada postanu i jedina arhiva operativnog rada. Isporuka može biti naručena e-poštom, izmijenjena telefonom i potvrđena u chatu: nakon nekoliko sati nitko više ne zna koja informacija ima prednost.

Rješenje nije zabraniti kanale kojima se koriste klijenti i vozači. Potrebno je uvesti pravilo: svaka informacija koja mijenja posao mora dospjeti u operativni izvor naloga. Poruka ostaje dokaz ili kontekst; kartica naloga sadržava ono što treba izvršiti.

Problem nije WhatsApp: problem je rascjepkanost

U mikropoduzeću vlasnik često sve zna napamet. S tri ili četiri kamiona sustav se čini funkcionalnim jer jedna osoba povezuje pozive, klijente i vozače. Kada se povećaju broj naloga, vozila ili suradnika, individualno pamćenje postaje usko grlo.

Simptome je lako prepoznati:

• traži se "posljednja e-poruka" prije nego što se nazove vozača;
• dvije osobe imaju različite verzije iste adrese;
• izmjena primljena na privatni telefon ne stiže do kolege;
• klijent pita zašto nije poštovana uputa koja nije bila zabilježena;
• računovodstvo i operativa naknadno moraju rekonstruirati što se dogodilo.

Utvrđivanje jednog operativnog izvora

Jedinstveni izvor ne mora nužno biti sofisticirani softver. U početnoj fazi to može biti dobro osmišljena tablica ili dijeljena baza podataka. Ipak, mora ispunjavati četiri zahtjeva:

1. svaki nalog ima identifikator;
2. postoji samo jedna trenutačna verzija operativnih informacija;
3. važne se izmjene mogu pratiti;
4. ovlaštene osobe mogu pristupiti podacima kada je potrebno.

Ta se logika često naziva single source of truth: to ne znači da u cijeloj tvrtki postoji samo jedan dokument, nego da je za svaku operativnu informaciju jasno koji izvor prevladava.

Kako postupati s e-poštom, telefonom i chatom

E-pošta

Korisna je za zaprimanje strukturiranih naloga, privitaka i potvrda. Kada sadržava novi zadatak, podatke treba unijeti u karticu naloga. E-poruka se zatim može povezati ili arhivirati kao referenca.

Telefonski poziv

To je najbrži i najmanje strukturiran kanal. Ako se tijekom poziva promijene adresa, vrijeme ili količina, izmjenu treba zabilježiti čim je moguće. Za osjetljive ili sporne informacije može biti korisna naknadna pisana potvrda.

WhatsApp ili drugi chatovi

Izvrsni su za brzinu i ažuriranja, ali osobni chat može biti teško dostupan ostatku tvrtke te miješa informacije iz različitih naloga. Važnu operativnu poruku treba unijeti u sustav naloga; dokumentima i fotografijama treba upravljati prema postupcima tvrtke i pravilima zaštite podataka.

Ugovori, nalozi i dokaz izmjena

Talijanska Zakonodavna uredba 286/2005 uređuje ugovor o cestovnom prijevozu robe za račun trećih osoba i pridaje važnost pisanom obliku i elementima odnosa. Način na koji e-poruke, nalozi, potvrde i drugi dokumenti pridonose dokazivanju sadržaja odnosa ovisi o konkretnom slučaju.

Zato je, kada izmjena ima važan gospodarski ili operativni učinak — primjerice drugo odredište, dodatno čekanje, drugo istovaranje ili znatna promjena robe — korisno sačuvati jasan trag i povezati ga s nalogom. Ne treba svaki poziv pretvoriti u ugovor: treba moći rekonstruirati tko je što zatražio i kada.

Pristupi, sigurnosne kopije i čuvanje

Centraliziranje naloga ne znači da sve treba biti vidljivo svima. MSP bi si barem trebao postaviti ova pitanja:

• tko može izmijeniti nalog?
• tko može vidjeti cijene i komercijalne uvjete?
• vide li vozači samo informacije potrebne za vožnju?
• što se događa ako se pokvari računalo dispečera?
• postoji li sigurnosna kopija?
• deaktiviraju li se računi bivših zaposlenika ili suradnika?
• čuvaju li se osobni podaci samo onoliko dugo i za one svrhe koje su potrebne?

GDPR među ostalim načelima zahtijeva ograničenje svrhe, smanjenje količine podataka, točnost i odgovarajuću sigurnost. Zato i jednostavan proces naloga treba izbjegavati nepotrebno umnožavanje osobnih podataka na desecima uređaja.

Minimalna metoda za MSP

Vrlo jednostavan tijek može biti:

1. Stiže zahtjev. E-pošta, telefon, chat ili portal.

2. Stvara se nalog. Identifikator, klijent, preuzimanje, isporuka, roba, datum i bilješke.

3. Prilažu se ili povezuju reference. E-pošta, dokumenti, komercijalni dogovor.

4. Dodjeljuje se posao. Vozač i kamion.

5. Svaka izmjena ažurira karticu. Izvorni kanal ne ostaje jedini izvor.

6. Nalog se zatvara. Status isporučeno i relevantni dokumenti.

7. Arhivira se prema dosljednim kriterijima. Ne mapa po osobi, nego kriterij koji omogućava pronaći prijevoz.

Praktični primjer

U 09:00 e-poštom stiže nalog Milano–Genova. U 11:00 klijent zove i traži ranije preuzimanje. U 13:00 putem WhatsAppa šalje novi referentni broj koji treba priopćiti skladištu.

Bez jedinstvenog izvora postoje tri dijela istine. Uz strukturirani tijek, nalog sadržava ažurirano vrijeme i novu referencu, dok e-poruka i poruka ostaju povezane kao kontekst. Kolega koji preuzima posao poslijepodne ne mora čitati cijelu povijest da bi razumio što treba izvršiti.

Kontrolni popis

• Bilježi li se svaki novi zadatak na zajedničkom mjestu?
• Unose li se važne telefonske izmjene u nalog?
• Nisu li chatovi jedina arhiva?
• Je li jasno koja je verzija naloga trenutačna?
• Imaju li cijene i osobni podaci odgovarajuće pristupe?
• Postoji li postupak sigurnosnog kopiranja?
• Može li se rekonstruirati povijest važne izmjene?