Tarinassa on taikaa

Tarina kuvaa
muutosprojektin suunnan,
maalaa tavoitteen.

Tarina auttaa
ymmärtämään, muistamaan,
sitoutumaan.

Projektiyhdistyksen jäsentilaisuuden aihe, Tarinan taika, kiehtoi, joten 27.8.2012 suuntasin Eteläranta kympin auditorioon.

Avauspuheessaan PRY:n toiminnanjohtaja Jyry Louhisto perusteli teemaa informaatioyhteiskunnan ja muutosprojektien tarinoilla. Hän mainitsi Aaro Ollikaisen  uuden projektialasta kertovan romaanin “Avain – muutosprojektista menestys“, josta ahmin samana iltana kolmasosan Espan puiston penkillä.
Helsingin Sanomien vastaava päätoimittaja Mikael Pentikäinen pohdiskeli mediaa muutoksen keskellä. Sananvapaus on ongelma monissa maissa. Mediaa hallitseva hallitsee mieliä ja vapaa sana on elämä itse. Netti ja mobiili mullistavat mediaa yhtä rajusti kuin Gutenbergin  painokoneet aikoinaan. Vaihtoehtojen räjähdysmäinen kasvu on lisännyt kilpailua ja muuttanut perspektiivin lokaalista globaaliksi. Kaikki menee pilveen. Voimmeko vaikuttaa digitalisoitumisen aikatauluun?
Vastaukseksi median murrokseen Helsingin Sanomat tarjoaa laadukasta, merkityksellistä sisältö, jonka tavoittaa kaikilla päätelaitteilla, sekä jatkuvaa vuoropuhelua asiakkaan kanssa. Suuri lehtiuudistus muuttaa paperilehden tabloidiksi. Avoin maksumuuri sallii digilehden lukemisen sosiaalisessa mediassa, mutta paljo lukeminen maksaa. Kolmasosa Helsingin Sanomien tilaajista maksaakin jo digisisällöistä.
Onko huono johtaminen osasyynä, jos ihmiset nukkuvat huonosti työasioiden vuoksi? Hyvä johtaminen luo tarinalla kirkkaan tavoitteen vaikeinakin aikoina, sillan taantuman kuopan yli. Resurssit ovat kunnossa ja projektin johtaminen hallinnassa. Avoimuus ja uskallus, reiluus ja luottamus ovat menestystarinan elementtejä.
Esityksensä lopuksi Mikael Pentikäinen muistutti, että kansanvalta ei toimi ilman toimivaa tiedonvälitystä.
Pekka Mattila myhäili, että muutos on edelleen ajankohtainen, mutta emme osaa johtaa sitä. Hän näytti esimerkkejä yritysten tarinoista, joihin voi nojata myös ongelmatilanteissa. Proppin perintö palauttaa tarinat 31 perusfunktioon ja hahmot 8 perushahmoon. Kaikki tarinat rakentuvat olemassa oleville myyteille. Uusissa tarinoissa Shakespearen ja Antiikin tarinat  sijoittuvat vain uusiin yhteyksiin.
Organisaation perustarina kertoo, mistä tulemme ja miksi olemme. Johtajuustarina kertoo, mikä meitä ohjaa. Johtaja edustaa tietynlaista muutostarvetta: keskitytään ytimeen, jota laajennetaan. Edessä olevan muutostarina kertoo, mikä meitä haastaa. Jännitteinen uratarina kertoo, mitä olen saavuttanut ja mikä minua odottaa.
Miksi muutokset ja fuusiot ovat vaikeita? Usein viitataan erilaisiin organisaatiokulttuureihin. Yhteensopimattomat yritystarinat ovat vähintään yhtä haastavia. Virallisen ja epävirallisen organisaation tavat ja tarinat eroavat toisistaan. Uusi tulokas tutustuu vähitellen yrityksen verkostoon, mielipidevaikuttajiin, talon tapoihin ja hiljaiseen tietoon. Tarinoita ja kokemuksia lainataan menneestä nykyiseen ja tulevaan.
Monia ilmiöitä pyritään selittämään eri sukupolvilla. Suuret ikäluokat olivat kilpailun sukupolvi: joka paikkaan oli tunkua, mikä synnytti kyynisyyttä ja pragmatismia. Y- ja Z-sukupolvet ovat mahdollisuuksien sukupolvia, joita leimaa ihanteellisuus ja kriittisyys. Huijaaminen ei enää onnistu samoin kuin ennen, kun faktat voi tarkistaa netistä; kansalaiset haluvat tietää, missä tuotteet oikeasti on valmistettu.
Yksilöiden erot ovat aina peitonneet sukupolvien erot. Ihmisiä pitäisi kohdella yksilöinä, ei sukupolviensa edustajina. Nuoretkin haluavat sitoutua ja löytää merkityksiä.
Antropologit ymmärtävät merkityksiä ja ongelmia aiheuttavia tarinoita. Uskotaanko tarinaa? Uskooko kertoja siihen itse? Johtaminen on aina näyttelemistä, mutta onko rooli luonteva?
Mikä saa ihmisen toimimaan? Freudin mukaan seksuaalinen mielihyvä, Adlerin mukaan halu kokea paremmuutta, Frankin mukaan halu tehdä jotain merkityksellistä. “Joka puussa on metsän siemen, joka pisarassa meren juuri”, totesi Emerson.
Läytääkö ihminen oman merkityksensä organisaation visiosta? Johtamisessa on kyse myynnistä, yhteisen edun osoittamisesta. Toimintamalli, jossa keskeneräisistä asioista ei tiedoteta, on harhainen vaikka toimiikin joskus. Jatkuva tiedottaminen helposti hajottaa ja turruttaa, ellei kyse ole pienistä tarinoista, jotka liittyvät suurempaan. Jos missio ja visio lainataan kaikilta, se ei kerro mitään konkreettista.
Pekka Mattila totesi, ettei ostaisi ydinvoimalaa tarinankertojalta, ellei mukana olisi muutamaa hyvää insinööriä.
Aaro Ollikainen, AVAIN-romaanin kirjoittaja, totesi, että projektijohtajuus on osa huomisen johtajuutta. Kaikkea pitäisi lukea, mikä aiheuttaa huonon omatunnon. Yöpöydällä on pino tietokirjoja ja toinen romaaneja. Kumpaan tarttuu mieluumin?
Kuva projekteista on usein preussilais-insinöörivetoinen. Projektipäällikkyys on monelle asiantuntijalle ensimmäinen johtamiskokemus; kokemus siitä, että on vastuussa muiden töistä.
Asiantuntijoiden johtamiseen hän suositteli kolmen kohdan ohjelmaa:

  • Imartele häpeämättä.
  • Hanki projektille hyvä sponsori tai kummisetä.
  • Kerro uskottava tarina.

Projektit ovat ainutkertaisia, jokaisella on tilaus merkitykselliseen tarinaan, jota ihmiset työstään hakevat. Tarina muistetaan, se voi olla hissipuhe, siinä on teema, rakenne, kertoja ja aikaulottuvuus, se inspiroi, vetoaa tunteisiin ja yhdistää joukot tavoitteeseen. Viestintä tarinana on tehokasta.
Tarina voi rakentua ongelman ratkaisusta, se voi edetä yleisestä yksityiseen tai päinvastoin. Se voi kertoa, mitä uusi tietojärjestelmä merkitsee tietyissä rooleissa oleville ihmisille. Se voi edetä menneestä nykyiseen ja tulevaan tai tulevasta nykyisyyteen.
Tarina voi alkaa projektin käynnistyspalaverista, selkeästä tai epämääräisestä. Projektin sponsori voi olla kielteinen tai myönteinen hahmo.
Aaro Ollikainen toivoo, että projektitarinoita etsittäisiin muualtakin kuin sodista.
Lopuksi
Tarinat ovat aina kiehtoneet, mutta ymmärsin niiden yhteiskunnallisen voiman vuosituhannen alussa, jolloin Vesa-Matti Paananen visioi, että tarinankertojat johtavat tulevaisuuden mobiiliheimojen yhteiskuntaa. Esitys jäi lähtemättömästi mieleeni. Tarinoiden merkitystä painotettiin myös pari vuotta myöhemmin matkailualan seminaarissa.
Tarinoissa on taikaa.

IT kaipaa naisia

Uuden kulttuurin
arvoketju hymyilee
raidetytöille.

Naista kutsuvat
nosturIT ja verkkotaidot
IT-alalle.

ICT Ladies -verkosto  kokoontui Teknologiateollisuuden auditorioon Eteläranta kymppiin 20.3.2012 kuulemaan projekteista, joilla tyttöjä ja naisia pyritään innostamaan ICT-alalle.
Jukka Viitasaari, Tietotekniikka-toimialan johtaja, esitteli Teknologiateollisuuden toimintaa ja tutkimuksia eri teknologia-alojen yritysten liikevaihdosta, henkilöstöstä ja koulutuksesta. Suomalaiset yritykset työllistävät entistä enemmän ulkomailla. Maantieteestä riippuen Suomen osuus tuotosta vaihtelee 17 % – 77 %. Tietotekniikka-alalla Suomeen voisi kuitenkin jäädä lähes 100 % tuotosta, siksi kyseiseen alaan pitäisi panostaa.
Tietotekniikka-ala tarvitsee uusia liiketoimintamalleja, palvelukulttuuria, asiakkaan ja asiakkaan asiakkaan ymmärtämistä, asiakkaiden ottamista mukaan tuotekehitykseen. Sosiaaliset taidot nousevat ohi kapea-alaisen teknisen osaamisen. Jukka Viitasaari kertoi itsekin valmistuneensa valtiotieteellisestä tiedekunnasta, josta opiskelukaveri meni Nokialle kehittämään 1990-luvun edistyksellisiä käyttöliittymiä.
Kun väestö vanhenee ja työntekijöiden määrä vähenee, tarvitaan innovatiivisia työskentelytaitoja, prosessien muuttamista, joustavaa osa-aika- ja etätyötä. Tietotekniikka-ala on rakennemuutoksessa, kun työt teetetään Aasiassa, mutta tietotekniikkaa tarvitaan kuitenkin vientiteollisuudessa. Tästä voisi lukea vaikka raportista Kenelle arvoketju hymyilee?
Digitaalisuus luo arvoa, se vaikuttaa tuottavuuteen, palvelukokemukseen, innovointiin ja johtamiseen. Verkostojohtaminen on ansaittua johtajuutta ilman arvomerkkejä tai nimityksiä. Innovointi siirtyy verkoon; kun annat paljon, saat paljon.
Puhelimiin tuleva NFC  luo uusia palvelumahdollisuuksia ja synnyttää valtavasti uutta dataa. Olisiko Suomi palvelinkeskusten Sveitsi?
Tuota kysyttiin pari vuotta sitten Systeemityöyhdistys Sytyken laivaseminaarissa.
Piia Simpanen kertoi Naisia ICT-alalle -tutkimuksesta, uudesta tytöille ja naisille suunnatusta nelivuotisesta vetovoimaohjelmasta, e-Skills 2012 -viikosta,  josta löytyy tietoa myös Facebookista, NosturIT-festarista sekä kansainvälistä innostusta keränneestä Rails Girls  -koodaustyöpajasta naisille, jossa opitaan verkkosovellusten suunnittelun ja rakentamisen alkeita sekaryhmissä.
Tytöt osaavat käyttää älykännyjä ja verkostopalveluita, mutta eivät koe ICT-alaa houkuttelevana; se ei vaikuta luovalta tai ihmisläheiseltä. Silti alalla työskentelevät naiset viihtyvät työssään.
Keskustelussa todettiin, että opettajankoulutukseen pitäisi kiinnittää erityistä huomiota, jotta opettajat jo alaluokilla altistaisivat lapset tietotekniikalle. Nyt monet opettajat sanovat, että ICT on vain nörttien hommaa.
Otammeko tuosta kopin IT-kouluttajien ensi viikon laivaseminaarissa Koulutus taskussa?
Tytöille pitäisi kertoa esimerkkejä, mitä IT-alalla oikeasti tehdään, että esimerkiksi projektipäällikön työ sisältää paljon viestintää ja markkinointia. Maailmassa koodia on kirjoitettu paljon ja sitä pitäisi hyödyntää, uudelleenkäyttää. Kun koodaus siirtyy Aasiaan, Suomeen jäävät ihmisläheiset osat IT-työstä.
Pitäisikö lyhenne “IT” tulkita uudestaan. Kyse ei enää olisikaan informaatioteknologiasta vaan ihmisteknologiasta, joka auttaa ihmisiä kohtaamaan toisensa, tai interaktioteknologiasta? Tämän ajatuksen esitti Ville Venäläinen IT-kouluttajien 10-vuotisseminaarissa viime marraskuussa.
Tietotekniikka-alalla työskentelevien koulutustausta on kirjava, nörttien sekaan mahtuu kauppa- ja valtiotieteilijöitä sekä humanisteja. Digi.fi-palveluun on kerätty mm. alalla työskentelevien haastatteluja.
Sini Kaukonen pohti, miksi naisia on niin vähän IT-johtajina. Vaikuttavatko siihen koulutusvalinnat, asenteet ja puuttuvat verkostot? Suomessa työtehtävät valitaan koulutusalan mukaan paljon useammin kuin muualla Euroopassa. Tarvittaisiin asennemuutosta, roolimalleja, joustavia ja selkeitä työjärjestelyjä. Rekrytoijat toteavat, että naisia pitää pyytää tehtäviin kun taas miehet hakeutuvat niihin. Auttaisivatko kiintiöt vai pahentaisivatko ne naisjohtajien tilannetta?

Ketterä monimutkaisuus

susi vai lammas
tylsyys vai yksinäisyys?
valitse siitä

unohda mallit
luokittelut, kuuntele
hiljaa kaaosta

Scandinavian Agile Conference 2012  keräsi naistenpäivästä huolimatta miesvoittoisen esiintyjäkaartin ja yleisön Helsingin Marina Congress Centeriin 8.3.2012. Pääsin mukaan TTL:n Systeemityöyhdistys Sytyken edustajana. Avaussanoissa todettiin, että IT-alalla työskentelijöistä vain 6-8 % on naisia, ja naisia kaivataan alalle lisää. Konferenssissa twiitattiin hashtagilla #scanagile.
Dave Snowden  ehdotti kielteisten määrittelyjen muuttamista myönteisiksi ja teorian vuorovaikutusta käytännön kanssa. Usein merkitykselliset asiat syntyvät sattumalta. Mukautumisen sijaa pitäisi etsiä poikkeuksia.
Järjestelmäkehityksessä ei voida olettaa, että asiakkaat aina tietäisivät, mitä haluavat. Heidät pitäisi johtaa tilanteisiin, joissa he oivaltavat tarpeensa. Tätä havainnollisti järjestystä kuvaava pieni pursi ja kaoottisesti vyöryvä valtameri. Järjestys asettaa rajoituksia ja liika kontrolli tuhlaa työpanosta. Satunnainen systeemi on kaoottinen; ei voida ennustaa, mitä tapahtuu, kun lähestyt toista – eikä tilannetta voida toistaa.
Hiljainen tieto on tärkeä voimavara organisaatiossa, mutta yleensä asiat alkavat tapahtua, kun ne tehdään näkyviksi.
Perinteisessä systeemiajattelussa kiinnitetään tavoitetila ja askeleet siihen, muu ympäristö jäädytetään eikä jätetä tilaa oppimiselle. Monimutkaisessa systeemissä taas tavoitetilaa ei voida tarkkaan määritellä. Inhimillistä toimintaa yritetään kuvata mallilla, jotta sitä voitaisiin kontrolloida, mutta monimutkaisuutta ei voi mallintaa. Tätä havainnollisti yksinkertaistettu malli monimutkaisesta liikenneympyrästä.
Ihminen käyttäytyy eri paikoissa ja eri tilanteissa eri tavoin; ihminen on kotonaan erilainen kuin työpaikallaan. Monimutkaisuus ei välttämättä ole hyvä, mutta se on osa elämää. Ihmisen pitäisi oppia kuuntelemaan omaa inhimillisyyttään.
Monissa organisaatioissa tietohallinnon toiminnot periytyvät 1980-luvulta. Tietohallinnon pitäisi olla taidetta, jolla nopeutetaan asiakkaan pääsyä tavoitteeseensa. Päivittäiset tarinat ja päiväkirjat avaavat todelliset tarpeet nopeammin kuin tarpeiden kyseleminen.
Suuressa organisaatiossa valtaosa ajasta kuluu säilyttämiseen ja vain pieni osa todelliseen työhön. Lampaan elämä voi olla tylsää kun taas susi voi tuntea itsensä yksinäiseksi. Valitse siitä! Inhimillinen heikkous on parempi kuin robotin voima. Kulttuuri on kaikkein monimutkaisin. Eikä monimutkaisuus pääty milloinkaan.
Joseph Pelrine  aloitti esityksensä kysymällä, miksi ketteryys toimii tai toimiiko ketteryys. Aikoinaan Dracula hämmensi todellisuutta, kun oli totuttu siihen, että ihminen oli joko elävä tai kuollut eikä muita vaihtoehtoja ollut. Kun ihminen joutuu pois mukavuusalueeltaan, hän alkaa oppia – päästäkseen uudelleen mukavuusalueelleen.
Ihmiset eivät ole rationaalisesti ajattelevia muurahaisia, Bobeja, jotka voisi korvata toisillaan. Jokaisella ihmisellä on ainutlaatuinen historiansa, muisti, josta ammentaa; siksi yritykset ihmisen toiminnan luokittelemiseksi ja mallintamiseksi pitäisi hylätä.
Perinteisessä tietojärjestelmän kehittämisessä on kyse monimutkaisesta epäjärjestystilanteesta, jossa ennustaminen tulee mahdottomaksi. Jälkikäteen on toki helppo nähdä, paljonko aikaa eri vaiheisiin meni ja miksi. Mutta se ei helpota seuraavassa arviointitilanteessa, jossa on taas kysymys monimutkaisesta epäjärjestyksestä.
Joseph Pelrine esitteli Dave Snowdenin Cynefic-rakennetta. Ketterä järjestelmäkehitys sopii monimutkaisiin tilanteisiin. Kaikki menetelmät, myös vesiputousmalli, toimivat, kun niitä käytetään niihin sopivissa tilanteissa. Jos jokin voidaan tehdä yksinkertaisesti, niin miksi se pitäisi tehdä monimutkaisemmin? Vasara ja naula eivät kuitenkaan ole kaikissa tilanteissa oikeita työkaluja.
Kati Vilkki Nokia Siemens Networkilta keräsi salin täyteen yleisöä kuuntelemaan konkreettisia kokemuksia siitä, miten luodaan jatkuvasti kehittyvä kulttuuri.
Ihmisille pitää antaa aikaa oppia ja kehittää, jatkuva kehittyminenhän on ketteryyden ja leanin kulmakivi. Jos halutaan erilaisia tuloksia, niin jotain pitää tehdä eri tavalla; tarvitaan uudenlaista ajattelua ja vanhan poisoppimista.
Kati Vilkki kysyi, mitä arvelisimme tavalliselle ihmiselle ensimmäisenä tulevan mieleen, jos hänelle puhuu ohjelmistosta. Niinpä: ongelmat, esimerkiksi kun viime syksynä junalippuja ei voinut ostaa.
Jos yritys pyrkii minimoimaan kustannuksia, se ennen pitkää minimoi laatua. Tuottavuus ei ole sitä, että kustannukset painetaan alas; tuottavuus on sitä, että tuotos suhteessa kustannuksiin olisi mahdollisimman suuri.
Monissa organisaatioissa palautekierros on niin pitkä, että voi kestää vuosia ennen kuin yritysjohto saa palautteen.  Palautekierrosta voidaan lyhentää keräämällä jatkuvasti tietoa (data) ja tarinoita.
Oppiminen on arvo sinänsä; sitä ei saa sysätä hetkeen, jolloin sattuu olemaan aikaa. Oppimisen pitää olla turvallista; ihmisellä pitää olla mahdollisuus sanoa: “En tiedä.” Tiimillä pitää olla tunne vastuustaan ja vaikutusmahdollisuuksistaan, myös vakautta ja tietoa tilastaan. Johtamisen pitäisi perustua merkityksiin, ei numeroihin.
Oppiminen on vaikeaa. Hämmennys on terveellinen tila mielelle. Kokemuksesta oppiminen tarkoittaa tekemisen tuloksen reflektointia ja analysointia, uuden työskentelyteorian muodostamista ja uudenlaista tekemistä.
Mitä on viisaus? Sitä, ettei tee samaa virhettä kahteen kertaan; nimenomaan sitä, että oppii kokemuksestaan.
Scrumin retrospektioita pidetään tylsinä. Ensimmäisellä kerralla voidaan vielä olla innostuneita, mutta kun samaa listaa toistetaan kerrasta toiseen, innostus laantuu. Retrospektioista voisi tehdä retrospektioita; miten tylsän asian voisi tehdä toisin? Kuitenkin tarvitaan palautetta, muuten ei tiedetä, missä ollaan ja miten tilannetta parannetaan. Tarvitaan yhteisöllistä, systemaattista ongelmanratkaisua ja syvällistä suunnittelua: Mikä on ongelma? Miksi se on ongelma? Mitä siitä seuraa? Miten ongelma ratkaistaan?
Voimmeko vaikuttaa toisiimme? Ketään ei saa halukkaasti tekemään asioita, joista tämä ei pidä. Jokainen pitkään naimisissa ollut on huomannut sen – tai jokainen muistellessaan, miltä tuntui lapsena, kun äiti käski huonetta siivoamaan.
Vuorovaikutus on paras tapa vaikuttaa. Kun toinen pyytää apua, auttamisesta nauttii, esimerkiksi lastenvaunujen kanssa julkisissa liikennevälineissä. Miten vähän tätä käytetään organisaatioissa? Kun muutamme omaa käyttäytymistapaamme, toinen ei voi käyttäytyä vanhalla tavalla. Ihmiset kuuntelevat uskottavaa ja merkityksellistä puhetta, joka on heidän puolellaan.
Ajattele työuraasi: Milloin olit täynnä energiaa? Parin minuutin porinatuokio toi esiin tilanteita, joissa ihminen oli kokenut voivansa itse vaikuttaa tekemisiinsä.
Laura Snellman-Junna Reaktorilta kertoi empaattisuuden mekanismeista. Ihmiset unohtavat sanasi ja tekosi, mutta eivät sitä, millaisia tunteita olet heissä herättänyt. Omat lapset ovat opettaneet empaattisuutta enemmän kuin koulu tai työelämä.
Empaattisuus tuo informaatiota päätöksentekoon, tehostaa keskustelua ja on perusta kaikille inhimillisille suhteille. Miten tulkitsemme toisen tunteita? Ensin kuulemme sanat, tarkkailemme kehon kieltä ja lopuksi kuuntelemme omaa sydäntämme.
Ryhmäempatiaan kuuluu ryhmän kehittämät omat normit, joilla ryhmä pysyy koossa. Ne vaikuttavat ihmissuhteisiin, tekemiseen, luovuuteen ja tuloksiin. Ryhmäempatia helpottaa keskustelussa ja synnyttää luottamusta.
Kysy enemmän, oleta vähemmän! Havainnoi, ole avoin! Meditoi; se kasvattaa empaattisuutta, emotionaalista itseohjautuvuutta ja itsetietoisuutta.
Empaattisuuteen liittyviä mekanismeja havainnollistettiin kuvilla ja värillisillä liimalapuilla, kynällä suussa ja muutamalla videolla. Videoiden äänentoisto vaati luovuutta: kokousmikrofonia pidettiin Macin kaiuttimen luona.
Marko Taipale Huitaleelta näytti sellaista, jota ei voi nähdä (showing unseen), tapauskertomuksia erilaisista ketteristä ohjelmistokehityksistä. Piirros ja tarina auttaa yleensä asian ymmärtämistä.
Miksi projekti ei etene? Kun projektihuoneessa on fäppejä liimalappuineen, mutta ei projektitiimiä. Työn eri vaiheiden kesto olisi yhteensä ollut kolme kuukautta, mutta  odotteluun vaiheiden välissä kului puolitoista vuotta. Mitä opittiin? Koko arvovirta (value stream) pitäisi optimoida.
Toisessa tapauskertomuksessa ohjelmistokehityksen dokumentit eivät täsmänneet. Vähitellen selvisi, ettei kellään ollut kokonaisvastuuta vaan jokainen vastasi vain tietyistä yksityiskohdista. Kun tästä otettiin oppia seuraavassa projektissa, säästettiin miljoonia euroja vuodessa. Mitä opittiin? Näyttäminen ei vielä ole kuntoon saattamista. Haluatko oikeutta vai olla avulias? Unohda dogmit, kuuntele ja näe tarpeet!
Kolmannessa tapauskertomuksessa tiimi kehitti samaa osaa ohjelmistosta, jota jo edellisenä vuonna oli kehitetty. Asiakas hermostui, kun toimittajan edustajat kyselivät samoja asioita uudestaan. Tilanne selittyi sillä, että tiimin kaikki jäsenet olivat välillä vaihtuneet eikä edellisen kehityksen tuloksia ollut otettu käyttöön, kun ne olisivat vaikuttaneet moneen muuhun tietojärjestelmään.
Visualisointi on hyvä keino, mutta se ei ratkaise kaikkea. Kuvatuissa tapauskertomuksissa ongelmat olivat johtamisessa. Konsultti voi näyttää totuuden, mutta hänen ei kannata leikkiä muulia vaan hakea tukea.
Lopuksi Reidar Wasenius  tutustutti meidät Aivobiciin, jota voi harrastaa mm. vasta avatussa Aivokuntokeskuksessa. Monen asian tekeminen samanaikaisesti, multitasking, on tärkeää, mutta siinä on jo menty liian pitkälle. Ihmiset ovat hajamielisiä eivätkä osaa keskittyä. Niinpä konferenssipäivän päätteeksi istuimme silmät kiinni ja musiikin rytmissä luettelimme Reidar Waseniuksen johdolla mielessämme helpohkoja numerosarjoja – keskityimme hetkeen, jossa olimme!

Ajankohtaista tietohallintoa

johto ymmärtää
näytöt ja eurot, kuka
näyttää taustat

tietohallinnon
termit tökkivät, pilvi
kaatuu klusteriin

Porterin voimat
tietohallintolaki –
katso, ihminen

Tietohallinnon ajankohtaisseminaari CIO & Management Today keräsi auditoriollisen yrityselämän edustajia, tietotekniikan ammattilaisia ja korkeakouluopiskelijoita Haaga-Heliaan 29.8.2011 kuulemaan, millaista tietohallinnon johtaminen on tänään. Anne-Maritta Talaslahti avasi ja juonsi tilaisuuden asiantuntevasti ja rauhallisesti kertoen tietohallintojohtamisen tutkimuksista, joita Haaga-Helian aikuisopiskelijat viime kesänä tekivät yrityselämän kanssa.
Heikki Saarinen kertoi kesän tutkimusta edeltävästä globaalista tutkimuksesta tammikuussa 2010 ja vertaili tutkimustuloksia keskenään.
Globaalin tutkimuksen mukaan tietohallintojohtajalle penninvenytystä tärkeämpää on arvo, joka syntyy tietohallinnon työntekijöiden organisaatio-osaamisesta, siitä, että he pystyvät yhä paremmin tukemaan liiketoimintaa. Kustannuksia voidaan optimoida tehostamalla prosesseja. Ulkoistettujen palvelujen ohjaus on entistä tärkeämpää. Tietohallintojohtajan toimintaan saattaa vaikuttaa, raportoiko hän talousjohtajalle vai suoraan toimitusjohtajalle. Tulevaisuuden näkymät ovat näiden kahden tutkimuksen välillä muuttuneet synkemmiksi, mikä osaltaan vaikuttaa tutkimustuloksiin.
Aikuisopiskelijat Tom Granroth ja Minna Harjuniemi kertoivat kesän 2011 tutkimuksen tuloksista. Suomalaiselle tietohallintojohtajalle kustannusten optimointi on tärkeämpää kuin tietotekniikan lisäarvon tuottaminen. Kansainvälisen tutkimuksen mukaan investointien takaisinmaksuaika lyhenee jatkuvasti, mutta suomalaisen tutkimuksen mukaan pysyy ennallaan. Miksi?
Suomessa kustannuksia optimoidaan jatkuvissa toiminnoissa. Vihreästä tietohallinnosta ei Suomessa puhuta – mikä saattaa johtaa ristiriitaan organisaation ja sen tietohallinto-osaston arvojen välillä.
Suomalaisessa tutkimuksessa tietohallintojohtaja piti kustannusten vähentämistä tärkeimpänä, kun taas kansainvälisessä tutkimuksessa sen edelle nousivat liiketoimintainnovaatiot.
Mittaamisessa on olennaista, mihin mitattavia asioita verrataan. Mitattavat asiat nousevat tärkeiksi: sitä saadaan, mitä mitataan.
Heikki Saarinen esitteli myös toisen kesän opiskelijaprojekteista, joka koski valtion IT-johtamisen konsernimallin ja tietohallintolain toteutumisen vaikutusten arviointia. Tietohallintolaki astuu voimaan 1.9.2011. Sen mukaan toimijoiden pitää kuvata kokonaisarkkitehtuuri ja yhteentoimivuudet sekä ylläpitää hankesalkkua.
Aikuisopiskelija Jari Nirvinen pohdiskeli, että kun nyt konsolidoidaan, niin hajautetaanko kohta taas. Mielenkiintoista on, että tietohallintolaki ei koske Kelaa eikä eläkesektoria. Lain vaikutusten arviointi saa toimittajan hykertelemään, mutta ei välttämättä veronmaksajaa.
Jussi Suomi Business Technology Finlandista kertoi Haaga-Helian liiketalouden koulutusohjelman opinnäytetyöstään, josta innostui niin paljon, että suuntaa ylempään ammattikorkeakoulututkintoon.
Päätöksentekijä ymmärää yleensä sen, mitä näkee näytöllä, mutta ei välttämättä näkemänsä taustoja. Johto ymmärtää, kun puhutaan euroista. Tietohallinnon päätöksentekomatriisissa kuvataan, mitkä roolit osallistuvat mihin tehtäviin. Yksinkertaisella tietohallintoympäristöllä tarkoitetaan mietittyä kokonaisuutta, joka on tehty mahdollisimman yksinkertaiseksi.
Opinnäytetyön kehityshankkeessa käytetään Porterin viiden markkinavoiman mallia. Jokaiselle markkinavoimalle löytyy tietohallintoon liittyvä kysymys. Nelikentässä kuvataan järjestelmän käytettävyys ja uuden teknologian tarve. Liiketoiminnan testaamisessa otetaan huomioon kehityshankekustannukset, joiden pitäisi maksaa itsensä takaisin. Siksi kehityshankkeiden osuus tietohallintokustannuksista on kiinnostava.
Reino Myllymäki CxO Mentor Oy:stä puhui liiketoiminnan ja tietohallinnon yhteenlinjaamisen ansasta ja sen välttämisestä. Yhteislinjaamisen ansalla tarkoitetaan sitä, että kustannukset nousevat, mutta tulos ei. Turvallisempaa olisi tehostaa tietohallintoa ja sitten ponnistaa ylös: kasvaa tietohallinnolla. Tehokas tietohallinto on liiketoiminnalle mieluinen kumppani. Suurimmat yhteistoiminnan esteet ovat puutteet johtamis- ja projektikulttuurissa, prosessien ja tietojen omistajuudessa sekä tietohallinnon terminologiassa. Myös tietohallinnon edustajat myöntävät, että heidän terminologiansa vaikeuttaa yhteistyötä liiketoiminnan edustajien kanssa.
Aikuisopiskelija Sari Kanto kertoi, että johtamiskulttuuriin kuuluvat mm. delegointi, rekrytointi sekä tietohallinnon ja liiketoiminnan suhteet. Osaoptimointi saattaa toteutua niin, että koulutuksesta tingitään. Roolit pitäisi määritellä ja noudattaa kurinalaisuutta tietyissä asioissa. Viestintä edellyttää sosiaalisuutta ja kulttuurin tuntemusta. Viesti ei mene perille, jos termejä ei ymmärretä. Klusterointi saattaa naispuoliselle keskustelukumppanille tuoda mieleen varasukkahousut käsilaukussa, niin, ja jokainenhan tietää, että pilvessä ei töissä olla.
Reino Myllymäki korosti, että ongelmat ovat aika pitkälti samoja kuin 1960-luvulla. Kaikki on kiinni ihmisistä, sopivien ihmisten löytämisestä. Liiketoiminnan edustajille on helpompi opettaa tietohallintoa kuin päinvastoin. Lopuksi hän totesi: “Strategisia virheitä ei korjata operatiivisilla tempuilla.”
Seminaari muistutti mieleeni neuvot, joita sain etsiessäni opintojeni suuntaa 1970-luvun alussa. “Älä hullu opiskele tietojenkäsittelyä, se on sama kuin opiskelisit konekirjoitusta. Opiskele sisältöaineita. Kun hallitset ne, niin opit kyllä nopeasti niiden käsittelyssä tarvittavan tietojenkäsittelyn.” Tuon neuvon sain parin pysäkkivälin raitiovaunumatkalla Kolmen sepän patsaalta Porthaniaan, mutta se jäi lähtemättömästi mieleeni.
Kymmenen vuoden aikana vakuutusyhtiöissä järjestelmäsuunnittelijan tehtävissä huomasin, kuinka paljon vaativampaa on ymmärtää käyttäjien ja asiakkaiden tarpeita kuin kulloisessakin organisaatiossa käytettävää tietotekniikkaa – vaikka jälkimmäinen onkin muuttunut kiivaassa tahdissa.

Hiljaista tyhjäkäyntiä

it pyörittää
tyhjäkäyntimyllyä
ylläpidossa

hiljainen tieto
huutaa, kodifioidaan
tietokantoihin

innovoimalla
muisti talteen, liikkeelle
osaamiseksi

Sytyken jäsentilaisuudessa Nokialla 31.3.11 Pentti Salmela pohdiskeli, miten hiljainen tieto saadaan talteen ja tuottamaan it:n avulla. Suomihan on jonkin tilaston mukaan pudonnut tietoyhteiskuntakehityksessä sijalle 20.
Pentti Salmela puhui it-toiminnan tyhjäkäyntimyllystä: perustason järjestelmiä ja laitteita uudistetaan jatkuvasti, seuraavalla tasolla rakennetaan kalliita erppejä, joiden takaisinmaksuaika on pitkä, eikä koskaan päästä ylimmälle tasolle, jossa it:n avulla saavutettaisiin liiketoiminnan uudistumista, muutosta ja kilpailuetua. Yli 90 % it-toiminnasta menee kertaalleen tuotettujen järjestelmien ylläpitoon. Pyörittävätkö laitetoimittajat tätä myllyä?
Yleisön joukosta todettiin, että teknologia kehittyy luontoystävällisemmäksi ja prosessorit kehittyvät jatkuvasti tehokkaammiksi, joten järjestelmiä ja laitteita pitää uudistaa.
Pentti Salmelan mukaan it-tuottavuus löytyy uudelta tasolta. Organisaation tiedosta vain 5 % on eksplisiittistä ja kodifioitua eli tietokantaan tai käyttöoppaaseen tallennettua, loput 95 % on hiljaista tietoa. Tässä on it-toiminnan potentiaali. Hiljainen tieto voidaan dokumentoida puhumalla ja strukturoida digitaaliseen muotoon. Tästä voidaan johtaa seuraava malli:

  • hiljainen tieto ->
  • puhuttu tieto ->
  • dokumentoitu tieto ->
  • tietokoneohjelman käsittelemä data.

Yleisön joukosta ehdotettiin toisaalta tunteen lisäämistä malliin ennen hiljaista tietoa, toisaalta puhutun ja dokumentoidun tiedon yhdistämistä kommunikoinniksi.
Hiljaista tietoa voidaan tarkastella useasta eri näkökulmasta:

  • filosofisesta – data, informaatio, tieto, älykkyys, viisaus
  • sosiaalisesta – esim. miten organisaatiosta lähtevien työntekijöiden hiljainen tieto saadaan talteen?
  • informaatiologistisesta – miten tieto, joka on osa organisaation muistia,  saadaan liikkumaan, talteen ja tuottamaan?

Miten uusi tieto syntyy organisaatiossa? Projektiryhmä, joka kehittää uutta tietojärjestelmää, tarvitsee kaiken kyseistä järjestelmää koskevan tiedon. Organisaation kehittäminen on yhtä tehokasta kuin muistin liike.
Yleisön joukosta kysyttiin, voidaanko hiljaisen tiedon välitysmekanismi kodifioida, vaikka kaikkea hiljaista tietoa ei haluttaisi kodifioida. Välitysmekanismiksi tarjottiin leirinuotioita, mentorointia ja kisälli-oppipoikajärjestelmää.
Toteamus “Osaan kävellä, mutten tiedä, miten kävellään” kuvannee hiljaista tietoa.
Innovaatio-, projekti- ja it-toiminnan avulla voidaan siirtää tietoa asiakkaan ja käyttäjän uudeksi osaamiseksi. Tähän tarvitaan uudenlaisia menetelmiä. Kun verrataan organisaation toiminnallista mallia ja teknistä toteutusmallia, niin ketterässä kehityksessä nämä saadaan nopeammin lähemmäs toisiaan kuin perinteisessä iteroivan vesiputousmallin mukaisessa systeemityössä.
Pitäisikö it-strategiaa kehittää tietämyksenhallintastrategiaksi?

Peleistä potkua liiketoimintaan

bisnes pelittää
virtuaalitiimeissä
huumori kukkii

pelein opitaan
viestintää, tuottavuutta
yhteistyötä

Pelien mahdollisuudet liiketoiminnassa kiinnostavat. Hetkyn Tietohallintokerhon tilaisuus Pelit ja Business 29.11.2010 toi Otava Mediaan tietohallintokerholaisten lisäksi muita hetkyläisiä ja ei-hetkyläisiä. Tilaisuuden alussa kerhon puheenjohtaja Anne-Maritta Talaslahti esitteli johtoryhmän, joka oli valittu tilaisuutta edeltäneessä vuosikokouksessa.
Kun puhumme käytettävyydestä, tarkoitammeko palvelun vai palvelimen käytettävyyttä? Joudummeko työskentelemään sovellusten kanssa, jotka on kehitetty 1990-luvun alussa ja konvertoitu sellaisinaan graafisiin ympäristöihin miettimättä navigointia tai käytettävyyttä? Pelit ja sosiaalisen median palvelut tarjoavat sovelluksilleuudenlaisia mahdollisuuksia, helppokäyttöisyyttä ja elämyksellisyyttä.
Kristian Tanninen LumoFlowsta, johdatti meidät sosiaalisen median ja pelien maailmaan yritysten välisen yhteistyön tehostamisessa, viestinnässä ja ihmisten aktiivisuudessa, jotka ovat LumoFlown missiona. Vanhassa työskentelytavassa kehitetään prosesseja, uudessa panostetaan sosiaaliseen tuottavuuteen. Sosiaalisen median pelilliset palvelut leviävät nopeasti ja verkostoituminen hajottaa prosessit. Virtuaalitiimeissä kukkivat huumori, aktiivisuus, kilpailu ja tiimihenki.
Esimerkkeinä pelillisyydestä voisivat olla Facebookin Farmville, jossa on enemmän käyttäjiä kuin Twitterissä sekä LinkedInin muistutukset käyttäjän statuksen keskeneräisyydestä: kiihottaahan se päivittämään statuksen valmiiksi!
Projektinhallintajärjestelmiä voidaan perinteisten Basecamp– tyyppisten näkymien sijaanhavainnollistaa pelillisillä koostenäkymillä kuten Panic Status Boards‘ssa . Jälkimmäiset kertovat yhdellä silmäyksellä perinteisiä enemmän ja haastavat aktiivisuuteen.
Blarp Business Live Action Role Play palkitsevinen mittaristoineen tukee yhteisöllisyyttä ja tiedon jakamista. Yhteistyöllä päästään maaliin; tätä asennetta tarvitaan hajautettujen tiimien yhteistyön hallinnassa.
Anu Sivunen Aalto-yliopistosta totesi kommenttipuheenvuorossaan, että käyttäjien kannustaminen on olennaista. Yhä enemmän kehitetään sosiaalista asiakkuudenhallintaa (CRM), jossa asiakkaita palkitaan näkyvästi keskustelualueilla.
Tuomas Syrjänen Futuricelta pohti, miten kuluttajapalveluista voidaan kehittää liiketoimintasovelluksia. Harva kuluttaja jaksaa ottaa selvää, miten palvelu toimii, ehkä pankkipalveluita lukuunottamatta. Siksi ensimmäisen käyttökokemuksen pitäisi olla riittävän yksinkertainen.
Tarvitaanko sovelluksen käyttöön käsikirjaa tai koulutusta vai olisiko pitänyt panostaa käytettävyyteen? Ihminenhän haluaa käyttää sovellusta. Käyttäjä on oikeasti oikeassa ja palaute on tärkeää.
Kun Facebookilta näyttävä Yammer monen mutkan ja neuvottelun jälkeen saatiin yritykseen, kaikki alkoivat käyttää sitä eivätkä kaivanneetkoulutusta tai ohjeistusta. Skype päihittää käytettävyydessä viralliset video- ja puhelinneuvottelujärjestelmät.
Aika on rahaa. Kuinka suuri on yrityksesi digitaalinen varasto: kaikki tehty, mitä ei ole jaettu käyttäjille?
Käytettävyys vaatii usein yksinkertaisesti, että viitsitään käyttää jonkin verran aikaa sen kehittämiseen. Joskus käyttettävyys tosin voi maksaa kohtuuttomasti.
Projektit pitäisi muokata lyhyiksi ja priorisoida. Kun nopeasti saadaan jotain tuotantoon, opitaan myös nopeasti.
Eri palveluita käytetään eri tavoin. Hyvin toimivien, mutta käyttöliittymältään kömpelöiden järjestelmien päälle voidaan rakentaa välikerros ja siihen käyttöliittymät erilaisille palvelinlaitteille.
Keskustelussa todettiin, että osaaminen, moniosaaminen ja sosiaalisuus ovat valttia. Käyttöliittymävetoisille, toiminnallisuuden hallitseville suunnittelijoille on kysyntää. Paras motivaatipurske suunnittelijalle on tavata oikea käyttäjä, jolle sovellustaan rakentaa.

Ajankohtaisia ajattomia haasteita

vaatimuksista
kehitys palastellaan
muutos hallitaan

omaperäinen
haiku, senryu syöksyy
teoskynnykseen

Kymmenet IT-alan ammattilaiset kokoontuivat TTL:n IT-kouluttajien jäsentilaisuuteen IT-koulutuksen ajattomia haasteita 11.11.10 verkkoon tai Haaga-Heliaan.
Paula Männistö Qentineliltä kertoi kahdesta tietojärjestelmäprojektista, joista ensimmäisessä kaikki epäonnistui ja toisessa onnistui.
Epäonnistunut projekti
Ensimmäisessä projektissa lähtökohtana oli asiakkaan liiketoimintalähtöinen ylätason vaatimusmääritys kahden nykyisen ERP-järjestelmän yhdistämisestä ja muutamien lisäominaisuuksien kehittämisestä. Projekti määriteltiin reilun vuoden mittaiseksi, mutta sitä ei palasteltu. Asiakas pääsi eri vaiheissa testaamaan järjestelmää, mutta mitään valmistuneista ominaisuuksista ei hyväksytty. Jossain vaiheessa todettiin, että vaatimusmäärityksen lisäksi pitäisi laatia selvitys, jota hierottiin yhdeksän kuukautta. Asiakas ei hyväksynyt selvityksen lopputulosta, ja lopuksi keskeytti koko projektin.
Ehkä nälkä kasvoi syödessä. Jäljellä olisi ollut vielä valtavan suuri työ, vuodessa oli saatu aikaan ehkä vasta neljäsosa siitä, mitä haluttiin. Esimerkiksi vaatimusmääritys “Tehdään tarvittava raportointi” paisui lopulta 150 raportiksi, eikä kukaan ei osannut päättää, mitkä niistä olisivat tarpeellisia.
Toimittajan oli pakko hyväksyä tehtäväksi kaikki, mitä asiakas keksi pyytää. Sopimus oli kiinteähintainen ja muutostöitä oli vaikea hinnoitella, joten toimittajalle kertyi tappiota. Hälytyskellojen olisi pitänyt soida jo projektin alkumetreillä.
Vanha järjestelmä oli tavallaan määrityksenä, mutta koodin lukeminen on vaikeaa ja haasteellista, ja ennen kaikkea hidasta. Näytöt ja raportit ovat vain ulkoisia ominaisuuksia, ne eivät vielä määrittele järjestelmän toiminnallisuutta. Toimittaja pyrki laatimaan teknisen määrityksen, mutta toimittajan ja asiakkaan ymmärryksen välinen kuilu oli leveä ja syvä.
Tunnetun nyrkkisäännön mukaan aikatauluarviot pitäisi kertoa piillä, mutta siitä tulisi liian pökerryttävä luku asiakkaalle esitettäväksi.
Onnistunut projekti
Toisessa projektissa oli tarkoitus uusia vain vanhan suurkoneympäristössä toimivan tietojärjestelmän käyttöliittymä web-pohjaiseksi. Asiakas ymmärsi nopeasti, että käyttötapauskuvaukset eivät kata koko toimintaa ja liiketoimintaprosessit vaativat hieromista, joten prosesseja mallinnettiin ja uudistettiin samalla kun käyttöliittymää. Prosessit kulkivat eri osastojen välillä eikä ollut selkeää, missä mitäkin tehdään ja kuka tai mikä rooli omistaa prosessit. Jokainen pääsi esittämään oman näkemyksensä. Vähitellen ymmärrettiin, mitä oikeasti tehdään ja saatiin suoraviivaistetuksi monia asioita.
Toteutustyö jakautui eri mittaisiin iteraatioihin puolentoista vuoden ajalle. Tuotantoon siirrettiin kokonaisuus kerrallaan eikä mitään ylimääräistä tai turhaa työtä tarvinnut tehdä. Asiakkaat pääsivät aidosti vaikuttamaan kehitystyöhön. Muutosvastarintaa pyrittiin pehmittämään tekemällä samanlaista kuin vanha järjestelmä oli ollut ja omaksumalla sopivia toimintatapoja. Muutaman iteraatiokierroksen jälkeen oli opittu paljon, ja seuraavien iteraatiokierrosten suunnittelu oli entistä helpompaa. Nälkä kasvaa syödessä ja työmäärä kasvaa, joten muutoshallinta on tärkeää.
Miksi joskus onnistutaan ja joskus ei?
Onnistuneessa projektissa asiakas oli mukana, ja ymmärsi, että kyse oli asiakasyrityksen liiketoiminnan kehittämisestä ja toiminnan muutoksesta. Toimittaja saattoi työskennellä määrämuotoisesti alusta asti, ja suunnitella, miten kehitystyötä lähdetään työstämään ja miten palastellaan.
Ensimmäisessä projektissa oli pari 10-15 hengen ryhmää, toisessa viiden hengen ryhmä laatimassa perusarkkitehtuuria, viiden hengen ryhmä toteutuksessa ja pari henkilöä testauksessa. Prosessimallinnus sitoutti koko asiakkaan organisaation projektiin, ja teki näkyväksi, miten prosessit kulkevat.
Kiinteähintainen, alhaisen hinnan tarjous, jossa toimittaja tekee tappiota, ei ole kenenkään etu. Sen sijaan ymmärrys työmäärän suuruudesta olisi kaikkien etu. Projektin edetessä ymmärrys tarvittavasta tuntimäärästä vakiintui. Yksittäisten henkilöiden erot koodin tuottamisessa olivat valtavia, ja niinpä vaikeimmat kokonaisuudet annettiin tehokkaimmille koodareille. Koodin tuottamisen tehokkuus laskettiin määrittämällä kullekin käyttötapaukselle pistemäärät niiden vaativuuden mukaan ja niiden toteutuksista laskettiin mekanisesti, kuinka monta tuntia kunkin pisteen koodaamiseen kului.
Työmäärien arvioinnissa käytetään usein Planning poker -menetelmää, jossa jokainen toteutustiimin jäsen mielessään arvioi, paljonko aikaa menisi esitellyn työkokonaisuuden toteuttamiseen, ja nostaa sitä vastaavan kortin näkyviin yhtaikaa muiden kanssa. Tämän jälkeen arvioinneista keskustellaan ja annettuja numeroita perustellaan. Menetelmä on mukava, nopea ja sitouttava.
Ohjelmistotuotannon tekijänoikeudet
Tarmo Toikkanen Aalto-yliopiston Taideteollisesta korkeakoulusta valotti IT-koulutukseen liittyvän ohjelmistotuotannon tekijänoikeusviidakkoa jakamalla tuotokset nelikenttään ulottuvuuksille taiteellinen – hyödyllinen ja fyysinen – eteerinen. Alunperin tekijänoikeuslaki suojasi riittävän omaperäisiä ja tekijänsä persoonaa ilmentäviä taiteellisia ja konkreettisia tuotoksia. Vähitellen tekijänoikeuslain suojaan liitettiin tietokirjat, kartat ja tietokoneohjelmat. Nykyisin kirjat, valokuvat ja elokuvat eivät välttämättä enää ole fyysisia tuotteita vaan bittejä, mutta tekijänoikeus suojaa niitä edelleen.
Tekijänoikeuslaki ei edellytä teoksilta oivaltavuutta. Selittävät kaaviot eivät yleensä pääse lähellekään teoskynnystä: kuka tahansa samalla osaamisella voisi tuottaa olennaisesti samanlaiset kaaviot. Nyrkkisääntönä voidaankin pitää sitä, että jos kukaan saman alan tekijöistä ei samassa tehtävässä päädy samanlaiseen tuotokseen kuin sinä, niin tuotoksesi todennäköisesti ylittää teoskynnyksen.
Alunperin brittiläisen tekijänoikeuden oli tarkoitus suojata kirjapainon tuotoksia ja ranskalaisen tekijän moraalisia oikeuksia. Nämä ovat taustalla nykyisessä EU-maiden tekijänoikeuslaissa. Taiteellisen tai kirjallisen teoksen tekijänoikeus on sen tekijällä, luonnollisella henkilöllä. Sen sijaan työsuhteessa tehdyn tietokoneohjelman omistaa työnantaja, koska työpaikalla tietokoneohjelma laaditaan yleensä yhteistyössä. Työnantaja ei omista tietokoneohjelmaa, joka on tehty itsenäisesti opetus- ja tutkimustehtävissä. Sotilasoppilaitoksissa kaikki tekijänoikeudet kuuluvat oppilaitokselle.
Yleisön joukosta kysyttiin, miten tekijänoikeuslaki suhtautuu Andy Warholin tuotoksiin. Tarmo Toikkanen myönsi, että tekijän nimellä on vaikutusta; tekijänoikeuslaki ei välttämättä ole objektiivinen.
Levitysoikeus on tekijän yksinoikeus. Jos hankkii teoskappaleen, sen voi myydä, mutta sitä ei saa vuokrata. Kavereille saa tehdä kopioita yksityiskäyttöön laillisista lähteistä saaduista kopioista. Sen sijaan tietokoneohjelmia ei saa kopioida yksityiskäyttöön. Teoksesta saa tehdä väliaikaisia teknisiä kopioita ja tietokoneohjelmaa saa muuttaa, jos sen käyttö sitä vaatii. Yhteentoimivuuden vuoksi tietokoneohjelman saa palauttaa lähdekoodiin – jos se onnistuu.
Oppilaitoksessa opiskelijat omistavat tekijänoikeudet laatimiinsa ohjelmiin. Nykyinen tekijänoikeuslaki sallii teosten välittämisen lisenssillä, mutta yhtään lisenssiä ei vielä ole tätä varten tehty.

Ketteryys ja hoikkuus pilvessä

hoikka ketterä
pilvipalvelu, Akva
suuntaa tulevaan

turvallisuutta
osaamista, viestintää
huumori suolaa

Akvan laivaseminaari Ketteryys ja pilvipalvelut 29.9.-1.10.2010 kokosi Vikingin auditorion täyteen innokkaita ict-ammattilaisia bongaamaan uutta tietoa ja verkostoitumaan. Tilaisuuden juontanut Jari Petersen-Jessen toivotti meidät tervetulleiksi ja kertoi Akvasta.
Avauspuheessaan Robert Serén Tietotekniikan liitosta korosti seminaarin ja ict-alan naisvaltaisuutta,  ict:n roolia yhteiskunnassa ja julkishallinnon suurta osuutta koko Suomen ict-markkinoista.
Ketterästi pilvessä
Arto Saario Ixonokselta kertoi, miten pilvipalvelut mahdollistavat ketterän toiminnan. Menestyvillä yrityksillä on toimiva organisaatiokulttuuri, jatkuvan organisaatiomuutoksen sykli. Ketteryys näkyy muutostilanteissa: muutos tunnistetaan, selvitetään sen vaikutukset prosesseihin ja sidosryhmiin, koordinoidaan ja toteutetaan. Muutoksen monimutkaisuutta on vaikea ennustaa.
Perinteisesti palveluita on kehitetty eri yksiköille, vaikka horisontaalinen, kokonaisvaltainen kehittäminen palvelisi paremmin koko organisaatiota. Infrastruktuuri pilvipalveluna IaaS voisi olla sopiva ratkaisu. Alkuinvestointi on pieni, koska pilvipalvelu kestää mahdolliset käyttöpiikit. Pilvimarkkinan kotimaiset palvelut puuttuvat vielä.
Pilvipalveluiden oikeudellisia ongelmia
Pia Ek Asianajotoimisto Hannes Snellmanista valotti meille pilvipalveluiden oikeudellisia ongelmia. ”Insinöörien tehtävänä on keksiä ongelmiin ratkaisut, juristien tehtävänä keksiä ratkaisujen ongelmat.” Ulkoistus ei ole samaa kuin pilvipalvelut (vrt. juokseminen ja lenkkarit).
Jos rekisterinpitäjä on suomalainen, voidaan soveltaa Suomen lakia. Rekisterinpitäjä on osapuoli, joka määrittelee käsittelyn tarkoituksen ja keinot. Sen tulee valita sopivat henkilötietojen käsittelijät ja turvata rekisteröityjen oikeudet sopimusteitse: Miten tietoja käsitellään? Kuka pääsee niihin käsiksi? Missä maassa tiedot sijaitsevat? Lainsäätäjä olettaa, että yksi rekisterinpitäjä vastaa tiedoista. Henkilötietojen käsittelijä on “mykkä toimija”.
Pilvipalvelut vähentävät suoraa kontrollia, mutta lainsäätäjän mielestä kontrollia pitää olla – vaikka   tieto olisi päivällä jossain ja yöllä jossain muualla sen mukaan, missä milloinkin tiedon säilyttäminen olisi halvinta.
EU- ja ETA-alueen ulkopuolella tietosuojan kannalta turvallisia maita ovat Argentiina, Kanada ja Sveitsi. Yhdysvalloissa tietosuojaa ei ole juuri lainkaan. Siellä Safe Harbour -säännöksiin liittyneiden palveluntarjoajien kanssa tilanne on hiukan helpompi, mutta silti nyrkkisääntö on, että kannattaa käyttää ainoastaan sellaista pilvipalveluntarjoajaa, jonka tietokeskus sijaitsee EU- tai ETA-alueella. Kannattaa myös varmistaa, että sopimuksessa pilvipalveluntarjoajan kanssa käytetään komission hyväksymiä mallilausekkeita, ja ottaa huomioon mahdollinen alihankinta.
Palvelusopimusmaailman viidakosta löytyvät palvelutasosopimus (SLA), joka takaa palveluiden toimimisen sovitulla tavalla, vuokrasopimus esimerkiksi ASP-palveluissa, palvelusopimus ja ulkoistussopimus. Pilvipalvelut tarjoavat matalan kynnyksen sisäänpääsyn ja mitoitusmahdollisuudet, mutta monet julkisesti saatavilla olevista pilvipalvelusopimuksista rajoittavat tarjoajan vastuuta niin paljon, ettei se ole linjassa mahdollisen riskin kanssa. Mistä saadaan korvaus, jos ei päästä pilvessä olevaan kirjanpito-ohjelmistoon? Millaiset ehdot ovat asiakkaan kannalta? Voiko hintoja tarkistaa? Voiko niitä yksipuolisesti muuttaa?
Tarkastus- ja auditointivaatimukset on hyvä ottaa huomioon. Mihin fyysisesti menet auditoimaan palveluntarjoajan aineistoa? Mitä teet, jos palveluntarjoaja menee konkurssiin? Mitä lakia sopimukseen sovelletaan?
Pilvipalvelut ovat harmaita pilviä juristin näkökulmasta. Toimittaja haluaisi yhtenäistettyjä palveluita ja pitkäaikaisia sopimuksia, mahdollisuutta nopeaan hinnan tarkistukseen ja pakettiratkaisuihin ilman asiakaskohtaista palvelutasosopimusta. Asiakas taas haluaisi räätälöityjä, muokattavia palveluita, varmuutta ja joustavuutta, vakaata hinnoittelua.
Palvelusopimuksissa palvelu pitäisi kuvata selkeästi, palvelutasosopimuksessa määritellä palvelutaso sanktioineen. Onko sopimuksissa määritelty vasteaika, korjausaika ja korjauskeinot? Onko varmistettu tiedon erottelu pilvessä kolmansien osapuolien tiedoista? Mitä tiedoille tehdään, kun sopimus päättyy? Mikä on tietojen palautusstrategia? Pitäisi pyrkiä sopimaan, että oman maan lakeja sovelletaan, mutta onnistuuko se aina?
Pilvipalvelun hankkijan muistilistalla pitäisi olla:

  • SLA:t sekä sopimuksen muodossa että käytännössä
  • Sovellettavat standardit
  • Kenellä on pääsy tietoihin? Alihankinta?
  • Missä tietoja säilytetään? Mitä lakia sovelletaan?
  • Miten ylivoimainen este on määritelty?
  • Sopimuksen päättyminen ja tarjottavat palvelut tietojen siirtämiseen?
  • Hinnoittelu?

Hoikka ja ketterä ohjelmistoturvallisuus
Antti Vähä-Sipilä Nokialta kertoi, miten turvallisuus ja laatu kulkevat käsi kädessä. Ohjelmistoturvallisuudessa avainasia on riittävä koulutus. Turvallinen ohjelmistokehitys sisältää uhka-analyysin, kontrollien valinnan ja jäännösriskien hyväksymisen. Aktiviteettilistoja on useita, esim.  bsimm2, opensamm, ms, safecode.
Uhat analysoidaan vapaamuotoisesti keskustellen, ehkä musta hattu päässä miettien, mitä kaikkea voisi tapahtua. Askel askeleelta -prosesseja ovat tietovuoanalyysi ja STRIDE-malli, jossa kuvataan kaikki prosessit fläppitaululle ja mietitään kunkin uhat. Väärinkäyttötapausten-mallia käytetään vaatimustenhallinnassa: business caseihin lisätään käyttäjätarinoita siitä, mitä ei saisi tapahtua.
Lean tulee sanasta leanness, hoikkuus. Lean tarkoittaa, että kaikki pyritään tekemään mahdollisimman vähäisellä turhuudella. Miten riskienhallintasyklin osat voidaan jalkauttaa niin, etteivät ne riko hoikkuutta? Lean-periaatteen rikkominen rikkoo myös scrumin. Kaikki järjestelmään lisättävät asiat pitää lean-testata. Esimerkiksi hoikkuus rikkoutuu ja flow tuhoutuu, jos keskitetyltä tietoturvatiimiltä pitää hakea hyväksyntä jokaiselle tehtävälle asialle. Hyväksyttävät asiat kasautuvat ja käsiteltäväksi jää isoja möhkäleitä. Hoikkuus säilyy, jos jokainen tiimi hoitaa asian itse ”soihdunkantajan” johdolla käyttämällä valmiita malleja – ja pyytää neuvoa keskitetyltä tietoturvatiimiltä vain tarvittaessa. Soihdunkantaja, keskitetty tiimin sisäinen konsultti, on henkilö, joka kysyy juuri ne hankalat kysymykset.
Hoikkuus rikkoutuu, jos uhka-analyysit ja tietoturvatestaus tehdään muun ohessa, omassa sprint-työjaksossaan tai erikseen järjestettynä aktiviteettina, koska sellaista ei pystytä hallinnoimaan srcumilla. Tietoturvatyö kannattaisi aikatauluttaa samanlaisiksi backlog-tehtäviksi kuin muutkin työt.
Tietoturva pitäisi analysoida vaatimusmäärittelyssä ja suunnittelussa. Koodin mukana toimitetaan jäännösriski koodin vastaanottajan hyväksyttäväksi. Kukin hyväksyy jäännösriskin omalla tasollaan, jolloin epäonnistuminen ei ole katastrofi ja ylempänä on aina veto-oikeus. Virheellinen hyväksyntä hukkaa korkeintaan yhden sprintin työn, jos ylempänä todetaan toisin.
Ohjelmistokehityksessä erotetaan vaatimustenhallinnan ja toteutuksen taso. Edelliseen liittyvät käyttötapaukset ja bisness caset, jälkimmäiseen koodi ja bitit. Vaatimustenhallinnassa ohjelmistoturvallisuudesta huolehditaan niin, että tuotteen omistaja käy lävitse käyttäjäkertomuksia ja generoi niistä turvallisuuskertomuksia mallien pohjalta (jotka heijastavat yrityksen ongelmia) ja väärinkäyttökertomuksia (mitä ei saa tapahtua; hyökkääjänä en saa pystyä tekemään tätä ja tätä, jotta tätä ei tapahtuisi). Näitä voidaan käyttää toiminnallisina vaatimuksina tai testitapauksina. Turvallisuuskertomukset ovat toiminnallisia tietoturvavaatimuksia.
Ohjelmistoturvallisuus scrumissa tarkoittaa, että scrum-tiimi ottaa tehtävän backlogista ja katsoo, pitääkö tehdä uhkatarkastus; käsitteleekö tehtävä käyttäjätietoja tai luottokorttitietoja? Näin uhka-analyysitehtävät aikataulutetaan ja voidaan sanoa, onko ne tehty vai ei. Erillistä listaa kontrolleista ei tarvita vaan kaikki syötetään tehtäväjonoon.
Jäännösriski hyväksytään sprintin katselmuksessa, jossa päätetään, ovatko sprintin tehtävät valmiita. Tällöin tarkastellaan suorituskykyä ja tietoturvaa: Kun otetaan huomioon uhat, jotka olemme löytäneet, niin onko tehty työ kunnossa turvallisuusnäkökulmasta? Koodin mukana tuleva jäännösriski voidaan esittää esimerkiksi wikisivulla.
Ketterä ostaminen
Perttu Tolvanen Sinisestä meteoriitista pohdiskeli ketterää ostamista. Organisaatio voi hankkia uuden tiedonhallintojärjestelmän tai toiminnanohjausjärjestelmän, mutta miten se saa yksilöt työskentelemään yhteisillä alueilla henkilökohtaisten alueiden sijaan? Ihmisiähän ei voi pakottaa muuttamaan toimintaansa.
Tiedonhallintajärjestelmiä on tuotteistettu aktiivisesti yli 10 vuotta, niillä on tietynlainen filosofia, jonka mukaan ne toimivat, ja se vaikuttaa tuotteiden ratkaisuihin. Kuitenkaan ei ole vain yhtä oikeaa tapaa tehdä ryhmätöitä. Järjestelmiä ei voi määritellä kuoliaiksi: tärkeimmät käyttötapaukset selviävät ja hioutuvat vasta käyttöönoton jälkeen. Ensimmäiset kuusi kuukautta ovat ratkaisevia, niiden aikana uusi järjestelmä muovataan tutkemaan tietotyöläisten tarpeita.
Kustannustehokkuus ja hyvä käytettävyys syntyvät siitä, että tuotteita käytetään niiden filosofian mukaisesti, kun taas tuotteiden taivuttaminen filosofiasta eriäviin käyttötarkoituksiin on vaikeaa ja kallista. Järjestelmä pitäisi saada käyttöön mahdollisimman pian, jotta päästään keräämään käyttökokemuksia.
Korjauksiin pitää varautua heti käyttöönoton jälkeen ja tiedot virhetilanteista välittää toimittajalle heti. Jos niitä kerätään palaute-exceliin ja soitetaan toimittajalle, niin tämä ehkä löytää aikaa listan läpikäyntiin vasta kuukausien kuluttua, jolloin saattaa mennä vuosi ennen kuin käyttäjien ensimmäisenä päivänä havaitsemat virheet on korjattu. Tiedonhallinta- ja tuotepohjaisilla järjestelmillä pitäisi aina edetä pilotilla.
Asiakkaan pitää ottaa vastuu hankinnoistaan, tehdä riittävän hyvä esitutkimus ja priorisoitu vaatimusmääritys. Enää ei voida lähettää tarjouspyyntöjä toimittajille ja odottaa, että nämä vastaisivat jotain fiksua, ei myöskään lähettää pitkää ominaisuuslistaa ja kysyä, vastaako tuote niihin. Järkevämpää on selvittää, miten kentällä olevat tuotteet hoitaisivat kymmenen tärkeintä vaatimusta. Asiakkaan on valittava, haluaako hän valmiin tuotteen vai räätälöidyn tuotteen, ne eivät toimi filosofisesti yhdessä. Maailmassa on myyty miljoonia maksavia portaaliratkaisuja asiakkaille, jotka eivät olisi sellaista tarvinneet.
Ketterä hankinta
Petri Heiramo Agilecraftista totesi, että ketteryys on haastavaa ja tarjouspyynnössä luodaan pohja onnistumiselle tai epäonnistumiselle. Jos pyydetään vaiheittaista toimitusta, toimittaja ei voi toimittaa ketterästi. Hankintalainsäädännön mukaisesti on hankalaa tilata ketterästi, muttei mahdotonta. Ketterässä hankinnassa asiakas sitoutuu ohjaamaan projektia koko ajan ja ottaa siitä vastuun.
Ketteryys koskettaa koko organisaatiota ja johto määrittelee viime kädessä ketteryyden onnistumisen. Ongelmat on tunnustettava ja korjattava, muuten mikään ei muutu. Ketteryys tuottaa kustannussäästöjä pitkällä tähtäimellä, mutta alkuvaiheen kustannukset ovat isot.
Laatu ei ole parametri, josta voidaan neuvotella. Mitä enemmän on tehty purkkaa ja teknistä velkaa, sitä vaikeammaksi tulee tiimin ketteryys. Jos hyväksytään tavoitteeksi 95 %:n laatu, ei kasvateta nälkää tehdä hyvin.
Älä yritä liian suurta kerralla, koska ympäristö muuttuu jatkuvasti eikä isoa projektia ole helppo ohjata. Jos tuloksia ei tule, vaihda toimittajaa. Ketterässä projektissa budjettivastuu siirtyy asiakkaalle, tuotepohjaisessa pikselien viilaaminen on kallista. Jos tietoturva on tärkeää, siihen pitää käyttää aikaa ja rahaa. Tiimi voi kertoa, mitä oikeasti tapahtuu. Tiimillä pitäisi olla suora yhteys todellisiin käyttäjiin, ei vain tilaajaan. Vaatimusten tarkentamiseen ja priorisointiin tarvitaan aikaa.
Älä hajauta, jos se ei ole välttämätön pakko. Viestintä on ketteryydessä olennaista ja hajautus luo aina kynnyksiä keskustelulle. Jos ulkoistat Kaukoitään, niin vaikka työvoima siellä olisi paikallista  halvempaa, kustannuksia syntyy ja yleensä alihankintatyöt ovat muita kalliimpia. Ainoat järkevät syyt ulkoistamiselle ovat joko se, että läheltä ei saa tarvittavaa osaamista tai että läheltä ei saa riittävästi kapasiteettia. Mikään ei muutu, jos mitään ei muuteta.
Allekirjoitus pilvessä
Kai Linnervuo Signomista totesi, että sopimuksia ja muita asiakirjoja tulostetaan ja allekirjoitetaan yhä vielä käsin, vaikka sähköinen allekirjoitus on teknisesti mahdollista. Perinteinen tapa sopimusten allekirjoittamiseen on tuttu: tulostetaan nippu sopimuksia, lähetetään ne postitse allekirjoitettaviksi, odotetaan, kysellään perään muutaman kuukauden kuluttua. Onko meillä todellinen varmuus siitä, että tietyllä henkilöllä on valtuudet allekirjoittaa ja onko allekirjoitus kyseisen henkilön? Kun sopimukset sitten tulevat allekirjoituskierrokselta, ne arkistoidaan mappeihin hyllyyn ja mahdollisesti skannataan arkistointijärjestelmiin.
Yritykset allekirjoittavat vuosittain satoja sopimuksia. Signom-tavassa sopimukset allekirjoitetaan luontevasti osana sopimusprosessia. Luotettavuus saavutetaan, kun kolmas osapuoli, patentti- ja rekisterihallitus, autentikoi sopimukset. Allekirjoittaja todennetaan vahvan tunnistamisen menetelmällä, tarkistetaan toimivalta ja varmistetaan allekirjoitettavan sopimuksen eheys. Järjestelmä on juridisesti vahvempi ja parempi kuin perinteinen.
Signomin allakirjoitusprosessissa vaihdetaan ja hiotaan sähköpostitse ensin doc-tiedostoja, kuten perinteisessäkin prosessissa. Kun sopimuksen lopullinen sanamuoto on valmis, sopimus muutetaan pdf-muotoon. Toinen osapuoli lataa sopimuksen Signomin palveluun ja kertoo toisen osapuolen, valitsee kielen ja maksutavan, esim. sopimuksen lähettäjä maksaa vastaanottajan puolesta kuten perinteisissä vakuutusyhtiön ja asiakkaan välisissä sopimuksissa ”vastaanottaja maksaa kulut” -vastauskuorineen. Järjestelmä tarkistaa lähettäjän oikeudet ja lähettää sopimuksen kryptatulla varmenteella vastaanottajalle. Vastaanottaja voi allekirjoittaa sähköisesti, mutta halutessaan hän voi tulostaa sopimuksen ja allekirjoittaa sen perinteiseen tapaan.
Jos allekirjoittajia on useita, palvelu tarkistaa, että allekirjoitetut versiot täsmäävät. Kun sopimus on allekirjoitettu, jokainen osapuoli saa viestin ja voi vuorokauden sisällä ladata allekirjoitetun sopimuksen itselleen. Sopimus poistetaan järjestelmästä, mutta sopimusloki jää jäljelle, jotta riitatapauksessa vuosien kuluttua voidaan nähdä, kuka on allekirjoittanut ja millaisin tunnuksin.
Tavoitteena on, että Signomin sähköinen allekirjoitus olisi standardi vuoteen 2016 mennessä.
Muistan hyvin perinteisen allekirjoitusprosessin Tietie-yhteistyön ja Virtuaaliammattikorkeakoulun sopimuksista 2000-luvun alkupuolelta. Itsekin kannoin sopimuksia rehtorillemme allekirjoitettavaksi, postittelin niitä muihin oppilaitoksiin ja soittelin perään, kun sopimusnippu oli kesälomalla juuttunut jonkun pöydälle.
Elisan pilvet
Kari Terho Elisalta kertoi eCloud-palveluista. Asiakas saa tarvitsemansa kapasiteetin ja maksaa vain siitä. eCloud joustaa myös alaspäin. Palvelimet saa käyttöön minuuteissa, virtuaalisen tietokonekeskuksen perustamiseen menee noin puoli tuntia, kun perinteisen konesalin perustamiseen menisi useita viikkoja.
Yrityspilvi – EnterpriseCloud, sisältää intergrointipalvelut ja vahvan tunnistuksen. Pilven ohjelmisto on auditoitavissa, sitä voi tulla vaikka taputtelemaan. Kari Terho vakuutti myös, että Elisa ei mene konkurssiin.
Tulevaisuuden pilvipalvelut
Janne Järvinen F-Securelta kertoi Tivitin kanssa käynnissä olevasta tutkimushankkeesta, jonka tavoitteena on luoda uudenlaista suomalaista liiketoimintaa. Tunnistettuja haasteita ovat kasvavat käyttäjävaatimukset, nopeus vaihtaa palvelusta toiseen ja palvelutason jatkuva nostaminen. Avoimet palvelut tulevat ja niitä voidaan yhdistää pilvessä, mutta kuka vastaa tietoturvasta?
Perinteisen ohjelmistotuotannon sijaan painopiste on pilven ohjelmistokehityksessä. Millaisia olisivat tulevaisuuden pilvipalvelut? Organisaation pitäisi olla huipputehokas ja sen pitäisi tavoitella  kestävää kehitystä, ylivertaista käyttäjäkokemusta ja tietoturvaa. Millainen olisi hoikin ja ketterin ict-organisaatio? Lean-konferensseissa kehitetään hoikkia arvoketjuja toiminnan tehostamiseksi, mutta ohjelmistoalan yrityksiä siellä ei juurikaan tapaa.
Projektin laajuuden arviointi
Paula Männistö Qentineliltä puhui projektin työmääräarviosta, joka perustuu vaatimuksiin. Projektin laajuuteen vaikuttavat halutut ominaisuudet ja niiden toteuttamiseen tarvittava työmäärä. Kohdealue nähdään usein pilvenä. Kuinka tarkasti pitäisi määritellä, ettei määriteltäisi kuoliaaksi?
Vaatimusmäärittelyä tarvitaan tarjouspyyntöön ja tarjoukseen ja testaukseen. Jokaisen pienen käyttäjän tarpeet pitäisi selvittää, samoin yhteydet muihin järjestelmiin. Vaatimusten kerääminen ja kirjoittaminen eivät ole helppoja tehtäviä, mutta ilman niitä ulkopuolisen toimittajan on vaikea laatia tarjousta. oskus kuvaus voi olla niin sekava, että oikeiden asioiden löytäminen on vaikeaa. Joskus taas vaatimuksia kirjoitetaan testausvaiheessa, jotta pystytään testaamaan. Mitenkähän järjestelmä on rakennettu ilman vaatimuksia?
Kumpi tärkeämpää, asiakkaan vai toimittajan osaaminen? Keskustellaanko paperinipun kanssa vai keskustelevatko ihmiset keskenään? Kaikki toimittajat pitäisi saada saman pöydän ääreen. Jos projektin alkupäässä hommat viivästyvät, niin pidetäänkö silti kiinni sovitusta valmistumisajankohdasta? Muutosten hallintaan liittyy vaatimusten hallinta, jossa sekä asiakas että toimittaja oppivat.
Paula Männistö havainnollisti tilannetta kolmiolla, jonka kärjissä olivat osaaminen, prosessi ja esitystapa ja jonka keskellä oli viestintä ja yhteistyö.
Keskustelussa pohdittiin, haluaako tilaaja oikeasti tietojärjestelmää vai jotain ihan muuta. Onnistuneissa projekteissa tavoitteena on yleensä jokin toiminnan muutos, ja tietojärjestelmän kehittäminen on vain osa toiminnan muutosta. Valitettavan usein kuitenkin tilataan vain tietojärjestelmää eikä toiminnan muutos näy toimittajalle asti.
Prosessien kuvaukset helpottavat kokonaistilanteen hahmottamista. Käyttäjien ja roolien avulla  pitäisi löytää vaatimukset. Tilaajan vastuulla on tehtävien jatkuva priorisointi, toimittaja ei priorisoida.
Ketteryys Itellassa
Pipsa Ylä-Mononen kertoi ketteryydestä Itellassa, jossa scrumia on käytetty nelisen vuotta aikatauluvaatimusten vuoksi. Vaatimukset syvenevät, niitä arvioidaan ja todennetaan jatkuvasti. Toteutustapa on testauslähtöinen ja liiketoiminta pääsee konkreettisesti iholle, vaikka liiketoiminnan edustajat eivät pääse ulkoistamaan vastuutaan.
Projekteja katselmoidaan säännöllisesti kahden viikon iteraatioissa. Varttitunnin mittaisia scrum-kokouksia pidetään päivittäin. Projekteissa tarvitaan avointa ja jatkuvaa viestintää. Parhaiten se onnistuisi samassa työhuoneessa, mutta joskus tiimin edustajat ovat eri kaupungeissa. Jos asiantuntijat eivät saa vaatimuksia paperille, joudutaan lypsämään, työstämään ja esittämään hypoteeseja siitä, miten asia voisi olla.
Projekti eri vaiheissaan onnistuu parhaiten tasaisesti työskennellen ja huumorilla ammatti- ja viestintätaitoisten ihmisten kanssa. Jos ostetaan ulkoa, kuvataan prosessit ja niiden muutokset sekä käyttötapaukset. Jos tehdään itse, kootaan ryhmä omia suunnittelijoita eri taloista, koodataan parityöskentelynä ja valvotaan laatua sisäisesti.
Scrum ei tee tai automatisoi määrittelyä tai tahtotilaa, ei hyväksymis- tai käyttöliittymätestausta eikä arkkitehtuuri- ja teknologiavalintoja. Tilaaja päättää, onko järjestelmä valmis. Scrumiin liittyvät käsitteet täytyy kouluttaa, jotta ihmiset ymmärtävät, mistä on kyse. Taannoin joku tuli puolen vuoden kuluttua kysymään, mitä inkrementti on, kun siitä oli koko syksy puhuttu. Käsite olisi pitänyt selittää ja avata heti alussa.
Onnistumisen edellytyksiä ovat jatkuvan ja avoimen tiedonkulun varmistaminen, riittävä suunnittelu, sprintin ulkopuolisten tehtävien vaatiman työajan ennakointi ja tiimin itseohjautuvuus. Liiketoimintayksiköistä tarvitaan riittävää resurssointia, sitoutumista ja priorisointia. Jos sama henkilö on ydinasiantuntija yli kymmenessä projektissa, miten hän jakaa aikansa? Lojaalisuus ja ymmärrys järjestelmien linkittymisestä toisiinsa on uskomatonta kavereilla, jotka ovat olleet talossa kymmeniä vuosia, mutta mitä tapahtuu, kun he jäävät eläkkeelle?
Tekemällä oppii, muutaman sprintin jälkeen tekeminen lähtee kunnolla käyntiin. Testaus on osa sprinttiä. Joka sprintillä on oma bugibudjettinsa, jotta virheet eivät kasaantuisi. Bugittomia tarinoita seurataan. Kun sprintti meni ilman bugeja, jaetaan kakkua kaikille, kun bugeja tulee paljon, istutaan töttöröhattu päässä – idea oli suunnittelijoiden oma. Olennaista kuitenkin on, ettei haeta syyllisiä vaan tehdään uutta ja katselmoidaan se, ettei tarvitsisi myöhemmin ihmetellä.
Itellassa tiimille hankittiin oma valkotaulu ja pöytä – josta sai aika pitkään keskustella arkkitehdin kanssa. Tiimihengen luominen ja motivaatio on tärkeää, jotta tiimi toimisi itseohjautuvana asianomistajana ja kehittäisi laatua oma-aloitteisesti.
Ketterä testaus

Maaret Pyhäjärvi Ilmarisesta kertoi ketterästä testaamisesta. Testauksessa on yleensä rajallinen budjetti, kohteena monimutkainen ja laaja kokonaisuus,  jossa tulee vastaan yllättäviä ongelmia ja  jatkuvaa muutosta, jolloin on mahdotonta suunnitella mitään yksityiskohtaisesti etukäteen.
Maaret Pyhäjärvi havainnollisti testausta 20 kysymyksen budjetilla, videolla 14 koripalloilijasta sekä wordpadin fonttidialogiin syötetystä luvusta 1639. Videon katselu osoitti, miten perinteinen testaus tekee sokeaksi emmekä huomaa olennaisia virheitä, joita emme osaa odottaa. Wordpadin fonttidialogista Maaret Pyhäjärvi totesi, että testauksessa pitää olla hauskaa, bugeista pitää nauttia, kun niitä löytää. Testaukseen tarvitaan riittävästi vapausasteita, jos halutaan todellisia tuloksia.
Tutkivan testauksen guru on twiitannut: ”Miksi kutsutaan ammattitaitoista lääkäriä? Lääkäriksi. Entä ammattitaitoista testaajaa? Tutkivaksi testaajaksi.”
Testaaja osaa kertoa omasta työkentästään. Maaret Pyhäjärvi kertoi kysyvänsä muutaman kerran viikossa testaajilta, mihin heidän aikansa on kulunut ja trendi on mielenkiintoinen. Toimittajien testausmallien muuttaminen vienee kuitenkin vuosia.
Ketterässä tiimissä testaus on ketterää. Testaajilla on vastuu kokonaislaadusta; ei eletä päiväunissa vaan katsotaan, että päiväunet toteutuvat. Sprintin aikana käytetään automatisoituja testejä. Yksikkötestaus pitäisi määritellä ennen toteutusta. Testiohjattu koodaus ei sovi kaikille, joillekin se aiheuttaa ahdistusta, joten muitakin toimintatapoja sallitaan.
Virheet ja vaatimusmuutokset pitää suhteuttaa hintalappuun. Bugi on bugi, mutta ketterässä kehityksessä se voi löytyä jo alkumetreillä eikä vasta lopussa. Suorituskyky pitää testata niin, että tiimi saa siitä myös palautteen.
Ketterää kehitystä ei tehdä ilman määritystä. Vaatimukset voidaan kirjoittaa vaikka valkotaululle ja kuvata eri värein ja täydentää ja lopuksi muokata parempaan muotoon. Palautemekanismi, tuotebacklogi ja muutosten hallinta ovat olennaisia.
Kaikki tiimissä testaavat ja testaaja on tiimin jäsen. Lyhyet sprintit alkuun ovat hyviä, koska ne edistävät oppimista. Tiimi paranee jokaisen sprintin aikana.
Onnistumisen mahdollisuudet lisääntyvät, kun ihmiset saadaan lähemmäs toisiaan ja keskustelemaan. Testaus on  osaavien ja tahtovien ihmisten yhteistyötä, jonka edellytyksinä ovat sopiminen ja sopimukset, työrauha ja luottamus.
Ulkoistaminen
Katriina Joki Tiedosta kertoi ketteristä menetelmistä ja ulkoistamisesta. Vaatimusmääritys tehdään edelleen samalla tavalla kuin aikaisemminkin. Odotusten pitää olla realistiset: Suomen työeläkeosaaaminen on hankittu vuosien aikana eikä sitä hetkessä siirretä muualle eivätkä hinnat putoa heti kun ulkoistetaan. Jokainen suomalainen tietää, mikä on lapsilisä ja millainen ongelma syntyy, jos sen maksu viivästyy – mutta intialainen ei ymmärrä.
Ulkoistamiseen liittyy vastarintaa ja epäluuloja. Monet asiakkaat haluavat dokumentoida suomeksi ja on osa-alueita, joilla ei kunnollista englanninkielistä termistöä olekaan. Ihminen saattaa pelätä menettävänsä työnsä; muualla tehdään sitä, mitä tein aikaisemmin! Voidaanko luottaa siihen, että poissa näkyvistä oleva etäprojektilainen tekee sitä mitä häneltä odotetaan? Entä mitä etäjohtaja tekee, jos jossain työtehtävässä ei voida edetä?
Projektin henkilöstölle pitäisi viestiä selvästi, mitä he ulkoistamisesta hyötyvät. Projektibudjetissa pitää varautua koulutukseen ja matkustamiseen. Matkustaminen ei ole niin kallista kuin miltä se ensin tuntuu, koska toimittajan ja asiakkaan kohtaaminen on tärkeää ja projektiin osallistuvien pitää oppia ymmärtämään muiden osapuolten mallia. Liiketoimintatukeen ja selvittelyyn tarvitaan tavallista enemmän resursseja, työnohjaukseen pitää kiinnittää huomiota ja aikatauluissa pitää varautua tekstien kääntämiseen. Miten projektin organisointi muuttuu, kun maailman ympärillä muuttuu? Miten käännösprosessi etenee, kun määritys ja toteutus iteroidaan?
Kulttuurieroja ei pidä kieltää. Intiassa vaihtuvuus on suurta, ja kuitenkin ihmiset pitäisi sitouttaa projektiin. Intialaisten on vaikea myöntää ongelmiaan, tarvitaan ilmapiiriä, jossa ongelmista voidaan puhua.Tarvitaan myös jämäkkyyttä ja herkkyyttä, erilaisuuden sietämistä ja tasaista työkuormaa, tuska ja kiitos täytyy jakaa kaikille.
Älä hajauta

  • jos et osaa laskea hajauttamisen kustannuksia
  • jos sinulla ei ole työkaluja kokouksiin
  • jos et kouluta ja sitouta henkilöstöä
  • jos laiminlyöt viestinnän etkä kerro, mitä ihmiset hajauttamisesta saavat
  • jos et ole valmis kohtaamaan uutta ja erilaista.

Nextdoor
Marko Taipale Huitaleesta kertoi nextdoor.fi-verkkopalvelusta,  josta kuluttajat voivat ostaa kotitalouspalveluita. Tuotteen rakentamiseen meni 20 miestyöpäivää. Ensimmäisenä päivänä hankittiin tietokone, 70 päivää meni toiminnallisuuden ja 50 päivää käyttöliittymän rakentamiseen ja hiomiseen. Tuotteen elinkaaren eri vaiheissa syntyi erilaisia käyttöliittymiä.
Mikään kuluttajatuote ei elä verkossa yksin. Nextdoorin Facebookin sivulla on 30 000 vierailijaa kuukaudessa ja yli 2000 aktiivista käyttäjää, ilmoitustaulu, 300 avointa ilmoitusta ja 3 päivän vastausaika.
Nextdoorin verkkopalvelua monitoroidaan automaattisesti. Liiketoimintaraportit ja varmuuskopiot tuotetaan päivittäin. Verkkopalveluun imetään Uranuksesta keikkailmoituksia, jotka saavat entistä laajempaa näkyvyyttä.
Verkkopalvelun kehittämisessä teemat selvitetään kahden tunnin istunnossa, jossa kerätään liiketoimintaraportteja, kilpailija-analyyseja ja käytettävyyteen liittyviä pyyntöjä. Teemoista poimitaan kolme, joita halutaan parantaa. Tämän jälkeen parin vuorokauden ideamyrskyssä nostetaan esiin konkreettisia ominaisuuksia, joilla on liiketoiminnallista arvoa ja jotka asetetaan jonoon. Kehitystyö kestää kuusi päivää, joiden päätteeksi tehty ominaisuus testataan varttitunnin automaattiajolla. Ominaisuuden julkaisemiseen menee minuutti.
Ominaisuuden matka ideasta tuotantoon kestää siis kahdeksan päivää. Jos tuotejonossa on seitsemän ominaisuutta, läpimenoaika = (7*8)/2 = 28 päivää.
Ongelmatiimi kuvaa ongelman, jonka ratkaisutiimi ratkaisee. Aiemmin ominaisuus ei mennyt tuotantoon, jos sitä ei hyväksytty. Nyt se menee tuotantoon, jos prosessia ei keskeytetä. Järjestelmästä ajetaan tilastoja ominaisuuksien käytöstä ja poistetaan ne ominaisuudet, joita ei käytetä. Minkä tahansa lapun voi ottaa pois, lapun seinältä tai keskeneräisen tai valmiin palan sovelluksesta.
Huitaleen blogista löytyy yksityiskohtainen kuvaus siitä, miten scrum tähän taipui.
Ketterä ostaminen
Ralf Sontag Huoltovarmuuskeskuksesta kertoi ketterästä ostamisesta. Projektin alussa koulutettiin kaikki projektin organisatioon kuuluvat. Tarjouspyynnössä painotettiin järjestelmäarkkitehtuuria, jossa kuvattiin, mitä ainakin pitäisi saada ja mitä lisäksi voisi olla. Tarjouksen jättäneet koottiin yhteiseen palaveriin, jotta kaikkia kohdeltaisiin tasa-arvoisesti.
Käyttäjätarina kehittyi projektin aikana kumulatiivisesti ja sprinteittäin. Kun määrittely oli karkealla tasolla, ei ollut yllätys, että löytyi tarkennettavia asioita. Gartner Groupin verkkopalvelussa on ketterien menetelmien vastaväitekokoelma.
Akva, 30-vuotias nuorukainen
Loppupuheenvuorossaan Akvalle, 30-vuotiaalle nuorukaiselle, Robert Serén korosti, että ict-alan palkat ovat naisten ja miesten välillä tasa-arvoisempia kuin monella muulla alalla. IT-barometri 2010 -tutkimus kertoo mm., että ict-projektien lopputulokset vastaavat yleensä sovittua, mutta projekteista iso osa ei pysy aikataulussaan ja ict-hankintojen tavoitteista saavutetaan vain puolet. Kaikesta ei tarvitse tehdä hypeä; asiat voidaan pitää yksinkertaisina.

Osaamista, liiketoimintaa ja vettä pilveen

pilvipalvelu
vettä, mielikuvia
taivas rajana

jalat maassa, pää
pilvessä, osaaminen
joustaa, laajenee

Systeemityöyhdistys Sytyken kolmastoista laivaseminaari “Pilviteknologiat – ohutta yläpilveä, näkyvyys hyvä” 8.-10.9.2010 oli suositumpi kuin koskaan: noin sata toimittajien, asiakkaiden ja oppilaitosten edustajaa mahtui mukaan, vaikka kokoushuoneen ahtaat seinät jättivät monta kiinnostunutta rannalle.
Ilkka Pirttimaa johdatteli Spotifyn kautta pilvipalveluihin, esitteli seminaarityöryhmän ja sponsorit. Sytyken puheenjohtaja Juha Jääskinen jatkoi kertomalla Sytyken toiminnasta ja osaamisyhteisöistä. Yhteistyötä oppilaitosten ja yritysten kesken syvennetään, verkkosivusto uusitaan lähikuukausina, sosiaalista mediaa hyödynnetään ja Systeemityölehden paperimuotoa pohditaan.
IBM
Jouko Ruuskanen kertoi IBM:n pilvipalveluista, joissa voi nähdä kolme trendiä:

  • yritetään edelleen kehittää soa-arkkitehtuuria lähemmäs liiketoimintaa
  • asiakasyritys voi tapauskohtaisesti ulkoistaa joitain paloja liiketoiminnastaan joksikin ajaksi
  • rinnakkaisuutta lisätään.

Pilven ominaisuuksia ovat virtualisoitu alusta, jossa palvelu pyörii, automatisoitu palvelunhallinta ja standardoidut palvelut. Lisäksi tarvitaan palvelukatalogit, käyttäjärajapinnat, joiden kautta automatisoituja palveluja pyydetään. Tällöin maksetaan vain siitä, mitä käytetään, päästään nopeaan skaalautuvuuteen ja paikasta riippumattomuuteen. Pilvipalveluna menestyy riittävän yleinen palvelu, jota riittävän monet ihmiset haluavat käyttää.
Pilvipalveluiden perustermit ovat SaaS (Software as a Service), PaaS (Platform as a Service) ja IaaS (Infrastructure as a Service). Palveluja voidaan pyörittää paitsi yksityisessä tai yleisessä myös hybridi-ympäristössä, jota kohti kehitys näyttää menevän. Liiketoiminnan kannalta kriittinen data hoidetaan yksityisessä ympäristössä.
Asiakas saattaa olla kiinnostunut palvelun maantieteellisestä sijainnista. Suomen ja EU:n markkinoilla onkin palveluntarjoajia, jotka takaavat, että data sijaitsee maantieteellisesti turvallisessa paikassa.
Perinteisen palvelimen käyttöaste on noin 10-20 %, koska joudutaan varautumaan myös kuormituspiikkeihin. Pilvipalveluissa käyttöastetta voidaan minuuteissa nostaa 70-90 %:iin. Pilvipalveluissa voidaan myydä enemmän resursseja kuin on tarjottavissa, koska kaikki eivät ole yhtaikaa pilvessä.
Pilven toteuttamisen arkkitehtuurisia elementtejä ovat mm. katalogi ja standardoitujen palvelujen templatet sekä automatisoinnin, lisenssien ja palvelupyyntöjen hallinta. Kun käyttäjä kertoo, millaisen palvelun haluaa ja millaisin ominaisuuksin, palvelu haetaan resurssialtaasta, provisointimanageri pystyttää palvelun, jonka jälkeen viesti valmiista palvelusta lähtee käyttäjälle.
Google
Marko Saarinen kertoi Googlen yritysratkaisujen periaatteista: huolehditaan tietoturvasta, hyödynnetään globaalia palvelinverkostoa ja minimoidaan riippuvuus kolmannen osapuolen ohjelmistoista. Offline-palvelut ovat olleet mahdollisia jo vuoden ajan.
Google voi taata, että asiakkaan data on EU:n sisällä, mutta ei voi osoittaa palvelinta, jossa se sijaitsee, koska data on pirstaloituneena usealle palvelimelle moneen palvelinkeskukseen. Ratkaisulla varaudutaan pommi-iskuun johonkin palvelukeskukseen, jolloin data pitäisi nopeasti siirtää toiseen ilman, että asiakas huomaisi katkosta.
Googlella on SAS 70 Type II -sertifiointi prosesseihin, mikä edellyttää tarkkaa kuvausta siitä, kuka pääsee mihin käsiksi, mitä käyttäjätilitietoja saa luovuttaa viranomaisille, miten lisätyt koodit auditoidaan ja evaluoidaan, miten asiat raportoidaan ja miten niihin reagoidaan. Sertifikaatti on FISMA-yhteensopiva. Googlella on myös toimialakohtaisia pilviä, joissa voidaan ottaa huomioon toimialan juridiset vaatimukset datalle.
Googlen palvelut eivät tarvitse uusia asennuksia käyttäjien työasemiin, ainoastaan joitain selainlaajennuksia. Peruspalveluita ovat sähköposti ja toimisto-ohjelmistot, joita ei kannata pyörittää omilla palvelimilla. Melko vähän kustomoitavia peruspalveluita ovat sähköposti, pikaviestintä ja videoneuvottelu, videomateriaalin jakaminen organisaation sisällä turvallisesti, sekä google-sivustot, joiden päälle voi rakentaa omia sivustoja. Lisäksi tarjolla on joukko tietoturvaan liittyviä palveluita, joita voi hyödyntää missä tahansa sähköpostiohjelmistossa.
Esimerkiksi Priority Inboxissa 78 algoritmia määrittelee, mitkä ovat meille tärkeitä sähköposteja ja vähentää viestintävälineiden hallintaan kuluvaa aikaamme. Sähköpostilaatikko on määritelty riittävän isoksi, jotta aikaa ei mene viestien jatkuvaan arkistointiin. Sähköpostit voidaan kontekstin mukaan pinota yhden säikeen alle niin, että viestien sisällöt näkee yhdellä silmäyksellä. Kansiokäsitteestä on luovuttu ja korvattu se viesteihin liitettävillä tageilla; yhdellä viestillä voi olla useita tageja eli se periaatteessa voisi olla useassa “kansiossa”.
Googlen pilvipalvelut sopeutuvat exchange-sharepoint-maailmaan, ja ovat yhteensopivia minkä tahansa Open LDAP -hakemiston kanssa. Googlen palvelut hyödyntävät yksisuuntaisella yhteydellä asiakkaan organisaatiohakemistossa olevia tietoja. Palveluihin tulee jatkuvasti uusia ominaisuuksia, mutta asiakas voi valita, milloin ottaa uudet ominaisuudet käyttöön tai missä rooleissa olevat henkilöt haluavat testata niitä ensin.
Vuonna 2007 Googlella oli vain kolme palvelua; nykyisin tarjonnassa on kymmeniä palveluita, jotka toimivat myös mobiilikäyttöjärjestelmissä.
Salesforce ja Fluido, asiakascase YIT
Kai Mäkelä kertoi Fluidon edustamasta Salesforce-palvelusta ja Tuuli Jahnsson kertoi palvelusta YIT:n näkökulmasta. Fluidon viiden hengen yrityksen ainoa it-infra on reititin, kaikki muu on pilvessä. Salesforce on sertifikoitu monikäyttäjäympäristö, jonka käyttäjämäärä lisääntyy noin 4000:lla yrityksellä vuosittain.
Yritys voi räätälöidä käyttöliittymänsä Salesforce-palveluun, saada sieltä osan palveluista ja liittää niihin omia sovelluksiaan. Liiketoimintalogiikkaa on helppo määritellä klikkaamalla tai koodaamalla.
YIT:llä kaikki prosessikuvaukset olivat jo olemassa, kun Salesforce-projekti alkoi. Käyttäjän näkökulmasta kyse on valistuneesta taulukkolaskennasta. YIT:llä tarvittiin ohjelmisto, jota voidaan kustomoida liiketoiminnan tarpeiden mukaisesti. Muutaman ohjelmiston testaamisen jälkeen Salesforce-valinta oli selvä. Tuuli Jahnson kertoi tehneensä sovelluksen kaikki  kentät omin pienin käsin, mutta ei kuitenkaan ruvennut koodaamaan; hän ei halunnut käyttää aikaansa sellaiseen, joka ei ollut hänen ydinosaamistaan.
Salesforcen käyttöönoton yhteydessä alettiin suoristaa prosesseja, poistettiin sivurönsyjä ja otettiin käyttöön Salesforceen valmiiksi miettitty myyntiprosessi. Salesforce-käyttäjät Wärtsilä, Kone ja YIT pitävät säännöllisesti yhteyttä ja jakavat keskenään parhaita käytäntöjään.
Salesforce tarkistaa, ettei järjestelmässä ole samaa tietoa useaan kertaan. Jos järjestelmän automaattiset huomautukset eivät johda datan korjaamiseen, YIT:n tiimiadministraattorit käyvät huomauttamassa korjaamisesta datasta vastuussa oleville henkilöille.
Parhaillaan YIT:ssä on meneillään Salesforcen integrointi ulkoisiin verkkopalveluihin, toimitilalaskuri, reklamaatioprosessi sekä auditointi.
Keskustelussa todettiin, että pilvipalveluiden integrointi toiminnanohjausjärjestelmiin lienee pilvipalveluiden akilleenkantapää. Voidaanko pilvipalveluiden varmistuksiin luottaa? Koneella data varmistetaan erikseen tiedostopohjaisesti pari kertaa päivässä. Myös YIT ottaa omat varmistuksensa datasta.
Salesforcen transaktioiden lukumäärää voi seurata osoitteessa http://trust.salesforce.com/.
Jyväskylän yliopisto
Lauri Frank Jyväskylän yliopiston ohjelmistoteollisuuden tutkimusryhmästä (SIRT, software industry research team) kertoi Cloud Software Program -tutkimusprojektista, joka vuosina 2010-13 keskittyy pilviteknologioihin, ketterään yritykseen (lean, agile), liiketoimintaan, käyttökokemukseen, tietoturvaan ja energiatehokkuuteen.
Pilvi tarkoittaa tietokonekeskusten laitteita, ohjelmia ja verkkoja. Pilvi voi olla julkinen, yksityinen ja hybridipilvi, joista viimeksi mainittu on selvästi nousussa. SaaS on vuoden 2009 Tietotekniikan termitalkoissa suomennettu ”verkkosovelluspalveluksi”. Termi ei erottele pilvipalvelua räätälöidystä tai ASP-palvelusta. ASPissa joka yrityksellä on oma ohjelmistoversio, tosin monet SaaS-palvelutkin voivat olla räätälöityjä niin, että kaikki eivät käytä samaa palvelua. SaaSissa pieni yritys voi saada kaiken kapasiteetin käyttöönsä, jos muut eivät ole sitä käyttämässä.
Verkkosovelluspalvelun, SaaSin, ominaisuuksia ovat:

  • palveluperusteisuus
  • skaalautuva ja elastinen kapasiteetti
  • jaettu (multi-tenant)
  • käytön mittaus (laskutus)
  • internet-teknologiat (selain tms.)

Pilvipalvelussa asiakkaan ei tarvitse huolehtia päivityksestä, ylläpidosta eikä tietoturvasta. Palvelusta voidaan maksaa erissä tai käytön mukaan. Yrityksen infrastruktuuri ei välttämättä kestä sitä, että kaikki tieto pitäisi hakea netin yli. Läpinäkyvyys ohjelmistoon katoaa. Pilvipalveluiden ominaisuudet ovat yleensä vaatimattomampia kuin räätälöityjen palvelujen.
Uudelle yritykselle pilvipalvelut tarjoavat uudenlaisia mahdollisuuksia, kun yrityksen ei tarvitse hankkia omaa it-henkilöstöä. Pilvipalvelun etuja ovat kustannukset, nopea käyttöönotto ja resurssien optimointi. Haittoja taas ovat palvelutason säilyminen, erityisesti tiedon saatavuus, tietoturva ja tiedon omistajuus sekä integrointi taustajärjestelmiin.
Miten ohjelmistoyritys muuttuu? Yhteys infrastruktuurin toimittajiin voi katketa, mutta palvelun ja prosessin pitää toimia jatkuvasti. Ennusteen mukaan pilvimarkkinat kaksinkertaistuvat vuosina 2008-2012 ja infrastruktuuripalvelut kasvavat 40 %. Pilvipalvelu kohdistuu pitkään häntään; kun palvelun käyttö on runsasta, sen hinta laskee ja samalla käyttäjämäärä kasvaa.
Keskustelussa kysyttiin, voisiko Suomesta tulla suurvalta pilvipalveluiden tuottajana? Meillähän on kylmä ilma, tuhansia järviä, tyhjiä tiloja, vakiintuneet poliittiset olot ja sekä toimivat suhteet Venäjään. Toisaalta tarvitaan investointeja ja hyvät yhteydet muualle; Ruotsin kautta kulkevien yhteyksien sijaan napojen yli Kanadaan.
Reaktor – pilvestä toiseen hyppääminen
Tuomas Kärkkäinen Reaktorilta kiteytti jo aiemmin esitetyn: pilvipalveluista saat skaalautuvuutta, mutta luovut sovelluksen hallinnasta.
Palveluntarjoajaa on joskus pakko vaihtaa: palveluntarjoaja voi mennä konkurssiin, palvelu voi loppua tai palveluntarjoajan kovalevy, jolla asiakkaan tiedot sijaitsevat, saatetaan takavarikoida.
NASAn Nebula-pilvi on sovelluspaketti, jolla kuka tahansa voisi luoda oman pilven. Mårten Mickosin Eucalyptuksella on yksityisen ja julkisen pilven rakentamiseen tuotteet, jotka ovat Api-yhteensopivia Amazonin EC2:n kanssa. Vaikka Eucalyptus on yhteensopiva EC2:n kanssa, sen avulla ei voida luoda EC2:n tasoista palvelua. Nasan ehdottamia parannuksia Eucalyptuksen avoimen lähdekoodin osaan ei hyväksytty, koska ne olivat päällekkäisiä Eucalyptuksen kaupallisen tuotteen premium-ominaisuuksien kanssa.
Vastuullinen pilven käyttö tarkoittaa, että asiakas ottaa vastuun datansa omistuksesta ja hallinnasta. Pilvi on aluksi ilmaista, mutta kustannukset kasvavat vähitellen. Varmuuskopioinnin tasosta voidaan sopia esim. Googlen pilvipalvelussa. Muokataanko liiketoimintaprosesseja sovellusten mukaan? YIT:llä niitä muokattiin jonkin verran, lähinnä objektien relaatioita. Perusdata toki oli samaa, josta yritys tarvitsi tiedot.
Tuomas Kärkkäisen diapakan lopussa oli asiallisesti kiitokset Flickristä otetuista kuvista osoitteineen.
Microsoft – ensimmäinen pilvisovellus kolmessa vartissa
Pasi Mäkinen Microsoftilta kertoi Windows Azuresta, PaaSista, sovellusalustapalvelusta. Pilvipalvelun optimaaliset työkuormat voidaan määritellä sen mukaan, onko kyseessä jaksottainen palvelu (esim. vakuutuspalvelut), nopean kasvun palvelu (esim. alkava yritys) tai palvelu, jossa on ennustettava piikki tai jossa voi olla ei-ennustettavia piikkejä.
Azuressa on skeematon tietokanta, jonka joka rivillä voi olla omannäköinen skeemansa. Skeemojen oikeanlainen käyttö on sovelluksen vastuulla. Vastaava ratkaisu löytyy myös Googlelta ja Amazonilta. Hinnoitteluun ei vaikuta pelkästään sanomamäärä vaan yhtaikaa käynnissä olevien sovellusyhteyksien määrä. Asiakkaille on tärkeää, että he voivat valita, missä data-keskuksessa heidän sovellustaan ajetaan, esim. EU-alueella.
Azuressa on konttipohjainen rakenne, jonka lisäksi tarvitaan vesijohtovettä, ulkoilmaa ja tietoliikennekapasiteettia. Virityksessä haasteellisia ovat olleet kylmät alueet, koska jäähdytysvesi ei saa päästä jäätymään.
Azure-alustalle voidaan siirtää helposti .net, liiketoimintalogiikka ja SQL-server. CGI-pohjaiset sovelluskehikot vaativat enemmän työtä. Uuden Facebookin kehittäminen edellyttäisi suunnittelua ja toteutusta. Tällä hetkellä ei voida siirtää asennuspaketin vaativia tai admin-oikeudet tarvitsevia sovellusympäristöjä kuten SharePoint.
Qentinel – tykistötulta pilvilinnasta
Teemu Vesala Qentinelilta kertoi, että pilvipalveluiden riskejä ovat käytettävyys, tietoturva, suorituskyky ja siirrettävyys. Hän oli testannut kaksi palvelua LoadStormin (SaaS) ja Amazon EC2:n (IaaS).
Toiminnalliset riskit kasvavat, kun järjestelmiä on eri tasoissa. Tietoturvaa on vaikea testata ilman toimittajan kirjallista lupaa, koska järjestelmässä voi olla muidenkin dataa. Käsin prosesseja säätämällä Teemu Vesala sai yhtäkkiä esiin jonkun toisen testiraportit. Virhe korjattiin nopeasti, mutta luottamus järjestelmään himmeni. Onneksi oma asias tiesi, että palvelu oli pilottikäytössä; riskit piti tietää etukäteen ja viestiä asiakkaille. Jos data menee bugin vuoksi jollekulle toiselle, onko se liiketoiminnan kannalta fataalia?
Pilvipalveluissa menetetään kontrolli moneen asiaan, joita mittaustilanteissa tarvitaan. Todelliset kustannukset saattavat jäädä jonnekin piiloon ja olla jotain ihan muuta kuin on kuviteltu. Lisäksi saatetaan tarvita lakimiespalveluita.
DataCenter Finland
Mika Leno DataCenter Finlandilta räätälöi esityksensä yleisölleen. Suomessa on poikkeuksellisen hyvät olosuhteet konesalitoiminnalle: sähkö on edullista, ilmaista kylmää saadaan merestä ja ilmasta, meillä on luotettava infrastruktuuri, korkea koulutusaste sekä yritysystävällinen lainsäädäntö ja valtiollinen toiminta. Merivesi Itämeren alueella on riittävän kylmää ympäri vuoden, kun mennään riittävän syvälle, kun taas järvet eivät ole jatkuvasti riittävän kylmiä, ei edes Laatokka. Järvistä voisi saada sähköä patoamalla, mutta se taas häiritsisi kalojen normaalia kutemista.
Tukholma – Helsinki -taso olisi konesalille optimi, Oulu – Rovaniemi -tasolla jäähdytysvesi saattaisi jäätyä. Menestyvälle konesalitoiminnalle Suomessa tarvitaan kuitenkin nykyistä paremmat tietoliikenneyhteydet ja investointivoimaa.
Tulevaisuuden pilvipalvelut ovat hybridejä, palvelut ovat osin asiakkaalla itsellään, osin pilvessä. Toistaiseksi kaikki vastaan tulevat järjestelmät on pystytty virtualisoimaan. Palvelutuotanto on syytä auditoida ja varmistusten varmistuksista on huolehdittava.
Mika Leno neuvoi ensin kokeilemaan pilvipalveluita, sitten modernisoimaan organisaation teknologiat, prosessit ja ihmisten osaamisen, tuotteistamaan palvelut ja kehittämään strategiaa. Vuoden sisällä organisaatiolle pitäisi kehittää kokonaisvaltainen cloud computing -strategia ja rakentaa dynaaminen cloud computing -hankintaa osaava organisaatio.
Pilvipaneeli
Mitro Kivisen juontama esiintyjäpaneeli totesi, että koulutuksessa olisi hyvä edelleen lähteä tunnetuista arkkitehtuureista ja lisätään niihin pilviteknologiaa ja liiketoimintaa. Pilvet mahdollistavat opiskelijoille ilmaiset välineet, opiskelu- ja tutkimusympäristön. Rikkinäisiä järjestelmiä voisi näyttää opiskelijoille ja kertoa, miten ne olisi saatu toimimaan ja mitä ostajan olisi pitänyt tehdä.
Pilviturvallinen ohjelmointi ei synny liian tiukoilla aikatauluilla. Huono ohjelmisto ei muutu pilvessä paremmaksi. Tietoturva pitää integroida koko sovelluskehitysprosessiin jo määrityksistä lähtien. Hakkeri voidaan mallintaa yhdeksi aktoriksi käyttötapauskaavioon, jolloin voidaan kuvata sisäiset ja ulkoiset hyökkäykset ja keinot niiden torjuntaan. Ohjelmoijien pitää ymmärtää, että ohjelmiston haavoittuvuus testataan ja auditoidaan. Ulkoistuksessa tietoturvaa on vaikea kyseenalaistaa. Tiedemaailmassa taas paras tapa suojata jotain on panna se julkiseksi; silloin sitä ei kukaan huomaa.
Pilviteknologian käyttö kannattaa aloittaa pienessä tutussa piirissä ja laajentaa vähitellen. Koko ratkaisun arkkitehtuuria ei tarvitse muuttaa; jos oma konesali puuttuu, sovelluksen voi viedä pilven reunalle. Erilaisten pilviteknologioiden tuntemus ja kyky yhdistellä niitä nousevat tärkeiksi. Entä jos kaikki käyttävät samoja ohjelmistoja ja muokkaavat prosessinsa niiden mukaisiksi, niin mistä yritykset saavat kilpailuetua?
Pilvestä saa skaalautuvan verkkopalvelun ja testiympäristön silloin, kun sitä tarvitsee, mutta palveluun ei tarvitse sitoutua. Pilviteknologian riskit ja rajoitukset olisi hyvä tuntea ja ymmärtää, ettei kaikkea kannata siirtää pilveen. Pilvi ei sovi luottamuksellisen datan käsittelyyn, tosin kymmenen vuoden kuluttua käsityksemme luottamuksellisesta ja arkaluontoisesta datasta saattaa olla erilainen kuin tänään.

Avoimet pilvet

pilvi purjehtii
pullollaan palveluja
sataa avoinna

julkipalvelut
koulutus, osaaminen
nouseeko pilveen?

Tekesin tilaisuus Open Source and Cloud Computing, FinNoden-projektin Signaalisessio 25.8.2010 keräsi videoneuvottelustudioihin Helsinkiin, Tampereelle ja Ouluun sekä Yhdysvaltoihin reilut puolisataa osallistujaa yrityksistä, korkeakouluista ja tutkimuslaitoksista.
Avoimuus ja pilvet
Mårten Mickos Eucalyptykselta johdatti lyhyesti avoimuuden ja pilvien maailmaan: kaikki muuttuu, myös tietokannat, tosin tällä hetkellä on vaikea löytää pilveen sopivaa tietokantaratkaisua. Vapaan ja avoimen lähdekoodin sovellukset kuten MySQL ja Linux valtasivat alaa 1990-luvulla, nyt 2010-luvulla Yahoon ostanut Microsoft julistaa rakastavansa avoimuutta.
Avoimuus voi tarkoittaa monia asioita: avointa lähdekoodia, avoimia ohjelmistorajapintoja tai avointa dataa. Esimerkiksi Twitterin lähdekoodi ei ole avoin, mutta Twitteriin kirjoitettu data on.
Avoimuus ei vielä ole tuottanut kovikaan monta liike-elämän menestystarinaa, vaikka mukana on monia yrityksiä, konserneja ja sponsoreita. Avoimuus ei myöskään ole pystynyt työasemissa syrjäyttämään Windowsia tai Applea. Monet uudet, merkittävät toimijat, kuten Twitter ja Google, eivät ole avoimia.
Avoimet pilvipalvelut voidaan jakaa kolmeen ryhmään sen mukaan, tarjotaanko palveluna infrastruktuuria, alustaa vai ohjelmistoa: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) ja Software as a Service (SaaS).
Uhat ja mahdollisuudet
Alustuksen jälkeen jokaisessa Suomen videoneuvottelupisteessä keskusteltiin avointen pilvipalveluiden uhista ja mahdollisuuksista. Pilvipalveluiden tietoturvaan ja standardeihin liittyvät kysymykset, lokaalit ja globaalit palvelut sekä julkishallinnon tietojen avoimuus nousivat esiin monissa pisteissä.
Pienelle aloittavalle yritykselle pilvipalvelut lienevät jo itsestäänselvyys; mikä tahansa muu vaihtoehto vaatisi huomattavasti suuremmat investoinnit. Mutta mistä saadaan luotettavaa tukea liiketoiminnalle? Mistä lokaaleja pilvipalveluita pitäisi lähteä ostamaan? Voidaanko avoimilla ratkaisuilla kumuloida osaamista? Voisiko Suomen maailmanlaajuisesti hyväksi tunnistettua koulutusosaamista tarjota pilvipalveluna?
Millaiset tietokannat toimivat pilvessä? Muuttuuko tietokannan ja sovelluksen perinteinen raja? Onko SQL:n merkitys vähenemässä kuten suurkoneiden (Mainframe) – kuitenkaan katoamatta? Näemmekö vihdoin semanttisia objektikantoja pilvissä?
Pohdiskelujemme ja kysymystemme jälkeen Mårten Mickos kertoi oman näkemyksensä. Pilvipalvelut ovat vasta alussa, eikä vielä ole standardien aika: tässä vaiheessa standardit rajoittaisivat palvelut akateemisiksi ja monimutkaisiksi. Kulttuurisidonnainen oppiminen tarjoaa hyvät liiketoimintamahdollisuudet, samoin  julkisen sektorin tietojen avaaminen ja tietoturvapalvelut. Myynti ja ostaminen muuttuvat pilvessä, kun mukaan tulevat kaikki eikä vain nuoriso. Pilvimaailmassa kannattaa muistaa lokaalit liiketoimintamahdollisuudet ja mobiilin pilven tarjonta.