Tässä kirjoituksessa käydään läpi keissiä, jossa tehtiin isoa ja vaativaa liiketoiminnan transformaatiota, ja joka vaati täysin uudenlaista kehittämisen tapaa. Projektia kuvastaa teknologinen epävarmuus, organisaation siilojen yhdistäminen, datahaasteet sekä liiketoiminnan ja käyttäjien vahva osallistaminen.
Visiona oli rakentaa ratkaisu, jossa yhdistetään uuden liiketoiminnan myynnin kannalta oleellinen tuotetieto, tilaus- ja toimitustiedot ja myyntimahdollisuudet useasta lähteestä yhdeksi helposti käytettäväksi palveluksi. Tämän palvelun tulisi mahdollistaa asiakasrajapinnassa työskenteleville henkilöille parempi asiakasymmärrys ja kyky tarjota vanhoihin ja uusiin tarpeisiin uudenlaisia tuotteita ja palveluita.
Teoriassa simppeli keissi, mutta kun huomioidaan seuraavat asiat, tilannekuva jäsentyy paremmin:
- Data on lähtökohtaisesti kuraa ja osa siitä vaikeasti teknisesti saatavissa useiden palomuurien takana sisäverkon takanurkassa.
- Data on hyvin moniulotteista ja siitä tulkintojen tekeminen vaatii erilaisten suhteiden ymmärtämistä ja löytämistä.
- Työntekijät eivät ole työssään tottuneet päivittämään tietoja mihinkään keskitettyyn järjestelmään, vaan käyttävät erinäköisiä ja -hajuisia Exceleitä siellä sun täällä
- Liiketoimintatarpeita on vaikea määrittää, koska kyseessä on uutta liiketoimintaa eikä kukaan osaa oikein sanoa miten asioiden pitäisi toimia.
- Organisaatio on tottunut toimimaan teknologisissa siiloissa, eikä integraatiohankkeista ole juurikaan kokemusta.
Hihat ylös ja kädet saveen
Ketterien filosofioiden mukaan olisimme voineet allokoida homman ratkaisemiseen cross-functional kehitystiimin ja lähteä sprint 1:stä koodaamaan ratkaisua. Tämän lähestymistavan ongelma on kuitenkin liialliset alkuoletukset, jotka pahimmillaan voivat johtaa softaprojektien pahimpaan kuolemansyntiin: Rakennetaan maailman paras turha ratkaisu.
Sen sijaan lähestymistavaksi valittiin kevyempi ja kokeilevampi, enemmän riskejä sietävä, hybridi-kehitysmalli, jossa hyödynnettiin mm. Design Thinking, Lean Startup ja Agile-ajattelua.
Kuva 1: Kolmivaiheinen kehitysmalliesimerkki haasteellisimpien liiketoimintaongelmien ratkomiseen
Ensin keskityttiin itse ongelmakenttään ja varmistettiin liiketoiminnan ja käyttäjien tarpeiden riittävä ymmärtäminen ja jäsentäminen. Tämän pohjalta muodostettiin ensimmäinen hypoteesi ratkaisusta, jota lähdettiin validoimaan tekemällä ensimmäinen MVP. Oikeastaan MVP oli enemmänkin kokoelma RATteja (Riskiest Assumption Test), joilla pyrittiin varmistamaan mahdollisimman pienellä työllä toteutuskelpoisuus ja minimoimaan tärkeimmät riskit. Ensimmäinen MVP toimi sekä käyttöliittymäparadigman että arkkitehtuurin ja integrointien validointina. Tarkoituksena oli minimityöllä varmistaa ratkaisun toimivuus, toteutettavuus ja soveltuvuus käyttäjille, sekä kyetä arvioimaan paremmin edessä olevan työn määrä.
Projektimallista vielä sen verran, että homma perustui täysin luottamukseen ja läpinäkyvyyteen asiakkaan ja toimittajan välillä. Haluttiin ratkaista yhdessä ongelmaa samalla puolella pöytää. Näin ollen oli selvää, että jos tulee esiin projektin kannalta show-stoppereita tai homma ei vain jostain muusta syystä toimi, asiakas voi antaa meille kenkää välittömästi.
Pureutumista käyttötapauksiin
Validoitavien RATien lisäksi yksi ensimmäisistä vaiheista oli pureutua ongelmakenttään ja pyrkiä jäsentämään pari ensimmäistä tärkeintä käyttötapausta, joita vasten palvelua voisi alkaa hahmottaa. Tässä muutamia esimerkkejä:
Palvelun pitäisi tukea määriteltyjä palvelumyynnin käyttötapauksia, kuten:
- Haluan tiedon kaikista asiakkaista, joilla on asennettuna tietty laitekokoonpano 3-5 vuoden sisällä ja joihin ei ole vielä toimitettu modernisointipalvelua
- Haluan tietää kaikki palvelutuotteet, joita on mahdollista myydä asiakkaalle X liittyen viimeisen 10-20 vuoden aikana toimitettuihin kokonaisiin laitoksiin, laitteisiin tai niiden osiin.
Lisäksi palvelun tulisi olla riittävän joustava, että sillä voisi ratkoa myös vastaavia ja syvempää analyysia vaativia käyttötapauksia, kuten:
- Perustuen asiakkaiden ostohistoriaan, mitkä ovat potentiaalisimmat ja hyväkatteisimmat palvelutuotteet, joita markkina-alueella X voidaan seuraavan vuoden aikana myydä.
Muita vaatimuksia:
- Palvelun tulisi olla helppokäyttöinen ja suoraviivainen, mutta samalla riittävän joustava tukemaan monipuolisempia käyttöskenaarioita
- Palvelun tulee toimia myös kokonaisvaltaisena näyteikkunana dataan ja datan laatuun
- Palvelun tulee tuottaa vastauksia nopeasti missä päin maailmaa tahansa
Joustava hybridikäyttöliittymä
Johtuen hieman ristiriitaisistakin käyttäjätarpeista ja eritoten analytiikkatarpeista, palvelun käyttöliittymä päätettiin rakentaa hybridiksi yhdistäen tärkeimpiin käyttötapauksiin optimoidun räätälöidyn web-applikaation ja joustavuutta sekä analytiikkavoimaa tuovan Power BI -raportointipalvelun.
Minimilähestymistapa edellytti kuitenkin, että käyttöliittymää ei vielä lähdetty ensimmäisessä MVP:ssä koodaamaan. Sen sijaan käyttöliittymästä rakennettiin käyttäjillä validoitava visio tekemällä kliksuteltava prototyyppi ja tueksi määriteltiin käyttöliittymäparadigman keskeiset ajatukset. Samalla muodostui näkemys Power BI:n ja web-palvelun yhteistoiminnasta, jotka käytännössä toteutuivat raporttiupotuksin ja suorin linkein web-palvelusta filtteröityihin täsmäraporttinäkymiin.
Käyttöliittymävisiota validoitiin ensimmäisen kerran käyttäjien kesken MVP:n jälkeen ja muutaman toteutussprintin jälkeen saatiin jo ensimmäiset käyttökokemukset itse web-palvelusta ja raporteista. Jatkokehitystä priorisoitiin havaintojen myötä aina keskittyen vain tärkeimpiin osiin. Pikseliviimeistelty käyttöliittymä rakennettiin vasta usean sprintin jälkeen, jolloin olimme jo varmoja, että kaikki palvelun kriittiset riskit ja osa-alueet on taklattu.
Käyttöliittymän suunnittelussa ja toteutuksessa tärkeintä oli välttää tekemästä yksittäisiä täsmäratkaisuja. Sen sijaan rakennettiin yleiskäyttöisiä ja joustavia käyttöliittymäkomponentteja, joita voitiin helposti ottaa käyttöön eri osissa palvelua. Näin pystyttiin pienemmällä työllä rakentamaan käyttöliittymä, joka joustaa laajemminkin organisaation tarpeisiin, myös sellaisiin, joita ei vielä suunnitteluvaiheessa ollut tiedossa.
Data-arkkitehtuuri
Tekninen arkkitehtuuri validoitiin ensimmäisessä vaiheessa vielä lähdejärjestelmien kehitysympäristöjä vasten. Rakennettiin ensimmäinen versio data patformista, johon tiedot tuotiin APIen kautta tärkeimmistä lähdejärjestelmistä. Validointina toimi tässä vaiheessa vielä Postman-työkalu, jonka avulla voitiin tehdä REST-hakuja data platformiin, johon tiedot taas oli tuotu lähdejärjestelmistä. Ruma, mutta toimiva MVP:n hengessä toteutettu ratkaisu.
Data-puolen ratkaisuksi otettiin joustava Azure CosmosDB ja Data Lake (alkuperäinen BLOB-ratkaisu konvertoitiin projektin aikana Data Lakeksi), joihin synkronoitiin kaikki oleellinen tieto JSON-muodossa lähdejärjestelmistä. JSON muoto valittiin siksi että tietorakenne on relaatiokantaa joustavampi ja näin lähdejärjestelmistä voitiin tuoda huoletta kaikki tieto rakenteesta riippumatta. Tiedon suuresta määrästä ja CosmosDB:n rajoituksista johtuen osa datasta piti tallentaa Data Lakeen.
Data platformista tiedot luettiin API Management -kerroksen läpi sekä web-applikaatioon että Power BI:hin. APIt suunniteltiin niin, että web palvelulle pystyttiin tarjoamaan valmiita yhdistettyjä tietorakenteita käyttöliittymän ja kehityksen nopeuttamiseksi. Power BI taas luki sisään tiedot alemman tason API-palveluista ja yhdisti ne vasta omassa datamallissaan raportoinnin tarvittavaan muotoon.
APIen lisäksi Power BI yhdistettiin Data Warehouseen, jotta keskeisimpiin data entiteetteihin saatiin mukaan historiadataa syvempiä analyysejä, kuten trendianalyysejä varten.
Datan laatu
Samaan aikaan projektin teknisen toteutuksen kanssa alkoi datan laadun parantamisen toimenpiteet. Kenttätyöprosessien tiedonsyöttövaateet formalisoitiin ja tueksi rakennettiin Power BI:llä datan laadun KPI-mittarit trendikäyrineen. Alussa kaikki mittarit olivat punaisella, mutta vaihe vaiheelta datan laatu alkoi parantua.
Palveluun rakennettiin myös palautekanava, jonka avulla virheellisen tiedon pystyi helposti korjaamaan. Tämä sitoutti osaltaan myös käyttäjiä laadun parantamiseen. Yksinkertaisuudessaan datan laadun parantamisen kaava on:
- Totea, että nykytila on surkea
- Mallinna uusi prosessi käyttäjien kanssa
- Jalkauta
- Seuraa ja jaa KPI-mittareita
- Tarjoa hyvä näkyvyys dataan ja tehokas palautekanava
Järjestelmä osaksi käyttäjän arkea
Koska kyseessä oli liiketoiminnan kehittämishanke, eikä pelkkä tekninen harjoitus, tavoitteena oli saada käyttäjän arki muuttumaan positiivisesti. Tästä syystä käyttäjät otettiin mukaan jo hyvin aikaisessa vaiheessa suunnittelemaan palvelua. Palvelua kehitettiin myös hyvin läpinäkyvästi tuoden alustavia ominaisuuksia beta-käyttäjätestiin ennen niiden viimeistelyä.
Palvelun käytön tueksi perustettiin myös useita tukevia ratkaisuja Microsoftin teknologiapakasta:
- Yammer-kanava tiedotuskanavaksi ja käyttäjien kanssa keskusteluun
- SharePoint communication site ohjeita ja jaettavia dokumentteja varten
- Forms lomake ja Logic Apps -työnkulkuja uusien käyttäjien pyyntöihin ja provisiointeihin
- Teams-kanava nopeaan työnkulkujen kanssa kommunikointiin (esim. luvitusten myöntäminen)
- Power BI raporttiembeddaus viestintäsivustolle ja käyttäjästatistiikan näyttäminen kaikille Azuren Application Insights -logista
- Stream screencasteja toimintojen lyhyitä esittelyjä ja pidempiä palveluesityksiä varten
Teknologiaa tärkeämpää oli kuitenkin käyttäjien aito huomioiminen ja positiviisen vireen rakentaminen palvelun ympärille. Koko projektiryhmä kehittäjiä ja data experttejä myöten oli suorassa yhteydessä käyttäjiin Yammerin kautta. Turhia viestinkantajarooleja tai proxyjä ei tarvittu. Havaitut bugit korjattiin usein seuraavaan päivään mennessä ja tämä loi positiivista osallistuvuutta käyttäjien joukossa.
Sitoutunutta käyttäjäporukkaa on helpompi kouluttaa. Koulutuksia järjestettiinkin, mutta niiden rooli jalkauttamisessa oli vähäinen. Sen sijaan tehtiin useita lyhyitä webcasteja itse tekijöiden toimesta ja näitä jaettiin sekä Yammerissa että viestintäsivustolla. Lisäksi käyttäjien tuettiin Yammerin kautta, sähköpostilla tai Teamsissa.
Todellinen digitaalisen data-vetoisen organisaation järjestelmällinen muutos ei kuitenkaan synny vain sisäisellä motivaatiolla ja kannustamisella. On rakennettava ylätason strategia ja tarkat toimintamallit sen viemiseksi käytäntöön. Ei riitä, että osa käyttäjistä alkaa toimimaan toivotulla tavalla. Kaikkien on hyväksyttävä uusi toimintamalli tai muuten edessä on taas kuraista dataa. Onneksi työntekijät ovat lähes poikkeuksetta järkipohjaista porukkaa ja hyvin valmistellut muutokset on ilman ongelmia läpivietävissä käyttäjän arkeen. Tyypillisin haaste onkin käyttäjän ja työntekijän aliarvioiminen ja sitä kautta heidän unohtaminen muutosprosessista.