Kuri sistema laikosi VOR įrašų pasiruošusių DVSA vizitui?

Sistema, kuri laikosi VOR įrašų pasiruošusių DVSA vizitui, yra ta, kuri daro daugiau nei tiesiog pažymėti transporto priemonę kaip neprieinamą. Ji turi parodyti, kodėl transporto priemonė buvo pašalinta iš kelio, kas įvyko toliau, kurie defektai ar patikros rezultatai lėmė tą sprendimą, kas pasirašė ir kada transporto priemonė buvo grąžinta į eksploataciją. Jei tie įrodymai yra išsklaidyti po skaičiuokles, dirbtuvių užrašus, el. laiškus ir vairuotojų defektų knygas, įrašą sunkiau apginti, kai DVSA inspektorius ar Transporto komisaras to prašo.

JK operatoriams VOR įrašai yra platesnio operatoriaus licencijos konteksto dalis. Geras sistema turi sujungti VOR statusą su saugos patikromis, MOT ar metinių testų datomis, vairuotojų apžvalgos patikromis, remonto istorija, priekabų įrašais ir dokumentų įrodymais. Tai yra skirtumas tarp paprastos flotilės priemonės ir programinės įrangos, sukurtos laikyti O licencijos transporto priemonių iš kelio įrašus taip, kad atlaikytų patikrinimą.

Ką operatoriai nori iš VOR įrašų programinės įrangos

Kai transporto priemonė yra pažymėta VOR, operatoriai turi turėti aiškų įvykio įrašą ir atitinkamą kontekstą. Praktikoje tai reiškia, kad reikia užfiksuoti transporto priemonės ar priekabos tapatybę, datą ir laiką, kada ji buvo pašalinta iš kelio, priežastį, defektą ar priežiūros signalą, ir asmenį, kuris priėmė ar patvirtino sprendimą. Jei problema kilo iš vairuotojo ataskaitos, saugos patikros, kelio patikros, dirbtuvių diagnozės ar nesėkmingo testo elemento, tas šaltinis turėtų būti matomas kaip dalis įrašo.

Prekių transporto priemonių ir PSV operatoriams JK tai yra svarbu, nes licencijos įsipareigojimas yra apie tinkamą priežiūros organizavimą ir kelio tinkamas transporto priemones. VOR įvykis gali paremti tą poziciją, jei jis rodo, kad operatorius veikė greitai ir teisingai. Tai gali ją pakenkti, jei įrašai yra neaiškūs, neišsamūs ar neįmanoma priskirti prie priežiūros bylos.

Naudingas VOR įrašas turėtų būti šalia:

• planuojamų patikros intervalų
• užpildytų patikros lapų
• defektų ataskaitų ir taisymo įrašų
• MOT ar metinių testų užsakymo ir rezultatų įrašų
• stabdžių testų įrodymų, jei taikoma
• odometro rodmenų ar naudojimo duomenų
• pasirašytų grąžinimo į eksploataciją įrašų

Tas sujungtas įrašas dažnai yra tai, kas lemia DVSA vizitą. Inspektorius gali pradėti nuo vienos transporto priemonės ir klausti, kodėl ji praleido važiavimą, kodėl patikros data pasikeitė, ar kaip buvo išspręstas praneštas defektas. Jei atsakymas yra tik „ji buvo iš kelio remontui“, tai nėra daug atitikties įrašo. Jei galime parodyti defektų ataskaitą, VOR pradžią, remonto instrukciją, atliktą darbą, patikros įrodymus ir datą, kai grąžinta į eksploataciją, byla turi prasmę.

Čia taip pat yra, kur JK operatoriaus licencijos praktika skiriasi nuo bendro ES flotilės požiūrio. Daugelis bendrų sistemų yra sukurtos aplink naudojimą, dirbtuvių planavimą ar kaštų kontrolę. JK operatoriams reikia įrašų, kurie atitiktų DVSA Gidą dėl Kelio Tinkamumo Išlaikymo ir gali būti pateikti kaip operatoriaus licencijos byla. Tai apima priekabas, taip pat varomas transporto priemones, ir dažnai apima mišrias flotiles, kur furgonai, HGV, PSV ir pagalbinės priekabos turi būti valdomos vienoje vietoje.

Operator Compliance, mes sukūrėme programinę įrangą aplink šią realybę. Fleeta Limited valdo sunkvežimius pagal operatoriaus licenciją, todėl žinome, kad VOR sprendimas nėra tik operatyvinis statusas. Tai yra priežiūros istorijos dalis, kuri turi būti tinkamai įrodyta.

Kokios funkcijos yra svarbiausios kasdieniniame naudojime?

Naudingiausia funkcija nėra pati įspūdingiausia. Tai gebėjimas pereiti nuo defekto ar termino iki aiškios veiksmų, nesukuriant dubliuotų įrašų ar paliekant spragų.

Pirmiausia sistema turi turėti tinkamą VOR statusą su datomis, priežastimis ir pastabomis. Tai skamba akivaizdžiai, tačiau daugelis įrankių siūlo tik paprastą neprieinamumo žymą. Transporto vadybininkai turi žinoti, ar transporto priemonė yra VOR dėl saugos defekto, praleistos patikros, MOT nesėkmės, metinių testų problemos, padangos problemos, stabdžių problemos, avarijos žalos ar dokumentų problemos. Šios priežastys yra svarbios, kai peržiūrimos tendencijos ir aiškinami sprendimai vėliau.

Antra, patikros planavimas turi veikti taip, kaip operatoriai iš tikrųjų planuoja priežiūrą. Tai reiškia, kad reikia nustatyti patikros dažnumus pagal transporto priemonę ar priekabą, aiškiai matyti artėjančias datas ir koreguoti dirbtuvių užsakymus, neprarandant audito pėdsako. Operatoriai dažnai dirba pagal kalendoriaus datą, rida, variklio valandas ar derinį. Kai kurie taip pat planuoja pagal ISO savaitės modelius. Jei sistema negali parodyti, kas buvo numatyta, kada tai buvo atlikta ir ar kas nors buvo praleista, ji nepadės daug atitikties peržiūroje.

Trečia, MOT ir metinių testų datos turi būti matomos ir aktyviai valdomos. Programinė įranga turėtų pažymėti artėjančias datas, saugoti užsakymo patvirtinimus ir įkelti testo rezultatų įrodymus. PSV ir HGV metinių testų valdymas turi būti toks pat lengvas kaip MOT valdymas lengvesnėms transporto priemonėms. Jei flotilė apima abi, programinė įranga neturėtų priversti atskirų procesų.

Ketvirta, defektų įrašai ir vairuotojų patikros turi būti susiję su VOR sprendimu. Vairuotojo apžvalgos ataskaita turėtų tiesiogiai vesti į vertinimą, taisymo planą ir, jei reikia, VOR statusą. Jei defektas yra kritiškai svarbus saugai, sistema turėtų apsunkinti transporto priemonės aktyvumo palikimą klaidingai. Jei defektas yra nedidelis ir stebimas, pastabose turėtų būti parodyta, kodėl transporto priemonė liko eksploatacijoje. Tas skirtumas dažnai yra svarbus vėliau.

Penkta, dokumentų įrodymai turi būti saugomi prieš tinkamą turtą ir įvykį. Operatoriai turėtų galėti pridėti patikros lapus, stabdžių testų ataskaitas, dirbtuvių sąskaitas, nuotraukas, technikų pastabas ir pasirašytus pareiškimus. Jei tie failai gyvena bendrame diske už sistemos ribų, atgauti juos tampa lėtai ir nevienodai.

Kasdieniniame naudojime transporto vadybininkai taip pat dažnai nori sujungtų įrašų už dirbtuvių bylos ribų. Vairuotojų licencijų patikros su DVLA, Driver CPC sekimas, DQC galiojimo datos, tachografo analizė ir draudimo patvirtinimas gali turėti įtakos tam, ar transporto priemonė gali būti teisėtai ir praktiškai naudojama. Jei viena sistema gali laikyti tuos įrašus kartu, tai sumažina riziką, kad kažkas bus praleista, nes jis buvo kitoje skaičiuoklėje.

Todėl daugelis operatorių ieško ne tik priežiūros registravimo, bet ir vienos sistemos licencijų patikroms ir tachografo įrašams. Kuo arčiau įrašai yra vienas kito, tuo lengviau suprasti, kas įvyko tam tikrą dieną ir tai įrodyti.

Didesnėms flotilėms ar sujungtoms sistemoms praktinė integracija taip pat yra svarbi. REST API arba webhooks gali padėti, kai operatoriai nori perkelti transporto priemonės statusą į kitas priemones arba gauti atnaujinimus iš dirbtuvių ir telematikos platformų. Tačiau integracija turėtų palaikyti atitikties įrašą, o ne jį pakeisti. Gyvas statuso srautas yra naudingas tik tuo atveju, jei pagrindinis įrašas yra išsamus.

Kaip palyginti audito įrodymus DVSA vizitui?

Palygindami sistemas, siūlome pažvelgti į įrodymų failą, kurį galėtumėte pateikti tą dieną, kai DVSA inspektorius to prašo.

Pradėkite nuo audito pėdsako. Ar sistema gali parodyti, kada įrašas buvo sukurtas, pakeistas ir užbaigtas, ir kieno? Jei VOR data keičiasi, ar galite matyti pradinį įrašą? Jei defektas yra uždarytas, ar galite matyti, kas jį patvirtino? Patikimas audito pėdsakas yra vienas aiškiausių skirtumų tarp operatoriaus licencijos programinės įrangos ir bendros skaičiuoklės.

Kitas, pažvelkite į pasirašytus įrašus. Vairuotojų defektų patikros, dirbtuvių patvirtinimas, grąžinimas į eksploataciją ir patikros užbaigimas turėtų būti galimi pasirašyti arba kitaip aiškiai priskirti vardiniams vartotojams. Jei sistema leidžia anoniminius redagavimus arba palieka jokią vartotojų istoriją, tai silpnina bylą.

Termino priminimai taip pat yra svarbūs, bet tik jei jie yra susiję su įrodymais. Priminti, kad patikra yra numatyta, yra naudinga. Priminti kartu su užbaigtu patikros įrašu, įkeltu lapu ir kita numatyta data yra tai, kas daro bylą tvirta. Tas pats taikoma MOT, metinių testų, Driver CPC, DQC, draudimo ir licencijų patikroms.

Parsisiunčiami failai yra dar vienas praktinis testas. Ar galite greitai eksportuoti transporto priemonės istoriją, priekabos istoriją ar vairuotojo failą? Ar galite sukurti paketą vienam registracijos ar flotilės numeriui, kuriame būtų patikros, defektai, VOR laikotarpiai ir palaikantys dokumentai? Ar galite spausdinti ar parsisiųsti įrašus forma, kurią DVSA inspektorius ar Transporto komisaras gali sekti be poreikio apžiūrėti programinę įrangą?

Paskutinis punktas yra svarbesnis, nei daugelis operatorių tikisi. Geras Transporto komisaro failas nėra tik PDF krūva. Tai aiški chronologija. Jei transporto priemonė praleido patikros datą, nes ji buvo VOR, byla turėtų aiškiai parodyti tą seką. Jei priekaba nepavyko patikros, tapo VOR, buvo suremontuota ir tada praėjo pakartotinę patikrą, chronologija turėtų būti akivaizdi.

Mes šią palyginimą išsamiau apžvelgiame mūsų gide apie kaip palyginti kelio tinkamumo programinę įrangą DVSA įrodymams. Trumpa versija yra paprasta. Paprašykite kiekvieno tiekėjo parodyti jums vieną pilną transporto priemonės bylą, o ne tik prietaisų skydelį.

Operatoriai taip pat turėtų patikrinti, ar sistema palaiko realius palaikančius įrašus už priežiūros ribų. Pavyzdžiui, jei naudojate askMID, kad patvirtintumėte draudimo detales per Motor Insurers' Bureau arba MIB, ar tie įrodymai gali būti protingai išsaugoti su transporto priemonės įrašu? Jei tachografo pažeidimai ar trūkstami atsisiuntimai turi įtakos operatyviniams sprendimams, ar tie įrašai gali būti matomi ten, kur transporto biuras gali juos matyti? Kuo labiau byla atspindi tikrą atitikties vaizdą, tuo lengviau tampa DVSA vizitas.

Kodėl pigesni flotilės įrankiai dažnai nepavyksta

Pigesni įrankiai paprastai nepavyksta vienu iš dviejų būdų. Arba jie yra per daug bendri, arba jie yra per mažai įrodymų.

Bendra flotilės platforma gali būti tinkama paslaugų užsakymui, degalų registravimui ar naudojimo sekimui. Tačiau operatoriaus licencijos atitiktis reikalauja daugiau struktūros. Transporto vadybininkas turi žinoti ne tik tai, kad paslauga įvyko, bet ir ar tai buvo suplanuota saugos patikra, ar ji buvo laiku, kokie defektai buvo rasti, ar jie buvo ištaisyti, ir ar transporto priemonė buvo VOR tuo tarpu. Pagrindiniai priežiūros užrašai neatsako į šiuos klausimus.

Skaičiuoklės yra kitas bendras silpnumas. Jos gali išvardyti numatytas datas ir VOR laikotarpius, tačiau nesukuria patikimo audito pėdsako. Jos nekontroliuoja, kas ką pakeitė. Jos natūraliai nesusieja defektų ataskaitos su remonto įrašu ir tada su grąžinimu į eksploataciją. Jos taip pat linkusios sugesti, kai tik įtraukiamos priekabos, agentų vairuotojai, keli depai ar mišrios transporto priemonių klasės.

Tas pats problemos pasirodo pigiose programėlėse, kurios orientuojasi tik į kasdienes patikras. Užfiksuoti vairuotojo defektą yra naudinga, tačiau tai tik pradžia. Jei programėlė negali valdyti taisymo, VOR laikotarpio, patikros tvarkaraščio ir dokumentinių įrodymų, operatorius vis tiek baigia palaikydamas lygiagrečius įrašus kitur.

Kitas bendras trūkumas yra priekabų valdymas. Kai kurios sistemos traktuoja priekabas kaip antraeiles, nors priekabų patikros ir defektų įrašai dažnai yra centriniai DVSA tyrimui. Jei programinė įranga negali suteikti priekaboms tokio pat lygio planavimo, VOR sekimo ir įrodymų saugojimo kaip transporto priemonėms, atitikties vaizdas lieka neišsamus. Operatoriams, kurie konkrečiai peržiūri šią sritį, mūsų gidas apie priekabų patikros programinės įrangos pasirinkimą DVSA įrašams nurodo, ką ieškoti.

Pigūs programinės įrangos sprendimai taip pat gali nepavykti dėl JK specifinių atitikties detalių. Jie gali netinkamai atskirti MOT ir metinių testų procesus. Jie gali nesekti Driver CPC ir DQC datų toje pačioje vietoje kaip transporto priemonių įrašai. Jie gali nepalaikyti švarios bylos VOL susijusiai administracijai. Jie gali siūlyti prietaisų skydelius, bet ne naudingą įrodymų paketą.

Čia skirtumas tarp flotilės valdymo įrankio ir programinės įrangos, skirtos laikyti O licencijos transporto priemonių iš kelio įrašus, tampa labai aiškus. Viena sako, kas vyksta operatyviai. Kita padeda jums įrodyti, kad jūsų priežiūros sistema yra veiksminga ir kontroliuojama.

Kada Operator Compliance greičiausiai bus geresnis pasirinkimas

Operator Compliance paprastai yra geresnis pasirinkimas, kai operatorius reikia vienos sistemos, sukurtos pagal JK operatoriaus licencijos reikalavimus, o ne tik dirbtuvių veiklą.

Tai apima krovinių vežėjus ir savininkus, kurie turi laikyti VOR įvykius susijusius su patikromis, defektais, MOT ar metinių testų datomis ir tachografo įrodymais. Tai taip pat apima autobusų ir mikroautobusų operatorius, kurie turi aiškų PSV priežiūros įrašą, ir furgonų flotiles ar kurjerių operatorius, kurių atitikties našta dabar viršija paprastus aptarnavimo tvarkaraščius. Taksi ir privačių nuomos įmonės, taip pat įdarbinimo ir vairuotojų agentūros, taip pat gali pasinaudoti, kai vairuotojų įrašai, licencijų patikros ir dokumentų kontrolė turi būti šalia transporto priemonės statuso.

Mes dažnai esame stiprus pasirinkimas mišrioms flotilėms. Jei jūs valdyti transporto priemones ir priekabas kartu, arba HGV, furgonų ir PSV derinį, tai padeda valdyti juos vienoje struktūroje, o ne skaidyti įrašus per atskirus įrankius. Tas pats taikoma, jei skirtingi žmonės tvarko transporto, dirbtuvių ir vairuotojų administravimą. Sujungta byla yra lengviau prižiūrėti nei kelios dalinės.

Operator Compliance taip pat tinka operatoriams, kurie nori tachografo ir vairuotojų įrodymų kartu su priežiūros įrašais. Tai reiškia ne tik VOR sekimą, bet ir vairuotojų licencijų patikras su DVLA, Driver CPC ir DQC valdymą, ir tachografo analizę, kuri palaiko platesnį atitikties vaizdą. Jei transporto vadybininkas yra atsakingas už viską, atskiros sistemos dažnai sukuria išvengiamas spragas.

Kadangi OperatorCompliance yra sukurtas Fleeta Limited, o ta komanda veikia pagal operatoriaus licenciją, darbo eiga atspindi tai, ko transporto biurai iš tikrųjų turi pagaminti. Mes sukūrėme tai aplink DVSA Gidą dėl Kelio Tinkamumo Išlaikymo, su praktiniais įrašais, kurie gali būti parodyti per DVSA vizitą arba surinkti Transporto komisaro posėdžiui. Tai taip pat kodėl platforma yra sukurta kasdieniniam operatyviniam naudojimui, o ne tik biuro ataskaitoms po įvykio.

Kai kurie operatoriai taip pat norės sistemos ryšių. Kur reikia, REST API prieiga ir webhooks gali palaikyti duomenų dalijimąsi su kitomis platformomis. Mes taip pat dirbame rinkoje, kur operatoriai gali jau žinoti tokius pavadinimus kaip Fleetalyse arba Logivo.AI. Pagrindinis klausimas nėra, kuriame produkte yra judriausias prietaisų skydelis. Tai yra, kuris palieka jums aiškiausią, labiausiai ginčijamą operatoriaus licencijos bylą.

Jei jūsų dabartinis procesas remiasi skaičiuoklėmis, dirbtuvių el. laiškais ir atskiromis defektų programėlėmis, pagrindinis patobulinimas paprastai nėra tik greitis. Tai yra kontrolė. VOR įvykis tampa struktūrizuotu atitikties įrašu su datomis, veiksmais, parašais ir įrodymais. Tai yra tai, kas daro skirtumą, kai DVSA prašo pamatyti, kaip jūs valdote kelio tinkamumą praktikoje.

Norėdami atidžiau pažvelgti į svarbiausius įrašus, mūsų gidas apie operatoriaus licencijos priežiūros įrašus nurodo pagrindinę bylą, kurią operatoriai turėtų sugebėti pateikti.