Programinė įranga, kuri el. paštu praneša apie atitikties terminus

Jei ieškote laivyno programinės įrangos su el. pašto atitikties pranešimais, naudingas klausimas nėra tai, ar ji siunčia priminimus. Dauguma sistemų tai gali padaryti. Tikrasis išbandymas yra tai, ar tie pranešimai yra susieti su įrašais, įrodymais ir patvirtinimais, kuriuos reikia išlaikyti operatoriaus licencijos byloje, kai DVSA (Kelių transporto saugos agentūra) prašo ją peržiūrėti.

JK prekių ir keleivių operatoriams el. pašto pranešimai turi daryti daugiau nei tik įspėti, kad MOT yra numatytas kitą savaitę. Jie turėtų padėti mums kontroliuoti pasikartojančias saugumo inspekcijas, metinių testų datas, vairuotojų licencijų patikras, Driver CPC ir DQC galiojimo pabaigą, tachografo analizės procedūras, draudimo ir mokesčių datas, defektų sekimą ir VOR (neveikiančių transporto priemonių) įvykius. Taip pat svarbu, kad jie parodytų, kas buvo informuotas, kada buvo informuota, kokių veiksmų buvo imtasi ir kur yra palaikomas įrašas. Tai yra skirtumas tarp priminimo įrankio ir atitikties sistemos.

Ką turi apimti el. pašto atitikties pranešimai JK laivyne

Transporto vadybininkas turėtų tikėtis, kad pranešimais pagrįsta programinė įranga stebės terminus, kurie yra susiję su operatoriaus licencijos atitiktimi, o ne tik lengvais kalendoriaus elementais. Praktikoje tai reiškia, kad sistema turėtų apimti transporto priemones, priekabas, vairuotojus ir su kiekvienu susijusius įrodymus.

Transporto priemonėms akivaizdžios datos yra MOT ir metinis testas. JK HGV (sunkvežimiai) ir PSV (keleivių transportas) dirba pagal metinį testą, o ne pagal automobiliams taikomą MOT procesą, su kuriuo operatoriai gali būti labiau susipažinę, tačiau daugelis mišrių laivynų vis tiek turi suprasti abu terminus, nes furgonai, automobiliai ir specialios transporto priemonės gali būti toje pačioje sistemoje. Programinė įranga turėtų atskirti transporto priemonės tipą ir taikyti tinkamą testavimo ciklą, nesukurdama papildomų sprendimų.

Prevencinės techninės priežiūros inspekcijų tvarkaraščiai yra taip pat svarbūs. Tai nėra vienkartiniai dienoraščio įrašai. Tai pasikartojantys įvykiai, nustatyti pagal intervalą, kurį pateisinome kiekvienai transporto priemonei ar priekabai, nesvarbu, ar tai yra laiko, ar ridos pagrindu, ar jų derinys. Tinkama sistema turėtų suplanuoti inspekcijas pagal datą, laikyti suplanuoto intervalo istoriją ir pažymėti, kai inspekcija artėja, vėluoja arba buvo atlikta vėlai. Jei mes dirbame pagal ISO savaitę dirbtuvėms planuoti, programinė įranga turėtų palaikyti ir šią perspektyvą.

Priekaboms reikia savo įrašų rinkinio. Čia dauguma bendrų laivyno sistemų tampa nepatogios. Priekaboms reikia inspekcijų tvarkaraščių, metinių testų datų, kur tai aktualu, stabdžių testų įrodymų, remonto istorijos ir defektų sekimo, nors jos neturi vairuotojų, priskirtų tokiu pačiu būdu kaip varomosios vienetai. Pranešimai turėtų vertinti priekabas kaip pirmos klasės turtą, o ne kaip pastabas, pridėtas prie traktoriaus vieneto.

Vairuotojams pranešimai turėtų apimti vairuotojų licencijų patikras, Driver CPC galiojimo pabaigą, DQC galiojimo pabaigą, medicininius patikrinimus, jei tai aktualu, įvadinius ar politikos pripažinimus, jei mes juos valdome centriniu būdu, ir bet kokius vidinius peržiūros ciklus, kuriuos nustatome. Dėl agentūrų intensyvių operacijų sistema turėtų leisti mums laikyti įrodymus apie laikinuosius vairuotojus, taip pat ir nuolatinius darbuotojus, nes atitikties pareiga neišnyksta, kai vairuotojas yra tiekiamas kažkieno kito.

Tachografo atitiktis taip pat turi būti stebima. Tai apima reguliarius tachografo analizės importus, pažeidimų peržiūrą, trūkstamos ridos ar trūkstamų duomenų sekimą ir vairuotojų aptarimo veiksmus. Detalės skiriasi priklausomai nuo operacijos, tačiau jei programinė įranga siunčia el. laišką, sakydama, kad analizė yra numatyta, ji taip pat turėtų nurodyti duomenų rinkinį, paveiktą vairuotoją ar transporto priemonę ir nebaigtą veiksmą. Priminti be įrodymų sekimo nėra didelės naudos.

Tada yra palaikantys įrašai, kurie yra svarbūs DVSA vizito metu. Draudimo atnaujinimas, kelių mokestis, leidimai, techninės priežiūros paslaugų teikėjų dokumentai, kalibravimo sertifikatai, dirbtuvių patvirtinimai, vairuotojų defektų ataskaitos ir taisymo įrašai visi turi turėti datų kontrolę ir dokumentų saugojimą. Kai kurie operatoriai taip pat nori pranešimų apie MID patikras per askMID, kuris yra viešai prieinamas paslaugas, susijusias su Motor Insurers' Bureau ir MIB duomenimis, ypač kai transporto priemonės dažnai pridedamos arba pašalinamos.

Operatoriaus licencijos administravimui mums taip pat reikia pranešimų, kurie palaiko pačią bylą. Tai gali apimti priminimus peržiūrėti įgaliotų transporto priemonių sąrašus, patikrinti VOL detales prieš gyvą laivyną, patvirtinti paskirtus veiklos centrus ir išlaikyti pavadintų transporto vadybininkų įrašus aktualius. Programinė įranga negali pakeisti teisinių atsakomybių, tačiau ji gali užkirsti kelią pamiršti rutinas.

Kaip palyginti pranešimų kokybę, o ne tik pranešimų kiekį

Lengviausias būdas parduoti programinę įrangą yra pažadėti daugiau pranešimų. Geresnis būdas ją įvertinti yra paklausti, ar tinkamas asmuo gauna tinkamą įspėjimą tinkamu laiku, su aiškiu veiksmų keliu.

Laikas yra pirmas. Naudingas pranešimų tvarkaraštis nėra vienas el. laiškas, išsiųstas septynias dienas prieš galiojimo pabaigą. Skirtingos pareigos reikalauja skirtingų išankstinių laikotarpių. Metinio testavimo užsakymo įspėjimas gali reikalauti kelių etapų, ypač jei vietos yra ribotos. Kasdienis defektų klausimas gali reikalauti tos pačios dienos eskalacijos. Driver CPC ir DQC galiojimo pabaiga gali reikalauti ilgesnio laikotarpio, nes kursų užsakymas ir kortelių išdavimas gali užtrukti. Paklauskite, kiek priminimų etapų programinė įranga palaiko ir ar tie etapai gali skirtis pagal įvykio tipą.

Eskalacija yra tokia pat svarbi. Jei pirmas pranešimas siunčiamas administratoriams ir nieko nedaroma, kas vyksta toliau. Ar sistema gali eskaluoti transporto vadybininkui, depų vadybininkui ar dirbtuvių kontrolieriui po nustatyto laikotarpio? Ar ji gali kopijuoti antrąjį savininką prieš praleidžiant terminą? Pranešimų kokybė yra apie kontrolę, o ne triukšmą.

Savininkystė yra dar vienas punktas, kurį skaitytojai turėtų atidžiai patikrinti. Kiekviena užduotis ar terminas turėtų turėti pavadintą asmenį, atsakingą už veiksmus. Jei transporto priemonės inspekcija yra numatyta, programinė įranga turėtų parodyti, ar ji priklauso dirbtuvėms, išoriniam techninės priežiūros teikėjui ar transporto biurui. Jei vairuotojų licencijos patikra yra nebaigta, ji turėtų priklausyti asmeniui, kuris turi ją užbaigti arba sekti. Bendri pašto dėžutės pranešimai yra vieta, kur terminai dingsta.

Pakartotiniai priminimai turėtų būti konfigūruojami ir prasmingi. Sistema, kuri kiekvieną rytą siunčia tą patį bendrą pranešimą, nepadeda. Geras priminimas keičiasi artėjant terminui ir sustoja, kai užduotis yra baigta. Dar geriau, jie atskiria užsakytus, atliktus ir įrodytus. Užsakyti metinį testą nėra tas pats, kas jį išlaikyti. Įkelti defektų ataskaitą nėra tas pats, kas užfiksuoti taisymą.

Veiksmų įrodymas yra vieta, kur daugelis produktų skiriasi. Kai pranešimas yra išvalytas, kokie įrodymai yra už to statuso. Ar galime matyti inspekcijos lapą, pasirašytą defektų taisymo, licencijos patikros rezultatą, tachografo peržiūros pastabą ar įkeltą sertifikatą? Ar yra laiko žyma ir vartotojo įrašas? Jei DVSA klausia, kodėl įspėjimas dingo iš informacijos suvestinės, turėtume galėti parodyti veiksmą, kuris jį uždarė.

Auditų matomumas yra galutinis kokybės testas. Transporto vadybininkai turėtų galėti matyti atviras užduotis pagal depą, turto tipą, atsakingą asmenį ir rizikos lygį. Turėtų būti galima nustatyti ne tik tai, kas yra numatyta, bet ir kas buvo nuolat ignoruojama. Tai yra daug vertingiau nei ilgas funkcijų sąrašas.

Jei norite gilesnio supratimo apie tai, kaip atrodo audito paruošta sistema, mūsų vadovas apie programinę įrangą, kuri atlaiko DVSA auditą apima įrašus ir kontrolę, kurie yra svarbūs, kai priminimas buvo išsiųstas.

Kodėl laivyno programinė įranga dažnai neatitinka DVSA lūkesčių

Dažniausia silpnybė yra paprasta. Sistema siunčia priminimus, tačiau nelaiko įrašų, reikalingų atitikties įrodymui. Tai gali palikti operatorių jaustis organizuotu iki pat DVSA vizito.

Vienas trūkumas yra neišsamūs inspekcijų įrodymai. Kalendoriaus pranešimas gali pasakyti, kad PMI yra numatytas, tačiau jei programinė įranga negali saugoti užbaigto inspekcijos lapo, užfiksuoti defektus, parodyti taisymą ir užfiksuoti patvirtinimą, ji tinkamai nepalaiko techninės priežiūros sistemos. Tas pats taikoma stabdžių testavimui ir sekimo remontams.

Dar viena dažna problema yra prasta defektų valdymas. Vairuotojai gali pranešti apie gedimą, tačiau nėra švarios grandinės nuo pranešimo iki vertinimo, remonto ir grąžinimo į eksploataciją. Kelių tinkamumo sistemai ši grandinė yra svarbi. Turime žinoti, kada defektas buvo užfiksuotas, ar transporto priemonė buvo padaryta VOR, kas, jei reikia, leido toliau naudoti, koks remontas buvo atliktas ir kada transporto priemonė buvo išleista. Be to, priminimas yra atjungtas nuo kontrolės proceso.

Vairuotojų įrašai taip pat dažnai yra fragmentuoti. Bendras HR failas gali turėti mokymo datas. Laivyno įrankis gali turėti licencijų numerius. Tachografo analizė gali būti kitame portale. Draudimo patikros ar agentūros dokumentacija gali būti dar kitur. DVSA neaudituoja mūsų programinės įrangos architektūros. Ji žiūri, ar galime pateikti nuoseklius įrašus. Jei įrodymai yra išskaidyti per penkias sistemas ir dvi bendras diskas, tik pranešimai neišgelbės situacijos.

Taip pat yra patvirtinimo problema. Daugelis produktų fiksuoja, kad užduotis buvo pažymėta kaip baigta, tačiau ne tai, kas ją peržiūrėjo ar patvirtino. Operatorius licencijos atitikties atveju pavadinta atsakomybė yra svarbi. Transporto vadybininkui reikia matomumo išimčių ir užtikrinimo, kad procesas buvo laikomasi, o ne tik žalia varnelė ekrane.

Dokumentų kontrolė taip pat gali būti silpna. Failai yra įkelti, tačiau versijų istorija nėra aiški, galiojimo datos nėra susietos su dokumentu, arba nėra lengvo būdo parodyti dabartinį sertifikatą prieš ankstesnį. Per DVSA vizitą tai sukuria nereikalingą trintį.

Galiausiai kai kurios sistemos neatspindi realaus laivyno struktūros. Jos susiduria su išoriniais techninės priežiūros teikėjais, keliais depais, nuomojamomis transporto priemonėmis, savininkų vairuotojais ar laikinomis priekabomis, judančiomis tarp vietų. Jei programinė įranga negali atspindėti operacijos, audito takas tampa nenuoseklus.

Mes atskirai rašėme apie programinės įrangos pasirinkimą, kuri išlaiko jūsų O-licencijos bylą pasiruošusią, nes tai yra ta vieta, kur daugelis operatorių tik atranda po to, kai jau įsigijo priminimų pagrindu veikiančią sistemą.

Palyginimas viskas viename atitikties sistemų su bendromis laivyno priemonėmis

Bendro laivyno valdymo programinė įranga gali būti naudinga. Ji gali apimti užduočių paskirstymą, degalus, telematika, maršrutus, dirbtuves, atsargas ir ataskaitas vienoje vietoje. Kai kuriems laivynams to pakanka. Tačiau prekių ir keleivių operatoriai, dirbantys pagal operatoriaus licenciją, turėtų paklausti, ar atitiktis yra produkto centras, ar tik viena iš daugelio modulių.

Platesnis laivyno įrankis dažnai traktuoja atitikties terminus kaip turto priminimus. Tai veikia mokesčiams, draudimui ir paslaugų datoms. Tai mažiau įtikinama pasikartojančioms inspekcijų sistemoms, tachografo įrodymams, vairuotojų atitiktims ir įrašams, kuriuos Kelių transporto komisija tikėtųsi, kad mes pateiksime. Kai atitiktis yra šoninė funkcija, darbo eiga paprastai sustoja ties el. laišku.

Specializuota operatoriaus licencijos platforma yra kitokia. Ji prasideda nuo atsakomybių DVSA Gido dėl Kelių Tinkamumo išlaikymo ir statoma aplink įrodymų grandinę. Tai reiškia, kad transporto priemonių ir priekabų tvarkaraščiai, defektų pranešimai, taisymas, patvirtinimas, vairuotojų įrašai, tachografo peržiūra ir dokumentų saugojimas yra sujungti, o ne sujungti.

Čia Operator Compliance yra sąmoningai siauresnė ir stipresnė. Mes nesistengiame pakeisti kiekvienos transporto sistemos versle. Mes koncentruojamės į tai, kad operatoriaus licencijos pusė būtų kontroliuojama ir matoma, nes tai yra vieta, kur transporto vadybininkai neša asmeninę atsakomybę. OperatorCompliance sukūrė Fleeta Limited, ir ši praktinė operatoriaus patirtis atsispindi darbo eigoje. Programinė įranga yra sukurta aplink įrašus, kuriuos tikėtumėmės patys pagaminti.

Tai nereiškia, kad specializuota programinė įranga turi būti izoliuota. Integracija yra svarbi. Kai kurie operatoriai reikia duomenų iš telematikos, dirbtuvių sistemų, HR platformų ar atlyginimų įrankių. Jei lyginate produktus, paklauskite, ar jie siūlo REST API ar webhooks, ir kokius įvykius ar įrašus jie apima praktikoje. Viena yra teigti integraciją. Kita yra palaikyti patikimus atnaujinimus vairuotojams, turtui, dokumentams ar statuso pokyčiams be rankinio įvedimo.

Jei tachografo kontrolė yra didelė problema jūsų operacijoje, verta peržiūrėti ką ieškoti tachografo analizės įrankiuose mažiems laivynams, ypač jei bandote išvengti dar vieno atskirto portalo.

Ką klausti prieš pasirinkdami programinę įrangą mišriai transporto priemonių operacijai

Mišrūs laivynai greitai atskleidžia silpnybes. Jei mes naudojame furgonus, HGV, priekabas, PSV, bendro naudojimo automobilius ar specialias transporto priemones per daugiau nei vieną depą, pirkimo klausimai turi tapti labai praktiški.

Pirmiausia paklauskite, kaip programinė įranga tvarko skirtingus atitikties ciklus pagal turto tipą. Ar ji gali valdyti furgonų MOT datas kartu su HGV ar PSV metinių testų tvarkaraščiais? Ar priekabų inspekcijos gali vykti nepriklausomai nuo vieneto? Ar galime taikyti skirtingus PMI intervalus pagal transporto priemonę, laivyno grupę ar veiklos centrą?

Antra, paklauskite, kaip yra priskiriamos atsakomybės. Ar pranešimai gali eiti į vieną depą transporto priemonių paruošimui, kitą užsakymui ir transporto vadybininkui eskalacijai? Ar išorinės dirbtuvės gali gauti užduotis ar patvirtinimus? Ar agentūrų administratoriai gali įkelti vairuotojų įrašus, nematydami nesusijusių duomenų?

Trečia, paklauskite, kaip yra fiksuojami įrodymai. Ar inspekcijos lapai yra skaitmeniniai? Ar defektus gali pasirašyti vairuotojas ir remontininkas? Ar yra aiški VOR darbo eiga? Ar galime įkelti sertifikatus, nuotraukas ir pastabas prieš tikslų įrašą, kuris sukėlė pranešimą? Jei terminas yra išvalytas, ar galime parodyti kodėl.

Ketvirta, paklauskite, kaip sistema tvarko išimtis. Kas nutinka, jei transporto priemonė praleidžia inspekcijos datą? Kaip vėluojančios užbaigimo datos yra rodomos? Ar programinė įranga gali fiksuoti įgaliotus nukrypimus ir priežastį? Ar galime pranešti apie pasikartojančius praleidimus pagal depą ar teikėją? Atitikties sistema turėtų padaryti silpnas vietas matomomis, o ne jas slėpti.

Penkta, paklauskite apie vairuotojų duomenų šaltinius. Jei naudojate DVLA patikras, kaip rezultatas yra saugomas ir peržiūrimas? Jei Driver CPC ir DQC įrašai įvedami rankiniu būdu, kas juos patvirtina? Jei naudojami laikini ar agentūrų vairuotojai, ar jų įrašai gali būti laikomi tiek, kiek jie dirba su mumis, ir vėliau atgauti, jei reikia.

Šešta, paklauskite apie audito rezultatus. Ar galime paruošti mėnesinį laivyno paketą? Ar įrašai gali būti filtruojami pagal transporto priemonę, priekabą, depą ar datų intervalą? Ar galime eksportuoti failą Kelių transporto komisijos tyrimui ar techninės priežiūros tyrimui be dokumentų sujungimo rankiniu būdu? Jei mėnesiniai peržiūros paketai yra svarbūs jūsų procesui, mūsų straipsnis apie mėnesinio laivyno paketo pasirinkimą, kuris atlaiko DVSA nurodo, ką įtraukti.

Septinta, paklauskite apie operatyvų tinkamumą. Ar programinė įranga gali palaikyti savininkų vairuotojus, taip pat didesnius depus? Ar taksi ir privačių nuomos operatoriai gali naudoti tą pačią discipliną transporto priemonių ir vairuotojų datoms, net jei teisinė struktūra skiriasi nuo HGV ir PSV operatorių licencijavimo? JK taisyklės gali skirtis nuo platesnės ES praktikos, ypač kai taikomos vidaus operatoriaus licencijos pareigos, metinių testų susitarimai ir vietiniai licencijavimo reikalavimai, todėl produktas turėtų būti sukurtas aplink JK darbo eigą, o ne bendrą Europos laivyno prielaidą.

Galiausiai paklauskite, kas nutinka po to, kai el. laiškas atkeliauja. Tai yra klausimas už visų kitų. Geras pranešimas nėra žinutė. Tai yra dokumentuota veiksmo pradžia, įgyvendinta iki pabaigos, su įrodymais, paruoštais, kai DVSA nori juos peržiūrėti.

Tai yra standartas, kurį mes kuriame Operator Compliance. El. pašto pranešimai yra svarbūs, tačiau tik tada, kai jie yra sistemoje, kuri išlaiko transporto priemones, priekabas, vairuotojus ir tachografo įrašus tvarkingai, su audito taku, kuris juos palaiko.