Miksi tietojärjestelmät tökkivät?

Ostaja valitsee halvimman tarjouksen, koska käsitykseni mukaan hankintalaki siihen käytännässä pakottaa. Yritykset tarjoavat lähes aina it-projekteissa reilusti alihintaista, ja ovat varmoja, että alkuperäiseen järjestelmän määritykseen asiakkaan tekemien muutospyyntöjen kautta projektin skouppia saadaan venytettyä niin, että katteet tulevat kohdalleen. Asiakas taas joutuu tekemään muutospyyntöjä, koska kaikilla on erilainen tulkinta siitä, mitä alkuperäinen määritys edes pitää tarkalleen sisällään.

(Sanoa, että yritykset tarjoavat alihintaista on tavallaan hieman harhaanjohtavaa, sillä ei ole olemassa menetelmää, jolla minkään it-järjestelmän vaatimaa työmäärää voidaan luotettavasti arvioida. Sen sijaan työmääräarviot ovat kyllä it-projekteissa itse itseään toteuttavia ennustuksia.)

Olisin myös erimieltä siitä, että VR:n lipunmyyntijärjestelmässä olisi periaatteessa jotain monimutkaista. Kyseessä on vain hyvin yksinkertaisia hakuja, lisäyksiä ja poistoja tietokantaan, maksuliikenteen hoitaminen siinä välissä, sekä usean yhtäaikaisen käyttäjän hallinta. Vastaavia, ja jotakuinkin toimivia, järjestelmiä maailma on pullollaan.

Se, mikä tekee usein järjestelmistä monimutkaisen, on usein nykyisin käytettävä JavaEE-teknologia ja sen päälle liimautuneet muut puolivalmiit teknologiat (en tosin tiedä ovatko nämä juuri VR:n järjestelmissä käytössä), jota kukaan ei kunnolla osaa, kukaan hallitse ja jonka sovelluspalvelimet ja koodauksen apuvälineet ovat täysiä susia. Siihen päälle vähän "agilea-projektimallia", josta siitäkin on aivan jokaisella erilainen käsitys, ja soppa on valmis.

"...miksei testiä avata asiakkaille?"
Näinhän tehtiinkin. Unohtui vain ilmoittaa, että tämä on testausta.

Ongelma johtuu liian suurista projektiorganisaatioista, kun oikea tulos syntyy yhä kahdesta kombinaatiosta:

1. Yksi osaava käyttäjä.
2. Yksi osaava toteuttaja, jolle ensin opetetaan koko systeemi niin, että hän osaa sen ulkoa.
ja jolle opetetaan käytetty teknologia niin, että hän osaa sen ulkoa.

Ei sotilaitakaan lähetetä ampumaan ennen kuin se kivääri osataan purkaa ja koota säkki päässä kohmeisin sormin.

Pientä liennytystä voin antaa noihin lukumääriin eli kahdeksan käyttäjää ja kahdeksan toteuttajaa saa aikaiseksi mitä tahansa. Sen yli menevä tiimi muuttuu tehottomaksi takuuvarmasti.

Oikein johdettuna.

T. Lasse
Mitatusti 300 prosenttia suurempi tuottavuus kuin muilla, ceteris paribus, KS. EU Essi Best Practices.

Esimerkki: Pystymetsästä otettu Oraclelle täysin vieras koodari oppi Oraclen ekosysteemin yhdessä päivässä, kun minä koulutuksen ostajana ja maksajana katsoin mitä koulutetaan ja kuka kouluttaa ja kuinka kouluttaa.

Tähän aina sopii suomalais-ruotsalaisen Bahamalla toimivan pienen rakennusfirman kokemus: Kuvernööri vaihtui ja herralle tilattiin uusi 'pikku' kämppä. No tämä SF-firma sai tietenkin tarjouspyynnön kuten suuret jenkkikonsernit Floridaa myöten.

Yrittäjä sitten laskee viimosen päälle hinnat ja kulut (kullatut vesihanat yms) ja päätyy mielestään hurjaan hintaan. Sitten vielä jänistää ja kertoo loppusumman kahdella. Kun ei ole amattitaitoista työvoimaakaan niin haluaa varmistaa ettei homma tulisi lainkaan hänelle.

Pieni ylläri: 'katsomme että tedän tarjouksenne on realistinen' !!
Tilaa Suomesta kaksi alan moniosaajaa ja hoitaa mansikat himaan.

Hae sinne rautateille! VR:n ongelmat johtuu kilpailutuspaineista; tulosta pitaa tehda, voittoa ja kasvua hakea. Vaikka rauteteiden virka on tuoda ja vieda ihmisia pisteesta A ja B!

Simulointi ei paljasta kaikki ongelmia. Esimerkiksi eduskunnan salijärjestelmä toimi hyvin simuloinnissa, mutta kun kutsuttiin 100 varusmiestä painelemaan 199 nappia, ongelmat paljastuivat. Niiden perimmäisen aiheuttajan löytäminen kesti sitten kuukausia ja kulutti paljon muutakin kuin palaverisämpylöitä. Saan vieläkin kylmiä väreitä ajatuksesta, että järjestelmä olisi otettu käyttöön ilman 100 varusmiehen useita vierailuja eduskunnan kellarissa.

Aikaisemmassa elämässäni olen sivusta ja kaukaa katseella seurannut Accenturen logistiikka- ja hallintojärjestelmän rakentelua. Jäi mielikuva hyvistä puhujista ja mielettömästä määrästä termejä jotka eivät sanoneet kenellekään yhtään mitään, tuskin puhujillekaan. Se kai oli tarkoituskin: sotkea selittelyä niin, ettei kukaan ymmärrä mitään, jolloin saadaan lisäaikaa keksiä uusia selityksiä.

Siksi, että sieltä ostetaan mistä halvimmalla saadaan. Halpuus ja laatu kulkevat harvoin käsi kädessä. Pitkässä juoksussa laatu maksaa itsensä monin kerroin takaisin.

Petteri Järviseltä odottaisin vihdoinkin kannanottoa sille, onko yhteiskunta jossa käyttöjärjestelmä ja sovellusohjelmistojen tuottajat pyrkivät kaiken aikaa monopolistiseen asemaan, patenttikiristykseen sekä todellisen kilpailun rajoittamiseen milloinkaan valmis todella toimivaksi tietoyhteiskunnaksi.

Yli 100 vuotta sitten USA pystyi hajoittamaan muutamat lähes monopoliasemaan pyrkineet suuryhtiöt yleiseen etuun vetoamalla. Nyt vastaavaan tietoteknologian osalta ei ole joko haluja tai kykyjä sen paremmin Pohjois-Amerikassa kuin Euroopassa ja Aasiassakaan.

Järjestelmien on oltava alustayhteensopivia. On sairasta että luodaan järjestelmiä jotka on suorastaan pakotettu olemaan Windows-yhteensopivia. Sehän on varma tae siitä että mikään ei silloin toimi. Missä Windows, siellä ongelma.

Testaaminen osuus moisen järjestelmän kehittämisessä on liioiteltu, ellei kehitysmetodina ole ollut joku ketterä menetelmä tai test-driven sw development.

Tärkeintä on varmistaa ostajan ja toimittajan osalta, että kehitetään oikeaa tuotetta. Määrittely, yksityiskohtainen määrittely, on ostajan ja toimittajan kenties tärkein työkalu. Tämä vie aikaa ja on vaikea tehdä. Mutta se on välttämätön, jotta kehitys voi tapahtua ja että tiedetään mitä ja miten pitää testata. Hyvin suunniteltu on puoliksi tehty pätee hyvin moneen asiaan.

Olisi mielenkiintoista nähdä, miten ketju tai sykli määrittely - kehitys - testaus - korjaus - määrittely on mennyt, etenkin tilaajan osuus ja vastuu jokaisessa vaiheessa.

Laajojen tietojärjestelmien testaus laboratorio-olosuhteissa ei ole ihan niin helppoa kuin voisi luulla. Ongelmana on usein tarpeeksi erilaisten käyttötapausten nopea simulointi. Esimerkiksi nykyiset tietokannat isoine välimuisteineen tallentavat paljon tietoa ja käyttötapausten ollessa liian toistavia järjestelmän kuormitusaste ei enää vastaa todellisuutta. Testauksen haasteellisuus ei kuitenkaan yksinään riitä selittämään tätä VR:n epäonnistumista.
 
On hyvin surullista huomata miten yritys toisensa perään sortuu ulkoistamaan keskeisten järjestelmiensä kehityksen ja ylläpidon uskoen vakaasti saavansa muualta parempaa laatua parempaan hintaan. Lähtökohtana näyttäisi usein olevan se, että koska IT ei ole oman yrityksen keskeisintä liiketoiminta-aluetta, niin ulkopuolinen taho tekee työt väkisinkin paremmin. Ulkoistamista puoltavissa laskelmissa yksi tunti ulkoistettua työtä vastaakin aina vähintään yhtä tuntia sisäistä työtä. Se mikä sitten unohtuu on se tosiasia, että ulkopuolisen konsultin ensisijainen tehtävä ei ole ratkaista toimeksiantajan ongelmia vaan saada puserrettua mahdollisimman monta laskutettavaa työtuntia. Samalla nämä samaiset konsultit turvaavat selustansa tekemällä suorittavat työtehtävät juuri määrittelyjen ja sopimusten mukaan jättäen pahimmillaan sen oikean konsultointityön tekemättä. Tästä on sitten seurauksena se, että ulkoistetuista kehityshankkeista ei tule ainoastaan kalliita vaan myös hyvin jäykkiä ja hitaita. Laatukin on loppujen lopuksi vain juuri niin hyvää kuin se määrittely, jonka yrityksen omat ihmiset ovat osanneet tehdä.
 
VR:n puolelta hankkeessa on todennäköisesti ollut mukana vain hyvin pieni ryhmä asiantuntijoita ja projektivastaavia, joista vain muutamalla on ollut edes jonkinlainen kokonaiskäsitys siitä mitä ollaan tekemässä. En kuitenkaan lähtisi vierittämään syytä näiden yksittäisten ihmisten hartioille vaan katselisin yrityksen kehitysprosesseja kokonaisuutena. Jos metsään mennään näin pahasti niin on mielestäni varsin selvää, että vaatimusmäärittely- ja hyväksymisprosessit eivät vastaa tämän päivän tarpeita. Tällöin vastuu olisi yksiselitteisesti kehitysjohtaja ja viime kädessä tietohallintojohtaja.
 
Itseäni on koko asiassa ärsyttänyt eniten se miten Matti Ahde oli vierittämässä syytä alihankkijoille. Politiikassa syntipukki tietenkin löytyy aina muualta kuin omasta puolueesta, mutta maksaville asiakkaille vastuullinen on palvelun tai tuotteen myyjä eivätkä alihankkijat. Jos hakukone ilmoittelisi sisäisestä järjestelmävirheestä, niin tuskinpa Googlekaan lähtisi syyttelemään palvelinrautaa. VR on ihan itse päättänyt kriittisimpien järjestelmiensä ulkoistamisesta ja nyt nämä päätökset kantavat hedelmää. Niin makaa kuin petaa.

"Jakovuori kuvailee järjestelmää hyvin monimutkaiseksi. Se toimii useassa eri paikassa."

Tämmöinen kommentti Kauppalehden uutisessa jotenkin tiivistää, että homma ei oikein ole hallussa. Tai voihan kyseessä olla ammattitaidottoman journalistin älynväläys.

Pallonheittotaitokin tuntuu liikenneministerillä olevan hallussa. Jos ja kun omistajaohjaukselle on oma ministerinsä, pitäisi jonkun pitää matkustajankin puolta. Mutta kun ei niin ei.

http://www.aamulehti.fi/Kotimaa/1194697789269/artikkeli/kyllonen

Terveisin Kalevi Kämäräinen
www.rautatiematkustajat.fi

seli, seli ja seli

Toisaalta käsittääkseni nykyaikaiset lentokoneet ja erityisesti sotilashävittäjät lentävät täysin tietotekniikan varassa. Näiden lentävien laitteiden tietotekniikan toimintavarmuuden täytynee olla 99,999% varmoja. Hävittäjäkoneethan ovat ns. epästabiileja, joka tarkoittaa, että niitä on mahdoton lentää enää manuaalisesti. Olen ymmärtänyt, että näissä järjestelmissä on useita rinnakkaisia tiedonkäsittelyjärjestelmiä, jotka varmentavat jatkuvasti toisiaan. Tietääkö kukaan näistä enemmän ? Voitaisiinko näistä ottaa mallia maan pinnalla käytettäviin järjestelmiin ja soveltaa ilmailun toimintavarmuusmallia ? Maksaahan se toki, mutta maksaa myös jatkuvat toimintakatkot ja niiden seurannaisvaikutukset.

Tuntuu vähän erikoiselta että VR on halunnnut keksiä pyörän uudelleen tilaamalla täysin uuden lipunmyyntijärjestelmän kun vastaavia on jo vuosia ollut käytössä mm. Saksassa, Sveitsissä ja Itävallassa. Lopulta kyse on kuitenkin suhteellisen geneerisestä systeemistä.

Jos olisin itse ollut päättämässä tämän tyyppisen järjestelmän hankinnasta jossa hankintakustannus tai toimintavarmuus olisivat päätöstä tehtäessä määräävävässä asemassa, olisin luultavasti kilpailuttanut ja hankkinut jo toimivan järjestelmän ulkomailta.

Toinen kilpailutus olisi koskenut paikallisten lokalisaatiomuutosten tuottamista ja tämä työ olisi varmasti sopinut myös nykyisille VR:n valitsemille toimittajille. Kolmas kilpailutus olisi koskenut itse laiteinfraa.

Voisin kuvitella että valmiin ratkaisun hankkimisella olisi säästetty huomattava määrä kehityskustannuksia ja järjestelmän toimivuuden takaaminen olisi ollut helpompaa. Valmiin järjestelmän käyttöönotto olisi lyhentänyt myös projektiin kulunutta aikaa.

Tulee mieleen tässä eräs hauska tapahtuma VR:stä. Aikanaan erään työkaverini kollega oli kehittelemässä jotain tietojärjestelmää VR:lle. Määrityksessä oli vaikeuksia päästä yksimielisyyteen siitä mikä on juna?
Voidaanko junaksi käsittää siis fyysinen juna, eli se jossa on veturi ja vaunut, onko se sama juna jos junan numero vaihtuu, vai eri juna? jne...

Ei mene hyvin tämän hetken tietojärjestelmäkehityksessä. Siinä on tilanne jossa ikään kuin auto tehtäisiin aina uudestaan skrätsistä. Näinhän ei tehdä, vaan erilaisissa automalleissa on ratkaisuja, joista on paljon kokemusta kuluttuajakäytössä. Autoteollisuus olisi varmasti pahoissa vaikeuksissa, jos ne aloittaisivat aina uuden auton kehitystyön "puhtaalta pöydältä". Tietojärjestelmien kehitystyössä näin ei pystytä tekemään, koska teknologiat vanhenee liian nopeasti. Autoissa näin ei ole. Uutta tietenkin tulee, mutta vanhaakin voidaan hyvin soveltaa ja otetaan hallitusti uutta mukaan.