Vairuotojų defektų programėlės su pasirašyta įrodymų palyginimu

Vairuotojų defektų programėlė yra vertinga tik tuo atveju, jei ji suteikia įrodymų, kuriais galima pasikliauti, kai transporto priemonė sustabdyta pakelėje, kviečiama į viešą tyrimą arba peržiūrima po susidūrimo. JK operatoriui tai reiškia daugiau nei skaitmeninis patikrinimo lapas. Tai reiškia, kad reikia įrodyti, jog tinkamas vairuotojas patikrino tinkamą transporto priemonę ar priekabą, tinkamu laiku, užfiksavo defektus arba nulinio defekto rezultatą ir kad verslas reagavo į tai, kas buvo rasta.

Štai kodėl tikras palyginimas nėra popierius prieš programėlę. Tai yra tai, ar sistema sukuria gynybinį atitikties įrašą. Gerai pasirašyta defektų pranešimo programėlė vairuotojams turėtų palaikyti kasdienius apžvalgos patikrinimus, defektų eskalavimą, remonto kontrolę ir auditų atkūrimą, nepaliekant spragų, kurias nedelsiant pastebėtų DVSA inspektorius ar Transporto komisaras.

Ką turi įrodyti pasirašytas defektų pranešimas JK flotilėje

JK flotilėje kasdieniai defektų pranešimai yra platesnių kelių tinkamumo pareigų dalis. Operatorius turi sugebėti parodyti, kad transporto priemonės ir priekabos yra tikrinamos, defektai pranešami laiku, saugos defektai tinkamai sprendžiami ir įrašai laikomi forma, kuri gali būti pateikta, kai to prašoma. Tikslus nustatymas skiriasi tarp HGV, PSV, furgonų ir mišrių flotilių, tačiau įrodymų standartas yra tas pats. Jei tai nėra aiškiai užfiksuota, sunku įrodyti, kad tai įvyko.

Pasirašyta defektų pranešimo programėlė turi įrodyti kelis dalykus.

Pirmiausia, vairuotojo tapatybė. Jūs turite žinoti, kas atliko apžvalgos patikrinimą. Tai svarbu dirbantiems vairuotojams, savininkams-vairuotojams, pagalbiniams vairuotojams ir agentūrų darbuotojams. Įrašytas vardas laisvoje teksto dėžutėje yra silpnas įrodymas. Tinkamas vartotojo prisijungimas, susietas su vardiniu vairuotojo profiliu, yra stipresnis. Jei programėlė fiksuoja parašą ar deklaraciją patikrinimo pabaigoje, ji turėtų būti susieta su tuo vartotojo įrašu ir išsaugota audito pėdsake.

Antra, transporto priemonės ir priekabos tapatybė. Ataskaita turi parodyti, kuris registracijos numeris buvo tikrinamas ir, jei tai aktualu, kuris priekabos numeris buvo prijungtas. Praktikoje transporto vadybininkai turi pasitikėti, kad programėlė neleidžia arba bent jau pažymi neteisingą turtą pasirinkti. Jei naudojate traktorių ir priekabų derinius, priekabos įrašas yra toks pat svarbus kaip ir vieneto įrašas.

Trečia, laikas. Ataskaita turėtų rodyti pateikimo datą ir laiką, o idealiai - kada patikrinimas prasidėjo ir baigėsi. Laiko įrodymai yra svarbūs, kai reikia parodyti, kad patikrinimas buvo baigtas prieš pirmą naudojimą tą dieną arba prieš tai, kai vairuotojas paėmė kitą transporto priemonę darbo metu. Jei sistema veikia neprisijungus, ji turėtų aiškiai nurodyti, kas buvo užfiksuota įrenginyje tuo metu ir kas buvo sinchronizuota vėliau.

Ketvirta, rezultatas. Įrašas turi aiškiai atskirti nulinio defekto pranešimą ir defektų pranešimą. Nuliniai defektai dažnai būna pamiršti silpnose sistemose, tačiau jie yra svarbūs. Jei nėra įrašo dieną, kai transporto priemonė buvo naudojama, gali būti sunku parodyti, ar defektai nebuvo rasti, ar patikrinimas nebuvo atliktas. Nulinio defekto deklaracija su parašu ar lygiaverte vairuotojo patvirtinimu uždaro tą spragą.

Penkta, defekto detalė. Naudingas įrašas turėtų identifikuoti tikrinamą elementą, defekto pobūdį, bet kokią rimtumo ar tinkamumo klasifikaciją, naudojamą viduje, vairuotojo komentarus ir palaikančias nuotraukas, jei tai aktualu. Akivaizdžiam kėbulo pažeidimui, padangų problemoms, žibintų gedimams, krovinio saugumo problemoms ar priekinio stiklo pažeidimams nuotraukos gali būti labai naudingos.

Šešta, operatoriaus veiksmai. Defektų pranešimas pats savaime nėra pakankamas. Jūs turite parodyti peržiūrą, sprendimą ir taisymą. Ar transporto priemonė buvo paskirta VOR? Ar defektas buvo įvertintas kaip saugos kritinis, tik stebėti, ar taisyti kitame patikrinime? Kas priėmė tą sprendimą ir kada? Jei defektas buvo ištaisyta, koks darbas buvo atliktas, kas tai padarė ir kada transporto priemonė buvo vėl paleista į eksploataciją?

Štai kur daugelis programėlių palyginimų praleidžia. Transporto komisaras nebus suinteresuotas formos elegancija, jei sistema negali parodyti grandinės nuo vairuotojo pranešimo iki valdymo veiksmo. Pasirašytas pranešimas yra viena dalis įrodymų bylos, o ne visa byla.

Operatoriams, kurie nori aiškesnio vaizdo, kaip atitinkantis procesas turėtų atrodyti praktikoje, kasdienių apžvalgos patikrinimų ir defektų pranešimo procedūrų gairės yra naudingas standartas.

Kaip palyginti programėles, nepraleidžiant atitikties pagrindų

Kai lyginate defektų programėles, pradėkite nuo atitikties pagrindų, prieš žiūrėdami į informacijos suvestinės dizainą ar prekės ženklą. Žemiau pateikti klausimai paprastai atskleidžia, ar sistema yra pakankamai tvirta operatorių licencijos aplinkai.

Vairuotojų parašai ir deklaracijos

Klauskite, kaip vairuotojas patvirtina pranešimą. Ar yra parašo langelis, deklaracijos žymėjimas, ar abu? Ar patvirtinimas susietas su vartotojo paskyra, su nepakitimu laiko žyma? Ar vadybininkas gali pakeisti pradinį pranešimą po pateikimo, ir jei taip, ar pokytis užfiksuotas? Gerai pasirašyta defektų pranešimo programėlė vairuotojams turėtų išlaikyti pradinį pateikimą ir parodyti bet kokius vėlesnius redagavimus atskirai.

Laiko žymės ir laiko šaltinis

Patikrinkite, kokios laiko žymės yra saugomos. Pateikimo laikas yra minimalus. Geresnės sistemos taip pat fiksuoja pranešimo sukūrimo laiką, redagavimo laiką, peržiūros laiką ir patvirtinimo laiką. Klauskite, ar programėlė fiksuoja laiką JK vietos laiku ir kaip ji tvarko Britų vasaros laiką. Jei vairuotojai dirba srityse su prastu signalu, klauskite, kas vyksta neprisijungus ir kaip vėluojantis sinchronizavimas yra rodomas.

Transporto priemonių ir priekabų paskirstymas

Programėlė turėtų palengvinti vairuotojui pasirinkti teisingą transporto priemonę ir priekabą, tačiau sunkiai pasirinkti neteisingą atsitiktinai. Klauskite, ar paskirstymai gali būti iš anksto priskirti iš transporto biuro, ar vairuotojai gali ieškoti pagal registraciją, ir ar priekabos gali būti prijungtos prie pranešimo atskirai. Dėl bendrų flotilių, bendrų transporto priemonių ir agentūrų aprėpties, tai yra svarbu kiekvieną dieną.

Nuotraukų įrodymai

Nuotraukos yra naudingos, tačiau tik jei jos tinkamai prijungtos prie pranešimo ir lengvai atkuriamos vėliau. Klauskite, ar vaizdai yra su laiko žymomis, ar galima pridėti kelias nuotraukas prie vieno defekto, ar jos yra suspaustos, ir ar išlaikoma originali vaizdo metaduomenų informacija. Taip pat patikrinkite, ar vairuotojai gali pridėti nuotraukas prie nulinio defekto pranešimų, jei jie nori parodyti ginčijamą būklę, pavyzdžiui, išankstinį pažeidimą.

Taisymo įrašai

Atitikties lygio sistema turėtų leisti defektams pereiti į remonto darbo eigą. Tai reiškia, kad reikia priskirti problemą, užfiksuoti dirbtuvės pastabas, naudojamas dalis, jei tai aktualu, remonto datą ir asmenį, patvirtinusį grąžinimą į eksploataciją. Jei programėlė baigiasi vairuotojo pateikimu ir perkelia likusius į el. paštą ar popierių, audito pėdsakas jau yra padalintas.

Audito pėdsakas ir išsaugojimas

Klauskite, ar galite pamatyti visą audito pėdsaką vienam pavyzdiniam defektui. Jūs turėtumėte galėti sekti jį nuo pradinio pateikimo iki uždarymo. Ieškokite vartotojų vardų, datų ir laikų, statuso pokyčių ir pastabų. Tada klauskite apie išsaugojimą. Ar įrašai gali būti laikomi pagal jūsų politiką ir atitikties poreikius? Ar jie gali būti eksportuojami dideliais kiekiais, jei reikia juos pateikti DVSA ar Transporto komisaro posėdyje?

Paprastumas dirbantiems ir agentūrų vairuotojams

Sistema, kuri yra sunkiai naudojama 04:30 lietuje, nesuveiks realiame pasaulyje. Išbandykite programėlę su vairuotojais, kurie nėra biuro darbuotojai ir nėra ypač techniniai. Taip pat išbandykite laikinų darbuotojų įdarbinimo procesą. Ar agentūros vairuotojas gali būti greitai pridėtas su tinkamomis teisėmis? Ar jie gali būti apriboti tik tiems transporto priemonėms, kurias jie iš tikrųjų naudoja? Flotiloms, kurios priklauso nuo laikino darbo jėgos, praktinės gairės dėl agentūrų vairuotojų naudojimo atitinkamai glaudžiai susijusios su defektų pranešimo kontrolėmis.

Nuliniai defektai ir praleisti patikrinimai

Klauskite, kaip sistema išryškina trūkstamą pranešimą. Nulinio defekto procesas padeda tik tuo atveju, jei pateikimo nebuvimas yra matomas. Kai kurios sistemos gali parodyti šiandien naudojamas transporto priemones, kurioms nėra užbaigtas apžvalgos pranešimas. Tai yra daug naudingiau nei tiesiog saugoti formas skaitmeninėje archyve.

JK tinkamumas, o ne bendroji flotilės programinė įranga

Daugelis programėlių parduodamos įvairiose šalyse. Tai savaime nėra problema, tačiau turėtumėte patikrinti, ar darbo eiga atitinka JK operatorių licencijos lūkesčius. Kur taisyklės skiriasi tarp JK ir ES, bendros sistemos dažnai grįžta prie plačios flotilės modelio, o ne JK atitikties modelio. Pavyzdžiui, JK operatoriai paprastai nori įrašų, kurie patogiai atitinka DVSA Gaires dėl Kelių Tinkamumo Išlaikymo ir gali būti pateikti kartu su patikrinimo lapais, MOT ar metinio patikrinimo istorija ir tachografo įrodymais.

Atskirų defektų programėlių palyginimas su plačiu atitikties sistema

Atskirta defektų programėlė gali gerai veikti, jei jūsų vienintelė problema yra popierinių apžvalgos lapų pakeitimas. Ji gali būti greitai diegiama, paprasta vairuotojams ir trumpuoju laikotarpiu pigesnė nei plačių sistemų keitimas. Jei jūsų dirbtuvės, priežiūros planuotojas ir vairuotojų įrašai jau yra griežtai kontroliuojami kitur, defektų tik programėlė gali būti pakankama.

Apribojimas yra fragmentacija.

Defektų pranešimas ilgai nesėdi atskirai. Praneštas padangos defektas susijęs su patikrinimo planavimu ir remonto istorija. Transporto priemonės išėmimas iš eismo veikia tvarkaraštį, VOR kontrolę ir prieinamumą. Praleistas apžvalgos patikrinimas gali būti svarbesnis, jei ta pati transporto priemonė taip pat yra pasenusi patikrinimui arba artėja prie MOT ar metinio patikrinimo. Vairuotojas, naudodamas programėlę, taip pat gali reikėti licencijų patikrinimų, Driver CPC stebėjimo, DQC galiojimo sekimo ir tachografo priežiūros.

Čia paprastai stipresnė platesnė operatorių licencijos atitikties platforma. Vietoj to, kad saugotumėte defektų pranešimus vienoje vietoje, patikrinimo lapus kitoje ir vairuotojų įrodymus trečioje, galite laikyti transporto priemonės, priekabos ir vairuotojo įrašą kartu. Tai palengvina atsakyti į pagrindinius, bet svarbius klausimus, tokius kaip:

• Ar ši transporto priemonė šiandien tinkama važiuoti?
• Ar ši priekabos patikra yra atnaujinta?
• Ar šis vairuotojas turi teisę ir galiojančią licenciją ją vairuoti?
• Ar yra neišspręstų saugos defektų?
• Jei Transporto komisaras prašo įrašų, ar galime greitai pateikti visą bylą?

Savininkams-vairuotojams ir mažesnėms flotilėms patrauklumas dažnai yra paprastumas, o ne mastas. Vienas prisijungimas, vienas turto sąrašas, vienas priminimų rinkinys ir vienas įrašų rinkinys yra lengviau valdomi nei krūva specializuotų programėlių. Tai ypač aktualu savininkams-vairuotojams, bandantiems išlaikyti vieną atitikties įrašą transporto priemonės ir vairuotojo įsipareigojimams.

Didesnėms flotilėms problema yra kontrolė. Platesnė sistema gali suderinti defektų pranešimus su prevencinės priežiūros patikrinimais, MOT ar metinio patikrinimo datomis, vairuotojų dokumentų patikrinimais ir tachografo įrašais. Ji taip pat gali palaikyti bendras JK operacines struktūras, tokias kaip keli depai, nuomojamos priekabos, pagalbiniai vairuotojai ir mišrios HGV ar PSV flotilės.

Štai kodėl Operator Compliance pateikia integruoto požiūrio argumentą. Kadangi OperatorCompliance sukūrė Fleeta Limited, kuri teigia, kad pati veikia sunkvežimius pagal operatorių licenciją, produkto pozicija nėra tik skaitmeniniai formatai. Tai operatorių licencijos atitikties programinė įranga, sukurta pagal DVSA Gaires dėl Kelių Tinkamumo Išlaikymo. Ar tai jums svarbu, priklauso nuo to, ar norite taško sprendimo, ar vienos įrašų sistemos.

Kur pasirašytas defektų pranešimas tinka dirbtuvėse ir VOR kontrolėje

Geriausias defektų procesas yra kontroliuojama darbo eiga, o ne formos pateikimas.

Pirmas žingsnis yra vairuotojo apžvalgos patikrinimo užbaigimas. Vairuotojas pasirenka transporto priemonę ir priekabą, užfiksuoja nulinį defektą arba rastus defektus, prideda komentarus ir nuotraukas, jei reikia, ir pasirašo deklaraciją.

Antras žingsnis yra peržiūra. Transporto vadybininkas, dirbtuvės kontrolierius ar paskirtas peržiūrėtojas turėtų greitai matyti naujus pranešimus. Sistema turėtų įspėti tinkamus žmones, o ne tiesiog archyvuoti pranešimą. Rimtų problemų atveju tas įspėjimas turi būti pakankamai greitas, kad sustabdytų transporto priemonės naudojimą eksploatacijoje.

Trečias žingsnis yra sprendimas. Peržiūrėtojas nusprendžia, ar defektas yra saugos kritinis, reikalauja skubaus remonto, gali būti stebimas, ar iš viso nėra defekto. Tas sprendimas turėtų būti užfiksuotas. Jei transporto priemonė neturėtų būti naudojama, statusas turėtų pereiti į VOR. Jei problema yra priekaboje, priekaba gali būti VOR, kol vienetas lieka prieinamas.

Ketvirtas žingsnis yra dirbtuvės veiksmas. Defektas turėtų būti priskirtas, ištaisyti ir užfiksuotas. Jei darbas atliekamas viduje, sistema turėtų užfiksuoti techniko ar montuotojo pastabas ir užbaigimo detales. Jei darbas yra perduodamas, vis tiek reikia turėti įrašą apie tai, kas buvo išsiųsta, kas grįžo ir kas priėmė remontą.

Penkta, tai patvirtinimas ir išleidimas. Kas nors su įgaliojimais turėtų patvirtinti, kad defektas buvo ištaisyta ir transporto priemonė ar priekaba gali grįžti į eksploataciją. Tas patvirtinimas turėtų būti matomas audito pėdsake.

Šeštas žingsnis yra išsaugojimas ir atkūrimas. Įrašai turėtų būti lengvai randami pagal transporto priemonę, priekabą, vairuotoją, datų intervalą ir defekto statusą. Jei pakelės sustojimas sukelia vėlesnių klausimų, arba jei reikia priežiūros tyrimo, neturėtumėte ieškoti per ekrano nuotraukas ir pašto dėžutes.

Praktiniais terminais operatoriai turėtų tikėtis, kad sistema teiks:

• įspėjimus apie naujai praneštus defektus
• statuso pokyčius, tokius kaip atidarytas, peržiūroje, VOR, remontuojamas ir uždarytas
• aiškų atskyrimą tarp vairuotojo pranešimo ir valdymo veiksmo
• filtravimą neišspręstiems saugos defektams
• matomumą pakartotiniams defektams tame pačiame turte
• išlaikytus įrašus, kurie gali būti eksportuojami, kai reikia

Jei programėlė nepalaiko šio proceso, dirbtuvės ir transporto biuras sukurs savo sprendimus. Kai tai įvyksta, pasirašytas pranešimas tampa tik vienu fragmentu tikrojo įrašo.

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

Tiekėjo demonstracija turėtų atsakyti į operacinius klausimus, o ne tik parodyti blizgantį mobilųjį ekraną. Naudokite kontrolinį sąrašą ir reikalaukite matyti sudėtingus atvejus.

Įdarbinimas ir vartotojo kontrolė

Klauskite, kaip vairuotojai yra pridėti, pašalinti ir sustabdyti. Ar galite masiškai įkelti vartotojus? Ar agentūros vairuotojai gali būti greitai aktyvuoti ir tada taip pat greitai išjungti? Ar leidimai gali būti padalinti tarp vairuotojų, dirbtuvės darbuotojų, prižiūrėtojų ir transporto vadybininkų?

Palaikymas ir diegimas

Klauskite, kokia diegimo parama yra įtraukta. Ar tiekėjas padės su formų dizainu, turto importu ir vairuotojų mokymu? Kokios palaikymo valandos yra prieinamos, jei vairuotojai pradeda anksti arba dirba savaitgaliais? Jei programėlė nepavyksta, koks yra atsarginis procesas?

Duomenų eksportas

Klauskite dėl pavyzdinio defektų įrašų eksporto, įskaitant parašus, nuotraukas, laiko žymas ir statuso istoriją. Ar eksportai gali būti filtruojami pagal transporto priemonę, priekabą, depą ar datų intervalą? Ar galite išgauti savo duomenis, nesikreipdami į palaikymą?

REST API ir webhooks

Jei jau vykdote transporto, dirbtuvių ar HR sistemas, integracija yra svarbi. Klauskite, ar platforma turi dokumentuotą REST API ir ar webhooks yra prieinami tokiems įvykiams kaip defektas sukurtas, statusas pakeistas ar defektas uždarytas. Tada klauskite sunkesnio klausimo, kokie yra integracijos apribojimai? Greičio apribojimai, laukų apribojimai, priedų tvarkymas ir vienpusis ar dvipusis sinchronizavimas yra svarbūs daugiau nei antraštinis teiginys, kad API egzistuoja.

Atitikimas jūsų turto ir vairuotojo struktūrai

Klauskite, ar sistema tvarko jūsų tikrą operaciją, o ne supaprastintą demonstracinę flotilę. Ar ji gali atskirai valdyti priekabas nuo varomų vienetų? Ar ji gali susidoroti su nuomojamomis transporto priemonėmis, laikinais pakeitimais, daugiadepų flotilėmis ir mišriomis prekių bei keleivių operacijomis?

Atitiktis su DVSA Gairėmis dėl Kelių Tinkamumo Išlaikymo

Klauskite tiekėjo tiesiogiai, kaip darbo eiga atitinka DVSA Gaires dėl Kelių Tinkamumo Išlaikymo. Nepriimkite bendro atsakymo apie pagalbą atitikties srityje. Paprašykite jų parodyti, kaip kasdieniai patikrinimai, nuliniai defektai, defektų eskalavimas, taisymas ir įrašų atkūrimas veikia praktikoje.

Platesni operatorių licencijos įrodymai

Jei jau žiūrite už defektų pranešimo ribų, klauskite, ką dar sistema apima. Ar ji gali sekti patikrinimus, MOT, metinius patikrinimus, Driver CPC, DQC, tachografo įrašus ir licencijų patikrinimus? Ar ji gali palaikyti ryšius su išoriniais duomenų šaltiniais, kai tai aktualu, pavyzdžiui, DVLA patikrinimais, askMID ar įrašais, susijusiais su Motor Insurers' Bureau ir MIB? Jei naudojate kitas flotilės priemones, klauskite, kaip tiekėjas derinasi su produktais, tokiais kaip Fleetalyse ar Logivo.AI, o ne manydami, kad viskas integruojasi sklandžiai.

Tinkamas pasirinkimas paprastai yra sistema, kuri apsunkina blogą praktiką, o ne ta, kuri daro demonstraciją lengvą. JK operatoriams pasirašytas defektų pranešimas nėra kosmetinė funkcija. Tai yra įrodymų grandinės dalis, kuri saugo licenciją, palaiko transporto vadybininką ir rodo DVSA ar Transporto komisarui, kad kelių tinkamumas yra tinkamai kontroliuojamas.

Ar pasirašytas defektų pranešimas pats savaime yra pakankamas įrodymas?

Ne. Tai pa