Kategoria: systeemityö

Tikon parhaita käytäntöjä

huominen vaatii:
intohimo oppia
muutosvalmius

ahot-tohtori
tutkii, kehittää, pilvi
painuu projektiin

Suomenlinnan Tenalji von Fersen oli viihtyisä ympäristö yksikkömme kehittämispäivälle. Perinteisten ryhmätöiden sijaan jaoimme kollegoiden kesken osaamistamme eri alueilta keskustellen alustusten pohjalta. Kaksi asiantuntijaluentoa lounaan jälkeen toivat piristävän lisämausteensa päivään, vaikka kahvia jouduttiinkin odottamaan.
Kansainvälisestä vaihdosta käyneet opettajat kehuivat avartavia kokemuksiaan ja niiden innostamaa vaihto-opiskelijavyöryä. Tohtoriopiskelijat ylistivät Haaga-Helian kirjaston tietokantoja aarreaittana ja kiittivät informaatikkojen palveluja. AHOT-käytännöt helpottavat opiskelijoiden työkuormaa, kun jo osattua asiaa ei tarvitse opintojaksoilla turhaan kerrata. Toisaalta ahotilla opiskelija menettää mahdollisuuden jakaa kokemuksiaan ja saada uusia oivalluksia muiden opiskelijoiden kysymyksistä ja nämä taas menettävät osaavan toverinsa kokemukset ja tuen. Projektityön periaatteet pysyvät, mutta  sovelluskohteet muuttuvat. Todelliset toimeksiannot motivoivat opiskelijoita uudella tavalla, ja niitä löytyisi niin oppilaitoksesta kuin sen ulkopuoleltakin. Tutkiva ja kehittävä oppiminen, joka vaatii aikaa ja palkitsee syvällisellä oppimisella, toimisi parhaiten jo opittujen perusasioiden soveltamisessa.
Tapio Volanen Logicalta kertoi 2010-luvun keskeisistä kyvykkyyksistä ict-alalla. Viestintätaidot nousevat entistä tärkeämmiksi, samoin monikulttuurisuuden ymmärrys. Vuorovaikutustaitoja tarvitaan esimerkiksi kun halutaan tarkentaa asiakkaan vaatimusmääritystä ja esittää siihen teknologian kannalta olennaisia muutoksia. Kaikki ovat tekemisissä asiakkaan kanssa, joten pelkkä ict-osaaminen ei riitä.
Logican omassa viestinnässä käytetään sähköpostia, blogia, wikiä, pikaviestimiä sekä videoneuvotteluja.
Projektin käynnistyessä määritellään aika, resurssit ja tulos. Ne saattavat muuttua projektin aikana: venyvä ja vanuva projekti ei pidä kiinni aikataulusta, rahasyöppö tarvitsee lisää resursseja ja tuloksesta tinkivä keventää laatua.
Hankejohtajien ja projektipäälliköiden, joiden tarve kasvaa jatkuvasti, pitäisi ymmärtää asiakkaan liiketoimintaa, osata neuvotella, joustaa ja kestää epävarmuutta. Palvelujohtajan, joka vastaa palvelujen tuottamisesta asiakkaalle, pitäisi olla pitkäjännitteinen ja ymmärtää prosesseja.
Arkkitehti kerää olemassa olevasta tiedosta olennaisen ja rakentaa kustannustehokkaan ratkaisun asiakkaan tarpeisiin. Hänellä pitäisi olla mallinnus- ja määrittelyosaamista, teknologian ja toimialan tuntemusta, kykyä visualisoida ja tuottaa kirjallista materiaalia.
Ratkaisujen toteuttamisesta vastaavia asiantuntijoita saadaan Intiasta huomattavasti halvemmalla kuin Suomesta. Minkälaista lisäarvoa suomalainen asiantuntija tuottaa? Laatu on Intiassa yhtä hyvää kuin Suomessa, joten lisäarvon pitäisi nousta asiakkaan prosessien ymmärtämisestä ja innovatiivisuudesta.
Intiaan englanniksi lähetettyjen tietojärjestelmän vaatimusmääritysten ja kuvausten pitäisi olla riittävän tarkat, koska sieltä saadaan juuri sitä, mitä on tilattu, eikä iterointiin ja määritysten tarkentamiseen ole mahdollisuutta samalla tavalla kuin paikallisella toimittajalla.
Myyjältä, account managerilta, edellytetään paitsi asiakkaan liiketoiminnan ymmärtämistä myös palvelu- ja ratkaisutarjooman riittävää tuntemusta, innovatiivisuutta ja neuvottelutaitoja.
Antti Larsio Microsoftilta näkee tietotekniikan kansalaistaitona, jota ei saa antaa vain ict-ammattilaisille. Teknologia on helppoa, ihmiset ovat vaikeita. Kommunikointi on olennaista: projektit epäonnistuvat, jos vuorovaikutus ei toimi.
Yksilön menestys kulkee käsi kädessä yhteisön menestymisen kanssa. Ammattilaisten muutosvastarinnan käsittely on keskeisempää kuin teknologinen osaaminen, mutta kukaan tuskin voi kuvitella tekevänsä samaa asiaa jatkuvasti. Mittaamista, raportointia ja suunnitteluakin tarvitaan.
Teknologia kehittyy seuraavien viiden vuoden aikana enemmän kuin viimeisten kahdenkymmenen vuoden aikana. Siksi tarvitaan oikeaa asennetta: kaikkea voi oppia, jos vain haluaa. Jos ihmiseltä puuttuu muutosvalmius tai intohimo teknologiaan, niin ict-ala ei ole häntä varten.
Nykyisin tarvitaan kielitaitoa ja eri kulttuurien tuntemusta. Pidättyvällä suomalaisella saattaa olla vaikeuksia parin päivän myyntineuvotteluissa, joissa toisen kulttuurin ihmiset huitovat käsillään ja puhuvat jatkuvasti. Nuoren polven suomalaisten vuorovaikutustaidot onneksi ovat erilaiset kuin meidän vanhempien.
Tulevaisuus on jo täällä – vaikka sitä esittävän videon ääni ei kuulunutkaan. Videolla lapset ja aikuiset viestivät keskenään taipuvien, läpinäkyvien näyttöjen käyttöliittymillä, joita ohjattiin sormella, puheella tai liikkeellä. Pilvipalvelut  käänsivät puhetta ja tekstiä reaaliaikaisesti ja toivat käsiteltäviin esineisiin ja asioihin lisätietoa verkosta. Second Life on Microsoftille First Life, osa reaalimaailmaa, ja sosiaalinen media osa tulevaisuuttamme. Glokalisaatio yhdistää toisiinsa osaamiskeskukset, joiden monirooliset ihmiset osaavat teknologiaa ja ymmärtävät sen sovellusmahdollisuuksia. Tähän liittyy Pekka Himasen raportti Kukoistuksen käsikirjoitus, joka kannattaisi lukea.

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.

Alkaako matka verkosta vai hausta?

verkkopalvelu
tarjoaa elämyksen
lumematkana

yhteisö viestii
kokemuksiaan, matka
muuttuu uudeksi
Aamutuimaan nauroimme Jaakko Saariluoman sähköistä stand-uppia ja iltapäivällä ahmimme ylitäydessä luentosalissa Best Westernin ja Gemillon sähköisen liiketoiminnan ideoita. Haaga-Helian Matka alkaa verkosta -seminaari 22.10.08 juhlisti matkailualan koulutuksemme merkkivuotta, mutta vastaavia seminaareja järjestettäneen jatkossakin.
Itseään Suomen johtavaksi matkailun Internet-markkinointiin keskittyväksi asiantuntijaksi tituleeraava Joensuun yliopiston eCompetence Centerin Ilkka Kauppinen johdatteli meitä selkokielellä sähköisen kaupankäynnin alkeisiin ja osin hämmentävästi sosiaalisen median termiviidakkoon. Hän puhui ”www-sivuista” ja ”kotisivuista”, vaikka tarkoitti myös niiden takana olevia kaupankäynnissä ja personifioinnissa tarvittavia tietokantoja. Internetin hän määritteli mediaksi eikä teknologiaksi ja markkinoinnin käsittämään lähes koko yritystoiminnan puhelimeen vastaamisesta rekrytointiin. Kalliisti rakennettu verkkokauppa ei löydy ilman markkinointia eikä viesti avaudu, ellei se ole ymmärrettävä ja kiinnostava. Verkkokaupassa pitäisi panostaa markkinointiin enemmän kuin teknologiaan.
Travelneerin Jaakko Löppönen tarjosi eväitä kokonaisvaltaisen ja tehokkaan sähköisen kaupan varmistamiseen. Selvitä ensin yrityksesi nykytila ja muodosta sen mahdollisuuksista tavoitetila! Dokumentoi, suunnittele, keskity ja innovoi! Kuuntele toisia ja pidä pari ässää hihassasi! Yksinkertaista tuotettasi ja ota hankkeisiin tarvittavat osapuolet! Panosta vuorovaikutteisuuteen ja käyttäjien luomiin sisältöihin! Seuraa sosiaalista mediaa ja keskusteluja yrityksestäsi!
Jaakko Löppösen visuaaliset diat täydensivät hyvin esitystä, joka painotti tietojärjestelmien kehittämisen näkökulmasta juuri oikeita asioita: liikkeelle lähdetään liiketoiminnasta, nykytilasta ja tavoitetilasta, joihin verkkopalvelun suunnittelu perustuu, ja ratkaisuissa otetaan huomioon vuorovaikutteinen sosiaalinen media.
Kirsi Mikkola Yritysvalmennus KM:stä toi terveisiä pohjoisesta Rovaniemeltä ja kertoi, miten sähköisen kaupankäynnin pitäisi vaikuttaa yrityksen sisäisiin prosesseihin ja viestintään. Lokakuun 2008 tilastojen mukaan Suomessa 73 % väestöstä käyttää nettiä ja 33 % on ostanut verkosta viimeisten kolmen kuukauden aikana, mutta vain 11 % suomalaisista yrityksistä myi jotain netissä vuonna 2006.
Matkailuliiketoiminta on suurelta osin yritysten välistä kauppaa, ja varsinkin etäällä olevia asiakkaita varten tarvitaan väliportaita, jotka tuntevat asiakkaan kulttuurin. Pienten matkailuyrittäjien monimutkaisia, erikoistuneita tuotteita ei viedä nettiin pelkillä toimistotyökaluilla, sähköpostilla ja kotisivuilla vaan siihen tarvitaan kumppaniverkostoa ja liiketoiminnan kehittämistä, monikanavaista vuorovaikutteista viestintää ja palautteen kuuntelemista ja analysoimista. Sosiaalisen median avulla verkkoliiketoiminta voisi kehittyä älykkääksi liiketoimintojen verkostoksi, jossa yritykset integroitaisiin toisiinsa, verkostot kilpailisivat keskenään ja verkostoprosessit kehitettäisiin asiakkaita palveleviksi. Ulkopuolinen konsultti voisi nähdä metsän puilta ja tarjota uudenlaista näkökulmaa.
Maija Hyötyläinen web-award-palkitusta Best Westernistä kertoi, miten verkkopalvelun suunnittelulla voidaan varmistaa myyntiä. Asiakkaita kannustetaan tuottamaan sisältöjä. He voivat kirjoittaa verkkopalveluun kertomuksia omista matkakokemuksistaan, tuoda verkkopalveluun kuvia lemmikeistään ja vinkkejä siitä, mitä pitäisi ottaa huomioon lemmikkien kanssa matkustettaessa, tai tuottaa YouTubeen kotivideoita matkatoiveistaan. Perheenäideille verkkopalvelussa on kampanjoita, joissa saa pelata ja jakaa kokemuksiaan.
Verkkopalvelun rakenne ja väriyhdistelmät on määritelty kansainvälisesti, mutta yksittäiset hotellit voivat päättää sisällöstä, kuvista ja toteutuksesta. Omasta ajankäytöstä ja osaamisesta riippuu, räätälöidäänkö ratkaisu itse vai käytetäänkö alihankkijaa, mutta mahdollisuus sisältöjen päivitykseen kannattaa joka tapauksessa säilyttää itsellä.
Verkkopalvelun turvallisuuteen pitäisi panostaa ennen kuin lööpit pääsevät kertomaan, miten hakkeri troijalaisellaan anasti Best Westernin saksalaisen hotellin asiakkaiden tietoja. Tuon jälkeen kyseisen hotellin tietojärjestelmä uusittiin pikaisesti ja tukea saatiin monelta taholta.
Jari Auranen Tietotalosta ja GO Finlandista keskittyi transaktioita tuottaviin sähköisiin jakelukanaviin ja sivuutti asiakkaiden tuottamat sisällöt. Verkkopalvelu pitäisi hänen mielestään rakentaa palastellen nopeasti, vaikka taustalla läikkyisikin, kunhan ei läiky liikaa. Hän kaipasi verkkopalvelujen dynaamiseen paketointiin destinaatiotuotteita, oheispalveluja, kuten nähtävyyksiä, lippupalvelua tai golfin tiiausaikoja, jotka majoitustarjonnan lisäksi saattaisivat kiinnostaa kyseiseen kohteeseen matkustavaa.
Destinaatiotuotteet toivat mieleeni Vesa-Matti Paanasen noin kymmenen vuotta sitten IIR:n Elektronisen kaupankäynnin strategiat -seminaarissa esittämän smartaalin eli älykkään portaalin idean: asiakas voisi verkkopalvelusta varata matkan majoituksineen, autovarauksineen ja päivällisineen suosikkiravintolassaan. Kuluneet lähes kymmenen vuotta eivät ilmeisesti ole riittäneet smartaalin toteuttamiseen.
Katri Lietsala Gemilosta kertoi, miten sosiaalisella medialla edistetään myyntiä. Sosiaalinen media on käyttäjälähtöinen ja käyttäjät tuottavat siihen sisältöjä yhteisöissä, keskusteluryhmissä, blogeissa, mikroblogeissa, wikeissä, podcasteissa ja ilmoitustauluissa. Julkaisutyökaluja ovat blogit, jotka sopivat tiedonvälitykseen ja viestintään, ja avoimet tai suljetut wikit, jotka puolestaan auttavat tiedon keräämisessä ja ideoinnissa. Säiliöihin YouTubeen ja Flickriin voidaan viedä omia tai asiakkaiden multimediasisältöjä. Verkostoissa LinkedIn ja FaceBook voi ylläpitää yhteystietojaan, jotka leviävät koko verkostoon, ja mainostaa tuotteitaan tee-se-itse-periaatteella esim. kohdejoukolle, joka löytyy hakusanoilla ”matkailu” ja ”Lappi”.
Myytkö tuotetta vai palvelua ja missä? Onko kohderyhmälläsi jo jokin yhteisö, johon voit liittyä? Jos on, niin yrityksesi pitäisi mennä sinne mieluummin kuin yrittää houkutella kohderyhmää omaan verkkopalveluusi. Jos yritys liittyy yhteisöön kuten FaceBookiin, sen pitäisi liittyä rehellisesti yrityksenä, oltava aito ja karhea lietsomatta liian positiivisia odotuksia, koska pettymysten jälkeen palaute voisi olla entistä kielteisempää. Esimerkiksi Amazon meni FaceBookiin, koska sen kohderyhmä on siellä.
Sosiaalisen median myötä verkkopalveluiden järjestelmäkustannukset ovat pudonneet radikaalisti, kunhan yritys tuo sinne sisältövirtaansa. Sosiaalinen media perustuu profiileihin: Kuka olen? Millainen yritykseni on? Verkkopalvelussa yritystä ei esitellä passiivissa neljännesvuositilastoin vaan aktiivissa tuomalla esiin yrityksessä toimivat ihmiset kuvineen.
Waraamo on Katri Lietsalan Gemilon palvelu, jossa varaustieto ei katoa eri yritysten verkkopalveluihin vaan jää kuluttajalle itselleen. Hän voi vaihtaa palvelusta toiseen ja pitää itsellään muistijäljet matkoistaan.
iPhon-palvelu ”Sytkärin tuli” tarjosi ihmisille mahdollisuuden pitää keskenään hauskaa ja kilpailla maanosien välillä. Kuluttajalle virtuaalituli maksoi euron, mutta yritys ansaitsi lyhyessä ajassa 75 000 euroa, kun kuluttajat halusivat oman maanosansa virtuaalitulen liekehtivän voimakkaimmin.
Sirte Pihlaja digitaalisen median suunnittelutoimisto Fjordilta kertoi pk-yritysten sähköisen kaupan palveluiden trendeistä ja todellisuudesta, Travel 2.0:sta. Yhteisöissä ihmisten kertomukset kokemuksistaan voivat muuttaa matkasuunnitelmia ja niiden yksityiskohtia ja vaikuttaa olennaisesti matkailuyrityksen myyntiin. Virtuaalilento Grand Canyonin yllä tai animoitu Disney World myy huomattavasti paremmin kuin samaa asiaa kuvaava tekstinpätkä. Tarjonnan voi paketoida uudella tavalla, esimerkiksi antamalla asiakkaiden imuroida verkkopalvelusta kylpylän rentoutusmusiikkia mukaansa kotiin.
Sirte Pihlaja kehotti matkailun pk-yritystä personoimaan palvelunsa kohderyhmien mukaan, liittämään kampanjoihinsa Google-mainoksia tai FaceBook-sovelluksia, jotka johtavat verkkopalvelussa oikeaan kohtaan, panostamaan mobiilipalveluihin ja elämyksiin, tarinoihin, vihreisiin arvoihin ja hyvinvointiin sekä sosiaaliseen markkinointiin.
Aamupäivällä esiintynyt Ilkka Kauppinen pohti keinoja kartoittaa asiakkaiden tarpeita ennakkoon ja matkakohteessa. Hän kertoi kylpylälomastaan vaimon kanssa Tallinnassa, jossa heitä odotti shampanjapullo hotellihuoneessa, kortti tunnelmalliseen iltaan ravintolassa sekä palautepyyntö heti matkan jälkeen sähköpostissa. Vaikka hän joutui maksamaan palveluista, joita ei ollut etukäteen tilannut, hän iloitsi lisäpalveluista ja koki saaneensa huippuhyvän kohtelun.
Anni Ronkainen Google Finlandilta kertoi asiakkaan tietotarpeista ja ostopäätöksiin vaikuttavista asioista Internetissä. Kymmenessä vuodessa tapa etsiä ja kokea tietoa on muuttunut. Web 2.0:ssa on oltu pari vuotta, netin käyttäjämäärä on moninkertaistunut, maailmassa tehdään päivittäin miljardi Google-hakua, Suomessa eniten käyttäjää kohti, sähköposteja ja pikaviestejä kulkee päivittäin 80 miljoonaa, sosiaalisissa yhteisöissä on 250 miljoonaa käyttäjää ja YouTubea ladataan 500 miljoonaa kertaa päivittäin.
Mitä kymmenessä vuodessa on tapahtunut? Nopeat yhteydet ja muistikapasiteetin hinnan putoaminen sekä digitaalikamerat ovat kasvattaneet verkon käyttöä, erityisesti yhteisöllisyyttä ja viihdettä.
Matka alkaa hausta tai hakukoneesta. Puolet ihmisistä ostaa verkosta, mutta lähes kaikki valmistelevat ostopäätöksiään verkossa. Haku on aikomusten tietopankki. Luonnolliseen hakuun ei pysty vaikuttamaan muulla kuin auttamalla hakukonetta löytämään yrityksen verkkopalvelun. Matkan ostoprosessi verkossa kestää noin kuukauden, ja yrityksen pitäisi olla mukana koko ajan. Sen pitää siis tukea sekä aloittelijoita että jo ostopäätöksen tehneitä – ja välttää Flashia, josta hakukoneet eivät pidä. Kuluttajat katsovat hakukoneen tuottamista tuloksista useampia kuin yhden sivun. Yhteisöllisyyteen kannattaa panostaa ja ainakin seurata, mitä yrityksestä ja sen palveluista keskustellaan Suomi24:ssä tai FaceBookissa.
Anni Ronkaisen mukaan tulevaisuudessa verkko on matkan ostoprosessissa tärkeä alusta loppuun, kuluttajat jakavat kokemuksiaan verkkoyhteisöissä ja hakusanamarkkinointi on strategisen matkailumarkkinoinnin ytimessä.

Innostavaa aamiaisoppia

jatkuva muutos
hengästyttää hitaaseen
palautumiseen

faarao haastaa
projektimuurahaiset
pyramideille

aalto tasoittaa
hiekkalinnan, opettaa
muutoksen luonnon
Wakarun Marskin aamiaisseminaari Innostava oppiminen keräsi aamiaispöydän täyteen innostuneita oppijoita 18.9.08.
Toimitusjohtaja Anni Vepsäläinen HRM Partnersista kertoi, miten innostaa ihmiset mukaan muutokseen. Esimies, tiedätkö, mikä motivoi tiimisi jäseniä, mikä saa heidät innostumaan? Jos rahalla ei olisi merkitystä, mikä saisi heidät tulemaan huomenna töihin?
Mitä tarkoitamme, kun puhumme muutoksesta? Olisiko parempi puhua ilmastokriisistä eikä ilmastomuutoksesta? Entä jatkuvasta muuntautumisesta ja suurista muutosprojekteista? Lenkkeilijä tietää tarvitsevansa juoksemisen jälkeen lepoa ja palautumista, jotta kunto kehittyisi. Työelämässäkin hitaus ja palautuminen ovat entistä tärkeämpiä.
Sitoutuvatko ihmiset työtehtäviin vai työyhteisöön? Ihmisen persoonallisuus ja kokemukset vaikuttavat muutostilanteessa. Uudet asiat kuormittavat aina. Pohjoinen ilmasto tarjoaa luonnollisen palautumissyklin vuodenaikojen vaihtelussa.
Kotterin teoria muutoksen portaista toimii – kuin junan vessa (ennen). Oletko muutoksessa subjekti vai objekti? Mieti, mitkä asiat eivät muutu. Viesti siitä! Anna tilaa tunteille!
Viestinnän merkitys on suuri. Ihmiset voidaan saada mukaan muutosprosessiin esimerkiksi käyttämällä verkon erilaisia osallistumismahdollisuuksia.
Jaakko Kuosmanen heitti, että uusi johtaja saattaa olla kuin hyttynen hyytelössä: heiluu, kunnes vaimenee. Hyytelö pitäisi pehmentää. Jos juokset liian kovaa, muut eivät pysy perässä.
Petri Väyrynen johdatti meidät simulointipelien mahdollisuuksiin muutostilanteissa. Hän näytti kuvia jälkikasvustaan simuloimassa keijua tai pääsiäisnoitia. Wakarun blogissa on tarina hiekkalinnoja rakentavasta pojasta, joka valmentautuu luontevasti ulkoa tuleviin muutoksiin.
Tarinat ovat hyvä tapa oppia, mutta niiden lisäksi tarvitaan faktoja. Simulaatiopeli tarjoaa turvallisen oppimisympäristön, josta ulkopuoliset tekijät on siivottu pois. Päätöksenteon ja seurausten ketju on helppo havaita. Peleissä annetaan tilaa luovuudelle ja ryhmätöille, mutta tehtävillä on selvät aikarajat.
Wakarun Apollo 13 -peli johdattaa ITILin käyttöönottoon. Eri pelaajaryhmät voivat keskustella ratkaisuistaan – ja muutoksen merkityksen avautumisen myötä ”ITIL free zone”-kyltit saattavat vähentyä toimitiloista. Egyptin haaste on projektipäällikköakatemia, joka tarjoaa ahaa-elämyksiä erilaisissa projektirooleissa.
Jaakko Kuosmanen luonnehti työuraansa konehuoneesta kulmahuoneeseen toimisto repussa ja vakuutti, että töissä on hauskaa, vaikka toimitaankin tiukasti prosessin mukaan. On helpompi tulla näytelmään, kun tietää, mitä näytellään ja mikä on oma rooli.
Hän avasi meille simulaatiopelejä käytännössä ja pukeutui Apollo 13 -pelin mukaiseen avaruuspukuun. Usein ei auta, vaikka ITILiä kaadetaan korvista, mutta pelin avulla ihmiset voivat ymmärtää, ettei astronautteja olisi saatu hengissä alas ilman hallinnassa olevia prosesseja. Peliin kuuluu vastuukortit ja tapahtumat, joihin pitää reagoida. Peliä pelataan neljä kierrosta, jotta oppimiselle ja oivaltamiselle olisi riittävästi tilaa.
Egyptin haastetta voidaan pelata riippumatta yrityksen projektijohtamismallista, koska eri malleissa on paljon yhteistä: projektiorganisaatio, riskienhallinta sekä työkäytännöt ja niiden soveltaminen. Yleensä saadaan epätäydellisiä toimeksiantoja, joita pitää täydentää. Projektiympäristö on tyypillinen: faaraon oikulliset toiveet, hyvät ja huonot ajat, onni ja onnettomuus, ilmasto ja Niilin tulvat aiheuttavat muutoksia, joihin on reagoitava neljän pelikierroksen ajan.

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?

Prosessimalli ja ihminen

globaalin haaste
innovatiivisuudelle
ketterä tiimi?

prosessimalli
motivoi, mahdollistaa
ihmisen tarpeet
Laskeva aurinko sinkosi punertavat liekkinsä SYSOPENDIGIAn tornin yllä kaartuvalle taivaalle Sytyken MallinnusOSYn pienseminaarin ”Toiminnan tehostaminen prosessimallein” alussa.
Ohjelmistokehitysprosessin mallintaminen
Henrik Terävä SYSOPENDIGIAsta kertoi ohjelmistokehitysprosessin mallintamisesta ja käytöstä diplomityönsä ”Software processing modelling with EPF” pohjalta. Ohjelmistokehityksen yleisiä haasteita ovat tiedonjako tiimeille, prosessien integrointi, koulutusmateriaalien ajantasaisuus ja tehokkaat prosessit. Turhan usein prosessimalli eroaa käytännön mallista, vaikka ohjelmistokehityksen pitäisi perustua ihmisen toimintaan. Prosessin pitäisi motivoida kehittäjän tarpeiden mukaiseen oikeaan toimintaan – kuten häkistä toiseen siirrettävää oravaa motivoi toisessa häkissä avoimen oven takana odottava pähkinä.
Suomalainen, avoimen lähdekoodin tuote OpenMethod säästää aikaa ja mahdollistaa tietämyksen hallinnan. Se tarjoaa standardit rajapinnat räätälöintiin ja uudelleenkäyttöön. Haasteena ovat eri kielialueet ja muutosvastarinta.
Ensimmäisessä demossa Sytyken pienseminaarin työvaiheet ja kestot mallinnettiin ohjelmistokehityksen työkaluilla, toisessa tutkittiin kirjaston staattista ja dynaamista sisältöä, vaatimusmäärittelyn tehtäviä sekä raportteja ja ohjeita, kolmannessa projektista laadittiin julkaisu asiakkaalle.
Yleisöstä kysyttiin, käytetäänkö oikeassa projektissa tällaista tuotetta: menetelmiä on muutenkin niin paljon, ettei niihin tutustumiselta ehdi tehdä oikeita töitä. Onko taustalla kuvitelma ohjelmistokehitystyön jakamisesta yksinkertaisiin paloihin? Eiväthän palat loksahda kohdalleen ilman syväosaamista.
Rami Talme RP5 Softwaresta kertoi EPF Composerin ja Rational Method Composerin käyttökokemuksistaan. Miten asiakas saataisiin osallistumaan sovelluskehitykseen? Kuvaaminen on raakaa työtä ja sisällön tuottaminen vaikeaa; tätä tosiasiaa työkalu ei muuta. EPF:n sateenvarjosta voidaan poimia tarvittava, kerätä sisältöjä eri paikoista ja menetelmistä kuten Scrumista, XP:stä ja RUPista. Menetelmät periytyvät, omia menetelmäsisältöjä ja steppejä voidaan lisätä tai poistaa.
Yleinen väärinkäsitys lienee, ettei Scrumissa tarvitse dokumentoida eikä välittää arkkitehtuureista, koska ne kasvavat prosessin mukana. Hyvä tiimi osannee toimia ilman kuvausta, mutta uudet jäsenet tarvitsevat jotain kättä pidempää. Aiemmin menetelmäkehityksessä laadittiin sisältöjä kuvaamatta niiden järjestystä tai käyttötapauksia – mikä selittänee prosessikuvausten nykytilaa.
Miksi projektia säädellään? Eikö valmis ohje sovellu omaan tilanteeseen? Malliksi voidaan ottaa osaavan tiimin prosessi ja katsoa, sopiiko se omaan tilanteeseen vai pitäisikö iteratiivisesti edeten tuunata siitä omiin tarpeisiin soveltuva.
Ohjelmistoprosessit muuttuvassa maailmassa
Antero Järvi Turun yliopistosta puhui ohjelmistoprosesseista muuttuvassa maailmassa. Muutos syntyy liiketoiminnasta, ei menetelmistä tai teknologiasta. Globaalien markkinoiden hajautetuissa hankkeissa ja lyhyissä tuotesykleissä innovaatioverkostot ja asiakas nousevat keskeisiksi.
Ketterä kehitys yhdistettyjen kompetenssien tiimeineen vastaa muuttuvan maailman tehokkuus- ja reaktiivisuusvaatimuksiin. Ohjelmistokehityksen perusyksikkö voisikin olla ketterä tiimi, jossa jokainen vastaa tekemisistään.
Miten itsenäiset ja ketterät kehitystiimit toimivat tuotehankkeessa tarkoituksenmukaisesti? Kun hallitsemme toisaalta laajat, muokattavat prosessikehykset, toisaalta ketterien menetelmien skaalauksen, tarjoaisivatko monitiimiset sovellukset nykykehitykseen optimaalisen ratkaisun?
Laajoissa prosessikehyksissä kehittämisstrategia on mietitty, riskinhallinta korostunut ja vaiheet päättyvät tarkistuspisteisiin. Työkäytänteiden tarkka kuvaaminen aiheuttaa turhia riippuvuuksia. Ketterässä kehityksessä asiakas on kiinnostunut tuotteesta ja tiimi on tuotteen kehityskone. Ketteryyteen kuuluu epävarmuus: ymmärrys siitä, mitä ollaan tekemässä, kasvaa iteratiivisessa prosessissa.
Miten tiimit suojataan prosessirajapinnalla? Yhdestä käyttötapauksesta voi tulla vaatimuksia kahteen tuotekomponenttiin, joita eri tiimit tekevät yhtaikaisesti. Tällöin tarvitaan scrum-mastereiden yhteydenpitoa ja kustomointia sprinttien aikana. Voidaanko hanketta skaalata entistä isommaksi lisäämällä scrum-tiimejä, joiden välisiä riippuvuuksia scrum-masterit selvittävät scrum-tapaamisissaan?
Kehitysprojektit kytkeytyvät liiketoimintaprosesseihin, toiminnan kehittämiseen ja organisaation oppimiseen. Tuoteprojektit tarvitsevat valmiita ratkaisuja; aikaa on turha kuluttaa organisoitumistapojen miettimiseen. Menetelmästä riippumatta tarvitaan tiimijakoa, työnkulkuja, koordinointia ja vaatimusmääritystä. Tilannekuva auttaa mukauttamaan prosesseja projektin aikana ja viestimään – ja antaa tiimeille tilaa keskittyä kehitystyöhön.
Pienseminaarin esitysmateriaali löytyy Sytyken MallinnusOsyn sivulta.

Yhteistyöllä laatua projekteihin

miksi-kysyjän
tehokkuus tuo laatua
kuviouintiin

kylmä jäävuori
harmaan veden sylissä
hukkuu miljooniin

Dipolissa 13.-14.11.07 pidettyjen Projektipäivien järjestelyissä oli esimerkillisesti panostettu verkostoitumiseen: esitysten välillä oli vartin tauko, kahvia, teetä ja vettä sai jatkuvasti, puolentoista tunnin lounas nautittiin coctail-pöydissä ja ensimmäisen päivän iltana oli parin tunnin verkostoitumistilaisuus ennen projekti-iltamia. Sääli, tauti söi ääneni muutamaa päivää aikaisemmin ja verkostoituminen ja virikkeet jäivät räpistelyksi. Yskän yltyessä jouduin jättämään illanvietot ja valtaosan luennoista. Erityisesti harmitti, etten päässyt Sytyken järjestämään ketterien menetelmien paneelikeskusteluun, johon olin etukäteen lähettänyt kysymyksenkin. Toivottavasti saan jostain tietää, millaista keskustelua kysymykseni herätti.

Ehdin kuitenkin poimia muutaman idun tiistaiaamupäivän esityksistä.
Anders Ericsson Ruotsin TietoEnatorista kehotti meitä kysymään ”Miksi?” vähintään kerran päivässä – kohteliaasti esimieheltä. Projekteissa tiedetään yleensä, kuka tekee ja koska, mutta harvemmin tiedetään, miksi. Pienet lapset kysyvät jatkuvasti ”miksi?”. Aikuisena työelämässä ja projekteissa on myös hyvä kysyä ”miksi?”.
Projektin ohjaus varmistaa, että joukko kulkee kohti liiketoiminnan tavoitteita – kuten kalat akvaariossa. Jos yksi eksyy kuviosta, hänet on välittömästi korvattava toisella.
Työvälineet eivät ratkaise ongelmia, projektia voi hallita vaikka tavallisella taulukkolaskentaohjelmistolla, kunhan käyttää sitä järkevästi. Tiedämmehän sanonnan: vale, emävale ja tilasto. Viimeksi mainittuja ei pidä tuijottaa liikaa.
Mitä on tehokkuus? Tehdään nopeammin? Tehdään asioita rinnan? Vai tehdään laadukkaammin?
Marjukka Markkanen KPMG:stä luovi harmailla vesillä pohtiessaan, mitä yrityksen johto odottaa projekteilta. Yritysten toimintaympäristöt muuttuvat rajusti ja rahaa palaa epäonnistuneisiin muutoksiin. Strategioissa kerrotaan tavoite, ei välttämättä edellytyksiä tavoitteeseen pääsemiseksi. Toki tahtotilan kuvaaminen on tärkeää, mutta toteutustakin tarvitaan: prioriteetit, vastuut, resurssit ja mitattavat hyödyt.
Osa toiminnasta, jäävuoren huippu, projektoidaan ja seurataan – samalla kun kaikkeen muuhun ”mukavaan puuhasteluun” voi huomaamatta viuhua miljoonia.
Menestyvä yritys valitsee tuottavat kohteet ja pitää sitoumuksensa projektin aikana. Toteuttajien ja johdon näkökulmat pitäisi yhdistää, koska toteuttajat tietävät realiteetit; mikä on mahdollista ja mikä ei. Toteuttajat miettivät, miten asia tehdään ja johto miettii, mitä siitä saa. Toteuttajat toivovat standardeja ja menetelmiä, johto joustavuutta ja nopeaa reagointia. Tarvitaan vuorovaikutusta: miten oma näkökulma ilmaistaan niin, että eri tahojen yhteisymmärrys voidaan saavuttaa.
Muutosten projektointi ei ole oikotie onneen. Johdon seuranta saattaa loppua investointipäätökseen. Johdon tuki ei riitä, tarvitaan johdon tahto.
Sam Ehnholm Epicor Software Finland – EMEA:sta esitteli MS SharePointin avulla välineiden integroinnin merkitystä. SharePoint sinällään ei ole arvokas, ellei siihen voida integroida aiemmin tuotettuja sisältöjä muista järjestelmistä. Demo toimi hyvin: projektin seurantaan saatiin vaivatta erilaisia tietoja, kunhan ne oli viety järjestelmiin. Integrointiperustuu malleihin ja olemassa oleviin työkaluihin. Kyse on siitä, miten työkaluja käytetään ja miten olemassa oleva tieto saadaan esiin.
Muistin Anders Ericssonin varoituksen tilastoihin tuijottamisesta. Toisaalta, vaivatta saatavat halutun muotoiset ja ajantasaiset tilastot antavat päätöksenteolle nopeasti suuntaa – toisin, kuin ennalta määrätyn perusmuodon mukaiset tilastot, jotka pitää etukäteen tilata (tällaiseen törmäsin Virtuaaliammattikorkeakoulun Opintopalveluissa).
Kari Vanhalakka Andrizilta painotti projektien ensimmäistä sataa ”kylmää” päivää: mitä jokainen projektin jäsen tuona aikana ajattelee. Näinä päivinä opittu pyritään siirtämään seuraaviin projekteihin, vaikka jokainen projekti olisikin yksilöllinen. Mitä isompi projekti, sitä tärkeämpiä ovat nuo ensimmäiset sata päivää.
Mieleeni palasivat Anders Ericsson aiemmat ohjeet projektin seurannasta ja tavoitteiden mukaisen kuvion varmistamisesta.
Dipolissa oli runsaasti näytteilleasettajia, mutta mukaani tarttui vain Wakarun faaraon esite Egyptin haaste -projektisimulaatiopelistä. Pelin idea pohjautuu tekemällä oppimiseen ja oivaltamisen; sitä voisi olla hauska kokeilla käytännössä niin projekteissa kuin projektityön koulutuksessa.

Pyrähtelevä ohjelmistokehitys

vaatimus jäätyy
putoukseen, pyrähtää
sulaen scrumiin

rup ruoppaa pienen
palan valmiiksi, muuttaa
lennossa suuntaa
Nykyaikaiset ohjelmistokehityksen mallit olivat aiheena Sytyken MallinnusOsyn jäsentilaisuudessa 17.9.07 SYSOPENDIGIAlla.
Paula Salmi Osuuspankkikeskuksesta (OPK), nykyisestä OP-Pohjolasta esitteli heidän kehittämänsä V5-mallin, Allan Halme Accenturalta pureutui RUPin teoriaan ja Lasse Koskela Reaktor Innovationsista pohdiskeli Scrumin taustaa ja todellisuutta tänään.
Yleisössä istuneet kokeneet systeemityöläiset toisaalta kritisoivat Allan Halmen turhan teoreettista esitystä RUPista, toisaalta täydensivät Lasse Koskelan esitystä omilla kokemuksillaan scrumista.
V5-malli kehittää
OP-Pohjolan organisaatiouudistus pyrki eroon eri palvelualueilla toimineiden järjestelmäkehittäjien erillisten ratkaisujen koordinointiongelmista. Ict-palvelut ostetaan keskitetystä ict-organisaatiosta, vaikka liiketoiminnan tavoitteet määritetään edelleen palvelualueilla ja liiketoiminnan edustajat päättävät hankkeiden priorisoinnista ja etenemisestä.
Kehitysprosessin vaiheet noudattelevat perinteistä systeemityömallia idean kiteyttämisestä pilotointiin, jalkauttamiseen ja hyötyjen mittaukseen. Malli on ryhdistänyt ja selkeyttänyt prosessia ja vastuunjakoa, mutta haasteet eivät ole kadonneet: tehtävät ja dokumentit ovat vielä osin päällekkäisiä ja riittävän informaation takaaminen kapulanvaihtotilanteissa eri yksiköissä toimivien määrittelijöiden ja testaajien välillä vaatii ponnisteluja.
Paula Salmi kevensi esitystään kuvalla näppikseen nojaavasta pääkallosta, jota näytöltä tuijotti teksti ”Waiting for reply”. Hän kertoi ketterän kehittämisen käynnistyneen OP-Pohjolassa sertifioitujen projektipäälliköiden ja OWASP-tietoturvaan erikoistuneiden testaajien myötä.
RUP palastelee
Allan Halme vertasi RUPia vesiputousmalliin. RUPissa vaatimuksia ei jäädytetä, mutta koodaus kannattaa aloittaa vasta kun neljä viidesosaa järjestelmästä on määritelty. Kiinteähintainen tilaus edellyttää mahdollisimman hyvää vaatimusmääritystä.
Systeemityötä voi verrata Firenzen katedraalin kupolin rakentamiseen 1400-luvulla: järjestelmästä saa todellisen kuvan vasta, kun toteutus on jonkin matkaa edennyt ja nähdään, pysyykö toteutus sovituissa raameissa ja onko järjestelmän suorituskyky riittävä.
Kun tilaajalta tulee uusia tarpeita kesken projektin, RUPissa osa järjestelmästä on valmiina ja suuntaa voidaan muuttaa kohti uusia tavoitteita. Vesiputousmallissa taas kaikki olisi levällään eikä suunnan muuttamiseen löytyisi kiintopistettä.
Yleisö oli aktiivinen: Vastaava palasteleva suunnittelu-toteutus-idea kehitettiin jo 1990-luvun alussa Sytyken STST-työryhmässä, nykyisen Rela-yhteisön edeltäjässä. OP-Pohjolan V-malli ei tietenkään noudata vaihejakoa vesiputousmaisesti, kuten Allan Halme tulkitsi, vaan sisältää luonnollista iteraatiota, kun käyttäjät, ongelma, teknologia tai markkinat saattavat muuttua projektin aikana. Esitetyt RUPin työmääriä kuvaavat käyrät eivät toimi versioivassa tuotekehityksessä, jossa vaatimusmäärityksen työmäärä ei vähene työn edetessä.
Scrum pyrähtää
Lasse Koskela esitti Scrumin tausta-ideat kuvaamalla Toytan toisen maailmansodan jälkeisestä innovoivaa tuotekehityksestä, jossa pienin askelin tehokkaasti tehtiin jotain konkreettista, mikä tuotti lyhimmän kehitysajan ideasta valmiiseen tuotteeseen. Tältä pohjalta kehitettiin Scrum 1990-luvun alussa.
Asiakkaan priorisoimat tärkeät kehittämistoimenpiteet kootaan Product Backlogiin, josta kahdesta neljään viikkoon kestävän pyrähdyksen työmäärä poimitaan Sprint Backlogiin. Pyrähdyksen jälkeen tuotos on valmis eikä vaadi hiomista.
Ict-ammattilaisten velvollisuus on selvittää asiakkaalle priorisointiin ja toteutusjärjestykseen vaikuttavat tekniset asiat. Yleisön joukosta todettiin, että Scrumissa käytetään jatkuvasti aikaa Backlogin kampaamiseen, ettei se happane.
Scrumia opitaan tekemällä, ei kurssilla. Prosessi on yksinkertainen, mutta vaikea soveltaa. Scrumin toimijoita ovat tuotteen omistaja, moniosaava ja itseohjautuvat tiimi, johon kuuluu 5-9 henkilöä sekä Scrum-master. Scrum-master on kuin voi leivän välissä, poistaa esteitä ja ylimääräisiä välikäsiä sekä huolehtii prosessin järkevästä soveltamisesta.
Asiakkaiden kanssa keskustellaan heidän ymmärtämällään kielellä. Siihen ei kuulu pariohjelmointi eikä Scrum-master.

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.

Sytyken MallinnusOSY

abstrakti malli
kehittää ketterästi
verkkopalvelut
Historian siivet havisivat, kun Sytyken OlioOSYn tuhkasta nousevan MallinnusOSYn ensimmäisessä miniseminaarissa 18.4.07 SysOpenilla kaksi puhujaa ja kaksi osallistujaa muistelivat yhdessä Sytyken Oliotyöryhmää, jossa viisitoista vuotta sitten työstivät yhdessä raporttia Oliot systeemityössä.
Jukka Tamminen aloitti historiakatsauksella 1980-luvun lopulla Finnairilla tehtyihin SRM-tutkimuksiin, jotka paljastivat yksitoista asiakastietojärjestelmää; joka sovelluksella oli omansa ja jokaisessa niistä tiedot eri tiloissa. Kokonaismallintaminen selkeytti tilannetta, mutta toi raskaat vuosia kestäneet projektit, jotka vastasivat huonosti nopeasti muuttuvan liiketoiminnan tarpeisiin.
Tänään tietojärjestelmiä kehitetään ketterästi. Muutamassa päivässä laadittava abstrakti oliomalli auttaa hallitsemaan useat samanaikaiset ketterät projektit. Malliin kootaan kaikki keskeiset käsitteet, joista liiketoiminta tarvitsee tietoa. (Otus, jota Jukka Tamminen nimitti oliomalliksi, on mielestäni UML:n mukainen luokkamalli.)
Malli tuottaa todellisuudesta toisen todellisuuden, lennoista varausjärjestelmän. Tarvitsemme älykkään ihmisen, joka huomaa vastaavuudet näiden todellisuuksien välillä – ja tämän älykkään ihmisen soisi olevan mukana jo järjestelmän rakennusvaiheessa.
Jukka sanoi, että jos liiketoiminnan abstrakti malli tietää jotain käyttöliittymistä, se on saastunut. (Saman tapaista ajatusta olen itse vuosikausia yrittänyt tolkuttaa opiskelijoilleni.)
Sakari Lehtonen heitti, että olioiden aika oli vuosina 1991-2006, mutta nyt on siirrytty SOAan. 1980-luvulla meillä oli moduulit, 1990-luvulla käyttötapaukset ja 2000-luvulla palvelut. Modulaarisuus tarkoittaa metsän näkemistä puilta. B2B tarkoittaa verkostoliiketoimintaa. Domain Modelista eli liiketoimintamallista saadaan XML-malli – niin, yksinkertaisesti väkäsillä.
Tilakaavion käyttö ja merkitys on herännyt uudestaan henkiin, kun mallinnetaan liiketoimintatapahtuman tilaa. Nykyisin puhutaan rekisterien sijaan komponenteista, mutta transaktiot ovat samoja kuin ne ovat olleet neljännesvuosisadan ajan. Uutta on integraatiokerros ja sen BPEL-kieli. BPM-prosesseissa orkesteroidaan liiketoimintaprosessit karkealla tasolla kun taas UML:n käyttötapaukset kertovat käsittelysäännöt tarkemmalla tasolla.
Sakarin mielestä luokkamallia ei pidä esittää liiketoiminnan edustajille vaan heidän kanssaan keskustellaan käyttöliittymien avulla. Oma kokemukseni on erilainen: käyttäjät, asiakkaat tai tilaajat, vaikka heillä ei olisi it-alan koulutusta, osaavat lukea luokkamallia ja ottaa kantaa luokkiin ja niiden välisiin yhteyksiin, kunhan heille annetaan selkokielellä mallin lukuohjeet. Käyttäjät ovat toimintansa asiantuntijoita; juuri he pystyvät kertomaan, voiko tilauksella olla yksi vai monta tilaajaa – tai asuntolainalla monta lainanottajaa, esimerkiksi mies ja vaimo.
Joku yleisön joukosta tiesi kertoa Ivar Jakobsonin sanoneen viime vuoden lopulla Suomen-vierailullaan, että UML on kuollut. Mielenkiintoista! Kun viisitoista vuotta sitten työstimme Sytyken Oliotyöryhmässä Oliot systeemityössä -raporttia, ei UML ollut vielä syntynyt eikä käyttötapauksia keksitty.
Sakari ja Jukka väittelivät kiivaasti käyttötapauksista ja kollaboraatiokaavioista. Sakari kannatti edellisiä ja piti jälkimmäisiä tarpeettomina kun taas Jukka oli täysin toista mieltä.
Illan viimeinen esiintyjä, nuori teoreetikko Tomi Reinikainen kertoi intressiperusteisesta lähestymistavasta. Intressejä on eri tahoilla ja niitä päivitetään järjestelmän elinkaaren ajan, myös ylläpitovaiheessa.