Kravredaktionsmøde den 25. juni 2018 Tidspunkt: 25. juni 2018 kl

Transkript

1 Kravredaktionsmøde den 25. juni 2018 Tidspunkt: 25. juni 2018 kl Mødested: Mødelokale 8 på Rådhuset, Rådhustorvet 4, Horsens Mødedeltagere: Peter, Thomas, Carsten, Henrik, Rasmus og Brian Afbud: Heidi, Martin Referent: Rasmus Ankomst og velkomst, Vi skal lige ankomme og finde os til rette. Dagsordenpunkt 1 [10 min] Status Brugere og testbrugere, økonomi, OS2kravmotor i hverdagen etc. Der er 19 tilsluttede kommuner og en solid organisering. Der opleves dog en lettere stagnering i tilslutning til løsningen. Økonomien følger planen men kravredaktionen får forventeligt flere midler da styregruppen drøfter en omlægning af budget så der kan indkøbes mere konsulenthjælp. Dagsordenpunkt 2 [15 min] Bedre onboarding og udnyttelse af prøveadgang Hvad bør være en del af onboarding for at vi sikre nye anvendere kommer i gang med at bruge Kravmotoren? I dag er man umiddelbart meget overladt til sig selv. Hvordan kan vi hjælpe kommuner med prøveadgang til at få mest muligt ud af testen. Vi vil gerne have de tilslutter sig efterfølgende. Ovenstående drøftelserne forventes at afføde indstilling til styregruppen. Emnet drøftes bredt og afføder en række forslag Bedre forankring af kravredaktion, f.eks. i KL eller KOMBIT. KOMBIT opretter krav. Der skal være nogen dedikeret til at lave arbejdet (økonomi). Få fuld opbakning internt.

2 Fortælle de gode historier. Her hjælper OS2-sekretariatet. Mange sidder tilbage og siger, fortæl os hvad vi skal gøre for at komme i gang. Vi skal kunne tilbyde starthjælp. o Intro-møder o Har vi fat i de rigtige mennesker? o Bede nogen om at tilbyde en pakke som hjælper kommuner i gang. Det er en kompleks størrelse. Kravredaktionen vil gerne involveres. o Det er ikke et svært værktøj. Det er det organisatoriske som er svært. De skal have hjælp til arbejdsprocessen. o En konsulent skal samle op og vedligeholde case-beskrivelser og skal kunne tilbyde onboarding hjælp. o Det skal opbygges omkring en case En pilot-kommune Tydelig forventningsafstemning. Hvad kræver det af en kommune at bruge kravmotoren. En bedre onboarding kræver ressourcer. Er styregruppen interesseret i at dedikere ressourcer til at benarbejdet kan udføres så vi kan lave oplæg til en konsulent der kan udarbejde bedre onboarding. Dagsordenpunkt 3 [10 min] Status på punkt 6 fra sidste møde Konsulentbistand. Beslutning Styregruppen har afsat kr. om året til konsulentydelser se budget. Brian er tilknyttet i 2018 som både kravkonsulent og leverandør af ny funktionalitet. Fra 2019 skal der være to forskellige leverandører på disse to ydelser. Vi skal komme med et bud på, hvem der kan tage over fra Se punkt 6: Referat fra sidste møde: Inden drøftelsen bedes leverandøren forlade lokalet. Leverandøren kommer med følgende input inden lokalet forlades. Leverandøren støtter op omkring at der findes en anden konsulent/leverandør så nuværende leverandør ikke sidder med dobbeltrollen i fremtiden. I 2018 er det rigtig godt at have leverandøren som står for funktionalitet dybt involveret. Kravredaktionen vil fra 1/ sikre at der er tilknyttet en ekstern konsulent. Enten en alternativ leverandør til funktionaliteten og nuværende som kravkonsulent. Eller en alternativ kravkonsulent. Kravredaktionen vil komme med en indstilling tids nok så styregruppen kan forholde sig til den. Inden næste møde byder medlemmer af kravredaktionen ind med input til type og/eller et navn. Kravredaktionen drøfter videre på næste møde. Kravredaktionen ønsker at kunne trække på nogen som er tæt på et udviklerhus. Drøftelser går efterfølgende over i hvordan er det styregruppen ønsker den fremtidige organisering skal være. Hvilken

3 model ønsker vi at arbejde med. Skal vi sigte mod at produktet har et dedikeret sekretariat. Over tid opstår der et behov for et mere etableret sekretariat. Dette spørgsmål ønsker kravredaktionen at sende videre til styregruppen. Mulige konsulent: Kenni, Konnect APS: og/eller Optimum IT: Kravredaktionen har ikke nogen specielle præferencer. Dagsordenpunkt 4 [5 min] Fremtidigt samarbejde med Digitaliseringsstyrelsen, afholdelse af kaffemøde (beslutning) Baggrund: Digitaliseringsstyrelsen har vist interesse for OS2kravmotor gennem deltagelse i præsentation i KL-huset, januar 2018 og invitation til at præsentere komponenten på FDA-konferencen i april Samtidig ses det, hvordan kommunernes arbejde med den fælleskommunale rammearkitektur er en tydelig inspirationskilde til Statens arbejde med fællesoffentlige tiltag på arkitekturområdet. På den baggrund er det naturligt at tage en indledende dialog om samarbejdsmulighederne. Indstilling: Kravredaktionen billiger, at Styregruppen inviterer Digitaliseringsstyrelsen til et kaffemøde (Skype) efter sommerferien med deltagelse af to fra Styregruppen og to fra Kravredaktionen. Her tages temperaturen på interessen fra styrelsen. Kravredaktionen godkender og indstillingen sendes til styregruppen. Digst. bør have en demo adgang. Brian gør opmærksom på at der er en praktisk udfordring med login da de ikke kører ADFS. Dagsordenpunkt 5 [5 min] KOMBIT tilbydes plads i Kravredaktionen (beslutning) Baggrund: KOMBIT har ved to lejligheder ytret interesse for at deltage i arbejdet med at udarbejde tværkommunale krav. De har tunge kompentancer og stor erfaring indenfor kravsstillelse og markedsdialog og vil således kunne bidrage til arbejdet i Kravredaktionen under forudsætning af, at der er enighed om rammer og betingelser for samarbejdet. Indstilling: Kravredaktionen indstiller til styregruppen, at KOMBIT tilbydes en plads i Kravredaktionen. Dette sker i form af en mailinvitation sendt til formanden for styregruppen i Videncentret. KOMBITs deltagelse i Kravredaktionen sker på samme vilkår som de øvrige deltagere. Deres deltagelse indledes ved første møde med en dialog og forventningsafstemning, der skal sikre et klart udgangspunkt.

4 Kravredaktionen godkender og indstillingen sendes til styregruppen. KOMBIT oprettes som en kommune og kan oprette lokale krav som de kan anmode om at ophøje. Samme proces som for alle andre. Dagsordenpunkt 6 [5 min] Modtage krav fra Open Data DK (beslutning) Open data Dk har henvendt sig og spurgt om kravmotor indeholder krav omkring åbne data. De tilbyder at udarbejde et krav såfremt kravredaktionen vurdere dette kan bruges og kan give værdi. Vi har en interesse i at dele data og alle bidrag til bedre krav i kravmotoren er velkommen. Der mangler et krav om at i det omfang data er åbne bør de leveres som åbne data. Det besluttes at vi ønsker at supplere de krav vi har, Brian finder de krav vi har. Rasmus sender til Open Data og beder dem supplere. Dagsordenpunkt 7 [60 min] Ændringer i eksisterende fælleskommunale krav (beslutning) a) # Krav svartider Løsningens brugergrænseflade skal være responsiv og understøtte brugernes arbejde uden unødig ventetid. Leverandøren skal, i forbindelse med afgivelse af tilbud, angive forventede svartider i løsningens brugergrænseflade, angivet som: gennemsnitssvartider for simple operationer (almindelig navigation i brugergrænsefladen) gennemsnitssvartider for komplekse operationer (fx større/komplekse søgninger, hentning af store mængde data, osv). Referat til a): Ændringen godkendes men der er behov for at kunne benytte parametre til et krav som dette. Der er behov for [placeholders] så man som kravstiller udfylder forventninger. Eller varianter af krav. Løses evt. af opgaven med lokale udvidelser til krav, Krav skal genbehandles når ny funktionalitet er udarbejdet. b) # Krav oppetid Løsningen skal være tilgængelig for brugernes anvendelse i den primære driftstid. Den primære driftstid er 6-18 for løsninger der anvendes i normal kontortid, og 24/7 for løsninger der altid er i anvendelse. Leverandøren skal, i forbindelse med afgivelse af tilbud, medsende dokumentation på den oppetid der tilbydes på løsningen, målt på månedsbasis. Oppetiden kan angives som en procentsats (fx 99,9% oppetid), eller som en samlet maksimal

5 Referat til b): nedetid over en kalendermåned (fx 3 timer og 20 minutter). Korrekt varslede servicevinduer tæller i den sammenhæng ikke som nedetid. Ændringen godkendes men her er samme problemstilling som for punkt a. c) # Krav servicevinduer Leverandøren skal, i forbindelse med afgivelse af tilbud, medsende dokumentation på de SLA niveauer som tilbydes, herunder beskrivelse af processer for softwareopdateringer, serveropdateringer, databaseopdateringer m.m. i forbindelse med servicevinduer Leverandøren skal, for hvert tilbudt SLA niveau, angive som minimum følgende oplysninger maksimalt antal servicevinduer indefor en given kalenderperiode omfang af servicevinduet, herunder beskrivelse af maksimal nedetid varslingsperiode for servicevinduer Referat til c): Ændringen godkendes men her er samme problemstilling som a og b. d) # Krav Dokumentation af løsningen Leverandøren skal, i forbindelse med afgivelse af tilbud, medsende dokumentation på løsningen, der dækker nedenstående områder i det omfang det giver meningen for løsningen Arkitekturbeskrivelse af Løsningen Driftshåndbog der dækker de områder der involverer Kommunen Brugermanuel til løsningen Teknisk dokumentation af udstillede snitflader Dokumentation af den rolle/rettighedsmodel der anvendes af Løsningen, herunder roller og rollebeskrivelse Dokumentationen vil indgå i en samlet vurdering af løsningen Referat til d): Godkendes i ovenstående formulering. Det med ArkiMate håndteres andre steder. Brian bedes udarbejde et bilag til kravet. e) # Krav 188 kravet bør begrundes, så leverandører og kommune kan få en bedre, så leverandører og kommune kan få en bedre dialog om emnet. Det kan evt. ske via eksempler på manglende anvendelse af standarder Referat til e): Dækkes ind af den gennemgang af alle krav som Carsten og Heidi har gang i. f) Forslag (Brian) til krav hvor bilag tilknyttes: NSIS 3 krav (skal ophøjes først) - Databehandler - Login og rettighedsstyring via rammearkitekturen -

6 Referat til e): Alle vores GDPR krav (samme bilag kan muligvis uploades på disse)... muligvis også krav til lokale server, desktop, database, mobilplatforme, osv (omend det kan være svært at have en fælles udgave) Bemærk at bilag ikke er krav, men er supplerende information til leverandøren. Det betyder også at vi ønsker følgende for de udarbejdede bilag Målgruppen er leverandøren, ikke egne/interne folk Formålet med bilaget er at hjælpe leverandøren til at forstå (og implementere) kravet - dvs bilaget er ikke som sådan kravmateriale Bilaget skal være kommune-uafhængigt, dvs ingen logoer eller referencer til interne kommune-specifikke setups NSIS 3 Kravet (ID 340) godkendes bilag godkendes og vedhæftes krav. Krav 340 skal sendes via KL (Dan Bjørnebo). Databehandler, ID 232. KLs standardaftale vedhæftes. Note, husk at lokale udvidelser også skal indeholde lokale bilag. Login og rettighedsstyring ID 171. Bilag fra Viborg kommune skal vedhæftes. Bilaget skal rundsendes til kravredaktionen. Alle GDPR-krav: Skal drøftes på næste møde krav fra DIGIT og staten. Disse bilag skal skaffes til næste gang. Vi mangler GDPR bilaget :) Muligvis også krav til lokale server osv Denne bliver løst af opgaven Lokale Udvidelser. Brian bedes lave et lille notat som forklarer hvad kendetegner det gode bilag og hvad kendetegner det krav som skal have et bilag. g) Heidi og Carsten har gennemgået de fælleskommunale krav og foreslår en lang række ændringer se bilag Referat til g): Krav 171 og alle andre Løsningen skal skrives med lille alle steder så vi ikke benytter kontraktsprog. Det skal konsekvensrettes i alle krav. Krav 175 Retningslinjer DT-STÆRK-KRYPTO skal uploades som bilag. Rasmus kontakter Datatilsynet for at høre hvad vi skal referere til.

7 Krav 177 og 178 arbejdes sammen inkl. teksten fra den gamle IT-sikkerhedsbekendtgørelse. Carsten udfører. I Krav 179 indarbejdes tekst fra den gamle IT-sikkerhedsbekendtgørelse. Carsten gør det. Krav 177, 178 og 179 skal forbi KL til GDPR-sparring. Ordet Kommunen konsekvensrettes med stort K. Carsten udfører. GDPR, Persondataloven mv. konsekvensrettes til Databeskyttelsesloven. Carsten udfører. Krav 184. herunder men ikke begrænset til alle registreringer om parter i systemet. slettes. Forretningsdata erstattes med data. Carsten udfører Dagsordenpunkt 8 [10 min] Ny filter (beslutning) Overskrift: Bruges løsningen til sagsbehandling? Tekst: Skal løsningen anvendes til at udføre egentlig sagsbehandling, og dermed generere sagsjournaler, dokumenter og/eller ydelser? Krav der kan dækkes ind under dette filter Integration med Digital Post - Journalisering af mails fra outlook/exchange - Løsning skal tillade automatisering via RPA værktøjer - Integration til ESDH system - (skal ophøjes først) Filtret tilføjes ikke. Dagsordenpunkt 9 [20 min] Anmodninger om nye fælleskommunale krav (beslutning) Der er anmodet om 5 nye fælleskommunale krav- 4 forslag til nye krav godkendt (Kravene 340, 341, 342 og 344), 1 afslået (Krav 292). Krav 340 og 342 sendes forbi KL til GDPR-sparring.

8 Dagsordenpunkt 10 [10 min] Ide til nyt fælleskommunalt krav (drøftelse) Horsens ønsker drøftelse af et muligt nyt krav, som vil kunne give noget automatisering ift. sletning af sager i fagsystemer - Horsens opfordres til at foreslå en formulering af et krav. Herefter vil Kravredaktionen behandle forslaget. Dagsordenpunkt 11 [30 min] GDPR-krav (orientering og drøftelse) KOMBITs sikkerhedskrav hængeparti fra redaktionsmøde i marts. Se Brians slides side 20 Tekst om Kravredaktionens arbejde er tilføjet - Henrik har lavet aftale med Dan Bjørneboe om faglig-juridisk sparring hos KL omkring GDPR-krav og hovedgreb (se tekst ovenfor) (Se bilag) KOMBITs sikkerhedskrav behandles efter udvidelse af Kravredaktionen. Øvrigt taget til efterretning. Dagsordenpunkt 12 [15 min] Vidensbank med funktionelle krav (drøftelse) Horsens foreslår en fælles drøftelse af, hvordan der kan laves en vidensbank med funktionelle krav Det undersøges hvorvidt ønsket om en vidensbank med funktionelle krav fortsat er tilstede. Hvis det kan bekræftes, bestilles oplæg til ny funktionalitet som ny story i backloggen hos løsningens leverandør. Dagsordenpunkt 13 [15 min] Anvendelse af KLs domænemodel (drøftelse)

9 KLs kontor for it-arkitektur og arbejdsgange har udarbejdet en såkaldt Domænemodel (se bilag). Den forventes anvendt bredt, og spørgsmålet er, om vi kan erstatte vores hjemmelavede domænemodel med KLs. Der medtages et punkt med drøftelse omkring det hensigtsmæssige i at have en domæne-filtrering på senere møde. Dagsordenpunkt 14 Evt. Ingen punkter behandlet