Elävä esimerkki työpaikaltani: julkisen sektorin softahankinnan (melko olennaisen sellaisen) hankintaperusteissa 70% määritteli hinta, 30% ominaisuudet. Laadusta ei puhuttu.

Voitimme kyllä tarjouskilpailun, mutta kaikki (ratkaisun myyjän päässä siis) tiestivät, että väärin perustein.Kuka olisi valmis tekemään (softan) hankintapäätöksiä vastaavilla perusteilla omaan käyttöönsä?

Julkishallinnon hankintasäännökset poistavat hankkijalta käytännössä kaiken harkintavallan. Kaikki pitää kirjata tarjouspyyntöön pisteineen, mutta kuka muistaa olla olettamatta, ja kirjata ylös että joo, konsulteilla pitää tosiaan olla vaatteet päällä ja heidän pitää olla pulssi.

Toisin sanoen et voi tehdä tarjouspyyntöä, jossa hinta ei ole merkittävä tekijä, koska satavarmasti toimittaja vedättää sitä sitten ylöspäin niin paljon kuin sielu sietää. Kaikki tämä on seurausta siitä, etteivät hankkijat saa pitää muistikirjaa siitä, että “katos joo, nämä kaverit ovat ryssineet kymmenen edellistä keikkaansa, ja yrittivät vielä kusettaa joka kerran – enpä päästä heitä edes kiinni tähän tarjoukseen.” Ilman inhimillistä joustovaraa kaikki on hyvin, hyvin kallista veronmaksajalle, ja tuskallista palveluiden käyttäjille.

Pakkoyhteishankinnat nostavat käytännössä hankintahintoja, ja pakottavat käyttämään muutamaa isoa toimijaa.

Uusi PalkkausJärjestelmä estää harkinnan julkishallinnon omien asiantuntijoiden (ja esimiesten) palkitsemisessa.

Mikä tähän ratkaisuksi? Tarkkaa ajatusta minulla ei ole, mutta harkintavaltaa on jossain muodossa pakko siirtää paikallistasolle.

Hankintasäännökset ovat tosiaan syvältä. Teknisen rautatavaran hankinnoissa olen useinkin törmännyt tilanteisiin jossa “kokonaisedullinen” hankintasopimus on pakottanut maksamaan 20 – 30% suuremman hinnan, täsmälleen samasta laitteesta. Tämä ärsyttää todella, etenkin kun “sopimusten” ulkopuolisissa hankinnoissa määräävänä perusteena on aina tuotteen hinta.

Hankintamenettelyn jäykkyys ja prosessin hitaus on myös usein tullut veronmaksajille kalliiksi. Kun pienehkökin hankinta, valmistelusta, lopullisen hankintapäätöksen tekoon saattaa viedä kuukausia, ei ole mitään mahdollisuutta käyttää esimerkiksi toimittajien lyhytaikaisia tarjouskampanjoita hyväksi.

Nämä pari toimijaa ovat jostain syystä onnistuneet luomaan itsestään katu-uskottavan kuvan, vaikka heidän tuottamat järjestelmät ovat kategorisesti kuraa. Olen vuosia ihmetellyt miten tällaiset yritykset voivat jatkaa aina vain uusissa hankkeissa ja kuinka aina samat ja uudet uhrit vain toistavat virheitään.

Käyttäjien kritiikki menee kuuroille korville, koska hankinnat tehnyt johtoporras ei halua myöntää virheitään, toimittajasta nyt puhumattakaan. Näimpä käyttäjät jäävät yksin ongelmiensa kanssa.

Nyt kun pientä natinaa liitoksista on alkanut näkymään, niin ehkä tuollaisen 5 vuoden kuluessa meidän katu-uskottavat ™ toimittajat eivät ole enää katu-uskottavia?

Olen huomannut eräässä alakoulussa, ammattikorkeakoulussa ja teknillisessä yliopistossa saman kaksivaiheisuuden:
1) Hankitaan halpa, vaatimukset täyttävä portaali. Ajan mittaan huomataan sen olevan buginen tai käytettävyydeltään surkea.

2) Myönnetään virhe ja siirrytään järjestelmään, mikä toimii muuallakin kuin paperilla.

Loppujen lopuksi on jouduttu maksamaan tuplasti verrattuna siihen, jos olisi heti hankittu kunnon järjestelmä.

Minä ottaisin hieman toisenlaisen näkökannan näihin valtion rahoittamiin projekteihin, mitä on ennen lausuttu. Milestäni valtion on ollut parempi satsata näihin tietoyhteisuktaprojekteihin sen takia, että virkamiehet oppivat mitä nämä ohjelmistoprojektit ovat virkamiehen näkökulmasta katsottuna. Että ajan kanssa virkamiesten tietoisuus paranee esim. sillä aluella, että kuka ja minkätasoinen virkamies milläkin koulutukselle pääsee määrittämään ohjelmistojen ääriviivoja.
Otetaanpa esimerkki teollisuudesta. Josko tuotekehityksessä olisi ennustettavissa, että on olemassa 10 erinlaista tapaa toteuttaa jokin tuotekehityshanke. Kun on totteutettu ja kokeilut 9 tapaa 10:stä, niin voidaanpa olla melko varmoja siitä, että tuo viimeien 1 10:stä tapa on se vihonmiineinen oikea tapa. Rahaa on palanut, mutta voisipa olla niinkin, että 9:lle väärällä tavalla toteutetulle tietämykselle löytyy markkinat.

Näin tässä vaan aavistelen.

Pahimmat nyrjähdykset toimimattomuudessa oli eri toimittajien välisissä ohjelmistojen rajapinnoissa. Olisikohan oikeasti avoimet tiedostomuodot ja protokollarajapinnat _ehkä_ voinut olla ratkaisu näinkin simppeleihin ongelmiin?

Julkisen tahon IT hankinnat ovat oikeasti järkyttävä esimerkki siitä kuinka

ostava osapuoli ei osaa tai ei pysty tekemään hyviä päätöksiä.
Vikaa on runsaasti myös toimittajissa. Olen ollut pitkään toisessa noista

“katu-uskottavissa” toimittajissa ja siellä julkishallinnon asiakkaita

lypsetään ihan helevetisti.
Julkkariasiakkaisiin laitetaan aloittelevat konsultit, tunareimmat myyjät ja

mahdottomiin lupauksiin sidotut mahdollisimman halvat toteuttajat. Näin

varmistetaan mahdollsimman suuri kate. Tämä on törkeä yleistys, joten

toivon että oikeat ammattilaiset eivät loukkaannu liikaa.
WM ja TE ovat saaneet aikoinaan tuotteensa sisään mm valtionhallintoon

ja nyt yli-ikäisillä ja surkeilla tuotteilla sidotaan asiakkaat maksamaan

näennäispalvelusta vain siksi että saataisiin laskutusaste näyttämään

mahdollisimman hyvältä.Sellaisista projekteista joista ketterä toimittaja veloittaisi muutaman päivän hinnan, nämä isot vakuuttavat että asiakkaan tarpeet vaativat satojen päivin konsulttiveloitukset + toteutus päälle.
Ostajan puolelle annan sapiskaa siitä että rohkeita linjanvetoja ei

uskalleta tehdä. Laki julkisista hankinnoista on tehty paperikoneen tai

lyijynkynien ostamista varten; kompleksisen tietojärjestelmän hankintaan

se ei sovellu.
Ostajat määrittelevät hankintaperusteeksi hinnan jopa 50 – 70 % tasolle. Loppu jakaantuu myyjän “toimituskyvyn”, ominaisuuksien ja mahdollisesti refesenssien kesken. Kukaan ei vaadi laatua, sehän vaatisi jo paneutumista asiaan. Tuo toimituskyky on somasti peitelty ilmaus sille että voidaan valita vain se toinen niistä kahdesta. Muuta ei uskalleta päättää. Kun ostat nimekkäältä toimittajalta niin oma jakkara ei heilu vaikka toimittaja ryssii. Ongelmat voi kaataa sen toimittajan niskaan. Mutta jos valitset sen pienemmän toimittajan niin aina voidaan syyttää Sinua kun menit valitsemaan tuon pienen ja tuntemattoman tunarin. Näin varmistetaan se että mikään ei kovin helposti muutu tai uusiudu.
Viestini julkishallinnolle onkin seuraava: maksakaa kunnon liksaa asiantunteville ostajille – vaikka 50 tonnia kuussa – sekin on halvempaa kuin maksaa huonosta palvelusta ylimielisille toimittajille. P-kle – vaatikaa meilta toimittajilta laatua ja osaamista! Nykyinen meno tulee veronmaksajille liian kalliiksi.
Olen nähnyt aivan liikaa esimerkkejä siitä kuinka loppukäyttäjät saavat aivan vääränlaisen tuotteen tai palvelun riesakseen vain siksi että ostajat eivät paneudu asiaan ja ahneet myyjät käyttävät sitä hyväkseen.

Scrummista voisi ehkä olla apua noissa projekteissa. Lyhyesti kerrottuna Scrum toimii näin:
Ostaja ja toimittaja laativat yhdessä listan ominaisuuksista mitä on tarkoitus toteuttaa ja asettavat ne tärkeysjärjestykseen. Toimittaja auttaa listan laatimisissa siten, että ominaisuudet ovat koodaajien ymmärrettävissä ja riittävän pieniä osakokonaisuuksia.

Tämän jälkeen toimittajan koodarit valitsevat listan yläpäästä muutamia ominaisuuksia, mitkä he ajattelevat saavansa kuukaudessa tehtyä ja sitten he lähtevätkin samantien toteuttamaan niitä.

Tässä voi olla hyvä käyttää myös XP:tä, mikä on eräs agilen tyyli, hyväkseen. Eli tehdään kaikelle ensin unit-testi ja vasta sen jälkeen kirjoitetaan koodi joka saa testin menemään läpi. Näin varmistetaan nyt ja jatkossa, että toteutetut funktiot ja ominaisuudet toimivat ja että ne toimivat myös kun jatkossa tehdään muutoksia.

Kuukauden päästä toimittajalla pitäisi olla valitut ominaisuudet jo toteutettuna ja niitä voidaan esitellä ostajalle. Ostaja voi näkemänsä perusteella priorisoida vanhoja ominaisuuksia, poistaa vanhoja tai lisätä uusia ominaisuuksia. Sen jälkeen koodaajat valitsevat taas sen mitä arvelevat pystyvänsä tekemään ja tekevät taas kuukauden ajan projektia eteenpäin.

Tämä oli lyhyt kuvaus, mutta etuina tästä olisi:
- Jos jokin ominaisuus kerran toimii, se ei koskaan hajoa, koska automaattiset testit ajetaan jatkuvasti uudelleen läpi. Tämä parantaa laatua.
- Asiakas näkee välittömästi mitä on saamassa, eikä siksi tule yllätyksiä asiakkaalle.
- Koodaajat voivat keskittyä rauhassa tekemään töitään, koska heitä ei saa kuukauden aikana häiritä. Jos asiakas keksii kesken kuukautta uusia ominaisuuksia, ne lisätään listalle, mutta koodaajat pohtivat listaa vasta kuukauden lopuksi. Tämäkin parantaa laatua ja lisäksi on työntekijöille miellyttävämpää.
- Tärkeimmät ominaisuudet toteutetaan ensimmäiseksi, joten jos budjetti uhkaa karata käsistä, jäävät vain turhimmat ominaisuudet pois.
- Asiakas voi helposti seurata projektin etenemistä ja rahan kulumista kuukausittain. Ei tule suuria yllätyksiä.
- Jos lisäksi asiakas ostaa projektin avoimen lähdekoodin projektina, voi asiakas vaihtaa toimittajaa kesken projektin, jos eteneminen ei toimi asiakkaan toivomalla vauhdilla. Asiakas voi myös tällöin hyödyntää ulkopuolista konsulttia, joka voi arvioida toimittajan tekemän koodin laatua (esim. ovatko unit-testit riittävän kattavia).

Vielä yksi näkökulma:
Julkiset hankintasäännöt ovat aika hankalia ja osin epätarkoituksenmukaisia. Johtuu taustalla olevasta EU-direktiivistä.
Hinnan ylikorostuminen tarjousvertailussa ei kuitenkaan johdu yksistään hankintalaista, vaan siitä että sitä ei osata käyttää virastoissa. Laki ei estä toimittajan valitsemista laatuperusteilla. Omalla toimialallani on esimerkiksi tavallista, että kaikkien projekteissa mukana olevien konsulttien CV:t referensseineen pitää toimittaa tarjouksen mukana ja iso osa vertailupisteistä tulee tästä. On myös luvallista käyttää monivaiheisia hankintaprosesseja, joissa ensimmäisten neuvottelujen tai suunnitelmien perusteella valitaan ne toimittajat, joilla tilaaja arvioi olevan parhaat edellytykset suoriutua projektista. Heiltä pyydetään viralliset tarjoukset ja muut eivät pääse edes ilmoittamaan hintaansa.

Järkevissä virastoissa on erillisiä hankinta-ammattilaisia, jotka ovat kouluttautuneet kursseilla nimenomaan julkisten hankintojen hoitamiseen. He tietävät kyllä, miten tarjousmenettely pitää hoitaa, että paras tarjoaja voittaa. Valitettavan usein IT-hankintoja hoitaa kuitenkin yksinään joku IT- tai muun alan asiantuntija, jolla ei ole erityisosaamista julkisista hankinnoista (yksityissektorilla saatu kokemus ei riitä, koska lainsäädäntö on ihan eri) ja he eivät aina tiedä, miten tarjousten laadullisia seikkoja voisi arvioida. Taustalla väijyy myös pelko joutua markkinaoikeuteen, jonne hanke voi jumiutua kuukausimääriksi, jos tarjousvertailussa tekee jonkin muotovirheen.

Avoin lähdekoodi toisi järkeä suomen kuin muidenkin maiden virastojen ohjelmistohankitoihin. Perustettaisiin vaikka Euroopan Unionin tukema avoimen lähdekoodin hanke, jolla tehtäisiin sovelluksia eri tarpeisiin. Kaikki järjestelmätoimittajat joutuisivat tekemään yhteensopivia sovelluksia. Ennenkaikkea järjestelmän toimittajaa voisi aina vaihtaa, jos ei oltaisi tyytyväisiä sen toimintaan. Avoimen lähdekoodin järjestelmät antaisivat myös pienille yrityksille mahdollisuuden tehdä asioita suuriin hankkeisiin. Tuo TE:n ja WM-datan sekoilu, jossa oli tuhlattu iso tukku rahaa turhiin määritelmiin ilman mitään konkreettista tulosta on pahin esimerkki mitä suljettu koodi pahimmillaan tekee. Jos tuo 25 miljoonaa nyt tuhlattua rahaa oltaisiin panostettu avoimen lähdekoodin hankeeseen, niin kaikki aikaansaatu tulos voitaisiin ottaa nyt käyttöön. Nyt kun rahaa on lapiolla laitettu TE:n ja entisen WM-data holveihin ollaan ainoastaan sitouduttu yhteen järjestelmätoimittajaan. Virastot elävät täysin järjestelmätoimittajan ehdoilla.

Muutenkin kannatan ehdottomasti Suomen kouluihin ja virastoihin avointa lähdekoodia. Ei ole mitään järkeä kärrätä rahaa meren taakse, kun saataisiin kustannussäästöjä ja työpaikkoja Suomeen.

http://teknoetlogia.blogspot.com/2008/01/linux-tuo-jrke-suomalaisten-virastojen.html

Jos kukaan ei vaadi laatua, laatu kärsii aikataulupaineiden vuoksi. Jos taas laatua vaaditaan, niin kustannukset nousevat. Silti pyritään yleensä juurikin kilpailuttamaan, että kuka tekee halvimmalla, ja sitten tuleekin ongelmia.

Lisäksi usein asiakkaat haluavat jotain pieniä muutoksia tai pieniä lisäpiirteitä eivätkä juuri halua, että niistä tehdään tarkkoja määrityksiä, koska pienet jutut pitäisi pystyä tekemään tuosta vain. Tällöin kuitenkin ajan mittaan niitä pieniä asioita kertyy isot kasat ja kokonaisuuden hahmottaminen alkaa kärsiä kaikilla osapuolilla. Määrittelystä ja määrittelemisestä tulisi siis pitää kiinni.

Jossain vaiheessa päätetään rakentaa järjestelmä kokonaan uusiksi, mutta kukaan ei edelleenkään hahmota kokonaisuutta, jos määrityksiä ei juuri ole. Tai sitten ihmiset kuvittelevat hahmottavansa, mutta yksityiskohdat ovat hukassa taikka ristiriitaisia. Puutteista seuraa myöhemmin lisäkustannuksia.

Ohjelmistoprojektit ovat usein kertaluonteisia toimituksia. Esimerkiksi tekstinkäsittelyohjelmaa käyttävät lähes kaikki, joten jos siinä on ongelmia, ne osataan korjata äkkiä. Eikä tekstinkäsittelyohjelma ole kovinkaan monimutkainen. Mutta sitten kun aletaan puhua yhdelle asiakkaalle rakennettavasta järjestelmästä, niin tulee eteen se tosiasia, että myös tekstinkäsittelyohjelma on ollut joskus versio 1.0 lastentauteineen ja synnytystuskineen. Puhumattakaan sitten siitä, että ovathan monimutkaiset liiketoiminnan kiemurat paljon vaikeampia toteuttaa järjestelmään kuin pelkkä tekstinkäsittelyohjelman toteutus.

Toisin sanoen järjestelmäprojekteissa tulisi panostaa laatuun, määrittelyyn ja dokumentointiin paljon enemmän kuin pienissä ohjelmistoprojekteissa.

Koskapa ongelmaksi on havaittu tarpeettomat liikesalaisuudet eli tiedot, joita asikas ei ole saanut omasta järjestelmästään, pitäisi säätää laki, joka kieltää viranomaista hankkimasta räätälöityjä sovelluksia ilman lähdekoodia.

Jenkeissäkin kun valtio vaatii lain nojalla tiettyjä menettelyjä esim. kopiosuojajärjestlemiä ei saa olla valtion hankkimassa ohjelmassa, niin toimittajilta tulee hyvin pian säädöksiin sopivia ohjelmistoja.

Suomessahan on jo taho joka kilpailuttaa yleiset hankinnat: Hansel

Hieman sivusta seuranneena tarjoukset voidaan tehdä niin että “haluttu” toimittaja voittaa. Ja kohtuullisen usein niin myös tehdään.

Toisaalta Hanselilla ei ole mitään legioonaa hoitamassa esim. pelkästään IT puolen tarjouksia, he vastaavat siitä että tarjoukset on tehty lain mukaisesti (vaikka eivät aina olekaan).

edelliseen korjauksena: tarjous -> tarjouspyyntö

Luinpa huviksein tuon tarkastusraportin. Vaikka tietojärestelmätoimittajille ei puhtaita pyyhkeitä voi antaa, ovat jo LÄHTÖKOHDAT useissa hankkeissa olleet ihan pyllyllään.

Katsokaapa asiatietoa sivulta 24 alkaen:

Hankkeen ensimmäisessä vaiheessa alueprojektiin osallistuneet henkilöt
koulutettiin prosessien määrittelyyn. Koulutuksen toteutti kilpailutuksen
perusteella HAUS kehittämiskeskus Oy, jonka valintaa JUPA-hankkeen
johtoryhmä perusteli kokouksessaan kokonaistaloudellisella edullisuudella,
sisällön hyvällä suunnittelulla sekä innostuneilla ja kokeneilla kouluttajilla.
Tarkastuksen yhteydessä ei kuitenkaan tarkemmin selvinnyt, miten
hanke suoritti arviointinsa mainituilla perusteilla. Tarkastushavaintojen
perusteella koulutus koettiin pääosin teoreettisena prosessijohtamisen ja
mallinnuksen yleisesityksenä.

Tarkempi ensimmäisen vaiheen palveluprosessien valinta ja siihen liittyvä
määrittelytyö rajattiin tarkastuksen ulkopuolelle.

Tarkastuksessa saadun käsityksen mukaan ensimmäisen vaiheen prosessien määrittelytyön tuloksien yksilöity käyttötarkoitus hankkeen toisessavaiheessa jäi avoimeksi, eikä hankkeen tuloksia voida kuin osin peilata
laadittuihin prosessikuvauksiin nähden. Myöskään valitun kaksivaiheisen
etenemismallin tarkoituksenmukaisen toteuttamisen perusteluja ei tarkastuksessa
pystytty selvittämään tarkastusvirastolle toimitetun aineiston ja
haastattelujen perusteella.

Ensimmäisessä vaiheessa hankkeeseen etsittiin
sekalaisin keinoin halukkaita organisaatioita. Kuitenkaan osallistuminen
ensimmäiseen vaiheeseen ei tarkoittanut automaattisesti sitä, että prosessien
kehittämiseen osallistunut organisaatio olisi päässyt mukaan toiseen
vaiheeseen osallistumaan palvelujen määrittelyyn ja rakentamiseen.

Toiseen
vaiheeseen osallistuminen edellytti hakemusmenettelyä, jolloin
hankkeen ensimmäisen ja toisen vaiheen välillä ei ollut suoraa jatkumoa.
Tarkastuksessa tehdyn arvion mukaan valittu etenemismalli oli kankea
ja se hidasti hankkeen etenemistä sekä johti myöhemmässä vaiheessa
hankkeen irrallisuuteen suhteessa aikaisemmin tehtyyn prosessien määrittelytyöhön.

Ensimmäisessä vaiheessa ei kiinnitetty huomiota palvelupro
sessien toteuttamisen realistisuuteen suhteessa taloudellisiin ja henkilöstöresursseihin
eikä eri osapuolten sitouttamiseen palveluprosessien toteuttamiseen.
Ongelma konkretisoitui hankkeen aikana muun muassa siten, että
JUPA-hanke sitoutui 20.3.2006 tehdyllä sopimuksella maksamaan Kansaneläkelaitokselle
nk. kynnysrahan, jotta se suostui priorisoimaan eläkkeensaajan
asumistukea ja eläkkeensaajan hoitotukea koskevien hakemuslomakkeiden
sähköistämisen omissa suunnitelmissaan.

Tarkastuksen mukaan JUPA-hankkeella ei ollut selkeää yksilöityä ja
konkreettista tavoitetta eikä realistista etenemissuunnitelmaa prosessien
määrittämisvaiheessa vuonna 2004 eikä myöhemmin alueprojektien toiminnallisia
tavoitteita määriteltäessä vuonna 2005.

Alueprojektien tehtäviksi määriteltiin myös palveluita, joiden toteuttaminen ei kuulunut alueprojektista vastaaville toimijoille. Esimerkiksi Oulun kuluttajaneuvonnan verkkopalvelun toiminnallisuuksiin määriteltiin kuluttajavalituksen tekeminen
silloiselle Kuluttajavalituslautakunnalle. Tarkastuksessa saatujen
tietojen mukaan Kuluttajavalituslautakunta ei kuitenkaan ollut mukana
hankkeen määrittelytyössä lainkaan.

—

Jos lähtökohdat ovat tällaiset, niin ei ole kyllä mikään ihme, että IT-projekti epäonnistuu.

Luinpa samaan syssyyn sitten koko tarkastuskertomuksen. Talouselämä on missannut jutussaan aika merkkittävän pointin: koko tietoyhteiskuntahankkeen ORGANISOINTI on ollut ihan poskellaan.

Lyhyesti vaikuttaa siltä, että keskushallinto on jakanut rahaa pieninä annoksina sinne sun tänne (erityisesti pieniin maakuntaprojekteihin). Tavoitteet ovat olleet korkealla (ja hyvin abstaktilla tasolla), mutta toteutustyö on ollut tyypillisesti parinsadan tonnin luokkaa. Ja kun tavoitteena on ollut tehdä strategisesti merkittäviä kehityshankkeita, ei ole kyllä mikään ihme että tulokset jäävät laihoiksi. Mersua ei saa mossen hinnalla.

Keskushallinnolla ei näemmä ole ollut mitään vastuuta toteutusten onnistumisesta. Keskusta on toiminut lähinnä rahanjakoautomaattina, joka on syytänyt fyrkkaa vähän sinne minne kulloinkin on huvittanut. Useat päällekkäiset projektit (kuten esimerkiksi ne kymmenkunta Lapin alueportaalia) ovat puhdasta rahojen haaskuuta.

Erityisen huvittavana pidän sitä, että keskushallinnon organisaatio on lopetettu kaksi vuotta ennen kuin alueiden keskushallinnon rahoilla käynnistämät projektit on saatu edes pilottivaiheeseen.

Ja on kyllä aluetasollakin osattu. Hankerahoja on käytetty jatkuvien toimintojen rahoittamiseen ja osa hankkeista on pilkottu teennäisesti useaan eri hankkeeseen, jotta oltaisiin mahduttu budjettiraamien sisään. Rahaa on poltettu opinnäytetöihin ja jopa psykologian perusopintoihin. Ei siis mikään ihme, että raportissa edellytetään takaisinperintätoimenpiteitä ja virkavastuusyytteiden nostamista.