Praleisti į turinį
OperatorCompliance
Išbandykite
← Visi straipsniai

· 13 min skaitymas

Kaip pasirinkti O-licencijos terminų programinę įrangą, atitinkančią

Praktinis programinės įrangos, stebinčios O-licencijos terminus, palyginimas JK operatoriams, transporto vadovams ir transporto priemonėms.

Pasirinkti programinę įrangą O-licencijos terminams stebėti iš tikrųjų nėra tik geresnio dienoraščio gavimas. Tai yra apie tai, kad transporto vadovas gali parodyti kontrolę. Jei DVSA (Kelių saugumo agentūra) paskambina, arba jei byla kada nors pasiekia Kelių komisiją, klausimas nėra tik tai, ar kas nors gavo priminimą. Tai yra, ar operatorius gali įrodyti, kad transporto priemonės, priekabos, vairuotojai ir įrašai buvo aktyviai valdoma, tikrinama, patvirtinama ir saugoma.

Geriausios sistemos atlieka dvi užduotis vienu metu. Jos įspėja jus prieš tai, kai kažkas tampa pavėluota, ir jos sukuria patikimą atitikties įrašą po darbo atlikimo. Tai yra skirtumas tarp priminimo programėlės ir sistemos, kuri atlaiko patikrinimą.

Ką geras terminų programinė įranga turi apimti JK operatoriui

JK operatoriui reikia programinės įrangos, kuri atspindėtų faktinius įsipareigojimus licencijoje ir kasdienes kontrolės priemones, kurias tikisi DVSA. Tai prasideda nuo pagrindų, tačiau neturėtų tuo baigtis.

Transporto priemonėms programinė įranga turėtų stebėti MOT arba metinių testų datas, prevencines techninės priežiūros apžiūras, stabdžių testus, kai tai numatyta, saugumo patikros intervalus, aptarnavimo įvykius, mokesčių ir draudimo datas, bei kalibravimo ar sertifikavimo datas, kai tai aktualu. Ji taip pat turėtų turėti pagrindinius įrodymus, susijusius su šiomis datomis, o ne tik artimiausią datą. Žalias priminimas nėra pakankamas, jei atitinkama patikros lapo, stabdžių testo rezultato ar dirbtuvės patvirtinimo negalima rasti.

Priekaboms taikoma ta pati taisyklė. Per daug sistemų yra orientuotos į transporto priemones ir traktuoja priekabas kaip antrinį dalyką. Tai greitai sukelia problemų krovinių vežimo flotilėms, mišrioms flotilėms ir operatoriams, naudojantiems nuomojamas ar besikeičiančias priekabas. Priekabų metinių testų datos, patikros istorijos, defektai, VOR laikotarpiai ir techninės priežiūros įrašai turi turėti savo profilį ir audito taką.

Vairuotojams sistema turėtų apimti licencijų patikras, Driver CPC statusą, DQC galiojimo pabaigą, tachografo kortelių datas, kai tai aktualu, agentūrinių ar laikino vairuotojo įdarbinimo įrašus, mokymus, deklaracijas ir bet kokias įmonės specifines galiojimo datas. Licencijų pusėje JK operatoriai taip pat turi galvoti apie praktinį ryšį su DVLA (Vairuotojų ir transporto priemonių agentūra) duomenimis. Svarbu, ar programinė įranga tiesiog saugo datą, kurią įvedė vartotojas, ar ji palaiko tinkamą procesą reguliariai tikrinant vairuotojų licencijas ir registruojant rezultatus. Jei norite atnaujinimo apie tai, ką operatoriai turėtų tikrinti, šis vadovas apie vairuotojų licencijų patikras operatoriams yra naudingas kontekstas.

Kalbant apie įrodymų failus, gera terminų programinė įranga turėtų turėti įrašus, kurie palaiko jūsų licencijos įsipareigojimus ir techninės priežiūros sistemas. Tai apima patikros lapus, MOT ir metinių testų sertifikatus, defektų ataskaitas, taisymo įrašus, draudimo dokumentus, nuomos sutartis, OCRS (Operatorių atitikties reitingo sistema) susijusius įrodymus, jei reikia, mokymo įrašus, politikos dokumentus ir korespondenciją. Jei transporto vadovas palieka, šie įrašai turi likti prieinami ir suprantami.

Čia svarbus JK specifinis aspektas. Kai kurie programinės įrangos produktai yra sukurti bendram flotilės administravimui keliuose šalyse. Jie gali pakankamai gerai tvarkyti aptarnavimą ir dokumentus, tačiau ne operatorių licencijos įsipareigojimų struktūrą Didžiojoje Britanijoje. Sistema JK operatoriui turėtų atitikti lūkesčius dėl techninės priežiūros planavimo, įrašų saugojimo ir valdymo kontrolės įrodymo. Ji turėtų atspindėti, kaip operatoriai iš tikrųjų ruošiasi DVSA biuro vertinimui, vietos vizitui ar viešajai apklausai, o ne tik bendram flotilės kalendoriui. Daugiau informacijos apie pagrindinius įsipareigojimus galima rasti operatorių licencijos įsipareigojimuose ir ką jie reiškia praktikoje.

Palyginant priminimo įrankius su pilnos atitikties sistemomis

Primintojas paprastai atlieka vieną funkciją. Jis saugo datą ir siunčia pranešimą prieš atėjus šiai datai. Tai gali būti naudinga, ypač labai mažai operacijai, tačiau palieka akivaizdžių spragų.

Pirmiausia priminimo įrankiai retai valdo susijusias veiklas. Techninės priežiūros apžiūra nesibaigia, kai atėjus datai. Darbas turi būti užsakytas, atliktas, defektai įvertinti, taisymas organizuotas, įrašai įkelti ir dažnai patvirtinti. Jei transporto priemonė yra neprieinama, planas gali tekti keisti, o priežastis turėtų būti užfiksuota. Jei priekaba yra už vietos, atsakomybė vis tiek turi būti aiški. Paprastas priminimas negali valdyti šio proceso.

Antra, priminimo įrankiai paprastai turi silpną įrodymų tvarkymą. Jie gali leisti jums pridėti failą, tačiau nesukuria tinkamo įrašo, kas jį įkėlė, ar užduotis buvo atlikta laiku, ar buvo defektų, kas peržiūrėjo rezultatą ir ar buvo uždaryta kokia nors sekanti veikla. Būtent tokie detalės yra svarbios, kai kas nors klausia, kaip operatorius užtikrina atitiktį praktikoje.

Trečia, jie retai suteikia švarų Kelių komisijos failą. Jei kyla vieša apklausa, operatorius gali tekti pateikti techninės priežiūros istorijas, praleistų patikros paaiškinimus, vairuotojų patikras, tachografo sekimą, VOR sprendimus ir valdymo ataskaitas per tam tikrą laikotarpį. Surinkti tai iš priminimų, skaičiuoklių, el. laiškų ir bendrų aplankų yra lėta ir rizikinga.

Pilna atitikties sistema turėtų būti sukurta aplink įrašus, veiksmus ir įrodymus. Praktiniu požiūriu tai reiškia, kad kiekvienas terminas gali sukelti darbo eigą. PM apžiūra gali sukelti užduotį, reikalauti užpildyto lapo, užregistruoti defektus, parodyti taisymo būseną ir saugoti pasirašytus įrodymus. Driver CPC arba DQC galiojimo pabaiga gali sukelti peržiūrą ir dokumentų užklausą. Praleistas terminas gali būti eskaluotas ir paaiškintas, o ne tiesiog pasidaryti raudonas ant prietaisų skydelio.

Čia tokie produktai kaip Operator Compliance pozicionuoja save kitaip nei bendroji priminimo programinė įranga. OperatorCompliance yra sukurta Fleeta Limited, kuri teigia, kad pati valdo sunkvežimius pagal operatorių licenciją. Tai svarbu, jei programinė įranga iš tikrųjų buvo sukurta remiantis DVSA Gidu dėl Kelių saugumo palaikymo, nes sistemos dizainas turėtų sekti realius operatorių procesus, o ne abstraktų užduočių valdymą.

Kasdien transporto vadovams svarbiausi bruožai

Transporto vadovai nepirko programinės įrangos dėl funkcijų sąrašo. Jie ją perka, nes jiems reikia mažiau aklų taškų 16:30 penktadienį. Tinkamas palyginimas nėra tas, kuris turi daugiausiai modulių. Tai yra tas, kuris palengvina kasdienes kontrolės priemones.

Pradėkite nuo MOT ir metinių testų planavimo. Sistema turėtų aiškiai atskirti transporto priemonių kategorijas ir testavimo režimus. Prekių transporto priemonės, PSV (viešojo transporto priemonės), priekabos ir lengvųjų flotilės tipai gali turėti skirtingus poreikius. Kalendorius turėtų rodyti, kas yra numatyta, kas yra užsakyta ir kokie įrodymai buvo grąžinti. Ji taip pat turėtų susidoroti su pakartotiniais testais ir nesėkmėmis, nesugriaudama istorijos.

Prevencinės techninės priežiūros apžiūros yra tokios pat svarbios. Ieškokite lanksčių intervalų planavimo pagal laiką, atstumą ar naudojimo modelį, su galimybe nustatyti skirtingas dažnumo normas visai flotilei. Daugeliui operatorių planavimas pagal ISO savaitę yra naudingas, nes dirbtuvių tvarkaraščiai, vairuotojų prieinamumas ir nuomojamų transporto priemonių rotacija dažnai seka savaitinius operacinius modelius, o ne paprastas mėnesines datas. Jei jūsų techninės priežiūros teikėjas planuoja pagal ISO savaitę, programinė įranga taip pat turėtų tai daryti.

Vairuotojų kontrolės taip pat reikalauja panašaus praktiškumo. Driver CPC ir DQC patikros neturėtų būti atskirame HR silose, jei jos veikia, ar vairuotojas gali teisėtai ar saugiai būti paskirtas darbui. Vairuotojų įrašai taip pat turėtų apimti licencijų kategorijas, patvirtinimus, patikros istoriją ir bet kokius vidinius patvirtinimus. Flotilėms, naudojančioms agentūrų darbo jėgą, sistema turėtų susidoroti su trumpalaikiais vairuotojais, nesukurdama nuolatinio chaoso ar prarandant audito galimybes.

Tachografo analizė yra dar viena skiriamoji linija. Kai kurios sistemos tiesiog užfiksuoja, kad analizė buvo atlikta kitur. Geresnės sistemos integruoja procesą į atitikties įrašą, rodydamos atsisiuntimo tvarkaraščius, pažeidimų ataskaitas, sekimo veiksmus ir pripažinimus. Jei lyginate galimybes šioje srityje, šis straipsnis apie tachografo analizės programinę įrangą mažoms flotilėms suteikia naudingą vaizdą, į ką atkreipti dėmesį.

Defektų ataskaitos ir VOR kontrolė yra kasdieniai būtinybės. Tinkama atitikties sistema turėtų leisti defektus pranešti greitai, susieti su atitinkama transporto priemone ar priekaba, peržiūrėti tinkamam asmeniui ir sekti iki taisymo. Ji turėtų atskirti saugos kritinius defektus nuo smulkių problemų ir turėtų padaryti VOR būseną matomą visoje operacijoje. Jei transporto priemonė ar priekaba yra VOR, ši būsena neturėtų būti paslėpta pastabų lauke. Ji turėtų būti akivaizdi planuotojams, dirbtuvių darbuotojams ir transporto valdymui.

Dokumentų saugojimas taip pat yra svarbesnis, nei daugelis pirkėjų tikisi. Testas nėra tas, ar dokumentai gali būti įkelti. Tai yra, ar jie gali būti rasti, filtruojami ir pasitikima vėliau. Paieška pagal transporto priemonę, priekabą, vairuotoją, dokumentų tipą, datų intervalą ir būseną turėtų būti lengva. Versijų kontrolė yra naudinga politikos ir draudimo dokumentams. Išlaikymas turėtų būti nuoseklus. Pavadinimai neturėtų priklausyti nuo vieno asmens, prisimenant, kaip jis išsaugojo PDF prieš šešis mėnesius.

Kai kurie operatoriai taip pat nori platesnių flotilės duomenų vienoje vietoje. Tai gali apimti draudimo patvirtinimą, MID patikras per askMID, arba nuorodas į duomenis iš Motor Insurers' Bureau arba MIB, kai tai aktualu flotilės administravimui. Tai nėra pakaitalai operatorių licencijos kontrolėms, tačiau jie gali sumažinti dubliavimą, jei sistema yra protingai sukurta.

Kaip įvertinti audito taką, ataskaitas ir pasirašytus įrodymus

Jei dvi sistemos abi siunčia priminimus ir abi saugo PDF, audito takas yra ta vieta, kur pasirodo tikras skirtumas.

Paklauskite, ką sistema automatiškai įrašo. Norite žinoti, kas sukūrė užduotį, kas pakeitė terminą, kas pažymėjo ją kaip užbaigtą, kada buvo įkeltas palaikomas dokumentas ir ar kas nors peržiūrėjo ar patvirtino rezultatą. Jei techninė priežiūros apžiūra buvo atlikta vėlai, ar sistema gali parodyti pradinę datą, pakeistą datą, pakeitimo priežastį ir patvirtintoją? Ši istorija yra svarbi.

Pasirašyti įrodymai yra ypač svarbūs defektų valdymui, techninės priežiūros užbaigimui ir vairuotojų pripažinimams. Elektroninis patvirtinimas neturėtų būti kosmetinis žymėjimo langelis. Jis turėtų susieti parašą ar patvirtinimą su konkrečia veikla, data ir vartotojo įrašu. Jei vairuotojas patvirtina defektų ataskaitą arba vadovas patvirtina tachografo sekimą, sistema turėtų išsaugoti tą įrodymą taip, kad vėliau būtų galima jį atkurti.

Ataskaitos turi veikti dviem lygiais. Pirmiausia, yra operatyvinės ataskaitos. Kas numatyta šią savaitę, kas pavėluota, kas yra VOR, kas neturi pridėtų įrodymų, kurie vairuotojai turi būti tikrinami, kurios priekabos turi artėjančius metinius testų laikotarpius. Antra, yra valdymo ataskaitos. Ar patikros atliekamos laiku, ar tam tikri depai praleidžia terminus, ar defektai per ilgai lieka atviri, ar agentūrų vairuotojai yra nuolat tikrinami, ar yra pakartotinių tachografo problemų su tais pačiais asmenimis.

DVSA tikslams, pagrindinis klausimas yra, ar galite greitai ir nuosekliai pateikti įrodymus. Vizito metu inspektoriai nenori trijų sistemų ir dviejų bendrų diskų turo. Jie nori matyti įrašus. Viešos apklausos metu Kelių komisija tikisi patikimo atitikties pasakojimo, pagrįsto dokumentais, datomis ir veiksmais. Programinė įranga turėtų padėti jums eksportuoti ar pateikti tą failą struktūrizuotu būdu.

Čia užbaigtos veiklos yra tokios pat svarbios kaip artėjantys terminai. Priešais pilnas priminimų prietaisų skydelis pasako tik pusę istorijos. Stipresnis testas yra, ar sistema gali parodyti, kad reikalaujami veiksmai buvo atlikti, tinkamų žmonių, su išimtimis, identifikuotomis ir valdomomis. Tai rodo efektyvią ir nuolatinę valdymo kontrolę.

Taip pat verta paklausti, kaip programinė įranga tvarko išimtis. Tikros flotilės turi praleistų užsakymų, nuomojamų transporto priemonių, dirbtuvių vėlavimų, kelio draudimų, agentūrų vairuotojų ir vėluojančių dokumentų. Geras sistema nesistengia apsimesti, kad šie dalykai niekada neįvyksta. Ji aiškiai juos registruoja, eskaluoja, kur reikia, ir palieka sąžiningą taką, rodantį, ką operatorius padarė toliau.

Klausimai, kuriuos reikia užduoti prieš perkant ar keičiant sistemas

Prieš pasirinkdami platformą, paklauskite, kaip vyksta nustatymas. Ar tiekėjas gali importuoti jūsų dabartinius transporto priemonių, priekabų ir vairuotojų duomenis, ar jūsų komanda turės viską įvesti rankiniu būdu? Duomenų migracija yra ta vieta, kur daugelis projektų praranda pagreitį. Jei jūsų dabartiniai įrašai yra skaičiuoklėse, dirbtuvių sistemose, debesų aplankuose ir tachografo portaluose, jums reikia aiškaus migracijos plano.

Paklauskite, kokie įrodymai gali būti perkelti. Tik datos nėra pakankamos. Jei keičiant sistemas paliekate istorinius techninės priežiūros lapus, metinių testų įrašus ir vairuotojų dokumentus, jūs iš tikrųjų neišsprendėte įrašų problemos. Jūs tiesiog ją padalijote.

Atidžiai patikrinkite integracijas. Jei jau naudojate dirbtuvių sistemą, tachografo platformą, HR įrankį ar telematikos teikėją, paklauskite, ar programinė įranga integruojasi tiesiogiai, ar darbuotojai turės vėl įvesti duomenis. Tinkama REST API gali būti svarbi, ypač didesniems operatoriams ar grupėms su vidinėmis sistemomis. Tas pats taikoma ir webhook'ams, jei norite realaus laiko atnaujinimų, kai defektas yra užfiksuotas, dokumentas įkeltas ar būsena pasikeičia.

Paklauskite, kaip sistema tvarko skirtingų flotilės tipų. Daugelis operatorių nėra tik viena rūšis. Jie gali valdyti HGV, furgonus, priekabas, PSV, specializuotas plantų palaikymo transporto priemones ar mišrius depus. Autobusų ir mikroautobusų operatoriai turės šiek tiek skirtingas kontrolės priemones nei prekių operatoriai. Taksų ir privačių nuomos firmos, taip pat įdarbinimo ar vairuotojų agentūros gali reikėti stiprių vairuotojų ir dokumentų darbo srautų, net jei operatorių licencijos profilis skiriasi. Įsitikinkite, kad produktas atitinka jūsų faktinę operaciją, o ne tiekėjo standartinę demonstracinę flotilę.

Planavimo formatas yra dar vienas praktinis aspektas. Jei jūsų dirbtuvės, planuotojas ar išorinis techninės priežiūros teikėjas dirba pagal ISO savaitę, patvirtinkite, kad sistema gali rodyti ir ataskaitas tokiu būdu. Tai skamba mažai, kol visi pradeda kalbėti savaitės numeriais, o programinė įranga reikalauja kalendorinių mėnesių.

Vartotojų prieiga ir leidimai nusipelno artimos priežiūros. Ar planuotojai gali matyti VOR būseną, nekeičiant techninės priežiūros įrašų? Ar dirbtuvių darbuotojai gali įkelti patikros lapus, nematydami konfidencialių HR dokumentų? Ar agentūrų koordinatoriai gali valdyti vairuotojų įdarbinimą, nekeičiant operatoriaus nustatymų? Geras leidimų valdymas sumažina tiek riziką, tiek painiavą.

Pagalba taip pat yra svarbi. Paklauskite, kas padeda su nustatymu, kas atsako į su atitiktimi susijusius klausimus apie sistemą, ir ar pagalba supranta JK operatorių licencijos praktiką ar tik bendrą programinės įrangos administravimą. Tiekėjas, kuris supranta VOL procesus, techninės priežiūros įrašus ir DVSA lūkesčius, paprastai greičiau išspręs problemas nei tas, kuris skaito iš techninio scenarijaus. Jei jums reikia konteksto apie įrašus, kuriuos operatoriai turėtų laikyti, šis apžvalga apie operatorių licencijos techninės priežiūros įrašus yra verta perskaityti prieš demonstracijas.

Galiausiai paklauskite, kaip sistema jums padės, jei būsite iššūkis. Ne teorijoje, bet realioje situacijoje. Jei DVSA apsilanko kitą savaitę, kaip jūs pateikiate techninės priežiūros istorijas, defektų uždarymus, vairuotojų patikras ir tachografo sekimą? Jei kyla licencijos peržiūra VOL, kokias ataskaitas galite eksportuoti? Jei transporto vadovas yra atostogose, ar kas nors kitas vis tiek gali gauti įrodymus?

Geriausia programinė įranga O-licencijos terminams stebėti turėtų palikti jums aiškius atsakymus į šiuos klausimus. Ji turėtų palengvinti kasdienę atitiktį, tačiau svarbiausia, ji turėtų palikti patikimą kontrolės įrašą. Tai yra tai, kas atlaiko DVSA, ir tai yra tai, kas apsaugo operatorių, kai patikrinimas viršija kitą priminimą.

Kokius terminus turėtų stebėti O-licencijos programinė įranga?

Mažiausiai ji turėtų stebėti MOT arba metinių testų datas, saugumo patikras, vairuotojų licencijų patikras, Driver CPC ir DQC datas, tachografo peržiūras, draudimo dokumentus ir kitus atitikties įrašus.

Ar kalendoriaus priminimo programėlė yra pakankama operatorių atitikties užtikrinimui?

Paprastai ne. Kalendorius gali priminti apie datas, tačiau jis nesuteikia patikros istorijos, pasirašytų įrodymų, tachografo įrašų, defektų ataskaitų ar audito tako DVSA.

Kodėl pasirašyti įrodymai yra svarbūs atitikties programinėje įrangoje?

Todėl, kad operatoriai gali tekti parodyti, kas buvo tikrinama, kada tai buvo padaryta ir kas tai patvirtino. Šis įrašas gali būti toks pat svarbus kaip ir pats priminimas.

Ar programinė įranga turėtų apimti tachografo analizę?

Jei jūsų operacija naudoja tachografus, taip. Laikyti tachografo analizę atskirai nuo transporto priemonių ir vairuotojų terminų gali sukurti spragų ir papildomą administravimą transporto vadovams.

Kokios integracijos yra naudingos šio tipo sistemoje?

Naudingi variantai apima nuorodas į dirbtuvių procesus, vairuotojų ir transporto priemonių duomenų šaltinius, ir technines galimybes, tokias kaip REST API arba webhook'ai, kai operatoriai nori, kad duomenys judėtų tarp sistemų.

Pasiruošę nustoti sekti datas?

Sukurkite per popietę. Išlaikykite savo operatoriaus licenciją švarią visam laikui.

14 dienų nemokamas bandomasis laikotarpis · jokių kortelių · atšaukite bet kada