Kuidas planeerisime planeerimatut ehk kuidas me digitaliseerisime liiklusõnnetusest teavitamise protsessi

Kuidas lahendatakse liiklusõnnetusi praegu?

Paljud meist on mingisugusel ajahetkel leidnud ennast osalisena liiklusõnnetusest. Sõltumata spetsiifilise õnnetuse asjaoludest on väga mitmete jaoks tegemist äärmiselt stressirohke olukorraga – mängus on ju rohkete muude faktorite kõrval nii tervis, raha kui aeg.

 

Kõikide kõrvaliste tegurite juures tuleb probleemi lahendamiseks ja liiklusvoo vabastamiseks olukord fikseerida ning kogutud info korrektsetele kindlustuspakkujatele edastada. Traditsiooniliselt on olnud esmane abimees nn sini-kollane leht nimega „Liiklusõnnetuse teade“, kus on võimalik tekstide ja ristikeste kõrval ka olukorda joonistada. Tuleb mainida, et vormi täitmine võib olla keerukas ka varasema täitmiskogemusega juhtidele.

 

Talletatud informatsioon võib olla lõppformaadis puudulik või poolik ning kindlustusandjad peavad sündmuse asjaolude selgitamiseks kasutama kolmandate osapoolte abi (pealtnägijad, kaamerasalvestised, politseiametnikud jpt).

 

Ideaalses maailmas peab antud leht olema sõidukis käepärast kõikidel liikluses osalevatel juhtidel. Reaalsuses leiavad paljud end olukordadest, kus ootamatus tabab meid hetkel, mil korrektsed vormid on käeulatusest väljas. Sellistes olukordades pöördutakse tihti häirekeskuse poole palvega, et neid antud olukorras samm-sammu haaval juhendatakse. 

 

 

Olemasoleva lahenduse puudused:

 

• tegemist on paberkandjal fikseeritava infoga, mis nõuab antud paberkandja olemasolu;
• kasutajatele on regulaarselt ebaselge, millise spetsiifilise juhtumiga on tegemist ning kuidas seda korrektselt üles märkima peab;
• kasutajate käekiri, stiil ning oskused materjali täita on erinevad. Sellest tulenevalt on ka paberkandja väärtus hilisemal kindlustusandja poolsel detailuuringul ebaühtlane;
• kahjuteate vormistamisel keskenduvad asjaosalised rohkem süüdlase otsimisele kui olukorra fikseerimisele – vaidluse korral ei ole alati põhjarajavat tugipunkti, millele keskenduda;
• paberkandjat saab realistlikult täita 1 asjaosaline korraga ning ühes eksemplaris. Info hoiustamine mitmele osapoolele nõuab kas mitmekordset täitmist või originaali pildistamist;
• paberkandjal sisestatud informatsioon on staatiline ning tuleb reeglina duplikaadina sisse kanda kindlustusandja poolt pakutavasse digitaalsesse lahendusse.

 

 

Kuidas infotehniliste vahenditega praegust olukorda parandada?

Kujutle, et leiad end ühte või teistpidi ülalmainitud olukorrast – kuidas on sinu arvates kõige kiirem ja mugavam sinult nõutavat informatsiooni teisele osapoolele ja kindlustusandjale edasi anda?

 

Paljude jaoks on kõige loogilisem variant kasutada ära tänapäevaste mobiilsidevahendite võimekust. Oled kindlasti kuulnud väljendit „pilt räägib rohkem kui tuhat sõna“. Erinevate arvamuste ja huvidega stressirohkes olukorras peab antud väljend igati paika.

 

Pilt sündmuskohast on võimas infoallikas, millelt saab lugeda rohkem informatsiooni - asukoha, sõidukite positsiooni, liiklusmärkide ja vigastuste kohta - kui isegi väga osav sõnasepp suudab tekstiliselt kirja panna.

 

Seadsime koos Eesti Liikluskindlustuse Fondiga projekti lennukates esimestes etappides eesmärgiks keskenduda sellele, mis on kõige olulisem. Vaadeldes liiklusõnnetustes osalejate statistilist keskmist (mees vanuses 25-35 aastat), on rutakas kasutusloo põhjal võtta vastu otsuseid, mis kõnetavad ainult kasutajaid, kes kõige sagedamini rakendusega kokku puutuvad.

 

Korrektse lahenduse leidmisel otsustasime astuda veel sammu tagasi ning lihtsustada protsessi viisil, mis kõnetab märgatavalt laiema kogemus- ja oskuspagasiga kasutajakonda. Selle saavutamiseks otsustasime rakendada ja korduvkasutada võimalikult lihtsaid elemente ning vaateid. Ühe vaate eesmärk peab alati olema selgelt mõistetav ning üheselt arusaadav. 

 

 

Standardse pildistamise kõrval on Eesti väga unikaalses olukorras: e-riiklusele ja tsentraliseeritud infovahetusele keskenduv infostruktuur võimaldab meile ligipääsu andmeaitadele, mida Euroopa ning maailma teised riigid nautida ei saa. Ühe sellise andmeaidana saab rakendus pärida sõiduki registrinumbri baasil andmeid kehtivate kindlustusandjate kohta.

 

Kindlustusandja informatsioonile ligipääs võimaldab rakendusel edastada täidetud informatsiooni automaatselt kindlustusandjate andmebaasidesse. Sellega kaob kasutajal vajadus juhtumi fikseerimisel täita sama informatsiooni dublikaadina mitmesse keskkonda.

 

 

Kumb on parem: mobiilirakendus või veebirakendus?

Igasuguse mobiilselt kasutatava rakenduse puhul on alati esimene aste võtta vastu sisuline otsus, kas liikuda edasi mobiilirakenduse (Native-app) või veebirakendusega (Web-app):

 

• mobiilirakendus – lokaalselt seadmesse laetav rakendus, mille uuendamine ja haldus käivad läbi operatsioonisüsteemi haldurite, näiteks Apple iOS App-store või Android OS Play Store. Rakendus on avatav seadmesse laetud ikooniga.
• veebirakendus – veebilehitsejas jooksutatav veebileht, mis ei nõua eraldi allalaadimist ega manuaalset uuendamist kasutaja poolt. Rakendus on avatav veebilehe domeenilt. 

 

Plusse ja miinuseid võib leida mõlemale lahendusele ohtralt. Native-appi omadusi oleme varasemalt kirjeldanud oma artiklis Native või cross-platform – millist lähenemist mobiilirakendustel (äppidel) valida?

 

Meie jaoks jäi peamise eesmärgistusena lauale vajadus luua rakendus, mis on võimalikult lihtsasti uuendatav. Veebirakenduse puhul on rakenduvad muudatused kohesed ning ei nõua kasutajalt eraldi rakenduse uuendamist.

 

Kõnealune rakendus on esimene omalaadne maailmas ning oodatavast kasutajate kasvust või soovist millalgi uutele turgudele liikuda, peab see olema nii horisontaalselt kui vertikaalselt skaleeritav.

 

Horisontaalsest ja vertikaalsest skaleeritavusest metafooride keeles: võtame metafooriliselt eesmärgiks, et liivakarjäärist on vaja kalluritega ära vedada 600 tonni liiva ning ühe kalluri vedamisvõimekus on 30 tonni. Vertikaalselt skaleeritud operatsioon tähendaks auto mootori ning kasti mahutamise suurendamist, mis muudab ühe sõidukorraga veetava koguse suuremaks. Horisontaalsel skaleerimisel aga lisatakse - ühe sõiduki vedamisvõimsust muutmata - autoparki juurde lisanduvaid kallureid.

 

Valiku tegemisel kujutasime samuti ette, millise kasutajakogemuse osaliseks saab õnnetusse sattuja juhul kui kokkupõrge leiab aset näiteks Põlvamaa metsade vahel. Sellisel hetkel võib pidada enamiku jaoks täiesti ebamõistlikuks rakenduse otsimist, alla laadimist ja registreerimisprotsessi. Pöördutakse tagasi paberkandjale, mis tähendaks, et loodud rakendus on teatud olukordades kasutajatele kättesaamatu.

 

Tänapäeva veebitehnoloogilised arengud võimaldavad ka veebirakendustele ligipääsu seadme GPS’ile ning sellest tulenevalt täitis otsus liikuda edasi veebirakendusega kõik vajalikud kastikesed.

 

 

Kuidas panime mõlemast kokku parima ehk pidev integratsioon + pidev kasutuselevõtt

Mobiilirakendusest loobumisel on üheks esmaseks mureks kiirus ja versioonihaldus. Mobiilirakendused on optimiseeritud spetsiifilistele seadmetele ning sellest tulenevalt on nende kasutuskiirus märgatavalt parem.

 

Mobiilirakendused pakitakse kokku viisil, kus erinevate versioonide vahel liikumine on võrdlemisi mugav ning intuitiivne. Veebirakenduse kasuks otsustamisel on antud funktsionaalsus kadunud – või kas ikka on?

 

 Originaaljoonis pärineb siit.

 

Pidev integratsioon (CI - Continuous Integration) ning kasutuselevõtt (CD – Continuous Delivery) on nagu nimigi ütleb, loodud toetama võimalikult sujuvat ja mugavat arendustsüklit. Struktuur jaguneb laias laastus kolmeks osaks:

 

• Image – tõmmis konkreetsest visuaalsest/tehnilisest arendusest. Arenduse tõmmis on pakitud element, mida on võimalik kasutajatele läbi serveri kuvada;
• Harbor – versioonihaldus, mis hoiustab erinevaid Image versioone unikaalse nimekirjana;
• Docker – Linux server, mille eesmärk on Image faile lõppkasutajale läbi domeeni presenteerida.

 

CI/CD võimekus sõiduauto näitel: vaadeldes CI/CD võimekust sõiduauto näitena eristame sõiduki keret (visuaalne) ning mootorit (funktsionaalne) täiesti eraldiseisvate elementidena. Üldjoontes antud elemendid üksteisest ei sõltu ning funktsioneerivad eraldiseisvalt. Sooviga sõidukil mootorit uuendada, ei tule vahetada välja tervet sõidukit, vaid ainult mootori element. Mootori elementidel on eraldiseisev ladu, mis hoiustab nii vanu kui uusi mootori versioone.

 

 

Kuidas lahendasime väljakutseid: andmete kinnitamine ja mitmes seadmes täitmine? 

Oletame, et sattusid õnnetusse ning teine osapool asub usinalt täitma nii tema kui sinu kohta käivat informatsiooni. Kuidas saad veenduda, et sisestatud informatsioon on korrektne ning arvestab mõlema osapoole huvisid?

 

Naljaga pooleks on üheks variandiks kindlasti kaaslasel järjepidevalt kõrval seista ning näpuga iga kirjutatavat tekstirida taga ajada. Osadele kindlasti selline dünaamika sobib, kuid laiema kasutushaardega rakendus peab võimaldama midagi enamat. 

 

Ülalmainitu baasil on rakenduse tähtsateks väärtusteks 2 funktsionaalsust:

 

1. võimalus igal osapoolel eraldi enda kohta informatsiooni täita. Eesmärgiks on kiirendada kahe või rohkema osapoole info sisestamist ning nägemuse fikseerimist.
2. võimalus kinnitada teise osapoole poolt täidetud infot enda nutiseadmes. Eesmärgiks on luua läbipaistvus, jagades sisestatud informatsiooni kõikide seotud osapooltega.

 

Mitu osalist saavad paralleelselt enda kohta kehtivat infot sisestada juhul kui ühe osalise poolt alustatud juhtumit on võimalik avada teises mobiiltelefonis. Selleks, et võimaldada liiklusõnnetuse infot sisestada mitmes seadmes korraga, on rakendus struktureeritud viisil, mis võimaldab juhtumi alustajal nii QR koodi kui SMSi vahendusel jagada teistele osapooltele spetsiifilisele juhtumile viitavat linki. 

 

Lingile liikudes avatakse kasutajale paralleelne ühendus spetsiifilise juhtumiga, kus täitja käsitleb täidetavate väljadena ainult tema kohta kehtivat informatsiooni. Info täitmisel salvestatakse mõlema osapoole poolt sisestatud andmeid jooksvalt.

 

Vastutuse välja selgitamisel ja kindlustusseltsi poole pöördumisel on olulised ka teise osapoole andmed, mida süsteem uuendab automaatselt. Osalised, kes tunnevad ennast mugavamalt informatsiooni ühes seadmes sisestades, saavad enda kohta täidetud informatsioonile ligipääsu juhtumi esmase kinnitamise järgselt. Ligipääs saabub eelnevalt täidetud kontaktnumbrile linkina SMSi vahendusel.

 

Link võimaldab isiklikke andmeid muuta ja kinnitada. Andmeid muutes eelnevaid sisestusi ei kustutata ning lõpliku kindlustusotsuse tegemisel on kindlustusametnikul ligipääs kõikidele juhtumiga seotud andmetele. 

 

Lisanduva ja Eestile tehniliselt ainulaadse väärtusena saavad mõlemad osapooled valida sobiva kindlustusandja, kes kindlustusjuhtumiga tegelema asub. Seda põhjusel, et kannatanul on kahju hüvitamisel õigus valida nii enda kui vastutaja kindlustusandja vahel. Sõidukitele, millel on kehtiv kaskokindlustus, kuvatakse kindlustuse pakkuja viidet. 

 

 

Mida õppisime?

Irooniliselt soovin sulle kui lugejale, et sul tuleks uue rakenduse ning selle lahendustega võimalikult vähe tutvust teha. Regulaarselt mootorsõidukisse istudes ei soovi meist keegi ju lõpetada sõitu enneaegselt ning asuda täitma kindlustusjuhtumit.

 

Eesti Liikluskindlustusfondi “Liiklusõnnetusest teavitamise süsteemi” analüüs ning arendused nõudsid keskendumist paljudele muutuvatele osadele. Kui eesmärgiks on planeerida planeerimatut ja luua seeläbi väärtust väga laiale sõidukijuhtide sihtrühmale, nõuab see kasutajakeskset lähenemist.

 

Stressirohked olukorrad omakorda nõuavad rakenduselt lihtsaid ja selgesti mõistetavaid elemente. Kasutusmugavus, ühendatavus, lihtsus ning skaleeritavus on olulised nii õnnetuses osalejale kui kindlustusjuhtumiga toimetajale.