Pasirinkimas priekabų patikros programinės įrangos DVSA įrašams

Jei renkatės programinę įrangą priekabų patikros įrašams JK, testas yra paprastas. Ar galite parodyti DVSA ir, jei reikia, Transporto komisijai aiškią kiekvienos priekabos priežiūros istoriją, su suplanuotomis patikros datomis, užpildytomis patikros lapais, defektų įrašais, taisymo įrodymais ir patvirtinimu? Jei atsakymas nėra akivaizdus „taip“, sistema palieka spragą.

Daugumai operatorių tinkamas pasirinkimas nėra tik priekabų kontrolinio sąrašo programa. Tai yra atitikties sistema, kuri laiko priekabų įrašus kartu su likusia operatoriaus licencijos byla. Tai svarbu, nes priekabos realiose operacijose nesėdi atskirai. Jos juda tarp vienetų, depų, vairuotojų ir dirbtuvių, o jų įrašai turi likti pilni, datuoti ir lengvai pateikiami.

Ką JK operatoriai iš tikrųjų reikia iš priekabų patikros įrašų

JK operatoriaus licencijos kontekste priekabų patikros įrašai nėra tik paslaugų priminimas. Tai yra įrodymas, kad turite tinkamą sistemą, kad priekabos būtų tinkamos važiuoti.

Praktiniu lygiu kiekviena priekaba turėtų turėti priežiūros istoriją, kuri rodo:

• priekabos tapatybę, paprastai flotilės numerį ir registraciją, jei taikoma
• priekabai nustatytą saugos patikros intervalą
• planuojamas patikros datas
• tikras patikros datas
• patikros ataskaitą
• bet kokius rastus defektus
• kokie veiksmai buvo atlikti
• kada defektai buvo pašalinti
• kas patikrino priekabą
• kas pasirašė darbą
• bet kokius laikotarpius, kai priekaba buvo VOR
• palaikančius dokumentus, tokius kaip stabdžių testų rezultatai, aptarnavimo lapai, sąskaitos faktūros ar nuotraukos, jei taikoma

Tai yra minimalus darbo įrašas. Jis turi būti organizuotas pagal priekabą, o ne išsklaidytas per el. pašto grandines, dirbtuvių užrašų knygas ir bendrus diskus.

Dažnumas yra kitas punktas. DVSA nenustato vieno patikros intervalo kiekvienai priekabai. Operatoriai turi nustatyti tinkamus saugos patikros intervalus, remdamiesi naudojimu, rida, apkrova, eksploatavimo sąlygomis, amžiumi ir gamintojo rekomendacijomis, o tada jų laikytis. Praktikoje transporto vadybininkams reikia programinės įrangos, leidžiančios nustatyti intervalus pagal priekabą arba pagal turto grupę, o tada įspėti juos gerokai prieš terminą. Jei norite atnaujinimo apie tai, kaip galvoti apie intervalus, mūsų gidas apie saugos patikros intervalų nustatymą apima operacinę pusę.

Defektai turi turėti savo darbo eigą. Priekabų patikros ataskaita neturėtų baigtis „defektas užfiksuotas“. Turite galėti parodyti, ar defektas buvo kritinis saugai, ar priekaba buvo nuimta nuo kelio, kokia remontas buvo atliktas ir kas leido grąžinti ją į eksploataciją. Jei priekaba turėjo būti VOR, įrašas turėtų tai aiškiai parodyti. Sistema, kuri saugo tik patikros lapą, be taisymo sekimo, palieka jums atlikti sunkų darbą rankiniu būdu.

Patvirtinimas taip pat yra svarbus. DVSA tikslais įrašo vertė yra galimybė parodyti, kas ką padarė ir kada. Tai reiškia, kad reikia nurodyti vartotojus, datos ir laiko žymes, ir aiškų skirtumą tarp patikros, remonto ir peržiūros. Įrašytas vardas skaičiuoklės ląstelėje yra silpnas įrodymas. Pasirašyta skaitmeninė patikra, susieta su priekaba, su vėlesnių redagavimų įrašu, yra daug stipresnė.

Dokumentų saugojimas dažnai yra pamirštamas. Operatoriai turi laikyti priežiūros įrašus, kad jie būtų prieinami patikrai ir greitai pateikiami. Transporto komisijos atveju klausimas retai būna, ar dokumentas egzistavo tam tikru momentu. Klausimas yra, ar galite pateikti pilną, patikimą bylą, kai to paprašoma. Mūsų straipsnis apie operatoriaus licencijos priežiūros įrašus nagrinėja įrašų rinkinį, kuris paprastai turi būti prieinamas.

Ten, kur JK pozicija skiriasi nuo platesnių ES prielaidų, tai daugiausia yra operatoriaus licencijos struktūroje ir įrodymų nagrinėjimo būde. Bendroji flotilės programa, sukurta kelioms šalims, gali pakankamai gerai tvarkyti aptarnavimo priminimus, tačiau vis tiek gali praleisti praktinius įrašų laikymo lūkesčius, susijusius su JK operatoriaus licencijavimu, DVSA susidūrimais ir Transporto komisijos patikra.

Kaip palyginti programinę įrangą, nepraleidžiant atitikties spragų

Palyginant sistemas, naudinga ignoruoti pagrindinio puslapio teiginius ir peržiūrėti įrašą nuo pradžios iki pabaigos. Jei priekaba turi būti patikrinta kitą antradienį, trečiadienį atsiranda defektas, ketvirtadienį ji remontuojama ir kitą mėnesį prašoma įrašų, ar programinė įranga gali palaikyti visą šį grandinę?

Pradėkite nuo planavimo. Sistema turėtų leisti jums:

• priskirti patikros intervalus pagal priekabą
• automatiškai suplanuoti būsimus patikrinimus
• peržiūrėti terminus pagal dieną, savaitę, mėnesį ar ISO savaitę
• aiškiai matyti praleistus patikrinimus
• gauti įspėjimus prieš praleidžiant datas
• perplanuoti su audito takeliu, kai operaciniai pokyčiai yra pagrįsti

Kalendorius vienas nėra pakankamas. Jums reikia plano įrodymo ir įvykdymo įrodymo.

Kitas, pažvelkite į pačią patikros formą. Priekabų patikroms reikia formų, kurios būtų naudojamos dirbtuvėse arba mobiliuosiuose įrenginiuose ir būtų pakankamai detalios, kad atspindėtų tikras patikros prekes. Geras sistema leidžia struktūrizuotą defektų fiksavimą, o ne tik laisvą tekstą. Ji taip pat turėtų palaikyti pridėtus įrodymus, tokius kaip stabdžių našumo rezultatai, padangų nuotraukos ar aptarnavimo dokumentai. Jei programinė įranga negali saugoti užpildyto patikros lapo kaip fiksuoto įrašo, ji neatlieka pagrindinio darbo.

Defektų darbo eiga yra ta vieta, kur silpnos sistemos atsiskleidžia. Užduokite šiuos klausimus:

• Ar defektai gali būti klasifikuojami pagal rimtumą?
• Ar priekaba gali būti pažymėta VOR?
• Ar taisymas gali būti priskirtas dirbtuvėms ar vartotojui?
• Ar galite užregistruoti remonto datą ir detales?
• Ar galite užkirsti kelią tyliai uždaryti neišspręstus defektus?
• Ar galite parodyti atvirus defektus ir praleistus remontus viename ekrane?

Tokia darbo eiga paverčia kontrolinį sąrašą į priežiūros įrašą.

Dokumentų saugojimas turi būti specifinis priekabai ir paieškos galimybė. Jūs turėtumėte galėti atidaryti vieną priekabos bylą ir matyti patikras, defektų ataskaitas, remonto įrodymus, metinių testų istoriją ir bet kokius susijusius dokumentus datų tvarka. Jei įrašai saugomi tik kaip bendri įkėlimai aplankuose, atgauti juos tampa lėtai ir klaidos įsiskverbia.

Audito takelis yra neginčijamas. Atitikties tikslais turėtų būti galima matyti:

• kas sukūrė įrašą
• kas jį redagavo
• kada buvo atlikti pakeitimai
• kokiame etape priekaba buvo
• ar patvirtinimas įvyko prieš ar po taisymo

Be to, negalite atskirti tikro šiuolaikinio įrašo nuo rekonstruoto.

Vartotojų leidimai yra svarbesni, nei daugelis operatorių tikisi. Dirbtuvės gali tekti užbaigti patikras ir remontus. Transporto biuras gali tekti peržiūrėti terminus ir rengti ataskaitas. Vairuotojams gali tekti tik defektų ataskaitų prieiga. Aukščiausio lygio vadovybė gali tekti tik skaityti. Sistema su vienu bendru prisijungimu arba plačiomis administratoriaus teisėmis visiems yra prasta kontrolė ir prasti įrodymai.

Ataskaitos yra paskutinis palyginimo taškas. Jūs turėtumėte galėti pateikti sąrašus:

• artėjančių priekabų patikrų
• praleistų patikrų
• nebaigtų defektų
• VOR priekabų
• užbaigtų patikrų pagal laikotarpį
• priekabų priežiūros istorijos pagal turtą

Jei jūsų dabartinis procesas DVSA vizitui būtų „duokite mums pusvalandį, kad surinktume dokumentus“, jūsų programinė įranga nedaro pakankamai. Mes išsamiau apžvelgiame šį standartą mūsų gide apie programinę įrangą, kuri palaiko jūsų O-licencijos bylą pasiruošusią.

Svarbiausios funkcijos priekaboms mišriose flotilėse

Priekabos dažnai yra tik viena atitikties paveikslo dalis. Krovinių vežėjas gali valdyti puspriekabes, traukinius, furgonus pagalbinėms užduotims ir galbūt keltuvų ar įrenginių įrašus šalia jų. Keleivių operatoriai gali turėti autobusus, mikroautobusus ir pagalbinius transporto priemones. Tokiose flotilėse naudingos programinės įrangos funkcijos yra tos, kurios sujungia susijusius turtus ir neleidžia įrašams fragmentuotis.

Pirmas yra turto sujungimas. Priekabos įrašas yra naudingesnis, kai jis gali būti susietas su vienetu, kuris ją tempė, depu, kuriame ji buvo, dirbtuvėmis, kurios ją tikrino, ir defektų ataskaitomis, pateiktomis prieš ją. Tai suteikia kontekstą, kai peržiūrite pasikartojančias problemas. Jei ta pati priekaba rodo pasikartojančius stabdžių ar apšvietimo defektus po naudojimo tam tikrame kontrakte ar maršrute, sujungti įrašai padeda pastebėti modelį.

Antras yra bendros atitikties logika tarp turto tipų. Mišrios flotilės nenori vieno proceso priekaboms, kito sunkvežimiams ir trečiojo furgonams ar PSV įrašams. Jie nori vieno būdo planuoti patikras, saugoti pasirašytus lapus, valdyti defektus ir rengti ataskaitas, tuo pačiu išlaikydami teisingą įrašų tipą kiekvienam turtui. Tokia nuoseklumas sumažina administravimą ir palengvina mokymą.

Trečias yra terminų matomumas visoje operacijoje. Transporto vadybininkas nemano atskirų programinės įrangos silosų. Jiems reikia vieno vaizdo, rodančio artėjančias priekabų patikras, sunkvežimių MOT užsakymus, priekabų metinių testų datas, vairuotojų licencijų patikras, Driver CPC galiojimo pabaigą, DQC būseną ir tachografo problemas. Atskira priekabų priemonė gali atlikti savo darbą pakankamai gerai, tačiau vis tiek priverčia biurą išlaikyti atskirus sekiklius viskam kitam.

Mišrioms flotilėms metiniai testai yra geras pavyzdys. Priekaboms reikia savo metinio testavimo planavimo ir įrašų, o šios datos turi būti šalia transporto priemonių MOT ar metinių testų įsipareigojimų, priklausomai nuo flotilės. Jei valdote tiek krovinių, tiek keleivių operacijas, terminologija ir procesas skiriasi, tačiau administracinė našta yra ta pati. Mūsų gidas apie HGV ir priekabų metinių testų reikalavimus paaiškina JK poziciją.

Kita svarbi funkcija yra vaidmenų pagrindu sukurta prieiga pagal operaciją. Centrinė atitikties komanda gali reikėti matomumo visose depuose, tuo tarpu vietinės dirbtuvių darbuotojai turėtų matyti tik tuos turtus, kuriuos jie prižiūri. Didelėse flotilėse tai yra svarbu tiek pat, kiek pati patikros forma.

Integracija taip pat gali padėti, jei ji yra praktiška. REST API arba webhooks gali būti naudingi, kai operatoriai nori, kad priekabų įrašai būtų įtraukti į platesnį flotilės ar dirbtuvių procesą. Tačiau integracija turėtų būti nauda, o ne pagrindinių atitikties funkcijų pakaitalas. Nėra prasmės turėti poliruotus ryšius su kitomis sistemomis, jei pati patikros įrašas yra silpnas.

Kur paprastos programos ir skaičiuoklės dažnai nepavyksta

Daugelis operatorių pradeda nuo skaičiuoklių, bendrų kalendorių ar pagrindinių formų programų, nes jas greitai nustatyti. Problema nėra ta, kad jos niekada neveikia. Problema yra ta, kad jos paprastai nustoja veikti ten, kur įrodymų kokybė yra svarbi.

Pirmas silpnumas yra pasirašyti įrodymai. Skaičiuoklė gali išvardyti patikros datas, tačiau ji nesukuria pasirašyto patikros įrašo. Formų programa gali fiksuoti kontrolinį sąrašą, tačiau jei įrašas gali būti redaguojamas vėliau be matomo audito takelio, jis yra silpnas. Kai DVSA prašo pamatyti priežiūros įrodymus, operatoriai reikia daugiau nei datos ir žymės.

Antras silpnumas yra praleistos datos. Skaičiuoklės priklauso nuo to, kad kas nors tinkamai palaiko formules, filtrus ir sąlyginį formatavimą. Bendri kalendoriai priklauso nuo žmonių, kurie pastebi priminimus. Kai flotilės auga, priekabos juda tarp depų, arba intervalai keičiasi, paprasti įrankiai tampa trapūs. Vienas neteisingas rūšiavimas, viena perrašyta ląstelė arba vienas praleistas el. laiškas, ir planas nebeveikia patikimai.

Trečias silpnumas yra defektų uždarymas. Pagrindiniuose įrankiuose defektai dažnai registruojami vienoje vietoje, o remontai fiksuojami kitur. Tai sukuria spragas, tokias kaip:

• defektai be taisymo datos
• remontai be nuorodos atgal į patikrą
• aiškios VOR sprendimo nebuvimas
• jokio patvirtinimo grąžinti priekabą į eksploataciją

Tai yra būtent tos spragos, kurios sukelia nepatogius klausimus vėliau.

Ketvirtas silpnumas yra ataskaitos. Transporto vadybininkas turėtų greitai galėti atsakyti į akivaizdžius klausimus. Kurios priekabos yra praleistos patikros? Kurios turi atvirų saugos defektų? Kurios patikros buvo užbaigtos vėlai praėjusį mėnesį? Kurios priekabos turi pasikartojančių stabdžių problemų? Skaičiuoklės gali atsakyti į kai kuriuos iš šių klausimų, jei jos yra puikiai palaikomos, tačiau jos yra lėtos pasitikėti ir lėtos pateikti.

Penkta silpnumas yra bylos paruošimas. Transporto komisijos paruošimas nėra apie tai, kad duomenys egzistuoja kažkur versle. Tai apie galimybę pateikti organizuotą, patikimą įrašų rinkinį be skubėjimo. Jei jūsų priekabų įrašai gyvena iš dalies skaičiuoklėje, iš dalies nuskenuotose PDF, iš dalies dirbtuvių popieriniuose failuose ir iš dalies el. pašte, jūs neturite bylos paruoštos sistemos.

Paprastos programos taip pat dažnai ignoruoja aplinkinius atitikties įrašus. Priekabų patikros yra tik viena grandis. Operatoriai vis dar turi MOT ir metinių testų datas, vairuotojų įrašus, tachografo įrodymus ir licencijų patikras. Pagrindiniai įrankiai retai sujungia tai taip, kad palaikytų tinkamą operatoriaus licencijos bylą.

Kai operatoriaus licencijos platforma yra geresnis pasirinkimas

Atskirai priekabų patikros įrankis gali būti pakankamas, jei priekabos yra jūsų vienintelis rūpestis ir viskas kitas jau yra kontroliuojama kitur. Praktikoje tai yra neįprasta. Dauguma operatorių, ieškančių priekabų patikros įrašų programinės įrangos JK, taip pat bando kontroliuoti platesnius operatoriaus licencijos įsipareigojimus tuo pačiu metu.

Čia operatoriaus licencijos platforma paprastai yra geresnis pasirinkimas. Vietoj to, kad priekabų patikras laikytų kaip izoliuotą darbo eigą, ji laiko priekabų, transporto priemonių ir vairuotojų atitiktį vienoje vietoje. Transporto vadybininkams tai reiškia mažiau paralelinių sekiklių ir išsamesnį rizikos vaizdą.

Operator Compliance mes sukūrėme sistemą aplink tai, kaip JK operatoriai iš tikrųjų turi pateikti įrašus. Fleeta Limited valdo sunkvežimius pagal operatoriaus licenciją, todėl produktas buvo formuojamas pagal praktinius lūkesčius DVSA Gido dėl Kelių Tinkamumo Išlaikymo, o ne pagal bendrą pasaulinę flotilės šabloną.

Tai svarbu, jei jums reikia vienos sistemos valdyti:

• priekabų saugos patikras ir defektų įrašus
• sunkvežimių, furgonų, autobusų ar mikroautobusų patikros tvarkaraščius
• MOT ir metinių testų datas
• vairuotojų licencijų patikras su DVLA duomenimis, jei taikoma
• Driver CPC ir DQC galiojimo pabaigos stebėjimą
• tachografo analizę ir susijusius įrodymus
• mėnesinius flotilės paketus ir valdymo ataskaitas
• įrašus, paruoštus pateikti DVSA arba Transporto komisijai

Daugeliui operatorių tikroji nauda nėra viena konkreti funkcija. Tai yra dubliavimosi pašalinimas. Jei priekaba pridedama vieną kartą, priskiriama tinkamam veikimo centrui, suplanuojama patikroms, sujungiama su defektais ir įtraukta į ataskaitas be to paties detalių įvedimo į kelias sistemas, administravimas sumažėja, o įrašų kokybė pagerėja.

Platesnė atitikties programinė įranga taip pat suteikia jums vieną audito takelį visoje operatoriaus licencijos byloje. Tai yra daug naudingiau nei turėti vieną programą priekaboms, kitą vairuotojų dokumentams ir skaičiuoklę testų datoms. Jei peržiūrite pasirinkimus, mūsų straipsnis apie kuri atitikties programinė įranga geriausiai palaiko jūsų Transporto komisijos bylą nurodo, į ką atkreipti dėmesį.

Taip pat yra praktiniai apribojimai atskiroms priemonėms, kai platesnė flotilės operacija tampa labiau sujungta. Operatoriai gali norėti nuorodų į draudimo patikras per askMID, kurią valdo Motor Insurers' Bureau, dar žinomas kaip MIB, arba srautus į susijusias sistemas, tokias kaip Fleetalyse arba Logivo.AI. Šios nuorodos gali būti naudingos, tačiau pagrindinė mintis išlieka ta pati. Pagrindiniai operatoriaus licencijos įrašai pirmiausia turi būti pilni ir gynybingi.

Jei dabar lyginate programinę įrangą, vertinkite ją pagal bylą, kurią turėtumėte pateikti rytoj. Atidarykite vieną priekabą ir paklauskite, ar galite matyti kiekvieną patikros terminą, kiekvieną užpildytą lapą, kiekvieną defektą, kiekvieną remontą, kiekvieną patvirtinimą ir kiekvieną susijusį terminą be ieškojimo. Jei ne, tęskite paiešką.

Tai yra standartas, kurio laikomės OperatorCompliance. Priekabų įrašai neturėtų būti už operatoriaus licencijos bylos ribų. Jie turėtų būti jos dalis, pilni, pasirašyti, atsekami ir paruošti, kai DVSA prašo.