Pasirinkite DVSA defektų registravimo programinę įrangą, kuri atlaiko

Jei renkatės programinę įrangą DVSA inspekcijos įrašams ir defektams, testas yra paprastas. Ar ji gali padėti mums tinkamai valdyti parką kasdien, ir ar ji gali pateikti aiškų, pasirašytą, laiko žymėtą įrašą, kai DVSA arba Transporto komisaras (Traffic Commissioner) prašo įrodymų? Jei atsakymas į bet kurį klausimą yra ne, tai nėra tinkama sistema, nesvarbu, kaip tvarkingai atrodo valdymo skydelis.

Transporto vadybininkams nereikia dar vienos programėlės, kuri renka formas ir palieka sunkų darbą skaičiuoklėms, el. pašto grandinėms ir depų atminčiai. Mums reikia vienos vietos, kad galėtume kontroliuoti inspekcijos intervalus, defektų registravimą, taisymą, sprendimus dėl transporto priemonių išėmimo iš eismo, dokumentų galiojimo laiką ir auditą, kuris juos palaiko. Tai yra standartas, kurį kuriame Operator Compliance, nes Fleeta Limited veikia pagal operatoriaus licenciją ir žino, ką turi atlaikyti tikras atitikties failas.

Ką transporto vadybininkai turi gauti iš defektų ir inspekcijos programinės įrangos

Minimali sistema turėtų laikyti įrašus, kurie palaiko kelių tinkamumo valdymą pagal DVSA Gidą dėl kelių tinkamumo palaikymo. Tai reiškia suplanuotas saugos inspekcijas, vairuotojų defektų ataskaitas, taisymo įrašus, MOT arba metinių testų datas, padangų ir stabdžių įrodymus, kur tai aktualu, ir istoriją, kuri susieja kiekvieną įvykį su konkrečia transporto priemone ar priekaba.

Daugumai operatorių pagrindinis darbo procesas atrodo taip:

1. Nustatyti inspekcijos grafiką kiekvienai transporto priemonei ir priekabai.
2. Užregistruoti atliktą saugos inspekciją, su data, rida arba kilometrais, išvadomis ir patvirtinimu.
3. Fiksuoti kasdienius arba pamaininius vairuotojų apžvalgos defektus.
4. Pasirinkti, ar kiekvienas defektas yra nedidelis, kritinis saugai, ar reikalauja, kad turtas būtų pažymėtas VOR.
5. Užregistruoti taisymo darbus, kas juos atliko, kada jie buvo atlikti, ir ar turtas grįžo į eksploataciją.
6. Laikyti dokumentus ir parašus kartu, kad įrašas galėtų būti pateiktas vėliau be rekonstrukcijos.

Tai skamba paprastai, tačiau daugelis sistemų nepavyksta dėl detalių. PDF saugykla nėra tas pats, kas inspekcijos įrašų sistema. Vairuotojo programėlė, leidžianti pažymėti „nėra defektų“, nėra pakankama, jei nėra darbo proceso remontui, peržiūrai ir užbaigimui. Dirbtuvės dienoraštis nėra pakankamas, jei transporto biuras negali įrodyti, kad inspekcija buvo suplanuota tinkamu intervalu ir atlikta laiku.

Tinkamas audito takas yra svarbus, nes DVSA patikros nesibaigia tuo, ar įrašas egzistuoja. Jie žiūri, ar įrašas yra patikimas. Ar galime parodyti, kada inspekcija buvo numatyta, kada ji buvo atlikta, kas ją pasirašė, kokie defektai buvo rasti, kokių veiksmų buvo imtasi ir ar praleisti įvykiai buvo identifikuoti ir išspręsti? Jei transporto priemonė turėjo pakartotinių padangų defektų ar apšvietimo problemų, ar galime matyti šią tendenciją? Jei priekaba keitė depus, ar vis dar galime matyti visą istoriją, nesikreipdami į tris žmones, kad ieškotume senose aplankaluose?

JK operatoriams sistema taip pat turi atspindėti operatoriaus licencijos realybę, o ne bendrą parkų administravimą. Saugos inspekcijos intervalas gali būti nustatytas pagal savaites, ridą, transporto priemonės amžių, eksploatavimo sąlygas arba dokumentuotą priežiūros planą. Kai kurie parkai nori grafikų pagal kalendoriaus datas, kiti pagal ISO savaitę, ypač kai inspekcijos yra suplanuotos atsižvelgiant į dirbtuvių pajėgumus ir transporto biuro rutiną. Programinė įranga turėtų palaikyti metodą, kurį iš tikrųjų naudojame, ir išlaikyti jo pagrindimą.

Įrašai taip pat turėtų atskirti kelių tinkamumo inspekcijas ir kitą priežiūros veiklą. Paslauga automatiškai nėra saugos inspekcija. PMI lapas, nuskenuotas į aplanką, yra naudingas tik tuo atveju, jei jis yra susietas su teisingu turtu, data ir pasirašiusiu asmeniu, ir jei praleisti ar vėluojantys įvykiai išlieka matomi, o ne paslėpti vėlesniu įkėlimu.

Štai kodėl mes teikiame pirmenybę sistemoms, sukurtoms aplink operatoriaus licencijos darbą. OperatorCompliance įrašų struktūra prasideda nuo transporto priemonių, priekabų ir vairuotojų, o tada aplink juos kuriami atitikties įvykiai. Tai nėra bendras užduočių valdytojas, turintis transporto etiketę.

Kokios funkcijos iš tikrųjų mažina atitikties riziką?

Funkcijos, kurios mažina riziką, retai būna blizgios. Tai yra kontrolės, kurios neleidžia praleisti darbo, daro išimtis matomas ir priverčia užbaigimo procesą.

Pirmiausia, suplanuotos inspekcijos turi būti patikimos. Turėtume galėti nustatyti inspekcijos dažnumą kiekvienai transporto priemonei ir priekabai, matyti kitą numatytą datą ir iš karto pastebėti vėluojančius elementus. Sistema turėtų susidoroti su skirtingų parkų tipais, įskaitant HGV, furgonus, PSV ir mišrią veiklą. Taip pat turėtų būti aišku, ar kita inspekcijos data buvo apskaičiuota pagal suplanuotą datą, ar pagal faktinę užbaigimo datą, nes tai veikia intervalo kontrolę.

Antra, defektų patvirtinimas turi turėti struktūrą. Defektų ataskaita neturėtų dingti, kai ji pateikiama. Ji turėtų judėti per apibrėžtą procesą, būti atvira, įvertinta, priskirta, suremontuota, patikrinta, uždaryta, su vardais, datomis ir laikais. Jei defektas išvedė transporto priemonę iš eismo, VOR statusas turėtų būti matomas biurui, dirbtuvėms ir planuotojui. Jei vairuotojas pranešė, kad defektų nėra, tas nulinis pranešimas vis tiek turėtų būti užregistruotas, nes įrodymų nebuvimas yra problema audito metu.

Trečia, dokumentų saugojimas turi būti integruotas į atitikties darbo procesą. Naudinga saugoti inspekcijos lapus, stabdžių testų ataskaitas, MOT arba metinių testų sertifikatus, nuotraukas, sąskaitas faktūras ir meistrų pastabas, tačiau tik jei jie yra susieti su teisingu įvykiu. Didelis PDF failų kabinetas nepadeda, kai reikia parodyti taisymo įrodymus dėl konkretaus defekto, kuris buvo pateiktas prieš tris mėnesius konkrečiai priekabai.

Ketvirta, pranešimai turi būti operatyvūs, o ne triukšmingi. Mums reikia priminimų apie artėjančias inspekcijas, MOT, metinius testus, Driver CPC ir DQC galiojimo laiką, licencijų patikras, draudimo datas ir tachografo terminus, jei tai yra taikoma. Tačiau sistema taip pat turėtų pranešti apie išimtis, kurios sukelia tikrą riziką, vėluojančias inspekcijas, atviras saugos defektus, pakartotinius defektus tame pačiame turte, trūkstamą patvirtinimą ir dokumentus, kurie buvo tikėtini, bet neįkelti.

Penkta, ataskaitos turėtų padėti mums anksti įsikišti. Naudingos ataskaitos apima vėluojančias inspekcijas, defektus pagal turtą, defektus pagal kategoriją, atviras VOR prekes, praleistus inspekcijos įvykius, priekabų inspekcijos būseną ir vairuotojų pranešimų atitiktį. Tendencijų ataskaita dažnai yra vertingesnė už ilgą sąrašą, nes ji rodo, ar depas, rangovas ar transporto priemonių tipas išslysta iš kontrolės.

Štai kur daugelis pirkėjų turėtų būti skeptiški. Tiekėjas gali parodyti blizgančią defektų programėlę, tačiau jei ataskaita negali atskirti atvirų nuo uždarų defektų, ar negali eksportuoti visos inspekcijos istorijos, atitikties rizika lieka su mumis. Tas pats taikoma sistemai, kuri saugo parašus, bet negali įrodyti, kada jie buvo užfiksuoti.

Jei norite išsamiau pažvelgti į tai, kas svarbu kasdieniniame defektų valdyme, mūsų gidas apie defektų ir priežiūros įrašus, kurie atlaiko DVSA apima praktinius patikrinimus, kuriuos siūlome prieš perkant.

Kaip sistema turėtų tvarkyti transporto priemones, priekabas ir vairuotojus?

Sistema turėtų laikyti transporto priemones, priekabas ir vairuotojus kaip atskirus atitikties subjektus su susijusiomis istorijomis. Tai skamba akivaizdžiai, tačiau čia mišrūs parkai dažnai susiduria su problemomis.

Transporto priemonės turi turėti savo inspekcijos grafiką, MOT arba metinių testų datas, mokesčių ir draudimo detales, kur tai stebima, ir išsamų defektų ir priežiūros istoriją. HGV ir PSV atveju paprastai taip pat norime aiškių nuorodų į stabdžių testų įrodymus, saugos inspekcijos įrašus ir bet kokias pasikartojančias kelių tinkamumo problemas. Lengvesnių režimų furgonams taikoma ta pati taisyklė, net jei įrašų rinkinys yra paprastesnis.

Priekaboms reikia lygiavertės priežiūros. Per daug sistemų vis dar traktuoja priekabas kaip antrarūšius turtus, kas sukelia spragų inspekcijos planavime ir defektų istorijoje. Priekaba gali sukelti savo kelių tinkamumo riziką ir savo DVSA klausimus, ypač jei ji juda tarp vienetų, depų ar subrangovų. Programinė įranga turėtų leisti mums priskirti inspekcijos intervalus, registruoti priekabų defektus, pažymėti priekabų VOR statusą ir pateikti visą priekabos istoriją, nesiremiant su traktoriaus vienetu, su kuriuo ji buvo poruojama tą dieną.

Vairuotojams reikia daugiau nei vardo ir telefono numerio. Mums reikia licencijos detalių, patikros datų, kategorijų, patvirtinimų, kur tai užfiksuota, Driver CPC statuso, DQC galiojimo laikotarpio ir įrodymų apie patikras, atliktas pagal DVLA duomenis arba įkeltus įrašus. Jei naudojami agentūros vairuotojai, sistema vis tiek turėtų turėti struktūrizuotą įrašą apie tai, kas, kada ir kieno įgaliojimu patikrino.

Vairuotojų apžvalgos ataskaita yra svarbus testavimo taškas. Programėlė ar forma turi būti pakankamai paprasta, kad vairuotojai galėtų ją tinkamai užpildyti, tačiau pakankamai kontroliuojama, kad sukurtų naudingus įrodymus. Mes ieškotume:

• Nuliniai defektų pranešimai, taip pat defektų pranešimai
• Data ir laiko žymės
• Transporto priemonės ir priekabos pasirinkimas
• Defektų kategorijos su laisvu tekstu ir nuotraukomis
• Vairuotojo deklaracija arba parašas
• Eskaluoti kritinius saugai defektus
• Biuro peržiūra ir užbaigimas
• Aiškus įrašas, jei tas pats defektas yra perkeliamas laukdamas dalių ar dirbtuvės vietos

Autobusų ir mikroautobusų operatoriams, taip pat taksi ir privačių nuomos įmonėms gali būti vietos valdžios ar vidaus politikos reikalavimų, kurie yra šalia DVSA lūkesčių. Sistema turėtų būti pakankamai lanksti, kad galėtų laikyti tuos patikrinimus, tačiau ne aukojant pagrindinių operatoriaus licencijos kontrolės.

Kur JK taisyklės skiriasi nuo platesnės ES praktikos, turėtume atsižvelgti į JK įrodymų standartą. Operatorius licencijos failas, DVSA kelio ir patalpų patikros, ir bet koks kvietimas į viešąjį tyrimą, kurį inicijuoja Transporto komisaras, yra vertinami pagal JK reikalavimus ir įrašus, kuriuos galime pateikti čia. Funkcijos, kurios turi prasmės platesniame Europos parko pakete, nėra labai naudingos, jei jos nesutampa su DVLA patikromis, Driver CPC įrodymais ir priežiūros įrašais, kurie tikimasi Didžiojoje Britanijoje.

Jei priekabos yra didelė jūsų veiklos dalis, mūsų straipsnis apie priekabų inspekcijos programinę įrangą DVSA įrašams išdėsto punktus, kuriuos sakome operatoriams patikrinti prieš įsipareigojant.

Kokie įrodymai jums reikės, jei DVSA arba Transporto komisaras paklaus?

Kai DVSA atvyksta, arba kai Transporto komisaras nori įrašų, problema retai būna ta, kad darbas nebuvo atliktas. Problema yra ta, kad įrodymai yra neišsamūs, išsklaidyti arba neįmanoma greitai pateikti.

Sistema turėtų leisti mums pateikti švarų paketą bet kuriai transporto priemonei, priekabai ar vairuotojui. Tai paprastai reiškia:

• Pasirašyti saugos inspekcijos įrašai
• Inspekcijos planuotojas, rodantis numatytas ir atliktas datas
• Visą defektų istoriją, įskaitant nulinės ataskaitas, jei naudojamos
• Taisymo įrodymai, su datomis, dalimis, meistrų pastabomis, sąskaitomis faktūromis ar darbo lapais, jei yra
• Praleistų ar vėluojančių inspekcijų įrašai
• Peržiūros ir korektyvių veiksmų įrodymai po bet kurio praleisto įvykio
• MOT arba metinių testų istorija
• Vairuotojo licencija ir Driver CPC įrodymai, jei tai aktualu
• Eksportuojamos ataskaitos už apibrėžtą laikotarpį

Pasirašyti įrašai yra svarbūs. Rašytas vardas pastabų lauke nėra tas pats, kas struktūrizuotas parašas ar deklaracija, susieta su įvykiu. Laiko žymės taip pat yra svarbios. Jei vairuotojas pateikė defektą 05:40, o transporto priemonė išvyko iš vietos 06:00, turime parodyti, koks sprendimas buvo priimtas ir kieno. Jei saugos inspekcija buvo atlikta vėlai, turime parodyti, kad tai pripažinome, įvertinome riziką ir ištaisėme grafiką.

Praleisti įvykiai neturėtų būti paslėpti. Sistema, kuri tyliai perrašo numatytą datą arba rodo tik naujausią atliktą inspekciją, gali priversti mus atrodyti blogiau, o ne geriau, nes tai rodo, kad audito takas buvo išlygintas. Geresnė programinė įranga išlaiko išimtį ir leidžia mums pažymėti priežastį ir korektyvią veiklą.

Eksportas yra dar vienas praktinis testas. Jei vienintelis būdas atsakyti į užklausą yra daryti ekrano nuotraukas, sistema nėra paruošta. Turėtume galėti eksportuoti inspekcijos istorijas, defektų žurnalus ir dokumentų paketus formatu, kurį kitas asmuo gali peržiūrėti be mūsų prisijungimo ar paaiškinimo.

Čia taip pat pasireiškia duomenų kokybė. Transporto priemonių registracijos numeriai, parkų numeriai, priekabų ID ir vairuotojų vardai turėtų būti pakankamai nuoseklūs, kad tas pats turtas neatsirastų po keliais variantais. Jei jūsų dabartiniai įrašai yra netvarkingi, paklauskite, kaip tiekėjas padeda juos išvalyti ir perkelti.

Operatoriams, kurie kuria mėnesinius peržiūros paketus, taip pat siūlome pažvelgti, ar programinė įranga gali palaikyti įprastus valdymo įrodymus, o ne tik krizės atgaminimą. Mūsų straipsnis apie mėnesinį parko paketą, kuris atlaiko DVSA paaiškina, kas, mūsų nuomone, turėtų būti matoma prieš egzaminuotojui prašant.

Kaip palyginti tiekėjus, neperkant netinkamos sistemos

Pradėkite nuo veiklos modelio, o ne demonstracijos. Paprašykite tiekėjo parodyti, kaip tiksliai transporto priemonė yra nustatyta, kaip priskiriamas inspekcijos intervalas, kaip vairuotojas praneša apie defektą, kaip registruojamas taisymas ir kaip eksportuojama visa istorija. Jei jie lieka valdymo skydelio lygyje, stumkite gilyn.

Praktinis palyginimo rėmas turėtų apimti penkias sritis.

Pirmiausia, nustatymas. Ar sistema gali importuoti transporto priemones, priekabas ir vairuotojus dideliais kiekiais? Ar ji gali tvarkyti mišrius parkus? Ar ji gali nustatyti skirtingus inspekcijos intervalus pagal turto tipą ar veiklos modelį? Ar ji gali saugoti MOT, metinių testų, draudimo ir licencijų susijusius terminus vienoje vietoje? Jei dirbate pagal ISO savaitę, ar ji gali tai palaikyti be apėjimų?

Antra, palaikymas. Kas padeda diegti, struktūrizuoti įrašus ir įdiegti darbuotojus? Ar palaikymas yra JK ir susipažinęs su operatoriaus licencijos atitiktimi, ar tai yra bendras programinės įrangos palaikymas? Paklauskite, kas supranta DVSA priežiūros failą, o ne tik kas gali atstatyti slaptažodį.

Trečia, duomenų migracija. Dauguma operatorių jau turi įrašus skaičiuoklėse, bendrose diskuose, dirbtuvių sistemose ar senesnėse parko produktuose. Paklauskite, kas gali būti importuota, kas reikalauja rankinio valymo ir kaip istorinės inspekcijos ir defektai atrodys po migracijos. Jei tiekėjas sako, kad migracija yra lengva, paprašykite pamatyti pavyzdį su istoriniais duomenimis, susietais su transporto priemonėmis ir priekabomis teisingai.

Ketvirta, integracija. Jei jau naudojate dirbtuvių programinę įrangą, HR sistemas, telematikos ar tachografo įrankius, paklauskite, ar tiekėjas siūlo REST API arba webhooks. Tai nėra madingi žodžiai, jei jums tikrai reikia, kad sistemos keistųsi įvykiais ar dokumentais. Tai svarbu, jei norite, kad defektų statusas patektų į planavimą, arba jei norite, kad vairuotojų įrašai būtų atnaujinti iš kito šaltinio. Tačiau jei tiekėjas reklamuoja integraciją ir negali paaiškinti įvykių struktūros, autentifikavimo ar galimų galinių taškų, elkitės atsargiai.

Penkta, produkto tinkamumas. Ar programinė įranga sukurta aplink operatoriaus licencijos darbą, ar transporto atitiktis buvo pridėta prie platesnės parko platformos? Užduokite tiesioginius klausimus apie DVSA inspekcijas, defektų uždarymą, priekabų įrašus, Driver CPC, DQC ir įrodymų paketus Transporto komisarui. Tiekėjas, kuris kalba tik apie parko efektyvumą, gali būti ne tas, kurio norite, kai problema yra teisinė atitiktis.

Taip pat verta patikrinti, ar sistema labai priklauso nuo trečiųjų šalių duomenų šaltinių pagrindiniams įrašams. Pavyzdžiui, kai kurie operatoriai klausia apie askMID, Motor Insurers' Bureau ir MIB duomenis draudimo patikroms. Šios paslaugos gali būti naudingos kontekste, tačiau jos nepakeičia mūsų pačių pareigos laikyti tikslius operatoriaus įrašus. Tas pats taikoma licencijų duomenims ir dirbtuvių įrodymams. Išoriniai šaltiniai gali palaikyti failą, o ne pakeisti jį.

Galiausiai, palyginkite produktą su darbu, kurį jūsų biuras iš tikrųjų atlieka kiekvieną savaitę. Ar jis gali pakeisti baltą lentą, bendrą skaičiuoklę, nuskenuotų PMI aplanką ir el. pašto dėžutę, pilną defektų nuotraukų? Ar jis gali parodyti, kas yra numatyta, kas yra vėluojama dabar ir kokie įrodymai yra pilni? Tai geresnis pirkimo testas nei ilgas funkcijų sąrašas.

Rinkoje yra daug pavadinimų, įskaitant Fleetalyse ir Logivo.AI, o kai kurie operatoriai jau gali turėti platesnes sistemas, įdiegtas per kitus tiekėjus. Teisingas sprendimas yra tas, kuris suteikia mums patikimą kelių tinkamumo įrašą, o ne tas, kuris turi plačiausią brošiūrą.

Jei lyginate pasirinkimus šalia, mūsų gidas apie kaip palyginti kelių tinkamumo programinę įrangą DVSA įrodymams yra geras kitas žingsnis.

Saugesnis pasirinkimas yra programinė įranga, kuri padeda mums tinkamai valdyti parką, kol niekas neužduoda klausimų, o tada aiškiai įrodo, kai jie tai daro. Tai reiškia, kad įrašai yra pilni, inspekcijos grafikai yra kontroliuojami, defektai yra tinkamai uždaryti, o įrodymai gali būti eksportuojami be skubėjimo. Mūsų nuomone, programinė įranga DVSA inspekcijos įrašams ir defektams turėtų tai daryti, nes atitikties darbas yra toks stiprus, kaip įrašas, kurį galime pateikti ant stalo.