Pasirinkti vieną sistemą atitikties užtikrinimui keliuose depuose

Jei valdote transporto priemones iš daugiau nei vieno veiklos centro, sunkiausia dalis retai būna duomenų rinkimas. Svarbiausia yra turėti tinkamus įrodymus vienoje vietoje, nesumažinant depų komandų atsakomybės, reikalingos kasdieniam transporto priemonių, priekabų ir vairuotojų valdymui. Geras kelių depų atitikties sistema turėtų leisti centriniam biurui matyti riziką visame licence, tuo pačiu kiekvienas depas turėtų atsakyti už patikrinimus, trūkumus, licencijų patikrinimus ir sekimą.

Tai svarbu JK, nes operatorių licencijos atitiktis vertinama tiek pagal įrodymus, tiek pagal ketinimus. Kai DVSA atvyksta, arba kai rengiamas Trafiko komisaro bylos dokumentas, turite parodyti, kas buvo numatyta, kas buvo padaryta, kas buvo praleista, kas apie tai žinojo ir kas įvyko toliau. Jei ši informacija yra išsibarstę po skaičiuokles, dirbtuvių dienoraščius, el. pašto grandines ir atskirus tachografų portalus, problema nėra tik administracija. Tai kontrolė.

Ką turi kontroliuoti kelių depų sistema vienoje vietoje

Daugelio depų atveju viena sistema turėtų laikyti visą operatoriaus licencijos įrašą transporto priemonių, priekabų, vairuotojų ir depų lygiu. Tai reiškia daugiau nei tik turtų ir galiojimo datų sąrašą. Tai reiškia gyvą atitikties failą, kuris atspindi, kaip jūsų flotilė iš tikrųjų veikia.

Pradėkite nuo pagrindinio turto registro. Kiekviena transporto priemonė ir priekaba turėtų turėti vieną įrašą su registracijos arba flotilės numeriu, depų paskirstymu, veiklos centru, mokesčių klase, jei tai aktualu, MOT arba metinio patikrinimo data, priekabų platinimo detalės, PMI arba saugos patikrinimo grafikas, odometro istorija, nuosavybės statusas ir dokumentų saugojimas. Jei vienetas perkeliamas iš vieno depų į kitą, istorija turėtų likti nepakitusi. Turėtumėte matyti, kur jis dabar yra, kur jis buvo anksčiau ir kurie patikrinimai ar trūkumai yra susiję su juo.

Vairuotojams reikia tokio paties požiūrio. Tinkamas įrašas turėtų apimti licencijų kategorijas, licencijos galiojimo datą, teisę dirbti, jei ją turite, Driver CPC terminus, DQC galiojimo datą, medicininius datums, jei taikoma, įvadinius įrašus, agentūros statusą, depų paskirstymą ir licencijų patikrinimų istoriją. Keleivių flotoms ir kai kurioms privačioms nuomos operacijoms vietinės valdžios įrašai taip pat gali būti svarbūs, tačiau pagrindinė JK operatorių licencijos padėtis išlieka ta pati. Jums reikia vairuotojo failo, kad parodytumėte dabartinę teisę ir aiškią peržiūros istoriją.

Patikrinimai ir priežiūros planavimas taip pat turi būti centralizuoti. JK prekių ir PSV operatoriams sistema turėtų planuoti saugos patikrinimus pagal jūsų deklaruotą priežiūros režimą ir DVSA Vadovą dėl kelių tinkamumo. Tai reiškia, kad reikia nustatyti patikrinimo intervalus pagal transporto priemonę arba flotilės grupę, planuoti pagal kalendoriaus datą ir rida, kai reikia, ir laikyti užbaigtų patikrinimų, stabdžių testų, remontų, techniko patvirtinimo ir bet kokių praleistų ar atidėtų įvykių įrašus. Jei jūsų dirbtuvės dirba pagal ISO savaitės planą, sistema turėtų tai palaikyti sklandžiai, kad depų komandos galėtų matyti, kas yra numatyta 32 savaitę, 33 savaitę ir taip toliau, nesukurdamos savo paralelinio planuotojo.

Tachografų įrodymai yra dar viena sritis, kur atskiros priemonės dažnai sukuria riziką. Neužtenka turėti analizę kažkur kitur ir tikėtis, kad kas nors prisijungs. Sujungta sistema turėtų laikyti vairuotojų ir transporto priemonių tachografų įrašus, pažeidimus, praleistą ridą ar neatskaičiuotas laikotarpius ir patvirtinimą, kad sekimas įvyko. Operatoriai turėtų galėti susieti tachografo vaizdą su vairuotojo failu ir atsakingu depu, o ne laikyti tai kaip atskirą atitikties salą. Jei lyginate variantus, mūsų vadovas apie tachografų analizę mažesnėms flotoms yra naudingas, nes tos pačios darbo srauto problemos taikomos didesniu mastu.

Flotoms, kuriose yra furgonų, teisinė struktūra nėra identiška HGV ir PSV operacijoms, tačiau valdymo poreikis yra panašus. Furgonai gali nesilaikyti tų pačių metinių patikrinimų ir tachografų reikalavimų kiekvienu atveju, tačiau operatoriai vis tiek turi turėti vieną patikrinimų, trūkumų, licencijų patikrinimų ir dokumentų kontrolės įrašą. Todėl daugelis mišrių operatorių ieško atitikties programinės įrangos furgonų flotoms, kuri gali būti šalia sunkesnių transporto priemonių vienoje sistemoje, o ne skirstyti flotilę pagal transporto priemonių tipą.

Kaip palyginti centrinę kontrolę su depų lygiu atsakomybe

Geriausios sistemos neįpareigoja rinktis tarp centrinių biuro kontrolės ir depų atsakomybės. Jos atskiria matomumą nuo leidimo.

Kai lyginate sistemas, pirmiausia atkreipkite dėmesį į vartotojų leidimus. Transporto vadybininkui viename depote gali prireikti pridėti trūkumus, užpildyti patikrinimų įrašus, priskirti vairuotojus ir pažymėti transporto priemonę VOR, tačiau ne redaguoti kitų depų įrašų ar keisti globalių nustatymų. Centriniam biurui gali prireikti grupės ataskaitų, audito prieigos ir eskalavimo teisių, tačiau netrukdyti vietinėms dirbtuvių pastaboms. Jei kiekvienas vartotojas mato viską ir gali redaguoti viską, neturite kontrolės. Jei tik vienas centrinis vartotojas gali atnaujinti įrašus, depų komandos grįš prie šoninių sistemų ir el. pašto.

Depų vaizdai yra tokie pat svarbūs. Planuotojas Birmingame turėtų galėti atidaryti informacijos suvestinę, kuri rodo tik Birmingamo transporto priemones, priekabas ir vairuotojus, su pradelstais elementais, artėjančiomis MOT arba metinio patikrinimo datomis, atvirais trūkumais, licencijų patikrinimais ir tachografų išimtimis, kurioms reikia veiksmų. Grupės valdymas turėtų galėti tai sujungti visiems depams, kad nustatytų tendencijas, pavyzdžiui, viename objekte nuolat praleidžiant PMI užbaigimą arba viename transporto biure atsilikus nuo Driver CPC sekimo.

Eskalacija yra ta vieta, kur daugelis sistemų tampa paviršutiniškomis. Lengva generuoti priminimus. Sunku įrodyti, kas įvyko, kai priminimas buvo ignoruotas. Naudinga atitikties sistema turėtų leisti jums apibrėžti, kas atsitinka, jei patikrinimas nėra užsakytas, jei trūkumas lieka atviras, jei DQC artėja prie galiojimo pabaigos, arba jei licencijos patikrinimas nebuvo atliktas. Audito takas turėtų rodyti numatytą datą, išsiųstą įspėjimą, kas jį gavo, ar jis buvo pripažintas ir kas jį eskalavo. Tai yra skirtumas tarp administracinės programinės įrangos ir atitikties kontrolės sistemos.

VOR tvarkymas nusipelno ypatingo dėmesio. Praktikoje VOR nėra tik dirbtuvių statusas. Tai operatyvinė kontrolė. Kai pranešama apie rimtą trūkumą, sistema turėtų leisti transporto priemonei ar priekabai būti pažymėtai VOR nedelsiant, užkirsti kelią atsitiktiniam uždarymui, užregistruoti priežastį, užregistruoti, kas taikė statusą, ir parodyti atleidimo sprendimą su data, laiku ir patvirtinimu. Jei depas gali pašalinti VOR statusą be remonto ar leidimo įrodymo, procesas yra silpnas. Jei centriniam biurui matomi VOR įvykiai, tačiau depų komandos vis tiek gali greitai veikti, turite geresnį balansą.

Transporto vadybininkai taip pat turi išlaikyti vietinę atsakomybę. Pagal JK sistemą, paskirti transporto vadybininkai turi tikrą atsakomybę už nuolatinį ir efektyvų valdymą. Centrinė sistema turėtų tai palaikyti, o ne sumaišyti. Teisingas klausimas nėra, ar centriniam biurui matyti viską. Tai yra, ar kiekvienas transporto vadybininkas gali parodyti kontrolę savo transporto priemonėms, vairuotojams ir priežiūros sutartims, tuo tarpu operatorius išlaiko priežiūrą visame licence.

Kokie įrašai yra svarbiausi, kai DVSA prašo įrodymų

Kai DVSA prašo įrodymų, greitis yra svarbus, tačiau struktūra yra dar svarbesnė. Turite pateikti įrašus, kurie yra pilni, aiškūs, datuoti ir priskirti asmeniui.

Pirmasis prioritetas yra prevencinės priežiūros įrašas. Kiekvienai transporto priemonei ir priekabai turėtumėte galėti pateikti patikrinimų planuotoją, užpildytus patikrinimų lapus, remonto įrašus, stabdžių testavimo įrodymus, jei jie yra, odometro rodmenis ir bet kokius praleistų patikrinimų ar intervalo pokyčių įrašus. Jei patikrinimas buvo pavėluotas, faile turėtų būti nurodyta, kodėl, kas patvirtino nukrypimą ir kas buvo padaryta, kad būtų valdomas rizika. Tuščias tarpas yra daug blogiau nei dokumentuota išimtis.

Dienos apžiūros ir trūkumų pranešimo įrašai yra kiti. Pasirašyti patikrinimai, ar tai būtų per programėlę, portalą ar užfiksuotą parašą, turi rodyti transporto priemonę, vairuotoją, datą, laiką ir praneštą būklę. Jei buvo rastas trūkumas, sistema turėtų susieti pranešimą su remontu ar priimtu sprendimu. Jei trūkumo nebuvo rasta, nulinio trūkumo įrašas vis tiek turėtų būti atsekamas. Kai kuriems operatoriams, ypač kai depai yra išsibarsčiusi, tai yra viena iš pirmųjų sričių, kur popierius dingsta. Sistema, kuri gali per kelias sekundes atkurti paskutinius 90 dienų patikrinimus konkrečiai transporto priemonei, atlieka tikrą darbą.

Vairuotojų licencijų patikrinimai ir DVLA patikrinimų istorija yra vienodai svarbūs. Jums reikia dabartinės teisės, ankstesnių patikrinimų datų, rezultatų ir bet kokių užrašytų apribojimų ar patvirtinimų. Agentūros vairuotojams ir atsitiktiniams darbuotojams įrašas vis tiek turėtų būti susietas su depu ir dirbtomis datomis. Jei vairuotojas buvo užkirstas kelią paskirstymui, nes patikrinimas buvo pavėluotas arba trūko licencijos kategorijos, tas sprendimas turėtų būti matomas. Tas pats taikoma Driver CPC ir DQC įrašams. Neužtenka žinoti galiojimo datą. Turite parodyti, kad atnaujinimas buvo stebimas ir sekamas.

Tachografų įrodymai dažnai lemia, ar failas atrodo kontroliuojamas, ar fragmentuotas. Stiprus audito takas parodys atsisiuntimus arba importuotą analizę, pažeidimų peržiūrą, praleistą ridą ar praleistus įrašus, vairuotojo pripažinimą, jei jis buvo naudojamas, ir valdymo veiksmus. Jei sistema negali susieti tachografo išimties su pavadinimu vairuotoju ir data peržiūrai, ji palieka per daug paaiškinimui po įvykio.

Taip pat turėtumėte tikėtis greitai pateikti dokumentų istoriją. Tai apima draudimo grafikus, OCRS susijusį vidinį stebėjimą, jei tai laikote, kalibravimo įrašus, jei tai aktualu, leidimų ar sertifikatų saugojimą ir korespondencijos pastabas. Draudimas gali būti kitoje komandoje, tačiau daugelis operatorių vis tiek naudinga patikrinti transporto priemonių draudimo detales su askMID, kuris yra viešoji paslauga, remiama Motor Insurers' Bureau, dar žinomo kaip MIB. Tai nepakeičia jūsų pačių politikos įrašų, tačiau gali padėti pastebėti akivaizdžius neatitikimus.

Operatoriams, kuriems reikia paruošti bylą viešajai apklausai ar formaliai peržiūrai, ta pati principas taikoma. Trafiko komisaras nebus sužavėtas ekrano nuotraukų rinkiniu be chronologijos. Jums reikia sistemos, kuri gali parodyti įvykių seką, vartotojų veiksmus, išimtis ir imtą korekcinę veiksmą.

Palyginant tachografus, licencijas ir priežiūros darbo srautus

Dažna pirkimo klaida yra palyginti modulius po vieną. Tachografas vienoje stulpelyje, licencijų patikrinimas kitame, priežiūros planuotojas trečiame. Toks požiūris praleidžia tikrąjį testą, kuris yra ar darbo srautai susijungia.

Paimkite paprastą pavyzdį. Vairuotojas patiria pakartotinius tachografų pažeidimus. Silpnoje sistemoje analizė yra viename portale, licencijos patikrinimas kitame, o mokymo įrašas skaičiuoklėje. Stipresnėje sistemoje transporto vadybininkas gali matyti pažeidimų modelį vairuotojo įraše, patvirtinti naujausią DVLA patikrinimą, peržiūrėti Driver CPC statusą, pridėti sekimo pastabas ir suplanuoti peržiūrą, neišeidamas iš atitikties darbo srauto.

Tas pats taikoma priežiūrai. Kasdienis trūkumas neturėtų dingti į dirbtuvių eilę be nuorodos atgal į pradinį patikrinimą. Jums reikia grandinės nuo pranešto trūkumo iki triage, iki VOR, jei reikia, iki remonto, iki patvirtinimo, iki transporto priemonės atleidimo. Jei patikrinimas numatytas, kai transporto priemonė yra ne kelyje, planuotojas turėtų tai atspindėti, o audito takas turėtų tai paaiškinti. Atskiri moduliai gali atrodyti pajėgūs demonstracijoje, tačiau jei jie nesidalina įvykiais ir statusais, jūsų komanda galiausiai turi atlikti sujungimą.

Licencijų ir teisių patikrinimai taip pat turėtų sąveikauti su paskirstymo sprendimais. Jei DQC galiojimas baigiasi, jei DVLA patikrinimas grąžina susirūpinimą, arba jei medicininė data yra pavėluota, sistema turėtų tai pažymėti toje pačioje vietoje, kur vairuotojas valdomas. Tai nereiškia, kad kiekviena sistema turi turėti pilną grafiko sudarymą. Tai reiškia, kad atitikties įspėjimai turėtų būti matomi ten, kur priimami operatyviniai sprendimai.

Išimčių tvarkymas dažnai yra ta vieta, kur geresnės sistemos atsiskiria. Paklauskite, kas atsitinka, kai transporto priemonė praleidžia patikrinimą, priekaba keičia depą, vairuotojas grįžta po ilgos pertraukos, arba tachografo įrašas dingsta, nes kortelė buvo prarasta arba sugadinta. Jei atsakymas yra „mes tai užrašome kitur“, darbo srautas yra nebaigtas. Jei atsakymas yra „išimtis užregistruota, priskirta, eskaluota ir uždaryta su įrodymais“, jūs žiūrite į kažką naudingesnio.

Tai viena iš priežasčių, kodėl operatoriai palygina sistemas praktiškai, o ne tik pagal funkcijų sąrašą. Mūsų sistemos palyginimo puslapis dėl flotilės atitikties programinės įrangos yra sukurtas aplink šį operatyvinį požiūrį, nes atitikties nesėkmės retai įvyksta viename modulyje.

Ką patikrinti diegiant, migracijoje ir integracijose

Įgyvendinimas yra ta vieta, kur geras pirkimo sprendimas vis dar gali būti neteisingas. Teisingas klausimas nėra tik tai, kiek laiko užtrunka diegimas. Tai yra, kiek atitikties rizikos yra perėjime.

Pradėkite nuo duomenų migracijos. Dauguma operatorių jau turi įrašus kažkur, skaičiuoklėse, dirbtuvių programinėje įrangoje, senose atitikties platformose, bendrose diskuose, popieriniuose patikrinimų lapuose arba atskiruose tachografų įrankiuose, tokiuose kaip Fleetalyse arba Logivo.AI. Prieš pasirinkdami sistemą, patvirtinkite, kas gali būti importuota. Turto sąrašai yra lengviausia dalis. Sunkesni klausimai yra, ar galite įtraukti istorinius patikrinimus, trūkumų istoriją, dokumentų galiojimo datas, vairuotojų įrašus, licencijų patikrinimų datas, Driver CPC ir DQC terminus, ir depų paskirstymus be visko perstatymo rankiniu būdu.

Taip pat turėtumėte paklausti, kaip sistema tvarko paveldėtus trūkumus. Jei jūsų esami duomenys yra nebaigti, diegimo procesas turėtų padaryti tuos trūkumus matomus, kad jie galėtų būti ištaisyti, o ne paslėpti masiniame importavime. Švarus paleidimas priklauso nuo aiškaus trūkstamų registracijos detalių, nebuvusių patikrinimų datų, dubliuotų vairuotojų įrašų ir nekonsekventiško depų pavadinimo valdymo.

Planavimo struktūra taip pat yra svarbi. Operatoriai, turintys išorinius priežiūros teikėjus, vidines dirbtuves ir mišrias flotiles, dažnai dirba pagal skirtingus ciklus. Jei jūsų planuotojai yra sukurti pagal ISO savaitės tvarkaraščius, įsitikinkite, kad sistema tai palaiko natūraliai. Jei ji veikia tik pagal fiksuotus mėnesinius intervalus, depų komandos gali baigti kurti atskirą sieninį planuotoją, kad išlaikytų kontrolę dėl faktinių užsakymų.

Integracijas verta patikrinti anksti, o ne po sutarties pasirašymo. Jei jau naudojate dirbtuvių programinę įrangą, telematikos, HR sistemas ar dokumentų įrankius, paklauskite, kokie ryšiai yra prieinami per REST API ir ar palaikomi webhooks statuso pokyčiams ir įvykių pranešimams. Tinkama integracija gali pašalinti dvigubą įrašymą naujoms transporto priemonėms, vairuotojų pradžiai, odometro atnaujinimams ar užbaigtiems remontams. Prasta integracija gali sukurti daugiau išimčių nei išsprendžia.

Kai kuriems operatoriams ryšiai su draudimo ir patikrinimo procesais taip pat yra svarbūs. Nors askMID nėra jūsų pačių įrašų pakaitalas, jis gali būti platesnio transporto priemonių užtikrinimo proceso dalis. Taksų ir privačių nuomos flotilės dažnai turi papildomų vietinių patikrinimų ir dokumentų reikalavimų, todėl jei vykdote tokio tipo operaciją, mūsų vadovas apie įrašų sistemas, kurios atlaiko patikrinimus taksi vairuotojams apima kai kurias praktines skirtumus.

Galiausiai, patikrinkite, ar sistema atitinka tai, kaip jūsų depai jau dirba, ar ji tikisi, kad visi pakeis darbus, kad atitiktų programinę įrangą. Geras atitikties platforma turėtų sustiprinti dirbtuvių kontrolę, transporto biuro sekimą ir valdymo ataskaitas, nesukeldama paralelinių skaičiuoklių atgal į naudojimą. Operator Compliance, sukurtas Fleeta Limited, mes suformavome OperatorCompliance aplink įrašus ir rutiną, kurių operatoriai iš tikrųjų turi pateikti pagal DVSA Vadovą dėl kelių tinkamumo, nes tai yra standartas, kurį jūsų sistema turi palaikyti, kai byla atidaroma ir klausimai prasideda.