Hvorfor elektronisk tinglysning startede som en katastrofe (selvom alle gjorde deres bedste) Søren Lauesen Januar 2012 IT-University of Copenhagen E-mail:

Præsentationer af emnet: "Hvorfor elektronisk tinglysning startede som en katastrofe (selvom alle gjorde deres bedste) Søren Lauesen Januar 2012 IT-University of Copenhagen E-mail:"— Præsentationens transcript:

1 Hvorfor elektronisk tinglysning startede som en katastrofe (selvom alle gjorde deres bedste) Søren Lauesen Januar 2012 IT-University of Copenhagen E-mail: slauesen@itu.dk www.itu.dk/people/slauesen

2 e-TL Banksys... 2. Elektronisk tinglysning (e-TL) – big-bang 2009 Borger DanID CVR Skat Matrikel... mv. Advokat Mægler TL medarb. 30% manuel Jan 2010: 60.000 sager venter over 50 dage 5 mio anmeldelser/år 2/s peak load Kunne det forudsiges? Næppe - så aldrig Big-Bang Opstart: 4000 fuldmagter Hvordan gør man? Hotline svar: 3-30 uger Overbelastning

3 3. Oversigt over e-TL projektet BehandlingstidFørStartSenere De heldige 70%5 dage1 min1 min De uheldige 30%15 dage2 mdr10 dage "Åbningstider"25%98%99,9% TidsforløbPlanFaktisk Udbudjuni 06 Kontraktdec 06 Bilbogjan 08nov 10 Tingbogmarts 08sept 09 Dokumentation Kravspec (413 krav)406 sider Kontrakt32 sider Tilbudca. 600 sider Løsninger, ændringer> 2000 Mio. 2006-16BudgetFaktisk IT-udvikling76103 Skanning161202 Andet3030 Udvikling ialt267335 Drift163163 Driftsbesparelser ?-163-163 Lønbesparelser-750-627 Nettogevinst-320-129 Fra 99.5 til 99.9% koster 10 mio pr. år? Pengene værd? Minus erstatninger Plus samfunds- mæssig gevinst

4 4. Årsag til overbelastning af TL medarbejdere 1.Flere fuldmagter end forventet – færre borgersignaturer. 2.Langt flere hotline-henvendelser – fra advokater og mæglere. 3.Lang tid om at opbygge rutine has TL medarbejdere – turde ikke trykke på slut-knappen. 4.Sidste papirpantebreve tinglyst af vikarer – mange fejl skal rettes. Heldigvis: Kun halvt så mange nye sager pga. finanskrisen. Stor succes med katastrofal start Endnu en IT-skandale? Nej, en organisatorisk skandale

5 1.Hvordan tinglyser man skøde på en ejerlejlighed? Muligheder: enfamiliebolig, andelslejlighed, landbrugsejendom, men ikke ejerlejlighed. Kur: Ring til hotline en time daglig i tre uger. Svar: Vælg enfamiliebolig - som i loven. 2.Er det gratis at udføre en prøvetinglysning, og hvor meget afprøver den? 3.Anmeldelse afvist. Men hvorfor? Prøv igen - håb på Jackpot? 4.Hvornår bliver sager udtaget til manuel behandling? (Nogle skrev "glædelig jul" i feltet meddelelser til tinglysningsmedarbejderen. Resultat: Sagen blev udtaget til manuel behandling - to måneders behandlingstid). 5. Manglende brugervenlighed - hotline overbelastes Hvad sagde kravene om brugervenlighed? Krav 153: Kvalitetssikring af brugervenlighed. Leverandøren skal under udviklingen kontrollere den eksterne portals brugervenlighed.... Tilbudsgiver skal beskrive hvordan. Svar på krav 153: Test med Rolf Molichs principper (tænke højt med tidlig prototype). Svar bilag 21, kvalitetssikring, dvs.: Testleder guider testdeltagerne igennem opgaverne, stiller uddybende spørgsmål, og hjælper hvor det er nødvendigt. Ændring 32, 30-03-2009: Brugervenlighedstest erstattes af en meget tæt dialog mellem [leverandørens og kundens eksperter] Ok, noget skal være hemmeligt, men... Ups !

6 6. Kravspec: Hvad skal systemet gøre - med brugerhistorier Anmeldelse af bodeling Hans og Grethe blev gift i 1989, men nu skal de skilles. De har i hele ægte- skabet boet i Hans' ejendom og de har aftalt at Grethe skal blive boende. Hans logger sig ind på www.e-tl.dk. Frem toner en velkomsttekst. Der er tekst og tegning for tingbogen over fast ejendom, bilbogen... Han kan se et ikon for informationscenter... Hans klikker på teksten for fast ejendom. Herefter får han vist et login-billede... Hans har sin digitale signatur lagret på sin PC... Han bliver bedt om at oplyse om han vil tinglyse eller forespørge på fast ejendom... og sin e-mail adresse... og om han skal arbejde med oplysninger om ejer, pant, servitutter eller andet. Han vælger ejer og bliver bedt om at oplyse om det er - endeligt skøde - endeligt skøde på flere ejendomme - skøde betinget af købesummens betaling - (og fire andre muligheder, herunder bodeling) I alt 5 A4-sider for dette eks. Teksten siger det ikke er krav. Færdigt system: 22 skærmbilleder for at tinglyse et skøde

7 7. Kravspec: Hvad skal systemet gøre - med use cases Use case A.5. Egentlig står der bare: 1.Bruger vælger en udfyldt anmeldelse 2.Systemet udfører en prøvetinglysning 3.Brugeren får resultatet Andre use cases: Udfyld anmeldelse Vedhæft fil Underskriv digitalt... Kontekst: Hvorfor ønsker han at kontrollere?

8 C1: Tinglys ejerskab Hyppighed:Få gange i borgerens liv Bruger:Almindelig borger 8. Med SL-07 skabelonen. Systemet skal støtte C1... Delopgaver og varianter: 1.Udfyld tinglysningsoplysninger (se data i kapitel D) 1a.Hent evt. en parkeret sag 2.Vedhæft evt. dokumenter 3.Prøvetinglys sagen og se hvad der evt. skal ændres. Prøvetinglys evt. igen. 3p.Hvad koster det? Også hvis der er fejl? 4.Giv betalingsinformation og send til tinglysning. 5.Underskriv det nødvendige. 6.Parker evt. sagen. Eksempler på løsning: Systemet markerer hvilke data der skal udfyldes. Systemet forklarer fejlen i borgerligt sprog. Priserne vises på forhånd. Systemet forklarer hvad der nu vil ske og hvor lang tid der vil gå. Systemet bruger digital signatur. Eksempel på computers del - ikke krav Udføres af bruger + computer Valgfri delopgaver og rækkefølge Dækker kontekst plus 6 use cases

9 e-TL DanID 9. Arkitektur, integration og SOA CVR Skat K1. Alt skal være SOA-XML-services internt såvel som eksternt. K2. Data må kun lagres ét sted - skal hentes i fødesystemet. K3. Systemet forventes baseret på eksisterende moduler. K4. Alle eksterne systemer har veldefinerede XML-snitflader. Hvorfor SOA? Leverandøruafhængighed? Hjælper ikke. XML Kontroller Problemer: Kræver 10-500 gange mere computerkraft. Leverandøren kan ikke tage ansvar for svartider og oppe-tider. Inkonsistens eller urimelig indskrænkning af leverandør-skaren. Alle på nær CPR var under omlægning. IT-præsteskabets vision? (Skal lovfæstes - så behøver vi ikke argumentere for den). Valgt løsning: Ingen intern SOA. Datareplikering de fleste steder. etc.

10 10. Risikoanalyse - et par tvivlsomme eksempler Risiko (tidligt 2007)Niv. 1-5 KonsekvensStatus, kommentar SOA er en umoden teknologi1Bruges hos SKAT Har kunden ringe IT erfaring?1DSS har stor erfaring [Ja med interne sys.] Leverandør-stab forsvinder [Google købte dem] 3Mindre tid til testStram projektstyring Snitflader til mange systemer3Systemerne er stabile (3-9-2009) Ved idriftsættelse viser der sig mangler ved brugervenligheden Manglende brugervenlighed Sagen er lukket. Sandsynlighed reduceret. (3-9-2009) Personalemangel hos TL 4Lang behand- lingstid DSS vurderer 5 dage inden big-bang

11 Dårlig bruger- forståelse Dårlig risiko- vurdering Dårlige usability teknikker State-of-the-art er utilstrækkelig Dårlig projektstyring Overbelastede medarb. Uventet mange fuldmagter BrugerfjendskIngen pilot test Uventet mange hotline opkald Lav medarb. produktivitet Fejl i seneste registreringer Dyre unødvendige krav Dårlige krav til brugergrænseflade Nøglemedarbejderne forsvandt Forstod ikke usability konsekvenser Holdt ikke øje med leverandør Forsinkelser Medarb. fyret og bevillinger skåret Usability test opgivet Pil fra årsag til virkning 11. Cause-effect

12 12. Senere i projektet Succes og nye problemer : 1.Man kan gå ind i sin bank og 30 min efter stå med 1 mio til disposition. Ikke muligt andre steder i verden. 2.Bilbogen i drift som big-bang nov. 2010. Uden problemer. Årsag: Man havde lært at sætte sig ind i brugernes faktiske behov. 3.Nyt krav til eTL: Store kunder i udlandet tror ikke på skærmprint - ser amatøragtigt ud. Svar: Beviset på ejerskab er i systemet ? 4.Nyt krav: Vi har 100+ sager i systemet. Kan ikke søge på tværs. (Er systemet er blevet jeres sagsbehandlingssystem?)