Kaip palyginti kelių tinkamumo programinę įrangą DVSA įrodymams

Palydami kelių tinkamumo programinę įrangą DVSA įrodymams, pagrindinis klausimas nėra, kuri sistema turi protingiausią valdymo skydelį. Svarbu, ar įrašai atlaikys, jei DVSA atliks tyrimą, arba jei Kelių komisijos narys paprašys jūsų bylos. Daugumai operatorių tinkama sistema yra ta, kuri padeda žmonėms atlikti teisingą užduotį teisingą dieną, o tada išlaiko aiškų, pasirašytą, laiko žymėtą įrašą apie tai, kas įvyko, kas buvo praleista ir kas buvo padaryta toliau.

Tai yra standartas, kurį naudojame Operator Compliance. Mes kuriame operatoriams, kuriems reikia savo transporto priemonių, priekabų ir vairuotojų įsipareigojimų vienoje vietoje, su įrašais, kurie atspindi, kaip atitiktis veikia realiose flotose. Jei lyginate DVSA kelių tinkamumo atitikties programinę įrangą, pirmiausia vertinkite ją pagal įrodymus, darbo eigą ir operatoriaus licencijos riziką. Grafika gali būti antroje vietoje.

Ką operatoriai turėtų palyginti prieš pirkdami

Transporto vadybininkai paprastai mato tas pačias pažadas kiekviename demonstravime. Lengvas planavimas. Realaus laiko įspėjimai. Geresnis matomumas. Švaresnė ataskaita. Šios dalykai yra svarbūs, tačiau jų nepakanka.

Praktiniai pirkimo kriterijai yra konkretesni.

Pirmiausia palyginkite auditų taką. Paklauskite, ką programinė įranga įrašo, kai saugos patikra yra suplanuota, atlikta, atidėta, atšaukta arba praleista. Paklauskite, ar ji saugo faktinį patikros dokumentą, kas jį pasirašė, kada jis buvo pasirašytas ir ar vėlesni redagavimai yra matomi. Jei sistema leidžia vartotojams perrašyti įrašą, nesaugodama originalios istorijos, tai yra rizika.

Antra, palyginkite kasdienį naudojimą. Atitikties sistema veikia tik tuo atveju, jei planuotojai, dirbtuvės darbuotojai, vairuotojai, administracijos darbuotojai ir transporto vadybininkai gali ją atnaujinti per užimtą savaitę. Programinė įranga gali atrodyti stipri demonstracijoje, tačiau praktikoje gali nepavykti, jei reikia per daug paspaudimų, kad įrašytumėte defektą, perkelkite patikrą, pažymėtumėte transporto priemonę VOR arba pridėtumėte įrodymus po remonto.

Trečia, palyginkite, kaip sistema tvarko operatoriaus licencijos ekspoziciją. Praleistas patikros intervalas, neužbaigtas saugos defektas, priekaba be galiojančio grafiko arba vairuotojas su pasibaigusiu DQC nėra tik administraciniai trūkumai. Tai yra problemos, kurios gali pasirodyti DVSA biuro vertinime, priežiūros tyrime arba viešame tyrime. Geras programinė įranga turėtų padaryti šias rizikas matomas anksti, o ne tiesiog pranešti apie jas po įvykio.

Ketvirta, palyginkite, ar programinė įranga yra sukurta pagal JK operatorių reikalavimus, o ne tik bendrą flotės valdymą. JK prekių transporto priemonių ir PSV operatoriai reikia įrašų, kurie atspindi DVSA Gidą dėl kelių tinkamumo palaikymo, metinių testų ir MOT datų, stabdžių testavimo įrodymų, priekabų istorijos, tachografo įsipareigojimų ir tokios bylos, kurią tikisi pamatyti Kelių komisijos narys. Bendras flotės produktas gali būti naudingas naudojimui ir išlaidoms, tačiau vis tiek paliks atitikties įrodymus silpnus.

Pagaliau, palyginkite, kas nutinka, kai kažkas nepavyksta. Nėra flotės, kuri veiktų puikiai visus metus. Patikros yra perplanavimas. Transporto priemonės genda. Vairuotojai vėluoja pateikti defektus. Dirbtuvių pajėgumai keičiasi. Geriausios sistemos nesistengia apsimesti, kad išimtys niekada neįvyksta. Jos rodo išimtį, priežastį, sprendimą ir korekcinę veiklą.

Jei norite platesnio kontrolinio sąrašo apie auditui orientuotus pirkimo kriterijus, mūsų gidas apie programinę įrangą, kuri atlaiko DVSA auditą pateikia daugiau detalių.

Ar ji iš tikrųjų laikosi DVSA Gido dėl kelių tinkamumo palaikymo

Tai yra pirmasis techninis testas. Paprašykite tiekėjo parodyti, ekranas po ekrano, kaip sistema palaiko įrašus ir kontrolę, kuriuos operatoriai turi laikyti pagal DVSA Gidą dėl kelių tinkamumo palaikymo.

Pradėkite nuo saugos patikrų. Ar galite nustatyti patikros dažnius pagal transporto priemonę ar priekabą? Ar šie intervalai gali skirtis pagal naudojimą, amžių, rida, apkrovą ar veikimo sąlygas? Ar sistema gali planuoti į priekį kalendoriaus datomis ir parodyti, kas yra numatyta pagal depą, flotę ar rangovą? Jei jūsų verslas veikia pagal fiksuotą dirbtuvių ciklą, ar ji gali planuoti pagal ISO savaitę, taip pat pagal datą?

Tada pažvelkite į defektų ataskaitas. Kasdieniai apžvalgos patikrinimai ir vairuotojų pranešti defektai reikalauja daugiau nei tik žymėjimo langelio. Sistema turėtų užfiksuoti defektą, datą ir laiką, pranešusį vairuotoją, susijusią transporto priemonę ar priekabą, sunkumą, atliktą veiksmą ir ar defektas buvo ištaisyta prieš naudojimą ar atidėta su priežastimi. Ji taip pat turėtų parodyti, kada buvo pateikta nulinė defekto ataskaita, jei jūsų procesas to reikalauja, ir ji turėtų atskirti tarp nerasta defekto ir nepateikto pranešimo.

Kitas, išbandykite MOT ir metinių testų kontrolę. HGV ir PSV metinių testų įrašai yra centriniai. Lengvosioms transporto priemonėms MOT datos taip pat gali būti tame pačiame flotės įraše. Programinė įranga turėtų sekti numatytas datas, užsakymo datas, rezultatus ir palaikančius dokumentus. Ji neturėtų laikyti praeities datos kaip vienintelio prasmingo įrašo. Operatoriai dažnai reikia užsakymo įrodymų, nesėkmių lapų, ištaisymo istorijos ir pakartotinio testo rezultato kaip visos atitikties vaizdo dalies.

Stabdžių testavimo įrašai taip pat yra svarbūs. Paklauskite, ar programinė įranga saugo apkrauto ir neapkrauto stabdžių testavimo įrodymus, susieja tuos rezultatus su susijusia saugos patikra ar priežiūros įvykiu ir leidžia greitai juos atgauti pagal transporto priemonę ar priekabą. Jei tiekėjas sako, kad stabdžių testavimas gali būti „pridėtas pastabose“, tai paprastai rodo, kad atitikties struktūra yra per laisva.

Priekabos yra dar viena vieta, kur silpnos sistemos pasirodo. Daugelis produktų tvarko varomas transporto priemones pakankamai gerai, tačiau priekabas traktuoja kaip antraeiles. Praktikoje priekabos įrašas turi savo patikros grafiką, defektų istoriją, stabdžių testavimo įrodymus, metinių testų istoriją, kur taikoma, padangų ir priežiūros pastabas, ir dokumentų saugojimą. Jei turite mišrias flotės, palyginkite, ar priekabos yra pirmos klasės įrašai sistemoje, ar tik priedai prie traktoriaus. Mes tai išsamiau aptariame mūsų straipsnyje apie priekabų patikros programinę įrangą DVSA įrašams.

Dokumentų saugojimas yra paskutinė šio testo dalis. Nepriklausomai nuo jūsų tikslios saugojimo politikos, sistema turėtų palengvinti patikros lapų, defektų ataskaitų, remonto įrodymų, stabdžių testų, metinių testų dokumentų ir susijusių įrašų laikymą kartu ir atgauti. Nepasiduokite sistemai, kurioje pagrindiniai įrodymai yra iš dalies programinėje įrangoje, iš dalies el. paštu ir iš dalies kažkieno stalčiuje.

Kur taisyklės skiriasi tarp JK ir ES apskritai, naudokite JK standartą, kuris taikomas jūsų operatoriaus licencijai ir vykdymo aplinkai. Tiekėjas, turintis plačią Europos aprėptį, nėra automatiškai neteisingas, tačiau vis tiek turi parodyti, kaip JK įrašų rinkinys yra tvarkomas praktikoje.

Ar ji gali laikyti transporto priemonių, priekabų ir vairuotojų atitiktį viename įraše

Transporto vadybininkas retai sprendžia kelių tinkamumą izoliuotai. Tikras darbas yra išlaikyti transporto priemonę, priekabą ir vairuotoją visus atitinkančius tuo pačiu metu, su įrodymais, kurie gali būti sekami iš vieno įrašo į kitą.

Tai reiškia, kad reikia palyginti, ar programinė įranga gali laikyti flotės, priekabų ir vairuotojų įsipareigojimus kartu, nesukeldama jums atskirų sistemų ir skaičiuoklių.

Transporto priemonėms ir priekaboms pagrindai yra patikros grafikai, priežiūros istorija, MOT arba metinių testų datos, stabdžių testavimas, defektai, remontai, VOR laikotarpiai ir palaikantys dokumentai. Bet jūs taip pat turite matyti, kaip šie įrašai susiję su vairuotojų puse.

Vairuotojams paklauskite, ar sistema seka licencijos detales, patikros datas, Driver CPC statusą, DQC galiojimo pabaigą, tachografo analizę, pažeidimus ir bet kokias sekimo veiklas, tokias kaip aptarimai ar mokymai. Turėtų būti galima matyti vairuotojo atitikties laikotarpį, o ne tik dabartinį statuso žymeklį.

Svarbus palyginimo taškas yra ryšys. Ar galite atidaryti vairuotojo įrašą ir pamatyti, kokias transporto priemones jie naudojo, kokius defektus jie pranešė, kokius tachografo išimtis buvo pateiktos ir kokie veiksmai buvo atlikti? Ar galite atidaryti transporto priemonės įrašą ir pamatyti, kurie vairuotojai pranešė apie pasikartojančias problemas arba vairavo ją per laikotarpį, kuris yra peržiūrimas? Tyrimo metu toks sujungtas vaizdas taupo laiką ir sumažina galimybę praleisti kontekstą.

Tai taip pat svarbu, kai yra keli operatoriai, depai ar licencijos subjektai. Jei jūsų verslo struktūra apima daugiau nei vieną operatorių, programinė įranga turėtų išlaikyti įrodymus, susijusius su teisingu operatoriumi, ir aiškiai parodyti tuos ribas. Įrašas, kurio negalima patikimai priskirti teisingam licencijos subjektui, yra prastas įrašas.

Įmonėms, naudojančioms prijungtas priemones, paklauskite, kaip duomenys juda viduje ir išorėje. Tinkamas REST API ir palaikymas webhooks gali būti svarbūs, jei norite sujungti atitikties įrašus su dirbtuvių sistemomis, BI įrankiais ar specializuotomis paslaugomis, tokiomis kaip Fleetalyse arba Logivo.AI. Integracija nėra tik patogumo klausimas. Tai veikia, ar žmonės perrašo duomenis, o perrašymas sukuria spragas ir klaidas.

Kiek stiprūs yra įrodymai, jei Kelių komisijos narys paklausia

Čia daugelis palyginimų tampa paprasti. Įsivaizduokite, kad gavote pranešimą apie tyrimą ir turite pateikti švarią bylą. Ar programinė įranga galėtų tai palaikyti be dienų rekonstrukcijos?

Pradėkite nuo parašų. Saugos patikros, defektų ištaisymo, vairuotojų deklaracijos ir peržiūros veiksmai turėtų būti pasirašyti arba kitaip aiškiai priskirti atsakingam asmeniui. Klausimas nėra, ar ekrane rodomas vardas. Klausimas yra, ar įrašas rodo, kas atliko veiksmą, kada jie tai atliko ir ar tas priskyrimas išlieka, jei įrašas vėliau redaguojamas.

Laiko žymės yra kitas. Turėtumėte matyti, kada defektas buvo praneštas, kada transporto priemonė buvo pašalinta iš kelio, jei reikia, kada remontas buvo baigtas ir kada transporto priemonė grįžo į eksploataciją. Tas pats taikoma praleistoms arba perkeliamoms patikroms. Jei numatyta data pasikeitė, sistema turėtų rodyti originalią datą, peržiūrėtą datą, kas ją pakeitė ir kodėl.

Keitimo istorija yra esminė. Atitikties byla yra stipresnė, kai ji rodo tiesą, įskaitant pataisas, nei kai ji atrodo dirbtinai tobula. Jei sistema leidžia tylų įrašų ištrynimą ar pakeitimą, tai silpnina jūsų poziciją. DVSA tyrimo ar viešo tyrimo metu nepaaiškinta tvarka gali būti tokia pat nepatogi kaip akivaizdus netvarkingumas.

Trūkstami veiksmai ir išimtys taip pat turėtų būti matomi. Paklauskite, ar programinė įranga praneša apie pavėluotas patikras, neperžiūrėtus defektus, neišspręstas tachografo problemas, pasibaigusį Driver CPC ar DQC, pavėluotus licencijos patikrinimus ir transporto priemones ar priekabas be būsimų užsakymų. Sistema, kuri rodo tik atliktą darbą, nerodo atitikties rizikos.

Išimčių ataskaitos turi būti praktiškos. Transporto vadybininkai turėtų galėti filtruoti pagal depą, operatorių, datų intervalą, transporto priemonės klasę, priekabų flotę, vairuotoją ir problemų tipą. Jei vienintelis būdas nustatyti spragas yra eksportuoti žalius duomenis ir sukurti savo skaičiuoklę, programinė įranga nedaro pakankamai.

Paskutinis testas yra išvestis. Ar galite pateikti nuoseklią bylą už vieną transporto priemonę, priekabą ar vairuotoją, su susijusiais įrodymais datų tvarka? Ar galite parodyti priežiūros planuotoją, atliktas patikras, defektus, remontus, stabdžių testus, metinių testų dokumentus, tachografo sekimą ir valdymo peržiūras? Tai yra standartas, su kuriuo reikia palyginti. Mes šį klausimą išsamiau aptariame mūsų straipsnyje apie kuri atitikties programinė įranga geriausiai palaiko jūsų Kelių komisijos nario bylą.

Ką svarbu kasdieniniame naudojime užimtiems transporto vadybininkams

Sistema gali būti visiškai funkcionali ir vis tiek nepavykti, jei ji yra nepatogi naudoti spaudimo metu. Praktikoje geriausia DVSA kelių tinkamumo atitikties programinė įranga yra ta, kuri išlaiko įrašus aktualius su mažiausiai trinties.

Terminų įspėjimai yra vienas iš pirmųjų dalykų, kuriuos reikia palyginti. Paklauskite, kiek iš anksto sistema įspėja apie patikras, MOT, metinius testus, Driver CPC, DQC, licencijos patikrinimus ir tachografo terminus. Įspėjimai turėtų būti konfigūruojami, matomi ir veikiami. Priminti, kuris atvyksta be kelio į pagrindinį įrašą, nėra didelės naudos.

Planavimas pagal ISO savaitę yra svarbus daugeliui flotų, nes dirbtuvių grafikai, patikros ciklai ir klientų paklausa dažnai seka savaitinius modelius. Jei jūsų operacija planuoja ISO savaitę, įsitikinkite, kad programinė įranga taip pat tai daro, o ne verčia viską į izoliuotas datos įrašus.

VOR tvarkymas yra dar viena praktinė detalė. Kai transporto priemonė ar priekaba yra ne kelyje, ar sistema gali greitai pažymėti ją VOR, parodyti priežastį, užkirsti kelią klaidingam paskyrimui ir užregistruoti grįžimo į eksploataciją sprendimą? Ar galite atskirti trumpą dirbtuvių laiką ir rimtą saugos susijusį VOR įvykį? Šios detalės vėliau yra svarbios.

Dirbtuvių komunikacija turėtų būti paprasta. Jei priežiūra yra viduje, ar montuotojai ir priežiūros darbuotojai gali atnaujinti darbus, nesukurdami dvigubos administracijos transporto biurui? Jei priežiūra yra išorėje, ar rangovai gali siųsti dokumentus ir užbaigimo įrodymus tiesiai į įrašą? El. pašto grandinės ir rankiniai įkėlimai dažnai tampa silpna vieta gerose sistemose.

Mobilus defektų fiksavimas dabar yra pagrindinis, tačiau kokybė vis dar skiriasi. Palyginkite, ar vairuotojai gali aiškiai pateikti defektus iš telefono, pridėti nuotraukas, identifikuoti tinkamą turtą ir patvirtinti nulinį defektą, kur to reikalaujama. Tada paklauskite, kas vyksta toliau. Ar ataskaita sukelia peržiūros eilę, remonto užduotį ar VOR sprendimą, ar ji tiesiog nusileidžia kaip žinutė, kurią kažkas pastebės vėliau?

Vartotojų leidimai yra svarbesni nei daugelis pirkėjų tikisi. Galbūt norėsite, kad vairuotojai praneštų apie defektus, tačiau ne redaguotų istoriją, dirbtuvės darbuotojai užbaigtų remontus, tačiau nekeitė atitikties grafikų, o vadybininkai peržiūrėtų išimtis per konkrečius depus ar operatorius. Detalizuoti leidimai padeda išlaikyti įrašus patikimus.

Savininkai-vairuotojai ir mažos flotės turėtų patikrinti paprastumą. Daugelis sistemų yra sukurtos didesnėms flotėms ir tampa nepatogios, kai vienas asmuo daro viską. Jei esate savininkas-vairuotojas arba valdote mažą operaciją, tinkama programinė įranga turėtų vis tiek palengvinti įrašų atnaujinimą, įkelti įrodymus iš telefono ir matyti, kas yra numatyta toliau, nesukeliant įmonės lygio sudėtingumo.

Norėdami išsamiau pažvelgti į terminų kontrolę ir praktinius priminimus, žiūrėkite mūsų straipsnį apie O-licencijos terminų programinę įrangą, kuri atlaiko DVSA.

Klausimai, kuriuos turėtumėte užduoti tiekėjams prieš įsipareigodami

Geras demonstravimas turėtų atsakyti į operacinius klausimus, o ne tik pristatyti funkcijas. Naudokite kontrolinį sąrašą ir paprašykite tiekėjų parodyti atsakymą sistemoje.

Pirmiausia paklauskite apie įgyvendinimą. Kas nustato transporto priemones, priekabas, vairuotojus ir grafikus? Kaip importuojami esami įrašai? Kas nutinka su istorinėmis patikromis, metinių testų dokumentais, defektų žurnalais ir tachografo istorija? Migracija dažnai yra ta vieta, kur projektai pavyksta arba žlunga.

Paklauskite, kokia parama yra įtraukta. Ar gaunate įvadą iš žmonių, kurie supranta JK operatorių atitiktį, ar tik bendrą programinės įrangos palaikymą? Jei jums reikia pagalbos ruošiantis DVSA priežiūros tyrimui, ar tiekėjas gali paaiškinti, kaip išgauti teisingus įrašus?

Paklauskite, kaip veikia ataskaitos. Ar galite kurti savo ataskaitas? Ar galite eksportuoti žalius duomenis, kai reikia? Ar galite gaminti mėnesinius valdymo paketus pagal operatorių, depą ar flotės tipą? Ar galite įrodyti tiek atliktą atitiktį, tiek praleistą atitiktį?

Paklauskite apie integracijas. Ar yra REST API? Ar yra prieinami webhooks? Ar yra esamų integracijų su Fleetalyse ar Logivo.AI? Ar platforma gali prisijungti prie tachografo analizės įrankių, dirbtuvių sistemų, licencijos tikrinimo paslaugų ar draudimo ir transporto priemonių duomenų šaltinių, tokių kaip askMID per Motor Insurers' Bureau, arba MIB, kai tai tinkama? Jei ne, kas liktų rankiniu būdu?

Paklauskite konkrečiai apie DVLA susijusius procesus. Jei tiekėjas mini licencijos patikrinimus, paklauskite, ar programinė įranga juos atlieka tiesiogiai, importuoja rezultatus iš partnerio, ar tiesiog saugo rezultatą. Yra didelis skirtumas tarp numatytos datos sekimo ir paties patikrinimo automatizavimo.

Paklauskite, ką tiekėjas automatizuoja. Tai yra vienas geriausių pirkimo klausimų, nes jis priverčia aiškiai atsakyti. Nėra sistemos, kuri automatizuoja kiekvieną sprendimą. Kažkas vis tiek turi peržiūrėti išimtis, įvertinti defektus, patvirtinti VOR grąžinimus, iššūkius praleistoms patikroms ir valdyti rangovų našumą. Patikimas tiekėjas pasakys jums tiksliai, kur žmogaus kontrolė vis dar yra būtina.

Taip pat paklauskite, ar galite pamatyti nepatogius atvejus. Praleista saugos patikra. Priekaba be būsimų užsakymų. Vairuotojas su pasibaigusiu DQC. Defektas, praneštas ne darbo valandomis. Transporto priemonė, kuri nepraeina metinio testo ir reikalauja pakartotinio testo įrodymų. Tai yra akimirkos, kurios atskleidžia, ar sistema yra sukurta atitikties realybei.

Kai palyginate tiekėjus šiuo būdu, trumpas sąrašas paprastai greitai tampa aiškus. Stipriausia sistema yra ta, kuri praktiniais terminais laikosi DVSA Gido dėl kelių tinkamumo palaikymo, išlaiko transporto priemonių, priekabų ir vairuotojų įrodymus kartu ir suteikia jums įrašus, kuriuos norėtumėte pateikti DVSA ar Kelių komisijos nariui be rekonstrukcijos.

Tai yra standartas, kurį laikomės OperatorCompliance, sukurtas Fleeta Limited kaip komanda, kuri pati veikia pagal operatoriaus licenciją. Jei pr