MOX et forretningsmønster for fagsystemers udveksling af hændelser Anvendelse af OIO-standarderne sag, dokument, organisation og klassifikation til at opnå sammenhæng og danne grundlag for automatiseringer mellem fagsystemer(herunder ESDH)igennem udveksling af hændelsesbeskeder. 1
Denne rapport udgør et foreløbigt udkast til rapportering fra en arbejdsgruppe nedsat af Kommunernes It-Arkitekturråd. Rapporten specificerer, hvordan eksisterende it-systemer med sags- og dokumenthåndtering må udvides for at processer i et system kan udveksle hændelser med processer i andre systemer. Specifikationen af udvidelsen er angivet på forretningsniveau, med anvendelse af de begreber, som er indeholdt i OIO standarderne Sag, Dokument, Klassifikation og Organisation. Implementeringen i systemet er her skitseret som en agent, der fx gør brug af eksisterende servicesnitflader på systemet. Dette udelukker ikke andre implementeringer. Kommunerne har behov for en udvikling, hvor stadig flere af de eksisterende systemer udvides med sådanne egenskaber, idet dette åbner for automatisk integration af processer. Rapporten behandler ikke de øvrige integrationsformer i den kommunale rammearkitektur, fx integration via servicekald mellem løsninger, eller integration af brugergrænser. Versionsoplysninger Version 0.76 (indeværende version) Dokumentet har indarbejdet reviewkommentarer fra 1. og 2. review i KL/KOMBIT arkitekturstab. Dokumentet er ikke koordineret i detaljer med udkastet til scope for en kommunal beskedfordeler, som KL og KOMBIT for nylig har lagt til eksternt review. De to dokumenter vil være fuldt koordineret i næste udgave på baggrund af kommuners og it-leverandørers kommentarer til begge dokumenter, forventeligt i september 2012. Version 0.7 Arbejdsgruppens oprindelige udkast KL, 6. juli 2012 Rasmus Vandkjær Rasmussen, Frederikshavn Kommune Marc David Martin, Horsens Kommune David Møller, Svendborg Kommune Michael Breuning, Odense Kommune Martin Scheil-Corneliussen, Hjørring Kommune Erik Helweg-Larsen, KL Nikolaj Skovmann Malkov, KL 2
Indholdsfortegnelse 1 Indledning... 5 1.1 Arbejdsgruppens arbejdsform, specifikationens status og den overordnede tidsplan.. 5 1.2 Kommunerne tager ansvaret i fællesskab... 6 1.3 Læsevejledning... 6 2 MOX som løsningskoncept for integration og automatisering... 7 2.1 MOX er et koncept for udveksling af hændelsesbeskeder mellem it-systemer.... 7 2.2 OIO Standarderne og beskeder... 9 2.3 Procesintegration... 10 2.4 Perspektiver muligheder og begrænsninger... 11 3 MOX anvendt på udvalgte kommunale arbejdsgange... 13 3.1 Ansætter medarbejder... 13 3.1.1 Arbejdsgangen for rekrutterer og ansætter medarbejder (as-is)... 13 3.1.2 Arbejdsgangen for rekrutterer og ansætter medarbejder (to-be)... 15 3.2 Udveksler dokumentation mellem myndigheder... 27 3.2.1 Arbejdsgangen for udveksling af dokumentation mellem myndigheder (as-is)... 27 3.2.2 Arbejdsgangen for udveksling af dokumentation mellem myndigheder (to-be).. 29 3.3 Dokumentation af byggesag... 34 3.3.1 Arbejdsgangen for dokumentation af byggesag (as-is)... 35 3.3.2 Arbejdsgang for dokumentation af byggesag (to-be)... 36 3.4 Distribution af klassifikationsoplysninger... 41 3.4.1 Arbejdsgang for distribution af klassifikationsoplysninger (as-is)... 41 3.4.2 Arbejdsgang for distribution af klassifikationsoplysninger (to-be)... 43 3.5 Konvertering af sager og dokumenter fra et ESDH-system til et andet ESDH-system 45 3.5.1 Arbejdsgange for konvertering af sager og dokumenter (as-is)... 45 3.5.2 Arbejdsgang for konvertering af sager og dokumenter (to-be)... 46 3
MOX er en metodisk anvisning til, hvordan kommunerne med de allerede eksisterende systemer og standarder, kan opnå forbedret og billigere integration og automatisering indenfor sag- og dokument området. Rapporten giver en række eksempler på, hvordan man i driftmiljøet for eksisterende fagsystemer med MOX nemt kan tilknytte en agent, der anvender fagsystemets eksisterende grænseflader og hjælper med at afvikle en eller flere processer og udveksle beskeder. MOX processerne er standardiserede, og med den foreslåede agent i driftmiljøet kan et eksisterende system hjælpes til at afvikle de standardiserede processer automatisk som reaktion på hændelser fra andre processer. MOX konceptet vil i efteråret 2012 blive prøvet af i en række konkrete pilotprojekter i samarbejde med kommuner og leverandører. 4
1 Indledning Specifikation af MOX til automatisering på Sag og Dokumentområdet er udarbejdet af en arbejdsgruppe under Kommunernes It-Arkitekturråd i løbet af perioden januar maj 2012. Navnet MOX er et akronym for Messages, altså beskeder, OIO-standarder for Sag og Dokument og X-change, altså udveksling. Baggrunden for gruppens arbejde med specifikationen er, at de fællesoffentlige standarder for Sag og Dokument siden 2009 har været tilgængelige som et redskab til at lette integrationen mellem ESDH- og fagsystemer. Med udgangspunkt i konkrete arbejdsgange har opdraget været at identificere et mønster for integrationer og dermed muliggøre automatiseringer af de administrative procedurer. Specifikationen er en metodisk anvisning af, hvordan man ved hjælp af OIO standarderne for Sag og Dokument og brug af beskeder kan realisere de gevinster, der ligger i at automatisere administrative procedurer, som en medarbejder udfører i dag - f.eks. journaliserer dokument, opretter sag, fremfinder sag, overholder frist, sender brev og fordeler indkommende post. De administrative procedurer er i deres natur en uundgåelig del af enhver opgave en kommune udfører. Eksempelvis at ansætte en ny medarbejder, behandle en byggesag, modtage en ledig i jobcenteret, udarbejde en lokalplan og alle de andre opgaver kommunerne udfører. Isoleret set er de administrative procedurer ikke voldsomt tidskrævende. Til gengæld gentages de igen og igen og igen. Hver eneste dag, året rundt og af et stort antal medarbejdere. Dermed bliver det samlede tidsforbrug meget stort, selvom den enkelte handling ikke er det. Der ligger altså store gevinster ved at automatisere så mange af de administrative procedurer som muligt. Udfordringen i dag er, at der er dårlig sammenhæng imellem de forskellige systemer, der tilsammen udfører de kommunale arbejdsgange. MOX giver et bidrag til at skabe sammenhæng ved hjælp af OIO standarderne for Sag og Dokument og beskeder. Den fælleskommunale rammearkitektur anviser tre generelle integrationsformer mellem itsystemer: Udveksling af hændelsesbeskeder, kald af data eller funktionalitet, samt integration af brugergrænseflader. Arbejdsgruppen har fokuseret på den førstnævnte integrationsform, som generelt er dårligst understøttet af eksisterende fagsystemer mv. 1.1 Arbejdsgruppens arbejdsform, specifikationens status og den overordnede tidsplan Det overordnede flow i arbejdsgruppens arbejde er, at vi tager udgangspunkt i de overordnede strategiske målsætninger, arbejder med forretningen forstået som de konkrete kommunale arbejdsgange og administrative procedurer og først derefter kigger på, hvordan den konkrete tekniske løsning skal udformes. Arbejdsgruppen har i arbejdet taget udgangspunkt i en vision om, at arbejdet skal bidrage til bedre økonomi i kommunerne, være med til at skabe forudsætningerne for øget konkurrence, højne kvaliteten og eksperimentere med at skabe nye samarbejdsformer mellem det offentlige og private leverandører. For at føre visionen ud i livet har vi analyseret en række konkrete kommunale arbejdsgange, der alle i dag har de ovennævnte karakteristika med dårlig sammenhæng og høj grad af manuel udførsel af de administrative procedurer. Specifikationen 5
af MOX er en standardiseret metode til at skabe sammenhæng i den kommunale forretning på Sag og Dokumentområdet. I slutningen af maj 2012 har arbejdsgruppen præsenteret de foreløbige resultater for nøglepersoner i de deltagende kommuner. Konceptet blev modtaget positivt, og der var interesse for at medvirke i det videre arbejde. Konceptets muligheder og begrænsninger blev belyst. Flere nøglepersoner pegede på, at en gennemførelse af konceptet fordrer en stærk governance og tæt kontakt med leverandørerne. Først når den færdige specifikation foreligger, kan vi med den i hånden indlede en dialog med markedet om, hvad det kræver at føre ideerne ud i livet og prøve dem af i praksis i konkrete proof-of-concepts. Specifikationen af MOX er et ufærdig produkt. Primo juli 2012 løber det igennem en reviewproces i KL og KOMBIT s arkitekturstab, hvorefter det præsenteres for kommuner og leverandører i en åben høring. På mødet den 12. september 2012 behandler Kommunernes It- Arkitekturråd specifikationen, og i efteråret bliver konceptet prøvet at i samarbejde med konkrete leverandører og kommuner. Processen omkring afprøvning og planlægning heraf kommer til at foregå i størst mulig åbenhed, så alle interesserede får mulighed for at byde ind. På den lidt længere bane er planen, at de høstede erfaringer er tilstrækkelige til, at MOX processer kan implementeres i de første pilotkommuner 2013, hvorefter det kan tilbydes resten af kommunerne fra 2014. Den formelle forankring for arbejdsgruppen er som nævnt under Kommunernes It- Arkitekturråd. Projektet Sager på tværs af it-løsninger og organisatoriske skel indgår i det tværgående rammearkitektur-initiativ 6.1 under handlingsplanen for den fælleskommunale digitaliseringsstrategi - det har kommunernes brug af standarderne for Sag og Dokument som indsatsområde, og sørger for at samle op på arbejdsgruppens resultater og bringe dem videre. Da projektet indgår i det samlede rammearkitekturarbejde og anvender en række fælles forretningsservices og støttesystemer herfra, vil specifikationen blive koordineret hermed. 1.2 Kommunerne tager ansvaret i fællesskab MOX er et eksempel på, at kommunerne i fællesskab igennem Kommunernes It-Arkitekturråd tager ansvar for at drive den kommunale digitalisering fremad. Her er den specifikke udfordring sammenhæng på Sag- og Dokumentområdet ved hjælp af udveksling af hændelsesbeskeder. Det er et arbejde, der ikke naturligt varetages af markedet eller andre, medmindre der kommer en tydelig kommunal efterspørgsel med vilje til at betale for leverandørernes investeringer. Det er altså med andre ord et område, hvor der også er brug for, at kommunerne selv tager initiativ. MOX bliver løbende afstemt og koordineret med øvrige aktiviteter i regi af KOMBIT og KL. Arbejdsgruppen har sørget for, og vil løbende sørge for, at bringe resultaterne af arbejdet videre til gavn for de øvrige initiativer og projekter og selv blive beriget og indrette os efter andres resultater. 1.3 Læsevejledning Afsnit 2 er en overordnet beskrivelse af konceptet MOX, og hvordan udveksling af hændelsesbeskeder adskiller sig fra de mere udbredte integrationsformer som servicekald og integration af brugergrænseflader. Det bliver beskrevet, hvordan MOX indeholder en række generiske, logiske byggeblokke - her beskrevet på forretningsniveau - der kan kombineres på 6
forskellige måder og dermed på standardiseret vis kan inspirere implementeringen af løsninger på helt konkrete integrationsudfordringer. I afsnit 3 bliver MOX anvendt analytisk på de konkrete kommunale arbejdsgange, der har været genstand for arbejdsgruppens analytiske arbejde i forbindelse med udarbejdelsen af specifikationen. De enkelte arbejdsgange er her delt op i en konkret beskrivelse af udfordringen as-is, som den ser ud i en kommune i dag, og et design af arbejdsgangen to-be med MOX, der kan illustrere det forretningsmæssige svar på de skitserede udfordringer. Specifikationen præsenterer MOX som en skitseret model til det samlede forretningsmæssige indhold og indeholder ikke mellemregningerne i form af metodeovervejelser m.v. Som bilag til rapporten er der en beskrivelse af metode, begreber, symbol m.v., og en beskrivelse af de byggeblokke der tilsammen udgør MOX. 2 MOX som løsningskoncept for integration og automatisering 2.1 MOX er et koncept for udveksling af hændelsesbeskeder mellem itsystemer. Det består af følgende dele: Besked baseret på OIO standarderne Agent i betydningen en beskedagent, der, på basis af beskeder, udfører en proces til hjælp for et it-system, og som også kan fungere som adapter mellem et it-systems format og det standardiserede udvekslingsformat. Beskedfordeler der fordeler beskeder til agenter Figur 1 MOX konceptets dele 7
Konceptet er i denne sammenhæng afgrænset til at håndtere administrative processer og objekter fra OIO standarderne for sag og dokumentområdet: Organisation, Klassifikation, Sag og Dokument og de generelle egenskaber herfor. En besked vedrører et objekt og udtrykker en tilstandsændring for objektet. F.eks. at et dokument er registreret i en dokumentservice, som typisk er realiseret fysisk i et fagsystem. En agent er en tilføjelse til et eksisterende system og kan udføre en proces med beskeden som input. Når den har gennemført sin proces, giver den besked herom. Hvis den ikke kan gennemføre sin proces, giver den også besked. Beskedernes indhold og opbygning overholder OIO standarderne og anbefalinger for en generel hændelsesbesked. En MOX proces er en standardiseret proces, der udfører en specificeret afgrænset opgave på et objekt på basis af en standardiseret MOX besked. En specificeret MOX proces kan driftmæssigt afvikles i en vilkårlig agent, hvis det tilknyttede it-system, der afvikles i samme driftmiljø kan håndtere den pågældende opgave. Figur 2 Traditionel integration Per definition indebærer begrebet integration, at it-systemer forbindes med de it-systemer, som de skal arbejde sammen med f.eks. udveksle information eller udføre processer sammen med. Der kan være tale om både standardiserede snitflader og proprietære snitflader. Men omkostningerne ved at udskifte et it-system, der er integreret med andre, kan være mere eller mindre omkostningsfyldt, afhængigt af hvordan integrationen implementeres. 8
Figur 3 MOX integration Forslaget i MOX integration er, at hvert it-system, hvad angår Sag- og Dokument, integrerer til samtlige øvrige it-løsninger via en agent. Denne agent udveksler beskeder med en beskedfordeler. Agenten kan udvikles af it-systemets leverandør eller en udvikler med kendskab til it-systemets grænseflader, og den idriftsættes tæt på det enkelte it-system mv.. 2.2 OIO Standarderne og beskeder OIO standarderne for Sag og Dokument er beskrevet på digitaliser.dk og bliver ikke gengivet i dette dokument. Standarderne er en specifikation af et serviceinterface, men siger intet om dets anvendelse til udveksling af hændelsesbeskeder mellem fagsystemer og ESDH mv. det er dette, som MOX skal råde bod på. Et serviceinterface består af en specifikationsmodel (objektmodel) og et antal operationer (opret, ret, slet, læs, søg, list, import, passiver), som bruger specifikationsmodellen i deres input-output struktur (xml-skemaer). Operationerne arbejder på et objekt ad gangen med objektets attributter, tilstande og relationer. Søg operationen anvender et søgeudtryk som input og dette er en delvis udfyldt struktur, hvormed man kan filtrere objektforekomster. Den returnerer alene id for de objekter, der er fremfundet. List operationer kan liste de objekter, der er fremfundet med deres attributter, tilstande og relationer. Sammenhængen mellem standarderne og de beskeder, som et fagsystem skal anvende ved integration via hændelsesbeskeder, er vigtig. Vores fokus er på automatisering af processer og især automatisering på tværs af it-systemer (procesintegration) via hændelsesbeskeder, som er en af de tre overordnede integrationsformer jf. rammearkitekturen. Der er således behov for at præcisere den information, som bæres af de fysiske beskeder. Sigtet med MOX er således ikke at præcisere, hvordan standarderne finder anvendelse i forhold til kald mellem løsningerne (SOA) eller i forhold til integration på brugergrænsefladen, men alene at beskrive indhold af beskeder i hændelsesintegrationen. 9
En MOX slutbesked indeholder information om et objekt. Beskeden dannes, når objektet er udsat for en ændring en registrering - altså en udgave af objektet, dets attributter, tilstande og relationer. Der er behov for, at fagsystemer (herunder ESDH) kan danne en sådan besked og dele den med omverdenen, hvis det er relevant. En MOX startbesked indeholder de samme oplysninger, nu blot set fra det fagsystem (eller ESDH), som lytter efter hændelser, der skal sætte deres processer i gang. Ofte vil en startbesked være modtaget via en beskedfordeler, der har modtaget den som slutbesked fra en anden proces og vil derfor indeholde den samme information. Når en agent, der tilfører fagsystemet beskedegenskaber, skal udføre en MOX standardproces tæt på fagsystemet, vil det typisk være som serviceanvender af et eksisterende serviceinterface på fagsystemet. Det er MOX processens ansvar, at bruge startbeskedens informationer til at udføre operationen. Derved opnår man, at fagsystemet via agenten fremstår rustet til at integrere sine processer via hændelsesbeskeder. En besked bør som udgangspunkt ikke have en direkte modtager. Med det menes, at den der udsteder slutbeskeden ikke skal behøve at vide, hvem der har brug for at reagere på den. En besked bør generelt udveksles via en beskedfordeler, hvor forskellige aktører kan tegne et MOX abonnement. Et abonnement er et søgeudtryk på en objekttype 1. For at generelle beskedfordelere kan håndtere hændelsesbeskeden, lægger agenten den forretningsmæssige hændelsesbesked udvidet med en række besked-metadata i en generel besked, som er beskrevet i anbefaling vedr. generel hændelsesbesked 2, og som muliggør den tekniske udveksling af beskeder via beskedfordelere i fagsystemets omverden. En generel hændelsesbesked er et beskedformat, som kan anvendes ved overførsel af hændelsesbeskeder mellem it-systemer. Det generelle betyder, at det kan bruges bredt for alle hændelser uanset fagområde, sektor eller konkret hændelse. Agenten skal kunne tilføje sådanne beskedmetadata i grænselaget imellem den specifikke hændelsesbesked (den egentlige forretningshændelse) og transportlaget (adressering, protokol og wireformat). 2.3 Procesintegration Ovenstående figur 1 illustrerer, hvad der kan opnås, såfremt fagsystemer implementerer agenter, der tilfører dem MOX-processerne: De to system-processer i henholdsvis fagsystem A og fagsystem B (MOX Proces A og MOX Proces B) interagerer ved, at slutbesked fra A indgår som startbesked i B. A afleverer sin slutbesked til en beskedfordeler, og B skal have tegnet et abonnement for at få beskeden. Beskeden bliver ikke ændret fra A til B. Det er altså abonnementet, der udtrykker en sammenhæng mellem processerne. Men abonnementet tegnes ikke af processen men af dens bruger, repræsenteret ved de(n) myndighed(er), der forvalter det modtagende fagsystem. Mønsteret illustrerer hensigten ved hændelsesintegrationen, at den samme proces kan udføre sin opgave for forskellige brugere baseret, igangsat af relevante forretningshændelser. 1 Der er pt. ikke et 1-1 match mellem beskedfordeler som omtalt her og KOMBIT s scope dokumentet for beskedfordeler. 2 http://digitaliser.dk/resource/446592 Anbefaling af en generel hændelsesbesked 10
MOX procesbrugeren (abonnenten, typisk et fagsystem herunder ESDH) kan tegne abonnement, ved at sende et abonnement (søgeudtryk) til den beskedfordeler, han ønsker at modtage beskeder fra. Abonnementet tegnes, når abonnenten er klar til at modtage beskeder, og der sendes en opsigelse, når den ikke mere er klar. Beskeder er i denne sammenhæng asynkrone og kan sættes i kø, hvis abonnenten ikke kan modtage dem. Et abonnement kan potentielt omhandle alle typer af objekter, som abonnenten kan behandle, dvs. potentielt alle objekter i abonnentens begrebsmodel. Beskedfordeleren skal gemme abonnementet og afprøve det, når den modtager en besked. Er søgeudtrykket opfyldt - udført på det objekt beskeden indeholder, sendes beskeden til abonnenten. En abonnent er en systembruger, som skal være en kendt aktør i organisation. En bruger har altid en relation til et eller flere it-systemer. En bruger kan også være en system-bruger. 2.4 Perspektiver muligheder og begrænsninger Er MOX et paradigmeskift eller er det blot endnu en integration, der ikke indfrier løfterne? Hvad skal der til, for at det kan gennemføres? Vil leverandører og kommuner være med, og er der den rigtige governance, der kan gennemføre det? Kan man overhovedet basere sig på beskeder, når der endnu ikke er en beskedfordeler. Er der flere beskedfordelere eller kun én? Der er mange spørgsmål, der endnu ikke er svar på. Men spørgsmålene kan sætte nogle ting på dagsordenen. Mulighederne i MOX er flere: It-systemets interface indkapsles via den tilførte agent i en standard MOX proces. En proces starter med og slutter med en MOX besked. En besked fra en proces kan igangsætte en anden proces. Processer kan udføres på tværs af systemer. Man kan udskifte et system uden at skifte proces. Man kan ændre en proces uden at skifte system. Man kan tilføje nye systemer uden påvirkning af eksisterende systemer. Man bevarer investering i eksisterende systemer. Man kan automatisere processer. Forslaget i MOX er, at leverandørerne af fagsystemer, herunder ESDH, udvikler en agent til deres system og tilbyde de beskrevne egenskaber heri. For at leverandørerne kan se et rationale for denne investering, er der behov for, at kommunerne stiller krav om MOX integration i forbindelse med nye anskaffelser. Men leverandørerne vil miste en indtjening på integration og vi håber, at det bliver brugt på forbedring af systemernes kernefunktionalitet. Pilotprojekterne skal også bidrage til, at vi kan opstille en business case for, hvad det er for en investering, der vil kræves for at implementere MOX. Vi forestiller os, at et af de første pilotprojekter vil fremstille en beskedfordeler og en agent, der kan stilles til rådighed for leverandørerne og for kommuner, der vil prøve selv. Beskedfordelerens opbygning vil ligne agentens opbygning den afvikler en standard proces op mod et interface, der håndterer et abonnement. Vi forestiller os, at der er behov for flere beskedfordelere, som kan abonnere på hinandens beskeder. Hovedparten af beskeder vil bruges indenfor egen organisation og indenfor organisationens sikkerhedsdomæne. 11
Selve implementeringen af kommunikation mellem en agent og en beskedfordeler, bør baseres på de aktuelle teknologiske muligheder og de teknologier, som anvendes af leverandørerne. Disse spørgsmål vil vi diskutere med leverandørerne. Kan man bruge beskeder til andet end integration? Vi forestiller os, at beskeder kan tilflyde agenter, der overvåger end-to-end processer, så der udsendes en besked, hvis processen går i stå, forsinkes eller på anden måde afviger fra et forudbestemt mønster. MOX arkitekturen er naturligvis ikke blot relevant for Sag- og Dokument-området, men har bredere relevans. Det er bl.a. nærliggende at implementere konceptet på de statslige autoritative registre, som holder grunddataobjekterne: Person, Virksomhed, Indkomst, Adresse, Ejendom, Bygning m.m. i forbindelse med den fællesoffentlige reform af grunddata. 12
3 MOX anvendt på udvalgte kommunale arbejdsgange I afsnit 2 ovenfor er det generelle koncept MOX blevet præsenteret. Nedenfor gennemgår vi de omtalte kommunale arbejdsgange, der har ligget til grund for analysen. Først præsenteres arbejdsgangen as-is med de udfordringer og uhensigtsmæssigheder, det byder for kommunerne. Der er altså tale om en helt specifik arbejdsgang fra en specifik kommune og med dens specifikke it-systemer. Derefter skitseres, hvordan løsningen kan automatiseres tobe ved hjælp af MOX. En pointe er her, at det generelle koncept for MOX vil kunne anvendes til at løse de specifikke udfordringer. Vi vil gennemføre en logisk afprøvning af konceptet indenfor nogle udvalgte kommunale arbejdsgange: Ansætter medarbejder o Integration mellem fagsystem og Portalsystem, automatisering af journalisering i ESDH, forsendelse med Digital Post, Indhentning af straffeattest, ajourføring af organisationsoplysninger i forskellige systemer og indhentning af straffe- eller børneattest Udveksler dokumentation mellem myndigheder o UDK rekvirerer dokumentation hos en kommune oplysningerne fremfindes, konverteres og overføres automatisk til UDK via Digital Post. Dokumenterne bliver journaliseret og sagsbehandler bliver adviseret Dokumentation af byggesag o Udveksling af dokumentation i forbindelse med byggesag via Portal, Digital Post med automatisk journalisering i fagsystemet, herunder ESDH og tilgængelig for Byggesagssystemet. Distribution af klassifikationsoplysninger o Udveksling af klassifikationsoplysninger mellem redaktør og de lokale kopier i f.eks. fagsystemer, herunder ESDH-systemer Konvertering af sager og dokumenter fra et fagsystem, fx ESDH-system til et andet fagsystem/esdh-system o herunder konvertering 3.1 Ansætter medarbejder 3.1.1 Arbejdsgangen for rekrutterer og ansætter medarbejder (as-is) 3 I Odense Kommune er der årligt en personaleomsætning på 3.200 personer. Rekruttering og ansættelsesprocessen involverer mindst 5 it-systemer: Rekrutteringssystemet EasyCruit SD-Løn (Silkeborg Data Løn og personalesystem) PPS personalesagssystem APOS2 (Organisationssystem) Digital Post 3 Begrebet as-is bruges om den eksisterende løsning. To-be bruges om en fremtidig løsning. 13
Der er i dag etableret en proprietær integration mellem SD-Løn, PPS og Digital Post, så når et ansættelsesbrev er udarbejdet I SD-Løn, oprettes der automatisk en personalesag, ansættelsesbrevet journaliseres og sendes til Digital Post. Da integrationen er proprietær, skaber den en vis afhængighed til de involverede leverandører. Der er ingen integration mellem EasyCruit og resten af processen, så der foregår manuelle processer, når rekrutteringen er slut (den nye medarbejder er udvalgt). Der er heller ikke integration til APOS2, så når en medarbejder er ansat, skal vedkommende oprettes i APOS. Igen en manuel proces. Organisationsstrukturen som optræder i alle systemerne, bortset fra Digital Post, skal ligeledes vedligeholdes. Organisationsstrukturen i APOS2, SD-Løn og EasyCruit vedligeholdes manuelt og parallelt. I PPS vedligeholdes strukturen indirekte fra SD-Løn. Disse overdragelser, manuelle processer og tripple inddateringer er dels ressourceforbrugende dels kilder til fejl. Figur 4 Overordnet beskrivelse af arbejdsgangen 14
Figur 5 Logisk systemlandskab (as-is) Ovenstående figur (as-is) viser en række forretningsprocesser, der udføres i forbindelse med rekruttering og ansættelse af en medarbejder. Vi viser sammenhæng med de it-systemer, de kan gøre brug af med en stiplet streg pilen viser retning på informationsudvekslingen. Der vil være flere forretningsprocesser og flere it-systemer. Og kommunen har forskellige it-systemer til at løse de forskellige forretningsprocesser. Vi har ikke noteret en rækkefølge (sekvens), fordi der er variationer. Vi har suppleret eksemplet fra Odense med en ansøgningsportal. 3.1.2 Arbejdsgangen for rekrutterer og ansætter medarbejder (to-be) To-be processen herunder kan eliminere de problemer der er beskrevet ovenfor i as-is: - Manuelle processer - Gentagne overdragelser - Genindtastninger - Fejl i forbindelse med ovenstående.. ved at skabe procesintegration mellem systemerne via udveksling af hændelsesbeskeder, så arbejdsgangen kan forløbe ubrudt. Nogle processer vil endda kunne forløbe automatisk, f.eks. indhentning og journalisering af straffeattest eller oprettelse af person i APOS2. I både as-is og to-be scenarierne er kun rekrutteringsprocessen beskrevet, men med få justeringer kan MOX også bruges på ansættelsesophør, skift af tjenestested, orlov og lønregulering. Herved stiger effekten af integrationerne betragteligt. 15
Processer vil kunne forløbe uafhængigt af hinanden, f.eks. indhentning af straffeattest samtidig med lønindplacering, men den endelige ansættelse kan først ske, når straffeattest er modtaget, altså check på en regel. Nedenstående figur viser to-be situationen, hvor der tæt på hvert af de eksisterende itsystemer implementeres en MOX-agent. MOX-agent er et it-system, der kan udføre en eller flere MOX processer i samarbejde med et it-system. MOX-processerne er standardiserede og udveksler beskeder med hinanden. Disse beskeder er baseret på OIO standarderne for Sag- og dokumentområdet. MOX processer er overvejende automatiske og vil dermed bidrage til at automatisere hele eller dele af de delprocesser, der indgår i rekruttering og ansættelse af en medarbejder. Figur 6 Logisk systemlandskab med anvendelse af MOX 16
Nedenfor beskrives hver forretningsproces og, hvordan den understøttes med en procesmæssig indkapsling af fagsystemerne i form af MOX processer. 3.1.2.1 Registrerer tilgang og afgang af personale Proces Processen opdaterer et eller flere systemer med tilgang og afgang af personale. I forbindelse med rekruttering og ansættelse har vi brug for at registrere en ledig stilling i organisatorisk enhed, stillingsbetegnelse, periode osv. Nedenfor vises hvordan denne proces beskrives med MOX standardprocesser. Den ledige stilling registreres ved at oprette en ny stilling eller afslutte et ansættelsesforhold. Forretningsmæssigt kan det være en fordel, hvis denne delproces sker så tidligt som muligt, hvormed man kan få stillingsbetegnelser, periode osv. med i beskeden. Den medarbejder der ansættes skal registreres i et af de organisationssystemer, kommunen anvender. Dette it-system, skal have tilknyttet denne MOX-proces, der skal udstede beskeden Aktør registreret. Med replikerer aktør distribueres organisationsoplysninger til de organisationsoplysninger, der abonnerer på dem. Dermed behøver man ikke have én bestemt master. Det betyder, at alle systemer der har brug for at kende afgang og tilgang af medarbejdere bliver synkrone. Disse it-systemer skal have tilknyttet denne MOX-proces, for at få replikeret oplysningerne automatisk. Her er det vist, at SD Løn og personale får besked om stillingen. Den ledige stilling herunder hvor den er placeret, hvornår den ønskes besat, stillingsbetegnelse osv. kan komme automatisk til Rekrutteringssystemet. Rekrutteringsagenten har brug for at abonnere på ansættelsesforhold der afslutter, og hvornår de genbesættes. 17
Proces Og hvis man også ønsker at holde andre organisationssystemer ajour, vil det være muligt her er det Active Directory, men det kunne også være IDM eller andre. 3.1.2.2 Gennemfører rekruttering og publicerer stillingsopslag Proces Processen sikrer, at en ledig stilling bliver slået op på en portal, og at der kan modtages ansøgninger. Den styrer også indkaldelser til samtale samt udvælgelse af den person, der skal tilbydes stilling. Stillingsopslaget kan udformes som et dokument her dannet som en brugerproces i rekrutteringssystemet. Stillingsopslaget kan også dannes andre steder. I så fald kan det replikeres til rekrutteringssystemet. Hvis der er andre aktører, der skal reviewe eller godkende stillingsopslaget, vil de kunne få besked herom ved at tegne et abonnement. Evt. ændringer vil optræde som en ny registrering. Når stillingsopslaget er godkendt (tilstanden er endelig), vil andre processer kunne abonnere på dette. Det vil typisk være publiceringsportalen og f.eks. et intranet med ledige stillinger. Stillingsopslaget som dokument kan tilgå portalen på forskellige måder. Her er vist, at opslaget replikeres. Det kan umiddelbart offentliggøres, hvis dokumentets tilstand er publiceret. En brugerproces kan vedligeholde stillingsopslaget i selve portalen via et administrationsinterface. Hvis man ændrer i dokumentets metadata f.eks. fjerner tilstanden publicering i portalen, kan replika af dokumentet opdateres automatisk forudsat at de abonnerer på denne oplysning. 18
3.1.2.3 Indsender ansøgning Proces Ansøgeren skal være logget ind for at indsende en ansøgning. I praksis vil det være en up-load af et dokument. I dette tilfælde ønsker vi ikke, at dokumentet resulterer i en automatisk sagsdannelse, fordi en ansøgning først skal journaliseres, når der tilbydes ansættelse. Indsender dokument kalder vi den proces, som up-loader et dokument i en portal. Portalen bør sikre, at brugeren får en kvittering. Vi forudsætter, at brugeren er bekendt med NemId og at han dermed er bruger. Processen sikrer, at konteksten bevares i forbindelse med, at brugeren indsender ansøgningen. Enhver indsendelse skal derfor ledsages af et modtager dokument. Den har vi lagt i rekrutteringssystemet. Men den kunne også ligge i et ESDH-system eller i et fagsystem. Denne proces anvendes, hvis en ansøgning er sendt fra en ansøgningsportal. Den sikrer, at dokumenter der sendes til den bliver registreret. Der kan være flere modtagere til en send, hvis man ønsker det. Det er stadig et abonnement, der afgør, hvem der kan modtage. Vi antager, at man har modtaget en række ansøgninger og rekruttering skal styre en række ting f.eks. udskrive brev for modtagelsen af ansøgning orientering af den medarbejder, som skal gennemgå ansøgningerne indkaldelser til samtale udvælgelse af den ansøger der skal have tilbud Vi antager endvidere, at rekrutteringssystemet danner disse breve, der skal tilgå ansøgere, der ikke tilbydes stilling. Brevene kan også dannes i et andet system men de ender alle med en registrering, der har en relation til ansøgningen, som har en relation til stillingsopslaget. 19
Proces Når rekrutteringssystemet har dannet brevene, og brevene er i den rette tilstand, vil de blive sendt automatisk. Det vil typisk være til Digital Post, men det kan også være andre kanaler det er alene et spørgsmål om, hvem der abonnerer på beskeden Dokument sendt. Den udvalgte ansøgers dokumenter bliver sendt til Løn og personale systemet, Processen kan starte automatisk på basis af en registrering af dokumentet, hvis dokumentets tilstand er endeligt og dette søgekriterium kan fremgå af det abonnement, der er tilknyttet denne proces. 3.1.2.4 Tilbyder ansættelse Proces Tilbyder ansættelse omfatter en række delprocesser men i denne sammenhæng vil vi reducere det til, at der udarbejdes et tilbud om ansættelse som et dokument. Løn og personalesystemet får kun den potentielle ansøgers dokumenter. Når ansøgningen modtages, ledsages den af relationer til opslaget og evt. andre dokumenter.. Hvis det er nødvendigt kan disse også rekvireres og derefter modtages. Det betyder at Løn- og personalesystemet har hele historikken og konteksten. Dette system skal alene bruge dokumenterne til at danne ansættelsestilbud dokumenterne vil blive journaliseret af ESDHsystemet (se senere). Vi antager, at den ansøger der skal have et tilbud tilknyttes som potentiel medarbejder i Løn- og personalesystemet. Dermed får vi registreret initialer, stillingsbetegnelse, den afdeling ansøgeren skal ansættes i osv. Som vi så tidligere, bliver disse oplysninger replikeret til de øvrige udgaver af organisationssystemet. 20
Proces Tilbud om ansættelse bliver dannet i løn- og personalesystemet. Tilbud knyttes til ansøgningen med en relation. Hvis der er en godkendelses- eller orienteringsproces, kan pågældende abonnere på dette tilbud. Det kan f.eks. være tillidsrepræsentant. Der knyttes forskellige bilag til tilbud bl.a. en blanket om samtykke til indhentning af en straffeattest eller en børneattest. 3.1.2.5 Forsender breve Proces Erstattes af nedenstående automatiske proces. Når tilbud og samtykkeblanket er udarbejdet, kan det sendes. Når en aktør sender et dokument, som forventer svar, kan man udføre en automatisk proces, der giver et advis til den pågældende aktør, når tiden er gået. Når der kommer svar, kan man annullere erindringen. Denne automatik er ikke vist. Digital Post agenten sender tilbud til ansøgerens digitale postkasse. Hvis agenten ikke kan bruge Digital Post f.eks. hvis ansøgeren ikke er tilsluttet, vil den alternative besked dokument ej modtaget (af Digital Post) sendes til videre til fjernprint. 3.1.2.6 Accepterer tilbud Proces Ansøgeren accepterer ansøgningen og giver samtykke til indhentning af straffeattest eller børneattest. Det bør gøres med en digital underskrift, fordi blanketten skal videre til rigspolitiet i en anden proces. Hvis Digital Post ikke umiddelbart kan signere dokumenter, kan man lave en agent, der kan. Den er ikke vist. 21
Proces Denne proces tømmer den digitale postkasse efter en tidsplan. Dokumenterne sendes til den eller de modtagere, der fremgår af metadata og forsendelsesdata i Digital Post. Processen vil kunne sende til forskellige inputkanaler afhængig af, hvem der abonnerer på forsendelsen. Det vil typisk modtages af en input manager, der kan fordele dokumentet til den rette afdeling. Vi viser senere denne input manager proces. Hvis kommunen ønsker at accepten gives via ansøgningsportalen, vil det også kunne lade sig gøre. Det vises her ved, at ansøgeren indsender accepten via portalen. Det er medtaget her for at vise, at processerne er uafhængige af den konkrete implementering. Dokumenter modtages af løn og personalesystemet, hvor accepten registreres automatisk. Vi går ud fra, at medarbejderen abonnerer på, at accepten er kommet, så han kan gennemføre det nødvendige. I denne sammenhæng dannes der en personalesag se senere. 3.1.2.7 Indhenter straffeattest Proces Denne brugerproces bliver afløst af den automatiske proces nedenfor. 22
Proces Denne proces forventes at abonnere på netop de samtykkeblanketter, som er modtaget ovenfor. Men vi ønsker først at sætte den i gang, når der er dannet en personalesag så det er dokumentet metadata med en tilføjelse af sagsid. De sendes videre til Rigspolitiets agent eller til Digital Post afhængig af hvilken kanal, der skal benyttes. Det er stadig alene abonnementet, der afgør, hvem der er modtager. Samtykkeblanketten sendes videre til rigspolitiet med metadata herunder kommunens sagsid. Her er det vist som Rigspolitiets portal, med en agent. Når man rekvirerer noget, bør man sikre sig, at der også kommer svar. Denne besked kan gå til en agent, der holder øje med, om der kommer svar. Hvis ikke så gives advis til den aktør, der har foretaget rekvisitionen. Når udveksling af dokumenter mellem myndigheder skal anvende Digital Post vil det være Digital Post, der får beskeden fra processen sender dokument. Samme proces som tidligere nu er det blot post fra Rigspolitiet en straffeattest eller en børneattest. Vi vælger, at den indgår i en input manager, der vises senere. I dette tilfælde skal dokumentet nemlig give anledning til et journalnotat om, at der er en ren straffeattest. 23
Proces Attesten modtages. Den skal ikke journaliseres (gemmes) på sagen. Den giver anledning til et journalnotat om, at den er modtaget og det foregår i en brugerproces. Vi illustrerer her, at et journalnotat på sagen kan dannes i en agent, der er tilknyttet løn og personalesystemet. Processen registrerer journalnotatet på den pågældende sag i det system, der har sagen. 3.1.2.8 Dokumenterer ansættelse præjournalisering og input management Proces Denne proces skal sikre, at alle relevante dokumenter bliver journaliseret på den rette sag. Vi vil så vidt muligt gøre den automatisk. Hvis sagen ikke findes skal den oprettes. Kommunernes ønsker til sagsdannelse er forskellige, og derfor vil vi vise, hvordan det kan lade sig gøre at bevare forskelligheden, selvom der er tale om standardprocesser. Præjournalisering er en proces, der sikrer at et dokument har de rette metadata, for at kunne blive journaliseret. Præjournalisering abonnerer på dokumenter, der mangler metadata og forsøger at få disse metadata fremfundet. Da kravene til metadata kan være forskellige fra de enkelte opgaveområder, vil den undersøge, om der er en journaliseringsregel, der kan hjælpe den. Den vil afslutte med en af de viste beskeder: Dokument mangler regel, klassifikation, aktør, part sag eller uden ændring af beskeden. 24
Proces Hvis dokumentet mangler en regel, vil en regel kunne tilføjes i denne proces. Med tilføjelse mener vi, at der tilføjes en relation til dokumentmetadata, der indeholder identifikation af en regel. Der kan være flere regler, der omfatter en bestemt sagstype (klassifikation). For hver regel laves en særskilt instruks, som en agent vil kunne omsætte til en anden krævet relation. F.eks. en regel om, at der til en ansættelsessag altid skal være en relation til den person, der skal ansættes. Hvis personen ikke findes som relation på dokumentet, er reglen ikke opfyldt. Det kan også være en regel for sagsdannelse, der siger, at rekrutteringsdokumenter skal på en rekrutteringssag. Og en tredje regel, der siger at en rekrutteringssag skal have en personalesag som oversag. Vi er ikke så langt med regler og derfor skal denne ide blot nævnes som noget der må analyseres nærmere. Det er vigtigt, at der kan være regler, der er forskellige fra kommune til kommune. Regel agenten og systemet er ikke medtaget i den samlede tegning. Hvis et dokument mangler klassifikation vil det kunne tilføjes med klassifikation. Det vil typisk være efter, at et dokument har fået tilknyttet en regel, og der f.eks. skal oprettes flere sager. Hvis dokumentet mangler aktør, skal det slå op i organisation for at finde den aktør, der er ansvarlig for behandling af dokumentet. Input vil typisk være en klassifikation. I en ansættelsessag vil der både være en ansvarlig i løn- og personaleafdelingen og en ansvarlig i den afdeling, hvor medarbejderen skal ansættes.. Tilføjer aktør er den vigtigste proces, når der er tale om input management, fordi det er den, der afgør, hvem der skal modtage indgående henvendelser. Den mest enkle måde at fordele på er, at organisationen er opmærket med arbejdsopgaver her Klassifikation KLE-nummer og at processen bruger klassen fra dokumentet som input og den organisatoriske enhed som output. Men der kan være fordelinger, som ikke kan anvende disse oplysninger alene. F.eks. fordeling baseret på partens fødselsdato eller hvilken medarbejder, der har en bestemt kompetence. Det kan også være at en bestemt lønmedarbejder tager sig af personalesager for en del af organisationen. Alle disse fordelinger vil kunne udtrykkes som regler og man vil så blive ledt til den eller de agenter, der kan hjælpe med at opfylde reglen. Hvis det ikke kan gennemføres automatisk, vil det ende med en alternativ tilstand, som fører til en manuel håndtering. 25
Proces Hvis dokumentet mangler en person vil denne proces forsøge at tilknytte personen. Person agenten og systemet er ikke medtaget i den samlede tegning. Dokumentet mangler en sag, er udtryk for, at sagen eller sagerne ikke er tilknyttet til dokumentet. Denne proces undersøger, om der er en eksisterende sag, og hvis der er, vil sagen blive tilknyttet. Hvis der ikke er en sag så er sag ej tilføjet i foregående proces, og det abonnerer denne proces på. Derfor bliver sagen eller sagerne oprettet på basis af de præjournaliserede oplysninger. Når tilføjer sag afvikles herefter, vil den netop oprettede sag blive tilknyttet. Læg mærke til, at det er en dokumentbesked og ikke en sag besked, der starter denne proces og en sag besked der går ud. I de foregående processer er der dannet en række dokumenter, og mange af dem er relateret til hinanden. Det gælder f.eks. stillingsopslag, ansøgning, tilbud, accept. De har fået tilføjet en række metadata, som gør det muligt at journalisere dem til den rigtige sag. Læg mærke til, at det er en dokumentbesked der går ind, og en sag besked der går ud. 26
3.2 Udveksler dokumentation mellem myndigheder 3.2.1 Arbejdsgangen for udveksling af dokumentation mellem myndigheder (as-is) En meget aktuel case, på udveksling af dokumentation mellem myndigheder, er en case i november 2012, hvor alle landets kommuners udbetalinger overgår til den dertil nyoprettede organisation Udbetaling Danmark (UDK). Rationalet er, at ved at samle udbetalingerne til danske borgere et sted, kan der skabes en øget effektivisering i den offentlige forvaltning gennem stordriftsfordele. I forbindelse med overgangen til UDK er der stor usikkerhed om, hvordan sager mellem kommuner og UDK skal udveksles. I sin yderste konsekvens kan det betyde, at kommunerne bliver pålagt at fremfinde og eftersende sager til UDK på forespørgsel herfra. Det vil udhule effektiviseringspotentialet for den enkelte kommune, som i forvejen kommer til at afholde en væsentlig udgift til UDK. UDK er som nævnt en nyoprettet organisation, der i første omgang skal sikre en stabil drift for hele udbetalingsområdet. UDK har i et teknisk perspektiv vurderet, at KMD Sag er det bedste bud på et it-system, der kan sikre stabil drift, da en række af de systemer, som anvendes i forbindelse med udbetalinger kommer fra samme leverandør. Dog er det langt fra alle kommuner, som benytter sig af KMD Sag. Da leverandøren på samme tid har meldt ud, at der ikke bliver etableret en standard grænseflade til udveksling af sager fra kommunerne til UDK, betyder det i praksis, at visse kommuner vil se sig nødsaget til at fremfinde sager og oversende dem manuelt. Problemstillingen er todelt set fra et kommunalt perspektiv: 1) Hvordan flytter vi eksisterende sager til UDK i første omgang? 2) Hvordan håndterer vi ad hoc forespørgsler fra UDK fremadrettet, uden at være nødsaget til at skulle anvende KMD Sag i kommunen? 27
Fra kommunernes synspunkt kunne det være at foretrække at flytte alle åbne sager over til UDK. Dermed ville kommunerne stort set slippe for at skulle fremfinde udbetalingssager. Det er dog tvivlsomt, om UDK vil være i stand til at håndtere en så stor manuel overførsel fra kommunerne allerede til november 2012. UDK vil derfor foretrække, at sagerne bliver liggende ude hos kommunerne og her kan rekvireres på anmodning. Det er den sidste situation, vi tager som eksempel. Figur 7 Logisk systemlandskab (as-is) Ovenstående diagram viser forretningsprocesserne, der indgår i udveksling af dokumentation mellem myndigheder og deres brug af forskellige it-systemer. Der kan f.eks. være tale om at UDK rekvirerer dokumentation hos en kommune i forbindelse med årsregulering af boligstøtte. I andre tilfælde kan kommunen sende dokumentation uopfordret eller ved, at UDK abonnerer på relevante oplysninger, så de kan danne et sagsoverblik. 28
3.2.2 Arbejdsgangen for udveksling af dokumentation mellem myndigheder (to-be) Såfremt kommunernes it-leverandører er parate til at implementere MOX kan processen bygges, så den løser denne problemstilling. Ved at automatisere sagsgangen fra rekvisition via KMD Sag til at fremfinde i et vilkårligt ESDH-system, kan kommunerne undgå manuel håndtering af rekvisitioner fra UDK. Dermed sikres det, at det ikke er udveksling af sager mellem myndigheder, der udhuler den gevinst, som kommunerne forventer i forbindelse med overgangen til UDK. Figur 8 Logisk systemlandskab (to-be) Ovenstående figur viser to-be situationen, hvor der til hvert it-system knyttes en MOX agent. En MOX agent er et it-system, der kan udføre en eller flere MOX processer i samarbejde med et it-system. MOX processerne er standardiserede og udveksler beskeder med hinanden. Disse beskeder er baseret på OIO standarderne for Sag- og Dokument. MOX processer er automatiske og vil dermed bidrage til at automatisere hele eller dele af de delprocesser, der indgår i myndighedskommunikation. I ovenstående tilfælde kan Doc2Mail udgå som system, fordi det erstattes af Digital Post (Agent). Endvidere vises, at der er indsat en FESD/OIO agent, der kan foretage konvertering af beskeder mellem FESD og OIO format. Det skyldes, at en række kommuner har ESDH-systemer, der anvender forskellige formater. I det følgende beskrives, hvilke standardprocesser der skal udføres i de respektive agenter. 29
3.2.2.1 Rekvirerer dokumentation Proces Rekvirerer dokumentation i en myndighed f.eks. en sag, en del af en sag, et journalnotat eller en oplysning. Det kan også være flere af disse dokumentationer. Eks. UDK skal bruge dokumentation i en Boligstøttesag det er journalnotater og dokumenter. En eller flere sager og dokumenter rekvireres ved at danne et søgeudtryk på det objekt, der ønskes. Når det er en sag, vil det være sagens identifikation, der normalt skal bruges. Men hvis den ikke kendes af modtageren hvilket er tilfældet i denne situation vil det være de øvrige informationer om sager, der er vigtige. Sagens tilstand og dens virkningsdato, sagens relationer primærklasse (KLE-nummer) og sagens part (person) vil være de vigtigste. Men der vil også kunne være en relation til et dokument f.eks. en samtykkeblanket, som giver rekvirenten ret til at indhente informationen. I så fald bør dokumentet være sendt med eller på anden måde være tilgængeligt for modtageren. Når det er et dokument, vil det også være et søgeudtryk på dokumentets tilstand, attributter eller relationer. Det er rekvisitionens (søgeudtrykkets) modtager, der styrer, hvem der skal levere dokumentationen. Der medsendes kontekst, således at den information der returneres, automatisk kan lægges på den rigtige sag. 3.2.2.2 Fremfinder dokumentation Proces Den organisation der skal levere dokumentation fremfinder den. Nedenfor er vist én agent, der kan udføre mange forskellige processer i det samme system. Her er det vist, at det kan gøres automatisk. 30
Søger sag er relevant hvis sagens nøgle ikke kendes af rekvirenten. Det er kun 0, 1 eller flere ID der returneres. Hvis der kun er én sag læses den hvis der er mange så gentages denne proces, og der dannes en ny besked for hver. Det registreres - evt. i et journalnotat - at sagen er rekvireret af en anden myndighed og denne myndighed kan indsættes som kopipart hvorved den kan sendes automatisk til denne. Det kan gøres uden at involvere organisationsagenten, fordi det forudsættes at aktøren (rekvirenten) er med i søgeudtrykket. Sagen sendes antagelig via Digital Post hvis der er mange, gentages denne proces. Dokumentets id er enten kommet fra sagen eller fra rekvisitionen søger dokument fremfinder dets nøgle. Denne proces kan evt. undværes, hvis nøglen kendes af rekvirenten. Processen skal læse dokumentets metadata, hvis dokumentet skal sendes. Processen sender dokumentet er der flere gentages dette. Hver forsendelse knytter an til rekvisitionen. 3.2.2.3 Konverterer dokumentation Proces 31
Proces Vi har indsat en konverteringsproces, der afvikles i en agent. Vi viser dermed, at det er muligt at lade en ekstra agent indgå i processen, når det er nødvendigt. Konkret kan de fleste ESDH-systemer udtrække sager i det format, der blev anvendt ved kommunalreformen. Det hedder esdh_udvekslingsag v5. Det indeholder sager og dokumenter. Agenten kan opdele dette udtræk i de respektive OIO-beskeder og sende dem videre. 3.2.2.4 Sender dokumentation Hvis sagen og dokumenterne skal sendes via Digital Post vil det kunne ske via denne agent fuldautomatisk. Forsendelse kan gå via andre kanaler, hvis det ønskes. Digital Post agenten kan modtage og sende dokumenter på vegne af organisationen. Vi viser, at den også sender sager men sagerne bliver blot sendt som et xml-dokument, som kan forstås af den tilsvarende agent, der modtager det. I dette tilfælde er det modtager sag og modtager dokument, der anvendes af den kommune, der leverer oplysningerne. Det kan virke omvendt men skal forstås således, at det er agenten, der sørger for at abonnere på besked om, at der er sendt et objekt. Det bliver så registreret i Digital Post som afsendt. Udbetaling Danmark (UDK) der skal modtage dokumentationen anvender sender sag og sender dokument fra Digital Post til den abonnent, der abonnerer på disse oplysninger. Fordelen herved er, at man undgår, at der skal opsættes mange forskellige postkasser og modtagere i Digital Post. Posten tømmes af agenten og abonnementet sikrer, at det tilgår det rigtige system. I dette tilfælde er det vigtigt, at rekvirenten får oplysningerne så det ikke går gennem den almindelige postfordeling. 32
3.2.2.5 Håndterer dokumentation Den rekvirerende myndighed får dokumentationen og skal lægge den på den rette sag. Vi viser, at det også kan gennemføres automatisk men vi går ud fra, at dokumentationen skal anvendes, og derfor bør sagsbehandleren adviseres om det ved at abonnere f.eks. på sag registreret. Modtager sag i dette tilfælde fra Digital Post agenten via beskedfordeleren. Sagen registreres, hvis betingelserne er opfyldt. Modtager dokument i dette tilfælde fra Digital Post agenten via beskedfordeleren. Dokumentet registreres, hvis betingelserne er opfyldt. Hvis den modtagne sag ikke har samme nøgle, skal man finde den der sag, der matcher men hvis sagen har en rekvisition tilknyttet, burde sagen fremgå af denne. Vi har valgt at bibeholde den oprindelige sag, men lave et journalnotat på den rekvirerede om, at den er modtaget og evt. en relation mellem de to sager. Det vil være mere rigtigt, end at opdatere en af sagerne med dokumentation fra en anden sag. Denne proces kan journalisere modtagne dokumenter på den sag, der rekvirerede dem hvis det ønskes. 33
3.3 Dokumentation af byggesag Figur 9 Byggesag - udvalgte processer En byggesag i Frederikshavn Kommune starter ved, at en ansøger (borger eller rådgiver) sender en henvendelse til kommunen om byggeprojektet. Denne henvendelse er i dag standardiseret ved brug af blanket og tilknyttet vejledning, der beskriver processen og udarbejdelse af supplerende dokumentation. Det er også muligt at ansøge uden brug af blanketten, hvis ansøgningen indeholder de relevante oplysninger. Forud for indsendelse af ansøgningen ligger der ofte en forhåndsdialog, hvor kommunen kan vejlede ansøger om udarbejdelsen af ansøgningen. Det sker med henblik på at sikre, at alle relevante oplysninger er til stede. Denne dialog kan foregå ad forskellige kanaler, men ofte via tlf. eller personligt fremmøde. Ansøgningen med tilhørende indsendes til kommunen. Det kan foregå ad forskellige kanaler. Det kan f.eks. ske via mail, pr. post eller afleveres direkte til kommunen. Fælles for alle disse kanaler er, at der efterfølgende skal foretages en manuel behandling af ansøgningen, herunder oprettelse af sag og fremsendelse af kvittering (hvis det ikke er digitalt ansøgt). Oprettelsen sker i kommunens ESDH-system, hvorefter en integration overfører sagen til byggesag systemet (fagsystem). Denne integration er i Frederikshavn udviklet specifikt mellem disse systemer. I den efterfølgende sagsbehandling er der som oftest behov for yderligere dialog/afklaring med ansøger, hvis dokumentation er mangelfuld eller projektet ændrer karakter. Denne dialog kan foregå ad forskellige kanaler og involvere udveksling af diverse dokumenter. I sagsbehandlingen kan der også opstå behov for at komme i dialog med andre interessenter, hvis byggesagen er naboafhængig, skal der gennemføres en høringsrunde. Der udarbejdes en skrivelse i kommunens ESDH-system, og adresseoplysningerne hentes fra GIS-systemet, og dokumentet sendes ud pr. post. Kommer der indsigelser, placeres disse på sagen og tages med i den videre sagsbehandling. Når der er truffet en afgørelse - enten en godkendelse (med approberede tegninger, underskrift og stempel) eller et afslag med klagevejledning sendes den til ansøger. 34
Godkendelsen med tegninger placeres i ESDH-systemet. Har der været naboorientering, skal naboerne også have besked om sagens afgørelse. 3.3.1 Arbejdsgangen for dokumentation af byggesag (as-is) Som det fremgår, er der en række integrationer i spil mellem forskellige systemer, og der udveksles dokumentation mellem forskellige parter. Integrationerne er enten udviklet specifikt mellem systemerne, hvilket giver problemer ved udskiftning af systemer, eller også er disse ikke fyldestgørende og skal udvikles. Derudover er der i processen en lang række steder, hvor dokumenterne ændrer tilstand fra fysisk til digital (og omvendt) med efterfølgende manuel konvertering. Derfor er der flere steder i denne proces, hvor et digitalt kanalvalg og en standardiseret integration mellem systemer, kan forenkle og automatisere de administrative processer og dermed frigive ressourcer til den faglige behandling. Figur 10 Logisk systemlandskab (as-is) Ovenstående viser nogle udvalgte processer, der anvender forskellige systemer. Vi har antaget, at der bruges blanketter og mail, og en ansøgningsportal er under udvikling. Kommunikation mellem det centrale og de lokale systemer er ofte et problem. Der er typisk tale om dyre integrationer, fordi kommunerne har forskellige modtagersystemer. Som det fremgår af beskrivelsen fra Frederikshavn, er ESDH og Byggesag integreret. Vi har også medtaget et byggesagsarkiv, som ligeledes er tæt koblet til ESDH. 35
3.3.2 Arbejdsgang for dokumentation af byggesag (to-be) Figur 11 Logisk systemlandskab (to-be) Figuren illustrerer, at integrationen mellem systemerne bliver løst koblet via beskedfordeleren. Under forudsætning af, at agenterne sikrer, at sammenhængen (kontekst) til den konkrete byggesag bevares, så vil kommunen kunne modtage på alle kanaler uden tab af information. Løsningen er også transparent overfor, om der anvendes centrale fælles systemer eller lokale systemer. Postfordeling bliver overflødig, fordi den enten afløses af de enkelte agenters abonnementer eller understøttes af organisations agentens automatiske fordeling (præjournalisering) eller dens evne til at visitere på grundlag af metadata. Vi beskriver denne løsning nærmere i det følgende. 36
3.3.2.1 Indsender dokumentation Proces Indsender dokumentation kan anvende flere forskellige kanaler. Skift mellem kanaler, ændrer ikke på den modtagne information, og der er begrænsede omkostninger ved skift af kanal. Indsender dokument via en blanketløsning vil dels have personen kendt men også klassificeret dokumentet med KLEnummer og ejendomsnummer dvs. en præjournalisering der kan bruges, hvis der endnu ikke er oprettet en byggesag. Dokumentation kan også komme ind via et mail-system. Man kan ikke forvente, at metadata er med i en mail. Man kan godt bruge en mailserver agent i de tilfælde, at afsenderadressen er kendt af agenten eller, hvis metadata medsendes som xml-fil. I øvrige tilfælde vil vi fraråde at anvende mail som transportkanal. Dokumentationen registreres i en portal, hvor både brugeren (borgeren) og byggesagen (sag identifikation eller ejendommen) er kendt. Portalen kan i visse tilfælde opmærke dokumentationen efter, hvilken slags dokumentation der er tale om. Vi viser her, at portalen registrerer dokumentet og opbevarer dokumentet. Vi lader byggesag systemet modtage dokumentet, hvis det er sendt. Det kan replikeres, hvis det kommer fra en portal, hvor det er registreret i forvejen. I begge tilfælde bliver det registreret, og forskellen er blot, at en replikering importerer dokumentet, mens modtager dokument kan oprette dokumentet. Hvis dokumentet ikke har de nødvendige metadata, udstedes en af de to beskeder dokument ej modtaget eller dokument ej replikeret. De to beskeder vil enten gå til en sagsbehandler eller gå videre til præjournalisering. 37
3.3.2.2 Postfordeling (Visiterer byggesag) Proces Processen er afløst af en mere eller mindre automatisk proces i forbindelse med præjournalisering, som er omtalt tidligere. Processen bruger dokumentets metadata til at fremfinde den afdeling eller den medarbejder, der kan håndtere den indsendte information. Rationalet er, at portalen ikke behøver at kende den modtagne organisation. Hvis processen ikke kan visitere automatisk (aktør ej tilføjet), vil den tilgå den brugerstyrede visitation. Vi har her vist, at kommunen bruger APOS2 Organisationssystemet. Visitationen kan også foregå manuelt ved at opmærke dokumentet med den aktør, der skal behandle dokumentet. Det forudsættes, at medarbejderen abonnerer på de beskeder, der vedrører hans eget arbejde. 38
3.3.2.3 Udarbejder mangelliste Proces Vi viser her én blandt mange processer, der udarbejder udgående post det kunne også være afgørelse eller naboorientering. Når et dokument vedligeholdes, vil metadata blive leveret af byggesagssystemet og evt. en skabelon. Når dokumentet har den rette tilstand i registreringen, vil de systemer, der abonnerer på det få meddelelsen. Det vil f.eks. være Digital Post, Byggesag portal og ESDH systemet. 3.3.2.4 Dokumenterer byggesag Proces Integrationen mellem byggesag systemet og ESDH systemet er afløst af en automatisk proces, der abonnerer på alle relevante dokumenter. Det er både ind- og udgående post. Processen journaliserer dokumentet direkte på sagen, fordi sagen var kendt. Dokumentet er stadig placeret i byggesags fagsystemet. Hvis sagen af en eller anden grund ikke findes, vil besked Dokument ej journaliseret tilgå præjournaliseringsprocessen. Det vil også være muligt at kopiere dokumentet. 3.3.2.5 Modtager mangelliste og modtager advisering Proces Den samme dokumentation her mangellisten kan tilgå en portal og Digital Post. Hvis kommunen vil være sikker på, at borgeren får besked, kan man anvende Digital Post som adviseringskanal hvor agenten blot fortolker beskeden som en NemSMS eller en advisering i Digital Post. Det kunne også være en naboorientering med henvisning til hvor de berørte naboer kan hente dokumentation på portalen. 39
Proces Digital Post agenten abonnerer på udgående post til en borger herunder de borgere, der er omfattet af en naboorientering. Byggesag portalen får replikeret alle relevante dokumenter. 3.3.2.6 Arkiverer byggesag Proces Når sagen er afsluttet, vil et byggesagsarkiv kunne replikere sagen og dens dokumenter. Her bruger vi også replikering. Man kan vælge, at byggesagsarkivet opdateres løbende på samme måde som ESDH men det vil være smartere at tage den sidste registrering, når sagen er afsluttet. 40
3.4 Distribution af klassifikationsoplysninger 3.4.1 Arbejdsgang for distribution af klassifikationsoplysninger (as-is) Leverandører af ESDH systemer, der anvender KL Emnesystematik (KLE) kan downloade nye releases af klassifikationssystemet fra KL s hjemmeside. Leverandører lægger derefter den nye udgave ind i systemerne for deres kommuner. I dag publiceres en udgave af KLE hvert kvartal. Figur 12 Arbejdsgang for distribution af klassifikationsoplysninger 41
Figur 13 Logisk systemlandskab (as-is) Det logiske systemlandskab viser et eksempel på de systemer, der indgår i distribution af klassifikationssystemet KLE. Nogle leverandører har lavet programmer, der har automatiseret denne opgave, andre bruger manuel tid til den. Oplysningerne er i nogle tilfælde flere måneder gamle, før de publiceres, og hvis der går tid hos leverandørerne, kan det betyde, at de korrekte klassifikationsoplysninger ikke er til stede for kommunen på rette tid. 42
3.4.2 Arbejdsgang for distribution af klassifikationsoplysninger (to-be) Med OIO standarden Klassifikation er det muligt at distribuere ændrede objekter direkte fra redaktionen til de kørende udgaver. Nedenfor beskrives hvordan det kan foregå. Figur 14 Logisk systemlandskab (to-be) Ovenstående viser, at et ESDH-system kan abonnere på klasseobjekter direkte fra redaktionen. Redaktøren vil kunne vælge, hvornår den vil frigive (publicere) de enkelte klasser. 43
3.4.2.1 Vedligeholder klassifikationsobjekt Proces Processen vedligeholder klassifikationsmasteren. Dette vil foregå hos redaktøren i dette tilfælde hos KL. Når klassifikationsobjektet er registreret i tilstanden publiceret, stilles det til rådighed for abonnenter. De systemer der abonnerer på klassifikation vil umiddelbart kunne replikere det ændrede objekt. 44
3.5 Konvertering af sager og dokumenter fra et ESDH-system til et andet ESDHsystem 3.5.1 Arbejdsgange for konvertering af sager og dokumenter (as-is) Arbejdsgangen for at konvertere fra et system til et andet kan se ud på forskellig måde. Vi viser her, at man afslutter sager i det gamle system, arkiverer dem ved at udtrække sager fra det gamle system og overfører dem til arkiv systemet. Hvis der er behov, kan man konvertere sager i det gamle system - der kan også være tale om oprydning. Til sidst overføres de sager, der skal videreføres til det nye system. Figur 15 Logisk systemlandskab (as-is) 45
3.5.2 Arbejdsgang for konvertering af sager og dokumenter (to-be) Nedenfor beskriver vi en to-be situation, hvor man skal tage et nyt ESDH-system i brug. Figur 16 Logisk systemlandskab (to-be) Vi antager, at man kan montere MOX processerne på begge ESDH-systemer. Vi viser, at man kan bruge sender sag som en mulighed, der bevirker, at der kan være flere forskellige modtagersystemer både det nye ESDH-system og fjernarkiv. 46
3.5.2.1 Afslutter sag Proces Afslutter sag dækker over, at sagens oplysninger og dokumenter skal være i den rette tilstand. Her vises en agent, der kan udføre en del af arbejdet med at afslutte sager. Den vil kunne søge sager med et søgekriterium og udføre en automatisk eller brugerstyret vedligeholdelse f.eks. at lukke sagerne. Søgningen kan også søge de sager, der skal sendes til arkiv eller til det nye system evt. via en konvertering. Hvis man ikke bruger sender sag, vil der ikke blive dannet en besked, som modtageren kan abonnere på. Som tidligere nævnt er det modtageren, der afgør om de skal have sagerne så metadata skal være så gode, at de andre agenter kan abonnere på beskederne. 47
3.5.2.2 Arkiverer sag Proces Arkiverer sag bliver nu en automatisk proces. Arkivet abonnerer på sager og dokumenter, der skal arkiveres og det er så det. 3.5.2.3 Konverterer sag Proces I forbindelse med ibrugtagning af nye systemer til erstatning for gamle, vil der ofte være brug for konvertering af en eller anden art. Konvertering foretages af en agent her den samme som er brugt ved andre konverteringer fra FESD til OIO standarderne. 48
3.5.2.4 Overfører sag Proces Det nye systems agent abonnerer på beskeder fra konvertering og lægger dem på plads. Der kan være regler for, om man modtager objekterne for at oprette dem på ny eller for at importere dem, de bevarer deres nøgle. 49