Search
Reflector Heli
Liiketoiminnan ja IT:n yhteensovittaminen on saavutettavissa

Onnistuvatko yritykset IT-hankkeissaan tänään paremmin kuin 20 vuotta sitten? Tukeeko IT nyt paremmin liiketoimintaa kuin vuosituhannen taitteessa? Meneekö kehitysprojekteista edelleen yli puolet metsään?

Liiketoiminnan ja IT:n integraatiosta on käyty vilkasta keskustelua jo vuosikymmeniä. 2000-luvun alussa kuilu liiketoiminnan ja IT:n välillä näytti uraansa aloittelevan konsultin silmin lähes ylittämättömältä: IT-osasto keskittyi liiketoiminnan mielestä epärelevanttiin kehittämiseen ja toimi epätehokkaasti. IT-osastolla puolestaan tuskailtiin sitä, miten liiketoiminnan päättäjät eivät ymmärrä IT:n roolia strategian mahdollistajana. Budjetointivaiheessa kauhisteltiin valtavia IT-kustannuksia, kunnes se tuomittiin tukifunktioksi ja määrättiin kulukuurille.

Liiketoiminta ja IT ovat lähentyneet toisiaan ainakin ketterissä malleissa

Havahduin pohtimaan liiketoiminnan ja IT:n yhteensovittamisen ajankohtaisuutta – vieläkö liiketoiminnan ja IT:n strateginen yhteensovittaminen on ongelma vai ovatko ne jo sopusoinnussa keskenään? Tein tästä pienimuotoisen LinkedIn-kyselyn, jonka tulokset olivat selvät: ongelma on edelleen olemassa.

Yllätyin kyselyn tuloksesta, koska omassa IT-kehityskuplassani tuntuu siltä, että IT:n ja liiketoiminnan strateginen yhteensovittaminen on itsestään selvää ja kaikki kehityksen kanssa tekemisissä olevat pyrkivät sitä omalla toiminnallaan edistämään. Organisaatioiden konkreettisissa toimintamalleissakin on tehty hyppyjä liiketoiminnan ja IT:n yhdistämisen suuntaan, yhtenä esimerkkinä vaikkapa ketterän kehityksen poikkifunktionaaliset tiimit, joissa on mukana liiketoiminnan ja IT:n edustajien lisäksi muutkin kehittämisen kannalta oleelliset funktiot. Ketterissä tiimeissä raja-aidat ovat kadonneet.

Toinen esimerkki business-IT -integraation toteuttamisesta käytännössä on se, että esimerkiksi Verkkokauppa.com uutisoi hiljattain yhdistäneensä teknologia- ja strategiajohtajan tehtävät samalle henkilölle. 2000-luvun alussa ei ollut itsestään selvää, että tietohallintojohtajalle oli paikkaa yrityksen johtoryhmässä ”tukifunktion” edustajana. Joissakin organisaatiossa IT:n strateginen rooli tunnistettiin jo toki silloinkin. Nyt digitalisaation uuden aallon, generatiivisen tekoälyn, nosteessa tietohallintojohtajan tai digijohtajan rooli strategian mahdollistajana tunnustetaan vihdoin varmasti kaikkialla.

Liiketoiminnan ja IT:n strategiseen yhteistyöhön on olemassa konkreettisia apukeinoja

LinkedIn-kyselyn tuloksista motivoituneena olen pyrkinyt tietoisesti omasta ketterästä kuplastani ulos ja yrittänyt päästä keskustelemaan sellaisten henkilöiden kanssa, joiden elämän pääsisältö ei ole ketterä kehittäminen. Nämä henkilöt joutuvat valitettavasti edelleen kohtaamaan IT:n ja liiketoiminnan välisen vastakkainasettelun.

Näissä keskusteluissa olen oppinut, että liiketoiminnan ja IT:n yhteensovittamista estävät edelleen yhteisen ymmärryksen puute, eriävät toimintatavat budjetoinnissa ja suunnittelussa, sekä tekniset haasteet.

1. Yhteisen ymmärryksen puute

Yhteisen kielen puute

IT-osaaja, kuten ohjelmistokehittäjä ja liiketoiminnan tai operatiivisen tason ammattilainen, kuten teollisuuden laiteasiantuntija, eivät välttämättä jaa samaa sanastoa digimuutoksen ja kehittämisen tarpeista keskustelemiseen. Molemmilla on oma ammattisanastonsa ja slanginsa sekä oma mallinsa tulkita maailmaa. Yhteisen kielen puute voi aiheuttaa suuria haasteita, eikä välttämättä ole aikaa arjen kiireissä sitä opetella. Tämän vuoksi tarvitaan “rajapintaihmisiä” eli tulkkeja, jotka osaavat kääntää alan termistön niin, että se on toiselle osapuolelle helpompi ymmärtää. Organisaatioiden tehostamisen nimissä voi tuntua siltä, että tällaiset roolit ovat turhia, eikä niitä tarvita. Tulkeista säästämällä voi kuitenkin tehdä organisaation kehitykselle karhunpalveluksen.

Yhteisen kontekstin puute

IT-ihmiset eivät voi täysin ymmärtää digikehittämiseen liittyviä tarpeita, jos he eivät ymmärrä kattavasti, mihin kaikkiin asioihin kehityshanke liittyy. Tämän vuoksi keskitetty IT ja jaetut resurssit voi olla haastavampi tapa organisoitua, jos tässä mallissa IT-osaajalla ei ole mahdollisuutta tutustua kunnolla esimerkiksi operatiivisiin prosesseihin ja loppuasiakkaan tarpeisiin ja samalla kasvattaa omaa liiketoiminnallista ymmärrystään.

IT:n osittainen hajauttaminen liiketoiminta-alueille voi helpottaa osapuolten keskinäistä ymmärrystä, kun vastinparit liiketoiminnan ja IT:n puolella pysyvät pidemmän aikaa samoina. Samalla IT-kehittäjät oppivat ymmärtämään syvällisesti liiketoiminnan kontekstin ja liiketoiminta puolestaan IT:n käyttämää kieltä.

Asenteet

Jos ei ole halua ymmärtää, ei yhteisestä tekemisestä tule mitään. Täytyy olla kärsivällisyyttä ja osaamista selittää tavoitteita, näkemyksiä ja suunnitelmia niin, että ne ovat helposti omaksuttavissa ja kommentoitavissa – välttäen oman alan erikoistermistöä. Meillä kaikilla pitäisi olla halua ja kykyä nähdä asioita ja toimia ilman IT:n ja liiketoiminnan välille pystytettyä raja-aitaa.

2. Näkemyserot budjetoinnista ja aikaperspektiivistä

Kehittämisen kustannusten ennustaminen suhteessa tavoitteisiin

Liiketoiminta asettaa budjetit ja tavoitteet yleensä vuodeksi kerrallaan ja strategia määritellään 3-5 vuoden jaksoissa. Tehdylle investoinnille odotetaan tiettyjen hyötyjen toteutumista, joka taas vaatii kehittämisen sisällön määrittelyä vähintään vuodeksi kerrallaan.

IT ja kehitysorganisaatio näkevät puolestaan ajan esimerkiksi sprintteinä, projekteina ja hankkeina. Ketterissä malleissa kantava ajatus on, että sisältö määritellään tarkasti vasta lähempänä toteutushetkeä turhan työn ja epärealististen odotusten välttämiseksi, koska vaatimukset muuttuvat ja työn edetessä asiasta opitaan uutta. Tämä lähtökohtaisesti erilainen suhtautuminen suunnittelun aikajänteeseen saattaa hiertää IT:n ja liiketoiminnan yhteistoimintaa.

Kuka maksaa ja kuka päättää?

Toinen kipeä keskustelunaihe budjetointiin liittyen on se, kuka omistaa kehittämisbudjetin? Keneltä raha tulee ja kuka sen käyttää? Jos rahan omistaja on liiketoimintayksikkö, joka maksaa IT-yksikölle kehitysprojektin toteutuksesta, syntyy helposti näkemyseroja siitä, onko raha käytetty fiksusti vai ei. Onko tehty oikeita asioita tarpeeksi tehokkaasti? Tähänkin voi vaikuttaa erilaisilla organisoitumismalleilla, joissa budjetti on sillä taholla, joka tietää, mitä pitää tehdä ja myös tekee itse kehittämistä.

3. Tekniset haasteet

Teknisen ympäristön monimutkaisuus ja historialliset kerrokset

Lähtökohtaisesti liiketoiminnan ei pitäisi huolehtia IT-arkkitehtuurin monimutkaisuudesta, mutta käytännössä tämä on usein kehittämisen pullonkaula, josta kaikkien pitäisi olla tietoisia.

Kehittäminen on monimutkaista silloin, kun taustalla on vanhat perinteiset järjestelmät eli “legacy” ja sen päälle vuosien saatossa kerrostunut kunkin ajanjakson uusinta teknologiaa. Pahimmassa tapauksessa kunkin eri aikakauden teknologioita ei ole saatu hyödynnettyä kunnolla, kun seuraava aalto on jo tuonut päälle uuden tavan tehdä asioita. Tämä ilmenee vaikkapa integraatiokehittämisessä, jossa erilaisia ratkaisuja tuodaan muutaman vuoden välein, mutta vanhatkin ratkaisut jäävät ylläpidettäviksi. Myös liiketoiminnan olisi hyvä olla tietoinen kehittämisen pullonkauloista, ettei luultaisi kehityksen hitauden johtuvan IT-organisaation haluttomuudesta tai jopa kyvyttömyydestä tehdä muutoksia.

Ketterä spagetti: Toinen esimerkki teknisistä haasteista on pilvimaailmaan syntyvät uudet ja ketterät ratkaisut, joita tarjotaan loppuasiakkaalle. Näitä syntyy, kun loppuasiakkaan tarpeeseen halutaan vastata mahdollisimman nopeasti mm. kilpailutilanteen vuoksi, ja mikään olemassa olevista järjestelmistä ei taivu tarpeeksi nopeasti tarpeen toteuttamiseen. Tällaisia pikaratkaisujakin toteuttaessa pitäisi miettiä ratkaisujen elinkaarta, dokumentointia tai ylläpidettävyyttä, eikä pelkästään tarvetta saada nopeasti hetkellinen asiakastarve tyydytettyä. Väliaikaiseksi tarkoitetusta pilottiratkaisusta tulee helposti pysyvä.

Yritysarkkitehtimme Henri Sintonen on nimennyt tämän ’Agile Spaghetti’ -ongelmaksi: tehdään samat virheet kuin aiemminkin, mutta uusilla teknologioilla. Ajan saatossa kerääntynyt ketterä spagetti hidastaa muutosvauhtia. Päädytään noidankehään, jossa tekniset haasteet pahenevat nopeasti, pitkäjänteisen parantumisen sijaan.

Jokainen voi tehdä jotain liiketoiminnan ja IT:n strategisen yhteensovittamisen eteen

Jos liiketoiminnan ja IT:n yhteistyössä on omassa organisaatiossa mielestäsi parantamisen varaa, kokeile aloittaa näistä asioista:

1. Yhteinen ymmärrys

Tarkastele kriittisesti organisoitumista: tarjoaako yrityksen rakenne mahdollisuuden IT:lle ja kehittämisen asiantuntijoille muodostaa yhteinen ymmärrys kehittämisen liiketoiminnallisista ja asiakaslähtöisistä tarpeista? Jos keskitettyä IT-/kehittämisosastoa ei ole ajankohtaista myllätä, auttaisiko tulkkien käyttäminen?

2. Budjetointi

Pohdi, onko organisaatiossanne yhtenäinen käsitys siitä, mikä nurkka projektinhallinnan kultaisesta kolmiosta joustaa, jos kaikki ei mene suunnitelman mukaisesti: aikataulu, budjetti vai sisältö? Jonkin pitää joustaa, kun odottamattomia asioita tapahtuu.

Useimmissa organisaatioissa tosiasia on, että vuosibudjetti ei voi joustaa esimerkiksi osakeyhtiöiden tiedonantovelvoitteesta, omistajien tulosodotuksista tai rahoitustilanteesta johtuen. Ainoa mahdollisuus on siis joustaa projektin sisällöstä. On päästettävä irti vaatimuksesta, että budjetointivaiheessa ja investointipäätöstä tehtäessä tiedettäisiin hyvin tarkalla tasolla, mitä investoinnilla saa. Sen sijaan on luotettava kehitysorganisaation ihmisten kykyyn tietää, miten budjetti käytetään mahdollisimman hyödyllisesti niin, että saadaan valmiiksi mahdollisimman hyvin tarpeet täyttävä MVP, Minimum Viable Product.

Tämä vaatii sitä, että asiakkaan tai loppukäyttäjän muuttuvia tarpeita seurataan tarkasti kehityksen aikana: mikä on ehdottoman tärkeää sisällyttää toiminnallisuuteen tai tuotteeseen ja minkä voi jättää tekemättä? Voit päästä alkuun analysoimalla, onko kehitysorganisaatiossa tarvittava kyky tehdä päätöksiä? Jos ei, miten osaamista voisi lisätä? Jos on, onko muulla organisaatiolla – myös johdolla – luottamusta päästää irti sisällön kontrolloinnista ja antaa vastuu kehittämisorganisaatiolle?

3. Tekniset haasteet

Ymmärtävätkö kaikki, myös liiketoiminta, organisaation teknisen ympäristön ongelmat ja syyt, miksi uusien toiminnallisuuksien rakentaminen on monimutkaista ja aikaa vievää? Jos yhteinen ymmärrys löytyy, organisaation tilanteen parantamiseksi voi päästä alkuun noudattamalla vanhaa sanontaa ”stop starting and start stopping”.

On tärkeää viedä pitkäjänteisesti kehitysaihioita maaliin, vaikka helppo purkkaratkaisu tai ketterä spagetti houkuttaisikin. Edellisen aallon teknologia vietynä loppuun asti on parempi kuin ikuinen keskeneräisyys. Tämä vaatii rankkaa kehitystarpeiden priorisoimista kehitysportfolion ylimmällä tasolla. Onko organisaatiossa tarpeeksi tietoa priorisointipäätösten tekemiseksi?

IT:n ja liiketoiminnan takkuilevan yhteistoiminnan taustalla voi olla vaikeasti korjattavia ongelmia. Sen sijaan oman asenteensa voi jokainen korjata vaikka heti tänään. IT:n ja liiketoiminnan välille ei kannata pystyttää raja-aitaa, koska organisaation kehittämisen haasteet ovat yhteisiä. Haasteet ovat monimutkaisia ja niiden ratkaisemiseen tarvitaan monialaista osaamista.

Tunnistetaan ja tunnustetaan omat kuplamme. Tämän jälkeen niistä voi yrittää päästä ulos ja astua sisään toistemme maailmaan. Toimitaan läpinäkyvästi ja opetellaan luottamaan toisiimme. Sillä se business-IT -integraatio hoidetaan.

Toimitusjohtaja Heli

HELI SYVÄOJA

Toimitusjohtaja

Heli Syväoja on Reflectorin toimitusjohtaja ja ketterien menetelmien puolestapuhuja.

Reflector on ICT-talo, jonka ykköstehtävä on auttaa asiakkaitamme liiketoiminnan isoissa ja pienissä muutoshankkeissa. Ketterästi ja riippumattomasti.

Jaa artikkeli

Voisit pitää myös näistä:

Reflector Heli Syväoja

Tekoälyahdistus

Tekoäly tulee ja tekee höyrykoneeseen verrattavissa olevia muutoksia asiantuntijapainotteisille aloille ja ammatteihin. Saamme kuulla kehityksen huimasta vauhdista lehtien palstoilta, uutisista, podcasteista ja kahvipöytäkeskusteluissa.

Lue lisää
Kokonaisarkkitehtuuri Reflector

Ota yhteyttä, mietitään yhdessä juuri teille parhaat ratkaisut

Täytä tiedot ja siirry lataamaan tutkimus

Kokonaisarkkitehtuuri Reflector

Get in touch!