Programinės įrangos pasirinkimas defektų ir priežiūros įrašams DVSA

Jei renkatės programinę įrangą DVSA tikslams, nesustokite ties defektų pranešimo programa. Transporto vadybininkui svarbu, ar sistema gali turėti visus, gynybinius, priežiūros įrašus kiekvienam transporto priemonių ir priekabų, parodyti, kas ir kada atliko darbus, ir greitai pateikti pasirašytus įrodymus, jei to prašo DVSA arba Transporto komisaras.

Štai kodėl patariame operatoriams vertinti programinę įrangą pagal visą operatoriaus licencijos įrašą, o ne tik pagal kasdienius apžiūros patikrinimus. Geras sistema turėtų susieti defektus, inspekcijas, taisymus, MOT ar metinius testų datas, VOR laikotarpius, palaikančius dokumentus ir vairuotojo ar meistro patvirtinimus į vieną istoriją. Jei ji vis dar verčia jus laikyti terminus skaičiuoklėse arba persekioti dokumentus el. paštu, ji netinkamai atlieka atitikties darbą.

Ką JK operatoriai turi iš defektų ir priežiūros įrašų

JK prekių ir keleivių operatoriams defektų registravimas yra tik viena dalis įrašo, kurį reikia išlaikyti. DVSA tikisi aiškios priežiūros sistemos, o Kelių tinkamumo išlaikymo vadovas yra praktinis standartas, kuriuo remiasi daugelis transporto vadybininkų. Jei programinė įranga negali palaikyti šio standarto, ji susidurs su sunkumais, kai jūsų sistemos bus peržiūrimos.

Minimali operatoriai paprastai turi išlaikyti įrašus apie transporto priemones ir priekabas, apimančius:

• kasdienius apžiūros patikrinimus ir praneštus defektus
• nulinio defekto pranešimus, kai tai naudojama jūsų procese
• saugos inspekcijų datas ir užpildytus inspekcijų ataskaitas
• prevencinės priežiūros inspekcijų lapus
• remonto ir taisymo darbus
• stabdžių testų įrašus, jei tai taikoma jūsų priežiūros režimui
• MOT ir metinių testų datas ir rezultatus
• odometro rodmenis arba naudojimo matavimus, naudojamus planuojant inspekcijas
• transporto priemonės stovėjimo laikotarpius, įskaitant VOR statusą
• palaikančius dokumentus, tokius kaip dirbtuvės sąskaitos, paslaugų lapai, testavimo sertifikatai ir nuotraukos
• atsakingo asmens peržiūros ir patvirtinimo įrodymus

Priekaboms taikoma ta pati taisyklė. Priekaba turi savo inspekcijų ir remonto istoriją ir neturėtų dingti į pastabų lauką traktoriaus įraše. Jei valdote mišrius turtus, programinė įranga turi traktuoti priekabas kaip pirmo lygio įrašus, su atskiromis tvarkaraščiais, defektais ir dokumentais.

Dėl furgonų operatoriaus licencijos pozicija priklauso nuo naudojimo atvejo ir svorio, o kai kurie skaitytojai gali būti už HGV operatoriaus licencijos režimo ribų. Net ir tada, tinkamų priežiūros įrašų išlaikymas vis dar yra praktinis standartas kelių tinkamumui ir rūpinimosi pareigoms. Taksi ir privačių nuomos parkai taip pat turi vietos valdžios reikalavimus kartu su įprastiniais transporto priemonių įrašais. Programinė įranga turėtų atspindėti parką, kurį iš tikrųjų valdote, o ne priversti kiekvieną turtą į HGV tik šabloną.

Priežastis, kodėl defektų programinė įranga viena pati nėra pakankama, yra paprasta. Kasdienis defektų pranešimas pasako, kas buvo rasta vieną dieną. Tai savaime neįrodo, kad remontas buvo tinkamai įvertintas, atliktas laiku, patvirtintas tinkamo asmens ir susietas su transporto priemonės planuotos priežiūros istorija. Kai DVSA žiūri į jūsų sistemas, klausimas retai būna tik „Ar vairuotojai gali pranešti apie defektus?“ Dažniau tai būna „Ar galite parodyti visą priežiūros seką?“

Ta seką turėtų leisti mums atidaryti vieną transporto priemonės ar priekabos įrašą ir aiškiai matyti seką. Inspekcijos data nustatyta. Inspekcija atlikta. Defektas praneštas. Taisymas pradėtas. Dalys sumontuotos. Transporto priemonė pažymėta VOR, jei reikia. Grįžimas į paslaugą patvirtintas. MOT arba metinis testas užsakyti ir išlaikyti. Dokumentai pridėti. Nieko trūksta, nieko negyvena atskiroje skaičiuoklėje.

Čia tinkama defektų ir priežiūros istorijos programinė įranga užima savo vietą. Ji neturėtų tik fiksuoti įvykius, ji turėtų išlaikyti ryšį tarp jų. Tai, kas daro įrašą naudingą atitikties, dirbtuvių kontrolės ir vidaus peržiūros tikslais.

Jei norite praktinio kontrolinio sąrašo įrašų, kuriuos operatoriai turi išlaikyti, mūsų vadovas apie operatoriaus licencijos priežiūros įrašus išdėsto pagrindinius dokumentus ir kodėl jie svarbūs.

Kaip palyginti audito taką ir pasirašytus įrodymus

Palyginant sistemas, audito takas yra toks pat svarbus kaip ir forma pati. Tvarkingas PDF nėra pakankamas, jei niekas negali parodyti, kada jis buvo sukurtas, kas jį pakeitė ir ar defektas buvo tinkamai uždarytas.

Siūlome patikrinti šiuos punktus bet kuriame trumpame sąraše:

• data ir laiko žymės kiekvienam pateikimui, redagavimui ir patvirtinimui
• vardiniai naudotojų įrašai, o ne bendri prisijungimai, dalijami visame depote
• matoma pakeitimų istorija, ypač jei defekto sunkumas ar užbaigimo data yra pakeista
• aiškus atskyrimas tarp asmens, pranešančio apie defektą, ir asmens, patvirtinančio grįžimą į paslaugą
• nuotraukų, sąskaitų, sertifikatų ir dirbtuvės lapų saugojimas pagal atitinkamą turtą ir įvykį
• galimybė parodyti atvirus defektus, praleistas taisymo ir praleistas inspekcijas, neeksportuojant duomenų pirmiausia
• pasirašyti įrodymai iš vairuotojų, meistrų, dirbtuvių darbuotojų ar transporto vadybininkų, jei jūsų procesas to reikalauja

Pagrindinis dalykas yra įrodymų kokybė. Jei DVSA atvyksta arba Transporto komisaras prašo įrašų, turite pateikti dokumentus, kurie turi prasmę išoriniam vertintojui. Tai reiškia, kad ataskaita turėtų rodyti daugiau nei darbų sąrašą. Ji turėtų rodyti laiką.

Pavyzdžiui, jei vairuotojas praneša apie padangos defektą 06:15, sistema turėtų rodyti pranešimo laiką, transporto priemonę, defekto kategoriją, bet kokį pridėtą vaizdą, atliktą veiksmą, ar transporto priemonė buvo pažymėta VOR, kas ją peržiūrėjo, koks remontas buvo atliktas, kas jį atliko ir kas patvirtino grįžimą į paslaugą. Jei defektas buvo įvertintas kaip saugus atidėti, įrašas turėtų rodyti tą sprendimą ir jo pagrindą, o ne tiesiog palikti elementą pažymėtą „padaryta“.

Pasirašyti įrodymai taip pat yra platesni nei skaitmeninė parašo dėžutė. Praktikoje operatoriai dažnai reikia įrašo, kad vairuotojas atliko apžiūros patikrinimą, meistras atliko taisymą, o transporto vadybininkas peržiūrėjo išimtis ar praleistus elementus. Programinė įranga turėtų palaikyti tą grandinę. Jei ji tik fiksuoja pirmąjį pranešimą ir palieka likusius popieriuje, audito takas nutrūksta.

Dokumentų saugojimas yra dar viena dažna silpna vieta. Paklauskite, ar dokumentai saugomi pagal transporto priemonę, priekabą, individualų defektą ar inspekcijos įvykį, ar visus tris, kai tai taikoma. Jei stabdžių testų lapas yra įkeltas, ar galite jį rasti vėliau iš inspekcijos įrašo? Jei MOT sertifikatas yra saugomas, ar galite jį ištraukti iš transporto priemonės laiko juostos iš karto? Jei ne, žmonės pradės saugoti failus kitur.

Taip pat patikrinkite, kas atsitinka, kai įrašai yra taisomi. Atitikties darbe redagavimai yra normalūs, tačiau tylus perrašymas yra problema. Norime matyti, kas pakeitė įrašą, kada jie jį pakeitė ir koks buvo ankstesnis statusas. Tai yra skirtumas tarp audito tako ir duomenų bazės, kuri tiesiog rodo naujausią versiją.

Operatoriams, kurie rengia mėnesinius peržiūros paketus, programinė įranga taip pat turėtų palengvinti įrodymų surinkimą valdymo patikrinimams. Mūsų straipsnis apie mėnesinio parko paketo pasirinkimą, kuris atlaiko DVSA paaiškina, ką tie peržiūros paketai turėtų apimti ir kaip programinė įranga gali sumažinti rankinį darbą.

Ar ji gali valdyti inspekcijas, MOT ir metinių testų terminus?

Sistema, kuri registruoja istoriją, bet negali kontroliuoti būsimų terminų, atlieka tik pusę darbo. Transporto vadybininkams reikia programinės įrangos, kuri planuoja inspekcijas į priekį, žymi, kas artėja, ir rodo, kas buvo praleista ar perkelta.

Pradėkite nuo saugos inspekcijų intervalų. Programinė įranga turėtų leisti nustatyti inspekcijų dažnumą pagal transporto priemonę ar priekabą, remiantis jūsų priežiūros režimu, o tada tinkamai apskaičiuoti būsimus datas. Kai kurie operatoriai planuoja pagal kalendoriaus datą, kai kurie pagal naudojimą, o kai kurie reikia abiejų. Jei jūsų inspekcijos valdomos pagal ISO savaitę, sistema turėtų tai tvarkyti be rankinių sprendimų.

Ilgalaikis planavimas yra svarbus, nes dirbtuvių ir testavimo pajėgumai niekada nėra neriboti. Turime matyti artėjančias inspekcijas ir testų datas pakankamai anksti, kad galėtume jas užsakyti, perkelti turtą ir išvengti susikaupimo. Pagrindinis priminimas, išsiųstas kelias dienas prieš terminą, nėra pakankamas, jei parkas turi būti suplanuotas savaites į priekį.

Ieškokite:

• pakartotinių inspekcijų tvarkaraščių transporto priemonėms ir priekaboms
• būsimų dienoraščių peržiūrų pagal datą, depotą ar turto tipą
• įspėjimų apie artėjančias inspekcijas, MOT ir metinių testų terminus
• praleistų įvykių ir praleistų veiksmų matomumo
• galimybės registruoti perkeltus datas su priežastimi
• ataskaitų, rodančių suplanuotą ir atliktą priežiūrą

Praleistų įvykių tvarkymas yra ypač svarbus. Tikroje veikloje inspekcijos kartais perkeliamos, nes transporto priemonė yra toli, remontuojama, parduodama, ne kelyje arba nepasiekiama. Programinė įranga turėtų fiksuoti tą išimtį ir išlaikyti istoriją. Ji neturėtų tiesiog pakeisti senos datos ir apsimesti, kad pirmoji niekada neegzistavo.

MOT ir metinių testų datos reikalauja to paties disciplinos. HGV ir PSV JK metiniai testai yra atskiras atitikties įvykis ir turėtų būti sekami kaip toks. Programinė įranga, sukurta bendram parko priežiūrai, kartais mano, kad kiekvienas turtas turi tik MOT sukaktį. Tai nepakanka operatoriams, kurie turi parodyti metinių testų planavimą ir rezultatus reguliuojamoms transporto priemonėms. Kur teisės pozicija skiriasi tarp transporto priemonių klasių, sistema turėtų sugebėti tvarkyti abi be priverstinio vieno taisyklės taikymo visiems turtams.

Čia taip pat kyla problemų dėl atskirų skaičiuoklių. Kai inspekcijų datos yra vienoje sistemoje, metinių testų datos kitoje, o priminimai kažkieno kalendoriuje, nėra vieno tiesos šaltinio. Tai tampa sunkiau įrodyti kontrolę ir lengviau praleisti terminą, kai darbuotojai keičiasi arba depas užimtas.

Mes sukūrėme Operator Compliance aplink vieną tvarkaraštį vienam parko įrašui, nes taip iš tikrųjų dirba transporto vadybininkai. Jei vis dar pasikliaujate el. paštu ir skaičiuoklėmis, kad pasivytumėte terminus, mūsų vadovas apie programinę įrangą, kuri žymi atitikties terminus el. paštu yra naudingas kitas žingsnis.

Kaip defektų pranešimas turėtų būti susietas su priežiūros istorija

Geriausias būdas palyginti sistemas yra sekti vieną defektą nuo pradžios iki pabaigos ir paklausti, kur kiekviena įrašo dalis gyvena.

Vairuotojas atlieka apžiūros patikrinimą. Defektas randamas. Transporto priemonė gali būti sustabdyta, arba problema gali būti įvertinta vėlesniam taisymui. Dirbtuvės atlieka darbus. Dalys gali būti sumontuotos. Laikas be kelio gali prireikti užregistruoti. Transporto priemonė tada grąžinama į paslaugą patvirtinto asmens. Jei šie žingsniai yra skirtingose sistemose, arba kai kurie visai nėra registruojami, priežiūros istorija yra nebaigta.

Štai kodėl kasdienis pranešimas turėtų tiesiogiai patekti į transporto priemonės ir priekabos įrašą. Turėtume galėti atidaryti turto istoriją ir matyti:

• pradinį defektų pranešimą
• vaizdus ar pastabas, pateiktas vairuotojo
• ar defektas paveikė kelių tinkamumą
• ar turtas buvo pažymėtas VOR
• dirbtuvių diagnozė ir atlikti veiksmai
• sumontuotos dalys arba išorinių remonto detalių
• neveikimo laikas ir grįžimo į paslaugą laikas
• atsakingo asmens patvirtinimas
• bet koks ryšys su kitomis inspekcijomis, paslaugomis ar testų įvykiais

Tas sujungtas įrašas padeda trimis būdais.

Pirmiausia, tai pagerina sprendimų priėmimą. Jei transporto priemonė turi pakartotinius padangų, apšvietimo ar stabdžių susijusius defektus, modelis yra matomas. Transporto vadybininkas gali iššūkį inspekcijos kokybei, dirbtuvių standartams ar vairuotojų pranešimo įpročiams, kol problema netampa klausimu.

Antra, tai pagerina įrodymų kokybę. Jei DVSA klausia, kas įvyko po to, kai buvo pranešta apie defektą, atsakymas yra toje pačioje istorijoje. Nereikia atsiimti vienos ataskaitos iš vairuotojo programėlės, kitos iš dirbtuvių sistemos ir trečios iš bendro disko.

Trečia, tai pagerina operatyvinę kontrolę. VOR laikas gali būti matomas prieš priežiūros įvykius, kas padeda mums suprasti ne tik atitiktį, bet ir prieinamumą. Atskiri defektų įrankiai dažnai baigiasi ties „pranešta“ ir „uždaryta“. Tai praleidžia tikrą operatyvinį vaizdą.

Parkams, kurie nori sustiprinti proceso pradžią, mūsų vadovas apie vairuotojų apžiūros patikrinimus ir defektų pranešimą apima, kaip turėtų atrodyti naudojama pranešimo darbo eiga kasdienėje veikloje.

Peržiūrint programinę įrangą, užduokite praktinius klausimus. Ar defektas gali automatiškai pasirodyti turto laiko juostoje? Ar dirbtuvių darbas gali būti susietas su pradiniu pranešimu? Ar priekabos defektas gali būti sekamas nepriklausomai nuo vieneto? Ar grįžimo į paslaugą sprendimas gali būti užregistruotas vardiniu naudotoju? Jei atsakymas neigiamas, vis tiek susiūsite priežiūros istoriją rankomis.

Kai platesnė atitikties platforma yra geresnis pasirinkimas

Kai kurie operatoriai tik reikia paprastos defektų proceso mažam skaičiui turtų. Tačiau daugelis atranda, kad atskira defektų programinė įranga yra per siaura, kai jie pažvelgia į visą operatoriaus licencijos darbo krūvį.

Transporto vadybininkas ne tik valdo defektus. Ši rolė paprastai apima transporto priemonių ir priekabų tvarkaraščius, MOT ir metinių testų datas, vairuotojų licencijų patikrinimus, Driver CPC galiojimo laiką, DQC galiojimą, tachografo analizę, draudimo dokumentus ir vidaus peržiūros įrodymus. Jei šie įrašai yra atskiruose įrankiuose, atitikties našta pereina iš popieriaus į sistemos administravimą.

Tai paprastai yra ta vieta, kur platesnė platforma yra geresnis pasirinkimas.

Platesnė atitikties sistema turėtų leisti mums valdyti, vienoje vietoje:

• transporto priemones ir priekabas
• inspekcijas ir priežiūros istoriją
• defektų pranešimus ir taisymus
• MOT ir metinių testų terminus
• vairuotojų įrašus ir dokumentų galiojimą
• Driver CPC ir DQC statusą
• tachografo analizę ir pažeidimų sekimą
• dokumento saugojimą ir peržiūros paketus
• įspėjimus apie artėjančius ir praleistus veiksmus

Tai svarbu tiek mažiems operatoriams, tiek didesniems. Savininko vairuotojas gali neturėti biuro komandos, kad suderintų keturias sistemas. Autobusų ar mikroautobusų operatorius gali reikėti stipresnės kontrolės tarp vairuotojų ir transporto priemonių kartu. Kurjerių ar furgonų parkas gali rūpintis tiek licencijų patikrinimais, tiek dokumentų galiojimu, tiek dirbtuvių įrašais. Taksi ir privačių nuomos parkai dažnai reikia vienos vietos tiek transporto priemonių, tiek vairuotojų įrodymams. Teisingas atsakymas priklauso nuo jūsų iš tikrųjų turimų įsipareigojimų.

Taip pat kyla praktinis integracijos klausimas. Jei jau naudojate kitas sistemas, paklauskite, ar programinė įranga siūlo REST API arba webhooks, ir kas iš tikrųjų gali būti keičiamasi. Atitikties platforma neturėtų teigti integracijos tik todėl, kad gali eksportuoti CSV failus. Jei jums reikia duomenų iš askMID, Motor Insurers' Bureau, MIB, DVLA ar kitų trečiųjų šalių darbo srautų, būkite aiškūs, kas yra natūralu, kas yra rankinis ir kas priklauso nuo išorinių paslaugų.

JK pozicija taip pat yra svarbi. Kai kurie programinės įrangos produktai yra sukurti platesniam ES parko naudojimui ir nesutampa su JK operatoriaus licencijos praktika. Jie gali būti tinkami bendriems paslaugų priminimams, tačiau silpnesni metinių testų kontrolei, Transporto komisaro įrodymams ar tam, kaip JK transporto vadybininkai struktūrizuoja savo įrašus. Tai viena iš priežasčių, kodėl sukūrėme OperatorCompliance aplink tai, kaip JK operatoriai iš tikrųjų ruošiasi DVSA patikrinimams.

Kadangi mes esame Fleeta Limited ir patys valdome sunkvežimius pagal operatoriaus licenciją, sukūrėme Operator Compliance aplink įrašus ir peržiūros taškus, kuriuos žinome, kad transporto vadybininkai turi pateikti, o ne aplink bendrą parko informacijos suvestinę. Tai reiškia vieną sistemą priežiūros istorijai, terminams, vairuotojų įrašams ir tachografo įrodymams, o ne defektų įrankį vienoje pusėje ir skaičiuoklių patchwork kitame.

Jei lyginate produktus, tokius kaip Fleetalyse, Logivo.AI ar bet kurią kitą platformą, laikykite testą paprastą. Paklauskite, ar sistema leistų jums patenkinti DVSA susitikimą ar Transporto komisaro prašymą, nesurinkus įrodymų iš trijų vietų. Jei ne, tai gali būti naudinga programa, tačiau tai dar nėra jūsų atitikties sistema.

Tinkama programinė įranga DVSA tikslams yra ta, kuri suteikia mums visą, datuotą, pasirašytą ir peržiūrimą įrašą, kaip kiekviena transporto priemonė, priekaba ir vairuotojas buvo valdomi. Tai yra standartas, pagal kurį reikia pirkti. Ne tik ar defektas gali būti praneštas, bet ar visa atitikties istorija išlaiko, kai kas nors prašo ją pamatyti.