Programinės įrangos pasirinkimas, kuri užtikrina autobuso

Jei valdote autobusus ar mikroautobusus pagal JK operatoriaus licenciją, tinkama programinė įranga turėtų atlikti vieną svarbiausią užduotį. Ji turėtų palengvinti jūsų įrašų išsaugojimą, peržiūrą ir įrodymų pateikimą, kai DVSA ar Transporto komisaras prašo įrodymų. Tai reiškia daugiau nei tik dirbtuvės dienoraštis ar bendroji flotilės duomenų bazė. Jums reikia sistemos, kuri atitinka tikrąjį keleivinio vežimo operatoriaus atitikties darbą, pradedant saugos patikromis ir metinių testų užsakymais iki vairuotojų patikrinimų, tachografo įrodymų ir pasirašytų veiksmų sekimo.

Gera autobusų ir mikroautobusų atitikties programinė įranga sumažina riziką, laikydama šiuos įrašus vienoje vietoje, su datomis, dokumentais, statusu ir auditų takeliu, kuris rodo, kas įvyko, kada ir kas tai padarė. Jei sistema negali padėti jums įrodyti kelių tinkamumo valdymo ir transporto vadybininko kontrolės taip, kad atitiktų reikalavimus, ji neatlieka savo darbo.

Ką autobusų ir mikroautobusų operatoriai nori, kad programa darytų

Autobusų ir mikroautobusų operatoriai reikia programinės įrangos, kuri atspindėtų įrašus, kuriuos jie turi kontroliuoti pagal operatoriaus licencijos režimą. Praktikoje tai prasideda nuo transporto priemonių įrašų.

Kiekvienam PSV (viešojo transporto autobusas), mums reikia aiškios saugos patikros, prevencinės priežiūros patikros, MOT arba metinių testų datų, stabdžių testavimo, jei taikoma, remonto darbų, defektų, taisymo ir laikotarpių, kai transporto priemonė yra VOR. Sistema turėtų rodyti suplanuotą patikros intervalą, užbaigtą datą, rezultatą ir bet kokius praleistus ar perkeliamus įvykius. Jei patikra buvo perplanuota, mums reikia pamatyti, kodėl, kas tai patvirtino ir ar pakeitimas liko mūsų deklaruotame priežiūros sistemoje.

Planavimo funkcija yra svarbi, nes autobusų ir mikroautobusų operacijos dažnai veikia aplink mokyklų sutartis, privačius užsakymus, paslaugų įsipareigojimus, depų prieinamumą ir inžinerinę pajėgumą. Kalendorius, kuris tiesiog išvardija numatytas datas, nėra pakankamas. Mums reikia matyti artėjančias patikras pagal depą, transporto priemonę, meistrą, rangovą ar ISO savaitę, kad galėtume pastebėti perkrovas ir spragas, kol jos taps praleistais įvykiais.

Vairuotojų įrašai yra antra pagrindinė sritis. Programinė įranga turėtų turėti licencijų kategorijas, galiojimo datas, Driver CPC statusą, DQC galiojimo datą, teisę dirbti dokumentus, kai tai aktualu, vidaus politikos pripažinimus ir patikrinimų istoriją. JK operacijoms tai reiškia darbo srautus, kurie atitinka DVLA licencijų tikrinimą ir periodinį Driver CPC stebėjimą. Jei jūsų operacija taip pat naudoja agentūrinius vairuotojus, sistema turi atskirti samdomus, agentūrinius ir atsitiktinius vairuotojus, vis tiek išlaikydama bendrą įrodymų standartą.

Tachografo įrodymai yra dar viena pagrindinė reikalavimų dalis. Net jei autobuso operacija turi vidaus taisykles kai kuriose verslo dalyse, daugelis mikroautobusų operatorių ir mišrių keleivinių flotilių vis tiek reikia tinkamos tachografo analizės, pažeidimų peržiūros ir sekimo įrodymų. Neužtenka žinoti, kad pažeidimas įvyko. Mums reikia parodyti, kad jis buvo identifikuotas, peržiūrėtas, aptartas, jei reikia, ir patvirtintas. Tas įrašas gali būti toks pat svarbus kaip ir pirminė analizė.

Tada yra pats auditų takelis. Atitinkanti sistema turėtų užfiksuoti, kas įkėlė dokumentą, kas pakeitė datą, kas uždarė defektą ir kada buvo išsiųsti priminimai. Per DVSA tyrimą ar viešąjį tyrimą sunkumai dažnai kyla ne dėl to, kad verslas nieko nedarė, bet kad jis negali įrodyti, ką padarė. Programinė įranga turėtų padėti sukurti tą įrodymą kaip kasdienio darbo dalį, o ne kaip rankinį atkūrimą vėliau.

Daugelio operatorių vienas naudingiausių testų yra paprastas. Ar galime eksportuoti arba parodyti pilną failą vienai transporto priemonei ar vienam vairuotojui, įskaitant artėjančias datas, istorinius įrašus, palaikančius dokumentus ir pasirašytus veiksmus, neieškodami popierinės dokumentacijos per el. pašto aplankus, depų failus ir dirbtuvių sistemas? Jei ne, įrašai nėra auditui paruošti.

Kaip autobusų ir mikroautobusų atitikties programinė įranga skiriasi nuo bendrųjų flotilės sistemų

Bendra flotilės sistema dažnai sukurta valdyti naudojimą, degalus, aptarnavimo išlaidas, telematikos ar dirbtuvių perdirbimą. Visi šie dalykai gali būti naudingi, tačiau jie nėra tas pats, kas operatoriaus licencijos atitiktis.

Autobusų ir mikroautobusų atitikties programinė įranga turėtų būti sukurta aplink įrodymų standartus, kurie yra svarbūs JK DVSA kontekste. Tai reiškia kelių tinkamumo įrašus, vairuotojų įrašus, tachografo įrodymus ir valdymo kontrolę. Plati flotilės platforma gali būti labai stipri turto valdyme, tačiau vis tiek silpna detalėse, kurių transporto vadybininkui reikia Transporto komisaro bylai.

Skirtumai paprastai pasireiškia darbo sraute. Atitikties sistemoje patikros nėra tik paslaugų įvykiai. Jos yra deklaruotos priežiūros sistemos dalis. Defektai nėra tik darbai. Jiems reikia statuso, taisymo įrodymų, patvirtinimo ir aiškaus ryšio tarp ataskaitos ir remonto. Vairuotojų patikrinimai nėra tik HR įrašai. Jiems reikia pakartotinai peržiūrėti datas, dokumentinius įrodymus ir eskalavimą, kai kažkas pasibaigia arba pasikeičia.

Keleivių operatoriai taip pat turėtų stebėti terminologiją ir struktūrą. Programinės įrangos tiekėjas gali teigti, kad jis palaiko autobusus ir mikroautobusus, tačiau jei produktas iš tikrųjų sukurtas aplink lengvas flotiles ar dirbtuvių paslaugų planus, jis gali nesuprasti metinių testų planavimo, PSV įrašų struktūrų ar to, kaip transporto vadybininkai peržiūri išimtis. Mes tai dažnai matome, kai paketas pradėjo gyvavimą kaip paslaugų užsakymo įrankis ir vėliau pridėjo atitikties laukus.

Dar vienas praktinis skirtumas yra tai, kaip sistema tvarko įrodymus laikui bėgant. Dirbtuvių paketas gali perrašyti dabartinį statusą. Atitikties programinė įranga turėtų išsaugoti istorinius takelius. Jei transporto priemonė buvo perkelta į VOR, jei patikra buvo atidėta, arba jei vairuotojo DQC pasibaigė ir vėliau buvo atnaujinta, mums reikia laiko juostos, o ne tik naujausios padėties.

Čia programinė įranga, sukurta pagal DVSA Gidą dėl kelių tinkamumo išlaikymo, skiriasi. Operator Compliance, sukurtas Fleeta Limited, mes sutelkiame dėmesį į įrašus ir darbo srautus, kurie palaiko operatoriaus licencijos darbą, o ne tik flotilės administravimą. Būtent todėl kai kurie operatoriai skaito mūsų gaires apie flotilės įrašų programinę įrangą operatoriaus licencijos darbui prieš palygindami sistemas.

Savybės, kurias verta palyginti prieš perkant

Palygindami sistemas, pradėkite nuo planuotojo. Rekomenduojame ieškoti planuotojo, kuris rodo patikras, MOT, metinius testus, licencijų patikrinimus, Driver CPC terminus, tachografo atsisiuntimus ar peržiūras ir kitas pasikartojančias užduotis viename vaizde. Jis turėtų būti lengvai filtruojamas pagal depą, transporto priemonės klasę, vadybininką, rangovą ar datų intervalą. Jei planuotojas negali parodyti, kas numatyta kitai savaitei ir kas jau pasibaigė, tai sukurs nereikalingą administravimą.

Defektų pranešimas yra dar viena svarbi palyginimo vieta. Patikrinkite, ar vairuotojai gali greitai pranešti apie defektus, ar nuliniai defektai yra užfiksuoti, jei tai yra jūsų proceso dalis, ar galima pridėti nuotraukas ir ar taisymas yra susietas su pradiniu pranešimu. Geriausios sistemos taip pat rodo, ar defektas pašalino transporto priemonę iš kelio, kas įvertino kelių tinkamumą ir kada transporto priemonė grįžo iš VOR.

Dokumentų saugojimas reikalauja daugiau dėmesio nei daugelis pirkėjų jam skiria. Paklauskite, ar sistema saugo patikros lapus, metinių testų sertifikatus, draudimo dokumentus, licencijų kopijas, DQC įrodymus, sutartis su priežiūros teikėjais ir vidaus politikos įrašus, susijusius su tinkamu turtu ar asmeniu. Dokumentai turėtų būti versijuoti arba susieti su datomis, o ne tiesiog išmesti į aplanką.

Vairuotojų tikrinimo funkcijos turėtų apimti suplanuotus DVLA licencijų patikrinimus, Driver CPC ir DQC stebėjimą, taip pat galimybę saugoti patvirtinimus, deklaracijas ir sekimo pastabas. Jei vairuotojų įrašai yra didelė problema jūsų versle, mūsų gidas apie programinę įrangą, kuri užtikrina vairuotojų įrašų auditą yra vertas perskaityti kartu su bet kokiu produkto demonstravimu.

Tachografo analizė neturėtų būti laikoma kaip priedas. Palyginkite, kaip sistema importuoja duomenis, žymi pažeidimus, registruoja aptarimus ir saugo pasirašytus pripažinimus. Jei naudojate kitą specializuotą analizės teikėją, paklauskite, ar programinė įranga vis tiek gali laikyti gautus įrodymus vairuotojo įraše.

Priminti turėtų būti konfigūruojami ir nuolatiniai. Vienas el. laiškas numatytą datą nėra atitikties procesas. Mes ieškome eskaluojančių priminimų prieš ir po terminų, su aiškiu statusu, ar užduotis buvo atlikta. Tai ypač svarbu metinių testų užsakymams, patikroms ir pasibaigusiems dokumentams. Tinkamas atitikties kalendorius, kuris išlaiko terminus matomus gali užkirsti kelią daugeliui nesėkmių, kurios paaiškėja tik audito metu.

Pasirašyti įrašai dažnai yra skirtumas tarp naudingos sistemos ir gynybinės. Ar meistras gali pasirašyti patikros įrašą? Ar vadybininkas gali pasirašyti defekto peržiūrą? Ar vairuotojas gali pripažinti tachografo aptarimą? Ar sistema gali parodyti datą ir vartotoją už kiekvieną veiksmą?

Tada pažvelkite į integracijas. Dažniausiai reikalaujama, kad būtų nuorodos su dirbtuvių sistemomis, telematika, HR platformomis, atlyginimų, tachografo įrankiais ir duomenų paslaugomis. API galimybė čia yra svarbi. Tiekėjas, kuris siūlo REST API ir webhooks, suteikia daugiau galimybių automatizuoti atnaujinimus ir išlaikyti įrašus suderintus tarp sistemų. Kai kurie operatoriai taip pat nori nuorodų su askMID duomenimis iš Motor Insurers' Bureau arba MIB susijusių patikrinimų, priklausomai nuo to, kaip jie valdo draudimo patvirtinimą ir flotilės įrašus. Jei naudojate tokius įrankius kaip Fleetalyse ar Logivo.AI kitur versle, integracijos galimybės tampa dar svarbesnės.

Galiausiai, palyginkite ataskaitas. Turėtumėte galėti gauti pradelstas prekes, artėjančius terminus, praleistas patikras, neišspręstus defektus, vairuotojų dokumentų spragas ir tachografo išimtis, neeksportuodami žalių duomenų į skaičiuokles pirmiausia.

Kur sistemos dažnai nepasiekia transporto vadybininkų lūkesčių

Dažniausia problema yra padalinti įrašus. Viena sistema laiko dirbtuvių įvykius, kita laiko dokumentus, kita laiko vairuotojų failus, o priminimai gyvena Outlook arba skaičiuoklėje. Toks išdėstymas gali veikti kasdien, tačiau jis tampa silpnas, kai kas nors prašo pilno įrašo.

Antrasis trūkumas yra prasta įrodymų fiksacija. Užduotis gali būti pažymėta kaip užbaigta, tačiau nėra pasirašyto patikros lapo, nėra įkeltų sertifikatų, nėra pastabų, paaiškinančių perplanavimą, ir nėra įrašo, kas tai uždarė. Tai sukuria rimtą problemą audito metu. Užbaigimas be įrodymų nėra daug geresnis už nebaigtumą.

Išimčių ataskaita yra dar viena silpna vieta. Daugelis sistemų gali parodyti, kas yra numatyta, tačiau mažiau aiškiai rodo, kas buvo neteisinga. Transporto vadybininkai turi matyti praleistas patikras, pradelstus defektus, pasibaigusius DQC įrašus, transporto priemones, artėjančias metiniam testui be užsakymo, ir neišspręstus tachografo pažeidimus. Žalių varnelės pilnas skydelis nėra naudingas, jei jis slepia išimtis.

Vairuotojų ir priekabų matomumas taip pat gali būti ribotas. Mišrūs operatoriai arba verslai, kurie derina PSV darbą su kita flotilės veikla, dažnai atranda, kad sistema gerai tvarko transporto priemones, tačiau vairuotojus traktuoja kaip antraeilius. Kiti visai negali tinkamai sekti priekabų. Net keleivių operatoriams tai svarbu, jei papildomi turtai, vilkimo susitarimai ar mišrios flotilės įsipareigojimai yra po ta pačia valdymo struktūra.

Dar vienas dažnas trūkumas yra sekimo įrodymų trūkumas. Lengva užfiksuoti, kad vairuotojas turėjo pažeidimą, kad transporto priemonė nepavyko testo, arba kad defektas buvo praneštas. Sunku įrodyti, kas įvyko toliau. Ar mes tyrėme? Ar mes informavome vairuotoją? Ar mes pervedėme transporto priemonę į VOR? Ar mes patvirtinome grįžimą į paslaugą? Sistemos, kurios nefiksuoja šių žingsnių, palieka transporto vadybininkus atvirus.

Galiausiai, daugelis produktų paprasčiausiai nėra sukurti JK operatoriaus licencijos kalba. Jei tiekėjas kalba apie paslaugų intervalus, bet ne apie saugos patikras, arba registracijos atnaujinimus, bet ne apie metinius testus, arba bendrąsias licencijas, bet ne apie DVLA patikrinimus ir Driver CPC, tai paprastai rodo prastą atitikimą tikrai atitikties darbui.

Kaip palyginti tiekėjus JK operacijai

Pradėkite nuo nustatymo. Paklauskite, ko tiekėjas iš jūsų reikia, kad pradėtų veikti, kaip transporto priemonės ir vairuotojai importuojami, ir kaip kuriami pasikartojantys tvarkaraščiai. Jei sistema reikalauja savaičių rankinio duomenų įvedimo, kol ji taps naudinga, diegimo rizika yra didelė.

Tada paklauskite apie duomenų migraciją. Ar jie gali importuoti esamas transporto priemonių istorijas, patikros datas, defektų žurnalus, vairuotojų įrašus ir dokumentų bibliotekas? Kokia forma jiems reikia? Ar bus išsaugotos istorinės datos ir priedai? Švari migracija yra svarbi, nes atitikties programinė įranga nėra tik apie būsimus priminimus. Jums dažnai reikia ir praeities istorijos.

Palaikymas yra kitas. Mes rekomenduojame paklausti, kam skirtas palaikymas, transporto vadybininkams, dirbtuvių komandoms, biuro administratoriams ar IT. Taip pat paklauskite, ar palaikymas supranta JK operatoriaus licencijos darbą ar tik programinės įrangos ekranus. Skirtumas greitai pasireiškia, kai užduodate klausimą apie patikros intervalus, metinių testų darbo srautus ar įrodymus Transporto komisaro posėdyje.

Patikrinkite terminologiją visame produkte. Ar jis natūraliai naudoja JK terminus, įskaitant MOT, metinį testą, Driver CPC, DQC, VOR ir VOL, kai tai aktualu? Jei kalba yra bendra arba svetima jūsų operacijai, darbuotojų priėmimas bus lėtesnis, o klaidų tikimybė didesnė.

Įvertinkite operacinį atitikimą gyvoje demonstracijoje. Paprašykite tiekėjo parodyti jūsų faktinius scenarijus, o ne poliruotą bendrą peržiūrą. Pavyzdžiui, paprašykite jų sukurti PSV patikros tvarkaraštį, perkelti datą su audito priežastimi, įkelti užbaigtą lapą, pažymėti transporto priemonę VOR iš pranešto defekto, atkurti ją į paslaugą po remonto ir tada pateikti pilną įrašą. Padarykite tą patį su vairuotoju, kurio DQC artėja prie pabaigos ir tachografo aptarimu.

Integracijos galimybės nusipelno tiesioginių klausimų. Jei jums reikia sujungti kitas sistemas, paklauskite, ar tiekėjas siūlo REST API, ar yra webhooks, kokius įvykius jie skelbia ir kaip veikia autentifikacija. Jei jie sako, kad integracijos yra įmanomos, paprašykite pavyzdžių, kurie jau naudojami.

Taip pat paklauskite, kaip produktas tvarko operatorių struktūras. Ar jis gali atskirti depus, juridinius asmenis ar sutartis, išlaikydamas centrinį stebėjimą? Ar agentūros gali valdyti vairuotojų įrašus, nesukeldamos klientų ribų? Ar savininkai-vairuotojai gali naudoti tuos pačius pagrindinius valdymo elementus be nereikalingos sudėtingumo? Tai praktiniai klausimai, o ne kraštutiniai atvejai.

Galiausiai, paklauskite, ar sistema atitinka tikrą operatoriaus licencijos darbą. Tai skamba akivaizdžiai, tačiau tai yra pagrindinis testas. Operator Compliance, mūsų požiūris formuojamas Fleeta Limited, valdančio sunkvežimius pagal operatoriaus licenciją, ir kuriant aplink DVSA Gidą dėl kelių tinkamumo išlaikymo. Tas operatyvinis pagrindas yra svarbesnis nei ilgas funkcijų sąrašas.

Kokio tipo operatoriai turėtų prioritetą teikti kurioms savybėms

Mažos mikroautobusų įmonės dažniausiai pirmiausia reikia paprastumo. Prioritetas yra aiškus planuotojas, metinių testų ir patikros priminimai, defektų įrašai, vairuotojų licencijų ir Driver CPC stebėjimas bei lengvas dokumentų saugojimas. Jei savininkas ar transporto vadybininkas atlieka didžiąją dalį administravimo, sistema turi sumažinti ieškojimą ir greitai paruošti auditų failus. Šiems operatoriams naudojimo paprastumas dažnai yra svarbesnis už gilią integraciją.

Didesni autobusų operatoriai turėtų sutelkti dėmesį į kontrolę dideliu mastu. Tai reiškia depų peržiūras, išimčių ataskaitas, stiprius vartotojų leidimus, dokumentų nuoseklumą ir ataskaitas, leidžiančias centriniams atitikties komandoms matyti, ką daro kiekvienas depas. Pasirašyti darbo srautai ir tvirti auditų takeliai tampa svarbesni, kai daugiau žmonių liečia įrašus.

Mišrios flotilės reikalauja lankstumo. Jei valdote keleivines transporto priemones kartu su krovininėmis transporto priemonėmis ar furgonais, programinė įranga turėtų palaikyti abi be atskirų sistemų. Čia platesnė operatoriaus licencijos atitikties platforma gali padėti, jei ji vis tiek tinkamai tvarko PSV specifinius poreikius. Svarbiausia yra vienas įrodymų standartas visai flotilei.

Savininkai-vairuotojai ir labai maži operatoriai paprastai reikia pagrindinių dalykų su minimalia administracija. Terminų matomumas, patikros istorija, metinių testų priminimai, vairuotojų dokumentai ir tachografo įrodymai yra prioritetai. Jei tai jūsų padėtis, mūsų gidas apie geriausią atitikties programinę įrangą JK savininkams-vairuotojams gali padėti siaurinti pasirinkimą.

Agentūros, valdančios vairuotojų įrašus, turėtų prioritetą teikti vairuotojų darbo srautams, o ne transporto priemonių darbo srautams. Jiems reikia licencijų patikrinimų, Driver CPC ir DQC stebėjimo, dokumentų galiojimo priminimų, aiškios klientų atskyrimo ir lengvo būdo įrodyti, kad patikrinimai buvo atlikti laiku. Jei agentūros vairuotojai juda tarp kelių operatorių, įrašų tikslumas ir laiko žymėjimai yra kritiniai.

Bet kuriam autobusų ar mikroautobusų operatoriui teisingas pasirinkimas priklauso nuo vieno klausimo. Kai DVSA klausia, kaip mes valdome kelių tinkamumą ir vairuotojų atitiktį, ar sistema gali aiškiai parodyti atsakymą, su datomis, dokumentais ir veiksmais, kurie atitinka reikalavimus? Jei gali, ji atlieka savo darbą. Jei negali, rizika išlieka, nesvarbu, kaip moderniai atrodo skydelis.

Jei norite programinės įrangos, sukurto pagal tą operatoriaus licencijos standartą, o ne bendros flotilės duomenų bazės su pridėta atitiktimi, pažiūrėkite, kaip mes palaikome autobusų ir mikroautobusų operatorių atitiktį vienoje sistemoje.