Maksaako esiselvitys vaivan?

Esiselvityksen tärkein tehtävä on varmistaa, että projektista saatavat hyödyt ovat todellisia, toteutettavissa olevia, rahaksi muutettavissa ja kuluja suurempia.  Hyödytöntä projektia ei pidä toteuttaa – ei, vaikka budjetissa olisi ylimääräistä rahaa.

Miksi esiselvittää?

Ennen projektia on tapana tehdä esiselvitys. Joskus esiselvitys tehdään, koska niin on ollut aina tapana tehdä. Joskus esiselvitys tehdään osana kilpailutusta, jolloin esiselvitys on osa kilpailutusdokumentaation tekemistä. Joskus esiselvitys tehdään, koska budjetissa on rahaa ja se on syytä käyttää – selvitetään siis onko rahan käyttäminen johonkin tarkoitukseen mahdollista teknisesti, osaamisen suhteen ja monelta muulta kannalta.

Kaikki nämä näkökannat ovat tärkeitä. Onhan ennen projektia tiedettävä

  • mitä on tarkoitus saada aikaan,
  • miten se on tarkoitus saada aikaan,
  • kuka sen tekisi ja
  • paljonko asian tekeminen maksaisi. 

Nämä tiedot eivät kuitenkaan vielä riitä. Yksi olennainen asia jää puuttumaan. Jokaisen projektin tarkoituksena on nimittäin luoda jotain hyötyä jollekulle. Projekti on perusteltavissa, jos siitä saadut hyödyt ovat suuremmat kuin projektin kulut. Mikäli kulut lopulta osoittautuvat suuremmiksi kuin hyödyt, on projekti epäonnistunut vaikka se olisi pystytty toteuttamaan aikataulussa ja jopa budjetoitua halvemmalla. Epäonnistuneeseen projektiin käytetyt voimavarat olisi pitänyt käyttää johonkin hyödylliseen.

Esiselvityksen tärkein tehtävä on varmistaa, että projektista saatavat hyödyt ovat todellisia, toteutettavissa olevia, rahaksi muutettavissa ja kuluja suurempia.  Tämän selvittämiseksi on toki syytä tutkia toteutusteknologioita, käytössä olevien henkilöiden osaamista, markkinoilta saatavissa olevia valmisjärjestelmiä ja montaa muuta seikkaa. Todellista merkitystä on kuitenkin ainoastaan hyödyillä. Hyödytöntä projektia ei pidä toteuttaa – ei, vaikka budjetissa olisi ylimääräistä rahaa.

Mitä hyödyt ovat?

ICT-projekti, kuten mikä tahansa projekti, voi auttaa organisaatiota (yritystä, ministeriötä, tms.) tekemään nykyiset tehtävät paremmin, tekemään uusia asioita tai välttämään joidenkin asioiden tekemisen kokonaan. Osaa hyödyistä voi mitata suoraan rahana (esimerkiksi tarvittavien raaka-aineiden määrän vähenemisenä), osan jonain muuna mitattavana suureena (esimerkiksi säästyneenä työaikana) ja osan voi havaita, muttei mitata tarkasti (esimerkiksi parantuneena maineena tai muuna vaikeammin rahaksi muutettavana suureena). Kaikki nämä hyödyt ovat hyviä perusteita projektin toteuttamiselle, joskin pelkästään maineen parantumisella perustellut projektit osoittautuvat myöhemmin vain vähän hyötyä luoviksi.

Hyötyjen suunnitteleminen ja arvioiminen on hankalaa

Hyötyjen arvioiminen tarkasti ja realististisesti on vaikeaa. Tutkimusten – ja yleisen projektikokemuksen – mukaan hyödyt usein yliarvioidaan. Tämä on inhimillistä, onhan onnistumisen ennustaminen kivempaa kuin epäonnistumisen. Esiselvityksen tekijä saattaa olla myös projektin toteuttaja – silloin on vaikeata sanoa, ettei projektista olisi hyötyä. Säästyneen työajan käyttäminen tuottavasti saattaa osoittautua paljon hankalammaksi toteuttaa kuin esiselvityksessä on arvioitu. Toisinaan näet säästynyt työaika pitäisi realisoida hyötynä irtisanomalla henkilöstöä. Mikäli tämä on tarkoitus, on irtisanomista sovittava jo esiselvityksen aikana ja ne on toteutettava ajallaan. Tätä tapahtuu hyvin harvoin.

Hyötyjen tarkkaa arviointia ja suunnittelua vaikeuttaa myös se, että esiselvitystä tekemässä harvoin ovat henkilöt, joille projektista olisi hyötyä ja joiden pitäisi toteuttaa prosessi- ja henkilöstömuutokset, joiden avulla projektin hyödyt saadaan aikaiseksi. Esiselvitystä ja hyötyjen suunnittelua ei voi tehdä vain tietohallinnon ja konsulttien voimin, vaan mukaan on otettava laaja joukko uuden järjestelmän käyttäjiä.

Tarkistuslista: kannattaako projekti toteuttaa esiselvityksen perusteella?

Esiselvityksessä on siis pystyttävä arvioimaan projektin hyödyt mahdollisimman tarkkaan. On myös luotava – yhdessä hyödyn toteuttajien ja saajien kanssa – tarkka suunnitelma hyötyjen toteuttamisesta projektin aikana ja erityisesti projektin valmistuttua. Projektin hyödyt toteutuvat vähitellen uuden järjestelmän ja uusien toimintatapojen myötä. Hyötyjen toteutumista on seurattava koko projektin ajan ja verrattava toteutumaa esiselvityksessä suunniteltuun. Mikäli hyödyt eivät projektin aikana toteudu suunnitellusti, on harkittava projektin keskeyttämistä. Rajalliset resurssit on syytä siirtää hyödyttömästä tekemisestä hyödylliseen mahdollisimman aikaisessa vaiheessa.

Esiselvityksen hyötysuunnitelman tarkistamiseen voi käyttää esimerkiksi seuraavaa tarkistuslistaa. Mitä vähemmän listalla on kyllä-vastauksia, sitä epävarmemmalla pohjalla projektin kannattavuus on.  

#KysymysKyllä/Ei/Osittain
1.
Ovatko kaikki hyötyjen saamiseksi vaadittavat kustannukset
tiedossa - myös käyttäjien prosessimuutokset,
henkilöstöjärjestelyt, koulutukset ja vaikkapa toimitilamuutokset?
2.Ovatko käyttäjät ja heidän esimiehensä sitoutuneet yksimielisesti
uuden järjestelmän käyttöönottoon ja sen vaatimiin muutoksiin
toiminnassa?
3.Ovatko kaikki hyödyt selkeästi ilmaistut säästettynä rahana, kasvaneena
liikevaihtona, pienentyneenä riskinä tai jonkin
strategisen tavoitteen määrällisenä täyttymisenä?
4.Liittyvätko hyödyt todellakin hankkeen päätarkoitukseen vai
syntyvätkö ne hankkeesta riippumatta?
5.Onko hyödyistä sovittu hyötyjen saajien kanssa ja ovatko
hyödyt mukana budjeteissa, henkilöstövähennyksissä,
strategioissa ja henkilökohtaisissa tavoitteissa, ja onko
mahdollisiin YT-neuvotteluihin varauduttu?
6.Käykö liiketoimintasuunnitelmasta selvästi ilmi, että aiempien
projektien kokemukset on otettu huomioon?
7.Onko väitettyjen tehokkuusparannusten toteutumismekanismi
selvä: esim. pienempi budjetti, vähemmän työntekijöitä,
säästyneen työajan käyttö johonkin tuottavaan?
8.Onko varmaa, ettei hyötyjä ole liioiteltu? Onko hyötyjä verrattu
edellisten projektien ja hankkeiden toteutumiin?
9.Onko olemassa kirjallinen suunnitelma, josta käy ilmi miten
hyödyt toteutuvat, kuka on vastuussa toteutumisesta, milloin
hyödyt toteutuvat ja miltä maailma näyttää hyötyjen
toteutumisen jälkeen?
10.Onko liiketoimintasuunnitelmassa otettu huomioon hyötyjen
hallinnointiin, seuraamiseen ja raportointiin liittyvät
kustannukset?
Bonus 1Onko mahdollista, että esiselvityksen perusteella päätetään
olla ryhtymättä projektiin? Jos ei, mitä merkitystä
esiselvityksellä on?
Bonus 2Ovatko hyödyt selkeästi kustannuksia suuremmat?
Bonus 3Onko projekti paras tapa suunniteltujen hyötyjen
toteuttamiseen? Onko olemassa muita tapoja?

Tämän artikkelin on kirjoittanut Matti Kinnunen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

IT-työn flow – Codenton uutiskirje 02/2016

Välitä tämä uutiskirje ja voita Flow-liput!

Jos pidät tästä uutiskirjeestä ja tulee mieleen, kuka voisi tykätä myös:
Välitä uutiskirjeen linkki kollegalle tai kaverille sähköpostilla (laita cc:ksi markkinointi@codento.com) tai twiittaa se 24.2. mennessä. Osallistut kahden 3 päivän passin arvontaan Flow-festareille elokuussa Helsingin Suvilahdessa. Ilmoitamme onnekkaalle lippujen omistajalle voitosta henkilökohtaisesti. Siispä kirje jakoon ja liput taskuun!

Liity uutiskirjeen tilaajaksi, niin saat uutiskirjeet jatkossa tuoreeltaan:




Mukavaa helmikuuta!

Työn imu: minuutit kiitävät, ja olet onnellisen täydellisesti uppoutunut siihen, mitä olet tekemässä. Miten IT-työläinen voi itse vaikuttaa oman työn imuun? Mitä työnantaja voisi tehdä flown edistämiseksi? Ajatuksia tässä uutiskirjeessä:

  • Syvätyö ja työn imu
  • Ja mikä se flow nyt taas olikaan?
  • Slack Codenton arjessa
  • 6 vinkkiä työn imun suojelemiseen
  • Flown kehittämisestä jatkuva

Syvätyö ja työn imu

The Economistin tuore artikkeli summaa tyypillisimmän tämän päivän ongelman töihin keskittymisessä. Kun organisaatiot yliarvostavat vuorovaikutusta ja yhteistyötä, niin sanottu syvätyö, yhtäjaksoinen asioihin paneutuminen, kärsii.

Harvard Business Reviewn artikkeli taas kertoo, miten työnantajan kuuluisi tähän reagoida. Tiivistettynä: pitäisi mitata yhteistyöhön käytettävää aikaa, palkita auttamisen sankarit ja huolehtia tällä tavoin, että kollaboraatio jakautuisi tasaisemmin työntekijöiden kesken.

Ja mikä se flow nyt taas olikaan?

Klassinen flow-käsitteen isä Mihaly Csikszentmihalyi selittää Ted-puheessaan 20 minuutissa imun konseptin ja erittelee, millaisten olosuhteiden vallitessa flow yleensä tutkitusti virtaa. (Samalla hän tulee kertoneeksi myös, miten tapasi vahingossa Carl Jungin.)

Time pistää artikkelissaan Csikszentmihalyin työn historialliseen kontekstiinsa.

Slack Codenton arjessa

Codento on nyt parin vuoden ajan käyttänyt Slackiä sisäiseen pikaviestintään koko yrityksen laajuisesti. Tuloksena on ollut kollegiaalista tukea, asioiden yhdessä työstämistä ja itse tehtyjä emojeja.

6 vinkkiä työn imun suojelemiseen 

Mitä sitten voi tehdä, kun määräaika on kohta paukahtamassa ja kollegat juoksevat ovella? The Muse listaa käytännöllisiä keinoja työrauhan suojelemiseen avokonttorissa ja Slackin äärelläkin – ja kertoo myös, miten keskeytyksen jälkeen voi saada uudelleen kiinni ajatuksen päästä.

Flown kehittämisestä jatkuvaa

Flow-tilan saavuttamisesta mahdollisimman säännöllisesti on hyötyä sekä työntekijälle itselleen, työnantajalle että asiakkaalle. Codenton Miika Kuha kertoo blogauksessaan, miten flown kehittämiseen kannattaisi suhtautua, jotta omasta oppimisesta saa jatkuvaa.

Kalvosarjassaan Miika vielä avaa jatkuvan parantamisen ja 5S-tekniikan käytännössä:

Työn imua kevääseesi!

Petri ja koko Codento-tiimi

Haluatko tutustua aiempiin uutiskirjeisiimme?

Jos haluat lukea aiempia uutiskirjeitämme, tässä linkit muutamaan niistä.

Leanillä tehoa liiketoimintaan (12/2015)
Lisenssit ja avoin lähdekoodi (09/2015)
Aamiaisseminaarin antia: tietojärjestelmien omistusoikeudet (06/2015)
Tiedolla johtaminen tuo parempia tuloksia (08/2014)
Inspiraatiota uuden IT:n päättäjille (06/2014)
Uutiset IT:n päättäjille (03/2014)

***

Ylempi kuva: Flickr Creative Commons, meridican.

Digitalisaatio ei etene kokonaisarkkitehtuuria virittämällä

Sipilän hallituksen tavoitteena on Suomen digitalisointi. Sama tavoite on eri sanamuodoin ilmaistuna ollut jo edellisten hallitusten ohjelmissa. Digitalisaatio kuitenkin etenee ja on edennyt hitaasti: julkiset palvelut ovat yhä paljolti paperityötä vaativia, hankalia käyttää eivätkä tiedot siirry viranomaiselta toiselle jouhevasti. Miksi digitalisaatio ei etene vahvasta poliittisesta tahdosta huolimatta?

Digitalisaatiota on pyritty toteuttamaan erityisesti kokonaisarkkitehtuuria kehittämällä. Tulokset ovat olleet huonoja ja onnistumiset paikallisia, eivät laajoja kokonaisuuksia muuttavia ja parantavia. Hyvä tahto, yhteiset menetelmät ja suuri määrä työtä eivät ole riittäneet digitalisaatioloikan ottamiseen. Samalla kuitenkin Virossa on onnistuttu digitalisoinnissa merkittävästi paremmin, nopeammin ja vieläpä vähemmällä työllä.

Työkalut kunnossa

Voisiko syy löytyä vääristä työkaluista? Suomessa keskeisenä digitalisaation työkaluna on ollut vuodesta 2011 JHS-suositus 179. Sen hyväksyi julkisen hallinnon tietohallinnon neuvottelukunta JUHTA 7.2.2011 ICT-palvelujen kokonaisarkkitehtuurin kehittämistä koskevaksi suositukseksi. Suositus perustuu 1990-luvulta asti kehitettyyn TOGAF-arkkitehtuurimalliin. Siitä on Suomessa laadittu JHS 179:n lisäksi myös korkeakouluissa ja valtionhallinnossa laajasti käytetty Kartturi-malli.

TOGAF on hyvä, kattava käsitemalli ja työkalusto organisaation tietojärjestelmien luettelointiin, tietojen omistajuuden, palvelinten sekä muiden teknisten laitteiden selvittämiseen. TOGAF myös antaa neuvoja organisaation tietojärjestelmien tavoitetilan hahmottamiseksi ja tiekartan eli projektijoukon luomiseksi nykytilasta tavoitetilaan. JHS 179 on keskeinen osajoukko TOGAF:sta ja siten varsin hyvä työkalu yhden organisaation tietojärjestelmien selvittämiseen ja suunnittelemiseen. Kartturimalli on kätevä tapa täyttää TOGAF:n vaatimat tiedot Excel-taulukoihin.

Syy ei siis sinänsä voi olla työkaluissa. TOGAF ja sen johdannaiset ovat päteviä työkaluja tehtävissä, joihin ne on suunniteltu – yhden organisaation tietojärjestelmien ja toimintatapojen kokonaisuuden ymmärtämisessä ja suunnittelemisessa. Suomen ongelman on siis oltava jossain muualla.

Rahat levällään

Kun aloitin konsulttina, eräs vanhempi ja kokeneempi kollegani kehotti minua aina seuraamaan rahaa. Kollegani mukaan liiketoiminnan ja sen osien – kuten kokonaisarkkitehtuurin – kehittämisessä se päättää, jolla on rahat. Millään suunnitelmalla, oli se miten hieno ja perusteltu ja mitä pätevimpien mallien mukainen, ei ole merkitystä, jos rahasta päättävät eivät kunnioita ja noudata suunnitelmaa.

Suomen julkishallinnossa rahat ovat levällään. Helsingin kaupungin tietotekniikkajaoston puheenjohtajan (ja kollegani) Otso Kivekkään mukaan Helsingissä on 33 toisistaan riippumatonta, itsenäisiä tietotekniikan hankintapäätöksiä tekevää organisaatiota. Luultavasti tilanne on hyvin samankaltainen Suomen muissakin 312 kunnassa, 48 kuntayhtymässä, 15 yliopistossa, 26 ammattikorkeakoulussa, 12 ministeriössä ja epämääräisessä joukossa valtion virastoja ja liikelaitoksia ynnä muita.

Suomessa on äkkiseltään laskettuna ainankin 1000 toisistaan riippumatonta tietotekniikkaa hankkivaa organisatiota. Osalla näistä, kunnilla, on perustuslaillinen autonomia. Ne saavat päättää asioistaan miten haluavat – ja ostaa millaisia tietojärjestelmiä haluavat, keneltä haluavat. Osa organisaatioista on autonomialtaan rajoitetumpia, mutta silti niillä on veto-oikeus niitä koskeviin muutoksiin: mikäli jokin organisaatio ei halua muutoksia, sen tarvitsee vain kieltäytyä käyttämästä varojaan kehitykseen, eikä mikään sitä koskeva kokonaisarkkitehtuurisuunnitelma voi toteutua. Myös tietojärjestelmien toimittajilla on veto-oikeus: erilaisia sopimuksia ja käytäntöjä on niin paljon, että muutoksen voi estää sopimusneuvotteluin ja toimittajaloukun antamaa hinnoitteluvapautta käyttäen.

Ongelmana monimutkaisuus

Suomen digitalisoinnin esteenä on monimutkaisuus. Ei järjestelmien monimutkaisuus, vaan järjestelmät omistavien organisaatioiden moninaisuus ja monimutkaisuus. Mikä tahansa digitalisaatiohanke törmää väistämättä usean itsenäisen organisaation keskinäisiin neuvotteluihin.

Mikä neuvoksi? Sama kuin isoissa kansainvälisissä yrityksissä: rahasta päättävien organisaatio-osien määrää on reilusti vähennettävä. TOGAF, JHS 179 ja Kartturi-malli toimivat vain yhden organisaation sisällä. Ei ole mitään syytä, miksi Suomen kokoisessa maassa tarvitaan tuhat itsenäistä tietotekniikan hankintaorganisaatiota.

Suomen digitalisointi onnistuu vain, jos autonomisten rahankäyttäjien määrää on jollakin keinoin mahdollista supistaa. Tällä hetkellä hallituksella ei näytä olevan tähän poliittista tahtoa, mutta toisaalta sote-uudistuksen kaltaiset yksinkertaistamiset saattavat onnistuessaan luoda tahtoa ja intoa. Onnistumisia on helppoa toistaa. 

Ongelma on kuitenkin tiedossa. Ratkaisukin olisi. Puuttuu vain tahtoa ja rohkeutta.

Tämän artikkelin on kirjoittanut Matti Kinnunen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Periaatteista käytäntöön – miten toteuttaa hallituksen digiperiaatteet

Järjestelmän helppokäyttöisyyttä voi arvioida miettimällä, käyttäisivätkö asiakkaat sitä, mikäli heidän ei olisi pakko.

Toimintatapojen uudistamisen ministerityöryhmä on ministeri Anu Vehviläisen johdolla hyväksynyt digitalisoinnin yhdeksän periaatetta. Periaatteet ja niiden perustelut ovat seuraavat:

Digitalisoinnin 9 periaatetta
Digitalisoinnin 9 periaatetta

Codento pitää työryhmän periaatteita erinomaisina. Ne ovat periaatteita, joita Codento on omassa ohjelmistokehityksessään noudattanut aina. Periaatteet ovat myös tuttuja niin Virosta, kuin Toyotan 50-luvulta lähtien kehittämästä lean-menetelmästä. Osa periaatteista on myös suoraan ketterän kehityksen agile-manifestista. Periaatteissa ei ole mitään vikaa. Kun periaatteet toteutuvat, hyvinvointimme Suomessa paranee.

Periaatteiden toteutuminen ei kuitenkaan ole automaattista. Se ei edes ole helppoa. Periaatteiden toteutuminen näet vaatii perustavanlaatuisia muutoksia toimintatapoihin ja menetelmiin. Mikäli kehitystyötä on aiemmin tehty jotenkin muuten kuin asiakaslähtöisesti ja nopeasti hyötyä tuottaen, on kehitystyön tekemisen tapa omiaan tuottamaan ei-asiakaslähtöisiä ja hitaasti hyötyä tuottavia järjestelmiä ja palveluita.

Jotta periaatteet toteutuisivat, Codento ehdottaa seuraavia käytännön toimenpiteitä:

Periaate 1.: Kehitämme palvelut asiakaslähtöisesti

Mitä se tarkoittaa: Ensinnäkin tunnistamme asiakkaan. Usein on myös tarpeen tunnistaa asiakkaan asiakas. Heitä voi olla useita. Mitä hyötyä he saavat uudesta palvelusta? Kenen tarpeet ja kenelle tuotettu arvo ovat tärkeimmät? Millaisia kustannuksia heille syntyy palvelun käytöstä? Miten on mahdollista minimoida kustannukset?

Kun asiakas on tunnistettu, hänen kanssaan on tehtävä yhteistyötä. Asiakas, joka useinkaan ei ole järjestelmien eikä palveluiden kehittämisen ammattilainen, on otettava mukaan kehitystyöhön. On uskallettava mennä asiakkaan luo, ymmärrettävä hänen kieltään ja puhuttava hänelle hänen kielellään. Asiakasta ei useinkaan kiinnosta palveluntuottajan sisäiset osastorakenteet vaan ainoastaan palvelun toiminta. Tästä johtuen palveluiden kehittäminen vaatii – jos se on aidosti asiakaslähtöistä – usein monien eri valtion organisaatioiden yhteistyötä.

Ei myöskään riitä, että asiakas on mukana kehittämistyön alkuvaiheessa. Asiakas on ainoa, joka voi kertoa palvelun onnistumisesta. Siksi palvelua on kehityksen aikana säännöllisesti esiteltävä asiakkaalle. Asiakkaan on päästävä kokeilemaan palvelua. Mikäli asiakas ei pidä palvelusta, on palvelun muuttamista syytä harkita vakavasti.

Periaate 2.: Poistamme turhan asioinnin

Mitä se tarkoittaa: Asiointi on turhaa, jos se ei tuota arvoa palvelun käyttäjälle. Jokaisen asiointitapahtuman on vietävä asioita eteenpäin – pelkästään tietojen keräämisellä ei jatkossa palvelun käyttäjää vaivata. Nykyisin asioinnin jälkeen on usein epämääräisen pituinen ajanjakso, jonka aikana ei asiakkaan näkökulmasta tapahdu mitään. Asiakas kokee, että asiointi oli turhaa, koska siitä ei heti seuraa mitään. Päätöksenteko on tehtävä mahdollisimman nopeasti, mieluusti asioinnin aikana –  välittömästi. Aivan vastaavasti kuin tietojen kyselykerrat on tarkoitus supistaa yhteen, niin myös asiointikerrat per päätös on minimoitava. Tämä vaatii aivan uudenlaista, kerralla valmiiksi tekemiseen perustuvaa toimintatapaa. Uuden toimintatavan omaksuminen ei varmasti ole helppoa.

Helppo tapa poistaa turha asiointi on arvottaa asiakkaan palvelussa käyttämä aika viisi kertaa kalliimmaksi kuin oman henkilökunnan. Mitä ilmeisemmin Verovirasto on käyttänyt jotain tämmöistä kerrointa, koska Veron palveluiden käyttämiseen ei juuri aikaa mene; vakiotuloilla ehkäpä minuutteja vuodessa per asiakas.

Periaate 3.: Rakennamme helppokäyttöisiä ja turvallisia palveluita

Mitä se tarkoittaa: Helppokäyttöisyys ei ole tärkein asia, vaan tärkeämpää on, että palvelu vastaa aidosti siihen tarpeeseen joka asiakkaalla on. Jos tämä tarve ei tule täytetyksi, palvelun käytön helppous on merkityksetöntä. Toki kun perusteet ovat kunnossa helppokäyttöisyys on oletus. Sen lisäksi asiakkaalle voi tarjota palvelua joka ylittää hänen odotuksensa. Hyvä keino arvioida järjestelmän tai palvelun helppokäyttöisyyttä on miettiä käyttäisivätkö asiakkaat palvelua tai järjestelmää, mikäli heidän ei olisi pakko. Tähän astihan monia valtion palveluita on kehitetty monopolimielessä: käytä, tai itke ja käytä.

Tietoturvan ja helppokäyttöisyyden yhdistäminen ei ole helppoa. On varottava, ettei uusista palveluista tule KATSO-järjestelmän kaltaisia tietoturvallisia kummajaisia. Tunnistautumisjärjestelmien kehittäminen saattaa olla hyvinkin tarpeen.

Periaate 4.: Tuotamme asiakkaalle hyötyä nopeasti

Mitä se tarkoittaa: Prosessit ja tavat toimia optimoidaan asiakkaan lisäarvon luomisen kannalta. Mittarit eivät mittaa kuinka tehokkaasti resurssin aika on allokoitu, vaan kuinka sujuvaa on asiakkaan palveleminen yli palveluun käytettyjen resurssien. Kiireettömyys on jatkossa hyvin tärkeää – ei vähiten siksi, että kiireetön ja siksi virheetön palvelu on asiakkaan näkökulmasta arvokkaampaa.

Periaate 5.: Palvelemme myös häiriötilanteissa

Mitä se tarkoittaa: Häiriötilanteessa varmistetaan ensin, että asiakas saa palvelun, vaikka palvelun tarjoajan pitäisi sitten tehdä manuaalista työtä ja jopa ylityönä. Häiriötilanne nähdään mahdollisuutena tunnistaa ongelman juurisyy ja poistaa ongelman uusiutumisen mahdollisuus. Tämä prosessin, työtapojen tai työkalujen korjaaminen tehdään välittömästi. On huomattava, että yöaika tai pyhäpäivä ei ole häiriötilanne. Julkisten tietojärjestelmien on toimittava kellon ympäri.

Periaate 6.: Pyydämme uutta tietoa vain kerran

Mitä se tarkoittaa: Tiedon pyytämisen eliminoimisen ei pitäisi olla itseisarvo, jos tilanne vaatii niin tietoa pitää voida pyytää juuri silloin kun sitä tarvitaan. Kun prosessi alunperin suunnitellaan toimittamaan asiakkaalle lisäarvoa, minimoiden kaikki muu, ollaan luonnostaan tilanteessa, jossa tieto on käytettävissä silloin kun sitä tarvitaan ja asiakaskin ymmärtää miksi tietoa tarvitaan. On varottava, että periaatetta ei oteta liian vakavasti ja pyritä liiaksi keskittämään tietojen syöttämistä järjestelmiin.

Missään tapauksessa jatkossa ei enää voida integroida järjestelmiä asiakkaan manuaalisella työllä. Olisi hyvä selvittää missä asiakasintegraatiota tällä hetkellä on ja miten sen voisi helpoiten poistaa – joko muuttamalla prosesseja tai rakentamalla uusia teknisiä ratkaisuita vaikkapa kansallista palveluväylää käyttäen.

Periaate 7.: Hyödynnämme jo olemassa olevia julkisia ja yksityisiä sähköisiä palveluita

Mitä se tarkoittaa: Arvokkain uusi järjestelmä on järjestelmä, jota ei tarvitse kehittää. On varottava, ettei uuden järjestelmän kehitystyöhön ryhdytä vain siksi, että budjetissa sattuu olemaan rahaa. Olemassa olevat järjestelmät eivät yleensä tarkalleen vastaa aiottua palveluprosessia ja siksi menneisyydessä on usein päädytty rakentamaan useita samankaltaisia järjestelmiä. Tulevaisuudessa näin ei voi enää tehdä vaan on selvitettävä myös mahdollisuudet muuttaa palveluprosessia. Yksityisten järjestelmien laajempi käyttö vaatii myös uudenlaista otetta hankintaan ja kilpailutuksiin. Miten voidaan kilpailuttaa rajapintojen tarjoamista, jos rajapinnat eivät ole ilmaisia?

Periaate 8.: Avaamme tiedon ja rajapinnat yrityksille ja kansalaisille

Mitä se tarkoittaa: Uusien järjestelmien toteutuksessa tiedon ja rajapintojen avaaminen on helppoa ja suoraviivaista. Maassamme on kuitenkin lukemattomia järjestelmiä, joiden suunnittelussa ei tiedon ja rajapintojen avaamista ole otettu lainkaan huomioon sen paremmin teknisesti kuin sopimuksellisesti. Vanhojen ja uusien, kehitettävien palveluiden ja järjestelmien avoimuuden varmistaminen on vaikea ongelma. Ongelman ratkaiseminen on kuitenkin välttämätöntä esimerkiksi SoTe-uudistuksen vertikaalisen ja horisontaalisen integraation toteuttamiseksi.

Periaate 9.: Nimeämme palvelulle ja sen toteutukselle omistajan

Mitä se tarkoittaa: Jos kukaan ei omista palvelua, kukaan ei erityisesti välitä palvelun kehittämisestä. Omistajan nimeäminen ei kuitenkaan riitä. Nimeämisen eli vastuun lisäksi omistajalle on annettava riittävästi valtaa palvelun toteuttamisen johtamiseen ja jatkokehittämiseen. Tietojärjestelmien kehittämisessä – mikäli käytössä on jokin hyvin määritelty ketterä menetelmä – vastuu ja valta on tuoteomistajalla. Jotta tämä periaate toteutuisi, on siis koulutettava riittävän monta tuoteomistajaa ja annettava heille tarvittavat voimavarat.

Yhteenveto

Meidän tulee ymmärtää, mikä on asiakkaalle arvokasta ja käyttää tätä tietoa optimoimaan sitä tapaa jolla lisäarvo tuotetaan. Tämä itsessään ohjaa parempaan asiakaskokemukseen. Jos turvaudumme nykyisen toimitavan päälle liimattuihin periaatteisiin, emme tule onnistumaan asiakaskokemuksen kokonaisvaltaisessa parantamisessa. Muutoksen pitää tapahtua syvällä siinä tavassa, miten asiakkaan arvo muodostuu.

***

Kuva: Flickr Creative Commons, Mike Licht

Tämän artikkelin on kirjoittanut Matti Kinnunen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

JIT2015 ja IT2015 sopimusehdot ja ketterät periaatteet

Olin tiistaina 2.2.2016 puhumassa ketterien periaatteiden näkymisestä uusissa ketterissä vakiosopimusehdoissa Lakimiesliiton koulutuksen ja Talentum Eventsin IT2015 ja JIT2015 – uudet vakioehdot -seminaarissa. Alla Slideshare-esitykseni seminaarista.

Tärkeimpänä viestinä uusien IT2015 että JIT2015 ketterien sopimusehtojen suhteen on, että ne ovat molemmat jonkinasteisia kompromisseja perinteisen riskikeskeisen sopimusajattelun ja luottamukseen rakentuvan ketterän hankeohjausfilosofian välillä. Hyppäys puhtaaseen ketterään malliin on monelle vakioehtoja käyttävälle asiakkaalle suuri. Niinpä sopimusehdoissa on tuotu perinteisestä sopimusmaailmasta turvakäytäntöjä asiakkaiden tueksi samalla, kun on tehty tutuiksi ketterän tilaamisen tärkeimpiä asioita kuten sitä, että asiakkaalla on oltava varattuna projektiin ihmisiä jotka pystyvät olevan päätöksenteossa päivittäin läsnä.

Yhteenvetona IT2015 ja JIT2015 ketterät ehdot suhteutuvat ideologialtaan ja rakenteeltaan “perinteisiin” ketteriin sopimuksiin seuraavasti:

“Perinteiset” ketterät sopimukset: asiakkaan ohjausvastuu, lyhyt irtisanomisaika, koodi talteen

Ketterissä piireissä perinteinen ja radikaalein sopimusmalli on perustunut time and materials -tyyliseen hinnoitteluun, jossa asiakas ostaa ketteriä kehittäjiä omaan hankeohjauksensa alle. Toisin sanoen asiakas vastaa täysin siitä, että projektissa syntyy liiketoiminnalle arvokkaita asioita tarvitussa aikataulussa. Näissä sopimuksissa riskejä on hallittu lyhyellä irtisanomisajalla (esim. yhden projektin iteraation kuten sprintin pituus). Kun lisäksi on huolehdittu, että jokaisen sprintin lopussa tuote on ehjä ja lähdekoodi tallennettuna jossakin minne asiakkalla on pääsy, asiakas voi ongelmien eskaloituessa periaatteessa jatkaa tuotteen kehitystä uuden tiimin kanssa heti seuraavan iteraation alusta.

IT2015: asiakkaan ohjausvastuu, nimetty menetelmä ja takuu

IT2015 ketterät ehdot (viralliselta nimeltään IT2015 Erityisehtoja toimituksista ketterillä menetelmillä, ks. http://www.it2010.fi/system/files/IT2010_PDF/fi/EsikatseleIT2015_EKT_Suomi2015.pdf) lähtevät perustavasti näistä “perinteisten ketterien ehtojen” lähtökohdista, lyhyttä irtisanomisaikaa (14 pv) myöten. Ehdot kuitenkin olettavat, että asiakas ja toimittaja nimeävät yhdessä käytettävän ketterän menetelmän, jotta käytänteistä voidaan olettaa jotakin. Asiakkaan roolin vaatimuksia opastetaan  velvoittamalla asiakas varaamaan työaikaa hankkeen käyttöön sekä olettamalla että alustava työlista on jo ennen sopimuksen solmimista laadittu. Hankinnan hallintataktiikoita opastetaan esittelemällä mahdollisuus viivästyssakkoihin sekä nimettyihin avainhenkilöihin, joiden vaihtaminen on kielletty. Ainoa varsinainen poikkeama perinteiseen time and materials -ajatteluun on 6 kk takuu projektissa kehitetyille ominaisuuksille.

JIT2015: toimittajan vastuu, avoin lähdekoodi korostuneena

JIT2015 ketterissä ehdoissa (virallisesti Erityisehtoja ketterillä menetelmillä toteutettavista projekteista – JIT 2015 Ketterät menetelmät), ks.
http://docs.jhs-suositukset.fi/jhs-suositukset/JHS166_liite4/JHS166_liite4.html) on tehty enemmän kompromisseja ketterän tilaamisen ja perinteisen IT-projektien sopimusmaailman välillä. Niinpä niitä ei voi käyttää sellaisinaan minkään yleisimmän ketterän metodin (esim. Scrum tai Kanban) kanssa, vaan menetelmään on tehtävä niiden vaatimusten johdosta poikkeuksia tai lisäyksiä.

Draamaattisin ero ketteräksi koettuun toimintamalliin on, että toimituksen sisältö ja aikataulu on toimittajan vastuulla. Lisäksi ketterästä toimintatavasta eroaa, että ehdottomat vaatimukset lyödään lukkoon jo sopimusvaiheessa, vaikkakin niiden sisältöä ja niiden ohelle tulevia valinnaisia vaatimuksia tarkennetaankin yhdessä. Tilaajan etuja suojataan niissä myös takuulla, viivästyssakoilla ja määrittelemällä ketterien metodien ulkopuolisia vastuuhenkilöitä. JIT 2015 ketteriä ehtoja voikin ajatella “my first agile” -tyyppisenä ensimmäisenä tutustumisena ketterään tilaustapaan. Niissä on tuotu erityisesti ilmi esim. tilaajan velvollisuus myötävaikuttaa projektin sujumiseen. Varsinaisen ketteryysteeman ulkopuolelta ehtoihin on tuotu avoimen lähdekoodin lisenssit.