Tämä kirjoitus on tarkoitettu henkilöille, jotka tilaavat, hyväksyvät tai joutuvat myöhemmin toteuttamaan strategiaa: kuntien ja piirikuntien sekretäärit (sekretarz) ja skarbnikit (treasurer), kuntayhtiöiden (spółka komunalna) hallitusten puheenjohtajat ja jäsenet, yritysten toimitusjohtajat ja talousjohtajat sekä IT-päälliköt, jotka haluavat, että dokumentti vihdoin auttaa heitä budjettikeskustelussa. Virastojen strategioiden tyypillisistä virheistä kirjoitin erikseen artikkelissa IT-strategia JST:ssä (kuntien ja piirikuntien tason yksiköt): yleisimmät virheet. Tässä keskityn siihen, mitä itse dokumentin pitäisi sisältää.
Miksi strategiat päätyvät pöytälaatikkoon
Sen perusteella, mitä olen nähnyt julkisen ja yksityisen sektorin organisaatioissa, strategia on harvoin sisällöllisesti heikko. Se päätyy pöytälaatikkoon, koska sitä ei voi käyttää ensimmäisessä konkreettisessa päätöksessä.
- Se alkaa visiosta, ei inventaarista. Kukaan ei ole tarkistanut, mitä järjestelmiä, sopimuksia ja riippuvuuksia on jo olemassa, jolloin suunnitelma menee sivuraiteille ensimmäisen hankinnan kohdalla.
- Se kuvaa tavoitteet, ei järjestystä. Kaikki on tärkeää, jolloin mikään ei ole ensisijaista.
- Rahaa ei ole. Kun yhteys budjettiin puuttuu, strategia ja taloussuunnitelma elävät erillään toisistaan.
- Se ei muuta hankintatapaa. Uusia järjestelmiä ostetaan edelleen samalla tavalla kuin ennen, toimittajien tarjousten pohjalta, ei omien standardien pohjalta.
- Sillä ei ole omistajaa. Dokumentti hyväksyttiin valtuuston päätöksellä tai hallituksen päätöksellä, ja siihen sen elinkaari päättyi.
- Se on kirjoitettu IT-kielellä. Hallitus ja valtuusto (rada) eivät löydä siitä vastauksia omiin kysymyksiinsä: kuinka paljon, mitä varten, mitä tapahtuu, jos emme tee mitään.
Seitsemän elementtiä strategiassa, jota käytetään
- Nykytila. Rekisteri järjestelmistä omistajineen, sopimuksineen, lisensseineen, kustannuksineen ja tuen päättymisajankohtineen, prosessien ja integraatioiden kartta, riskirekisteri. Tämän puuttuessa jokainen seuraava kohta on arvausta. Tämä on inventoinnin tehtävä.
- Tavoitearkkitehtuuri. Yksinkertainen kuva siitä, miten rekisterit, prosessit, integraatiot ja käyttöoikeudet suhtautuvat toisiinsa. Kyse ei ole teknisistä kaavioista, vaan vastauksesta kysymykseen, mitkä järjestelmät ovat keskeisiä ja mitkä tukevat niitä, missä tiedon pitäisi syntyä ja mitkä järjestelmät perivät sen tiedon.
- Standardit. Muutama sääntö, joita sovelletaan jokaisessa hankinnassa: miten käyttöoikeudet myönnetään, miltä käyttöliittymän tulisi näyttää työntekijöille, miten vaatimukset dokumentoidaan, mitkä oikeudet dataan meillä on oltava, mitä kieltä (standardia) käytämme prosessien kuvaamiseen, miten varmistetaan yhteistyön päättämismahdollisuus.
- Tiekartta jaettuna velvoitteisiin ja investointeihin. Erikseen se, mitä meidän on tehtävä lain tai sopimuksen vaatimuksesta (virastoissa esimerkiksi EZD-luokan järjestelmä, KSeF, e-Doręczenia (Puolan e-toimitus)), ja erikseen se, mitä tehdään, koska se on kannattavaa. Perusteluineen ja järjestyksineen. Esimerkki: KSeF:stä ladatun laskun voi tallentaa asian asiakirjoihin, mutta lain mukaan sen tulisi saada sisällöllinen hyväksyntä, muodollis-laskennallinen tarkistus ja päättyä automaattiseen tallennukseen talous- ja kirjanpitojärjestelmään.
- Budjetti jaettuna investointiin ja ylläpitoon. Ylläpito kasvaa jokaisen uuden järjestelmän myötä, ja sen pitäisi olla näkyvissä ennen hankintapäätöksen tekemistä. Lisää tästä artikkelissa kokonaisomistuskustannuksesta. Muista, että käyttöönotto on yleensä kertaluonteinen investointi (CAPEX), mutta budjetin, toiminnan jatkuvuuden ja turvallisuuden näkökulmasta huolto ja päivitykset (OPEX) toistuvat vuosittain.
- Järjestelmien hankintaperiaatteet. Milloin inventointi tai analyysi tarvitaan ennen hankintaa, kuka arvioi tarjouksen, mitkä lausekkeet sopimuksessa on oltava. Osan näistä kuvasin artikkelissa SWZ (tarjouspyyntöasiakirja) ilman vendor lock-in -riippuvuutta.
- Omistaja ja katselmusrytmi. Nimetyn johtotason henkilön tulisi katselmoida strategiaa ja omistuskustannuksia vähintään kerran vuodessa budjetin laadinnan yhteydessä, noudattaen selkeää periodisuuden sääntöä näissä katselmuksissa.
Yksinkertaisin testi strategialle: voiko skarbnik (treasurer) tai talousjohtaja ensi vuoden budjettia valmistellessaan ottaa siitä suoraan kohdat ja niiden perustelut? Jos ei, strategia ja budjetti elävät erillään, ja IT-menoista päättää se, mikä sattuu olemaan kiireellistä.
Käytännön esimerkki
Yhtiö Wodociągi Miejskie, joka kuuluu keskisuurelle kunnalle, valmisteli IT-hankintasuunnitelmaa seuraavalle vuodelle. Alun perin IT-osasto esitti samanaikaista toimistotietokoneiden vaihtoa, uuden valvontajärjestelmän hankintaa ja verkkoinfrastruktuurin nykyaikaistamista. Hallitus pyysi kuitenkin osoittamaan, mitkä menot ovat kiireellisimpiä vedenjakelun jatkuvuuden näkökulmasta.
Yhtiö aloitti inventoinnista: se kokosi laitteet, ohjelmistot, verkkoyhteydet ja huoltosopimukset ja liitti ne sitten konkreettisiin prosesseihin – asiakaspalvelusta vedenkäsittelylaitosten ohjaukseen. Kävi ilmi, että osa laitoksiin viestintää välittävistä laitteista oli lähellä tukikautensa päättymistä, eikä yhteyksien dokumentaatio kattanut kaikkia sijainteja. Samaan aikaan suurin osa toimistotietokoneista pystyi toimimaan edelleen ilman merkittävää vaikutusta keskeisiin palveluihin.
Tämän perusteella hankintojen järjestystä muutettiin. Ensin suunniteltiin teknisten kohteiden yhteyksien järjestäminen ja suojaaminen sekä sellaisten laitteiden vaihtaminen, joiden vikaantuminen voisi vaikeuttaa vedenjakelun valvontaa. Seuraavaksi suunniteltiin varmuuskopioinnin ja valvonnan täydentäminen. Osan toimistotietokoneiden vaihto siirrettiin myöhempään vaiheeseen.
Hallituksen edessä IT-osasto ei enää perustellut budjettia yleisluontoisella toteamuksella, että "laitteisto on vanhaa". Se osoitti riippuvuuden: konkreettinen infrastruktuurin osa → tuettu prosessi → vikaantumisen seuraus → ehdotettu hankinta. Näin hallitus pystyi hyväksymään menot vaiheittain ja selittämään hallintoneuvostolle, miksi etusija annettiin palvelujen jatkuvuuteen liittyvälle infrastruktuurille, ei henkilöstölle näkyvimmälle toimistolaitteistolle.
Milloin tarvitaan riippumaton neuvonantaja
Strategian voi laatia omin voimin, jos organisaatiossa on henkilö, jolla on siihen aikaa ja joka näkee kokonaisuuden. Ulkopuolinen tuki on hyödyllinen, kun nykytilaa ei ole kirjattu ylös, kun strategian pitäisi toimia budjetin puolustamisen perustana valtuustolle, omistajalle tai keskushallinnolle, kun useita sääntelyvelvoitteita on tulossa samaan aikaan tai kun hallitus ja IT näkevät prioriteetit eri tavoin ja tarvitaan henkilö, joka kääntää yhden näkökulman toiselle.
Laadin digitalisaatiostrategian ja tavoitearkkitehtuurin inventoinnin pohjalta: tiekartalla, standardeilla, hankintaperiaatteilla ja budjetilla, jota voi puolustaa.