Yritysten ohjelmiston hankkiminen ja toimittaminen voi joskus tuntua hankalalta. Olen työvuosieni aikana tarkastellut asiaa eri puolilta: toimittajana, tilaajana ja konsernin sisäisenä toimittajana. Tällä hetkellä toimin edelleen säännöllisesti kaikkien näiden tahojen kanssa ja ongelmat tuntuvat pysyvän samoina, vaikka teknologia kehittyy.
Tilaajana sopivaa tuotetta ei tunnu löytyvän, tai sopivat ovat liian laajoja ja kalliita. Yleistä on myös, että ongelman ratkaisee useampi tuote yhdessä, mutta ei mikään yksin. Yksi on toisaalla parempi kuin toinen, mutta kumpikaan ei ratkaise kaikkea. Tähän voi jokainen samaistua; sopivaa kanavapakettia ei löydy, kamera olisi muuten hyvä, mutta… Täydellistä sopivuutta ei tunnu löytyvän, mikäli tuotetta ei pääse itse muokkaamaan. Tämänkin toki onnistuu, kunhan on valmis maksamaan. Toimittaja taas saattaa vastata toiminnoista esitettyihin kysymyksiin epäilyttävin reunaehdoin (jos aidosti yrittää välttää myöhempiä ongelmia), tai lupaa ihan kaiken. Yhteisten sanojen löytäminen on vaikeaa. Tilaajan kannalta jokainen uusi hankinta on henkilökohtainen riski ja on siksi luontaista pyrkiä minimoimaan hankintojen määrä. Tarpeiden yhdistäminen lisää toisaalta yksittäisen ohjelmiston riskiä laajana kokonaisuutena.
Toimittajan puolelta joskus tuntuu, että kysytään taikalaatikkoa, mikä tekee mitä vain vakiona. Selkeimmin tämä nousee esiin RFI (Request for Information) ja RFP (Request for Proposal) kyselyissä. RFI/RFP tiedusteluissa on melko usein myös nimetty valmiiksi tietty tuote/käsite minkä puitteissa asiat pitäisi ratkaista. Formaali rivimäinen ominaisuuksien kysely on toisaalta hyvä tapa käsitellä laajaa toimittajajoukkoa, mutta voi myös johtaa umpikujaan sanojen väärinkäsitysten tai myöhemmin ilmenevien haasteiden vuoksi ja kokonaisuuden kadotessa. Tilaajan kannalta yhden virkkeen kysymys ”onko tuotteessa ominaisuus x?” voi olla selvä, mutta ohjelmiston toimittajan kannalta vastaukseen voi vaikuttaa kymmeniä muita kysymyksiä ja päätöksiä. On todella vaikea vastata yksinkertaisen näköiseen, mutta sisältä monimutkaiseen kysymykseen yksinkertaisesti ilman että syntyy mahdollisuus merkittävään väärinkäsitykseen. Vuosien aikana on eteen tullut lukuisia tapauksia, missä hankalimmat ongelmat piilevät juuri noissa yksityiskohdissa (data, prosessi, sanat ja niiden merkitys).
Sisäisen toimittajan (IT, tai muu palvelua tuottava toiminto) haasteet ovat toisaalla. Budjetti, henkilöstön saatavuus, ylläpitovaatimukset, osaaminen, integraatiot, muiden töiden aikataulu, tai kokonaisarkkitehtuurin hallinta. Rooliin kuuluu lähes aina mielikuva jarruttajasta ja esteestä, mikä on harmillista. Itse en liiketoiminta-arkkitehtina tietoisesti pyrkinyt jarruttamaan, vaan saamaan aikaan toimivan kokonaisuuden. Tämä vain ei usein välity muulle organisaatiolle; palvelun tilaajan keskittyessä businesshaasteeseensa ja toimittajan pyrkiessä toimittamaan. Kun IT on kiinteä osa yrityksen strategiaa ja mukana määrittelemässä tavoitteita voi välttää monia haasteita järjestelmien kehityksessä ja sisäisessä kommunikoinnissa. Huonoimmillaan, eli ollessaan täysin irrallinen toimija on IT:lle loogisinta minimoida järjestelmien ja oman riskin määrä.
Suuri osa ohjelmista on alun perin tehty jotakin tiettyä tarkoitusta varten. Jos toimitus onnistuu, on luonnollista, että tuotosta sovelletaan toisaalle, jolloin siitä alkaa muodostua tuote. Ongelmia alkaa syntyä soveltamisen reunoilla, jossa jokin ohjelmiston sovellustapa alkaa olla liian kaukana sen perusperiaatteesta. Vuosien varrella olen törmännyt Excelillä tehtyihin konepiirustuksiin ja työajanseurantajärjestelmällä ohjattuihin vannesahoihin. Nyt näitä tilanteen aikanaan sanelemia kummallisuuksia koitetaan purkaa. Ohjelmistot ovat usein kehitettyjä ratkaisemaan tietty ongelma, ei saavuttamaan laajempi tavoite. Ongelma on usein rajatumpi kuin tavoite. Ohjelmistot perustuvat usein alkuperäiseen tietomalliin, joka rajoitteineen sallii luovaa käyttöä vain tiettyyn pisteeseen asti.
Ohjelmistojen tietomallin haaste on usein organisaatio mihin ohjelmisto on alkujaan tehty. Organisaatiorakenne muovaa usein merkittävästi tarvittavaa prosessia sekä tietomallia ja siten ohjelmiston perustoimintatapaa. Ongelma on havaittu jo niinkin aikaisin kuin 1967, jolloin muotoiltiin Conwayn laki.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin E. Conway
Kehitetyt ohjelmat siis muistuttavat niitä kehittämishetkellä käyttäneen ja kehittäneen organisaation kommunikointimallia. Tämä voi toteutua kahdella tasolla, ohjelmiston kehityksessä ja itse toiminnoissa mitä ohjelmalla toteutetaan. Ohjelmistojen puutteet ja kummallisuuden siis juontavat usein juurensa ensimmäiseen niitä kehittävään ja käyttävään organisaatioon. Ohjelmiston kehittäjäorganisaation oma organisoituminen, jopa yksittäiset osaamisen keskittymät voivat vaikuttaa logiikkaan millä kokonaisuus toimii.
Vuosia erilaisissa yrityksissä projekteja tehneenä olen huomannut, että on todella vähän täysin identtisiä organisaatiota – edes yhden konsernin sisällä. Tekemisen rajapinnat/kättelyt siis siirtyvät ja mahdollisesti alkavat jakaa jotain oleellista tietoa eri tavoin kuin toisessa organisaatiossa. Esimerkkinä voisi mainita, vaikka ERP järjestelmät mitkä usein toimivat pääosin organisaatiofunktioiden siiloina: osto, myynti, tuotanto jne. Yhteistyö funktioiden välillä on jäykkää, tai olematonta. Syy voi olla se, että ensimmäinen organisaatio mihin ohjelmisto on suunniteltu, ei sitä tarvinnut, tai kokonaisuus on kehitetty toiminto kerrallaan eri aikakausina. Esimerkiksi lähtevä logistiikka voi olla jossain ERP:ssä myynnin alla, mikä on outoa yrityksessä missä logistiikka sitä hoitaa, palautus taas tehdään jossain ihan muualla. Laatu on toinen hyvä esimerkki. En ole nähnyt montaa identtistä tapaa hoitaa laatua eri organisaatiossa. Erillinen laatuohjelma ei palvele ylipäätään koko toiminnan sisälle leivottua kyvykkyyttä laadun käsittelyyn, mutta valitun ohjelmiston ensimmäisellä asiakkaalla on voinut olla erillinen laatuosasto, jota erillinen laatuohjelma on palvellut hyvin. Joskus ERP projekteissa törmää tilanteeseen missä on helpompi muokata organisaatiota kuin tuotetta.
Voisiko ohjelmiston ostamista helpottamaan tehty tuotteistus tässä tapauksessa aiheuttaa ongelmia? Tuotteistuksen idea on rajata mahdollisuuksia, jotta rajattu joukko toimintoja toimii hyvin ja luotettavasti. Täysin räätälöity auto ei ole yhtä luotettava kuin sarjavalmiste, eli siinä tuotteistuksen tavoite toteutuu. Miksi sitten ohjelmistoissa samasta hyvästä mallista voi olla joskus haittaa? Osa ongelmaa voi olla tuotteistuksen väärässä tasossa ja vastaavasti vaatimusten pilkkoutumisessa. Esimerkiksi autoa ostaessa ostaja tietää mitä tarvetta autolla ratkaisee, ja valitsee tarpeeseen sopivimman tuotteen, eli tietyn auton. Ohjelmiston kanssa ei sen sijaan pitäisi ostaa tuotetta vaan työkaluja saavuttaa tavoite. Koska ongelmia ja toimintoja on lukematon määrä, ei voi olla kaikkeen sopivaa tuotetta. Jos ohjelmistoa ostetaan kuten autoa oletetaan, että kaikki ohjelmistot toimivat kuten oma käsitys tuotteesta on muodostunut.
Tästä päästään aikaisempaan Conwayn lakiin, mikä oikeastaan kertoo miksi näin ei ole, vaan ensimmäinen käyttötarkoitus ja kehittäjä usein ohjaa koko tuotetta johonkin tiettyyn suuntaan ja logiikkaan. Päädytään siis vertaamaan omenoita appelsiineihin, vaikka kauempaa tarkasteltuna kaikki toteuttaisivat samaa asiaa, mutta eri tavoin organisoituneena. Auto esimerkissä tarve olisi jonkinlainen tarve liikkumiselle. Jos ominaisuuden siis muotoilee tavoitteeksi, tai kyvykkyydeksi hiukan kauemmasta perspektiivistä voi asialle olla useita erilaisia ratkaisuja ja siten myös erilaisia tuotteita. Liikkumisesimerkissä ostaja on jo rajannut kaikki muut vaihtoehdot kuin auton pois. Ohjelmistojen tuotteistus on siis mahdollisesti liian korkealla tasolla (tai alhaisella, riippuen näkökulmasta) ja aiheuttaa sopivuusongelmia alkuperäisen asiakasryhmän ulkopuolella.
Oma mausteensa aiheeseen on sykleinä muuttuva tavoite keskittää ja vuoroin hajauttaa arkkitehtuuria. Nykyisessä mahdollisuuksien maailmassa on lähes mahdotonta saada kaikki tavoitteet katettua yhdellä tuotteella. Oli se sitten mikä tahansa.
Usein yritysten strategiset tavoitteet ovat paljon yksittäisiä tuotteita ja niiden ominaisuuksia ylemmällä käsitteellisellä tasolla. Yritys voi tavoitella jäljitettävyyttä toimitusketjussa, laadun varmistusta, konfiguroitavaa tuotetta, vastuullisuutta, tehokkuutta tai muuta yrityksen mittaustasolla olevaa etua. Strateginen tavoite on käsitteenä lähempänä yrityksen kykyä (cabability) tehdä asioita, kuin jotain yksittäisen funktion (logistiikka, tuotanto, laatu, yms.) ominaisuutta millä osatavoite ehkä saadaan katettua. Tavoite usein kuitenkin muuttuu projektiksi/haasteiksi yrityksen funktiolle, mikä on siis jo vaikuttunut oman organisaation mallista kommunikoida ja toimia. Jos tällainen tunnistettu ongelma on myös muuttunut käsitykseksi mikä tuote ongelmaa ratkaisee, on kädet jo osin sidottu ratkaisun suhteen.
Tavoitteen delegoituessa yrityksen toimintoihin ratkaisee jokainen toiminto asiaa erillisenä ongelmana ja siten myös omana projektinaan, mihin tuote sopii tai on sopimatta. Myynnissä esimerkiksi vastuullisuus ratkaistaan web sivulle laitetulla päästöjen kompensointinapilla, logistiikassa pienellä roskalaatikolla, tai ei ratkaista lainkaan, mikä ei vastaa yrityksen alkuperäistä tavoitetta yrityksen toimitusketjun vastuullisuudesta. Ei ole lainkaan harvinaista, että asiakas tiedustelee ratkaisua tiettyyn rajattuun ongelmaan. Kun varsinaista tavoitetta ongelman takana laajemmin tutkitaan, selviää että koko haastetta ei ole, jos kokonaisprosessia muutetaan.
Harvalla yrityksellä on johdon tavoitteissa jokin tietty ohjelmistotuote ilman ajatusta mitä sillä ratkaistaan. Jos ohjelmisto ei ratkaise yrityksen liiketoiminnallista tarvetta miksi sitä ylipäätään tavoiteltaisiin. Linkki strategiaan on joskus vaikea muotoilla yksinkertaisesti, mutta jostain sen on syytä löytyä tai tehdään asioita mitkä eivät edistä yritystä kasvavassa kilpailussa. Syy ei aina liity suoraan rahaan. Tavoite voi olla esimerkiksi henkilöstötyytyväisyys, mikä vaikuttaa vaihtuvuuteen, mikä vaikuttaa tulokseen ja laatuun.
On siis paljon tekijöitä mitkä yhdessä tekevät ohjelmistohankkeista hankalia tai ne joskus jopa epäonnistuvat kansallisen uutiskynnyksen ylittävällä tavalla. Useimmiten asiat lähtisivät selviämään, jos tilaajat ja toimittajat puhuisivat paremmin samaa kieltä termien ja käsitteiden suhteen. Käsitteiden tasojen väärinymmärrys, liika yksinkertaistaminen ja oikominen vaikeissa kysymyksissä on aika varmoja keinoja saada vaikeuksia.
Tilaajan ymmärryksen lisääminen omasta prosessista ja varsinaisesta tavoitteesta selkeyttä hankintaa ja toimitusta. Siihen kokonaisarkkitehtuurilla on paljon annettavaa. Ohjelmistotoimittajan panostaminen oikeaan tuotteistuksen tasoon ja asiakasymmärrykseen helpottaa merkittävästi keskustelua asiakkaan kanssa. Keinoja ohjelmistotoimituksen sujuvuuden parantamiseen on paljonkin, mutta niihin palataan toisessa blogissa.
Kirjoittaja:
Pekka Saarelainen
CPO
Leanware Oy
