Bilag 2E - Sådan forretningsmodellerer vi i ATP

Bilag 2E - Sådan forretningsmodellerer vi i ATP
Version 0.8
22-11-2013

Indhold
1 Vejledning til Tilbudsgiver ...................................................................................................................... 3
2 Indledning ................................................................................................................................................ 4
3 Sådan forretningsmodellerer vi i ATP .................................................................................................... 5
3.1 Artefakter forankres i OIO-reolen ................................................................................................ 6
3.2 Sådan er reolen opbygget ........................................................................................................... 7
4 Proces ...................................................................................................................................................... 8
4.1 Indledning ................................................................................................................................... 8
4.2 Procesoverblik ............................................................................................................................ 9
4.3 End to end processer ................................................................................................................ 12
4.4 IGOE ........................................................................................................................................ 12
4.5 Løsningsflows ........................................................................................................................... 13
4.6 Aktivitetsbeskrivelser ................................................................................................................ 14
4.7 Nummereringsstruktur af processer .......................................................................................... 16
5 Information ............................................................................................................................................ 19
5.1 Informationsartefakter ............................................................................................................... 20
5.2 Begrebsmodeller ....................................................................................................................... 21
5.3 Informationsmodeller ................................................................................................................ 23
6 Funktionalitet ......................................................................................................................................... 25
6.1 Indledning ................................................................................................................................. 25
6.2 Forretningskomponentmodel – konceptuel ................................................................................ 26
6.3 Teststrategi – konceptuel .......................................................................................................... 26
6.4 Ordningsoverblik ....................................................................................................................... 26
6.5 Systemlandskab ....................................................................................................................... 26
6.6 Løsningsarkitektur .................................................................................................................... 26
6.7 Forretningskomponenter - og model ......................................................................................... 29
6.8 Regelmodellering via beslutningsmodeller ................................................................................ 29
6.8.1 Eksempler på metoden for beslutningsmodellering ................................................................... 32
Bilag 2E – Sådan forretningsmodellerer vi i ATP
1

Figur 1: Procestrekanten ................................................................................................. 5
Figur 2: OIO-reolen for Barsel ......................................................................................... 6
Figur 3: Procestrekant – Fokus på Proces ....................................................................... 8
Figur 4: Procesoverblik for barselordningen. .................................................................. 10
Figur 5: Model over procesniveauer .............................................................................. 11
Figur 6: En IGOE .......................................................................................................... 13
Figur 7: Løsningsflow LF Barsel: Afgør ansøgning 1.3.2.3. ............................................ 14
Figur 8: Nummereringsstruktur af processer. ................................................................. 17
Figur 9: Nummerering af procesområde og ordninger. ................................................... 17
Figur 10: Nummereringsstruktur fra procesområde til løsningsflow – eksempel.............. 18
Figur 11: Procestrekanten – Fokus på information. ........................................................ 19
Figur 12: Tabel over de fire forskellige modeller i Information ........................................ 20
Figur 13: Overordnet begrebsmodel .............................................................................. 22
Figur 14: Et overblik over, hvad en beslutning indeholder .............................................. 31
Figur 15: Oversigt over beslutningen ’Valider NemRefusion-oplysninger’ ....................... 32
Figur 16: Beslutningstabel: ”Validering 1” ...................................................................... 33
Figur 17: Beslutningstabel: ”Validering 2” ...................................................................... 33
Figur 18: Beslutningstabel: ”Validering 3” ...................................................................... 34
Figur 19: Beslutningstabel: ”Validering OK?” ................................................................. 34
Tabel 1 Procesniveauer ................................................................................................ 12
Tabel 2 Indhold i aktivitetsbeskrivelse ........................................................................... 16
Bilag 2E – Sådan forretningsmodellerer vi i ATP
2

1 Vejledning til Tilbudsgiver
Bilaget skal ikke ændres af Tilbudsgiver.
Tabel 1 Vejledning til Tilbudsgiver
Bilag 2E – Sådan forretningsmodellerer vi i ATP
3

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.
Nedenfor ses sammenhænge mellem 5 centrale mantra, overordnet forretningsarkitektur
samt procestrekantens artefakter. Ligeledes hvordan de enkelte områder er forankret i
OIO-reolen:
Figur 1 Procestrekant i samspil med artefakter og OIO reolen
Bilag 2E – Sådan forretningsmodellerer vi i ATP
4

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 2E – Sådan forretningsmodellerer vi i ATP
5

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 OIO-reolen,
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:
Figur 3: OIO-reolen for Barsel
Bilag 2E – Sådan forretningsmodellerer vi i ATP
6

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
3.2 Sådan er reolen opbygget
På det konceptuelle niveau beskriver dokumenterne de overordnede, strategiske
beslutninger. Ejerskabet er normalt 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,
således at vi på det konceptuelle niveau har fx Udbetaling Danmark loven, og helt nede
på det fysiske niveau har en konkret vejledning om det fællesoffentlige grunddata
program.
OIO-reolens Strategi-søjle indeholder vores Strategiartefakter, fx ATP’s digitaliseringsstrategi.
Forretningsartefakter, som er opstået i alle 3 dele af Procestrekanten, er placeret
i OIO-reolens proces-, informations- og funktionalitetssøjle. Teknologiartefakter for itlø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øsningsflows og herfra have adgang til at klikke på aktivitetsbeskrivelser,
informations/begrebsmodeller, beslutningsmodeller, IGOE`s samt gældende lovgivning
relateret til løsningsflow.
Bilag 2E – Sådan forretningsmodellerer vi i ATP
7

4 Proces
Kommentar [LWL1]: Skal
sammenholdes med vejledningen for at
eliminere overlap - BRM
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 OIO-reolen:
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).
Bilag 2E – Sådan forretningsmodellerer vi i ATP
8

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.
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.
Bilag 2E – Sådan forretningsmodellerer vi i ATP
9

• Procesområde ’Driftsprocesser’, der afspejler vores driftsprocesser på tværs af
ordninger og på bestand-niveau inden for en ordning.
• Procesområde ’Støtteprocesser’, der afspejler vores støtteprocesser på tværs af
ordningerne.
Figuren nedenfor giver et visuelt overblik over vores processer for barselordningen:
Figur 5: Procesoverblik for barselordningen.
Bemærk om 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 2E – Sådan forretningsmodellerer vi i ATP
10

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.
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
Artefakt
Procesoverblik
IGOE
Bilag 2E – Sådan forretningsmodellerer vi i ATP
11

Niveau 2
Niveau 3
Niveau 4
End to end proces
Løsningsflow
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
destionation; resultatet.
Figuren viser en IGOE med dens generelle indhold:
Bilag 2E – Sådan forretningsmodellerer vi i ATP
12

Figur 7: En IGOE
IGOE’ en laves i PowerPoint af ATP og linkes sammen med end to end processen. Der
er udarbejdet IGOE for hele barselordningen samt IGOE’s pr niveau 1 proces indenfor
procesområderne Indberetning og Administration.
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.
Bilag 2E – Sådan forretningsmodellerer vi i ATP
13

Figur 8: Løsningsflow LF Barsel: Afgør ansøgning 1.3.2.3.
4.6 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 2E – Sådan forretningsmodellerer vi i ATP
14

Emne
Input
Beskrivelse
Sluttilstand
Output
Regler
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.
Bilag 2E – Sådan forretningsmodellerer vi i ATP
15

Emne
Behov for
understøttelse
af aktivitet
Kontrol
Beskrivelse
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:
• Skriv meget tydeligt hvad Leverandøren skal levere
• Hvor der er tilknytning til en snitflade, skal det fremgå med
reference til entydigt Integrations_id eller Snitflade-id
• Skriv først hvad Leverandøren skal levere –
systemunderstøttelse
• Skriv dernæst hvad der er af krav til Leverandøren omkring
proces i afklarings-etapen eller i delleverancens
afklaringsforløb
• Udtrykt som kan benyttes er
o valider og supplere (data)
o detailspecificere
• Hvis der fx er beskrivelse af hvad andre fx DKC skal levere
skal 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
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:
Bilag 2E – Sådan forretningsmodellerer vi i ATP
16

Figur 9: 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
Støtteprocesser 50 N/A N/A
Figur 10: 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
Bilag 2E – Sådan forretningsmodellerer vi i ATP
17

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 indberetning
Udfyld
indberetning –
person
-
1 3 1 1 LF – Barsel – Udfyld
indberetning – person
1.3.1.1
Indberetning Barselsdagpenge Barselsdagpenge,
Tilkend ydelse
Afgør sag -
1 3 2 3 LF – Barsel – Afgør
sag – 1.3.2.3
Udbetaling - Håndter udbetaling Håndter
udbetaling –
person
-
10 X 1 1 LF – Udbetaling –
Håndter udbetaling –
person 10.x.1.1
Figur 11: Nummereringsstruktur fra procesområde til løsningsflow – eksempel.
Bilag 2E – Sådan forretningsmodellerer vi i ATP
18

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 12: 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.
Bilag 2E – Sådan forretningsmodellerer vi i ATP
19

Dette kapitel forklarer vores begrebsarkitektur, valg af begrebsdokumentation,
dokumentationsværktøj.
5.1 Informationsartefakter
Information i Procestrekanten, Figur 11: Procestrekanten – Fokus på information.,
beskrives i fire forskellige modeller. Figuren viser de fire modeller:
Model Indhold Ansvar
Begrebsmodel
Informationsmodel
Forretningsmæssige
Begreber
ATP leverer
Logisk datamodel
Fysisk datamodel
Systemmæssige begreber
Systemdata
Leverandøren udarbejder
Figur 13: Tabel 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.
Bilag 2E – Sådan forretningsmodellerer vi i ATP
20

• 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.
• 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. Interessent-, Person-, Virksomhed-,
Myndighed-modellerne 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:
Bilag 2E – Sådan forretningsmodellerer vi i ATP
21

Figur 14: Overordnet begrebsmodel
Den overordnede begrebsmodel viser, hvordan Interessenter af typen Person,
Virksomhed eller Myndighed 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:
• Interessent
• Person
• Virksomhed
• Myndighed
• Sag.
De specifikke modeller, derimod, rummer kun information for en enkelt ordning. Der er
følgende specifikke begrebsmodeller:
• Barseldagpenge
Bilag 2E – Sådan forretningsmodellerer vi i ATP
22

• Boligstøtte
• Familieydelse
• Pension
• Helhedsorienteret kontrol.
Bemærk om 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.
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.
Bemærk
• 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.
Bilag 2E – Sådan forretningsmodellerer vi i ATP
23

• 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:
• (-)foran attributten betyder: Private; følsomt data, logning påkrævet.
• (+) foran attributten betyder: Public; ikke-følsom data, logning ikke-påkrævet.
• (~) 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 2E – Sådan forretningsmodellerer vi i ATP
24

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 15: 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.
Bilag 2E – Sådan forretningsmodellerer vi i ATP
25

6.2 Forretningskomponentmodel – konceptuel
ATP’s konceptuelle forretningskomponentmodel er udmøntet i en faktisk model for
Barsel.
6.3 Teststrategi – konceptuel
ATP’s konceptuelle teststrategi er udmøntet i bilag 6 Test og prøver.
6.4 Ordningsoverblik
Et Ordningsoverblik viser ordningen set fra Ordningens interessenter, og det viser
datastrømme mellem interessenterne og Ordningen.
6.5 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.6 Løsningsarkitektur
ATP har udarbejdet en målarkitektur for Udbetaling Danmark, som på logisk niveau
angiver hvilke it-systemer, ATP ønsker, der skal indgå i den fremtidige
systemunderstøttelse af Udbetaling Danmarks opgaver på ordningerne Barsel, Pension,
Familieydelser, Boligstøtte, Opkrævning og Helhedsorienteret kontrol.
Målarkitekturen skal ses som et udtryk for det systemlandskab, ATP ønsker, når alle de i
dag anvendte KMD fagsystemer er blevet konkurrenceudsat, og der ikke længere indgår
KMD monopolsystemer i understøttelsen af Udbetaling Danmarks opgaver. Da det ikke
vil være muligt at etablere alle systemer på én gang, vil der være en række interimarkitekturer
på vejen mod målarkitekturen.
Målarkitekturen for Udbetaling Danmark er fastlagt under hensyn til Udbetaling Danmarks
arkitekturprincipper (se afsnit 9.3) og herudover særligt drevet af nedenstående ønsker:
• Sikker drift.
• Anskaffelse og drift af støttesystemer skal optimeres på tværs af Udbetaling
Danmark og kommunerne, således at kommunerne ikke skal betale for
anskaffelse og drift af det samme støttesystem to gange
• Processerne og systemerne omkring administrationen af ordningerne skal
optimeres til stordrift, som beskrevet i forretningsarkitekturen
• Der skal høstes stordriftsfordele på ATP’s eksisterende it-infrastruktur
Bilag 2E – Sådan forretningsmodellerer vi i ATP
26

• Fællesoffentlige løsninger søges anvendt.
Figuren nedenfor viser den resulterende målarkitektur:
Figur 16: Udbetaling Danmarks målarkitektur
Målarkitekturen udtrykker, nøjagtigt som beskrevet i forretningsarkitekturen, et
systemlandskab, hvor hver af Udbetaling Danmarks ordninger har et fagsystem, der er
centralt i forhold til understøttelse af de ordningsspecifikke processer og funktionalitet.
Sammen med fagsystemerne anvendes en række tværgående systemer, som
understøtter de processer og den funktionalitet, som skal anvendes på tværs af
ordningerne. Endelig vil der være en række ordningsspecifikke systemer og parter, som
det enkelte fagsystem skal anvende eller levere oplysninger til.
De tværgående systemer udgøres af flere forskellige kategorier af systemer:
• Eksterne kanaler
Øverst på målarkitekturtegningen optræder de digitale kanaler, hvorigennem der skal
udstilles oplysninger til personer og virksomheder. Der er tale om eksisterende
fællesoffentlige løsninger; Virk.dk, Borger.dk og Digital Post. Derudover er der
Bilag 2E – Sådan forretningsmodellerer vi i ATP
27

mulighed for, at der kan komme andre kanaler til.
• ATP koncern IT infrastruktur
ATP har en række it-systemer og it-infrastruktur, som anvendes bredt i hele
koncernen, herunder Udbetaling Danmark. Der er tale om pc’er og
kontorstøttesystemer, intranet, callcenter, bruger-, rolle- og rettighedsadministration,
ERP-system til HR og økonomi, servicedesk-funktion med tilhørende overvågning,
samt infrastruktur til integration med disse systemer.
• Fælles Støttesystemer
Alle Udbetaling Danmarks ordninger skal gøre brug af fælles støttesystemer, som
dækker bestemte funktionelle områder af de tværgående processer. Der er tale om et
udbetalingssystem, samt et system til håndtering af grunddata (person- og
virksomhedsdata). Systemerne etableres som fælleskommunale systemer under
KOMBIT.
• Interne tværgående støttesystemer
Der vil være brug for en række støttesystemer, som indeholder tværgående
forretningslogik, som er unik for Udbetaling Danmark. Der er tale om nogle centrale
elementer i forretningsarkitekturen, nemlig kunderådgiverværktøjet DKC (Digitalt
Kontakt Center), samt Screening for snyd. Disse støttesystemer etableres af ATP
specifikt til Udbetaling Danmark. Endvidere anvendes et datawarehouse og en
videnløsning, som er ATP-systemer udbygget med indhold, der er specifikt for
Udbetaling Danmark.
• Eksterne services
Alle Udbetaling Danmarks ordninger skal gøre brug af nogle ydelser, som leveres af
eksterne parter. Der er tale om håndtering og scanning af indgående post
(kommercielt indkøbt ydelse), samt print og kuvertering af udgående fysisk post (via
den fællesoffentlige fjernprintløsning).
• Fælles eksterne komponenter
Udbetaling Danmarks ordninger anvender en række fælleskommunale eller
fællesoffentlige systemer. Der vil fx være brug for anvendelse af flere af de
støttesystemer som etableres under den fælleskommunale rammearkitektur, fx
Ydelsesindeks, samt fællesoffentlige komponenter som NemLog-in. Endvidere skal
der leveres oplysninger til eller hentes oplysninger fra en række offentlige registre,
Bilag 2E – Sådan forretningsmodellerer vi i ATP
28

herunder SKAT’s eIndkomst. Bemærk, at målarkitekturdiagrammet kun indeholder et
udsnit af de komponenter, systemer og parter, som vil være aktuelle på tværs af
Udbetaling Danmarks ordninger.
• Ordningsspecifikke eksterne komponenter
Udbetaling Danmarks ordninger vil hver især have brug for at anvende eller levere
oplysninger til nogle systemer og parter, som kun er aktuelle for den pågældende
ordning. Målarkitekturdiagrammet viser blot nogle eksempler på systemer i denne
kategori.
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.
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
Bilag 2E – Sådan forretningsmodellerer vi i ATP
29

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 faktum, som kombineres med flere regelfamilier
eller fakta. Figuren viser et eksempel på en beslutning:
Bilag 2E – Sådan forretningsmodellerer vi i ATP
30

Figur 17: 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
• Supplerende beskrivelser af beslutningslogik
• Supplerende beskrivelser af beregningsregler
• Antagelser, afgrænsninger, og forslag til regelforenklinger.
Bilag 2E – Sådan forretningsmodellerer vi i ATP
31

6.8.1 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 1.3.1.2” og ”LF - Barsel - Håndter løbende ændring - virksomhed 2.3.1.2”
Beslutningen går på at validere, om de modtagne data fra NemRefusion er OK:
Figur 18: Oversigt over beslutningen ’Valider NemRefusion-oplysninger’
Bilag 2E – Sådan forretningsmodellerer vi i ATP
32

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 19: 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 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 20: 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.
Bilag 2E – Sådan forretningsmodellerer vi i ATP
33

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 21: 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.
Delkonklusionerne fra de tre regelfamilier samles nu i den overordnede regelfamilie,
”Validering OK?”:
Figur 22: 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.
Bilag 2E – Sådan forretningsmodellerer vi i ATP
34

Bemærk
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 2E – Sådan forretningsmodellerer vi i ATP
35