Transporto priminimo programinė įranga, kuri stebi MOT ir metinius

Kai operatoriai ieško metinių testų ir MOT priminimo programinės įrangos transporto priemonėms, jie paprastai pradeda nuo vienos skubios problemos. Jie nenori praleisti testų datos. Praktikoje tai yra tik dalis darbo. Tinkama sistema taip pat turi rodyti, kas buvo numatyta, kas žinojo, kokių veiksmų buvo imtasi, kokie įrodymai buvo išsaugoti ir kaip tai dera su likusia operatoriaus licencijos byla.

Štai kodėl mes laikome priminimus kaip atitikties procesą, o ne tik dienoraščio pranešimą. JK prekių ir keleivių transporto priemonėms MOT ir metinių testų kontrolė yra šalia patikrinimų, defektų, tachografų įrašų, vairuotojų patikrinimų ir dokumentų, kuriuos gali tekti pateikti Transporto komisijos nariui. Jei programinė įranga negali palaikyti šio platesnio vaizdo, ji išspręs tik pusę problemos.

Ką operatoriai iš tikrųjų reikia iš priminimo programinės įrangos

Pagrindinė priminimo priemonė praneša, kad artėja data. Atitikties orientuota sistema padeda valdyti darbą, kuris slypi už tos datos.

JK transporto priemonių parkui ši skirtumas yra svarbus, nes MOT ir metinių testų įsipareigojimai nėra visi vienodi. Lengvosios transporto priemonės gali reikalauti MOT. HGV, PSV ir daugelis priekabų yra valdomi pagal metinių testų reikalavimus. Terminologija yra svarbi, tačiau praktinė pusė yra dar svarbesnė. Operatoriai dažnai valdo mišrius parkus, kuriuose yra furgonai, HGV vienetai, priekabos, mikroautobusai ar autobusai vienoje įmonėje. Priminti sistema turi aiškiai tvarkyti visus juos, nesukeldama transporto vadybininkams poreikio naudoti atskirus skaičiuokles ar atskirus kalendorius.

Tinkama sistema turėtų leisti mums užregistruoti kiekvieną turtą su teisingais identifikavimo duomenimis, registracija, parko numeriu, transporto priemonės tipu, plokštelės duomenimis, kai tai aktualu, ir kitą numatytą datą. Ji taip pat turėtų atspindėti, kaip parkai iš tikrųjų veikia. Kai kurios transporto priemonės yra naudojamos kiekvieną dieną. Kai kurios yra sezoninės. Kai kurios yra VOR. Kai kurios yra nuomojamos arba ne kelyje tam tikrą laiką. Priminti, kuris skamba be konteksto, sukuria triukšmą. Atitikties orientuotas pranešimas turėtų vis tiek išlaikyti datą matomą, tačiau jis taip pat turėtų rodyti statusą ir atsakomybę.

Kitas skirtumas yra įrodymai. Jei po praleisto testo mes esame iššūkiai, arba auditorijoje paklausiama, kaip mes kontroliuojame metinių testų datas, nepakanka pasakyti, kad egzistavo kalendoriaus priminimas. Mes turime parodyti įrašus. Tai reiškia, kad sistema turėtų išlaikyti numatytą datą, užsakymo datą, palaikančius dokumentus, rezultatą ir bet kokius sekimo veiksmus. Jei testas buvo perkeliamas, turėtų būti priežastis. Jei transporto priemonė buvo paimta VOR laukdama remonto, tai taip pat turėtų būti matoma.

Čia metinių testų ir MOT priminimo programinė įranga transporto priemonėms turi būti vertinama kitaip nei bendroji užduočių priemonė. Transporto vadybininkas ne tik nustato asmeninius priminimus. Jie kontroliuoja reguliuojamus terminus per kelis turtus, vartotojus ir depus, su operatoriaus licencijos pareiga už jų.

Norėdami išsamiau pažvelgti į praktinius aspektus, kuriuos verta patikrinti, žr. mūsų gidą apie transporto priminimo sistemos pasirinkimą, kuri užtikrina testų laiką.

Kokios funkcijos yra svarbiausios, lyginant sistemas

Lyginant sistemas, siūlome pradėti nuo operacinių klausimų, o ne programinės įrangos žargono.

Pirmiausia, kaip datos yra sukuriamos ir palaikomos? Kai kurios sistemos remiasi tik rankiniu įvedimu. Tai gali būti įmanoma labai mažam parkui, tačiau tai sukuria riziką, kai parkas auga. Mes turime galėti greitai įvesti datas, peržiūrėti jas vienoje vietoje ir atnaujinti jas, neprarandant ankstesnio įrašo. Jei sistema gali palaikyti pasikartojančius darbo procesus aplink testus, patikrinimus ir atnaujinimus, tai sumažina dubliuojančią administraciją.

Antra, kiek matomos artėjančios terminai? Naudinga sistema turėtų rodyti, kas yra numatyta pagal dieną, savaitę ir mėnesį, ir ji turėtų palaikyti planavimą pagal ISO savaitę, kur transporto operacijos naudoja šį formatą. Turėtų būti lengva filtruoti pagal depą, parko tipą, vartotoją ar numatytą laikotarpį. Transporto vadybininkas turėtų galėti greitai atsakyti į paprastus klausimus. Kurios priekabos numatytos per artimiausias šešias savaites? Kurios transporto priemonės užsakytos, bet dar neįrodytos? Kurie turtai neturi patvirtintos datos po nesėkmės?

Trečia, kokie įrodymai gali būti pridėti? Bent jau tikimės palaikymo saugant testų susijusius dokumentus ir pastabas prieš transporto priemonės ar priekabos įrašą. Realiame naudojime tai gali apimti užsakymo patvirtinimus, testų sertifikatus, draudimo susirašinėjimą, remonto įrašus ir vidinį patvirtinimą. Priminti be pridėtų įrodymų vis tiek palieka popierinį medžiagą kitur.

Ketvirta, kokia audito takas egzistuoja? Tai yra viena didžiausių spragų lengvesnėse sistemose. Mes turime žinoti, kas pridėjo datą, kas ją pakeitė, kada buvo išduoti pranešimai ir kas užbaigė užduotį. Jei įrašai redaguojami be istorijos, mes prarandame pasitikėjimą byla. Tinkamas audito takas yra svarbus tiek vidiniam valdymui, tiek išoriniam patikrinimui.

Penkta, kaip tvarkomas vartotojų prieiga? Ne kiekvienas vartotojas turėtų galėti keisti pagrindines atitikties datas. Dirbtuvės darbuotojai gali prireikti įkelti įrodymus. Administracijos darbuotojai gali prireikti užsakyti testus. Transporto vadybininkas gali prireikti visiško matomumo ir patvirtinimo teisių. Prieiga pagal vaidmenis nėra prabanga. Tai yra dalis, kad įrašas būtų patikimas.

Šešta, kokie ataskaitos yra prieinamos? Operatoriai reikia skirtingų vaizdų. Kai kurie nori išimčių ataskaitos apie pradelstas prekes. Kai kurie nori ateities planuotojo. Kai kurie nori pilno turto istorijos. Ataskaitos turėtų būti naudojamos kasdienėje veikloje, o ne tik eksportuojamos, kad liktų neskaitytos. El. pašto pranešimai gali padėti, tačiau informacinė lenta, kuri suteikia aiškų gyvą vaizdą, paprastai yra vertingesnė.

Septinta, ar sistema gali tinkamai tvarkyti mišrius parkus? Daugelis operatorių reikia vienos vietos furgonams, HGV, priekaboms, autobusams, mikroautobusams ar privačiai nuomojamoms transporto priemonėms. Testų ciklai, terminologija ir įrašai gali skirtis. Programinė įranga neturėtų visko priversti į vieną grubų šabloną.

Galiausiai, paklauskite, kaip sistema dera su likusia jūsų operacija. Jei priminimai yra izoliuoti, vartotojai galiausiai turės perrašyti informaciją į defektų sistemas, patikrinimų planuotojus ir vairuotojų bylas. Mes teikiame pirmenybę sujungtiems įrašams, o ten, kur verslams reikia platesnio ryšio, techninės galimybės, tokios kaip REST API ir webhooks, gali būti svarbios.

Kaip priminimo programinė įranga atitinka operatoriaus licencijos atitiktį

MOT ir metinių testų datos yra svarbios pačios savaime, tačiau jos taip pat yra platesnio operatoriaus licencijos kontrolės sistemos dalis.

Pagal DVSA požiūrį į kelių tinkamumą, testų atitiktis yra susijusi su prevencine priežiūra, saugos patikrinimais, defektų pranešimu ir taisymu. Jei transporto priemonė nuolat atvyksta į metinį testą su išvengiamais gedimais, tai rodo kažką apie priežiūros kontrolę. Jei priekaba neturi aiškios patikrinimo istorijos prieš testą, tai silpnina bylą. Todėl priminimo programinė įranga turėtų būti šalia patikrinimų planavimo ir įrašų laikymo, o ne atskirai nuo to.

Tas pats taikoma vairuotojams. Atitinkama operacija ne tik stebi transporto priemones ir priekabas. Ji taip pat seka vairuotojų licencijų patikrinimus su DVLA, Driver CPC terminus, DQC galiojimo laiką, tachografų analizę ir defektų pranešimą. Kai šie įrašai yra fragmentuoti, transporto vadybininkai praleidžia laiką derindami sistemas, o ne valdydami riziką.

Tai taip pat aktualu, kai ruošiamasi auditui ar viešajai apklausai. Transporto komisijos narys nežiūrės į praleistą metinį testą izoliuotai, jei platesnė byla yra silpna. Jie gali norėti pamatyti priežiūros įrašus, PMI tvarkaraščius, defektų taisymo įrodymus, licencijų patikrinimo kontrolę ir tachografų valdymą. Priminti sistema, kuri prisideda prie pasirašytų, datuotų įrašų, yra naudingesnė nei ta, kuri tiesiog siunčia el. laiškus.

Daugeliui operatorių praktinis klausimas yra, ar programinė įranga padeda jiems išlaikyti gynybinį įrašą. Ar galime parodyti numatytą patikrinimo intervalą? Ar galime parodyti iškeltus ir uždarytus defektus? Ar galime parodyti, kad vairuotojo licencija buvo patikrinta, Driver CPC ir DQC buvo galiojantys, o tachografų įrašai buvo stebimi? Ar galime parodyti, kad transporto priemonė buvo išbandyta laiku, arba jei ne, kas nutiko ir kokių veiksmų mes ėmėmės?

Čia vienos sistemos veikimas tampa vertingas. Jei metinių testų įrašas, MOT priminimas, patikrinimų tvarkaraštis ir defektų istorija visi yra prieš tą patį turtą, transporto biuras turi daug aiškesnį vaizdą. Lengviau valdyti VOR sprendimus, lengviau informuoti dirbtuves ir lengviau pateikti įrodymus, jei DVSA prašo.

Operatoriai, kurie peržiūri susijusias kontrolės priemones, taip pat gali norėti perskaityti mūsų gidą apie transporto įrašų programinės įrangos pasirinkimą operatoriaus licencijos darbui, ir mūsų palyginimą apie licencijų tikrinimo programinę įrangą transporto atitikties tikslais.

Kur paprastos kalendoriaus priemonės yra nepakankamos

Skaičiuoklės, Outlook kalendoriai ir bendros užduočių programos gali veikti tam tikrą laiką. Daugelis parkų pradeda nuo to. Problema nėra ta, kad jos niekada nesiunčia priminimų. Problema yra ta, kad jos nesuteikia pakankamai kontrolės, kai atsakomybė yra pasidalinta tarp žmonių, turtų ir terminų.

Skaičiuoklė paprastai priklauso nuo vieno atsargaus asmens. Jei formulės yra pakeistos, eilutės yra paslėptos arba datos yra perrašytos, įrašas tampa nepatikimas. Versijų kontrolė yra prasta. Audito takas yra silpnas arba neegzistuoja. Palaikantys dokumentai gyvena kitur. Jei kas nors išeina, išeina atostogų arba tiesiog praleidžia atnaujinimą, sistema neapsaugo verslo.

Outlook kalendoriai turi panašių apribojimų. Jie yra naudingi asmeniniam planavimui, tačiau jie nėra sukurti kaip operatoriaus licencijos įrašai. Kalendoriaus kvietimas nepasako daug apie turto istoriją. Jis natūraliai nelaiko struktūrizuoto atitikties bylos. Paprastai jis nesiskiria gerai tarp užsakymo priminimo, numatytos datos, nesėkmės rezultato ir pakartotinio testo veiksmų. Jis gali įspėti vieną vartotoją, tačiau nesuteikia valdymo lygio matomumo visame parke.

Bendros užduočių programos dažnai iš pradžių atrodo geriau, nes jos palaiko statusus, komentarus ir paskirtus asmenis. Net ir tada, jos dažnai nepakankamai atitinka parkui specifinius poreikius. Jos nesupranta skirtumo tarp MOT ir metinio testo. Jos nesusieja įrašų švariai su transporto priemonių ir priekabų bylas. Jos retai palaiko platesnį atitikties vaizdą aplink patikrinimus, defektus, tachografų įrašus, Driver CPC ir DQC datas. Jos yra užduočių valdytojai, o ne transporto atitikties sistemos.

Dar viena silpnybė yra įrodymai. Auditorijoje sakyti, kad egzistavo priminimas, nepakanka. Mes turime parodyti aiškią grandinę nuo numatytos datos iki užsakymo, iki rezultato ir iki sekimo. Paprastos priemonės dažnai išsklaido tą grandinę per pašto dėžutes, bendras diskus ir ranka rašytas pastabas. Tai švaisto laiką ir didina tikimybę, kad kažkas svarbaus negalės būti rastas, kai to reikia.

Matomumas yra kita didelė problema. Transporto vadybininkui reikia vieno vaizdo apie tai, kas yra numatyta, kas yra pradelsta, kas yra užsakyta ir kas yra blokuota remonto ar VOR statuso. Jei tai turi būti sudėliota iš skaičiuoklės, el. pašto aplanko ir sienų planuotojo, yra per daug klaidų galimybių.

Operatoriams, kurie vis dar naudoja lengvesnes priemones, mūsų straipsnis apie priminimo programas, kurios palaiko mažą parką auditui pasiruošus, nurodo, kur paprastai yra riba tarp veiksmingos laikinos priemonės ir tinkamos atitikties sistemos.

Kaip Operator Compliance lyginamas su JK parkams

Operator Compliance yra sukurta JK operatoriaus licencijos darbui, o ne pritaikyta iš bendros parkų programos. Tai svarbu, nes detalės yra svarbios. Mes ją sukūrėme aplink tai, kaip transporto vadybininkai ir operatoriai iš tikrųjų palaiko įrašus pagal DVSA lūkesčius, ir aplink dokumentus, kuriuos gali tekti pateikti Transporto komisijos nariui.

Mūsų dėmesys nėra tik rodyti datą. Tai yra išlaikyti transporto priemonių, priekabų ir vairuotojų įrašus sujungtus. Tai reiškia, kad MOT ir metinių testų priminimai yra toje pačioje operatyvinėje aplinkoje kaip patikrinimai, defektai, licencijų patikrinimai, Driver CPC ir DQC kontrolė, tachografų įrodymai ir pasirašyti įrašai. Mišriam parkui tai paprastai sumažina riziką, nes transporto biuras nesikeičia tarp nesusijusių įrankių.

Mes taip pat sukūrėme sistemą remdamiesi operacine patirtimi. OperatorCompliance yra vystoma Fleeta Limited, ir tai svarbu daugeliui operatorių, nes mes patys suprantame, kokia yra įtampa valdant transporto priemones pagal operatoriaus licenciją. Produktas yra formuojamas pagal DVSA Gidą dėl kelių tinkamumo išlaikymo, o ne pagal bendrą priežiūros kontrolinį sąrašą.

Praktiniu požiūriu, mes palaikome įrašus, kuriuos transporto vadybininkai iš tikrųjų turi išlaikyti tvarkingus. Turtas gali būti sekamas kaip transporto priemonės arba priekabos. Statusas yra svarbus, įskaitant VOR, kai tai aktualu. Įrašai gali būti pasirašyti ir saugomi prieš bylą. Vartotojai gali dirbti iš gyvos sistemos, o ne bandyti rekonstruoti atitikties vaizdą iš atskirų aplankų.

Verslams, lyginantiems programinę įrangą, vienas naudingas testas yra, ar produktas padeda kasdienėje veikloje, taip pat ruošiantis auditui. Operator Compliance yra sukurta abiem. Turėtų būti paprasta matyti, kas yra numatyta, sekti, kas trūksta, saugoti įrodymus ir vėliau atgauti bylą, kai kas nors to prašo. Tai yra kitoks standartas nei priminimo programa, kuri tiesiog siunčia pranešimus.

Mes taip pat žinome, kad kai kurie parkai reikia platesnių duomenų ryšių. Priklausomai nuo nustatymo, integracijos ir duomenų mainai gali būti svarbūs, nesvarbu, ar tai per REST API, webhooks, ar ryšius su susijusiomis paslaugomis. Platesniame atitikties ir parkų duomenų kraštovaizdyje operatoriai gali taip pat naudoti įrankius ar duomenų šaltinius, tokius kaip askMID, Motor Insurers' Bureau, MIB, Fleetalyse ar Logivo.AI. Svarbu ne rinkti programinės įrangos pavadinimus. Svarbu užtikrinti, kad priminimo procesas nebūtų izoliuotas nuo likusios operatyvinės bylos.

Tas pats taikoma administravimui aplink VOL ir transporto priemonių įrašus, ir skirtumui tarp JK taisyklių ir platesnių ES prielaidų. Šis straipsnis yra apie JK parkus, kur operatoriaus licencijos atitiktis, DVSA lūkesčiai ir Transporto komisijos nario kontrolė formuoja įrašų laikymo standartą. Jei sistema yra sukurta bendram ES parkų rinkai, ji gali nepakankamai atspindėti tuos JK specifinius operacinius ir įrodymų poreikius.

Jei lyginate pasirinkimus, vertinkite juos pagal tai, ar jie padeda jums kasdien valdyti švaresnį atitikties bylą. Ar sistema gali išlaikyti matomas metinių testų ir MOT datas? Ar ji gali palaikyti mišrius parkus? Ar ji gali laikyti įrodymus ir išlaikyti audito taką? Ar ji gali sujungti tuos priminimus su patikrinimais, defektais, vairuotojų kontrolėmis ir tachografų įrašais? Jei atsakymas yra taip, programinė įranga daro daugiau nei tik siunčia pranešimus. Ji padeda apsaugoti operatoriaus licenciją.