Hvorfor elektronisk tinglysning startede som en katastrofe Hvordan kunne det være undgået? Hvorfor deres sagsbehandlingssystem blev lukket Søren Lauesen IT-University of Copenhagen E-mail: slauesen@itu.dk www.itu.dk/people/slauesen 2 Hvorfor rejsekortet blev 4 år forsinket Søren Lauesen IT-Universitetet i København slauesen@itu.dk www.itu.dk/people/slauesen Hvordan forbedring nedsatte produktiviteten (i begyndelsen?) Flere? Havarikommission 19 behandlinger 36 slags årsager 20 skader i 5 projekter 19 behandlinger og antal årsager de forhindrer 7 Problem-orienterede krav Se mere: Lauesen: 6 Pilot test Damage and damage 5 Tidlige prototyper og test causes in large IT 4 Juster plan ved overraskelser government projects 4 POC (Proof of concept) 3 Studer hvad der er og planlæg fremtiden 3 Scope management + function points 3 Overvåg resterende arbejde 2 Idriftsæt i flere omgange 2 Ekspertinddragelse 2 Lille arbejdsgruppe med beføjelser 1 Opfølgende undersøgelse 1 Undersøg teknologien grundigt 1 Tredje-part kan integrere 1 Planlæg lukningen tidligt 1 Kreative jurister 1 Overvåg forretningsaspekterne 1 Risikostyring efter bogen 1 Giv ledelsen IT-kompetencer 4 Årsager uden kendt behandling 51 Total Nogle årsager har to behandlinger 21 Gældsinddrivelse (Skat, EFI) Hvordan man spildte 600 M DKK på software og tabte gæld for 70.000 M DKK 11
Hvorfor deres sagsbehandlingssystem blev lukket 2
Polsag (Politiets sagsbehandling) Udviklet 2005-2012 Observerede skader Tid: 3,7 -> 7 år. Pris: SW 173 -> 354 M DKK. Interne omkostninger og drift: 213 M DKK. Forretning: Negativ. Ingen formål. Drift ville blive 5 gange dyrere. Brugervenlighed: Pilot-brugerne var meget frustrerede. Leverandørtab: 50+ M DKK. Bemærkede ikke stigende timeforbrug. Er det muligt? Svartider? fejl? dårlig kode? eller bare rygter? Status: Projekt lukket. Hvorfor? Analysefase A1 Politiet kunne ikke beskrive deres arbejdsprocesser - var fortrolige! A2 Hovedkravet var "som i dag men mere moderne". A5 Troede på standard ESDH system og SOA (snarere ERP?). A7 Alle fødesystemer straks (planlagde dog gradvis udbredelse - fint). A8 Planlagde ikke nye processer - kendte ikke engang de gamle. A9 Var det overhovedet muligt den vej? Anskaffelse B4 Forkert prisskøn. Baseret på 100 eksisterende simple (?) skærmbilleder. B5 Glemte at medregne pris på drift og vedligehold. 3
Design C6 På vores måde, ikke på leverandørens. Designede 100+ nye skærmbilleder med speciel funktionalitet. 300 eksisterende databasetabeller. Tilføjede 500. Programmering D1 Underleverandøren betalte selv de nye skærmbilleder. D2 System-integration dyrt og indviklet. Mange andre systemer skulle ændres. Idriftsættelse F1 Satte i drift med utilstrækkelig support. Hovedleverandør driftede, men kendte ikke underleverandørens system. Underleverandør måtte ikke ændre noget. F2 Kontrollerede ikke om systemet blev brugt som forventet -> Falske rygter om fejl og lange svartider. Ledelse G1 Forretningsmål aldrig nedskrevet. Ingen kendte dem undervejs. G3 Projektet voksede uden at nogen bemærkede det. G4 Pengene slap op og parterne skændtes. G7 Manglende ledelsesinvolvering - ingen forretningsperspektiv. G9 40 betjente designede skærmbilleder med udviklerne. Virkede ikke. 4
36 forskellige årsager i 5 projekter: Grønt: Også i Analysefase Bonnerup 2001 A1 Sætter sig ikke ind i brugernes behov. Skaber ikke win-win A2 Skriver ikke krav der dækker kundens behov A3 Beskriver løsningen i detaljer. Ingen spillerum til leverandøren A4 Kræver ind og tror det er gratis A5 Teknologier oversælges, fx SOA, web-baseret, workflow maskine A6 Flerleverandør-teknologi - så er vi leverandøruafhængige!? A7 Vil have det hele på engang, fx hele landet, eller alle slags gæld A8 Planlægger ikke de nye arbejdsprocesser A9 Tvivl om der findes en løsning, er der fx det nødvendige data? kan man opnå akceptable svartider? etc. A10 Overraskende regel-jungle Anskaffelse B1 Tror at loven forbyder fx at tale med leverandører eller lave pilotdrift der kan give nogle en fordel B2 Leverandør for optimistisk - den der lyver vinder B3 Kunden vurderer ikke løsningen, beder evt. leverandøren gøre det B4 Forkerte beregninger af udgifter B5 Glemmer eller ignorerer vigtige omkostninger 5
Design af løsningen C1 Sikrer ikke brugervenlighed, selv når man ved hvordan det gøres C2 Designer skærmbillederne for sent C3 Akcepterer kundens løsningsbeskrivelse uden at forstå den C5 Kan ikke se hvor langt leverandøren er C6 Vil have det på sin egen måde uden at se på leverandørens måde Programmering D1 Leverandøren akcepterer en dyr kravfortolkning selvom det er urimeligt D2 Overraskelser ved system-integration Test E1 Idriftsætter systemet med utilstrækkelig test Deployment F1 Idriftsætter systemet med utilstrækkelig support og uddannelse F2 Tjekker ikke om systemet bruges som forventet F3 Fejlvurderer brugernes hastighed 6
Ledelse G1 Ingen forretningsmæssige mål eller glemmer dem undervejs G2 Justerer ikke planen ved overraskelser, men tror resten kan speedes op G3 Projektet vokser uden at nogen opdager det G4 Ser ikke faren i øjnene, men bagatelliserer risikoen G5 Pengene slipper op og parterne skændes i stedet for at samarbejde G6 Høster gevinsten førend den er der, fx fyrer for tidligt G7 Manglende ledelse eller ekspertinddragelse G8 Overdreven ledelse eller ekspertinddragelse G9 For store styregrupper eller arbejdsgrupper G10 Overdreven brugerinddragelse 7
Årsagsprofiler Hvornår skete det? 10 Analysefase 5 Anskaffelse 5 Design 2 Programmering 1 Test 3 Idriftsættelse 10 Ledelse 36 I alt Årsager pr. projekt 17 etinglysning 12 Rejsekortet 20 Politiets sagssystem 15 Skat EFI, gældsinddrivelse 12 Patientjournal EPIC 76 I alt Hver årsag observeres i ca. to projekter Hvem gjorde det? 31 Kunden 11 Leverandøren 14 Konsulenten 5 Regeringen 61 I alt I mange tilfælde skyldes det to parter Hvilken slags fejl? 16 Ignoreret 3 Misforståelse 5 Fejlinformeret 6 Konflikt 12 Uvidenhed 5 Over gængs praksis 47 I alt Nogle årsager var af to slags 8
Flere? Havarikommission 19 behandlinger 36 slags årsager 20 skader i 5 projekter 19 behandlinger og antal årsager de forhindrer 7 Problem-orienterede krav Se mere: Lauesen: 6 Pilot test Damage and damage 5 Tidlige prototyper og test causes in large IT 4 Juster plan ved overraskelser government projects 4 POC (Proof of concept) 3 Studer hvad der er og planlæg fremtiden 3 Scope management + function points 3 Overvåg resterende arbejde 2 Idriftsæt i flere omgange 2 Ekspertinddragelse 2 Lille arbejdsgruppe med beføjelser 1 Opfølgende undersøgelse 1 Undersøg teknologien grundigt 1 Tredje-part kan integrere 1 Planlæg lukningen tidligt 1 Kreative jurister 1 Overvåg forretningsaspekterne 1 Risikostyring efter bogen 1 Giv ledelsen IT-kompetencer 4 Årsager uden kendt behandling 51 Total Nogle årsager har to behandlinger 9