Kaip palyginti transporto priemonių atitikties sistemas O-licencijos

Pasirinkimas tarp transporto priemonių atitikties sistemų O-licencijos darbui priklauso nuo vieno klausimo. Ar sistema padės mums tinkamai valdyti licenciją kiekvieną dieną ir vėliau tai įrodyti, kai bus tikrinama DVSA (Kelių transporto agentūra) ar Transporto komisaro?

JK operatoriams tai reiškia daugiau nei priminimus. Naudinga sistema turi turėti išsamius įrašus apie transporto priemones, priekabas ir vairuotojus, planuoti ir įrodyti saugos užduotis, sekti MOT ir metinių testų datas, palaikyti tachografų ir vairuotojų atitiktį bei palikti aiškų audito pėdsaką. Kai lyginame transporto priemonių ir priekabų atitikties programinę įrangą, turėtume mažiau žiūrėti į informacinius skydelius ir daugiau į tai, ar platforma atspindi tikrą operatoriaus licencijos darbą.

Ką JK operatoriai iš tikrųjų reikia iš vienos atitikties sistemos

Atitikties sistema O-licencijos darbui turėtų tinkamai apimti keturias sritis: turtą, vairuotojus, užduotis ir įrodymus.

Transporto priemonėms ir priekaboms mums reikia pilno turto įrašo. Tai paprastai apima registracijos numerį, flotilės numerį, VIN arba važiuoklės numerį, markę ir modelį, pirmo naudojimo datą, mokesčių klasę, kur tai aktualu, MOT arba metinio testo datą, PMI arba saugos patikrinimo intervalą, stabdžių testų grafiką, apkrovos testų įrašus, kai naudojama, padangų informaciją ir ar turtas yra aktyvus, parduotas, ne kelyje ar VOR (neveikiantis). Priekaboms programinė įranga turėtų jas vertinti kaip pirmo lygio turtą, o ne kaip požiūrį po traktoriaus.

Vairuotojams sistema turi turėti licencijos kategorijas, galiojimo datas, teisę dirbti, kur mes jas saugome, Driver CPC galiojimo datą, DQC detales, tachografo kortelės detales, agentūros statusą, jei tai aktualu, ir patikrinimų istoriją. Sistema, kuri tik saugo vardus ir telefono numerius, nėra atitikties sistema.

Užduotims mums reikia suplanuotų ir pakartojamų darbo srautų. Saugos patikrinimai, MOT užsakymai, metinio testo paruošimas, kalibravimo datos, draudimo atnaujinimai, vairuotojų licencijų patikrinimai, Driver CPC sekimas, tachografų atsisiuntimai, defektų pranešimai ir dokumentų peržiūros turėtų būti planuojamos. Geresnės sistemos leidžia mums planuoti pagal datą, intervalą, naudojimą ar modelį, pavyzdžiui, ISO savaitę, kai tai atitinka, kaip dirbtuvės ir transporto biuras iš tikrųjų planuoja.

Įrodymams standartas yra paprastas. Jei užduotis įvyko, turime galėti parodyti, kada ji įvyko, kas tai padarė, kas buvo rasta, kokia buvo reakcija ir kada turtas ar vairuotojas buvo grąžintas į eksploataciją. Pasirašyti patikrinimo lapai, defektų šalinimas, dirbtuvių patvirtinimas ir dokumentų versijos yra svarbios. Priminti be įrodymų yra silpna parama, kai kas nors prašo pamatyti įrašą po mėnesių.

Štai kodėl transporto priemonių ir priekabų atitikties programinės įrangos palyginimas JK flotilėms skiriasi nuo bendro flotilės įrankių palyginimo. Bendro flotilės platforma gali puikiai sekti paslaugų datas ir degalų korteles, tačiau O-licencijos darbas priklauso nuo kelių tinkamumo sistemų, vairuotojų priežiūros ir dokumentinių įrodymų. JK standartas yra operatoriaus licencijos režimas ir DVSA nustatytos lūkesčiai. ES flotilės sistemos gali apimti priežiūrą ir tachografus, tačiau jei jos neatspindi JK operatoriaus licencijos praktikos, jos palieka spragų.

Kaip palyginti transporto priemonių ir priekabų įrašus šalia vienas kito

Kai lyginame sistemas, naudinga paimti vieną transporto priemonę ir vieną priekabą ir bandyti sekti visą įrašą nuo įdarbinimo iki utilizavimo.

Pradėkite nuo turto įrašo. Ar galime matyti dabartinę būseną, pagrindines datas, patikrinimo intervalą, priskirtą veiklos centrą ir dokumentų biblioteką vienoje vietoje? Jei priekaba keičia patikrinimo dažnumą, ar galime matyti, kada ta kaita buvo padaryta ir kieno? Jei transporto priemonė parduodama, ar galime ją archyvuoti, neprarandant istorijos? Tai yra pagrindiniai testai, ar sistema sukurta atitikties, o ne paprasto inventoriaus valdymui.

Tada patikrinkite patikrinimų planavimą. Transporto vadybininkas turėtų galėti nustatyti pasikartojančią saugos patikrinimo schemą ir aiškiai matyti artėjančias užduotis. Ieškokite lankstumo šioje srityje. Kai kurie operatoriai planuoja kas 6, 8 ar 10 savaičių. Kiti valdo mišrias flotiles su skirtingais dažniais pagal turto tipą, naudojimo modelį ar riziką. Geras sistema susitvarko su viskuo ir vis tiek aiškiai rodo pradelstas užduotis. Ji taip pat turėtų susidoroti su dirbtuvių realijomis, pavyzdžiui, šiek tiek paspartinti patikrinimą, neprarandant suplanuoto ritmo.

Kalbant apie MOT ir metinių testų sekimą, klausimas nėra tik ar data gali būti saugoma. Turime žinoti, ar sistema gali valdyti paruošimą, užsakymą, sėkmingus ir nesėkmingus rezultatus, draudimo susijusias sekas, jei tai aktualu, ir palaikančius dokumentus. HGV, PSV ir priekabų metinių testų valdymas dažnai yra sudėtingesnis nei privačios transporto priemonės MOT priminimas. Mes tai išsamiau aptariame savo gide apie HGV ir priekabų metinių testų įrašų valdymą.

VOR statusas yra dar vienas naudingas palyginimo taškas. Jei turtas turi saugos kritinį defektą, ar galime jį pažymėti VOR iš karto? Ar tas statusas aiškiai matomas visoje sistemoje, kad transporto darbuotojai, dirbtuvių darbuotojai ir vadovai visi matytų tą pačią padėtį? Ar galime užregistruoti, kas pašalino transporto priemonę iš eksploatacijos, kodėl, kokie buvo atlikti pataisymai ir kas leido grąžinti į eksploataciją? Jei VOR procesas yra neformalūs, programinė įranga nepadės daug, kai sprendimas vėliau bus užduotas.

Dokumentų saugojimas yra svarbesnis nei daugelis pirkėjų tikisi. Turėtume galėti saugoti patikrinimo lapus, metinių testų sertifikatus, MOT įrašus, kur tai aktualu, platinimo dokumentus, draudimo dokumentus, nuomos sutartis, kalibravimo sertifikatus ir nuotraukas prieš tinkamą turtą. Svarbus aspektas yra atgavimo galimybė. Audito metu ar galime greitai rasti tikslų įrašą, pagal transporto priemonę ar priekabą, su datomis ir versijų istorija? Jei ne, dokumentai gali būti laikomi archyve.

Jei reguliariai įtraukiame turtą į licenciją, taip pat verta patikrinti, ar sistema palaiko tinkamą įdarbinimo procesą. Mūsų straipsnis apie transporto priemonės įdarbimą su tinkamais įrašais rodo, kokius žingsnius programinė įranga turėtų palaikyti, o ne palikti atmintyje ir el. pašto grandinėse.

Specifiniu atveju priekaboms, palyginkite, kaip rimtai platforma jas vertina. Daugelis operatorių per vėlai atranda, kad sistema yra orientuota į transporto priemones ir tik laisvai palaiko priekabas. Jei priekaboms yra atskiri patikrinimų istorijos, metinių testų datas, stabdžių testų įrašai ir dokumentų paketai, joms reikia tinkamų nepriklausomų įrašų. Mes aptarėme praktinius aspektus savo gide apie priekabų patikrinimo programinės įrangos pasirinkimą DVSA įrašams.

Kur tachografas ir vairuotojų atitiktis daro didžiausią skirtumą

Daugelis atitikties nesėkmių neprasideda nuo priežiūros. Jos prasideda nuo vairuotojų, tachografų išimčių ir sekimo, kuris niekada neįvyksta.

Palydėdami sistemas, pirmiausia paklauskite, kaip tvarkoma tachografų analizė. Ar platforma tiesiog importuoja pažeidimų ataskaitas, ar ji palaiko tikrą peržiūros procesą? Turėtume galėti matyti išimtis, priskirti sekimą, užregistruoti, kad su vairuotoju buvo kalbama, saugoti pasirašytus konsultavimo užrašus, jei juos naudojame, ir parodyti modelį per laiką. Tachografo sistema, kuri generuoja ataskaitas, bet neturi valdymo pėdsako, palieka transporto vadybininką kurti įrodymus kitur.

Vairuotojų licencijų patikrinimai yra dar viena svarbi sritis. Programinė įranga turėtų užregistruoti, kada patikrinimai yra numatyti, kada jie buvo atlikti, rezultatus ir bet kokius apribojimus ar patvirtinimus, kuriems reikia veiksmų. JK daugelis operatorių remiasi DVLA patikrinimo darbo srautais arba trečiųjų šalių patikrinimo paslaugomis. Klausimas yra, ar atitikties sistema paverčia tai matomu valdymo procesu, o ne atskiru PDF dokumentu.

Driver CPC ir DQC įrašai taip pat reikalauja daugiau nei galiojimo datą. Turime žinoti, kas artėja prie galiojimo pabaigos, kas baigė periodinį mokymą, ar DQC detalės yra aktualios ir kokie įrodymai yra laikomi. Tai ypač svarbu mišriose operacijose, naudojančiose samdomus ir agentūrinius vairuotojus. Jei sistema negali atskirti tarp aktyvių, pasibaigusių, sustabdytų ir laukiančių įrašų, ji sukuria išvengiamą riziką.

Išimčių sekimas yra ta sritis, kur viena platforma paprastai atsiskiria nuo kitos. Jei vairuotojas praleidžia tachografo atsisiuntimą, nuolat pažeidžia taisykles arba leidžia Driver CPC pasibaigti, kas vyksta toliau sistemoje? Ar galime sukurti užduotį, priskirti ją, nustatyti terminą ir saugoti rezultatą? Ar galime parodyti, kad valdymas pastebėjo, veikė ir eskalavo, kur to reikia? Tai yra tai, ko ieško tyrėjai ir auditoriai, o ne tik ar programinė įranga gali parodyti raudoną įspėjimą.

Tai taip pat yra ta sritis, kur JK reikalavimai turi būti skaitomi JK kontekste. Tachografų taisyklės yra platesnės nei JK, tačiau operatorių priežiūra, licencijų įsipareigojimai ir įrodymų pateikimo būdas DVSA ar Transporto komisaro atžvilgiu yra JK praktikos klausimai. Sistema, sukurta aplink pan-europinę flotilės administraciją, gali nesuteikti JK transporto vadybininkui reikalingos atvejų istorijos.

Ką transporto vadybininkas turėtų ieškoti audito pėdsake

Kai sistema teigia, kad yra paruošta auditui, turėtume patikrinti šį teiginį su tikrais įrašais.

Pasirašyti įrodymai yra pirmieji. Ar sistema gali užfiksuoti parašus atliekant apžiūras, patikrinimus, defektų šalinimą ir vadovų peržiūras? Ar tie parašai yra susieti su įrašu taip, kad jų negalima būtų lengvai perrašyti? Jei defektą pranešė vairuotojas ir jį pašalino meistras, turėtume matyti abu šios grandinės aspektus.

Datos antspaudai yra tokie pat svarbūs. Kiekvienas svarbus įvykis turėtų turėti aiškią datą ir laiką, idealiai su vartotojo identitetu. Tai apima įrašų kūrimą, redagavimą, užduočių užbaigimą, palaikančių dokumentų įkėlimą ir statuso pakeitimus, tokius kaip VOR į tinkamą eksploatacijai. Jei įrašai gali būti keičiami be pėdsako, audito pėdsakas yra silpnas.

Defektų istoriją turėtų būti lengva sekti per laiką. Turėtume matyti pasikartojančius defektus transporto priemonėje ar priekaboje, o ne tik izoliuotus darbus. Pasikartojantys stabdžių, padangų, apšvietimo ar sujungimo klausimai pasakoja istoriją apie priežiūros kontrolę. Transporto vadybininkui reikia šios matomumo, kad iššūkį dirbtuvių procesui, tiekėjui ar veiklos modeliui, kol istorija netampa klausimu.

Praleistų užduočių matomumas yra dar vienas praktinis testas. Kai kurios sistemos gerai rodo, kas buvo padaryta, ir daug mažiau gerai rodo, kas buvo praleista. Mums reikia abiejų. Pradelsti patikrinimai, vėluojantis defektų patvirtinimas, pasibaigę dokumentai, praleisti licencijų patikrinimai ir neperžiūrėti tachografų išimčių turėtų aiškiai išsiskirti. Neturėtų prireikti specialaus skaičiuoklės, kad pamatytume, kas buvo praleista.

Ataskaitos yra ta sritis, kur audito pėdsakas tampa naudingas. Prieš pasirinkdami platformą, paklauskite pavyzdžių ataskaitų, kurios padėtų su DVSA vizitu ar Transporto komisaro viešojo tyrimo paketu. Ar galime pateikti patikrinimų istoriją vienai priekabai per apibrėžtą laikotarpį? Ar galime parodyti visus praleistus PMIs per pastaruosius šešis mėnesius, su priežastimis ir atnaujinimo datomis? Ar galime eksportuoti vairuotojų atitikties statusą, licencijų patikrinimus, Driver CPC datas ir tachografų sekimą forma, kurią vadybininkas gali iš tikrųjų naudoti?

Tai yra standartas, kuriuo dirbame Operator Compliance, nes žinome, kad programinė įranga turi atlaikyti išorėje. Fleeta Limited sukūrė platformą aplink tuos įrašus, kurių operatoriai tikimasi laikytis pagal DVSA Gidą dėl kelių tinkamumo palaikymo, o ne aplink bendrą flotilės administravimo modelį. Jei svarstote, ką tai reiškia praktikoje, mūsų straipsnis apie programinę įrangą, kuri atlaiko DVSA auditą nagrinėja detales.

Klausimai, kuriuos reikia užduoti prieš pasirenkant Operator Compliance ar kitą platformą

Kai pagrindinis atitikties tinkamumas aiškus, pirkimo sprendimas paprastai priklauso nuo įgyvendinimo, palaikymo ir to, kaip gerai sistema atitinka mūsų vykdomą operaciją.

Paklauskite, kiek pastangų reikia nustatymui. Ar galime masiškai importuoti transporto priemones, priekabas ir vairuotojus? Koks formatas reikalingas? Kaip istoriniai patikrinimai ir dokumentai bus perkelti? Jei turime metų įrašų skaičiuoklėse, dirbtuvių sistemose, bendrose aplankaluose ar kitoje platformoje, migracijos planas yra svarbus. Sistema, kuri atrodo tvarkinga demonstracijoje, gali tapti sunkiu darbu, jei įdarbinimas yra rankinis.

Paklauskite, kaip atrodo palaikymas po paleidimo. Ar yra pagalba nustatymui, šablonams, patikrinimų grafikams ir vartotojų leidimams? Jei transporto vadybininkas nori vėliau keisti darbo srautus, ar tai paprasta? Atitikties programinėje įrangoje palaikymas nėra tik techninis. Dažnai tai apima pagalbą operatoriui struktūrizuoti įrašus taip, kad jie veiktų tikrinimo metu.

Integracijos yra vertos atidžiai ištirti. Jei jau naudojame dirbtuvių programinę įrangą, telematikos, tachografų analizės įrankius, HR sistemas ar licencijų tikrinimo paslaugas, kas gali būti sujungta ir kaip? Tinkama REST API gali būti svarbi čia, ypač didesnėms flotilėms ar grupėms su vidinėmis sistemomis. Webhook'ai yra naudingi, kai reikia, kad įvykiai sukeltų veiksmus kitur, pavyzdžiui, užduoties sukūrimą, informacijos skydelio atnaujinimą ar dokumentų automatinį archyvavimą.

Jei draudimo patikrinimas yra jūsų proceso dalis, paklauskite, ar sistema gali palaikyti patikrinimus prieš askMID, kuris yra viešoji paslauga, remiama Motor Insurers' Bureau, dar žinomo kaip MIB. Tai nepakeis mūsų pareigos turėti tinkamus įrodymus, tačiau tai gali būti aktualu tam tikruose darbo srautuose, susijusiuose su nuomojamomis, subrangovų ar išorės teikiamomis transporto priemonėmis.

Taip pat protinga paklausti, kaip platforma tinka skirtingiems flotilės tipams. Krovinių vežėjai, furgonų flotilės, autobusų ir mikroautobusų operatoriai, savininkai, taksi ir privačių nuomos firmų, ir vairuotojų agentūros turi persidengiančius poreikius, tačiau ne identiškus. PSV operatorius gali labiau rūpintis metinių testų paruošimu ir defektų darbo srautais per paslaugų grafikus. Kurjerių flotilė gali reikalauti stipresnės paramos mišriems furgonams ir savininkų vairuotojų įrašams. Agentūra gali labiau koncentruotis į vairuotojų dokumentų kontrolę, DQC galiojimą ir paruošimą. Tinkama sistema turėtų tilpti be priverstinio kiekvienos operacijos pritaikymo į tą pačią formą.

Kur palyginimo įrankiai apima produktus, tokius kaip Fleetalyse ar Logivo.AI, užduokite tuos pačius operacinius klausimus kiekvienam. Ar platforma gali turėti pilną O-licencijos įrašų rinkinį? Ar ji gali įrodyti valdymo veiksmus? Ar ji gali parodyti, kas buvo praleista, o ne tik tai, kas buvo suplanuota? Ar ji gali tiesiogiai palaikyti JK operatorių licencijos darbą, o ne reikalauti šoninių procesų el. paštu ir skaičiuoklėse?

Galiausiai paklauskite, kokį failą galėtumėte paruošti rytoj, jei DVSA paskambintų arba jei gautumėte Transporto komisaro tyrimo laišką. Šis klausimas paprastai greitai išskiria funkcijų sąrašus. Jei atsakymas yra tas, kad vis tiek reikėtų surinkti įrašus iš kelių vietų, persekioti parašus ir paaiškinti spragas rankiniu būdu, sistema gali nedaryti pakankamai.

Gera atitikties platforma turėtų sumažinti tą skubėjimą. Ji turėtų padėti mums tinkamai valdyti flotilę kasdien, palaikyti VOL įsipareigojimus kontroloje ir palikti aiškų sprendimų, veiksmų ir įrodymų įrašą. Tai yra tikras pagrindas palyginti transporto priemonių ir priekabų atitikties programinę įrangą O-licencijos darbui. Ne kuri sistema turi įspūdingiausią ekraną, bet kuri padeda mums išlaikyti licenciją saugią.