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 kobles på DKC eller er det kun de nye fagsystemer i takt med, at de kommer i udbud? Hvor stor bliver porteføljen af fagsystemer tilkoblet DKC? Er DKC et system, der har sin egen datamodel, der selv opbevarer fysiske data? Hvordan håndteres den fysiske print- og brevafsendelse idag? Vil ATP have fagsystemer uden journalmoduler? Hvor dannes breve? Når ATP kigger på platforme til DKC, hvad har I så fokus på? Kigger I også på ESDH? Forudsætter fagsystemer eller DKC at sagen fødes digitalt? Svar fra ATP Den endelige strategi er ikke pt. valgt, vi overvejer forskellige scenarier, men ATP vil have en væsentlig rolle i drift setuppet. Fagsystemet ejer data Kun de nye fagsystemer. Pt. er planen ca. 5 fagsystemer, men vi kan ikke låse et endeligt antal fast. Det vil formentlig blive et multileverandør setup, og der skal løbende kunne kobles fagsystemer til og fra, det stiller høje krav til fleksibilitet. Ja, det er tanken, at DKC skal være et system med egen datacontainer, og som holder data fra de bagvedliggende fagsystemer. Udbetaling Danmark benytter i dag Doc2mail, som håndterer den videre udsendelse af fysisk post. Ja, det skal foregå i DKC Der er 2 veje. - De manuelt genererede breve, hvor kunderådgiveren selv er inde og forfatte et brev, her hentes brevskabelonen i DKC og afsendes via den fællesoffentlige printløsning (når den kommer) eller sendes via digital post. - De af fagsystemet automatisk genererede breve, dvs. en forretningsadministrator laver en brevskabelon for en udbetalingsspecifikation, det lægger vi ind i fagsystemet på et tidspunkt, hvor brevskabelonen skal udføres i flowet herefter fletter den med udvalgte data fra fagsystemet og sender den automatisk ud fra fagsystemet. Når det sker, bliver det så også journaliseret ovre i DKC. Fagsystemet skal selv kunne flette de automatiske breve. Vi har stor fokus på vores integrationer, ESDH-systemet vil kunne løse noget af opgaven, men ikke det hele. Ikke nødvendigvis, hvis vi f.eks. på barsel får en manuel ansøgning ind, går Kunderådgiveren i DKC og trykker på opret sagsmappe. Herefter oprettes en sag automatisk i

fagsystemet og fagsystemet sender et sags ID tilbage. Digitale henvendelser i DKC regi indeholder det input/output til sagerne? Hvis sags dannelse sker i eksisterende fagsystemer, hvad sker der så i den periode, hvor de nye fagsystemer ikke eksisterer, men DKC et eksisterer? Hvad sker der i den periode? Hvor meget sagsbehandling håndteres i fagsystemet f.eks. barsel, og hvad er det egentlig, der forgår oppe i DKC af sagsbehandling? Er det korrekt forstået, at ATP ikke gør brug af ATP s egne systemer i stor udstrækning i forhold til ATP s infrastruktur? Vedrørende input/output til sager, hvor der f.eks. skal klistres oplysninger på eksisterende sager, skal I så have fem systemer til at håndtere input/output delen? Standardisering med OIO, er det i spil? Er det relevant med et modul til fx mødeindkaldelser og dagsordner? Skal DKC indeholde alle data? Bliver alle henvendelser til Selve sags oprettelsen og opmagasineringen af data sker i fagsystemet. Herefter scannes ansøgningen og ligges i bunden af sagsmappen i DKC. Ikke altid, en digital henvendelse kan også være et spørgsmål, som kommer ind via borger.dk. Kunderådgiveren kan så journalisere det automatisk men kan også journalisere det manuelt og besvare. Planen er, at vi tager et fagsystem ind ad gangen. Så sager i DKC følges med det nye fagsystem. Al sagsbehandling, der kan håndteres uden menneskehånd, håndteres automatisk af fagsystemet. Udfald i processerne, som kræver en faglig vurdering eller anden gennemgang ligges, som en opgave i indbakken i DKC. Telefoner for front Kunderådgivere skal kunne besvares fra DKC, f.eks. i form af personoverblik og videnløsning. Kunderådgiveren skal med DKC kunne besvare langt de fleste telefoner, uden at Kunderådgiverene behøver at skifte system til fagsystemet. Rammearkitekturen fastlægges sammen med Kombit og valg af infrastruktur elementer udvælges i Udbetaling Danmark set ud fra den samlede kommunale økonomi. Nej det skal vi ikke. Det skal via en input/output manager. Ja det er det. Når vi sender sager og ydelser til sags- og dokument index, er det OIO s snitflader, der anvendes. Det vil give mening at anvende lignende snitflader omkring DKC og fagsystemerne. Nej, ikke umiddelbart. Nej, men vi har brug for at kunne udstille/sammensmelte data fra andre kilder på en individuel sag. Så hvis en borger ringer ind, så kan kunderådgiveren automatisk se oplysninger om den sag/borger fra alle kilder. Nej, vi skal have data, inden vi ved, om der bliver en sag.

sager? Har I også brug for en knowledgeløsning? I har 6-7 forskellige kundecentre i landet? Borgeren skal vel ikke opleve en forskel i service? Mangler der ikke en selvbetjeningsløsning i komponenter på DKC tegningen? Hvis Finanstilsynet fx vælger at placere yderligere ydelser hos Udbetaling Danmark, vil behovet for 360 graders borgerview vel være påkrævet? Skal sagsbehandlerne i kommunen have adgang til DKC? I forhold til et 360 graders syn på borgeren? Vejen fra fagsystemet og over til DKC: Hvor friske skal data være her? Skal de være et halvt sekund gamle eller kan I leve med, at det er 10 minutter om at opdatere? Det ser ud, som om der mangler en vigtig komponent omkring ledelses- og proceshåndtering, eller er det med? Når I arbejder med blanketter, er det så bare pdf'er? Vi håber ikke, at jeres kravspec bliver sat op sådan, at det afskærmer os fra at bruge vores standard produkter eller en af jeres standard platforme i dag? Er det interessant for jer at bruge task management/workflow på opgaverne? Hvordan er jeres videnløsning Vores henvendelser fører ikke nødvendigvis til en sag. Ved mange af vores henvendelser slår kunderådgiver op i videnløsningen og giver et svar til borgeren. Denne type henvendelser bliver aldrig en sag. Vi har allerede en videnløsning fra Moxie, denne skal integreres i DKC. Centrene skal ses som virtuelle centre, som kun er fysisk opdelte. De kører efter samme proces og på samme videnløsning og callcenter. Nej, fagsystemerne leverer deres egen selvbetjeningsløsninger til borger.dk. DKC er kunderådgivernes værktøj. Så derfor er der ikke tænkt nogen selvbetjeningsdel ind i DKC. Det må vi forholde os til, hvis det bliver aktuelt. Nej, det skal de ikke. Det skal løses via det sagsindeks, som Kombit skal udvikle. Lovgivningen foreskriver, hvilke informationer der må deles på tværs af Udbetaling Danmark og kommunerne. Det vi, i virkeligheden, går med er nogle forskellige modeller for kvalitet og data. Det er vigtigt, at kunderådgiveren kan stole på, at vitale data er opdateret i DKC, det vil blive kravstillet, hvordan vi ser på det i forhold til tidspunkter på døgnet, samt hvilke data er kritiske hvornår. Det er en af de tre helt vigtige ting, måske bliver det ikke kommunikeret helt klart ud fra tegningen. Men det er meget væsentligt; det er i virkeligheden, derfor vi har brug for et tværgående system, så vi kan se, hvilke opgaver der er, og hvordan vi kan prioritere etc. Vi har begge dele. Vi vil helst have dem automatiserede, men vi har også områder, hvor det ikke giver mening at digitalisere dem. Kravene lukker ikke for muligheden for at bygge videre på eksisterende applikationer eller platforme. Både nej og ja. Det kan godt være, at vi ville bruge det meget smalt, men ikke i stor stil. Vi har tidligere brugt en lille wizard, har vi lavet en lille boks oppe i hjørnet, hvor der står, at når du får den her task, så skal du gøre det her, slutte af med et brev osv.- men anvendes i lille skala de store proces tunge opgaver ligger i fagsystemet. Vi vil ofte anvende videnløsningen og instrukser til nye medarbejdere. Det ligger i Moxie og er bygget op om de enkelte

bygget op? I DKC forestiller I jer, at 80 % af de henvendelser som kommer ind bliver løst her? ydelsesområder. Man kan tilgå instrukserne derfra. Instrukserne bliver så udarbejdet i Qualiware Lifecycle Manager, men eksponeret i Moxie (HTML-genereret). For hver aktivitet er der tilkoblet nogle instrukser, som du klikker dig ind på. Nej. Det er omvendt. På barsel får vi vores ansøgninger ind igennem Nem Refusion. Så kommer det ind i vores fagsystem. Det opretter en sag og indlæser de modtagne data. Samtidig opretter det en sagsmappe i DKC. Der er altid en 1 til 1 mellem vores sag i fagsystemet og vores sagsmappe i DKC. Fagsystemet sagsbehandler på sagen ud fra nogle regler. Det kan fx være forretningsmæssige regler. Hvis vi er gode, så kan den på baggrund af reglerne træffe afgørelse. Du er berettiget til barsel, refusion osv. Så kører den igennem systemet til udbetaling. Der er altså oprettet en sagsmappe i DKC. Hvis der kommer en mail, ændring eller lign. som vedrører sagen, så journaliseres ændringen til sagsmappen. DKC modtager også opgaver fra fagsystemet, som kommer over i en opgaveindbakke. Så bliver der automatisk genereret en opgave i DKC med en årsagskode fx alvorligt syg barn- kig nærmere på vedhæftet lægeerklæring. Så hiver du sagsmappen og dokumentet frem. Finder medarbejderen sagen i DKC eller fagsystemet? Kan sagen afsluttes i DKC? Fagsystemet ejer sagen og data. DKC Kunderådgiveren kan initiere en afslutning af sagen fra DKC. En afslut knap i DKC bliver aktiveret, og beskeden ryger videre til fagsystemet. Fagsystemet lukker sagen. Skal alle henvendelser ikke rapporteres? Bruger I noget output management system i dag? Hvad er jeres referenceramme? Foretrækker I tynde klienter? Har I nogen præferencer til platform? Med hensyn til medbyg. Har I gjort jer nogen tanker om ATP s rolle? Kunderådgiveren vil tro, at sagen bliver lukket i DKC, men teknisk bliver den lukket i fagsystemet, som ejer sagen. Nej. Fx hvis det er åbningstiden i Hillerød. Kun på ATP ordninger ikke endnu på Udbetaling Danmark. I dag bruger vi tykke klienter, hvad vi foretrækker fremadrettet kræver nærmere analyse. Nej, det har vi ikke. Det er åben konkurrence. Vi vil være en del af projektet. Vi skal løbende henover de næste mange år koble flere fagsystemer til DKC, så der vil løbende blive opstartet nye projekter samt opdateringer til

Hvor meget har I tænkt jer at gå ud og få ændret i jeres processer, hvor meget vil det blive de samme blanketter, processer m.m.? Vigtigt for os at vide, hvor meget vi kan udfordre de nuværende løsninger. Hvordan influerer støttesystemerne på DKC? Hvor kommer kravet om at ydelserne skal kunne flyttes væk fra Udbetaling Danmark igen? Indholdet i DKC, fælles for de forskellige fagområder, det er her, du kan se sagerne på tværs af den enkelte borger, er der nogle SAPA eller KMD sag paralleller? Vi forstiller os at sagsbehandlingen er i et system, hvornår sker skiftet, og hvornår sker skiftet af brugerfladen? Hvornår går man over i et andet system, fordi nu har sagen fået en anden karakter? Det er fordi man gerne vil holde DKC ren? Hvordan peger Borger.dk ind i DKC og fagsystemerne? Hvordan i forhold til de andre allerede implementerede fagsystemer. Vi er nødt til at følge de love, der er udstukket for vores ydelsesområder, men i forhold til standard systemets anvendelse, er I mere end velkommen til at udfordre, så kan vi evaluere, hvordan det passer ind i arbejdsgangene i forhold til lovene. Vi ligger os op af de fælles offentlige komponenter, som de løbende bliver klar til implementering. Imellem tiden vil en transformationsarkitektur være implementeret i DKC. Lov om Udbetaling Danmark foreskriver, at ydelserne skal konkurrenceudsættes igen. Ja, der er fælles træk mellem SAPA og DKC f.eks. personoverblikket kan minde om hinanden. ATP og Kombit er i tæt dialog vedr. om Kombit kan integrere ATP s krav ind i SAPA, der er et stort overlap, men det som er vigtigt for os, er den objektive sagsbehandling, og at vores sagsfabrik skal være så effektiv som muligt. Vi ønsker, at 80 % af de manuelle opgaver skal kunne læses i DKC. Vi skal have defineret de 20 %, hvor vi skal over i fagsystemet. Det har ikke noget med sags kompleksiteten at gøre i virkeligheden. Det har noget at gøre med kompleksiteten af den her opgave man løser. Hvis en borger ringer ind og spørger hvis nu jeg skal på barsel.., så slår man enten op i vores videndatabase og finder svaret, henviser eller sender noget til borgeren. Det er ikke sagens kompleksitet nødvendigvis, der gør om det skal forgår over i fagsystemet eller DKC. Hvis det skal lykkes med vores løsninger, skal de ikke ret meget ind i fagsystemet. Tænkt som en hop-til funktion for at se, hvad der er af data i fagsystemet. Profilering af data i brugergrænseflade kunne være en anden mulighed. Det vil vi selvfølgelig også gerne, men der er jo en business case, borgerne skal kunne betjene sig selv, kan de ikke det, så kan de gå ned på kommunen og få hjælp. Vi skal ikke have alle mulige dokumenter ind her, som kunderådgiverne skal bruge tid på. Visionen er, at det skal være benhårdt afgrænset, for ellers er der jo ikke en case i det her. Der bliver ikke de der store hop mellem systemerne. Hver fagsystem leverer en webløsning, som kan indlejres i borger.dk. Vi ønsker, at borgeren kan få svar på mange ting uden at få hjælp. Borger.dk bliver vores univers derude. DKC vil blive implementeret sammen med det første

komponenter, hvor meget kommer på plads, før man laver de første fagsystemer? Hvad er det man henter fra borger.dk? Er det Digital Post? Det er jo separat fra borger.dk. Borger.dk er bare borgerens adgang til Digital Post ikke? Er der andet I henter fra borger.dk? Skal man kunne se data fra flere borgere samtidig? I tildeler i maj/juni. Hvor lang tid går der før det skal være implementeret (det er lidt uklart i materialet)? Hvor bor sagen og dokumenterne? Afklaring omkring tanken bag DKC og fagsystemet fagsystem. Det, som det går ud på er, at vi skal kunne modtage Digital Post. Der er altså ikke tale om en integration med borger.dk. Man skal mere kunne se sammenhængen mellem fx hvem er borgeren gift med, og hvilke børn er der. Det er typisk et telefonopkald, hvor kunderådgiveren skal kunne se en masse data for den ene borger, men ikke data fra andre borgere. Projektet starter op i august, men det skal ikke være implementeret der. Vi arbejder hen imod at sagen bor i fagsystemet. Dokumenterne bor i DKC. Vi har et fagsystem og et digitalt kontakt center. Tanken er, at alle formularer, når de f.eks. kommer via Nem Refusion, går gennem fagsystemet som procesmotor, og fagsystemet håndterer alle de automatiske aktiviteter. De opgaver ligger på det, vi kalder motorvejen, det er der, hvor vi har stor volumen, og det er de opgaver, vi ønsker at automatisere. Processen kan så, hvis nødvendigt føde en automatiseret opgave i opgaveindbakken i DKC. DKC betragtes som den manuelle holdeplads for opgaven, det er her kunderådgiveren sidder og arbejder, som udgangspunkt. Vi tænker, at det i virkeligheden er fagsystemet, som kender forretningsreglerne og som fortygger alle henvendelser. Det vi forventer, er at vi får en blanket ind, og så ser fagsystemet, om betingelserne er opfyldt for, at du kan få dine penge, og så får du pengene. Hvis de ikke er opfyldt, så er der nogle, som skal kigge på det, derved dannes en opgave i DKC, derved er det er en meget simpel proces i DKC. Fagsystemet siger: det her kan jeg ikke finde ud af, hjælp mig.