Bilag 2A Sådan forretningsmodellerer vi i ATP

Størrelse: px
Starte visningen fra side:

Download "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 SÅDAN FORRETNINGSMODELLERER VI I ATP FORRETNINGSMODELLERING I KONTEKST AF FORRETNINGSARKITEKTUREN SUCCESKRITERIER OG DE FEM CENTRALE MANTRA FORRETNINGSMÅLARKITEKTUR FORRETNINGSUDBUDSARKITEKTUR DOKUMENTATIONSREOLEN PROCES IGOE PROCESKATALOG PROCESNIVEAUER LØSNINGSFLOWS AKTIVITETSBESKRIVELSER NUMMERERINGSSTRUKTUR AF PROCESSER INFORMATION INFORMATIONSARTEFAKTER SÆRLIGE FORHOLD VED BEGREBSMODELLER INFORMATIONSMODELLER SÆRLIGE FORHOLD VED INFORMATIONSMODELLER FUNKTIONALITET FORRETNINGSUDBUDSARKITEKTUR FORRETNINGSKOMPONENTMODEL Bilag 2A Sådan forretningsmodellerer vi i ATP Side 1 af 45 1

3 5.3 IT-UDBUDSARKITEKTUR SYSTEMKONTEKST REGELMODELLERING VIA BESLUTNINGSMODELLER EKSEMPLER PÅ METODEN FOR BESLUTNINGSMODELLERING SÆRLIGE FORHOLD VED BESLUTNINGSMODELLER UDVIKLING AF PROTOTYPE FOR SYSTEMETS BRUGERGRÆNSEFLADER OPSTART CO-CREATION KONCEPTDESIGN PROTOTYPING Bilag 2A Sådan forretningsmodellerer vi i ATP Side 2 af 45 2

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 45 3

5 2 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 den enkelte medarbejder i organisationen kan forstå egne arbejdsopgaver i relation til hele forretningen. Processerne viser samspil mellem manuelle opgaver, som udføres af kunderådgivere, og de aktiviteter som udføres automatisk af systemer. Overordnet set beskriver kerneprocesserne behandlingen af informationer. I ATP anvender vi Procestrekanten, se figur 1, til at vise sammenhængen mellem de forretnings- og it-vendte artefakter, der i samspil beskriver en løsning. Når ATP forretningsmodellerer er det tredelingen mellem Proces, Information og Funktionalitet, der er i fokus. Denne tredeling er central for vores måde at forstå, beskrive og dokumentere forretningen og de forretningsmæssige behov på. Koblingen af Proces, Information og Funktionalitet sikrer transparens i forretningen og giver bl.a. mulighed for styring og risikominimering ved ændringer i eksisterende løsninger. Systemerne som udvikles til ydelsesområderne skal levere en forretningsmæssig løsning, der understøtter de forretningsmæssige behov, dette er illustreret ved den stiplede teknologi-trekant i figuren. Hele løsningen beskrives indenfor rammerne af forretningsudbudsarkitekturen. Figur 1 Procestrekanten Bilag 2A Sådan forretningsmodellerer vi i ATP Side 4 af 45 4

6 2.1 Forretningsmodellering i kontekst af forretningsarkitekturen Som overordnet retningsgiver for arbejdet med forretningsmodellering er forretningsudbudsarkitekturen for de enkelte ydelsesområder. Forretningsudbudsarkitekturen for ydelsesområderne beskriver dels sammenhænge mellem de forskellige systemer, registre og parter i den forretningsmæssige løsning, dels den ønskede forretningsmæssige funktionalitet. Forretningsudbudsarkitekturen for ydelsesområderne udarbejdes med afsæt i Udbetaling Danmarks forretningsmålarkitektur og Udbetaling Danmarks succeskriterier og fem centrale mantraer. Nedenfor ses ovennævnte sammenhænge samt procestrekantens artefakter. Ligeledes vises Dokumentationsreolen, hvor artefakter for ydelsesområderne fremgår: Figur 2 Procestrekantens samspil med forretningsmålarkitektur og forretningsudbudsarkitektur 2.2 Succeskriterier og de fem centrale mantra I forbindelse med opstarten af programmet for konkurrenceudsættelse i Udbetaling Danmark er der udarbejdet et sæt af succeskriterier for konkurrenceudsættelsen. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 5 af 45 5

7 Succeskriterierne præsenteres grafisk i en stjerne (grøn), fordi succeskriterierne ikke kan eller skal prioriteres. Alle fem kriterier og det overordnede succeskriterie omkostningseffektive løsninger skal være til stede og være afbalancerede i løsningerne. Omvendt, opfyldes succeskriterierne ikke, træder skyggestjernen (blå) frem i form af succeskriteriernes modsætninger det som ikke må ske. Figur 3 Succeskriterier for konkurrenceudsættelse i Udbetaling Danmark Ydermere er der defineret fem mantraer, der skal sikre, at Udbetalings Danmarks interessenter forstår vores mindset og substansen i vores virke og dermed udgangspunktet for vores behov. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 6 af 45 6

8 Figur 4 Fem centrale mantraer 2.3 Forretningsmålarkitektur Forretningsmålarkitekturen udtrykker visionen for hvordan forretningsarkitekturen skal se ud efter implementering af samtlige udbud i konkurrenceudsættelsesprogrammet i 2020, som omfatter: Barseldagpenge Social Pension Familieydelser Boligstøtte Debitor Fagsystem til kontrol Fællesoffentlige løsninger benyttes i videst muligt omfang. KOMBITs rammearkitektur benyttes til dataudveksling med kommunerne. Forretningsmålarkitekturen beskrives nærmere i bilag 3 (Leverancebeskrivelse). 2.4 Forretningsudbudsarkitektur Forretningsudbudsarkitekturen beskriver dels sammenhænge mellem de forskellige systemer, registre og parter i den forretningsmæssige løsning, dels den ønskede forretningsmæssige funktionalitet. Forretningsudbudsarkitekturen beskrives nærmere i bilag 3A (Behovsopgørelse). Bilag 2A Sådan forretningsmodellerer vi i ATP Side 7 af 45 7

9 2.5 Dokumentationsreolen Vi beskriver og dokumentere de forretningsmæssige behov med udgangspunkt i Procestrekanten. De artefakter der udarbejdes i forbindelse med udbudsprojektet placeres i en ydelsesspecifik Dokumentationsreol. ATP anvender en OIO-inspireret reol, fordi den er det offentlige Danmarks anbefaling for, hvordan dokumentation skal struktureres og fremvises. Hermed sikrer vi samme struktur som det offentlige Danmark, hvilket er en fordel i samarbejdet med øvrige myndigheder. Det offentlige Danmark benytter sig af OIOstandard som står for Offentlig Information Online, og er en struktur for dokumentation af arkitekturartefakter. Vi har dog valgt at tilpasse standard OIOreolens indhold af artefakter med ATP-koncernens egen standard, og omtaler den Dokumentationsreolen. Reolen indeholder den samlede dokumentation for en løsning på et ydelsesområde. 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 Dokumentationsreolen. ATP har udarbejdet eller udarbejder i projekternes implementeringsfase de sorte artefakter i Dokumentationsreolen. Leverandøren leverer de røde artefakter jf. bilag 4 (Dokumentation). Dokumentationsreolen er opbygget af rækker og kolonner, som kort præsenteres nedenfor. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 8 af 45 8

10 Figur 5 Dokumentationsreolen 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. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 9 af 45 9

11 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. Dokumentationsreolens Strategi-søjle indeholder vores Strategiartefakter, fx ATP s digitaliseringsstrategi. Forretningsartefakter, som er udarbejdet i henhold til Procestrekanten, er placeret i Dokumentionsreolens Proces-, Informations- og Funktionalitetssøjle. Teknologiartefakter for it-løsningen, fx sikkerhedsarkitektur, er præsenteret dels i Applikationssøjlen og i Teknologisøjlen. Den dokumentation, som Leverandøren skal levere, placeres i Dokumentationsreolen på konceptuelt, logisk og fysisk niveau af Proces-, Information-, Funktionalitet, Applikation og Teknologisøjlerne. Alle de artefakter, der er beskrevet i dette bilag, udstilles i Dokumentationsreolen, som er tilgængelig for Leverandøren fra et lukket site. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 10 af 45 1

12 3 Proces Dette kapitel introducerer kort ATP s metode for forretningsmodellering med fokus på Proces: Figur 6 Procestrekant fokus på proces I ATP anvender vi processer til at dokumentere og forstå vores forretning. Processerne visualiserer og beskriver de aktiviteter, der gennemføres i ATP fra en henvendelse er modtaget til denne henvendelse er behandlet. En henvendelse kan f.eks. være en ansøgning om en ydelse. Forretningsprocesserne indeholder en række automatiske aktiviteter, hvor systemet læser, skriver, opdaterer eller sletter data ud fra givne forretningsmæssige regler. Processerne indeholder også en række manuelle aktiviteter, hvor det i stedet er en person, der behandler data ud fra de givne forretningsmæssige regler. Derudover er der forretningsprocesser, der går på tværs og leverer support til kerneprocesserne, f.eks. processen omkring modtagelse af post. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 11 af 45 1

13 ATP bruger processerne til at rammesætte behov og krav til eksterne og interne itsystemer. Det er med baggrund i processerne i proceskataloget, at vi opstiller vores krav til den manuelle og maskinelle understøttelse af processen. Vi anvender også processerne som kommunikationsværktøj i dialogen med interessenter så som; lovgivere, leverandører, jurister, forretningsspecialister, ledere, kunder og slutbrugere. Vores mind-set er at tænke i helheder, at kigge på processerne end to end og altid med udgangspunkt i personens, virksomhedens eller myndighedens brugeroplevelse. 3.1 IGOE For at understøtte en fælles forståelse af helhedsbilledet for det enkelte ydelsesområde har ATP udarbejdet en IGOE for hvert udbud. En IGOE beskriver end to end processen for hele ydelsesområdet ud fra følgende fire kriterier: IGOE I Input Her beskrives input til opstart af processen, samt hvem eller hvad der trigger processen. G Guidelines Her beskrives regler og rammer. Rammerne relateres til ATP s interne politikker og reglerne er at sidestille med lovgivningen der regulerer ydelsesområdet. O Output Her beskrives processens output. E Enablers Her beskrives de ressourcer, der er nødvendige for at understøtte den faglige og tekniske del af ydelsesområdets processer. Tabel 2 IGOE Bilag 2A Sådan forretningsmodellerer vi i ATP Side 12 af 45 1

14 Figuren viser nedenfor viser den skabelon, som ATP anvender til udarbejdelse af IGOE for de enkelte ydelsesområder. Figur 7 IGOE 3.2 Proceskatalog ATP har valgt at gruppere sine processer i et proceskatalog. ATP s proceskatalog er opdelt i kerneprocesområderne Indberetning, Administration og Udbetaling. Figuren nedenfor viser proceskataloget, hvor kerneprocesserne for Boligstøtte er markeret. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 13 af 45 1

15 Figur 8 Proceskatalog Bilag 2A Sådan forretningsmodellerer vi i ATP Side 14 af 45 1

16 Kerneprocesområderne indeholder de kerneprocesser, der i deres sammenhæng beskriver de enkelte ydelsesområder (Familieydelser, Barseldagpenge, Boligstøtte, Pension og Debitor). Procesområdet Indberetning indeholder de processer, hvor ATP modtager oplysninger, som danner grundlag for vores administration af ydelserne. Procesområdet Administration indeholder de processer, hvor ATP træffer afgørelser på baggrund af modtagne oplysninger. Derudover findes ydelsesspecifikke processer, der understøtter den daglige drift af ydelsesområderne. Procesområdet Udbetaling indeholder de processer, hvor ATP håndterer udbetaling til personer, virksomheder og myndigheder. Processen hvor de enkelte ydelsesområder danner krav til opkrævning er også placeret i dette procesområde. Procesområdet Kommunikation indeholder ATP s tværgående kommunikationsprocesser eksempelvis modtagelse og afsendelse af post. Procesområdet Styringsprocesser afspejler ATP s styringsprocesser på tværs af ydelserne. Procesområdet Driftsprocesser afspejler ATP s processer der vedrører driften af bestanden indenfor et ydelsesområde. 3.3 Procesniveauer ATP inddeler processer i niveauer for at sikre en ensartet og sammenlignelig modellering set i forhold til, hvordan processerne beskrives. ATP har i alt fem procesniveauer fra 0 til 4. Figuren nedenfor viser procesniveauerne. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 15 af 45 1

17 Figur 9 Procesniveauer Niveau 0 processerne er procesområderne Indberetning, Administration og Udbetaling. De fremgår i proceskataloget som de lyseblå vertikale kolonner omkring niveau 1 processerne. Niveau 1 processerne er overordnede procesgrupper, så som Håndter indberetning, Træf afgørelse mv., som nedbrydes i en række niveau 2 processer, der logisk hører til i procesgruppen. Hvert enkelt niveau 2 proces brydes ned i et løsningsflow, som visualiserer og beskriver processens aktiviteter og de roller der udfører dem. Løsningsflow er procesniveau 3. Alle aktiviteter i løsningsflowet beskrives i prosa og indeholder eventuelle referencer til informations- og beslutningsmodeller. Aktivitetsbeskrivelserne er procesniveau Løsningsflows Det er i vores løsningsflows, at vi visualiserer, hvordan vi ønsker at processen skal forløbe, og hvordan dette forløb kan fordeles på manuelt udførte opgaver og Bilag 2A Sådan forretningsmodellerer vi i ATP Side 16 af 45 1

18 systemunderstøttet funktionalitet. Der angives også snitflader til interne og eksterne parter, så som borgere, eksterne fagsystem, andre interne systemer m.fl. I vores løsningsflows findes der flere fastdefinerede svømmebaner (lanes). Kanalbanen viser al kommunikation mellem Udbetaling Danmark og eksterne parter. Aktiviteterne i Kanalbanen er visualiseret i løsningssubflows, som er generiske på tværs af ydelsesområderne. Svømmebanen selvbetjener angiver selvbetjeningsløsninger, hvor en handling fra borger, virksomhed eller myndighed er påkrævet inden processen startes op i Udbetaling Danmark. Kunderådgiverbanen viser manuelle opgaver, som skal håndteres af en kunderådgiver. Svømmebanen automatisk beskriver de fuldt ud automatiske aktiviteter i processen. Såfremt en automatisk aktivitet ikke kan gennemføres, dannes et advis som sendes til kunderådgiver. I vores løsningflows er dette angivet med en pil (SequenceFlow) mellem svømmebanen automatisk og kunderådgiverbanen. Løsningsflows beskriver ikke noget om gennemløbstid, afviklingstidspunkt og ekspeditionstider. Kompleksiteten i udførelsen af de manuelle aktiviteter kan ikke bestemmes ud fra løsningsflowet, ej heller hvordan opgaveløsningen er organiseret. Kompleksitet kan dog i nogen grad udledes via reglerne i aktivitetsbeskrivelser og antallet af udfald af decisions på løsningsflowet. Den ønskede grad af automatisering fremgår af løsningsflowet ud fra placeringen af aktiviteter i henholdsvis manuelle og automatiske baner. UDK har valgt at angive volumen på løsningsflows. Dette gøres ved farvelægning af pilene mellem aktiviteterne (SequenseFlows). Løsningsflow farvelægges ud fra en volumenbetragtning, hvor motorveje markeres grønne, landeveje blå og bjergveje røde. Motorveje er kendetegnet ved processer med stor volumen. Her tilstræbes fuldautomatisering etableret ved positiv business case. Landeveje er kendetegnet ved processer med middel volumen, hvor hel eller delvis automatisering etableres med positiv business case. Bjergveje er kendetegnet ved processer med lav volumen og lav grad af automatisering, da automatisering ikke kan etableres med positiv business case. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 17 af 45 1

19 Volumen bestemmes ud fra antal hændelser der aktiverer den del af processen som farvelægges. Løsningsflows er udarbejdet til it-leverandørerne og viser sammenhængen mellem de funktionelle krav og den funktionalitet, som vi ønsker, at it-leverandøren skal kunne håndtere, samt en mulig måde hvorpå processerne i fagsystemet kan forløbe. Figur 10 Løsningflow LF-Boligstøtte Træf afgørelse Aktivitetsbeskrivelser Alle aktivitetsbeskrivelserne i løsningflows beskrives via samme skabelon. Tabellen nedenfor beskriver de elementer, der indgår i skabelonen. Emne Formål Startbetingelse Beskrivelse Kort beskrivelse af aktivitetens formål. Startbetingelse angiver, hvilke betingelser der skal være til stede før aktiviteten kan startes op. 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 en startbetingelse til en aktivitet. Hvis dette er tilfældet er startbetingelserne opsat i punktform. Beskrivelsen af en startbetingelse skal være kort og sigende. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 18 af 45 1

20 Emne Beskrivelse Beskrivelse En længere beskrivelse af hvad der sker i aktiviteten. Som en del af beskrivelsen angives rollen, som har ansvaret for at udføre aktiviteten. Beskrives i punktform eller som en længere tekstbeskrivelse. Hvis der er tilknyttet flere beslutningsmodeller til den pågældende aktivitet, så kan der være angivet et beslutningsflow, der angiver i hvilken rækkefølgen de pågældende beslutningsmodeller skal eksekveres. Sluttilstand Sluttilstanden angiver udfaldet af en gennemført aktivitet. Sluttilstanden følger samme notation som startbetingelsen. Tabel 3 Indhold i aktivitetsbeskrivelse 3.6 Nummereringsstruktur af processer Der er koblet en nummereringsstruktur på alle niveau 0, 1, 2 og 3 processer. Tabellen nedenfor viser de numre vi har givet niveau 0 processerne/procesområderne og ydelsesområderne. Niveau 0 proces Nr. Ydelse Nr. Indberetning 1 Pension 1 Administration 2 Boligstøtte 2 Udbetaling 3 Barseldagpenge 3 Kommunikation 20 Familieydelser 4 Styringsprocesser 30 Debitor 5 Driftsprocesser 40 Ikke specifik ydelse x Tabel 4 Nummerering af niveau 0 processer og ydelser. Figuren nedenfor viser et eksempel på nummerering af en konkret proces: Bilag 2A Sådan forretningsmodellerer vi i ATP Side 19 af 45 1

21 Figur 11 Nummerering af processer Bilag 2A Sådan forretningsmodellerer vi i ATP Side 20 af 45 2

22 4 Information Dette kapitel introducerer kort ATP s metode for forretningsmodellering med fokus på Information: Figur 12 Procestrekant fokus på information De forretningsmæssige behov for information beskrives og dokumenteres i begrebs- og informationsmodeller. Begrebsmodeller er den overordnede beskrivelse af de konceptuelle begreber og relationer, som indgår i Udbetaling Danmarks sagsbehandling. Informationsmodellerne tager udgangspunkt i begrebsmodellerne og er detaljerede og udbyggede modeller af begrebsmodeller. Informationsmodellen viser de centrale forretningsobjekter og deres attributter på et overordnet plan, og skal derfor detaljeres yderligere i afklaringsfasen i samarbejde med Leverandøren. Leverandøren skal beskrive og levere dokumentation for løsningen i logiske og fysiske datamodeller. Informationsmodellerne præsenterer således den forretningsmæssige konceptuelle information, der skal danne grundlag for Bilag 2A Sådan forretningsmodellerer vi i ATP Side 21 af 45 2

23 Leverandørens logiske og fysiske datamodeller af de systemmæssige informationer. 4.1 Informationsartefakter I ATP har vi fire forskellige modeller til at beskrive vores informationsarkitektur. Tabellen viser de fire modeller: Model Indhold Ansvar Begrebsmodel Forretningsmæssige ATP leverer udkast Informationsmodel Begreber Leverandør bidrager Logisk datamodel Systemmæssige begreber Fysisk datamodel Systemdata Leverandøren udarbejder Tabel 5 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. Begrebs- og informationsmodeller er modelleret efter følgende regler: Vi prioriterer, 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. Begreber, Klasser og attributter kan ændre sig som følge af det udviklingsarbejde, der starter sammen med Leverandøren. Modellerne er statiske modeller, og har ikke noget tidsmæssigt forløb. Modellerne viser intet om behov for historiske data. Alle begreber har generel definition, samt eventuelt også kommentarer. Modellerne indeholder udelukkende de forretningsmæssige begreber som skal systemunderstøttes. Vi har generiske modeller, som indeholder begreber som skal anvendes i alle ordninger. Vi har specifikke modeller, som indeholder begreber der kun skal anvendes indenfor et enkelt ydelsesområde. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 22 af 45 2

24 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. Som en grov hovedregel kan man dog antage, at informationsmodellen for Boligstøtte og store dele af Sagsmodellen indeholder den forretningsmæssige information som skal ligge i Boligstøtteløsningen. Informationsmodellen for boligstøtte er udarbejdet med en forretningsmæssig vinkel og vurderingen er, at den størstedelen af det samlede informationsindhold for boligstøtte - modelleret som attributter. Informationsmodellen vil blive udbygget gennem de efterfølgende faser i projektet fx via regelmodelleringen og en yderligere berigelse af snitfladebeskrivelserne. Endelig vil der kunne opstå ny forretningsmæssige begreber og dermed attributter, når arbejdet med det kommende system går i gang. Beriget Grunddata-modellen indeholder den information, som ligger i støttesystemet (Beriget Grunddata). Sag-modellen indeholder uddybende information om Sagsbegrebet Overordnet set har vi modelleret 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 2A Sådan forretningsmodellerer vi i ATP Side 23 af 45 2

25 Figur 13 Overordnet begrebsmodel for Udbetaling Danmark 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ælles offentlige standarder på området 2. Fælles afklaring med KOMBIT 3. Intern afklaring i Udbetaling Danmark forretningsområder Den overordnede begrebsmodel viser, hvordan Personer, Virksomheder eller Myndigheder kan opnå 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. Af disse findes både generiske begrebsmodeller og specifikke begrebsmodeller. De generiske modeller er fælles for Udbetaling Danmarks ydelsesområder, og indeholder forretningsmæssig information der er gældende på tværs af ydelserne. Der er følgende generiske modeller: Beriget Grunddata Sag Bilag 2A Sådan forretningsmodellerer vi i ATP Side 24 af 45 2

26 De specifikke modeller, rummer kun information for om det enkelte ydelsesområde. Der er følgende specifikke begrebsmodeller: Barseldagpenge Boligstøtte Familieydelse Social Pension Debitor 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 (Klasser) logisk samhørende entiteter er samlet i delområder (Pakker). 4.2 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 Dokumentationsreolen Særlige forhold ved informationsmodeller Informationsmodellerne er beriget med attributter gennem arbejdet med aktivitetsbeskrivelser. Sammen med Leverandøren gennemføres en proces i afklaringsfasen 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 Dokumentationsreolen og danner, sammen med løsningsflows og beslutningsregler, en sammenhængende dokumentation af de forretningsmæssige behov til løsningen. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 25 af 45 2

27 Informationsmodellerne danner, sammen med aktivitetsbeskrivelserne i løsningsflow, en sammenhæng mellem funktionalitet og information. Forretningskomponenters logiske opdeling, jf. bilag 3A (Behovsopgørelse), er lagt til grund for informationsmodellens logiske opdeling. 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 de forretningsmæssige begreber, som angives i processerne. Vi modellerer i et UML Class diagram (QLM) Entiteter er repræsenteret i enkeltenheder (Klasse) Logisk samhørende entiteter er samlet i delområde (Pakke) Blå entiteter er hjemmehørende i en anden informationsmodel men er indeholdt for at lette forståelsen for en indbyrdes sammenhæng mellem flere informationsmodeller. En attribut på en Klasse kan være obligatorisk eller frivilligt udfyldt. Denne skelnen kan ses ud fra attributtens multiplicity. En attribut på en Klasse kan være følsomt data som skal logges. Det vises med en logningsmarkering. Dette ses på hver Klasse, 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. o (~) foran attributten betyder: Package; der er en regel der afgør om logning er påkrævet o (#) foran attributten betyder: Protected; som har betydning for logning. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 26 af 45 2

28 5 Funktionalitet Dette kapitel introducerer kort ATP s metode til arkitekturen og rammerne for den forretningsmæssige funktionalitet, der skal leveres i løsningen. Figur 14 Procestrekant fokus på funktionalitet 5.1 Forretningsudbudsarkitektur Forretningsudbudsarkitekturen beskriver dels sammenhænge mellem de forskellige systemer, registre og parter i den forretningsmæssige løsning, dels den ønskede forretningsmæssige funktionalitet. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 27 af 45 2

29 Figur 15 Forretningsudbudsarkitekturen for Boligstøtte Forretningsudbudsarkitekturen beskrives nærmere i bilag 3A (Behovsopgørelse). 5.2 Forretningskomponentmodel ATP s forretningskomponentmodeller udmøntes i en model for hvert ydelsesområde/udbud. Forretningskomponentmodellen illustrerer, hvordan løsninger/systemer er tænkt opdelt i forretningsmæssige logiske komponenter. Modellen og de hertil hørende komponentbeskrivelser har to formål: At give et overblik over den funktionalitet Systemet skal indeholde At gøre os i stand til, at italesætte og kategorisere Systemets funktionalitet fra et forretningsmæssigt perspektiv. De funktionelle krav der udarbejdes af ATP, som del af udbudsmaterialet kobles til de konkrete komponenter de vedrører, hvilket sikrer en logisk nedbrydning af kravene. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 28 af 45 2

30 Figur 16 Forretningskomponentmodellen for Boligstøtte Forretningskomponentmodellen og komponentbeskrivelser beskrives nærmere i bilag 3A (Behovsopgørelse). 5.3 IT-udbudsarkitektur IT-udbudsarkitekturen er udarbejdet med afsæt i IT-målarkitekturen og afspejler IT arkitekturen efter implementering af fagsystemet. IT-udbudsarkitekturen understøtter forretningsudbudsarkitekturen ved at udmønte de forretningsmæssige behov i en konkret systemkontekst. IT-arkitekturen bygger videre på og konkretiserer forretningsudbudsarkitekturen i forhold til hvilke systemer og registre, der indgår i løsningen. Endvidere angives de eksterne systemer og parter, som skal modtage-/levere data fra Systemet, således at omfanget af snitflader klarlægges. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 29 af 45 2

31 Figur 17 IT-udbudsarkitekturen for Boligstøtte IT-udbudsarkitekturen beskrives nærmere i bilag 3A (Behovsopgørelse). 5.4 Systemkontekst Systemkonteksten illustrerer hvilke systemer der skal integreres til i løsningen og hvordan de er forbundet. Systemkonteksten holdes på logisk niveau. Bemærk at infrastrukturkomponenter ikke er beskrevet her, men i særskilt bilag om integrationer og infrastruktur, se bilag 3A.6 (Integrationer). Bilag 2A Sådan forretningsmodellerer vi i ATP Side 30 af 45 3

32 Figur 18 Systemkontekst for Boligstøtte Systemkonteksten beskrives nærmere i bilag 3A (Behovsopgørelse). 5.5 Regelmodellering via beslutningsmodeller I ATP anvender vi beslutningsmodeller i forbindelse med alle automatiserede komplekse beslutninger. Beslutningsmodellering er en metodik, der er med til at sikre, at alle nødvendige beslutninger, 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 Bilag 2A Sådan forretningsmodellerer vi i ATP Side 31 af 45 3

33 o Analysen understøttes af principper og guidelines kombinerer diagrammer og tabeller 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 den bruges til at systematisere beslutninger og forretningsregler. Det giver et overblik over de forskellige delkonklusioner, betingelser, regler og fakta, der indgår i en beslutning. Beslutningsmodellen er med til at strukturere lovgivning og forretningsregler i forhold til 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 definerer reglerne i detaljer. Hver regelfamilie består af delkonklusioner (underliggende regelfamilier) og fakta. Figuren viser et eksempel på en beslutning: Bilag 2A Sådan forretningsmodellerer vi i ATP Side 32 af 45 3

34 Figur 19 Et overblik over, hvad en beslutning indeholder 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. Det er imidlertid ikke alle regler, der skal beskrives ved hjælp af beslutningsmodellen. En lang række regler vil være beskrevet i informationsmodel (typisk valideringsregler) og procesmodel (flowregler). I beslutningsmodellen beskrives kompleks beslutningslogik. Beslutningsdokumentationen kan 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 2A Sådan forretningsmodellerer vi i ATP Side 33 af 45 3

35 5.5.1 Eksempler på metoden for beslutningsmodellering For at vise hvordan beslutninger og regler modelleres og læses, følger et eksempel på, hvordan 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. Hvis en celle (betingelse) i en række ikke er udfyldt, betyder det, at reglens konklusion ikke er afhængig af denne betingelse (dvs. cellen kan være udfyldt med forskellige værdier, men det påvirker ikke udfaldet af reglen). Hver beslutningsmodel er koblet på en aktivitet i et løsningsflow. Beslutningsmodellerne er således altid tæt knyttet til processen. Det betyder, at når man læser en beslutningsmodel, skal man være meget bevidst over, hvilke informationer der er til rådighed netop dét sted i processen, dvs. beslutningsmodellens udgangspunkt (informationsgrundlag). Eksempel Beslutningsmodel BS: Berettigelse til boligstøtte findes i aktivitet BS: Valider (fortsat)berettigelse, som ligger i løsningsflow LF Boligstøtte Træf afgørelse Beslultningen går på at vurdere, om en person er berettiget til boligstøtte og i så fald, hvilken ydelsestype (boligsikring eller boligydelse) samt form (tilskud eller lån). Beslutningsmodellen består af en beslutning Beslut berettigelse til Boligstøtte, se figur 20 nedenfor. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 34 af 45 3

36 Figur 20 Oversigt over beslutningen Berettigelse til Boligstøtte Figur 20 illustrerer beslutningen om berettigelse til boligstøtte. Beslutningen er illustreret som ottekant med én regelfamilie, der er afhængig af otte underliggende regelfamilier, altså delbeslutninger. Disse er: Kan Person betegnes som pensionist eller sidestilles? Opfylder Person betingelse om ansøgning? Opfylder boligen krav? Opfylder Person krav til bopæl og benyttelse af bolig? Er betingelse for udbetaling af lån opfyldt? Opfylder kollektivt bofællesskab krav? Kan Boligstøtte ydes til en given deltager i et kollektivt bofællesskab? Er betingelse om underskrift af erklæring om, at et givet husstandsmedlem hæfter solidarisk for tilbagebetalingskrav, opfyldt? - Denne delbeslutning har en underliggende delbeslutning Skal Systemet medregne en given person som medlem af husstanden i pågældende periode? For at illustrere, hvordan modellen læses, tager vi udgangspunkt i den sidstnævnte delbeslutning Er betingelse om underskrift af erklæring om, at et givet Bilag 2A Sådan forretningsmodellerer vi i ATP Side 35 af 45 3

37 husstandsmedlem hæfter solidarisk for tilbagebetalingskrav, opfyldt?. Se figur 21 nedenfor. Figur 21 Oversigt over beslutningen Berettigelse til Boligstøtte For at få det bedste overblik, går vi struktureret til modellen, og starter i bunden og kigger på, om det kan konkluderes, at Systemet skal medregne en given person som medlem af husstanden i pågældende periode på baggrund af de oplysninger, som findes på vurderingstidspunktet i Systemet (det er de fakta, der er placeret under den stiplede linje i delbeslutningen Skal Systemet medregne en given person som medlem af husstanden i pågældende periode? ). Regler i denne delbeslutning er opstillet i beslutningstabel, se figur 22 nedenfor: Bilag 2A Sådan forretningsmodellerer vi i ATP Side 36 af 45 3

38 Figur 22 Beslutningstabel: Skal Systemet medregne en given person som medlem af husstanden i pågældende periode? Bemærkning til den gule farve: Beslutningstabellen er under udarbejdelse, og derfor de steder, hvor der udestår afklaringer er farvet gult. Start i øverste venstre hjørne af modellen og læs i skriveretningen. Modellen viser, at hvis Persons rolle i sagen er Ansøger, så medregnes denne som medlem af husstanden (RuleID 1). Bilag 2A Sådan forretningsmodellerer vi i ATP Side 37 af 45

39 Hvis Persons rolle i sagen er enten Øvrig person med status = Voksen eller Øvrig person med status = Tvungen voksen og Persons adresse i den periode, hvor boligstøtte skal beregnes for er lig med Ansøgers adresse, så medregnes denne person som medlem af husstanden (RuleID 2). Hvis Persons rolle i sagen er enten Øvrig person med status = Voksen eller Øvrig person med status = Tvungen voksen og Persons adresse i den periode, hvor boligstøtte skal beregnes for er forskellig fra Ansøgers adresse, så medregnes denne person ikke som medlem af husstanden (RuleID 3). Og således i de resterende rækker (regler) ned i tabellen. Delkonklusionen ender altså med enten Medregnes eller Medregnes ikke. Delkonklusionerne fra delbeslutningen sammenholdes nu i den overordnede regelfamilie, Er betingelse om underskrift af erklæring om, at et givet husstandsmedlem hæfter solidarisk for tilbagebetalingskrav, opfyldt?, med fakta Den aktuelle situation i sagen er, Med hvilke rolle indgår en person i husstanden mv. se figur 23 nedenfor: Bilag 2A Sådan forretningsmodellerer vi i ATP Side 38 af 45 3

40 Figur 23 Beslutningstabel: Er betingelse om underskrift af erklæring om, at et givet husstandsmedlem hæfter solidarisk for tilbagebetalingskrav, opfyldt?. Bemærkning til den gule farve: Beslutningstabellen er under udarbejdelse, og derfor de steder, hvor der udestår afklaringer er farvet gult Bilag 2A Sådan forretningsmodellerer vi i ATP Side 39 af 45

41 I yderste højre kolonne findes den endelige konklusion af, om betingelse om underskrift af erklæring om solidarisk hæftelse er opfyldt eller ej. Som det fremgår af figur 23, RuleID 6, personer der ikke medregnes som en del af husstanden skal ikke underskrive erklæring om solidarisk hæftelse. Dermed er betingelsen opfyldt for så vidt angår den givne person. Hvis Person fylder 18 år og Person enten er barn eller Tvungen voksen, der medregnes som en del af husstanden, og personen har underskrevet erklæringen om solidarisk hæftelse, senest 3 måneder efter at personen er fyldt 18 år, så er betingelsen om underskrift opfyldt (RuleID 3). Hvis Person fylder 18 år og Person enten er barn eller Tvungen voksen, der medregnes som en del af husstanden, og personen har ikke underskrevet erklæringen om solidarisk hæftelse, senest 3 måneder efter at personen er fyldt 18 år, så er betingelsen om underskrift ikke er opfyldt (RuleID 4). Delkonklusionen ender altså med enten Ja eller Nej. Disse svar bruges i den endelige beslutning Berettiget til Boligstøtte til vurderingen af den endelige berettigelse Særlige forhold ved beslutningsmodeller Beslutningsmodeller, som tager udgangspunkt i aktiviteter og forankres i aktiviteter, modelleres i QLM. De kobles med informationsmodeller og løsningsflows i aktiviteter. Eksempel: Aktivitet BS: *Generer opgave til indbakke i figur 24 nedenfor har ingen beslutningsmodeller tilknyttet. Aktivitet BS: *Generer digital besked har en beslutningsmodel tilknyttet, hvilket er illustreret ved en firkant lige under aktiviteten. Figur 24 Eksempel aktiviteter og beslutningsmodel Ved at køre musen over denne firkant aflæses navnet på Beslutningsmodellen og ved at klikke på firkanten åbnes Beslutningsmodellen, se figur 25 nedenfor: Bilag 2A Sådan forretningsmodellerer vi i ATP Side 40 af 45 4

42 Figur 25 Eksempel - beslutningsmodel Nogle aktiviteter har flere beslutningsmodeller tilknyttet, hvilket er illustreret ved at der under sådan en aktivitet er placeret flere firkanter, se figur 26 nedenfor: Figur 26 Eksempel aktivitet med tilhørende beslutningsmodeller Hvilken rækkefølge disse beslutningsmodeller skal eksekveres i, i den pågældende aktivitet, gives via et beslutningsflow, der er knyttet til aktiviteten. Aktiviteten i figur 26 indeholder et Beskrivelses afsnit, som indeholder et link til sådan et beslutningsflow, se figur 27 nedenfor: Bilag 2A Sådan forretningsmodellerer vi i ATP Side 41 af 45 4

43 Figur 27 Eksempel link til rækkefølgen af beslutningsmodellen Beslutningsflowets navngivning læses således: BF for beslutningsflow, Boligstøtte for den UDK ordning, flowet hører til, mens den sidste del er en angivelse af navnet på den aktivitet, hvor beslutningsflowet illustrerer rækkefølgen for eksekvering af beslutningsmodellerne. Principperne for diagrammering af et beslutningsflow er de samme som ved diagrammering af et løsningsflow, dog m ed følgende præciseringer: Aktivitetsnavene er informationsbærende Der er kun tilknyttet én eller ingen beslutningsmodel til hver aktivitet Der er ingen beskrivelser i selve aktiviteterne Der er ingen opdeling i svømmebaner idet beslutningsflowet illustrerer kun de processer, der foregår i én aktivitet fra et løsningsflow. Der modelleres udelukkende beslutninger, som forventes at køre automatisk. Eksempelvis betyder det at beslutninger, der relaterer sig til manuel behandling, forankres i en instruks og ikke i en beslutningsmodel som ovenfor vist i afsnit Vores regelstrategi baserer sig på, at vi betragter samtlige sager for en given ordning og opdeler dem i sager, der behandles automatisk og sager, hvor en opgave (en delmængde af den samlede behandling af en sag) kræver en manuel behandling, se figur 28 nedenfor. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 42 af 45 4

44 Figur 28 Sagerne behandles enten automatisk eller manuelt Beslutningsmodellerne indeholder derfor regelsæt, som omfatter følgende: Regler for den automatiske behandling af sager Regler som definerer de situationer, hvor en given sag ikke kan behandles automatisk og dermed skal falde ud til manuel behandling. Disse regler definerer desuden en opgaveårsag, som er sigende for en kunderådgiver, og som gør det muligt for Systemet at placere opgaven i en relevant arbejdspakke. Kunderådgiver via en brugergrænseflade til Systemet trækker opgaven til sig, behandler opgaven ud fra de regler, der er beskrevet i en relevant instruks, noterer resultater af behandlingen på sagen og returnerer sagen til Systemet, således at sagen kan igen fortsætte den videre behandling automatisk. Alle de sager, som ikke falder under den automatiske behandling og hvor det ikke er muligt at identificere en opgave, såfremt reglerne jf. ovenfor ikke er fuld dækkende, skal også falde ud til manuel behandling for at forebygge, at en sag strander i Systemet og ikke bliver færdigbehandlet. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 43 af 45 4

45 6 Udvikling af prototype for Systemets brugergrænseflader Vi udvikler brugergrænseflader via et udviklingsforløb der har til formål at kvalificere og teste udviklingsløsninger undervejs med Brugerne - fra tidlige skitser/mock-ups til færdigkodet selvbetjeningsløsning / brugergrænseflade. Formålet med brugerinddragende udvikling af brugergrænseflader er at sikre at Brugerne er i stand til at benytte Systemet og opfatter Systemet som brugervenligt. Ved tidlig brugerinvolvering sikres det, at grundlæggende antagelser om brugervenlighed udfordres og om nødvendigt korrigeres. De faser, som er beskrevet herunder, er de iterationer som forfiner brugergrænsefladen frem mod en godkendt prototype: 1. Opstart: Forventningsafstemning og projektplanlægning 2. Co-creation: Workshops med Brugere 3. Konceptdesign: Udvikling af wireframes og prototyper 4. Prototyping: Videreudvikling af prototyper I praksis har forløbet og faserne karakter af et iterativt forløb, hvilket betyder, at det kan være nødvendigt helt eller delvist at gentage faser. Når prototypen er færdig og Brugervenlighedstesten godkendt, indgår den som grundlag for udvikling af Systemet. De fire faser er beskrevet nedenfor. 6.1 Opstart Leverandør og ATP deltager i 1-2 opstartsworkshops. Formålet er at få fastlagt rammerne for det brugerinddragende udviklingsforløb. Konkret udbytte og indhold: Form og metode for udviklingsforløbet fastlægges efter opstartsworkshops. Rollefordeling og samarbejdsform ift. til de leverancer, som ligger i udviklingsarbejdet. Identificering af relevante Brugere, der skal inddrages i udviklingsarbejdet vil fungere som input til rekruttering af Brugere forud for co-creation workshops. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 44 af 45 4

46 6.2 Co-creation Afhængig af brugergrænsefladernes forventede kompleksitet gennemføres ca. 3-5 co-creation workshops. Formålet med disse co-creation workshops er, at Brugerne er med til at udvælge, validere og videreudvikle på idéer til det System, som Leverandøren skal levere. Formålet er, at Leverandøren skal have de input fra Brugerne, der er nødvendige for at kunne designe en opbygning af brugergrænsefladerne både i forhold til informationsarkitektur og funktionalitet, som Brugerne forstår at anvende. Formålet med disse workshops er at sikre, at den fremtidige løsning har præcis det indhold og den funktionalitet, som Brugerne oplever som værdifuld. ATP ønsker at teste, hvordan Brugerne opfatter den funktionalitet, Leverandøren forventer at implementere i en brugergrænseflade. Ved tidligt i Udviklingsprojektet at afprøve dette med Brugerne, kan vi hurtigere få prioriteret, hvilken funktionalitet der er intuitiv for Brugerne. Funktionalitet Brugerne ikke oplever som attraktivt, kan dermed tidligt elimineres. 6.3 Konceptdesign Leverancen fra co-creationfasen danner grundlag for konceptdesignfasen, hvor Leverandøren og ATP tager Brugernes input og transformerer dem til sammenhængende og gennemarbejdede løsningskoncepter. Leverandøren visualiserer disse løsningskoncepter i en prototype på wireframeniveau. Disse wireframes skitserer den brugergrænseflade som Leverandøren efterfølgende skal udvikle. Funktionalitet og sammenhæng er vigtigt i denne fase. Det endelige koncept design præsenteres for ATP. Resultatet afgør, om der er behov for flere iterationer i denne fase. 6.4 Prototyping I denne fase, prototypingfasen, forudsætter ATP, at Leverandøren har indhentet alle nødvendige behov og krav til en prototype, så en prototype som svarer til den endelige brugergrænseflade kan færdiggøres. På dette tidspunkt, forventer ATP ikke, at den interaktive prototype integrerer til bagvedliggende fagsystemer og offentlige registre. Navne, tal og personlige oplysninger forventes blot at være fiktive om end ikke urealistiske. ATP producerer råtekst til prototypen, som Leverandøren indarbejder i løsningen. Der gennemføres brugervenlighedstest af den klikbare prototype. Resultatet afgør, om der er behov for flere iterationer i denne fase. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 45 af 45 4

Bilag 2A Sådan forretningsmodellerer vi i ATP

Bilag 2A Sådan forretningsmodellerer vi i ATP Bilag 2A Sådan forretningsmodellerer vi i ATP Version 0.9 19-12-2014 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 INDLEDNING... 4 2.1 FORRETNINGSMÅLARKITEKTUR... 5 2.2 FORRETNINGSUDBUDSARKITEKTUR... 5

Læs mere

Bilag 2A Sådan forretningsmodellerer vi i ATP

Bilag 2A Sådan forretningsmodellerer vi i ATP Bilag 2A Sådan forretningsmodellerer vi i ATP Version 1.0 27-04-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 SÅDAN FORRETNINGSMODELLERER VI I ATP... 4 2.1 FORRETNINGSMODELLERING I KONTEKST AF FORRETNINGSARKITEKTUREN...

Læs mere

Bilag 2A Sådan forretningsmodellerer vi i ATP

Bilag 2A Sådan forretningsmodellerer vi i ATP Bilag 2A Sådan forretningsmodellerer vi i ATP Version 0.9 05-05-2014 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 INDLEDNING... 4 2.1 FORRETNINGSMÅLARKITEKTUR... 4 2.2 FORRETNINGSUDBUDSARKITEKTUR... 5

Læs mere

Bilag 3A.2 Løsningsflow

Bilag 3A.2 Løsningsflow Bilag 3A.2 Løsningsflow Version 0.9 19-12-2014 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 2.1 SÅDAN LÆSES ET LØSNINGSFLOW... 3 3 LØSNINGSFLOW... 6 Bilag 3A.2 Løsningsflow Side 1 1 Vejledning

Læs mere

Bilag 3A.7 Brugergrænseflader

Bilag 3A.7 Brugergrænseflader Bilag 3A.7 Brugergrænseflader Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 INDLEDNING... 4 3 USER EXPERIENCE GUIDELINES (UX-GUIDELINES)... 5 3.1 GENERELLE UX-GUIDELINES... 5 3.1.1

Læs mere

15 års erfaringer med QualiWare

15 års erfaringer med QualiWare 15 års erfaringer med QualiWare ATP s rejse Jytte Bertelsen Afdelingschef, Forretningsarkitektur og metode JB@atp.dk 2000-2010 Fra siloorienteret til procesorienteret 2010-2012 Etablering af Udbetaling

Læs mere

EDS Lå n til betåling åf ejendomsskåtter processer, regler og informåtion

EDS Lå n til betåling åf ejendomsskåtter processer, regler og informåtion EDS Lå n til betåling åf ejendomsskåtter processer, regler og informåtion Indhold 1. Indledning... 1 Rapportens indhold... 1 2. Kontekst for ansøgning om lån til ejendomsskat... 3 Livssituationer... 3

Læs mere

ATP s digitaliseringsstrategi 2014-2018

ATP s digitaliseringsstrategi 2014-2018 ATP s digitaliseringsstrategi 2014-2018 ATP s digitaliseringsstrategi samler hele ATP Koncernen om en række initiativer og pejlemærker for digitalisering i ATP. Den støtter op om ATP Koncernens målsætning

Læs mere

Bilag 3A.2 Løsningsflows

Bilag 3A.2 Løsningsflows Bilag 3A.2 Løsningsflows Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 2.1 SÅDAN LÆSES ET LØSNINGSFLOW/LØSNINGSSUBFLOW... 3 3 LØSNINGSFLOWS OG LØSNINGSSUBFLOWS...

Læs mere

Bilag 3 Leverancebeskrivelse

Bilag 3 Leverancebeskrivelse Bilag 3 Leverancebeskrivelse Version 0.8 23-02-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 INDLEDNING... 4 2.1 UNDERBILAG... 4 2.2 FARVEANVENDELSE PÅ ARKITEKTURDIAGRAMMER... 5 3 BAGGRUND FOR UDBUDDET...

Læs mere

Bilag 3A.7 Brugergrænseflader

Bilag 3A.7 Brugergrænseflader Version 0.8 19-12-2014 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 4 2 INDLEDNING... 5 3 USER EXPERIENCE GUIDELINES (UX-GUIDELINES)... 6 3.1 GENERELLE UX-GUIDELINES... 6 3.1.1 MODTAGERORIENTERET SPROG...

Læs mere

Kommunernes Ydelsessystem

Kommunernes Ydelsessystem Kommunernes Ydelsessystem Kommunernes Ydelsessystem De næste 15 minutter Målsætninger for Kommunernes Ydelsessystem Omfang af løsningen Status på projektet Implementering Spørgsmål 2 27.9.2012 Digitaliseringsmessen

Læs mere

Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt.

Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt. 8. april 2013 19-Partskontakt => Kontaktdata Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt. I de oprindelige oplæg med visionen

Læs mere

Bilag 3A.2 Løsningsflow

Bilag 3A.2 Løsningsflow Bilag 3A.2 Løsningsflow Version 1.0 23-02-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 2.1 SÅDAN LÆSES ET LØSNINGSFLOW... 3 3 LØSNINGSFLOW... 6 Bilag 3A.2 Løsningsflow Side 1 1 1 Vejledning

Læs mere

Metodehåndbog. Forretningsbeslutninger og forretningsregler Beslutningsmodellen. Udarbejdet i fællesskab mellem KL/KOMBIT

Metodehåndbog. Forretningsbeslutninger og forretningsregler Beslutningsmodellen. Udarbejdet i fællesskab mellem KL/KOMBIT Metodehåndbog Forretningsbeslutninger og forretningsregler Beslutningsmodellen Udarbejdet i fællesskab mellem KL/KOMBIT Indholdsfortegnelse Introduktion... 3 Beslutningsmodellering af forretningsregler...

Læs mere

Leverandørmøde Kommunernes Ydelsessystem. Den 19. februar 2013

Leverandørmøde Kommunernes Ydelsessystem. Den 19. februar 2013 Leverandørmøde Kommunernes Ydelsessystem Den 19. februar 2013 A. Idemodning Eksterne tests og pilot-drift F. Afslutning Tidsplan 2011 2012 2013 2014 2015 2016 C. Krav & kontrakter D. Udvikling & overtagelse

Læs mere

Bilag 3 Leverancebeskrivelse

Bilag 3 Leverancebeskrivelse Bilag 3 Leverancebeskrivelse Version 0.8 15-08-2014 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 INDLEDNING... 4 2.1 UNDERBILAG... 4 2.2 FARVEANVENDELSE PÅ ARKITEKTURDIAGRAMMER... 5 3 BAGGRUND FOR UDBUDDET...

Læs mere

Bilag 3A Behovsopgørelse

Bilag 3A Behovsopgørelse Bilag 3A Behovsopgørelse Version 0.85 23-02-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 7 2 INDLEDNING... 8 2.1 UNDERBILAG... 8 2.2 FARVEANVENDELSE PÅ ARKITEKTURDIAGRAMMER... 10 3 DEN SAMLEDE FORRETNINGSMÆSSIGE

Læs mere

Klik her for at angive tekst.

Klik her for at angive tekst. 30. april 2013 Klik her for at angive tekst. NOTAT Klik her for at angive tekst. Bilag 16: Anvenderkrav til Støttesystemet Ydelsesindeks version 1.0 (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav

Læs mere

Referater af leverandørmøder:

Referater af leverandørmøder: Referater af leverandørmøder: Spørgsmål fra leverandører Forventer ATP selv at drifte applikationerne i de kommende udbud? Hvilket system ejer data (DKC eller fagsystem)? Skal eksisterende fagsystemer

Læs mere

DEBITOR. Bilag 3A.8 Oversigter

DEBITOR. Bilag 3A.8 Oversigter DEBITOR Bilag 3A.8 Oversigter Version 0.9 23-02-2015 Vejledning Bilaget skal ikke ændres af Tilbudsgiver. Indledning Dette dokument indeholder følgende oversigter: Brevoversigt viser breve i forhold til

Læs mere

Bilag 1 Tidsplan Version 0.9 05-05-2014 0

Bilag 1 Tidsplan Version 0.9 05-05-2014 0 Bilag 1 Tidsplan Version 0.9 05-05-2014 0 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 2.1 ETAPER I UDVIKLINGSPROJEKTET... 3 2.1.1 ETAPE I - AFKLARING... 3 2.1.2 ETAPE II ANALYSE, DESIGN,

Læs mere

Arkitekturrapport: Kommunernes Ydelsessystem (KY) Arkitekturrapport: Kommunernes Ydelsessystem

Arkitekturrapport: Kommunernes Ydelsessystem (KY) Arkitekturrapport: Kommunernes Ydelsessystem Arkitekturrapport: Kommunernes Ydelsessystem 1 Indholdsfortegnelse Baggrund for projekt... 3 Resultat af gennemført arkitekturanalyse... 5 Anvendelse af forretningsservices... 9 Baggrund for projekt Baggrund

Læs mere

Bilag 3A Behovsopgørelse

Bilag 3A Behovsopgørelse Bilag 3A Behovsopgørelse Version 0.9 19-12-2014 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 4 2 INDLEDNING... 5 2.1 UNDERBILAG... 5 2.2 FARVEANVENDELSE PÅ ARKITEKTURDIAGRAMMER... 6 3 DEN SAMLEDE FORRETNINGSMÆSSIGE

Læs mere

Ejendomsdataprogrammet - Matriklen Løsningsarkitektur

Ejendomsdataprogrammet - Matriklen Løsningsarkitektur Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltning og genbrug af ejendomsdata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet - Matriklen Løsningsarkitektur

Læs mere

Vejledning i implementering af Udbetaling Danmarks standardside om boligstøtte

Vejledning i implementering af Udbetaling Danmarks standardside om boligstøtte Vejledning i implementering af Udbetaling Danmarks standardside om boligstøtte Indhold Introduktion... 2 Formålet med standardsiden... 2 Hvad betyder standardsiden for jer?... 3 Standardsiden for boligstøtte

Læs mere

Bilag 3A Behovsopgørelse

Bilag 3A Behovsopgørelse Bilag 3A Behovsopgørelse Version 1.0 27-04-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 7 2 INDLEDNING... 8 2.1 UNDERBILAG... 8 2.2 FARVEANVENDELSE PÅ ARKITEKTURDIAGRAMMER... 9 3 DEN SAMLEDE FORRETNINGSMÆSSIGE

Læs mere

Digital Post 2020 Arkitektur i infrastrukturen

Digital Post 2020 Arkitektur i infrastrukturen FDA2018 Digital Post 2020 Arkitektur i infrastrukturen Thomas Pedersen Digitaliseringsstyrelsen, CIU thope@digst.dk FDA Konference, 23. april 2018 Digital Dagsorden: Post 2020 Arkitektur i infrastrukturen

Læs mere

UDBETALING DANMARK STATUS OG PORTEFØLJE

UDBETALING DANMARK STATUS OG PORTEFØLJE UDBETALING DANMARK STATUS OG PORTEFØLJE V/ Hans Christian Jelstrup, UDK KOMBIT Kommunedage 1.-3. juni 2015 Udbetaling Danmarks Konkurrenceudsættelsesprogram Kommunedagene 1. - 3. juni 2015 1. juni 2015

Læs mere

Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks

Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks 23. maj 2013 HHK/KMJ NOTAT Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk

Læs mere

Bilag 3A.3 Aktivitetsbeskrivelser

Bilag 3A.3 Aktivitetsbeskrivelser Bilag 3A.3 Aktivitetsbeskrivelser Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 2.1 SÅDAN LÆSES EN AKTIVITETSBESKRIVELSE... 3 3 AKTIVITETSBESKRIVELSER... 4 Bilag 3A.3

Læs mere

It-principper. Bilag 1 til It- og Digitaliseringsstrategi for Sønderborg Kommune

It-principper. Bilag 1 til It- og Digitaliseringsstrategi for Sønderborg Kommune It-principper Bilag 1 til It- og Digitaliseringsstrategi for Sønderborg Kommune Indledning It-principperne er grundstenene for it-arkitekturen i Sønderborg Kommune. Principperne skal bidrage til, at vi

Læs mere

Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer

Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer UdbudsVejledning Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog,

Læs mere

Kundeoplevelser og servicedesign i ATP Michael Lehmann, Webmanager i Digitalisering

Kundeoplevelser og servicedesign i ATP Michael Lehmann, Webmanager i Digitalisering Kundeoplevelser og servicedesign i ATP Michael Lehmann, Webmanager i Digitalisering Digitalisering af udbetalinger 0 ATP s Kundeoplevelses strategi Service Design Digitalisering af udbetalinger ATP s strategiske

Læs mere

Ejerfortegnelse Løsningsarkitektur Bilag C Processer Grunddataprogrammet under den Fællesoffentlig digitaliseringsstrategi 2012 2015

Ejerfortegnelse Løsningsarkitektur Bilag C Processer Grunddataprogrammet under den Fællesoffentlig digitaliseringsstrategi 2012 2015 Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltningg og genbrug af ejendomsdataa under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet Ejerfortegnelsen Løsningsarkitektur

Læs mere

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning:

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning: Introduktion til EA3 Mit navn er Marc de Oliveira. Jeg er systemanalytiker og datalog fra Københavns Universitet og denne artikel hører til min artikelserie, Forsimpling (som også er et podcast), hvor

Læs mere

Agenda Møderække vedr. markedsreview for udbud af It-løsning til administration og udbetaling af Barseldagpenge

Agenda Møderække vedr. markedsreview for udbud af It-løsning til administration og udbetaling af Barseldagpenge Agenda Møderække vedr. markedsreview for udbud af It-løsning til administration og udbetaling af Barseldagpenge Tid Dagsorden 5 min Præsentation af mødedeltagerne 20 min Leverandørens præsentation jf.

Læs mere

Bilag 1 Tidsplan Version 0.9 23-02-2015 0

Bilag 1 Tidsplan Version 0.9 23-02-2015 0 Bilag 1 Tidsplan Version 0.9 23-02-2015 0 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 2.1 ETAPER I UDVIKLINGSPROJEKTET... 3 2.1.1 ETAPE I - AFKLARING... 3 2.1.2 ETAPE II ANALYSE, DESIGN,

Læs mere

Strategi 2013-2017 Danmarks Miljøportal

Strategi 2013-2017 Danmarks Miljøportal Strategi 2013-2017 Danmarks Miljøportal Introduktion Danmarks Miljøportal (DMP) har ansvaret for en digital infrastruktur på miljøområdet, der gør det muligt for myndigheder og offentlighed at få nem adgang

Læs mere

Faktaark for Byg og Miljø

Faktaark for Byg og Miljø 14. juni 2016 Faktaark for Byg og Miljø Overordnet beskrivelse og baggrund for Byg og Miljø Indholdsfortegnelse 1. Indledning... 2 2. Baggrund og formål... 3 Byg og Miljø består af tre dele... 3 Byg og

Læs mere

Løsning til administration af en række sagsområder med mindre bestande

Løsning til administration af en række sagsområder med mindre bestande Temaer/spørgsmål til individuelle leverandørmøder Løsning til administration af en række sagsområder med mindre bestande Uge 6, 2016 0 Dagsorden Velkomst og introduktion Introduktion til leverandørens

Læs mere

Vilkår for brug af Støttesystemet Sags- og Dokumentindeks

Vilkår for brug af Støttesystemet Sags- og Dokumentindeks Version 1.0 Vilkår for brug af Støttesystemet Sags- og Dokumentindeks KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og

Læs mere

Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011

Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011 Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011 Indholdsfortegnelse Ændringer i forhold til forrige version... 2 1 Brug af snitfladebeskrivelsen... 3 2 Formål

Læs mere

Peter Thrane Enterprisearkitekt KL+KOMBIT. Den fælleskommunale Rammearkitektur - Inspiration

Peter Thrane Enterprisearkitekt KL+KOMBIT. Den fælleskommunale Rammearkitektur - Inspiration Peter Thrane Enterprisearkitekt KL+KOMBIT Den fælleskommunale Rammearkitektur - Inspiration REGIONERNE Selvstyre Egen økonomi Konkurrence = bedre priser Samarbejde Koordinering Udveksling SAMMENHÆNG

Læs mere

Procedurer for styring af softwarearkitektur og koordinering af udvikling

Procedurer for styring af softwarearkitektur og koordinering af udvikling LEVERANCE 2.3 Procedurer for styring af softwarearkitektur og koordinering af udvikling Procedurerne vil omfatte: Planlægning af udfasning af gamle versioner af OpenTele Planlægning af modning af kode

Læs mere

Bilag 3A Behovsopgørelse

Bilag 3A Behovsopgørelse Bilag 3A Behovsopgørelse Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 7 2 INDLEDNING... 8 2.1 UNDERBILAG... 8 2.2 FARVEANVENDELSE PÅ ARKITEKTURDIAGRAMMER... 9 3 DEN SAMLEDE FORRETNINGSMÆSSIGE

Læs mere

Fremtidsmodel (Blueprint) - Vejledning

Fremtidsmodel (Blueprint) - Vejledning Fremtidsmodel (Blueprint) - Vejledning Januar 2014 Indhold 1. FORKLARING PÅ CENTRALE BEGREBER... 3 2. HVAD ER FREMTIDSMODELLEN (BLUEPRINT)... 4 3. FORMÅLET MED FREMTIDSMODELLEN... 4 4. HVEM MODTAGER FREMTIDSMODELLEN...

Læs mere

Digital Kommuneplan. Kravsspecifikation gennem brugerinvolvering

Digital Kommuneplan. Kravsspecifikation gennem brugerinvolvering Digital Kommuneplan Kravsspecifikation gennem brugerinvolvering Indhold Introduktion Afklaring af behov: Hvad skal digitale kommuneplaner kunne? Udarbejdelse og test af løsning: Hvordan skal digitale kommuneplaner

Læs mere

Om konkurrenceudsættelsen af it-løsninger til Udbetaling Danmark

Om konkurrenceudsættelsen af it-løsninger til Udbetaling Danmark Agenda Baggrund Ydelsesområder Visioner Udbudsplan Løsning Om konkurrenceudsættelsen af it-løsninger til Udbetaling Danmark 1 Baggrund ATP har fra den 1. oktober 2012 leveret teknisk og administrativ bistand

Læs mere

Scope dokument for Advisservice

Scope dokument for Advisservice 18. marts 2013 AHI Scope dokument for Advisservice Indhold 1. Advisservice... 2 2. Advis håndtering i KMD Sag... 2 3. Hændelse og Advis... 3 4. Advis løsningsmodel... 4 5. Abonnementsopsætning... 5 6.

Læs mere

IT- og Arkitekturkonferencen 2009

IT- og Arkitekturkonferencen 2009 DIAS 1 IT- og Arkitekturkonferencen 2009 Rolf Sørensen, KMD A/S KORT OM KMD DIAS 2 _ Full it service provider - It til hele værdikæden: _Strategisk sparring, projektbeskrivelse og -ledelse, implementering,

Læs mere

It-løsning til administration og udbetaling af Barseldagpenge.

It-løsning til administration og udbetaling af Barseldagpenge. It-løsning til administration og udbetaling af Barseldagpenge. Resumé markedsdialog (november 2013 til januar 2014). Dette notat indeholder en anonymiseret sammenfatning af de væsentligste kommentarer

Læs mere

Formidling og dokumentation af arkitektur. FDA konferencen, September 2019

Formidling og dokumentation af arkitektur. FDA konferencen, September 2019 Formidling og dokumentation af arkitektur FDA konferencen, September 2019 Retningslinjer og vejledninger ift dokumentation 2 Arkitekturudarbejdelse Metode og dokumentation Hvad skal vi lave og hvorfor?

Læs mere

Den fælleskommunale Rammearkitektur. - en arkitektur for den kommunale digitalisering

Den fælleskommunale Rammearkitektur. - en arkitektur for den kommunale digitalisering Den fælleskommunale Rammearkitektur - en arkitektur for den kommunale digitalisering Fundament Vision & Strategi Logik Rammearkitektur Fysik Udvikling/Implementering 2 10.6.2014 De 5 digitaliseringsmål

Læs mere

Metodehåndbog. Begrebsmodeller, Informationsmodeller og Begrebsdefinitioner. Udarbejdet i fællesskab mellem Udbetaling Danmark/KL/KOMBIT

Metodehåndbog. Begrebsmodeller, Informationsmodeller og Begrebsdefinitioner. Udarbejdet i fællesskab mellem Udbetaling Danmark/KL/KOMBIT Metodehåndbog Begrebsmodeller, Informationsmodeller og Begrebsdefinitioner Udarbejdet i fællesskab mellem Udbetaling Danmark/KL/KOMBIT Indhold Introduktion... 2 Begrebsmodeller, informationsmodeller og

Læs mere

Projekt 5.3 Digitale Vandløbsregulativer

Projekt 5.3 Digitale Vandløbsregulativer Projekt 5.3 Digitale Vandløbsregulativer 1. Formål og baggrund Baggrund Vandløb kan oversvømme byer og landbrugsarealer. Vandløb er samtidig levested for mange dyr og planter. Kommunerne og lodsejerne

Læs mere

1 Baggrund Sådan bliver særlig støtte påvirket af implementeringen...5

1 Baggrund Sådan bliver særlig støtte påvirket af implementeringen...5 Særudgave: Information om det nye boligstøttesystem Indhold 1 Baggrund..........................................................................2 2 Overgang til det nye boligstøttesystem...2 2.1 Frister

Læs mere

EDS Udrejse Kontekst, regler, proces og data

EDS Udrejse Kontekst, regler, proces og data EDS Udrejse Kontekst, regler, proces og data 1. Indledning Denne rapport indgår som en del af leverancen fra Effektiv digital selvbetjening i forbindelse med As-Is og To-Be analyserne af de selvbetjeningsområder,

Læs mere

Bilag 10 - Forslag til struktur og principper (metamodel) for en forretningsdomænemodel

Bilag 10 - Forslag til struktur og principper (metamodel) for en forretningsdomænemodel Bilag 10 Punkt 11.3 Bilag 10 - Forslag til struktur og principper (metamodel) for en forretningsdomænemodel Viden om forretningsdomænerne sikrer en solid forståelse af forretningens problemstillinger,

Læs mere

It-Arkitekturrådets møde 28. februar Effektmåling af rammearkitektur

It-Arkitekturrådets møde 28. februar Effektmåling af rammearkitektur www.pwc.dk It-Arkitekturrådets møde 28. februar Effektmåling af rammearkitektur Revision. Skat. Rådgivning. Interviews og workshop har været primær input til udarbejdelsen af målepunkter, som har haft

Læs mere

Opsamling på kommunal høring. Vejle & Roskilde Den 18. Juni 2013

Opsamling på kommunal høring. Vejle & Roskilde Den 18. Juni 2013 Opsamling på kommunal høring Vejle & Roskilde Den 18. Juni 2013 Dagsorden Velkommen Høringsprocessen frem til udbuddet på KY Resultater fra høringen Udbudsmaterialet kapitel 1 4, 5 og 6 Temaer: EDSH, opgavelisten,

Læs mere

SAPA. Kommunenetværk. KMJ, d. 24. november 2013

SAPA. Kommunenetværk. KMJ, d. 24. november 2013 SAPA Kommunenetværk KMJ, d. 24. november 2013 P R O J E K T S T A T U S 1. Integrationer til sagsbærende it-systemer 2. Kravspecifikation for SAPA 3. Interessenterne 4. Tidsplan 2 1. Se data fra sagssystemer

Læs mere

Bilag 3A Behovsopgørelse

Bilag 3A Behovsopgørelse Bilag 3A Behovsopgørelse Version 0.9 05-05-2014 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 7 2 INDLEDNING... 8 2.1 UNDERBILAG... 8 3 FORRETNINGSUDBUDSARKITEKTUR OG KOMPONENTMODEL... 9 3.1 FORRETNINGSUDBUDSARKITEKTUREN...

Læs mere

Vejledning til gevinstdiagram og gevinstprofiler

Vejledning til gevinstdiagram og gevinstprofiler Vejledning til gevinstdiagram og gevinstprofiler Januar 2014 Indhold 1. CENTRALE BEGREBER... 3 2. HVAD ER ET GEVINSTDIAGRAM OG GEVINSTPROFILER... 4 3. FORMÅL MED GEVINSTDIAGRAM OG GEVINSTPROFILER... 4

Læs mere

Hvem er målgruppen for disse dokumenter. Hvilke forudsætninger skal læseren have?

Hvem er målgruppen for disse dokumenter. Hvilke forudsætninger skal læseren have? Kommenteringsskema 15. januar 2018 Sekretariatet for Initiativ 8.1. BEMÆRK: Alle indsendte kommentarer offentliggøres (på arkitektur.digst.dk). Såfremt du ikke ønsker en kommentar offentliggjort, bedes

Læs mere

Bilag 15 Leverandørkoordinering

Bilag 15 Leverandørkoordinering Bilag 15 Leverandørkoordinering Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 3 LEVERANDØRENS ANSVAR... 4 4 LEVERANDØRENS KOORDINERINGS- OG SAMARBEJDSFORPLIGTELSE...

Læs mere

Konkurrenceudsættelse på syge- og barseldagpengeområderne: Oplæg til indledende teknisk dialog (nov. 2012)

Konkurrenceudsættelse på syge- og barseldagpengeområderne: Oplæg til indledende teknisk dialog (nov. 2012) 14. nov. 2012 Klik her for at angive tekst. NOTAT Konkurrenceudsættelse på syge- og barseldagpengeområderne: Oplæg til indledende teknisk dialog (nov. 2012) ATP og KOMBIT samarbejder om konkurrenceudsættelse

Læs mere

DEN FÆLLESKOMMUNALE RAMMEARKITEKTUR

DEN FÆLLESKOMMUNALE RAMMEARKITEKTUR DEN FÆLLESKOMMUNALE RAMMEARKITEKTUR FDA2017 DEN FÆLLESKOMMUNALE RAMMEARKITEKTUR - FRA VISION TIL PRAKSIS FDA 2017 Agenda Digitaliseringsstrategien og kommunernes udfordringer Rammearkitekturen som et fælles

Læs mere

Bilag 2 - Fælles arkitekturramme for GD1-GD2-GD7. Etablering af datadistribution på den Fællesoffentlige Datafordeler

Bilag 2 - Fælles arkitekturramme for GD1-GD2-GD7. Etablering af datadistribution på den Fællesoffentlige Datafordeler Bilag 2 - Fælles arkitekturramme for GD1-GD2-GD7 Etablering af datadistribution på den Fællesoffentlige Datafordeler Version: 0.8 Status: udkast Oprettet: 10.3.2014 Dato: 16. juni 2014 Dokument historie

Læs mere

Bilag 3A Behovsopgørelse

Bilag 3A Behovsopgørelse Bilag 3A Behovsopgørelse Version 1.0 23-02-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 7 2 INDLEDNING... 8 2.1 UNDERBILAG... 8 2.2 FARVEANVENDELSE PÅ ARKITEKTURDIAGRAMMER... 9 3 DEN SAMLEDE FORRETNINGSMÆSSIGE

Læs mere

Metodehåndbog. Processer. Udarbejdet i fællesskab mellem KL og KOMBIT

Metodehåndbog. Processer. Udarbejdet i fællesskab mellem KL og KOMBIT Metodehåndbog Processer Udarbejdet i fællesskab mellem KL og KOMBIT Indhold Introduktion... 3 Procesmodellering... 3 Qualiware... 4 Notation for Processer... 4 Pool... 5 Lane... 6 Aktivitet... 6 Hændelse...

Læs mere

Oversigt over kriterier for klarmelding af bølge 2-løsninger i 2013

Oversigt over kriterier for klarmelding af bølge 2-løsninger i 2013 Notat Oversigt over kriterier for klarmelding af bølge 2-løsninger i 2013 Baggrund Frem mod 1. december 2013 gennemføresen klarmeldingsproces med tre statusrapporteringer i hhv. maj, oktober og november.

Læs mere

Bilag 3A.5 Regel- og beslutningsmodeller

Bilag 3A.5 Regel- og beslutningsmodeller Bilag 3A.5 Regel- og beslutningsmodeller Version 0.9 05-05-2014 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 INDLEDNING... 4 3 REGEL- OG BESLUTNINGSMODELLER... 5 3.1 BEREGN TIMETAL... 8 3.2 BEREGN YDELSE...

Læs mere

Støttesystemerne. Det er tid til

Støttesystemerne. Det er tid til 1 Det er tid til Støttesystemerne 2 Kombit Digitalisering er afgørende for udviklingen af de kommunale kerneopgaver, hvor bedre borgerservice med færre ressourcer er i centrum. Kommunernes mål er at bevare

Læs mere

Informationsmøde om Social Pension til Udbetaling Danmark

Informationsmøde om Social Pension til Udbetaling Danmark Informationsmøde om Social Pension til Udbetaling Danmark Intro til Markedsdialog Udbetaling Danmark casen KUP- Konkurrence udsættelses programmet Pensionssystemet, overordnet arkitektur og udbudsplan

Læs mere

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) 25. april 2013 NOTAT Anvenderkrav til Støttesystemet Klassifikation (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin BACKEND

Hassansalem.dk/delpin User: admin Pass: admin BACKEND Hassansalem.dk/delpin User: admin Pass: admin BACKEND 1/10 Indledning Dette projekt er den afsluttende del af web udvikling studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med Del-pin

Læs mere

ARBEJDET MED UDVIKLING AF EN AGIL STANDARDKONTRAKT

ARBEJDET MED UDVIKLING AF EN AGIL STANDARDKONTRAKT Executive summary 1. ARBEJDET MED UDVIKLING AF EN AGIL STANDARDKONTRAKT Regeringen har et mål om, at den offentlige sektor skal være blandt de mest effektive og mindst bureaukratiske i verden, og for at

Læs mere

Bilag 2: Kravspecifikation - Side 1

Bilag 2: Kravspecifikation - Side 1 Bilag 2: Kravspecifikation - Side 1 Use-Cases Syddjurs Kommune betragter den tværgående sundhedsplatform som en del af en større infrastruktur, hvor data flyder mellem forskellige elementer. Dette dokument

Læs mere

Vejledningen til proces for design af fremtidsmodellen

Vejledningen til proces for design af fremtidsmodellen Vejledningen til proces for design af fremtidsmodellen Januar 2014 Indhold 1. FORMÅL... 3 FORMÅLET MED DENNE PROCESVEJLEDNING... 3 2. FREMTIDSMODELLENS OMRÅDER... 3 2.1. AKTIVITETER... 4 DEFINER OVERORDNEDE

Læs mere

Koncept for systemforvaltning af den fælles open source kode, herunder procedure for opfølgning på software-versioner af OpenTele

Koncept for systemforvaltning af den fælles open source kode, herunder procedure for opfølgning på software-versioner af OpenTele LEVERANCE 2.1 Koncept for systemforvaltning af den fælles open source kode, herunder procedure for opfølgning på software-versioner af OpenTele Konceptet beskriver, hvordan koden forvaltes, og hvordan

Læs mere

Programgrundlag (Programme Brief) - Vejledning

Programgrundlag (Programme Brief) - Vejledning Programgrundlag (Programme Brief) - Vejledning December 2015 er med Budgetvejledning 2016 frivillig at bruge for statslige myndigheder. Opdelingen i frivillige og obligatoriske faser, ledelsesprodukter,

Læs mere

Vilkår for Dialogintegration

Vilkår for Dialogintegration Vilkår for Dialogintegration KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/8 Dokumenthistorik Dato Version Ansvarlig Kommentar til ændringer

Læs mere

SAPAs forretningsmæssige behov i relation til Dialogintegration. SAPAs behov for Dialogintegration. Fordele ved brug af dialogintegration i SAPA

SAPAs forretningsmæssige behov i relation til Dialogintegration. SAPAs behov for Dialogintegration. Fordele ved brug af dialogintegration i SAPA 26. marts 2014 NOTAT SAPAs forretningsmæssige behov i relation til Dialogintegration Dette notat beskriver SAPAs specifikke forretningsmæssige behov i forhold til integration med relevante ESDH-/fagsystemer,

Læs mere

1 Begrebsmodel for Ydelsesindeks

1 Begrebsmodel for Ydelsesindeks 1 Begrebsmodel for Ydelsesindeks Ydelsesindeks skal indeholde metadata om tildelte ydelser, samt nøgler til andre relaterede forretningsobjekter fra Afsendersystemer, således at der kan leveres et tværgående

Læs mere

<navn på proces eller use case>

<navn på proces eller use case> -- AKT 444548 -- BILAG 1 -- [ Bilag B1_Skabelon Integrationstabel ] -- Bilag B1 Integrationstabel Formålet med integrationstabellerne er at danne et samlet overblik over de tekniske integrationer, der

Læs mere

FDA Retningslinjer for arkitekturdokumentation. Marts 2019

FDA Retningslinjer for arkitekturdokumentation. Marts 2019 FDA Retningslinjer for arkitekturdokumentation Marts 2019 Baggrund og ophæng 2 Principper & Regler STYRING STRATEGI JURA SIKKERHED OPGAVER INFORMATION APPLIKATION INFRASTRUKTUR Princip 1: Arkitektur styres

Læs mere

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) 25. april 2013 Klik her for at angive tekst. NOTAT Bilag 14: Anvenderkrav til Støttesystemet Organisation (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) kombit@kombit.dk CVR

Læs mere

Vejledning til KOMBIT KLIK

Vejledning til KOMBIT KLIK Vejledning til KOMBIT KLIK KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 0 Version Bemærkning til ændringer/justeringer Dato Ansvarlig 1.0 Første

Læs mere

Ejendomsdataprogrammet - BBR Løsningsarkitektur Bilag C Processer

Ejendomsdataprogrammet - BBR Løsningsarkitektur Bilag C Processer Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltning og genbrug af ejendomsdata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet - BBR Løsningsarkitektur

Læs mere

Bilag 2B Eksisterende data

Bilag 2B Eksisterende data Bilag 2B Eksisterende data Version 0.8 23-02-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 3 OVERBLIK OVER DOKUMENTATION FRA... 4 3.1 BEGREBSMODEL ( OPUS DEBITOR)... 4 3.2 INFORMATIONSMODEL

Læs mere

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) 30. april 2013 NOTAT Bilag 12: Anvenderkrav til Støttesystemet Beskedfordeler (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334

Læs mere

Data og rammearkitektur på beskæftigelsesområdet

Data og rammearkitektur på beskæftigelsesområdet R E SULTATKONTRAKT Data og rammearkitektur på beskæftigelsesområdet (2.1) Kommunerne ønsker at levere en langt mere effektiv beskæftigelsesindsats, både mere effektiv i betydningen af bedre målopfyldelse

Læs mere

Fra hvidbog til rammearkitektur FDA konferencen v Michael Bang Kjeldgaard

Fra hvidbog til rammearkitektur FDA konferencen v Michael Bang Kjeldgaard FDA2018 2 Fra hvidbog til rammearkitektur FDA konferencen 2018 v Michael Bang Kjeldgaard Agenda Strategi Begreber Indhold Anvendelse Styring 3 4 FDA Rammearkitekturs rolle Understøtte fælles forretningsmål

Læs mere

Indlæg på Kommunerne IT arkitektur råd

Indlæg på Kommunerne IT arkitektur råd Indlæg på Kommunerne IT arkitektur råd 25. februar 2014 Peter Glargaard Jytte Bertelsen Hvor vi kom fra Kommunerne UDK SAPA Overblik, Opgavestyring Driftsstabilitet afhænger bl.a. af leverandørafhængigheder

Læs mere

Notat om metadata om grunddata

Notat om metadata om grunddata Bilag 16 - Fælles arkitekturramme for GD1-GD2-GD7 Notat om metadata om grunddata 6. december 2013 SAR & PLACE Indledning Metadata data om data betegner ikke en entydig klasse af data. Anvendelsen af betegnelsen

Læs mere

Introduktion til MeMo

Introduktion til MeMo Introduktion til MeMo 1. februar 2019 CIU I forbindelse med Digitaliseringsstyrelsens udbud af Næste generation Digital Post løsningen (NgDP) er der udviklet en ny model for udveksling af digitale postmeddelelser,

Læs mere

ECdox som favorit. Indledning 1. Internet Explorer 2. Chrome 4. Safari 5. Favorit på mobile enheder 6 Android 6 IOS 7. ECdox på mobile enheder 7

ECdox som favorit. Indledning 1. Internet Explorer 2. Chrome 4. Safari 5. Favorit på mobile enheder 6 Android 6 IOS 7. ECdox på mobile enheder 7 ECdox som favorit Indledning 1 Internet Explorer 2 Chrome 4 Safari 5 Favorit på mobile enheder 6 Android 6 IOS 7 ECdox på mobile enheder 7 Indledning Dette dokument beskriver hvordan man opretter og arbejder

Læs mere

Bilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer)

Bilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer) Klik her for at angive tekst. Bilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer) Krav og vejledning til

Læs mere

Pensioneringsprocessen/Statens Administration

Pensioneringsprocessen/Statens Administration PENSAB Pensioneringsprocessen/Statens Administration Indhold 1. Overblik over den samlede proces... 2 2. Tildel pensionssag... 3 2.1 Søg i listen [Pensionssager]... 5 2.2 Tildel sag... 5 2.3 Afgiv sag...

Læs mere