Mihin tarvitaan ei-toiminnallisia IT-vaatimuksia?

Useimmiten uuden IT-ratkaisun määrittelytyö keskittyy ratkaisun toiminnallisiin vaatimuksiin: Tietojärjestelmältä haluttuja toimintoja kuvataan käyttäjätarinoiden (user story), käyttötapausten (use case) ja käyttöliittymän näköismallien (wireframe/mockup) avulla. Toiminnalliset vaatimukset kuvaavat kattavasti ja yksityiskohtaisesti käyttäjän vuorovaikutuksen tietojärjestelmän kanssa. Ne määrittelevät, millä tavalla ja mitä syötteitä käyttäjä antaa tietojärjestelmään sekä järjestelmän antamat vasteet käyttäjän syötteisiin.

Tietojärjestelmän ei-toiminnalliset tai laadulliset vaatimukset (non-functional requirements) sen sijaan määrittelevät miten tietojärjestelmä antaa vasteet syötteisiin tai millainen se on. Ei-toiminnallisia vaatimuksia ovat esimerkiksi:

  • Saatavuus (availability). Jos IT-ratkaisun tulee olla käytettävissä 99 % ajasta, saako se olla pois käytöstä 14 minuuttia päivässä vai yhtäjaksoisesti 3,5 päivää vuodessa? Miten IT-arkkitehtuurilla ja toimintatavoilla varmistetaan, että ratkaisun suunnitellut ylläpitotoimenpiteet ja yllättävät virhetilanteet hoidetaan saatavuusvaatimukset täyttäen?
  • Skaalautuvuus (scalability). Jos IT-ratkaisu toimii 100 yhtäaikaisen käyttäjän kuormalla, niin toimiiko se samalla suorituskyvyllä myös 500 käyttäjän kuormalla? Miten IT-arkkitehtuurilla varmistetaan, että ratkaisu voidaan pienillä muutoksilla (infrastruktuuriin, alustaan tai sovellukseen) saada toimimaan myös 10000 käyttäjän kuormalla?
  • Siirrettävyys (portability). Jos IT-ratkaisu toimii Windows PC:llä, niin toimiiko se myös Applen Mac-tietokoneella (OS X), Samsungin Galaxy-puhelimella (Android) tai Nokian Lumia-puhelimella (Windows Phone)? Miten teknologiavalinnoilla varmistetaan ratkaisun alustariippumattomuus tai minimoidaan työ, joka vaaditaan ratkaisun siirtämiseen uudelle alustalle?

Muita ei-toiminnallisia vaatimuksia ovat esimerkiksi tietojärjestelmän tietoturvaan (security), käytettävyyteen (usablity), ylläpidettävyyteen (maintainability), räätälöitävyyteen (modifiability), integroitavuuteen (interoperability) tai suorituskykyyn (performance) liittyvät vaatimukset. Kuten yllä olevat esimerkit auttavat ymmärtämään, ei-toiminnalliset vaatimukset määrittelevät rajoitteita ja reunaehtoja tietojärjestelmän tekniselle toteutukselle ja hallinnoinnille.

Tietojärjestelmän ei-toiminnallisia vaatimuksia on haastavaa määritellä selkeästi, koska ne liittyvät järjestelmän sisäisiin ja teknisiin ominaisuuksiin. Uuden tietojärjestelmän vaatimuksia määriteltäessä kiinnostavat tyypillisesti eniten ratkaisun käyttäjälle tarjoamat toiminnot eli toiminnalliset vaatimukset. Kuitenkin ei-toiminnalliset vaatimukset voivat työmäärällisesti vastata useita kymmeniä prosentteja ratkaisun toteutuksen kokonaistyömäärästä.

Ei-toiminnallisilla vaatimuksilla on kriittinen rooli tietojärjestelmän laadun, luotettavuuden ja kustannustehokkuuden takaamisessa koko elinkaaren ajan. Panostus ei-toiminnallisten vaatimusten määrittelyyn heti alussa on tärkeää, koska ratkaisun toteutuksen jälkeen ei-toiminnallisia vaatimuksia voi olla hyvin työlästä tai jopa mahdotonta täyttää.

Realististen ei-toiminnallisten vaatimusten määrittelyyn tarvitaan yhdistelmä teknistä ja liiketoiminnallista ymmärrystä. Ei-toiminnalliset vaatimukset laatii tyypillisesti projektin suunnitteluvaiheessa IT-arkkitehti, joka tasapainottelee liiketoiminnan ja tietohallinnon tarpeiden sekä teknologian mahdollisuuksien välillä. Ei-toiminnallisten vaatimusten määrittelyssä tarvitaan kompromisseja ja vaatimusten välistä priorisointia (trade-off), koska useimmiten kaikkia vaatimuksia ei ole mahdollista toteuttaa käytössä olevilla rajallisilla resursseilla. Esimerkiksi ratkaisun suorituskyvyn parantaminen saattaa vähentää ratkaisun siirrettävyyttä tai integroitavuus saattaa vähentää tietoturvaa.

Yksinkertaistaen voisi sanoa, että ratkaisun toiminnalliset vaatimukset määrittelevät ratkaisun liiketoiminnallisen hyötypotentiaalin (prosessien mahdollistaminen, tehostaminen, tukeminen), kun taas ei-toiminnalliset vaatimukset määrittelevät ratkaisun luotettavuuden, kustannustehokkuuden ja teknisen mukautuvuuden tulevaisuuden tarpeisiin. Usein määrittelyvaiheessa eniten keskustelua herättävä ei-toiminnallinen vaatimus on järjestelmän saatavuus, jonka voidaan erityisesti liiketoimintakriittiselle järjestelmälle suoraviivaisesti vaatia olevan 100 %. Keskusteluun tuo perspektiiviä se, että AT&T:n puhelinverkko USA:ssa on ainut tekninen järjestelmä maailman historiassa, jossa on tiettävästi paikallisesti päästy 99,999 % saatavuuteen. Esimerkiksi Google tähtää palveluissaan 99,99 %:n saatavuuteen, mutta ei uskalla luvata käyttäjille sitäkään.

Lisätietoa:
The New York Times
Wikipedia

Tietojärjestelmäintegraatioiden ihanuus ja hurjuus

Kaikki nykypäivän tietojärjestelmäkokonaisuudet sisältävät integraatioita useiden eri tietojärjestelmien välillä. Käytännössä tietojärjestelmäintegraatiossa on kyse järjestelmissä olevan tiedon (datan) siirtämisestä järjestelmien välillä tietoverkon avulla. Integraatiossa tieto luetaan ohjelmallisesti lähdejärjestelmästä, jonka jälkeen tietoa voidaan muokata ennen sen tallentamista kohdejärjestelmään.

Integraatioiden avulla useista tietojärjestelmistä koostuva kokonaisuus saadaan tarjoamaan käyttäjilleen haluttu toiminnallisuus. Esimerkiksi verkkopankissa asioidessaan käyttäjän käyttöliittymä integroituu useisiin taustajärjestelmiin, joista yhdessä voi hallita maksuja, toisessa tehdä osakekauppaa ja kolmannessa käsitellä laina-asioita. Lisäksi kaikki edellä mainitut taustajärjestelmät integroituvat tilitransaktioiden hallintajärjestelmään, joka edelleen integroituu mm. vähittäiskauppojen maksupäätteisiin, pankkiautomaatteihin ja toisten pankkien tietojärjestelmiin.

Tietojärjestelmäintegraatiot ovat haastavia, koska integroitavat tietojärjestelmät voivat käyttää samaa tietoa eri tarkoituksiin, käsitellä samaa tietoa eri tavoin ja perustua eri teknologioihin. Halutun kokonaistoiminnallisuuden varmistamiseksi integraatioita toteutettaessa täytyy määritellä:

  1. tietosisällön rakenne (tietomalli, keskinäiset suhteet, attribuutit)
  2. tiedon käsittelysäännöt (tiedon oikeellisuus, omistajuus, transaktiosäännöt)
  3. tiedonsiirron tekniset periaatteet (väylät, standardit, protokollat, tilallisuus)

Esimerkkinä tietosisällön rakenteeseen (kohta 1 yo. listassa) liittyvistä integraatiohaasteista toimii e-reseptin suunnitteluvirhe, jonka takia osa reseptille tarkoitetusta tekstistä voi jäädä puuttumaan reseptiltä. Ongelman syynä lienee, että tietosisältö (mm. tietokenttien pituudet) ei ollut yksiselitteisesti ja yhtenäisesti määritelty kaikille e-reseptin tietoja käsitteleville järjestelmille ja osassa tietoa käsittelevistä järjestelmistä reseptin tekstikenttien merkkimääriä on rajoitettu (ks. YLE). Tästä seuraa, että vaikka lääkäri pystyykin onnistuneesti syöttämään reseptin tiedot järjestelmään käyttöliittymänsä kautta, jossain integraatioketjun vaiheessa järjestelmä ei pystykään tallentamaan tiedosta kuin esim. ensimmäiset 50 merkkiä. Tämän seurauksena apteekin käyttöliittymässä näkyy tietyssä kentässä vain 50 merkkiä.

Esimerkkinä tiedon käsittelysääntöihin (kohta 2 yo. listassa) liittyvistä integraatiohaasteista toimii Puolustusvoimien SAP HR –järjestelmän käyttöönotto puutteellisesti testattuna, jonka takia tuhansien työntekijöiden palkanmaksussa oli virheellisyyksiä ja viivästymisiä. Ongelman syynä lienee, että tiedon käsittelysäännöt (mm. tiedon oikeellisuuden varmistaminen) oli puutteellisesti määritelty ulkoisen tiedon tuonnin kannalta (toisista järjestelmistä), jonka takia uudessa järjestelmässä oli työntekijöiden peruspalkassa, tehdyissä työtunneissa ja pankkitileissä virheellisyyksiä (ks. HS tai Tietokone ). Tästä seurasi, että ajettaessa palkanlaskenta-ajo SAP HR –järjestelmässä tulokset olivat virheellisen tiedon takia väärin, vaikka itse ajon logiikka olisikin oltu testattu toimivan täydellisesti.

Esimerkkinä tiedonsiirron teknisiin periaatteisiin (kohta 3 yo. listassa) liittyvistä haasteista toimii suomalaisten teleoperaattoreiden kapasiteetin, VR:n maksupäätelaitteiden ja maksukorttien EMV-standardin vaatimusten keskinäiset riippuvuudet, jonka takia VR:n päätti lopettaa Visa Electronin hyväksymisen junissa (ks. YLE). Ongelman syynä lienee, että joko Visa Electron-kortille pankin online-tarkistuksen vaativa EMV-standardi tai VR:n maksupäätelaite ei salli sellaisia teknisiä viiveitä (latensseja), pakkausta tai protokollaa, jolla tietojärjestelmäkokonaisuus toimisi varmuudella suomalaisten mobiiliverkkojen kattavuudella ja kapasiteetilla. Tästä seuraa, että Visa Electron ei toimi aina junassa, vaikka tietosisällön rakenne ja tiedon käsittelysäännöt onkin pilkuntarkkaan määritelty.

Riippuen IT-projektista tietojärjestelmien väliset integraatiot saattavat muodostaa jopa puolet projektin kokonaistyömäärästä (verrattuna siihen, että tehtäisiin yksi monoliittinen sovellus, mikä ei usein ole edes käytännössä mahdollista). Siksi on tärkeää, että järjestelmän toiminnalliset vaatimukset ja käyttötapaukset kytketään integraatioiden suunnitteluun jo projektin aikaisessa vaiheessa. Tietojärjestelmäintegraatioissa onnistumisen varmistamiseksi on olemassa lukuisia teknisiä ja metodologisia hyviä käytäntöjä. Mikään ei kuitenkaan korvaa tärkeintä menestystekijää eli avointa, selkeää ja tehokasta osapuolten (usein eri toimittajien) välistä viestintää.

Verottajan uudet IT-kujeet

Verohallinnossa on lähdössä käyntiin massiivinen IT-projekti, jossa uudistetaan lähes kaikki verotuksessa käytettävät tietojärjestelmät. Verohallinnon nykyinen tietojärjestelmäkenttä on monimutkainen ja hajanainen, mikä aiheuttaa ylläpitoon kustannuspaineita (ylläpidon kokonaiskustannukset ovat 40 miljoonaa euroa vuodessa). Verohallinnon tietojärjestelmäuudistusprojekti tulee olemaan noin viisivuotinen ja budjetiltaan kymmeniä miljoonia euroja.

Uudistuksella tavoitellaan verohallinnon tietojärjestelmien kokonaiskustannuksista (total cost of ownership) leijonan osan muodostavien ylläpitokustannusten alentamista 20-40%. Lisäksi tavoitteena on parantaa tietojärjestelmien ketteryyttä (time-to-live) sekä pyrkimys kasvattaa verovirkailijoiden työn tuottavuutta (productivity).

Erityisen verohallinnon projektista tekee sen suuren koon lisäksi ratkaisun pohjaaminen kaupallisiin valmisohjelmistoihin (commercial-of-the-shelf, COTS). Valmisohjelmistoilla pyritään ratkaisun sisäiseen standardointiin ja rakentamaan järjestelmä, joka on muuallakin vastaavan laajuisessa vaativassa käytössä.

Tarkoituksena on valjastaa suuri määrä valmisohjelmistoja verohallinnon tarpeisiin. Haasteen asettaa se, että mikään valmisohjelmisto ei luonnollisesti voi suoraan paketista tukea suomalaisen verohallinnon prosesseja, joten tarvitaan ratkaisujen räätälöintiä. Julkisuudessa lausuttujen tavoitteiden mukaan räätälöinnit pyritään minimoimaan, mutta kysymys kuuluukin, miten tämä käytännössä saavutetaan?

Kun projektin tavoitteena on toteuttaa tietojärjestelmä valmisohjelmistoilla, hyvän ratkaisuarkkitehtuurin (solution architecture) suunnittelu sekä projektin laajuuden hallinta (scope management) ovat avainasemassa. Tavoitteena on, että valmisohjelmistojen ominaisuuksia käytetään optimaalisesti ja ratkaisun räätälöintiä tehdään sopivasti.

Ratkaisuarkkitehtuurin tulee määritellä, millä valmisohjelmistolla kukin kokonaisratkaisun toiminnallinen vaatimus (functional requirement) toteutetaan, miten ei-toiminnalliset vaatimukset (non-functional requirement) otetaan huomioon, huolehtia valmisohjelmistojen keskinäisestä yhteensopivuudesta (interoperability) sekä tarpeen mukaan määritellä täydentäviä ratkaisun komponentteja, jotka eivät perustu valmisohjelmistoihin. Ratkaisuarkkitehtuurin puutteellisuudesta johtuvia tyypillisiä ongelmia ovat valmisohjelmistojen epäselvät tehtävät, epärealistiset ei-toiminnalliset vaatimukset, valmisohjelmistojen yli- tai aliräätälöinti tai niiden yhteensopimattomuus.

Projektin laajuuden hallinnan tulee pitää huolta, että tietojärjestelmän kokonaisuudistustavoitteesta huolimatta ei sorruta valmisohjelmistojen yliräätälöintiin. Joskus projektin tilaaja (liiketoiminta) voi nähdä, että projektin suuri koko oikeuttaa myös toiminnallisten vaatimusten monimutkaistamisen tai lukumäärän kasvattamisen, jopa projektin aikana. Tämä on usein myös toimittajan intressi, koska se tietää toimittajalle lisää työtä. Tällaisessa tilanteessa projektipäällikön ja projektiohjausryhmän tulee kysyä: onko todella niin, että valmisohjelmiston standardina (tai pienellä räätälöinnillä) tarjoama toiminnallisuus ei riitä, vaan suurempaa räätälöintiä todella tarvitaan. Päätöksissä on tärkeää huomioida, että räätälöimällä ratkaisua menetetään joka askeleella valmisohjelmistojen tuomia ratkaisun standardointiin ja ylläpitokustannusten alentamiseen liittyviä hyötyjä.

Verohallinnon edellinen tietojärjestelmäuudistus 1990-luvulla tuotti kansalaisille sähköisen veroehdotuksen ja jatkokehitys 2000-luvulla on entisestään parantanut verohallinnon sähköisiä palveluita. Verohallinnon aiempia uudistusprojekteja voisi pitää jopa julkishallinnon malliesimerkkinä asiakasprosesseista lähtevästä tietojärjestelmäkehityksestä. Toivotan verohallinnolle ja toimittajille voimia ja onnea seuraavaan vaativaan hankkeeseen!

Lisätietoa: Tietoviikko

300 miljoonan euron sairasta IT-leikkiä terveydellä

Eduskunnan tarkastusvaliokunta on uudessa selvityksessään iskenyt kyntensä julkisen terveydenhuollon tietojärjestelmiin. Esimerkiksi vuonna 2010 näiden kehittämiseen käytettiin veronmaksajien rahoja noin 300 miljoonaa euroa. Mitä sillä saatiin? Huonosti yhteensopivia ja käytettävyydeltään monimutkaisia järjestelmiä, jotka tuhlaavat hoitohenkilökunnan aikaa ja pahimmillaan vaarantavat potilasturvallisuuden.

Hovitoimittajat ovat varmasti tilanteesta kiitollisia: ensin TEKES tukee heidän ”tuotekehitystään”, sitten näitä ”tuotteita” otetaan käyttöön massiivissa konsultointiprojekteissa veronmaksajien rahoilla ilman kunnon kilpailutusta ja lopulta, kun ”tuotteet” osoittautuvat kelvottomiksi, niin toimittajat pääsevät kuin koira veräjästä veronmaksajien kuittatessa laskun. Asian saaman julkisuuden takia saattaa näiden vastuuttomien toimittajien perävalotakuu-taktiikka kuitenkin lopulta epäonnistua.

Aiemmin myös Valtiontalouden tarkastusvirasto on kunnostautunut terveydenhuollon tietojärjestelmähankkeiden moittimisessa: tietojärjestelmät eivät ole käyttäjäystävällisiä, ja sama tieto pitää kirjata useaan järjestelmään, koska tiedot eivät siirry virheettömästi järjestelmien välillä. On arvioitu, että vuodessa menee tietojärjestelmien takia hukkaan noin 600 lääkärityövuotta. Tämäkin arvio saattaa olla alakanttiin!

Mistä ongelmat sitten johtuvat ja mitä asialle pitäisi tehdä? Täysin ulkopuolisen näkemykseni mukaan ongelmat ovat erityisesti hankkeiden valmistelussa. Hankkeita ei valmistella tarpeeksi liiketoiminta- ja käyttäjälähtöisesti ratkaisujen konseptoinnin ja kokonaisarkkitehtuurisuunnittelun kautta, vaan hankkeet toteutetaan teknisistä lähtökohdista ja vailla kokonaisymmärrystä todellisista liiketoiminnan tavoitteista ja tarpeista. Koska toimittajat valitaan pienestä sisäpiiristä ilman todellista kilpailua, toimittajien intressi on pönkittää omaa asemaansa paisuttamalla projekteja ja tekemällä järjestelmistä entistä yhtyeensopimattomampia ja suljetumpia, jotta toimittajista tulee korvaamattomia.

Ehdotukseni kolmeksi keskeisimmäksi painopisteeksi julkisen terveydenhuollon tietojärjestelmien kehitykseen tulevaisuudessa on: 1) vahvan liiketoiminta-, prosessi-, arkkitehtuuri- ja konseptointiosaamisen ottaminen mukaan järjestelmien määrittelyyn, 2) toimittajien aito kilpailuttaminen ja arviointi kompetenssin perusteella toteuttamaan määrittelyjen mukainen tietojärjestelmä, 3) toimittajien teknisen työn ja projektinhallinnan ohjaus ja valvonta toteutusvaiheessa, jotta hankkeen etenemisestä on selkeä käsitys, toimittajalukot (vendor lock) voidaan välttää ja ongelmatilanteessa vaihtaa toimittajaa ajoissa.

Näissä kolmessa menestystekijässä on kyse toimintatapojen muuttamisesta, tuottavuudesta ja tehokkuudesta enemmän kuin merkittävistä taloudellisista lisäinvestoinneista. Ulkopuolisen riippumattoman neuvonannon kustannus on tyypillisesti vain muutamia prosentteja investointien kokonaisuudesta. Se ei ole suuri kustannus, kun tuloksena on käyttäjäystävällinen, työskentelyä tehostava ja luotettava tietojärjestelmäkokonaisuus.

Lisätietoa: Yle