17.11.2023 | Blogi Markkinakatsaus Poiminnat Teknologiat

Microsoft Fabric yleisesti saataville – tutustu päivitettyyn hinnoittelumalliin!

Microsoft Ignite toi viimein meille kaikille dataintoilijoille hartaasti odotettuja uutisia, kun Microsoft Fabric julkaistiin yleisesti saataville (GA). Joulu jo marraskuussa, kelpaa! Ignite toi mukanaan paljon mielenkiintoisia julkistuksia Fabricin osalta. Kaiken keskiössä on kuitenkin se, että nyt Fabric on maturiteetiltaan virallisesti julkaistu tuote, jota voidaan tosissaan alkaa hyödyntämään data-alustana. Toki tiedämme, että paljon ominaisuuksia on vielä kehityksen alla Preview-tilassa ja road map on pitkä, mutta tärkeä virstanpylväs vakavasti otettavana datatuotteena on nyt saavutettu.

Nyt kun organisaatiot voivat turvallisin mielin alkaa suunnittella Fabricin käyttöönottoa, on hyvä hetki perata Fabricin hinnoittelua vähän syvällisemmin – aihe, jota olen päässyt esittelemään lukuisia kertoja asiakkaillemme viime kuukausien aikana. Koska suurin osa Fabricia käsittelevästä materiaalista on englanniksi, tehdään poikkeus ja kirjoitetaan tällä kertaa suomeksi.

Hinnoittelun komponentit

Fabric paketoi ennen erillisenä hankitut analytiikkaalustan palaset yhden SaaS-palvelun sisälle, siispä tuotteella on vain yksi hinta – tai näin Microsoftilla sanovat. Tämä pitää siinä mielessä paikkansa, sillä Fabricin sisällä et maksa esimerkiksi Data Factoryn ja Synapse Data Warehousen käytöstä erikseen. Todellisuudessa Fabricin hinnoittelu kuitenkin koostuu itseasiassa kolmesta komponentista:

  1. Fabric-kapasiteetista eli laskentatehosta
  2. OneLake-tallennustilasta
  3. Käyttäjäkohtaisesta Power BI -lisensoinnista

Ennen kuin siirrytään tutkimaan miten kunkin komponentin hinta muodostuu, käydään vielä läpi pari oleellista Fabric-käsitettä, jotta pystymme paremmin keskustelemaan aiheesta.

  • Jotta Microsoft Fabric ympäristö pystytään luomaan, tarvitaan Microsoft Entra Tenant (entinen Azure AD). Yleensä organisaatiolla on käytössä yksi tenant.
  • Työtila (Workspace) on säiliö, johon Fabric-komponentit luodaan. Työtilat ovat tuttuja Power BI:stä jo entuudestaan, ja niiden luomien tapahtuu täysin samalla tavalla – asetuksista valitaan vain lisesointimalliksi Fabric-kapasiteetti. Työtiloja voi olla useita, ja jokainen Fabric-työtila liittyy johonkin Fabric-kapasiteettiin. Usea työtila voi käyttää samaa Fabric-kapasiteettia.

Kaikki tässä kirjoituksessa esitetyt hinnat ovat voimassa julkaisuhetkellä ja voivat muuttua ajan mittaan.

Fabric-kapasiteetti

Fabric-kapasiteettia mitataan kapasiteettiyksiköillä (Capacity Unit, CU) saatavilla olevaa laskentatehoa. Kapasiteettia on saatavilla eri kokoisia ja hintaisia, kuten oheinen taulukko kuvaa. F2-kapasiteetti sisältää 2 kapasiteettiyksikköä ja niin edelleen. Fabric-kapasiteetilla saat käyttöön kaikki Fabricin komponentit (Synapsen komponentit, Data Factoryn, Data Activatorin jne.), lukuun ottamatta Power BI:n käyttäjälisenssejä, joita vaaditaan raporttien julkaisuun ja käyttämiseen Power BI Service -portaalissa. Tarkastellaan Power BI -lisenssien osuutta hieman myöhemmin, mutta todettakoon että Fabric-kapasiteetin suuruus vaikuttaa tähän käyttäjäkohtaiseen lisensointitarpeeseen.

Kuva 1: Fabric-kapasiteetin hinnoittelu Pohjois- ja Länsi-Euroopan Azure-alueilla

Fabric-kapasiteetti provisioidaan Azure-portaalista. Tämä on hyvin yksinkertainen prosessi, ja jo muutamassa minuutissa Fabric-kapasiteetti on käytössäsi. Kapasiteetin hinnoitteluun on käytettävissä kaksi mallia: sekuntipohjainen Pay-as-you-go -hinnoittelu, sekä juuri julkaistu vuosikohtainen Reservation-hinnoittelu. Pay-as-you-go -hinnoittelussa minimissään laskutetaan yksi minuutti, ja tämän jälkeen laskutus jatkuu sekuntipohjaisesti kapasiteetin ollessa päällä, riippumatta siitä onko palvelussa työkuormaa vai ei. Taulukossa esitetty hinta muodostuu Fabric-kapasiteetin ollessa päällä 24/7 kuukauden ajan. Pay-as-you-go -hinnoittelulla kustannuksia on kuitenkin mahdollista optimoida sulkemalla kapasiteetti silloin, kun sille ei ole tarvetta, tai skaalata sitä tarpeen mukaan. Tämä prosessi voidaan automatisoida.

On kuitenkin syytä muistaa, että kapasiteetin ollessa pois päältä mitkään Fabricin palvelut eivät ole käytettävissä. Tämä on ehkä merkittävintä Power BI -raporteille, mikäli ne on julkaistu Fabric-kapasiteettia hyödyntävään työtilaan, ja mikäli ne käyttävät DirectLake-yhteyttä – jos kapasiteetti on pois päältä, eivät raportitkaan toimi tällöin. Tätä pystytään kiertämään julkaisemalla Power BI -raportit omaan työtilaansa, joka hyödyntää esimerkiksi Power BI Pro -lisenssin tarjoamaa kapsiteettia. Tällöin raportti on import-tilassa, ja sitä koskevat pro-lisenssin rajoitteet esimerkiksi tietomallin koon osalta.

Vuodeksi kerrallaan sitouduttavaan Reservation-hinnoittelun tuntihinta on noin 40 prosenttia edullisempi verrattuna Pay-as-you-go:hon. Tällöin laskua ei kuitenkaan pysty samalla tavalla optimoimaan sulkemalla tai skaalaamalla kapasiteettia tarpeen mukaan. Sopivaa hinnoittelumallia valitessa käyttötarve tuleekin analysoida tarkasti: mikäli Fabricin palveluiden tulee olla saavutettavissa 24//7, on Reservation hinnoittelu parempi valinta. Toisaalta jos tarve Fabric-palveluille on vain tiettyinä kellonaikoina tai satunnaisesti, voidaan edullisempaan hintaan päästä Pay-as-you-go -mallilla. Mikään ei myöskään estä esimerkiksi pitämästä yhtä Reservation-hinnoittelun piirissä olevaa kapasiteettia pohjalla, ja luomaan rinnalle Pay-as-you-go -kapasiteettia adhoc-tarpeita varten. Ylipäätään organisaatiolla voi olla olemassa useita kapasiteetteja rinnakkain tarpeen mukaan, jolloin eri työtiloille voidaan kohdistaa sen tarvetta vastaava kapasiteetti.

Kapasiteetin tason lisäksi hintaan vaikuttaa Azure-alue, josta Fabric-provisioidaan. Fabric ei ole saatavilla tällä hetkellä kaikilla alueilla. Suomen kannalta relevanteimmat EU-sijainnit ovat todennäköisesti Länsi- (Alankomaat) ja Pohjois-Eurooppa (Irlanti) sekä Keski-Ruotsi. Oheinen taulukko kuvaa Länsi- ja Pohjois-Euroopan alueiden Microsoft Fabric-hintoja blogin kirjoitushetkellä. Taulukosta huomaa, että varsinkin suuremmissa kapasiteeteissa hintaero näiden kahden alueen välillä alkaa jo olla huomattava, eli alueen valintaan kannattaa kiinnittää huomiota. Keski-Ruotsin hinnoittelu oli identtinen Pohjois-Euroopan kanssa. Hintaa puntaroidessa on toki hyvä ottaa huomioon myös pidemmän etäisyyden aiheuttama latenssiero sekä organisaation datahallintasäännöt.

Mikäli organisaatiolla on olemassa tällä hetkellä Power BI Premiumin P-luokan kapasiteetti, rinnastuvat ne Fabric F64:ään ja sitä suurempiin kapasiteetteihin. Sallimalla Microsoft Fabricin käytön Admin-portaalista pystytään samalla kapasiteetilla luomaan myös Fabric-objekteja. Power BI Premium -kapasiteetin admin pystyy esimerkiksi Power BI -sovelluksen avulla tarkastamaan CPU:n käyttöasteen – mikäli koko kapasiteettia ei hyödynnetä, pystytään Fabric-kuormaa lisäämään ilman haittaa olemassa olevalle Power BI -käytölle.

Microsoft hyödyntää Power BI:stä tuttuja tasoitus- (smoothing) ja rajoitus- (throttling) -operaatioita myös Fabric-kapasiteetille. Tasoituksella mahdollistetaan hetkellisesti pääsy suuremman kapasiteetin piiriin, jotta operaatiot suoriutuvat nopeasti. Tällöin kapasiteettia käytetään tulevaisuuden kapasiteettisaldosta. Näitä käyttöpiikkejä tasataan hetkillä, jolloin kapasiteetti ei ole aktiivisesti käytössä. Näin tarvittava kapasiteetti voidaan siis valita keskimääräisen tarpeen pohjalta, ei maksimipiikkien mukaan. Rajoituksella tarkoitetaan tilannetta, jossa tulevaisuuden kapasiteettia on käytetty liikaa, ja Fabric alkaa rajoittaa operaatioiden suoritusta, mikä vaikuttaa käyttökokemukseen. En tässä artikkelissa mene yksityiskohtiin eri rajoitusmetodeista, mutta samoin kuten aiemmin Power BI:ssä, erilaiset operaatiot jaetaan interaktiiviseen (esim. raporttien käyttö) ja taustakuormaan (esim. tietovarastolataukset). Taustakuormien tasausperiodi on vuorokausi (24h), interaktiiviset kuormat tasataan minimissään viiden minuutin tasolla. Fabric-kapasiteetin käyttöä voidaan monitoroida aiemmin mainitun Power BI -sovelluksen avulla. Tasoitus- ja rajoitus-operaatiot ovat kapasiteettikohtaisia toimenpiteitä.

OneLake-tallennustila

OneLake on Fabricin tallennustila, josta kaikki eri Fabric-komponentit voivat lukea ja tallentaa datan. Oheisessa taulukossa OneLake muistin hinnat Pohjois- ja Länsi-Euroopan Azure-alueella. Yleiskäyttöisen OneLake-tallennustilan hinta on hyvin kohtuullinen, noin 22€/TB/kk. Tätä tallennustilaa käytetään suurimmalle osalle OneLake-datastasi. Kun uusi työtila luodaan, generoituu sille oma OneLake-kansio, johon tiedot tallennetaan. Muut työtilat voivat oikopolkujen (shortcut) avulla kysellä toisten työtilojen dataa. Kun työtila poistetaan, katoaa myös OneLake-kansio. Taustalla tiedot kuitenkin ovat tallessa asetetun säilytysajan (7-90 päivää), jonka ajan kyseisestä OneLake-säilytystilasta vielä maksetaan. OneLake-tallennustila on käytettävissä, vaikka Fabric-kapasiteetti olisikin suljettuna.

Kuva 2: OneLake-tallennustilan hinnoittelu Pohjois- ja Länsi-Euroopan Azure-alueilla

Yleiskäyttöisen OneLake-tallennustilan lisäksi on määritetty OneLake-, Cache- ja Business Continuity & Disaster Recovery (BCDR) -tallennustilan hinnoittelu. Cache-hinnoittelua käytetään reaaliaikaisen analytiikan KQL-tietokannan sekä monitorointiin hyödynnettävän Data Activatorin välimuistiin. Välimuistista data on saatavilla hyvin nopeasti, mutta hinta on myös kymmenen kertaa kalliimpi verrattuna normaaliin tallennustilan hintaan. Välimuistiin tallennettavat tiedot ja säilytysaika onkin siis syytä suunnitella tarkasti.

Uusin lisäys Fabricin tallennustilatarjoomaan on BCDR-tallennustila luomaan turvaa datalle katastrofien sattuessa. Fabricin BCDR-kyvykkyydet yleisesti eivät kata vielä kaikkia Fabricin komponentteja, mutta BCDR-tallennustilan avulla OneLakessa oleva data turvataan toiselle Azure-alueelle. BCDR-muistin hinta on korkeampi kuin normaalin tallennustilan hinta ja tämä pitää erikseen ottaa käyttöön Fabric kapasiteetin admin-portaalista.  Power BI on automaattisesti BCDR:n piirissä, kuten tähänkin asti.

Power BI -käyttäjälisenssit

Fabric ei ole muuttanut oikeastaan mitään suhteessa Power BI -käyttäjälisenssien tarpeeseen verrattuna aiempaan. Raporttien tekeminen Power BI Desktopilla on edelleen ilmaista, myös silloin kun hyödynnetään Fabricin dataa. Kun puolestaan Power BI -raportti halutaan julkaista ja jakaa Power BI Service -portaalissa myös muille organisaation jäsenille, tarvitaan maksullinen Power BI -käyttäjälisenssi – käytännössä tämä tarkoittaa yleensä Power BI Pro -lisenssiä, joka maksaa 9,4€/käyttäjä/kk. F64:ää pienemmillä Fabric-kapasiteeteilla niin raporttien käyttäjät kuin kehittäjätkin tarvitsevat nämä käyttäjälisenssit, samoin kuin aikaisemminkin, mikäli organisaatiolla ei ole käytössään Power BI Premium -kapasiteettia. Kuten aiemmin mainittiin, F64:stä alkaen Fabric-kapasiteetit rinnastuvat Power BI Premiumin P-luokan kapasiteetteihin, ja samat käytänteet käyttäjälisenssien osalta jatkuvat, sillä ainoastaan kehittäjät, jotka julkaisevat raportteja, tarvitsevat käyttäjälisenssit näillä suuremmilla Fabric-kapasiteeteilla.

Yhteenveto

Fabric-hinnoittelu on saanut lisää sävyjä tuotteen maturiteetin kasvaessa, ja alun punch line ”yksi hinta” voi tuntua nyt hieman liioittellulta. Silti on huomattava, että hinnoittelu on suhteellisen yksinkertainen verrattuna erikseen provisioitaviin palveluihin, joiden kapasiteettitarve tulee arvioida yksitellen. Edellä mainittujen varsinaisten Fabric-kustannusten lisäksi saattaa muodostua toki joitain muita kustannuksia tapauksesta riippuen. Tietoliikennekustannusten laskutusperiaatteen osalta minkään ei pitäisi olla oleellisesti muuttunut verrattuna aiempaan, Microsoft on kuitenkin julkaisemassa Fabriciin liittyvän verkkoliikenteen hinnoittelun tulevaisuudessa. Käyttötapauksesta riippuen saatetaan joutua käyttämään Fabricin ulkopuolisia palveluita, jotka maksavat erikseen. Data Governanceen hyödynnettävä Microsoft Purview integroituu Fabriciin tiiviisti, mutta se hinnoitellaan erikseen.

Hinnoittelusta puhuttaessa tietenkin olennaiseksi nousee kysymys: paljonko kapasiteettia tarvitaan? Tämän aiheen käsittelyyn tarvittaisiin kokonaan oma kirjoitus, ja suoraa, kaikille sopivaa vastausta tähän ei edes ole mahdollista antaa. Tarvittavaan kapasiteettiin kun huomattavasti vaikuttavat erilaiset käyttötapaukset, sisältäen datan ja lähteiden määrän, raporttien ja niiden käyttäjien lukumäärän, ja niin edelleen. Hyvä nyrkkisääntö on kuitenkin aloittaa provisioimalla pienin F2-kapasiteetti, alkaa rakentaa Fabric-ympäristöä tätä hyödyntäen, ja aktiivisesti seurata Fabric Capacity Metric Appia kapasiteetin riittävyyden arvioimiseksi.

Me Evitecillä olemme päässeet auttamaan jo muutamia asiakkaitamme matkalla Fabric-edelläkävijöiksi, ja mielellään autamme teitäkin alkuun pääsemisessä!

Kirjoittaja

Henni Niiranen

Data Consultant

Järjestelmäuudistuksen yhteydessä kuumia puheenaiheita ovat muun muassa digitalisaatio, automaatio, konversio ja migraatio. Eikä edellä mainituissa ole mitään väärää, tärkeitä tekijöitä, joilla varmistetaan, että uusi järjestelmä toimii halutulla tavalla ja tuottaa toivottua hyötyä. Mutta tuoko järjestelmäuudistus käyttäjille muutakin kuin uuden käyttöliittymän?

 

annika-edit-3-1440x1920-6572602
Annika Karppinen, PLP Product Manager

”Meillä on aina tehty näin”

Olemme varmaan kaikki joskus törmänneet sanontaan ”kun meillä on aina tehty näin”. Tähän törmää usein myös järjestelmäuudistuksen yhteydessä. Automaatiotason noustessa rutiininomaisten manuaalisten tehtävien määrä vähenee. Myös uuden järjestelmän toimintalogiikka saattaa poiketa aiemmasta. Näistä johtuen myös työprosesseja voidaan joutua muokkaamaan, minkä johdosta järjestelmäuudistus tulee nähdä kokonaisvaltaisempana muutosprosessina, ei pelkästään teknologian päivityksenä. Käyttäjille tämä tarkoittaa uuden käyttöliittymän lisäksi uusia työtapoja ja rutiineja.

Tekninen ja henkinen transformaatio

Projektissa mukana olevat tutustuvat yleensä vaiheittain tulevaan järjestelmään. Osatoimitusten demot ja erityisesti testausvaihe ovatkin hyviä ajankohtia keskustella uuden järjestelmän toiminnallisuuksista ja kuunnella järjestelmätoimittajan näkökulmia erilaisista ratkaisuista. Samalla on luontevaa alkaa arvioida nykyisiä työprosesseja ja tarvittaessa muokata näitä.

Myös luottamus uuteen järjestelmään ja uusien toimintatapojen järkiperäisyyteen rakentuu projektin aikana. Projektissa työskentelevät tulevat jo projektin aikana sinuiksi muutosten kanssa ja käyvät läpi henkistä siirtymää vanhasta totutusta uuteen aikakauteen.

Kun käyttöönoton ajankohta lähestyy ja organisaation muut käyttäjät otetaan mukaan, ei heillä ole samaa aikaikkunaa tutustua kaikkeen uuteen. Heille ensikosketus uuteen järjestelmään ja työskentelytapaan on usein pilotointivaihe, mutta sen ollessa huomattavasti projektia lyhyempi, pitää heidän omaksua kaikki uusi varsin nopeasti. Tällöin projektiryhmäläiset ovat tärkeässä roolissa uuden aikakauden lähettiläinä: he voivat tukea ja perustella uusia toimintamalleja ja auttaa nopeammin omaksumaan nämä. Muilla organisaation käyttäjillä on varmasti samoja kysymyksiä kuin projektiryhmäläisillä itsellään oli, joten kukapa olisi parempi niitä käsittelemään kuin ne, jotka ovat jo läpikäyneet tämän vaiheen.

Muokkautuva standardijärjestelmä

Mikäli jokin osaratkaisu ei tunnu istuvan vakuutusyhtiön toimintamalliin, ovat asiakaskohtaiset muokkaukset hyvä ratkaisu asiaan. Profit Life & Pension (PLP) on henkivakuutusyhtiön tarpeisiin kehitetty standardijärjestelmä eläke-, säästö- ja riskivakuutussopimusten hoitoon ja korvausten käsittelyyn. Järjestelmän parametrisoitu tuoterakenne mahdollistaa joustavan tuotekonfiguraation. Tämän lisäksi järjestelmän toiminnallisuuksia voidaan muokata asiakkaan tarpeiden mukaan. Siten jokainen toimitus onkin yksilöllinen, vaikka perusta on pitkälti sama. Toimimme asiakkaan kumppanina ja järjestelmäuudistusprojektit suunnitellaan, toteutetaan ja testataan tiiviissä yhteistyössä.  Näin pystymme tarjoamaan toimivan järjestelmäratkaisun, joka huomioi asiakkaan yksilölliset tuotteet, tarpeet ja toimintatavat.


Kiinnostuitko? Ota yhteyttä sales@evitecdata.local

annika-edit-1-1440x1920-1787171
Annika Karppinen, PLP Product Manager

Payment Services Directive 2 (PSD2) -direktiivin siivittämänä Open Banking avasi joitakin vuosi sitten ovet aivan uuteen maksamisen maailmaan. Nyt kaupan kassalla riittää, kun vilauttaa älykelloa ja verkko-ostokset voi maksaa parilla klikkauksella. Open Banking toi pankkien rinnalle uusia toimijoita, jotka keskittyivät pelkästään maksupalveluihin. Innon iskeä tähän saumaan ymmärtää, kun ottaa huomioon, että esimerkiksi vuonna 2021 suomalaisilla maksukorteilla maksettiin 1,9 miljardia kertaa. Jo pienikin siivu tämän maksuliikenteen välittämisestä antaa kohtuullisen liikevaihdon.

PSD2 oli finanssialalla alkusoitto entistä avoimempaan tiedon jakamiseen. Nyt aihe puhuttaa myös vakuutusalalla ja “Open Insurance” hakee muotoaan. Mutta mitä Open Insurance tarkoittaa ja mitä sillä tavoitellaan? Yhdenmukaista määrittelyä ei vielä ole. European Insurance and Occupational Pension Authority (EIOPA) julkaisi vuonna 2021 konsultaatiodokumentin Open Insurance: Accessing and sharing insurance related data, jossa on lähdetty erittäin laveasta määrittelystä: “Kaiken vakuutuksiin liittyvän henkilö- ja muun tiedon käyttö ja jakaminen rajapintojen kautta”. Tavoitteiksi konsultaatiossa on määritelty innovaation, kilpailuedun ja tehokkuuden lisääntyminen.

Mitä vakuutustietojen jakaminen mahdollistaa?

Kun ottaa huomioon vakuutuksiin sisältyvän tiedon määrän ja kuinka tietoa tänä päivänä ylipäätään voi hyödyntää eri käyttötarkoituksiin, on selvää, että vakuutustietojen avoin jakaminen mahdollistaa monenlaisen tuote- ja palveluinnovaation. On kuitenkin syytä heti huomata, etteivät yhtiöt voi vapaasti jakaa tietoa, vaan lähtökohtaisesti, kuten PSD2:ssakin, vakuutettu hallitsee tietojaan ja päättää mitä ja milloin haluaa tietoa jaettavaksi. Tämä nostaa asiakashyödyn innovaation keskiöön ja luo lähtökohdan uusille kilpailutekijöille.

Mikäli asiakkaalla on vakuutuksia useammassa yhtiössä, mahdollistaa tietojen avoin jakaminen pirstaloituneen tiedon keräämisen yhteen. Asiakkaalle avautuu näkymä vakuutusturvaansa kokonaisuutena ja hänelle voi tarjota parempaa vakuutusneuvontaa sekä vakuutusten helpompaa kilpailuttamista. Suomessa erityisesti työeläkkeen ja muun eläkesäästämisen tietojen yhdistäminen voisi olla hyödyllinen käyttötapaus.

Korvauskäsittely puolestaan on asiakassuhteen kannalta kriittinen vaihe ja sen sujuvoittamiseen löytyy varmasti monia käyttötapauksia. Esimerkiksi, jos lentoni myöhästyy yli 4 tuntia, mikä oikeuttaa korvaukseen matkavakuutuksestani? Voisiko lentoyhtiöstä mennä suoraan vakuutusyhtiölle tieto myöhästymisestä ja korvaus maksettaisiin automaattisesti tililleni?

Rajapinnat avainroolissa

Rajapinnat ovat perusedellytys tiedon jakamiselle ja vastaanottamiselle, mutta saattavat osoittautua myös kehityksen hidasteiksi. Tästäkin on jo PSD2:n osalta kokemusta, sillä rajapintojen erilaiset standardit ovat vaikeuttaneet sujuvan ekosysteemin kehittämistä. Toivottavasti tästä kokemuksesta voidaan ottaa oppia Open Insurance -direktiivin muotoutuessa.

Myös vakuutusyhtiöiden vanhenevan järjestelmäkannan liittäminen rajapintoihin asettaa omat haasteensa. Kun rajapinnat ovat digitalisaatiossa aivan keskeisessä roolissa ja vaikuttavat moneen asiaan jo nyt, pohditaankin yhä useammassa vakuutusyhtiössä, mikä on paras ratkaisu pidemmällä tähtäimellä. Jatketaanko vanhenevan teknologia päälle rakentamista, vai onko tullut aika uusia järjestelmät ja nostaa digitalisaation hyödyntäminen aivan uudelle tasolle?

Tiedon jakamisen tulevaisuus

Tuleeko Open Insurance aiheuttamaan PSD2:n ja mobiilimaksamisen kaltaisen vallankumouksen vakuutusalalla? Ehkä ei, jo siksikin, että vakuuttamisessa ei ole tapahtumaa, jossa tapahtumatiheys on lähimainkaan vastaavanlainen kuin maksuliikenteessä. Lisäksi vaatimus jakaa tietoa avoimesti tuntuu EU:ssa etenevän varsin verkkaisesti.

Open Insuranceen liittyy vielä monia kysymysmerkkejä ja haasteita ratkottavaksi. Jollain aikavälillä tämä direktiivi on silti odotettavissa. Siksi onkin hyvä jo pohdiskella, kuinka ja minkälaisilla ratkaisuilla parhaiten hyödyntää Open Insurancen mahdollisuuksia.

annika-2021-1-crop-1-1860960
Annika Karppinen, PLP Product Manager

Kestävä rahoitus on aihe, jonka merkitys ilmastonmuutoksen kiihtymisen myötä on entisestään lisääntynyt. Kestävän rahoituksen määritelmä on toki laajempikin, ympäristötekijöiden lisäksi siinä tarkastellaan myös yhteiskuntaan ja hallintotapaan liittyviä näkökulmia, eli ns. ESG-tekijöitä (lyhenne sanoista Environmental, Social ja Governance) ja kuinka nämä huomioidaan sijoittamista koskevassa päätöksenteossa.

Vaikuttamisen mahdollisuus on kenellä tahansa sijoitustoimintaa harrastavalla, yhtä lailla institutionaalisella sijoittajalla kuin yksittäisellä rahastosäästäjälläkin. Mutta voidakseen tehdä vastuullisia valintoja, tarvitsee sijoittaja luotettavaa tietoa sijoituskohteiden kestävyydestä. Kohteiden tulisi myös olla keskenään vertailukelpoisia, jolloin tarvitaan yhteneväisiä mittareita ja käytäntöjä. EU:ssa tähän on haettu ratkaisua kahden eri asetuksen kautta. Tiedonantovelvoiteasetuksen (SFDR, Sustainable Finance Disclosure Regulation) tavoitteena on lisätä läpinäkyvyyttä sijoitustuotteiden kestävyystekijöistä. Taksonomia-asetus (TR, Taxonomy Regulation) puolestaan määrittelee milloin taloudellista toimintaa voi kutsua kestäviksi kuuden ympäristökestävyyttä mittaavan tavoitteen kautta.

Asetukset ovat sinällään jo tulleet voimaan, mutta niissä säädettyjen velvoitteiden soveltaminen jalkautuu asteittain. Molemmissa asetuksissa on artikloja, joiden yhteneväiseen tulkintaan ja soveltamiseen Euroopan komissio on pyytänyt finanssialan Euroopan valvontaviranomaisia (ESA, European Supervisory Authorities) määrittelemään tekniset standardit (RTS, Regulatory Technical Standards). Nämä eivät ole vielä kaikilta osin valmiita tai lopullisesti hyväksyttyjä, mutta oletuksena on, että niitä tulisi porrastetusti alkaa noudattaa tämän ja ensi vuoden aikana.

Finanssiala on yhteisen haasteen edessä

Asioiden keskeneräisyydestä huolimatta, valvontaviranomaiset ovat nyt kehottaneet toimijoita aloittamaan valmistelut asetusten soveltamiseen. Ja hyvä niin, sillä urakka on huomattavan suuri, vaikka toimijoille tilanne on hieman epäkiitollinen, kun ne joutuvat tähtäämään liikkuvaan kohteeseen. Niinpä kaikki sijoituspalveluja tuottavat ja tarjoavat tahot, kuten rahastoyhtiöt, pankit ja henkivakuutusyhtiöt ovat kovan urakan edessä.
Mutta mikä tekee tämän niin haastavaksi?

Pähkinänkuoressa: valtava tietomäärä kerättäväksi ja analysoitavaksi sekä pitkä välitysketju, jonka varrella on useita toimijoita.

Teknisestä näkökulmasta urakka kiteytyy tiedon sujuvaan välittämiseen ja tehokkaaseen käsittelyyn:

    • kuinka sijoituspalvelun tuottaja kerää ja analysoi sijoituskohteiden kestävyyteen liittyvää tietoa ja muokkaa tiedon sopivaan muotoon seuraavan vaiheen tarpeet huomioiden
    • kuinka sijoituspalvelun tuottaja välittää tämän tiedon sijoituspalvelua tarjoavalle taholle, tiedon kaikissa eri muodoissa, raportteina, avaintietoesitteinä ja SFDR:n määrittelyn mukaisen, sijoituskohteen kestävyyttä indikoivana värikoodina
    • kuinka sijoituspalveluntarjoaja välittää tiedon loppuasiakkaalle eri ajankohtina ja eri palvelukanavissa kuten verkkosivuilla, portaaleissa ja ehkäpä jopa tulosteina.

Pitkä ja monivaiheinen ketju, mutta modernien järjestelmien tuella ja tiedonvälityksen rajapintoja hyödyntämällä hyvinkin tehtävissä. Finanssiala on uuden edessä ja yhteisellä ponnistuksella rakennamme edellytykset kestävälle rahoitukselle.

 

annika-2021-1-crop-1-1860960
Annika Karppinen, PLP Product Manager

Digitalisaatio on jo monen vuoden ajan ollut kestopuheenaihe vakuutusalalla. Koronaviruksen tuoma paine pystyä palvelemaan asiakkaita etäyhteyksin kiihdytti keskustelua entisestään. Yhtiöt ovatkin viimeistään koronan myötä kehittäneet asiakasrajapinnassa tapahtuvaa palvelua digiaikaan. Mutta mikä on yhtiöiden sisäisten toimintojen tilanne?

Kun asiakas täyttää esimerkiksi henkilöriskivakuutuksen korvaushakemuksen verkkopalvelussa, alustaako tämä automaattisesti korvaustapahtuman ja ehkäpä tekee myös korvauspäätöksen ja hoitaa korvauksen ulosmaksatuksen? Vai syntyikö tästä pdf -lomake, joka otetaan manuaaliseen käsittelyyn?  

Monella yhtiöllä sisäisten toimintojen kyvykkyys törmää sopimushallinnan ja korvauskäsittelyn ydinjärjestelmien yli-ikäisyyteen. Pahimmillaan niiden yhdistäminen digitaaliseen ympäristöön ei onnistu ylipäätään tai ainakin toimenpiteen kustannukset ylittävät pitkän aikavälin hyödyt. Sen sijaan uusimalla liiketoiminnan ydinjärjestelmä saataisiin pitkälle tulevaisuuteen kantava ratkaisu, joka kytkeytyy jouhevasti muuhun liiketoimintaympäristöön. 

Kaiken kattava järjestelmä 

Profit Life & Pension (PLP) on varsinkin suomalaisille henkivakuutusyhtiöille tuttu vakuutussopimusten hallintajärjestelmä. Järjestelmä kehitettiin alkujaan erityyppisten eläke-, säästö- ja sijoitusvakuutusten hoitojärjestelmäksi, josta onkin kertynyt paljon kokemusta. Luonnollinen jatkumo kehityspolulle on ollut tuoda riskihenkivakuutustuotteet säästötuotteiden rinnalle.  

PLP:ssä voikin nyt hallinnoida kaikkia henkivakuutusyhtiön henkilöriskiturvia sekä näiden erilaisia yhdistelmiä. Yhtenä esimerkkinä yhdistelmistä mainittakoon Lainaturvavakuutukset, joissa omana erityispiirteenä on vakuutusmäärän sitominen lainapääomaan. PLP:ssä on jo entuudestaan voinut käsitellä sekä yksilöllisiä- että ryhmäsopimuksia ja henkilöriskivakuutusten osalta lisäksi pariturvia.  

Kun vielä henkilöriskivakuutusten korvauskäsittely on tuotu sopimushallinnan kanssa samaan järjestelmään, voimme ylpeänä tarjota henkivakuutusyhtiölle kaiken kattavan järjestelmän. Erityyppisten korvausten, kerta- ja päivärahakorvausten sekä kulukorvausten, hoitoa sujuvoittaa käsittelyssä tarvittavien sopimustietojen automaattinen välittyminen korvausjärjestelmään. Mikäli korvauspäätöksellä on vaikutusta sopimuksen tietoihin, esimerkiksi jokin turvalaji päättyy, päivittyy tieto automaattisesti sopimushallinnan puolelle.

Sopimusten ja korvausten hoitaminen samassa modernissa järjestelmässä tuo useita merkittäviä kustannus- ja tehokkuushyötyjä, kun liiketoimintaprosesseja automatisoidaan ja järjestelmäarkkitehtuuri yksinkertaistuu. Tällä luodaan pitkälle tulevaisuuteen kantava, koko liiketoimintaprosessin läpäisevä uudistus.

Olisiko nyt aika päivittää järjestelmäkanta nykyaikaan ja alkaa hyödyntää modernin teknologian suomia mahdollisuuksia?


Lue lisää Profit Life & Pension -järjestelmästämme

annika-2021-1-crop-1-1860960
Annika Karppinen, PLP Product Manager

Eläkkeet tuntuvat olevan kuuma peruna EU:ssa.  

Insurance European julkaisi viime syksynä European Retirement Week -tapahtuman yhteydessä eläketutkimuksen, jossa selvitettiin, missä määrin EU-maissa omaehtoisesti varaudutaan eläkevuosien toimeentuloon. Kyselyyn vastanneiden 16 maan vertailusta käy ilmi, että suomalaisista vain 40 % säästää eläkettä varten. Vastanneiden keskiarvo oli 62 %, eli Suomi jäi melko kauas keskiarvosta. Toki suomalainen työeläkejärjestelmä on monessa tutkimuksessa sijoittunut yhdeksi maailman parhaista, mutta onko sen antama peruseläke kuitenkaan riittävä tulevaisuuden eläkeläisille? Kysymys, jota kenen tahansa olisi hyvä ajoittain pohtia.  

Samaa on pohdittu EU:ssa laajemminkin. EU:ssa on useita hankkeita, joilla pyritään kannustamaan kansalaisia omaehtoiseen eläkesäästämiseen. PEPP (Pan-European Personal Pension) -tuotteella pyritään madaltamaan eläkesäästämisen kynnystä, minkä lisäksi EIOPA (European Insurance and Occupational Pension Association) kommentoi viime vuoden lopulla Euroopan Komissiolta saamaansa ehdotusta, kuinka EU-kansalaisten tietämystä omasta tulevasta eläkkeestään voitaisiin lisätä.  

Ehdotettu Pension Tracking System (PTS) yhdistäisi henkilön koko eläkesäästäminen; sekä lakisääteisen että vapaaehtoisen lisäeläkkeen. Tämä avaisi kansalaisille realistisen ja ajantasaisen näkymän eläkevuosiensa tulotasoon. Itse asiassa seitsemällä EU-maalla, mukaan lukien Ruotsi ja Tanska, on jo vastaava järjestelmä. Suomalaista työeläkeotetta voi pitää hyvänä alkuna, mutta koska siihen koostetaan pelkästään lakisääteinen eläkekarttuma, tulisi se ehdotuksen valossa laajentaa kattamaan myös vapaaehtoinen eläkesäästäminen. Vaikka useat eläkesäästämisen lakimuutokset ovat käytännössä näivettäneet suomalaisen eläkevakuutusten uusmyynnin, on suomalaisilla kuitenkin vanhastaan voimassa kohtuullinen määrä vapaaehtoisia sopimuksia. Monelle säästäjälle olisikin varmasti tervetullutta pystyä seuraamaan kokonaistilannettaan.  

PTS:ssä painotetaan selkeyttä, esitettävä tieto tiivistetään kaikkein oleellisimpaan. Ei mitään monimutkaista, vaan perustietoja, jotka löytyvät eläkevakuutusten hoitojärjestelmistä. Modernista hoitojärjestelmästä tiedon välittäminen hoituukin vaivattomasti. Profit Softwaren PLP (Profit Life & Pension) -järjestelmässä on jo entuudestaan lukuisia digitaalisia palvelurajapintoja eri ulkoisten toimijoiden järjestelmiin, joten yhden uuden lisääminen olisi helppo tehtävä.  

Mutta kuka Suomessa ottaisi vetovastuun PTS:n kehittämisestä? Työeläkelaitokset ja Eläketurvakeskus (ETK) ylläpitävät nykyistä työeläkeotetta, mutta vapaaehtoisia lisäeläkkeitä myyvät henkivakuutusyhtiöt. Ruotsissa julkinen ja yksityinen puoli ovat aikanaan lyöttäytyneet yhteen kehittääkseen Minpension:in, voisiko Suomestakin löytyä vastaavanlaista halua edistää yhteistä asiaa?

copy-of-linkedin-himmeli-blogi-1-2427903

 

Ensimmäinen suomalaisen vakuutusyhtiön myöntämä henkivakuutus tehtiin joulukuussa 1874. Kyseinen sopimus ei tietenkään enää ole voimassa, vaikka usean kymmenen vuosien pituiset voimassaoloajat ovatkin henkivakuutussopimuksille ominaisia. 

Tällaiset pitkät sopimusajat tuovat alati muuttuvassa maailmassa omat erityishaasteensa. Kun katsomme vaikka 30 vuotta ajassa taaksepäin, 90-luvun alkupuolelta tähän päivään, on henkivakuutusyhtiöiden toimintaympäristössä tapahtunut lukemattomia muutoksia. Lainsäädännön muutokset ovat ohjanneet mm. tuotekehitystä, myyntiä ja vakuutusten hoitoprosesseja. Samalla suomalaisten mielenkiinto säästämistä kohtaan on kasvanut, minkä siivittämänä on kehitelty eri variaatioita säästöhenkivakuutuksista palvelemaan vaihtelevia asiakastarpeita. Asiakkaat odottavat myös yhä enenevissä määrin digitaalisia palveluja. Ei enää riitä, että portaalissa voi katsella tietoja, sillä monet ovat jo tottuneet itsenäisesti hoitamaan asioitaan portaaleissa.  

Erityisesti eläkevakuutuksiin liittyviä muutoksia on tippunut tiuhaan tahtiin. Verotusta ja eläkkeen noston aloitusikää on muutettu moneen kertaan, mistä johtuen vakuutusyhtiön tulee pystyä ylläpitämään useita toisistaan poikkeavia kantoja tai tuotevariaatioita, vaikka kyseisiä tuotteita ei enää myydä. Koska sopimukset saattavat jatkua useita kymmeniä vuosia, ei tämä tarve poistu kovinkaan pian. 

Tänä päivänä monet henkivakuutusyhtiöt ovatkin tilanteessa, jossa tuotekirjon lisäksi myös järjestelmäkirjo on kasvanut vaikeasti hallittavaksi himmeliksi. Järjestelmien ylläpitokustannukset ovat kasvaneet eikä muutosten toteuttamiseen ole aina helppo löytää tarvittavaa teknistä osaamista. Kun samalla asiakaspalvelu digitalisoituu ja prosesseja haluttaisiin automatisoida, mikä voisi tuoda tervetulleita kustannussäästöjä, ei vanhoja järjestelmiä välttämättä voida järkevästi yhdistää modernimpaan teknologiaan. 

Profit Life & Pension hoitaa monimutkaisetkin tuoterakenteet 

Profit Software on kehittänyt järjestelmiä henkivakuutusyhtiöille jo 90-luvun puolesta välistä asti. Voikin sanoa, että olemme vahvasti eläneet mukana alan kehityksessä ja muutoksissa. Profit Life & Pension (PLP) -järjestelmä kehitettiin aluksi käsittelemään säästöhenkivakuutustuotteita. PLP on ollut jo pitkään ja usean asiakkaan käytössä, joten säästöhenkivakuutussopimusten hoitojärjestelmänä PLP on kannuksensa ansainnut. Siinä hoidetaan sujuvasti niin yksilölliset kuin ryhmien sopimukset sekä näihin liittyvät ulosmaksatukset. Myös vanhojen vakuutuskantojen konvertointi on tullut tutuksi ja prosessia helpottamaan on kehitetty oma työkalunsa. Näin PLP:ssä voidaan yhdessä järjestelmässä hoitaa sekä run-off -kantoja että myynnissä olevia tuotteita. Tuoterakenteiden parametrisointi puolestaan mahdollistaa nopean ja joustavan uusien tuotteiden lanseerauksen. 

Voidaksemme auttaa henkivakuutusyhtiötä hoitojärjestelmien kokonaisuudistuksessa olemme laajentaneet PLP:n sopimushallinnan kattamaan myös henkilöriskivakuutustuotteet. Henkilöriskivakuuttaminen perustuu hyvin joustaviin turvamäärittelyihin, sisältäen sekä yksilölliset, pari- ja ryhmärakenteet. Henkilöriskikorvausten osalta järjestelmässä pystyy käsittelemään kerta-, päiväraha- ja kulukorvauksia.  

PLP:ssä on useamman vuoden ajan lisätty automaation astetta ja REST-palveluiden määrää. Digitaalisten palvelujen kehittämisen kannalta REST-palvelut ovat avainasemassa. Näiden avulla tehostetaan oleellisesti myös sisäisiä prosesseja. Kun esimerkiksi korvauskäsittelijän vakuutussopimuksesta tarvitsema tieto on yhdessä paikassa, vähenee tarve liikkua eri järjestelmien välillä. Samalla vähenee inhimillisten virheiden määrä, mikä luonnollisesti heijastuu positiiviesti myös loppukäyttäjän suuntaan.  

PLP:ssa voi hallinnoida koko henkivakuutusyhtiön tuotetarjonnan sopimushallinnasta ulosmaksatukseen ja henkilöriskivakuutusten korvauskäsittelyn. PLP on täysiverinen ja kokonaisvaltainen henkivakuutusyhtiön sopimushallintajärjestelmä.


Lue myös:

Profit Life & Pension

P27 Nordic Payment muuttaa pohjoismaista maksukenttää

Suomalainen henkilötunnus muuttuu vaiheittain

customer-target-audience

 

Vuonna 2018 EU-alueella voimaan astuneen yleisen tietosuoja-asetuksen (General Data Protection Regulation eli GDPR) mukaisesti henkilötietojen käsittelyn on oltava luottamuksellista ja turvallista. Käytännössä tämä tarkoittaa, että esimerkiksi yritysten, jotka henkilötietoja käsitellessään ovat samalla myös rekisterinpitäjiä, tulee suojata tietojärjestelmissään olevat henkilötiedot mahdollisten tietoturvaloukkausten varalta. Samalla tulee varmistaa tietojen luottamuksellisuus, eheys ja saatavuus – tiedot on myös pystyttävä palauttamaan esimerkiksi teknisen onnettomuuden sattuessa.

Yritysten testiympäristössä tämä vaatimus konkretisoituu henkilötietojen peittämiseen tai häivyttämiseen siten, että henkilötietoja ei voi suoraan nähdä tai yhdistää muihin järjestelmässä oleviin tietoihin, mutta tietorakenteet pysyvät kuitenkin eheinä. Usein tämä toteutetaan algoritmeilla, jotka anonymisoivat tai pseudonymisoivat tiedot, jotta niitä voidaan tietoturvallisesti tarkastella ja käyttää testauksessa. Englanniksi puhutaan termistä data masking.

 

Anonymisointi vai pseudonymisionti?

Anonymisoinnilla tarkoitetaan henkilötietojen käsittelyä niin, että henkilöä ei enää voida tunnistaa niistä. Pseudonymisointi puolestaan tarkoittaa henkilötietojen käsittelemistä siten, että henkilötietoja ei voida enää yhdistää tiettyyn henkilöön ilman lisätietoja. Tällaiset lisätiedot täytyy tietenkin säilyttää huolellisesti erillään henkilötiedoista. (ks. lähde: Tietosuojavaltuutetun toimisto) Se, kumpaa suojaustapaa käytetään, riippuu käyttötapauksesta. Mikäli yritys käyttää tietoja vain testatakseen omaa tuotantoaan, pseudonymisointi riittää. Jos tietoja on tarve jakaa sellaiselle joukolle, jolla ei muuten olisi aineistoon oikeutta, käytetään näistä kahdesta raskaampaa anonymisointia tietojen suojaamiseksi.

Molemmissa tapauksissa datakokonaisuus säilyy eheänä. Tämä on tärkeää, jotta voidaan tuottaa testejä oikean elämän oikeilla tapauksilla, joita ei testijärjestelmässä tulisi muutoin mieleen testata, tai joita ei ilmenisi satunnaisesti generoidulla datalla. Toisaalta voidaan ongelmatapauksissa tuoda oikea käyttötapaus maskattuna testiympäristöön ja selvittää ongelma tietosuoja säilyttäen. Ilman henkilötietojen huolellista suojaamista ei testiympäristöissä voisi olla näitä oikean elämän tapauksia.

 

Meillä on ratkaisu ja kokemusta tietosuojaan liittyvistä projekteista

Henkilötietojen suojaaminen isoissa järjestelmissä voi parhaimmillaan olla hyvinkin yksinkertaista ja mutkatonta. Me Profit Softwarella olemme auttaneet asiakkaitamme jo vuosia järjestelmiensä henkilötietojen suojaamiseksi. Olemme kehittäneet siihen tehokkaan ja läpinäkyvän ratkaisun, joka on myös rakenteeltaan kevyt ja käyttäjäystävällinen. Sen läpi kulkee parhaillaankin isoja tietomassoja automatisoidusti, ja käyttäjä myös näkee, millaisten algoritmien mukaan ratkaisu tietoja käsittelee. Kyse ei suinkaan ole mistään mustasta laatikosta, vaan näitä määrityksiä pystystään myös joko yhdessä tai asiakasyritys omin voimin muokkaamaan – tarvittaessa tuotamme asiakkaallemme matemaattiset algoritmit juuri heidän tarpeeseensa.

Asiantuntijoillamme on jo paljon kokemusta tietosuojaan liittyvistä projekteista. Me tiedämme, mitä viranomaisvaatimukset tarkoittavat käytännössä, ja mitä ne tarkoittavat järjestelmien ja projektinhallinnan kannalta. Me olemme valmiita auttamaan yrityksesi tietojärjestelmien henkilötietojen suojaamisessa tietosuoja-asetuksen edellyttämällä tavalla.

Mikäli haluat keskustella lisää, lähetä meille yhteydenottopyyntö osoitteeseen sales@evitecdata.local. Asiantuntijamme vastaavat sinulle ripeästi.

 

linkedin-data-masking-blogi-1-1547555

 

Tutustu myös muihin analytiikan ja tiedolla johtamisen palveluihimme.

Lue lisää: Lieksan ananasfarmi ja koirakiven käsikirurgia – sensitiivisen testausaineiston pseudonymisointi

annika-2021-1-crop-1-1860960
Annika Karppinen, PLP Product Manager

Väestörekisteriä ylläpitävälle Digi- ja väestötietovirastolle (DVV) on jo pitkään ollut selvää, että henkilöä yksilöivät henkilötunnukset eivät nykyisessä muodossaan tule pidemmällä tähtäimellä riittämään. Lisäksi nykyiseen henkilötunnuksen rakenteeseen liittyy haasteita henkilön tietosuojan kannalta. 

DVV myöntää säännöllisesti uusia henkilötunnuksia esimerkiksi 1900-luvulla syntyneille. Yleensä kyseessä on tällöin ulkomaalainen, joka tarvitsee suomalaisen henkilötunnuksen. Koska joissakin maissa kaikille kansalaisille merkitään esimerkiksi passiin syntymäajaksi 1.1. tai 31.12., myöntää DVV juuri näillä päivämäärillä keskimääräistä enemmän henkilötunnuksia. Tämä puolestaan on johtanut siihen, että kyseisten päivämäärien osalta henkilötunnuksen tarkisteosan eri variaatiot ovat yksinkertaisesti loppumassa ja tähän on löydettävä ratkaisu, hyvin pian.   

Tämän akuuteimman haasteen lisäksi on henkilötunnuksen nykyisessä muodostustavassa yksityisyyden suojaan liittyviä ongelmia. Henkilötunnus, jonka tulisi toimia ainoastaan henkilöä yksilöivänä tietona, paljastaa henkilön syntymäajan ja sukupuolen. Nämä tiedot tulisi häivyttää, jotta henkilötunnus jatkossa olisi yksiselitteisesti yksilöintitieto.   

Valtiovarainministeriö (VM) aloittikin vuonna 2017 niin sanottu henkilötunnuksen uudistukseen tähtäävän selvitystyön. Työryhmän loppuraportti julkaistiin keväällä 2020. Tämä on sittemmin toiminut pohjana VM:n Hetu-uudistushankkeelle, joka käynnistyi loppuvuodesta 2020. Jo keväällä 2021 oli kuitenkin selvä, että loppuraportissa hahmoteltu tavoitteellinen aikataulu ei ole realistinen.  

Ei tarvitse kauaa miettiä, jotta muutoksen laajuus valkenee. Henkilötunnuksen lonkerot ulottuvat niin moneen ja lisäksi myös yhteiskunnallisesti kriittisiin toimintoihin, että muutoksen toteutus tulee vaatimaan toimenpiteitä lukemattomilta sekä julkisen että yksityisen puolen toimijoilta. Kun monet toiminnot lisäksi ovat kytköksissä toisiinsa, tullaan myös toimijoiden kesken tarvitsemaan aimo annos koordinaatiota. Kaikki tämä, ja toisaalta DVV:n tarve saada tarkisteosaan liittyvä ongelma pian ratkaistua, on liian iso kokonaisuus ratkaistavaksi kerralla. Niinpä henkilötunnuksen kokonaismuutos toteutetaan vaiheittain. Ensimmäisessä vaiheessa haetaan ratkaisu henkilötunnusten riittävyyteen.  

Muutoksen pyörteisiin joutuvan organisaation näkökulmasta vaiheistaminen on hieman harmillista. Vaiheistuksen kautta muutos on toki usein hallitumpi, mutta saattaa valitettavasti lisätä kustannuksia. Siksipä olisi jo ensimmäisen muutoksen suunnitteluvaiheessa hyödyllistä pystyä laajentamaan näkökulmaa lopulliseen tavoitekuvaan ja pyrkiä ennakoimaan myös tulevia muutoksia. Hetu-muutoksen osalta ainakin nyt kolme mainittua muutosta on jo tiedossa (välimerkki, syntymäpäivä ja sukupuoli). Kun näitä muutetaan, se vaikuttaa myös henkilötunnuksen tarkistukseen. Kuinka hyvin näillä olettamilla osutaan maaliin, se jää nähtäväksi.  

Meillä Profit Softwarella päätöksiä tulevista muutoksista odotellaan rauhallisin mielin. Profit Life & Pension (PLP) -järjestelmän joustavuus tulee tässäkin tilanteessa osoitettua todeksi. Mikään nyt tiedossa olevista muutoksista ei ole PLP:n toiminnan kannalta kovin merkittävä, sillä henkilötunnus  toimii jo nykyisellään vain yhtenä henkilöä yksilöivänä tietona. Esimerkiksi syntymäaika, joka on vakuutuksissa usein merkityksellinen, on oma erillinen tietokenttänsä. Mutta koska PLP on laajasti kytköksissä integraatioiden ja REST-palvelujen kautta moneen muuhun toimijaan, on näiden välisiä riippuvuuksia hyvä alkaa selvittämään ja varmistaa henkilötunnusmuutoksen sujuvuus. 


Lue lisää:

PLP-tuotetarjoomamme

Valtiovarainministeriö: Henkilötunnuksen uudistamista ja valtion takaaman identiteetin hallinnoimista koskeva hanke

Valtiovarainministeriö: HETU-uudistuksen loppuraportti

Finanssivalvonta* julkaisi syyskuun puolivälissä tiedotteen, jossa se kertoi toteuttaneensa teema-arvion koskien sijoituspalveluntarjoajien soveltuvuuden arviointia. Yhtenä havaintona oli, että MiFID II:n tuomia uudempia vaatimuksia oli selkeästi noudatettu heikommin kuin aiemman sääntelyn asettamia vakiintuneita vaatimuksia.

Soveltuvuusarvio liittyy sijoitusneuvonnan menettelytapoihin, mikä käytännössä tarkoittaa, että ennen kuin asiakkaalle pystytään tarjoamaan soveltuvia sijoituspalveluita ja rahoitusvälineitä, tulee pankin tai sijoituspalveluyrityksen selvittää asiakkaan tietämys ja kokemus palveluun liittyen – ja tähän tietämykseen perustuen tarjota soveltuvaa ratkaisua.

Asiakaspalvelun moninaiset järjestelmät eivät välttämättä tue sijoitusneuvojan pyrkimystä asiakkaan tilanteen kartoittamiseksi. Asia on kuitenkin syytä ottaa tosissaan: pahimmillaan pankki tai sijoituspalveluyritys voi saada laiminlyönnistä seuraamusmaksun. Toisena äärimmäisyytenä on se, että asiakaskohtaaminen muuttuu kuulusteluksi, jotta viranomaismääräykset varmasti täyttyisivät.

Asiakaskohtaamisen ratkaisumme tarjoaa hallitun ja yhdenmukaisen rakenteen asiakastapaamiseen. Se mahdollistaa asiantuntijalle keskittymisen asiakkaaseen ja asiakaspalvelun laatuun aina taustatietojen kartoituksesta asiakkaan jatkuvaan tukemiseen saakka.

asiakaskohtaamisen-jarj-1920x960-4291719

Hyödyt, joita ratkaisumme tarjoaa:
• Saat asiakkaan sijoittamisen ja säästämisen tavoitteista paremman ymmärryksen, mikä puolestaan helpottaa asiakkaalle sopivan ratkaisun esittelyä
• Tiedot ovat keskitetyssä järjestelmässä
• Asiakastapaamisesta voidaan kerätä selkeästi mitattavaa dataa
• Prosessi on selkeästi auditoitavissa, mikä auttaa noudattamaan finanssilaitoksen linjauksia ja viranomaisvaatimuksia
• Järjestelmä on mukautettavissa finanssilaitoksen omaan asiakkuuksien hoitomalliin

Ratkaisu voidaan toteuttaa on-premise tai pilvipohjaisena. Ennen toteutusta käymme läpi asiakkaan tilanteen ja valitsemme yhteistyössä parhaan mahdollisen teknisen toteutustavan ja sen, miten ratkaisu saadaan integroitumaan saumattomasti asiakkaan prosesseihin.

*) Sijoituspalvelujen ja rahoitusvälineiden soveltuvuuden arvioinnissa kehitettävää