Ensimmäisestä kartoituksesta järjestelmän vastaanottotarkastukseen. Yksi neuvonantaja johdon puolella koko reitin ajan.

1. IT-järjestelmien ja prosessien kartoitus

   Mitä meillä oikeastaan on?

   Jokaisen käyttöönottopäätöksen lähtökohta. Ennen kuin valitsette järjestelmän, toimittajan tai suunnan, saatte selkeän ja jäsennellyn kuvan siitä, mitä teillä jo on.

   • Sovellusrekisteri, jossa on omistaja, sopimus, lisenssi, kustannus ja tuen päättymispäivä.
   • Kartta järjestelmien tukemista ja tukemattomista prosesseista, kartta integraatioista ja kohdista, joissa tietoja syötetään käsin uudelleen.
   • Riskirekisteri, mukaan lukien yksittäiset vikaantumispisteet (single points of failure) ja riippuvuus yhdestä toimittajasta.
   • Järjestelmien A/B/C/D-luokittelu ja yhden sivun yhteenveto johdolle.

   2–6 viikkoa, julkisten hankintojen kynnysarvon alapuolella.

   IT-kartoituksen koko laajuus

2. Tarveanalyysi ja työpajat

   Mitä todella tarvitsemme?

   Sisäisiä työpajoja, joissa selvitämme, mitä organisaatio todella tarvitsee. Saan sen usein esiin yksinkertaisilla kysymyksillä: mikä on onnistumisen määritelmä? Milloin hanke katsotaan onnistuneeksi? Yritykset ja virastot ohittavat tämän hyvin usein, joko koska ne uskovat jo tietävänsä kaiken tai koska niillä ei yksinkertaisesti ole aikaa syvällisempiin kysymyksiin. Se on yksi yleisimmistä hankkeiden ongelmien syistä.

   • Työpajat johdon ja prosessissa päivittäin työskentelevien ihmisten kanssa: tavoitteet, odotukset, rajoitteet.
   • Onnistumisen määritelmä ja kriteerit, joista tunnistatte hankkeen onnistuneen.
   • Kuvaus siitä, mikä tänään ei toimi, ja siitä, miltä tulevaisuuden pitäisi näyttää.
   • Lähtötiedot vaatimuksiin tai markkinaselvitykseen tai päätös siitä, että uutta järjestelmää ei tarvita.

   Kysymykset, joista aloitan

3. Digitalisaatiostrategia ja tavoitearkkitehtuuri

   Mihin olemme menossa ja missä järjestyksessä?

   Strategia, joka ei jää pöytälaatikkoon, koska se perustuu siihen, mitä organisaatiolla todella on, ja kertoo, mitä seuraavassa budjetissa tehdään.

   • Kerroksittain kuvattu tavoitearkkitehtuuri: rekisterit, prosessit, integraatiot ja pääsynhallinta.
   • Organisaation omaksumat standardit: käyttöoikeusmalli, rajapintastandardi, vaatimusten dokumentointisäännöt.
   • Tiekartta, joka erottaa sääntelyn asettamat velvoitteet investoinneista.
   • Järjestelmähankintojen hankintasäännöt ja budjetti jaettuna investointeihin ja ylläpitoon.

4. Vaatimukset ja hankkeen valmistelu

   Miten kuvaamme tarpeet niin, että toimittaja ymmärtää ne?

   Vaatimukset kirjoitettuina prosessienne kielellä ennen kuin käynnistätte kilpailutuksen tai lähetätte tarjouspyynnön. Niiden ansiosta tarjoukset ovat vertailukelpoisia ja toimittajan voi myöhemmin pitää vastuussa.

   • Haastattelut, prosessikartat, tietomalli, integraatiot ja testiskenaariot.
   • Ennen kaikkea vastaus kysymykseen, mitä käyttöönoton onnistuminen tarkoittaa: miksi teemme tätä ja mitä tuloksia odotamme.
   • Kun johdolla on idea mutta ei aikaa kirjoittaa sitä auki: konsepti tai prototyyppi yhden keskustelun pohjalta noin 2 päivässä.

5. Tarjousten arviointi ja keskustelut toimittajien kanssa

   Miten eri toimittajien tarjouksia vertaillaan tehokkaasti?

   Riippumaton näkemys oman IT:nne suosituksen rinnalle, ei sen tilalle. Johto saa vertailun, johon se voi perustaa päätöksensä ja jonka se voi perustella valtuustolle, omistajalle tai konsernin pääkonttorille.

   • Kysymykset toimittajille ja esittelyt omien skenaarioidenne pohjalta.
   • Vertailumatriisi: tarjoukset yhteismitalliseen laajuuteen saatettuina, kokonaiskustannus usean vuoden aikajänteellä, ylläpidon ja sopimuksesta irtautumisen ehdot.
   • Tytäryhtiöille vertailu konsernin pääkonttorin hankintaohjeisiin, tarvittaessa englanniksi.
   • Osallistuminen toimittajatapaamisiin tilaajan edustajana.

6. Käyttöönotto, muutos ja vastaanottotarkastus

   Miten viemme hankkeen maaliin, saamme ihmiset mukaan ja pidämme toimittajan vastuussa?

   Suuri IT-hanke on myös muutos ihmisten tavassa tehdä työtä. Usein ensimmäinen laatuaan organisaatiossanne, mutta ei minun työssäni. Edustan johtoa käyttöönottotiimissä ja ohjaan muutosta niin, että ihmiset todella ottavat uuden järjestelmän omakseen. Johdon tarvitsee palata asiaan vain silloin, kun sen päätöstä tarvitaan.

   • Laajuuden, aikataulun ja muutospäätösten valvonta sekä muutos- ja päätösloki.
   • Muutoksenhallinta: viestintäsuunnitelma, koulutukset, muutoslähettiläät osastoilla ja yksiköissä, keskustelut vielä epäröivien kanssa.
   • Lyhyet yhteenvedot johdolle sekä viestintään IT:n, valtuuston tai konsernin pääkonttorin kanssa.
   • Vastaanottotarkastus sovittujen testiskenaarioiden ja kriteerien mukaan, varmistettu tiedonsiirto vanhasta järjestelmästä.
   • Ylläpitosopimus, joka ei sido teitä yhteen toimittajaan enempää kuin on välttämätöntä.

   Miltä tämä näyttää ERP-käyttöönotossa

7. Pysyvä neuvonantaja johdolle

   Meillä ei ole IT-johtajaa. Kuka pitää kokonaisuuden hallussa?

   Rooli, jota kansainvälisesti kutsutaan osa-aikaiseksi CIO:ksi (”fractional CIO”), yhdellä erolla: en ota IT-osastoa tai sen budjettia hoitooni. Käännän johdon tavoitteet vaatimuksiksi, arvioin IT:n suosituksia ja edustan tilaajan etua suhteessa toimittajiin.

   • Kuukausittainen tapaaminen hallintojohtajan tai toimitusjohtajan ja IT-päällikön kanssa, kuukausittainen toiminta- ja riskiraportti.
   • Neljännesvuosittainen riskien ja kriittisten sopimusten katselmus, lausunto ennen jokaista suurempaa hankintaa.
   • Ensimmäiset 90 päivää: alustava arvio ja mahdolliset kiireelliset ”punaiset liput”, rekisterien käynnistäminen ja sopimusten läpikäynti, raportti johdolle ja tiekartta 12–24 kuukaudeksi.

Kunkin vaiheen kesto riippuu organisaatiosta ja hankkeesta: siitä, kuinka valmis organisaatio on, millainen sen organisaatiokulttuuri on ja millaisen mandaatin johto antaa. Siksi sovimme laajuudesta ja aikataulusta ensimmäisen keskustelun jälkeen. Kiinteä hinta ja aikataulu on vain IT-kartoituksella.