– superstrategisia valintoja –
Tietojärjestelmät ovat nyt jo merkittävä osa palvelutuotantoa, niin julkista kuin yksityistäkin. Automatisoinnin jatkuva lisääntyminen tarkoittaa tietojärjestelmien merkityksen jatkuvaa kasvua.
Kun vanhemmat vievät lapsensa päivähoitoon, tarvitaan tietojärjestelmää joka välissä. Tietojärjestelmän ominaisuudet ja määritykset asettavat käytännössä rajat sille, miten kommunikointi vanhempien ja kunnan suuntaan tapahtuu, minkälaisia palvelumalleja (koko päivä, puolipäivä jne.) voidaan tarjota, miten laskutus tapahtuu (määrät, tulojen huomioiminen, ostosetelit), miten poikkeustilanteet hoidetaan jne. Tämä on nykypäivää ja tulevaisuudessa tietojärjestelmien rooli on vain merkittävämpi.
Päätöksenteko toiminnan järjestämiseen liittyvissä tietojärjestelmissä on vähimmilläänkin strategista: ne vaikuttavat toimintaan 5-10 vuotta tai pidempäänkin. Tietojärjestelmien mahdollisuudet tai rajoitukset vaikuttavat palvelujen tarjontaan koko järjestelmän elinkaaren ajan. Kun katsotaan terveydenhuollon järjestelmiä, jos niitä vielä aiotaan levittää useisiin sairaanhoitopiireihin ja kuntiin, muuttuu vaikutuksen aikayksikkö selvästi pidemmäksi, 15-20 vuodeksi. Kyse on todella superstrategisesta päätöksestä.
Tietojärjestelmiin liittyy vielä sellainen erityisyys, että teknologian omistaja (ja osin toimittaja) on järjestelmän tekijänoikeuksien haltija ja tällä on tekijänoikeudesta johtuva, lakiin perustuva yksinoikeus määrätä järjestelmän käyttämisestä, muuttamisesta ja levittämisestä. Tämä kriittinen erityispiirre muodostaa strategisissa ja superstrategisissa päätöksissä erityisen huolenaiheen. Teknologian omistaja ja toimittaja määräävät tietojärjestelmistä. Ellei ostaja varaudu tähän, on tietojärjestelmän ylläpito, toiminta ja kehitys aina alisteinen teknologian omistajan ja toimittajan tahdolle. Yksittäisen ostajan varautuminen ei riitä tilanteessa, jossa samaa järjestelmää pyritään saamaan käyttöön esimerkiksi useissa sairaanhoitopiireissä ja kunnissa. Jotta kokonaisuus voisi toimia, on ostajan määräysvalta tietojärjestelmästään yhtä suuri kuin kokonaisuuden piirissä olevan heikoimman ostajan määräysvalta.
Suurimmat virheet
Törmään yhä liian usein käsitykseen, että ”tietojärjestelmien tulee vain toimia, emme ole kiinnostuneet detaljeista”. Tämä käsitys on valtava virhe ja valtaosin tietotekniikan ammattilaiset pitävät tätä huolta vanhentuneena: ”eihän kukaan johtaja enää ajattele näin”. Valitettavasti tätä käsitystä on silti liikaa ja CIO-johtajat eivät ole aina osa strategista johtoa. Tällöin tietojärjestelmää ei nähdä strategisena päätöksenä, mikä johtaa siihen, että teknologian omistajan ja toimittajan vallassa on, toteutetaanko ostajan strategiset päätökset ja millä ehdoin.
Virheellistä on myös keskittyä vain siihen, että ”nyt sovituilla uusilla ominaisuuksilla saamme tehostettua toimintaa nykyiseen verrattuna”. Tällöin ostaja määrää ensimmäisen 1-3 vuoden strategisista valinnoista ostamisen yhteydessä, mutta jättää 4-20 vuoden aikaikkunan strategiset valinnat teknologian omistajan ja toimittajan valtaan.
Ja on aivan turha luulla, että kansainvälinen teknologian omistaja pyrkisi joustavasti palvelemaan ohjelmistonsa käyttäjäorganisaatioita, ellei heidän ole pakko tehdä näin. Teknologian omistajan kehityspolut, jos niitä seurataan purematta, johtavat sellaiseen lukittautumiseen, että valtaa ostajalla ei ole. Kotimainen toimittajakaan ei voi tähän vaikuttaa, ja vaikuttaminen ei yleensä ole toimittajan intresseissäkään, ellei ostaja sellaista mahdollisuutta itselleen järjestä ja vaadi.
Ratkaisu
Eli ostajan on ajateltava (super)strategisesti hankkiessaan tietojärjestelmää. Miten ostaja ottaa kontrollin tietojärjestelmistään? Miten ostaja hallitsee superstrategisia päätöksiään?
Vastaus löytyy yhdistelmästä, joka perustuu avoimeen arkkitehtuuriin ja hyödyntää avoimia rajapintoja, ja mieluiten myös avointa lähdekoodia. Vielä tulee välttää mammuttikoon tietojärjestelmiä ja pyrkiä muodostamaan kokonaisuus modulaarisesti avoimen arkkitehtuurin ja avoimien rajapintojen pohjalta.
Arkkitehtuurilla tarkoitetaan lyhyesti eri tietojärjestelmien ja niiden välisten yhteyksien muodostaman kokonaisuuden rakennetta. Yksinkertaistava esimerkki: ”tietomme tallennetaan sovitulla tavalla tuonne ja tällä tavalla kaikki eri ohjelmat hakevat tietoja tallennuspaikasta ja vievät tietoja sinne”. Avoin arkkitehtuuri mahdollistaa toisiinsa helposti liitettävien ratkaisujen toteuttamisen ja antaa riippumattomuuden valita paras toimittaja kulloiseenkin työhön. Alla on linkkejä tarkempiin tietoihin.
Linkkejä lisätietoon
Mitä on avoin arkkitehtuuri, avoimet rajapinnat ja avoin lähdekoodi ja miten ne auttavat ratkaisussa: Jouko Poutanen (IBM) ja Janne Hietala (Arcusys) kertovat hyvät pohjatiedot
http://coss.fi/avoin-arkkitehtuuri-tie-onneen/
Miten asia voidaan tehdä oikein? Yhtenä esimerkkinä voi käyttää Tampereen kaupungin hankintaa Ixonokselta, koskien lapsiperheiden palveluiden tuottamista: http://www.ixonos.fi/2012/06/ixonos-julkaisee-lapsiperheiden-palvelujen-tuottamiseen-soveltuvan-avoimen-lahdekoodin/. Tässä esimerkissä on menty ns. parhaimman kautta ja lähdekoodit ovat kenen tahansa saatavilla http://github.com/ixonos osoitteessa.
Lisää näkökulmia huonoista strategisista valinnoista ja niiden seurauksista ja niiden välttämisestä:
- Ilkka Lehtinen (Suomen avoimien tietojärjestelmien keskus – COSS ry) herättelee lukijoita artikkelissa ”Mene suoraan vankilaan, kulkematta lähtöruudun kautta” http://coss.fi/mene-suoraan-vankilaan-kulkematta-lahtoruudun-kautta/ . Näkökulmana myös suomalainen työ ja osaaminen.
- Otso Kivekäs (Codento Oy) kirjoittaa toimittajaloukun välttämisestä http://otsokivekas.fi/2012/07/toimittajaloukku-ja-kuinka-se-valtetaan/
Muodostuuko hankintalaki ongelmaksi? Outi Jousi ja allekirjoittanut selittävät, kuinka hankintalaki ei ole ongelma, vaan sitä on vain sovellettava oikein: http://coss.fi/hankintalaki-helvetinkone-vai-tie-taivaaseen/.
Martin von Willebrand
Martin von Willebrand on asianajaja, osakas ja teknologiaryhmän vetäjä Asianajotoimisto HH Partnersilla sekä hallituksen ja ohjausryhmän jäsen Suomen avoimien tietojärjestelmien keskus – COSS ry:ssä. Hän on Kuntaliiton nimittämä asiantuntija valtionvarainministeriön Avoimuuden hallinta -työryhmässä. Hän neuvoo yrityksiä ja organisaatioita lukuisissa teknologian hyödyntämiseen liittyvissä oikeudellisissa kysymyksissä ja hänen asiantuntemustaan alalla suositellaan laajalti (mm. Legal 500, Chambers Europe, Best Lawyers ja useat muut julkaisut).
Intellectual Transit Zone 
Jo ensimmäisestä lauseesta huomaa, että asialla on konsultti. Ja jatko vahvistaa ensivaikutelman.
Hieman vaikuttaa siltä, että kirjoittan käsitys tuotteen ja sovelluksen eroista on häilyvä?!
@Lauri Gröhn
Kiitos kommentista. Voisitko ystävällisesti jatkaa, miten näet tuotteen ja sovelluksen erojen vaikuttavan blogin aiheeseen tai esille nostamiini ratkaisuihin? Siis mikäli näet vaikutusta olevan.
Mielelläni vastaan ajatuksesi asiasisältöön, mutta nyt se ei käy riittävästi ilmi.
Automaatiota ja tietojärjestelmiä ei voi käsitellä samassa kontekstissa.
Hankintaprosessi on täysin erilainen riippuen siitä onko kohteena tuote vaiko räätälöity sovellus.
@Lauri Gröhn
Kirjoituksessani tarkoitan yleiskielistä “automatisoitumista”, en “automaatiota”, esimerksi tehdasautomaatiota. (Tehdasautomaatiota on esimerkiksi kahvin paahtamiseen käytettyjen tehdaslaitteistojen, kuten paahtimon, automaatio. Tällainen automaatio on toiminnanohjausjärjestelmiin nähden ns. matalamman tason järjestelmä eli laiteläheisempi järjestelmä. Automaation osalta ostajan huoli kontrollista on selvästi vähäisempää kuin mitä blogissa kuvaan.)
Tietojärjestelmien ammattilaiselle termi “automatisoituminen” ei ole tavallinen, mutta termi on perusteltu, koska tässä intellectual transit zone -blogissa käsitellään tulevaisuutta. Toiminnanohjausjärjestelmät ovat nykypäivän automatisoitumista, tietynlainen robotisaation esiaste. Blogin alku tavallaan kytkee huoleni tietojärjestelmien kontrollista tähän tulevaisuusblogiin. Eli tällä perustelulla pidän kiinni termieni valinnasta 🙂 !
Toiseen huomioosi liittyen: olen samaa mieltä, hankinprosessit ovat erilaiset tuotetta tai räätälöityä sovellusta/järjestelmää hankittaessa. Nämä erot eivät kuitenkaan blogin strategisella tasolla vaikuta esille nostamiini huoliin tai ratkaisuihin. Eräs virhekäsitys on syytä mainita tässä: välillä törmään ajatukseen, että kun hankitaan tuote, eikä räätälöity sovellus, on lukittautumisriski (tai päätäntävallan luovuttamisen riski) pienempi. Tämä ei enää ole näin, tilanne on itse asiassa usein aivan toisinpäin.
Aikanaan räätälöityä sovellusta hankittaessa lukittautuminen yhteen toimittajaan syntyi tavallaan sivutuotteena, ilman että ostaja tai toimittaja siihen pyrkivät: siihen vain ajauduttiin. Ajateltiin, että tuote hankkimalla, ostetaan standardilla tavalla esim. tietokantoja käyttävä sovellus, joka noudattaa hyvin tutkittua kehityspolkua. Todellisuus on ikävä kyllä toinen: isot kansainväliset teknologiaomistajat suunnittelevat tuotteidensa kehityspolut niin, että ne johtavat lukittautumiseen. Polut pilvipalveluihin ja niiden toteutukset ovat hyvä esimerkki tästä. Mutta muutenkin: tuotteiden keskinäiset riippuvuussuhteet, hinnoittelumallit, tiedostoformaatit ja tietovarantojen käyttötavat ovat sellaisia, että ne rakentavat sidonnaisuutta kyseiseen teknologian omistajaan.
Näinpä ollen esille nostamani huoli ja ratkaisumalli soveltuvat yhtä hyvin räätälöityjen sovellusten hankintaan kuin tuotteen hankintaan. Taustalla olevat intressit ovat kyllä erilaiset ja se varmasti vaikuttaa hankintaan ja ratkaisujen soveltamistapaan.
OK. Selveni.
OHO – maailmankirjat sekaisin. Lauri Gröhnille jokin asia selveni eikä siitä tarvitsekaan kirjoittaa jokaisella keskustelupalstalla vuosia eteenpäin 🙂