Bilag 2A Sådan forretningsmodellerer vi i ATP

Transkript

1 Bilag 2A Sådan forretningsmodellerer vi i ATP Version

2 Indhold 1 VEJLEDNING TIL TILBUDSGIVER INDLEDNING FORRETNINGSMÅLARKITEKTUR FORRETNINGSUDBUDSARKITEKTUR SÅDAN FORRETNINGSMODELLERER VI I ATP ARTEFAKTER FORANKRES I OIO-REOLEN SÅDAN ER REOLEN OPBYGGET PROCES INDLEDNING PROCESOVERBLIK PROCESNIVEAUERNES SAMMENHÆNG END TO END PROCESSER IGOE LØSNINGSFLOWS AKTIVITETSBESKRIVELSER NUMMERERINGSSTRUKTUR AF PROCESSER FLOWREGLER INFORMATION INFORMATIONSARTEFAKTER BEGREBSMODELLER SÆRLIGE FORHOLD VED BEGREBSMODELLER INFORMATIONSMODELLER Bilag 2A Sådan forretningsmodellerer vi i ATP Side 1 af 32

3 5.3.1 SÆRLIGE FORHOLD VED INFORMATIONSMODELLER FUNKTIONALITET INDLEDNING FORRETNINGSKOMPONENTMODEL KONCEPTUEL IT MÅLARKITEKTUR IT UDBUDSARKITEKTUR ORDNINGSOVERBLIK SYSTEMLANDSKAB FORRETNINGSKOMPONENTER - OG MODEL REGELMODELLERING VIA BESLUTNINGSMODELLER EKSEMPLER PÅ METODEN FOR BESLUTNINGSMODELLERING SÆRLIGE FORHOLD VED BESLUTNINGSMODELLER Bilag 2A Sådan forretningsmodellerer vi i ATP Side 2 af 32

4 1 Vejledning til Tilbudsgiver Bilaget skal ikke ændres af Tilbudsgiver. Tabel 1 Vejledning til Tilbudsgiver Bilag 2A Sådan forretningsmodellerer vi i ATP Side 3 af 32

5 2 Indledning Dette bilag giver Leverandøren indsigt hvordan ATP arbejder med de forretningsmæssige processer og derigennem kravstiller til systemunderstøttelse med udgangspunkt i procestrekanten. Som overligger for procesarbejdet er forretningsudbudsarkitekturen, den er udarbejdet med afsæt UDK Forretning målarkitektur. Forretning målarkitekturen er udarbejdet med afsæt i UDK Succeskriterier og 5 centrale mantra. Nedenfor ses ovennævnte sammenhænge inkl. procestrekantens artefakter. Ligeledes hvordan de enkelte områder er forankret i OIO-reolen: Figur 1 Procestrekant i samspil med artefakter og OIO reolen 2.1 Forretningsmålarkitektur Forretningsmålarkitekturen udtrykker visionen for 2020, som forretningsarkitekturen ser ud efter implementering af KUP projekterne: Bilag 2A Sådan forretningsmodellerer vi i ATP Side 4 af 32

6 Barsel Pension Familieydelser Boligstøtte Opkrævning MultiFagsystem (tværgående ESDH) Fælles offentlige løsninger benyttes i videst muligt omfang. KOMBIT s rammearkitektur benyttes til dataudveksling med kommunerne. 2.2 Forretningsudbudsarkitektur Denne forretningsarkitektur danner grundlag for leverandørens tilbud. Udbudsarkitekturen for Barsel benytter sig af følgende interimløsninger: Kommunal medfinansiering Indkomstoplysninger Udbetaling Udfaser Opus Barsel KMD Sag udtyndes Bilag 2A Sådan forretningsmodellerer vi i ATP Side 5 af 32

7 3 Sådan forretningsmodellerer vi i ATP Hos ATP beskriver vi vores forretning ved hjælp af processer. Denne måde at arbejde på skaber synlighed omkring forretningens kerneområder således, at det for den enkelte medarbejder i organisationen er nemt at forstå sine egne arbejdsopgaver og helheden i forretningen. Koblingen af proces, funktionalitet og information, giver mulighed for synlighed og risikostyring ved ændringer i eksisterende løsninger. En eventuel ændring i lovgivningen, giver hurtigt et fuldt overblik over hvilke processer, brugerfunktionalitet og it-system, der vil blive berørt Processerne kan være både manuelle eller maskinelle. Det er kunderådgiverne, der udfører de manuelle processer, mens it-løsningens funktionalitet udfører de maskinelle processer. Processerne behandler information. Denne tredeling, Proces, Information og Funktionalitet, er central i vores måde at forstå, beskrive og dokumentere vores forretningsmæssige behov. Figuren viser Procestrekanten: Figur 2 Procestrekanten Systemet, som skal anskaffes, er indeholdt i den stiplede teknologi-trekant, som understøtter vores forretningsmæssige behov ovenover. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 6 af 32

8 3.1 Artefakter forankres i OIO-reolen At forstå, beskrive og dokumentere vores behov sker i Procestrekanten. Resultaterne placeres i OIO-reolen. ATP har valgt at anvende reolen, fordi den er det offentlige Danmarks anbefaling af, hvordan dokumentation skal struktureres og fremvises. Ved at anvende OIOreolen, anvender vi samme sprog og metode som det offentlige Danmark, hvilket er en fordel i samarbejdet med øvrige myndigheder. Vi har dog valgt at tilpasse standard OIO-reolens indhold af artefakter med ATP-koncernens egen standard, så det er en ATP-udgave af OIO reolen. OIO står for Offentlige Information Online, og er en struktur for dokumentation af arkitekturartefakter. Reolen indeholder den samlede dokumentation for en løsning. OIO-reolen kan sammenlignes med en velordnet bogreol, idet den giver systematik og overblik over dokumentationen: Forståelsen for vores forretningsmæssige behov fremkommer ved at arbejde med koblingen af informationer, funktionalitet og processer, som det er anskueliggjort i Procestrekanten, mens beskrivelsen af vores behov udmøntes i en række artefakter, som vi dokumenterer i vores OIO-reol. Figuren viser OIO-reolen: Bilag 2A Sådan forretningsmodellerer vi i ATP Side 7 af 32

9 Figur 3 OIO-reolen for Barsel Bemærk ATP har udarbejdet de sorte artefakter i udbudsmaterialet og udarbejder i projektets implementeringsfase de grønne artefakter. Leverandøren leverer de røde artefakter jf. bilag 4 (Dokumentation). 3.2 Sådan er reolen opbygget På det konceptuelle niveau beskriver dokumenterne de overordnede, strategiske beslutninger. Ejerskabet er forankret hos ledelsen i organisationen. På det logiske niveau beskriver dokumenterne de generelle designregler, man opererer ud fra. Ejerskabet er forankret hos de ansvarlige for den daglige ledelse i organisationen. På det fysiske niveau er ejerskabet forankret hos de operationelt ansvarlige i organisationen, og herunder hos de leverandører man benytter til at levere løsninger. Fra venstre til højre i reolen sker der en klassificering af dokumentationen fra det strategiske hen mod det mere teknologiorienterede. Fra toppen og ned til bunden sker der en nedbrydning og detaljering af dokumentationen. OIO-reolens Strategi-søjle indeholder vores Strategiartefakter, fx ATP s digitaliserings-strategi. Forretningsartefakter, som er opstået i alle 3 dele af Procestrekanten, er placeret i OIO-reolens proces-, informations- og funktionalitetssøjle. Teknologiartefakter for it-løsningen, fx sikkerhedsarkitektur, er præsenteret i Teknologisøjlen yderst. Den dokumentation som Leverandøren skal levere, placeres i OIO-reolen på konceptuelt, logisk og fysisk niveau af Proces-, Information-, Funktionalitet og Teknologisøjlerne og er markeret med rød skrift i figuren. Alle de artefakter, der er beskrevet i dette bilag, udstilles i OIO-reolen, som er tilgængelig for Leverandøren fra et lukket site. Leverandøren får mulighed for at klikke sig igennem løsningsflow og herfra have adgang til at klikke på aktivitetsbeskrivelser, begrebs- og informationsmodeller, beslutningsmodeller, IGOE samt gældende lovgivning relateret til løsningsflow. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 8 af 32

10 4 Proces Dette kapitel beskriver, hvordan ATP arbejder med forretningsmodellering på et overordnet niveau. Med forretningsarkitekturen som overligger, kobles forretningsprocesser sammen med begrebs- og informationsmodeller, gældende lovning og forretningsregler for derved at beskrive vores behov til it-understøttelse og teknisk infrastruktur. Figuren viser placering af procestrekanten og den indhold i OIOreolen: Figur 4 Procestrekant fokus på proces 4.1 Indledning Forretningsprocesser beskriver de aktiviteter, der foregår fra en virksomhed indberetter og videre gennem sagsbehandlingen i Udbetaling Danmark, til ansøgningen er færdigbehandlet. Derudover dækker forretningsprocesserne over de ydelser, der går på tværs og leverer support til kerneprocesserne (Barselprocesserne). Forretningsprocesserne indeholder en række af automatiske og/eller manuelle aktiviteter, hvor man læser, skriver, ændrer eller sletter data ud fra givne forretningsmæssige regler. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 9 af 32

11 Processerne er i dag både et centralt, internt kommunikationsværktøj, men også et værdifuldt værktøj til kommunikation mellem forskellige parter, når vi tænker i nye forretningsmuligheder. Procestankegangen kommunikerer tæt med en række interessenter, fx lovgivere, leverandører, jurister, forretningseksperter, ledelse, kunder og slutbrugere, men også med de eksterne og interne it-systemer som indgår i processen. Den tætte kontakt, og de klare processer, er med til at sikre, at det er nemmere at ændre, justere og optimere processerne. Formålet med at tænke i forretningsprocesser i alle vores aktiviteter er at kunne tilbyde individuelle løsninger fra en standardiseret platform, og samtidigt kunne opnå forretningsmæssige stordriftsfordele i administrationen af ydelser, både til gavn for borger, virksomheder og ATP som forretning evne forandringer på en struktureret facon, uden at sætte kerneforretningen over styr. Vores mind-set er at tænke i helheder, at kigge på processerne end to end som en totaloplevelse og altid med udgangspunkt i personen eller virksomheden. Det er ud fra processerne i vort proceskatalog, at vi opstiller vores krav til den tekniske samt faglige understøttelse af processen. 4.2 Procesoverblik ATP har valgt at gruppere sine processer i et procesoverblik. ATP s procesoverblik er opdelt i: Forretningsmæssig funktionalitet (procesområde: Indberetning, Administration), der indeholder kerneprocesserne omkring vores ordninger (Familieydelser, Barselsdagpenge, Boligstøtte og Pension). Procesområde Udbetaling, der indeholder processer omkring hvordan vi håndterer udbetaling til personer og virksomheder, foretager opkrævning og medfinansiering af ydelser samt udøver Helhedsorienteret kontrol Procesområde Kommunikation, der afspejler vores kommunikationsprocesser på tværs af ordningerne hvordan ATP modtager post, afsender digitale beskeder etc. Procesområde Styringsprocesser, der afspejler vores styringsprocesser på tværs af ordningerne. Procesområde Driftsprocesser, der afspejler vores driftsprocesser på tværs af ordninger og på bestand-niveau inden for en ordning. Figuren nedenfor giver et visuelt overblik over vores processer for barselordningen: Bilag 2A Sådan forretningsmodellerer vi i ATP Side 10 af 32

12 Figur 5 Procesoverblik for barselordningen Procesniveauernes sammenhæng ATP opererer med procesniveauer for at sikre en ensartethed i modelleringen, set i forhold til, hvor dybt man går ned i beskrivelsen af processerne. ATP opererer med fem niveauer på processerne. Figuren viser processerne fra niveau 0 til 4: Bilag 2A Sådan forretningsmodellerer vi i ATP Side 11 af 32

13 Figur 6 Model over procesniveauer Niveau 0 processerne (også kaldet procesområder) fremgår af procesoverblikket. Niveau 1 processerne er de processer, der også fremgår af procesoverblikket. De hører til under hvert Niveau 0 område. Til hver Niveau 1 proces er der koblet en tilhørende Niveau 2 proces. Hver enkel Niveau 2 proces indeholder et løsningsflow (Niveau 3). Løsningsflow indeholder aktiviteter (Niveau 4). Der kan i visse løsningsflow være aktiviteter med et kryds i aktivitetsnavnet, som vist herunder. Figur 7 Aktivitet med kryds i aktivitetsnavnet Det gælder for disse aktiviteter, at de har koblet et løsningssubflow på sig. Løsningssubflowet er en udfoldelse af aktiviteten i en underliggende proces. Proces Niveau 0 Niveau 1 Niveau 2 Niveau 3 Artefakt Procesoverblik IGOE End to end proces Løsningsflow Bilag 2A Sådan forretningsmodellerer vi i ATP Side 12 af 32

14 Proces Niveau 4 Artefakt Aktivitetsbeskrivelser med links til informationsmodel, beslutningsmodel, regler og lovgivning. Tabel 2 Procesniveauer 4.3 End to end processer Mellem Niveau 0 og niveau 1 processer, på procesområderne Indberetning og Administration, har vi endvidere modelleret en end to end proces, der overordnet beskriver hele vejen igennem de underliggende Niveau 2 og 3 processer. Dette artefakt indeholder ingen krav og tjener udelukkende som en oversigtsmodel. 4.4 IGOE En IGOE (input, guidelines, output, enablers) beskriver end to end processen ud fra de 4 kriterier: I (Input) = Hvad er input til start af processen og hvem kommer med det G (Regler/rammer) = Rammerne relaterer til ATP`s interne politikker og reglerne er at sidestille med den lovgivning, der er styrende for processerne (Output) = Hvilket output generer processen E (Ressourcer) = Hvilke systemer, samt ressourcer, er tilknyttet for at understøtte den faglige og tekniske del af processen. De er alle kilder til den endelige destination; resultatet. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 13 af 32

15 Figuren viser en IGOE med dens generelle indhold: Figur 8 En IGOE IGOE en laves i PowerPoint af ATP. Der er udarbejdet IGOE for hele barselordningen. 4.5 Løsningsflows Det er i vores løsningsflows, at vi beskriver processen gennem systemer og flowet mellem interne og eksterne parter. Gennem aktivitetsbeskrivelserne definerer vi de funktionelle krav, vi har for den tekniske understøttelse af aktiviteten. Løsningsflow viser grænseflader og afhængigheder mellem de enkelte parter (borgere, kunderådgivere, fagsystem, andre interne systemer samt 3. mand), herunder hvilke arbejdsopgaver og/eller funktionalitet, der ikke er automatiseret. Svømmebanerne borger og kunderådgiver viser hvad borgeren skal gøre og hvilke arbejdsopgaver og situationer kunderådgiverne skal håndtere. Løsningsflow siger ikke noget om mængder, peaks, tid herunder online eller batch, ekspeditionstider eller angiver konkrete budskaber i breve/på nettet samt arbejdsopgavernes kompleksitet, herunder hvordan arbejdet i Kundeservice er organiseret. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 14 af 32

16 Løsningsflow er udarbejdet til fordel for it-leverandørerne og viser de krav og den funktionalitet, som vi ønsker, at it-leverandøren skal håndtere, samt en mulig måde hvorpå processerne i fagsystemet kan være håndteret. Figur 9 Løsningsflow LF Barsel: Afgør ansøgning Aktivitetsbeskrivelser Aktivitetsbeskrivelserne er opbygget i en bestemt afsnitsstruktur på tværs af alle løsningsflow. Tabellen nedenfor beskriver de forskellige emner, som indgår i strukturen og som er afspejlet i billedet ovenfor: Emne Formål Start betingelser/ Forudsætninger Beskrivelse Kort beskrivelse af aktivitetens formål Startbetingelser/Forudsætninger angiver, hvilke betingelser der er for at aktiviteten kan gennemføres. Et eksempel er, at en forudgående aktivitet er blevet gennemført, eller en given information er modtaget. Det kan forekomme, at der er mere end én startbetingelse til en aktivitet. Hvis dette er tilfældet, skal startbetingelser opsættes i punktform. Beskrivelsen af en startbetingelse skal være kort og sigende. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 15 af 32

17 Emne Input Beskrivelse Sluttilstand Output Regler Behov for understøttelse af aktivitet Kontrol Beskrivelse Input angiver, hvad der eventuelt modtages til at starte processen. Det kan være en datafil systemgenereret godkendelse eller advis. Input skal stemme overens med outputtet fra den foregående aktivitet. En længere beskrivelse af hvad aktiviteten omfatter. Evt. på punktform eller som en længere tekstbeskrivelse, som supplerer den korte. Som en del af beskrivelsen beskrives rollerne (dem der har en aktie i aktiviteten). Vi beskriver sluttilstanden, når vi har gennemført en aktivitet. Sluttilstanden følger samme princip som startbetingelsen. Output angiver, hvad der i sidste ende generes af selve aktiviteten, og hvilke krav der er til evt. form. Output følger samme princip som Input I dette afsnit henvises til de beslutningsmodeller/regler der ønskes implementeret til styring af aktivitetens funktionalitet. Det er også her at der kan kobles gældende lovgivning til aktiviteten, for at synliggøre hvorfor vores beslutningsmodeller/regler ser ud som de gør. Beskriver de konkrete krav til leverandørens leverance, både for funktionelle såvel som krav til afklaringsforløb I dette afsnit refererer vi til bestemte attributter i informationsmodellen, i de tilfælde hvor det er nødvendigt for forståelsen af kravene. Der gælder følgende retningslinjer: Der skives tydeligt hvad Leverandøren skal levere Hvor der er tilknytning til en snitflade fremgår dette med reference til entydigt integrationsid Først står hvad Leverandøren skal levere (systemunderstøttelse) Dernæst hvad der er af krav til Leverandøren omkring proces i afklarings-etapen eller i delleverancens afklaringsforløb Hvis andre Leverandører skal levere ind til aktiviteten vil dette stå til sidst Kontrol angiver, hvilke handlinger der skal udføres, for at aktiviteten bliver udført korrekt samt hvilken lovgivning aktiviteten understøtter. Tabel 3 Indhold i aktivitetsbeskrivelse Bilag 2A Sådan forretningsmodellerer vi i ATP Side 16 af 32

18 4.7 Nummereringsstruktur af processer Der er koblet en nummereringsstruktur på alle Niveau 1 og 2 processer, samt de løsningsflows og løsningssubflows, der er koblet op på Niveau 2 processerne. Figuren viser dén struktur, nummereringen af en given proces følger: Figur 10 Nummereringsstruktur af processer. Figuren nedenfor viser, hvordan procesområde og ordningsnumrene er givet på forhånd for hver enkelt proces: Procesområde Procesområde nr. Ordning Ordning nr. Indberetning 1 Pension 1 Administration 2 Boligstøtte 2 Udbetaling 10 Barselsdagpenge 3 Kommunikation 20 Familieydelser 4 Styringsprocesser 30 Ikke specifik ydelse x Driftsprocesser 40 N/A N/A Bilag 2A Sådan forretningsmodellerer vi i ATP Side 17 af 32

19 Tabel 4: Nummerering af procesområde og ordninger. Niveau 1 og 2, samt løsningssubflow-nummeret afhænger af, hvilken rækkefølge processerne er grupperet i. Disse nummereres fortløbende med nummer 1 som start indenfor hver Niveau 0 proces. Hvis en proces benyttes på tværs af Ordninger, og betragtes den som en generisk proces, og den får et X i stedet for et nummer i nummereringen. Tabellen viser et eksempel herpå: Procesområde Ordningsområde Niveau 1 proces Niveau 2 proces Resultat = Løsningsflow Indberetning Barselsdagpenge Barselsdagpenge, Håndter Udfyld indberetning - indberetning person LF Barsel Udfyld indberetning person Indberetning Barselsdagpenge Barselsdagpenge, Tilkend Afgør sag - ydelse LF Barsel Afgør sag Udbetaling - Håndter udbetaling Håndter udbetaling - person 10 X 1 1 LF Udbetaling Håndter udbetaling person 10.x.1.1 Tabel 5 Nummereringsstruktur fra procesområde til løsningsflow eksempel. 4.8 Flowregler Flowregler modelleres når endelig proces (løsningsflow) er udarbejdet i samspil med Leverandør. Flowregler udarbejdes jf. beskrivelse i afsnit 6.8 Bilag 2A Sådan forretningsmodellerer vi i ATP Side 18 af 32

20 5 Information Dette kapitel skal give en forståelse af vores metode for modellering af information. Når vi forretningsmodellerer, arbejder vi med Information i Procestrekanten: Figur 11 Procestrekant fokus på information Begrebs- og informationsmodellerne indeholder krav til, hvilke forretningsmæssige begreber, som skal kunne persisteres i Leverandørens løsning. De forretningsmæssige behov for information beskrives og dokumenteres i begrebs- og informationsmodeller. Leverandøren beskriver og leverer dokumentation for løsningen i logiske og fysiske datamodeller. Dette kapitel forklarer vores begrebsarkitektur, valg af begrebsdokumentation, dokumentationsværktøj. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 19 af 32

21 5.1 Informationsartefakter Information i Procestrekanten, Figur 11 Procestrekant fokus på information, beskrives i fire forskellige modeller. Figuren viser de fire modeller: Model Indhold Ansvar Begrebsmodel Forretningsmæssige Informationsmodel Begreber ATP leverer Logisk datamodel Systemmæssige begreber Fysisk datamodel Systemdata Leverandøren udarbejder Tabel 6 Oversigt over de fire forskellige modeller i Information Overgangen mellem forretningsmæssige og systemmæssige begreber sker mellem informationsmodellen og den logiske datamodel. Det er vigtigt, at der er sammenhæng herimellem, så der sikres kontinuitet mellem modellerne for forretning og for system. ATP udarbejder begrebs- og informationsmodeller og har modelleret efter følgende regler: Vi prioriterer det højere, at modellerne indeholder genkendelige forretningsmæssige begreber, fremfor at modelleringen er korrekt i forhold til generelle principper for datamodellering. Der afviges for eksempel fra princippet om, at data kun bor ét sted i modellen, hvis det er relevant for forretningen at se både inputdata, og også hvor disse data anvendes. Der afviges også fra normaliseringsregler. Modellerne er statiske modeller, og de har ikke nogen tidsmæssigt forløb, Modellerne viser intet om behov for historiske data. Modellerne har alle en generel definition af begreberne, samt eventuelt også kommentarer. Modellerne indeholder udelukkende de forretningsmæssige begreber som skal systemunderstøttes. Begreber og attributter kan ændre sig som følge af det udviklingsarbejde, der starter sammen med Leverandøren. Vi har generiske modeller, som indeholder begreber som skal anvendes i alle ordninger Vi har specifikke modeller, som indeholder begreber og som kun skal anvendes i en enkelt ordning. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 20 af 32

22 Opdelingen mellem de enkelte modeller er en forretningsmæssig logisk opdeling, som ikke har nogen sammenhæng til, hvordan der vælges at opdele data i forskellige systemer. Opdelingen af data i fagsystemer fastlægges alene i forretningsarkitekturen. Som en grov hovedregel kan man dog antage, at Barseldagpengemodellen og store dele af Sagsmodellen indeholder den forretningsmæssige information som skal ligge i Barseldagpengeløsningen. Beriget Grunddata-modellen indeholder den information, som ligger i støttesystemet (Beriget Grunddata). Udbetaling-modellen indeholder den information, som ligger i støttesystemet (Udbetaling). Opkrævning er ikke modelleret særskilt. 5.2 Begrebsmodeller Begrebsmodeller er de overordnede modeller af vores forretningsdomæne. De viser konceptuelle begreber og relationer, som indgår i Udbetaling Danmarks sagsbehandling. Overordnet set kan vi modellere Udbetaling Danmarks sagsbehandling, som vist i figuren nedenfor, hvor det ses, hvordan vi interagerer med omverdenen i behandlingen af sager i de forskellige ordninger: Overordnet begrebsmodel for Udbetaling Danmark Figur 12 Overordnet begrebsmodel Bilag 2A Sådan forretningsmodellerer vi i ATP Side 21 af 32

23 Alle begreber og attributter i begrebs- og informationsmodellerne er, når det er muligt, defineret efter følgende i prioriteret rækkefølge: 1. Fællesoffentlige standarder på området 2. Fælles afklaring med KOMBIT 3. Internt afklaret i Udbetaling Danmarks forretningsområder Den overordnede begrebsmodel viser, hvordan Personer, Virksomheder eller Myndigheder kan starte eller have en relation til en given sag, som Udbetaling Danmark foretager automatisk og/eller manuel sagsbehandling på. Vi har nedbrudt denne overordnede begrebsmodel i en række mere detaljerede begrebsmodeller. De generiske modeller er fælles for Udbetaling Danmarks ordninger, og indeholder således forretningsmæssig information for flere ordninger. Der er følgende generiske modeller: Beriget Grunddata Sag Udbetaling De specifikke modeller, derimod, rummer kun information for en enkelt ordning. Der er følgende specifikke begrebsmodeller: Barseldagpenge Boligstøtte Familieydelse Pension Helhedsorienteret kontrol Særlige forhold ved begrebsmodeller Det er værd at bemærke omkring begrebsmodeller, at der er ingen attributter på entiteter vi modellerer i et UML værktøj (QLM) entiteter er repræsenteret som enkeltenheder logisk samhørende entiteter er samlet i delområder. 5.3 Informationsmodeller Informationsmodellerne tager udgangspunkt i begrebsmodellerne og er detaljerede og udbyggede modeller af begrebsmodeller. Informationsmodellerne er tillige udgangspunktet for de logiske datamodeller. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 22 af 32

24 Der er én Informationsmodel for hver begrebsmodel, og derudover er der lavet en særskilt informationsmodel for Udbetaling Danmark. Dette er gjort af hensyn til overskueligheden. Informationsmodellerne, samt begrebsdefinitioner, findes i OIO reolen Særlige forhold ved informationsmodeller Informationsmodellerne er beriget med attributter gennem arbejdet med aktivitetsbeskrivelser. Sammen med en leverandør gennemføres en proces i afklaringsetapen eller i delleverancers afklaringsforløb som valider og supplerer informationsmodellerne. Der er ikke sat systemtekniske nøgler på klasserne, og der er kun sat forretningsmæssige nøgler på enkelte klasser. Det er gjort, hvor de forretningsmæssige nøgler er alment kendt og anvendt i forretningen. Informationsmodellerne ligger på det logiske niveau i OIO-reolen og danner, sammen med løsningsflows og beslutningsregler, en sammenhængende dokumentation af de forretningsmæssige behov. Forretningskomponenters logiske opdeling er lagt til grund for informationsmodellens logiske opdeling. Informationsmodellerne danner, sammen med aktivitetsbeskrivelserne i løsningsflow, en sammenhæng mellem funktionalitet og information. Hvor der i aktivitetsbeskrivelser i løsningsflow er henvisning til forretningsmæssige begreber skal disse kunne findes i informationsmodeller. Det giver en kvalitetssikring af, at de færdige informationsmodeller indeholder alle forretningsmæssige begreber. Vi modellerer i et UML Class diagram (QLM) Entiteter er repræsenteret i enkeltenheder (Class) Logisk samhørende entiteter er samlet i delområde (Package) Blå entiteter er hjemmehørende i en anden informationsmodel men er indeholdt for at lette forståelsen for en sammenhæng En attribut på en class kan være obligatorisk eller frivilligt udfyldt. Denne skelnen kan ses ud fra attributtens multiplicity En attribut på en class kan være følsomt data som skal logges. Det vises med en logningsmarkering. Dette ses på hver class, hvor attributten har følgende markering: o (-)foran attributten betyder: Private; følsomt data, logning påkrævet. o (+) foran attributten betyder: Public; ikke-følsom data, logning ikkepåkrævet. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 23 af 32

25 o o (~) foran attributten betyder: Package; der er en regel der afgør om logning er påkrævet (#) foran attributten betyder: Protected; som har betydning for logning. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 24 af 32

26 6 Funktionalitet Dette kapitel skal give en forståelse af ATP s metode for modellering af funktionalitet Når vi forretningsmodellerer, arbejder vi med Funktionalitet i Procestrekanten: Figur 13 Procestrekant fokus på funktionalitet Funktionalitetsartefakterne vist i figuren indeholder krav til arkitekturen og rammerne for den forretningsmæssige funktionalitet. 6.1 Indledning Leverandøren bliver i stand til at forstå vores funktionalitetsartefakter, som indeholder krav til arkitekturen og rammerne for den forretningsmæssige funktionalitet, som leverandøren skal udvikle. 6.2 Forretningskomponentmodel konceptuel ATP s konceptuelle forretningskomponentmodel er udmøntet i en faktisk model for Barsel. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 25 af 32

27 6.3 IT Målarkitektur IT Målarkitekturen har fokus på it-understøttelse af forretningsmålarkitekturen. Oversigten viser hvordan IT arkitekturen ser ud efter implementering af KUP projekterne: Barsel Pension Familieydelser Boligstøtte Opkrævning MultiFagsystem (tværgående ESDH) Fælles offentlige løsninger benyttes i videst muligt omfang. 6.4 IT Udbudsarkitektur IT Udbudsarkitekturen er udarbejdet med afsæt i IT målarkitekturen og afspejler den IT arkitekturen efter implementering af Barseldagpengesystemet. 6.5 Ordningsoverblik Et Ordningsoverblik viser ordningen set fra Ordningens parter, og det viser datastrømme mellem parterne og Ordningen. 6.6 Systemlandskab Systemlandskabet for Barseldagpengesystemet viser den samlede it-løsning samt den kommunikation, der foregår mellem Fagsystemet og de eksterne it-systemer og komponenterne. Systemlandskabet er tegnet i et komponentdiagram. 6.7 Forretningskomponenter - og model Forretningskomponentmodellen viser Systemets interne komponenter. Komponentmodellen er tegnet i et komponentdiagram.. De enkelte komponenter er beskrevet ved deres ansvar samt deres relation med andre systemer/komponenter. Barseldagpengesystemet er opdelt i forretningskomponenter, hvor hver komponent er en logisk afgrænset del af Systemet, som indeholder funktionalitet og information til at udføre aktiviteter, der ligger indenfor komponentens område. En brevkomponent sørger for at udtrække data og tekst til breve, indsamle adresser og pakke det hele sammen, således at en printleverandør kan foretage udprintning. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 26 af 32

28 Systemet er opdelt i komponenter for at sikre løs kobling mellem komponenterne og høj samhørighed indenfor en komponent. Opdelingen i komponenter giver ATP en større fleksibilitet til at løfte en komponent fra Systemet op til at være en generisk komponent som kan anvendes af flere ordninger. 6.8 Regelmodellering via beslutningsmodeller I ATP anvender vi beslutningsmodeller i forbindelse for alle automatiserede beslutninger. Beslutningsmodellering er en metodik, der har til formål at sikre, at alle nødvendige informationer der er forbundet med en aktivitet kontrolleres på det rigtige tidspunkt. Vi modellerer vores beslutninger og forretningsregler ved hjælp af Beslutningsmodellen ( The Decision Model ), som er defineret af Barbara von Halle og Larry Goldberg i bogen The Decision Model (2009). Beslutningsmodellen er karakteriseret ved, at den fokuserer på beslutningslogik o Forretningsregler og beslutninger kan analyseres på lige fod med processer og information o Analysen understøttes af principper og guidelines kombinerer diagrammer og beslutningstabeller o Modellen anvender en simpel notation som er let overskuelig o Kombinerer grafisk og tabel-baseret dokumentation o Simplificerer forretningsprocesserne o Går fint i spænd med proces- og informationsmodeller, idet de let kan kobles sammen er teknologiuafhængig o Kan implementeres i forskellige teknologier (arbejdsgange/instrukser, programlogik, regelmaskiner mv.). En beslutningsmodel udarbejdes som et diagram, og bruges således til at systematisere forretningsregler. Dette giver et overblik over de forskellige parametre, der indgår i en beslutning eller en regel. Ved hjælp af beslutningsmodellen vises logikken bag en proces, regel eller beslutning, så der kan kobles korrekt lovgivning på processerne. På den måde sikrer vi os, at alle retningslinjer er overholdt. En beslutning består, som vist på tegningen nedenfor, af en eller flere regelfamilier. En regelfamilie er en samling af fakta. Hver regelfamilie indeholder som minimum ét Bilag 2A Sådan forretningsmodellerer vi i ATP Side 27 af 32

29 faktum, som kombineres med flere regelfamilier eller fakta. Figuren viser et eksempel på en beslutning: Figur 14 Et overblik over, hvad en beslutning indeholder For at gøre en beslutning så overskuelig og gennemsigtig som muligt, nedbrydes den i dele, hvor hver del er repræsenteret af en regelfamilie. I eksemplet ovenfor nedbrydes én regelfamilie i yderligere to dele, som hver bidrager med en delkonklusion; delkonklusion 1 og 2. Resultaterne af disse to delkonklusioner sammenholdes med Faktum A, hvorefter det munder ud i en endelig konklusion på beslutningen. Ved at liste alle regler eller faktorer op, som kan have betydning for en beslutning, har vi således truffet en beslutning, som baserer sig på korrekt kontrollerede data og fakta. Det er imidlertid ikke alle beslutninger, der kan dækkes fyldestgørende ved hjælp af modellen alene. Derfor kan beslutningsdokumentationen ofte også bestå af et notat, der beskriver den komplette samling af lovgivning og regler inden for en bestemt ydelse eller aktivitet. Et sådant notat vil typisk indeholde følgende: Kobling til forretningsprocessen Bilag 2A Sådan forretningsmodellerer vi i ATP Side 28 af 32

30 Supplerende beskrivelser af beslutningslogik Supplerende beskrivelser af beregningsregler Antagelser, afgrænsninger, og forslag til regelforenklinger Eksempler på metoden for beslutningsmodellering For at vise hvordan beslutninger og regler modelleres og læses, følger her to eksempler på måder, hvorpå vi bruger beslutningsmodellering. Når man læser modellen, er det vigtigt at huske, at der implicit står OG mellem alle kolonner, og ELLER mellem alle rækker. Det vil altså sige, at hvis man i den første række kan svare ja, og der i den række ikke er flere kolonner med noget i, så kan man gå videre til næste model. Hvis man til gengæld svarer nej, og der er flere kolonner, er det vigtigt, at de alle er positivt udfyldt (altså med ja eller ok ), før man går videre til næste model. Hver beslutningsmodel er koblet på en aktivitet i et løsningsflow. Beslutningsmodellerne er således altid tæt knyttet til processen. Eksempel Beslutningsmodel: Valider NemRefusion-oplysninger. Findes i aktivitet Valider NemRef. Oplysn., som ligger i løsningsflows LF - Barsel - Udfyld indberetning, virksomhed og LF - Barsel - Håndter løbende ændring - virksomhed Beslutningen går på at validere, om de modtagne data fra NemRefusion er OK: Bilag 2A Sådan forretningsmodellerer vi i ATP Side 29 af 32

31 Figur 15 Oversigt over beslutningen Valider NemRefusion-oplysninger Som det ses ovenfor, består beslutningen, som på figuren er vist som ottekantet, af én regelfamilie, som er afhængig af tre andre regelfamilier. For at få det bedste overblik går vi struktureret til modellen, og starter i bunden og kigger på, om Validering 1 er OK: Figur 16 Beslutningstabel: Validering 1 Som i det tidligere eksempel starter man i øverste venstre hjørne af modellen og læser i skriveretningen. Modellen viser således, at hvis fraværsårsagen er enten Graviditetsorlov, adoption, sygeligt forløben graviditet, eller offentligt fastsatte bestemmelser (altså alle fraværsårsager som kommer inden en fødsel), OG at datoen for første fraværsdag er før forventet fødsel eller modtagelsesdato, så er valideringen her OK. Hvis man for de samme fraværsårsager har første fraværsdag efter Bilag 2A Sådan forretningsmodellerer vi i ATP Side 30 af 32

32 datoen forventet fødsel eller modtagelse, så er der noget galt med enten dato eller fraværstype, og valideringen er ikke OK. Er der derimod tale om barselsorlov, fædreorlov, forældreorlov eller far indtræder i mors ret til orlov (som først kan startes efter fødslen) som fraværsårsag, så skal datoen for første fraværsdag ligge efter datoen for forventet fødsel eller modtagelse. Delkonklusionen ender altså med enten OK eller Ikke OK, og vi går videre til næste regelfamilie: Validering 2 : Figur 17 Beslutningstabel: Validering 2 Igen startes der i øverste venstre hjørne, og vi kan se, at hvis fraværsårsagen er fædreorlov, skal varigheden være under eller lig med 14 dage for at valideringen er OK. Er varigheden længere end 14 dagen (som længden på en fædreorlov) er der lavet fejl i indberetningen, og valideringen er ikke OK. I den tredje validering tjekker vi, om der i forvejen findes en aktiv sag på indberetningen (for at undgå at få den samme sag ind flere gange): Figur 18: Beslutningstabel: Validering 3 Her kan vi se, at hvis der er tale om graviditetsorlov, adoption, sygeligt forløben graviditet eller offentligt fastsatte bestemmelser, så må der ikke eksistere en allerede aktiv sag på den person og virksomhed. Gør der det, er valideringen ikke OK. Hvis der ikke allerede findes en sag er valideringen OK, og hvis der er tale om andre fraværsårsager er valideringen også OK. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 31 af 32

33 Delkonklusionerne fra de tre regelfamilier samles nu i den overordnede regelfamilie, Validering OK? : Figur 19 Beslutningstabel: Validering OK? Delkonklusionerne fra de tidligere regelfamilier sammenholdes nu med de øvrige parametre for validering, og det er således i yderste højre kolonne, at vi findes den endelige konklusion af, om valideringen er OK. Som det kan ses i tabellen er forudsætningen for at valideringen er OK, at Validering 1, Validering 2 og Validering 3 er OK, samt at første fraværsdato skal være mindre end 9 måneder fra dags dato, og at barselsperiodens slutdato skal være efter datoen for første fraværsdag. Er disse parametre overholdt, er valideringen OK. Hvis der mangler et OK i en eller flere af kolonnerne er valideringen ikke OK. Kun hvis der er gået mere end 7 uger siden datoen for sidste fraværsdag tager vi sagen til manuel behandling også på trods af at de øvrige valideringer i modellen ikke var OK Særlige forhold ved beslutningsmodeller Beslutningsmodeller modelleres i QLM, og kobles sammen med informationsmodeller og løsningsflows i aktivitetsbeskrivelser: Beslutningsmodeller tager udgangspunkt og forankres i aktivitetsbeskrivelser Der modelleres udelukkende beslutninger, som forventes at køre automatisk (fx varetages instrukser til kunderådgivere ikke af os, men af ordningsansvarlige). Bilag 2A Sådan forretningsmodellerer vi i ATP Side 32 af 32