Pasirinkite HGV apžiūros programėlę, kuri atitinka DVSA

Jei renkatės kasdienės apžiūros programėlę HGV vairuotojams, pagrindinis klausimas nėra ar ji gali pakeisti popierių. Svarbu, ar įrašai, kuriuos ji generuoja, padėtų mums paaiškinti mūsų sistemas DVSA ir, jei reikia, Transporto komisarui. Išvaizdi kontrolinė sąrašas nepakanka, jei jis palieka spragų dėl defektų detalių, laiko žymėjimo, patvirtinimo, VOR kontrolės ar įrodymų, kad remontai buvo atlikti prieš transporto priemonei grįžtant į eksploataciją.

JK operatoriams tinkama programėlė turėtų palaikyti praktines pareigas, susijusias su kasdienine apžiūra. Ji turėtų padėti vairuotojams atlikti tinkamą patikrinimą, padėti transporto vadybininkams kontroliuoti saugos defektus ir kurti įrašus, kurie atlaikytų, kai kas nors paklaus, kas buvo rasta, kokia buvo priimta sprendimas, kas jį priėmė ir kada transporto priemonė buvo vėl naudojama. Tai yra standartas, su kuriuo turėtume palyginti.

Ką kasdienė apžiūros programėlė turi daryti praktikoje

Minimali kasdienės apžiūros programėlė HGV operacijoms turi palaikyti kasdienio vairuotojo defektų pranešimo procesą, nustatytą įprastoje JK operatoriaus licencijos praktikoje. Tai reiškia, kad ji turi daryti daugiau nei tiesiog pateikti padangų, žibintų ir veidrodžių sąrašą su varnele šalia kiekvieno elemento.

Turėtume tikėtis, kad ji atliks penkias pagrindines užduotis.

Pirmiausia, ji turi leisti mums kurti patikrinimo formas, kurios atspindi transporto priemones ir priekabas, kurias iš tikrųjų naudojame. Standartinė, artic vienetų, priekabų, mikroautobusų ir PSV (viešojo transporto) seka ar žodynas nebūtinai turi būti vienodi. Programėlė turėtų leisti mums atskirti vienetų ir priekabų patikrinimus, nustatyti privalomus elementus ir pritaikyti formas krovininėms ir keleivinėms transporto priemonėms, kuriose veikimo modelis skiriasi. Jei naudojame mišrius parkus, vienas šablonas viskam dažnai sukuria arba nereikalingus žingsnius, arba praleistus patikrinimus.

Antra, ji turi užfiksuoti, kas atliko patikrinimą ir kuri priemonė buvo tikrinama. Tai skamba akivaizdžiai, tačiau detalės yra svarbios. Mums reikia aiškaus ryšio su transporto priemonės registracijos numeriu, priekabos numeriu, jei tai aktualu, vairuotojo tapatybe, data ir laiku, ir depu ar vieta, jei tai yra mūsų proceso dalis. Jei programėlė leidžia neaiškius įrašus arba laisvą tekstą, kuris gali būti neteisingai įvestas, įrašas tampa silpnesnis, kai jis vėliau peržiūrimas.

Trečia, ji turi vienodai gerai tvarkyti nulinio defekto ir defektų pranešimus. Daugelis sistemų gerai fiksuoja švarų patikrinimą, tačiau prastai, kai kažkas iš tikrųjų yra neteisinga. Praktikoje programėlė turėtų leisti vairuotojui identifikuoti defektą, tinkamai jį apibūdinti, pridėti nuotraukas, jei tai naudinga, ir be delsimo nukreipti tą pranešimą tinkamam asmeniui. Programėlė neturėtų skatinti vairuotojų pasirinkti artimiausią bendrą kategoriją ir judėti toliau.

Ketvirta, ji turi palaikyti tikrą sprendimą dėl keliamų reikalavimų. Defektų pranešimas nėra tas pats, kas VOR sprendimas. Programėlė turėtų leisti įgaliotam asmeniui peržiūrėti problemą ir nuspręsti, ar transporto priemonė gali būti naudojama, ribojama ar pašalinama iš kelio. Jei tas sprendimas yra už sistemos ribų tekstuose, skambučiuose ar atmintyje, mes prarandame audito taką.

Penkta, ji turi išlaikyti įrašus tokiu būdu, kad galėtume juos greitai rasti. Jei DVSA prašo įrodymų per vizitą, arba jei ruošiamės dokumentams viešajai apklausai, mums reikia rasti patikrinimus pagal transporto priemonę, priekabą, datą ir vairuotoją, nesikapstydami per telefonus ar pašto dėžutes.

Čia daugelis pirkėjų daro neteisingą palyginimą. Jie palygina ekrano išdėstymus ir kontrolinių sąrašų ilgį, tačiau nevertina, ar programėlė padeda jiems vykdyti procesą, aprašytą DVSA Gide dėl keliamų reikalavimų palaikymo. Tas vadovas vis dar yra praktinis standartas JK operatoriams. Kasdienė apžiūros programėlė HGV vairuotojams turėtų atitikti šį standartą, o ne prašyti mūsų jį sumažinti, kad atitiktų programinę įrangą.

Jei taip pat naudojame furgonus, kurie yra žemiau HGV ribų, ta pati sistema vis dar gali būti naudinga, tačiau turėtume prisiminti, kad operatoriaus licencijos sistema yra skirtinga. Atitikties rizika 44 tonų artic ir lengvojo furgono nėra identiška, net jei abi naudoja disciplinuotą kasdienės apžiūros procesą.

Kaip palyginti įrodymų kokybę, o ne tik varnele

Stipriausios apžiūros programėlės kuria įrodymus, o ne tik užpildytas formas. Šis skirtumas yra svarbus, kai įrašas yra tikrinamas.

Pradėkite nuo parašų. Turėtume pažvelgti, kaip vairuotojas pasirašo patikrinimą ir ką ta parašas reiškia sistemoje. Ar jis susietas su vardiniu prisijungimu, data ir laiku, ir tiksliai užpildytu kontroliniu sąrašu tuo momentu? Ar tai tiesiog brūkšnys ekrane, kuris galėjo būti pridėtas vėliau? Naudingas parašo įrašas turėtų rodyti, kas atliko patikrinimą ir užrakinti tą pateikimą kaip audito taką.

Kitą, pažvelkite į laiko žymėjimus. Mums reikia daugiau nei tik dienos. Tinkamas įrašas turėtų rodyti pateikimo laiką, o idealiai - bet kokias vėlesnes veiklas, tokias kaip defekto peržiūra, VOR sprendimas, remonto patvirtinimas ir grįžimas į eksploataciją. Jei transporto priemonė buvo sustabdyta 07:15, o patikrinimas buvo akivaizdžiai atliktas 09:40, mums reikia tai žinoti. Sistema, kuri negali aiškiai parodyti įvykių sekos, gali greitai tapti nepatogia.

Defektų detalės yra dar viena skiriamoji linija. Jei kiekvienas klausimas pasirodo kaip „šviesos defektas“ arba „padangos problema“, įrašas mums nepasako daug. Geresnės sistemos leidžia vairuotojui nurodyti, kuris žibintas, kuri padangos padėtis, kokia žala buvo matoma ir ar defektas paveikė saugų naudojimą. Laisvas tekstas čia yra svarbus, tačiau struktūra taip pat. Norime pakankamai standartizacijos, kad galėtume nuosekliai pranešti, nesumažindami kiekvienos realios problemos iki neaiškaus žymėjimo.

Nuotraukos yra naudingos, tačiau tik jei jos yra įrodymų grandinėje. Turėtume patikrinti, ar nuotraukos yra pridėtos prie pranešimo su laiku ir data, ar jos lieka susietos su defektu, ir ar vėlesni žiūrovai gali matyti visą kontekstą. Nuotraukos turėtų palaikyti raštišką pranešimą, o ne pakeisti jį. Neryški nuotrauka su šoninio sienelės pjūviu be jokios pastabos apie ašies padėtį ar protektoriaus būklę nėra labai naudinga.

Tada yra audito takas. Čia stipresnės sistemos atsiskiria nuo paprastų formų programėlių. Turėtume galėti matyti, kas sukūrė patikrinimą, kas peržiūrėjo defektą, kas pakeitė statusą, kas įgaliavo išleidimą iš VOR ir ar kas nors buvo redaguota vėliau. Jei įrašai gali būti perrašyti be pėdsakų, jais daug sunkiau pasikliauti.

Išlaikymas ir atkūrimas yra tokie pat svarbūs kaip ir fiksavimas. Per DVSA vizitą galime prireikti pateikti įrodymų modelį, o ne vieną izoliuotą patikrinimą. Pavyzdžiui, įrašai, rodantys pakartotinius nulinio defekto pranešimus apie transporto priemonę, kuri vėliau parodė akivaizdžių problemų, gali sulaukti didesnio dėmesio. Programėlė turėtų palengvinti paiešką ir įrašų eksportavimą pagal transporto priemonę, priekabą, vairuotoją ir datų intervalą.

Šiuo metu taip pat turėtume paklausti, ar sistema gali palaikyti valdymo priežiūrą. Ar galime identifikuoti praleistus patikrinimus, vėluojančius patikrinimus, pakartotinius defektus ar transporto priemones, naudojamas prieš uždarant defektą? Įrašas, kuris egzistuoja, bet niekada nepateikiamas transporto biurui, yra tik pusė sprendimo.

Mes šią operatyvinę pusę išsamiau apžvelgiame savo gide apie vairuotojų apžiūras ir defektų pranešimus. Principas yra paprastas. Jei įrašas nepadėtų mums paaiškinti mūsų veiksmų, kai esame tikrinami, jis nėra pakankamai stiprus įrodymas.

Defektų pranešimas, VOR kontrolė ir remonto sekimas

Reali bet kurios apžiūros programėlės patikra prasideda, kai vairuotojas randa defektą, kuris gali paveikti keliamus reikalavimus.

Paprasta programėlė užregistruos klaidą ir išsiųs el. laišką. Geresnė palaikys visą grandinę nuo pranešimo iki sprendimo, remonto ir išleidimo. Tai yra tai, ką transporto vadybininkai turėtų palyginti.

Pirmas punktas yra eskalacija. Kai pranešamas su sauga susijęs defektas, kas yra informuojamas ir kaip greitai? Sistema turėtų leisti nedelsiant pranešti tiems, kurie gali veikti, o ne tiesiog viską sudėti į bendrą pašto dėžutę. Jei dirbtuvės, parkų inžinierius ir transporto biuras kiekvienas turi matyti, programėlė turėtų aiškiai palaikyti tą darbo eigą.

Antras punktas yra statuso kontrolė. Mums reikia daugiau nei atvirų ir uždarų. Praktikoje naudingi statusai gali apimti pranešta, peržiūrima, VOR, užsakyta remontui, suremontuota, patikrinta ir grąžinta į eksploataciją. Tikslūs žymėjimai yra mažiau svarbūs nei disciplina už jų. Turime galėti parodyti, kad transporto priemonė nebuvo tiesiog „sutaisyta“ teorijoje, bet perėjo per kontroliuojamą procesą.

VOR tvarkymas nusipelno ypatingo dėmesio. Jei defektas reiškia, kad transporto priemonė neturėtų būti naudojama, sistema turėtų tai aiškiai parodyti ir sunkiai apeiti. Idealiu atveju transporto priemonės ar priekabos statusas turėtų būti matomas planuotojams ir transporto darbuotojams, kad ji negalėtų būti netyčia paskirta. Pastaba, paslėpta viename vairuotojo pranešime, nėra pakankama. Taip pat turėtume galėti užfiksuoti, kas priėmė VOR sprendimą ir kokiu pagrindu.

Remonto sekimas yra vieta, kur daugelis operatorių vis dar grįžta prie popieriaus ar WhatsApp. Tai silpnina bylą. Geresnis požiūris yra išlaikyti dirbtuvių komunikaciją ir užbaigimo įrodymus susietus su originaliu defektu. Tai gali apimti meistro pastabas, išorinių remontininkų duomenis, pakeistas dalis ir remonto užbaigimo datą bei laiką. Jei saugos patikrinimas, PMI ar kitas dirbtuvių įvykis yra aktualus, įrašai turėtų būti aiškiai tarpusavyje susieti.

Svarbiausia, turi būti įrodymas, kad defektas buvo išspręstas prieš transporto priemonei vėl naudojantis, jei tai buvo reikalaujama. Tai gali reikšti priežiūros patvirtinimą, antrą vairuotojo patvirtinimą arba vadybininko išleidimą, priklausomai nuo mūsų proceso. Svarbu, kad įrašas parodytų aiškų prieš ir po.

Tai ypač svarbu priekaboms. Užimtuose kiemuose priekabų defektus gali pranešti vienas vairuotojas, aptarti kitas, o vienetas gali paimti iš kitos dirbtuvės. Jei programėlė netinkamai seka priekabos statusą, lengva, kad defektyvi priekaba vėl būtų naudojama.

Operatoriams, naudojantiems trečiųjų šalių dirbtuves, programinė įranga vis tiek turėtų leisti mums išlaikyti įrodymus vienoje vietoje. Teisinė atsakomybė pagal operatoriaus licenciją lieka su mumis. Negali būti gynybos teigti, kad dirbtuvės turėjo duomenis savo sistemoje.

Vairuotojo naudojimo paprastumas, darbas be interneto ir mišrūs parkai

Atitikties procesas veikia tik tada, kai vairuotojai gali jį tinkamai atlikti kiekvieną dieną, esant sąlygoms, kuriose jie iš tikrųjų dirba.

Tai reiškia, kad naudojimo paprastumas yra svarbus, tačiau ne vartotojų programėlės prasme. Mes neieškome pramogų. Mes ieškome proceso, kurį galima greitai, tiksliai ir nuosekliai užbaigti 04:30 lietuje, naudojant bendrą įrenginį, vairuotojui, kuris turi pradėti darbą.

Programėlė turėtų būti paprasta naršyti, su aiškia patikrinimo tvarka ir žodynu, kurį vairuotojai supranta. Jei kontrolinis sąrašas yra perpildytas, paslėptas už per daug paspaudimų arba pilnas biuro kalbos, užbaigimo kokybė sumažėja. Taip pat turėtume ieškoti protingų valdymo priemonių, tokių kaip privalomi defektų pastabos, kai pranešama apie klaidą, lengvas priekabų pasirinkimas ir aiškūs raginimai nuotraukoms, kur tai naudinga.

Darbas be interneto nėra neprivalomas daugeliui operatorių. Kaimo depai, karjerai, uostai, statybvietės ir kai kurios pagrindinės tinklo dalys vis dar turi prastą signalą. Jei programėlė veikia tik su aktyvia jungtimi, vairuotojai arba praleis patikrinimus, arba juos vėl atliks vėliau, abu atvejai silpnina įrašą. Tinkama offline režimas turėtų leisti patikrinimą atlikti įrenginyje, o vėliau automatiškai sinchronizuoti, kai signalas grįžta, išsaugant originalų užbaigimo laiką.

Bendri ir mišrūs parkai reikalauja kruopštaus apmąstymo. Jei mes naudojame HGV, furgonus, priekabas ir PSV, programėlė turėtų leisti kiekvienai operacijai naudoti tinkamą darbo eigą, nesukeliant painiavos. Autobusų ar mikroautobusų operatorius gali reikėti skirtingų kasdienių pranešimų raginimų nei bendrosios krovinių vežimo parkas. Kurjerių parkas, naudojantis lengvesnes transporto priemones, vis tiek gauna naudos iš defektų pranešimų, tačiau operatoriaus licencijos ir metinio testo kontekstas nėra identiškas.

Agentūros ir laikini vairuotojai yra dar vienas praktinis išbandymas. Ar jie gali būti greitai nustatyti su tinkamomis teisėmis ir vis tiek palikti vardinius, pasirašytus įrašus? Jei mes reguliariai pasikliaujame agentūros darbuotojais, apžiūros procesas turi veikti be tapatybės kontrolės silpninimo. Mūsų gairės apie agentūros vairuotojų naudojimą atitinkamai ir vairuotojų licencijų patikrinimus operatoriams yra šalia to dėl priežasties. Kasdienis patikrinimas yra tik viena dalis, įrodanti, kad tinkamas asmuo vairavo teisėtai ir kontroliuojamai.

Nuosavybės vairuotojams tas pats taškas taikomas paprastesne forma. Jei vienas asmuo yra vairuotojas, operatorius ir dažnai pirmasis defektų pranešėjas, programėlė vis tiek turi aiškiai atskirti etapus, kad parodytų kontrolę. Tai viena iš priežasčių, kodėl daugelis vieno transporto priemonės operatorių pereina nuo popieriaus prie programinės įrangos, kai verslas auga. Mūsų atitikties įrankiai nuosavybės vairuotojams yra sukurti aplink šią realybę.

Kada apžiūros programėlė turėtų būti platesnės atitikties sistemos dalis

Nepriklausoma apžiūros programėlė gali būti pakankama, jei mūsų operacija yra maža, paprasta ir jau gerai kontroliuojama kitur. Tačiau kai mes valdome kelias transporto priemones, priekabas, vairuotojus, patikrinimo intervalus ir dokumentų terminus, kasdieniai patikrinimai turėtų būti platesnės atitikties sistemos dalis.

Priežastis yra paprasta. Apžiūros pranešimas retai būna atskiras. Jis susijęs su transporto priemonių priežiūros planavimu, MOT ar metinio testo datomis, saugos patikrinimų tvarkaraščiais, vairuotojų įrašais, tachografo įrodymais, draudimu ir kartais incidentų valdymu. Jei šie įrašai yra skirtingose sistemose be bendros turto istorijos, mes praleidžiame per daug laiko juos suderindami, kai kyla klausimų.

Pavyzdžiui, jei transporto priemonė kasdieniuose patikrinimuose rodo pakartotinius su padangomis susijusius defektus, galbūt norėsime pamatyti jos patikrinimo istoriją ir dirbtuvių rezultatus šalia tų pranešimų. Jei vairuotojas nuolat pateikia prastos kokybės nulinio defekto patikrinimus, galbūt norėsime peržiūrėti mokymo įrašus, licencijų patikrinimus su DVLA, Driver CPC statusą, DQC galiojimo pabaigą ir bet kokius tachografo modelius, rodančius skubotus startus. Tai sunku, jei apžiūros programėlė yra izoliuota.

Platesnė sistema taip pat padeda su terminais ir kontrolės įrodymais. Operatoriai turi stebėti MOT užsakymus, metinio testo planavimą PSV, patikrinimo dažnumus, vairuotojų licencijų patikrinimus, Driver CPC, DQC, draudimą ir kitus įrašus vienoje vietoje. Kur yra JK specifiniai operatoriaus licencijos lūkesčiai, tas sujungtas vaizdas yra svarbesnis nei gali būti bendroje ES parko priemonėje. JK vykdymo aplinka formuojama DVSA praktikos, operatoriaus licencijos režimo ir Transporto komisaro vaidmens.

Todėl mes sukūrėme OperatorCompliance kaip platesnės operatoriaus licencijos atitikties platformos dalį, o ne tik formų programėlę. Fleeta Limited valdo sunkvežimius pagal operatoriaus licenciją, todėl mes sukūrėme aplink įrašus, kurių operatoriai paprastai prašomi pateikti. Praktikoje tai reiškia, kad kasdieniai apžiūros patikrinimai turi būti susiję su likusia byla, o ne sėdėti atskirai.

Integracija taip pat gali būti svarbi. Jei jau naudojame kitas sistemas, paklauskite, kas yra prieinama be skaičiuoklės eksportavimo. REST API ir webhooks gali būti naudingi, kai parkų duomenys turi judėti tarp dirbtuvių, telematikos ar HR sistemų. Tačiau integracija neturėtų atitraukti dėmesio nuo pagrindinio atitikties klausimo. Gražiai sujungta programėlė, kuri generuoja silpnus įrodymus, vis tiek yra neteisingas pasirinkimas.

Tas pats taikoma papildomoms ir gretutinėms paslaugoms. Nuorodos į askMID, Motor Insurers' Bureau ar MIB duomenis gali padėti kai kuriuose darbo procesuose. Ryšiai su Fleetalyse ar Logivo.AI gali būti tinkami tam tikriems operatoriams. Prieiga prie VOL įrašų taip pat gali būti svarbi operatyviai. Tačiau niekas iš to nepakeičia aiškaus kasdienio defektų įrodymo, kontroliuojamų VOR sprendimų ir atkuriamų įrašų poreikio.

Tai kada turėtume pasirinkti platesnę atitikties sistemą, o ne nepriklausomą programėlę? Paprastai, kai taikoma bet kuri iš šių sąlygų:

• mes valdome kelias transporto priemones ar priekabas
• daugiau nei vienas asmuo valdo atitiktį
• defektai reikalauja dirbtuvių sekimo per depus
• mes turime vieną bylą DVSA vizitams
• mes norime matyti praleistus patikrinimus ir vėluojančias veiklas
• vairuotojų įrašai, tachografo įrodymai ir priežiūros terminai šiuo metu yra išsklaidyti skirtingose vietose

Trumpai tariant, geriausia kasdienė apžiūros programėlė HGV vairuotojams yra ta, kuri padeda mums įrodyti kontrolę, o ne tik rinkti varnele. Jei ji palaiko tinkamą defektų pranešimą, stiprius įrodymus, aiškius VOR sprendimus ir natūraliai susijungia su likusiomis mūsų operatoriaus licencijos pareigomis, ji atliks savo darbą, kai tai svarbu. Jei negali, tai tik skaitmeninė popieriaus versija, o popierius niekada nebuvo tikroji problema.