Miksi nopeampi skaalaaminen ei korvaa perustaa

Sudenkuoppa

On ollut onnistunut pilotti. Johto haluaa vauhtia. Päätös tehdään: laajennetaan koko organisaatioon, muihin tiimeihin, muihin osastoihin. Sen, mikä toimi yhdessä nurkassa, on nyt toimittava kaikkialla.

Se ei suinkaan aina onnistu. Ei siksi, että teknologia yhtäkkiä reagoisi eri tavalla, vaan siksi, että ympäristö, jossa sen on toimittava, on kaikkialla järjestetty eri tavalla. Tiimillä, jossa pilotti onnistui, oli sattumalta IT-infrastruktuuri, joka pystyi vastaamaan vaatimuksiin, datanhallinta, joka oli kunnossa, ja organisaatiorakenne, jossa joku otti vastuun. Muualla organisaatiossa yksi tai useampi näistä asioista on eri tilassa. Tulos: sama panostus tuottaa yhdessä paikassa jotain ja toisessa paikassa ei mitään, tai pahempaa, ylimääräistä työtä virheiden korjaamiseksi.

Miksi se tuntuu loogiselta

Skaalaaminen tuntuu seuraavalta askeleelta, koska pilotti on todistanut jotain. On tulos, on innostusta, on painetta kasvattaa tuottoa. Kun jonkin on saanut toimimaan, sitä ei halua pitää rajattuna yhteen tiimiin. Lisäksi skaalaaminen on näkyvää: enemmän käyttäjiä, enemmän tiimejä, enemmän prosessilinjoja, jotka omaksuvat uuden työskentelytavan. Se tuntuu edistykselle, myös silloin kun perustavanlaatuiset ulottuvuudet — organisaatio, IT-infrastruktuuri, datanhallinta — eivät kaikkialla ole tasolla, jolla niistä riippuvainen ulottuvuus voisi todella toimia.

Järjestys, jossa tämä toimii, ei ole valinnainen. Jos perustavanlaatuinen kerros ei ole kunnossa, riippuvaisella kerroksella ei ole mitään, minkä päälle rakentaa. Se ei ole mieltymyskysymys eikä kysymys enemmän aikaa ottamisesta; se on tapa, jolla ulottuvuudet kannattelevat toisiaan. Skaalaaminen ohittaa tämän järjestyksen ja odottaa, että työskentelytavan toistaminen riittää, myös silman sitä perustaa, joka ensimmäisellä kerralla oli sattumalta läsnä.

Mistä huomaatte olevanne tässä tilanteessa

Muutama merkki toistuu usein. Tiimit, jotka omaksuvat uuden työskentelytavan, raportoivat vaihtelevia tuloksia, eikä kukaan pysty hyvin selittämään, miksi se toimii yhdessä tiimissä mutta ei toisessa. Pyydetään lisää koulutusta tai lisää viestintää, vaikka ongelma on muualla: järjestelmissä, jotka eivät toimi yhteen, datassa, joka ei ole samaa laatua, rakenteessa, jossa kukaan ei omista tulosta tiimirajojen yli.

Tunnistettavissa on myös tilanne, jossa teknologiaa laajennetaan rakenteeseen, joka itse ei ole muuttunut mukana: uusi työskentelytapa asetetaan teknisesti saataville, mutta roolit, vastuut ja päätöslinjat ovat samat kuin ennen pilottia. Samankaltainen kaava on tilanteessa, jossa pilotti toimii hyvin omassa nurkassaan mutta ei kytkeydy muuhun organisaatioon: skaalaus kopioi työskentelytavan, ei olosuhteita, joissa tämä työskentelytapa syntyi.

Kolmas merkki on vähemmän näkyvä, mutta yhtä ratkaiseva: kaksi innostunutta ihmistä vetää kärryä ja kukaan muu ei tunne vastuuta. Niin kauan kuin aloite riippuu muutamasta sattumalta motivoituneesta ihmisestä, ei ole organisatorista perustaa skaalaamiselle — on vain innostusta, joka ei monistu, kun tiimi kasvaa.

Kuka tunnistaa näitä merkkejä, tekee viisaasti kysyessään itseltään, onko tiimien välinen hajonta toteutuksen seuraus vai eroa valmiudessa, joka oli olemassa jo kauan ennen skaalaamista. Juuri tähän eroon hybridresourcing-kypsyysmittaus katsoo: ei yhteen pisteytykseen koko organisaatiolle, vaan viiteen tasoon seitsemällä ulottuvuudella, mitattuna siten, että useat ihmiset arvioivat erikseen ja heidän vastaustensa välinen hajonta tulee näkyväksi. Tämä hajonta kertoo usein enemmän kuin keskiarvo: jos toimitusjohtajan arvio poikkeaa perustavanlaatuisesti tietohallintojohtajan arviosta, siinä piilee osa selitystä siihen, miksi skaalaaminen toimii jossain ja ei toisaalla. Se, mitä toimitusjohtaja tässä mittauksessa näyttää omasta organisaatiostaan, ja se, mitä operatiivinen johtaja siinä tunnistaa päivittäisestä toteutuksesta, tuottavat harvoin saman kuvan, ja juuri tämä ero on se, mihin mittaus on rakennettu.

Silta seuraavaan kysymykseen

Tämä sivu käsittelee kysymystä, kestääkö organisaatio AI:ta: on rakenne, on infrastruktuuri, on datanhallinta tasolla, jolla skaalaaminen on mielekästä. Se on eri kysymys kuin se, mikä osa itse työstä soveltuu siirrettäväksi AI:lle. Jälkimmäiseen kysymykseen vastaa FTE TO AI:n työskannaus: se laskee tehtäväkohtaisesti, mikä osa työstä on AI:n otettavissa haltuun, riippumatta siitä, onko organisaatio siihen jo valmis. Molemmat kysymykset kuuluvat yhteen, mutta järjestys ei ole vapaaehtoinen — sen tietäminen, mikä on siirrettävissä, on vähäarvoista, jos ei ole selvää, kestääkö perusta tämän siirron.

Työkalu on rakenteilla