Digitalist
Vasara koholla ruuvin päällä – väärä työkalu tehtävään – harmaalla pinnalla, mustavalkoinen

Järjestelmäriippuvuus: kun työkalusta tulee strategia

Liiketoimintastrategia
Digitaalinen transformaatio
Jussi Hermunen
28.10.2025

Tervetuloa Muutoksen kiihdyttämisen -sarjan osaan 4/7!

Tämä artikkeli osoittaa, miten organisaatiot nojaavat liikaa suuriin alustoihin – ERP:eihin, CRM:iin, työkaluekosysteemeihin – muutoksen vipuvarsina, samalla sivuuttaen kitkan ja katkokset, joita nämä järjestelmät usein pahentavat. Muotoilu tarjoaa tavan linjata järjestelmät uudelleen sen työn kanssa, jota niiden on tarkoitus tukea. Muutoksen kiihdyttämisen sarjaa jatkaen Järjestelmäriippuvuus osoittaa, miten hyvää tarkoittavista työkaluista voi tulla muistomerkkejä niille toimintahäiriöille, joita olemme tarkastelleet.

Alustojen lupaus ja sudenkuoppa

Monille organisaatioille alustat lupaavat pelastusta. ERP-järjestelmät, CRM:t ja työnkulkutyökalut nähdään mittakaavan, nopeuden ja transformaation välineinä. Käyttöönotettaessa niihin liittyy rohkeita odotuksia: parempi johdonmukaisuus, automaatio, näkyvyys ja kontrolli.

Mutta tuo lupaus tulee usein hinnalla.

Käytännössä alustahankkeet ovat hitaita, jäykkiä ja resurssi-intensiivisiä. Ne toimittavat harvoin sillä nopeudella tai joustavuudella, jota johto toivoo. Useammin ne lukitsevat oletuksia, jotka eivät enää päde, heijastavat kiertoteitä työnkulkujen sijaan ja muovaavat käyttäytymistä tavoilla, joita kukaan ei aivan tarkoittanut.

Tulos on tuttu. Alusta menee tuotantoon, mutta todellinen transformaatio ei aivan seuraa perässä.

Miten järjestelmät ottavat vallan

Järjestelmäriippuvuus ei tapahdu kerralla. Se rakentuu ajan myötä, kun työkalut ja alustat siirtyvät vähitellen työn tukemisesta sen muovaamiseen. Tulos ei ole aina vastustusta, vaan hiljaista myöntymistä.

Tässä joitakin signaaleja, joita näemme:

Alusta edellä -ajattelu

Alustahankkeet keskittyvät liian usein kyvykkyyteen tarkoituksen sijaan. ThoughtWorks kuvaa alusta-ajattelun sisäisten alustojen kohtelemisena tuotteina – omine käyttäjineen, tiekarttoineen ja mitattavine tuloksineen.

Kun organisaatiot ohittavat tämän ajattelutavan, ne lankeavat yleiseen ansaan: rakenna alusta ja toivo sitten, että ihmiset keksivät, miten sitä käytetään. Kuten Eduardo Matos sen ilmaisee, tiimit keskittyvät usein niin voimakkaasti teknisten ominaisuuksien toimittamiseen, että he kadottavat näkyvistä ihmiset, joiden on tarkoitus käyttää niitä.

Kun näin käy, alustasta tulee kehys, ei mahdollistaja. Ydinkysymys siirtyy muodosta ”Mitä ongelmaa ratkaisemme?” muotoon ”Mitä järjestelmä sallii?”

Prosessin jäykkyys

Tuore tutkimus vahvistaa, että heikko ERP-käyttökokemus on edelleen merkittävä este. Aalto-yliopiston vuoden 2025 tutkimus osoitti, että tarpeettomien klikkausten vähentäminen parantaa mitattavasti tehokkuutta ja alentaa käyttäjän stressiä – ei yllättäen.

Toimialaraportit vahvistavat tämän: Panorama Consulting huomauttaa, että intuitiivinen navigointi ajaa suoraan ERP:n käyttöönottoa ja tuottavuutta. Samaan aikaan modernit UX-trendit – kuten personointi, tekoälyavustus ja mobile-first-suunnittelu – muokkaavat odotuksia yritysalustoja kohtaan.

Varjojärjestelmät

Kun järjestelmät eivät vastaa todellista työtä, ihmiset rakentavat kiertoteitä. Gartner raportoi, että 30–40 % yritysten IT-menoista kohdistuu varjo-IT:hen – hyväksymättömiin työkaluihin, joita tiimit ottavat käyttöön saadakseen asiat tehdyksi (Josys, 2024). Lisäksi 65 % kaikista käytössä olevista SaaS-sovelluksista ei ole IT:n hyväksymiä, ja 59 % IT-ammattilaisista raportoi kamppailevansa niiden hallinnan kanssa (Zluri, 2023).

Suuttumuksen aiheuttamisen sijaan nämä kiertotiet syntyvät usein välttämättömyydestä. Olen kuullut jonkun sanovan: Tiedän, että minun pitäisi käyttää tarjottuja järjestelmiä, mutta päivittäisissä tehtävissäni käytän työkalua, joka sopii kontekstiini paremmin.”

Viivästynyt vaikutus

Viivästyneestä vaikutuksesta tulee normi, kun alustat toimitetaan mutta tavoiteltu arvo siirtyy tuonnemmaksi. Go-livet julistetaan onnistuneiksi, vaikka käyttö olisi vähäistä tai pirstaleista. Usein projektista tulee transformaation korvike itsessään. Johto asettaa kaikki muutostoiveensa yhden työkalun varaan tajutakseen liian myöhään, että kulttuuri, prosessi ja linjaus jäivät koskematta. Niken toimitusketjukatastrofi ilmentää tätä kaavaa: 400 miljoonan dollarin ERP-toteutus johti 100 miljoonan dollarin menetettyihin myynteihin ja 20 %:n osakekurssin laskuun, kun ohjelmistoviat aiheuttivat massiivisia tilausten toimitusongelmia. Perässä seuraa joskus hiljainen kysymys: Ja tämän piti korjata kaikki?”

Nämä kaavat eivät ole epäonnistumisen merkkejä. Ne ovat merkkejä siitä, että järjestelmä menee niiden ihmisten edelle, joita sen oli tarkoitus tukea. Ja suuren mittakaavan hankkeissa tavoite on usein saada käyttöönotto maaliin, ei ajatella uudelleen, miten työn pitäisi todella virrata.

Miksi näin tapahtuu

Järjestelmät valitaan ja otetaan käyttöön yleensä parhain aikein. Niiden on tarkoitus tuoda linjausta, nopeutta ja selkeyttä. Mutta ne epäonnistuvat usein, koska ne olettavat, että prosessit tunnetaan, työnkulut ovat vakaita ja tiimit toimivat siisteissä luovutuksissa.

Se on harvoin totta.

Kun kitka ja katkokset ovat ratkaisematta, alustat voivat yksinkertaisesti automatisoida kaaoksen. Ja kun järjestelmiä tuodaan ilman riittävää huomiota kontekstiin, kannustimiin tai todelliseen käyttöön, niistä tulee epälinjauksen muistomerkkejä.

Britannian postin Horizon-järjestelmätapaus havainnollistaa tätä täydellisesti. Yli vuosikymmenen ajan järjestelmä osoitti virheellisesti taloudellisia poikkeamia paikallistoimipisteissä. Mutta teknologian kyseenalaistamisen sijaan organisaatio nosti syytteet satoja paikallispostinhoitajia vastaan varkaudesta ja petoksesta. Järjestelmästä oli tullut niin keskeinen toiminnalle, että sen tarkkuuden haastaminen tuntui mahdottomalta – vaikka ihmisten elämät olivat vaakalaudalla. Computer Weekly raportoi, että yli 700 paikallispostinhoitajaa vastaan nostettiin syytteet rikoksista kuten varkaudesta ja väärennetystä kirjanpidosta, ja monet joutuivat vankilaan ennen kuin järjestelmän virheet lopulta paljastuivat.

”Me muovaamme työkalumme; sen jälkeen ne muovaavat meitä.” – John Culkin

Olemme nähneet tämän toteutuvan julkisessa terveydenhuollossa, jossa suuren mittakaavan alustakäyttöönotot lupaavat transformaatiota mutta päätyvät ylikuormittamaan henkilöstöä jäykillä työnkuluilla, heikoilla käyttöliittymillä ja huonolla sopivuudella arjen käytäntöön. Järjestelmä menee tuotantoon, mutta järjestelmä ei kuuntele.

Monissa organisaatioissa alustaprojektit siirtävät päätöksentekoa tavoilla, joita kukaan ei suunnitellut. Sen sijaan että strategia ohjaisi järjestelmää, järjestelmä alkaa ohjata strategiaa – ja IT:stä tulee muutoksen tosiasiallinen orkestroija. Kuten ERP Today huomauttaa, tietohallintojohtajista on tulossa ”innovaation orkestroijia… jotka toteuttavat ’yrityksen ohjaustason’ hallitakseen yrityksen prosesseja ja datavirtoja”.

Tuo siirtymä ei ole luonnostaan kielteinen. Itse asiassa jotkut tietohallintojohtajat omaksuvat tämän roolin tuomalla liiketoiminta-ajattelun ja muotoiluvetoiset käytännöt IT:hen. Kuten Toyota Financial Servicesin Vipin Gupta sen ilmaisee: ”Hyvät tietohallintojohtajat muuttavat IT:tä sisältäpäin, mutta suurenmoiset tietohallintojohtajat käyttävät muotoiluajattelua ja inklusiivisuutta muuttaakseen IT:tä muuttamalla sitä, mitä tapahtuu IT:n ulkopuolella.”

Mutta syvempi haaste nousee esiin, kun alustoja laajennetaan ilman ennakointia – erityisesti tekoälykyvykkyyksien tuomisen kautta. Tekoälyä upotetaan yhä enemmän ERP- ja CRM-alustoihin, usein innovoinnin nimissä. Mutta kuten Forbes huomauttaa, tämä johtaa usein monimutkaisuuteen, ei selkeyteen – erityisesti kun tekoäly kerrostetaan jo valmiiksi epälinjaisten järjestelmien päälle. Alusta päätyy automatisoimaan melun signaalin kirkastamisen sijaan.

Tämä johtuu osittain siitä, että alustan laajuutta koskevat päätökset tehdään usein johtotasolla – mutta luovutetaan liian nopeasti IT:lle ja toimittajille. Ylin johto haluaa transformaatiota mutta olettaa, että työkalu toimittaa sen. Siihen mennessä kun tosielämän monimutkaisuus nousee pintaan, päätökset on lukittu ja johto on astunut sivuun.

Eivätkä kustannukset ole vain teknisiä. Kun nämä projektit menevät pieleen, ne eivät hiljaa haihdu vaan kasvavat. Laajuus paisuu, deadlinet siirtyvät, budjetit turpoavat. Tuloksena liikevaihtopaineet kasvavat. Organisaatio pakotetaan säästämään muualta – ja liian usein se tarkoittaa työpaikkoja.

Globaaleissa organisaatioissa tätä painetta on vielä vaikeampi hallita. Monialue-käyttöönotot lupaavat mittakaavaa mutta kamppailevat paikallisen vaihtelun huomioimisessa. Markkinat, joilla on erilaiset säännökset, roolit tai toimintamallit, puristetaan tyypillisesti yhden järjestelmälogiikan sisään. Linjauksen sijaan tuloksena on kitkaa globaalissa mittakaavassa – ja kasvava haluttomuus nostaa ongelmia esiin, peloten hidastavansa asioita entisestään.

Vielä pahempaa: paine investoinnin takaisin saamiseksi pakottaa tiimit usein kiertämään viat niiden korjaamisen sijaan. Alustoista tulee liian suuria haastettaviksi – erityisesti kun laskutettava työ tai go-live-deadlinet menevät käytettävyyden, selkeyden tai mukautumisen edelle.

Muotoilun rooli järjestelmien uudelleenkehystämisessä

Tässä palvelumuotoilu tarjoaa paremman polun eteenpäin – ei täydellisen transformaatioblueprintin kautta, vaan jalat-maassa-menetelmin, jotka paljastavat, mitä järjestelmän sisällä todella tapahtuu. Vaikka systeemisen muotoilun menetelmät yhä tukevat työtä – erityisesti narratiivin kehystämisessä ja johdon osallistamisessa – ensisijaiset työkalut ovat tässä käytännöllisiä ja operatiivisia: blueprinting, asiakaspolkujen kartoitus ja prosessisuunnittelu.

Oletusten tai abstraktien prosessimallien varaan nojaamisen sijaan muotoilu alkaa havainnoimalla todellista käyttäytymistä – ja yhteiskehittämällä vaihtoehtoja työtä tekevien ihmisten kanssa. Se jäljittää, missä työ virtaa, missä se katkeaa ja missä järjestelmät alkavat rajoittaa tukemisen sijaan. Nämä havainnot ja jaetut tekemisen hetket nostavat usein esiin sen, minkä business case ohittaa: varjoprosessit, päällekkäisen työn ja muodollisten työnkulkujen sisään piiloutuneet täyttymättömät tarpeet.

Palvelu-blueprinting on tässä keskeisessä roolissa. Se antaa tiimeille jaetun näkymän siitä, miten ihmiset, järjestelmät, data ja prosessit ovat vuorovaikutuksessa siilojen, kanavien ja työkalujen välillä. Hyvin rakennettu blueprint näyttää, missä alusta auttaa, missä se haittaa ja missä tarvitaan lisäkontekstia, jotta järjestelmä toimii tarkoitetusti.

Tämän lisäksi journey operations – asiakaspolkujen ylläpitämisen ja kehittämisen käytäntö ajan myötä – auttaa varmistamaan, että järjestelmät pysyvät linjassa kehittyvien liiketoimintatarpeiden kanssa. Se siirtää alustan käyttöönoton kertaluontoisesta pystytyksestä jatkuvaksi keskusteluksi kokemuksesta, tuloksista ja työtavoista.

Käytännössä nämä menetelmät auttavat vastaamaan kriittisiin kysymyksiin:

  • Missä alusta heijastaa todellista työtä ja missä se vääristää sitä?
  • Missä ihmiset kiertävät järjestelmää, ja miksi?
  • Mitkä prosessivaiheet näyttävät siisteiltä paperilla mutta hajoavat todellisuudessa?

Tässä astuu mukaan prosessisuunnittelu – ei vain kartoittamaan, mitä pitäisi tapahtua, vaan muovaamaan, mitä voisi tapahtua. Se tuo selkeyttä työnkulkuihin, kytkee aikomuksen toteutukseen ja kääntää monialaiset tarpeet joksikin skaalautuvaksi. Palvelumuotoiluun yhdistettynä se varmistaa, että syntyvät järjestelmät eivät ole vain haluttavia vaan myös operatiivisesti kestäviä.

Muotoilu ei vain dokumentoi näitä kysymyksiä, se prototypoi vaihtoehtoja. Se tarjoaa jotain näkyvää ja testattavaa, johon eri sidosryhmät voivat reagoida kauan ennen kuin mitään konfiguroidaan.

”Muotoilua käytetään osallistamaan käyttäjät ja paljastamaan järjestelmä ennen kuin järjestelmä rakennetaan.”

Muotoilu toimii parhaiten, kun se sijoitetaan alustojen suunnittelun tai konfiguroinnin rinnalle – tarjoten näkyvyyttä, selkeyttä ja linjausta samalla kun konfigurointipäätöksiä tehdään. Eräässä suuren mittakaavan ERP-käyttöönotossa, jota tuimme, vain kaksi muotoilijaa työskenteli kymmenien toteuttajien rinnalla – kartoittaen todellisia käyttäjätarpeita, visualisoiden monialaisia virtoja ja näyttäen, miltä hyvä voisi näyttää. Tulos oli häikäisevä: nopeampi konsensus, vähemmän uudelleentyökierroksia ja alusta, joka sopi muuhunkin kuin oletusprosessiin.

Sellainen vaikutus ei vaadi kontrollia. Se vaatii ajoitusta, selkeyttä ja läsnäoloa. Muotoilun vahvuus ei ole ohjelman johtamisessa – vaan sen muovaamisessa, miten ohjelma ymmärtää, mitä kannattaa ratkaista ja miltä toimiva oikeasti näyttää.

Design-järjestelmät siltana

Yksi selkeimmistä esimerkeistä tästä on design-järjestelmien (Design Systems) nousu.

Design-järjestelmät eivät ole vain UI-kittejä. Oikein tehtyinä ne yhdistävät alustalogiikan liiketoimintakontekstiin. Ne tekevät johdonmukaisesta toteutuksesta nopeampaa, mutta sallivat myös joustavuutta siellä missä sillä on merkitystä. Ne vähentävät toistoa, parantavat saavutettavuutta ja linjaavat tiimit teknologian ja tuotteen välillä.

Vankka design-järjestelmä sisältää tyypillisesti UI-kitit, design-tokenit (kuten värit, välistykset ja typografia), komponenttikirjastot, koodipaketit, saavutettavuusohjeet, dokumentaation ja yhtenäiset työtavat. Yhdessä nämä antavat organisaatioiden näyttää, toimia ja tuntua yhtenäisiltä markkinoiden välillä – samalla merkittävästi vähentäen käyttöliittymien suunnittelun ja rakentamisen päällekkäistä vaivaa.

Mutta kriittisin hyöty on nopeus. Design-järjestelmillä on mitattava vaikutus markkinoilletuloaikaan, usein leikaten viikkoja tai jopa kuukausia toimitusaikatauluista poistamalla tarpeen keksiä perusmallit yhä uudelleen.

Ja näin tehdessään ne antavat tiimeille jotain vielä arvokkaampaa kuin johdonmukaisuus: aikaa. Aikaa keskittyä monimutkaisempiin ja strategisempiin haasteisiin, kuten alustaponnistelujen linjaamiseen todellisuuteen, katkosten ratkaisemiseen ja organisaatiokitkan vähentämiseen. Näin design-järjestelmät eivät vain paranna toimitusta. Ne edistävät selkeyttä, kulttuuria ja merkitystä läpi organisaation.

Alustapainotteisissa ympäristöissä siitä tulee strateginen etu. Design-järjestelmät antavat tiimien puhua samaa kieltä – ei vain visuaalisesti vaan myös toiminnallisesti. Ne siltaavat sen, mitä järjestelmä odottaa ja mitä ihmiset tarvitsevat.

Milloin muotoilu astuu mukaan

Muotoilu ei aina saavu alustamatkan alussa. Itse asiassa se ilmestyy usein myöhään – käyttöönoton jälkeen, kun käyttö laahaa, kiertotiet ilmestyvät tai tiimit alkavat kysyä, miksi järjestelmä ei sovi.

Siinä vaiheessa tehtävä muuttuu. Kyse ei ole enää konfiguroinnin ohjaamisesta – vaan tiimien auttamisesta ottamaan takaisin ja muovaamaan uudelleen se, mikä on jo olemassa. Edellä käsitellyistä muotoilun menetelmistä tulee työkaluja merkityksen rakentamiseen ja pelastamiseen.

Mutta kun muotoilu astuu mukaan varhain, vaikutus moninkertaistuu. Ennen kuin mitään on kovakoodattu, tiimit voivat testata oletuksia, muovata rooleja, yhteiskehittää prosesseja ja määritellä, miltä hyvä oikeasti näyttää.

Miksi tällä on merkitystä

Kun organisaatiot asettavat liikaa toivoa pelkästään järjestelmiin, ne päätyvät usein suunnittelemaan alustalle ihmisten sijaan. Se saattaa vakauttaa toimintaa, mutta harvoin avaa muutosta.

Tuloksena on tuttu kehä:

  1. Työkaluja otetaan käyttöön johdonmukaisuuden tuomiseksi.
  2. Ihmiset mukautuvat kiertoteiden kautta.
  3. Alustasta tulee vaikeampi haastaa, vaikka se olisi epälinjassa.
  4. Liikevoima hiipuu ja turhautuminen kasvaa.

Tämä ei ole vain käytettävyysongelma vaan rakenteellinen. Hoitamattomana järjestelmäriippuvuus siirtää hiljaa valtaa, muovaa päätöksiä ja rajoittaa sitä, mitä tiimit uskovat mahdolliseksi. Se voi pysäyttää transformaation ei vastustuksen vaan myöntymisen kautta.

Siksi muotoilulla on tässä merkitystä. Ei koristelemaan sitä, mikä on olemassa, vaan kyseenalaistamaan, mitä pitäisi olla. Ei konfiguroimaan parempaa ruokalistaa, vaan auttamaan tiimejä kysymään oikeat kysymykset ennen ravintolan valintaa.

Mutta tämä siirtymä vaatii muotoilijoita astumaan esiin, jälleen. Monet organisaatiot eivät vielä näe muotoilua relevanttina alustojen kontekstissa – eivätkä usein myöskään muotoilijat itse. Se on tila, jota hallitsevat kokonaisarkkitehtuuri, toimittajamyynti ja toteutusaikataulut. Silti juuri siksi muotoilua tarvitaan: tuomaan todelliset käyttötapaukset, inhimillinen selkeys ja operatiivinen merkityksenluonti huoneeseen.

Koska järjestelmät eivät ole strategia, mutta ne muovaavat sitä, miten strategia näyttäytyy.

Ja jos haluamme muutoksen kiihtyvän, meidän on varmistettava, että suunnittelemme oikean järjestelmän, emme vain toteuta saatavilla olevaa.

______

Osallistu keskusteluun:Muutoksen kiihdyttämisen sarja LinkedInissä:

  1. Muotoilijoista muutosagenteiksi
  2. Kitka – siellä missä liike jää jumiin
  3. Katkokset – kun signaali katkeaa
  4. Järjestelmäriippuvuus – kun työkalusta tulee strategia (olet tässä)
  5. Sokeat pisteet – kun kriittiset signaalit jäävät huomaamatta
  6. -
  7. -