Domstolsstyrelsen. Genudbud af e-tl. Spørgsmål / Svar i forbindelse med tilbudsfasen

Transkript

1 Pulje 5, 25. juli Teknisk dokumentation Enterprise Architect Af den fremsendte tekniske dokumentation fremgå det at den nuværende leverandør benytter Enterprise Architect fra Sparx Systems, til fx vedligehold og dokumentation af domæne/begrebsmodel. Er det muligt at få udleveret en kopi eller eksport af dette repository? En eksport af den nuværende leverandørs modeldatabase samt vejledning om tilgang til denne modeldatabase kan rekvireres ved at sende en anmodning til Casper Adrian König i Domstolsstyrelsen på cadk@domstolsstyrelsen.dk. 2 Bilag 3, Driftskrav AppDynamics: Af Afsnit End-to-end værktøj til måling af svartider, fremgår det, at Leverandøren til måling af svartider skal anvende AppDynamics: Leverandøren skal anvende AppDynamics fra MCG, som er implementeret i dag, til måling af svartider hos og mellem de enkelte Komponenter i det samlede System. Der er tale om et helt sædvanligt måleværktøj, der kan sættes ind på ethvert sted i systemet og måle svartider herfra og til et hvert andet tilfældigt sted. Der foreligger ingen særskilt dokumentation. Produktet har ikke anden betagnelse end AppDynamics og licensen er Tinglysningsrettens. Det fremgår umiddelbart ikke af den fremsendte tekniske dokumentation, at det er det ovennævnte overvågningsværktøj der anvendes eller hvordan det er sat op (metrikker og målepunkter, event regler) og hvilke ressourcer (kapacitet) og service der er deployet hertil. Kan kunden fremsende den tilsyneladende manglende dokumentation, herunder Driftshåndbog og installationsvejledning? Hvilke produkter og licensforhold fra AppDynamics omfatter dette krav? 3 Kontrakt, underbilag Har Tilbudsgiver mulighed for at fremsende yderligere underbilag end de underbilag, hvis template allerede er indeholdt i udbudsmaterialet? Eksempelvis er i Bilag 12 anført "Henvisninger til besvarelser i underbilag bør tilsvarende angives i kravlisten ud for pågældende informationskrav. ". Dette kunne fortolkes som, at Tilbudsgiver kan komme med egne underbilag, men da Kunden selv har produceret 2 underbilag til Bilag 12, er det ikke klart Tilbudsgiver er velkommen til at udarbejde yderligere underbilag. Dette følger også af udbudsmaterialet, idet Leverandøren skal udarbejde underbilag 12-a, jf. bilag 12, afsnit 1.

2 om der henvises til disse to underbilag. 4 Bilag 3, punkt 9.5 Kunden bedes nærmere anføre, hvad der forstås ved "stabil Drift af Systemet" Leverandøren forstår det således, at Kunden ønsker en aftale, hvor der aftales en fast driftspris baseret på et aftalt fast kapacitetsniveau. På den baggrund bedes Kunden nærmere uddybe a) hvorledes der forventes at forekomme kapacitetstræk uden varsel udover det aftalte, b) hvilke(n) kapacitetstype(r) er der tale om (serverkapacitet, storage mm), c) i hvilket omfang forventer Kunden at der vil forekomme øget kapacitetstræk uden varsel - angivet som forøget kapacitetstræk i forhold til aftalt kapacitetsniveau, d) hvor ofte forventes det at forekomme og e) forventer Kunden at dette øgede kapacitetstræk afregnes som en merpris i forhold til den faste driftspris eller skal den ekstra kapacitet indregnes i den faste driftspris? 5 Bilag 12 Kan Kunden udlevere testmaterialet fra de tidligere gennemførte test fra den afgivende Leverandør i form af: Testplaner, Testdrejebøger, Testrapporter inkl. testresultater, Testcases, Testscripts, Rapporterede fejl, Etc.? Systemets kapacitet skal til enhver tid kunne modsvare det behov, der opstår i markedet f.eks. i forbindelse med en konverteringsbølge, hvor kapacitetstrækket over nogle få dage måske vil være fordoblet, eller i forbindelse med et pludseligt opstået behov for besvarelse af forespørgsler til systemet (antallet af forespørgsler steg f.eks. fra i juni måned 2013 til i juli måned 2013). Sådanne pludselige kapacitetsspring kan ikke varsles og omfanget kan ikke forudses (men det er typisk 2-4 gange årligt). Omkostningerne ved et sådant pludseligt øget kapacitetstræk skal være indregnet i den faste driftspris. Der foreligger ikke testmateriale fra tidligere gennemførte test fra den nuværende leverandør. 6 Bilag 14, Mindstekrav 3 Det ønskes oplyst hvilke (om nogen) særlige forhold bortset fra at der ikke må ændres i de installerede programversioner - der gør sig gældende for Kunden og Kundens systemer i Finanssektorens fryseperiode fra 1. dec. til 31. januar. Eventuelle begrænsninger i omfanget hvormed Domstolsstyrelsen stiller personalemæssige ressourcer til rådighed i fryseperioden ønskes kvantificeret. Kunden har indgået en hensigtserklæring med Finanssektoren om ikke at ændre unødvendigt i tinglysningssystemet i Finanssektorens fryseperiode. Dette betyder blot, at der ikke bør indlægges planlagte releases i denne periode.

3 7 Bilag 14 Mindstekrav 2 og Mindstekrav 6 Kunden bedes uddybe hvorledes parentesen i bilag 14, Mindstekrav 2 ( godkendt afklaringsrapport, milepæl 4 uger efter kontraktunderskrift) skal forstås. I bilag 14 Mindstkrav 6 står skal sammen med afklaringsrapporten foreligge senest 4 uger efter Kontraktens indgåelse. Spørgsmålet er således hvorvidt afklaringsrapporten skal være godkendt eller om den skal foreligge til godkendelse 4 uger efter kontraktunderskrift? Såfremt afklaringsrapporten skal være godkendt, ønskes oplyst hvor lang tid Kunden skal gives til dette. Afklaringsrapporten skal foreligge til godkendelse 4 uger efter kontraktunderskrift. 8 Bilag 14, Mindstekrav 4 9 Kontrakten pkt. 1.1, afsnit 6 10 Kontrakten pkt. 11, afsnit 8 Det ønskes oplyst hvorvidt Kunden her skelner mellem udbedring af mangler og forbedring. Er det således den nuværende leverandør der i etableringsetapen skal udbedre mangler, mens forbedring varetages af Leverandøren som en ændring jf. Kontraktens bilag 16? Kundens behov opfyldes først, når Brugernes oplevelse af Systemet som en del af forretningen er enkel, effektiv og stabil. Kan Leverandøren lægge til grund for opfyldelsen af dette krav, at Brugernes oplevelse af Systemet er enkel, effektiv og stabil, såfremt servicemål og krav i Bilag 18 og bilag 5 er opfyldt? Er Brugernes oplevelse af Systemet enkel, effektiv og stabil på nuværende tidspunkt? Vil Kunden overveje helt at lade bestemmelsen udgå henset til at denne form for værdiladet kravsopfyldelse er svær/umulig at vurdere opfyldelsen af? Leverandøren skal ved anskaffelsen af licenser på Kundens vegne tilstræbe at erhverve de rettigheder, som følger af den danske ophavsretslovs 36 og 37, såfremt en given licensaftale er underlagt udenlandsk lovgivning. Såfremt disse rettigheder ikke kan erhverves fra licensgiveren, er Ændringer i dokumentationen, der ikke skyldes implementering af ny funktionalitet, skal foretages af den nye Leverandør. Kravet er opfyldt i dag, og skal til enhver tid være opfyldt. Kravet kan ikke udelades og kan ikke alene knyttes til servicemål, da der netop er tale om en subjektiv vurdering fra Kunden. Forespørgslen giver ikke anledning til ændring af udbudsmaterialet.

4 Leverandøren forpligtet til at meddele Kunden herom, forinden licensen anskaffes. Denne pligt for Leverandøren til at opnå rettigheder i henhold til Ophl. 36 og 37 er i realiteten umulig. Vil Kunden lade sidste linje: Såfremt disse rettigheder, udgå? 11 Kontraktens pkt sidste afsnit 12 Bilag 3, punkt 6.10 ("Retention backup tilgængelighed for restore") 13 Bilag 18, afsnit ("Servicemål og KPI er til backup og restore") Leverandøren har ikke noget kontraktforhold til tredjemand. Er det rigtigt forstået at sikre alene betyder at Leverandøren har en form for initiativpligt i forhold til tredjemand, men intet ansvar for tredjemands aktiviteter, eller mangel på samme? Kan Kunden beskrive scope af restore af gamle backup nærmere, herunder: Drejer restore sig kun om datafiler til databasen, en kørende database eller forventes det at Leverandøren skal kunne restore f.eks. en 5 år gammel version af systemet med både en gammel JEE applikationsserver og gammel databaseversion? Skal en restore af databasen være den oprindelige database version eller kan data konverteres til nuværende database version? Forventes det at Leverandører stiller licenser til oprindelig applikationsserver/database til rådighed selvom systemet måtte være skiftet til anden teknologi? Kan Kunden bekræfte om det kun er den ugentlige fulde backup, der skal være tilgængelig i 10 år eller forventes det også at alle incrementale backup skal gemmes i 10 år? Gælder kravet om 10 års retention kun produktionsmiljøet eller gælder det både de 2 testmiljøer og produktionsmiljøet? Kan Kunden beskrive en use case hvor SLA i punkt 2 fra tabel 4 vil være relevant ("Produktionsmiljø - Recovery Time Objective - RTO (timer)")? Kan Kunden uddybe begreberne "Recovery" og "Restore"? Leverandørens opfattelse er at Ja, det er korrekt. Det skal blot være muligt at læse data og/eller at tilpasse disse til den kørende version af systemet. Det er kun den fulde ugentlige backup, der skal være tilgængelig og det gælder alene produktionsmiljøet. Hvis det udstyr Leverandøren anvender af en eller anden grund pludseligt forgår, skal Leverandøren kunne genskabe et fuldt funktionsdygtigt produktionsmiljø inden for de angivne servicemål.

5 "Recovery" dækker genetablering af forretningsservicen efter en større driftshændelse (ikke nødvendigvis en katastrofe, som angivet i punkt 4 i tabel 4), mens "Restore" omfatter indlæsning af en backup - er dette korrekt? Vil en "Recovery" altid medføre en "Restore"? Kan Kunden bekræfte at Leverandøren ikke skal afvente en henvendelse fra Kunden før Leverandører påbegynder genetablering af forretningsservicen? Opfatter Kunden Site Failover som Recovery? Forventer Kunden at det skal være muligt at restore en vilkårlig backup indenfor 2 timer? Dvs. f.eks. også en 10 år gammel backup? Forventer Kunden at SLA kravene kan justeres i takt med at databasen bliver større? Kunden er enig i beskrivelsen af Recovery og Restore og mener ikke, at en Recovery nødvendigvis altid vil medføre en Restore, men det vil sikkert ofte være tilfældet. Kunden bekræfter, at Leverandøren ikke skal afvente henvendelse fra Kunden inden genetablering påbegyndes. Kunden opfatter ikke Site Failover som Recovery. Det skal være muligt at restore den backup, der er nødvendig for at bringe produktionssystemet i fuld drift igen. SLA kravene forventes at være faste i hele kontraktens løbetid, men Leverandøren er velkommen til at byde ind med bedre servicemål. 14 Bilag 3, punkt 6.9 Kan Kunden uddybe behovet for at der skal lagres backup på et online medie minimum i de til enhver tid seneste 6 måneder, herunder om der er forskel på de forretningsmæssige krav og behov mellem backup der er mindre eller ældre end 6 måneder. Det fremgår bl.a. af punkt 6.5. at online og offline back up skal placeres og håndteres på en sådan måde at data ikke utilsigtet kan ødelægges eller slettes. Der synes ikke at være forskel på de data der skal lagres i en online og i en offline backup og Leverandøren undrer sig derfor over behovet for online backup. Kan Kunden ligeledes oplyse om der er forskel på SLA i krav om restore på online og offline backup under henvisning til bilag 18 punkt Bilag 7, afsnit 3.4 Det er angivet at der skal tilrettes 10 kontroller og udvikles 5 nye, men ikke noget om omfanget og kompleksiteten af ændringerne. Kan vi få en liste over de 10 eksisterende kontroller, der skal tilrettes, samt en kort beskrivelse af de forventede ændringer? I princippet burde al backup være på et online medie for at sikre hurtig/umiddelbar adgang til data, men af økonomiske hensyn har Kunden valgt en model, hvor dette alene er krævet i 6 måneder. Der er ingen forskel på SLA kravene, men Leverandøren er velkommen til at byde med en differentiering, blot servicemålene er bedre end de kravsatte. Der foreligger ikke på nuværende tidspunkt en detaljeret beskrivelse af de kontroller, der vil være nødvendige. En sådan beskrivelse vil skulle ske i samarbejde med leverandøren. Der skal derfor regnes med sædvanlige ændringer og udviklinger (set i forhold til de i dag i systemet forekommende kontroller).

6 Kan vi få en kort beskrivelse af de 5 nye, herunder en indikation af kompleksiteten af hver ny kontrol? 16 Bilag 7, afsnit 3.5 Der er angivet at alle udskrifter/visninger skal tilrettes med nye data. Hvordan skal alle forstås? Kan det præciseres hvilke visninger og udskrifter der er tale om (eller det præcise antal)? 17 Bilag 7, afsnit 3.6a I forbindelse med ændring af tinglysningssvaret: Skal leverandøren, som en del af option 1, indgå i arbejde med OIO godkendelse af den ændrede type? 18 Bilag 7, afsnit 3.6d Etablering af kopidatabase for CVRoplysninger: Hvem er aftalepartner med ES? Hvilke dele af CVR oplysninger skal gemmes i databasen? Hvilket interface skal anvendes til integration (Web service, eller andet)? Systemet indeholder, jf. dokumentationen, en lang række renderinger af systemets data. Det er disse renderinger, der på helt sædvanlig vis skal tilrettes med de nye data. Nej. Aftalepart er Tinglysningsretten. CVR-nr., navn, adresse og virksomhedstype skal gemmes. Interface aftales med Leverandøren efter anbefaling fra denne. Opdatering f.eks. en gang i døgnet, men gerne oftere. Hvordan og hvor ofte modtages information om ændringer til data i kopien? 19 Bilag 7, afsnit 3.6e Løbende opdateringer fra andre offentlige registre. Opdatering fra præcis hvilke offentlige registre skal prissættes som en del af Option 1? Alle de offentlige registre, der vil være omfattet af Datafordeleren og som Kunden derfor vil være forpligtet til at hente fra denne. De to sidste spørgsmål bedes besvaret for hvert andet offentligt register, som kravet vedrører. 20 Bilag 7, afsnit 3.6a Hvad omfatter behandling af de nye datatyper i Sagsportalen, hvilken logik skal understøttes? Er det muligt at få en oversigt over de use-cases der påvirkes af ændringen? Der er blot tale om tilretning af sagsportalen, således at denne kan håndtere de nye ekspeditionstyper på samme måde som de eksisterende ekspeditionstyper.

7 21 Bilag 4, afsnit 7.1 For at vurdere omfanget af garantiforpligtelsen i forhold til den tidligere leverandør, vil Leverandøren gerne have adgang til en liste med de ændringer og fejlrettelser, for hvilke der stadig er garanti. For hver af disse ændringer eller fejlrettelser vil Leverandøren gerne have oplyst datoen for idriftsættelse samt have adgang til den designdokumentation el.lign., der beskriver indholdet i ændringen eller fejlrettelsen, samt timeforbruget for hver enkelt ændring/fejlrettelse Det vil først være relevant at udarbejde en sådan liste umiddelbart før overtagelsesdagen, da de ændringer, der vil være omfattet af en sådan garantiforpligtelse endnu ikke er leveret/bestilt, 22 Kontrakten, afsnit 15.2, samt bilag 15 Af hovedkontraktens afsnit 15.2 og af formuleringerne i bilag 15 fremgår det, at Leverandøren skal vedlægge CV er alene for nøglemedarbejdere i underbilag 15-a. Men af hovedkontraktens afsnit fremgår det, at alle medarbejdere, som der skal kunne faktureres timer for, skal fremgå af CVgrundlaget i underbilag 15-a, og således ikke kun nøglemedarbejdere. Vil kunden ændre formuleringen i afsnit , således at dette krav udgår? Alternativt vil kunden oplyse hvordan processen med opdatering af underbilag 15-a tænkes håndteret? Kontraktens pkt , første afsnit ændres til: Leverandøren skal sikre, at medarbejdere der faktureres timer for, som hovedregel, fremgår af CVgrundlaget, jf. underbilag 15-a. Fremgår medarbejderen ikke heraf, og er det ikke nærmere godtgjort, hvorfor der er faktureret timer for den pågældende medarbejder, er Kunden berettiget til at afvise hele eller dele af fakturaen.