Moni taho panostaa tällä hetkellä asiointipalveluidensa kehitykseen, ja moni näistä tahoista kehittää jo jopa toista tai kolmatta versiota asiointipalveluistaan. Monet asiakkaat ovat jo tottuneet hyviin asiointipalveluihin, esimerkiksi verkkopankit ja NetPosti ovat hyviä esimerkkejä jo varsin pitkäikäisistä asiointipalveluista. Myös valtionhallinnossa, kaupungeilla ja vaikkapa vakuutusyhtiöillä on paljon hyviä syitä panostaa helppokäyttöisiin itsepalvelukanaviin. Jotkut ovat menossa jo itsepalvelusta eteenpäin, ja rakentavat asiointikanavien sisälle verkkokauppoja ja muita lisäpalvelutarjoamia – esimerkiksi Elisa on tästä hyvä esimerkki.
North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
22.2.2016
Web-sivustojen ja verkkokauppojen puolella on päästy itse asiassa aivan dramaattisesti parempaan tilanteeseen viimeisen vuosikymmenen aikana. Aika harvan asiakkaan enää tarvitsee verkkokauppaansa tehdä räätäliprojektina (noh, joskus poikkeus toki vahvistaa säännön…). Asiointikanavien kohdalla räätälinä koodataan kuitenkin edelleen paljon, ja vaikka käytettäisiinkin valmistuotteita – niin silti yleensä päädytään tekemään alustan päälle tai rinnalle paljon räätälikoodia.
Miksi näin? Ja ovatko asiat menossa parempaan suuntaan?
Vastaus: Ovat menossa parempaan suuntaan. Haaste on se, että ne menevät samanaikaisesti hyvin moneen suuntaan.
Itse asiassa 2000-luvun lopussa ja 2010-luvun alussa oli jopa hetken aikaa melko selkeätä, kun kaikki Microsoft-asiakkaat halusivat väkisin tehdä kaikki asiointipalvelunsa SharePointin päälle. Noh, siitä krapulasta aletaan jo toipua sentään.
Microsoftikin on siirtynyt hyvin toisenlaisen meiningin puoltajaksi. Nyt Microsoft panostaa täysillä Azure-pilvialustaansa ja kannustaa kaikkia koodaamaan asiointipalvelunsa räätälitoteutuksina Azureen. Tämä viesti ei ole aivan huono edes, mutta epäilemättä muuttuu sillä sekunnilla kun Microsoft shoppaa jonkun alustan omaan tuoteportfolioonsa.
Alustat eivät nimittäin ole mitenkään kuolleita, eivät edes portaalit – vaikka niiden kuolemaa olen itsekin aktiivisesti vuosien varrella toivonut. Aivan kauheimmista portaalialustoista on onneksi päästy eroon. Suomessa suosittu Liferay-portaali esimerkiksi ei ole ollenkaan huono alusta, jos omat tarpeet portaaliratkaisulla tulevat tyydytetyksi.
Asiointipalveluita voi kuitenkin tehdä hyvin monella tavalla. Karkeasti voisi sanoa, että ylätason teknologiastrategisen lähestymisen (aikamoinen sanahirviö…) voi valita neljästä eri vaihtoehdosta:
1) Osta portaalituote, integroi siihen kaikki ja räätälöi kaikki asiakasnäkymät sen päälle.
2) Räätälöi kaikki asiakasnäkymät tärkeimmän liiketoimintajärjestelmäsi päälle, esim. CRM:n.
3) Panosta rajapintoihin ja räätälöi asiakasnäkymät asiakaskohtaisina sovelluksina.
4) Panosta identiteetti- ja pääsynhallintajärjestelmään ja avaa sen avulla asiakkaille rajoitettu pääsy suoraan liiketoimintajärjestelmiisi.
Tarkastellaan näitä eri lähestymisiä seuraavaksi hieman tarkemmin.
Malli 1: Portaalituotteen päälle rakentaminen
Asiakkaille tarjottavan asiointikanavan pohjaratkaisuna kenties kaikkein tyypillisin malli on rakentaa palvelut jonkun portaaliratkaisun päälle. Itse asiassa Microsoftin SharePoint edustaa asiointipalveluiden kohdalla yleensä myös tätä mallia, vaikka SharePointtia ei aivan täysiveriseksi portaaliksi voikaan oikein kutsua. Tällä hetkellä Microsoftin Office 365 kehittyy tosin aivan eri suuntaan kuin mihin perinteiset portaalit kehittyvät, kuten Liferay.
Portaalituotteiden isoimpana etuna voi pitää sitä, että ne tarjoavat “vähän kaikkea”.
Suomessa yleisimmät portaalit ovat käytännössä Liferay sekä IBM:n portaaliratkaisut. Myös Oraclen eri portaalituotteita on jonkin verran käytössä.
Portaalituotteiden isoimpana etuna voi pitää sitä, että ne tarjoavat “vähän kaikkea”. Niihin voi tehdä kevyitä integraatioita taustajärjestelmiin. Niissä on yleensä varsin hyvä käyttäjä- ja pääsynhallinta jo itsessään. Niissä on yleensä kohtuullisia julkaisujärjestelmien toiminnallisuuksia, kuten sisältöjen ja ulkoasujen hallintaa. Niille löytyy yleensä osaajia ihan kohtuullisesti, ja Java-portaaleihin etenkin on kehittynyt vuosien varrella myös yhteisiä käytänteitä.
Tämä kaikki tekee portaaleista hyviä “yleistyökaluja” asiointipalveluiden rakentamiseen – etenkin jos kyse on asiointikanavasta, johon kohdistuu monenlaisia tarpeita ja odotuksia. Portaalin päälle rakentamista voisikin kutsua vaikka “turvalliseksi perusratkaisuksi”.
Noh, aina ei tämä turvallisuus ja yleistyökalumaisuus ole ainoita syitä. Joskus on kyse vain siitä, että portaalin päälle rakentaminen voi olla paljon kustannustehokkaampaa kuin esimerkiksi erillisen identiteetin- ja pääsynhallintajärjestelmän ostaminen tai jonkun bisnesjärjestelmän laajentaminen asiointikanavaksi, kuten Salesforcen.
Yleensä etenkin pitkäikäisiä palvelukanavia rakennettaessa portaaliratkaisut voivat osoittautua voittaviksi ratkaisuiksi, ja täten ei olekaan ihme, että esimerkiksi valtionhallinnossa portaalien päälle tehdyt asiointikanavat ovat yleisiä.
Malli 2: Rakenna asiointipalvelut jonkun bisnesjärjestelmäsi päälle/kylkeen, esimerkiksi Salesforcen varaan
Joskus asiointipalvelut nojaavat niin vahvasti johonkin yksittäiseen bisnesjärjestelmään, että järkevin vaihtoehto asiointipalveluiden toteutukseen on rakentaa asiointinäkymät tiukasti kyseisen bisnesjärjestelmän kylkeen. Monilla organisaatioilla tämä keskeinen bisnesjärjestelmä esimerkiksi on CRM-järjestelmä, jolloin asiointipalveluidenkin keskeiset näkymät voi olla järkevintä tehdä tiukasti CRM:n kylkeen esimerkiksi sen tarjoamien rajapintojen varaan.
Bisnesjärjestelmän päälle asiointikanavien rakentamista on yleensä kaikkein vaikein suositella, koska tällainen malli ei ole kovin helposti tulevaisuudessa laajennettavissa ilman entistäkin isompia sidoksia ko. bisnesjärjestelmän käyttöön.
Tällä hetkellä etenkin Salesforce ajaa tätä mallia aktiivisesti monille organisaatioille – ja jopa sellaisille asiakkaille, jotka eivät käytä Salesforcea CRM-ratkaisunaan. Salesforcen tarjoama malli muistuttaa paljon aiempaa “SharePoint-buumia”, jossa asiakkaat hurmataan oletetuilla “alustan ominaisuuksilla” vaikka käytännössä päädytään yleensä koodaamaan aivan räätälitoteutuksia. Erona räätälitoteutuksiin on vain se, että Salesforcesta joutuu maksamaan kaiken ylläpidon lisäksi korkeita lisenssimaksuja.
Bisnesjärjestelmän päälle asiointikanavien rakentamista on yleensä kaikkein vaikein suositella, koska tällainen malli ei ole kovin helposti tulevaisuudessa laajennettavissa ilman entistäkin isompia sidoksia ko. bisnesjärjestelmän käyttöön. Alustatoimittajien, kuten Salesforcen, kannalta tämä malli on tietysti verrattavissa Kalifornian parhaiden kultaesiintymien valloitukseen ikuisella sopimuksella. Täten vaikea heitä on syyttää tämän mallin ajamisesta.
Asiakkaiden kannalta malli on yleensä järkevä vain tilanteissa, joissa asiointipalvelut todellakin ovat 90% ko. bisnesjärjestelmän tuottamia. Esimerkiksi jos asiointipalvelut ovat puhtaasti sitä, että asiakkaille annetaan pääsy päivittämään omia tietojaan, selailemaan omia sopimuksiaan ja ehkä tekemään palvelupyyntöjä organisaatiolle – ja tämä kaikki tapahtuu nimenomaan sen CRM:n sisällä – niin silloin voi olla järkevää tehdä asiointipalveluiden asiakaskäyttöliittymät sen bisnesjärjestelmän päälle. Muissa tapauksissa malli johtaa todennäköisesti vain suhteettoman tiukkaan toimittajaloukkuun yksittäiseen bisnesjärjestelmään.
Malli 3: Panosta rajapintoihin ja toteuta asiakasnäkymät räätälisovelluksina
Kolmas malli on varmaankin arkkitehtuurillisesti se “kaunein” ja siksikin usein koodareiden suosima malli. Tätä mallia myös ajavat aktiivisesti monet tämän maan räätälitalot, jotka näkevät mallissa tietysti suuret räätälikoodaustyömaat.
Perusideana on, että bisnesjärjestelmät abstraktoidaan erillisen rajapintakerroksen taakse, jolloin asiointisovelluksia ei integroida suoraan bisnesjärjestelmiin.
Noh, tässä mallissa on kyllä paljon järkeä. Halvalla tämä malli ei irtoa, mutta tulevaisuuden kannalta tämä malli voi tarjota paljon mahdollisuuksia.
Perusideana on, että bisnesjärjestelmät abstraktoidaan erillisen rajapintakerroksen taakse, jolloin asiointisovelluksia ei integroida suoraan bisnesjärjestelmiin, vaan asiakasrajapinnan sovellukset kommunikoivat vain rajapintakerroksen kanssa. Tästä mallista on tietysti vuosia jo vouhotettu alan lehdissä ja sille on annettu monia nimiä, esim. palveluarkkitehtuuri (”SOA”) ja monet muut termit.
Tietohallinnon kannalta malli on toteutuessaan kaunis, koska bisnesjärjestelmiä voidaan vaihtaa rajapintakerroksen takaa melko joustavasti eivätkä asiakkaille tarjottavat palvelut keskeydy niin herkästi. Samoin asiakkaille tarjottavat asiointipalvelut voidaan uudistaa melko useinkin ilman että kosketaan taustajärjestelmiin tai integraatioihin. Täten etenkin kuluttajaliiketoimintaa harrastavat konsernit, kuten teleoperaattorit ja pankit, usein panostavat tällaisiin arkkitehtuureihin, koska nämä antavat muutosnopeutta etenkin asiakkaille näkyviin palveluihin ja sovelluksiin.
Mallin kääntöpuolena on se, että rajapintakerroksen toteutus on helposti satojen tuhansien eurojen harjoitus, eikä se vielä sellaisenaan tuota mitään näkyviä hyötyjä mihinkään. Vasta kun rajapintakerroksen varaan aletaan rakentaa uusia palveluita, niin hyödyt alkavat hitaasti tulla näkyviin. Ylipäätään mallin hyödyt tulevat esiin vasta kun aidosti kehitetään paljon palveluita asiakkaille tai tehdään paljon muutoksia taustajärjestelmiin. Yleensä mallia käyttävillä organisaatioilla onkin aidosti monikanavaisia tarpeita, esimerkiksi useita mobiilisovelluksia asiakkailleen tai useita erilaisia extranet-ratkaisuja, jotka käyttävät samoja taustajärjestelmiä ja tekevät tilauksia samoista tuotetietokannoista.
Yleensä mitä monikanavaisempaa asiakaskokemusta ja mitä heterogeenisempaa taustajärjestelmäarkkitehtuuria, niin sitä todennäköisemmin kunnolliseen rajapintakerrokseen panostaminen kannattaa pitkällä tähtäimellä. Lyhyellä tähtäimellä rajapintakerrokseen investointi on aina haastava perusteltava, koska näkyviä hyötyjä ei juurikaan tule.
Asiakkaille näkyviä sovelluksiakaan ei välttämättä tässä mallissa tarvitse toteuttaa räätälisovelluksina. Esimerkiksi monet verkkokauppaa harjoittavat organisaatiot käyttävät tätä mallia, mutta silti käyttävät jotain verkkokauppa-alustaa asiakkaalle näkyvän kaupan pyörittämisessä.
Asiointipalveluiden toteutuksessa tämä malli kuitenkin konseptillisesti suosii “piensovelluskonseptia”, eli mallia, jossa tehdään melko itsenäisiä, pieniä sovelluksia ja jossa asiakkaan avaama etusivu saattaa jopa muistuttaa älypuhelimen avausnäkymää.
Tällainen piensovellusmalli on tällä hetkellä tietysti muistakin syistä järkevä, koska se soveltuu hyvin mobiilikäyttöön ja mahdollistaa melko itsenäisen pienkehityksen palveluiden eri osille.
Malli 4: Panosta identiteetin- ja pääsynhallintaratkaisuun
Neljäs malli on eniten käytössä yritysten välisessä asiointimaailmassa, koska kuluttajille yleensä halutaan tarjota melko yhtenäisiä käyttökokemuksia eikä haluta pomputtaa kuluttajaa useissa eri järjestelmissä.
Järjestelmän avulla voidaan tarjota käyttäjille kirjautumispalvelut sekä esimerkiksi yksinkertainen aloitussivu, josta eri sovelluksia voi käynnistää.
Yrityspuolella “pomputtaminen” on hyväksyttävämpää, ja jopa ihanteellista, koska näin voidaan ammattikäyttäjille tarjota suoraan pääsy erityissovelluksiin, joissa he voivat toimia jopa samanlaisilla oikeuksilla kuin oma henkilökunta. Esimerkiksi monet isot maahantuojat käyttävät tätä mallia, jotta voivat avata jälleenmyyjilleen suoran pääsyn tilaus- ja varastojärjestelmiin ilman erillisen “asiointikerroksen” rakentamista (vaikkapa jonkun portaalijärjestelmän päälle).
Tässä mallissa siis panostetaan monipuolisen identiteetin- ja pääsynhallintaratkaisun pystytykseen ja kytketään keskeiset bisnesjärjestelmät suoraan tähän järjestelmään. Järjestelmän avulla voidaan tarjota käyttäjille kirjautumispalvelut sekä esimerkiksi yksinkertainen aloitussivu, josta eri sovelluksia voi käynnistää. Identiteetin- ja pääsynhallintajärjestelmä (esim. Ubisecure) sitten vastaa siitä, että jokainen käyttäjä näkee vain ne sovellusikonit, jotka hänelle kuuluvat – ja lisäksi järjestelmä vastaa siitä, että jokaisessa sovelluksessa käyttäjä saa vain ne oikeudet jotka hänelle kuuluvat.
Tällaista mallia voisi kuvata vaikka “ammattilaisen asiointipalveluksi”, koska käyttökokemus on hyvin riisuttu – ja muistuttaa tavallaan älypuhelimen käyttöä. Kaikki asiat tehdään erillisissä sovelluksissa, jotka voivat toimia hyvinkin eri tavoilla ja mahdollistavat hyvin eritasoisia toimintoja. Tällainen malli soveltuu erittäin hyvin juuri yritysten välisiin asiointiratkaisuihin, ja voi parhaimmillaan säästää jopa miljoonia euroja, koska tämän mallin avulla ei tarvitse koodata sitä raskasta asiointikerrosta ollenkaan, koska käyttäjät päästetään suoraan bisnesjärjestelmien käyttöliittymiin – rajoitetuilla oikeuksilla toki.
Yhteenveto: Valitse oikea malli oikeaan tarpeeseen
Tämä oli lopulta vasta pintaraapaisu siihen millaisia erilaisia teknisiä ratkaisumalleja voidaan asiointipalveluihin ottaa. Jatkojutuissa on tarkoitus avata eri malleja vielä hieman tarkemmin, mutta toivottavasti tästä kokonaiskuvasta jo on hyötyä. Todella isojen organisaatioiden kannattaa myös huomioida, että nämä mallit voivat toteutua myös yhdessä. Esimerkiksi joku OP-Pohjolan verkkopankki-, vakuutusasiointi- ja mobiilisovelluskokonaisuus sisältää helposti kaikkia kuvattuja elementtejä.
Varmasti se isoin viesti tässä jutussa on kuitenkin se, että ensin kannattaa todella tehdä liiketoiminnallinen konsepti asiointipalveluille ja kehityksen haaveiltu tiekartta – ja vasta sitten kannattaa valita teknologinen lähestyminen asiointipalveluiden toteutukseen.
Teknologiavalinta on vuosikymmenen investointi
Teknologiaratkaisuissa ei kannata tehdä valintojaan kuumimpien trendien mukaan, vaan soveltuvuuden, skaalautuvuuden, ylläpitokokemuksen, yhteensopivuuden ja elinkaarikustannuksien ehdoilla. North Patrol auttaa näkemään teknologiavaihtoehtojen plussat ja miinukset puolueettomasti, konkreettisesti ja kaukonäköisesti.
PS. Sinua voisi kiinnostaa tulossa oleva ilmainen webinaarimme: Onnistu verkkopalvelu-uudistuksen läpiviennissä (20.11.2024 klo 10:00). Ilmoittaudu webinaariin
