Järjestelmän käyttöönotto epäonnistui — neljä toistuvaa syytä ja niiden estotoimet

Käyttöönotto kaatuu harvoin tekniikkaan. Neljä syytä toistuu: projektilla ei ole omistajaa, koulutus jää pitämättä, vanha data siirretään sellaisenaan ja vanhaa tapaa käytetään uuden rinnalla. Tässä jokaisen mekanismi, estotoimi ja varhaiset merkit.

Järjestelmän käyttöönotto epäonnistuu harvoin tekniikan takia. Ohjelmisto asennetaan, se toimii, ja silti kuuden kuukauden päästä työ tehdään entiseen tapaan ja lisenssi maksaa taustalla. Neljä syytä toistuu: projektilla ei ole omistajaa, koulutus jää pitämättä, vanha data siirretään sellaisenaan, ja vanhaa tapaa käytetään uuden rinnalla niin kauan, että uusi jää käyttämättä.

Tässä käydään läpi jokaisen mekanismi — miksi se johtaa epäonnistumiseen — ja yksi estotoimi kutakin kohti. Lopuksi on taulukko varhaisista merkeistä, joista näet suunnan ennen kuin puoli vuotta on kulunut. Prosenttilukuja ei ole, koska niitä ei ole luotettavasti saatavilla ilman nimettyä lähdettä; mekanismit sen sijaan ovat tunnistettavia ja korjattavia.

Syy 1: mitä tapahtuu, kun projektilla ei ole omistajaa?

Mekanismi on tämä. Hankintapäätös tehdään yhdessä, toimittaja nimetään, ja siihen jää oletus että projekti etenee itsestään. Kun toimittaja kysyy jotain, kysymys menee sähköpostilla useammalle ihmiselle. Kukaan ei vastaa, koska jokainen olettaa jonkun toisen vastaavan. Kaksi viikkoa menee. Toimittaja siirtyy toiseen projektiin, teillä alkaa kiireinen kausi, ja käyttöönotto liukuu kuukaudella. Sama toistuu kolmesti, ja puoli vuotta on mennyt ilman että kukaan teki väärin.

Toinen muoto samasta ongelmasta on omistaja, jolla ei ole valtaa. Jos nimetty vastuuhenkilö ei voi päättää, muutetaanko työtapaa, hän voi vain välittää viestejä. Silloin jokainen päätös odottaa sitä, joka päättää oikeasti.

Estotoimi: nimeä yksi ihminen, kirjaa hänen nimensä sopimukseen, anna hänelle päätösvalta työtapojen muutoksiin ja varaa hänen kalenteristaan kiinteä viikkoaika projektille. Yksi tunti viikossa nimettynä on enemmän kuin viisi tuntia, jotka löytyvät "kun ehtii". Toimittajan puolelta nimetään sama tapa: yksi nimi, ei tiimi.

Syy 2: milloin koulutus pitäisi pitää?

Koulutus epäonnistuu käyttöönotoissa kahdesta syystä, ja molemmat ovat aikatauluongelmia. Ensimmäinen on paikka suunnitelmassa: koulutus on aina viimeisenä, ja kun aikataulu venyy — ja se venyy — venymä otetaan viimeisestä kohdasta. Koulutus supistuu tunnin esittelyksi, joka pidetään kiireessä, ja sen jälkeen jokainen opettelee itse. Toinen on ajoitus: yksi pitkä koulutuspäivä ennen käyttöönottoa tuntuu järkevältä, mutta silloin kukaan ei osaa vielä kysyä mitään, koska kukaan ei tiedä mikä on vaikeaa. Kaksi viikkoa myöhemmin kysymyksiä olisi kymmenen, mutta koulutus on jo pidetty. Oikea hetki on siis molemmat: lyhyt aloitus ennen ja varsinainen koulutus oikean työn jälkeen.

Toinen virhe on ajoitus. Yksi pitkä koulutuspäivä ennen käyttöönottoa tuntuu järkevältä, mutta silloin kukaan ei osaa vielä kysyä mitään, koska kukaan ei tiedä mikä on vaikeaa. Kaksi viikkoa myöhemmin kysymyksiä olisi kymmenen, mutta koulutus on jo pidetty.

Estotoimi: jaa koulutus kahteen osaan. Lyhyt aloitus ennen käyttöönottoa, sitten kaksi viikkoa oikeaa työtä, sitten toinen kerta, johon jokainen tuo omat kysymyksensä. Kirjaa molemmat päivämäärät kalenteriin ennen kuin projekti alkaa, jotta ne eivät ole venytettävissä. Nimeä lisäksi talon sisältä yksi henkilö, joka osaa järjestelmän muita paremmin ja jolta saa kysyä — se maksaa itsensä takaisin heti.

Syy 3: miksi vanhaa dataa ei kannata siirtää sellaisenaan?

Mekanismi on epäintuitiivinen: mitä enemmän dataa siirretään, sitä epätodennäköisemmin uusi järjestelmä otetaan käyttöön. Vanhassa rekisterissä on kaksoiskappaleita, vanhentuneita yhteystietoja, puolivalmiita tapauksia ja asiakkaita, jotka lopettivat vuosia sitten. Kun ne siirretään, uusi järjestelmä näyttää ensimmäisenä päivänä sekavalta. Käyttäjä hakee asiakasta, saa kolme osumaa eikä tiedä mikä niistä on oikea — ja palaa vanhaan, jossa hän ainakin tietää mikä on ajan tasalla.

Toinen puoli samasta ongelmasta on luottamus. Jos ensimmäisellä viikolla löytyy kolme virheellistä tietoa, käyttäjä alkaa tarkistaa kaiken vanhasta järjestelmästä. Silloin uusi järjestelmä on lisätyötä, ei säästöä.

Estotoimi: siirrä vain aktiivinen data. Käytännön rajaus: asiakkaat, joiden kanssa on ollut tapahtumia viimeisen kahden vuoden aikana, avoimet työt ja keskeneräiset laskut. Loput arkistoidaan erilliseen tiedostoon, joka säilytetään mutta jota ei tuoda uuteen järjestelmään. Siivoa myös ennen siirtoa: poista kaksoiskappaleet ja yhdenmukaista muodot, erityisesti puhelinnumerot ja yritysnimet. Tämä on tylsää työtä ja se on käyttöönoton kannattavin päivä.

Syy 4: miksi rinnakkaiskäyttö jää päälle?

Tämä on neljästä yleisin ja se, joka tappaa hitaimmin. Vanha järjestelmä tai vihko jätetään käyttöön "varmuuden vuoksi siirtymäajaksi". Aluksi molempia päivitetään. Sitten joku kiireessä kirjaa vain vanhaan. Nyt järjestelmät ovat eri mieltä. Kun ne ovat eri mieltä, luotetaan siihen, jonka tuntee — eli vanhaan. Kuukauden päästä uusi on tyhjä ja kukaan ei tehnyt päätöstä sen hylkäämisestä.

Tässä on tärkeä ero: rinnakkaiskäyttö tarkoittaa saman tiedon ylläpitoa kahdessa paikassa. Vanhan järjestelmän pitäminen auki lukukäyttöön ei ole rinnakkaiskäyttöä eikä ole ongelma. Ongelma on kaksinkertainen kirjaaminen.

Estotoimi: aseta katkaisupäivä ja tee siitä konkreettinen. Sovittuna päivänä vanhaan järjestelmään ei enää kirjata, vaan se jätetään auki pelkkään lukukäyttöön. Jos vanha on paperivihko, se siirretään hyllyyn. Ilmoita päivä etukäteen ja pidä siitä kiinni, vaikka kaikki ei olisi valmista — se ei koskaan ole. Yksi poikkeus kannattaa sallia: jos jokin kriittinen toiminto ei aidosti toimi uudessa, katkaisua siirretään, mutta uudella päivämäärällä eikä avoimeksi.

Miten neljä syytä ruokkivat toisiaan?

Neljä epäonnistumisen syytä eivät esiinny yksin vaan ketjuna, ja juuri siksi käyttöönotto voi näyttää sujuvalta ensimmäisen viikon ja kaatua kolmannella. Ketju kulkee tyypillisesti näin: omistajan puuttuminen viivyttää päätöksiä, viivästys syö aikataulusta, ja aikataulusta leikataan koulutus, koska se on suunnitelmassa viimeisenä. Kouluttamaton käyttäjä ei osaa hakea tietoa uudesta järjestelmästä, ja jos data on lisäksi siirretty siivoamatta, haku tuottaa vääriä osumia. Silloin käyttäjä palaa vanhaan tapaan — ei vastustuksesta vaan siksi, että työ pitää saada tehdyksi tänään. Rinnakkaiskäyttö on siis useimmiten seuraus kolmesta muusta syystä eikä itsenäinen ongelma, ja se kannattaa muistaa ennen kuin sitä lähtee kieltämään.

Omistajan puuttuminen viivyttää päätöksiä. Viivästys syö aikataulusta, ja aikataulusta leikataan koulutus, koska se on viimeisenä. Kouluttamaton käyttäjä ei osaa hakea tietoa uudesta järjestelmästä, ja jos data on lisäksi siirretty siivoamatta, haku tuottaa vääriä osumia. Silloin käyttäjä palaa vanhaan — ei vastustuksesta vaan siksi, että työ pitää saada tehdyksi tänään. Rinnakkaiskäyttö on siis useimmiten seuraus kolmesta muusta syystä, ei itsenäinen ongelma.

Tästä seuraa käytännön johtopäätös: jos huomaat rinnakkaiskäyttöä, älä aloita kieltämällä sitä. Kysy ensin, kumpi kolmesta muusta syystä sen aiheuttaa. Kielto ilman syyn poistamista siirtää työn näkymättömiin — muistilapuille ja henkilökohtaisiin tiedostoihin, joista sitä ei enää löydä kukaan.

Varhaiset merkit: mitä katsoa ensimmäisten viikkojen aikana?

Merkkien seuraaminen ei vaadi raportointijärjestelmää. Riittää, että kysyt kerran viikossa kolme kysymystä niiltä, jotka työtä tekevät: mitä teit tällä viikolla vanhalla tavalla, mikä uudessa oli hankalinta, ja mitä tietoa et löytänyt. Kirjaa vastaukset ylös. Kolmen viikon jälkeen listalla on käytännössä kaikki, mikä projektissa on vialla, ja useimmat kohdat ovat pieniä korjauksia. Kysyminen kannattaa tehdä kasvotusten eikä kyselylomakkeella, koska kirjallisesti kukaan ei kerro palanneensa vanhaan tapaan.

Kaikki viisi ovat nähtävissä kolmen ensimmäisen viikon aikana. Siinä vaiheessa korjaus maksaa muutaman tunnin. Kuuden kuukauden päästä sama korjaus tarkoittaa uutta käyttöönottoprojektia.

Milloin käyttöönotto kannattaa keskeyttää?

Joskus rehellisin päätös on keskeyttää käyttöönotto, ja kolmessa tilanteessa jatkaminen maksaa enemmän kuin peruminen. Ensimmäinen on se, ettei järjestelmä tee sitä, minkä takia se ostettiin: jos keskeinen toiminto puuttuu ja sen rakentaminen olisi oma projektinsa, jatkaminen tarkoittaa koko organisaation opettamista väärään työkaluun. Toinen on käyttämättömyys kolmen kuukauden jälkeen — se on vastaus, ei ongelma ratkaistavaksi, ja syy kannattaa selvittää ennen kuin jatketaan. Kolmas on yrityksen tilanteen muuttuminen kesken projektin: suljettu toimipiste, vaihtunut palvelu tai lähtenyt avainhenkilö tarkoittaa, että käyttöönotto lukitsisi keskeneräisen toimintatavan. Keskeyttäminen ei näissä ole epäonnistuminen vaan halvin jäljellä oleva vaihtoehto.

Kun järjestelmä ei tee sitä, minkä takia se ostettiin. Jos keskeinen toiminto puuttuu ja sen rakentaminen on erillinen projekti, älä jatka toivossa. Neuvottele purku tai vaihda tuotetta ennen kuin koko organisaatio on opetellut väärän työkalun.

Kun ihmiset eivät käytä sitä kolmen kuukauden jälkeen. Käyttämättömyys on vastaus, ei ongelma ratkaistavaksi. Selvitä syy: jos se on koulutus tai data, se korjataan. Jos se on se, ettei järjestelmä sovi työhön, jatkaminen ei muuta asiaa.

Kun yrityksen tilanne on muuttunut kesken projektin. Toimipiste sulkeutui, palvelu vaihtui, avainhenkilö lähti. Käyttöönotto keskeneräiseen tilanteeseen lukitsee väärän toimintatavan. Pysäytä, odota, aloita uudelleen mittauksesta.

Yhteenveto: neljä estotoimea

1. Yksi nimetty omistajaNimi sopimukseen, päätösvalta työtapoihin ja kiinteä viikkoaika kalenterissa. Sama toimittajan puolelta.
2. Koulutus kahdessa osassaLyhyt aloitus, kaksi viikkoa työtä, toinen kerta omilla kysymyksillä. Päivämäärät kalenteriin ennen aloitusta.
3. Vain aktiivinen data siirtoonKahden vuoden aktiiviset, avoimet työt ja keskeneräiset laskut. Loput arkistoon. Siivous ennen siirtoa.
4. Katkaisupäivä rinnakkaiskäytölleKorkeintaan kaksi viikkoa, kalenteriin, kaikille kerrottuna. Vanha jää lukukäyttöön, ei kirjaamiseen.

Neljä toimenpidettä, joista yksikään ei maksa mitään ja jotka kaikki pitää päättää ennen kuin käyttöönotto alkaa. Sen jälkeen ne ovat vaikeita, koska silloin kyse on työtapojen muuttamisesta kesken kaiken — siitä lisää sivulla muutosjohtaminen.

Jos haluat, että käyttöönotto viedään läpi näiden neljän kohdan mukaisesti, katso digitalisaatio ja hinnat hinnastosta.

Mitä epäonnistunut käyttöönotto maksaa?

Kustannus ei ole lisenssimaksu. Se on kolme muuta erää: käytetty oma työaika, se että vanha ongelma on yhä olemassa, ja se että seuraava hanke on vaikeampi myydä omalle porukalle. Kolmas on pisimpään vaikuttava — kerran epäonnistuneen käyttöönoton jälkeen jokainen seuraava ehdotus kohtaa perustellun epäilyn.

Siksi kannattaa pitää ensimmäinen hanke pienenä. Yksi prosessi, yksi mitattava luku, selvä katkaisupäivä. Onnistunut pieni käyttöönotto tekee seuraavasta helpon, ja se on arvokkaampaa kuin se, kuinka kunnianhimoinen ensimmäinen oli.

Usein kysyttyä

Lue seuraavaksi

• Yrityssovelluksen kehittämisen hinta
• WordPress-ylläpidon hinta ja mitä siihen oikeasti kuuluu
• WordPressin hakukoneoptimointi: neljä asetusta, jotka ratkaisevat teknisen puolen
• Webhotellin vaihto ilman katkoa: testaa uusi palvelin ennen kuin kukaan asiakas näkee mitään
• Ilmainen verkkotunnus: milloin se on oikeasti ilmainen ja mitä se sitoo
• Verkkosivun nopeus ja myynti: kolme yleisintä hidastetta ja miten mittaat oman hyötysi

Lue myös: Tekoälykonsultointi pienyritykselle · Digitalisaatio pienyritykselle · Liikkeenjohdon konsultointi pienelle yritykselle · Google-yritysprofiili: tee itse ilmaiseksi tai anna meidän hoitaa se · Sähköposti yritykselle: mitä nimi@firma.fi maksaa ja miten se otetaan käyttöön · verkkotunnus ja domain · WordPress-ylläpito: mitä se on, mitä se maksaa ja milloin sitä ei tarvita · Microsoft 365 vai Google Workspace: rehellinen vertailu 1-10 hengen yritykselle