Kako organizovati servisiranje i voditi istoriju opreme kod klijenata?

Firme koje prodaju, ugrađuju i održavaju opremu često prate iste uređaje godinama. To mogu biti klima-uređaji, UPS uređaji, protivpožarni aparati, industrijska oprema ili drugi uređaji kojima su potrebni pregledi i servisiranje.

Neki uređaji mogu da se donesu u servis. Drugi su trajno instalirani kod klijenta, pa serviser odlazi na njihovu lokaciju. U oba slučaja, za svaki pojedinačni uređaj treba znati:

• Gde se nalazi i kada je ugrađen?
• Šta je ranije servisirano i koje su intervencije izvršene?
• Koji delovi su menjani?
• Kada je potreban sledeći pregled?

Ako se podaci čuvaju samo u pojedinačnim radnim nalozima, svaka naredna intervencija počinje traženjem prethodnih informacija. Zato je važno da svaki uređaj ima sopstvenu istoriju.

Većina uređaja ima fabrički serijski broj. Međutim, deo opreme nema takvu oznaku, ona može biti nečitljiva ili nije pogodna za poslovnu evidenciju.

Zato svaki pojedinačni uređaj koji pratimo treba da ima jedinstveni interni identifikator. Po potrebi mu se dodeljuje inventarska oznaka, bar-kod ili QR kod, preko kojeg može da se pronađe njegova evidencija.

Fabrički serijski broj i interni identifikator nisu ista stvar. Serijski broj je podatak proizvođača. Interni identifikator povezuje sve zapise o istom uređaju, čak i kada fabrički broj nedostaje ili se ponavlja u poslovnoj evidenciji.

Na jednoj lokaciji mogu da postoje dva ista modela klima-uređaja. Njihove intervencije treba voditi odvojeno: zamena dela na jednom uređaju ne pripada istoriji drugog.

Kada firma razvija sopstveni softver, često objedini organizaciju terenskog rada i evidenciju servisiranja u jednoj aplikaciji. Te aktivnosti su povezane: serviser dobija nalog, odlazi kod klijenta, obavlja intervenciju i beleži šta je uradio.

Ipak, radni nalog i oprema imaju različit životni vek.

Radni nalog služi za organizaciju, dodeljivanje, izvršavanje i završetak konkretnog posla. Servisna evidencija prati jedan uređaj tokom godina, kroz više naloga, servisera i intervencija.

Sve može da bude u jednoj aplikaciji. Kako sistem raste, važno je da te odgovornosti ostanu jasne, kako bi se funkcije lakše održavale i precizno odredilo ko sme da vidi i menja podatke.

U pristupu ASAP Core platforme, Dispatch ASAP organizuje i prati izvršavanje poslova. Servisna evidencija treba da vodi uređaje, njihove oznake i istoriju održavanja. Veza između njih su konkretan uređaj i radni nalog na koji se intervencija odnosi.

Dobro korisničko iskustvo počinje razumevanjem posla koji osoba obavlja. Dispečer, serviser i osoba zadužena za evidenciju opreme imaju različite zadatke i potrebni su im različiti pregledi.

Dispečera zanima koga šalje na teren, gde, kada i koji posao treba da bude obavljen. Serviseru su potrebni podaci o konkretnom uređaju, prethodnim intervencijama i današnjem zadatku.

Osoba koja vodi servisnu evidenciju treba da ima pregled podataka o opremi, istorije servisa i narednih pregleda. Zaposleni ne treba da poznaje celu poslovnu logiku sistema da bi obavio svoj deo posla.

Posebnu pažnju treba posvetiti mobilnoj aplikaciji. Serviser dolazi kod klijenta da popravi ili pregleda uređaj. Evidentiranje rada treba da mu oduzme što manje vremena.

U povezanom toku treba da može brzo da pronađe uređaj, pogleda prethodne intervencije, zabeleži šta je uradio i nastavi sa poslom. Podaci i pravila koja nisu deo njegovog zadatka ne treba da opterećuju taj ekran.

Cilj je da zaposleni rado koristi aplikaciju zato što mu olakšava rad, a ne samo zato što je obavezan da je koristi.

Klijent prijavljuje kvar na klima-uređaju koji je ranije ugrađen u njegovom poslovnom prostoru. Dispečer otvara posao u Dispatch ASAP i dodeljuje servisera. Serviser dobija obaveštenje na telefonu.

U ciljanom povezanom toku zadatak bi, uz lokaciju i opis posla, sadržao vezu ka tačno određenom uređaju i relevantnoj prethodnoj servisnoj istoriji. Serviser bi mogao da proveri šta je ranije rađeno pre nego što započne intervenciju.

Po dolasku kod klijenta obavlja pregled ili popravku i evidentira izvršeni rad. Ako je zamenjen deo, taj podatak treba povezati sa uređajem i konkretnim nalogom.

Radni nalog se završava, a uređaj ostaje u servisnoj evidenciji sa dopunjenom istorijom. Kada se sledeći put pojavi kvar, drugi serviser može da nastavi od postojećih podataka.

Ovaj primer opisuje kako evidencije treba da budu povezane. Prikaz istorije uređaja u mobilnom zadatku i njeno dopunjavanje kroz intervenciju ovde su deo tog modela, bez tvrdnje da je kompletno povezivanje već dostupno.

Nisu svim zaposlenima potrebni isti podaci. Pri uvođenju sistema treba dogovoriti ko vidi podatke i ko ima pravo da ih menja.

• Dispečeru je potreban pristup poslovima i rasporedu.
• Serviseru su potrebne informacije za dodeljenu intervenciju.
• Osobi koja vodi servisnu evidenciju potreban je odgovarajući pristup podacima o opremi i istoriji održavanja.
• Klijent, ako mu je omogućen pristup, treba da vidi samo podatke o svojoj opremi i uslugama.

Razdvajanje odgovornosti olakšava organizaciju prava pristupa. Sama podela na module ne rešava kontrolu pristupa: prava treba posebno podesiti i proveriti za svaku ulogu. Pristup klijenta u ovom primeru je poslovni zahtev, bez obećanja gotovog klijentskog portala.

Servisiranje opreme obuhvata i današnji posao i ono što se sa istim uređajem događalo tokom godina.

Radni nalog govori šta je urađeno danas. Istorija uređaja povezuje ugradnju, prethodne intervencije, zamenjene delove i naredne preglede.

Kada su ove dve evidencije povezane, lakše je organizovati terenski rad, pratiti opremu i planirati naredne intervencije. Za početak odaberite jednu vrstu opreme ili jednu lokaciju i dogovorite oznake uređaja, podatke koji se beleže i odgovornost za njihovo ažuriranje.