Räätälityötä vai hyllytavaraa?

Räätälöityä kehitystä koskevan keskustelun huonon laadun takana näemme neljä keskeistä tekijää:

• Toimittajat vetävät – ja niiden oletetaankin vetävän – liikaa kotiinpäin
• Asiakkaat laskevat euroja liian lyhytjänteisesti
• Sovellusten integraatio- ja elinkaarikustannuksia koskeva keskustelu on liian alkeellista
• Keskustelu polarisoituu tarpeettomasti joko/tai-malliseksi

Yllättäen avoimia keskusteluja näin kriittisestä valinnasta käydään vain harvassa projektissa. Joko reitti on valittu heti alussa jonkin ennakkokäsityksen perusteella, tai sitten asiakas pyytää hankkeeseensa pari tarjousta räätälöidystä ratkaisusta ja toiset pari tuotepohjaisesta. Harkinta tehdään sitten näiden välillä.

Usein valintaan päädytään ilman, että saatujen tarjousten välillä olisi mitään dialogia: räätälöidyn ratkaisun tarjoaja ei saa tilaisuutta perustella, miksi heidän ratkaisunsa on 30 000 euron edestä parempi kuin kilpaileva toteutus, eikä tuotepohjaisen ratkaisun edustaja pääse kertomaan, miten he ratkaisisivat niitä erikoistapauksia, joiden kohdalla räätälöity ratkaisu kuitenkin houkuttelee. Tämäkin malli toimii erinomaisesti, jos asiakkaalla on riittävä osaaminen tehdä vertailu loppuun asti. Ongelma on vain siinä, että sovelluskenttä on laajentunut hurjasti, ja kaikkia relevantteja näkökulmia on todella vaikea onnistua huomioimaan.

Valmissovellusten voittokulku

2000-luku on muuttanut liiketoimintasovellusten kentän täysin. Kun pienempiinkin yrityksiin tulivat tietokoneet, valmissoftapaketteja alkoi löytyä kaupoista. Nyt kaikki on tietysti netissä, ja Capterran kaltaiset palvelut auttavat asiakkaita löytämään valmisratkaisuja valtavista valikoimista. Joskus ihan naurattaa: esimerkiksi pienpanimoille suunniteltuja ERP-järjestelmiä on sivutolkulla. Ja luonnollisesti yhä useampi sovelluksista toimitetaan SaaS-periaatteella: Järjestelmää pääsee kokeilemaan heti ilmaiseksi, ja sen jälkeen mennään kuukausitilauksella.

Nykyisin useimpien yritysten ei kannata ajatellakaan liiketoimintatiedon perusjärjestelmien räätälöintiä, ellei niihin liity selvää kilpailuetua. Taloushallinto, palkanlaskenta, CRM, verkkokauppa, sisällönhallintajärjestelmä… Harvoinpa näitä enää tehdään. Pienissä yrityksissä investointien minimointi on tärkeä ohjaava tekijä; suuryrityksissä taas korostuvat saatavilla oleva valmis osaaminen (”Etsitään Basware-pääkäyttäjää”), määräystenmukaisuus ja nopea käyttöönotto.

Yleinen taloustieteen periaate pätee IT:ssäkin: työnjako lisää tuottavuutta. Kun joukko tuotesuunnittelijoita, koodareita ja muita ammattilaisia on saanut keskittyä 10 vuotta vain CRM-konseptin hiomiseen, lopputulos on parempi CRM kuin jos tuhannet räätälöidyt devaustiimit olisivat tehneet jokainen omansa kaikkien muiden softaprojektien lomassa.

Joskus monikansallisen tuotteen kehitystiimin varaan heittäytyminen pelottaa. Tästä syystä valinta kohdistuukin usein tutumpiin tuotteisiin, joille löytyy Suomesta paikalliset edustajansa. Esimerkiksi Salesforce-säätäjiä ja WordPress-virittäjiä löytyykin joka lähtöön – tarvitsee vain etsiä se, joka sopii omiin tarpeisiin, budjettiin ja tekemisen tyyliin parhaiten. Valmistuotetta ei myöskään aina oteta käyttöön sellaisenaan, vaan usein sen ympärille kietoutuu ainakin jonkinlaista konfigurointia, jossa kokeneen konsultin ote säästää aikaa ja rahaa.

Räätälöidyn ratkaisun paikka

Koska koodin tekeminen vain yhtä asiakasta varten vaatii erityistä ajallista ja rahallista panostusta, sitä kannattaa ajatella harkittuna investointina. Jälleen voi nojata taloustieteeseen: Kannattaa investoida siihen, mikä tuottaa eniten kilpailuetua eli maksaa itsensä takaisin. Mikä sitten olisi sellaista?

Ensin keksitään aina erottautuminen loppuasiakkaiden silmissä. Timanttinen matkalaskujen käsittelyratkaisu ei vie kenenkään bisnestä uusiin ulottuvuuksiin, mutta asiakkaiden elämää helpottava mobiilisovellus voi hyvinkin olla kaupallisesti ratkaiseva. Tästä näkökulmasta räätälöidyt kehityspanokset kannattaisi suunnata sinne, missä myynnin, toimituksen ja asiakaspalvelun tarpeita ei saada riittävän laadukkaasti ratkaistua valmisohjelmistoilla. Näinpä monen digitaalisia palveluita tarjoavan yrityksen ensimmäinen räätälöity ratkaisu onkin nimenomaan asiakaskokemus.

Sitten tulee tuotannon tehostaminen. Voisiko räätälöidyllä ratkaisulla johtaa suunnittelua, ohjata paremmin työtä, optimoida varastoa, tehostaa jakelua? Valmisratkaisujen saatavuus riippuu toimialasta, mutta useimmiten yrityksen ydinprosesseissa on ainakin joitain elementtejä, jotka ovat jollain tavalla toiminnalle uniikkeja. Alkuvaiheessa valmisohjelmistojen välejä voi täyttää Excelin ja Power BI:n tyyppisillä yleistyökaluilla, mutta jossain vaiheessa tarve omien ratkaisujen käyttöönotolle kasvaa.

Monesti räätälöidyn ratkaisun tarve kasvaa ajan myötä huomaamatta. SaaS-sovellusten tilkkutäkki vaatii integraationsa – joko ATK:ta tai MTK:ta (manuaalinen tietojenkäsittely). Kun integraatioverkko pettää ja kaikkea tarvittavaa ei saadakaan tehtyä, monimutkainen järjestelmäpaletti voi olla työläs kuroa kasaan. Tällöin osan järjestelmistä korvaaminen räätälöidyllä ratkaisulla voi näyttäytyä houkuttelevana valintana.

Sama koskee myös datan laatua: Jos liiketoiminnan kannalta kriittiset käsitteet elävät vain esimiesten Exceleissä tai myyntijohtajan muistivihossa, jossain vaiheessa tilanne eskaloituu. Jos keskitetyn datan puute johtuu järjestelmien puutteista, on aika tarkastella kriittistä kysymystä: Tekevätkö järjestelmäni sitä mitä pitääkin, vai vaatiiko niiden käyttö liian raskasta mukautumista?

Risteys edessä, silmät auki!

Oman sovelluksen toteutuksen mahdollisuutta koskevat myyntipuheet ovat ikävän yksiulotteisia. Valmistuotekonsultit äityvät usein kaavamaiseen räätälöinnin kustannuspelotteluun, kun taas räätälöintitalot sortuvat ylikorostamaan mukautuvan sovelluksen etuja. Molemmissa on totuuden siemen, mutta molemmat ääripäät hukkaavat asian ytimen: asiakkaan saaman liiketoiminta-arvon ymmärtämisen – nyt ja nähtävissä olevassa lähitulevaisuudessa. Usein tuntuukin, että toteutuslinja päädytään valitsemaan liian köykäisellä harkinnalla.

Osaava konsultti tuo mukanaan paitsi teknistä osaamista, parhaimmillaan myös toimialatietämystä. Varsinkin tuoteratkaisuissa tämä pohjanäkemys vie helposti vauhdilla eteenpäin: SaaS-ympäristöt syntyvät äkkiä, ja taitava toteuttaja naputtelee perusrungot äkkiä tutulla tuotteella. Tämä on kiistaton hyllytuotteen etu: tuotannossa voidaan olla jopa päivissä, kun taas räätälöidyn ratkaisun kanssa suunnittelu ja toteutus vie aina vähintään viikkoja, usein kuukausia tai jopa vuosia.

Vauhdissa on kuitenkin vaaransakin: Kokonaisvaltaisen liiketoiminnallisen näkemyksen muodostuminen ottaa aikansa. Ketterä kokeileva tekeminen on fiksua, mutta vastuullisuus kärsii, jos kokeilujen elinkaarta ei ole ennalta mietitty. Onko kiireistä kampanjaa varten testikäyttöön otettu markkinoinnin automaatioväline vieläkin testissä, jos sitä on pyöritetty 24 kuukautta? Entä, jos naapuridivisioona teki saman tempun, mutta valitsi eri tuotteen? Ei hätää, kyllä ne kaikki järjestelmät sieltä joskus löytyvät – viimeistään GDPR-auditoinnissa.

Jos kalenteriaika vain antaa myöten, monissa projekteissa kannattaisi ensin tehdä jonkinlainen määrittelyvaihe sillä ajatuksella, että sen pohjalta voisi käynnistää räätälöidyn sovelluskehitysprojektin. Hyvä määrittelytiimi nimittäin ravistaa tehokkaasti organisaatiosta esiin toiveita, reunaehtoja ja prioriteetteja. Voi olla, että räätälöityä ratkaisua ei koskaan kannata oikeasti toteuttaa, mutta suunnitelman kautta löytyneet arvot kantavat liiketoiminnan kehitystä ilman järjestelmiäkin. Kustannuskysymyksenä tätä ei kannata nähdä: On joka tapauksessa halvempaa ideoida ja iteroida alkuvaiheessa paperilla kuin loppumetreillä projektin puristuksessa.

Suunnittelua ei pidä ajatella ketteryyden vastakohtana. Jos jokainen ominaisuus koitetaan määritellä etukäteen, syntyy liiketoimintaa kangistava vesiputousprojekti. Jos vaatimusmäärittelyn tehtävänä onkin haastaa liiketoiminnan omistajia ja tulevan järjestelmän käyttäjiä kertomaan tarpeistaan, syntyy materiaalia ainakin tarjouspyyntöön, projektidokumentaatioon ja käyttöönottokoulutukseen. Parhaassa tapauksessa selvittely ruokkii myös järjestelmäkehityksen tiekarttaa laajemminkin.

”Plans are useless, but planning is indispensable.”

Dwight D. Eisenhower

Muista ei-toiminnalliset näkökulmat

Pelkän toiminnallisen suunnittelun – esimerkiksi käyttötapausluettelon – lisäksi kannattaa miettiä myös sitä, miten sovellus sopii organisaation kokonaispalettiin ja hallintamalliin. Mikä ikinä ratkaisun teknologinen tausta tai tuotteistuksen aste onkin, tärkeitä tarkasteltavia kysymyksiä ovat esimerkiksi seuraavat:

• Montako vuotta sovelluksen oletetaan palvelevan?
• Kun sovellusta tarvitsee muuttaa tai jatkokehittää, millaisella prosessilla ja kustannuksilla se tehdään? Mitä muita sovelluksia tarvitsee tyypillisesti kehittää samalla?
• Onko ratkaisu integroitavissa kohtuukustannuksilla ympäröiviin sovelluksiin? Mikä integraation taso on tarpeellinen?
• Onko ratkaisun tukipalvelu riittävä? Saadaanko sille sovelluksen kriittisyyteen nähden vaadittava palvelutasolupaus?
• Onko ratkaisun hallintamalli harkittu? Miten tietosuoja, tietoturva ja valvonta on huolehdittu?
• Ovatko sovelluksen IPR-asiat kunnossa esimerkiksi toimittajan katoamista ajatellen?
• Entä jos toimittajan liiketoiminnan prioriteetit muuttuvat, ja palvelun saatavuus heikkenee?

Räätälöityjen ratkaisujen riskinä nähdään usein se, että niissä ollaan toimittajan armoilla, ja sovelluksen elinkaaren riskit tuntuvat painavilta. Tämä on tärkeä näkökulma, jota ei kannata unohtaa. Devisioonankin auditointipöydälle saapuu säännöllisesti räätälöityjä ratkaisuja, joissa toimittajasuhteen ontuminen tai peräti katoaminen on aiheuttanut merkittävän liiketoimintakriisin.

Toisaalta samat arkkitehtuurikonsultit päätyvät myös pohtimaan tilanteita, joissa SaaS-tuotteen kehitys onkin kääntynyt asiakkaan kannalta kielteiseen suuntaan, kerran ostetun verkkokaupan tuen jatkumiseksi pitäisi tehdä vaativa versiopäivitysprojekti tai tusinan SaaS-tuotteen yhdistelmä on sementoitunut kehityskelvottomaksi. Siinä missä räätälöityä ratkaisua voi useimmiten tekohengittää melko lineaarisin kustannuksin, tuotteiden kohdalla elinkaaririskit realisoituvat usein jyrkemmin. Esimerkiksi poistuvan tuotteen korvaushankkeen aikataulu on varsin ehdoton, jos taustalla jyskyttää tuen päättyminen. Jos taas liiketoiminnan kehitys tarvitsisi sen ihan pienen lisäominaisuuden jota ei kuitenkaan tuotteeseen saa, ratkaisun vaihtaminen lennossa voi kääntyä veriseksi viidakkoseikkailuksi.

Räätälöinnin ja tuotteen monet kasvot

Osa ongelmaa on yksinkertaisesti se, että puheet ja mielikuvat eivät aina vastaa mitään tiettyä, jaettua todellisuutta. Kun joku puhuu ”räätälöidystä ratkaisusta”, tarkoittaako hän sitä, että valitsee sovelluskehittimestään ”New Project” ja alkaa vääntää tuoreinta ja tulisinta Reactia? Vai ottaako hän ehkä jonkin avoimen lähdekoodin ratkaisukehikon ja rakentaa siihen päälle hieman omaa ulkonäköä ja lisätoiminnallisuutta? Jos näin, kuinka paljon se eroaa vaikkapa tyypillisestä tuotepohjaisesta WordPress-toimituksesta, jota käytännössä aina räätälöidään ainakin vähintään jonkinlaisen teeman verran?

Valmistuoteratkaisuihin liitetty lähtökohtainen nopeus ja notkeus on sitä enemmän totta, mitä vähemmän yrityksellä on järjestelmiä ja mitä lähempänä tuotteen ydinaluetta ollaan. Esimerkiksi vakiintunut brändikieli ja tiedonhallinta, vahvat henkilötietokäytännöt ja keskitetty asiakastelemetrian koontiraportointi ovat kypsän organisaation toimintatapoja, joista jokainen lisää kaikkiin jatkokehitysprojekteihin vähintäänkin integraatiopainetta: Tarvetta olla yhteydessä tietovarastoihin, valvontajärjestelmiin, raportointiin, palveluväyliin ja niin edelleen. Tämä paine ei riipu siitä, ratkaistaanko ongelma tuotteella vai räätälöinnillä, vain ratkaisutavat ja -vastuut vaihtelevat.

Ja lopulta sille itse koodauksellekin on kovin monia abstraktiotasoja. ”Pitkä tavara” viittaa yleensä ohjelmointikieliin ja tyhjästä aloittamiseen, mutta platform as a service -alustat ja avoin lähdekoodi ovat olemassa myös siksi, että räätälöidynkään toteutuksen ei tarvitse lähteä aivan tyhjästä. Usein räätälöityyn ratkaisuun voi toteuttaa joitain osia käyttäen hyväkseen varsin korkean tason ratkaisuja: työnkulkujen kuvaamista esimerkiksi Logic Appeilla, tai mahdollisesti jonkin käyttöliittymän toteuttamista Power Platformin low code -välinein. Jos räätälöinnin nykynäkymä kiinnostaa tarkemmin, vilkaise myös esityksemme aiheesta Cloud1:n Azure-aamussa 25.11.2020.

Hyvä valinta on kaikkien etu

Räätälöityjen ja tuotepohjaisten ratkaisujen – kaikissa eri välimuodoissaan – suhteen tehty oikea, kustannustehokas valinta on kaikkien osapuolten etu. Järjestelmäkäyttöönottoja ei kannata ajatella pistemäisinä projekteina vaan jatkumoina: etsitään suoraan sellainen malli, jossa kehitysnäkymä on olemassa ainakin muutamaksi vuodeksi, mahdollisesti koko elinkaareksi. Pelkkä näiden kysymysten pohtiminen auttaa myös hankelaajuuden hallinnassa: Kun kaiken ei tarvitse mahtua ykkösversioon, käyttöönottoprojektistakin tulee hallittavampi.

Asiakkaan näkökulmasta tärkeimmät kysymykset ovat selkeät: Mitä järjestelmän pitää tehdä nyt ja näkyvissä olevassa lähitulevaisuudessa? Miten sen pitää integroitua muuhun IT-järjestelmäpalettiin? Kuinka paljon kontrollia tarvitsen juuri tämän järjestelmän yksityiskohtiin ja kehittämiseen, ja miten sen parhaiten saan? Siedänkö mieluummin muutamaa isoa järjestelmää ja toimittajaa, vai haluanko monilukuisen joukon pieniä ratkaisuja, joiden välisistä integraatioista vastaan? Vastaukset tulevat harvoin kuin apteekin hyllyltä, mutta huolellinen harkinta ja kohtuullinen selvitystyö maksaa itsensä takaisin yleensä hyvin nopeasti.

Lopulta on hyvä muistaa, että pitkiä elinkaaria suunnitellessa yritysarkkitehtuurin kokonaiskuva tulee joka tapauksessa elämään, ja notkeutta kannattaa miettiä ennalta. Vuonna 2010 pilvipohjaisten sovellusten suosittelu oli vielä varsin rohkea ratkaisu, nyt itsestäänselvyys. Vuonna 2015 oli selvää, että SaaS-tuotteiden huikea yleistyminen vaikuttaa isojenkin yritysten kokonaisarkkitehtuuriin. Näin 2020-luvulla tekisi mieli kirjoitella ennustuksia siitä, miten Microsoftin Dataversen ja Common Data Modelin tapaiset keskitetyt yritystietoratkaisut mullistavat sovelluspaletin universaalilla integroitavuudella, mutta emme ihan vielä uskalla. Palataan asiaan lähivuosina.

Haluatko jutella lisää oman sovellusarkkitehtuurisi suuntaviivoista tai työkaluvalinnoista? Ole yhteyksissä!