Risotto

Og dette betyr at man skal innrette sine anskaffelser som en rammeavtale.

En rammeavtale er en avtale mellom en eller flere oppdragsgivere og en eller flere leverandører, som har til formål å fastsette kontraktsvilkårene for de kontraktene som skal inngås i løpet av den perioden rammeavtalen varer. ...En konkurranse om en rammeavtale, dreier seg da i realiteten om retten til å kunne levere de aktuelle varene og tjenestene til oppdragsgiveren. Det gir også oppdragsgiveren en eller flere faste leverandører å forholde seg til i avtaleperioden. Dette er til fordel for begge parter, siden man i løpet av avtaleperioden kan utvikle et godt og verdifullt kundeforhold som begge parter drar nytte av.

Med rammeavtalen skal prosjektene, slik som Christin skriver, sikre at en eller flere brukergrupper får sine arbeidsrutiner realisert i løsningen på tvers av de tekniske komponenter.

Godt innlegg Christin. Jeg er enig i din fremstilling og analogier til byggeprosjekter. Men jeg er noe usikker på hvor mye utvikling det egentlig er i AKSON. Jeg tipper det meste arbeid består i anskaffelser, integrasjoner og forvaltning. Jeg er også enig i brukergruppevinklingen, der vi setter brukeren i sentrum og gradvis åpner opp for mer, men hvordan dette prinsippet kan overføres til statens standard avtaler, der man helst skal spesifisere det meste på forkant, kan muligvis være en forklaring til det som er gjort så langt.

... en risiko med agil metodikk er at teamene «kan bli for egenrådige og ende opp med å lytte mer til kundene enn til eierne» -> Umiddelbart høres det jo positivt ut. Jeg syns vi skal dyrke denne risikoen og fokusere på den verdifulle kundeopplevelsen og ja, vår egenrådighet er det mest handlekraftige vi har, la oss bruke den

En smidig artikkel. Den begynte som reaksjon på en påstand, ble til underveis, for nå var du jo begynt, og ender opp med en tynn konklusjon. Flott, du fikk levert. Neste gang så skriv et mandat til deg selv innen du begynner.

Helt enig! I konseptvalgutredningsrapporten fremgår det at risiko knyttet til gjennomføring har blitt vurdert innen 4 hovedgrupper:

_Styringsrisiko

Dette er risiko knyttet til beslutninger nasjonalt og lokalt for å iverksette og prioritere tiltaket innenfor de rammer som er vedtatt i styringsdokumentet.

_Definisjonsrisiko

Dette er risiko knyttet til hvilken funksjonalitet hvert enkelt konsept skal levere og omfatter fagstyring og styring av omfang og funksjonalitet

_Løsningsrisiko

Dette er risiko som kan oppstå i anskaffelse og konfigurering/utvikling av de løsningskomponenter som utgjør hvert enkelt konsept. Løsningsrisiko vurderer leverandørmarkedets evne til å levere funksjonalitet og brukerflater som dekker ulike brukeres behov, evnen til å etablere en leveranseorganisasjon, spesialisthelsetjenestens evne til å levere et felles grensesnitt i samhandlingen med løsningen(e), samt evnen til å etablere de nasjonale løsningene som skal understøtte samhandling

_Innføringsrisiko

Dette er risiko knyttet til mottakende organisasjons evne til å etablere nødvendig mottaksprosjekt for å gjøre lokale tilpasninger, integrasjoner, opplæring, konvertering samt tilpasninger av arbeidsprosesser

Virker som det er en premiss at løsningen skal bygges med grunnmur, plattformer og programvarer fra leverandørmarkedet og at løsningsrisikoen derfor er avgrenset til det formålet.

Smidig tilnærming har kanskje aldri vært et tema?

Konseptene (3) er differensiert ift. et ønsket fremtidig målbilde:

(K1) Lokale journaler, (K4) Nasjonal rammeavtale eller (K7) Nasjonal journal

Dernest er konseptene vurdert innen fem kategorier: Kvalitet, effektivitet, risiko, kostnad og nytte.

- > Hvordan man skal oppnå målbildet f.eks. med smidig tilnærming er ikke et valgkriterie.

Risiko er vurdert innen omfanget til informasjonssikkerhet: konfidensialitet, tilgjengelighet og integritet

- > Risiko relatert til implementering er ikke vurdert.

Trolig en konsekvens av inndelingen i 4 helseregioner. Legg så til samarbeid med 180+ kommuner. ~30% av budsjettet er vel til administrasjon, kontroll og styring fordi det er så mange interessenter.

Tipper utfordringen her er at kunden vil mye og forlanger både prislapp og leveransedato før oppstart, slik at de kan legge sine budsjetter.

Årsbudsjetter dreper smidig utvikling.

Man oppnår en mellomting, som består av stegvis tilnærming (fint det), men med fast omfang og fast leveransedato. Det er den gode gamle fossefallsmetoden forkledt som smidig og skalerbar.

Prisen er trolig kalkulert etter komplett grunnmur, plattformer og alle tjenester/moduler ferdigstilt. Alle gevinster forventes hentet hjem. Samtidig skal det utvikles prototyper som realiseres mens de bygges. Kravene endres fortløpende, teknologien fornyes og foreldes.

En ferge eller en bro kan jeg forstå må total beregnes innen oppstart, men med IT er vi så heldige at vi kan skalere og bygge løpende, mens det går trafikk.

Foreslår hellere at det leveres en skalerbar løsning med 1 modul som programmets første prosjekt.

En enkelt uttgave av EPJ/PAS som App på mobilen vil kunne løse dette.

At de finner feil i en test er vel ikke så rart.