Programinės įrangos pasirinkimas, kuri atlaiko DVSA auditą

Jei sistema skirta apsaugoti jūsų operatoriaus licenciją, ji turi daryti daugiau nei siųsti priminimus. DVSA audito metu, ir jei reikalai kada nors pasieks Transporto komisiją, turite parodyti, kas buvo numatyta, kas buvo padaryta, kas tai padarė, kada tai buvo užfiksuota, kokie įrodymai tai palaiko ir kas nutiko, kai kažkas buvo praleista arba transporto priemonė tapo VOR (neveikianti). Tai yra skirtumas tarp dienoraščio įrankio ir programinės įrangos, kuri gali palaikyti tinkamą atitikties failą.

Daugumai operatorių tikrasis testas yra paprastas. Ar galime greitai gauti transporto priemonių, priekabų ir vairuotojų įrašus vienoje vietoje, su datomis, dokumentais, pasirašytais įrodymais ir aiškia veiksmų istorija? Jei ne, sistema gali padėti kasdien, bet vargu ar gerai atlaikys, kai DVSA inspektorius prašys įrodymų.

Ką turi įrodyti operatoriaus licencijos auditų takas

Operatoriaus licencijos auditų takas yra apie įrodymus, o ne ketinimus. Transporto vadybininkai turi nuolat ir efektyviai valdyti transporto operacijas. Operatoriai turi užtikrinti, kad transporto priemonės būtų tinkamos eksploatacijai, laikyti įrašus, stebėti vairuotojus ir vykdyti licencijos prisiimtus įsipareigojimus. Programinė įranga turėtų padėti mums įrodyti, kad šie dalykai vyko praktikoje.

Transporto priemonių priežiūrai auditų takas turi parodyti suplanuotas datas, atliktas datas, rezultatus ir sekimą. Tai paprastai reiškia saugos patikrinimų grafikus, patikrinimo lapus, remonto įrašus, stabdžių testo įrodymus, jei taikoma, MOT arba metinių testų datas ir rezultatus, ridos rodmenis, PMI istorijas ir defektų, kurie buvo pranešti ir ištaisyti, įrašus. Jei transporto priemonė nebuvo tinkama eksploatacijai, įraše turėtų būti nurodyta, kad ji buvo nuimta nuo kelio arba pažymėta VOR, ir kada ji grįžo į eksploataciją.

Vairuotojams takas turi parodyti patikrinimus ir intervencijas. Tai apima vairuotojo licencijos patikrinimus su DVLA, Driver CPC statusą, DQC galiojimo pabaigą, tachografo analizę, pažeidimų sekimą ir bet kokius grįžimo į darbą ar periodinius patikrinimus, kurių reikalauja jūsų operacija. Švarus auditų takas ne tik rodo, kad priminimas egzistavo. Jis rodo, kad patikrinimas iš tikrųjų buvo atliktas ir koks buvo rezultatas.

Transporto komisijos failui kontekstas yra toks pat svarbus kaip ir datos. Jei metinis testas nepavyko, kokie buvo atlikti remonto darbai ir kada buvo išlaikytas pakartotinis testas? Jei vairuotojas turėjo pakartotinių tachografo pažeidimų, ar buvo atliktas aptarimas, ar jis buvo dokumentuotas, ir ar modelis pagerėjo? Jei patikrinimas buvo atliktas vėlai, kokia buvo priežastis ir kokia kontrolė buvo įdiegta, kad tai nepasikartotų? Geros programinės įrangos turėtų leisti mums įrodyti išimčių tvarkymą, o ne tik laimingą kelią.

Tai ypač svarbu JK, nes operatorių licencijavimas yra susijęs su konkrečiais įsipareigojimais ir lūkesčiais pagal vidaus sistemą. ES taisyklės vis dar veikia tokiose srityse kaip vairuotojų valandos ir tachografai, tačiau tai, kaip įrašai yra tikrinami JK prekių ar PSV operatoriui, formuojama DVSA proceso ir Transporto komisijos sistemos. Bendroji flotilės priemonė, sukurta platesnei ES rinkai, gali sekti paslaugų datas, tačiau vis tiek gali nepakakti įrašams, kuriuos JK operatorius turi pateikti.

Jei peržiūrite savo dabartinę sistemą, mūsų gidas apie kaip pasirinkti atitikties programinę įrangą, kuri atlaiko DVSA pateikia tą pačią mintį iš pirkimo perspektyvos. Pagrindinis dalykas visada yra įrodymai, kurie gali būti greitai atgauti ir suprasti.

Kaip skirtingos sistemos tvarko įrašus, priminimus ir įrodymus

Dauguma operatorių, atsisakančių skaičiuoklių, pirmiausia žiūri į priminimų įrankius. Šie įrankiai yra naudingi pagrindiniam terminų valdymui. Jie gali laikyti datą MOT, metiniam testui, draudimui ar vairuotojo patikrinimui, tada siųsti el. laišką prieš tai, kai terminas pasibaigia. Tai geriau nei pasikliauti sieniniu planuotoju ar kieno nors atmintimi. Tačiau priminimų įrankis paprastai sustoja ties priminimu. Jis gali neturėti pasirašyto patikrinimo lapo, nepavykusio testo pranešimo, ištaisymo sąskaitos ar istorijos, rodančios, kad numatyta data pasikeitė, nes transporto priemonė buvo nuimta nuo kelio.

Tai svarbu audito metu. Priminių sistemų gali pasakyti, kad šešių savaičių patikrinimas buvo numatytas tam tikrą datą, tačiau nepasako, ar jis buvo atliktas, ar buvo rasta defektų, ar jie buvo saugos kritiniai, ir ar transporto priemonė buvo naudojama tuo tarpu. Kitaip tariant, ji gali parodyti mūsų ketinimą valdyti atitiktį, tačiau ne visada mūsų įrodymus.

Kitas lygis yra flotilės priežiūros sistema. Šios sistemos paprastai yra stipresnės dirbtuvėms, turto įrašams, darbo kortelėms ir paslaugų istorijoms. Operatoriams, turintiems vidinę priežiūrą arba artimą priežiūros kontrolę, tai gali būti geras žingsnis į priekį. Tinkama priežiūros sistema gali geriau sekti patikrinimus, remontus, dalis, MOT paruošimą ir metinių testų rezultatus nei paprasta priminimų programa.

Silpnybė dažnai būna už dirbtuvės ribų. Kai kurios priežiūros sistemos mažiau išvystytos vairuotojų atitikties, tachografo darbo srautams, licencijų patikrinimams, Driver CPC stebėjimui, DQC įrašams ar būdui, kaip transporto vadybininkai turi matyti visus įsipareigojimus visose transporto priemonėse, priekabose ir vairuotojuose viename atitikties vaizde. Jos gali būti puikios inžinerijos sistemos, tačiau ne visada yra pilnos operatorių licencijų sistemos.

Pilna atitikties platforma turėtų sujungti abi puses. Ji turėtų valdyti terminus, bet taip pat išsaugoti įrodymus. Ji turėtų saugoti dokumentus, susijusius su atitinkama transporto priemone, priekaba ar vairuotoju. Ji turėtų užfiksuoti, kas įkėlė ar pasirašė kažką, ir kada. Ji turėtų aiškiai parodyti pradelstas prekes, palaikyti eskalaciją ir padaryti ataskaitų teikimą paprastą, kai DVSA prašo įrašų per tam tikrą laikotarpį. Ji taip pat turėtų būti naudojama gyvose operacijose, nes jei sistema yra nepatogi, žmonės dirba aplink ją, o auditų takas tampa nenuoseklus.

Auditų tako gylis yra tikras palyginimo taškas. Paklauskite, ar sistema užfiksuoja tik naujausią būseną, ar ji išsaugo laikotarpį. Ar galite matyti, kad vairuotojo licencijos patikrinimas buvo numatytas, atliktas vėlai, peržiūrėtas transporto vadybininko ir po to pažymėtas dėl taškų licencijoje? Ar galite matyti, kad transporto priemonės defektas buvo praneštas vairuotojo, pripažintas, įvertintas, ištaisyta ir pasirašyta prieš transporto priemonės grįžimą į eksploataciją? Tai yra tai, kas atlaiko patikrinimą.

Integracija taip pat gali būti svarbi, tačiau tik jei ji pagerina kontrolę. Kai kurios didesnės sistemos siūlo REST API arba webhooks, kad būtų galima perkelti duomenis tarp platformų. Tai gali padėti, jei jums reikia ryšių su dirbtuvėmis, HR įrašais, atlyginimų ar telematikos. Tai naudinga, tačiau tai nėra pakaitalas tinkamam atitikties įrašui pačioje platformoje.

Įrašai, kurie yra svarbiausi JK flotilėje

Kai kurie įrašai yra prašomi nuolat, nes jie yra susiję su kelių tinkamumu ir valdymo kontrole.

MOT ir metinių testų įrašai turi būti lengvai sekami pagal transporto priemonę ir priekabą. HGV ir PSV atveju metinių testų planavimas yra svarbus atitikties taškas, o priekaboms reikia lygiavertės dėmesio. Sistema turėtų rodyti rezervavimo datas, numatytas datas, išlaikymo arba nepavykimo rezultatus, draudimo susijusius pastabas, kur tai aktualu, ir palaikančius dokumentus. Ji taip pat turėtų susidoroti su tuo, kad mišrios flotilės gali apimti furgonus su MOT kartu su O-licencijos transporto priemonėmis ir priekabomis, turinčiomis metinius testus. Jei norite atnaujinimo apie konkrečius testavimo aspektus, žr. mūsų gidas apie HGV ir priekabų metinių testų reikalavimus.

Saugos patikrinimai ir priežiūros įrašai dažnai yra vieta, kur auditai laimimi arba pralaimi. Programinė įranga turėtų leisti mums nustatyti patikrinimų dažnumą pagal transporto priemonę ar flotilės grupę, remiantis veiklos modeliu ir priežiūros režimu. Ji turėtų išlaikyti patikrinimo lapą, rezultatą, meistro ar paslaugų teikėjo duomenis, bet kokius stabdžių testo įrodymus, kuriuos saugote, ir ištaisymo įrašą. Ji taip pat turėtų aiškiai rodyti praleistus ir perplanuotus patikrinimus, nes nepaaiškinti tarpai yra sunkiai ginami. Mūsų praktiniai pastebėjimai apie operatorių licencijų priežiūros įrašus nagrinėja, ką reikia laikyti failuose.

Vairuotojų licencijų patikrinimai reikalauja daugiau nei tik kitą numatytą datą. Mums reikia patikrinimo rezultato, atlikimo datos, kas jį peržiūrėjo ir kokių veiksmų buvo imtasi. JK DVLA įrašas yra centrinis teisės, papildymų ir galiojimo pabaigos klausimais. Tai nėra tas pats, kas bendras tapatybės patikrinimas ar teisės dirbti procesas. Jei jūsų operacija naudoja agentūrinius ar atsitiktinius vairuotojus, sistema vis tiek turėtų leisti jums įrodyti patikrinimų dažnumą ir rezultatus kiekvienam asmeniui. Mūsų puslapis apie vairuotojų licencijų patikrinimus operatoriams apima operacinį standartą, kurio tikimės matyti.

Driver CPC ir DQC įrašai turėtų būti matomi kartu su licencijos statusu, o ne paslėpti kitur. Transporto vadybininkas turi žinoti, kas yra dabartinis, kas artėja prie galiojimo pabaigos ir ar įrodymai buvo įkelti. Autobusų, mikroautobusų ir sunkvežimių operacijose prarasti Driver CPC datas gali greitai tapti darbuotojų ir atitikties problema.

Tachografo analizė yra dar viena sritis, kuriose paviršinės sistemos susiduria su sunkumais. Neužtenka pažymėti, kad analizė yra perduota išorėje arba kad ataskaitos yra prieinamos kažkur kitur. Mums reikia žinoti, ar atsisiuntimai yra naujausi, ar pažeidimai buvo peržiūrėti, ar vairuotojai buvo aptarti ir ar pakartotiniai klausimai yra tvarkomi. Sistema, kuri gali susieti analizės rezultatą su vairuotojo įrašu ir saugoti aptarimo įrodymus, yra daug naudingesnė nei ta, kuri tiesiog užfiksuoja numatytą datą.

Defektų pranešimas taip pat reikalauja tinkamos įrodymų grandinės. Vairuotojų apžiūros patikrinimai, nuliniai defektų pranešimai, kur jų reikalaujate, pranešti defektai, remonto būsena ir grįžimo į eksploataciją sprendimai turėtų būti matomi. Jei buvo pranešta apie rimtą defektą, programinė įranga turėtų aiškiai parodyti, kad transporto priemonė nebuvo naudojama, kol ji nebuvo ištaisyta, arba kad ji buvo pažymėta VOR. Tai yra vienas iš aiškiausių pavyzdžių, kodėl operatoriaus licencijos auditų takas programinės įrangos platforma turi išsaugoti veiksmus, o ne tik datas.

Kai kuriems operatoriams taip pat yra susijusių įrašų, kuriuos verta laikyti kartu, net jei jie yra šiek tiek už pagrindinio O-licencijos failo ribų. Draudimo įrodymai, askMID patikrinimai per Motor Insurers' Bureau arba MIB, ir transporto priemonės duomenys, gauti iš tokių šaltinių kaip VOL, gali padėti užtikrinti sklandesnę administraciją. Tai nėra priežiūros ir vairuotojų įrašų pakaitalas, tačiau jie gali sumažinti riziką, kad atsiras spragų platesniame flotilės faile.

Klausimai, kuriuos reikia užduoti prieš pereinant nuo skaičiuoklių

Pereiti nuo skaičiuoklių nėra tik programinės įrangos pirkimas. Tai yra kontrolės pokytis. Prieš pereinant, turėtume išbandyti, ar nauja sistema veiks užimtoje transporto stotyje, dirbtuvėse ir transporto vadybininkui, rengiančiam įrašus DVSA.

Pradėkite nuo naudojimo paprastumo. Ar žmonės gali greitai įvesti ir rasti informaciją? Jei užbaigtos patikros registravimas užtrunka per daug žingsnių, įrašai bus atidėti arba praleisti. Paprašykite pamatyti darbo eigą, kaip pridėti transporto priemonę, nustatyti patikrinimo grafiką, įkelti patikrinimo lapą, pažymėti defektą kaip ištaisytą ir parengti ataskaitą apie vieną transporto priemonę per pasirinktą laikotarpį. Jei demonstracija vengia šių užduočių, tai jums ką nors sako.

Paklauskite, kaip tvarkomi pasirašyti įrašai. Ar vairuotojai, meistrai ar vadybininkai gali pasirašyti skaitmeniniu būdu? Ar parašas susietas su įrašo data ir naudotojo paskyra? Ar sistema gali išsaugoti originalų įkeltą dokumentą, taip pat pasirašytą būseną? Teismo posėdyje ar audito metu tvarkingas statuso simbolis yra mažiau įtikinamas nei pilnas įrašas su pridėtu pagrindiniu dokumentu.

Dokumentų saugojimas turi būti praktiškas. Ar galime saugoti PDF, nuotraukas, nuskenuotus lapus ir sertifikatus, susijusius su tinkamu turtu ar asmeniu? Ar įrašai yra ieškomi? Ar galime filtruoti pagal datų intervalą, transporto priemonę, priekabą, depą ar vairuotoją? Sistema tampa daug naudingesnė, kai ji gali sukurti švarų failą, nes kažkas ieško per el. pašto dėžutes ir bendrus diskus.

Ataskaitų teikimas yra dar vienas pirkimo patikrinimas. Paklauskite, kokios standartinės ataskaitos egzistuoja dėl pradelstų patikrinimų, artėjančių MOT ir metinių testų datų, galiojančių DQC įrašų, licencijų patikrinimų, kurie yra numatyti, ir tachografo sekimo. Tada paklauskite, ar ataskaita gali būti eksportuota ir ar ji rodo pakankamai detalių, kad būtų galima veikti. Ataskaita, kuri sako „3 pradelsti“, nėra pakankama, jei ji nepasako, kurie turtai, kiek vėlai ir kokių įrodymų trūksta.

Naudotojų leidimai yra svarbesni nei daugelis pirkėjų tikisi. Transporto vadybininkui gali prireikti visiško peržiūros, tuo tarpu dirbtuvės darbuotojams reikia prieigos prie priežiūros, vairuotojams reikia defektų pranešimo, o biuro darbuotojams gali prireikti tik dokumentų įkėlimo arba priminimų matomumo. Geros leidimų sistemos saugo auditų taką, nes sumažina atsitiktinius redagavimus ir padaro naudotojų veiksmus aiškesnius.

Duomenų migracija nusipelno tinkamo dėmesio. Dauguma flotilių turi metų įrašų skaičiuoklėse, aplankuose ir el. pašto grandinėse. Paklauskite, kas gali būti importuota, kas reikalauja rankinio nustatymo ir kaip istorinių įrašų pridedama. Taip pat paklauskite, kaip tvarkomos datos, ypač jei jūsų verslas planuoja pagal ISO savaitę patikrinimams ar dirbtuvėms. Prasta migracija gali palikti jus su nauja sistema, kuri prasideda švariai, bet praranda istoriją, kurios jums gali prireikti vėliau.

Galiausiai paklauskite apie operacinį tinkamumą. Mišrios flotilės dažnai apima HGV, furgonus, priekabas, PSV, atsitiktinius subrangovų turtus ir agentūrinius vairuotojus. Sistema gali atrodyti gerai vienos flotilės demonstracijoje, tačiau tapti nepatogia, kai pasirodo tos variacijos. Jei taip pat naudojate sujungtus įrankius, paklauskite, kokios integracijos egzistuoja šiandien ir kas yra įmanoma per REST API arba webhooks. Fleetalyse arba Logivo.AI paminėjimai gali būti aktualūs kai kuriose operacijose, tačiau tik jei ryšys palaiko atitikties procesą, o ne priduria dar vieną nesusijusį informacijos skydelį.

Kur Operator Compliance tinka transporto vadybininkams

Operator Compliance yra sukurta JK operatorių licencijų aplinkai, o ne kaip bendroji flotilės programa su atitiktimi, pridėta vėliau. Tai svarbu, nes transporto vadybininkams čia reikia įrašų, kurie atitinka DVSA lūkesčius, Kelių tinkamumo išlaikymo gaires ir praktinę Transporto komisijos failo realybę.

Mūsų dėmesys yra į įrašus, kurių operatoriai iš tikrųjų prašomi pateikti. Mes sekame transporto priemones, priekabas ir vairuotojus kartu. Mes tvarkome pagrindinius terminus, tokius kaip MOT, metiniai testai, patikrinimai, vairuotojų licencijų patikrinimai, Driver CPC ir DQC. Mes taip pat palaikome tachografo įrodymus ir platesnį dokumentų taką, kuris yra už kasdienės atitikties sprendimų.

Operacinis tinkamumas yra svarbus. Dauguma flotilių yra mišrios. Jos gali valdyti sunkvežimius pagal operatoriaus licenciją, furgonus, kuriems vis dar reikia disciplinuotos priežiūros kontrolės, ir priekabas su savo testavimo ciklu. Jos gali naudoti samdomus vairuotojus, savininkus-vairuotojus ir agentūrų aprėptį. OperatorCompliance yra sukurta taip, kad šie įsipareigojimai galėtų būti valdomi vienoje sistemoje, su vienu vaizdu, kas yra numatyta ir kokie įrodymai yra faile.

Auditų takas yra vieta, kur mes dedame svorį. Mes nesistengiame būti tik priminimų įrankiu. Priminimai yra svarbūs, tačiau tik kaip dalis įrašo, kuris rodo atliktą veiksmą, įkeltus įrodymus, atsakingą naudotoją ir laikotarpį. Jei kažkas vėluoja arba nepavyksta, įrašas turėtų tai parodyti. Transporto vadybininkas turėtų galėti atsakyti į akivaizdžius sekimo klausimus, nepalikdamas sistemos.

Mūsų JK operatorių dėmesys taip pat kyla iš to, kaip produktas buvo sukurtas. Fleeta Limited valdo sunkvežimius pagal operatoriaus licenciją, todėl programinė įranga buvo formuojama atsižvelgiant į tas pačias priežiūros ir atitikties problemas, su kuriomis susiduria mūsų naudotojai. Todėl dizainas atitinka DVSA Kelių tinkamumo išlaikymo gaires, o ne verčia operatorius prisitaikyti prie bendros priežiūros paketo.

Pirkėjams, lyginantiems sistemas, tai reiškia, kad Operator Compliance yra arčiau pilnos atitikties platformos nei dienoraščio programos ar tik dirbtuvėms skirtos sistemos. Mes suteikiame transporto vadybininkams praktišką būdą išlaikyti failą, stebėti terminus, saugoti pasirašytus įrašus ir pateikti įrodymus, kai to prašoma. Jei jūsų dabartinis procesas priklauso nuo skaičiuoklių, bendrų aplankų ir atminties, tai paprastai yra spraga, kurią reikia užpildyti.

Tinkama programinė įranga turėtų palengvinti DVSA auditą, nes įrodymai jau yra organizuoti, o ne todėl, kad kažkas praleido dvi dienas ruošdamasis vizitui. Tai yra standartas, kurio mes siekiame.