Oppimista, oppimateriaalia ja mittaamista

Mustavalkoinen
filmi rahisee, antaa
perspektiiviä.

Hyvät tekijät
jakavat osaamista,
firma menestyy.

Oppimatskuja
yhdessä, avoimesti
muokataan nettiin.

Monimuotoinen
osaaminen; yhdistä,
sovella, näytä.

Tieken Vaikuta ja vaikutu -seminaari keräsi toistasataa opetusalan ammattilaista ja vaikuttajaa Korjaamon ratikkamuseoon 24.9.2013. Salin valkokankailla näkyivät esitysdiojen lisäksi yleisön Viestiseinälle tai Twitteriin aihetunnisteella #vaikutu kirjoittamat kysymykset ja kommentit, joihin reagoitiin kiitettävästi.
Jatka lukemista ”Oppimista, oppimateriaalia ja mittaamista”

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.

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.

Palveleeko tietohallinto liiketoimintaa?

puhu bisnestä
bisneksen kanssa, iitee
ymmärtää iiteen

pilvi ja some
bisnekseen, panostathan
tietoturvaankin?

Keskustelu ”Tietohallinnon kriittisistä menestystekijöistä” oli vilkasta ja rönsyilevää, kun liiketoiminnan edustajat ja Haaga-Helian opettajat kohtasivat 11.5.2010.
Vesa Tiirikainen kertoi, että kuusikymppisenä, elämän suunnitelmansa puolivälissä, hän rajoitti työntekoaan kolmeen päivään viikossa ja ehti sitten kirjoittaa kirjoja ja TiVin blogia. Hän ammensikin alustukseensa ajatuksia vasta ilmestyneestä kirjastaan IT ja parempi bisnes.
Laman myötä johdon ote bisneksestä paranee. Tietohallinnon edustajien pitäisi puhua bisneksen edustajien kanssa bisneksestä eikä tuhlata kohtuuttomasti aikaa teknisten vempainten valintaan. Johtaminen muuttuu harvoin prosessimaiseksi; voisiko joku vastata koko prosessin toiminnasta riippumatta siitä, ketkä prosessissa toimivat?
Meitä pitkän linjan systeemityön ammattilaisia ilahdutti, kun Vesa Tiirikainen kertoi tietokeskeisen järjestelmäkehityksen palaavan. Tietokeskeisestihän järjestelmiä mallinnettiin 1980-luvun lopulla, kun pyrittiin eroon siitä, että sama tieto olisi yrityksen eri tietojärjestelmissä moneen kertaan, osa päivitettyinä, osa ei.
Vesa Tiirikainen esitteli tutkimuksia erilaisten tietojärjestelmähankkeiden ongelmien laadusta ja vakavuudesta taulukkomuodossa. Mielenkiintoista oli, että eniten ongelmia syntyy it-toiminnan tehostamisratkaisuissa; ulkoistamisessa tai teknisen infrastruktuurin uudistamisessa.
Tietojärjestelmiin liittyvien ongelmien syynä on useimmiten joko epäselvä tavoite tai se, että toteutetaan vain it-ratkaisua, mutta ei muuteta toimintatapaa.
Vesa Tiirikainen julisti, että ihminen on luonnostaan muutoshakuinen eikä muutosta vastustava. Tavoitteen pitää kuitenkin olla riittävän innostava. Mittarit ovat usein ongelmallisia: säästöjä henkilöstökuluissa on vaikea mitata päivittäin säästettyinä minuutteina, jos työtä tehdään yhtä kauan kuin ennen eivätkä palkkakustannukset pienene.
It-painotteisen muutoksen toimeenpanossa tärkeintä on:

  • yhtenäisen tiedon merkitys
  • sidosryhmien hallinta
  • muutosta johtavan ydinryhmän valinta
  • muutoksen johtaminen projektityön periaattein
  • bisneshyötyjen varmistaminen läpi muutoksen.

It:lla on yhä suurempi rooli muutoksessa: miten järjestelmä toimii suhteessa prosesseihin ja organisaatioon?
Jarmo Hallikas valaisi meille tietohallinnon kiehtovaa ja monimutkaista maailmaa laatimallaan miellekartalla ja fläpeillä kuvaamillaan esimerkeillä. Tietohallinto vastaa toisaalta kehittämisestä, toisaalta jatkuvasta toiminnasta. Jos kaikki rahat kaadetaan kehittämishankkeisiin, jatkuvan toiminnan laitteet ja ohjelmistot saattavat rapautua vuosiksi. Liiketoimintayksikkö osaa määrittää liiketoiminnan tarpeet, mutta ei välttämättä ymmärrä, mihin tekniikka taipuu.
Usein järjestelmiä myydään bisnes-johtajille kauniilla lupauksilla, mutta tietohallinnon edustajien kanssa ei haluta keskustella, koska heidät koetaan lähinnä jarrumiehiksi. Menestyvä tietohallintojohtaja keskustelee bisneksen kanssa bisnes-kysymyksistä ja it:n kanssa it-kysymyksistä.
ITIL ratkaisee jatkuvan toiminnan organisoinnista yhdeksänkymmentä prosenttia. Miten loput kymmenen prosenttia hoidetaan? Aiemmin asiakkaan monimutkainen ongelma saatettiin huutaa sermin yli kollegoille: ”Kaverit, asiakkaalla on tällainen ongelma, mitäs sanotte?” Nyt yksi henkilö kirjaa ongelman järjestelmään ja toinen lukee sen sieltä, mikä hidastaa ongelman ratkaisuprosessia.
Yrityksissä tarvitaan edelleen pienen alueen syvällistä asiantuntemusta. Jos jotain osaamista tarvitaan vain muutama kuukausi vuodessa, osaaminen kannattaa ostaa ulkoa. Joskus saattaa olla järkevämpää palkata muutama henkilö hoitamaan tietty asia kuin hankkia sitä varten uusi tietojärjestelmä.
Pilvipalvelut ja sosiaalinen media ovat tulleet bisnekseen, ja niiden myötä tietoturvakysymysten merkitys on kasvanut. Yritys voisi palkata porukkaa hakkeroimaan ja katsomaan, missä kohdassa järjestelmä vuotaa. Sähköpostijärjestelmän lamautuminen vaikka vain puoleksi tunniksi voi olla iso taloudellinen katastrofi, jos yrityksen kaikki sopimukset laaditaan sähköpostitse.
Tietojärjestelmäkoulutus ei saisi olla pelkkää nappulatekniikkaa; olennaista olisi kertoa, miten järjestelmä palvelee toimintaa. Miksei eri järjestelmiin voisi olla samanlaista käyttöliittymää? Tietojärjestelmän lopullinen käyttäjäohjeistus kannattaa laatia liiketoiminnan näkökulmasta asiakasorganisaatiossa. Samalla pitäisi muuttaa ja kehittää liiketoimintaprosesseja.
It-infrastruktuuria pitäisi pyrkiä jatkuvasti yksinkertaistamaan.  Kuitenkin näyttää siltä, että tietojärjestelmät tulevat yhä monimutkaisemmiksi ja kompleksisuuden hallinta nousee keskeiseksi. Kaikkia asioitahan ei voi tehdä yksinkertaisiksi; kännyköissäkin toiminnallisuus muuttuu koko ajan.
Tietojärjestelmien kehittämisessä viestinnällä on olennainen rooli. Myös hiljaista tietoa tarvitaan.

Mielikuvittelu sytytti lainehtivat ideat innovaatioiksi

jaat osaamista
olet Sytyke-pankin
kokemustili

tuotekehitys
patentoi illuusiot
liukuhihnalle

tiedon lisäksi
ultrakevyt YubiKey
käsilaukussa

Sytyke-yhdistyksen perinteisen seminaarin tämän syksyn aihe ”Mielikuvittele – Ideoista innovaatioiksi!” keräsi tavallista vähemmän osallistujia Viking Gabriellalle 10-12.9.08. Viime metreillä kilpaillut aiheidea ”Ohjelmistotuotteen hankinta – itse tekemällä vai ostamalla” olisi ehkä purrut paremmin sytykeläisiin.

Sytyke

Puheenjohtaja Mitro Kivinen pohti Sytykettä. Sytykkeessä puhutaan mukavia ja asiaa sopivassa suhteessa, saadaan asioita syttymään. Kipinät löytävät tarttumapintaa, syttyvät, lämmittävät, voivat kehittyä innovaatioiksi. Sytyke yhdistää osaamisyhteisöihin ohjelmistokehityksen asiantuntijat tuottamaan ja jakamaan toisilleen osaamista ja tietoa sekä oppimaan toistensa kokemuksista.
Ensimmäisen kerran Mitro Kivinen kuuli Sytykkeestä opiskellessaan vuonna 1992 ATK-instituutin perillisessä, silloin vielä väliaikaisessa Heliassa. Sytyke syntyi organisaatioiden tietojenkäsittelyn tarpeisiin. Perinteisesti systeemityöllä on tarkoitettu räätälöityjen ohjelmistojen suunnittelua ja toteutusta, kun taas ohjelmistotuotannolla tarkoitetaan valmisohjelmistojen valintaa, ostamista, räätälöintiä ja käyttöönottoa. Nykyisin systeemityö kattaa koko tämän kentän.
Sytykkeessä parasta on asioista keskustelu osaamisyhteisöissä, syys- ja kevätkokouksissa sekä Systeemityölehdessä. Sytyke on aktiivinen tietotekniikka-alan ja ohjelmistokehittämisen tieto- ja kokemuspankki, jossa jokainen meistä on kokemustili. Sytyke-pankissa kokemus ei jakaessa vähene vaan lisääntyy. Mitro Kivinen kannustikin meitä etsimään seminaaripäivinä uusia keskustelukumppaneita.
US-patentit
Pentti Juhala, Suomen Keksijäin Keskusliiton puheenjohtaja kertoi US-patenttien hyväksikäytöstä ja tekijänoikeuden osoittamisesta. Wattia pidetään höyrykoneen ja Edisonia sähkölampun keksijöinä, vaikka todellisuudessa he kehittivät muiden keksinnöt hyödyllisiksi tuotteiksi eli innovaatioiksi. Jälkimaailma muistaa innovaattorit keksijöinä.
Patenteista saatavaa tietoa voidaan käyttää mm. tutkimuksessa, kilpailijaseurannassa ja tuotekehityksessä. Jos patenttitietoa ei osata käyttää, saatetaan kehittää uudestaan sellaista, mikä on jo kehitetty. Patenttijulkaisuista voi seurata, mitä kilpailijat tekevät ja mitä teknologiaa he kehittävät. Jos uusi tuote havaitaan vasta messuilla, saatetaan olla kilpailijaa kymmenen vuotta jäljessä.
USAn patenttikäytännöt poikkeavat jonkin verran muun maailman käytännöistä. Ääriesimerkki USAn patenttikäytännöstä lienee patentti tavalliselle riippukeinulle, jota joku keksi keinuttaa sivusuuntaan!
USAssa voidaan patentoida pelkät tietokoneohjelmat ja bisnesmetodit ja patentti myönnetään aina keksijälle, kun se muualla myönnetään hakijalle. USAn käytäntö edellyttää tarkkaa laboratoripäiväkirjaa, josta käy ilmi, kuka tutkijayhteisöstä keksinnön on tehnyt. Laboratoriopäiväkirja on siis sidottu kirja, jonka sivut on numeroitu ja korjaukset tehty yliviivaamalla ja jonka jokaisen sivun on allekirjoittanut kaksi todistajaa. Laboratoriopäiväkirjassa kuvataan tavoite ja tulokset, mitä keksittiin milloin ja ketkä keksivät.
Euroopassa tietokoneohjelmien ja bisnesmetodien patentointi edellyttää, että keksintöön liittyy fyysinen laite, jota ohjelmisto käyttää. Hoitotoimenpiteitä ei voida patentoida, mutta niissä käytettävät laitteet voidaan. Yleensä ohjelmistojen patenttihakemukset liittyvät analysointilaitteisiin. Modulaarisessa ohjelmassa mahdollinen patenttia loukkaava kohta voidaan helposti korvata jollain muulla.
Keskustelussa ihmeteltiin Microsoftin saamaa patenttia page-up- ja page-down-näppäimiin, jota se oli hakenut vuonna 2005.
Illuusiot romahtavat
Lauri Laitinen Nokialta kertoi kokemuksiinsa perustuen illuusioiden romahtamisesta patentoinnissa ja standardoinnissa. Nokialle tullessaan hän ajatteli patenttien olevan keksintöjä, mutta totesi, että valtaosa patenteista tuotetaan liukuhihnalta normaalina insinöörityönä (esimerkiksi käyttämätön bitti ja sille keksitty käyttö). Hänellä itsellään on jo kuusi hyväksyttyä keksintöä.
Lauri Laitisen toi selkeästi esiin, että patentit, merkantilismin viimeiset jäänteet, liittyvät omistusoikeuteen. Patentti ei ole tuote vaan yksinoikeus käyttää tiettyä teknologiaa tuotteessaan. Analogiatelevision patentit ovat vanhentuneet, joten kuka tahansa voisi tehdä televisioita – niinpä siirrytään digitaaliseen televisioon. Patentoimalla jokin teknologia voidaan pitää poissa markkinoilta. Patentoinnin sijaan keksintö voitaisiin julkistaa, jolloin muut eivät enää voisi sitä patentoida.
Patentointi-ikkuna on tilanne, jossa kaikki näkevät, mihin speksit ovat menossa. Kun joku istuu alas ja kirjoittaa eri vaihtoehdot patenttihakemuksiksi, niin varmasti jokin niistä menee lävitse. Patenttien käsittelyaika on kohtalaisen pitkä: Lauri Laitisen vuonna 1997 laatima Umts-patenttihakemus tuotti palkkion vasta pari kuukatta sitten.
Nokiassa on tavoitteena, että jokainen työntekijä saisi vähintään yhden keksintöhakemuksen läpi puolessa vuodessa. Keksinnön pitää ratkaista jokin ongelma, pelkkä tekniikka tai tarve ei riitä. Keksinnön taustalla on usein kahden asian yhdistäminen uudella tavalla.
Huippututkimus
Petri Myllymäki Helsingin yliopiston Tietojenkäsittelytieteen laitokselta kertoi tieteellisestä huippututkimuksesta ohjelmistoalan innovaatioiden synnyttäjänä, joista esimerkkejä ovat hänen parinkymmenen hengen CoSCo (Complex Systems Computation) -tutkimusryhmänsä kehittämät tuotteet.
Koptimi-algoritmin avulla voidaan optimoida paperirullien pakkaamista konttiin. Algoritmia kehitettäessä opittiin, mitä kaikkea asiakkaalta pitää kysyä, jotta päästään käytännössä toimivaan ratkaisuun. Kontti ei saa olla epätasapainoinen, koska sellainen voisi tippua nosturista. Rullat pitää pakata niin, etteivät ne heilu merenkäynnissä eivätkä paperin reunat vahingoitu. Algoritmi ei toiminut kaikissa tilanteissa, joten päädyttiin heuristiseen ratkaisuun. Se toimi ällistyttävän hyvin. TietoEnator tuotteisti ratkaisun ja se on ollut StoraEnsolla tuotannossa jo kymmenisen vuotta. Suurin voitto on kertynyt tilauskokojen kasvusta, kun lisätilaus voidaan mitoittaa algoritmin kertoman konttiin jäävän tyhjän tilan mukaiseksi.
BayesIT on ollut käytössä Helsingin Sanomien vaalikoneessa vuosina 2003, 2004, 2007 ja 2008. Ekahau tarjoaa ratkaisuja sisätilapaikannukseen. Aino on uudentyyppinen hakukone, joka käyttää tekstidokumenttien analysoinnissa samoja menetelmiä kuin paikannuksessa.
Menetelmien menestyksellinen räätälöinti edellyttää niiden syvällistä ymmärtämistä; oppikirjamenetelmä ei riitä käytännön ongelmien ratkaisuun. Ongelman keksiminen voi olla innovaatio. Huippututkimuksessa on aina epäonnistumisen riski; projektin kestoa ja tulosten laatua on vaikea ennakoida. Parhaat tulokset ovat usein suunnittelemattomia. Kun tutkijat innostuvat, he paiskivat töitä hullun lailla, mutta välillä tarvitaan laiskuusvaiheitakin.
Suomeen tarvitaan nykyistä enemmän menestystarinoita. Miten huippututkijat ja huippubisnesosaajat kohtaisivat?
Yhteistyön uudet välineet
Perttu Karvinen ja Mikko Holmberg CodeBakersilta kertoivat, miten uudet välineet auttavat kuvittelusta yhteistyöhön. Perttu Karvinen ravisteli esiin nykytilan tutut ongelmat: systeemityön vaiheet ovat toisistaan erillisiä eikä kokonaiskuva ei ole kenenkään hallinnassa. Yhteistyössä käytetään palavereja, sähköposteja, dokumentteja, wikejä ja katselmointeja. Tieto hukkuu sähköpostimassaan, wikin kirjoittaminen vie työaikaa, dokumentit tiedonvälityksessä edellyttävät katselmointeja, mutta nämä eivät takaa faktoja. Miten projektipäällikkö voisi selvittää projektin tilan vain dokumenttien perusteella?
Ratkaisuksi Perttu Karvinen ehdotti projektin tehtävien hallinnan ja tekemisen nivomista yhteen niin, että kaikki tieto olisi kerralla sopivassa muodossa kaikkien nähtävissä. Tämän jälkeen Mikko Holmberg näytti vakuuttavan, etukäteen ohjelmoidun demon pilotista, jota sovellettiin scrum-projektin hallintaan ja toteuttamiseen.
YubiKey
Ensimmäisen seminaaripäivän päätteeksi Ilkka Pirttimaa kertoi tervejärkisestä hypetyksestä YubiKeystä. YubiKey on pieni, avaimenperään liitettävä laite, jonka avulla voidaan autentikoitua mihin tahansa OpenId-kirjautumista tukevaan järjestelmään, joita web 2.0 on täynnä. YubiKey on helppokäyttöinen ja turvallinen eikä tarvitse ajuria missään ympäristössä. YubiKey käyttää avointa rajapintaa, jolloin koodin tekeminen on yksinkertaista. Lyhyessä ajassa onkin syntynyt satoja sitä hyödyntäviä valmisratkaisuja.
Toisen seminaaripäivän aamuna saimme sormituntuman YubiKey:iin, kun Simon Josefsson Yubicosta vieraili laivalla. EU-palkinnon voittaneen innovaation kehittäminen alkoi vuonna 2007. Kyse on helppokäyttöisestä ultrakevyestä, painikkeella varustetusta USB-tikusta. Siinä ei ole näyttöä, paristoja eikä mekaanisia osia. Käyttäjän ei tarvitse ylläpitää tietokantaa eri verkkopalveluiden tunnuksistaan ja salasanoistaan. Nopea kosketus saa tikun generoimaan kertakäyttöisen salasanan, jonka alussa on tikun yksilöivä pysyvä tunniste. Simon Joseffsonin kokemuksen mukaan perinteisten pankkikorttien tunnukset ja salasanat aiheuttavat huomattavasti enemmän ongelmia kuin YubiKey.
Sytytä
Tukholmassa käynnin jälkeen Mitro Kivinen kertoi meille, miten asiat saadaan tapahtumaan. Usein ajattelet, että jonkun pitäisi hoitaa homma. Kuka se joku on? Sinä itse. Laadi johdolle perusteltu esitys, kenties kaksi vaihtoehtoa, joista johto voi valita. Kun päätös on tehty, jonkun pitää se toteuttaa. Taas sinä itse olet se joku. Saat porukan tekemään kanssasi. Luota tekijöihin, mutta tarkista ja pidä langat käsissäsi. Kun homma on valmis, muista kiittää.
Avoin yhteistyö
Kari Aho Elisalta ja Sami Kettunen Samcomilta kertoivat kokemuksiaan avoimuudesta asiakkaan ja toimittajan yhteistyössä.
Samcomin slogan ”tulisieluisia tietojärjestelmiä inhimillisellä otteella” korostaa, että kyse on ihmisten välisestä työtä, mikä vaatii henkilökemiaa ja ihmisten välistä vuorovaikutusta. Jos henkilökemia ei toimi, henkilöitä pitää uskaltaa vaihtaa. Perinteisistä yhteistyösopimuksista pitäisi päästä avoimuuteen kannustaviin kumppanuussopimuksiin. Perinteisiä sopimuksiahan katsotaan nimenomaan silloin, kun jokin menee pieleen, kun taas kumppanuussopimuksilla pyritään jo ennalta estämään kitkatilanteet.
Tavoitehintamallissa yritys ottaa projektiriskin kannettavakseen, mikä on tuottanut hyviä asiakassopimuksia. Yhteistyön apuvälineinä käytetään irc-kanavia, blogeja, wiki-intraa, asiakas-extraa ja tuotannonohjausta. Wikejä käytetään projektikohtaiseen tiedonkeruuseen, blogeja sisäiseen tiedottamiseen. Asiakkaan kanssa on jo ryhdytty tekemään yhteistä wikiä ja asiakas-extraan on avattu tuotannonohjausjärjestelmä, johon kerätään testaushavaintoja ja tietoja korjauksista.
Kari Aho Elisalta vahvisti Sami Kettusen myönteisen kuvauksen asiakkaan ja toimittajan välisestä avoimesta yhteistyöstä. Elisan yritysasiakkaiden palvelutuotannossa sovellusylläpito ja hallinta on ulkoistettu Samcomille, jonka osaamiseen luotetaan.
Navitas-palvelu, terveydenhuollon alueellinen tietojärjestelmä, jolla on n. 7000 käyttäjää ja johon on tallennettu 1,5 milj.kansalaisen potilastiedot ja röntgenkuvat, on yksi esimerkki Elisan ja Samcomin yhteistyöstä. Tiedon pitäisi kulkea terveyskeskuksen ja sairaalan välillä suljetuissa yritysverkostoissa, joissa voi käyttää myös tunnusta ja salasanaa.
Monitoimittajaympäristössä vastuu ylläpidosta on yhdellä toimittajalla, Samcomilla. Ulkoistaminen vapauttaa aikaa palvelujen kehitystoiminnalle. Toimittajalta vaaditaan toimivaa sovelluskoodia, relevanttia ja ajantasaista dokumentaatiota sovellushallinnasta ja ylläpidosta sekä kokemusta osaamisesta. Koodaajien ja arkkitehtien pitää voida istua loppuasiakkaan kanssa samassa pöydässä ja osata käyttäytyä. Tämä tarkoittaa, että itsehillintä toimii, ei sallita iskuja vyön alle, mutta sallitaan tyhmät kysymykset ja jaksetaan selostaa. Esimerkiksi, ei sanota ”Sä et osannut” vaan sanotaan ”Se röntgenkuva ei tule tuonne näkyviin”.
Liimataan IT liiketoimintaan
Ilkka Pirttimaa ja Antti Everi Stockmannilta kertoivat, mistä saadaan liimaa IT:n ja liiketoiminnan väliin yrityksen kokonaisarkkitehtuurin mallintamisessa.
Stockmannin tietohallinto huolehtii yli kuudestasadasta myymälästä eri puolilla maailmaa eri kielillä ja aikavyöhykkeillä. Yritysarkkitehtuuri voidaan mallintaa käyttämällä monipuolisesti Arista ja sen olioita, suhteita ja attribuutteja.
Järjestelmäkuvauksen vanha malli perustui moniin tuotteisiin kuten Microsoftin Visio, Excel, Word, IBM:n Rational ja sähköposti, joista syntyi paljon irrallisia dokumentteja. Uudessa, vajaa vuosi sitten käyttöönotetussa mallissa Aris tuottaa suoraan tietokannan ajantasaisista tiedoista valmisraportteja palvelimista, järjestelmistä, teknologioista ja niiden riippuvuuksista.
Stockmannille ei perustettu Aris-projekteja vaan mallinnuskerho. Siihen ovat tervetulleita kaikki, joilla tarve mallintaa ja vähentää Excel-dokumentteja.
Tietohallinnolta pyydetään usein lausuntoja järjestelmistä. Arisilla tuotetaan suoraan havainnolliset kaaviot – sen sijaan, että kirjoitettaisiin tekstiä käsin. Jos pitäisi kartoittaa, missä järjestelmissä liikkuu sensitiivistä tietoa, kuten asiakkaan kotiosoite tai henkilötunnus, raportti etsii prosesseja ja integraatioita ja kertoo, mitkä roolit näkevät tiedon ja missä se kulkee. Tämän perusteella arkkitehtuuria voidaan muuttaa entistä tietoturvallisemmaksi.
Miten motivoidaan henkilökuntaa päivittämään tietoja järjestelmään, jotta se olisi aidosti reaaliaikainen? Sellaistahan yrityksessä työskentelevät ihmiset tarvitsevat omassa työssään. Entä miten löydetään sopiva mallinnustarkkuus, ettei mallinneta turhaan?
Esitetty demo ei toiminut parhaalla mahdollisella tavalla, kun attribuutit unohtuivat laivalle tuodusta demokoneesta.
Ketterä tietovarastointi
Tomas Stenlund Ineolta puhui korkealentoisesti Data Vaultista ja ketteristä menetelmistä tietovarastoinnissa, jotka voivat tuottaa esimerkkejä liiketoimintaa parantavista innovaatioista.
Aiemmin lautatarhassa mies osasi heti sanoa, paljonko varastossa on minkälaista lautaa ja ottaa tilauksen vastaan. Nykyisin siihen tarvitaan tietojärjestelmiä. Data Vaultissa liiketoiminnan tietoja ja niiden välisiä suhteita kuvaavaa oliomallia käytetään mallinnuksessa, toteutuksessa ja ylläpidossa. Kapselointi mahdollistaa palastelun. Mallia ylläpidetään hyvällä muutoshallinnalla: Jos jokin liiketoimintasääntö muuttuu, se heijastuu dataan.
Tekninen näkökulma liitetään liiketoimintaymmärrykseen ja tuotetaan ajasta riippumatonta dataa. Laskenta- ja jalostussäännöt ovat lähellä liiketoimintaa. Olioiden yksinkertaisuus helpottaa niiden tuottamista ja ylläpitoa, jolloin niiden suuri lukumäärä ei ole olennainen ongelma. Menetelmä toteuttaa vaiheistettua kehitysmallia, jossa päästään nopeasti liiketoimintakysymyksiin.
Onko enää kyse innovaatiosta, jos sovelletaan valmista mallia?

Mikä on systeemityössä IN?

hanke purjehtii
vesiputouksesta
muutoskaaokseen

hiljainen tieto
siivittää muuttolinnun
laadunhallinnan

tutkija testaa
haarukalla perunaa
ilman speksejä

Systeemityöyhdistys Sytyken kymmenennessä laivaseminaarissa Viking Mariellalla 5.-7.9.2007 kysyttiin: ”Mikä mahtaa olla IN?”
Sytyken sytyttämiä sponsoreita oli niin paljon, ettei kaikille riittänyt puheenvuoroa paripäiväisessä seminaarissa. Niinpä puheenvuorotta jäänyt Samcom ilmoittautui jo ensi vuoden sponsoriksi.
Timo Kaisla Ixonos Projektinjohtopalveluista kertoi haasteista suurissa tietojärjestelmähankkeissa, sata kertaa tavallisia suuremmissa, tuhansia henkilötyövuosia ja yli kolme kalenterivuotta nielevissä migraatio eli konsolidointi- tai vaihtohankkeissa. Alustava suunnitelma ja lopullinen todellisuus poikkeavat toisistaan merkittävästi: kustannukset kasvavat nelinkertaisiksi ja aikataulu kolminkertaiseksi, hanke koskettaa koko organisaatiota ja suurta alihankkijajoukkoa.
Ainutkertaisen hankkeen skaalasokeutta ei riko konsulttikaan. Johto ja kokenut projektipäällikkö hallitsevat normaaliprojektit, ei koko henkilöstöä koskevaa muutosta. Organisaation pitäisi lääkitä itseään ulkopuolisten kokemuksilla suurista projekteista.
Puolet meneillään olevista projekteista pitäisi tappaa, jotta migraatiohankkeeseen saataisiin kaikkien divisioonien parhaat resurssit. Päällikkövetoinen vaatimusmääritys, vaikka siihen varattaisiin reilut puoli vuotta, tuottaa puutteellisia ja tasoltaan kirjavia tuloksia, jos päälliköt eivät ole systeemityön ammattilaisia. Systematisointi on saattanyt rämettyä organisaation pienissä projekteissa; suurissa sitä tarvitaan. Pienissä projekteissa kannuksensa ansainnut projektipäällikkö ei ehkä uskalla skaalata resurssi- ja aikatarvetta riittävän ylös – ja jos uskaltaisi, esimies ei sitä hyväksyisi.
PMBOK kuvaa, mitä pitäisi tehdä, ei sitä, miten se tehtäisiin.
Vaatimusten- ja muutostenhallinnassa työpajat toimivat, ne tuottavat paljon dokumentoimatonta, ns. hiljaista tietoa. Aikataulu annetaan yleensä ylhäältä, vaikka suurta hanketta pitäisi suunnitella alhaalta ylös. Linjaihmiset arvioivat työmäärät kirjavasti. Katselmointi vaatii pari kuukautta ja kymmenen henkilöä, ettei ”takaseinä jää puuttumaan”.
Laadunhallinnasta tarvitaan kuvaus, jossa käsitellään muutakin kuin testausta. Testaajiksi tarvitaan ulkopuolisia ammattitestaajia, he oppivat nopeasti prosessit kuin prosessit. Jos talon omat asiantuntijat pannaan kolmeksi kuukaudeksi ajamaan erilaisia testejä, kyse on heidän ammattitaitonsa väärinkäytöstä.
Miten henkilöstö saadaan mukaan? Aluksi voisi kutsua vaikka Esa Saarisen luennoimaan, muutoshan koskee kaikkea ja kaikkia. Projektipäälliköt ovat avainasemassa: jos homma on liian iso jollekulle heistä, hänet pitäisi vaihtaa toiseen mahdollisimman pian, muuten muutosvastarinta kasvaa.
Miten suuri tietojärjestelmäprojekti ostetaan? Vaatimusmääritys on niin vaativa, että kiinteä hinta johtaa yleensä jatkuvaan sopimuspapereiden läpikäyntiin juristien kanssa.
Ostavan ja tilaavan organisaation toiminta- ja kulttuurierot vaikuttavat projektiin. Jos organisaatiot ovat eri maissa, ongelmat yleensä lisääntyvät. Halvin tapa rakentaa siltoja saattaa joissain tapauksissa olla ilmainen viina. Projektissa työskentelevien ihmisten pitäisi kokea olevansa ”yhdessä veneessä” eikä vain asiakassuhteessa. Parhaimmillaan projektin lopussa ei enää voi erottaa, kuka on toimittajan ja kuka asiakkaan edustaja.
Nopeasti muuttuvassa maailmassa isoissa projekteissa voidaan käyttää ketteriä menetelmiä monin sprintein.
Claus Günther ja Sakari Lehtonen IDS Scheer Finlandilta selvittivät meille Open BPM:n merkitystä liiketoiminnalle. Claus Güntherin mukaan nykyinen muutosten aika edellyttää kokonaisratkaisuja, liiketoiminnan harmonisointia ja segmentointia. Miten se näkyy attribuuttitasolla? Mitä tehdään itse ja mitä ostetaan?
Kokonaisuuden hallinta tarkoittaa suhteiden hallintaa, asioiden välisten suhteiden ymmärtämistä. Onko tämän hallitseva toimitusjohtajasukupolvi vasta kasvamassa? Kolme vuotta sitten puhuttiin malliin perustuvasta arkkitehtuurista (Model Driven Architecture), nykyisin arkkitehtuurin pitäisi perustua liiketoimintaan (Business Driven Architecture).
Mikä on IN? Olisiko Business Driven SOA? Tulevaisuudessa yritysarkkitehtuuria ja SOA:a hallitaan yhdessä.
Sakari Lehtonen kysyi, miten järjestelmät palvelevat liiketoimintaa kokonaisuutena. Monessa organisaatiossa on kiinnitetty huomiota prosessien hallintaan, mutta laajempi kehikko, sovellukset, tiedot, laitteistot ja integrointi, on jäänyt hoitamatta. Olennaista olisi saada nämä kaikki samaan tietokantaan, jotta tiedetään, mitä sovellusta, tietoja ja laitteistoja tietty prosessi tarvitsee. Miten tällaista tietokantaa ylläpidetään? Tuskin PowerPointilla.
SOA:ssa on aina sama kerrosarkkitehtuuri: käyttöliittymät – integraatioalusta – ERPit. Portaalista tuleva käsky reitittyy integraatiokerroksen läpi keskuskoneelle, jossa kaikki tiedot ovat luontevissa moduuleissa. Muutaman vuoden kuluttua integrointikerroksen korvaa ohjaava kerros.
Entä tulevaisuus? Yrityksellä on yksi sovittu tapa kuvata ohjelmalogiikka, joka voidaan generoida eri alustoille. Prosessit mallinnetaan BPM:lla ja tekniikka UML:lla – ja nämä kuvaustavat pidetään erillään!
Joakim Sandström nSenselta vakuutti innostavassa puheessaan, että tietoturvan testaaminen on osa systeemityötä. Hän kertoi aloittaneensa uusmediahypen aikana ohjelmoijana, törmänneensä koodin tietoturvaongelmiin ja innostuneensa sovellustietoturvahaavoittuvuudesta, josta kukaan ei tuolloin ymmärtänyt mitään. Ohjelmistorobotilla hän löysi viikossa puolesta miljoonasta verkkopalvelusta pari miljoonaa haavoittuvuutta.
Hän kertoi esimerkin, miten oli sovellushaavoittuvuuksia käyttäen muuttanut tilaukseensa 80 %:n alennuksen. Varastomies alkoi kuitenkin ihmetellä suurta alennusprosenttia ja tarttui puhelimeen. Entä tulevaisuudessa, jos tuotantoketju automatisoituu eikä ole enää varastomiestä lukemassa tilausta?
Ohjelmoijille ei kerrota, miten tehdään tietoturvallista SOAP:ia. Heille opetetaan, että ensin koodataan ja sitten testataan, vaikka tietoturva pitäisi rakentaa osaksi koko prosessia.
Monet kuvittelevat, että palomuuri, VPN ja SSL takaavat tietoturvan. Uusia haavoittuvuuksia on kuitenkin 75 % enemmän kuin ennen; nyt ne ovat sovelluksissa eivätkä linjoissa tai palvelimissa.
Jos autoja rakennettaisiin kuin tietojärjestelmiä, niissä ei olisi ikkunoita eikä jarruja; eihän niitä itsestäänselvyyksinä mainittaisi vaatimusmäärittelyissä.
nSense teki vuonna 2006 yli sata turvatestiä, joista löytyi vain viisi puhdasta sovellusta.
Yrityksen pitäisi analysoida, mitä tietoturvaongelmista seuraa? Ensimmäinen raportoitu verkkopankkihaavoittuvuus lienee se, kun äiti jätti verkkopankin auki ja 16-vuotias poika huomasi, että osoitekentässä pyöri tilinumeroita. Hän pääsi vaivattomasti siirtämään rahoja toisten tileiltä.
Http-protokolla on tilaton ja ohittaa kaikki tietoturvat. Se suosii ”pahiksia”. OWASP kuvaa, millaisia haavoittuvuuksia sovelluksista löytyy. Niitä löytyy 80 % sovelluksista, mikäli tietoturvatestaus uupuu.
Tietoturvahaavoittuvuudet voidaan jakaa teknisiin ja loogisiin. Jälkimmäiset liittyvät tilanteisiin, joissa sovellus ei tarkista syötettä: sushia saatiin parissakymmenessä minuutissa, vaikka ohjeellinen vähimmäisaika oli pari tuntia. 95 % haavoittuvuuksista voitaisiin välttää validoimalla syöte ja enkoodaamalla tuloste.
Missään ei rakenneta ohjelmistoja niin, että tietoturvallisuus olisi ohjelmoijasta riippumatonta. Liian usein ohjelmoija itse testaa sovelluksen tietoturvan ja liian harva asiakas vaatii tietoturvallista toimintaa. Tietoturva pitäisi testata silloin, kun ympäristö muuttuu – mutta ympäristöhän muuttuu päivittäin.
Koulutuksessa pitäisi korostaa, että sovelluksen tietoturva on laatukriteeri siinä missä toiminnallisuuskin. Kaikille sovelluksille pitäisi määrittää minimivaatimukset. Organisaatio jää riskianalyysissaan liian usein sille tasolle, että tunkeutujaa ei päästetä palvelimelle, mutta unohdetaan, että tunkeutuja voi hintoja muuttamalla huijata itselleen ilmaiseksi musiikkifirman kaikki kappaleet.
Pentti Virtanen Tieturilta kertoi kouluttajan ottein, miten vaatimukset valmistuvat viikossa. Riittävän pieniksi pilkotuilla kokonaisuuksilla, joita osaavat ihmiset käsittelevät.
Perinteinen vesiputousmenetelmä on kuin organisaatiota vaihdettaisiin joka vaiheen jälkeen ja tieto välitettäisiin kuvauksissa keskustelua välttäen. Ketterissä menetelmissä myönnetään, ettei vaatimuksia saada kerralla oikein – varsinkaan sitä, mitä kaivataan neljän vuoden kuluttua tai ensi joulumarkkinoilla. Sitäpaitsi: jatkuvasti löytyy uusia tapoja tietojärjestelmien toteuttamiseen. Miksi ne jätettäisiin hyödyntämättä kiveen hakatuilla vaatimusmäärityksillä ja tietojärjestelmäprojekteilla?
Sopimukset eivät tee järjestelmää eikä tavoitteena ole voitto välimiesoikeudessa vaan toimiva järjestelmä. Sopimusten sijaan tarvitaan luottamusta ja sopeutumista muutoksiin!
Ketterissä projekteissa asioita tehdään rinnakkain, siksi kalenteriaika lyhenee. Ketteryys edellyttää ammattitaitoisia, motivoituneita ihmisiä sekä kommunikointia tiimien sisällä, niiden välillä ja asiakkaiden kanssa. Projektissa pitää olla riittävästi osaavia ihmisiä, jotka voivat keskittyä päätoimisesti, tuntea ”flown”. Mieluummin tehdään heti tietoturvallista koodia kuin etsitään haavoittuvuuksia jälkeenpäin.
Kallein tapa rakentaa on kokonaishintainen budjetti. Jos järjestelmä tilataan paloissa, voidaan lopettaa ajoissa. Scrum tuottaa asiakkaalle joka kuukausi toimivan sovelluksen, jota on helppo arvioida. Miten perinteisessä projektissa voidaan tietää, milloin sovelluksesta 22 % olisi valmiina?
Millainen projektisuunnitelma on muuttolinnuilla? Niillä ei ole projektipäällikköä ja ne sopeutuvat kulloinkin eteen tuleviin tilanteisiin.
Miten keität perunoita? Mittaatko veden määrän ja perunoiden koon ja lasketko siitä, kuinka kauan perunoiden pitää kiehua? Vai kokeiletko perunoiden kypsyyttä haarukalla?
Ketterät menetelmät eivät ole hopealuoti. Ohjelmistotuotannossa vaikeinta on ajatteleminen.
Byrokraattisessa organisaatiossa, jossa luvan saamiseen menee kuukausia, on vaikea toimia ketterästi. Perinteistä ohjelmistokehityksestä siirrytään ketteriin pienin askelin – aluksi vaikka lisäämällä kommunikointia.
Minna Oksanen SysOpen Digialta innosti meidät Business Intelligencesta. Onko organisaatiosi pulloposti, purjevene vai laiva? Ajelehditko vai ohjaatko itse? Business Intelligence tarkoittaa liiketoimintatiedon hallintaa yhtenäisen tietomallin avulla. Muutosta mitataan mahdollisimman pienin syklein, jotta saadaan konkreettisia tuloksia järkevässä ajassa.
Mitä tällä alueella on tapahtunut kymmenessä vuodessa? Voisiko metatiedoin kertoa, että tiedot liittyvät toisiinsa niin, ettei tietoa tarvitsisi toistaa? Perustiedot keskittyvät transaktioihin, kuutiot analyysiin. Kahden eri järjestelmän raportit saattavat poiketa toisistaan, jos luvut lasketaan eri tavoin. Samalle näytölle voidaan yhdistää eri elementtejä, kunhan tiedot ovat olemassa.
Näkyviä ratkaisuja saadaan sadassa päivässä. Real Time Datawarehousing and Reporting tarjoaa vastauksen kysymykseen, kuinka monelta kalkkunalta pitää katkaista kaula, jotta huomenna liikkeessä on riittävä määrä kalkkunaleikkeitä. Vastaus ei saa perustua viime viikon tilanteeseen, jos huomisen tilaukset ovat jo tiedossa.
Metadatan merkitys kasvaa, mallinnuksesta ei koskaan saa luopua ja liiketoiminnan kanssa pitää keskustella.
Perttu Karvinen ja Mikko Holmberg CodeBakersista kertoivat Java-kehityksessä puhaltavista tuulista. Kehitysrytmi on hidastunut, Java on vakiinnuttanut asemansa, mutta vaihtoehtojakin löytyy. Suppeimmillaan Java on ohjelmointikieli, laajimmillaan ohjelmistoalusta. Skriptikielillä pystytään nopeasti tekemään jotain tilanteissa, joissa Javalla joudutaan vääntämään paljon.
Spring on ohjelmointikehys, joka hoitaa sille esiteltyjen olioiden väliset riippuvuudet. Hibernate on olio-relaatio-tulkki, joka piilottaa relaatiomaailman olio-ohjelmoijalta. Java-koodaajan ei siis tarvitse tietää mitään SQL:stä. Hibernaten ongelmana on, että sovellus voi lähettää SQL-käskyjä ilman, että tulkki huomaa sitä. Eclipse taas on avoin kehitysympäristö.
Ketterään kehitykseen on tulossa kollaboraatioalustoja. Työkalutuki on jo olemassa ja kasvaa jatkuvasti. TDD eli Test Driven Development vaatii aloittamaan testauksen heti. Jatkuva integraatio varmistaa, että koodi toimii. Silti projektinhallintaakin tarvitaan. SOA ja BPM, joista aiemmin puhuttiin, eivät periaatteessa vaikuta sovelluskehitykseen Javalla.
Juhani Snellman Qentinelista kysyi: Testaus, Quo Vadis? Hän aloitti esityksensä kolmesta taidemaalarista, joiden piti kuvata omena. Yksi kuvasi omenan, toinen omenapuun ja kolmas puutarhan, jossa omenapuu kasvoi. Juhani Snellman kuvasi meille testauksen ympäristössään, nopeutuvan liiketoiminnan ja globalisaation puutarhassa, jossa kaikkea halutaan enemmän, nopeammin ja kustannustehokkaammin.
Testaus tekee näkyviksi liiketoiminnan riskit ja mahdollisuudet. Testaus sinänsä ei paranna ohjelmistoa vaan tuottaa relevanttia informaatiota liiketoimintariskien hallintaan. Testaus on ohjelmistokehityksen ja tietojärjestelmähankkeiden tukiprosessi.
Testauksen trendeinä voidaan mainita halpatuotanto, erikoistuminen ja ketterä testaus. Kymmenen erikoistunutta testaajaa voivat korvata tuhat halpatuotantomaista ostettua perustestaajaa.
Ketterän menetelmän kirjat eivät käsittele testausta. Osaava ketterä testaaja tukee sekä kehittäjätiimiä että liiketoimintaa.
Yksikkötesti ohjaa suunnittelua ja hyväksyntätesti tavoitteiden määrittelyä. Näistä voidaan automatisoida ne, jotka eivät vaadi aivokapasiteettia.
Tutkivassa testauksessa testaajan ammattitaito korostuu: hän ei toimi etukäteen mietittyjen määritysten mukaan vaan kokeilee asioita, joista tiedetään, että niissä joskus on ongelmia tämänkaltaisissa järjestelmissä. Kyse on negatiivisesta testaamisesta. Se ei onnistu perinteisessä organisaatiossa, jossa vaaditaan paljon kuvauksia ja testitapausten katselmointia etukäteen.
Siirtyminen perinteisestä ohjelmistokehityksestä ketterään tuottaa välivaiheessa kaaoksen; ihmisen toimintahan ei muutu nopeasti.
Lopuksi Silja Räisänen Osuuspankkikeskuksesta kertoi omien kokemustensa ja Systeemityölehtien valossa, mikä kymmenen vuoden aikana Sytyken laivaseminaareissa on ollut IN.