Oplægget blev holdt ved InfinIT-arrangementet "Udbud og kravspecifikationer for procesorienterede digitaliseringsløsninger", der blev afholdt den 6. februar 2013.

1. Leverandørvalg med SL-07
Søren Lauesen, december 2012
IT-University of Copenhagen
E-mail: slauesen@itu.dk http://www.itu.dk/people/slauesen

2. 2. Traditionelle krav - løn og vagtplan på hospital
Krav 148: Systemet skal kunne registrere den daglige faktiske
arbejdstid for hver medarbejder. Klassisk
IEEE 830
Krav 475: Systemet skal kunne beregne regnskabsmæssige
konsekvenser af en given vagtplan i kroner og øre.
Absolutte krav? Kun krav 148. Vi kan leve uden krav 475.
Krav A's løsning B's løsning
Krav 148. Fang data via Indtast data fra
Registrer arbejdstid medarbejdernes afdelingens eksisterende
eksisterende adgangskort opslagstavle
Krav 475. Send vagtplan. Svar Interaktiv løsning: Vis med
Regnskabsmæssig indenfor 24 timer farvekoder hvor dyrt det er
konsekvens at placere medarbejder N
her på planen
Løsningen er
uanvendelig i praksis
Er kravet formelt opfyldt?
Tallene vises ikke
Efter kontraktunderskrift leverer A
opslagstavleløsningen i stedet?

3. 3. Hvad kan vi lære af det?
Hvad er bedst: God løsning til krav 148 og dårlig løsning til krav 475.
Eller omvendt?
5 års besparelse Værdi af A's løsning Værdi af B's løsning
Krav 148. Data via adgangskort: Indtast fra opslagstavle:
Registrer arbejdstid 10 mio 0 mio
Krav 475. Send vagtplan. Svar Interaktiv løsning med
Regnskabsmæssig indenfor 24 timer: farvekoder:
konsekvens 0 mio 800 mio
I alt 10 mio 800 mio
Kravopfyldelse er ikke ja/nej, men grader af værdi.
Absolutte/ufravigelige krav er uegnede.
Løsningen skal være en del af kontrakten.

4. 4. Skriv krav 475 som use case?
Hovsa-trigger.
Hvad bruges det
Use case 475: Beregn regnskabsmæssig konsekvens af vagtplan
Trigger: Brugeren vil beregne konsekvensen til og hvornår?
Precondition: Brugeren er logget på
1. Systemet viser en liste af vagtplaner
2. Brugeren vælger en vagtplan
3. Brugeren vælger "Beregn konsekvens"
4. Systemet beregner konsekvensen
5. Systemet viser konsekvensen
Exception: Ingen vagtplaner i listen Selvopfunden dialog.
Leverandør B må vrages.
Trivielle detaljer - forført af skabelonen.
Ingen værditilvækst. Er use cases krav?
Skrives, men bruges ikke
Use cases kan ikke fange problemer
med ukendt løsning – men her er de
forretningskritiske behov ofte.

5. 5. SL-07: Task descriptions. Støt task C1, C2 . . .
C2: Lav vagtplan
Hyppighed: Hver 14. dag. I nogle afdelinger . . .
Start: Når der er fred i vagten.
Slut: Når der bliver travlt.
Subtask og varianter: Eksempler på løsning:
1. Dan ny vagtplan. Automatisk ud fra sidste plan . . .
2. Registrer ferie. To slags ferie . . . Systemet kontrollerer feriereglerne.
2p. Nuv. problem: Små lapper Systemet har en tidshorisont på flere
med ønsker mange måneder frem. år.
3. Bemand vagter. Tjek rette Systemet foreslår bemanding af
kompetencer, ferie, overenskomster ubemandede vagter.
og undgå tillæg. Advarer om brudte regler og unødige
3p. Nuv. problem: Svært at gøre tillæg. Støtter "puslespillet" med undo
manuelt. Fejl og for mange tillæg. og flere forsøgsudgaver.
3a. Vikarer endnu ikke i systemet.
3b. Skaf medarb. fra anden afdeling. Viser ledige fra andre afdelinger.
4. Send planen til kommentering. En udskrift af planen er nok.
5. Parker planen eller frigiv den.
Udføres af menneske Eksempel på computers
plus computer del - ikke krav

6. 6. Leverandørsvar (typisk, men ikke eksemplarisk)
C2: Lav vagtplan
Hyppighed: Hver 14. dag. I nogle afdelinger . . .
Start: Når der er fred i vagten.
Slut: Når der bliver travlt.
Subtask og varianter: Tilbudt løsning:
1. Dan ny vagtplan. Automatisk ud fra sidste plan. OK.
2. Registrer ferie. To slags ferie . . . Systemet kontrollerer feriereglerne.
2p. Nuv. problem: Små lapper Op til to år frem.
med ønsker mange måneder frem.
3. Bemand vagter. Tjek rette Støttes. Se skærmbilleder i . . .
kompetencer, ferie, overenskomster
og undgå tillæg.
3p. Nuv. problem: Svært at gøre
manuelt. Fejl og for mange tillæg.
3a. Vikarer endnu ikke i systemet.
3b. Skaf medarb. fra anden afdeling. Ledige også fra andre hospitaler.
4. Send planen til kommentering. En udskrift af planen er nok.
5. Parker planen eller frigiv den.

7. 7. Kundens vurdering af løsning ved teknisk afklaring
C2: Lav vagtplan Samlet point: 0
Hyppighed: Hver 14. dag. I nogle afdelinger . . . (som i dag)
Start: Når der er fred i vagten.
Slut: Når der bliver travlt.
Subtask og varianter: Eksempler / løsning:
1. Dan ny vagtplan. Automatisk ud fra sidste plan . . .
2. Registrer ferie. To slags ferie . . . Systemet kontrollerer feriereglerne.
Nuv. problem: Små lapper med Kun 12 mdr ud i fremtiden.
ønsker mange måneder frem.
3. Bemand vagter. Tjek rette Systemet foreslår bemanding af
kompetencer, ferie, overenskomster ubemandede vagter.
og undgå tillæg. Tillægsberegning batch - 24 timer.
Nuv. problem: Svært at gøre Flere udgaver besværligt.
manuelt. Fejl og for mange tillæg.
3a. Vikarer endnu ikke i systemet. Kan vise ledige fra andre
3b. Skaf medarb. fra anden afdeling. hospitaler.
4. Send planen til kommentering.
5. Parker planen eller frigiv den.

8. 8. Forretningsmæssige mål og hvordan de opnås
C1 Månedlig timeregnskab til pers.afd.
Ikke hierarkisk
nedbrydning,
Bruger: Medarbejder i afdelingen
Bruger: Planlægger i afdelingen
C8 Registrer nye medarbejdere
men mange-til-
C3 Registrer faktisk arbejdstid
C5 Sygdom hos medarbejder
mange
Bruger: Personaleafdeling
C7 Ændringer af lønsedler
Task
C6 Kontroller vagtplaner
C2 Lav vagtplan
Forretningsmæssig værdi
C4 Byt vagter
Ansatte: 5000
Overarb.bet: 20% til 10%
Forretnings-
IT udgifter nu: 30 mio/år
mæssige mål
Sparede Mio DKK
Personaleafdeling: årsværk over 5 år
Automatiser nogle opgaver 7 15
Fjern fejlkilder 7 15
Overhold 120-dags reglen ?5 ? 10
Mindre trivielt arb. og stress (blød faktor)
Hospitalsafdeling:
Mindre overarbejdsbet. mv. (400) 800
Hurtigere vagtplanlægning 7 15
Bedre plankvalitet (blød faktor)
Lavere IT udgifter 50

9. 9. Forretningsproces – ikke hierarkisk nedbrydning
Proces 2: Behandlingsforløb
Start: Patienten henvises af egen læge eller kommer akut.
Slut: Patienten er helbredt eller . . .
Trin: Løsning:
1. Indskriv patienten C1: Indskriv inden ankomst
C2: Indskriv akut
2. Stil diagnoser C10: Udfør klinisk session
3. Planlæg behandling C10: Udfør klinisk session
4. Udfør behandling C10: Udfør klinisk session
5. Vurder resultat C10: Udfør klinisk session
6. Udskriv patient C3: Udskriv patient . . .

10. 10. Kravskabelon SL-07
A. Baggrund og vision, vejledning . . . H. Sikkerhed 50% genbrug
20% genbrug
H1. Login og adgangsret for brugere
B. Overordnede behov
H2. Sikkerhedsadministration
B1. Forretningsmæssige mål
H3. Sikring mod tab af data
B2. Early proof of concept
H4. Sikring mod utilsigtet brugeradfærd
B3, B4, B5. Tildelingskriterier mv.
H5. Sikring mod trusler
C. Tasks systemet skal støtte
I. Brugervenlighed og design 80%
C1. Indskriv patient 1% genbrug I1. Indlæring og effektivitet i daglig brug
C10. Udfør klinisk session . . .
I2. Tilgængelighed og Look-and-Feel
D. Data systemet skal anvende
J. Andre krav og leverancer
D1. Diagnoser 1% genbrug J1. Andre standarder der skal følges
D2. Diagnosetyper
J2. Uddannelse
D3. Ydelser . . .
J3. Dokumentation
80% genbrug
E. Andre funktionelle krav J4. Datakonvertering
E1. Systemgenerede hændelser J5. Installation
E2. Komplekse beregninger og regler
K. Kundens leverancer
E3. Udskrifter og rapporter 30% genbrug
E4. Udbygning af systemet L. Drift, support og vedligehold
L1. Svartider
F. Integration med eksterne systemer
L2. Tilgængelighed
90% genbrug
G. Teknisk it-arkitektur L3. Datalagring
G1. Brug af eksisterende HW og SW L4. Support
G2. Nyt hardware og software . . . L5. Vedligehold

11. 11. Minimumskrav og tildelingskriterier
Regler ved EU udbud:
1. Der skal være minimumskrav. Dårligere tilbud afvises.
2. Der skal beregnes ét godhedstal pr. tilbud. Det højeste tal er vinderen.
3. Leverandørerne skal kende beregningsmetoden på forhånd.
Problemer ved offentlige projekter:
4. Hvilke af de 1000 krav er minimum (ufravigelige)? Umuligt at afgøre.
5. Hvordan skal vi vægte eller prioritere 1000 krav?
Løsning:
6. Fastsæt minimum for kravområder i stedet for enkelt-krav.
7. Tildeling ud fra forretningsmæssig værdi.

12. 12. B3. Minimumskrav til elektronisk patientjournal
Point: -2 (ikke støttet), -1 (ubekvemt), 0 (som i dag), 1 (effektivt), 2 (meget effektivt)
Kravområde Min. point Lev. A Lev. B
C1-C4. Indskriv patient -2 1
C10. Udfør klinisk session (*) 0 1
C11-C14. Medicinering 0 2
D. Data. Vurderes via tasks N/A N/A
...
F10. Integrer med nyt system (*) 1 1
H1. Login og adgangsret 0 0
H2-H5. Anden sikkerhed -1 -1
I. Brugervenlighed (*) 0 1
J2. Uddannelse 0 0
J4. Datakonvertering 0 1
L1. Svartid (*) 0 0
* Vurderes også ved det tidlige bevis (proof of concept)

13. 13. Tildelingskriterie B4: Nettogevinst i mio kr. over 5 år
Forretningsmål Opf.grad Risiko 5-års værdi
5-års
poten-
A B A B A B
tiale
1. Effektiv støtte af klinikerne 1000 mio 0.5 30% 350
2. Reducer medicineringsfejl 250 mio 1.0 10% 225
3. Løbende procesforbedring 250 mio 1.0 40% 150
4. Mindre driftsomk (se omk.)
Bruttogevinst over 5 år 1500 mio 725
Nettogevinst over 5 år Lev. A Lev. B
Bruttogevinst over 5 år 725
Produktets pris 100
Kundens hardware-udgifter 50
Medarbejderuddannelse 28
Driftsudgifter over 5 år 100
Samlede omkostninger over 5 år 278
Nettogevinst for 5 år 447

14. 14. Tildelingskriterie B5: Vægtede point pr. mio kr.
Kravområde Point Point Vægtet Vægtet
Vægt A B A B
C1-C4. Indskriv patient 5 1 5
C10. Udfør klinisk session 50 1.5 75
C11-C14. Medicinering 15 2 30
D. Data. Vurderes via tasks (C) N/A
...
F10. Integrer med nyt system 15 1 15
H1. Login og adgangsret 0 0
H2-H5. Anden sikkerhed 0 -1
I. Brugervenlighed 10 1 10
J2. Bruger uddannelse (omk.) 0
J4. Datakonvertering 0 1
L1. Svartid 5 0
Vægtede point i alt 100 135
Vægt i forhold til skønnet
potentiale i mio kr.

15. 15. Resultat: Vægtede point pr. mio kr.
Lev. A Lev. B
Vægtede point i alt 135
Produktets pris 100
Kundens hardware-udgifter 50
Medarbejder uddannelse 28
Driftsudgifter for 5 år 100
Samlede omkostninger for 5 år 278
Point pr. mio kr. 0,49