Bilag 2A Sådan forretningsmodellerer vi i ATP
|
|
- Mikkel Laustsen
- 8 år siden
- Visninger:
Transkript
1 Bilag 2A Sådan forretningsmodellerer vi i ATP Version
2 Indhold 1 VEJLEDNING TIL TILBUDSGIVER INDLEDNING FORRETNINGSMÅLARKITEKTUR FORRETNINGSUDBUDSARKITEKTUR SÅDAN FORRETNINGSMODELLERER VI I ATP ARTEFAKTER FORANKRES I DOKUMENTATIONSREOLEN SÅDAN ER REOLEN OPBYGGET PROCES INDLEDNING PROCESKATALOG PROCESNIVEAUERNES SAMMENHÆNG IGOE LØSNINGSFLOWS AKTIVITETSBESKRIVELSER NUMMERERINGSSTRUKTUR AF PROCESSER FLOWREGLER INFORMATION INFORMATIONSARTEFAKTER BEGREBSMODELLER SÆRLIGE FORHOLD VED BEGREBSMODELLER INFORMATIONSMODELLER SÆRLIGE FORHOLD VED INFORMATIONSMODELLER Bilag 2A Sådan forretningsmodellerer vi i ATP Side 1 af 33
3 6 FUNKTIONALITET INDLEDNING FORRETNINGSKOMPONENTMODEL KONCEPTUEL IT MÅLARKITEKTUR IT UDBUDSARKITEKTUR FORRETNINGSKOMPONENTER - OG MODEL 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 33
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 33
5 2 Indledning Dette bilag giver Leverandøren indsigt i, hvordan ATP arbejder med de forretningsmæssige processer og derigennem kravstiller til systemunderstøttelse med udgangspunkt i procestrekanten. Som overligger for procesarbejdet er forretningsudbudsarkitekturen, der er udarbejdet med afsæt i Udbetaling Danmarks forretningsmålarkitektur. Forretningsmålarkitekturen er udarbejdet med afsæt i Udbetaling Danmarks succeskriterier og 5 centrale mantraer. Nedenfor ses ovennævnte sammenhænge samt procestrekantens artefakter. Ligeledes vises, hvordan de enkelte områder er forankret i Dokumentationsreolen: Figur 1 Procestrekant i samspil med artefakter og Dokumentationsreolen Bilag 2A Sådan forretningsmodellerer vi i ATP Side 4 af 33
6 2.1 Forretningsmålarkitektur Forretningsmålarkitekturen udtrykker visionen for 2020, som forretningsarkitekturen ser ud efter implementering af samtlige udbud i konkurrenceudsættelsesprogrammet: Barsel Pension Familieydelser Boligstøtte Debitor Fagsystem til kontrol mv. (tværgående ESDH). Fællesoffentlige løsninger benyttes i videst muligt omfang. KOMBIT s rammearkitektur benyttes til dataudveksling med kommunerne. 2.2 Forretningsudbudsarkitektur Denne forretningsarkitektur danner grundlag for det enkelte udbud. Udbudsarkitekturen for Familieydelser benytter sig af følgende interimløsninger: Indkomstoplysninger Udfaser KMD Børneydelses KMD Underholdsbidrag KMD Sag (dog udveksles data frem til endelig udfasning af KMD Sag) KMD Opus Debitor det forventes at nyt opkrævningssystem er klar til ibrugtagning ved idriftsættelse af ny familieydelsessystem Bilag 2A Sådan forretningsmodellerer vi i ATP Side 5 af 33
7 3 Sådan forretningsmodellerer vi i ATP Hos ATP beskriver vi vores forretning ved hjælp af processer. Denne måde at arbejde på skaber synlighed omkring forretningens kerneområder således, at det for den enkelte medarbejder i organisationen er nemt at forstå sine egne arbejdsopgaver og helheden i forretningen. Koblingen af proces, funktionalitet og information, giver mulighed for synlighed og risikostyring ved ændringer i eksisterende løsninger. En eventuel ændring i lovgivningen, giver hurtigt et fuldt overblik over hvilke processer, brugerfunktionalitet og it-system, der vil blive berørt Processerne viser samspil mellem manuelle opgaver, som udføres af kunderådgivere, og de aktiviteter som løses maskinelt af it-løsningen. Processerne behandler information. Denne tredeling, Proces, Information og Funktionalitet, er central i vores måde at forstå, beskrive og dokumentere vores forretningsmæssige behov. Figuren viser Procestrekanten: Figur 2 Procestrekanten Systemet, som skal anskaffes, er indeholdt i den stiplede teknologi-trekant, som understøtter vores forretningsmæssige behov ovenover. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 6 af 33
8 3.1 Artefakter forankres i Dokumentationsreolen At forstå, beskrive og dokumentere vores behov sker i Procestrekanten. Resultaterne placeres i Dokumentationsreolen. ATP har valgt at anvende reolen, fordi den er det offentlige Danmarks anbefaling af, hvordan dokumentation skal struktureres og fremvises. Ved at anvende Dokumentationsreolen, anvender vi samme sprog og metode som det offentlige Danmark, hvilket er en fordel i samarbejdet med øvrige myndigheder. Det offentlige Danmark benytter sig af OIO-standard som står for Offentlig Information Online, og er en struktur for dokumentation af arkitekturartefakter. Vi har dog valgt at tilpasse standard OIO-reolens indhold af artefakter med ATP-koncernens egen standard, og omtaler den Dokumentationsreolen. Reolen indeholder den samlede dokumentation for en løsning og kan sammenlignes med en velordnet bogreol, idet den giver systematik og overblik over dokumentationen. Forståelsen for vores forretningsmæssige behov fremkommer ved at arbejde med koblingen af informationer, funktionalitet og processer, som det er anskueliggjort i Procestrekanten, mens beskrivelsen af vores behov udmøntes i en række artefakter, som vi dokumenterer i vores Dokumentationsreolen. Figuren viser Dokumentationsreolen: Figur 3 Dokumentationsreolen for Familieydelse Bilag 2A Sådan forretningsmodellerer vi i ATP Side 7 af 33
9 ATP har udarbejdet eller udarbejder i Udviklingsprojektets implementeringsfase de sorte artefakter. Leverandøren leverer de røde artefakter jf. bilag 4 (Dokumentation). 3.2 Sådan er reolen opbygget På det konceptuelle niveau beskriver dokumenterne de overordnede, strategiske beslutninger. Ejerskabet er forankret hos ledelsen i organisationen. På det logiske niveau beskriver dokumenterne de generelle designregler, man opererer ud fra. Ejerskabet er forankret hos de ansvarlige for den daglige ledelse i organisationen. På det fysiske niveau er ejerskabet forankret hos de operationelt ansvarlige i organisationen, og herunder hos de leverandører man benytter til at levere løsninger. Fra venstre til højre i reolen sker der en klassificering af dokumentationen fra det strategiske hen mod det mere teknologiorienterede. Fra toppen og ned til bunden sker der en nedbrydning og detaljering af dokumentationen. Dokumentationsreolens Strategi-søjle indeholder vores Strategiartefakter, fx ATP s digitaliserings-strategi. Forretningsartefakter, som er opstået i alle 3 dele af Procestrekanten, er placeret i 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. Leverandøren får mulighed for at klikke sig igennem løsningsflow og herfra have adgang til at klikke på aktivitetsbeskrivelser, begrebs- og informationsmodeller, beslutningsmodeller, IGOE samt gældende lovgivning relateret til løsningsflow. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 8 af 33
10 4 Proces Dette kapitel beskriver, hvordan ATP arbejder med forretningsmodellering på et overordnet niveau. Med forretningsudbudsarkitekturen som overligger, kobles forretningsprocesser sammen med begrebs- og informationsmodeller, gældende lovning og forretningsregler for derved at beskrive vores behov til it-understøttelse og teknisk infrastruktur. Figuren viser placering af procestrekanten og den indhold i Dokumentationsreolen: Figur 4 Procestrekant fokus på proces 4.1 Indledning Forretningsprocesser beskriver de aktiviteter, der foregår fra en virksomhed indberetter og videre gennem sagsbehandlingen i Udbetaling Danmark, til ansøgningen er færdigbehandlet. Derudover dækker forretningsprocesserne over de ydelser, der går på tværs og leverer support til kerneprocesserne (Familieydelsesprocesserne). Forretningsprocesserne indeholder en række af automatiske og/eller manuelle aktiviteter, hvor man læser, skriver, ændrer eller sletter data ud fra givne forretningsmæssige regler. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 9 af 33
11 Processerne er i dag både et centralt, internt kommunikationsværktøj, men også et værdifuldt værktøj til kommunikation mellem forskellige parter, når vi tænker i nye forretningsmuligheder. Procestankegangen kommunikerer tæt med en række interessenter, fx lovgivere, leverandører, jurister, forretningseksperter, ledelse, kunder og slutbrugere, men også med de eksterne og interne it-systemer som indgår i processen. Den tætte kontakt, og de klare processer, er med til at sikre, at det er nemmere at ændre, justere og optimere processerne. Formålet med at tænke i forretningsprocesser i alle vores aktiviteter er at kunne tilbyde individuelle løsninger fra en standardiseret platform, og samtidigt kunne opnå forretningsmæssige stordriftsfordele i administrationen af ydelser, både til gavn for borger, virksomheder og ATP som forretning evne forandringer på en struktureret facon, uden at sætte kerneforretningen over styr. Vores mind-set er at tænke i helheder, at kigge på processerne end to end som en totaloplevelse og altid med udgangspunkt i personen eller virksomheden. Det er ud fra processerne i vort proceskatalog, at vi opstiller vores krav til den tekniske samt faglige understøttelse af processen. 4.2 Proceskatalog ATP har valgt at gruppere sine processer i et proceskatalog. ATP s proceskatalog er opdelt i: Forretningsmæssig funktionalitet (procesområde: Indberetning, Administration), der indeholder kerneprocesserne omkring vores ordninger (Familieydelser, Barselsdagpenge, Boligstøtte, Pension og Debitor). Procesområde Udbetaling, der indeholder processer omkring hvordan vi håndterer udbetaling til personer og virksomheder, foretager opkrævning og medfinansiering af ydelser samt udøver Helhedsorienteret kontrol Procesområde Kommunikation, der afspejler vores kommunikationsprocesser på tværs af ordningerne hvordan ATP modtager post, afsender digitale beskeder etc. Procesområde Styringsprocesser, der afspejler vores styringsprocesser på tværs af ordningerne. Procesområde Driftsprocesser, der afspejler vores driftsprocesser på tværs af ordninger og på bestand-niveau inden for en ordning. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 10 af 33
12 Figuren nedenfor giver et visuelt overblik over vores processer for familieydelser: Figur 5 Proceskatalog for familieydelser Procesniveauernes sammenhæng ATP opererer med procesniveauer for at sikre en ensartethed i modelleringen, set i forhold til, hvor dybt man går ned i beskrivelsen af processerne. ATP opererer med fem niveauer på processerne. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 11 af 33
13 Figuren viser processerne fra niveau 0 til 4: Figur 6 Model over procesniveauer Niveau 0 processerne (også kaldet procesområder) fremgår af proceskataloget. Niveau 1 processerne er de processer, der også fremgår af proceskataloget. De hører til under hvert Niveau 0 område. Der er udarbejdet én IGOE for hele familieydelsesløsningen. Til hver Niveau 1 proces er der koblet en tilhørende Niveau 2 proces. Hver enkel Niveau 2 proces indeholder et løsningsflow (Niveau 3). Løsningsflow indeholder aktiviteter (Niveau 4). 4.3 IGOE En IGOE (input, guidelines, output, enablers) beskriver end to end processen ud fra de 4 kriterier: I (Input) = Hvad er input til start af processen og hvem kommer med det G (Regler/rammer) = Rammerne relaterer til ATP`s interne politikker og reglerne er at sidestille med den lovgivning, der er styrende for processerne Bilag 2A Sådan forretningsmodellerer vi i ATP Side 12 af 33
14 (Output) = Hvilket output generer processen E (Ressourcer) = Hvilke systemer, samt ressourcer, er tilknyttet for at understøtte den faglige og tekniske del af processen. De er alle kilder til den endelige destination; resultatet. Figuren viser en IGOE med dens generelle indhold: Figur 7 En IGOE IGOE en laves i PowerPoint af ATP. Der er udarbejdet IGOE for ydelsesområdet. 4.4 Løsningsflows Det er i vores løsningsflows, at vi beskriver processen gennem systemer og flowet mellem interne og eksterne parter. Gennem aktivitetsbeskrivelserne definerer vi de funktionelle krav, vi har for den tekniske understøttelse af aktiviteten. Løsningsflow viser grænseflader og afhængigheder mellem de enkelte parter (borgere, kunderådgivere, fagsystem, andre interne systemer samt 3. mand), herunder hvilke arbejdsopgaver og/eller funktionalitet, der ikke er automatiseret. Svømmebanerne selvbetjener og kunderådgiver viser hvad borgeren skal gøre og hvilke arbejdsopgaver og situationer kunderådgiverne skal håndtere. Løsningsflow siger ikke noget om mængder, peaks, tid herunder online eller batch, ekspeditionstider eller angiver konkrete budskaber i breve/på nettet samt arbejdsopgavernes kompleksitet, herunder hvordan arbejdet i Kundeservice er organiseret. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 13 af 33
15 Løsningsflow er udarbejdet til fordel for it-leverandørerne og viser de krav og den funktionalitet, som vi ønsker, at it-leverandøren skal håndtere, samt en mulig måde hvorpå processerne i fagsystemet kan være håndteret. Figur 8 Løsningsflow LF-Familieydelse - Håndter indberetning Aktivitetsbeskrivelser Aktivitetsbeskrivelserne er opbygget i en bestemt afsnitsstruktur på tværs af alle løsningsflow. Tabellen nedenfor beskriver de forskellige emner, som indgår i strukturen og som er afspejlet i billedet ovenfor: Emne Formål Startbetingelse Beskrivelse Sluttilstand Beskrivelse Kort beskrivelse af aktivitetens formål Startbetingelser/Forudsætninger angiver, hvilke betingelser der er for at aktiviteten kan gennemføres. Et eksempel er, at en forudgående aktivitet er blevet gennemført, eller en given information er modtaget. Det kan forekomme, at der er mere end én startbetingelse til en aktivitet. Hvis dette er tilfældet, skal startbetingelser opsættes i punktform. Beskrivelsen af en startbetingelse skal være kort og sigende. En længere beskrivelse af hvad aktiviteten omfatter. Evt. på punktform eller som en længere tekstbeskrivelse, som supplerer den korte. Som en del af beskrivelsen beskrives rollerne (dem der har en aktie i aktiviteten). Vi beskriver sluttilstanden, når vi har gennemført en aktivitet. Sluttilstanden følger samme princip som startbetingelsen. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 14 af 33
16 Emne Input Output Regler Behov for understøttelse af aktivitet Beskrivelse Input angiver, hvad der eventuelt modtages til at starte processen. Det kan være en datafil systemgenereret godkendelse eller advis. Input skal stemme overens med outputtet fra den foregående aktivitet. Output angiver, hvad der i sidste ende generes af selve aktiviteten, og hvilke krav der er til evt. form. Output følger samme princip som Input I dette afsnit henvises til de beslutningsmodeller/regler, der ønskes implementeret til styring af aktivitetens funktionalitet. Det er også her at der kan kobles gældende lovgivning til aktiviteten, for at synliggøre hvorfor vores beslutningsmodeller/regler ser ud som de gør. Beskriver de konkrete krav til leverandørens leverance. I dette afsnit refererer vi til bestemte attributter i informationsmodellen, i de tilfælde hvor det er nødvendigt for forståelsen af kravene. Der gælder følgende retningslinjer: Der skives tydeligt hvad Leverandøren skal levere Hvor der er tilknytning til en snitflade fremgår dette med reference til entydigt integrationsid Først står hvad Leverandøren skal levere (systemunderstøttelse) Hvis andre Leverandører skal levere ind til aktiviteten vil dette stå til sidst Tabel 2 Indhold i aktivitetsbeskrivelse 4.6 Nummereringsstruktur af processer Der er koblet en nummereringsstruktur på alle Niveau 1 og 2 processer, samt de løsningsflows, der er koblet op på Niveau 2 processerne. Figuren viser dén struk- Bilag 2A Sådan forretningsmodellerer vi i ATP Side 15 af 33
17 tur, nummereringen af en given proces følger: Figur 9 Nummereringsstruktur af processer Figuren nedenfor viser, hvordan procesområde og ordningsnumre er givet på forhånd for hver enkelt proces: Procesområde Nr. Ordning Nr. Indberetning 1 Pension 1 Administration 2 Boligstøtte 2 Udbetaling 3 Barselsdagpenge 3 Kommunikation 20 Familieydelser 4 Styringsprocesser 30 Debitor 5 Driftsprocesser 40 Ikke specifik ydelse x Tabel 3: Nummerering af procesområde og ordninger. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 16 af 33
18 4.7 Flowregler Flowregler modelleres når endelig proces (løsningsflow) er udarbejdet i samspil med Leverandør. Flowregler udarbejdes jf. beskrivelse i afsnit 6.6 Bilag 2A Sådan forretningsmodellerer vi i ATP Side 17 af 33
19 5 Information Dette kapitel skal give en forståelse af vores metode for modellering af information. Når vi forretningsmodellerer, arbejder vi med Information i Procestrekanten: Figur 10 Procestrekant fokus på information Begrebs- og informationsmodellerne indeholder krav til, hvilke forretningsmæssige begreber, som skal kunne persisteres i Leverandørens løsning. De forretningsmæssige behov for information beskrives og dokumenteres i begrebs- og informationsmodeller. Leverandøren beskriver og leverer dokumentation for Systemet i logiske og fysiske datamodeller. Dette kapitel forklarer vores begrebsarkitektur, valg af begrebsdokumentation, dokumentationsværktøj. 5.1 Informationsartefakter Information i Procestrekanten, Figur 10 Procestrekant fokus på information, beskrives i fire forskellige modeller. Figuren viser de fire modeller: Bilag 2A Sådan forretningsmodellerer vi i ATP Side 18 af 33
20 Model Indhold Ansvar Begrebsmodel Forretningsmæssige Informationsmodel Begreber ATP leverer 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. ATP udarbejder begrebs- og informationsmodeller og har modelleret efter følgende regler: Vi prioriterer det højere, at modellerne indeholder genkendelige forretningsmæssige begreber, fremfor at modelleringen er korrekt i forhold til generelle principper for datamodellering. Der afviges for eksempel fra princippet om, at data kun bor ét sted i modellen, hvis det er relevant for forretningen at se både inputdata, og også hvor disse data anvendes. Der afviges også fra normaliseringsregler. Modellerne er statiske modeller, og de har ikke nogen tidsmæssigt forløb, Modellerne viser intet om behov for historiske data. Modellerne har alle en generel definition af begreberne, samt eventuelt også kommentarer. Modellerne indeholder udelukkende de forretningsmæssige begreber som skal systemunderstøttes. Begreber og attributter kan ændre sig som følge af det udviklingsarbejde, der starter sammen med Leverandøren. Vi har generiske modeller, som indeholder begreber som skal anvendes i alle ordninger Vi har specifikke modeller, som indeholder begreber og som kun skal anvendes i en enkelt ordning. Opdelingen mellem de enkelte modeller er en forretningsmæssig logisk opdeling, som ikke har nogen sammenhæng til, hvordan der vælges at opdele data i forskellige systemer. Opdelingen af data i fagsystemer fastlægges alene i forretningsarkitekturen. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 19 af 33
21 Som en grov hovedregel kan man dog antage, at familieydelsesmodellen 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). Udbetaling-modellen indeholder den information, som ligger i støttesystemet (Udbetaling). Opkrævning er ikke modelleret særskilt. 5.2 Begrebsmodeller Begrebsmodeller er de overordnede modeller af vores forretningsdomæne. De viser konceptuelle begreber og relationer, som indgår i Udbetaling Danmarks sagsbehandling. Overordnet set kan vi modellere Udbetaling Danmarks sagsbehandling, som vist i figuren nedenfor, hvor det ses, hvordan vi interagerer med omverdenen i behandlingen af sager i de forskellige ordninger: Overordnet begrebsmodel for Udbetaling Danmark Figur 11 Overordnet begrebsmodel Alle begreber og attributter i begrebs- og informationsmodellerne er, når det er muligt, defineret efter følgende i prioriteret rækkefølge: 1. Fællesoffentlige standarder på området 2. Fælles afklaring med KOMBIT 3. Internt afklaret i Udbetaling Danmarks forretningsområder Bilag 2A Sådan forretningsmodellerer vi i ATP Side 20 af 33
22 Den overordnede begrebsmodel viser, hvordan Personer, Virksomheder eller Myndigheder kan starte eller have en relation til en given sag, som Udbetaling Danmark foretager automatisk og/eller manuel sagsbehandling på. Vi har nedbrudt denne overordnede begrebsmodel i en række mere detaljerede begrebsmodeller. De generiske modeller er fælles for Udbetaling Danmarks ordninger, og indeholder således forretningsmæssig information for flere ordninger. Der er følgende generiske modeller: Beriget Grunddata Sag Udbetaling De specifikke modeller, derimod, rummer kun information for en enkelt ordning. Der er følgende specifikke begrebsmodeller: Barseldagpenge Boligstøtte Familieydelse Pension 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 logisk samhørende entiteter er samlet i delområder. 5.3 Informationsmodeller Informationsmodellerne tager udgangspunkt i begrebsmodellerne og er detaljerede og udbyggede modeller af begrebsmodeller. Informationsmodellerne er tillige udgangspunktet for de logiske datamodeller. Der er én Informationsmodel for hver begrebsmodel, og derudover er der lavet en særskilt informationsmodel for Udbetaling Danmark. Dette er gjort af hensyn til overskueligheden. Informationsmodellerne, samt begrebsdefinitioner, findes i Dokumentationsreolen. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 21 af 33
23 5.3.1 Særlige forhold ved informationsmodeller Informationsmodellerne er beriget med attributter gennem arbejdet med aktivitetsbeskrivelser. Sammen med en leverandør gennemføres en proces i afklaringsetapen eller i delleverancers afklaringsforløb som valider og supplerer informationsmodellerne. Der er ikke sat systemtekniske nøgler på klasserne, og der er kun sat forretningsmæssige nøgler på enkelte klasser. Det er gjort, hvor de forretningsmæssige nøgler er alment kendt og anvendt i forretningen. Informationsmodellerne ligger på det logiske niveau i Dokumentationsreolen og danner, sammen med løsningsflows og beslutningsregler, en sammenhængende dokumentation af de forretningsmæssige behov. Forretningskomponenters logiske opdeling er lagt til grund for informationsmodellens logiske opdeling. Informationsmodellerne danner, sammen med aktivitetsbeskrivelserne i løsningsflow, en sammenhæng mellem funktionalitet og information. Hvor der i aktivitetsbeskrivelser i løsningsflow er henvisning til forretningsmæssige begreber skal disse kunne findes i informationsmodeller. Det giver en kvalitetssikring af, at de færdige informationsmodeller indeholder alle forretningsmæssige begreber. Vi modellerer i et UML Class diagram (QLM) Entiteter er repræsenteret i enkeltenheder (Class) Logisk samhørende entiteter er samlet i delområde (Package) Blå entiteter er hjemmehørende i en anden informationsmodel men er indeholdt for at lette forståelsen for en sammenhæng En attribut på en class kan være obligatorisk eller frivilligt udfyldt. Denne skelnen kan ses ud fra attributtens multiplicity En attribut på en class kan være følsomt data som skal logges. Det vises med en logningsmarkering. Dette ses på hver class, hvor attributten har følgende markering: o (-)foran attributten betyder: Private; følsomt data, logning påkrævet. o (+) foran attributten betyder: Public; ikke-følsom data, logning ikkepåkrævet. 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 22 af 33
24 6 Funktionalitet Dette kapitel skal give en forståelse af ATP s metode for modellering af funktionalitet Når vi forretningsmodellerer, arbejder vi med Funktionalitet i Procestrekanten: Figur 12 Procestrekant fokus på funktionalitet Funktionalitetsartefakterne vist i figuren indeholder krav til arkitekturen og rammerne for den forretningsmæssige funktionalitet. 6.1 Indledning Leverandøren bliver i stand til at forstå vores funktionalitetsartefakter, som indeholder krav til arkitekturen og rammerne for den forretningsmæssige funktionalitet, som leverandøren skal udvikle. 6.2 Forretningskomponentmodel konceptuel ATP s konceptuelle forretningskomponentmodel er udmøntet i en faktisk model for Familieydelser. Bilag 2A Sådan forretningsmodellerer vi i ATP Side 23 af 33
25 6.3 IT Målarkitektur IT Målarkitekturen har fokus på it-understøttelse af forretningsmålarkitekturen. Oversigten viser hvordan IT arkitekturen ser ud efter implementering af KUP projekterne: Barsel Pension Familieydelser Boligstøtte Debitor System til kontrol mv. Fælles offentlige løsninger benyttes i videst muligt omfang. 6.4 IT Udbudsarkitektur IT Udbudsarkitekturen er udarbejdet med afsæt i IT målarkitekturen og afspejler IT arkitekturen efter implementering af Familieydelsessystemet. 6.5 Forretningskomponenter - og model Forretningskomponentmodellen viser Systemets interne komponenter. Komponentmodellen er tegnet i et komponentdiagram.. De enkelte komponenter er beskrevet ved deres ansvar samt deres relation med andre systemer/komponenter. Familieydelsessystemet er opdelt i forretningskomponenter, hvor hver komponent er en logisk afgrænset del af Systemet, som indeholder funktionalitet og information til at udføre aktiviteter, der ligger indenfor komponentens område. En brevkomponent sørger for at udtrække data og tekst til breve, indsamle adresser og pakke det hele sammen, således at en printleverandør kan foretage udprintning. Systemet er opdelt i komponenter for at sikre løs kobling mellem komponenterne og høj samhørighed indenfor en komponent. Opdelingen i komponenter giver ATP en større fleksibilitet til at løfte en komponent fra Systemet op til at være en generisk komponent som kan anvendes af flere ordninger. 6.6 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, Bilag 2A Sådan forretningsmodellerer vi i ATP Side 24 af 33
26 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 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 25 af 33
27 Figur 13 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 26 af 33
28 6.6.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 27 af 33
29 Figur 14 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 28 af 33
30 Figur 15 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 16 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. Hvis Bilag 2A Sådan forretningsmodellerer vi i ATP Side 29 af 33
31 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 17 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 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 30 af 33
32 Bilag 2A Sådan forretningsmodellerer vi i ATP Side 31 af 33
33 7 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/mockups 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. 7.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 32 af 33
34 7.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 (borgere, virksomheder og kunderådgivere) 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. 7.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. 7.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 33 af 33
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...
Læs mereBilag 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 mereBilag 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 mereBilag 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 mereATP 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 mereIndledning 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 mereIt-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 mere15 å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 mereArkitekturrapport: 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 mereBilag 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 mereUDBETALING 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 mereBilag 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 mereEjendomsdataprogrammet - 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 mereBilag 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 mereLeverandø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 mereOm 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 mereBilag 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 mereMetodehå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 mereEjerfortegnelse 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 mereKommunernes 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 mereStrategi 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 mereReferater 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 mereEDS 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 mereKlik 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 mereSAPA. 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 mereBilag 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 mereDigital 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 mereIt-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 mereBilag 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 mereKundeoplevelser 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 mereEA3 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 mereVilkå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 mereKlik 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 mereScope 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 mereProcedurer 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 mereDen 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 mereIT- 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 mereF remtidens Digital Post
F remtidens Digital Post Kommunale input til videreudvikling af Digital Post Anvendelse af Digital Post er en central del af udviklingen af den offentlige service. Derfor er det vigtigt, at kravene til
Læs mereEn digital verden. Fra ideer til brugbare løsninger
En digital verden Fra ideer til brugbare løsninger Fra Marketing til Digitalisering Marketing Marketing og digitalisering Digitalisering Udbetaling Danmark Tillykke-brevet Den fællesoffentlige digitaliseringsstrategi
Læs mereDen 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
Læs mereBilag 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 mereDEN 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 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 mereAgenda 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 mereBilag 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 mereBilag 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 merePeter 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 mereStø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 mereKoncept 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 mereOpsamling 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 mereATP s digitale kundeservice god kundeservice forenet med lave administrationsomkostninger
ATP s digitale kundeservice god kundeservice forenet med lave administrationsomkostninger Kammeradvokaten 8. november 2013 ATP Koncernens visioner Vi er her for at sikre hele Danmark økonomisk grundtryghed.
Læs mereDEBITOR. 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 mereBilag 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 mereTil 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(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 mereProjektbeskrivelse. 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
Læs merePLAN OG UDVIKLING GIS-STRATEGI 2012-2016
PLAN OG UDVIKLING GIS-STRATEGI 2012-2016 Indhold 1 INDLEDNING 3 2 STRATEGIGRUNDLAGET OG HANDLINGSPLAN 5 3 VISION 6 4 PEJLEMÆRKER OG PRINCIPPER 8 4.1 TEKNOLOGI 8 4.1.1 Principper 8 4.2 KOMMUNIKATION 9 4.2.1
Læs mereInformationsforvaltning i det offentlige
Informationsforvaltning i det offentlige 1 Baggrund Den omfattende digitalisering af den offentlige sektor i Danmark er årsag til, at det offentlige i dag skal håndtere større og større mængder digital
Læs mereVejledning 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
Læs mereRetningslinjer 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...
Læs mereKonkurrenceudsæ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 mereBilag 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 mereBUDSKABSPAPIR om den fælleskommunale rammearkitektur for it og digitalisering ("rammearkitekturen")
1 BUDSKABSPAPIR om den fælleskommunale rammearkitektur for it og digitalisering ("rammearkitekturen") BRUGSVEJLEDNING Budskabspapiret er en hjælp til at sætte ord og sætninger på, når du som kommunal chef
Læs mereData 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 mereIndlæ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 mereFremtidsmodel (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 mereBilag 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 mereBilag 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 mereBilag 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 mereVejledning - Udarbejdelse af gevinstdiagram
Vejledning - Udarbejdelse af gevinstdiagram Maj 2015 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4
Læs mereLø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 mereDigital 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 mereHassansalem.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 mereOversigt 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 mereBilag 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
Læs mereFaktaark 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 mereInformationsmø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 mereVejledning 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 mereArkitekturrapport: MDB Min Digitale Byggesag
Arkitekturrapport: MDB Min Digitale Byggesag Denne orienteringsrapport udarbejdes for it-projekter med effekt på den fælleskommunale rammearkitektur. Rapport ejes af projektets it-arkitekt. Det er projektlederens
Læs mere1 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 mereHillerød Kommunes Kanalstrategi 2014-2018
Hillerød Kommunes Kanalstrategi 2014-2018 Forord Hillerød Kommunes Kanal- og Servicestrategi er en samlet strategi for kommunikation mellem kommune og borgere, virksomheder og foreninger. Service over
Læs mereMetodehå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 mereFAGLIGT NYT FRA UDBETALING DANMARK
Til kommunernes borgerservice Oktober 2014 Uge 41 Ref.nr.: Fagligt nyt fra Udbetaling Danmark Oplys venligst ved henvendelse Indhold Tema: Obligatorisk digital selvbetjening... 2 Undtagelsesmodel... 2
Læs mereBilag 1: Teknisk dialogmøde for udformningen af Digital Post
Bilag 1: Teknisk dialogmøde for udformningen af Digital Post Næste generation Digital Post, 2016 Indhold Indledning... 2 Kap. 1 Formelle rammer... 3 Kap. 2 Vision og formål... 3 Kap. 3 Næste generation
Læs mereFæ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
Læs mereForslag til ny struktur - overblik
BESKRIVELSESVÆRKTØJ Forslag til ny struktur - overblik Den korte version Udarbejdet af Molio 2018-03-01 Høringsversion Molio 2018 1 Indledning og formål Molio ønsker at omlægge beskrivelsesværktøjets struktur.
Læs mereFormidling 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 mereEjendomsdataprogrammet - 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 mereSAPA Kommunenetværk Øst & Vest. KMJ 28. august 2013, Værløse 29. August 2013, Middelfart
SAPA Kommunenetværk Øst & Vest KMJ 28. august 2013, Værløse 29. August 2013, Middelfart P R O J E K T S T A T U S 1. Kravspecifikation A. Kommuner B. Leverandører 2. Faglige afklaringer i workshops 3.
Læs mereWHITEPAPER DokumentBroker
WHITEPAPER DokumentBroker Copyright 2013 DokumentBrokeren er en selvstændig arkitekturkomponent, som uafhængigt af forretningsapplikation og kontorpakke, genererer dokumenter af forskellige typer og formater,
Læs mereProjekt 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 mereDECEMBER Vejledning til kommunens snitfladestrategi
DECEMBER 2016 Vejledning til kommunens snitfladestrategi Dette notat introducerer arbejdet med kommunens snitfladestrategi. Snitfladestrategien beskriver kommunens strategiske beslutninger vedr. snitflader
Læs mereOIS - Applikationskatalog
OIS - Applikationskatalog OIS arkitekturprodukter 25. januar 2018 Indledning Dokumentationen omkring OIS er struktureret med inspiration fra OIO Arkitekturguidens arkitekturreol, således at arkitekturprodukterne
Læs mereErfaringer med CPR-replikering
Erfaringer med CPR-replikering Dette dokument beskriver en række overvejelser vi har gjort os i forbindelse med at vi har udviklet en Proof of Concept (PoC) af en CPR-replikeringstjeneste for KOMBIT. CPRs
Læs mereBilag 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
Læs mereBehov for større sammenhæng og fælles sprog om borgerens tilstand på tværs af myndigheder, udfører og aktører inden for socialområdet
Projektbeskrivelse 2.2 Sammenhæng og viden om effekt på socialområdet 1. Formål og baggrund Kommunerne har i de senere år styrket kvaliteten i det socialfaglige arbejde gennem udvikling og implementering
Læs mereDigitaliseringsstrategi
Digitaliseringsstrategi Godkendt i xx den xx.xx.2010 Digitalisering i Viborg Kommune skal understøtte en helhedsorienteret og effektiv service over for borgere og virksomheder effektivisere de kommunale
Læs mereBilag 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 mereBilag 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