Leverandørvalg med SL-07 af Søren Lauesen, ITU
-
Upload
infinit-innovationsnetvaerket-for-it -
Category
Spiritual
-
view
521 -
download
1
description
Transcript of Leverandørvalg med SL-07 af Søren Lauesen, ITU
Leverandørvalg med SL-07
Søren Lauesen, december 2012 IT-University of Copenhagen
E-mail: [email protected] http://www.itu.dk/people/slauesen
Krav 148: Systemet skal kunne registrere den daglige faktiske arbejdstid for hver medarbejder.
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.
2. Traditionelle krav - løn og vagtplan på hospital
Klassisk IEEE 830
Krav A's løsning B's løsning
Krav 148.
Registrer arbejdstid
Fang data via medarbejdernes eksisterende adgangskort
Indtast data fra afdelingens eksisterende opslagstavle
Krav 475.
Regnskabsmæssig konsekvens
Send vagtplan. Svar indenfor 24 timer
Interaktiv løsning: Vis med farvekoder hvor dyrt det er at placere medarbejder N her på planenLøsningen er
uanvendelig i praksis Er kravet formelt opfyldt? Tallene vises ikkeEfter kontraktunderskrift leverer A
opslagstavleløsningen i stedet?
Hvad er bedst: God løsning til krav 148 og dårlig løsning til krav 475.Eller omvendt?
3. Hvad kan vi lære af det?
5 års besparelse Værdi af A's løsning Værdi af B's løsning
Krav 148.
Registrer arbejdstid
Data via adgangskort:
10 mio
Indtast fra opslagstavle:
0 mio
Krav 475.
Regnskabsmæssig konsekvens
Send vagtplan. Svar indenfor 24 timer:
0 mio
Interaktiv løsning med farvekoder:
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. Skriv krav 475 som use case?
Use case 475: Beregn regnskabsmæssig konsekvens af vagtplanTrigger: Brugeren vil beregne konsekvensenPrecondition: Brugeren er logget på
1. Systemet viser en liste af vagtplaner2. Brugeren vælger en vagtplan3. Brugeren vælger "Beregn konsekvens"4. Systemet beregner konsekvensen5. Systemet viser konsekvensenException: Ingen vagtplaner i listen
Hovsa-trigger.Hvad bruges det til og hvornår?
Trivielle detaljer - forført af skabelonen. Ingen værditilvækst.
Selvopfunden dialog. Leverandør B må vrages.
Use cases kan ikke fange problemer med ukendt løsning – men her er de
forretningskritiske behov ofte.
Er use cases krav? Skrives, men bruges ikke
Subtask og varianter:
1. Dan ny vagtplan.
2. Registrer ferie. To slags ferie . . .
3. Bemand vagter. Tjek rette kompetencer, ferie, overenskomster og undgå tillæg.
3a. Vikarer endnu ikke i systemet.3b. Skaf medarb. fra anden afdeling.
4. Send planen til kommentering.
5. Parker planen eller frigiv den.
5. SL-07: Task descriptions. Støt task C1, C2 . . . C2: Lav vagtplanHyppighed: Hver 14. dag. I nogle afdelinger . . .Start: Når der er fred i vagten.Slut: Når der bliver travlt.
Eksempler på løsning:
Automatisk ud fra sidste plan . . .
Systemet kontrollerer feriereglerne.Systemet har en tidshorisont på flere år.
Systemet foreslår bemanding af ubemandede vagter. Advarer om brudte regler og unødige tillæg. Støtter "puslespillet" med undo og flere forsøgsudgaver.
Viser ledige fra andre afdelinger.
En udskrift af planen er nok.
Udføres af menneskeplus computer
Eksempel på computers del - ikke krav
2p. Nuv. problem: Små lapper med ønsker mange måneder frem.
3p. Nuv. problem: Svært at gøre manuelt. Fejl og for mange tillæg.
Subtask og varianter:
1. Dan ny vagtplan.
2. Registrer ferie. To slags ferie . . .
3. Bemand vagter. Tjek rette kompetencer, ferie, overenskomster og undgå tillæg.
3a. Vikarer endnu ikke i systemet.3b. Skaf medarb. fra anden afdeling.
4. Send planen til kommentering.
5. Parker planen eller frigiv den.
6. Leverandørsvar (typisk, men ikke eksemplarisk)C2: Lav vagtplanHyppighed: Hver 14. dag. I nogle afdelinger . . .Start: Når der er fred i vagten.Slut: Når der bliver travlt.
Tilbudt løsning:
Automatisk ud fra sidste plan. OK.
Systemet kontrollerer feriereglerne.Op til to år frem.
Støttes. Se skærmbilleder i . . .
Ledige også fra andre hospitaler.
En udskrift af planen er nok.
2p. Nuv. problem: Små lapper med ønsker mange måneder frem.
3p. Nuv. problem: Svært at gøre manuelt. Fejl og for mange tillæg.
Subtask og varianter:
1. Dan ny vagtplan.
2. Registrer ferie. To slags ferie . . .
3. Bemand vagter. Tjek rette kompetencer, ferie, overenskomster og undgå tillæg.
3a. Vikarer endnu ikke i systemet.3b. Skaf medarb. fra anden afdeling.
4. Send planen til kommentering.
5. Parker planen eller frigiv den.
7. Kundens vurdering af løsning ved teknisk afklaring
Eksempler / løsning:
Automatisk ud fra sidste plan . . .
Systemet kontrollerer feriereglerne.Kun 12 mdr ud i fremtiden.
Systemet foreslår bemanding af ubemandede vagter. Tillægsberegning batch - 24 timer.Flere udgaver besværligt.
Kan vise ledige fra andre hospitaler.
Nuv. problem: Små lapper med ønsker mange måneder frem.
Nuv. problem: Svært at gøre manuelt. Fejl og for mange tillæg.
Samlet point: 0(som i dag)
C2: Lav vagtplanHyppighed: Hver 14. dag. I nogle afdelinger . . .Start: Når der er fred i vagten.Slut: Når der bliver travlt.
8. Forretningsmæssige mål og hvordan de opnås
Personaleafdeling:Automatiser nogle opgaver Fjern fejlkilderOverhold 120-dags reglenMindre trivielt arb. og stress
Hospitalsafdeling:Mindre overarbejdsbet. mv.Hurtigere vagtplanlægningBedre plankvalitet
Lavere IT udgifter
Bru
ger:
Pla
nlæ
gger
i af
delin
gen
C1M
åned
lig ti
mer
egns
kab
til pe
rs.a
fd.
C2La
v va
gtpl
an
Bru
ger:
Med
arbe
jder
i af
delin
gen
C3Re
gist
rer f
aktis
k ar
bejd
stid
C4By
t vag
ter
C5Sy
gdom
hos
med
arbe
jder
Bru
ger:
Per
sona
leaf
delin
gC6
Kont
rolle
r vag
tpla
ner
C7Æ
ndrin
ger a
f løn
sedl
erC8
Regi
stre
r nye
med
arbe
jder
e
Forretnings-mæssige mål
Task
Forretningsmæssig værdiAnsatte: 5000Overarb.bet: 20% til 10%IT udgifter nu: 30 mio/år
Sparede Mio DKKårsværk over 5 år
7 15 7 15
? 5 ? 10(blød faktor)
(400) 800
7 15(blød faktor)
50
Ikke hierarkisk nedbrydning,
men mange-til-mange
Trin: Løsning:1. Indskriv patienten
2. Stil diagnoser3. Planlæg behandling4. Udfør behandling5. Vurder resultat6. Udskriv patient
9. Forretningsproces – ikke hierarkisk nedbrydning
Proces 2: BehandlingsforløbStart: Patienten henvises af egen læge eller kommer akut.Slut: Patienten er helbredt eller . . .
C1: Indskriv inden ankomstC2: Indskriv akutC10: Udfør klinisk sessionC10: Udfør klinisk sessionC10: Udfør klinisk sessionC10: Udfør klinisk sessionC3: Udskriv patient . . .
10. Kravskabelon SL-07
A. Baggrund og vision, vejledning . . .
B. Overordnede behovB1. Forretningsmæssige målB2. Early proof of conceptB3, B4, B5. Tildelingskriterier mv.
C. Tasks systemet skal støtteC1. Indskriv patientC10. Udfør klinisk session . . .
D. Data systemet skal anvendeD1. DiagnoserD2. DiagnosetyperD3. Ydelser . . .
E. Andre funktionelle kravE1. Systemgenerede hændelserE2. Komplekse beregninger og reglerE3. Udskrifter og rapporterE4. Udbygning af systemet
F. Integration med eksterne systemer
G. Teknisk it-arkitekturG1. Brug af eksisterende HW og SWG2. Nyt hardware og software . . .
H. SikkerhedH1. Login og adgangsret for brugereH2. SikkerhedsadministrationH3. Sikring mod tab af dataH4. Sikring mod utilsigtet brugeradfærdH5. Sikring mod trusler
I. Brugervenlighed og designI1. Indlæring og effektivitet i daglig brugI2. Tilgængelighed og Look-and-Feel
J. Andre krav og leverancerJ1. Andre standarder der skal følgesJ2. UddannelseJ3. DokumentationJ4. DatakonverteringJ5. Installation
K. Kundens leverancer
L. Drift, support og vedligeholdL1. SvartiderL2. TilgængelighedL3. DatalagringL4. SupportL5. Vedligehold
20% genbrug
1% genbrug
1% genbrug
50% genbrug
80%
80% genbrug
90% genbrug
30% genbrug
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. B3. Minimumskrav til elektronisk patientjournal
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
Point: -2 (ikke støttet), -1 (ubekvemt), 0 (som i dag), 1 (effektivt), 2 (meget effektivt)
* Vurderes også ved det tidlige bevis (proof of concept)
13. Tildelingskriterie B4: Nettogevinst i mio kr. over 5 år
Forretningsmål 5-års poten-tiale
Opf.grad Risiko 5-års værdi
A B A B A B
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. Tildelingskriterie B5: Vægtede point pr. mio kr.Kravområde
VægtPoint
APoint
BVægtet
AVægtet
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. 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