Kaip webhook'ai integruoja laivyno atitiktį į jūsų sistemas

Jei jūsų laivyno atitikties įrašai jau yra šalia atlyginimų, dirbtuvių, personalo, finansų ar planavimo įrankių, integracija yra tokia pat svarbi kaip ir atitikties funkcijos. Praktikoje klausimas nėra, ar jūsų programinė įranga gali eksportuoti duomenis. Tai, ar tinkami žmonės ir sistemos yra informuojami tinkamu momentu, kad testavimo data pasikeitė, defektas buvo užfiksuotas, licencijos patikra nepavyko, DQC artėja, ar tachografo problema reikalauja veiksmų.

Čia webhook'ai gali būti naudingi. Daugeliui operatorių webhook'ų laivyno atitikties programinė įranga vidinėms sistemoms yra praktiškas vidurys tarp rankinio administravimo ir visiško pritaikymo REST API. Ji gali siųsti įvykius iš atitikties platformos, kai jie vyksta, todėl jūsų vidinės sistemos gali kurti užduotis, atnaujinti įrašus ir išsaugoti įrodymus, nelaukdamos, kol kas nors pastebės el. laišką ar paleis skaičiuoklę.

Ką operatoriai paprastai turi omenyje kalbėdami apie integraciją

Kai operatoriai klausia, ar atitikties programinė įranga „integruojasi“, jie paprastai turi omenyje vieną iš keturių dalykų.

Pirmiausia, jie gali turėti omenyje rankinį eksportą. Tai vis dar yra įprasta. Transporto biuras eksportuoja CSV su artėjančiomis MOT datomis, PMI, defektų istorija, vairuotojų patikromis ar tachografo pažeidimais, tada kas nors importuoja tai į kitą sistemą arba platina el. paštu. Tai veikia, tačiau tik jei biuras tai nuolat daro. Tai reikalauja daug darbo, lengva praleisti, ir silpna, kai reikia aiškaus audito pėdsako, rodančio, kada problema buvo nustatyta ir kas į ją reagavo.

Antra, jie gali turėti omenyje el. laiškų pranešimus. El. paštas yra naudingas, kad paskatintų veiksmus, ypač mažesniems operatoriams ar savininkams-vairuotojams. Licencijos galiojimo priminimas ar patikros pranešimas gali būti pakankamas, jei vienas asmuo valdo visą operaciją. Tačiau el. paštas nėra struktūrizuota integracija. Jis patikimai neatnaujina jūsų HR sistemos, dirbtuvių lentos, agentūros užsakymo proceso ar BI ataskaitų. Jei pranešimas lieka neperskaitytas pašto dėžutėje, procesas ten ir sustoja. Mes aptarėme kai kurias šias ribas mūsų gide apie laivyno programinę įrangą, kuri pažymi atitikties terminus el. paštu.

Trečia, jie gali turėti omenyje REST API. REST API suteikia jūsų vidiniams kūrėjams būdą užklausti duomenis iš atitikties platformos, kurti įrašus ir sinchronizuoti sistemas kontroliuojamu būdu. Tai yra lanksčiai ir galinga. Tai dažnai yra teisingas atsakymas, kai reikia visiškos dvipusės integracijos, gilių ataskaitų ar reguliarios sinchronizacijos tarp kelių verslo sistemų. Jei jūsų komanda lygina API pagrindu paremtas galimybes, mūsų gidas apie kaip palyginti laivyno sistemas su REST API išdėsto praktinius punktus, kuriuos reikia patikrinti.

Ketvirta, jie gali turėti omenyje webhook'us. webhook'ai yra įvykių valdomi. Vietoj to, kad jūsų vidinė sistema nuolat klaustų: „ar kas nors pasikeitė?“, atitikties programinė įranga siunčia pranešimą, kai įvyksta konkretus įvykis. Tas įvykis gali būti vairuotojo licencijos patikros rezultatas, naujai praneštas defektas, pasikeitęs patikros rezultatas, atnaujinta tachografo būsena arba artėjanti data, peržengusi slenkstį.

Tai yra pagrindinis skirtumas. REST API paprastai yra užklausų pagrindu. webhook'ai paprastai yra stūmimo pagrindu. Rankiniai eksportai ir el. laiškų pranešimai labiau priklauso nuo žmonių. webhook'ai yra viduryje, jie gali būti paprasti įgyvendinti, tačiau vis tiek suteikia jūsų sistemoms momentinius, mašininio skaitymo atnaujinimus.

Daugeliui JK laivynų to pakanka. Transporto vadybininkas gali vis dar dirbti kasdien Operator Compliance viduje, tačiau dirbtuvių sistema, agentūros užsakymo srautas, atlyginimų išimčių sąrašas ar vidinė užduočių lenta gali automatiškai reaguoti, kai įvyksta atitikties įvykis.

Kada webhook'ai yra geresnis pasirinkimas

webhook'ai yra stipriausi, kai svarbus laikas.

Gerai pavyzdys yra terminų valdymas. Jei transporto priemonės MOT ar metinės patikros data yra pakeista, arba periodinės patikros data yra perkeliama dėl naudojimo ar dirbtuvių pajėgumų, galite norėti, kad vidinė užduotis būtų sukurta iš karto. REST API apklausa kas kelias valandas gali būti priimtina valdymo ataskaitoms, tačiau ji yra mažiau naudinga, kai praleista data gali išvesti transporto priemonę iš eismo arba palikti jus pažeidžiamą audito metu.

Tas pats taikoma defektams. Jei vairuotojas praneša apie saugos defektą per apžiūros patikrinimą, galite norėti, kad jūsų vidinė priežiūros lenta būtų atnaujinta iš karto, VOR vėliava būtų taikoma viduje, ir atitinkamas vadybininkas būtų informuotas. Laukdami kito suplanuoto importo galite sukurti spragą tarp defekto užfiksavimo ir transporto priemonės kontrolės. Operatoriams, naudojantiems mišrias sistemas, webhook'ai gali sukelti tą kontrolės žingsnį, kai defektas yra užregistruotas.

Vairuotojų patikros yra dar vienas stiprus naudojimo atvejis. Kai DVLA licencijos patikros rezultatas pasiekia, arba kai Driver CPC ir DQC galiojimo slenksčiai yra pasiekti, vidinės sistemos dažnai turi reaguoti iš karto. Agentūra gali prireikti sustabdyti pamainų siūlymą. Planavimo komanda gali prireikti pašalinti vairuotoją iš maršruto. HR gali prireikti sukurti užduotį dėl sekamųjų dokumentų. Jei jūsų procesas priklauso nuo gyvos būsenos, webhook'ai paprastai yra praktiškesni nei periodinė apklausa.

Tachografo susiję įvykiai taip pat gerai tinka webhook'ams. Jei pasirodo trūkstamas atsisiuntimas, peržengiamas pažeidimo slenkstis, arba vairuotojo analizės rezultatas reikalauja pripažinimo, galite norėti, kad tas įvykis būtų perduotas tiesiai į jūsų vidinį darbo srautą. Tai ypač naudinga, kai viena komanda peržiūri tachografo analizę, tačiau kita komanda tvarko vairuotojų valdymą, atlyginimų užklausas ar drausmines procedūras. Įvykis gali būti perduotas tinkamai sistemai, nesiremiant asmeniu, kuris jį perrašys.

Operatoriams, dirbantiems griežtu savaitiniu ciklu, įskaitant ISO savaitės pagrindu planavimo ar atlyginimų procesą, webhook'ai taip pat gali sumažinti nepatogius laiko klausimus. Vėlyvas penktadienio įvykis gali būti išsiųstas iš karto, o ne laukiant kito partijų darbo po savaitės.

Trumpai tariant, webhook'ai paprastai yra geresnis pasirinkimas, kai verslo pasekmės dėl delsimo yra realios. Tai paprastai apima:

• artėjančius teisinius ar operacinius terminus
• naujus defektus ir VOR sprendimus
• nepavykusius ar pasikeitusius licencijos patikros rezultatus
• Driver CPC ir DQC galiojimo signalus
• tachografo išimtis, pripažinimus ir trūkstamus duomenų įvykius
• būsenos pokyčius, kurie turėtų blokuoti transporto priemonės ar vairuotojo paskyrimą

Tai nepakeičia REST API. Tai papildo jį. Daugelis geresnių integracijų naudoja abu. webhook'ai informuoja jūsų vidines sistemas, kad kažkas pasikeitė, tada REST API gali gauti išsamesnius duomenis, jei reikia.

Kada webhook'ai gali būti nepakankami

webhook'ai nėra stebuklas, ir jie nėra be priežiūros.

Pirmasis pavojus yra praleisti įvykiai. Jei jūsų gavimo taškas neveikia, laiku pasibaigia arba atmeta apkrovą, kas vyksta toliau yra svarbu. Jums reikia žinoti, ar siuntėjas bando dar kartą, kaip dažnai, kiek laiko, ir ar nesėkmingi pristatymai yra matomi jūsų komandai. Be tinkamos pakartotinio bandymo proceso ir nesėkmių žurnalo, galite manyti, kad įvykis buvo gautas, kai jis nebuvo.

Antrasis klausimas yra apkrovos dizainas ir duomenų žemėlapis. webhook'as gali pasakyti, kad defektas buvo sukurtas, tačiau jūsų vidinė sistema vis tiek turi žinoti, kuris turtas, kuris vairuotojas, kokia rimtumo laipsnis, koks objektas ir kokie statuso vertės atitinka jūsų įrašus. Jei jūsų transporto priemonių ID, darbuotojų ID ar priekabų nuorodos yra nesuderinamos tarp sistemų, integracijos pastangos greitai pereina nuo „paprasto pranešimo“ prie duomenų valdymo užduoties.

Trečia, webhook'ai ne visada suteikia jums pilną audito pėdsaką patys. Jie puikiai tinka siųsti įvykį, tačiau Transporto komisaro failas paprastai reikalauja daugiau nei įrodymo, kad įvykis buvo išsiųstas. Jums gali prireikti pasirašytų patikros įrašų, taisymo įrodymų, pripažinimo istorijos, defekto uždarymo pastabų, vairuotojų deklaracijų ir aiškaus įrašo, kas ir kada peržiūrėjo. webhook'as gali sukelti jūsų procesą, tačiau pagrindinė atitikties sistema vis tiek turi tinkamai laikyti įrodymų įrašus.

Taip pat svarbu saugumas. Bent jau turėtumėte tikėtis autentifikuoto pristatymo, transporto šifravimo ir būdo patikrinti, kad pranešimas iš tikrųjų atėjo iš siuntėjo. Jei webhook'as gali kurti ar keisti įrašus jūsų vidinėse sistemose, silpna autentifikacija nėra priimtina. Turėtumėte paklausti, ar platforma palaiko pasirašytas apkrovas, slaptažodžių rotaciją, IP leidimų sąrašą, jei reikia, ir atskiras kredencialus pagal aplinką.

Taip pat yra techninio nuosavybės klausimas. webhook'ų pagrindu veikianti sistema vis tiek reikalauja, kad jūsų versle būtų kas nors, arba patikimas tiekėjas, kuris prižiūrėtų galinius taškus, stebėtų nesėkmes, versijų žemėlapius ir testuotų pakeitimus. Jei jūsų vidinė parama yra silpna, „lengva“ integracija vis tiek gali tapti trapia laikui bėgant.

Galiausiai, webhook'ai yra įvykių valdomi, o ne užklausų valdomi. Jie nėra idealūs, jei jūsų pagrindinis poreikis yra platus istorinis ataskaitos, ad hoc analizė ar sudėtingas duomenų išgavimas per metus. Tam REST API, suplanuotas eksportas ar tiesioginė ataskaitų srautas gali būti tinkamesni.

Todėl riba nėra ta, kad webhook'ai yra prasti. Tai, kad jie geriausiai naudojami operatyviniams signalams, o ne kaip vienintelis integracijos įrankis kiekvienam tikslui.

Ką palyginti laivyno atitikties programinėje įrangoje

Jei lyginate sistemas, nesustokite ties „taip, ji turi webhook'us“. Tikras klausimas yra, ar webhook funkcija yra naudinga operatoriaus licencijos darbui.

Pradėkite nuo įvykių aprėpties. Kurie įvykiai iš tikrųjų gali būti siunčiami? Transporto priemonė pridėta, testavimo data pakeista, defektas užfiksuotas, defektas uždarytas, patikra baigta, patikra vėluoja, dokumentas artėja prie galiojimo pabaigos, licencijos patikra grąžinta, Driver CPC artėja, DQC artėja, tachografo pranešimas sukurtas, pripažinimas baigtas, VOR būsena pasikeitė, priekabos būsena pasikeitė ir taip toliau. webhook funkcija, kuri apima tik siaurą veiksmų rinkinį, gali nepalaikyti jūsų proceso.

Tada pažvelkite į apkrovos detales. Ar kiekvienas įvykis apima pakankamai informacijos, kad būtų naudingas pats savaime? Turėtumėte tikėtis stabilių identifikatorių, įvykių laiko žymų, atitinkamų galiojimo datų, statuso vertybių ir pakankamai konteksto, kad atitiktų tinkamą transporto priemonę, priekabą ar vairuotoją jūsų sistemoje. Jei kiekvienas įvykis priverčia jūsų kūrėjus atlikti kelias sekimo užklausas, kad tik identifikuotų įrašą, įgyvendinimas tampa lėtesnis ir trapus.

Dokumentacija yra svarbesnė už pardavimo teiginius. Paklauskite, ar galite pamatyti įvykių sąrašus, pavyzdinius apkrovimus, autentifikavimo metodus, pakartotinio bandymo taisykles, laiko limitus, klaidų tvarkymą ir versijų politiką. Jei dokumentacija yra menka, jūsų kūrėjai galiausiai atranda integraciją bandydami ir klysdami.

Autentifikavimas ir saugumas turėtų būti aiškūs. Patikrinkite, ar webhook'ai naudoja bendrus slaptažodžius, pasirašytus antraštes, nešiklio žymes ar kitą metodą. Paklauskite, kaip slaptažodžiai yra keičiami ir ar testinė ir gyva aplinka yra atskirtos. Dėl laivynų, tvarkančių vairuotojų asmens duomenis, tai nėra šoninis klausimas.

Testavimo parama yra dar vienas praktinis patikrinimas. Ar galite siųsti testinius įvykius pagal poreikį? Ar yra smėlio dėžė? Ar įvykiai gali būti pakartoti, jei jūsų galinis taškas nepavyksta? Ar jūsų kūrėjai gali peržiūrėti pristatymo žurnalus? Šie punktai sutaupo laiko diegimo metu ir po bet kokių būsimų pakeitimų.

Užimtumas ir parama taip pat reikalauja dėmesio. Jei webhook paslauga turi sutrikimų, kaip sužinosite? Jei pristatymai nepavyksta, kas pirmiausia tai pamatys, jūsų komanda ar mūsų? Kokia parama yra numatyta tirti įvykių nesėkmes, kurios paveikia atitikties darbą?

Galiausiai, paklauskite, ką sistema daro dėl įrodymų. Integracija gali maitinti jūsų vidines priemones, tačiau pati atitikties platforma vis tiek turi atlaikyti DVSA patikrinimus. Pasirašyti įrašai, datos žymėti veiksmai, patikros istorija, defektų valdymas, tachografo įrodymai ir dokumentų kontrolė turėtų būti lengvai pateikiami mėnesiniam paketui, vidiniam auditui ar Transporto komisaro posėdžiui. Mūsų gidas apie kaip palyginti laivyno atitikties sistemas O-licencijos darbui išsamiau nagrinėja šią pusę.

Taip pat galite susidurti su platformomis, tokiomis kaip Fleetalyse ar Logivo.AI platesniuose laivyno programinės įrangos palyginimuose. Tas pats kontrolinis sąrašas taikomas. Paklauskite, kokius įvykius jie atskleidžia, kaip įrodymai yra išlaikomi ir ar integracija atspindi tikrus JK operatoriaus licencijos darbo srautus, o ne bendrą laivyno administravimą.

Kaip JK atitikties reikalavimai keičia sprendimą

JK laivyno atitiktis nėra tik datų dienoraštis. Integracijos pasirinkimas turėtų atspindėti įrašus, kuriuos gali tekti pateikti pagal operatoriaus licenciją.

Prekių transporto priemonių ir PSV operatoriams MOT ir metinės patikros datos yra akivaizdūs pavyzdžiai, tačiau tai tik dalis paveikslo. DVSA Gidas dėl kelių tinkamumo reikalauja įrodymų apie saugos patikras, defektų pranešimus, taisymą, apkrovos stabdymo testus, kai tai taikoma, ir tinkamą transporto priemonių ir priekabų kontrolę. Jei jūsų programinė įranga siunčia webhook, kai patikra baigta, tai yra naudinga. Tačiau jums taip pat reikia patikros lapo, pasirašymo, rezultato ir bet kokių susijusių remontų, saugomų formatu, kurį galite vėliau atgauti.

Vairuotojų atitiktis turi panašių JK specifinių poreikių. webhook'as, kuris informuoja jūsų HR sistemą, kad Driver CPC ar DQC artėja prie galiojimo pabaigos, yra naudingas, tačiau pagrindinis įrašas vis tiek turi rodyti, kas buvo patikrinta, kada ir kokia veiksmas buvo atliktas. Licencijos patikroms JK procesas dažnai koncentruojasi aplink DVLA duomenis ir vidinę peržiūrą dėl patvirtinimų, kategorijų ir galiojimo datų. Jei įvykis pasiekia jūsų vidinę sistemą, tačiau šaltinio įrašas yra silpnas, integracija neišsprendė atitikties problemos.

Transporto priemonių būsenos sprendimai taip pat yra svarbūs. VOR žymeklis nėra tik operatyvinis užrašas. Jis gali tapti svarbiu kontrolės įrodymu, jei defektas yra užfiksuotas. Jei jūsų webhook integracija atnaujina planavimo sistemą, tačiau ne faktinį atitikties įrašą, galite vis tiek turėti sunkumų parodyti nuoseklų veiksmų grandinę.

Draudimo ir tapatybės patikros taip pat gali paveikti darbo srautą, ypač mišriems laivynams, agentūroms ir taksi darbui. Kai kurie operatoriai kryžminiai tikrina registracijos ir politikos detales su askMID duomenimis, pateiktais per Motor Insurers' Bureau, kartais vadinamu MIB. Tai nėra jūsų pačių draudimo kontrolės pakaitalas, tačiau tai gali paveikti, kaip transporto priemonių įrašai yra patvirtinami viduje. JK šie praktiniai patikrinimai dažnai yra šalia operatoriaus licencijos atitikties, o ne viename teisiniame kontekste, todėl jūsų integracija gali tekti juos sujungti.

Ten, kur JK skiriasi nuo ES apskritai, operatoriaus licencijos režimo detalės ir tai, kaip įrodymai pateikiami Transporto komisariui, turėtų lemti dizainą. Bendroji ES laivyno platforma gali pakankamai gerai tvarkyti aptarnavimo priminimus, tačiau JK operatoriai dažnai reikalauja stipresnės dokumentų kontrolės, aiškesnių defektų ir patikros įrodymų, ir įrašų, kurie atitinka VOL lūkesčius ir DVSA kelio ar biuro pagrindu atliekamus patikrinimus.

Kuri konfigūracija tinka skirtingiems operatoriams

Nėra vieno teisingo nustatymo kiekvienam laivynui.

Vežėjams, turintiems dirbtuves, priekabas, kelis depus ir formalią transporto valdymą, webhook'ai dažnai yra naudingiausi kaip mišraus modelio dalis. Naudokite atitikties platformą kaip tiesos šaltinį. Stumkite skubius įvykius į dirbtuvių, planavimo ir HR sistemas per webhook'ą. Naudokite REST API platesnėms ataskaitoms ir suderinimui. Tai suteikia momentinį veiksmą dėl defektų, patikrų, licencijų patikrų ir tachografo įvykių, tuo pačiu palaikydama valdymo ataskaitas ir duomenų kokybės patikrinimus.

Vanų laivynams ir kurjerių operacijoms pasirinkimas priklauso nuo masto ir kontrolės. Mažesni laivynai gali gerai susidoroti su nepriklausoma programine įranga ir el. laiškų pranešimais. Dideli kurjerių laivynai, turintys vidinį tvarkymą, subrangovų kontrolę ar agentūros naudojimą, dažnai gauna naudos iš webhook'ų licencijų patikroms, dokumentų galiojimo ir defektų eskalacijai. Jei esate toje grupėje, mūsų straipsnis apie vairuotojų licencijų patikros programinę įrangą kurjerių laivynams gali padėti formuoti vairuotojo pusę.

Autobusų ir mikroautobusų operatoriai dažnai reikalauja tvirtesnių ryšių tarp inžinerijos, grafiko ir vairuotojų atitikties. Nepavykusi defekto procedūra ar vėlyvas kvalifikacijos klausimas gali nedelsiant paveikti suplanuotas paslaugas. Tokioje aplinkoje webhook'ai paprastai yra vertingi, nes jie gali sukelti operatyvinį veiksmą, nelaukdami partijų importo. REST API vis tiek gali būti reikalingas išsamesniam inžinerijos ir atlyginimų duomenų mainams.

Savininkai-vairuotojai yra kitokie. Daugelis visai nereikalauja vidinių sistemų. Gerai struktūrizuota nepriklausoma atitikties platforma dažnai yra geriausias atsakymas, jei ji tvarko įrašus tvarkingai, kad atitiktų DVSA ir Transporto komisaro reikalavimus. webhook'ai tampa aktualūs tik tuo atveju, jei yra buhalteris, priežiūros teikėjas ar klientų portalas, kuriam iš tikrųjų reikia gyvų būsenos atnaujinimų.

Įdarbinimo ir vairuotojų agentūros dažnai mažiau rūpinasi transporto priemonių priežiūros įvykiais ir daugiau apie licencijų patikras, Driver CPC, DQC, teisę dirbti procesų ryšius ir momentinius būsenos pokyčius, kurie paveikia užsakymus. Čia webhook'ų valdomi pranešimai į užsakymo ar CRM sistemą gali būti naudingesni nei visiškas API kūrimas, nes pagrindinis poreikis yra greitai sustabdyti netinkamus paskyrimus.

Taksi ir privačių nuomų firmos patenka į kitą mišrią kategoriją. Jiems gali prireikti derinio vairuotojų dokumentų kontrolės, transporto priemonių datų ir draudimo patikros. Kai kurie pasinaudos paprastesne konfigūracija, kiti - įvykių valdymo integracija į išsiuntimo ar vairuotojų įdarbinimo įrankius. Šiam sektoriui mūsų puslapis taksi laivyno atitikties poreikiams išdėsto pagrindines įrašų laikymo problemas.

Operator Compliance, sukurtas Fleeta Limited, prie šio klausimo žiūrime iš kasdienės realybės, kaip valdyti atitinkančius laivynus pagal JK taisykles, o ne iš bendro programinės įrangos šablono. Jei jūsų pagrindinis poreikis yra patikimi įrašai ir pasirašyti įrodymai, nepriklausoma programinė įranga gali būti pakankama. Jei jūsų vidinės sistemos turi reaguoti iš karto į atitikties įvykius, webhook'ai dažnai yra praktiškas sprendimas. Jei jums reikia visiškos sinchronizacijos ir gilesnės sistemos kontrolės, pridėkite REST API prie paveikslo. Teisingas atsakymas yra tas, kuris padeda jūsų transporto komandai greitai veikti, išlaiko įrodymus pilnus ir atlaiko, kai DVSA ar Transporto komisaras prašo pamatyti failą.