Atitikties kalendoriaus programinė įranga, kuri mato terminus

Atitikties kalendorius padeda tik tada, jei jis atlieka dvi užduotis vienu metu. Jis turi matyti kiekvieną operatoriaus licencijos terminą pakankamai anksti, kad būtų galima imtis veiksmų, ir jis turi palikti tinkamą įrašą, kai darbas baigtas. JK transporto priemonėms tai reiškia daugiau nei tiesiog dienoraštis su priminimais. Tai reiškia veikiančią sistemą MOT ir metinių testų datoms, saugos patikroms, vairuotojų patikroms, tachografų apžvalgoms, Driver CPC ir DQC galiojimo pabaigai, ir įrodymams, kurie įrodo kontrolę DVSA ir, jei reikia, Transporto komisaro.

Štai kodėl daugelis operatorių pradeda ieškoti programinės įrangos transporto vadybininko atitikties kalendoriui ir pranešimams, kai skaičiuoklės ir Outlook nebeužtenka. Kai įrašai yra išskirstyti po pašto dėžutes, sienų planuotojus, dirbtuvių lapus ir atskiras programas, terminus tampa sunkiau pasitikėti. Rizika yra ne tik praleista data. Tai taip pat reiškia, kad negalima parodyti, kas tikrino ką, kada tai buvo patvirtinta ir kas nutiko, kai buvo rasta problema.

Ką transporto vadybininkai nori iš atitikties kalendoriaus

JK operatoriaus atitikties kalendorius turi atspindėti realias užduotis, kurios slypi už operatoriaus licencijos. Tai nėra tik vieta datoms saugoti. Jis turėtų sekti įsipareigojimus visiems transporto priemonėms, priekaboms ir vairuotojams, ir tai turėtų daryti taip, kad atitiktų, kaip transporto vadybininkai dirba kasdien.

Mažiausiai tikimės, kad sistema turės ir rodys:

• MOT terminai
• metinių testų datos atitinkamoms transporto priemonėms
• planuojamų saugos patikros intervalų datos
• prevencinės priežiūros patikros
• vairuotojų kasdieniai apžiūros patikrinimai
• vairuotojų licencijos patikros datos
• Driver CPC galiojimo pabaiga
• DQC galiojimo pabaiga
• tachografų atsisiuntimo tvarkaraščiai
• tachografų analizės peržiūros užduotys
• draudimo ir kitų palaikančių dokumentų datos, kurias operatorius nori stebėti

JK prekių ir keleivių operatoriams priežiūros pusė paprastai yra pirmasis spaudimo taškas. Transporto priemonėms ir priekaboms reikia aiškaus patikros tvarkaraščio, su datomis, matomomis pagal parką, depą ir turtą. Transporto vadybininkas turėtų matyti, kas yra numatyta šiai savaitei, kas yra pavėluota ir kas yra užsakyta. Jei transporto priemonė keičia naudojimą ir jos patikros intervalas turi būti sutrumpintas, kalendorius turėtų prisitaikyti, nesukeldamas painiavos audito pėdsake.

MOT ir metinių testų datos taip pat turi būti tinkamai tvarkomos. Praktikoje operatoriai dažnai turi matyti tiek griežtą terminą, tiek planavimo langą prieš jį. Tik data nėra pakankama. Naudingas klausimas yra, ar yra pakankamai laiko užsakyti laiką, atlikti bet kokius paruošiamuosius darbus ir valdyti prastovas, nesukeliant sutrikimų operacijai.

Vairuotojų atitiktis atneša kitą terminų rinkinį. Driver CPC ir DQC galiojimo pabaiga yra akivaizdūs pavyzdžiai, tačiau kalendorius taip pat turėtų palaikyti įprastą licencijų tikrinimą ir bet kokį vidinį peržiūros ciklą, kurį operatorius naudoja. Daugelis parkų taip pat nori suplanuoti įvadus, politikos pripažinimus, regėjimo patikras ar agentūros vairuotojų dokumentų peržiūras toje pačioje vietoje, kad transporto biuras nesiremti atmintimi.

Tachografų darbas yra dar viena sritis, kur paprastas dienoraštis dažnai sugenda. Terminai nėra tik metiniai ar mėnesiniai. Tai yra pasikartojančios operatyvinės užduotys, tokios kaip užtikrinti, kad atsisiuntimai vyktų pagal tvarkaraštį, pažeidimai būtų peržiūrėti ir sekimo veiksmai būtų užfiksuoti. Geras kalendorius turėtų iškelti šiuos kaip gyvas užduotis, o ne paslėpti juos ataskaitoje, kurios niekas neatidaro, kol ne per vėlai.

Tai svarbu, nes JK atitikties padėtis yra dokumentais paremta. DVSA nepriims, kad data buvo kažkieno galvoje, ar kad dirbtuvės „paprastai prisimena“. Jei priežiūros planuotojas yra nebuvęs, jei transporto vadybininkas keičiasi, ar jei agentūros vairuotojas prisijungia trumpai, sistema vis tiek turi rodyti, kas yra numatyta ir kas buvo atlikta.

Kur operatoriai dirba tiek JK, tiek ES veikloje, taip pat naudinga aiškiai žinoti, kad kai kurie taisyklių ir įrodymų lūkesčiai sutampa, tačiau operatoriaus licencijos sistema ir kaip ji yra tikrinama DVSA ir Transporto komisaro, yra JK reikalas. Jūsų kalendorius turi palaikyti šią JK veiklos realybę.

Kokios pranešimų funkcijos iš tikrųjų sumažina praleistus terminus?

Pranešimai yra naudingi, kai jie skatina veiksmus. Jie nėra naudingi, kai sukelia triukšmą, atvyksta per vėlai arba siunčiami neteisingam asmeniui. Geriausia programinė įranga transporto vadybininko atitikties kalendoriui ir pranešimams suteikia operatoriams kontrolę dėl laiko, atsakomybės ir eskalacijos.

Pirmas dalykas, kurį reikia ieškoti, yra išankstinio įspėjimo laikotarpiai, kurie atitinka užduoties tipą. Ne kiekvienam terminui reikia tokio paties įspėjimo. Driver CPC galiojimo pabaiga gali reikalauti daug ilgesnio įspėjimo laikotarpio nei savaitinė patikra. MOT užsakymas gali reikalauti etapu priminimų, vieno gerokai iš anksto planavimui, kito arčiau datos, kad patvirtintų užsakymą, ir galutinio pranešimo, jei rezultatas nebuvo užfiksuotas.

Pasikartojantys priminimai yra tokie pat svarbūs. Vienkartinis pranešimas lengva praleisti. Užduotims, kurios lieka atviros, sistema turėtų tęsti priminimus, kol darbas bus baigtas arba sąmoningai perplanuotas. Tai ypač svarbu įprastoms patikroms, licencijų patikroms ir tachografų peržiūroms, kur rizika yra ne pamiršti vieną kartą, bet palaipsniui normalizuoti delsimo.

Pareigoms pritaikyti pranešimai yra dar viena praktinė reikalavimų dalis. Transporto vadybininkas neturi gauti kiekvieno dirbtuvių atnaujinimo, jei parkų inžinierius jau tuo rūpinasi. Lygiai taip pat dirbtuvės neturėtų būti vienintelė komanda, kuri gauna pranešimą apie transporto priemonės terminą, kuris veikia išsiuntimą. Geras pranešimas leidžia mums nukreipti tinkamą žinutę tinkamai pareigai, pvz., transporto biurui, dirbtuvėms, atitikties administratoriui, depų vadovui arba vairuotojų vadovui.

Operatoriams, turintiems daugiau nei vieną vietą, matomumas pagal vietą taip pat yra svarbus. Centrinis transporto vadybininkas gali reikėti viso parko vaizdo, tuo tarpu vietiniai vadybininkai nori gauti pranešimus tik savo depui. Jei visi mato viską, žmonės pradeda ignoruoti pranešimus, nes dauguma jų nėra aktualūs.

VOR matomumas yra viena naudingiausių funkcijų praktikoje. Jei transporto priemonė pažymėta VOR, kalendorius turėtų tai aiškiai parodyti prieš artėjančias užduotis ir užsakymus. Tai padeda išvengti dažnos problemos, kai transporto priemonė atrodo „padengta“, nes egzistuoja patikros data, kai iš tikrųjų ji yra ne kelyje laukdama remonto, ir niekas neperplanuoja atitikties darbo pagal tą statusą.

Eskalacija yra vieta, kur dauguma pagrindinių sistemų nepavyksta. Jei užduotis nebaigta iki jos termino, programinė įranga turėtų daryti daugiau nei tiesiog pakeisti eilutę raudona. Ji turėtų eskaluoti kitam atsakingam asmeniui arba išplėsti matomumą, kad praleista užduotis negalėtų likti nepastebėta. Tai gali reikšti pranešimą transporto vadybininkui, jei vairuotojo dokumentas nebuvo patikrintas, arba pranešimą vyresniajam vadybininkui, jei saugos patikra lieka nepanaikinta po termino.

Geriausias pranešimas taip pat skiria tarp numatytų, pavėluotų ir užblokuotų. Užduotis gali būti pavėluota, nes ji buvo praleista. Ji taip pat gali būti užblokuota, nes transporto priemonė yra VOR, dokumentas laukia iš agentūros, arba dirbtuvių užsakymas buvo perkelta. Tai skirtingos operatyvinės būsenos ir joms reikia skirtingų valdymo atsakymų.

El. pašto pranešimai išlieka naudingi, ypač vadybininkams, kurie gyvena savo pašto dėžutėje. Mes tai išsamiau aptariame savo gide apie fleeto programinę įrangą, kuri žymi atitikties terminus el. paštu. Tačiau el. paštas vienas nėra pakankamas. Pranešimai taip pat turėtų būti matomi sistemos valdymo skydelyje, užduočių sąrašuose ir mobiliuosiuose įrenginiuose, kur tai reikalauja pareiga.

Kodėl įrodymai ir patvirtinimai yra tokie pat svarbūs kaip priminimai

Priminti sako, kad kažkas turėtų įvykti. Įrodymai rodo, kad tai įvyko, kas tai padarė, ką jie rado ir kas nutiko toliau. Operatorius-licencijos darbui antra dalis dažnai yra skirtumas tarp tvarkingo valdymo skydelio ir gynybinio atitikties įrašo.

Jei saugos patikra suplanuota, sistema neturėtų sustoti ties terminu. Ji turėtų saugoti patikros įrašą, bet kokius defektų užrašus, taisymo detales, patvirtinimą ir datą, kada transporto priemonė buvo grąžinta į eksploataciją. Jei vairuotojo apžiūros patikra baigta, mums reikia užpildyto kontrolinio sąrašo, laiko, deklaracijos, bet kokių praneštų defektų ir atliktų veiksmų. Jei vairuotojo licencija tikrinama, mums reikia rezultato ir peržiūros datos, o ne tik varnelės kalendoriuje.

Štai kodėl mes kalendorių laikome viena iš platesnio atitikties įrašo dalių. Transporto vadybininkas gali tekti parodyti Transporto komisarui ne tik tai, kad priminimai egzistavo, bet ir tai, kad operatorius laikėsi sistemos ir išlaikė kontrolę. Švarus audito pėdsakas yra svarbus. Užrašai yra svarbūs. Dokumentų versijos yra svarbios. Parašai yra svarbūs.

Tai ypač svarbu, kai randamos problemos. Praeities rezultatas lengva užfiksuoti. Tikras sistemos išbandymas yra tai, kas nutinka, kai yra defektas, pažeidimas, praleista patikra ar pasibaigęs dokumentas. Ar galime aiškiai matyti išimtį? Ar galime pridėti palaikančius failus? Ar galime užfiksuoti, kas tai peržiūrėjo, kokia buvo priimta sprendimas ir ar atsakingas asmuo buvo sekamas?

Tachografų darbui įrodymai dažnai yra svarbesni už patį priminimą. Data atsisiųsti arba peržiūrėti duomenis yra tik pradžia. Mes taip pat turime išlaikyti analizės rezultatą, bet kokią pažeidimo peržiūrą, vairuotojo pripažinimą, kai naudojamas, ir valdymo veiksmą, jei atsiranda modeliai. Be to, operatorius gali žinoti, kad peržiūra buvo numatyta, tačiau negali parodyti prasmingo priežiūros.

Tas pats taikoma vairuotojų akreditacijoms. DQC galiojimo pabaigos priminimas yra naudingas, tačiau įrašas taip pat turėtų turėti atnaujintą dokumentą ir naują galiojimo laikotarpį. Driver CPC valdymas nėra tik apie galiojimo datos stebėjimą. Tai apie dabartinio, atsektino failo išlaikymą.

Tai tampa dar svarbiau atliekant auditus, tyrimus ar licencijų paraiškas ir variacijas per VOL. Įrašai, kurie yra išskirstyti po el. pašto grandinėmis, bendrais diskais ir popieriniais aplankais, yra lėti atgauti ir lengvai iššūkiams. Viena sistema su datų istorija, priedais, užrašais ir patvirtinimais yra daug lengviau remtis. Mes tai išsamiau nagrinėjame savo straipsnyje apie keliamųjų įrašų programinę įrangą, kuri atlaiko auditą.

Kaip palyginti viskas viename sistemas su atskiromis priemonėmis

Daugelis operatorių pradeda nuo atskirų įrankių, nes kiekvienas iš jų sprendžia skubią problemą. Skaičiuoklė seka patikros datas. Outlook siunčia priminimus. Dirbtuvių paketas saugo priežiūros lapus. Tachografų tiekėjas tvarko analizę. Vairuotojų failai yra bendrame diske. Tai gali veikti kurį laiką, tačiau sukuria perdavimus, dubliuotą įrašą ir aklumas.

Pagrindinis klausimas nėra tai, ar atskiros priemonės gali atlikti individualias užduotis. Tai yra, ar jos suteikia transporto vadybininkams vieną patikimą atitikties statuso vaizdą visame parke.

Skaičiuoklės yra lanksčios, tačiau jos labai priklauso nuo disciplinos. Datas reikia atnaujinti rankiniu būdu. Pasikartojančios užduotys gali būti sulaužytos dėl rūšiavimo klaidų arba kopijuotų formulių. Paprastai nėra įmontuoto patvirtinimo, nėra teisių pagal pareigas ir nėra patikimos audito istorijos. Jei vienas asmuo palaiko lapą ir tas asmuo yra išvykęs, procesas dažnai sustoja.

Outlook kalendoriai yra naudingi asmeniniams priminimams, tačiau jie yra silpni kaip atitikties sistema. Jie natūraliai nelaiko transporto priemonių įrašų, defektų įrodymų, patikros formų ar susijusių vairuotojų dokumentų. Jie taip pat susiduria su sunkumais, kai ta pati užduotis turi matomumą tarp dirbtuvių, transporto ir valdymo komandų.

Atjungtos specializuotos programos gali būti geresnės už skaičiuokles savo srityje, tačiau jos vis tiek palieka operatorius rankiniu būdu suderinti informaciją. Transporto priemonė gali būti pažymėta kaip baigta priežiūros programoje, tačiau vis tiek rodyti pavėluotą biuro planuotojui. Vairuotojas gali atnaujinti DQC, tačiau nebent kas nors atnaujina centrinį įrašą, transporto vadybininkas vis tiek žiūri į seną galiojimą.

Viskas viename sistema turėtų sumažinti tą fragmentaciją. Mes norime vieno įrašo kiekvienai transporto priemonei, priekabai ir vairuotojui, vieno tiesos šaltinio terminams ir vienos vietos matyti įrodymus už priminimą. Tai nereiškia, kad kiekvienas operatorius turi turėti kiekvieną funkciją įjungtą nuo pirmos dienos. Tai reiškia, kad struktūra yra ten, kai parkas auga arba audito našta didėja.

Specializuota operatoriaus-licencijos atitikties programinė įranga taip pat turėtų atspindėti transporto realybę. Ji turėtų suprasti metinių testų planavimą, VOR statusą, pasikartojančias patikras, tachografų sekimą ir poreikį greitai pateikti įrašus DVSA. Bendros užduočių programos retai tai daro gerai.

Tuo pačiu metu, viskas viename nereiškia, kad ji turi būti uždara. Kai kurie operatoriai vis dar reikės duomenų, kurie teka į atlyginimų, telematikos, dirbtuvių sistemas ar verslo intelekto įrankius. Čia svarbios integracijos, įskaitant REST API ryšius ir webhook'us įvykių pagrindu atnaujinimams.

Mes pateikėme išsamesnę palyginimą kaip palyginti atitikties sistemas JK transporto vadybininkams, tačiau trumpa versija yra paprasta. Jei jūsų dabartinė sistema priklauso nuo žmonių prisiminti atnaujinti kelias vietas, ji neša daugiau rizikos, nei atrodo.

Ką patikrinti prieš pasirenkant programinę įrangą JK parkui

Pradėkite nuo tinkamumo darbui. Programinė įranga turėtų palaikyti operatoriaus-licencijos įsipareigojimus, kuriuos iš tikrųjų valdote, o ne tik bendrą parko administravimą. JK operatoriams tai apima priežiūros planavimą, vairuotojų dokumentų kontrolę, tachografų susijusias užduotis ir įrašų struktūrą, kuri atitinka DVSA Gidą dėl kelių tinkamumo išlaikymo.

Paprastumas yra svarbesnis už funkcijų skaičių. Jei dirbtuvių darbuotojai, transporto administratoriai ir vadybininkai negali greitai naudotis sistema, įrašai vėl grįš į popierių ir el. paštą. Atidžiai pažvelkite, kaip užduotys yra atliekamos, kaip įrodymai yra pridedami ir kaip pavėluoti elementai yra rodomi. Tvarkingas pardavimo demonstravimas nėra pakankamas. Paprašykite pamatyti darbo eigą praleistai patikrai, defekto taisymui ir atnaujintam DQC.

Įdiegimo pastangos yra dar vienas praktinis aspektas. Transporto priemonių, priekabų, vairuotojų ir istorinių datų importavimas gali užtrukti. Patikrinkite, kokie duomenys gali būti įkelti dideliais kiekiais, kokie numatyti nustatymai gali būti nustatyti pagal parko tipą ir kaip yra kuriami pasikartojantys tvarkaraščiai. Jei jūsų operacija planuoja pagal ISO savaitę, programinė įranga turėtų tai palaikyti sklandžiai, o ne priversti ieškoti sprendimų.

Ataskaitos turi būti paprastos. Transporto vadybininkai turėtų galėti gauti pavėluotų sąrašų, artėjančių terminų, patikros istorijos, vairuotojų dokumentų būsenos ir tachografų sekimo be sudėtingų eksportų. Jei vadybininkas ruošiasi vizitui, jam neturėtų prireikti analitiko, kad sudarytų failą.

Mobili prieiga yra svarbi, kai patikros vyksta toli nuo stalo. Vairuotojų apžiūros, dokumentų fiksavimas, defektų pranešimas ir patvirtinimas yra daug stipresni, kai atliekami šaltinyje. Autobusų ir mikroautobusų, furgonų ir kurjerių operacijose mobilios darbo eigos dažnai lemia skirtumą tarp tą pačią dieną užfiksuotų įrašų ir savaitės pabaigos atnaujinimų.

Integracijas verta patikrinti anksti. Jei jums reikia ryšių su kitomis sistemomis, klauskite konkrečiai apie REST API prieigą ir webhook'us, o ne tik ar tiekėjas sako, kad jis „integruojasi“. Yra tikras skirtumas tarp tinkamo duomenų sąsajos ir rankinio CSV proceso, apsirengusio kaip integracija.

Duomenų šaltiniai ir patikros taip pat yra svarbūs. Kai kurie parkai nori kryžminio transporto priemonių detalių, draudimo būsenos ar incidentų tvarkymo su kitomis paslaugomis. Priklausomai nuo jūsų proceso, tai gali apimti askMID duomenis iš Motor Insurers' Bureau, dar vadinamo MIB. Kiti gali norėti ryšių su tokiais įrankiais kaip Fleetalyse arba Logivo.AI. Pagrindinis dalykas yra tai, ar atitikties platforma gali protingai sėdėti sistemose, kuriomis jau pasikliaujate.

Galiausiai, patikrinkite operatyvinį patikimumą už produkto. Mes sukūrėme Operator Compliance per Fleeta Limited, ir mes sukūrėme ją aplink tai, kaip operatoriaus-licencijos darbas iš tikrųjų yra valdoma pagal DVSA sistemą. Tai svarbu, nes atitikties programinė įranga nėra tik duomenų bazė. Tai kontrolės sistema. Jei ji neatspindi, kaip transporto vadybininkai planuoja patikras, valdo VOR transporto priemones, peržiūri tachografų problemas ir išlaiko įrašus Transporto komisaro failui, ji sukurs darbą, o ne jį pašalins.

Jei dabar peržiūrite galimybes, mūsų puslapis transporto vadybininkams, kuriems reikia vienos vietos atitikties terminams ir įrašams rodo, kaip mes struktūrizuojame šias užduotis OperatorCompliance.