Kaip palyginti transporto sistemų sprendimus su REST API

Jei lyginate transporto sistemas ir trumpame sąraše yra bet kas, kas apibūdinama kaip transporto atitikties programinė įranga su API prieiga, naudingas klausimas nėra, ar API egzistuoja. Svarbu, ką tas API iš tikrųjų gali padaryti operatorių licencijai dirbant JK, kaip švieži išlieka įrašai ir ar įrodymai atlaikytų, jei DVSA (Kelių transporto agentūra) ar Transporto komisaras paprašytų juos pamatyti.

Daugumai operatorių teisingas atsakymas yra sistema, kuri apima įrašus, kuriuos jau turite saugoti, leidžia tiems įrašams sklandžiai judėti ir išlaiko tinkamą audito taką. Poliruota informacijos suvestinė yra antraeilis dalykas. Jei API negali palaikyti patikrinimų, defektų, vairuotojų patikrinimų, tachografo įrodymų ir terminų kontrolės taip, kaip tai atitinka JK praktiką, ji neišsprendžia sunkiosios dalies.

Ką JK operatoriai iš tikrųjų reikia iš API

Naudingas REST API atitikties darbui turėtų palaikyti transporto vadybininkų jau vykdomas užduotis kiekvieną savaitę, o ne tik bendrą transporto duomenų mainų.

Vežėjams tai paprastai prasideda nuo transporto priemonių, priekabų, saugos patikrinimų, remonto istorijos, MOT datų, vairuotojų pažymėjimų patikrinimų, Driver CPC datų, DQC įrodymų ir tachografo įrašų. Jei operatorius dirba pagal O-licenciją, programinė įranga taip pat turi atspindėti, kaip planuojama ir įrodoma priežiūra pagal DVSA (Kelių transporto agentūros) Gaires dėl kelių tinkamumo. Tai reiškia, kad patikrinimų intervalai, praleisti ar perkelti patikrinimai, VOR (neveikiančių transporto priemonių) laikotarpiai, taisymo įrašai ir palaikantys dokumentai nėra neprivalomi priedai.

Vanų flotilėms modelis yra panašus, tačiau dažnai išsidėsto per mišrią veiklą. Kai kurios furgonai gali nesilaikyti to paties priežiūros režimo kaip HGV (sunkvežimiai), tačiau operatorius vis tiek turi turėti patikimą aptarnavimo, kelių tinkamumo patikrinimų, defektų, draudimo ir vairuotojų teisių įrašą. Jei flotilė apima transporto priemones, viršijančias ribas, kurios įjungia operatorių licencijos taisykles, sistema turėtų susidoroti tiek su įprasta flotilės administracija, tiek su oficialiais atitikties įrašais vienoje vietoje. Mūsų puslapis apie atitikties programinę įrangą vanų flotilėms detaliau apima šį mišraus naudojimo reikalavimą.

Autobusų ir mikroautobusų operatoriams metinių testų planavimas, PMI (periodiniai techniniai patikrinimai), vairuotojų kvalifikacijos įrašai ir defektų ataskaitos yra centriniai. REST API turėtų leisti šiuos įrašus įtraukti į ataskaitų rengimo įrankius, atlyginimų ar dirbtuvių sistemas, nesulaužant įrodymų grandinės. Keleivių flotilėms taip pat reikia aiškios kontrolės, kas pasirašė ką, kada defektas buvo praneštas ir kada jis buvo grąžintas į eksploataciją.

Nuosavų vairuotojų atveju API klausimas paprastai yra paprastesnis. Jiems dažnai nereikia didelio integracijos projekto. Jiems reikia galimybės prisijungti prie tachografo paslaugos, dokumentų saugyklos ar klientų portalo, nesukant tų pačių įrašų. Geriausios sistemos nepriverčia nuosavų vairuotojų pereiti prie įmonės stiliaus nustatymo, kad gautų pagrindinį tarpusavio suderinamumą.

Rekrutavimo įmonėms ir vairuotojų agentūroms API poreikiai daugiausia susiję su vairuotojų įdarbinimu, pažymėjimų patikrinimais, Driver CPC, DQC ir įrodymu, kad teisingi patikrinimai buvo atlikti prieš įdarbinimą. Jei agentūros vairuotojai juda tarp operatorių, sistema turėtų palengvinti kvalifikacijos įrašų centrą, tuo pačiu išlaikant operatoriui specifinius įrodymus, kur to reikia.

JK kontekste taip pat yra svarbus skirtumas nuo platesnės ES transporto programinės įrangos. Daugelis Europos platformų yra stiprios telematikoje ar maršruto kontrolėje, tačiau silpnos praktiniuose įrodymuose, kurie tikimasi aplink JK operatorių licencijavimą. Mes kuriame Operator Compliance per Fleeta Limited aplink įrašus, kurių iš tikrųjų reikalauja JK operatoriai, nes patys valdome sunkvežimius ir žinome, kad failas turi būti prasmingas DVSA ir, jei reikia, Transporto komisarui.

Kokie įrašai turėtų būti prieinami per sistemą

Kai lyginate sistemas, žiūrėkite ne tik į antraštės frazę "atvira API" ir išvardinkite faktinius įrašų tipus, kurie yra prieinami. Čia vienas produktas gali atrodyti integruotas popieriuje, tačiau vis tiek palieka transporto vadybininkus eksportuoti skaičiuokles svarbiems atitikties užduotims.

Transporto priemonės turėtų būti prieinamos su registracijos numeriu, flotilės numeriu, marke ir modeliu, mokesčių detalėmis, jei tai aktualu, MOT arba metinių testų datomis, patikrinimų tvarkaraščiais, statusu ir VOR laikotarpiais. Jei naudojate askMID, kad patikrintumėte draudimą prieš Motor Insurers' Bureau arba MIB įrašus, būtų naudinga, jei šie patikrinimai galėtų būti susieti su transporto priemonės failu, o ne palikti el. laiškų grandinėse.

Priekabos yra tokios pat svarbios daugeliui prekių operatorių. Kai kurios sistemos traktuoja priekabas kaip antrarūšius turtus arba visiškai neįtraukia jų į API prieigą. Tai sukuria spragą iš karto, nes priekabų patikrinimai, stabdžių testų įrodymai, defektai ir metiniai tvarkaraščiai yra tikro atitikties vaizdo dalis.

Patikrinimų įrašai turėtų apimti suplanuotą datą, užbaigtą datą, ridos arba naudojimo nuorodą, kur naudojama, patikrinimo lapą, rezultatus, susijusius defektus, taisymo pastabas ir pasirašytus įrodymus. Taip pat turėtų būti galima matyti, ar patikrinimas buvo atliktas laiku, perkelta dėl operatyvios priežasties ar visiškai praleistas. Jei tiekėjas siūlo tik PDF įkėlimą ir jokios struktūrizuotos patikrinimų duomenų, API bus riboto naudingumo.

Defektų įrašai turėtų apimti pranešimo šaltinį, vairuotoją, transporto priemonę ar priekabą, laiko žymę, defekto kategoriją, sunkumą, taisymo statusą ir pasirašymą. Operatoriams, turintiems kasdienius apžvalgos patikrinimus, vairuotojų patikrinimai turėtų būti prieinami atskirai arba aiškiai susieti, įskaitant nulinio defekto pateikimus. Praktikoje nulinio defekto įrodymai dažnai yra tokie pat svarbūs kaip ir gedimų pranešimai, nes tai rodo, kad patikrinimas įvyko.

Vairuotojų įrašai turėtų apimti pažymėjimų kategorijas, galiojimo datas, patikrinimo datas, patvirtinimus, jei jie buvo įrašyti, Driver CPC terminus ir DQC statusą. Jei pasikliaujate išoriniais pažymėjimų patikrinimais, paklauskite, ar sistema saugo tik rezultatą, ar taip pat patikrinimo įrodymą ir datą, kada jis buvo atliktas.

Tachografo įrašai reikalauja kruopštaus palyginimo. Kai kurie produktai teigia, kad turi tachografo integraciją, kai jie tik saugo santraukos pažeidimų ataskaitas. Operatoriams, dirbantiems pagal O-licenciją, gali prireikti vairuotojo ir transporto priemonės vieneto atsisiuntimo istorijos, trūkstamos ridos ar trūkstamų duomenų žymėjimo, pažeidimų ataskaitų, darbo laiko matomumo ir įrodymų, kad atsisiuntimai buvo peržiūrėti. Jei lyginate sistemas iš dalies šiuo aspektu, mūsų vadovas apie tachografo analizę mažoms flotilėms nurodo, į ką atkreipti dėmesį.

Dokumentų saugojimas taip pat yra svarbus. API turėtų idealiai palaikyti pridėtus failus prieš transporto priemones, priekabas, vairuotojus ir įvykius. Tai apima MOT sertifikatus, metinių testų rezultatus, patikrinimų lapus, draudimo dokumentus, kalibravimo sertifikatus, dirbtuvių sąskaitas ir korespondenciją. Atitikties įrašas dažnai yra tik pilnas, kai struktūrizuoti duomenys ir dokumentas yra kartu.

Galiausiai, patikrinkite datų logiką. JK operatoriai dažnai planuoja pagal kalendorinius mėnesius, fiksuotus intervalus ir ISO savaitės ataskaitas. Jei jūsų dirbtuvės, planuotojas ar mėnesinis paketas veikia pagal ISO savaitę, sistema neturėtų priversti nepatogių datų konversijų ar slėpti originalių terminų taisyklių.

Kaip integracijos veikia kasdieniniame flotilės valdyme

Yra didelis praktinis skirtumas tarp duomenų importavimo kartą per mėnesį ir gyvo atitikties proceso vykdymo su šviežiais įrašais.

Rankiniai importai yra paprasčiausias pasirinkimas. Jūs eksportuojate CSV iš vienos sistemos ir įkeliat ją į kitą. Tai gali būti pakankama pradiniam migravimui ar retkarčiais masiniams atnaujinimams, tačiau tai nėra gyva integracija. Tai priklauso nuo to, ar kas nors prisimena tai padaryti, patikrina failo formatą ir ištaiso nesėkmes. Statiniams įrašams tai gali būti priimtina. Defektams, pažymėjimų patikrinimams ar tachografo veiklai tai paprastai nėra.

Planuoti sinchronizavimai yra kitas žingsnis. Jie vyksta nustatytu laiku, dažnai naktį arba kas valandą, ir automatiškai perkelia įrašus tarp sistemų. Pavyzdžiui, dirbtuvių platforma gali atnaujinti užbaigtus patikrinimus naktį, arba HR sistema gali kiekvieną vakarą stumti naujus vairuotojų pradžios įrašus. Planuoti sinchronizavimai dažnai yra visiškai tinkami atitikties užtikrinimui, jei laikas atitinka riziką. Naktinis sinchronizavimas metinių testų datoms paprastai yra gerai. Naktinis sinchronizavimas tą pačią dieną defekto išvalymui gali būti ne.

Tiesioginė REST API prieiga suteikia daugiau kontrolės. Jūsų programinė įranga arba ataskaitų rengimo sluoksnis gali prašyti dabartinio įrašo, kai to reikia, sukurti naujus įrašus arba atnaujinti esamus pagal tiekėjo leidimus. Tai naudinga, kai operatoriai nori vieno tiesos šaltinio, tačiau kelių sujungtų įrankių, tokių kaip atlyginimų, dirbtuvių valdymo, dokumentų kontrolės ar agentūros įdarbinimo. Tai taip pat palengvina išimčių ataskaitų rengimą, pavyzdžiui, identifikuojant transporto priemones, kurių patikrinimai turi būti atlikti per artimiausias 14 dienų, tačiau neturi priskirtos dirbtuvių rezervacijos.

Webhooks sprendžia kitą problemą. Vietoj to, kad jūsų sistema nuolat klaustų, ar kas nors pasikeitė, atitikties platforma siunčia pranešimą, kai įvyksta pokytis. Tai naudinga tokiems įvykiams, kaip defekto pranešimas, transporto priemonės perėjimas į VOR, vairuotojo dokumento galiojimo pabaiga arba patikrinimo pasirašymas. Webhooks dažnai yra švariausias būdas išlaikyti kitą sistemą šviežią be nuolatinio apklausimo.

Kasdieniame flotilės valdyme teisingas modelis dažnai yra mišinys. Masiniai pagrindiniai duomenys gali būti gaunami per suplanuotą sinchronizavimą. Laiko jautrūs įvykiai gali naudoti webhooks. Istoriniai ataskaitų rengimai gali naudoti REST API užklausas. Klaida yra manyti, kad visi "integracijos" yra ekvivalentai. Jie nėra. Paklauskite, kas nutinka, kai vairuotojas pateikia defektą 05:30, kai dirbtuvės jį išvalo 07:10, ir kai transporto biuras gali matyti, kad transporto priemonė yra tinkama išvykti. Tas atsakymas pasako jums daug daugiau nei funkcijų sąrašas.

Taip pat verta patikrinti, kaip įspėjimai įsilieja į procesą. Jei sistema gali atskleisti terminus ir statusus per API, tačiau negali patikimai informuoti žmonių, kurie turi veikti, vis tiek turite sekti terminus rankiniu būdu. Mes atskirai rašėme apie el. pašto įspėjimus dėl atitikties terminų, nes priminimai yra naudingi tik tada, kai jie atitinka faktinį kontrolės procesą.

Ką patikrinti audito takui ir Transporto komisaro įrodymams

Operatorių licencijos atitikties atveju audito takas nėra techninis priedas. Tai yra įrodymų dalis.

Pradėkite nuo pasirašytų įrašų. Jei vairuotojas atlieka kasdienį patikrinimą, ar sistema gali parodyti, kas jį pateikė, kada jis buvo pateiktas ir kas buvo deklaruota tuo momentu? Jei dirbtuvės uždaro defektą, ar gali parodyti, kas pažymėjo jį užbaigtu ir ar po to buvo pakeistas koks nors žodis? Įrašas, kurį galima perrašyti be pėdsakų, yra silpnas įrodymas.

Laiko žymės turėtų būti sistemos sugeneruotos ir matomos. Jums reikia sukūrimo datos ir laiko, užbaigimo datos ir laiko, ir, jei tai aktualu, pakeistos datos ir laiko. Jei įrašai gali būti atgal datuojami, tai turėtų būti kontroliuojama ir akivaizdu istorijoje. Klausime ar tyrime, nepaaiškintas atgal datavimas greitai sukelia problemų.

Pakeitimų istorija yra svarbi dėl tos pačios priežasties. Tinkamas audito takas turėtų rodyti, kas pasikeitė, kas tai pakeitė ir kada. Tai taikoma terminams, patikrinimų rezultatams, defektų statusui, vairuotojų kvalifikacijos datoms ir VOR laikotarpiams. Neužtenka parodyti tik naujausią vertę. Jei metinių testų data buvo pataisyta po perplanavimo, sistema turėtų išsaugoti tiek originalią, tiek pakeistą istoriją.

Dokumentų saugojimas turėtų būti susietas su pagrindiniu įrašu, o ne paliktas kaip laisvas failų išmetimas. Jei įkelsite patikrinimo lapą, stabdžių testų ataskaitą ar MOT praėjimo sertifikatą, jis turėtų būti prijungtas prie atitinkamos transporto priemonės ar priekabos įvykio ir likti ten. Tas pats taikoma vairuotojų įrodymams, tokiems kaip DQC kopijos ar Driver CPC patvirtinimai. Paieškos galimybė taip pat svarbi. Kai DVSA prašo pavyzdinės laikotarpio, jums reikia greitai atgauti teisingus dokumentus.

Taip pat atkreipkite dėmesį į išsaugojimą. Atitikties įrašai turi likti prieinami tiek laiko, kiek jums jų reikia teisiniams, operatyviniams ir audito tikslams. Paklauskite, ar ištrinti įrašai yra atkuriami, ar eksportai apima audito istoriją, ir ar priedai išeina naudojamu formatu, jei kada nors reikės perkelti sistemą.

Transporto komisaro įrodymams svarbu pateikimas. Jums reikia galėti parodyti aiškią chronologiją, o ne tik žalius duomenų bazės įrašus. Mėnesinis paketas, išimčių ataskaita ar transporto priemonės istorija turėtų būti prasminga kam nors, kas peržiūri, ar buvo laikomasi sistemų. Tai viena iš priežasčių, kodėl mes daug dėmesio skiriame failams paruoštų ataskaitų rengimui Operator Compliance. Jei vertinate šią rinkos pusę, mūsų straipsnis apie programinę įrangą, kuri išlaiko jūsų O-licencijos failą paruoštą yra tiesiogiai aktualus.

Kaip palyginti tiekėjus, nesikreipiant į funkcijas

Protinga palyginimo sistema prasideda nuo aprėpties, o ne blizgesio.

Pirmiausia išvardinkite atitikties sritis, kurias dabar reikia apimti. Transporto priemonės, priekabos, patikrinimai, defektai, MOT arba metinių testų datos, vairuotojų patikrinimai, Driver CPC, DQC, tachografo įrodymai, dokumentų saugojimas ir įspėjimai yra įprasti pagrindai. Tada pažymėkite, ar kiekvienas tiekėjas juos apima natūraliai, ar per integraciją, ar palieka juos už sistemos ribų. Tai padeda nesikreipti į periferines funkcijas.

Antra, įvertinkite nustatymo pastangas. Kai kurios sistemos atrodo lanksčios, nes gali būti konfigūruojamos bet kam, tačiau tai dažnai reiškia, kad turite patys sukurti atitikties procesą. Kitos jau turi JK operatorių licencijos darbo eigas. Transporto vadybininkams praktinis klausimas yra, kaip greitai sistema gali atspindėti priežiūros planuotoją, patikrinimų intervalus, vairuotojų failų patikrinimus ir ataskaitas, kurias iš tikrųjų naudojate. Mažesnis nustatymo krūvis nėra tik patogumas. Tai sumažina spragų tikimybę įgyvendinimo metu.

Trečia, išbandykite patikimumą. Paklauskite, ką apima API dokumentacija, kokie galiniai taškai yra prieinami, kaip veikia autentifikacija, kokie greičio apribojimai galioja ir kaip tvarkomos nesėkmės. Jei suplanuotas sinchronizavimas nepavyksta, kas apie tai žino? Jei webhookas nėra gautas, ar yra pakartotinio bandymo procesas? Jei įrašas atmetamas, ar priežastis aiški? Patikimumas yra daug svarbesnis nei ilgas sąrašas galinių taškų, kurių niekas nepasitikės gamyboje.

Ketvirta, įvertinkite tinkamumą JK atitikties darbui konkrečiai. Čia bendros transporto priemonių priemonės dažnai nusileidžia. Paklauskite, ar sistema sukurta pagal DVSA Gaires dėl kelių tinkamumo, ar priekabų įrašai yra pirmos klasės, ar pasirašyti defektų ir patikrinimų įrodymai yra standartiniai, ir ar ataskaitos būtų prasmingos VOL susijusiame peržiūroje ar Transporto komisaro tyrime. Jei atsakymas priklauso nuo individualaus vystymo pagrindinėms JK darbo eigoms, tai aiškiai užfiksuokite.

Penkta, patikrinkite, kaip tiekėjas tvarko sujungtas paslaugas. Jei naudojate tachografo analizę, pažymėjimų patikrinimus, dirbtuvių sistemas ar draudimo patikrinimus, paklauskite, ar šie ryšiai jau egzistuoja ir kokie įrodymai grįžta į įrašą. Tas pats taikoma, jei lyginate su produktais, tokiais kaip Fleetalyse ar Logivo.AI. Teisingas klausimas nėra, ar produktas turi platų funkcijų žemėlapį. Tai yra, ar svarbūs įrašai atkeliauja į teisingą vietą, su teisingomis laiko žymėmis ir įrodymais, be rankinio taisymo.

Galiausiai, paprašykite realaus darbo proceso demonstravimo. Ne bendro pardavimo turo. Paprašykite pamatyti, kaip transporto priemonė pridedama, patikrinimas suplanuojamas, defektas pranešamas, vienetas perkeliamas į VOR, remontas pasirašomas, transporto priemonė grąžinama į eksploataciją ir visa istorija eksportuojama. Tada paprašykite pamatyti vairuotojo failą su pažymėjimo patikrinimo įrodymais, Driver CPC ir DQC datomis, taip pat tachografo peržiūros statusu. Jei tiekėjas negali aiškiai parodyti šios sekos, API teiginys nėra lemiamas veiksnys.

Operator Compliance mes laikomės šios praktinės nuomonės, nes Fleeta Limited sukūrė sistemą iš gyvos operatorių patirties, o ne iš bendro transporto šablono. Kai lyginate sistemas, tai yra standartas, kurį reikia naudoti. Sutelkite dėmesį į tai, ar įrašai, integracijos ir audito takas iš tikrųjų palaiko JK operatorių licencijos atitiktį. Jei taip, API tampa naudinga. Jei ne, API yra tik dar viena funkcija sąraše.