Kun julkiselle puolelle tulee huonosti toimiva tietojärjestelmä, vastaus on aina että henkilöstö ei vain osaa käyttää sitä ja järjestelmä kyllä on hyvä

Vierailija kirjoitti:

Vierailija kirjoitti:

Nykyjärjestelmien perusongelma on se, että ovat niin mutkikkaita, koska niihin on ympätty valtavasti tietoa ja eri toimintoja yhteen ja samaan ohjelmaan. Väistämättä (?) lopputulos on sekava. Mutta se on sitten voi voi ja käyttäjät muutosvastarintaisia tyhjästä valittajia kun eivät varauksetta ylistä uutta hienoa järjestelmää... 🙄

Niinpä. Ja kyllä sitä aina ihmettelee, miksi jotain aivan nyanssiasiaa, kuten fonttia, on viilattu ja viilattu, mutta sitten joku perusominaisuus tökkii.

Ilmeisesti on siis todella vaikeaa tehdä järjestelmää, jossa voisi esim vetää monta tiedostoa asian alle kerralla. Nyt sitten vedetään niitä yksi kerrallaan ja odotellaan jokaisen kohdalla 2min että se latautuu. Tosin ei siinä järjestelmässä myöskään pysty korjaamaan tietoa, jos huomaat että merkkasit väärin. Tai poistamaan tuplana mennyttä asiakirjaa keskeneräiseltä asialta.

Tuo ei tarkoita yhtään mitään. Ei siis ihme että käyttäjien haastattelut ja speksin keräilyt menevät pisin reisiä.

Kännykän ominaisuudet ovat nykyään paljon laajemmat kuin keskiverto tietojärjestelmän. Tarvitaanko kännykän käyttöön viikkojen koulutusta, seminaareja ja hampaiden kiristelyä?

Jos ohjelmaa ei osaa käyttää, se on huonosti suunniteltu

Vierailija kirjoitti:

Ongelmana on naiset jotka ovat hakeutuneet julkiselle sektorille (se sana jota Igor haet on sektori, ei puoli).

Ne naiset kun ei ole penaalin terävämpiä kyniä ja järjestelmät... ne nyt vaativat jotain perustaitoja.

Ai niinkun että naiset kilpailuttaa tietojärjestelmien hankinnat julkisella puolella? Sitä saa mitä tilaa, valitettavasti, kun on kyse julkisista kilpailutuksista. 

Oon ollut tarjoamassa it-projekteja ja on usein päätetty, ettei edes tarjota, kun (julkisen puolen) asiakas ei itsekään ymmärrä, mitä on ostamassa.  Kilpailutuksen tarjouspyynnöistä ja sen liitteistä näkee joskus ensimmäisellä lukemisella, ettei toimitusprojekti voi muuta kuin epäonnistua. Pyydetään yhtä ja vaaditaan jossain toisessa kohtaa jotain ihan muuta. Tarjouspyyntöihin on kopioitu varmaan jotain 1990-luvun järjestelmien toimintoja ja kerrottu, että ne ovat pakollisia vaatimuksia. Kukaan ei ole ajatellut ottaa järjestelmän tulevaa käyttäjää mukaan tai edes ottaa sen arkisen työn kulkua mitenkään huomioon. 

Ohjelmistoprojekteja tutkitaan yliopistoissa ja firmoissa koitetaan kehittää toimivia käytäntöjä koska likimain kaikki osapuolet tajuaa ettei homma toimi tällä hetkellä aivan täydellisesti :)

Joka tapauksessa ongelma ei ole yksinkertainen kun otetaan käyttäjät jotka ei tiedä mitä oikeastaan haluaisi ennen kuin se tuodaan nokan eteen ja nuo tajuaa että tuonhan me oikeastaan haluttaisi.

Toisaalta käyttäjillä on iso muutosvastarinta eli jos on opittu tekemään joku asia edellisessä ohjelmassa tietyllä tavalla niin valitusta tulee heti jos se uudessa tehdään toisella tavalla.

Kolmas ongelma on ettei softan tilaaja ole sen käyttäjät vaan näiden organisaatio ja näillä on omat vaatimuksensa mm. hinnan ja aikataulun suhteen. Lisäksi nää tuppaa laittamaan jonkun tuotevastaavan projektiin mukaan päättämään mitä ominaisuuksia tarvitaan eniten ja tää ei välttämättä ole käyttäjä.

Sitten voidaan vielä lisätä monimutkaisuuteen se, että ohjelmistokehitys on muuttunut viimeisen parinkymmenen vuoden aikana aika lailla eikä homma ole oikein kypsynyt vielä prosessiksi josta suunnilleen voisi sanoa että kunhan toimitaan näin niin tulee jotain käyttökelpoista, kuten esim. talonrakennuksessa.

Tähän lisäksi se, että asiaan tunkee näppejään eri tahojen puolelta porukkaa joilla on vaihteleva osaaminen ja kokemus ohjelmistokehitysprojekteista. Yleensä suurempi kokemus on sillä taholla joka myy ja koodaa softaa kuin ostavalla puolella ja tuo lisää riskiä että ostaja tulee tilanneeksi jotain mihin ei tule olemaan tyytyväinen.

Sitten vielä joidenkin projektien historialliset vaatimukset. Esim. firmassa on joku ikivanha järjestelmä jonka tuottama tieto pitäisi sovittaa tai viedä uuteen järjestelmään, tai useampiakin. Tämä lisää homman monimutkaisuutta kun saa olla hakemassa että mikä noista monista systeemeistä ei nyt sitten toimi kuten kuviteltiin jos tulee ongelmia.

Eli jos et tykkää stressistä ja mahdottomista ongelmista niin pysy kaukana ohjelmistoprojektialalta. 

Järjestelmäkehitys on työnä kuin siivoaminen: jos palautetta tulee, se on aina vain negatiivista. Käyttäjät eivät osaa arvioida, onko joku järjestelmä hyvä vai ei, koska monella ei ole mitään relevanttia vertailukohtaa. Eivät myöskään välttämättä omassa työssään näe sitä, miten kompleksinen järjestelmä aidosti on, eivätkä näin ollen osaa antaa positiivista palautetta siitä, kuinka kehittäjät ovat saaneet haastavan kokonaisuuden toimimaan edes jotenkin. On usein vaikea tehtävä ja usein projektiin osallistujat niska limassa yrittää tehdä järjestelmästä niin hyvän kuin mahdollista (painetaan pitkää päivää ja tehdään parhaansa).  Ja sitten joku loppukäyttäjä vaan antaa haukut päälle ilman mitään kehitysajatuksia. Kiva työyhteisö.

Muutosvastarinta ja järjestelmien pelko on aina voimakasta ja aiheuttaa usein todella voimakasta negatiivista palautetta (usein myös asiatonta sellaista, eli valitetaan, mutta valittajalla ei kuitenkaan ole tarjota mitään kehitysehdotusta, miten asia olisi paremmin). Monesti toimintatavan sopeuttaminen uuden järjestelmäprosessin mukaiseksi ei oikeasti ole niin hankalaa ja se voi olla myös toivottavaa. Johto ikään kuin järjestelmää syyttäen pakottaa ihmiset uuteen toimintatapaan, mitä muutosta ei ilman vastaavaa pakotusta saataisi ikinä läpi.

Toki koulutusta ja myös hiekkalaatikkotoimintaa saisi usein olla enemmän jo ennen käyttöönottoa (siis nk. sandbox-ympäristö, missä kaikki voivat rauhassa kokeilla järjestelmää jo ennen todellista käyttöä).

Vierailija kirjoitti:

Ne jotka ostavat noita järjestelmiä eivät usein itse käytä niitä työssään.

Eivät kysy esimerkiksi virkailijoita mitä tietoja tarvitaan löytää tai tallentaa simppelisti ja nopeasti. Kaikki järjestelmät eivät myöskään aina toimi eri kuntien välillä saatikka kansainvälisesti.

Yleensä nuo järjestelmät lobataan päättäjille ja sitten on jonkinlainen kilpailutus, tulos on yleensä huono, it- alan ihmiset ovat jo vuosia naureskelleet noille asioille. Päättäjät eivät ole perillä edes alkeellisesta tietoturvasta tai melko sudeksi jääneestä EU:n GDPR pykälistä. Ne jotka tietää, heitä ei edes kuunnella, se on ihan joku muu, kuin asiantuntemus joka puhuu.

Aina kun julkiselle on tullut toimimaton järjestelmä sen kilpailutus on suhmuroitu tai kierretty kokonaan

Ja kukaan ei joudu vastuuseen.

Voiko tuloksena olla muuta kuin sutta ja sekundaa, kun valitaan tietojärjestelmän toimittajaksi taho (esim. sarastia), joka sitten hankkii alihankkijalta jonkin valmiiksi oletetun tietojärjestelmätoteutuksen? Sarastialla ei liene niin syvällistä tietoa tietojärjestelmästä kuin alihankkijalla, ja voisi olettaa että alihankkija voi olla joissakin tilanteissa ainoa joka voi korjata esim. suorituskykyongelmia.

Jos tietotekniikkaa on käyttänyt ainoastaan itsensä kuvaamiseen, niiden kuvien muokkaamiseen ja niiden julkaisemiseen someen tykkäyksiä kalastellen niin onko mikään ihme että ei osaa käyttää

Vierailija kirjoitti:

Vierailija kirjoitti:

Miksi noita järjestelmiä ylipäätänsä pitää vaihtaa kuin sukkia?  Tehdäänkö niitä lähinnä sen vuoksi että kehittäjille olisi jotain kehitettävää ja myytävää?

Tietojärjestelmien uusimiselle on ainakin kaksi ilmeistä syytä. Vanha tietojärjestelmä muuttuu jatkuvien muutosten ja korjausten johdosta väistämättä mahdottomaksi ylläpitää järkevällä työmäärällä ja hinnalla. Lisäksi esimerkiksi lainsäädäntö tai muut syyt saattavat edellyttää sellaisia muutoksia joita ei ole järkevää tehdä 30 vuotta vanhana järjestelmään.

Toinen syy on järjestelmän hoitamien prosessien tehostaminen. Esimerkiksi Helsingin palkanlaskenta toimi vanhalla järjestelmällä niin että esihenkilöt, rehtorit, jne toimittivat palkanlaskentaan työntekijöiden palkkatiedot sähköpostilla, sen excel-liitteinä ja lippusina sekä lappusina. Palkanlaskija-armeija toimi tallentajina ja syötti nämä tiedot palkanlaskentajärjestelmään. Tuossa on turhaa kaksinkertaista työtä, mikä myös lisää virheen mahdollisuutta. Käytännössä ainakin osittain koominkertaistakin, työntekijä ilmoittaa tuntinsa esihenkilöllä, joka kokoaa ne tiimin tunneiksi ja palkanlaskenta tallentaa.

Nykyaikainen palkanlaskentajärjestelmä toimii niin että työntekijä syöttää tuntinsa järjestelmään, esihenkilö hyväksyy ne ennen palkanmaksua ja palkanlaskenta vain valvoo että kaikki on tehty ajallaan sekä potkii tarvittaessa. Lisäksi palkanlaskenta ylläpitää henkilöstötietoja, eli lisää uudet työntekijät ja tekee tarvittaessa muutokset palkanlaskennan parametristoon ja hintoihin.

Ja kuten olemme saaneet huomata, Helsingin palkanmaksu toimii uuden hienon järjestelmän ansiosta kuin junan vessa. Eli yhdeksän kertaa kymmenestä ei toimi.

Vierailija kirjoitti:

Meillä vuodenvaiheessa käyttöönotettu sote-ohjelma on varmaan ihan hyvä. Kukaan ei vaan ole missään kohtaa opettanut, miten sitä ihan KÄYTÄNNÖSSÄ käytetään. Eli yrityksen ja erehdyksen kautta tässä on taaplattu menemään.

Juuri samaa mielessäni kirosin kun kuuntelin uutisista Helsingin kaupungin palkanmaksuongelmia. Työntekijöitä ei ole koulutettu sitä käyttämään. Aina sama asia eli perehdytykseen ei satsata ollenkaan, missään yrityksessä tai laitoksessa. Jos tulee uusia ohjelmia tai uusia työntekijöitä, kukaan ei perehdytä. Haukut kyllä tulee jostain kautta jos ei heti osaa ja tee oikein, koska "kyllähän nyt jokainen oppii kerrasta ja on saanut geeneissä kaikkien ohjelmien ja työpaikkojen ohjeistukset". Itsekin sain työpaikan ja kun piti alkaa työvuoroja suunnittelemaan, esimies puhelimessa vartin verran kertoi miten ohjelma toimii. Sitten tehtiin yrityksen ja erehdyksen kautta. Käytännössä sitten alaiseni minut perehdytti, ilmaiseksi, työn lomassa. 

Sarastian ongelmat ei perehdytyksen puutteesta johdu. Uutisten mukaan palkka-ajot voi kestää päiviä.

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Järjestelmän suunnittelu on usein aika monen kompromissin summa. Meillä kyllä otetaan asiakkaan puolelta loppukäyttäjän mielipide huomioon. Valitettavasti loppukäyttäjillä ei usein ole koskaan minkäänlaista aiempaa kokemusta järjestelmäuudistuksista. On ehkä käyttänyt jotain yhtä kahta aikaisemmin, mutta usein loppukäyttäjillä ei ole hajuakaan siitä millaisen järjestelmän haluaisivat. Tilaajan puolta kiinnostaa hinta ja aikataulu, numerot yleensä.

Lopulta toteuttaja on kourallinen suunnittelijoita, joilla on kullakin oma osuutensa. Sitten näiden osioiden yhteensovittamista, testausta, kommenttikierrosta loppukäyttäjältä (joka ei vieläkään osaa sanoa yhtään mitään). Sen jälkeen järjestelmä otetaan käyttöön.

Käyttöönoton jälkeen sitten alkaa niitä soraääniä kuulua: miksi tämä ei toimi näin, miksi kukaan ei kysynyt. Mutta kun kysyttiin ja selvitttiin ja istuttiin kymmenissä ellei sadoissa palavereissa.

Kun käyttäjäpalautetta on saatu riittävästi, niin suunnitellaan sitä miten sitä saataisiin muokattua siihen suuntaan. Kaikkea ei olla osattu välttämättä ottaa etukäteen huomioon. Aina kaikki ei ole mahdollista ja usein käyttäjillä ei ole käsitystä siitä mitä mikäkin muutos vaatii. Lisäksi kun toimitus on hyväksytetty ennen käyttöönotta, muutokset maksavat tilaajalle lisää rahaa. Siinä on tilaajan sitten mietittävä paljonko lisää rahaa laitetaan näihin muutoksiin.

Näitä jälkeenpäin huutelijoita yhdistää kuitenkin aina sama asia: jälkiviisaus. Mikään ei ole helpompaa kuin arvostella valmista tuotetta. Sitten kun täytyy tehdä jotain puhtaalta pöydältä, menee näillä joka kerta sormi suuhun.

Se on hitsin hankalaa niissä suunnittelupalavereissa ottaa kantaa siihen, mitä käyttäjä ohjelmalta haluaa kun ei ole mitään hajua siitä, miltä se ohjelma sitten ihan käytännössä näyttää/miten toimii. Se on hankala vastata ennen sitä. Jos te suunnittelijat saisitte aikaan kunnon demon siitä, miten se ohjelma niillä ja näillä spekseillä siellä ruohonjuuritasolla näyttää ihan arjessa, niin tuskin soraääniäkään kuuluisi niin paljoa.

T. Lukuisat järjestelmämuutokset 20 vuoden aikana läpikäynyt niin yksityisellä kuin julkisella puolella

Juu juu, ja sitten tulee laskukin niistä 20 eri tavoilla toimivasta prototyypistä

Mitä hourit? Protoja tehdään yksi, ja sitä iteroidaan kunnes se vastaa asiakkaan toiveita ja tarpeita. Tai siis järkevässä maailmassa tehdään näin, julkisilla kun ei osata ostaa kuin vesiputousta niin saadaan aina mitä sattuu eikä protoista ole tietoakaan.

Olen julkisella puolella ja meille ollaan ostettu ketterää kehitystä eli sellaista, joka on käytännössä kovakoodattu, koska on kiire ja vanhanmallinen tapa on halpa. Mikään muutos ei mene läpi! Määrittelyssä tehdään ostajan vaatimusten mukaista, mutta sen jälkeen tuotantoon voi tulla ihan mitä tahansa, kosta toimittajan edustajat katsovat, että määrittelyissä vaaditaan asioita, joita ei kannata tehdä, ostaja haluaa varmasti jotain muuta. Niinpä meillä on proto, joka ei vastaa määrittelyjä, mutta joka on pakko ottaa käyttöön, koska ei ole aikaa korjata. Eikä haluakaan. Järjestelmänkehittäjä tekee omia päätelmiään ja termit ovat sekaisin, tulossa on pelkkiä virheitä sisältävä tuote, mutta jos huomauttaa ongelmista, saa kuulla kaiken olevan muutosvastarintaa ja vanhaan jämähtämistä.

Vanhassa vesiputousmallissa meille tehtiin se, minkä tilasimme ja halusimme, protoa ei tarvittu, koska lopputulos oli tilauksen mukainen. Nyt tuotantoon on tulossa tuote, joka ei vastaa mihinkään tarpeeseen ja jonka takia yksikköihin joudutaan jakamaan ruutupaperivihkoja asioiden tallennusta varten.

Vierailija kirjoitti:

Sarastian ongelmat ei perehdytyksen puutteesta johdu. Uutisten mukaan palkka-ajot voi kestää päiviä.

Siellä ei oivallettu, että yhden palkan maksamiseen liittyy muutakin kuin yhden loppusumman siirto paikasta A paikkaan B.

Olin töissä julkisella sektorilla ja meidän tärkein tietojärjestelmä vaihtui. Juuri noin, että pe iltapäivänä kun sulki koneen, niin piti saada kaikki työt valmiiksi vanhassa, se poistettiin kaikkien koneilta vkl aikana ja ma aamuna piti heti suoraan käyttää uutta. Ja ma päivä oli yhtä täynnä töitä kuin ennenkin eli mitään löysää aikaa opettelulle ei ollut. Saimme kyllä koulutuksen. Istuimme paria viikkoa aiemmin 20 hlön ryhmissä katsomassa tunnin luennon, jossa kouluttaja näytti miten uutta järjestelmää käytetään ja mistä eri toiminnon sieltä löytyy. Teimme kiltisti muistiinpanojakin. Eipä kyllä mitään muistanut eikä osannut silloin ma aamuna että aika shokki oli, kun ei ymmärtänyt ollenkaan miten työt piti hoitaa.