· 13 min skaitymas
Kaip palyginti furgonų parko atitikties sistemas JK
Praktinis JK palyginimo vadovas apie furgonų parko atitikties programinę įrangą, apimantis patikrinimus, vairuotojų patikras, tachografų įrašus ir audito
Pasirinkimas tarp furgonų parko atitikties sistemų JK priklauso nuo vieno testo. Ar sistema gali padėti mums tinkamai valdyti parką kiekvieną dieną, ir ar ji gali pateikti aiškius įrodymus, kai to prašo DVSA, klientas, auditorius ar Transporto komisaras?
Tai reiškia, kad reikia žiūrėti už funkcijų sąrašų. Platforma gali atrodyti stipri dėl valdymo skydelių ir priminimų, tačiau vis tiek gali palikti spragų patikros įrašuose, vairuotojų bylose, priekabų kontrolėje ar priežiūros istorijoje. Daugumai operatorių teisingas būdas palyginti furgonų parko atitikties programinę įrangą JK yra pradėti nuo realių atitikties užduočių, kurias turime atlikti, ir tada patikrinti, ar sistema suteikia patikimą auditų taką kiekvienai iš jų.
Ką turi apimti furgonų parko atitikties programinė įranga JK veikloje
JK furgonų operatoriui reikia daugiau nei tik užsakymų dienoraščio su keliais galiojimo priminimais. Net jei kai kurie automobiliai yra už operatoriaus licencijos ribų, klientų, draudikų ir vykdymo institucijų tikimasi valdymo standartas vis tiek priklauso nuo tikslių įrašų, suplanuotos priežiūros ir įrodymų, kad defektai buvo nustatyti ir pašalinti.
Mažiausiai sistema turėtų turėti tinkamą transporto priemonės įrašą kiekvienam furgonui. Tai reiškia registraciją, VIN, mokesčių duomenis, jei tai aktualu, MOT datas, aptarnavimo grafiką, saugos patikros intervalą, padangų informaciją, nuomos ar nuosavybės detales ir bet kokius pastabas, kurios gali paveikti naudojimą. Jei mes taip pat naudojame priekabas, joms reikia savo įrašų, patikros grafikų ir defektų istorijos, o ne tik pastabos, pridėtos prie tempiamos transporto priemonės.
Patikros valdymas yra centrinis. Programinė įranga turėtų leisti mums suplanuoti įprastas saugos patikras, užfiksuoti užbaigtas patikros formas, registruoti defektus, priskirti remonto veiksmus ir parodyti, kada transporto priemonė buvo grąžinta į eksploataciją. Jei furgonas yra ne kelyje, sistema turėtų rodyti jį kaip VOR ir padaryti šį statusą matomą žmonėms, paskirstantiems darbą.
Vairuotojų įrašai yra tokie pat svarbūs. Mums reikia vietos saugoti licencijos duomenis, patikros datas, kategorijas, patvirtinimus, teisę dirbti dokumentus, jei reikia, Driver CPC statusą, DQC galiojimo datą, medicininius įrašus, jei tai aktualu veiklai, ir agentūros vairuotojų įrašus, kai naudojame laikinas darbo jėgas. Daugeliui furgonų parkų Driver CPC netaikomas kiekvienam vairuotojui, tačiau jei dalis parko ar dalis darbo reikalauja šių reikalavimų, sistema turi tai tvarkyti sklandžiai.
Datas, kurios sukelia veiksmus, turi būti tinkamai valdomos. Tai apima MOT, metinę patikrą, jei tai aktualu, patikras, aptarnavimą, kalibravimo datas, draudimo datas ir dokumentų galiojimo pabaigas. Geras sistema neturėtų tiesiog saugoti datas. Ji turėtų išsiųsti priminimus pakankamai anksti, kad galėtume veikti, eskaluoti pradelstas prekes ir aiškiai parodyti, kas su jomis dirbo. Jei jūs vertinate galimybes, mūsų vadovas apie parko programinę įrangą, kuri pažymi atitikties terminus el. paštu apima, ką tie priminimai turi daryti praktikoje.
Operatoriaus licencijos darbams sistema taip pat turėtų palaikyti Transporto komisaro bylą. Realiai tai reiškia, kad turime galėti pateikti įrodymus apie patikros dažnumą, užbaigtą priežiūrą, defektų pašalinimą, vairuotojų patikrinimus, draudimų sekimą, OCRS susijusias valdymo veiklas, jei tai aktualu, ir politiką ar įrašus, kurie rodo nuolatinę ir veiksmingą kontrolę. Jei platforma negali padėti mums sukurti šios bylos, kai mes dirbame, greičiausiai tai sukels darbą vėliau, kai būsime po spaudimu.
JK tai turi būti vertinama pagal DVSA lūkesčius ir operatoriaus licencijos praktiką, o ne pagal bendrą ES parko šabloną. Kai kuri programinė įranga yra sukurta plačiai Europos parko administracijai ir gali neatspindėti to, kaip JK operatoriai turi įrodyti priežiūros intervalus, metinės patikros paruošimą, tachografų įrašus ar Transporto komisaro įsipareigojimus.
Kaip palyginti sistemas pagal jūsų realų parko riziką
Teisinga sistema vietiniam furgonų parkui, dirbančiam lengvų siuntų darbą, gali būti netinkama mišriai veiklai, vykdančiai 3.5 tonos furgonus, 7.5 tonos transporto priemones, priekabas ir HGV iš to paties depų. Palyginimas turi prasmę tik tada, kai pradedame nuo savo rizikos profilio.
Pirmiausia, žemėlapiuokite parką. Išvardinkite transporto priemonių tipus, ar kurios nors yra operatoriaus licencijos ribose, ar mes tempiame priekabas, ar naudojame specializuotas kėbulo rūšis, ir ar kai kurios transporto priemonės yra priskirtos, o kitos dalijamos. Dalijamos transporto priemonės paprastai reikalauja stipresnio kasdienio defektų pranešimo ir griežtesnės raktų kontrolės, nes atsakomybė paskirstyta tarp daugiau vairuotojų.
Kitas, pažvelkite į operatoriaus licencijos ekspoziciją. Kai kurie furgonų operatoriai dabar turi įsipareigojimų, kurie yra arčiau tradicinės prekių transporto priemonių atitikties, nei jie tikisi, ypač kai kalbama apie sunkesnes transporto priemones, priekabas ar mišrius parkus. Jei mes jau turime licenciją arba tikimės jos gauti, programinė įranga turėtų būti vertinama pagal tai, ar ji palaiko šią aplinką nuo pirmos dienos. Jei mes naudojame prekių transporto priemones, furgonus ir galbūt keleivines transporto priemones toje pačioje veikloje, naudojant vieną sistemą visiems, paprastai sumažėja dubliavimas ir praleisti terminai.
Mišrus transporto priemonių naudojimas yra dar viena sritis, kuri dažnai praleidžiama. Furgonas, naudojamas vieną savaitę vietiniams pristatymams, o kitą - ilgesniems darbams su priekaba, sukuria kitokius įrašų tvarkymo poreikius nei furgonas, vykdantis tą pačią miesto maršrutą kiekvieną dieną. Sistema turi susidoroti su besikeičiančiu naudojimu, besikeičiančiais vairuotojais ir besikeičiančiais priežiūros poreikiais, nesukeldama rankinio sprendimo.
Agentūros vairuotojai nusipelno ypatingo dėmesio. Jei mes įdarbiname vairuotojus trumpai, programinė įranga turėtų leisti mums greitai sukurti ir valdyti laikinas vairuotojų bylas, saugoti licencijos ir Driver CPC įrodymus, registruoti įvadinius ar politikos pripažinimus ir pašalinti prieigą, kai užsakymas baigiasi. Jei programinė įranga mano, kad kiekvienas vairuotojas yra nuolatinis darbuotojas su fiksuotu profiliu, tai gali sukelti spragų.
Jei priekabos yra veiklos dalis, tinkamai išbandykite šią sritį. Daugelis sistemų sako, kad jos tvarko priekabas, tačiau siūlo tik registracijos lauką ir priminimo datą. Praktikoje mums reikia atskirų patikros įrašų, defektų ataskaitų, priežiūros istorijos ir dokumentų saugojimo. Mes apie tai išsamiau kalbėjome mūsų vadove apie priekabų patikros programinės įrangos pasirinkimą DVSA įrašams.
Galiausiai, nuspręskite, ar verslui reikia vienos platformos visiems furgonams, HGV ir PSV darbams. Transporto vadybininkams, atsakingiems už kelias licencijų rūšis, atskiros sistemos dažnai reiškia dubliuotą duomenų įvedimą, nesuderinamą ataskaitų teikimą ir papildomą darbą ruošiantis auditui. Operator Compliance mes sukūrėme platformą per Fleeta Limited, atsižvelgdami į realų operatoriaus licencijos darbą, nes daugelis parkų netelpa į vieną transporto priemonių klasę.
Funkcijos, kurios yra svarbiausios transporto vadybininkams
Transporto vadybininkams dažniausiai mažiau rūpi pristatymas ir labiau tai, ar sistema išsaugo praleistus žingsnius. Stipriausi palyginimai paprastai priklauso nuo kelių praktinių funkcijų.
Defektų pranešimas yra viena iš jų. Mums reikia, kad vairuotojai galėtų atlikti patikras mobiliuoju telefonu, registruoti nulinės defektus, taip pat faktinius defektus, pridėti nuotraukas, jei tai naudinga, pasirašyti ataskaitą ir pateikti ją be trukdžių. Biuro pusė yra taip pat svarbi. Ar galime greitai peržiūrėti defektą, nuspręsti, ar transporto priemonė yra VOR, priskirti remontą, registruoti pašalinimą ir parodyti, kada transporto priemonė buvo išleista? Jei procesas nutrūksta tarp vairuotojo ataskaitos ir dirbtuvės veiksmų, auditų takas yra silpnas.
Priežiūros planavimas yra dar viena svarbi sritis. Sistema turėtų palaikyti pasikartojančias patikras pagal datą ar intervalą, dirbtuvių užsakymus, išorinių paslaugų teikėjų užsakymus, aptarnavimo planavimą ir metinės patikros paruošimą. Taip pat turime matyti, kas artėja pagal depą, rangovą ar transporto priemonių klasę. Daugeliui operatorių planavimas pagal ISO savaitę yra naudingesnis nei planavimas pagal kalendorinį mėnesį, nes dirbtuvių pajėgumai ir parko paketai dažnai valdomi šiuo būdu.
Vairuotojų licencijų ir Driver CPC sekimas turėtų būti daugiau nei galiojimo sąrašas. Sistema turėtų saugoti patikros datas, rezultatus, patvirtinimus, kategorijas ir DQC įrašus, ir turėtų būti lengva matyti, kas yra pasirengęs pakartotinei patikrai. Jei jūsų procesas apima internetines patikras su DVLA, paklauskite, kaip tie rezultatai yra užfiksuoti ir išlaikomi. Jei tiekėjas sako, kad patikra vyksta kitur ir turi būti įkelta rankiniu būdu, tai yra papildoma administracija, kurią reikia apskaičiuoti.
Tachografų analizė yra svarbi, jei parkas apima transporto priemones, kurioms tai taikoma. Furgonų operatorius gali to nereikėti visam parkui, tačiau mišriems parkams tai dažnai reikia. Tokiu atveju palyginkite, ar tachografų duomenys, pažeidimų peržiūra, trūkstamas mylių skaičius ar trūkstamas atsisiuntimo sekimas yra toje pačioje atitikties įrašo dalyje kaip transporto priemonių ir vairuotojų valdymas. Mes išdėstėme operacinius aspektus mūsų straipsnyje apie tachografų analizės programinę įrangą mažiems parkams.
Dokumentų saugojimas skamba paprastai, tačiau dažnai tai yra sritis, kur sistemos nepavyksta auditų metu. Mums reikia struktūrizuoto saugojimo, o ne laisvos įkėlimo aplankos. Transporto priemonių bylos, vairuotojų bylos, draudimas, priežiūros sąskaitos, patikros lapai, mokymo įrašai, sutartys ir politikos pripažinimai turėtų būti lengvai randami, pažymėti datomis ir susieti su tinkamu įrašu.
VOR kontrolė taip pat reikalauja kruopštaus palyginimo. Atitinkanti sistema turėtų leisti mums sustabdyti transporto priemonę, kad ji būtų laikoma prieinama, kai tik kyla rimtas defektas, ir ji turėtų išlaikyti laiką. Kas pažymėjo ją kaip VOR, kada buvo patvirtintas remontas, kada darbas buvo baigtas ir kas grąžino ją į eksploataciją? Ši seka yra svarbi tiek vidinėse peržiūrose, tiek išoriniuose vizituose.
Ataskaitos turėtų palaikyti kasdienį valdymą, o ne tik mėnesio pabaigos santraukas. Pradelstos patikros, pradelsti remontai, galiojančių dokumentų pabaigos, praleisti vairuotojų patikrinimai, atviri defektai, transporto priemonės be neseniai užfiksuotų nulinės defektų ataskaitų ir dirbtuvių apkrovimas pagal ISO savaitę - visos šios ataskaitos yra vertos, kad būtų prašoma pamatyti demonstracijoje.
Koks geras auditų įrodymas atrodo, kai DVSA prašo
Kai DVSA atvyksta, problema retai būna, ar turime tam tikrų duomenų kažkur. Problema yra ta, ar galime greitai pateikti aiškų, pilną įrašą, kad parodytume kontrolę.
Patikroms geri įrodymai reiškia pasirašytą įrašą, kuriame nurodyta patikros data, patikrinta transporto priemonė ar priekaba, patikrinti elementai, rasti defektai, asmuo, atlikęs patikrą, ir rezultatas. Jei defektai buvo nustatyti, byla taip pat turėtų rodyti pašalinimą, dalis ar atliktą darbą, jei tai aktualu, ir datą, kada transporto priemonė grįžo į eksploataciją.
Priežiūros istorijai turėtume galėti pateikti prasmingą seką. Planuojamos patikros galiojimo data, faktinė patikros data, nustatyti defektai, atlikti remontai, bet koks perplanavimas su priežastimi ir įrodymai, kad intervalas buvo kontroliuojamas. Jei patikra buvo vėluojama, sistema neturėtų to slėpti. Ji turėtų tai parodyti kartu su paaiškinimu ir valdymo veiksmu.
Vairuotojų atitikties geras įrodymas apima licencijų patikras, Driver CPC įrašus, jei taikoma, DQC galiojimo datas, bet kokius mokymo įrašus ir įrodymus, kad problemos buvo sekamos. Jei naudojami agentūros vairuotojai, jų įrašai turėtų būti tokie pat lengvai prieinami kaip nuolatinių darbuotojų įrašai.
Pradelsti elementai turi būti matomi. Platforma, kuri tiesiog perrašo praleistas datas su kitomis galiojimo datomis, gali padaryti operatorių atrodyti geriau ekrane nei realybėje, tačiau ji neatsilaikys DVSA vizito metu. Mums reikia galėti parodyti, kas tapo pradelsta, kada tai buvo baigta ir kas su ja dirbo.
Auditų takas pats savaime yra svarbus. Kiekviena veika turėtų būti priskirta. Kas įkėlė patikrą, kas pakeitė galiojimo datą, kas uždarė defektą, kas pašalino VOR statusą? Jei sistema leidžia įrašus keisti be pėdsakų, tai silpnina pasitikėjimą visa byla.
Operatoriaus licencijos darbams daugelis parkų taip pat reikia mėnesinio paketo ar peržiūros bylos, kuri gali būti parodyta viduje ir, jei reikia, išorėje. Tai gali apimti užbaigtas patikras, praleistus elementus, MOT ar metinės patikros užsakymus, licencijų patikras, tachografų išimtis ir valdymo pastabas. Mūsų straipsnis apie mėnesinio parko paketo pasirinkimą, kuris atitinka DVSA paaiškina, į ką atkreipti dėmesį.
Naudingas papildymas yra palaikymas platesniam atitikties vaizdui aplink kiekvieną transporto priemonę. Draudimo įrodymai, politikos dokumentai ir patikros prieš askMID gali visi vaidinti vaidmenį vidinėje kontrolėje, askMID remiasi duomenimis iš Motor Insurers' Bureau ir MIB. Tai nėra pagrindinių priežiūros įrašų pakaitalas, tačiau tai padeda išlaikyti visą bylą tvarkingą.
Klausimai, kuriuos reikia užduoti prieš pasirenkant platformą
Prieš pasirinkdami bet kurią sistemą, paklauskite, kaip veikia nustatymas praktikoje. Kokie duomenys gali būti importuojami, iš kokio formato ir kas atlieka žemėlapį? Transporto priemonių sąrašai, priekabų įrašai, vairuotojų bylos, patikros šablonai ir istorinių priežiūros įrašų perkėlimas užtrunka laiko. Jei atsakymas yra tiesiog „įkelkite skaičiuoklę“, paklauskite, kas nutiks priedams, dokumentų istorijoms ir pasikartojantiems grafikams.
Paklauskite apie palaikymą operatyviniais terminais. Kas padeda, jei reikia koreguoti patikros darbo eigą, keičiasi depų struktūra, arba transporto vadybininkui reikia ataskaitų viešajai apklausai? Tiekėjas, kuris supranta operatoriaus licencijos atitiktį kasdien, paprastai atsakys kitaip nei bendroji programinės įrangos įmonė.
Vartotojų prieiga nusipelno tinkamo dėmesio. Ar galime atskirti dirbtuvių, transporto biuro, vairuotojų, agentūros ir valdymo teises? Ar išorinis priežiūros paslaugų teikėjas gali įkelti įrašus, nematydamas nesusijusių duomenų? Ar įdarbinimo verslas gali tvarkyti laikinas vairuotojų bylas sklandžiai? Šie detalės yra svarbios, kai sistema pradeda veikti.
Mobiliuoju naudojimu turėtų būti išbandyta, o ne laikoma savaime suprantamu dalyku. Vairuotojai turi greitai atlikti patikras vietoje, dažnai su kintančiu signalu. Dirbtuvių darbuotojai gali tekti atnaujinti remontus iš kiemo. Vadybininkai gali tekti peržiūrėti pradelstus elementus toli nuo biuro. Paklauskite, kas veikia mobiliuoju, kas veikia neprisijungus, jei kas nors, ir kur procesas priklauso nuo darbalaukio.
Ataskaitos turėtų būti demonstruojamos naudojant jūsų pačių scenarijus. Paprašykite tiekėjo parodyti pradelstas patikras, galiojančius DQC įrašus, VOR transporto priemones, priekabų priežiūrą, kuri turi būti atlikta kitą ISO savaitę, ir visą transporto priemonės istoriją vienai registracijai. Jei jie negali to aiškiai parodyti, sistema gali netikti realiam transporto darbui.
Integracijos yra vertos ankstyvo klausimo. Jei jums reikia, kad duomenys būtų perkelti į atlyginimų, telematikos, dirbtuvių sistemas ar BI įrankius, paklauskite, ar platforma siūlo REST API ar webhook'us, ir kokie įvykiai ar įrašai gali būti išsiųsti. Mes išdėstėme praktinius palyginimo taškus mūsų vadove apie kaip palyginti parko sistemas su REST API.
Taip pat paklauskite, ar tiekėjas konkrečiai supranta JK atitikties aplinką. Ar jie žino, kas turi būti Transporto komisaro byloje? Ar jie supranta VOL procesus, metinės patikros planavimą, tachografų įsipareigojimus mišriuose parkuose ir skirtumą tarp priminimų sistemos ir gynybinio auditų tako? Tai nėra mažos detalės. Jos paprastai yra skirtumas tarp programinės įrangos, kuri atrodo naudinga, ir programinės įrangos, kuri palaiko operatorių, kai kas nors nepavyksta.
Operator Compliance mes dirbame pagal šį standartą. OperatorCompliance buvo sukurta Fleeta Limited atsižvelgiant į tai, kaip JK operatoriai iš tikrųjų turi įrodyti atitiktį, naudojant DVSA Gidą, kaip išlaikyti kelių tinkamumą, kaip praktinį orientyrą kasdieninei kontrolei. Jei lyginate sistemas furgonų parkui, pradėkite nuo ten. Patikrinkite, ar platforma gali valdyti darbą, įrodyti, kad darbas buvo atliktas, ir išlaikyti įrašą tvarkingą, kai DVSA to prašo.
Ar furgonų parko atitikties programinė įranga skirta tik HGV operatoriams?
Ne. Furgonų parkams taip pat reikia struktūrizuotų įrašų apie patikras, priežiūrą, vairuotojų dokumentus ir terminus. Teisinga sistema priklauso nuo to, kiek atitikties įrodymų jūsų veikla turi išlaikyti ir pateikti.
Ar visiems furgonų parkams reikia tachografų analizės?
Ne. Tai priklauso nuo naudojamų transporto priemonių ir vykdomo darbo. Jei jūsų veikla naudoja tachografus, programinė įranga turėtų tinkamai saugoti ir organizuoti analizę ir susijusius įrodymus.
Ar turėčiau pasirinkti parko sistemą ar atitikties sistemą?
Jei operatoriaus licencijos pareigos, patikros ir auditų įrodymai yra pagrindinė rizika, pradėkite nuo atitikties poreikių. Bendros parko priemonės gali nesuteikti transporto vadybininkams reikalingų įrašų.
Ką turėčiau paklausti apie vairuotojų dokumentų patikras?
Paklauskite, kaip sistema seka licencijų patikras, Driver CPC datas, DQC įrašus, galiojimo priminimus ir įrodymus, kad patikros buvo atliktos ir peržiūrėtos.
Kodėl integracijos yra svarbios atitikties programinėje įrangoje?
Jei jau naudojate kitas sistemas, integracijos gali sumažinti duomenų įvedimą ir praleistus atnaujinimus. Paklauskite, ar platforma siūlo REST API ar webhook'us ir kokie duomenys gali judėti tarp sistemų.