Kaip vežėjai lygina atitikties sistemas DVSA įrašams

Vežėjai paprastai lygina atitikties sistemas pagal vieną paprastą klausimą. Jei DVSA (Kelių saugumo agentūra) paskambintų rytoj, ar galėtume pateikti išsamų, tvarkingą įrašą apie kiekvieną transporto priemonę, priekabą ir vairuotoją, nepraleisdami pusės dienos ieškodami per pašto dėžutes, skaičiuokles ir archyvus?

Būtent tai skiria paprastą transporto priemonių valdymo įrankį nuo programinės įrangos, kuri iš tikrųjų palaiko operatoriaus licenciją. Tinkama sistema ne tik primena, kad kažkas artėja. Ji padeda kontroliuoti patikros intervalus, MOT ir metinius testus, defektus, Driver CPC ir DQC įrodymus, tachografo įrašus ir auditų taką, kurio gali prireikti transporto vadybininkui, kad pateiktų jį Kelių komisijai. Daugeliui operatorių tai yra priežastis, kodėl palyginimas prasideda nuo programinės įrangos, sukurtos vežimui, o ne nuo bendros transporto priemonių platformos.

Ką vežėjai nori, kad sistema darytų kasdien

Kasdienis atitikties darbas yra pasikartojantis, terminų vedamas ir dokumentų gausus. Sistema turi atitikti šią realybę.

Mažiausiai, vežėjai turi turėti vieną vietą, kur laikyti pagrindinį įrašą apie kiekvieną transporto priemonę, priekabą ir vairuotoją. Transporto priemonėms ir priekaboms tai paprastai reiškia registracijos numerį, VIN arba rėmo numerį, markę ir modelį, platinimo detales, jei tai aktualu, MOT arba metinio testo datą, kelių mokestį, draudimo nuorodą, patikros dažnumą, PMI istoriją, stabdžių testavimo įrodymus ir bet kokius VOR laikotarpius. Vairuotojams tai reiškia licencijų kategorijas, galiojimo datas, Driver CPC terminus, DQC galiojimą, teisę dirbti dokumentus, jei verslas juos seka, įdarbinimo įrašus, agentūros statusą ir tachografo kortelės detales.

Praktinis testas yra tai, ar sistema palaiko, kaip iš tikrųjų veikia transporto biuras. Transporto vadybininkas turėtų galėti akimirksniu pamatyti, kas yra numatyta šiai savaitei, kas yra pasenę, kas yra ne kelyje ir kas trūksta įrodymų. Jei biuras vis dar turi eksportuoti sąrašus į skaičiuoklę, kad suplanuotų patikras ar ieškotų dokumentų, programinė įranga neatlieka pagrindinio darbo.

Patikros planavimas čia yra svarbus. Operatoriai turi suplanuoti saugos patikras tinkamu intervalu kiekvienam turtui, o ne taikyti vieną bendrą ciklą visam parkui. Kai kurios transporto priemonės gali būti šešių savaičių cikle, kitos - skirtingu modeliu, priklausomai nuo naudojimo, amžiaus ar eksploatavimo sąlygų. Priekaboms reikia to paties disciplinos. Tinkama sistema turėtų planuoti pasikartojančias patikras į priekį nuo paskutinio užbaigto įvykio arba pagal fiksuotą planą, priklausomai nuo to, kaip operatorius valdo savo programą.

Datos sekimas taip pat turi apimti dokumentus, kuriuos lengva praleisti, kol jie tampa problema. MOT ir metinių testų datos yra akivaizdžios, bet taip pat ir kalibravimo datos, draudimo atnaujinimai, priežiūros sutarčių peržiūros ir bet kokios vietinės politikos, kuriomis operatorius remiasi kaip dalimi savo valdymo kontrolės. Vairuotojams, Driver CPC ir DQC terminai turi būti šalia licencijų patikrinimų ir bet kokių vidinių mokymo reikalavimų.

Defektų pranešimas yra dar viena kasdienė reikalavimas. Neužtenka pažymėti, kad defektas egzistavo. Sistema turėtų rodyti, kada defektas buvo praneštas, ar jis buvo susijęs su saugumu, kokių veiksmų buvo imtasi, kas jį įvertino, ar transporto priemonė ar priekaba buvo pažymėta VOR, ir kokie įrodymai palaiko remontą ir grąžinimą į eksploataciją. Pasirašyti įrašai yra svarbūs. Taip pat svarbus ryšys tarp defekto, remonto ir grąžinimo atgal į naudojimą.

Tachografo įrodymai dažnai tampa silpna vieta, kai įrašai yra paskirstyti tarp skirtingų tiekėjų. Vežimo operatorius turi turėti pasitikėjimą, kad vairuotojo kortelės ir transporto priemonės vieneto duomenys buvo atsisiųsti tinkamais intervalais, tinkamai saugomi, analizuojami dėl pažeidimų ir trūkstamo ridos, ir išlaikomi tokiu būdu, kad būtų galima pateikti, jei to bus paprašyta. Jei tachografo analizė yra už pagrindinio atitikties įrašo, kažkas vis tiek turi rankiniu būdu suderinti išimtis.

Štai kodėl daugelis operatorių, ieškančių transporto priemonių atitikties programinės įrangos vežėjams, nori mažiau programinės įrangos, o ne daugiau. Jie nori vieno operatyvinio įrašo, o ne penkių dalinių. Jei lyginate pasirinkimus, naudinga pradėti nuo kontrolinio sąrašo įrašų, kuriuos turite kontroliuoti kiekvieną savaitę, ir paklausti, ar sistema tvarko kiekvieną iš jų natūraliai.

Kokios funkcijos iš tikrųjų sumažina operatoriaus licencijos riziką

Ne kiekviena funkcija demonstracijoje sumažina operatoriaus licencijos riziką. Svarbios yra tos funkcijos, kurios sumažina praleistų įvykių, silpnų įrašų ir neaiškios atsakomybės tikimybę.

Pasikartojantys tvarkaraščiai yra arti sąrašo viršaus. Jei sistema negali patikimai generuoti būsimų patikrų, testų ir patikrinimų, visa atitikties proceso struktūra yra ant smėlio. Mes ieškome tvarkaraščių, kurie gali tvarkyti atskirus ciklus transporto priemonėms ir priekaboms, palaikyti ISO savaitės vaizdą planavimui ir pateikti aiškų sąrašą, kas yra numatyta, užsakyta, užbaigta ir pasenusi. Operatoriai dažnai planuoja dirbtuvių veiklą pagal ISO savaitės ritmą, todėl programinė įranga turėtų kalbėti ta kalba.

VOR kontrolė yra dar viena svarbi sritis. Vežimo versle, paimti turtą iš kelio nėra tik dirbtuvės užrašas. Tai yra atitikties kontrolė. Įrašas turėtų rodyti VOR priežastį, pradžios datą ir laiką, bet kokį susijusį defektą ar draudimo problemą, ir įrodymus, kad turtas grąžinamas į eksploataciją. Jei sistema leidžia darbą pažymėti kaip užbaigtą, neparodant, ar transporto priemonė tuo tarpu buvo apribota naudoti, tai palieka spragą, kuri gali būti svarbi vėliau.

Pasirašyti įrašai yra būtini, nes nepasirašyti įrašai yra sunkiau ginami. Patikros lapai, defektų ataskaitos, remonto patvirtinimai ir vairuotojų deklaracijos turėtų turėti asmens, kuris juos užpildė, tapatybę, o idealiu atveju - laiko žymą, rodančią, kada įrašai buvo padaryti arba pakeisti. Transporto vadybininkas nenori aiškinti, kodėl svarbus atitikties dokumentas egzistuoja tik kaip redaguojama skaičiuoklė arba nepasirašytas PDF.

Dokumentų saugojimas taip pat reikalauja daugiau dėmesio nei dažnai gauna. Klausimas nėra tik tai, ar failai gali būti įkelti. Klausimas yra, ar tinkamas dokumentas gali būti pridedamas prie tinkamo turto ar asmens, greitai randamas, protingai versijuojamas ir išlaikomas kaip dalis viso įrašo. Jei MOT sertifikatas yra viename aplanke, patikros lapas kitame, o remonto sąskaita el. laiškų siuntinyje, vis tiek neturite švaraus failo.

Įspėjimai yra svarbūs, bet tik jei jie yra naudojami. Per daug įspėjimų tampa fono triukšmu. Ko operatoriai reikia, tai terminų įspėjimų, kurie atkeliauja pakankamai anksti, kad būtų galima veikti, yra nukreipti į tinkamus žmones ir atskiria dokumentą, kuris turi būti pateiktas kitą mėnesį, nuo patikros, kuri jau yra pasenusi. Mes apie tai išsamiau kalbėjome savo gide apie el. pašto įspėjimus, kurie pažymi atitikties terminus.

Paskutinis testas yra tai, ar sistema padeda jums sukurti aiškų failą Kelių komisijai. Tai nereiškia, kad vienas mygtukas pažymėtas "auditas". Tai reiškia, kad įrašai jau yra organizuoti taip, kad atlaikytų patikrinimą. Transporto priemonei ar priekabai turėtumėte galėti sujungti priežiūros tvarkaraštį, užbaigtas patikras, defektus, remontus, MOT arba metinių testų istoriją ir VOR laikotarpius. Vairuotojui turėtumėte galėti parodyti licencijų patikrinimus, Driver CPC ir DQC įrodymus, tachografo analizę ir bet kokius sekimo veiksmus. Jei tas failas priklauso nuo to, kad kas nors prisimena, kur dokumentai buvo išsaugoti, sistema nepakankamai sumažina riziką.

Kaip lyginti tachografo, licencijų ir vairuotojų patikrinimus

Vairuotojų atitiktis dažnai nepavyksta tarp sistemų. Tachografo duomenys yra vienoje vietoje, DVLA licencijų patikrinimai kitoje, o vairuotojų dokumentai trečioje. Štai kodėl ši palyginimo dalis nusipelno laiko.

Dėl tachografo analizės pradėkite nuo pagrindų. Ar sistema registruoja, ar atsisiuntimai buvo atlikti laiku tiek vairuotojo kortelėms, tiek transporto priemonių vienetams? Ar galite matyti trūkstamus atsisiuntimus, nepriskirtą ridą, akivaizdų vairavimą be kortelės ir pažeidimus, kuriuos reikia peržiūrėti? Ar yra įrašas, kas peržiūrėjo išimtis ir kokių veiksmų buvo imtasi? Analizė viena nėra pakankama. Operatoriai taip pat reikia valdymo takelio.

Išimčių tvarkymas yra toks pat svarbus kaip ir žali analizės duomenys. Geras sistema turėtų padėti transporto vadybininkams atskirti tarp mažos problemos, kuri buvo peržiūrėta, ir pasikartojančio modelio, kuris reikalauja eskalacijos, perkvalifikavimo ar drausminės veiklos. Jei kiekviena išimtis yra tik dar viena eilutė ataskaitoje, programinė įranga jums nepadeda valdyti rizikos.

Jei lyginate tiekėjus, mūsų gidas apie tachografo analizės programinę įrangą mažoms flotilėms pateikia praktinius punktus, kuriuos reikia patikrinti.

Dėl DVLA licencijų tikrinimo paklauskite, kaip patikrinimai yra inicijuojami, registruojami ir įrodoma. Sistema turėtų sekti patikrinimų dažnumą pagal politiką, pažymėti didelės rizikos vairuotojus dažnesnei peržiūrai, jei to reikia, ir saugoti rezultatą vairuotojo įraše. Ji taip pat turėtų susidoroti su realybe, kad ne kiekvienas vairuotojas yra nuolatinis darbuotojas. Agentūros vairuotojai, pagalbiniai vairuotojai ir atsitiktiniai vairuotojai vis dar turi turėti dokumentuotą procesą.

Štai kur vairuotojų dokumentų sekimas tampa svarbus. Sistema turėtų laikyti licencijų nuotraukas arba nuorodas, kur jūsų politika leidžia, Driver CPC statusą, DQC galiojimą, pasą arba teisę dirbti dokumentus, jei jie yra sekami, ir bet kokius vidinius patvirtinimus vairuoti tam tikras transporto priemonių klases. Autobusų ir mikroautobusų operatoriams, taip pat kai kurioms mišrioms flotilėms, ta pati principas taikomas, tačiau konkretūs dokumentai gali skirtis. Kur JK taisyklės skiriasi nuo platesnės ES praktikos, operatoriai turėtų laikytis JK režimo, kuris taikomas jų licencijai ir veiklai, ypač dėl to, kaip įrodymai tikrinami ir išlaikomi.

Agentūros ir atsitiktiniai vairuotojai dažnai yra sunkiausia grupė, kurią gerai valdyti. Programinė įranga turėtų leisti jums greitai pridėti vairuotoją, teisingai pažymėti juos kaip laikinuosius ar agentūros, priskirti dokumentų reikalavimus, užregistruoti DVLA patikrinimą ir pašalinti arba archyvuoti prieigą, kai užduotis baigiasi. Ji taip pat turėtų aiškiai nurodyti, iš kur gauti įrodymus, ar tiesiogiai iš vairuotojo, iš agentūros, ar iš vidinio patikrinimo. Jei tie vairuotojai gyvena už pagrindinio proceso, nes "jie tik padarė kelis pamainas", tai būtent ten atsiranda spragos.

Kai kurie operatoriai taip pat nori ryšių su išoriniais duomenų šaltiniais. Priklausomai nuo darbo proceso, tai gali apimti patikrinimus prieš askMID arba duomenis, suderintus su Motor Insurers' Bureau, taip pat žinomą kaip MIB. Jei draudimo statusas yra jūsų kontrolės proceso dalis, paklauskite, kaip ta informacija patenka į įrašą ir kaip išimtys yra pažymimos.

Kur bendros transporto priemonių priemonės nepakankamai vežėjams

Bendros transporto priemonių sistemos paprastai daro kai kuriuos dalykus gerai. Jos gali būti geros degalų, naudojimo, paslaugų užsakymo, vairuotojų programėlių ar išlaidų ataskaitų srityse. Problema ta, kad operatoriaus licencijos atitiktis nėra tik priežiūros kalendorius.

Bendra transporto priemonių platforma dažnai traktuoja sunkvežimį taip pat, kaip traktuoja įmonės automobilį ar pilkąją flotilę. Tai reiškia, kad ji gali saugoti paslaugų datas ir dokumentus, tačiau ne įrašus, kurių vežimo operatorius reikia, kad parodytų sisteminę kontrolę pagal DVSA lūkesčius. Priekabų įrašai yra dažna silpnybė. Vežime priekaba nėra neprivalomas papildinys duomenų modelyje. Tai yra pagrindinis turtas su savo patikra, defektų ir metinių testų istorija.

Dar viena spraga yra pati atitikties failo struktūra. Vežėjams reikia įrašų, kurie atitiktų tai, kaip DVSA ir, kai reikalai eskaluojami, Kelių komisija gali peržiūrėti veiklą. Tai reiškia aiškius priežiūros intervalus, užbaigtų patikrų įrodymus, pasirašytą defektų tvarkymą, VOR kontrolę ir tvarkingą palaikymą palaikančių dokumentų. Bendros sistemos dažnai sustoja ties "užduotis užbaigta", nesaugodamos įrodymų grandinės už užduoties.

Planavimas taip pat skiriasi. Dirbtuvių ir patikros planavimas vežime dažnai veikia pagal ISO savaitę, pagal flotilės grupę, pagal eksploatacijos centrą ir pagal priežiūros teikėją. Programinė įranga, sukurta aplink bendrą transporto priemonių aptarnavimą, gali to nepakankamai palaikyti. Jei jūsų komanda turi sukurti atskirą skaičiuoklę, kad vykdytų faktinį patikros planą, programinė įranga iš tikrųjų nėra jūsų atitikties sistema.

Tachografo ir vairuotojų atitiktis yra ten, kur skirtumas tampa aštresnis. Bendras transporto priemonių įrankis gali pasiūlyti vairuotojo failą ir keletą priminimų, tačiau tai nėra tas pats, kaip valdyti tachografo įrodymus, pažeidimų peržiūrą, DVLA patikrinimus, Driver CPC ir DQC terminus vienoje vietoje. Vežėjams reikia, kad programinė įranga atspindėtų operatoriaus licencijos režimą, o ne tik transporto priemonių ir vairuotojų egzistavimą.

Štai kodėl Operator Compliance buvo sukurta Fleeta Limited aplink tai, kaip licencijuotas operatorius iš tikrųjų dirba, įskaitant praktinius reikalavimus, kuriuos transporto vadybininkai pripažįsta iš DVSA Gido, kaip išlaikyti kelių tinkamumą. Operatoriams, lyginantiems pasirinkimus, mūsų puslapis apie vežimo atitikties programinę įrangą, sukurtą operatoriams išdėsto tą dėmesį išsamiau.

Klausimai, kuriuos reikia užduoti prieš pereinant nuo skaičiuoklių ar kitos sistemos

Pereinamasis laikotarpis nuo skaičiuoklių, bendrų diskų ar senesnės platformos turėtų būti vertinamas pagal įgyvendinimo detales, o ne tik pagal demonstracijoje parodytas funkcijas.

Pradėkite nuo nustatymo. Paklauskite, kas įkelia jūsų flotilės, priekabų ir vairuotojų duomenis, kokio formato jiems reikia ir kaip tvarkomi kraštiniai atvejai. Mišrios flotilės, nuomojami turtai, subrangovų priežiūra ir neveiksmingi įrašai visi reikalauja apmąstymų. Jei migracijos planas apima tik lengvus duomenis, jūsų pirmas mėnuo naujoje sistemoje vis tiek apims rankinį taisymą.

Paklauskite konkrečiai apie dokumentų migraciją. Ar istoriniai patikros lapai, MOT sertifikatai, metinių testų įrašai, defektų formos ir licencijų įrodymai gali būti importuojami pagal tinkamą turtą ar vairuotoją, ar jie atkeliauja kaip masinis archyvas su mažu struktūrizavimu? Sistema yra daug vertingesnė, jei seni įrodymai išlieka paieškomi ir pridedami prie tinkamo įrašo.

Patikrinkite, kaip veikia planuotojas. Ar jis gali rodyti darbą pagal dieną, savaitę ir ISO savaitę? Ar galite filtruoti pagal eksploatacijos centrą, priežiūros teikėją ar turto tipą? Ar pasikartojantys tvarkaraščiai gali būti koreguojami, nesugriaunant auditų tako? Dėl priekabų turinčių operacijų paklauskite, ar galite pamatyti priekabų planavimą, o ne tik transporto priemonių planavimą. Mes apie tai kalbame savo gide apie priekabų patikros programinės įrangos pasirinkimą DVSA įrašams.

Integracijos yra svarbios, jei jau naudojate kitas sistemas. Paklauskite, ar platforma turi REST API, ar ji palaiko webhook'us, ir kokie įvykiai ar įrašai gali būti perduodami arba traukiami. Tai gali apimti defektų duomenis iš vairuotojo programėlės, dirbtuvių užbaigimo statusą, HR įrašus naujiems darbuotojams arba eksportus į BI įrankius, tokius kaip Fleetalyse arba Logivo.AI. Jei atsakymas yra "mes greičiausiai galime sukurti kažką", paklauskite, kas jau egzistuoja ir kaip tai dokumentuota. Mūsų straipsnis apie kaip lyginti transporto priemonių sistemas su REST API suteikia naudingą struktūrą.

Vartotojų prieiga nusipelno daugiau dėmesio, nei dažnai gauna. Transporto vadybininkas, dirbtuvių kontrolierius, išorinis priežiūros teikėjas, atitikties administratorius ir agentūros stalas ne visi turi tas pačias teises. Paklauskite, ar prieiga gali būti kontroliuojama pagal vaidmenį, pagal depą, pagal turto grupę ir pagal funkciją. Taip pat paklauskite, kaip sistema registruoja, kas ką pakeitė. Auditų takas yra dalis atitikties įrašo.

Ataskaitos yra dar viena praktinė patikra. Ar galite sukurti artėjančių terminų ataskaitą, pasenusią ataskaitą, VOR sąrašą, trūkstamų dokumentų ataskaitą, vairuotojų atitikties santrauką ir paketą transporto priemonei ar priekabai, neeksportuodami visko į Excel pirmiausia? Jei jums reikia mėnesinio valdymo paketo, paklauskite, ar galite pamatyti vieną. Ataskaita turėtų būti skaitoma, išsami ir ginama. Mūsų gidas apie mėnesinį flotilės paketą, kuris atlaiko DVSA yra geras standartas.

Galiausiai, paklauskite, kaip sistema įrodo užbaigtą darbą. Ar užbaigta patikra rodo naudojamą formą, asmenį, kuris ją užpildė, datą ir laiką, bet kokius iškeltus defektus, patvirtinimą ir susijusius remonto įrodymus? Ar galite matyti visą grandinę nuo defekto iki VOR iki remonto iki grąžinimo? Tas įrodymas yra tai, kas paverčia priminimo įrankį į atitikties sistemą.

Vežėjams geriausias palyginimas nėra tas, kuris turi ilgiausią funkcijų sąrašą. Tai tas, kuris suteikia jums išsamų, tvarkingą ir ginamą įrašą apie tai, kaip jūs kontroliuojate transporto priemones, priekabas ir vairuotojus pagal savo operatoriaus licenciją. Tai standartas, kurį mes kuriame OperatorCompliance, kad atitiktų.