Kelių tinkamumo įrašų programinė įranga, kuri atlaiko auditą

Jei jums reikia kelių tinkamumo įrašų, kurie atlaiko DVSA skambučius, programinė įranga turi daryti daugiau nei tiesiog saugoti PDF failus ir siųsti priminimus. Ji turi atspindėti, kaip JK tikrinamas operatoriaus licencijos failas. Tai reiškia aiškias patikros istorijas, defektų darbo eigą, taisymo įrodymus, MOT ir metinių testų kontrolę, VOR laikotarpius, vairuotojų apžvalgas, priekabų įrašus ir patikimą auditą, rodantį, kas ir kada ką padarė.

Čia programinė įranga, skirta valdyti DVSA gaires dėl kelių tinkamumo įrašų, arba pasitvirtina, arba nusivylia. Testas paprastas. Ar galime greitai, tvarkingai, su datomis, parašais ir susijusiais įrodymais, kurie turi prasmę transporto vadybininkui, priežiūros teikėjui ir, jei reikia, Kelių komisijos nariui, pateikti tinkamus įrašus?

Kokius įrašus DVSA gidas iš tikrųjų tikisi, kad kontroliuosite

DVSA Gidas dėl kelių tinkamumo išlaikymo yra praktiškas. Jis neprašo operatorių laikyti įrašų vien dėl to, kad tai daryti. Jis tikisi, kad mes kontroliuosime priežiūros sistemą, kuri yra už flotilės, ir galėsime tai įrodyti.

Mažiausiai tai reiškia, kad reikia laikyti visus suplanuotus saugos patikrinimų įrašus kiekvienam automobiliui ir priekabai. Šie įrašai turi rodyti patikros datą, rida, jei tai aktualu, patikros intervalą, tikrinamus daiktus, rezultatą, bet kokius rastus defektus, kas atliko patikrą ir kas peržiūrėjo ar patvirtino darbą, jei tai yra proceso dalis. Jei patikra praleista, perkelta ar atlikta anksčiau, turi būti priežastis ir įrašas.

Defektų pranešimas yra dar viena pagrindinė sritis. DVSA tikisi kasdienių defektų pranešimo procedūrų, įskaitant nulinio defekto pranešimą, jei tai yra operatoriaus sistemos dalis. Praktikoje įrašai turi rodyti vairuotojo apžvalgos patikrą, bet kokius praneštus defektus, ar transporto priemonė ar priekaba buvo nuimta nuo kelio, kokių veiksmų buvo imtasi ir kas pasirašė taisymą. Jei defektas yra saugos kritinis, mums reikia aiškaus pėdsako, rodančio, kad transporto priemonė nebuvo naudojama, kol ji nebuvo suremontuota.

MOT ir metinių testų datos taip pat turi būti griežtai kontroliuojamos. HGV ir PSV JK atveju metiniai testai yra operatoriaus licencijos atitikties paveiksle, kaip tai dažnai negerai tvarko bendros flotilės sistemos. Praleistas metinių testų laikas gali paveikti tiek atitiktį, tiek transporto priemonės prieinamumą. Lengvoms transporto priemonėms MOT kontrolė vis dar svarbi, tačiau operatoriaus licencijos kontekstas skiriasi. Kur JK taisyklės skiriasi nuo platesnių ES lūkesčių, tai yra viena iš sričių, kur reikia būti atsargiems. Sistema, sukurta aplink bendrą Europos flotilės priežiūrą, gali neatspindėti, kaip DVSA ir Kelių komisijos narys žiūri į JK operatoriaus įrodymus.

VOR įrašai yra svarbūs dėl tos pačios priežasties. Neužtenka žinoti, kad transporto priemonė buvo neprieinama. Turime žinoti, kada ji tapo VOR, kodėl, koks defektas ar remontas tai sukėlė, kada ji grįžo į tarnybą ir ar prastova atitinka priežiūros ir defektų įrašą. Jei šios datos nesutampa, įrašų rinkinys pradeda atrodyti nepatikimas.

Remontų ir priežiūros istorija taip pat turi būti tinkamai susieta. Tai apima dirbtuvių darbo lapus, sąskaitas faktūras, kurias naudojame kaip palaikymo įrodymus, remonto pastabas, pakeistus komponentus, stabdžių testų rezultatus, jei taikoma, ir bet kokį papildomą darbą iš patikrinimų ar defektų. Švarus operatoriaus licencijos failas leidžia mums sekti liniją nuo pranešto klausimo iki taisymo ir grįžimo į tarnybą.

Vairuotojų apžvalgos įrodymai yra ypač svarbūs audito metu. Transporto vadybininkas gali žinoti, kad patikros atliekamos, tačiau DVSA ieškos įrodymų. Įrašas turėtų rodyti datą, laiką, vairuotojo tapatybę, dalyvaujančią transporto priemonę ar priekabą, praneštus defektus ar nulinį grąžinimą ir bet kokį pasirašytą pripažinimą. Jei naudojami agentūros vairuotojai, sistema turėtų nuosekliai fiksuoti tuos įrodymus.

Galiausiai, pasirašyti įrodymai yra svarbūs. Nesvarbu, ar tai techniko patvirtinimas, vairuotojo deklaracija, transporto biuro peržiūra ar trečiosios šalies priežiūros teikėjo patikros lapas, turime žinoti, kas pasirašė ką. Įrašas, kuris negali parodyti atsakomybės, yra silpnesnis, nei atrodo.

Ką palyginti programinėje įrangoje, skirtą kelių tinkamumo įrašams

Palygindami sistemas, pradėkite nuo planavimo. Ar programinė įranga gali planuoti patikras pagal datą, ridą, variklio valandas ar fiksuotą modelį, pavyzdžiui, kas 6 savaites? Ar ji gali susidoroti su mišriomis flotilėmis, kur kai kurie turtai yra skirtingais intervalais? Ar ji gali išdėstyti tuos intervalus pagal ISO savaitę, kas yra tai, kaip dauguma transporto biurų ir dirbtuvių iš tikrųjų planuoja metus?

Kitas punktas yra dokumentų kontrolė. Mums reikia vienos vietos patikros lapams, stabdžių testų ataskaitoms, MOT ar metinių testų dokumentams, remonto įrašams, draudimo dokumentams ir palaikymo failams. Geras programinė įranga turėtų leisti mums prijungti įrašus prie tikslios transporto priemonės, priekabos, vairuotojo ar įvykio. Katalogas, pilnas įkeltų failų, nėra pakankamas, jei niekas nėra tinkamai indeksuotas.

Priminti taip pat turi būti daugiau nei bendri pranešimai. Turėtume galėti nustatyti terminus patikroms, metiniams testams, MOT, draudimui, kalibravimams, licencijų patikroms, Driver CPC, DQC galiojimo laikui ir kitiems operatoriaus užduotims. Punktas nėra gauti daugiau el. laiškų. Tai žinoti, kas yra laiku, kas yra pavėluota ir kokia veiksmai yra priskirti.

Defektų darbo eiga yra viena iš stipriausių palyginimo vietų. Ar vairuotojai gali pranešti apie defektus iš kelio? Ar biuras gali juos triaguoti? Ar defektas gali būti pažymėtas kaip saugos kritinis, perkelti į VOR, priskirti remontui ir pasirašyti su įrodymais prieš išleidžiant turtą? Ar nuliniai defektai gali būti užfiksuoti taip pat aiškiai? Jei ne, sistema gali atrodyti tvarkinga, tačiau vis tiek paliks spragų audito pėdsake.

Priekabų įrašai dažnai atskleidžia silpnas sistemas. Daugelis platformų pakankamai gerai tvarko varomas transporto priemones, tačiau priekabas traktuoja kaip antraeiles. JK operatoriai to negali sau leisti. Priekabų patikros, defektai, metiniai testai, jei taikoma, padangų įrašai ir VOR laikotarpiai turi turėti tą pačią discipliną kaip ir transporto priemonių įrašai. Mes tai išsamiau aptarėme savo gide dėl priekabų patikros programinės įrangos pasirinkimo DVSA įrašams.

Vairuotojų patikros ir vairuotojų atitiktis taip pat turėtų būti šalia kelių tinkamumo įrašų. Tai apima licencijų patikras pagal DVLA, Driver CPC ir DQC galiojimo kontrolę, ir apžvalgos įrodymus. Jei programinė įranga skirsto tuos įrašus į atskirus modulius be sujungto vaizdo, transporto vadybininkas vis tiek turės kurti įrodymų paketą rankiniu būdu.

Tachografų nuorodos yra dar viena praktinė svarba. Kelių tinkamumas ir vairuotojų atitiktis yra skirtingos temos, tačiau jos susitinka operatoriaus licencijos faile. Jei ta pati sistema gali laikyti tachografo analizę, pažeidimų sekimą ir vairuotojų įrašus kartu su priežiūros įrodymais, biuras yra daug geriau pasiruošęs DVSA vizitui.

Ataskaitos taip pat svarbios. Ar galime pateikti transporto priemonės istoriją, rodančią patikras, defektus, remontus ir prastovas vienoje sekoje? Ar galime parodyti praleistas patikras, pavėluotus veiksmus ir pasikartojančius defektus? Ar galime išvalyti įrašus? Audito metu greitis yra svarbus. Jei mums reikia pusės dienos, kad surinktume failą, sistema neatlieka savo darbo.

Visų pirma, palyginkite auditų pėdsako kokybę. Turėtume galėti matyti, kada įrašas buvo sukurtas, pakeistas, uždarytas ar pasirašytas, ir kas tai padarė. Tai yra standartas, su kuriuo reikia lyginti, o ne tik skydelio išvaizda. Didesniam palyginimo kontroliniam sąrašui žiūrėkite mūsų straipsnį apie kaip palyginti kelių tinkamumo programinę įrangą DVSA įrodymams.

Kodėl bendros flotilės sistemos dažnai nepakankamos

Bendros flotilės sistemos dažnai žada priežiūrą, atitiktį ir dokumentų saugojimą viename pakete. Problema ta, kad daugelis jų sukurtos plačiai flotilės administracijai, o ne operatoriaus licencijos įrodymams.

Pirmas bendras trūkumas yra patikros logika. Sistema gali fiksuoti paslaugas ir remontus, tačiau ne tikras saugos patikros tvarkaraščius su suplanuotomis datomis, užbaigtomis datomis, intervalų matomumu ir praleistų patikrų pranešimu. Tai svarbu, nes DVSA domisi, kad priežiūros sistema būtų kontroliuojama, o ne tik ar egzistuoja sąskaitos faktūros.

Antras trūkumas yra defektų tvarkymas. Daugelis platformų gali užregistruoti klaidą, tačiau jos nesukuria visos defektų darbo eigos su vairuotojo pranešimu, biuro peržiūra, VOR sprendimu, remonto įrodymais ir grąžinimu į tarnybą. Skaičiuoklės čia yra dar silpnesnės. Jos gali parodyti, kad defektas įvyko, tačiau neatskleidžia atsakomybės grandinės aplink jį.

Diagramos pagrindu veikiančios sistemos nesugeba dėl panašių priežasčių. Sieninis planuotojas ar bendras kalendorius gali priminti, kad metinis testas yra numatytas, tačiau negali pateikti pasirašytų apžvalgų, susijusių remonto įrodymų ar visos istorijos, kas pakeitė patikros datą ir kodėl.

Priekabų atitiktis yra dar viena dažna silpnybė. Mišriose operacijose priekabų įrašai dažnai atskiriami nuo transporto priemonių įrašų arba valdomi atskiruose skaičiuoklėse. Tai yra valdomas iki audito, kai biurui reikia viso vaizdo ir jis randa, kad įrodymai išsklaidyti po el. laiškus, dirbtuvių aplankus ir vietinius diskus.

Bendros sistemos taip pat dažnai yra silpnos dėl JK specifinių operatorių reikalavimų. Jos gali pakankamai gerai tvarkyti transporto priemonių kelių mokestį ir aptarnavimą, tačiau ne metinių testų užsakymus, operatoriaus licencijos stiliaus priežiūros failus ar tai, kaip Kelių komisijos narys tikisi, kad įrodymai bus organizuoti. Jei sistema sukurta aplink bendrą ES flotilės praktiką, ji gali vis tiek praleisti JK detales, kurios yra svarbios viešajai apklausai ar biuro vertinimui.

Tada yra pasirašytų įrodymų problema. Daug sistemų saugo skenavimus. Mažiau gali parodyti tinkamą vairuotojų deklaracijų, technikų patvirtinimų ir valdymo peržiūrų laikotarpį. Kai klausimas yra ne tik „ar turite įrašą?“, bet „ar galite parodyti, kad jūsų sistema veikia?“, tas skirtumas tampa akivaizdus.

Kaip Operator Compliance atitinka JK operatoriaus licencijos failą

Operator Compliance yra sukurtas šiam JK operatoriaus licencijos kontekstui. Mes jį sukūrėme aplink įrašus ir terminus, kuriuos transporto vadybininkai ir operatoriai turi kontroliuoti pagal DVSA gaires, o ne aplink bendrą flotilės administravimą.

Praktikoje tai reiškia, kad transporto priemonių, priekabų ir vairuotojų įrašai yra kartu. Galime sekti patikras, defektus, remontus, VOR laikotarpius, MOT ir metinių testų datas bei palaikymo dokumentus vienoje sistemoje. Vairuotojų apžvalgos ir pasirašyti įrodymai sudaro tą pačią atitikties paveikslą, o ne gyvena atskiroje programėlėje, neturint aiškaus ryšio su turto failu.

Mes taip pat sukūrėme sistemą, kad palaikytume tachografo analizę ir platesnį vairuotojų įrašą. Daugeliui operatorių mėnesinis flotilės paketas Kelių komisijos failui reikalauja kelių tinkamumo įrašų kartu su licencijų patikromis, Driver CPC ir DQC kontrole bei tachografo įrodymais. Laikydami juos kartu sumažiname rankinio darbo kiekį, kurį biuras turi atlikti prieš DVSA vizitą. Mes paaiškiname šį sujungtą požiūrį savo straipsnyje apie mėnesinio flotilės paketo pasirinkimą, kuris atlaiko DVSA.

Mūsų patirtis čia yra svarbi. OperatorCompliance sukūrė Fleeta Limited, ir mes tai sakome aiškiai, nes patys vykdome sunkvežimius pagal operatoriaus licenciją. Tai veikia detalėms. Mes žinome, kodėl patikros planuotojai turi dirbti pagal ISO savaitę. Mes žinome, kodėl transporto vadybininkai turi matyti VOR laikotarpius prieš defektus ir remontus, o ne atskirame prieinamumo ataskaitoje. Mes žinome, kodėl priekaba negali būti laikoma antriniu turtu, ir kodėl pasirašytas nulinio defekto ataskaitas gali būti toks pat svarbus kaip ir praneštas defektas.

Tas pats praktinis požiūris taikomas sujungtiems įrašams. Licencijų tikrinimas pagal DVLA, draudimo patikrinimas per askMID ir duomenų patikrinimai, susiję su Motor Insurers' Bureau, dažnai sutrumpinami iki MIB, visi yra realaus pasaulio atitikties aplinkoje, kurioje dirba operatoriai. Taip pat yra integracijos su kitomis sistemomis, nesvarbu, ar tai per REST API, webhooks, ar nuorodas į įrankius, tokius kaip Fleetalyse ar Logivo.AI, kur operatorius nori, kad duomenys tekėtų tarp platformų.

Mes taip pat pripažįstame dokumentus, susijusius su operatoriaus licencijavimu. Įrašai dažnai turi palaikyti vidines peržiūras, priežiūros teikėjų priežiūrą ir atnaujinimus, atliktus per VOL. Punktas nėra sukurti daugiau administravimo. Tai sukurti švaresnį, greitesnį, labiau ginamą įrašų rinkinį.

Kokio tipo operatorius reikia kokio lygio sistemos

Ne kiekvienam operatoriui reikia tokio pat lygio programinės įrangos, tačiau kiekvienam operatoriui reikia įrašų, kurie turi prasmę po peržiūros.

Vairuotojas su vienu automobiliu gali nereikėti sudėtingų integracijų ar daugiadepo darbo srautų. Jiems vis tiek reikia patikimo patikros, MOT ar metinių testų datų, defektų, remontų ir vairuotojų įrodymų valdymo. Tokiai operacijai svarbiausia yra paprastumas ir greitis. Jei sistema per sunki, įrašai prarandami.

Krovinių vežėjai ar furgonų flotilės gali turėti mažiau operatoriaus licencijos įsipareigojimų, jei transporto priemonės patenka už HGV ir PSV operatoriams taikomų reikalavimų ribų, tačiau jiems vis tiek reikia tvirtų priežiūros ir vairuotojų įrašų. Kur flotilės maišo furgonus su sunkesnėmis transporto priemonėmis, programinė įranga turi aiškiai atspindėti abi aplinkas, o ne priversti vieną procesą visiems turtams.

Krovinių vežėjai su priekabomis reikia stipresnio priekabų valdymo nei dauguma pagrindinių sistemų teikia. Tai reiškia atskirus patikros tvarkaraščius, defektų žurnalus, VOR kontrolę ir metinių testų matomumą, jei taikoma. Jei priekabos juda tarp vienetų ir depų, audito pėdsakas turi sekti pačią priekabą.

Autobusų ir mikroautobusų operatoriai dažnai reikia dar gilesnio kontrolės lygio. Metinių testų planavimas, patikros tvarkaraščiai, defektų valdymas ir vairuotojų atitiktis visi turi svorį, o įrodymai dažnai turi būti pateikti greitai. Tas pats pasakytina apie mišrius krovinių ir keleivių veiksmus.

Įdarbinimo ir vairuotojų agentūros yra atskira byla. Jos gali nereikėti visiškos dirbtuvių priežiūros kontrolės kiekvienam turtui, tačiau joms reikia stiprių vairuotojų įrašų, licencijų tikrinimo, Driver CPC ir DQC sekimo bei įrodymų, kad tie, kurie tiekia vairuotojus, yra tinkamai valdoma. Jei jie taip pat tiesiogiai valdo transporto priemones, reikalavimas plečiasi.

Taksi ir privačių nuomos firmos patenka į kitą mišrią kategoriją. Kai kurie iš jų daugiausia reikia vairuotojų ir transporto priemonių dokumentų kontrolės. Kiti valdo didesnes flotiles su dirbtuvių veikla ir formalesne atitikties priežiūra. Tinkamas sistemos lygis priklauso nuo to, ar verslas valdo izoliuotus atnaujinimus, ar visą operatyvinį failą.

Sprendžiamasis veiksnys dažnai nėra tik flotilės dydis. Tai sudėtingumas. Kuo daugiau judančių dalių turime, transporto priemonių, priekabų, agentūros vairuotojų, išorinių priežiūros, kelių tachografų įsipareigojimų, tuo labiau mums reikia vienos sistemos, kuri gali sujungti įrodymus.

Klausimai, kuriuos reikia užduoti prieš perkeliant savo įrašus į vieną sistemą

Prieš perkeliant savo įrašus, paklauskite, kaip veikia migracija. Ar esamus transporto priemonių, priekabų ir vairuotojų duomenis galima švariai importuoti? Ar istorinius patikrinimus, defektus ir dokumentų archyvus galima įtraukti, ar jie amžinai liks už sistemos ribų?

Paklauskite apie vartotojų prieigą. Ar transporto vadybininkai, dirbtuvių darbuotojai, vairuotojai ir išoriniai priežiūros teikėjai gali turėti tinkamas teises, nematydami visko? Ar parašai ir veiksmai gali būti susieti su pavadinimu vartotojais?

Patikrinkite, kaip planavimas veikia praktikoje. Ar sistema gali planuoti pagal ISO savaitę? Ar ji gali tvarkyti mišrius intervalus ir perkelti patikras, išlaikydama originalų auditą?

Paklauskite, kokios integracijos yra prieinamos. Jei jau naudojate kitus įrankius, ar programinė įranga gali prisijungti per REST API ar webhooks? Jei pasikliaujate išoriniais duomenų šaltiniais ar ataskaitų įrankiais, ar įrašai gali būti dalijami be rankinio įvedimo?

Duomenų eksportas yra dar vienas svarbus punktas. Ar galite eksportuoti įrašus naudingu formatu, jei reikia pateikti failą valdymui, tyrėjui ar tiekėjo pakeitimui? Uždara sistema yra rizika.

Galiausiai, užduokite paprasčiausią auditų klausimą. Jei rytoj apsilankytų DVSA, kaip greitai galėtumėte pateikti transporto priemonės ar priekabos visą istoriją, įskaitant patikras, defektus, remontus, VOR laikotarpius, MOT ar metinių testų įrodymus ir pasirašytas apžvalgas? Jei atsakymas matuojamas minutėmis, o ne valandomis, jūs žiūrite į sistemą, sukurtą operatoriaus atitikties, o ne tik flotilės administravimui.

Tai yra standartas, kurio laikomės Operator Compliance. Programinė įranga neturėtų tik laikyti įrašų. Ji turėtų padėti mums vykdyti priežiūros ir atitikties sistemą, kuri atlaiko, kai kas nors prašo pamatyti įrodymus.