IT-alan työpaikat

[zepi]

Omat tuntikirjanpidot ovat olleet vähän mitä sattuu.
Eräässä menneessä työpaikassa ITIL-koulutuksen käynyt dirika keksi, että pitää saada sisäinen tuntikirjanpito, että voidaan sisäisesti laskuttaa oikein. Toimi teoriassa hienosti, mutta työläiset käytännössä sitten päivän päätteeksi aina yrittivät keksiä miten sen 7,5t jakaisi eri projekteille ja jakoivat sitten sen mukaan miten heidän oletettiin käyttävän päivänsä, vaikka olisivat sammuttaneet tulipaloa projektille x. Tämä siksi, että tuli hutia (joka tuntui bonareissa), jos kuukauden kokonaissumma ei täsmännyt oletettuun.

Ainoat kerrat jolloin tuntikirjanpitoa on suunnilleen noudatettu on TEKES-projektit ja jotkin suoraan asiakkaille tehtävät pikkuprojektit, isommissa projekteissa silloisen työnantajan tavoite oli sitten saada sovittu laskutus täyteen, vaikka tunteja ei olisi tullutkaan tarpeeksi.

Ja muita huonoja kokemuksia… Näistä johtuen nyt kun itse olen manageritasossa, jossa tuntikirjanpito tukisi toimintaa olen sitä vastaan, se on ilman jatkuvaa kyttäämistä ihan turhaa aiheuttaen lisäksi narinaa koneistossa. Joskus toki sitä on vain tehtävä, mutta onneksi näitä tapauksia on vähän ja sen tarve on helppo tällöin kommunikoida tekijöille.

Tuntikirjanpito on ainakin omalta osaltani nykyisessä hommassa 100%:sesti lakisääteinen. Firman valvoo, että ihmiset eivät tee yli työaikalaissa sallittujen maksimien. Muuten kirjataan kaikki vain työajaksi, joka menee 100%:sesti oman tuotteen kuluihin.

Tuntikirjanpito olisi hyvä työkalu, mutta sen perusteella palkitseminen tai laskutus johtaa lähes väkisinkin kirjanpidon oikeellisuuden hajoamiseen. Nää on näitä jokapäiväisen elämän kvantti-ilmiöitä, pelkkä mittaaminen vaikuttaa järjestelmän käytökseen.

 

[Harb]

Aika monessa keskisuuressa IT firmassa on erillinen laskutusjärjestelmään liittyvä tuntikirjanpito ja sitten lainsäädännöllinen tuntikirjanpito. Niitä on hankala yhdistää johtuen "arvopohjaisesta laskutuksesta" ts. asiakkaalta laskutetaan useampi tunti kuin asiantuntija työhön käyttää.

Asiakaslaskutettavan työn käyttäminen bonuksen pohjana on helppoa mutta muun työn on hankalampaa.

 

[Paapaa]

Aika monessa keskisuuressa IT firmassa on erillinen laskutusjärjestelmään liittyvä tuntikirjanpito ja sitten lainsäädännöllinen tuntikirjanpito. Niitä on hankala yhdistää johtuen "arvopohjaisesta laskutuksesta" ts. asiakkaalta laskutetaan useampi tunti kuin asiantuntija työhön käyttää.

Tai sitten on yksi tuntikirjanpito, johon työtekijä merkkaa tunnit, mutta nämä menevät sitten filtterin ja mankelin läpi ennen kuin asiakas saa laskun. Riippuu varmaan firmasta ja tarpeesta. Toisissa taas on "kirjanpito", mutta siihen täytetään käytännössä automaattisesti se 7,5h/päivä. Työntekijä sitten itse pitää huolta flexeistä sun muista.

 

[PieniLäski]

Tai sitten on yksi tuntikirjanpito, johon työtekijä merkkaa tunnit, mutta nämä menevät sitten filtterin ja mankelin läpi ennen kuin asiakas saa laskun. Riippuu varmaan firmasta ja tarpeesta. Toisissa taas on "kirjanpito", mutta siihen täytetään käytännössä automaattisesti se 7,5h/päivä. Työntekijä sitten itse pitää huolta flexeistä sun muista.

Meillä on aikalailla tämä. Meillä on liukuva työaika mutta ei saldoja. Toisin sanottuna voit tulla töihin 7 ja lähteä 15. Jos taas tuut 7 ja lähet 15:30 niin se on automaattisesti ylityötä 30min. Hassua sinänsä. Itse kyllä mielelläni keräisin saldoja, mutta pienessä yrityksessä toki miehitys voi olla vähän niin ja näin jos joku on poissa.

 

[Mechanical Man]

Meillä on aikalailla tämä. Meillä on liukuva työaika mutta ei saldoja. Toisin sanottuna voit tulla töihin 7 ja lähteä 15. Jos taas tuut 7 ja lähet 15:30 niin se on automaattisesti ylityötä 30min. Hassua sinänsä. Itse kyllä mielelläni keräisin saldoja, mutta pienessä yrityksessä toki miehitys voi olla vähän niin ja näin jos joku on poissa.

Saldotkin voi sopia +-2h per päivä tms. Ja kokonaiset vapaat erikseen sopimalla.

 

[PieniLäski]

Saldotkin voi sopia +-2h per päivä tms. Ja kokonaiset vapaat erikseen sopimalla.

Niin no.. Ei meillä kukaan välitä jos oot puolen tunnin sijaan tunnin ruokatunnilla tai jos pitää käydä hoitaas asioita niin sitten pitää käydä hoitaas asioita.

Eli se tuntien kirjaus ei oo niin kovin tarkkaa, mutta ilmeisesti kokonaiset vapaat on aika vaikeita (joskin palkattomia saa kyllä pyytämällä).

 

[Randomizer]

Kuinka usein olette vaihtaneet työnantajia keskimäärin? Onko mielestänne 4v pitkä aika samassa firmassa?

 

[JCSH]

Kuinka usein olette vaihtaneet työnantajia keskimäärin? Onko mielestänne 4v pitkä aika samassa firmassa?

12 vuoden aikana on kaksi kertaa tullut vaihdettua työnantajaa, eka yritysjärjestelyjen seurauksena ja toinen koska alkoi hommat pännimään.

Ja en sanoisi että ei ole mitään nyrkkisääntöä siitä mikä on pitkä aika samassa firmassa. Tosin 4 vuotta ei kyllä ole pitkä aika. Sanoisin että voidaan ehkä argumentoida että 10 vuotta olisi pitkä aika mutta ei todellakaan 4 vuotta.

Tuntuu vähän Piilaksomaiselta höpötykseltä idea että työpaikkaa pitäisi vaihtaa tietyin väliajoin. Jos hommat on mielenkiintoisia ja niistä saa sellaista palkkaa mitä pitää hyvänä (tai vähintään riittävänä) niin miksi vaihtaa?

 

[Randomizer]

Juu, nyt on vaan niin hyvä aika vaihdella työnantajia kun palkkaa ja muita etuja saa helposti hinattua vaihtamalla. Kaikki firmat tuntuvat olevan vailla osaajia. Mun ura on kestänyt jotakin 10v ja firmoja on tullut 3 nähtyä jo, ja elokuussa olisi taas vaihto. Eipä ole haastattelijat koskaan tivanneet miksi paikat vaihtuu noin useasti.

 

[JCSH]

Juu, nyt on vaan niin hyvä aika vaihdella työnantajia kun palkkaa ja muita etuja saa helposti hinattua vaihtamalla. Kaikki firmat tuntuvat olevan vailla osaajia.

Niin kai sitä aina rahan perässä voi vaihtaa. Mutta oma asenne on että jos nykyinen duuni on mielenkiintoista, hyvät työkaverit ja ei mitään isompaa valitettavaa niin ei sitä muutaman satasen palkankorotuksen perässä kyllä jaksa lähteä vaihtaan.
Toki jos joku tarjoais vaikkapa 1k€ / kk lisää niin sitten voisi jo alkaa miettimään.

 

[Frederikin rintakarva]

Mun ura on kestänyt jotakin 10v ja firmoja on tullut 3 nähtyä jo, ja elokuussa olisi taas vaihto. Eipä ole haastattelijat koskaan tivanneet miksi paikat vaihtuu noin useasti.

Jos laskee palkkakuiteista firmojen nimiä vuosien varrelta, niin taitaa päätyä jonnekin 8 tietämille. 20 vuoden aikana tosin vasta kerran ehtinyt itse vaihtaa paikkaa. Softapuolen hommia koko ajan.

 

[pelitys]

Pian kymmenen vuotta samassa firmassa ja vaihtaisin samantien jos saisin saman liksan kauempana pk-seudusta tai yli viidensadan palkankorotuksen. Työ on kuitenkin rentoa ja saako IT-manageri monessakaan paikassa lähemmäs 60t€ vuodessa? Silloin tällöin selailen muutaman sivun IT-työilmoituksia mutta aina haetaan joko junnuja analyytikkoja tai koodaajia, ei koskaan välitason esimiehiä tai vastaavan tasoisiin tietohallinnon hallinnollisiin tehtäviin.

 

[Unihiekkamyrsky]

Toisaalta kopioitu 'välikevennys':

 

[sirace]

Toisaalta kopioitu 'välikevennys':

EI JUMA.... nappien tekstithän on aina "järjestelmä riippumattomia" ja täten täysin kustomoitava asia. EPIC on siis järjestelmä jossa napitkin on "kovakoodattu". Mitähän muuta? Toki saattoi olla ettei 1960-luvulla oltu keskitty vielä muuttujia.

Onnea vaan asiasta päättäneille tahoille...

 

[Svaiski]

Juu, nyt on vaan niin hyvä aika vaihdella työnantajia kun palkkaa ja muita etuja saa helposti hinattua vaihtamalla. Kaikki firmat tuntuvat olevan vailla osaajia. Mun ura on kestänyt jotakin 10v ja firmoja on tullut 3 nähtyä jo, ja elokuussa olisi taas vaihto. Eipä ole haastattelijat koskaan tivanneet miksi paikat vaihtuu noin useasti.

Itselläni neljäs työpaikka menossa ~10v aikana. Välissä oli yksi "kunhan jotain IT-alan hommia" -paikka jossa olin reilun vuoden, muuten olen ollut vähintään 2 vuotta samassa paikassa. Viimeisin siirtymä oli toiselta paikkakunnalta josta palattiin perhesyistä ~2,5v jälkeen takaisin. Välissä voi tiheämpäänkin vaihtaa paikkoja, kunhan niille on järkevät perusteet. Esimerkiksi tuosta paikasta jossa olin reilun vuoden, kerroin seuraavalle työnantajalle, että siellä ei ollut tarpeeksi haastetta saatikka tehtäviä enkä jaksa joka päivä pelkkää internettiä selata ajankuluksi.

 

[JCSH]

EI JUMA.... nappien tekstithän on aina "järjestelmä riippumattomia" ja täten täysin kustomoitava asia. EPIC on siis järjestelmä jossa napitkin on "kovakoodattu". Mitähän muuta? Toki saattoi olla ettei 1960-luvulla oltu keskitty vielä muuttujia.

Onnea vaan asiasta päättäneille tahoille...

En nyt oikein tiedä mitä tarkoitat "täysin kustomoitavalla". Ihan normaalia se on että UI-tekstit, etenkin jotku geneeriset nappulan tekstit, on buildattu mukaan siihen executableen. Tässä vissiin sieltä sitten Epiciltä tulee yhdet geneeriset binäärit kaikille asiakkaille jolloin tuollaisia ei pääse kustomoimaan. Eiköhän siellä Epicin sorsakoodeissa homma ole hoidettu ihan normaalisti jollain resurssifileillä missä nuo käännökset ovat.

Toki herää kysymys on että kannattaako tuollaista järjestelmää hankkia missä valtaosa järjestelmästä tulee taholta joka ei mahdollista tuollaisia asiakaskustomointeja (tai voi olla että sallisi mutta maksaisi paljon enemmän).

 

[qtba]

En nyt oikein tiedä mitä tarkoitat "täysin kustomoitavalla". Ihan normaalia se on että UI-tekstit, etenkin jotku geneeriset nappulan tekstit, on buildattu mukaan siihen executableen. Tässä vissiin sieltä sitten Epiciltä tulee yhdet geneeriset binäärit kaikille asiakkaille jolloin tuollaisia ei pääse kustomoimaan. Eiköhän siellä Epicin sorsakoodeissa homma ole hoidettu ihan normaalisti jollain resurssifileillä missä nuo käännökset ovat.

Toki herää kysymys on että kannattaako tuollaista järjestelmää hankkia missä valtaosa järjestelmästä tulee taholta joka ei mahdollista tuollaisia asiakaskustomointeja (tai voi olla että sallisi mutta maksaisi paljon enemmän).

Järjestelmän hintalappu on kuitenkin ~700 miljoonaa. Sillä luulisi saavan ihan alusta asti omiin tarpeisiin rakennetun järjestelmän...

 

[JCSH]

Järjestelmän hintalappu on kuitenkin ~700 miljoonaa. Sillä luulisi saavan ihan alusta asti omiin tarpeisiin rakennetun järjestelmän...

Niin kai sitä luulis, tosin ei ole tietoa kuinka tuo integroituu esim. olemassaoleviin laboratoriojärjestelmiin. Voi käydä todella kalliiksi jos kaikki joudutaan tekemään nollista.

 

[demas]

CGI:llä oli jokunen vuosi sitten käytäntö etätöihin ettei ma eikä pe, estettiin pitkät viikonloput.

Hienoa en ihan ymmärrä kuviota tuon takana. Tai ainoastaan tulee mieleen että ihmisiin ei luoteta? ei haluta maksimaalista hyötyä joustavuudesta ja etätöistä? Itsellä on joustavat työajat niin teen käytännössä aina niin että perjantai on lyhyempi eli lopettelen 14-15 aikaan (perjantait aika usein toimistolla, maanantai enemmän etäillyt). Itsellä menisi maku jos pomo sanoo jonkun tuollaisen mielivaltaisen säännön. Mutta talossa talon tavoilla ja kannattaa vaihtaa jos joku sääntö ei nappaa. Lähinnä se että omituista jos sääntö vaan "keksitään" jotta perjantaisin ei oltaisi etänä koska se on hyvä päivä etäillä jossain reissun päällä.

 

[Zigh]

En nyt oikein tiedä mitä tarkoitat "täysin kustomoitavalla". Ihan normaalia se on että UI-tekstit, etenkin jotku geneeriset nappulan tekstit, on buildattu mukaan siihen executableen. Tässä vissiin sieltä sitten Epiciltä tulee yhdet geneeriset binäärit kaikille asiakkaille jolloin tuollaisia ei pääse kustomoimaan. Eiköhän siellä Epicin sorsakoodeissa homma ole hoidettu ihan normaalisti jollain resurssifileillä missä nuo käännökset ovat.

Toki herää kysymys on että kannattaako tuollaista järjestelmää hankkia missä valtaosa järjestelmästä tulee taholta joka ei mahdollista tuollaisia asiakaskustomointeja (tai voi olla että sallisi mutta maksaisi paljon enemmän).

Kyllä mulle ainakin tuosta selityksestä tulee heti mieleen, että aluperäiset tekstit on jollain tapaa kovakoodattu ja käännökset tehdään ns. lennosta mallilla "korvaa tämä merkkijono tällä". Vai mikä muu voi selittää sitä, että jos jonkin elementin suomenkielistä tekstiä haluaisi muuttaa, pitäisi myös alkuperäinen englanninkielinen teksti muuttaa?

 

[poskiholisti]

Niin kai sitä luulis, tosin ei ole tietoa kuinka tuo integroituu esim. olemassaoleviin laboratoriojärjestelmiin. Voi käydä todella kalliiksi jos kaikki joudutaan tekemään nollista.

HUS hankki taannoin Intersystemsin integraatioalustan hoitamaan yhteyksiä esimerkiksi laboratoriojärjestelmien ja potilastietojärjestelmän välillä. Sanomaliikennehän sinänsä on standardoitu protokollien ja sanomamuotojen osalta.

Sivujuonteena myös laboratoriopuolen järjestelmiä ollaan uusittu viime aikoina: Kehitystyö ei pääty käyttöönottoon - Mylab

 

[JCSH]

Kyllä mulle ainakin tuosta selityksestä tulee heti mieleen, että aluperäiset tekstit on jollain tapaa kovakoodattu ja käännökset tehdään ns. lennosta mallilla "korvaa tämä merkkijono tällä". Vai mikä muu voi selittää sitä, että jos jonkin elementin suomenkielistä tekstiä haluaisi muuttaa, pitäisi myös alkuperäinen englanninkielinen teksti muuttaa?

Tuo voi olla prosessikysymys, eli niillä on se massiivinen lista käännettäviä stringejä jotka ovat englanniksi. Sitten ne menee paikkaan X joka hoitaa käännökset noiden englanninkielisten tekstien pohjalta. Tuolta tulevat käännökset sitten paketoidaan osaksi sitä yhtä isoa executablea joka toimitetaan asiakkaille ilman mitään kustomointeja. Eli jos haluat muokata sieltä yhtä käännöstä, sun pitää muokata sitä alkuperäistä englanninkielistä tekstiä.
Toki voi olla että sitä käännöstä voi myös muokata lennosta (tosin kyseessä on medicalia joten nuo voi olla aivan hirveän prosessiraskaita muutoksia) mutta sitten ongelmaan törmätään jos Epicillä on muita asiakkaita jotka tarvitsee suomea ja siellä on sitten yhtä asiakasta varten modattu teksti.

Tuollainen "lennosta replace" puhtaasti sen tekstin perusteella (eikä esim. resurssi id:n) olisi kyllä käsittämättömän huono toteutus koska ilman kontekstia käännökset hajoaa välittömästi.

 

[ravallo]

Tuollainen "lennosta replace" puhtaasti sen tekstin perusteella (eikä esim. resurssi id:n) olisi kyllä käsittämättömän huono toteutus koska ilman kontekstia käännökset hajoaa välittömästi.

Veikkaisin että sillä tosiaan on haluttu vain ylläpidettävyyttä, ei haluta että merkitys hajoaa kieliversioiden välillä, mikä kuulostaa ihan järkevältä. Varsinkin jos komponentti on sellainen että sitä saatetaan käyttää järjestelmässä muuallakin. Voi olla vähän hapokas hanskata tilannetta jossa sulla on käännöstaulukko jollekin 85 000 elementille 45 kielellä ja siellä on ihan ok että "save" voikin jossain painikkeessa suomeksi tarkoittaa "kopioi". Jossain vaiheessa jatkokehitystä sattuu varmasti leukaan.

Mulla ei hirveästi ole kokemusta noiden valmisohjelmistojen kanssa puljaamisesta, mutta eiköhän niiden kanssa tule aika säännöllisesti tällaisia tilanteita, kun väkisin halutaan keittää teetä kahvinkeittimellä...

 

[edup]

Täytyy kyllä terveydenhuollon datojen kanssa jonkun verran töitä tehneenä sanoa, että on ihan positiivista että tuollaisia merkitystä vaihtavia käännöshirvityksiä ei toteuteta. Potilastietojärjestelmiin tullaan niiden käytössäoloaikana integroimaan ties minkäsorttisia lisäpalikoita ja muita palveluita. Se on ihan oikea ongelma ja pahimmillaan potilasturvallisuusriski jos käyttöliittymässä näkyy merkitykseltään jotakin muuta kuin mitä se taustalla olevissa kannoissa ja dokumentaatioissa englanniksi on.

Se on sitten eri asia mitä mieltä kukin on Apotin/Epicin ketteryydestä ylipäätään tehdä kustomointeja ja muita muutoksia. Ylipäätäänhän Epic on hyvin jenkkisentrinen, ja järjestelmä ainakin osittain taipuu huonosti mihinkään sellaisiin prosesseihin tai työtapoihin mitkä ei mene pilkulleen niin kuin jenkeissä on määrätty tai tapana tehdä.

 

[Mechanical Man]

Täytyy kyllä terveydenhuollon datojen kanssa jonkun verran töitä tehneenä sanoa, että on ihan positiivista että tuollaisia merkitystä vaihtavia käännöshirvityksiä ei toteuteta. Potilastietojärjestelmiin tullaan niiden käytössäoloaikana integroimaan ties minkäsorttisia lisäpalikoita ja muita palveluita. Se on ihan oikea ongelma ja pahimmillaan potilasturvallisuusriski jos käyttöliittymässä näkyy merkitykseltään jotakin muuta kuin mitä se taustalla olevissa kannoissa ja dokumentaatioissa englanniksi on.

Se on sitten eri asia mitä mieltä kukin on Apotin/Epicin ketteryydestä ylipäätään tehdä kustomointeja ja muita muutoksia. Ylipäätäänhän Epic on hyvin jenkkisentrinen, ja järjestelmä ainakin osittain taipuu huonosti mihinkään sellaisiin prosesseihin tai työtapoihin mitkä ei mene pilkulleen niin kuin jenkeissä on määrätty tai tapana tehdä.

Eikös tuossa ole kyse siitä, että käännös ei vastaa siitä toteutuvaa toimintoa. Se jos mikä on potilasturvallisuuden puolesta vaarallista.

 

[edup]

Eikös tuossa ole kyse siitä, että käännös ei vastaa siitä toteutuvaa toimintoa. Se jos mikä on potilasturvallisuuden puolesta vaarallista.

Paha sanoa kun ei tiedä mistä namiskasta on kyse. Pyydettävä nimimuutos saattaa suomalaisittain olla perusteltu ja jopa paremmin sitä napin pääasiallista toimintoa Suomessa kuvaava (koska ei tuollaisia muutoksia nyt yleensä turhaan pyydellä). Mutta nuo on monimutkaisia systeemeitä, ja yksittäinen namiska harvoin on vain yksittäinen namiska, vaan sen alta saattaa paljastua ties mitä mörköjä kun lähtee kaivamaan.

 

[JCSH]

Eikös tuossa ole kyse siitä, että käännös ei vastaa siitä toteutuvaa toimintoa. Se jos mikä on potilasturvallisuuden puolesta vaarallista.

No tuossahan lukee:
"Epicin kanta on, että teksti vastaa järjestelmän alkuperäistä toimintatapaa kyseisessä toiminnossa. Suomessa toimintaa on hieman muutettu Apotissa tehtävällä kehitystyöllä."

Eli siis vissiin se alkuperäinen käännös on oikein mutta sitten se onkin Suomessa puukotettu tekemään jotain muuta ja nykyinen käyttötapa ei enää vastaa sitä alkuperäistä toimintoa ja sen käännöstä.

 

[SundeR]

Surkuhupaisaa tuosta Apotista lukea vuosi vuodelta juttuja, kun "alalla" tiedettiin jo melkein 10 vuotta sitten että päin vittua tulee menemään. Hanke olisi keretty keskeyttää ja miettiä uusiksi tässä moneen kertaan.

 

[FireFly Renaissance]

En nyt oikein tiedä mitä tarkoitat "täysin kustomoitavalla". Ihan normaalia se on että UI-tekstit, etenkin jotku geneeriset nappulan tekstit, on buildattu mukaan siihen executableen. Tässä vissiin sieltä sitten Epiciltä tulee yhdet geneeriset binäärit kaikille asiakkaille jolloin tuollaisia ei pääse kustomoimaan. Eiköhän siellä Epicin sorsakoodeissa homma ole hoidettu ihan normaalisti jollain resurssifileillä missä nuo käännökset ovat.

Toki herää kysymys on että kannattaako tuollaista järjestelmää hankkia missä valtaosa järjestelmästä tulee taholta joka ei mahdollista tuollaisia asiakaskustomointeja (tai voi olla että sallisi mutta maksaisi paljon enemmän).

Tämä kuulosti minusta ennenkaikkea poliittiselta kuin tekniseltä ongelmalta. Onhan ne tekstit nytkin käännetty ja lokalisoitu. Koska company policy ,siellä ei vaan löytynyt manageria jolla olisi ollut natsoja/uskallusta sanoa, että pistäkää mitä tykkäätte.

 

[poskiholisti]

No tuossahan lukee:
"Epicin kanta on, että teksti vastaa järjestelmän alkuperäistä toimintatapaa kyseisessä toiminnossa. Suomessa toimintaa on hieman muutettu Apotissa tehtävällä kehitystyöllä."

Eli siis vissiin se alkuperäinen käännös on oikein mutta sitten se onkin Suomessa puukotettu tekemään jotain muuta ja nykyinen käyttötapa ei enää vastaa sitä alkuperäistä toimintoa ja sen käännöstä.

Onhan tuo hieman erikoista, että toiminnallisen logiikan muutokset ovat mahdollisia, mutta käyttöliittymämuutokset toiminnallisuuden päällä ovat kiveen hakattuja?

 

[ravallo]

Surkuhupaisaa tuosta Apotista lukea vuosi vuodelta juttuja, kun "alalla" tiedettiin jo melkein 10 vuotta sitten että päin vittua tulee menemään. Hanke olisi keretty keskeyttää ja miettiä uusiksi tässä moneen kertaan.

...ja kaikista niistä uudelleen mietityistä vaihtoehtoisistakin toteutustavoista "alalla" tiedettäisiin heti että päin vittua tulisi silti menemään.

 

[FireFly Renaissance]

...ja kaikista niistä uudelleen mietityistä vaihtoehtoisistakin toteutustavoista "alalla" tiedettäisiin heti että päin vittua tulisi silti menemään.

No ilmeisesti ainakin tällä vaihtoehtoisella toteutustavalla menee aika paljon paremmin, ja loppulasku varmaan jonkun miljardin ehkä halvempikin.

OYSissa tehtiin itse potilastietojärjestelmä ja parempihan siitä tuli kuin ostamalla – "Meidän kaikkein suurin vahvuus on, että lääkärit ja hoitajat ovat koko ajan mukana kehittämisessä"

Pohjois-Pohjanmaalla ei ole tarvetta sijoittaa satoja miljoonia euroja Helsingin Apotin kaltaiseen sairaaloiden tietojärjestelmään.

www.kaleva.fi

 

[JCSH]

No ilmeisesti ainakin tällä vaihtoehtoisella toteutustavalla menee aika paljon paremmin, ja loppulasku varmaan jonkun miljardin ehkä halvempikin.

OYSissa tehtiin itse potilastietojärjestelmä ja parempihan siitä tuli kuin ostamalla – "Meidän kaikkein suurin vahvuus on, että lääkärit ja hoitajat ovat koko ajan mukana kehittämisessä"

Pohjois-Pohjanmaalla ei ole tarvetta sijoittaa satoja miljoonia euroja Helsingin Apotin kaltaiseen sairaaloiden tietojärjestelmään.

www.kaleva.fi

Tuo on maksumuurin takana joten en pysty näkemään koko artikkelia mutta ainakin tuon yhden kuvan sliden pohjalta näyttäisi siltä että kyseistä järjestelmää on kehitetty vuodesta 1996 asti.
Joten ei välttämättä ihan verrattavissa tuollaiseen HUS tyyliseen "vaihdetaan lennosta kaiken kattava uusi järjestelmä muutaman vuoden sisään".

 

[FireFly Renaissance]

Tuo on maksumuurin takana joten en pysty näkemään koko artikkelia mutta ainakin tuon yhden kuvan sliden pohjalta näyttäisi siltä että kyseistä järjestelmää on kehitetty vuodesta 1996 asti.
Joten ei välttämättä ihan verrattavissa tuollaiseen HUS tyyliseen "vaihdetaan lennosta kaiken kattava uusi järjestelmä muutaman vuoden sisään".

”Esko lyö Apotin” – Oulussa lääkärit ovat tyytyväisiä potilastietojärjestelmäänsä ja haluavat sen muillekin käyttöön

Oululaiset haluavat ujuttaa potilastietojärjestelmänsä osaksi Apotin kilpailijaa Unaa, Tekniikka&Talous-lehti kertoo.

www.tivi.fi

No toi tivin juttu on luettavissakin. Kyllähän tuosta aina silloin tällöin on ollut kirjoituksia.

Mutta lyhyesti, eivät ostaneet jotan megalomaanista ja megahintaista valmisalustaa, eivätkä edes tilanneet softaa miltään suurelta palveluyhtiöltä, vaan palkkasivat itse kehittäjät tekemään mitä tarvivat.

 

[JCSH]

Mutta lyhyesti, eivät ostaneet jotan megalomaanista ja megahintaista valmisalustaa, eivätkä edes tilanneet softaa miltään suurelta palveluyhtiöltä, vaan palkkasivat itse kehittäjät tekemään mitä tarvivat.

Siis helvetin hyvä veto kyllä noilta alkaa kehittään sitä about 25 vuotta sitten kun ei ollut vielä juurikaan mitään elektronisia legacyjärjestelmiä.
Mutta HUS ei voi mennä aikakoneella takaisin vuoteen 1996 ja aloittaa vastaavaa projektia vaan ne tarvitsee sen valmiin ratkaisun. Tosin en tiedä että yritettiinkö tuota Eskoa kaupata niille, olis voinut olla hyvä kotimainen ratkaisu.

 

[ravallo]

No ilmeisesti ainakin tällä vaihtoehtoisella toteutustavalla menee aika paljon paremmin, ja loppulasku varmaan jonkun miljardin ehkä halvempikin.

OYSissa tehtiin itse potilastietojärjestelmä ja parempihan siitä tuli kuin ostamalla – "Meidän kaikkein suurin vahvuus on, että lääkärit ja hoitajat ovat koko ajan mukana kehittämisessä"

Pohjois-Pohjanmaalla ei ole tarvetta sijoittaa satoja miljoonia euroja Helsingin Apotin kaltaiseen sairaaloiden tietojärjestelmään.

www.kaleva.fi

Veikkaisin asiasta paremmin tietämättä että Esko on varmasti hyvä järjestelmä, todennäköisti omalla osa-alueellaan Apotti / Epiciä parempi, mutta siinä kyllä kokonaisuutena verrataan kananmunaa koko kakkuun, tuo Eskon laajuus on huomattavasti pienempi, eikä oikein ole näyttöjä siitä miten hyvin sen käyttöönotto jossain toisessa sairaanhoitopiirissä kuin missä se on kehitetty onnistuisi.

(Ylipäänsä hieman hämärtävää puhua potilastietojärjestelmästä, jos kyse olisi pelkästä potilastietosta niin sitten se "Virossa tehtiin tääkin 15M hintaan" olis ihan validi argumentti...)

Nythän Eskoa ollaan laajentamassa perusterveydenhuollon käyttöön ja kaupallistamassa eli kohta näkee paremmin mitä se osaa. Järjestelmäkehitys yhtä asiakasta varten on suhteellisen kivaa ja mukavaa, voi hörppiä asiakkaiden kanssa kahvia ja miettiä että mikäs juuri tähän teidän skenaarioon nyt olisi paras lähestymistapa, mutta sitten kun asiakkaita on useampia ja järjestelmästä pyörii useita eri versiota tuotannossa vähän eri tavalla kustomoituna, niin se kiva vähenee aika nopeasti, ja ne "joo, mikäs siinä, laitetaan se toimimaan niin" -kommentit alkaa muuttumaan "ei pysty, ei kykene, ehkä vuonna 2023" -kommenteiksi, kun selviää että asiakkaan A haluamat toiminnallisuudet rikkoisivat asiakkaan C toiminnallisuudet...

Tosin Eskon kanssakin olisi tullut tilanne jossa sitä olisi joutunut rinnakkaiskäyttämään olemassaolevien järjestelmien kanssa pitkään, ja käytännössä toteuttamaan taustalla Effica --> Lifecare -järjestelmäuudistuksen, ja eikös Uranus / Pegasoskin taida olla samassa tilanteessa?

 

[FireFly Renaissance]

Veikkaisin asiasta paremmin tietämättä että Esko on varmasti hyvä järjestelmä, todennäköisti omalla osa-alueellaan Apotti / Epiciä parempi, mutta siinä kyllä kokonaisuutena verrataan kananmunaa koko kakkuun, tuo Eskon laajuus on huomattavasti pienempi, eikä oikein ole näyttöjä siitä miten hyvin sen käyttöönotto jossain toisessa sairaanhoitopiirissä kuin missä se on kehitetty onnistuisi.

(Ylipäänsä hieman hämärtävää puhua potilastietojärjestelmästä, jos kyse olisi pelkästä potilastietosta niin sitten se "Virossa tehtiin tääkin 15M hintaan" olis ihan validi argumentti...)

Nythän Eskoa ollaan laajentamassa perusterveydenhuollon käyttöön ja kaupallistamassa eli kohta näkee paremmin mitä se osaa. Järjestelmäkehitys yhtä asiakasta varten on suhteellisen kivaa ja mukavaa, voi hörppiä asiakkaiden kanssa kahvia ja miettiä että mikäs juuri tähän teidän skenaarioon nyt olisi paras lähestymistapa, mutta sitten kun asiakkaita on useampia ja järjestelmästä pyörii useita eri versiota tuotannossa vähän eri tavalla kustomoituna, niin se kiva vähenee aika nopeasti, ja ne "joo, mikäs siinä, laitetaan se toimimaan niin" -kommentit alkaa muuttumaan "ei pysty, ei kykene, ehkä vuonna 2023" -kommenteiksi, kun selviää että asiakkaan A haluamat toiminnallisuudet rikkoisivat asiakkaan C toiminnallisuudet...

Tosin Eskon kanssakin olisi tullut tilanne jossa sitä olisi joutunut rinnakkaiskäyttämään olemassaolevien järjestelmien kanssa pitkään, ja käytännössä toteuttamaan taustalla Effica --> Lifecare -järjestelmäuudistuksen, ja eikös Uranus / Pegasoskin taida olla samassa tilanteessa?

Kun hintalaput on satoja miljoonia, niin siinä vaiheessa on kyllä jo ihan validia kysyä, että onko siitä standardituotteesta jotain oikeaa iloa tai edes minkäänsortin järkeä.

Samaa softaa on kuitenkin tarkoitus uudelleenkäyttää siksi, että se on merkittävästi halvempaa. Jos se uudelleenkäyttö vain bloattaa kaiken, mukaanlukien kustannukset, niin silloin sitä ei tule tehdä tai sitten pitää miettiä miten se tehdään paremmin.

 

[namlepo]

On se vaikeeta tehä yksi tietokanta. Nami nami.

 

[JCSH]

Kun hintalaput on satoja miljoonia, niin siinä vaiheessa on kyllä jo ihan validia kysyä, että onko siitä standardituotteesta jotain oikeaa iloa tai edes minkäänsortin järkeä.

Samaa softaa on kuitenkin tarkoitus uudelleenkäyttää siksi, että se on merkittävästi halvempaa. Jos se uudelleenkäyttö vain bloattaa kaiken, mukaanlukien kustannukset, niin silloin sitä ei tule tehdä tai sitten pitää miettiä miten se tehdään paremmin.

Tosin jos hintalaput on satoja miljoonia niin voidaan kysyä että jos se maksaa satoja miljoonia per asiakas kun sen kehittäneellä firmalla on satoja asiakkaita joita laskuttaa niin kuinka paljon sen vastaavan softan tekeminen nollasta yhdelle asiakkaalle sitten maksaisi.

 

[FireFly Renaissance]

Tosin jos hintalaput on satoja miljoonia niin voidaan kysyä että jos se maksaa satoja miljoonia per asiakas kun sen kehittäneellä firmalla on satoja asiakkaita joita laskuttaa niin kuinka paljon sen vastaavan softan tekeminen nollasta yhdelle asiakkaalle sitten maksaisi.

No, jos se softa on toimimatonta bloattia jota pidetään jotenkin kasassa miljardikustannuksilla, niin sellaista softaa ei nyt alunperinkään kuulu tehdä.

Ylipäänsä, jos yhden monoliittisen softan tekemiseen uppoaa tuollaisia rahamääriä niin voidaan jo lähtökohtaisesti lähteä siitä, että ei sillä mitään toimivaa kunnollista aikaan saada ja jotain on todella pahasti pielessä. Mythical man month ja niin edelleen. Jos sadalla miljoonalla palkatut tuhat koodaria eivät hommaa saa hoidettua, niin palkkaamalla 2000 koodaria 200 miljoonalla tuskin korjaa/parantaa tilannetta.

 

[ravallo]

Kun hintalaput on satoja miljoonia, niin siinä vaiheessa on kyllä jo ihan validia kysyä, että onko siitä standardituotteesta jotain oikeaa iloa tai edes minkäänsortin järkeä.
Samaa softaa on kuitenkin tarkoitus uudelleenkäyttää siksi, että se on merkittävästi halvempaa. Jos se uudelleenkäyttö vain bloattaa kaiken, mukaanlukien kustannukset, niin silloin sitä ei tule tehdä tai sitten pitää miettiä miten se tehdään paremmin.

Alan ikuisuuskysymyksiä

Joskus juttelin asiasta pitkään yhden tanskalaisen, reilun parikymmentä vuotta pakettisoftaprojekteja tehneen kollegan kanssa, olin oman, täysin customkehitykseen perustuvan kokemuksen pohjalta sitä mieltä että customkehitys on ihan saatanasta missään vähänkään isommissa järjestelmissä, pitäis tehdä satoja näyttöjä ja työnkulkuja, ja sitten hinkataan tuntikausia että saadaan johonkin valikkoon arvot oikeaan järjestykseen tai ihmetellään kun sorsakirjastot happanee käsiin kesken hankkeen. Se taas oli sitä mieltä että aina kannattais tehdä customina, ei niistä pakettisoftista ole kun haittaa, loppukäyttäjät haluaa kuitenkin käyttää sitä pakettisoftaa ihan eri tarkoitukseen ja ihan eri tavalla kuin miten se softa tykkää toimia, ja sitten se lopputulos on joku purkallaja nippusiteillä kokoon kasattu frankensofta.

Samaa tilitti joskus yksi SAP projekteja vuosia vetänyt kaveri. Sanoi että kaikki projektit alkaa kun kickoffissa kilistellään laseja ja todetaan että ihan minimimuutoksilla mennään, ei muuta kuin data sisään ja menoksi. Sitten viiden vuoden ja muutaman kymmenen miltsin jälkeen lähdetään pihalle ja todetaan että sitä mikä taakse jää ei enää edes tunnista SAPiksi. Ja että vaikka SAP polttaa hillittömiä määriä hilloa tutkimukseen että mikä on minkäkin alan best practice, niin ihan sama mille kaken konepajalle sitä laitat, niin ne omat toimintatavat on just ne parhaat eikä niitä sitten jonkun toiminnanohjausjärjestelmän takia muutella.

Mitä tähän voi sanoa, teki niin tai näin niin noi isot hankkeet menee aina vituiksi. Eikä siihen auta vaikka ne pilkkoisi ja tekisi osissa, kokonaisuus menee silti vituiksi.

 

[SundeR]

...ja kaikista niistä uudelleen mietityistä vaihtoehtoisistakin toteutustavoista "alalla" tiedettäisiin heti että päin vittua tulisi silti menemään.

En nyt puhunut mistään yleisestä pessimismistä tms, vaan ihan nähtävissä olevista asioista kun projekti oli jonkun matkaa nytkähtänyt käyntiin. Ja siis ihmisten kesken keillä osalla kokemusta julkishallinon jättihankkeista ja miten ne voi perseelleen mennä.

...
Mitä tähän voi sanoa, teki niin tai näin niin noi isot hankkeet menee aina vituiksi. Eikä siihen auta vaikka ne pilkkoisi ja tekisi osissa, kokonaisuus menee silti vituiksi.

Jos määrittelyssä on lauseita, miten uuden jäjrestelmän pitää toteuttaa kaikki mitä vanhat (kymmenet?) järjestelmät, tai jos johtoryhmässä istuu (kymmeniä?) tyyppiejä eri sairaanhoitopiireistä vetämässä järjestelmää omaan suuntaansa, niin siinä vaiheessa lienee turha puhua tekniikasta, millä uusi järjestelmä olisi voitu toteuttaa paremmin. Veikkaan että valittu vanhanaikainen järjestelmä oli vain kirsikkana kakussa.

 

[JCSH]

No, jos se softa on toimimatonta bloattia jota pidetään jotenkin kasassa miljardikustannuksilla, niin sellaista softaa ei nyt alunperinkään kuulu tehdä.

Ylipäänsä, jos yhden monoliittisen softan tekemiseen uppoaa tuollaisia rahamääriä niin voidaan jo lähtökohtaisesti lähteä siitä, että ei sillä mitään toimivaa kunnollista aikaan saada ja jotain on todella pahasti pielessä. Mythical man month ja niin edelleen. Jos sadalla miljoonalla palkatut tuhat koodaria eivät hommaa saa hoidettua, niin palkkaamalla 2000 koodaria 200 miljoonalla tuskin korjaa/parantaa tilannetta.

Eli siis mikä sitten on ratkaisu, ei tehdä isoja softia? Kasa pikkuisia softakokonaisuuksia joita sitten pidetään kasassa ties millä purkalla?
Lisäksi eiköstä näissä yleensä se varsinainen koodauksen kustannus ole suht pieni ja valtaosa tulee muista tuohon liitetyistä kuluista?

 

[FireFly Renaissance]

Eli siis mikä sitten on ratkaisu, ei tehdä isoja softia? Kasa pikkuisia softakokonaisuuksia joita sitten pidetään kasassa ties millä purkalla?
Lisäksi eiköstä näissä yleensä se varsinainen koodauksen kustannus ole suht pieni ja valtaosa tulee muista tuohon liitetyistä kuluista?

No se on se mythical man month. Ne muut kulut karkaa täysin käsistä ja tuottavuus kääntyy jopa negatiiviseksi, kun byrokratia generoi vain enemmän byrokratiaa ja pahimmillaan tuottavan työn määrä vähenee, eikä kasva kun kokkeja lisätään koko ajan soppaan jossa on niin paljon suolaa ettei muuta sekaan mahdu.

Ainakaan ei kannata yrittää tehdä sellaista isoa softaa joka yrittää tehdä kaiken kaikille. Pienemmät softakokonaisuudet on kyllä paljon helpompi pitää kasassa ilman purkkaa kuin suuret. Hajoita ja hallitse nyt olisi pitänyt olla itsestäänselvyys suunnittelussa jo siitä lähtien kun ensimmäiset reikäkortit laitettiin hyllyille pölyttymään.

 

[JCSH]

No se on se mythical man month. Ne muut kulut karkaa täysin käsistä ja tuottavuus kääntyy jopa negatiiviseksi, kun byrokratia generoi vain enemmän byrokratiaa ja pahimmillaan tuottavan työn määrä vähenee, eikä kasva kun kokkeja lisätään koko ajan soppaan jossa on niin paljon suolaa ettei muuta sekaan mahdu.

Ainakaan ei kannata yrittää tehdä sellaista isoa softaa joka yrittää tehdä kaiken kaikille. Pienemmät softakokonaisuudet on kyllä paljon helpompi pitää kasassa ilman purkkaa kuin suuret. Hajoita ja hallitse nyt olisi pitänyt olla itsestäänselvyys suunnittelussa jo siitä lähtien kun ensimmäiset reikäkortit laitettiin hyllyille pölyttymään.

Hajoita ja hallitse toimii silloin jos sulla on järkevä modulaarinen pohja-arkkitehtuuri. Mutta se ei toimi jos sulla on se n+20 eri toimittajilta saatua erillistä järjestelmää jotka pitäisi saada jakamaan tietoja ja toimimaan nätisti yhdessä.

 

[ravallo]

Eli siis mikä sitten on ratkaisu, ei tehdä isoja softia? Kasa pikkuisia softakokonaisuuksia joita sitten pidetään kasassa ties millä purkalla?
Lisäksi eiköstä näissä yleensä se varsinainen koodauksen kustannus ole suht pieni ja valtaosa tulee muista tuohon liitetyistä kuluista?

Jos siihen olis joku ratkaisu, niin eiköhän se olis jo industry best practice, ja kaikki tekis niin

Mä luulen että noista monoliitti vs. ekosysteemi -välisistä väännöistä saa ihan samalla lailla painajaisskenaarioita aikaan molemmilta puolilta kun tuosta paketti vs. custom -valinnasta. Arkkitehtuurin hallinta tuollaisessa palasista rakennettavassa ekosysteemissä pitää olla aivan timanttista, samaten tiedon semantiikan hallinta, jotta palaset saadaan kommunikoimaan keskenään. Sitten se roadmapin ja riippuvuuksien hallinta on helvetin haastavaa, ja kehitystiimien välinen kommunikaatio. Ja sitten sen pitäisi vielä kestää aikaa, niin että kun savupiippu on valmis niin perustus ei ole jo laho. Ja helposti tuossa päädytään sellaiseen hämähäkinseittiin, jossa kehitys seisahtuu kun keskinäiset riippuvuudet ovat niin monimutkaisia ettei mitään uskalleta muuttaa ettei jotain hajoa, ja hups, on tehty palasista monoliitti. Olen tehnyt projekteja pankkimaailmassa, ja siellä on tullut vastaan tuollaisia satojen järjestelmien kauhugallerioita.

Aika on yksi hankala tekijä. Tuollaisessa hankkeessa pitää saada sovittua helkkarin monesta erilaisesta periaatteesta (esm. minkä yksikön toimintatavat muodostaa jonkin toiminnon baselinen, mikä järjestelmä on minkäkin tiedon master, millainen tieto pitää olla saatavilla reaaliajassa ja mille riittää harvempi päivityssykli, kuka päättää mistäkin, miten kustannukset jaetaan jne) ja jo tuon pyörittäminen on monesti niin hidas prosessi, että jos kaikki pääperiaatteet halutaan sopia ennenkuin lyödään näpit näppikselle, ehtii hanke hapantua käsiin ennenkuin ollaan edes valmiita aloittamaan. Siksi monesti lähdetään liikkeelle ilman että kaikkia perusperiaatteita on sovittu, ja sitten tapellaan matkan varrella, yksi haara tehdään yhdellä tavalla ja toinen toisella, sitten ehkä konsolidoidaan, ehkä purkataan, ja rahaa palaa.

 

[JCSH]

Jos siihen olis joku ratkaisu, niin eiköhän se olis jo industry best practice, ja kaikki tekis niin

Mä luulen että noista monoliitti vs. ekosysteemi -välisistä väännöistä saa ihan samalla lailla painajaisskenaarioita aikaan molemmilta puolilta kun tuosta paketti vs. custom -valinnasta. Arkkitehtuurin hallinta tuollaisessa palasista rakennettavassa ekosysteemissä pitää olla aivan timanttista, samaten tiedon semantiikan hallinta, jotta palaset saadaan kommunikoimaan keskenään. Sitten se roadmapin ja riippuvuuksien hallinta on helvetin haastavaa, ja kehitystiimien välinen kommunikaatio. Ja sitten sen pitäisi vielä kestää aikaa, niin että kun savupiippu on valmis niin perustus ei ole jo laho. Ja helposti tuossa päädytään sellaiseen hämähäkinseittiin, jossa kehitys seisahtuu kun keskinäiset riippuvuudet ovat niin monimutkaisia ettei mitään uskalleta muuttaa ettei jotain hajoa, ja hups, on tehty palasista monoliitti. Olen tehnyt projekteja pankkimaailmassa, ja siellä on tullut vastaan tuollaisia satojen järjestelmien kauhugallerioita.

Aika on yksi hankala tekijä. Tuollaisessa hankkeessa pitää saada sovittua helkkarin monesta erilaisesta periaatteesta (esm. minkä yksikön toimintatavat muodostaa jonkin toiminnon baselinen, mikä järjestelmä on minkäkin tiedon master, millainen tieto pitää olla saatavilla reaaliajassa ja mille riittää harvempi päivityssykli, kuka päättää mistäkin, miten kustannukset jaetaan jne) ja jo tuon pyörittäminen on monesti niin hidas prosessi, että jos kaikki pääperiaatteet halutaan sopia ennenkuin lyödään näpit näppikselle, ehtii hanke hapantua käsiin ennenkuin ollaan edes valmiita aloittamaan. Siksi monesti lähdetään liikkeelle ilman että kaikkia perusperiaatteita on sovittu, ja sitten tapellaan matkan varrella, yksi haara tehdään yhdellä tavalla ja toinen toisella, sitten ehkä konsolidoidaan, ehkä purkataan, ja rahaa palaa.

Ja näissä asioissa tuntuu siltä että sä aina löydät sen pari sataa kommentoijaa jotka "osaa" kertoa miten hommaa ei pidä tehdä mutta jostain syystä sitten ne jotka osaa kertoa miten se pitäisi tehdä ovat harvemmassa.

 

[FireFly Renaissance]

Hajoita ja hallitse toimii silloin jos sulla on järkevä modulaarinen pohja-arkkitehtuuri. Mutta se ei toimi jos sulla on se n+20 eri toimittajilta saatua erillistä järjestelmää jotka pitäisi saada jakamaan tietoja ja toimimaan nätisti yhdessä.

Tietenkin, mutta on olemassa muitakin vaihtoehtoja kuin "rakentaa jumalattoman suuri ja kompleksinen monoliittisofta kaikkiin tarpeisiin" tai "tilata n+20 eri toimittajan epäyhteensopivaa erilaista järjestelmää". Kumpikin kannattaa unohtaa heti alkuunsa.

 

[JCSH]

Tietenkin, mutta on olemassa muitakin vaihtoehtoja kuin "rakentaa jumalattoman suuri ja kompleksinen monoliittisofta kaikkiin tarpeisiin" tai "tilata n+20 eri toimittajan epäyhteensopivaa erilaista järjestelmää". Kumpikin kannattaa unohtaa heti alkuunsa.

No miten esim. tuo HUS:n tapaus olisi pitänyt hoitaa? Siis kun otetaan huomioon että käsittääkseni nykytilanne (tai ainakin oli kun tuota Apottia potkittiin henkiin) on että niillä oli käytössä se n+20 eri toimittajan järjestelmää jotka eivät jutelleet kiltisti keskenään.

 

[FireFly Renaissance]

No miten esim. tuo HUS:n tapaus olisi pitänyt hoitaa? Siis kun otetaan huomioon että käsittääkseni nykytilanne (tai ainakin oli kun tuota Apottia potkittiin henkiin) on että niillä oli käytössä se n+20 eri toimittajan järjestelmää jotka eivät jutelleet kiltisti keskenään.

Lähteä rakentamaan uusi järjestelmä ilman Apottia (oletetaan, että Apotti oli oikeasti parasta mitä markkinoilta sai). Koska Apotti on ollut (ennustusten mukaisesti) täydellinen katastrofi ja loputon rahareikä ei se ainakaan huonompaan lopputulokseen voi päätyä. Todennäköisesti niiden kannattaisi edelleen heittää se Apotti mäkeen, koska siitä tuskin saadaan millään rahalla hyvin toimivaa vaikka kuinka kaivoon kaataisi.

Jopa ne vanha n+20 järjestelmääkin kuitenkin ilmeisesit toimivat ainakin käyttäjien mielestä paremmin kuin Apotti. Niitä n+20 järjestelmää olisi myös voinut lähteä korvaamaan osissa paremmilla ja yhteensopivimmilla järjestelmillä yhdistäen toiminnallisuuksia niissä osin kuin se on järkevää ja jättämällä erillisiksi niiden kohdalla jolloin se on fiksumpaa.

Ja noin isossa järjestelmässä olisi ensiarvoisen tärkeää, että ainakin merkittävä osa kehittäjistä pitäisi olla oman talon sisällä vaikka konsultointia ja osakokonaisuuksia ostettaisiinkin ulkoa.