Taannoinen kirjoitukseni sairaaloiden tietojärjestelmistä sai jonkin verran huomiota, ja myös Hesari innostui aiheesta eilen kirjoittamaan. Eniten huomiota on saanut Accenturen toiminta ja sen moraaliset aspektit. Se on lopulta kuitenkin vain sivujuonne. Oikea ongelma on siinä, miten tietojärjestelmiä ostetaan, ei siinä miten niitä myydään.
Tilanne ei juuri muuttuisi, vaikka järjestelmäksi valittaisiinkin Cerner ja toimittajaksi Logica, tai vaikka Effica ja Tieto. HUS on joka tapauksessa ostamassa yhtä järjestelmää yhdeltä toimijalta, joka samainen toimija tulee sitten toimittamaan myös järjestelmän kustomoinnit, uudet versiot ja tulevaisuudessa tarvittavat lisätoiminnallisuudet. Koska on vain yksi toimittaja, joka voi ne toimittaa.
Tätä kutsutaan toimittajaloukuksi (engl. vendor lock-in). Se tarkoittaa tilannetta, johon varomaton tietojärjestelmän ostaja joutuu valittuaan järjestelmälle toimittajan: kaikki muutostyöt on pakko ostaa samalta toimittajalta, ja tämä voi rahastaa niillä lähes miten haluaa. Myös huono laatu ja hitaus ongelmien korjaamisessa kulkevat yleensä käsi kädessä toimittajaloukon kanssa.
Alalla vuosikymmeniä toiminuttu myyjää lainatakseni, ”Suomessa on haluttu rakentaa järjestelmä, jossa tuotteet myydään halvalla ja raha tehdään ylläpidolla sekä muutostöillä”. Toimittajan vaihtaminen ei siis ratkaise ongelmia.
Koska koen tietynlaista vastuuta myös ratkaista esiin nostamani ongelmat, esittelen tässä kolme tapaa, jolla HUS voisi yhden toimittajan loukun välttää.
Lähtökohta on, että tietojärjestelmä ei koskaan ole valmis tuote. Sitä ei voi ostaa valmiina ja ”vain käyttää”, vaan käyttöönotto on raskas prosessi, jossa sekä muutetaan järjestelmää että muutetaan organisaation toimintatapoja. Ja käyttöönoton jälkeen muutostarpeet jatkuvat. Unohtuneita tarpeita huomataan, ja uusia syntyy.
Mutta tässä ne kolme optiota HUS:lle
Optio 1) sorsat käteen
Mikäli HUSilla olisi pääsy ja käyttöoikeus ostamansa järjestelmän lähdekoodiin, voisi sairaanhoitopiiri teettää haluamansa muutokset kenellä haluaa, tai vaikka tehdä ne omassa IT-organisaatiossa. Tällöin muutostyöt eivät olisi yhtä hitaita ja kalliita, koska niitä tilattaessa vallitsisi ainakin jossain määrin aito kilpailutilanne.
Toki järjestelmän alkuperäisellä tekijällä (ja muilla sen kanssa työskennelleillä) olisi etulyöntiasema, mutta se olisi merkittävästi nykytilannetta pienempi. Toimittajan vaihtamisen kustannus ei olisi satoja miljoonia, vaan ehkä vain satoja tuhansia, joten mahdollisuudet rahastamiseen tai slarvaamiseen olisivat selvästi pienemmät.
Tämä on se ratkaisu, jota aiemmassa kirjoituksessani ehdotin. Käytännössä tämä vaatisi yhtä lisäehtoa tietojärjestelmän kilpailutukseen: ”Osana kauppaa ostaja haluaa järjestelmän koko lähdekoodin, tarvittavat ohjeet ja koulutuksen sen käyttöön sekä oikeuden tehdä itse tai teettää muutostöitä vapaasti haluamallaan toimittajalla.” Juridisesti sitovana ehto olisi varmasti paljon pidempi, mutta olennainen sisältö on tuossa.
On epävarmaa, suostuisivatko ulkomaiset toimijat kuten Epic tai Cerner tällaiseen ehtoon. Voi olla, että eivät. Kotimaiset toimijat luultavasti suostuisivat: jos kukaan ei heiltä enää ostaisi tietojärjestelmää kuin sikaa säkissä, joutuisivat he myymään sitä sisuskaluineen kaikkineen. Palkinto on liian suuri, jotta Tieto tai Logica heittäisi pyyhkeen kehään.
Optio 2) open source
Toinen vaihtoehto on avoin lähdekoodi. HUS voisi vaatia ehtona, että ostettavan järjestelmän koko lähdekoodi julkaistaan avoimella lisenssillä. Tämä poikkeaa ensimmäisestä vaihtoehdosta siinä, että myös muut kuin HUS pääsisivät käyttämään koodia. Eniten hyötyisivät muut sairaanhoitopiirit, jotka saisivat HUSin järjestelmän käyttöönsä ilmaiseksi, mutta myös HUS hyötyisi, koska avoimuus tehostaa kehitystyötä monin tavoin. Sitä paitsi HUS saisi sitten muiden muutostyöt myös itselleen käyttöön.
Kehityksen lähtökohtana voisi toimia jokin nykyinen potilastietojärjestelmä, valmis avoimen lähdekoodin järjestelmä, kuten USA:n veteraaniterveydenhuollon VistA, tai se voitaisiin kasata tyhjältä pöydältä. Yksikään ratkaisu ei ole ongelmaton. Nykyiset järjestelmät ovat juuri niitä, joita kovasti kritisoidaan, eikä toimittajien halukkuudesta avata koodinsa ole mitään varmuutta. VistA taas sisältää samaa arkaaista MUMPS-kieltä kuin EPICkin eikä amerikkalaisena välttämättä sovellu suoraan Suomen terveydenhuolto-organisaatioon. Ja tyhjältä pöydältä kehittäminen on aina työlästä ja osin riskaapelia.
Optio 3) pilkonta, rajapinnat ja vahva yhteistyö
Tanskassa terveydenhuoltoalan tietojärjestelmät ostetaan pienehköissä osissa: yksi järjestelmä kerrallaan. Eri sairaanhoitopiirit ostavat kuka mistäkin. Alan toimijat – niin yritykset kuin viranomaisetkin – määrittelevät yhteistyössä rajapinnat ja tiedonsiirtostandardit, joita noudattaen järjestelmät toimivat sulavasti yhteen. Kokonaisuutena Tanskassa on ”ekosysteemi” terveydenhuoltoalan tietotekniikkaa tekeviä yrityksiä.
Paperilla järjestelmä kuulostaa melko samantapaiselta kuin Suomessakin. Erona on, että Tanskassa se toimii, kun suomalainen terveydenhuollon IT on katastrofi. Juutit siis ilmeisesti tekevät jotain oikein.
Jari Forsström et al kuvaavat raportissa ”Terveydenhuollon tietojärjestelmät ja Suomi” miten Tanskan ja Ruotsin vastaavat alat toimivat, sekä esittävät näkökantoja siitä, miten potilastietojärjestelmien uudistusta tulisi Suomessa tehdä. Heidän keskeinen johtopäätöksensä on:
- Terveydenhuollon kokonaisjärjestelmään sisältyy suuria riskejä.
- Hajautetuista ratkaisuista, ohjelmistojen ekosysteemistä, on pohjoismaista hyviä kokemuksia.
- Terveydenhuollon tietojärjestelmäkustannuksista noin puolet koostuu henkilötyöstä, joten toimialalla on merkittävä työllistävä vaikutus. Suomalaisen IT-osaamisen taso on korkea ja sitä tulisi voida hyödyntää näin mittavassa kansallisessa hankkeessa.
Käytännössä Suomessa Terveyden- ja hyvinvoinnin laitoksen (THL) pitäisi ottaa vetovastuu ja johtava rooli sairaanhoidon tietojärjestelmäekosysteemin kehittämisestä. Samaan tapaan kuin Tanskan Medcomilla on. THL tosin on taustaltaan tutkimusorganisaatio, eikä muutos ohjaavaksi viranomaiseksi varmasti olisi sille ihan helppo.
Hajautetummassa kehityksessäkin on riskinsä. Jos halua yhteentoimivuuteen ei ole, ei sitä myöskään synny. Standardit voidaan määritellä paitsi hyvin, myös huonosti. Järjestelmiä hankittaessa pitää myös oikeasti ymmärtää, mitä ollaan hankkimassa ja miten se suhtautuu muihin jo hankittuihin järjestelmiin. Tanskassa on saatu aikaan koko alaa koskeva yhteinen henki ja halu tehdä yhdessä järjestelmistä hyviä. Suomesta tämä toistaiseksi puuttuu.
 |
| Perinteinen ja moderni terveydenhuollon tietojärjestelmän arkkitehtuuri Forsströmin et. al mukaan. Suomessa käytössä olevat ja Sirius-hankkeessa ehdotetut uudet järjestelmät perustuvat vanhaan monoliittiseen arkkitehtuuriin. |
Johtopäätökset
Kaikille kolmelle vaihtoehdolle on yhteistä, että ostaja joutuu tekemään selvästi nykyistä enemmän ja parempaa työtä. Tilaajan puolelle pöytää tarvitaan nykyistä enemmän ammattitaitoa sekä sairaalan hallinnoinnista että erityisesti nykyaikaisesta tietojärjestelmien kehittämisestä.
Tietojärjestelmät muodostavat nykyään organisaation kuin organisaation toiminnan ytimen. Ne ovat se luuranko, jonka varassa organisaatiot liikkuvat. Jos ei tietojärjestelmää soviteta organisaation toimintatapaan, täytyy toimintatavat sovittaa järjestelmään.
On vaarallista fantasiaa kuvitella, että tällaisen ydintoiminnon voisi ostaa valmiina ulkoa ymmärtämättä sen toimintaa itse. Ajatus ulkomaisesta potilastietojärjestelmästä, joka ”vaan toimii” on hopealuoti: fiktiivinen ratkaisu kaikkiin ongelmiin. Se on käärmeöljyä, ei lääketiedettä.
Ihmepillereitä ei ole, vaan terveys perustuu elämäntapoihin; samaan tapaan potilastietojärjestelmän toiminta perustuu organisaation toimintatapoihin. Mikään ratkaisu, jossa ei muuteta sairaanhoitopiirien tapaa ostaa ja tuottaa tietojärjestelmiä, ei tule ratkaisemaan ongelmia.
Kaikki kolme ehdotusta sisältävät myös ongelmia ja riskejä. Yksikään niistä ei ratkaise terveydenhuoltoalan nykyisiä ongelmia mitenkään itsestäänselvästi. Siksi paras mitä osaan suositella on, että jokaista näistä vaihtoehdoista – ja muitakin – tutkitaan tosissaan, ja etsitään paras mahdollinen tapa välttää toimittajaloukku.
Sillä jos jokin on varmaa, niin se, että perinteisenä könttäkauppana ei Suomessa tulla koskaan ostamaan onnistunutta potilastietojärjestelmää. Epäonnistuminen on prosessin sisäänrakennettu ominaisuus.
Tietojärjestelmistä päättää viime kädessä HUSin hallitus. En kehota häiritsemään kenenkään kesälomaa, mutta meillä, jotka ymmärrämme tietojärjestelmiä on vastuu, että he tietävät mistä ovat päättämässä.
Edistääkseni asiaa loin adressin, jonka toivon lukijoiden allekirjoittavan. Siinä vaaditaan HUSin hallitusta selvittämään mahdollisuudet välttää toimittajaloukku. Mitään yksittäistä nimenomaista ratkaisutapaa ei vaadita, ainoastaan katastrofaalisen virheen välttämistä. Addressi toimitetaan alkusyksystä HUSin hallitukselle.
Keskustelualustaksi loin myös Facebook-ryhmän Terveydenhuollon IT korjattava. Liittykää sinnekin, ketkä FB:tä harrastatte ja haluatte aihetta seurata.
Kolmantena tapana vaikuttaa ovat vaalit. Kysykää ehdokkailta, mitä he aikovat tehdä, jotta terveydenhuollon IT-järjestelmien katastrofi saadaan tulevina vuosina korjattua. Erityisesti kysykää tätä sairaanhoitopiirien hallituksissa istuvilta.
Ensimmäinen otsikosta mieleeni tullut ajatus oli, että miten vältetään journalististen toimittajien loukut. 🙂
mut jos noi systeemit toimii Tanskassa ja Ruotsissa hyvin ja ne on hajautettuja, niin eiks niitä vois käyttää aika paljon hyväks meidän potilastietojärjestelmässä. Otetaan niiden standardit ja sit muokataan niitä paloja, mitkä ei toimi meillä suoraan, ja ostetaan valmiina ne mitkä toimii?
Ainakin periaatteessa juuri näin. VOisi kuvitella, että merkittävä määrä standardeja ja osajärjestelmiä soveltuisi meille sellaisenaan tai ainakin lähes sellaisenaan. Totta kai asiaa pitäisi tutkia, ja voi olla että jotain yllättäviä ongelmiakin ilmenisi. Mutta ilman muuta tutkimisen arvoinen asia.
En tiedä, että tätä olisi Suomessa selvitetty. Oikea taho tekemään selvityksen olisi Terveyden ja hyvinvoinnin laitos (THL). Asiasta vastannee joko Tietorakenteen ja luokitukset -yksikkö tai Tietojärjestelmien kehitys ja tuki -yksikkö.
Pointtinsa tuossakin, mutta kansainvälisessä tuotteessa on se etu, että saadaan jaettua kustannusta muiden asiakkaiden kanssa eikä tule Suomeen räätälöityä järjestelmää. Kansainvälisten standardien myötä ollaan avoimilla markkinoilla integroinneissakin – Suomen kokoisessa maassa kun ei oikein markkinoita synny.
Olen toiminut viitisentoista vuotta asiantuntijana asiakaspuolen edunvalvonnassa ja yllä olevasta tulee mieleen muutama yleinen huomio IT-hankkeista:
1) Teknisesti osaamatonkin henkilö tekee pienen ohjauksen jälkeen määrittelytyötä ihan mielellään, kunhan ensin ymmärtää pääsevänsä sekä vaikuttamaan omiin tulevaisuuden työkaluihinsa että leikkivänsä jonkun toisen rahoilla. Ei haittaa jos hänelle maksetaan asianmukainen korvaus ylimääräisestä vaivasta.
2) Jos ei kiinnosta, niin ei kiinnosta. Jätä virkavuosillaan kunniajäsenyyden kaikkeen saaneet eläkkeen odottelijat pois projektiorganisaatiosta, jos heillä ei erikseen ole projektille annettavaa. Projektin aikana he eivät tee muuta kuin valittavat sen menettelytavoista ja jälkikäteen he eivät missään tapauksessa tule tekemään muuta kuin valittamaan projektin tuloksista.
2b) Varmista mandaattisi ja kasvata pronssiset kivekset. Valitus tulee kuulumaan taivaisiin asti ja varsinkin lähimmälle esimiehellesi.
3) Kaikki toteutusvaiheessa tai jälkikäteen huomattu maksaa kymmenkertaisesti verrattuna etukäteen suunniteltuun. Toistele tätä ad nauseaum projektin kustannusvastaaville.
3b) Ks. 2b).
4) Jos se tuntuu liian suurelta, se on liian suuri. Paloittele se hallittaviin osiin ja nakita osavastuita omille linjaorganisaatioille. Jos asia ei ole jonkun henkilökohtaisella vastuulla, se ei tule hoidetuksi. Ks. 3).
5) Ei ole olemassa liian tarkasti tehtyä rajapintamäärittelyä. On silkkaa plussaa jos rajapintamäärittelyä tekevä insinööri osaa puhua, mutta välttämätöntä se ei ole. Sen sijaan on tärkeää, että hän on luonteeltaan pedantti, eikä haittaa jos hän on savantti. Tällaiset henkilöt ovat rakentaneet koko nykyisen Internetin ja se toimii oikein hyvin.
6) Ks. 2b).
7) ”Plain is simple”, eli perinteinen Rooma rakennettava yhdessä päivässä ei vain onnistu. Tosin on mukava katsella kun sellaisia vetoja tehdään.
Anonyymi: totaalista harhaa, että kansainvälisen tuotteen hinta tulisi jaettua muiden käyttäjien kesken.
Ohjelmistobisneksessä kehitystyöhön käytetty raha on ”sunken cost”.
Tuotteen valmistuttua sitten haistellaan, että paljonko asiakkaalta on nyhdettävissä rahaa ja hinta asetetaan sen mukaan. Paljonko tuotteen kehittämiseen meni rahaa ei ole mitään tekemistä sen hinnan kanssa.
Kilpailullako ei ole mitään tekemistä hinnan kanssa?
Kilpailtuksen voittaa se, joka kirjoittaa parhaan ohjelmistokuvauksen niin että se täyttää määrittelyn, näyttää hyvältä ja todistaa soveltuvuuden – riippumatta siitä toteuttaako se lainsäädännön, soveltuuko työehtosopimuksen mukaiseen toimintaan tai onko siinä yhteensopivat tai sovitettavissa olevat rajapinnat. Hinta tuskin on ainoa merkittävä valintakriteeri. Palveluna mallissa hinnat määritellään vain määräajaksi. Sopimuskauden päättyessä ei ole sitä vaihtehtoa että kilpailuttaisi esim. laitealustatoimittajan, jos se sisältyy palveluun. Ainoa turva tässä on se, että kansalliset rajapinnat mahdollistavat järjestelmävaihdot aikaisempaa joustavammin.
HUS vastaa laittomuuksista joka tapauksessa – riippumatta siitä mitä toimittaja pystyy toimittamaan.
Jos hankkija pystyy asettamaan ”Kokonaishinnan” (joka sisältää kaiken), niin lopputulos voisi olla hankkijaa tyydyttävä. Siihen kuitenkaan tuskin edes HUS pystyy – ainakaan ulkomaisen toimijan kanssa. Kun lainsäädäntö tai työn tekeminen muuttuu niin sitten taas ollaan rahaa vaatimassa, koska projekti ei vastaa enää alkuperäistä. Samoin käy jos tärkeitä asioita unohtuu pyytää tarjouksessa.
Juuri tästä syystä toimittajaloukun välttäminen on tärkeää. Jos ensimmäisen kilpailutuksen jälkeen ollaan yhden toimittajan loukussa, ei sillä paljonko järjestelmä maksoi tai edes mitä se sisälsi ole juuri mitään väliä. Lopputulos on lähes järjestään, että muutoskustannuksia tulee paljon ja järjestelmä toimii melko kehnosti.
Etukäteen kirjoitettu täydellinen vaatimusdokumentti, joka sisältää kaikki nykyiset tarpeet kattavasti ja riittävän täsmällisesti on pelkkää utopiaa. Sellaista ei yksinkertaisesti ole isossa hankkeessa mahdollista kirjoittaa, vaan on hyväksyttävä, että osa tarpeista löydetään vasta matkan varrella tai alkuperäinen vaatimus osoittautuukin vääräksi. Ja sitäpaitsi lainsäädäntö ym. ulkoiset vaatimukset tosiaan muuttuvat.
Projektin lopputulos on aina laadultaan enintään niin hyvä kuin sen asiakas on hommansa osaava.
Liittyen kommenttiin THL:n roolista:
THL on sektoritutkimuslaitos, joilla on aina läheiset suhteet edustamiinsa toimialoihin.
Tällaisessa tilanteessa on olemassa kuitenkin toimija, jolla voi olla enemmän valtaa nimenomaan päätöksenteon tukijana: yliopisto.
Onko Suomen yliopistoissa (tai sektoritutkimuslaitoksissa?) tällä hetkellä institutionalisoitua asiantuntemusta tämän projektin sisältöön tai eri osa-alueisiin liittyen?
Institutionalisoidulla tarkoitan tässä yhteydessä nyt sitä, että siellä on esim. proffa, tutkijoita, tutkimusryhmää ja päättyneitä, käynnissä olevia ja tulevia tutkimusprojekteja sekä – parhaimmassa tapauksessa – tutkimusohjelma, joka osoittaa sitoutumisesta aiheeseen liittyvään pitkäjänteiseen ja kestävään tutkimus- ja kehitystyöhön.
Tällaiset toimijat ja niiden mukana- tai läsnäolo tuo tällaisiin hankkeisiin sellaista uskottavuutta, jota ei rahalla saa.
Mikäli näitä lähdetään etsimään, on seuraavaksi syytä ymmärtää yliopistojen kolmas tehtävä eli yhteiskunnallinen vaikuttavuus. Tämä tarkoittaa esim. sitä, että yliopiston tutkimushenkilökuntaa käytetään asiantuntijana jossain projektissa.
Mikäli siis tällaista ”institutionalisoitua asiantuntemusta” ja siihen liittyvää tietopääomaa on jossain päin Suomea olemassa, olisiko fiksua hyödyntää sitä tässä?
>> Onko Suomen yliopistoissa …tällä hetkellä institutionalisoitua asiantuntemusta tämän projektin sisältöön tai eri osa-alueisiin liittyen? < < Itä-Suomen yliopistossa Kuopiossa on Terveydenhuollon tietojärjestelmien tutkimus- ja kehittämisyksikkö: http://www.uef.fi/his/his
Siellä näyttäisi olevan toimintaa, ja jonkin verran ”kilometrejä alla”, julkaisuluettelosta päätellen toimintaa on ollut kahdeksankymmentäluvulta saakka.
(Äh, tuo suluissa oleva (tai sektoritutkimuslaitoksissa?) piti poistaa mutta se jäi tohon. Prkl.)
Totta kai Jari Forsström suosittaa mitä suosittaa, koska hänellä on taloudellinen kytkös tanskalaiseen Systematiciin, joka on mukana HUS:n kilpailussa.
Ah, tätä en tiennytkään. Kiitos lisätiedosta; olisiko tälle mahdollisesti jotain lähdettä tai yksityiskohtia?
No, tästä huolimatta Tanskan malli on ehdottomasti selvittämisen arvoinen.
Hei otso! Loistava, selkeä kirjoitus.
Lähetähän version tästä kirjoituksesta myös Hesariin: mielipideosastolle, sunnuntaidebattiin tai muuhun vastaavaan
Kyllä, ajatukseni on kirjoittaa tästä jotain itsekin Hesariin, sekä tarjota jotain myös Lääkärilehteen. Tässä vaan oli kesällä muutakin tekemistä lomailun muodossa, niin tämä vielä odottaa tekemistään…
Pohdin, että pitäisikö koittaa ennemmin vieraskynää vai sunnuntaidebattia…
Kunnolla määritellyt avoimet rajapinnat ja vahva paloittelu maustettuna mahdollisuuksien mukaan avoimella tai käyttäjän haltuun jatkokehityslisenssillä saatavalla lähdekoodilla on tosiaan monessa toimivaksi havaittu resepti.
Ongelmana tässä on mm. se, että suomalainen julkishallinto ja sitä lähellä olevat piirit ovat olleet todella surkeita rajapintojen määrittelyissä, tai määrittelyttämisissä. Ja tuollainen pilkkominen elää ja kuolee sen määrittelyn laadun mukana.
Avoimen lähdekoodin toimijoista voisi löytyä riittävää näkemystä ja kokemusta omaavia tiimejä tuota määrittelyä tekemään, mutta julkiset ostomenettelyt, ja ostajien valitettavan usein heikko ammattitaito, ja Accenturen ja muutaman muun toimijan vahvat ”hyvä veli verkostot” tekevät hyvän määrittelytyön tilaamisen todennäköisesti ”liian vaikeaksi”.
@Mika:
Kyllä julkishallinnostakin löytyy osaamista rajapintojen määrittelyyn, modularisointiin jnpp. Ongelmana tahtoo (osittain) olla se, etteivät nämä tahot ole päättämässä hankinnoista, vaan ovat ”sisäisiä teknisiä konsultteja”. Esim. talous- tai henkilöstöhallinnon järjestelmää hankittaessa viimeinen sana on talous/henkilöstöhallinnolla. Olenpa omassa työpaikassani huomannut, että erästä tietojärjestelmähanketta aloitettaessa ”omistaja” ilmoitti haluavansa että ”lähdetään vaan koodaamaan tätä, kyllä se siitä”. (Arvannette miksi kirjoitan nimettömänä – Mika taas arvannee kuka kirjoittaa 😉
Julkisella puolella on töissä paljon fiksuja ihmisiä, mm. sinä.
Vaan yleensä heidän kapasiteettiaan ei käytetä, tai se ei ainakaan näy lopputuloksessa. esimerkkeinä vaikkapa e-laskufiasko, kansalaisvarmennefiasko jne..
Johtuneeko huonosta johtamisesta, maan tavasta, vai siitä, että nämä ”suuret konsulttitalot” ovat onnistuneet ujuttamaan ”asiantuntijansa” melkolailla kaikkiin isoihin hankkeisiin niitä vesittämään.
Otso Kivekäs radio ykkösessä klo 16.05 ”Ohjelmistoarkkitehti eroaa arkkitehdista siinä, että hän piirtelee neliöitä paperille ja niiden välille viivoja. Arkkitehti piirtelee niitä julkisivuihin.”!!!!?????tä. Onko Otson ymmärrys arkkitehtuurista tätä tasoa?
Mitäs luulet?
Kunpa tätä samaa loukkua pyrittäisiin välttämään pienemmissäkin tietojärjestelmähankinnoissa esim. valtion virastoissa.
Joo, mutta pienet hankinnat tehdään johtotasolla, joko sukulaisille tai tuttaville, vaihtoehtoisesti kannattamaan jotain omaa sivubusinesta, josta tietyn toimittajan valitsemisesta on hyötyä eli esimerkiksi saa omat sovellukset ilmaiseksi tai puoleen hintaan pariksi vuodeksi.