Bilag 2A Sådan forretningsmodellerer vi i ATP
|
|
- Finn Dideriksen
- 7 år siden
- Visninger:
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 39
3 5.3 IT-UDBUDSARKITEKTUR SYSTEMKONTEKST REGELMODELLERING VIA BESLUTNINGSMODELLER EKSEMPLER PÅ METODEN FOR BESLUTNINGSMODELLERING UDVIKLING AF PROTOTYPE FOR SYSTEMETS BRUGERGRÆNSEFLADER OPSTART CO-CREATION KONCEPTDESIGN PROTOTYPING Bilag 2A Sådan forretningsmodellerer vi i ATP Side 2 af 39
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 39
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 39
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: Figur 2 Procestrekantens samspil med forretningsmålarkitektur og forretningsudbudsarkitektur Bilag 2A Sådan forretningsmodellerer vi i ATP Side 5 af 39
7 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. 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 39
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 39
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 39
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. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 9 af 39
11 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. 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 39
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. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 11 af 39
13 Derudover er der forretningsprocesser, der går på tværs og leverer support til kerneprocesserne, f.eks. processen omkring modtagelse af post. 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 1 IGOE Bilag 2A Sådan forretningsmodellerer vi i ATP Side 12 af 39
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 Familieydelser er markeret. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 13 af 39
15 Figur 8 Proceskatalog 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 Bilag 2A Sådan forretningsmodellerer vi i ATP Side 14 af 39
16 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. Figur 9 Procesniveauer Bilag 2A Sådan forretningsmodellerer vi i ATP Side 15 af 39
17 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 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 mængder, belastning, 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. 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 Bilag 2A Sådan forretningsmodellerer vi i ATP Side 16 af 39
18 kunne håndtere, samt en mulig måde hvorpå processerne i fagsystemet kan forløbe. Figur 10 Løsningsflow LF-Familieydelse - Håndter indberetning 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 Sluttilstand Beskrivelse Kort beskrivelse af aktivitetens formål. Startbetingelse angiver, hvilke betingelser der skal være til stede førend 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. 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. Sluttilstanden angiver udfaldet af en gennemført aktivitet. Sluttilstanden følger samme notation som startbetingelsen. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 17 af 39
19 Emne Input Output Regler Behov for understøttelse af aktivitet Beskrivelse Input angiver hvilke informationer der danner grundlag for udførelsen af aktiviteten. Det kan f.eks. være: en datafil en systemgenereret godkendelse en advis Input skal stemme overens med outputtet fra den foregående aktivitet eller de informationer der modtages fra ekstern part. I input kan der refereres til konkrete klasser eller attributter i informationsmodellerne. Output angiver hvilke informationer der dannes af aktiviteten. I output kan der refereres til konkrete klasser eller attributter i informationsmodellerne. Regler henviser til de beslutningsmodeller, der ønskes implementeret til styring af aktivitetens funktionalitet. Se punkt 6.6 om regelmodellering for yderligere information. Beskrivelse af konkrete krav til løsningen. Der gælder følgende retningslinjer: Der skrives tydeligt hvad Leverandøren skal levere Hvor der er tilknytning til en snitflade fremgår dette med reference til entydigt integrationsid Først står hvad Leverandøren skal levere (systemunderstøttelse) Hvis andre Leverandører skal levere ind til aktiviteten vil dette stå til sidst Tabel 2 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 Bilag 2A Sådan forretningsmodellerer vi i ATP Side 18 af 39
20 Niveau 0 proces Nr. Ydelse Nr. Styringsprocesser 30 Debitor 5 Driftsprocesser 40 Ikke specifik ydelse x Tabel 3: Nummerering af niveau 0 processer og ydelser. Figuren nedenfor viser et eksempel på nummerering af en konkret proces: Figur 11 Nummerering af processer Bilag 2A Sådan forretningsmodellerer vi i ATP Side 19 af 39
21 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 20 af 39
22 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 4 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 21 af 39
23 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 Familieydelser og store dele af Sagsmodellen indeholder den forretningsmæssige information som skal ligge i Familieydelsesløsningen. Beriget Grunddata-modellen indeholder den information, som ligger i støttesystemet (Beriget Grunddata). 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: 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ællesoffentlige standarder på området 2. Fælles afklaring med KOMBIT 3. Intern afklaring i Udbetaling Danmarks forretningsområder Bilag 2A Sådan forretningsmodellerer vi i ATP Side 22 af 39
24 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 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. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 23 af 39
25 4.2.1 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. 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 Bilag 2A Sådan forretningsmodellerer vi i ATP Side 24 af 39
26 o (#) foran attributten betyder: Protected; som har betydning for logning. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 25 af 39
27 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 26 af 39
28 Figur 15 Forretningsudbudsarkitekturen for Familieydelser 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. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 27 af 39
29 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. Figur 16 Forretningskomponentmodellen for Familieydelser 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 28 af 39
30 Figur 17 IT-udbudsarkitekturen for Familieydelser 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 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 29 af 39
31 Figur 18 Systemkontekst for Familieydelser Systemkonteksten beskrives næremere 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 Bilag 2A Sådan forretningsmodellerer vi i ATP Side 30 af 39
32 Halle og Larry Goldberg i bogen The Decision Model (2009). Beslutningsmodellen er karakteriseret ved, at den: fokuserer på beslutningslogik o Forretningsregler og beslutninger kan analyseres på lige fod med processer og information o Analysen understøttes af principper og guidelines kombinerer diagrammer og 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 31 af 39
33 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 32 af 39
34 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: F: Hvilket barn berettiget til hvilken BUY? findes i aktivitet F: Vurder (fortsat)berettigelse, som ligger i løsningsflow LF Familieydelse Træf afgørelse Beslutningen går på at vurdere, om et barn er berettiget til børne-/ ungeydelsen og i givet fald, til hvilken ydelse. Beslutningsmodellen består af en beslutning Beslut om barnet berettiget til hvilken BUY, se billedet nedenfor. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 33 af 39
35 Figur 20 Oversigt over beslutningen Beslut om barnet berettiget til hvilken BUY Som det ses ovenfor, består beslutningen, som på figuren er vist som ottekantet, af én regelfamilie, som er afhængig af to andre underliggende regelfamilier (delbeslutninger hhv. Krav til barnet ift. BUY opfyldt? og Krav til forældre m.m. ift. BUY opfyldt? ). For at få det bedste overblik går vi struktureret til modellen, og starter i bunden og kigger på, om det kan konkluderes, at krav til barnet er opfyldt på baggrund af de oplysninger, som findes på vurderingstidspunktet i Systemet (det er de fakta, der er placeret under det stiplede linje i delbeslutningen Krav til barnet ift. BUY opfyldt? ). Regler i denne delbeslutning er opstillet i Beslutningstabel, se billedet nedenfor: Bilag 2A Sådan forretningsmodellerer vi i ATP Side 34 af 39
36 Figur 21 Beslutningstabel: Krav til barnet ift. BUY opfyldt? 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 Barnet er gift eller indgået registreret partnerskab, så opfylder Barnet ikke kravene. Hvis Barnet er ugift og er registreret på en dansk kendt adresse og der ikke er tale om en EØS-sag, og der er ingen aktiv stopårsag (dvs. kommunen har ikke truffet en afgørelse om stop af ydelsen pga. visse forhold), så opfylder Barnet kravene. Og således i de resterende rækker (regler) ned i tabellen. Delkonklusionen ender altså med enten Ja eller Nej, eller Måske, hvis beslutningen ikke kan træffes på baggrund af de foreliggende oplysninger. Den anden delbeslutning, Krav til forældre m.m. ift. BUY opfyldt? vises nedenfor. Figur 22 Beslutningstabel: Krav ti forældre m.m. ift. BUY opfyldt? Bemærkning til den gule og røde farve: Beslutningstabellen er under udarbejdelse, og derfor de steder, hvor der udestå afklaringer er farvet gult og rødt. Igen startes i øverste venstre hjørne, og vi kan se, at hvis Barnet har én forældremyndighedsindehaver, og denne er ikke skattepligtig, så krav til forældre er ikke opfyldt. Hvis barnet har én forældremyndighedsindehaver og denne er fuld skattepligtig og barnet er registreret på forælderens adresse, så kravene er opfyldt. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 35 af 39
37 Hvis barnet har 2 forældremyndighedsindehavere er det nok, at mindst én er fuld skattepligtig til at opfylde kravene. Delkonklusionen ender altså med enten Ja eller Nej, eller Måske, hvis beslutningen ikke kan træffes på baggrund af de foreliggende oplysninger. Delkonklusionerne fra de to regelfamilier (delbeslutninger) samles nu i den overordnede regelfamilie, Hvilken BUY barnet er berettiget til?, se billedet nedenfor: Figur 23 Beslutningstabel: Hvilken BUY barnet er berettiget til? Delkonklusionerne fra de tidligere regelfamilier sammenholdes nu med faktum Barnets alder, og det er således i yderste højre kolonne, at vi finder den endelige konklusion af, om barnet er berettiget og til hvilken børne-/ ungeydelse, eller om der er behov for manuel behandling eller indhentning af yderligere oplysninger. Som det kan ses i tabellen er forudsætningen for at barnet er berettiget til ydelsen er at barnets alder er mellem 0 og 18 år. Ud over det, skal krav til barnet og krav til forældre være opfyldt. Hvis disse 3 betingelser er opfyldt, så er barnet berettiget til en børne-/ungeydelse med forskellige satser afhængige af barnets alder. Hvis der i de underliggende delbeslutninger ikke var muligt at enstydig fastsætte opfyldelse af krav, så konkluderes der, at barnet måske er berettiget, men det kræver enten en manuel behandling eller indhentelse af yderligere oplysninger Særlige forhold ved beslutningsmodeller Beslutningsmodeller modelleres i QLM, og kobles sammen med informationsmodeller og løsningsflows i aktivitetsbeskrivelser: Beslutningsmodeller tager udgangspunkt og forankres i aktivitetsbeskrivelser Bilag 2A Sådan forretningsmodellerer vi i ATP Side 36 af 39
38 Der modelleres udelukkende beslutninger, som forventes at køre automatisk (fx beslutninger der relaterer sig til manuel behandling af kunderådgiver forankres i en instruks og ikke i beslutningsmodeller som ovenfor vist). Bilag 2A Sådan forretningsmodellerer vi i ATP Side 37 af 39
39 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 38 af 39
40 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 39 af 39
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
Bilag 2A Sådan forretningsmodellerer vi i ATP
Bilag 2A Sådan forretningsmodellerer vi i ATP Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 SÅDAN FORRETNINGSMODELLERER VI I ATP... 4 2.1 FORRETNINGSMODELLERING I KONTEKST AF FORRETNINGSARKITEKTUREN...
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
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
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
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
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...
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
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
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
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
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...
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
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,
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
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
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...
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...
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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...
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
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
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
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
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
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?
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
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 13.10.2014 Fælles it-arkitekturstyring
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
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,
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,
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ø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
OIS - Applikationskatalog
OIS - Applikationskatalog OIS arkitekturprodukter 25. januar 2018 Indledning Dokumentationen omkring OIS er struktureret med inspiration fra OIO Arkitekturguidens arkitekturreol, således at arkitekturprodukterne
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
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...
BILAG 1: TIDSPLAN BILAG 1: TIDSPLAN 21. februar 2014
BILAG 1: TIDSPLAN 21. februar 2014 INSTRUKTION TIL TILBUDSGIVER Nærværende bilag indeholder tidsplanen for Systemet. Tilbudsgivers eventuelle forbehold til bilag 8 anføres i forbeholdslisten og skrives
Vejledning i implementering af Udbetaling Danmarks standardside om familieydelser
Vejledning i implementering af Udbetaling Danmarks standardside om familieydelser Introduktion Den 1. oktober overgår familieydelserne til Udbetaling Danmark. Det betyder, at kommunernes hjemmeside skal
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...
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,
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
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
Fælles Digital Arkitektur
1 Fælles Digital Arkitektur KL - Arkitekturrådet 17. maj 2017 AGENDA Hvidbog Standarder Review-model Rammearkitektur 2 STATUS HVIDBOG Udkastet til hvidbogen har været udsendt i offentlig kommentering i
Bilag 1: Beskrivelse af ydelsen (udkast) Konsulent Rammeaftale
Bilag 1: Beskrivelse af ydelsen (udkast) Konsulent Rammeaftale Der er udbudt følgende delaftaler: Delaftale 1: Digital forretningsstrategi Delaftale 2: It-strategi og governance Delaftale 3: It-konsulenter
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
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
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
Velkommen til markedsdialog om en ny sagsbehandlingsløsning. Den 1. februar 2017
Velkommen til markedsdialog om en ny sagsbehandlingsløsning Den 1. februar 2017 Dagsorden Velkomst v/ direktør for Forretnings- og Driftsudvikling Birgitte Kartman Om projektet v/ chef for IT Udvikling
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.
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
EFFEKTMÅLING DREJEBOG FOR KVANTITATIVE MÅLEPUNKTER EFFEKTMÅLING AF INITIATIVET SAMMENHÆNG OG GENBRUG MED RAMMEARKITEKTUREN
DREJEBOG FOR KVANTITATIVE MÅLEPUNKTER EFFEKTMÅLING AF INITIATIVET SAMMENHÆNG OG GENBRUG MED RAMMEARKITEKTUREN EFFEKTMÅLING DREJEBOG FOR KVANTITATIVE MÅLEPUNKTER Udarbejdelsen af denne drejebog Formål Tilgang
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
(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
(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
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
Projektbeskrivelse. Adgang til egne data
Projektbeskrivelse Adgang til egne data 1. Formål og baggrund 2.1 Baggrund Målsætningen i den fælleskommunale digitaliseringsstrategi er, at digitalisering styrker og underbygger nær og tilgængelig, sammenhængende
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
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
BILAG 1: TIDSPLAN DUBU 3.0. Version 0.5
BILAG 1: TIDSPLAN Version 0.5 18-11-2016 INSTRUKTION TIL TILBUDSGIVER Nærværende Bilag indeholder tidsplanen for gennemførelse af Projektet. Nærværende Bilag skal udfyldes af Tilbudsgiveren, jf. nedenstående
Bilag 16. Den Iterative Model. Til Kontrakt. Den Nationale Henvisningsformidling
Bilag 16 Den terative Model Til Kontrakt OM Den Nationale Henvisningsformidling Bilag 16 Den terative Model Side 1/9 NSTRUKTON TL TLBUDSGVER: Teksten i dette afsnit er ikke en del af Kontrakten og vil
Bilag 3A.5 Regel- og beslutningsmodeller
Bilag 3A.5 Regel- og beslutningsmodeller Version 1.0 27-04-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 INDLEDNING... 4 1 Vejledning til Tilbudsgiver Bilaget skal ikke ændres af Tilbudsgiver. Tabel
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
Retningslinjer for arkitekturreviews Version 1.0. Maj 2017
Retningslinjer for arkitekturreviews Version 1.0 Maj 2017 Indhold Indhold... 2 Introduktion til retningslinjerne... 3 Hvilke projekter skal have foretaget arkitektur-reviews?... 3 Tre trin for arkitekturreviews...
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
Underbilag 14 C: Afprøvningsforskrifter til prøver og tests
Underbilag 14 C: Afprøvningsforskrifter til prøver tests Udbud om levering, installation, implementering, support, drift vedligehold af Borgeradministrativt System (BAS) Indhold underbilag 14 C Afprøvningsforskrifter
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
<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
Ingen ydelser uden en proces
ARBEJDSGANGSBANKEN OG DIGITALISERING Det er et velkendt, at al god digitalisering starter med en analyse af den proces den arbejdsgang som digitaliseringen vedrører. Det er ligeså velkendt, at det alligevel
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,
FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø
FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har
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...
DKAL Snitflader REST Register
DKAL Snitflader REST Register 1 Indholdsfortegnelse A2.1 INTRODUKTION 3 A2.1.1 HENVISNINGER 3 A2.1.2 LÆSEVEJLEDNING 4 A2.1.2.1 SÅDAN LÆSES EN REST GRAF 4 A2.1.2.2 SÅDAN LÆSES EN RESSOURCE OG EN TYPE 4
Overblik over egne sager og ydelser
1 Overblik over egne sager og ydelser Mathilde Illum Aastrøm, Digitaliseringsstyrelsen og Steen Andersen, OptimumIT September 2017 INITIATIVETS FORMÅL Nemmere at få klaret sine ærinder Servicen bliver
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,
Arkitekturrapport: Standard for indbetalinger
Arkitekturrapport: Standard for indbetalinger Denne orienteringsrapport udarbejdes for it-projekter med effekt på den fælleskommunale rammearkitektur. Rapporten ejes af projektets it-arkitekt. Det er projektlederens
Relancering af wikien for den fælleskommunale rammearkitektur
Bilag 5 Punkt 13 Projektbeskrivelse Relancering af wikien for den fælleskommunale rammearkitektur Sammenfatning Projektets første fase skal afdække grundlaget for og stille forslag til den efterfølgende
ST Sortiment Informationsmodel
.5.27 ST Sortiment Informationsmodel .5.27. Delsortiment Delsortimentet er en obligatorisk opdeling af sortimentet i værdilister, samlinger af mulige registreringsværdier, hvor hver samling, delsortimentet,
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
Fælles retningslinjer for REST webservices
Fælles retningslinjer for REST webservices Fællesoffentlig digital arkitektur Pelle Borgsten, Nikolaj Malkov, Christian Callsen Dagsorden Punkt 1. Formål 2. Principper og forretningsbehov 3. Retningslinjer