VR otti käyttöön uuden lipunmyyntijärjestelmänsä vaiheittain keskiviikon 14.9. ja perjantain 16.9. välillä. Nettikauppa lakkasi toimimasta heti keskiviikkona, eikä ole alkanut toimia kunnolla tähän mennessä. Sunnuntaina oli pieniä häiriöitä muussakin lipunmyynnissä. Lippuautomaatit tippuivat pelistä maanantaina, ja pian niiden perässä myös asemien lipunmyynti.
VR on tietysti tullut viime aikoina tunnetuksi kyvyttömyydestään liikennöidä junia, joten sikäli tämä ei yllättänyt ketään. Tällä kertaa syypää ei kuitenkaan ole yksin junayhtiö, joka ei saa junia liikkeelle, vaan myös ohjelmistoyhtiöt, jotka eivät saa ohjelmistoja toimimaan: parivaljakko Tieto ja Accenture.
Ongelmana on näet VR:n uusi tietojärjestelmä. Verkkokauppa, asemajärjestelmä ja automaatit käyttävät samaa taustajärjestelmää. Ja taustajärjestelmää ei ilmeisesti oltu tehty kestämään tätä käyttöä. Uudet lipputyypit ja integroinnit lisäsivät kuormaa: ”Emme osanneet ennakoida tällaista. Meillä oli 20-kertainen kysyntäpiikki normaaliin verrattuna” kommentoi hankkeen vastaava. Alalla toimivat lukijat ymmärtävät varmasti, että uudistukset aiheuttavat piikkejä, ja niiden suuruutta on mahdollista arvioida. On aivan normaali käytäntö varautua merkittäviin kysyntäpiikkeihin järjestelmäuudistuksissa, varsinkin jos käyttömalli muuttuu, kuten tässä tapahtui.
Tämä ei ole mitenkään ainutkertaista. Etenkin Tieto on surullisen kuuluisa suurista ohjelmistohankkeista, jotka menevät täysin penkin alle. On kyse sitten eduskunnan äänestysjärjestelmästä, Oulun päiväkotijärjestelmästä, yhteishausta tai ajoneuvorekisteristä.
Eikä tässä nyt ole kyse vain Tiedosta. Samanlaisia kauhutarinoita löytää muidenkin suurten IT-talojen toimittamista projekteista. Taas eilen kuului paljon ideoita, kuinka voitaisiin säätää laki, ettei niiltä saa ostaa mitään, koskaan, ikinä. Vaikka tulisi EU:lta sakot. Tai ehkä moista tuhoa tekevät organisaatiot voisi kieltää EU:n terroristijärjestösäädösten perusteella?
Eiväthän tälläiset fantastiset ehdotukset tietenkään ratkaisisi ongelmaa, vaikka olisivat mahdollisiakin, mitä ne eivät ole. Jos maan kymmenen suurinta IT-toimittajaa lakkaisivat tänään olemasta, olisi meillä muutamassa vuodessa tilalla uudet aivan samanlaiset. Ongelma ei ole yksittäisen yrittyksen huonous tai pahuus, se on syvemmällä.
Asian ydin on tässä Ari Järvelän (Tieto) lausumassa ”VR:n tietojärjestelmä on arkkitehtuuriltaan hyvin monimutkainen järjestelmäkokonaisuus.”
Lippujärjestelmä ei toki ole mikään javakurssin harjoitustyö. Siinä on useammanlaisia lippuja, useita eri tapoja ostaa niitä, ja junavuorojakin on 1200 joka päivä. Junamatkoja tehdään 44 miljoonaa vuodessa, eli ehkä 150 000 arkipäivänä. Ei tätä koodaa iltapäivässä.
Vertailun vuoksi: yksi yhteistyökumppani rakensi lippuvarausjärjestelmän, jolla voi ostaa kaikki maailmassa myytävät elokuvaliput, 230 miljoonaa lippua kuussa. Ihan vaan demotakseen fancy-fancy-bling-bling-ui-systeemiään. Kai sitä joku viikon pari koodasi, satakertaista kapasiteettia. Toki paljon yksinkertaisempaa ratkaisua, ei yhtä monimutkaista kuin VR:llä.
Mutta juuri siitähän tässä on kyse: yksinkertaisista ratkaisuista. Ei VR:n lipunmyynnin olisi mikään pakko olla arkkitehtuuriltaan hyvin monimutkainen. Näin alan ammattilaisena voin sanoa, että jos haluaa toimivaa, systeemistä kannattaa sen sijaan tehdä melko yksinkertainen, ja hyväksyä monimutkaisuutta vain se minimimäärä, joka on ihan pakko. Ei tässä olla mitään ydinvoimalaa tekemässä, vaan ihan tavallista lipunmyyntijärjestelmää.
Yksinkertaisemmat arkkitehtuurit, joissa voidaan asioita muuttaa pala kerrallaan, ratkaisisivat monta ongelmaa. Itse asiassa juuri siihen VR:nkin uudistuksessakin pyrittiin. 15 miljoonaa euroa ja yksi katastrofaalinen käyttöönotto myöhemmin voidaan todeta, että jokin meni vikaan. Se jokin ei ole tekniikkaa. Jokaisen teknisen ongelman takana on aina organisatorinen ongelma, josta johtuu, ettei teknistä ongelmaa ole ratkaistu.
Eli miksi VR:n lipunmyyntijärjestelmä on arkkitehtuuriltaan hyvin monimutkainen? Miksi sen koodaaminen on jättiläishanke, johon tarvitaan toista sataa työntekijää? Miksei sitä tehty pienempänä, helpommin ja pala kerrallaan?
Vastauksia on tietenkin monenlaisia, ja jokaisella virheellä on ainutkertainen historiansa. Tälläisessä löysäranteisessa tarkastelussa riittänee todeta: on sekä myyjän että ostajan intressissä, että hanke on suuri ja monimutkainen.
Ohjelmistohankkeet tehdään monessa vaiheessa alkaen alustavasta määrittelystä, määrittelyn ja erilaisten suunnittelujen kautta toteutukseen. Samat IT-talot tekevät kaikkia vaiheita, ja kilpailevat sitten itse määrittelemiensä järjestelmien toteutusprojekteista.
Jos ohjelmistohankkeeseen tarvitaan 200 henkeä, Suomesta löytyy noin kaksi IT-taloa, jotka voivat sen toimittaa. Aivan, Tieto ja Accenture. Sata henkeä saisi penkkiä lämmittämään jo muutama muukin yritys, ja 20 vaikka kuinka moni. Suuren IT-talon konsultin kannattaa tietenkin määritellä järjestelmä, jonka lähinnä oma talo voi toteuttaa.
Ostajan kannalta – ja puhun nyt ihmisestä, en organisaatiosta – suuri hanke on tietenkin suurempi. Ajatelkaa katumaastureita, kyllä sillä koolla on väliä. Ja jos hankkeita pilkkoo, joutuu koordinoimaan eri projekteja, kun ”kokonaistoimituksen” ongelmia voi aina turvallisesti olla havaitsematta. Sitäpaitsi vakiotoimittajalt ostaminen on turvallista. Kukaan ei ole saanut potkuja siksi, että osti Tiedolta. Jos pikkufirma mokaa, vika on ostajan joka luotti siihen, mutta jotunnettu toimittaja mokaa, niin eihän se voi olla ostajan vika.
 |
| Hyvän ja pahan tiedon puu |
Taisin lupailla jotain ratkaisujakin. Otsikko on vihje: lisää tietoa.
Nimittäin avointa tietoa. Kaikki julkisten tahojen tilaamat ohjelmat pitäisi julkaista avoimen koodin lisenssillä. Avaaminen helpottaisi pienempien yritysten mahdollisuutta osallistua tarjouskilpailuihin, kun omien rahkeiden riittävyyttä voisi tutkia etukäteen. Avaaminen helpottaisi järjestelmien integraatiota, kun rikkinäisen rajapinnan voisi korjata tai ainakin ymmärtää sen toimintaa. Ja avaaminen poistaisi vendor-lock-inneistä suurimman osan.
Kaiken julkisen koodin avaaminen toisi vähitelleen kustannussäästöjä, kun asioita ei tarvitsisi tehdä uudestaan niin monta kertaa, ja kun yritykset uskaltaisivat tarjota projekteja halvemmalla. Vielä merkittävämpi potentiaalinen hyöty tulisi epäsuorasti, jos ja kun ohjelmien laatu alkaisi pikkuhiljaa parantua.
Ja kun yksikään julkinen taho ei tee ohjelmistobisnestä, eivät oikein tehdyt ohjelmat voi sisältää liikesalaisuuksia tai mitään niihin verratavaa salattavaa tietoa. Merkittäviä haittoja ei siis ole.
Monimutkaisuuden ongelmaa avoimuus ei suoraan ratkaisisi. Mutta se olisi osa kulttuurista muutosta kohti parempia ohjelmistoja, pois tästä murheen laaksosta, jossa tavoite on vain saada paljon perseitä tuoleja lämmittämään, ei mitään valmista.
Itse asiassa koodin avaaminenhan on vain virallisten dokumenttien julkisuuden looginen laajennos. Ei mitään radikaalia, ei mitään vallankumouksellista. Paitsi että avaaminen parantaisi radikaalisti julkisia ohjelmistohankintoja. Parhaat ratkaisut ovat yksinkertaisia.
Kirjoittaja on töissä yrityksessä, joka hyötyisi merkittävästi, jos Tiedolta ja Accenturelta ostettaisiin vähemmän softahankkeita sekä kansalainen valtiossa, joka hyötyisi merkittävästi, jos Tiedolta ja Accenturelta ostettaisiin vähemmän softahankkeita.
Minä olen itse asiassa nähnyt yhden julkisen puolen tietojärjestelmäkilpailutuksen, jossa kilpailutettavien toimittajien vertailua oli auttamassa ulkopuolinen pieni it-konsulttitalo, jolla ei ollut kytköksiä yhteenkään toimittajaan.
Kilpailutus onnistui hyvin, kilpailutuksen voitti pieni talo ja toimitettu järjestelmä toimi hyvin.
3v päästä valittiin tilalle ilman kilpailutusta yksi vanhoista isoista taloista. Ilman kilpailutusta oletettavasti siksi, että haluttiin varmistua siitä, että toimittaja on jokin niistä harmaista herroista harmaissa puvuissa jotka eivät heiluta status quoa; sillä, toimiiko järjestelmä tai onko se edullinen on vähemmän väliä kuin sillä, että ostajalla on tunne että nyt ostetaan isolta ja tunnetulta taholta.
Tuollainen uuden, lopputulokseltaan paremman ja hinnaltaan halvemman toimijan mukaantulo kun ravistelee koko pakkaa. Jokainen porras on tottunut siihen, että omalla tontilla on löysää, jonka voi pelata omaan pussiin ja laskuttaa veronmaksajalla. Kun yksi palikka vaihdetaan sellaiseen, joka ei noudatakaan tätä kaavaa, missä yhdessä diilataan sellainen kuvio kuin aina ennenkin, tulee yhtäkkiä muutospaineita muuallekin.
Ja on sitten tympeää olla se byrokraatti joka joutuu vastaamaan niille muille osallisille, että miksi tämä menee siten kuin sopimuksissa lukee, eikä silleen kuin on niistä huolimatta aina ennenkin tehty. Ja byrokraatille on siis helpompaa ottaa se vaihtoehto joka on kallis ja huono, mutta ei vaaranna omaa uraa, eikä aiheuta kiukkuisia yhteistyökumppaneita.
Sanot:”Lippujärjestelmä ei toki ole mikään javakurssin harjoitustyö.”
Miksi se ei ole javakurssin harjoitustyö? Ts. mitä tässä on sellaista, että työ ei voisi olla javakurssin harjoitustyö. Pelkästään eri lippujen määrä ei tätä selitä, lipun hintaan vaikuttavia parametrejä ei lopultakaan ole kovin montaa. Taulukoituna ne mahtuvat A4-kokoiselle paperille.
150 000 lipunostotapahtumaa päivän aikana antaa toki haastetta serveripuolelle, mutta tällaisten järjestelmien haasteet ja ruuhkautumisen välttäminen ovat skaalauskysymyksiä, joita käsitellään osana ohjelmistoalan opintoja. Minusta tämä näyttää juurikin joltain javakurssin harjoitustyöltä.
Ehkä vika onkin siinä, että tätä ei ole tarpeeksi nähty harjoitustyönä, vaan liikaa isona asiakasprojektina, jossa maksajana on turvonnut julkinen instanssi, jolta rahaa voidaan kupata. On keskitytty siihen kuppaamiseen sensijaan että olisi tehty kelvollinen harjoitustyö.
zds on oikeilla jäljillä, meiltä puuttuu paremman termin puutteessa semmoinen ammattikunta kuin ostokonsultti, tai ainakaan niitä ei käytetä tarpeeksi. Tarkoitan siis asiantuntevia ihmisiä jotka tietää mitä voi ostaa ja miten se kannattaa tehdä, ja jotka eivät itse myy mitään muuta kuin omaa osaamistaan. Toinen vaihtoehto on että ostajalla pitää olla omaa tuotantoa ja kehitystä, jonka ansiosta talon sisällä on joku taju siitä mitä se ihan käytännössä tarkoittaa.
Itse tuosta suorituskykyongelmasta, mun kokemuksen mukaan jos ongelmat on tuota tasoa niin ei tuo raudalla ratkea niin kuin lehtitietojen mukaan on kai tarkoitus tehdä. Kuvittelisin että on kirjoitusintensiivinen sovellus, semmoisen skaalaamisessa on yleensä rajansa vaikka se olisi kuinka hyvin tehty. Nyrkkisääntönä, raudalla saa kymmenien prosenttien tehonlisäyksen, jos tarve on satoja prosentteja niin eiku koodin kimppuun.
Tiedemies: Njoo, kyllä se ehkä nykyään voisi ollakin, mutta 10v sitten ei olisi voinut. Skaalautuvuus tuohon mittaan vaatii jo omat ratkaisunsa, jotka eivät niikään liity ohjelmointikieleen, kuin frameworkkien ym. valintaan ja konfigurointiin.
Nykyään tosiaan voitaisiin ihan hyvin lyödä AWS-tili käteen ja käskeä rakentamaan systeemi, joka kestää 1000 pyyntöä minuutissa, ja ajamaan se testeriä vasten. Mutta se ei sitten olisi kyllä Java-kurssi, vaan joku pilvideployment-kurssi. Ehkä pitäisi ruveta pitämään tuollaisia (olemme töissä jo luonnostelleet pilviarkkitehtuurikurssia, tuo olisi luonteva käytännön työpaja siihen jatkoksi).
Zds, Teemu: viimeeksi tänä aamuna puhuin puhelimessa hyvin pätevänoloisen saksalaisen ostokonsultin kanssa, joka oli ostamassa ketterää (ihan oikeasti ketterää) projektia pohjoismaiselle toimijalle reguloidulla alalla. Eli toivoa selvästi on, kylllä se ammattikunta on vähitellen syntymässä.
t. Nimim. itsekin ostokonsulttina toiminut.
Ja tuon avoimuuden tarkoitushan oli nimenomaan helpottaa status quon heiluttamista ja vaikeuttaa sen ylläpitoa.
Oma hypoteesini ongelmasta on: SAPista lasketaan jokaisen lipunhinnan esityksen yhteydessä dynaamisesti ne dynaamiset hinnat. Joku on innostunut liikaa uudesta bisnesmallista, ja luulee että koodin pitää toimia samalla tavalla. Tästä seuraa sitten, että taustajärjestelmän kuorma suhteessa lipunmyynteihin moninkertaistuu; ehkä juuri sillä faktorilla 20. Oikeinahn systeemi tehdään niin, että pidetään yllä hetkellistä hintataulua omana SOA-komponenttinaan, ja pushataan sinne taustajärjestelmästä uudet hinnat vaikka pari kertaa minuutissa. Mutta tämä oli ihan puhdas arvaus.
Vaikka kannatankin avointa lähdekoodia, en laittaisi avointa lähdekoodia ehdottomaksi vaatimukseksi. Avoimen lähdekoodin vaihtoehtona saa olla suljetut COTS (common of the shelf) ratkaisut.
Ts. suljettu koodi on sallittua, jos a) ohjelma on valmis b) ohjelmalla on muitakin käyttäjiä kuin valtio.
Esimerkkejä: windows, office, jne.
COTS:in voi hyväksyä suljettunakin, koska sen saa käyttöön heti.
Sensijaan kaikki koodi mikä räätälöidään valtiolle/kunnille/muille julkisen talouden toimijoille tulee olla avointa lähdekoodia – jä lähdekoodin tekijänoikeudet siirtyvät tilaajalle, ei tekijälle.
Esimerkkejä: vr:n liput, e-resepti, potilastietokanta, aken tietojärjestelmä
Räätälöitävän järjestelmän lähdekoodin avoimuus varmistaa että järjestelmän toimittajan voi vaihtaa milloin vain.
AKE:n järjestelmä on muuten jo 10v aikataulusta jäljestä, googlesta lisätietoa. Omanlaisensa maailmanennätys.
Huhupuheiden mukaan järjestelmää kehittäneiden koodareiden testeissä systeemi toimi (lue: oli toimimatta) samalla tavalla kuin käytännössäkin. Pukutyypit ja businessjohto kuulemma eivät tästä välittäneet vaan halusivat releasen (ja siihen sidotut bonukset?) heti. Jäljet siis johtavat taas sylttytehtaalle.
VR:n matkustajaliikenteen matkojen määrä oli 68,9 miljoonaa vuonna 2010.
VR:n liikennöimistä 68,9 miljoonasta junamatkasta 47,1 miljoonaa tehtiin Helsingin seudun lähiliikenteessä vuonna 2010.
Lisäksi Helsingin seudulla tehtiin 57,1 miljoonaa matkaa metrolla ja 54,5 miljoonaa matkaa raitiovaunulla.
Yhteensä Helsingin seudulla siis tehtiin erilaisilla raideliikenteen muodoilla 158,7 miljoonaa matkaa vuonna 2010.
Toisin sanoen muualla Suomessa kuin Helsingin seudulla tehtiin 21,8 miljoonaa matkaa raideliikenteessä vuonna 2010. Tämä on 13,7 % kaikesta Suomen raideliikenteestä.
Kaikista Suomen junaliikenteen matkoista puolestaan 68,4 % oli Helsingin seudun lähijunaliikennettä.
Voisiko joku selittää minulle, miksi junaliikenteestä vastaa Suomessa VR?
Pointtini ei nyt ollut se, onko se tehty javalla, vaan että valmiita sapluunoita tämän kokoluokan järjestelmille on olemassa, ja tässä systeemissä ei ole mitään sellaista poikkeuksellista haastetta, jota ei (käsittääkseni, en hajautetun tms. arkkitehtuureja tunne) opetettaisi käytännössä kaikille softa-alan DI:lle ainakin teoriassa.
Tavoittelinkin sitä, että perusvika eivät ole ne tekniset haasteet vaan se, että tehdään organisaatioille, jotka ovat turvonneita ja joissa on aivan vinot kannustimet. Yksinkertainen ratkaisu on, että pieleen mennyt projekti ei olekaan bonusautomaatti, vaan projektin botchannut pukuporukka menee kilometritehtaalle tai ottaa palkanalennuksen. Nykyisinhän ns. varmanpäälle pelaaminen on isoissa organisaatioissa IT-projekteissa sitä, että otetaan siltä, joka on ennenkin tehnyt sutta, niin voidaan aina sanoa, että tällä tavalla on ennenkin toimittu eikä vika ole meidän, ja bonukset juoksee.
Eräässä yliopistossa, jonka toimintaa sattumalta hieman tunnen otettiin jokin aika sitten käyttöön eräs järjestelmä, josta tiedettiin että siitä tulee susi. Kun ostajan konsulttina ollut asiantuntija oli alusta asti sanonut, että tämä menee pieleen, älkää tehkö näin, niin pukuporras reagoi tukkimalla konsultin suun ja yritti uhkailla hiljaiseksi että saataisiin projekti nyt vaan läpi jotenkin, vaikka oli menossa kiville. Kukaan ei joutunut vastuuseen vaikka paperijälki siitä oli, että käytännössä tahallaan ostettiin paskaa.
Julkinen toimija tässä on se ongelma, ei tekniikka.
Pardon my french, it-asioissa täysin diletantti muusiko kun olen, mutta eikö esim. lentokonefirmoilla ole käytännössä täysin vastaavat, jopa monimutkaisemmat systeemit jatkuvasti käytössä? Lipun hinnat muuttuvat jatkuvasti ja nettikaupat yms. automaatit pelaavat. (Käytännössähän ”automaatti” on vain nettipääte jossa on spessu käyttöliittymä.)
Miksi hemmetissä systeemit täytyy koodata 15m€ kustannuksin taas ihan alusta? Eikö oikeasti ole mitään valmista lippujärjestelmätoimittajaa, joka olisi voinut toimittaa valmiin palvelupaketin?
Tiedemies: joo siis käytin ”java-kurssia” terminä peruskurssille, kun niin olen siihen HY:ssä tottunut. Lavi-tason kursseilla ainakin omassa opinahjossani käydään tämän tason asioita teoriatasolla läpi jonkin verran; enemmänkin ehkä voisi, ja ehkä teknillisessä käydäänkin.
Harjoitustöitä, joissa tehtäisiin oikeasti skaalautuva systeemi sen sijaan en ole nähnyt. Mutta tosiaan aika taitaa olla soveltuvien työvälineiden osalta niille kypsä, kun tarvittavan infran voi ostaa tunniksi kerrallaan käyttöön kun testaa, eivätkä kulut ole siksi kohtuuttomia.
Ne tekniset ongelmat ovat toki olemassa, mutta vaikea nähdä tässä tapauksessa mitään sellaista, joka ei olisi ihan oppikirjatason ratkaisuilla onnistunut. Oikea ongelma on organisaatiossa ja ostoprosessissa, kuten oma esimerkkisikin havainnollistaa.
Hannu: on käytössä, ja luulisi löytyvän. Siellä on kai taustalla SAP, johon saanee nuo hjinnanhallinnat halutessaan valmiina mokkulana. nettikaupan (ja automaatit, ja virkailijapäätteet, sama asia nekin oikeastaan) voi sitten tehdä ihan standardin webiframeworkin päälle kohtuullisella omalla koodilla. Suurin vaiva on kasata kaikki yhteen JA TESTATA KUNNOLLA.
Juhoa/posts: mielenkiintoinen huhu. Kuulostaa ihan mahdolliselta, valitettavasti
Kirjoituksesta (ja muutamista kommenteista) tuli selväksi, että ongelma liittyi koodiin tai softa-arkkitehtuuriin. Miksi tämä on Tiedon vika? Eikös Accenture koodannut ja Tieto hostannut? Onko Tieto tässä syyllinen kuten kaikki ruotsalaiset homoja ja mustalaiset varkaita?
Siis Tietoa puolustelematta tai sitä liiemmälti rakastaen, kapasiteetin ostajallakin on jokin vastuu.
komppaan anonyymiä, itse kun olen siellä kapasiteetin puolella. Siinä on jotain liikkistä että kun transaktio kestää 0,5 sekunnin sijaan 15 minuuttia niin ensimmäinen kysymys on että onko liian hidas prossu tai verkkoyhteyksissä vikaa. Opetaanko siellä peruskursseille suhteellisuudentajua?
Kunnon testaamiseen tarvitaan näillä prosesseilla käytännössä release, joten halvempaa on toimittaa se, ja sitten korjata jos (siis kun) jotain ongelmaa tulee. Tämä on aivan urpå prosessi, mutta siihen on totuttu, ja sillä voi tehdä rahaa, kunhan asiakas sen nielee.
Meillä on sikäli hauska tilanne, että softassa joka ikinen vika on valmistusvika, eikä siinä ole huonoja osia, jotka on periaatteessa suunniteltu kunnolla, mutta jonka joku tehtaan rikkinäinen kone on prässännyt väärin. Siksi on aivan käsittämätöntä, että joku suostuu ostamaan softaa ja maksamaan siitä senttiäkään, ennenkuin se on selvästi osoitettu toimivaksi käytännössä. Mutta maailma on tällainen, syytän siitä viime kädessä Microsoftia, joka on kasvattanut yhden sukupolven ihmisiä uskomaan että softa voi muka käyttäytyä niin kuin niiden tuotteet ja että se on ”normaalia”.
Kuulin VRn julistaneen ennen suurta lippu-uudistusta, että vanha Opera -järjestelmä jätetään standby -tilaan taustalle JOS jotain ongelmia tulee. Kaikesta voimme päätellä, ettei ongelmia ole ja uusi järjestelmä toimii.
Toisaalta voi kai kysyä kohtuullisen oikeutetusti, miksi piti rakentaa kokonaan uusi järjestelmä vanhan päälle tai alusta asti? Maailmalta olisi saanut varmasti toimivia ja hyväksi havaittuja ratkaisuja ( mallia voi ottaa vaikka halpalentoyhtiöiden nettilipunmyynneistä ) – vaikka länsinaapurista sikäläiseltä valtiolliselta rautatieyhtiöltä. Mutta ei, piti rakentaa oma…
Omia näkemyksiäni mitä tästä voisi oppia:
http://67.prosenttia.fi/?p=559
TM, tuotantovinkelistä: Me ollaan vaan kyynistytty siihen että softa nyt on kuraa kuten kirjoitat, semmoisia vienoja toiveita esimerkiksi esitetään ettei errorlogiin tule virheitä joihin ei tarvitse reagoida, mutta toikin on toiveajattelua.
Se mitä minä en tajua on että miksei suosiolla lähdetä siitä että kaikki hajoaa kuitenkin, niin kuin rautapuolella tehdään, ja suunnitella sen mukaan. Eli esimerkiksi, kun siinä verkkopalvelussa on kuitenkin joku hilavitkutin joka hyydyttää koko roskan niin miksei sitä saa edes pois päältä ihan vaan napinpainalluksella? Miksei ole varatoiminnallisuuta, esimerkiksi kevyempi käyttöliittymä jos se hieno interaktiivinen härpäke hyytyy omaan mahdottomuutensa? Jne.
Kyllä tästä on suurelta osin helppoa olla samaa mieltä, joskin läheisessä ojassa lepäilevä oma lehmä antaa vähän toisenlaisen perspektiivin. Varsinkin tuon yksinkertaisuuden vaatimus on helppoa allekirjoittaa (ja huomattavasti vaikeampi toteuttaa).
Muutamia hajanaisia huomioita:
Yksinkertaisuuden pitäisi lähteä paitsi järjestelmien ostamisen osaamisesta, myös niiden määrittelystä. Tietyillä toimittajilla on jalka pysyvästi oven välissä koska niiden suurin myyntivaltti on substanssi- ja olemassa olevan ympäristön tuntemus. Tämä saattaa kuulostaa triviaalilta, mutta harvoin on. Julkisen puolen substanssi on aika raskasta, osittain koska laki ja säädökset, osittain koska niin on aina ollut ja osittain koska sovelluskehityksen lisäksi pitää tehdä aikamatka olemassaoleviin järjestelmiin. VR:n lippukaupasta en tiedä, mutta ainakin suurten perusjärjestelmien kohdalla paletti on aikas iso. Sitten on erikseen se liittymäpaljous.
Isoilla toimittajilla on, hyvässä ja pahassa, kosolti tietotaitoa substanssista, mutta vaikeuksia pysyä kiinni kehityksessä ja pitää kiinni osaajista. Ostajalla pitäisi olla riittävästi tahtoa paitsi vaatia substanssista läpinäkyvämpää, myös tahtoa tehdä siihen niitä yksinkertaistuksia. Jo senkin vuoksi että jonkinmoinen osa substanssista on suullista perimätietoa ja mielikuvissa suunnilleen alkemiaan verrattavaa mystiikkaa. Jonkinlaisella modernilla kokonaisarkkitehtuurilla ja riittävän yksinkertaistetulla määrittelyllä hommat saisi ehkä pilkottua niin pieniksi että niitä voi ihan oikeasti kilpailuttaa laajasti. Ja välttää ne parin-kolmen vuoden megahankkeet.
Sitten on tietysti spesifistä teknologia- ja välineosaamista joita on lähinnä isoilla taloilla. Ei se DB2 sieltä höyrykonesalista ihan hetkessä häviä.
Noin lopuksi tietty toivoisi että nuo perinteiset isot toimittajat osaisivat markkinoida itseään myös suurelle yleisölle ja kertoa myös niistä onnistumisista. Tulee vähän toispuoleinen olo tässä uutisoinnissa.
Tiedemies: ”Julkinen toimija tässä on se ongelma, ei tekniikka.”
Mitä todisteet sanovat tästä väitteestäsi?
Meillä on nykyään aika vähän kokonaan julkisten toimijoiden laatimia tietojärjestelmiä. Se ei ole muodikasta.
Lähinnä esimerkeiksi käyvät kai Kelan kaikki tietojärjestelmähankkeet. En ole nähnyt asiasta tilastoja, mutta käsittääkseni Kelan kehitys on poikkeuksellisen kustannustehokasta. Ainakaan mitään katastrofeja ei ole ollut julkisuudessa. Vaihtuvuus Kelan it-yksikössä on Suomen alhaisimpia ja työtyytyväisyys Suomen korkeimpia. Se on yllättävää, kun tietää ettei Kela varmasti voi kilpailla palkalla.
Tässä keskusteluketjussa läpikäyty esimerkki ei ole julkisen puolen toteutushanke, vaan toteuttajana on nimenomaan yrityksiä joilla on ensisijaisesti kaupallinen intressi tehdä rahaa.
Edes tilaaja ei ole puhtaasti julkisen puolen toimija, vaan konsernin emoyhtiö VR-Yhtymä Oy pyrkii tekemään liiketoiminnastaan kaupallisesti kannattavaa. Yritykseen on kohdistettu viime vuosina rankkoja tehokkuuden lisäämiseen pyrkiviä toimenpiteitä, jotka ovat kaupallisen puolen toimintatapojen tuomista julkisen puolen organisaatioon.
On argumentoitavissa, että VR:n palvelu on rapautunut nimenomaan näiden kaupallisista lähtökohdista tehtyjen tehostustoimenpiteiden seurauksena.
Käyttäjämäärät kuulostavat hurjilta, mutta minusta tässä jäänyt huomioimatta käyttäjänäkökulma. Jos joku tahtoo matkustaa junalla ja ostaa lippunsa verkkokaupasta, hän sinnikkäästi yrittää kunnes onnistuu tai luovuttaa. Sama käyttäjä voi siis kokeilla aamulla, palata päivällä ja jatkaa yömyöhällä verkkokaupan kanssa painimista – koska matkustusongelma on saatava ratkaistua.
Varmaan uudistus lippujen hinnoittelussa sai myös enemmän yleisöä liikkeelle (miksi se piti ajoittaa juuri järjestelmäuudistukseen?), mutta tuleehan aseman myyntipistekin tukkoisaksi jos kukaan ei pääse poistumaan tiskiltä tyytyväisenä matkalipun kanssa.
Minäkin toivoisin Otsolta vastinetta anonyymin 20. syyskuuta 2011 16.53 kirjoittamaan viestiin. Monilla julkishallinnolle järjestelmiä toimittavilla yrityksillä on ollut ongelmia. Uutiskommentteja ja blogeja lukiessa tuntuu siltä että on yhtä muodikasta huudella Tiedon kaikkia tekeleitä paskaksi kuin iPhonen käyttäjiä homoiksi, Windowsin käyttäjiä pelleiksi jne. VR myönsi arvioineensa tarpeen väärin. Miten tämä on juuri Tiedon vika? En minäkään bensa-aseman pitäjää syytä siitä että tankkasin liian vähän polttoainetta ja auto jätti tien poskeen.
Matti (ja aiempi anonyymi): Tekstin varsinainen tarkoitus ei siis ole haukkua Tietoa, vaikka sellainen kuva kieltämättä voi tulla nopeasti lukemalla. Aivan kuten sanot, Tiedon haukkuminen on trendikästä samaan tapaan kuin iPhone-käyttäjienkin. Sillä saa halpoja pisteitä. Itseäni lainaten ”Ongelma ei ole yksittäisen yrittyksen huonous tai pahuus, se on syvemmällä.”
Varsinainen ongelma on pikemminkin ostoprosessissa, siinä, että ostajien kannattaa ostaa softaa tavoilla, jotka johtavat huonoon lopputulokseen. Ja tähän liittyvässä kulttuurissa hyväksyä kelvottomat arkkitehtuurit ja surkeat toteutukset. Tätä tematiikkaa yritän lähinnä avata kirjoituksessa. Ja vähän hakea siihen vastaustakin, että miten ongelmaa voisi lähteä purkamaan. Yhden yrityksen haukkuminen kun ei tosiaan auta asiaa.
Pekka: noinhan se juuri meni. Mutta se lisäkysyntä pitäisi olla ihan hyvin ennakoitavissa. Ei ole mitään syytä, miksi se ei olisi.
merten: Kiitos tarkentavasta analyysistä. Itselleni VR:n softaratkaisut eivät ole suoraan tuttuja lainkaan, eli olen tässä asiassa täysin lehtitietojen ja kuulopuheiden varassa. Siksi puhunkin enemmän yleisistä lainalaisuuksista, kuin tämän nimenomaisen tapauksen ongelmista.
Ja toimittajien jalka oven välissä on aika suuri ongelma. Monessa organisaatiossa on vahva kulttuuri, että tietyltä toimittajalta ”kuuluu” ostaa, ja sitten kilpailutukset koitetaan junailla siihen suuntaan. Aika pahaa jälkeä saa syntyä, ennen kun toimittajaa vaihdetaan. Ja riittävän isoissa habnkkeissa vaihtoehtoja ei sitten enää ole kovin montaa. Määrittelyn puolella voidaan hyvinkin ratkaista jo käytännössä, kuka toteutustyön saa tehtäväkseen.
Mikko: Ihan näppituntumalla heittona, pahimmat ongelmat näyttäisivät syntyvän julkisen ja yksityisen rajapinnoissa. Esimerkiksi sellaisessa valtion täysin omistamassa osakeyhtiössä kuin VR, jonka lakisääteinen tehtävä on vain tuottaa voittoa omistajalleen.
COTSista puhunut anonyymi: Olen kokolailla samaa mieltä. En avannut tuota tähän kirjoitukseen enempää, mutta suunnilleen noinhan se pitäisi tehdä.
Eli julkishallinto voi ostaa esim. Office-paketin halutessaan, mutta heti jos tehdään jotain ksutomointeja ja maksetaan työstä, kaikki uusi koodi on vapaata. Off-the-shelf-tuotteet voidaan esim. testata heti alkuunsa, ja kaikki se, mikä ei toimi jo projektin alussa, katsotaan projektissa tehdyksi työksi.
Tästä seuraa toki jonkin verran kaikenlaisia rajanvetoja ja harmaita alueita ja ehkä tarvetta Escrown tyyppisille palveluille ja ulkosille konsuletille. Mutta se on ihan arkipäivää isoissa IT-hankkeissa muutenkin, ei mitään kauhean ongelmallista.
Olipa loistava kirjoitus, kiitos siitä!
Olen itse toiminut pitkään alalla ja ollut mukana useassa saman kokoluokan projektissa. Oma analyysini on kiteytynyt vuosien saatossa seuraavaan kuvitteelliseen anekdoottiin: ”Pihalle haluttiin kaivaa kuoppa suihkulähdettä varten. Oli kuitenkin päätetty, että kuopan kaivamiseen on käytettävä sadan ihmisen työpanos vuoden ajan.”
Tyhmän kuuloinen esimerkki, mutta näinhän asia aika usein on. Hanke on asiakkaalle tärkeä, suuri ja haastava. Sen pitää olla sitä myös ulkoisilta puitteiltaan. Tämä ajatus ja tarina on on iskostettu kaikkien avainhenkilöiden mieliin niin mikään vähempi kuin 200 hengen organisaatio ei riitä, vaikka softakehityksessä vähän on melkein aina enemmän.
Ohjelmistot ovat aina toteutuksen tehneen organisaation näköisiä. 200 ihmistä pitää jakaa ainakin viiteen osaan, jolloin myös järjestelmä pitää jakaa myös. Siispä pitää integroida. Ja hankkia integrointia ”auttavia” välineitä (SOA-käärmeöljyjä). Sen jälkeen peli onkin arkkitehtuurin osalta aika pitkälti menetetty.
Lyhyemmin sanottuna: 200 ihmistä kun laitetaan tekemään tietojärjestelmää, lopputulos on lähes väistämättä monimutkainen.
Olen kirjoitellut itsekin aiheesta aiemmin: http://realistic-architect.blogspot.com/2010/12/how-to-rebuild-large-legacy-system.html
Perusajatus kuitenkin on, että pienellä, taitavalla tiimillä ilman pompöösejä seremonioita toimittaessa tämä VR:nkin järjestelmä olisi saatu todennäköisesti tehtyä paremmin ja murto-osalla kustannuksista.
Ja mitä tulee Tiedon haukkumiseen – itseäni alkaa ainakin jo kyllästyttää. Tässäkin tapauksessa softan on toteuttanut Accenture ja Tieto toimittanut ”vain” infran. Silti useimmat haukkuvat Tietoa.
Samalla voitaisiin myös lopettaa se Nokian haukkuminen 🙂
Mikko: Ihan näppituntumalla heittona, pahimmat ongelmat näyttäisivät syntyvän julkisen ja yksityisen rajapinnoissa. Esimerkiksi sellaisessa valtion täysin omistamassa osakeyhtiössä kuin VR, jonka lakisääteinen tehtävä on vain tuottaa voittoa omistajalleen.
Tavallaan olen samaa mieltä.
Mutta minusta esimerkiksi VR:n lippu-uudistuksen nimittäminen ”julkiseksi hankkeeksi”, kuten esimerkiksi Valtiontalouden tarkastusvirasto tässä uutisessa tekee, on kansalaisten tietoista harhauttamista. Taustalla oleva ideologia on julkisten palveluiden yksityistäminen.
Ongelma ei ole se, että VR on julkinen toimija — siellä on vuosikaudet ennen yksityistämistä toimitettu toimivia palveluita ilman katastrofeja. Ongelma on ideologisista syistä lähtevä pakkoyksityistäminen joka ei ota huomioon toimialan erityispiirteitä. Eli VR:n osalta luonnollisesta monopolista eli infrastruktuurista on pyritty väkisin vääntämään markkinatalouden periaatteiden mukaan toimiva voittoa tavoitteleva yritys.
Ideologisista syistä tehdyissä yksityistämisissä ei voi kuin epäonnistua: Sonera (Saksan miljardit), VR, Itella, Aalto, HUS, jne. Jostain syystä näissä organisaatioissa pakkoyksityistäminen tarkoittaa että kun ”tehostetaan toimintaa” leikataan perustoiminnoista niin että ne rapautuvat käyttökelvottomiksi (Postin toimipisteet lakkautetaan, ihmiset odottavat leikkausjonoissa, VR:n junat eivät kulje, Aallosta karkaavat tutkijat pois). Ja kaikkiin järjettömiin mausoleum-hankkeisiin, kuten tämä lippu-uudistus, löytyy loputtomasti miljoonia.
On huomattavaa, että uutisessa sivuutetaan kaikki todelliset datapisteet (Kela) kun puhutaan ”julkisista hankkeista” ja käytetään myös esimerkkejä jossa sekä tilaaja että toimittaja ovat kaupallisia osakeyhtiöitä.
Kyllähän tuon saa helpolta javan alkeiskurssin yhden sivun uml kaaviolta kuulostamaan, kun sen niin mielessään pyörittelee, mutta sitten kun pitäisi tosiaan saada järjestelmä käytännössä toimimaan, niin aika monta mutkaa on matkassa. Ei tietojärjestelmistä huvikseen tehdä niin laajoja ja monimutkaisia, vaikka saattaa ehkä kuulostaakin että jollain olisi sellaiseen intressejä.