Udbud: Spørgsmål og svar om Indberetningsplatform

Prækvalifikation

Spørgsmål: ”Er det så korrekt forstået, at det er ansøgning om deltagelse i udbuddet (5 referencer samt ESPD i 3 papireksemplarer og i 1 elektronisk version) der skal afleveres inden den 01-08-2017 kl. 10:00”.

Svar: Ja.

Spørgsmål: ”Kan man tilgå selve tilbuddet (besvarelsen af udbuddet), som kan hentes på http://www2.sdfe.dk/udbud/?”

Svar: Nej. Udbudsmaterialerne, kravspecifikation, kontrakt med flere er allerede nu tilgængelige på  http://www2.sdfe.dk/udbud/ som det kræves jf. Udbudsloven.

Spørgsmål: ” Vil SDFE afholde en prækvalifikationsrunde i august, hvor SDFE udvælger op til tre tilbudsgivere. Skal tilbudsgiverne derefter aflevere det egentlige tilbud med tidsplan, løsningsbeskrivelser, priser m.v.?”

Svar: Ja, det er korrekt forstået.

Spørgsmål: Rådgiver/leverandøransvarsbegrænsningen bedes venligst oplyst

Svar: ”Det følger af kontraktens punkt 29, at:

Parterne er erstatningspligtige efter dansk rets almindelige regler.

For forhold, der udløser betaling af bod eller forholdsmæssigt afslag, kan erstatning kun kræves i det omfang, Kunden dokumenterer et tab ud over bodsbeløbet eller det forholdsmæssige afslag. Erstatning og eventuelt bodsbeløb eller forholdsmæssige afslag tilsammen er dog under alle omstændigheder begrænset til leverancevederlaget.

Såfremt en uvildig sagkyndig ved audit, jf. punkt 17, har truffet afgørelse om, at en Parts manglende opfyldelse af kravene til indsigt, jf. punkt 10, har haft betydning for Partens væsentlige misligholdelse af Kontrakten, forhøjes maksimum for den samlede erstatning og bod eller reduktion af vederlag med 15%.  

Parterne er ikke i noget tilfælde ansvarlig for driftstab, følgeskader eller andet indirekte tab. Følgeskader og indirekte tab anses bl.a. ikke at omfatte Kundens omkostninger til Standardprogrammel efter en delvis ophævelse, såfremt disse omkostninger ligger ud over nødvendige omkostninger forbundet med Kundens brug af Delleverancer, som ikke er omfattet af ophævelsen. Tab af data anses for indirekte tab, bortset fra tilfælde hvor dette skyldes Leverandørens applikationsdrift eller anden datahåndtering, hvor dette er omfattet af Kontrakten.

Foranstående begrænsninger gælder kun, såfremt tabet ikke kan henføres til grov uagtsomhed eller forsætlige forhold hos den skadevoldende Part.

Leverandøren har et produktansvar for produkter, der er leveret eller produceret af Leverandøren. Leverandøren er forpligtet til at opretholde produktansvarsforsikring fra indgåelsen af Kontrakten og indtil fem år efter Overtagelse af den sidste Delleverance. Produktansvaret for tingskade er beløbsmæssigt begrænset til kr. 5 millioner pr. skadestilfælde.

For de dele af Leverancen, for hvilke der skal leveres Løbende Ydelser, opretholdes produktansvarsforsikringen i hele vedligeholdelses- og driftsperioden.

Kontrakten indeholder således en sædvanlig erstatningsmaksimeringsregulering, idet ordregiver skal henvise til Kontraktens punkt 31 vedr. kravene til skadesløsholdelse for eventuelle krænkelser af tredjemands rettigheder.”

Spørgsmål: Bilag 3c er tilsyneladende ikke i materialet?

Svar: Korrekt, der er desværre sket en teknisk fejl. Bilaget er tilgængeligt separat på udbudshjemmesiden: http://www2.sdfe.dk/udbud/ 

Spørgsmål: Vil det være tilladt at vedlægge et læsevenligt dokument med tekst, der er en-til-en identisk med teksten i ESPD-dokumentet?

Svar: ”Tilbudsgivere må ikke vedlægge bilag til ESPD’et, herunder word-dokumenter med angivelse af referencer.
 
Konkurrence- og Forbrugerstyrelsen har i forbindelse med www.bedreudbud.dk udtalt, at en ordregiver ikke må kræve, at ansøgerne eller tilbudsgiverne vedlægger bilag i forbindelse med ESPD. Ordregiver ligger således, i overensstemmelse med udbudsbekendtgørelsen, alene vægt på de referencer, som er angivet i ESPD’et.”

Spørgsmål: Der synes at være uoverensstemmelse mellem angivelserne i bilag 14 pkt.6 og bilag 1 figur 1?

Svar: Figur 1 i bilag 1 er tilpasset således at indholdet stemmer overens med angivelsen i bilag 14 pkt.6. Desuden er angivelserne af delleverancernes forventede perioder for gennemførelse, præciseret i bilag 3ai, i overensstemmelse med bilag 1 og bilag 14. De reviderede bilag (1 og 3ai) kan hentes fra udbudssiden (http://sdfe.dk/om-os/udbud-tenders/)

Spørgsmål: Tilbudsgiver gør opmærksom på, at der I bilag 14a er en formelfejl i Samlet evalueringsteknisk pris inkl. tillæg for krav til Kundens IT miljø, der gør at Samlet evalueringsteknisk pris reelt tælles med 2 gange.

Svar: Det er korrekt. Revideret bilag 14a er gjort tilgængeligt.

Spørgsmål: Integration til styrelsens ESDH-system (KMD WorkZone) er beskrevet som tilhørende Delleverance 3 i afsnit 5 i bilag 3ai, samt i kravnr. 1.9 i bilag 3aii.

Samtidigt er det i afsnit 4.2 i bilag 3ai beskrevet, at Grundscenarie/Grundflow indeholder "Automatisk Journalisering af indberetning i ESDH-system med relevant status (Initial)" og at dette grundflow leveres med Delleverance 1 (Figur 3 i bilag 3ai).
Derudover beskrives det for kravnr. 4.6 i bilag 3ai at advisering skal journaliseres i SDFE’s ESDH-system og at kravnr. 4.6 skal leveres med Delleverance 1.

Skal al integration til SDFEs ESDH-system leveres med Delleverance 3 eller er der undtagelser herfor, hvorfor en initiel integration til ESDH-systemet allerede skal leveres med Delleverance 1?

Svar: Selve integrationen forventes leveret med Delleverance 3, men som det fremgår af materialet og som nævnt på orienteringsmødet er placeringen af kravene i delleverancer, ordregivers oplæg baseret på de forretningsmæssige behov der skal indfries. Tilbudsgiver må således godt foreslå den fulde implementering af ESDH integrationen foretaget tidligere end delleverance 3.

Der fremgår følgende af den indledende tekst omkring scenarier og flows i bilag 3.ai: ” Dog skal det bemærkes at fuld anvendelse af journalisering i styrelsens ESDH system først forventes fra delleverance 3”. Indberetningsplatformen skal således forberedes til at integrationen kan implementeres i delleverance 3, herunder at allerede opsamlede indberetninger kan journaliseres til ESDH systemet.

Spørgsmål: Kan tilbudsgiver vælge at vedlægge et appendiks til bilag 3bii med figurer og billeder, som tilbudsgiver kan henvise til i kravbesvarelserne skrevet i bilag 3bii?

Svar: Ja.

Spørgsmål: I bilag 3 står beskrevet at "Tilbudsgiver har, baseret på indholdet af Behovsopgørelsen (Bilag 3a), udarbejdet ... en kvalitativ besvarelse af Kundens krav (Bilag 3b.ii) og har heri udarbejdet en risikolog for Projektet …"

I bilag 3bii står beskrevet at "Dette bilag indeholder Tilbudsgivers overordnede beskrivelse af, hvorledes Leverandøren vil opfylde Kundens behovsopgørelse. Tilbudsgivers Overordnede Løsningsbeskrivelse indeholder risikologgen."

Er det korrekt forstået, at den efterspurgte risikolog kan udgøres af tilbudsgivers beskrivelse af eventuelle identificerede risici i de individuelle kravbesvarelser for de individuelle kravnumre i bilag 3bii?

Svar: Ja.

Spørgsmål: I kravnr. 1.20 i bilag 3aii beskrives det, at Indberetningsplatformen skal kunne håndtere referencer til specifikke og unikke objekter, som f.eks. bygninger eller beregninger af afstande. Ydermere beskrives det i kravnr. 2.10 i bilag 3aii, at det skal være muligt at udpege objekter på et kort, der resulterer i, at der udfyldes referencer i en indberetning.

Tilbudsgiver formoder, at med "referencer til objekter" menes det ”Objekt ID” i Indberetningsdata der identificerer det specifikke objekt som indberetningen drejer sig om og som beskrives i bilag 3c. Dette Objekt ID er ikke markeret som et "Beregnet Felt" i bilag 3c.

Er det rigtigt forstået, at ordregiver forventer at feltet Objekt ID på Indberetningsdata udfyldes med en reference til en eksisterende objekt identifikator, der er dannet og findes i et andet eksternt fagsystem? Og at Indberetningens Objekt ID dermed ikke bliver dannet i Indberetningsplatformen.

Svar: Ja.

 

Spørgsmål: Kan SDFE redegøre for sammenhængen mellem de datoer der er om talt i krav #4 og vist i Figur 1:Stjernekort (begge i bilag 1 Tidsplan) samt forventninger til overtagelses- og driftsprøvers forventede eller ønskede længde?

Svar: Idriftsættelse, som omtalt i bilag 1 K-4 skal forstås som det tidspunkt hvor driftsprøven kan begynde. Da SDFE, som det fremgår af K-14, ikke er tilgængelige omkring påske, forventes overtagelsesprøven at være afsluttet inden påskeugen, dvs. fredag d.23.marts 2018. Driftsprøven forventes påbegyndt kort efter påske, og afsluttet med udgangen af april 2018, således at integrationstest med SKM kan foretages i perioden maj/juni 2018.

 

Spørgsmål: Bilag 3a.i, Afsnit 4.3: Kan der gives nogle eksempler på hvilke typer valideringsdata som kan komme i spil i relation til de beskrevne scenarier?

Svar: Vi antager der menes afsnit 4.2. Der kan være tale omvalideringer af attributter, geometri, refererede objekter og kombinationer heraf. Og valideringerne kan være i forhold til andre eksisterende indberetninger eller øvrige data. Se også bilag 3a.ii krav 7.1.

 

Spørgsmål: Bilag 3a.i, side 7, afsnit 3: Hvordan forventes systemet at kunne afrapportere samt at understøtte kvalitetsforbedringer og kontrolaktiviteter?

Svar: Understøttelsen ligger i, at modtagne indberetninger i høj grad vil være grundlag for at kunne højne kvaliteten af data. Ligeledes kan indberetninger give værdifuldt input til hvor kontrolaktiviteter eventuelt skal styrkes. Rapporteringen kan fx være i relation til oversigter og statistik ift. fremdrift, indberetningstyper, geografiske områder mv. Se også beskrivelserne af rollerne ’kontrollør’ og ’formidler’ i bilag 3a.i afsnit 4.1, samt bilag 3a.ii krav 2.19, 2.20, 6.4, 6.5

 

Spørgsmål: Bilag 3a.i, side 10, punkt 3: Hvad menes med ”understøttelse og ageren i forhold til geografisk validering i det nuværende landskab”?

Svar: Der er tale om punkt 4, hvis ordlyd er: I SDFE’s nuværende løsningslandskab foretages relevant central (geografisk) validering med henblik på at sikre datakvalitet. Understøttelse af disse valideringer samt ageren i forhold til dem, vil være væsentligt for indberetningsplatformen i forhold til bl.a. dataudveksling og status håndtering.”

Formuleringen kan ses i relation til de efterfølgende punkter i listen, samt kravene til valideringskomponenten (bilag 3a.ii afsnit 7). ’Understøttelsen’ af disse centrale valideringer ligger i at valideringskomponenten skal kunne validere ved hjælp af valideringer der defineres og vedligeholdes eksternt i forhold til komponenten (jf. også bilag 3a.ii krav 7.6 og 7.7). ’Ageren’ i forhold til disse centrale valideringer kunne fx være at valideringsresultaterne kan vises i indberetningsplatformens brugergrænseflade, som et datalag (jf. også bilag 3a.ii krav 1.31), eller at de anvendes i forbindelse med udledning af hændelseshistorik for de objekter indberetningerne refererer til (jf. også bilag 3a.ii krav 6.6).

 

Spørgsmål: Bilag 3a.i, side 10, punkt 6: Hvilke eksterne valideringsregler kunne komme i spil her?

Svar: Det kunne være valideringer af attribut- eller geometrimæssig karakter, eller kombinationer heraf, også på tværs af registre. Og da styrelsen allerede foretager en lang række valideringer centralt, kan det være hensigtsmæssigt ikke at skulle opbygge og vedligeholde disse flere steder.

 

Spørgsmål: Bilag 3a.i, side 71: Kan tilbudsgiver modtage en beskrivelse af disse standardiserede integrationssnitflader?

Svar: Tanken er at det er Indberetningsplatformen der er det samlende punkt og udstiller services/integrationsflader, således at fagsystemer kan udbygges til at integrere direkte med platformen.

 

Spørgsmål: Bilag 3a.ii, krav 1.12: Hvordan tolkes dette da der for komponenten ingen krav er defineret til DL1?

Svar: Grunddelen af adviseringskomponenten forventes udviklet som del af delleverance 1 (jf. bilag 3a.i afsnit 5.1), men i det omfang advisering om statusskift til indberetter bygger på de øvrige stillede krav til adviseringskomponenten (bilag 3a.ii afsnit 5) kan implementeringen af krav 1.12 ske i en anden delleverance end indikeret. Som angivet i bilag 3a.ii er der ift. kravenes placering i delleverance tale om ordregivers forventning. Som det også blev fremhævet på orienteringsmødet kan tilbudsgiver komme med forslag til en alternativ placering af kravene i delleverancerne, under iagttagelse af at de forretningsmæssige mål opnås som angivet.

 

Spørgsmål: Bilag 3a.ii, krav 1.19: Formulering af kravet er ikke forstået – kan dette reformuleres?

Svar: Platformen skal kunne understøtte forskellige forretningsområder og behov. Og for at kunne understøtte modtagelse og behandling af indberetninger fra fx SKM, myndigheder og borgere kan der være behov for en opdeling, med flere brugergrænseflader for oprettelse af indberetninger, men også forskellige brugergrænseflader der understøtter at behandlingen af forskellige typer indberetninger kan være forskellig.

Fx vil en brugergrænseflade til crowdsourcing antageligt skulle se anderledes ud end en til interne indberetninger og der kan være forskel på de data der opsamles og processerne i behandlingen kan være så forskellige, at der skal anvendes forskellige brugergrænseflader.

Kravet skal ses i relation til krav 2.16 om funktionsdedikerede brugergrænseflader og handler i høj grad om at indberetningsplatformen skal være samlende for styrelsens arbejde med indberetninger i et bredt perspektiv, men at der skal kunne ske en tilstrækkelig opdeling til at forskellige forretningsområder kan understøttes på en måde der passer til områdets behov, fremfor at Indberetningsplatformen kun understøtter én måde at modtage og behandle indberetninger på.

Denne opdeling skal kunne ske både ift. forskellige typer af indberetninger/opgaver, ift. hvordan data vises og opsamles (både når indberetninger skal oprettes og behandles), og ift. hvilke procestrin der er, hvilke regler der er for data og hvilken interaktion der tilbydes. Det er altså ikke kun opdeling i separate brugergrænseflader, men også den bagvedliggende funktionalitet/understøttelse.

 

Spørgsmål: Bilag 3a.ii, krav 2.20: Hvordan skal arbejdsgangen omkring en Fagvurdering tolkes?

Svar: Når en indberetning er visiteret til en fagspecialist vil vedkommende tilgå Indberetningsplatformen, og med udgangspunkt i de informationer der vises, vurdere indberetningen og eventuelt foretage en fagajourføring i det rette fagsystem. Herefter vil fagspecialisten påføre indberetningen information om resultatet af den foretagne vurdering og mulige ajourføring. Se også bilag 3a.i side 71-72 omkring fagvurdering. Der er her i høj grad tale om processer der ønskes automatiseret/integreret.

Ift. kvalitetskontrol vil det fx være relevant at se på i hvilket omfang fagvurderingerne giver sig udslag i ajourføring og om der er forskelle relateret til geografi, domæne, fagspecialist mv.

 

Spørgsmål: Bilag 3a.ii, krav 4.7: Hvordan opstår en manglende validering og hvordan tænkes den efterfølgende arbejdsgang?

Svar: Det kunne fx være at der er modtaget et antal indberetninger med forslag til ændringer af attribut værdier, men de foreslåede attributværdier fejler validering, da de ikke er gyldige værdier for det pågældende datasæt. Indberetningsbehandleren vurderer imidlertid at de modtagne indberetninger indeholder værdifulde informationer og bør behandles af fagspecialister, og vedkommende fremsøger de berørte indberetninger og overstyrer valideringen, således at indberetningerne kan visiteres.

 

Spørgsmål: Bilag 3a.ii, krav 5.1: Hvad menes med sikker advisering?

Svar: Sikker advisering skal forstås i relation til krav 5.6. Og som der står i indledningen til afsnit 5 i bilag 3a.ii 'Med sikker leverance tænkes på evnen til at notificere uden at transportere personhenførbare data eller anden unødig information på usikker vis'. Fx er det vigtigt at sikkerheden omkring personhenførbare data, som er indberettet, ikke kompromitteres ved advisering om disse indberetninger.

 

Spørgsmål: Bilag 3a.ii, krav 8.1: Skal der være flere versioner(historiske) af en indberetning?

Svar: Der skal være fuld sporbarhed, i en let tilgængelig form, af alle ændringer på en indberetning (herunder statusskift og øvrige ændringer eller tilføjelser af information)

 

Spørgsmål: Bilag 3a.ii, krav 9.11: Hvad menes med dette krav?

Svar: Se svaret omkring krav 8.1 ovenfor.

 

Spørgsmål: Vil SDFE overveje at forlænge afleveringsfristen?

Svar: SDFE har forståelse for baggrunden for spørgsmålet, men ønsker, henset til projektets tidsplan, ikke at forlænge afleveringsfristen.

 

Spørgsmål: Bilag 1 – Tidsplan – havde tidligere karakter af Forhandlingskrav og omfattede også mindste krav og evalueringskrav. Skal de i krav K4 anført leverancetider samt datoer i det viste stjernekort forstås som ufravigelige datoer eller repræsenterer disse SDFE’s ønsker som leverandøren kan forholde sig til og ændre om nødvendigt?

Svar: SDFE kræver, at krav K4 skal overholdes og opfyldes. Datoerne og tidspunkterne er derfor ufravigelige.

 

Spørgsmål: Hvorledes tænkes Driftsprøven for Delleverance 1 gennemført når SKM ikke er i operativ drift når den skal gennemføres?

Svar: Driftsprøven for delleverance 1 tænkes gennemført som forberedelse til integrationstesten og som test af Indberetningsplatformens stabilitet og robusthed, blandt andet ved løbende modtagelse af testdata, som også tænkes anvendt ved overtagelsesprøven. Altså ved at Leverandøren selv agerer simpelt eksternt system, der oversender test indberetninger.

 

Spørgsmål: Krav 4.1 Ang. ”Central opdatering” refereres der til brugergrænsefladen og/eller backend?

Svar: SDFE mener i første omgang ”Visiteringskomponenten”. Data opdateringerne skal kunne vises til slutbrugeren af komponenten fx SDFE Løsningsadministrator. Eftersom Visiteringskomponenten er service enabled (som alle andre komponenter i Indberetningsplatformen), da skal grafiske brugergrænseflader også kunne modtage data om ændringerne i proces, regler, organisation og navne. Et eksempel kunne være, at en regel for journalisering skal ændres og at brugerne skal oplyses om den ændrede regel/praksis; dette vil være en ændring i såvel backend som brugergrænseflade.

 

Spørgsmål: Krav 8.8: Henviser ”visuel dokumentation” til en grafisk præsentation af tilknyttede dokumenter til en indberetning e.g. pdf, regneark, shape filer?

Svar: Nej. Kravet går på en brugergrænseflade til at kunne redigere og dokumentere (fx visuelt eller ved print) datamodellen for indberetninger.

 

Spørgsmål: Krav 9.11: Vil ordregiver uddybe krav 9.11, og give eksempler på hvad der menes med evaluerings- og ajourføringsstatus i relation til Indberetningsplatformen?

Svar: SDFE’s ønsker at evalueringsdata (Visiteringsdata) fra visiteringen skal logges og være tilgængelig. Ligeledes, når en indberetning har ført til en ajourføring, så skal data om dette logges, og være tilgængelig.

Eksempel: Indberetning fra SKM indeholder fejl og bliver visiteret og afvist. Data om dette skal logges.

Eksempel: Indberetning fra SKM visiteres og vurderes at kunne fagajourføres af et bestemt kontor i SDFE, hvortil indberetningen visiteres til det specifikke kontor. Data om dette logges.

Eksempel: Fagspecialist får tildelt indberetning efter denne er blevet visiteret af Indberetningsbehandler. Fagspecialisten ajourfører kildedata (håndbåret) i et fagsystem, og skriver en kort note om dette i den grafiske brugergrænseflade i Indberetningsplatformen. Disse data skal logges.

 

Spørgsmål: Krav 9.13: Hvad mener ordregiver med hhv. central og decentral validering i krav 9.13, og menes specielt med sidste punkt ”Centrale valideringskomponenter i SDFE”?

Svar: Kravet skal ses i relation til kravene 7.6 og 7.7 om enkeltfaset og flerfaset validering, hvor valideringsregler kan være defineret og vedligeholdt internt (centralt) eller eksternt (decentralt), og hvor decentralt også kan være i valideringskomponenter i SDFE generelt (dvs. udenfor Indberetningsplatformen). Disse tænkes pt. at være 1Integrate og FME.

 

Spørgsmål: Krav 9.15: Vil ordregiver generelt uddybe krav 9.15, gerne med eksempler. Vil ordregiver desuden redegøre for hvad der menes med begreberne ”problemkoder” og ”decentrale kildedatasystemer”?

Svar: Det kravet grundlæggende skal understøtte er, som det fremgår til slut i kravet, at kunne registrere: "Hvem har gjort hvad, på hvilke objekter og i forhold til hvilken Indberetning". Hvis der fx allerede er ageret på en tidligere indberetning om et objekt med et givet objekt-id kunne man forestille sig at forespørge (foretage dataekstraktion) på det pågældende objekt i det relevante forvaltningssystem (kildedatasystem), således at informationer om det opdaterede objekt kunne tilknyttes indberetningen, for at informere afsenderen om objektets nuværende karakteristika og den ændring der allerede er foretaget (Indberetningsplatformens hændelses-historik komponent må antages også at have visse informationer herom). I praksis vil forespørgslen ske mod SDFEs datavarehus (Geodatabanken), men på lang sigt kunne Indberetningsplatformen integrere mere direkte med forvaltningssystemer, ultimativt også udenfor SDFE.

I situationer, hvor der findes uoverensstemmelse mellem indberetning og data fra kildesystemet, da skal en problemkode oprettes på objektet i Indberetningsplatformen. En problemkode vil indikere, at det enkelte objekt uoverensstemmelsen omhandler, skal have problemkoden tilknyttet. Problemkoden er dermed et specificeret udfaldsrum for det enkelte objekt. Fx modtages en indberetning om en vindmølles fejlagtige placering, hvor en forespørgsel/udtræk fra Geodatabanken viser, at vindmøllen er blevet nedlagt tre måneder tidligere, hvor problemkoden da vil være en bestemt kode for at objektet der indberettes om, ikke længere findes i kildedata. En anden problemkode tildeles hvis der indberettes et manglende objekt, fx en bygning, men der ikke kan konstateres en bygning på det pågældende sted.

 

Spørgsmål: Krav 9.20: Hvordan definere SDFE ”kapaciteten”? Eksempler udbedes.

Svar: SDFE definerer kapacitet som antal funktionskald og mængde af data der forespørges og sendes fra et API. Et eksempel kunne være, at SDFE’s løsningsadministrator identificerer et ualmindeligt stort datatræk og utrolig højt antal funktionskald på et af API’erne, hvortil afskærmning viser sig nødvendigt.

Et andet eksempel kan være, at en anden styrelse ønsker at kunne forespørge på indberetninger, som Indberetningsplatformen indeholder. Det viser sig at den anden styrelse har udviklet en fejl i sit IT-system der leder til utrolig mange forespørgsler mod det pågældende API på indberetningsplatformen. Her skal SDFE’s løsningsadministrator kunne skærme API’et af og orientere den anden styrelse om et behov for ændring.

 

Spørgsmål: Bilag 11 Afsnit 3.3 beregning af bod, særligt K-6
Er det korrekt forstået at selv hvis svartiderne er indenfor ”Servicemålet for opfyldelsesgrad” (Dvs at mere end 95% af de simple transaktioner håndteres på under 1 sekund), så vil der alligevel tildeles strafpoint da der jo vil være transaktioner der tager længere tid? Dette virker som en lidt skjult måde at kræve 100% opfyldelse af svartidene: Selv hvis vi forestiller os at der måles 1000 gange pr dag vil blot én svartid der ligger over grænsen udløse bod: Hvis det antages at der blot er én Simpel transaktion der tager 1,1 sekund hver dag vil dette udløse 1 strafpoint pr dag, svarende til 30 strafpoint pr måned. Fortages tilsvarende antagelse for de øvrige 4 transaktionstyper (med hhv 2 sek, 4, sek, 8 sek og 4 sek) får 150 strafpoint (1 strafpoint x 30 dage x 5 kategorier) nærmest automatisk pr måned. Dette udløser så en bod på  15% af månedens vederlag, som må imødeses hver eneste måned (150 strafpoint- 50 strafpoint iflg K-7 = 100 strafpoint x 0,15%).

Svar: Det er korrekt forstået, at hvis svartiderne er indenfor ”Servicemålet for opfyldelsesgrad”, men over ”Servicemål for maksimal svartid i sekunder”, så vil der beregnes point, forudsat betingelserne i øvrigt er opfyldt. Opgørelsen af point skal derudover ske i overensstemmelse med den i bilaget anførte model. Det bemærkes bl.a. i den forbindelse, at sker der samtidig overskridelse af en maksimal svartid eller manglende opfyldelse af opfyldelsesgraden for en transaktion, betragtes det kun som én overskridelse.

%MCEPASTEBIN%