Pasirinkite laivyno priminimo sistemą, kuri laiku vykdo testus

Jei renkatės priminimo sistemą JK laivynui, pagrindinis testas yra paprastas. Ar ji tik praneš jums, kad artėja data, ar padės įrodyti, kad transporto priemonės, priekabos ir vairuotojų įrašai, susiję su ta data, buvo tinkamai tvarkomi? Daugumai operatorių tai yra skirtumas tarp dienoraščio įrankio ir atitikties sistemos.

Tinkama MOT, metinių testų ir saugos patikrinimų sistema turėtų daryti daugiau nei siųsti pranešimus. Ji turėtų laikyti patikrinimų grafiką, saugoti užpildytus įrašus, rodyti, kas juos patvirtino, sekti trūkumus iki remonto ir suteikti jums švarų failą, jei DVSA (Kelių transporto saugos agentūra) ar Transporto komisaras paprašys įrodymų. Tai yra standartas, kurio laikomės Operator Compliance, nes praleisti datą yra tik viena rizikos dalis. Didesnė problema dažnai yra nesugebėjimas parodyti kontrolės.

Ką turi apimti priminimo sistema JK operatoriams

JK operatoriams reikalinga priminimo sistema, kuri atspindi, kaip veikia operatorių licencijos atitiktis. Prekių ar keleivių laivynas ne tik tvarko MOT datas. Jis tvarko susijusias pareigas, susijusias su transporto priemonėmis, priekabomis, vairuotojais ir įrašais.

Transporto priemonėms akivaizdžios datos yra MOT arba metinis testas, priklausomai nuo transporto priemonės tipo ir režimo. Bet jos yra šalia suplanuotų prevencinių techninės priežiūros patikrinimų, stabdžių testų, kai to reikalauja jūsų techninės priežiūros sutartis, mokesčių, draudimo ir bet kokių vidinių peržiūros datų, kurias naudojate techninės priežiūros teikėjo veiklos vertinimui. Jei dirbate pagal operatoriaus licenciją, jūsų patikrinimų intervalai ir įrodymų sekimas yra tokie pat svarbūs kaip ir jūsų testų datos.

Priekaboms sistema turi sekti patikrinimų grafikus, metinius testus, jei taikoma, ir priekabos istoriją atskirai nuo ją traukiančio vieneto. Čia dažnai nepavyksta pagrindinėms priminimo priemonėms. Priekabą lengva praleisti, jei sistema buvo sukurta tik aplink registracijos numerius. Operatoriai su mišriomis priekabų grupėmis turi turėti įrašus pagal turtą, o ne tik pagal transporto priemonę.

Vairuotojams priminimai paprastai turi apimti licencijų patikras su DVLA (Vairuotojų ir transporto priemonių agentūra), Driver CPC (Vairuotojų profesinio mokymo) galiojimo pabaigą, DQC (Vairuotojų kvalifikacijos kortelės) galiojimo pabaigą, tachografo kortelių datas, paso ar teisės dirbti datas, jei tai svarbu jūsų procesui, ir bet kokius įmonės specifinius mokymus ar įvadinius kursus. Priminimas yra naudingas, tačiau įrodymai yra tai, kas jus apsaugo. Jūs turite parodyti, kad patikra buvo atlikta, kas buvo rasta ir kada buvo atliktas sekimas.

JK operatoriui taip pat reikia darbo proceso, o ne tik datų. Jei saugos patikrinimas numatytas kitą savaitę, sistema neturėtų tik pranešti jums. Ji turėtų rodyti, ar užsakymas buvo atliktas, ar patikrinimo lapas buvo grąžintas, ar trūkumai buvo užfiksuoti, ar remontai buvo atlikti, ir ar transporto priemonė turėtų būti pažymėta VOR (neveiklus) laukiančiam patvirtinimui. Jei data praeina be užpildytos dokumentacijos, sistema turėtų tai padaryti akivaizdu.

Įrašai yra svarbūs, nes Transporto komisaras paprastai neklausia, ar ketinote laikytis taisyklių. Jie klausia, kokios buvo jūsų sistemos, kas įvyko praktikoje ir kokius įrodymus galite pateikti. Tai reiškia dokumentų saugojimą, audito takus, užpildytus patikrinimo formas, trūkumų žurnalus, patvirtinimo istoriją ir galimybę greitai atkurti failą.

JK prekių ir keleivių operatoriams taip pat yra skirtumas nuo bendro ES laivyno konteksto. Sistema turi palaikyti operatorių licencijos modelį, naudojamą čia, įskaitant lūkesčius dėl techninės priežiūros planavimo, patikrinimų įrašų ir įrodymų, kuriuos gali tekti pateikti per VOL (Transporto priemonių registracijos sistema) arba per DVSA tyrimą. Bendroji laivyno platforma, sukurta pan-europiniam planavimui, gali pakankamai gerai apimti aptarnavimo intervalus, tačiau vis tiek gali praleisti įrašus ir įrodymus, kurie tikimasi JK operatorių licencijos aplinkoje.

Kaip pagrindiniai priminimai lyginami su atitikties pagrindu veikiančiomis laivyno sistemomis

Skaičiuoklė dažnai yra vieta, kur laivynai pradeda. Ji yra pažįstama, pigi ir lanksti. Labai mažai veiklai ji gali veikti tam tikrą laiką. Galite išvardyti numatytas datas, spalvų koduoti pradelstas prekes ir dalintis failu viduje. Problema yra kontrolė. Skaičiuoklė neįgyvendina proceso. Ji nesurenka užpildytų patikrinimo lapų, trūkumų taisymo, parašų ar patikimo audito tako. Ji priklauso nuo disciplinos ir tampa trapia, kai daugiau nei vienas asmuo ją atnaujina.

Bendri kalendoriai yra dar lengvesni. Jie gali pagerinti testų užsakymų ir aptarnavimo datų matomumą, tačiau jie iš tikrųjų yra tik skelbimų lentos. Jie nesusieja įvykio su transporto priemonės istorija, priekabos failu, trūkumų įrašu ar vairuotojo įrodymais. Jei kas nors išeina, pakeičia kalendoriaus įrašą arba pamiršta pridėti dokumentus, atitikties takas nutrūksta.

Dirbtuvės programinė įranga gali būti stipresnė techninės priežiūros planavime ir darbo kontrolėje. Jei jūsų teikėjas užsako patikrinimus, registruoja atliktą darbą ir išrašo sąskaitas per vieną platformą, tai gali padėti dirbtuvės matomumui. Tačiau dirbtuvės sistemos paprastai yra sukurtos aplink remonto veiklą, o ne operatorių licencijos įrodymus. Jos gali nesugebėti tvarkyti vairuotojų patikrinimų, tachografo įrašų, priekabų atitikties, DQC galiojimo pabaigos ar ataskaitų, kurių reikia transporto vadybininkui visam laivynui.

Atitikties pagrindu veikianti laivyno sistema yra kitokia, nes ji sukurta aplink operatoriaus įsipareigojimus, o ne tik aplink dirbtuvės dienoraštį. Ji turėtų rodyti, kas yra numatyta, kas yra pradelsta, kokių įrodymų trūksta ir kas buvo patvirtinta. Ji turėtų susieti priminimą su įrašu ir įrašą su audito taku.

Čia tinka tokia sistema kaip OperatorCompliance. Mes ją sukūrėme per Fleeta Limited, remdamiesi DVSA (Kelių transporto saugos agentūra) Gidu dėl kelių tinkamumo palaikymo ir praktiniais operatorių poreikiais, dirbantiems pagal operatoriaus licenciją. Tai reiškia, kad priminimas yra tik viena kontrolės dalis. Svarbesnė dalis yra galimybė parodyti nuoseklų procesą patikrinimams, trūkumams, vairuotojų patikrinimams ir palaikomiems dokumentams.

Kiekviendienis praktiškumas taip pat yra svarbus. Atitikties pagrindu veikianti sistema turėtų sumažinti dubliavimą, o ne sukurti daugiau jo. Jei vairuotojas praneša apie trūkumą, tai turėtų patekti į transporto priemonės įrašą. Jei transporto priemonė pažymėta VOR, planuotojai ir vadybininkai turėtų matyti šią būseną. Jei patikrinimas baigtas, pasirašytas lapas turėtų būti priskirtas turtui, o ne kažkam ieškant per el. pašto aplankus.

Jei lyginate lengvas priemones su pilnos atitikties platformomis, naudinga perskaityti kaip priminimo programėlės palaiko mažą laivyną auditui pasiruošusį ir kaip viena sistema gali laikyti patikrinimus, planuotojus ir O-licencijos įrodymus kartu. Praktinis atotrūkis dažnai nėra pats pranešimas. Tai viskas, kas turi įvykti aplink jį.

Svarbiausios funkcijos MOT, metiniams testams ir patikrinimams

Kai lyginate sistemas, pradėkite nuo planavimo. Jums reikia pasikartojančių patikrinimų grafikų, kurie atitinka jūsų suplanuotus techninės priežiūros intervalus, su lankstumu skirtingiems turto tipams. Kai kurie operatoriai planuoja pagal kalendoriaus datas, kai kurie pagal ISO savaites, o kai kurie reikia abiejų, priklausomai nuo laivyno ir dirbtuvių sutvarkymo. Sistema turėtų susidoroti su vienetais, priekabomis ir skirtingais patikrinimų dažnumais be nepatogių sprendimų.

Datos priminimai turėtų apimti MOT ir metinį testą, bet taip pat pirmo naudojimo datas, mokesčius, draudimą, kalibravimo ar LOLER datas, jei jos svarbios jūsų veiklai, ir vidinių peržiūrų terminus. Jūs turėtumėte galėti nustatyti įspėjimo laikotarpius, kurie atitinka, kaip užsakote darbą realiame gyvenime.

Trūkumų valdymas yra viena iš aiškiausių ribų tarp pagrindinių ir rimtų sistemų. Geras platforma turėtų registruoti praneštus trūkumus, priskirti atsakomybę, sekti remonto pažangą ir laikyti taisymo įrodymus. Ji taip pat turėtų palaikyti nulinio trūkumų ataskaitą, jei tai yra jūsų proceso dalis. Jei trūkumas veikia kelių tinkamumą, sistema turėtų palengvinti turto pažymėjimą VOR ir išlaikyti šią būseną matomą iki išleidimo.

Patvirtinimas yra taip pat svarbus. Patikrinimo lapai ir trūkumų taisymai neturėtų dingti į nuskaitymo aplanką be nuosavybės. Jūs norite, kad būtų nurodyti patvirtinimai, datos ir laiko žymės, ir aiškus takas, rodantis, kas buvo rasta, kas buvo padaryta ir kas priėmė transporto priemonę atgal į eksploataciją. Jei kada nors būsite paprašyti paaiškinti praleistą patikrinimą ar pakartotinį trūkumą, ta istorija yra svarbi.

Priekabų sekimas reikalauja tinkamo dėmesio. Sistema turėtų vertinti priekabas kaip pirmo lygio turtą, su savo grafiku, patikrinimais, dokumentais ir testų istorija. Operatoriai su bendromis priekabų grupėmis žino, kaip lengvai atitiktis prarandama, kai viskas organizuojama tik aplink varomas transporto priemones.

Dokumentų saugojimas turėtų būti integruotas, o ne pridėtas. Jūs turėtumėte galėti saugoti patikrinimo lapus, MOT sertifikatus, metinių testų dokumentus, techninės priežiūros sutartis, draudimo dokumentus, vairuotojų įrašus ir korespondenciją prieš atitinkamą turtą ar asmenį. Paieška ir atkūrimas turi būti greiti, nes saugojimo tikslas nėra tik archyvavimas. Tai galimybė pateikti įrodymus, kai to reikia.

Vairuotojų atitikties funkcijos taip pat veikia, kaip naudingas priminimo sistema iš tikrųjų yra. Jei ta pati platforma gali sekti DVLA licencijų patikras, Driver CPC ir DQC galiojimo pabaigą, tachografo analizės įrašus ir pažeidimų pripažinimą, jūs išvengiate įrodymų skaidymo tarp kelių įrankių.

Ataskaitos yra svarbios transporto vadybininkams. Jūs turėtumėte galėti matyti artėjančius numatytus elementus, pradelstus įrašus, pakartotinius trūkumus, trūkstamus dokumentus ir turto būseną vienu žvilgsniu. Geriausios sistemos taip pat palengvina įrodymų paruošimą techninės priežiūros failui, vidinei audito ataskaitai ar Transporto komisaro posėdžio rinkiniui.

Integracija taip pat gali būti svarbi. Jei jūsų verslas jau turi vidines sistemas, paklauskite, ar platforma siūlo REST API arba webhooks, kad atitikties įvykiai galėtų maitinti kitas darbo eigas. Mes tai išsamiau aprašome mūsų gide, kaip integruoti atitiktį į savo sistemas su webhooks.

Galiausiai, patikrinkite, ar sistema palaiko praktinius duomenų patikrinimus, kurie yra susiję su atitiktimi. Pavyzdžiui, kai kurie operatoriai nori draudimo patvirtinimo pagal askMID duomenis iš Motor Insurers' Bureau, dar žinomo kaip MIB, kaip dalį savo laivyno kontrolės proceso. Tai gali nebūti pirmas bruožas, kurį lyginate, tačiau tai gali būti svarbu mišriose ar subrangovų operacijose.

Kaip lyginti sistemas skirtingiems laivyno tipams

Ne kiekvienam laivynui reikia tokios pačios konfigūracijos, net jei pagrindiniai atitikties principai yra tokie patys.

Vežėjams dažniausiai reikia stipriausios priekabų kontrolės, techninės priežiūros planavimo ir tachografo įrodymų. Jie dažnai turi kelis patikrinimų teikėjus, nuomojamą turtą, agentūros vairuotojus ir besikeičiančias priekabų allocations. Jiems sistema turi atskirai tvarkyti vienetus ir priekabas, išlaikyti dirbtuvių įrodymus organizuotus ir rodyti aiškią techninės priežiūros istoriją visame laivyne.

Furgonų laivynai dažnai pradeda su lengvesniais reikalavimais, ypač žemiau operatorių licencijos ribų, tačiau vis tiek jiems reikia kontrolės dėl patikrinimų, aptarnavimo, padangų, trūkumų ir vairuotojų patikrinimų. Jei dirbate su sunkesniais furgonais arba veikiate pagal prekių transporto operatoriaus licenciją, poreikis tampa daug artimesnis vežimo modeliui. Mes išdėstome pagrindinius skirtumus mūsų gide, kaip palyginti furgonų laivyno atitikties sistemas JK ir mūsų puslapyje furgonų laivyno atitikties poreikiams.

Autobusų ir mikroautobusų operatoriai reikalauja tokios pačios disciplinos techninės priežiūros ir metinių testų srityje, tačiau dažnai su griežtesniais ryšiais su paslaugų patikimumu, apžvalgos patikrinimais ir keleivių saugos procesais. Sistema turi tinkamai palaikyti keleivių laivyno įrašus, o ne tiesiog pritaikyti vežimo šabloną.

Nuosavybės vairuotojai dažniausiai nori kažko paprastesnio, tačiau ne silpnesnio. Praktikoje jie dažnai reikia sistemos, kurią lengva atnaujinti iš telefono, saugo visus atitikties įrodymus vienoje vietoje ir suteikia jiems švarų įrašą, jei jie bus pakviesti paaiškinti savo sistemas. Vienos transporto priemonės ar mažo transporto priemonių veiklai naudojimo paprastumas yra kritinis. Jei sistema per sunki, įrašai pasiklysta.

Mišrūs laivynai yra vieta, kur silpnos sistemos dažnai sugenda. Jei turite HGV, furgonų, priekabų ir galbūt kai kurių keleivinių transporto priemonių, jums reikia lanksčių turto tipų, atskirų grafikų ir ataskaitų, kurios vis tiek suteikia vieną valdymo vaizdą. Tai ypač tiesa, jei viena laivyno dalis yra pagal operatoriaus licenciją, o kita dalis - ne. Sistema turėtų atspindėti skirtingus įsipareigojimus, nesukeldama jums atskirų duomenų bazių.

Taksų ir privačių nuomos firmų, taip pat įdarbinimo ar vairuotojų agentūrų, gali nereikėti kiekvienos techninės priežiūros funkcijos, naudojamos vežimo laivyne, tačiau dažnai vis tiek reikia stiprios vairuotojų dokumentų kontrolės, licencijų patikrinimų ir galiojimo priminimų. Tinkama platforma priklauso nuo to, ar pagrindinė rizika kyla iš transporto priemonių, vairuotojų, ar abiejų.

Palydėdami produktus, žiūrėkite už antraštės sektoriaus žymės. Sistema gali teigti, kad ji palaiko laivynus, tačiau tikrasis klausimas yra, ar ji palaiko jūsų laivyno struktūrą, jūsų įrodymų reikalavimus ir jūsų kasdienį darbo krūvį.

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

Prieš judėdami, paklauskite, kas iš tikrųjų apima konfigūracija. Ar galite importuoti transporto priemones, priekabas, vairuotojus ir numatytas datas dideliais kiekiais, ar kas nors turės jas įvesti po vieną? Jei pereinate iš skaičiuoklių, dirbtuvių programinės įrangos ar kitos platformos, duomenų migracija dažnai yra ta vieta, kur projektai sustoja.

Paklauskite, kokie įrašai gali būti perkelti. Tik datos nėra pakankamos. Ar galite įtraukti patikrinimų istoriją, saugomus dokumentus, trūkumų įrašus ir vartotojų pastabas? Jei ne, kaip išlaikysite senus įrodymus taip, kad jie vis dar būtų naudojami?

Atidžiai patikrinkite vartotojų prieigą. Transporto vadybininkai, dirbtuvių darbuotojai, vairuotojai, atitikties darbuotojai ir išoriniai techninės priežiūros teikėjai gali reikėti skirtingų teisių. Sistema, kuri suteikia visiems pilną prieigą, nėra kontroliuojama. Sistema, kuri yra per daug ribota, tampa nepatogi, ir žmonės dirba aplink ją.

Paklauskite, kaip platforma tvarko įrodymus. Jei DVSA prašo patikrinimo įrašų transporto priemonei, arba Transporto komisaras prašo jūsų techninės priežiūros sistemų ir sekimo dėl trūkumų, ar galite greitai eksportuoti aiškų failą? Ar galite parodyti, kas pasirašė ką, kada buvo išduoti priminimai ir kaip pradelsti elementai buvo eskaluoti?

Ataskaitos yra dar vienas praktinis testas. Ar galite paruošti artėjančių ir pradelstų ataskaitų pagal transporto priemonę, priekabą, depą ar laivyno segmentą? Ar galite matyti pakartotinius trūkumus ar praleistus patikrinimus? Ar galite gauti ataskaitą, tinkamą techninės priežiūros peržiūros susitikimui, o ne tik informacijos ekrano nuotrauką?

Jei turite kitą programinę įrangą, anksti paklauskite apie integracijas. Kai kurie operatoriai reikia ryšių su telematika, HR sistemomis, dirbtuvių sistemomis, tachografo analize ar vidinėmis duomenų bazėmis. Jei tai jums svarbu, paklauskite, ar tiekėjas palaiko REST API, webhooks, ar abu. Taip pat paklauskite, ar integracija yra dokumentuota ir palaikoma, ar tik teoriškai įmanoma. Jei lyginate variantus išsamiai, mūsų straipsnis apie kaip palyginti laivyno sistemas su REST API yra naudingas kontrolinis sąrašas.

Paklauskite, kaip sistema tvarko teisines ir operacines kraštutines situacijas. Kas nutinka, jei turtas yra parduodamas, nuomojamas, neeksploatuojamas ar laikinai VOR? Ar galite išlaikyti istoriją nepažeisdami gyvų grafikų? Ar galite užregistruoti politikos pokyčius, tokius kaip peržiūrėtas patikrinimo intervalas, ir parodyti, kada pokytis įsigaliojo?

Verta paklausti, kaip tiekėjas supranta JK operatorių licencijos darbą. Ar jie žino skirtumą tarp paslaugų priminimo ir įrodymų, tinkamų VOL ar viešosios apklausos failui? Ar jie supranta metinių testų planavimą keleivių laivynams, priekabų įrašus ir praktinius lūkesčius, kurie kyla iš DVSA Gido dėl kelių tinkamumo palaikymo?

Šis paskutinis punktas mums yra svarbus. Operator Compliance buvo sukurta Fleeta Limited, atsižvelgiant į šiuos JK reikalavimus, nes mes patys vežame sunkvežimius pagal operatoriaus licenciją. Tikslas yra ne tik priminti jums, kad artėja data. Tai padėti jums išlaikyti įrašus, veiksmus ir įrodymus, susijusius su ta data, tvarkingai.

Jei renkatės HGV laivyno MOT, patikrinimo ir aptarnavimo priminimo sistemą, tai yra standartas, kurį reikia naudoti. Ne tai, ar ji siunčia pranešimus, nes dauguma sistemų tai gali padaryti. Ar ji padeda jums tinkamai vykdyti procesą, išlaikyti įrodymus kartu ir parodyti kontrolę, kai kas nors prašo to pamatyti.