DevOps (automatisoidut IT-palvelut) tarjoaa monia hyötyjä järjestelmäprojekteissa, mutta kiteyttäen se varmistaa, että uusia toiminnallisuuksia saadaan tuotantoon nopeasti niin kehitys- kuin ylläpitovaiheessa. Malli säästää ennen kaikkea liiketoiminnan aikaa. Keskustelimme asiantuntijoidemme, Janne Takalan ja Jussi Kauhasen, kanssa DevOpsin hyödyistä.
Ketterästi kehittäen
– DevOpsin tärkein hyöty on ketteryys ja nopeus, jota se tarjoaa. Siinä ei ole perinteistä byrokratiaa, jossa kehittäjät kehittävät toiminnallisuuksia, minkä jälkeen ne menevät jonkin putken kautta jollekulle, joka varmistaa laadun. Mallissa samat henkilöt kehittävät ja asentavat toiminnallisuuksia, ja parhaimmillaan asiat toimivat nappia painamalla ja niihin voidaan reagoida nopeasti, kertoo Jussi.
Asiakkaan näkökulmasta DevOps mahdollistaa uusien toiminnallisuuksien tehokkaan tuomisen testaukseen tai ylläpitovaiheessa tuotantoon.
– Tuotantoon voidaan päivittää jatkuvasti virheenkorjauksia tai tuoda uusia toiminnallisuuksia eikä siinä mene kuukausia tai pahimmissa tapauksissa useita vuosia. Kehitysprojektissa asiakkaalle saadaan ensimmäinen demo julkaistua jo muutamassa viikossa, jatkaa Janne.
Pipeline pilvessä: enemmän automatisaatiota, vähemmän virheitä
Pilvi mahdollistaa ympäristöjen automaattisen perustamisen. Esimerkiksi uusi testiympäristö saadaan käyttöön minuuteissa ilman fyysisiä asennuksia. Eteneminen on flow-tyyppistä, julkaisuja tehdään jatkuvasti automatisoituna. Kun päivitykset tuotantoon tehdään automaattisesti, minimoidaan samalla virheet.
– Laatu voidaan varmistaa monin keinoin, mutta se myös maksaa. Automaattitestauksen avulla hoidamme asioita, jotka olisivat muuten testaajan työlistalla. Tämä tuo myös työhön mielekkyyttä, kun samoja regressiotestejä ei tehdä käsin uudelleen ja uudelleen, sanoo Jussi.
Laadukasta koodia
DevOps tarkoittaa myös automatisoitua julkaisuputkea kehittäjän työpöydältä tuotantoon. Kun tiimissä tehdään koodiin muutoksia, tehdään julkaisuputkessa aina koodikatselmointi ja staattinen analyysi sekä ajetaan yksikkötestit.
– Kehittäjän tekemät muutokset katselmoidaan aina vähintään kahden muun kehittäjän toimesta, minkä jälkeen ne viedään testiympäristöön ja ajetaan integraatiotestit. Vasta tämän jälkeen muutokset julkaistaan eteenpäin, selventää Janne.
– Ajamme samat testit kaikissa ympäristöissä. ”Putki” ohjaa työtä ja koko prosessi on pitkälle automatisoitu, minkä avulla inhimilliset virheet voidaan välttää. Meillä on työkalut automaattiseen laadunvarmistukseen ja automaattitestit käytössä. Pysymme koko ajan kartalla siitä mikä toimii, ja että kaikki toimii oikein. Asiakkaan liiketoimintaosaajien aikaa ei tarvitse käyttää testaukseen, sillä automaattitestaus estää regressiot, summaa Jussi.
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?
Finanssialan järjestelmäuudistuksia tehdään pitkälti kahdesta syystä: viranomaismääräykset asettavat uusia vaatimuksia tai käytössä oleva järjestelmä on tullut tiensä päähän. Uuden järjestelmäprojektin alkaessa Profit Softwaren tiimissä on aina tarvittaessa liiketoiminta-asiantuntijoiden ja kehittäjien lisäksi käyttäjäkokemuksen asiantuntija tai useampi. Haastattelimme Profit Softwaressa käyttäjäkokemuksen parissa työskentelevää Suvi Tuomistoa.
”Käyttäjäkokemus (User Experience, UX) on ollut intohimoni jo opiskeluajoista lähtien. Töitä olen tehnyt asian parissa jo reilun 10 vuoden ajan. Nykyinen tittelini Business Analyst kuvaa rooliani hyvin: hyvä käyttäjäkokemus syntyy, kun ymmärretään liiketoiminnan tavoitteet ja loppukäyttäjien tarpeet.
Työskentelymme pohjautuu vakiintuneeseen malliin. Se varmistaa, että ymmärrämme liiketoiminnan ja käyttäjien näkökulmasta tarpeet, mutta yhtä tärkeää on luoda yhteinen ymmärrys ja selkeät kommunikointitavat projektille. Projektista riippuen osa palvelumuotoilumallimme vaiheista saattaa toteutua jo ennen varsinaista aloitusta. Suuremmissa projekteissa vaiheet esiselvityksestä konseptin validointiin saatetaan eriyttää omaksi Sprint 0 -määrittelyprojektiksi, jonka avulla ymmärrämme tarpeita ja kokonaisuuden paremmin. Teemme myös projekteja, joissa käyttäjälähtöisten menetelmien kirjo on perustellusti suppeampi esimerkiksi projektin koosta johtuen.
Esiselvitysvaihe käynnistyy yhteisellä työpajalla asiakkaan kanssa. Parasta on aloittaminen ilman odotuksia: avoin mieli auttaa kuulemaan asiakkaan tarpeen ja ymmärtämään tapauksen problematiikkaa juuritasolta ja asiakasnäkökulmasta. Meidän tehtävämme on tutustua aiheeseen esimerkiksi dokumentaation avulla. Työpajassa saamme käsityksen asiakkaalle tärkeistä ja merkityksellisistä asioista.
Uutta järjestelmää kehitettäessä on tärkeää ymmärtää, ketkä sitä käyttävät. Käyttäjätutkimus on keskeisin vaihe tämän ymmärryksen muodostamisessa. Käyttäjäsegmentoinnin avulla saamme tiedon kunkin käyttäjän roolista ja millaiset roolit on hyvä olla projektissa edustettuna. Erityisen arvokkaita ovat kahdenkeskiset haastattelut. Niissä saamme usein rehellisen palautteen ja haastateltavan ääni tulee parhaiten kuuluviin.
Ratkaisua ei kannata suunnitella tietylle ryhmälle. UX-suunnittelijana ymmärrän heuristiset lähtökohdat ja sen, miten asiat toimivat. Hyvä ratkaisu palvelee nykyisiä, mutta myös tulevia käyttäjiä. Käyttäjäprofiilien ja -polkujen avulla saadaan käyttäjän kokemia ongelmia hyvin selville. Näin voimme suunnitella ratkaisun, joka aidosti palvelee tekemistä ja liiketoimintaa.
Konseptin määrittely ja validointi tapahtuu usein iteratiivisesti. Vaiheen aikana tarkennetaan sitä, mitä ollaan tekemässä ja validoidaan tekemistä eritasoisilla prototyypeillä. Käyttäjätarinaan on sisällytetty, mitä käyttäjä haluaa tehdä ja miksi. Käyttäjätarinoista on apua suunniteltaessa, miten järjestelmän tulee toimia, jotta asia tulee hoidetuksi. Suunnittelijan näkökulmasta tämä on projektin näkyvin ja työllistävin vaihe.
Toteutusvaiheen aikana suunnittelija tekee usein käyttöliittymäkatselmointeja ja järjestää käyttäjätestauksia. Käyttäjätestauksista saamme arvokasta käyttäjäpalautetta ja toisaalta testaukseen osallistuvat käyttäjät saavat ensisilmäyksen uudesta järjestelmästä. Koska kaikki käyttäjät eivät yleensä osallistu käyttäjätestaukseen on syytä suunnitella, miten ratkaisusta annetaan jatkossa palautetta, miten käyttäjäkokemusta mitataan, ja miten tuloksia käsitellään myöhemmin järjestelmän käytön aikana.”
Käytöstä poistettujen järjestelmien tietojen säilyttäminen – asia, joka kuulostaa yksinkertaiselta, mutta ei sitä useimmiten ole. Tietojärjestelmien käytön jatkaminen ainoastaan arkistointitarkoituksessa on yleensä kallista saavutettuun hyötyyn nähden: järjestelmää pyöritetään, kunnes vanhan tiedon arkistointitarve vähitellen poistuu. Tämän lisäksi vanhojen järjestelmien käyttäminen arkistona saattaa olla työlästä ja aikaa vievää varsinkin, jos arkistointitarpeena on vain rajattu joukko tietoja, kuten yleensä on.
– Vanhojen järjestelmien alasajon yhteydessä on aina tietoja, jotka tulee arkistoida. Tähän velvoittavat niin lainsäädäntö, joka vaatii tietojen säilyttämistä tietyn aikaa, mutta myös liiketoiminnalliset tarpeet, kertoo tuotepäällikkö Janne Takala
Vuonna 2018 voimaan tullut EU:n yleinen tietosuoja-asetus* (GDPR) asettaa arkistoinnille uusia vaatimuksia. Kun aiemmin arkistointi saatettiin hoitaa varmuuskopioinnin turvin, ei se enää nykyisellään onnistu. Lisäksi lainsäädäntö velvoittaa eräiden tietojen säilytysajaksi vähintään 10 vuotta.
– GDPR:n myötä asiakkaat voivat pyytää kaiken tunnistettavan datan poistamista eli asiakas ikään kuin unohdetaan. Tämä vaatimus ei toteudu tarvittavalla tavalla varmuuskopioinnissa eikä tietovarastoinnissa. Vanhoja järjestelmiä ja niiden arkkitehtuuria ei ole yksinkertaisesti optimoitu arkistointikäyttöön, jatkaa Takala.
Arkki-ratkaisun kehittäminen on lähtenyt liikkeelle siitä, että poistuvien järjestelmien osalta on olemassa selkeä arkistointitarve. Tämän lisäksi asia on ajankohtainen myös aktiivisessa käytössä oleville järjestelmille. Ensimmäinen Arkki-ratkaisun asiakaskäyttöönotto tehtiin vuosi sitten tammikuussa.
Takalan mukaan kokemukset ovat tähän mennessä hyviä: ”Arkki nopeuttaa arkistointiprosessia 70–90 % verrattuna tilanteeseen, jossa arkistointiratkaisu rakennetaan kokonaan alusta alkaen.”
Käyttöönotossa apuna ovat Evitecin asiantuntijat sekä käyttöönottoa tukevat prosessit ja työkalut. Arkki skaalautuu eri tarpeisiin ja sillä voidaan hoitaa suurienkin tietomassojen arkistointi.
*) https://tietosuoja.fi/gdpr
Paraneeko vaihtamalla? Jos sen tekee harkitun vertailun ja asiaansa palvelevan kriteeristön mukaan, niin kyllä. Tämän huomasivat Profit Loans & Collaterals -tiimissä nykyaikaista antolainausratkaisua yritysrahoituksen tarpeisiin kehittävät koodarit. Tärkeä osa kehitystyötä on ratkaisun käyttöliittymän end-to-end-testaaminen, jota tehdään omassa testausympäristössään. Tiimissä kaikki kehittäjät ovat moniosaajia, jotka tekevät joustavasti kaikkia kehitysvaiheen eri tehtäviä, joten myös testaaminen kuuluu jokaisen pöydälle.
— Testausautomaatioon olemme aiemmin käyttäneet Robot Frameworkia, joka ajaa automaattisia robottitestejä. Huomasimme kuitenkin, että testit hajoilivat satunnaisesti. Kun jokainen kehittäjä sitten joutuu painimaan testien selvittelyiden kanssa vuoron perään, tähän menee aika paljon aikaa, kertoo kehittäjänä työskentelevä Timi Voutilainen.
Tiimin kehittämän ratkaisun vaatima testimassa on suuri, koska testattavia ominaisuuksia on paljon. Yhden testiajon ajamiseen kuluu aikaa keskimäärin 40–60 minuuttia. Kahden vuoden aikana tiimissä on ajettu automaatiotestejä yli 5000 kertaa. Kun testimäärät ovat suuret ja niihin kuluu aikaa, on tärkeää, että testit ovat luotettavia.
Uutta työkalua lähdettiin etsimään tunnettujen ja laajasti käytössä olevien ratkaisuiden kautta. Testien luotettavuus oli tärkein kriteeri. Robot Frameworkin kanssa toimittaessa onnistumisprosentti saattoi olla mitä vain 90 ja 97 prosentin välillä – tämän luvun oli noustava. Toinen kriteeri oli se, että testaustyökalun käyttö olisi mahdollista TypeScriptillä, jota käyttöliittymätoteutuksessa käytetään – tämä helpottaa kehittäjän työtä, kun testaustyökalua varten ei tarvitse vaihtaa käytettävää kieltä toiseen.
Myös se painoi vaakakupissa, että testaustyökalun ominaisuudet ovat monipuoliset ja mahdollistavat esimerkiksi ongelmatilanteiden imitoinnin siten, että testaaja näkee, mitä http-kutsuja käyttöliittymältä lähtee. Niin ikään tyypitetyn kielen käyttö, esimerkiksi rajapintatyypitykset, olivat kriteeri bugien vähentämiseksi.
— Päädyimme lopulta Cypressiin, joka on suosittu testaustyökalu maailmalla. Huomasimme nopeasti, että se täyttää kriteerimme ja tarpeemme, ja näin ollen helpottaa ja nopeuttaa kehitystyötä, Timi kertoo.
— Se, että voimme tehdä testejä samalla kielellä, jolla työskentelemme muunkin kehityksen parissa, auttaa selkeän arkkitehtuurin rakentamisessa ja ylipäätään sujuvoittaa tekemistä, Timi jatkaa.
Cypressin monipuoliset ominaisuudet mahdollistavat esimerkiksi paremmat debuggaus-ominaisuudet, jokaisen vaiheen yksityiskohtaisen erittelyn käyttöliittymältä ja jopa suoran tuen videolle ongelmatilanteiden eri vaiheiden selvittämiseksi, mikä ei aina pelkkää kuvaa katsomalla ole niin yksiselitteistä.
— Virheiden löytäminen on Cypressissä ylipäätään helpompaa, Timi toteaa.
— Tulokset, joita testien ajo tuottaa, osoittaa meille hyödyn työkalun vaihdosta. Lisäarvo asiakkaalle on laadukas tuote, joka toimii luotettavasti.
Lue myös muita blogejamme Profit Loans & Collaterals -tiimin työskentelystä:
https://profitsoftware.com/sovellusarkkitehti-jussi-profit-softwarella-kehittajat-jotka-kehittavat-omaa-tekemistaan-eivat-voi-muuta-kuin-onnistua/
https://profitsoftware.com/hyvat-sprinttirutiinit-helpottavat-projektissa-aloittamista/
https://profitsoftware.com/devaajan-paiva/
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:
Evitecillä on vankka kokemus kiinnitysluottopankkitoiminnan järjestelmäprojekteista. Toteutuksia on tehty mm. Hypolle, OP:lle, Oma Säästöpankille ja viimeisimpänä S-Pankille sen parhaillaan käynnistäessä kiinnitysluottopankkitoimintaa.
Kiinnitysluottopankkitoiminnan aloitus on pitkä prosessi ja tietojärjestelmän toteutus on yksi osa sitä. Ennen aloitusta asiakkaalle tarjotaan yleensä mahdollisuutta Proof of Concept:iin (POC), eli asian toteuttamiskelpoisuuden todentamiseen.
– Ennen toiminnan käynnistämistä on tärkeää todentaa kiinnitysluottopankkitoimintaan kelpaava luottomassa, osassa tapauksia se vaikuttaa jopa päätöksentekoon. POC:in aikana selvitetään, mitkä edellytykset aloittamiselle ovat ja ylipäätään minimoidaan riskejä niin asiakkaan kuin toimittajan näkökulmasta, kertoo lukuisissa toteutuksissa mukana ollut Tino Silfver Evitecistä.
Proof of Concept:in aikana tuotetaan analyysi laina- ja vakuuskannasta. Analyysin seurauksena saadaan selville esimerkiksi mahdolliset dataongelmat, jotka pitää ratkoa ennen prosessin aloittamista. Pahimmassa tapauksessa dataongelmat nimittäin heikentävät luottokannan laatua.
– Analyysin aikana saadaan myös yleistä tuntemusta omasta lainakannasta, mikä voi joskus johtaa jopa toimenpiteisiin, jatkaa Silfver.
POC:in pihvi on asiakkaan data
POC:in ensimmäisessä vaiheessa saadaan pääsy asiakkaan ympäristöihin. Tämän jälkeen voidaan alkaa määrittelemään POC-kriteeristöä, eli millä kriteeristöllä luottoja ja vakuuksia valitaan pooliin. Tärkeässä roolissa on myös raportointiin liittyvät yksityiskohdat.
Varsinaisessa analyysivaiheessa tehdään erilaisia kyselyitä datamassaan liittyen. Rinnakkain asennetaan Evitec Covered Bonds -ratkaisun POC-versiota käyttökuntoon. Ihannetilanteessa POC:in aikana saadaan käyttövalmis demoympäristö, jossa ratkaisua pääsee kokeilemaan.
Lopuksi asiakkaalle esitellään raportti ja asiantuntijoidemme tekemät havainnot.
– Kun POC rajataan järkevästi, se saadaan yleensä toteutettua 1–2 kuukauden aikana. Hyötynä mainitsisin myös sen, että esimerkiksi työmäärät itse projektin osalta on huomattavasti helpompi arvioida, summaa Silfver.
Onko kiinnitysluottopankkitoiminnan käynnistäminen tai KLP-järjestelmän vaihtaminen ajankohtaista? Lue toteutuksistamme!
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.
Tutustu myös muihin analytiikan ja tiedolla johtamisen palveluihimme.
Lue lisää: Lieksan ananasfarmi ja koirakiven käsikirurgia – sensitiivisen testausaineiston pseudonymisointi
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ää:
Evitec Power Lending on antolainauksen ja vakuushallinnan elinkaarijärjestelmä, joka soveltuu parhaiten suomalaisen yritysrahoituksen tarpeisiin. Nyt toimme perinnän osaksi lainanhallintajärjestelmää.
Gorilla-perintäjärjestelmällä voit hoitaa saatavien perintää niiden elinkaaren kaikissa vaiheissa. Ratkaisua on kehitetty pitkään ja asiakkaillamme on siitä käytössä eri versioita.
– Rahoituslaitoksen näkökulmasta ideaalitilanne on, että käytettävä ratkaisu kattaa koko asiakkuuden elinkaaren, tässä tapauksessa vaiheet hakemuksesta perintään, kertoo Evitecin asiantuntija Nina Luukkanen.
Lainanhallinta- ja perintäratkaisumme teknologinen yhteensopivuus on hyvä, sillä molemmissa on SQL-tietokanta, vaatimukset palvelimille ovat siis samat.
– Evitec Power Lending -järjestelmän suunnittelun perustavoite on mahdollistaa tehokkaat prosessit. Reaaliaikainen tieto ja integraatiot ovat tässä avaintekijöitä. Perinnän järjestelmässämme on nämä samat piirteet. Haastehakemukset lähtevät napin painalluksella, jatkaa Financial Sector Solutions -yksikön tuotteista Evitecissä vastaava Janne Takala.
Gorilla mukautuu joustavasti asiakkaan liiketoiminnan tarpeisiin, minkä lisäksi mahdolliset lisäominaisuudet voidaan toteuttaa asiakaskohtaisesti. Se on myös integroitavissa muihin järjestelmiin. Gorillan tuominen osaksi Evitec Power Lending -ratkaisua tehostaa järjestämättömien luottojen hoitoa.
– Ratkaisu sisältää laajasti toimintoja, mutta kaikkia toimintoja ei tarvitse ottaa heti käyttöön. Voisi sanoa, että vain mielikuvitus on tässä rajana, tiivistää Luukkanen.
