Programinės įrangos pasirinkimas, kuris užtikrina vairuotojų įrašų

Jei renkatės programinę įrangą, kad išlaikytumėte vairuotojų įrašus auditui paruoštus, pradėkite nuo vieno klausimo. Ar ji padės mums greitai ir aiškiai įrodyti, kad kiekvienas licencijos patikrinimas, Driver CPC peržiūra ir sekantis veiksmas buvo atlikti laiku, tinkamo asmens, su įrodymais, kuriuos galime pateikti vėliau?

JK operatoriams tai svarbiau nei ilgas funkcijų sąrašas. Išmanus sistema nėra naudinga, jei ji negali parodyti švarios istorijos Traffic Commissioner (Transporto komisaro) tyrimui, DVSA vizitui, vidaus audito ar kliento išankstinio kvalifikavimo patikrinimui. Geras vairuotojų licencijų tikrinimo ir CPC sekimo programinė įranga turėtų sumažinti rankinį sekimą, anksti pažymėti tinkamus rizikos veiksnius ir išlaikyti įrašus susietus su kitais operatoriaus licencijos atitikties aspektais, o ne palikti juos atskiruose skaičiuoklėse, pašto dėžutėse ir archyvavimo spintose.

Ką JK operatoriai turėtų palyginti pirmiausia

Pirmasis palyginimo taškas nėra valdymo skydelis. Tai auditų takas.

JK operatorių licencijos kontekste transporto vadybininkams reikia programinės įrangos, kuri fiksuoja, kas buvo patikrinta, kada tai buvo patikrinta, kas tai peržiūrėjo, koks buvo rezultatas ir kas įvyko toliau. Jei vairuotojas turi naujų taškų, kategorijos apribojimą, pasibaigusį DQC ar trūkstamą mokymo užsakymą, mums reikia, kad sistema parodytų tiek įspėjimą, tiek atliktą veiksmą.

Palygindami sistemas, pirmiausia atkreipkite dėmesį į šiuos praktinius aspektus:

1. Kaip gaunami ir saugomi DVLA licencijų patikrinimai

Programinė įranga turėtų palaikyti tinkamus DVLA licencijų tikrinimo darbo procesus, o ne tik užrašą, kad "licencija patikrinta". Mums reikia rezultato, kuris gali būti išsaugotas vairuotojo įraše, su data, rezultatu ir bet kokiais patvirtinimais ar teisių klausimais, užfiksuotais naudojamo formato.

Daugeliui operatorių skirtumas tarp pakankamos sistemos ir naudingos yra tai, ar rezultatas gali būti peržiūrėtas vėliau, nesiremiant atskira el. pašto grandine ar atsisiųstu PDF, saugomu kažkur kitur.

2. Ar rizikos taisyklės yra konfigūruojamos

Ne kiekvienas vairuotojas turėtų būti vertinamas pagal tą pačią peržiūros ciklą. 23 metų kurjeris, dirbantis su keliomis siuntomis, autobuso vairuotojas, vežantis keleivius, ir ilgalaikis 1 klasės vairuotojas su švaria istorija gali reikalauti skirtingų peržiūros intervalų.

Naudinga sistema leidžia mums nustatyti peržiūros dažnumą pagal rizikos profilį, vaidmenį, amžių, taškų lygį, pretenzijų istoriją ar verslo padalinį. Ji taip pat turėtų leisti mums inicijuoti skubią peržiūrą, kai patikrinimas rodo naujus patvirtinimus, prarastas teises, medicininius apribojimus ar bet ką kitą, kas keičia, ar vairuotojas yra tinkamas dirbti.

3. Driver CPC ir DQC kontrolės

Sistema, kuri tvarko tik licencijų patikrinimus, atlieka tik pusę darbo. Daugeliui prekių ir keleivių operatorių Driver CPC statusas ir DQC galiojimo laikas yra tokie pat svarbūs operatyviai. Mums reikia vienos vietos, kur galėtume matyti, ar vairuotojas yra teisėtai ir praktiškai pasiruošęs dirbti, nesikeisdami tarp atskirų įrankių.

4. Įrodymų saugojimas ir pasirašyti įrašai

Auditams mums reikia įrašų, kurie lieka prijungti prie vairuotojo bylos. Tai apima patikrinimo rezultatus, įkeltus dokumentus, vadybininkų pastabas, mokymo įrašus, pripažinimo formas ir, jei taikoma, pasirašytus įrodymus. Sistema turėtų palengvinti įrašų saugojimą tiek išvykusiems, tiek esamiems darbuotojams, nes istoriniai įrodymai dažnai yra tai, ko prašoma.

5. Ataskaitos, atitinkančios operatoriaus licencijos realybę

Transporto vadybininkui reikia daugiau nei tik pasibaigusių licencijų sąrašo. Mums reikia ataskaitų, kurios rodo pavėluotus patikrinimus, artėjančius DQC galiojimo laikus, trūkstamus dokumentus, neišspręstas problemas ir išimtis pagal sandėlį, sutartį ar veiklos centrą. Taip pat mums reikia ataskaitų, kurias galime eksportuoti vidiniam peržiūrai ir valdybos ataskaitoms.

6. Nuorodos į platesnę atitiktį

Vairuotojų įrašai nesėdi izoliuotai. Jei tas pats operatorius taip pat tvarko MOT, metinius testus, prevencines technines apžiūras, tachografų analizę, defektų ataskaitas ir dokumentų galiojimo laikus, tai vairuotojų laikymas atskirame įrankyje sukuria spragas. Būtent tose spragose atsiranda praleisti terminai ir silpni įrodymų grandinės.

Jei norite gilesnio kontrolinio sąrašo prieš palygindami tiekėjus, mūsų gidas apie licencijų tikrinimo programinės įrangos palyginimą flotų atitikties užtikrinimui išdėsto punktus, kuriuos operatoriai dažniausiai praleidžia.

Kaip turėtų veikti licencijų tikrinimas praktikoje

Praktikoje licencijų tikrinimas turėtų sekti pakartotinį procesą, o ne ad hoc administracinę užduotį.

Pirmiausia, vairuotojo įrašas turėtų turėti pagrindinius duomenis: visą vardą, gimimo datą, adresą, licencijos numerį, kategorijas, pradžios datą, vaidmenį, sandėlį, tiesioginį vadovą ir bet kokias rizikos pastabas. Tai suteikia verslo kontekstą, nustatant peržiūros dažnumą ir sprendžiant, ką daryti su bet kokiais radiniais.

Antra, pats DVLA patikrinimas turėtų būti paprastas inicijuoti ir lengvai interpretuoti. Rezultatas turėtų rodyti teises, galiojimą, patvirtinimus ir bet ką, kas yra svarbu vaidmeniui. Pavyzdžiui, vairuotojas gali vis dar turėti galiojančią licenciją, tačiau nebeturėti kategorijos, reikalingos jam priskirtam transporto priemonei. Programinė įranga turi tai padaryti matomu.

Trečia, sistema turėtų paversti radinius veiksmais. Švarus rezultatas gali tiesiog nustatyti kitą peržiūros datą. Rezultatas su taškais gali inicijuoti vadybininko peržiūrą. Rimtas klausimas, pavyzdžiui, atšauktos teisės ar diskvalifikuojantis nusikaltimas, turėtų inicijuoti eskalaciją, darbo apribojimus ir dokumentuotą sprendimą.

Tai reiškia, kad programinė įranga turėtų palaikyti:

• numatytus patikrinimus pagal rizikos grupes
• rankinius patikrinimus, kai incidentas ar pranešimas reikalauja to
• išimtis, pažymėtas dėl patvirtinimų, teisių pokyčių ir galiojimo klausimų
• užduočių priskyrimą transporto biurui ar tiesioginiam vadovui
• pastabas ir priedus, susijusius su rezultatu
• užrakintą atliktų patikrinimų ir veiksmų istoriją

Peržiūros intervalai čia yra svarbūs. Nėra vieno įstatyminio JK intervalo, kuris tiktų kiekvienam operatoriui ir kiekvienam vaidmeniui. Svarbu turėti rizikos pagrindu sukurtą politiką ir nuosekliai jos laikytis. Kai kurie operatoriai tikrina kasmet mažos rizikos vairuotojams, dažniau didesnės rizikos vairuotojams, ir iš karto po incidentų, skundų, avarijų ar draudimo problemų. Svarbu, kad sistema užtikrintų politiką, kurią nustatome, o ne paliktų tai dienoraščio priminimams ir atminčiai.

Įrodymų saugojimas yra toks pat svarbus kaip ir pats patikrinimas. Jei DVSA klausia, kaip mes stebime vairuotojų teises, turime parodyti politiką, tvarkaraštį, atliktus patikrinimus, išimtis ir sekimą. Užrašas skaičiuoklėje, sakantis "viskas gerai", yra silpnas įrodymas. Data su rezultatu, peržiūrėtoju, rizikos rezultatu ir kita data yra daug stipresnis.

Operatoriams, kurie taip pat tvarko agentūros vairuotojus, darbo procesas turėtų apimti ir neįdarbinamus vairuotojus. Mes vis dar turime įrodyti, kad patikrinimai buvo atlikti prieš jiems dirbant pas mus, ir vėl laikantis intervalų, kurie atitinka mūsų politiką. Tas pats taikoma savininkams-vairuotojams ir subrangovams, kur sutartinė struktūra nepašalina mūsų poreikio kontroliuoti, kas vairuoja mūsų darbe.

Jei norite detalių apie patikrinimo dažnumą, įrodymus ir politikos kūrimą, mūsų gidas apie vairuotojų licencijų patikrinimus operatoriams išsamiau apima operatyvinę pusę.

Koks geras Driver CPC sekimas?

Gerai Driver CPC sekimas nėra tik galiojimo priminimas.

JK prekių ir keleivių operatoriams reikia žinoti, ar kiekvienas atitinkamas vairuotojas turi galiojantį DQC, kada jis pasibaigia, kokie mokymai buvo atlikti, kas lieka nebaigta ir kokių veiksmų buvo imtasi, jei vairuotojas artėja prie galiojimo pabaigos arba jau jo pasibaigęs. Jei programinė įranga tik saugo datų lauką, ji palieka per daug darbo už sistemos ribų.

Praktinis Driver CPC procesas turėtų apimti:

DQC statusas akimirksniu

Vairuotojo byla turėtų aiškiai rodyti dabartinį DQC statusą. Mes neturėtume atidaryti kelių ekranų, kad pamatytume, ar vairuotojas yra galiojantis, artėja prie galiojimo pabaigos ar jau pasibaigęs.

Galiojimo priminimai su laiku veikti

Priminti reikia pradėti pakankamai anksti, kad būtų galima užsakyti mokymus, o ne tik įspėti mus, kai kortelė artėja prie galiojimo pabaigos. Praktikoje operatoriai dažnai nori etapuotų priminimų, pavyzdžiui, keli mėnesiai iki galiojimo pabaigos, tada arčiau galiojimo pabaigos, tada kasdien ar kas savaitę, kai jau esame kritiniame lange.

Mokymo istorija ir įrodymai

Sistema turėtų saugoti atliktų modulių datas, įkeltus sertifikatus, jei taikoma, teikėjo duomenis ir bet kokias pastabas apie planuojamus kursus. Net jei galutinis teisėtas statusas yra pagrindinis klausimas, mokymo pėdsako išlaikymas padeda, kai vairuotojai keičia sandėlius, keičia planuotojus arba klausia, kas jau buvo padaryta.

Sekimo veiksmai

Artėjantis galiojimas turėtų sukurti darbą, o ne tik spalvą ekrane. Mums reikia užduočių mokymų užsakymui, kontaktavimui su vairuotoju, dalyvavimo patvirtinimui, užbaigimo patikrinimui ir, jei reikia, darbo apribojimui, kol statusas bus atkurtas.

Išimtys ir vaidmenų filtravimas

Ne kiekvienas vairuotojas flotėje turėtų būti sekamas Driver CPC tokiu pačiu būdu. Kai kurios furgonų flotės turės įvairių vaidmenų, kai kurie privačių nuomų ir taksi verslai turės skirtingus vietinius licencijavimo reikalavimus, kartu su ar vietoj sunkiųjų transporto priemonių įsipareigojimų, o kai kurie biuro darbuotojai gali turėti licencijas, bet niekada nevairuoti operatyviai. Sistema turėtų leisti mums taikyti Driver CPC kontrolę tik ten, kur tai aktualu.

Tai yra viena vieta, kur JK ir platesnės ES kontekstas gali praktikoje skirtis. Operatoriai, dirbantys tik Didžiojoje Britanijoje, dažniausiai orientuojasi į JK taisykles ir įrodymus, kurių tikisi DVSA ir Transporto komisaras. Jei vykdote tarptautinį darbą, taip pat galite turėti omenyje, kaip įrašai pateikiami kitoms institucijoms ir mokymo teikėjams. Programinė įranga neturėtų manyti, kad vienas dydis tinka visiems, jei jūsų veikla apima daugiau nei vieną režimą.

Gera sistema taip pat turėtų tinkamai tvarkyti pasibaigusius DQC įrašus. Neužtenka jų pažymėti raudonai. Mums reikia parodyti, koks sprendimas buvo priimtas, ar vairuotojas buvo sustabdytas, perkeliamas į ne vairuojamas pareigas, užsakytas mokymams, ar pašalintas iš aktyvaus sąrašo. Tas valdymo veiksmas dažnai įrodo, kad kontrolė yra reali.

Kodėl vairuotojų įrašai turėtų būti kartu su kitais atitikties aspektais

Operatoriai paprastai pradeda spręsti vieną skausmo tašką, licencijų patikrinimus, CPC datas, tachografų analizę, MOT planavimą. Problema kyla vėliau, kai įrodymai yra išskirstyti per kelias sistemas, kurios nesikalba tarpusavyje.

Kasdienėje transporto valdyme vairuotojų įrašai dažnai turi būti susiję su:

• MOT ir metinių testų tvarkaraščiais
• prevencinėmis techninėmis apžiūromis
• vairuotojų apžiūromis ir defektų ataskaitomis
• tachografų įrašais ir pažeidimais
• mokymais ir politikos pripažinimais
• dokumentų galiojimo laikais ir draudimo įrašais
• veiklos centru, transporto priemonių ir priekabų paskirstymu
• VOL veiksmais ir licencijų administravimu
• VOR sprendimais ir dirbtuvės statusu

Paimkite paprastą pavyzdį. Vairuotojas praneša apie defektą per apžiūrą, transporto priemonė tampa VOR, planuotojas perkelia kitą vienetą, o transporto biuras vėliau peržiūri, ar vairuotojas teisingai ir laiku atliko patikrinimą. Jei defektų sistema, transporto priemonės byla ir vairuotojo byla yra atskiros, mes praleidžiame laiką rekonstruodami, kas įvyko. Jei jie yra kartu, įrodymų grandinė yra daug aiškesnė.

Tas pats taikoma tachografų klausimams. Vairuotojas su pakartotiniais pažeidimais gali reikalauti dažnesnių licencijų peržiūrų, papildomo mokymo ar oficialaus sekimo. Jei tachografų analizė yra atskirta nuo vairuotojo įrašo, tie ryšiai priklauso nuo kažkieno atminties, kad būtų prisijungti taškai rankiniu būdu.

Tai viena iš priežasčių, kodėl mes sukūrėme Operator Compliance aplink operatoriaus licencijos realybę, o ne aplink vieną izoliuotą funkciją. Fleeta Limited valdo sunkvežimius pagal operatoriaus licenciją, todėl žinome, kad slėgio taškai yra susiję. DVSA Gidas, kaip išlaikyti kelio tinkamumą, nelaiko atitikties kaip nesusijusių administracinių užduočių rinkinio, ir programinė įranga taip pat neturėtų.

Taip pat yra išoriniai įrašų patikrinimai, kuriuos kai kurie operatoriai turi apsvarstyti kartu su vairuotojų bylomis. Draudimo patikrinimas gali apimti askMID duomenis iš Motor Insurers' Bureau, dar vadinamo MIB. Priklausomai nuo darbo proceso, operatoriai gali norėti priminimų ar įrodymų laukų, kurie rodo, ar draudimas, transporto priemonių paskirstymas ir vairuotojų teisės buvo suderinti naudojimo metu.

Kur įmonės jau naudoja kitas sistemas, integracija yra svarbi. Kai kurie operatoriai jau turi telematikos, HR, atlyginimų, dirbtuvių ar planavimo įrankius. Kiti gali naudoti analizės sluoksnius, tokius kaip Fleetalyse, arba darbo proceso įrankius, tokius kaip Logivo.AI. Tokiais atvejais vertė nėra viską pakeisti. Svarbu užtikrinti, kad vairuotojų atitikties įrašai išliktų pilni, aktualūs ir atsekami per svarbias sistemas.

Mūsų vairuotojų apžiūros ir defektų ataskaitų gidas paaiškina, kodėl vairuotojo įrašas ir transporto priemonės įrašas turi palaikyti vienas kitą, o ne būti valdomi kaip atskiros atitikties užduotys.

Klausimai, kuriuos reikia užduoti prieš pasirenkant sistemą

Prieš pasirinkdami sistemą, užduokite tiekėjams klausimų, kurie patikrins, kaip programinė įranga veiks auditų spaudimo sąlygomis, o ne tik pardavimo demonstracijoje.

Operatyviniai klausimai

• Ar galime nustatyti skirtingus licencijų tikrinimo intervalus pagal vaidmenį, sandėlį, amžių, taškų lygį ar rizikos kategoriją?
• Ar galime inicijuoti nenumatytus DVLA patikrinimus ir užfiksuoti, kodėl jie buvo atlikti?
• Kaip pažymimi patvirtinimai, teisių pokyčiai ir medicininiai klausimai?
• Ar galime stebėti Driver CPC ir DQC statusą toje pačioje vairuotojo byloje kaip licencijų patikrinimus?
• Ar galime užfiksuoti atliktus veiksmus, o ne tik galiojimo datą ar praeitį/nepraeitį rezultatą?
• Ar agentūros vairuotojai, savininkai-vairuotojai ir išvykę darbuotojai gali būti išlaikyti sistemoje su visa istorija?

Ataskaitų klausimai

• Ar galime pateikti ataskaitas apie pavėluotus patikrinimus, artėjančius galiojimo laikus ir neišspręstas problemas pagal sandėlį ar veiklos centrą?
• Ar galime eksportuoti auditams paruoštas ataskaitas valdymo peržiūrai ir Transporto komisaro įrodymams?
• Ar galime matyti istorinius statusus ankstesnėmis datomis, o ne tik dabartinius įrašus?
• Ar dokumentų įkėlimai, pastabos ir pasirašyti pripažinimai yra įtraukti į ataskaitas ar lengvai atgauti?

Auditų ir įrodymų klausimai

• Ar kiekvienas pokytis turi datą, laiką ir vartotojo antspaudą?
• Ar įrašai gali būti redaguojami be auditų takelio?
• Kiek laiko saugomi istoriniai įrašai?
• Ar galime saugoti politikos pripažinimus, tyrimo pastabas ir nuskenuotus dokumentus vairuotojo byloje?
• Jei vairuotojas buvo sustabdytas dėl pasibaigusio DQC ar teisių klausimo, ar galime įrodyti, kada tas sprendimas buvo priimtas?

Integracijos klausimai

• Ar yra REST API vairuotojų, transporto priemonių ir atitikties duomenims?
• Ar yra webhooks, kad kitos sistemos galėtų reaguoti į naujus įspėjimus, galiojimo laikus ar statuso pokyčius?
• Ar sistema gali keistis duomenimis su HR, atlyginimų, telematikos ar tachografų platformomis?
• Jei jau naudojame kitą platformą daliai darbo proceso, kokie duomenys gali būti sinchronizuoti ir kas vis dar turi būti įvedama rankiniu būdu?

Praktinės įgyvendinimo klausimai

• Kaip importuojami esami vairuotojų įrašai?
• Ar galime migruoti istorinius licencijų patikrinimus ir CPC datas, ar pradedame nuo nulio?
• Kiek greitai transporto vadybininkai gali pamatyti, kas yra numatyta, pavėluota ar apribota vairuoti?
• Kaip atrodo kasdienis išimčių procesas transporto biurui?

Tinkamas atsakymas paprastai nėra sistema su daugiausia funkcijų. Tai ta, kuri padaro jūsų kontrolės procesą pakartotinį, matomą ir lengvai įrodytą.

Daugeliui JK operatorių tai reiškia pasirinkti vairuotojų licencijų tikrinimo ir CPC sekimo programinę įrangą, kuri veikia kaip platesnės operatoriaus atitikties sistemos dalis, o ne kaip atskira priminimų priemonė. Jei ji gali parodyti patikrinimą, riziką, veiksmą ir rezultatą, ir jei ji sklandžiai susijungia su likusia flotės įrašu, ji padarys daug daugiau, kad išlaikytume mus auditui paruoštus, nei dar viena skaičiuoklė kada nors galėtų.

OperatorCompliance tai yra standartas, kurį mes kuriame Operator Compliance, nes transporto vadybininkams reikia įrašų, kurie atlaiko realų pasaulį, su DVSA lūkesčiais, operatoriaus licencijos pareigomis ir kasdieniu flotės spaudimu visame paveiksle.

Koks pagrindinis vairuotojų licencijų tikrinimo ir CPC sekimo programinės įrangos darbas?

Ji padeda operatoriams išlaikyti vairuotojų teisių patikrinimus, Driver CPC datas, DQC įrašus, priminimus ir įrodymus vienoje vietoje, kad galėtų parodyti aiškų atitikties procesą.

Ar DVLA patikrinimas pats savaime yra pakankamas?

Ne. DVLA patikrinimas yra tik dalis įrašo. Operatoriams taip pat reikia peržiūros datų, sekimo veiksmų, saugomų įrodymų ir proceso, kuris gali būti parodytas DVSA, jei to bus paprašyta.

Kodėl Driver CPC sekimas turi turėti savo darbo procesą?

Todėl, kad galiojimo datos, trūkstamos kortelės, agentūros vairuotojai ir planuojami mokymai visi reikalauja veiksmų prieš pasibaigiant terminui. Paprastas priminimų sąrašas dažnai nėra pakankamas.

Ar vairuotojų programinė įranga turėtų būti atskirta nuo transporto priemonių atitikties programinės įrangos?

Kai kurios flotės gali valdyti atskirus įrankius, tačiau daugelis operatorių gauna naudos, kai vairuotojų įrašai yra kartu su transporto priemonių, priekabų ir tachografų atitiktimi vienoje sistemoje.

Kokios integracijos yra vertos paklausti?

Klauskite apie DVLA duomenų tvarkymą, tachografų importą, dokumentų saugojimą, ataskaitų eksportą, REST API parinktis ir webhooks, jei reikia, kad duomenys judėtų tarp sistemų.