Gå til innhold

Har brukt 2,8 milliarder på ny plattform: – Ikke mulig å tro at profesjonelle aktører er i stand til å lage et så elendig produk…


Anbefalte innlegg

Videoannonse
Annonse

2,8 milliarder... Når en bruker såpass mye penger så har en jo helt klart overbetalt noe voldsomt. Det må da være en langt bedre løsning å da ha en egen utvikleravdeling. En får garantert gjort mye mer med 100 dedikerte utviklere over 28 år der alle får en millionlønn.

Hadde det bare vært så enkelt som at lønn til utviklere var den eneste utgiftsposten i et utviklingsprosjekt ...

  • Liker 3
Lenke til kommentar

 

2,8 milliarder... Når en bruker såpass mye penger så har en jo helt klart overbetalt noe voldsomt. Det må da være en langt bedre løsning å da ha en egen utvikleravdeling. En får garantert gjort mye mer med 100 dedikerte utviklere over 28 år der alle får en millionlønn.

Hadde det bare vært så enkelt som at lønn til utviklere var den eneste utgiftsposten i et utviklingsprosjekt ...

Det er egentlig ikke så produktivt å fokusere på kostnaden, men hva som blir oppnådd og i hvilken grad man senere kan bygge videre på det som er gjort. Det er faktisk et godt poeng at dette er systemer man burde utviklet selv, med en egen utviklingsorganisasjon, men det alene er heller ikke nok.

 

Det man må innse er at dette er systemer som skal betjene en organisasjon som det bare finnes én av i verden og at denne organisasjonen hvert eneste år vil ha endrede behov. Ethvert statlig system vil per definisjon være unikt fordi hver eneste stat har sine unike lover og regler.

 

Det vil selvsagt være store deler av en slik platform som kan gjennomføres med standardiserte komponenter, men der man er nødt til å tilpasse komponenter fra en leverandør i vesentlig grad vil det på sikt antagelig være langt mer lønnsomt med et eget system. (En god pekepinn er egentlig å finne i historikken til systemer i helsevesenet der man lover at man "bare trenger litt tilpasning" av systemer, og så ramler utpå).

 

Et annet viktig moment er kontinuitet og kontinuerlig utvikling. Man begynner å se at endel statlige foretak har skjønt dette og tar over mer av utviklingen selv, men for det meste opererer statlige prosjekter fremdeles med en big-bang-utviklingsmodell som vi vet ikke fungerer.

 

Å starte opp et digert utviklingsprosjekt, gjennomføre det og så legge det ned innebærer at man først bruker veldig mye ressurser på å bygge opp kunnskap for så å kaste denne når man er "ferdig". Ikke minst fordi bestiller skal klare å finne ut av hva de vil ha – og det er i endel tilfeller ikke mulig å spikre helt på forhånd.

 

Man kaster ikke kunnskapen i form av at dokumentasjonen forsvinner, men i form av at man kvitter seg med den levende kunnskapen som finnes i de menneskene som bygger systemene. Man kaster også informasjonen i form av at alle relasjonene mellom de som jobber direkte med leveransen og de man skal levere til forsvinner.

 

Det er også viktig å huske at det er veldig lite sannsynlig å finne dyktige utviklere på slike digre prosjekter. Og om man finner dyktige utviklere er disse som oftest begrenset av en ganske spikret plan. Dyktige utviklere foretrekker gjerne jobber som tilbyr mer faglig mat og der de kan ha større innflytelse på faglige beslutninger. De som ender opp i den typen konsulentselskaper som gjennomfører slike prosjekter er de som ikke får seg noe bedre å gjøre. Man kan føle seg støtt av den uttalelsen, men det gjør den ikke noe mindre sann.

 

Hvis man kan bygge en organisasjon som er i stand til å tilby langsiktighet, autonomi, lønnsbetingelser og en arbeidsmåte som er mer i tråd med det som faktisk fungerer, er det mulig å sette standarden for utviklere ganske mye høyere. For ikke å snakke om at det er mulig å ansette dyktige ledere både for å sikre en kontinuerlig politisk forankring, og de faglige forankringene man trenger. Prosjekter har gjerne ikke tilstrekkelig dyp forankring fordi de er av temporær karakter.

 

2-3 milliarder er forøvrig ikke mye penger når det er snakk om dette omfanget. Om noe er tallet suspekt lavt.

  • Liker 8
Lenke til kommentar

Åjada. Det er ikke slutt ennå. Bare å åpne lommeboka for nye fremtidige krise-prosjekter. De står i kø.

I Danmark vurderer de jo løpende om man skal starte en karriere som snylter, svindler eller bedrager. -Alle andre gjør det jo. Fra ypperste prest, til politikere, til ansatte i lederposisjon i både politi og skatt. -På tide ‘normale’ mundane gjør det også.

  • Liker 2
Lenke til kommentar

Dere har ikke fått med dere det beste ved denne historien, og det er at Epic nå er eneste deltaker igjen i anbudet til Helse Midt-Norge.

 

Altså vil de ta i bruk "Sundhetsplatformen" i norsk utgave, om noen ikke reagerer

 

https://www.dagensmedisin.no/artikler/2018/062/18/it-selskap-trakk-seg-fra-milliardanbud-i-helse-midt-i-siste-liten--kun-en-leverandor-igjen/

 

Kjempegreier... dette blir bra...

  • Liker 1
Lenke til kommentar

 

2,8 milliarder... Når en bruker såpass mye penger så har en jo helt klart overbetalt noe voldsomt. Det må da være en langt bedre løsning å da ha en egen utvikleravdeling. En får garantert gjort mye mer med 100 dedikerte utviklere over 28 år der alle får en millionlønn.

Hadde det bare vært så enkelt som at lønn til utviklere var den eneste utgiftsposten i et utviklingsprosjekt ...

Ja, ok, 100 utviklere med millionlønn i 10 år, så har du 1 milliard til planlagte utgifter, og 800 millioner i buffer til uforutsette utgifter.

 

Hva har pengene faktisk gått til?

  • Liker 2
Lenke til kommentar

 

Dere har ikke fått med dere det beste ved denne historien, og det er at Epic nå er eneste deltaker igjen i anbudet til Helse Midt-Norge.

 

Altså vil de ta i bruk "Sundhetsplatformen" i norsk utgave, om noen ikke reagerer

 

https://www.dagensmedisin.no/artikler/2018/062/18/it-selskap-trakk-seg-fra-milliardanbud-i-helse-midt-i-siste-liten--kun-en-leverandor-igjen/

 

Kjempegreier... dette blir bra...

VEl... Jeg har førstehåndskjennskap til systemene det er snakk om, og i Norge er kompleksiteten langt høyere enn i Danmark. Feks. så har Danmark EN standardisert dataformat som leverandørene må støtte, i Norge et mylder av standarder.

Dete blir et varslet skandaleprosjekt imho....

  • Liker 3
Lenke til kommentar

En må begynne å utvikle slike systemer på samme måte som Linux utvikles. Linus på topp med en oversiktelige gruppe mellomledere under som har vist seg dyktige og motiverte nok til at Linus har tillit til dem. Samme kan en gjøre her. En liten gruppe av kodere, administrativt personell, og helsepersonell som gjennomgår kode og funksjonalitet som pushes fra små utviklerteam spredt over hele verden. Koden skal være fri og åpen og ligge i et gir-reservoar.

 

Så kan en heller definere overordnete mål for systemet, og så kan hvem som helst pushe sin kode. Kompensasjonsmodellen bør være fastlagt på forhold og en må åpne for at konkretiserte behov belønnes etter en dusør-modell.

  • Liker 1
Lenke til kommentar

En må begynne å utvikle slike systemer på samme måte som Linux utvikles. Linus på topp med en oversiktelige gruppe mellomledere under som har vist seg dyktige og motiverte nok til at Linus har tillit til dem. Samme kan en gjøre her. En liten gruppe av kodere, administrativt personell, og helsepersonell som gjennomgår kode og funksjonalitet som pushes fra små utviklerteam spredt over hele verden. Koden skal være fri og åpen og ligge i et gir-reservoar.

 

Så kan en heller definere overordnete mål for systemet, og så kan hvem som helst pushe sin kode. Kompensasjonsmodellen bør være fastlagt på forhold og en må åpne for at konkretiserte behov belønnes etter en dusør-modell.

 

Tror ikke det er mulig.

Du er klar over at det er helt ekdtremt strenge regler knyttet til hvem som skal ha hvilke tilganger til helse opplysninger? Open source er spennende, men på grunn av regelverket (nåværende) vil dette ikke være et alternativ (foreløpig).

 

Mistenker også at folk her har litt for stor tro til at dette er et resultat av svak programmering / det tekniske, men dette er nok bare et resultat som følge av en rekke svake valg og analyser i forkant. Det tekniske er nesten alltid trivielt. Man kan gjøre alle de rette tingene for alle de gale grunnene.

Endret av The Very End
  • Liker 2
Lenke til kommentar

2,8 milliarder... Når en bruker såpass mye penger så har en jo helt klart overbetalt noe voldsomt. Det må da være en langt bedre løsning å da ha en egen utvikleravdeling. En får garantert gjort mye mer med 100 dedikerte utviklere over 28 år der alle får en millionlønn.

 

Man kunne hatt 1000 utviklere i femti år, og det hadde ikke utgjort noen forskjell om spesifikasjonene hadde vært dårlig og lite gjennomtenkte.

 

Det er ikke vanskelig å kode slike systemer. Dette er nærmest så basic man får koding nå til dags. Det handler kun om dataflyt og sikkerhet.

 

Problemet er at omfanget er så stort med en enorm kompleksitet at det å definere dataflyten sett opp mot alle behov, lover, regler, arbeidsmetoder og nye arbeidsmetoder etter realisert gevinst er en enorm utfordring. Glipper det her er man ute å kjøre med en gang. Plutselig sitter man med et lappeteppe av endringsønsker på problemer man ikke visste at man hadde, enkelte av disse kommer kanskje i konflikt med den definerte dataflyten man trodde man hadde kål på. Neste er da forsinkelser og budsjettsprekk, før man sitter på deadline uten et ferdig prosjekt. Man utsetter, men innser etter hvert at problemene er for store og eller mange til at de kan løses på kort tid. Man gjør en kjapp vurdering, og bestemmer at man må sette i drift systemet uansett for ikke å tape ansikt.

 

Man er allerede på overtid, prosjekter har kostet for mye, ting fungerer ikke slik man først trodde, og som alt annet undervurderer man da også behov for opplæring. Det viktigste er å komme i gang. De som bruker systemet går seg på snægg som ikke blir fikset omgående, de begynner å ta snarveier eller å omgå systemet. De jobber ikke mer effektivt på grunn av at ting ikke fungerer som de skal. I tillegg var ilke arbeidsmetodikk analysert godt nok, slik at man ikke har endret denne der det kunne vært mulig. Altså oppnår man ikke gevinster noe sted.

 

Svært lite handler altså om selve koden, selv om også kodere kan være jalla innimellom altså...

  • Liker 2
Lenke til kommentar

Tror ikke det er mulig.

Du er klar over at det er helt ekdtremt strenge regler knyttet til hvem som skal ha hvilke tilganger til helse opplysninger? Open source er spennende, men på grunn av regelverket (nåværende) vil dette ikke være et alternativ (foreløpig).

Mistenker også at folk her har litt for stor tro til at dette er et resultat av svak programmering / det tekniske, men dette er nok bare et resultat som følge av en rekke svake valg og analyser i forkant. Det tekniske er nesten alltid trivielt. Man kan gjøre alle de rette tingene for alle de gale grunnene.

Jeg kjenner reglene, og det er enkelt å produsere dummy-data for test av disse systemene. Tror fremdeles at utviklingsmodellen til Linux er veien å gå for så store og kompliserte system som systemene til helsevesenet.

  • Liker 1
Lenke til kommentar

*snippet masse gode argumenter*

Svært lite handler altså om selve koden, selv om også kodere kan være jalla innimellom altså...

Tror nok at for detaljerte krav kan være et problem her. En må mer definere hva en ønsker å oppnå, og så levere med de lover og forskrifter en mener vil kunne ha en påvirkning. Det siste der har jeg opplevd mer enn en gang at utviklere av sensitive systemer ikke helt forstår eller har et forhold til. Det er derfor jeg ønsker å bryte ned utviklingen til samme modell som Linux utvikles etter. Det er en metode som tross alt har vist seg å fungere.

Lenke til kommentar

Tror nok at for detaljerte krav kan være et problem her. En må mer definere hva en ønsker å oppnå, og så levere med de lover og forskrifter en mener vil kunne ha en påvirkning.

 

Det du beskriver er rent fossefall. Fungerer ikke.
Lenke til kommentar

Det du beskriver er rent fossefall. Fungerer ikke.

Det går an å forholde seg til regelverk også i iterative utviklingsprosesser, vet du.

 

Og et formål man ønsker å oppnå er også til å leve med. Jeg vil vel nesten si det sånn at det er vanskeligere å lykkes uten ...

  • Liker 1
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...