Der mangler såvidt vi kan se et punkt til netværksovervågning ligesom punkt 7.6/7.6.1 DCM som kun er datacenter overvågning..

Under punkt 7.4.x burde det vel hedder Datacenterservere for at matche punkt 7.6 Datacenter infrastructure management.

Burde der være et seperat punkt under 7.3 for cloudbased wireless services, da det i aftalens løbetid sikkert kommer til at vokse kraftigt?

I har skrevet: Dette afsnit uddybes SNAREST muligt efter 9. april 2014. VH SKI 

Hvornår kommer uddybningen /opdateringen? 

Kommunerne og de statslige organisationer er de sidste år begynd at efterspørge ”converge infrastructure” elller datacenter ”in a box” løsninger, hvor netværk, storage og server leveres i en samlet løsning. SKI har idag ikke en aftale hvor disse produkter indgår. Som vi har forstået det fra SKI,  har det været forslået at disse løsninger skal ind under aftale 02.07.

Vi kan ikke se at der under sfanittet ”Netværksudstyr og Datacenterløsninger” ikke er medtaget disse løsninger. Derfor forslår vi at ”Converge Infrastructure” kommer ind under afsnittet ”Netværksudstyr og Datacenterteknologi” imellem afsnittet Storage 7.5 og 7.6 og Data center infrastructure managment.

Afsnittet kunne hedde ”Datacenter Blok løsninger” og Ski kunne bede om en Blok løsninger for 100 virtuelle servere, 200 virtuelle servere, 500 virtuelle servere. 

Ved at implementere et setup baseret på to enheder i High Availability (HA) configuration, kan man argumentere for, at et krav omkring ”Mulighed for redundant strømforsyning” ikke bærer samme nødvendighed isoleret set.
Kunne det være en mulighed, at omskrive dette krav indeholdende High Availability for funktionalitets redundans, baseret på to eller flere enheder som et alternativ til redundant strømforsyning?
 

Multi-Factor-Authentication sikkerhedsløsninger gør ofte brug af realtidsgenerede koder ved login og specifikke RADIUS atributter i denne forbindelse, kunne man forestille sige at der kom nogle krav der understøtter dette?

Endvidere benyttes der ofte vendor specifikke attributter, hvorfor et ønskelig krav kunne være support for disse.

Kravet omkring "6.3.3 - 802.1x brugervalideringsprodukter" kunne med fordel flyttes ind under Mellemgrupperne ”Firewalls”, ”Switche” og ”Routere” som et krav, da denne teknologi ikke i sig selv er et brugervalideringsprodukt (BVS), og kan ikke stå alene, men gør brug, for teknologien, af ekstern validering, såsom RADIUS. 

I de fleste netværksinfrastrukturer benytter man sig af Netværksrelaterede Delivery Services, som støtte og værditilførselssystemer til infrastrukturen.
Af basis Netværksrelaterede Delivery Services kan nævnes f.eks.: DNS, DHCP og NTP Services og af de lidt mere avancerede Netværksrelaterede Delivery Services kan nævnes f.eks.:  DOS/DDOS sikringssystemer/mekanismer, Lastbalancering af servere og applikations optimering for at nævne et par stykker.

Vi kan ikke finde ”Delivery” området i kravspecifikationen og foreslår derfor, at Delivery Services bliver taget med ind under aftale 02.07 og der bliver specificeret krav til dette område.

Det i mener her er ikke SAN, men storage som er block baseret, og det er block protokoller der har adgang til det

Et SAN er en infrastruktur, som forbinder server med storage, lige som et LAN.    

Forslag til ny tekst:

a)      Det er et Krav, at Produkter der tilbydes under Undergruppen blokbaseret storage, leveres som et dedikeret storage enhed, der giver adgang til konsoliderede datablokke, via blok protokoller fks. FC, FCoE, ISCSI og andre  

b)      Det er et Krav, at Produkter der tilbydes under Undergruppen block baseret storage, leveres færdigkonfigurerede inklusiv fastlagerenheder, og den nødvendige infrastruktur

c)      Det er et Krav, at Produkter der tilbydes under Undergruppen block baseret storage, leveres som Produkttypen hardware eller løsning.

Sondringen imellem mellemgruppe 6.1, 6.4 og 6.5 er ikke markedskonform, idet der findes produkter der i dag i et og samme produkt understøtter disse 3 adspurgte delområder. Vi anbefaler derfor, at der i stedet for en produktopdeling i tilbudslisten kan angives hvilke af disse områder det enkelte varenummer spænder over.

I dokumentet ”udkast til tilbudsliste” ses, at der skal opgives leverandørens kostpris og avance. Dette er ikke oplysninger som er muligt at give. Prissætning imellem leverandør og producent er et fortroligt anliggende, som ikke er tredje part vedkommende. I de fleste partneraftaler mellem leverandør og producent, er fortroligheden omkring leverandørens indkøbspriser specifikt omfattet af NDA og kan derfor ikke opgives. Indkøbspriser er endvidere et uigennemsigtigt begreb, da de konstant kan ændre sig i forhold til bonusser for individuelt fastsatte mål osv.

Vi anbefaler, at SKI ændre prissætningen til en officiel listepris minus en rabat. Derved opnår SKI en prisstruktur, som altid er i tråd med den aktuelle prisudvikling på produkterne.

Udbudsdesignet og retningslinjer for miniudbud ligger op til at der i 2 af de I alt 6 tildelingsformer indgår resultatansvar for leverandøren (miniudbud 3 og 5).

Rammeaftalen (det vi har set af den) ligger i sin struktur og til at være baseret på en ’komponentaftalemodel’ dvs. at alle produkter på aftalen kan leveres i afgrænsede og fast definerede størrelser eller perioder, f.eks. en switch eller en konsulenttime. Hele kontraktdesignet f.eks. bodsbestemmelser, leveringsbestemmelser, rapporterings til SKI, varekataloger etc. må derfor formodes at bygge på en komponentmodel, hvor løsninger sammensættes ud fra fast definerede komponenter, men hvor komponenterne vedbliver at være kontraktgenstanden.

Ved at introducere ’resultatansvar’ som del af miniudbudsform 3 og 5 ændres grundlaget for aftalen fra at være komponenten til at være den samlede ydelse. Rent juridisk er dette et aftaleretligt problem, idet grundlaget i et løsningskøb med resultatansvar (servicemodel/IT-projekt) er væsentligt forskelligt fra et komponentkøb. Bl.a. har vi svært ved at se hvordan SKI’s traditionelle bodsbestemmelser, leveringsbestemmelser og rapportering kan kombineres på en måde så det både giver mening ved komponentkøb og ved løsningskøb. Vi frygter derfor at aftalen bliver ekstrem svær at håndtere fordi den spænder for vidt og forsøger at kombinere to kontraktparadigmer, der reelt ikke kan kombineres.

Vi anbefaler derfor at SKI lader miniudbudsform 3 og 5 udgå.

SKI skriver at ‘der ikke kan anskaffes on-site konsulenttimer’ ved direkte tildeling og miniudbud 1. Vi kan ikke se hvad formålet med denne begrænsning er og foreslår den derfor fjernet.

Da man i flg. SKIs egne regler godt må levere mere end minimumskravene, virker opdelingen af switche i 4 grupper i afsnit 7.1 lidt overflødig. Man kan vælge at lægge alle sine produkter i ”type 1”, og dermed leverer man det, som er kravet - eller mere.

Under punkt 7.2.d, er der lavet en copy-paste fejl. 7.2. omhandler routere men i kravene er angivet ”switche”

Punkt 7.2.1-7.2.4 ligner til forveksling kravene på switch-grupperne under afsnit 7.1.1-7.1.4. Under switch-grupperne er der helt fair fokus på antallet af porte og hastigheder på disse. Under routere giver det mere mening at sætte krav til router-funktionaliteter og faciliteter end krav til portantal. Der vil være stor fare for at frasortere en stor mængde interessante routerprodukter, såfremt kravene om portantal fastholdes. Eksempler på routerfunktionaliteter og faciliteter:

a.       specificering af WAN interfaces (som E1 eller ISDN), og

b.      routningsprotokoller (OSPF, BGP, ISIS)

Under punkt 7.3 mangler der en behandling af en evt. licensstruktur til AP’erne op mod den trådløse controller. SKI bør inkludere evt. licensaftaler i aftalen. Vi forslår at der under gruppe 8 ’tilbehør’ gøres muligt at tilbyde licensaftaler i forbindelse med produkter under punkt 7.3

Hvis et produkt kan kategoriseres under flere undergrupper, skal man så angive dem i alle undergrupperne?

Punkterne 7.4.1 og 7.4.2. For ikke at det SKI 02.07 skal blive endnu en ny serveraftale under SKI, så bør ordet ”kan anvendes til” ændres til  ”skal anvendes til…”

Er det korrekt opfattet, at de minimumskrav, der er i kravspecifikationen, er meget åbent formuleret, for at få en så stor udstyrsliste som muligt inden for de definerede rammer? 

Er yderligere tekniske minimumskrav derfor overflødige indenfor nuværende kravspecifikation 02.07? Og skal uddybende tekniske krav, derfor kun være funderet i kundecases, under Miniudbud?

Eksempel :

Yderligere krav til »7.1 - Switche«, såsom f.eks. Link Aggregering (f.eks. LACP) og Lag 2 beskyttelse (F.eks. Spanning tree - MST, RSTP) hører til som kundecase defineret minimumskrav under Miniudbud.

Yderligere krav til »7.2 - Routere«, såsom f.eks. Dynamiske rountingsprotokoller (f.eks. RIP, OSPF, BGP) og Netværks Virtualisering/Virtuelle Netværk (f.eks. VRF/VRF-Lite, VPN-instances) hører til som kundecase defineret minimumskrav under Miniudbud.

Priser skal opgives i DKK, men der er ikke indikeret hvorledes priserne kan ændres i kontraktperioden. De fleste indkøb er i USD og vil derfor kunne svinge op og ned. Hvor tit og hvordan kan leverandørerne ændre sine priser?

I forhold til de ønskede kommentarer til kravspecifikationen, mener vi at der mangler følgende produktområder for at dække relevante It-sikkerhedsprodukter. Her savnes:

1.      Management produkter, eftersom produkterne i mellemgrupperne gør brug af sådanne til opsætning og administration af produkterne.

2.      Event og rapporteringsprodukter , der på tværs af produkterne i mellemgrupperne kan advisere  om irregulariteter og trusler, og generere periodiske rapporter.

3.      DDOS beskyttelses produkter.

DDOS produkter passer ikke ind under hverken Content scanning eller Intrusion, detection, and prevention mellemgrupperne. Burde have deres egen gruppe.

Under tilbehør til IT-sikkerhedsprodukter bør der vel også være udvidelse af hardware sikkerhedsprodukterne i form af netkort, transceivere og ramudvidelse. Ligeledes tokens ( hardware, software, sms) tilbehør til Brugervalideringsprodukter  (BVS) mellemgruppen.

I ”Vejledning” til tilbudsliste, står angivet at der foruden nærværende faneblad er indeholdt 16 faneblade. Hvis dette er det endelige antal faneblade, mener vi at der mangler faneblade omhandlende ”IT-sikkerhedsprodukter”.

Dagens trusselsbillede ændrer sig hastigt, hvorfor det ikke er nok blot at købe et produkt. Vi vil derfor anbefale, at der stilles krav om at produkterne (mellemgruppe 6.1, 6.4 og 6.5) understøtter abonnement for proaktiv opdatering for både signaturer og reputation data.

Vi forslår følgende formulering indsat i mellemgruppe 6.1, 6.4 og 6.5: ’Det er et Krav, at Produkter der tilbydes under Mellemgruppen xxxx, understøtter abonnement for proaktiv opdatering for både signaturer og reputation data.’ Endvidere forslår vi at det under mellemgruppen ’8.2.   Tilbehør til IT-sikkerhedsprodukter’ gøres muligt at tilbyde de nødvendige tilkøb med en separat pris således at der ikke kun kan tilbydes kabler og strømforsyninger som tilkøb.

For at kunne vurdere det økonomisk mest fordelagtige tilbud for hardware komponenterne (undergruppe 6.1.1, 6.4.1 og 6.5.1) anbefaler vi, at der stille krav til produkternes REELLE throughput og latency samt antallet af sessioner der understøttes.

Vi har med stor bekymring læst det tilgængelige materiale. Vores bekymring ligger i, at SKI tilsyneladende forsøger, at gøre 02.07 kommunikationsaftalen til en end to end datacenteraftale. Dette er en yderst uheldigt af følgende årsager:

1) Aftalen bliver i sin karakter yderst konkurrenceforvridende i forhold til leverandører med specialviden inden for kommunikation og netværk, som må formodes at være det primære genstandsområde. Udbuddet appellerer udelukkende til meget store og brede leverandør, som i følge evalueringskriterierne, kan mønstre den længste liste af varenumre og producenter. Dette står i stærk kontrast til SKI´s ønske om ”højt specialiserede leverandører”, som beskrevet i dokumentet ”Uddrag af udbudsdesign”.

2) Servere, storage, infrastruktursoftware og netværk er yderst forskellige discipliner, som kun meget få leverandører kan levere i en samlet løsning. Der kræves fra producenternes side omfattende certificeringer inden for hvert område, for at opnå tilladelse til, at kunne både rådgive, sælge, levere og installere produkterne. Ambitionen om at flertallet af de vindende leverandører, reelt skal kunne levere en samlet datacenterløsning er derfor ganske urealistisk.

3) SKI skriver i ’kom godt i gang med kommentering’ at ’undergrupperne Netværks- og kommunikationsservere og Storage ….. dækker alene ”færdigkonfigurerede” produkter. Tilkøb til disse må ske via andre aftaler.’

Et datacenter udvikler sig over tid og behovet for kapacitet øges. Vi formoder, at SKI bl.a. i respekt for leverandørerne på henholdsvis 02.03 server- og storageaftalen, 50.45 forpligtende serveraftale og 02.06 softwareaftalen forventer, at alle efterfølgende tilkøb til en indkøbt datacenterløsning, skal suppleres fra disse aftaler. 

Der er endog meget stor sandsynlighed for, at kunder efterfølgende et miniudbud vil befinde sig i en situation, hvor de ikke kan supplere deres indkøbte løsning, fordi de rette varer og producenter ikke er repræsenteret under de eksisterende aftaler.

4) Det kunne være yderst spændende at høre fra SKI, hvorfra inspirationen til udvidelsen af genstandsområdet på netop denne aftale er opstået. Der er udelukkende én producent, som anskuer hele datacenteret fra et netværkscenteret perspektiv. Vi har derfor svært ved at se behovet for at indrette en hel rammeaftale efter denne ene producents tilgang, da det på ingen måde kan betegnes, som en generel trend for markedet.

Samlet set anbefaler vi, at SKI i nærværende udbud afgrænser genstandsområdet til de relevante produkter for en netværks- og kommunikationsaftale. Dette anbefales for at sikre en rimelig kompetence hos de fremtidige leverandører inden for deres tilbudte sortimenter, samt for at sikre at leverandørerne på de allerede eksisterende SKI IT-aftaler, stadig finder aftalerne attraktive.

Konkret anbefaler vi at punkt 7.4, 7.5 og 7.6.1 til 7.6.4 udgår af kravspecifikationen.

Punkt 7.3. Vi forstår udmærket kravene omkring AP’ernes radioer, men forstår ikke hvorfor SKI vil afholde sig fra at tilbyde AP’er med single-radio produkter. Typisk er der store besparelser i sigte ved brug af denne teknologi.

Punkt 7.3  e lyder: ’Det er et Krav, at Produkter der tilbydes under Mellemgruppen Trådløse komponenter, er udstyrede med to (2) seperate radioer, henholdsvis en radio til 2,4 Ghz og en radio til 5 Ghz frekvensbåndene.’

Kravet bør ændres til: ’Det er et Krav, at Produkter der tilbydes under Mellemgruppen Trådløse komponenter, er udstyrede med en eller to (1 eller 2) seperate radioer, henholdsvis en radio til 2,4 Ghz og/eller en radio til 5 Ghz frekvensbåndene.

Sommeren nærmer sig og de fleste har allerede planlagt ferieafholdelse. I respekt for alles sommerferieafholdelse med familie osv., beder vi SKI om at planlægge udbudsforløbet således at tilbudsfristen forlænges hvis udbudsmaterialet sendes ud henover sommeren. Vi ser meget gerne at svarfristen ikke ligger før ultimo aug/primo september, såfremt udbuddet sendes ud henover sommeren.

I punkt 8 tilbehør, er der kun mulighed for at tilbyde kabler, antenner og strømforsyninger. Vi foreslår at der under hver mellemgruppe (8.1, 8.2 og 8,3) indsættes en kategori for ’øvrigt tilbehør’, hvori f.eks. rackskinner, monteringsbeslag, optiske transivere, licensaftaler etc. kan tilbydes. Hver af disse tilbehørsprodukter er nødvendige for aftalen men vil ikke kunne tilbydes under selve produktkategorien da de ikke selvstændigt lever op til kravene. Der bør dog ikke åbnes for at tilbyde servere og storage under denne kategori.

I dokumntet (punkt 3) omtales konsulentkategorierne juniorkonsulenter, specialister og seniorkonsulenter. Disse afviger fra punkt 3.1 , hvor konsulentkategorierene angives som juniortekniker, tekniker og ekspert.

Der bør være overensstemmelser i hele dokumentationen vedr. disse kategorier.

Vedr. punkt 5.2. Der bør være mulighed for at leverandøren kan foreslå andre prismodeller/prissætninger samt optioner, som kan være til økonomisk fordel for kunden. Vi foreslår at procentsatsen for hastetilkald og arbejde uden for normal arbejdstid i punkt 5.2 fastsættes af tilbudsgiver.

Der er en del anonyme indlæg som er svære at forholde sig til netop fordi de er anonyme. Vi foreslår SKI kun tillægger vægt på indlæg fra kilder som vil give sig til kende.

 Er det korrekt forstået at alle tre punkter som minimum skal indgå i en Conferencing-løsning?

• Conferencing-videokameraer
• Conferencing-monitorer eller Conferencing-lærreder
• Conferencing-projektorer 

I Mellemgruppen "Switche" menes der at mangle en undergruppe, der specificere kravet omkring 10Gbit downlinks.

I datacentre benyttes ofte 10G access switche til at forbinde servere og andet udstyr på 10G.
Udstyret bør være baseret på SFP+ porte.

Udstyret ses både i L2 og L2/L3 senarier.

Kan ikke finde det i dokumenterne der er lagt op, men benytter alligevel chancen, da det har stor betydning for administrationen og vedligeholdelsen af sortimentet på aftalen.

Opdatering af sortiment, jf. de gamle regler (bilag RB05 - Opdatering af sortiment og priser samt e-katalog), har været meget tidskrævende, da vi skal udskifte sortimentet ud fra reglerne 1:1 eller 1:bedre.
Udfordringer er, at leverandørerne ikke følger denne regler. 3 udgåede produkter kan blive til 8, et udgået produkt bliver ikke erstattet, nye produkter lanceres osv.

Jeg foreslår, at når man som SKI leverandør har meldt en produktgruppe ind fra en givne producent, så følger vores sortiment producenternes sortiment.  

Vi foreslår at der tilføjes en standard (AC - 802.11ac) I afsnit 7.3 underpunkt d.

Vi ønsker mulighed for at tilføje flere linjer I tilbudslinjerne. F, eks. er der kun 22 linjer under switche og de producenter vi forhandler har væsentlig flere end 22 switche I sortimentet.

Der ønskes også mulighed for at prissætte tilkøbskomponenter på kommunkationsservere og storage således at tilkøb af enkelte serverer f. eks. til en telefoniløsning eller ekstra lagringskapacitet til en storage løsning bliver muligt. 

Hvad er SKI's baggrund for at kræve kostpriser oplyst?

SKI er vel interesseret I den bedst mulige pris for kunderne og ikke hvad den enkelte leverandør tjener eller hvilken rabat denne har hos producenten. Vi har alle forskellige rabatniveau'er, omkostninger og krav til indtjening. 

Vi ønsker, at der bydes med en listepris (meget gerne i fremmed valuta) og en salgspris gerne i fremmed valuta. Listeprisen fremkommer fra producenternes officielle prislister, som kan indeholde prissætning i fremmed valuta, f,eks. Cisco. Kostpriser kan være forskellige for de enkelte leverandører, så billedet er mere enkelt med en listepris og en salgspris. Hvorledes, salgsprisen fremkommer, er vel også kunderne underordnet.

Tilbudslisten skal tage hensyn til den valuta, som producenterne/forhandleren handler i. Dette sikrer at leverandørerne kan levere med reduceret risiko og dermed lavere pris

For at sikre optimale indkøbsforhold på aftalen, anbefaler vi, at det bliver muligt at have særlige rabatpriser i en specificeret periode.

Kunderne skal kunne købe en bundle af produkter i et begrænset tidsrum. F.eks. en wireless løsning bestående af et antal access punkter, et antal controllere og kabler, hvor rabatten gives på sammensætningen af komponenterne.

Beløbsgrænsen på 1 mio dkr (i udkastet) er meget lavt set i lyset af den eksisterende aftale. Ved at have et højere beløb på direkte tildeling jo større incitament til at byde ind med skarpe priser.

I forbindelse med køb af et produkt, så er service et naturligt tilkøb. Derfor anbefales det, at service tænkes ind i aftalen, som et separat punkt for hver varelinje. Det producenterne leverer som standard er i dag begrænset og opfylder formentlig ikke SKI’s garantibetingelser. Fx er garantien for de fleste producenterne meget begrænset.  

De beskrevne konsulentkategorier er vidt forskellige i deres struktur. Det vil således give mening at lave guldabonnement på test og fejlfinding, men normalt ikke på uddannelse, projektledelse og design/arkitektur. Vi foreslår at uddannelse, projektledelse og design/arkitektur kun kan sælges med et beredskabsniveau svarende til bronze.

Der bør derfor være mulighed for at differentiere de enkelte opgavetyper i relation til beredskabsniveauer i punkt 5.1 således at kunden kan købe forskellige niveauer ift. de ønskede ydelser.

SKI ønsker at stille krav om at ’alle tilbudte produkter skal sælges med en brugsanvisning med information om:

•        Hvordan man anvender produkterne på den energimæssigt set bedste måde – herunder

•        Information om bortskaffelse af produkterne i henhold til gældende lov om elektronikaffald

•        Eventuel returordning for udtjent udstyr.’

Vi har følgende kommentarer til kravet:

1.      Der stor forskel på de produkter der tilbydes på aftalen. Der medfølger f.eks. ikke en brugsanvisning til et strømkapel ligesom en række SW-produkter heller ikke leveres med en trygt manual.

2.      En række af produkterne markedsføres og sælges ikke udelukkende til det danske marked. Punkt to og tre i formuleringen er typisk specielle for danske forhold og information og vejledning herom trykkes derfor ikke i en brugsanvisning, men gøres tilgængelig på nettet.

3.      Af hensyn til netop miljøet bør det være tilladt at gøre brugsanvisningen tilgængelig på nettet eller via et medfølgende medie.

Vi foreslå at kravet omformuleres til:

’alle tilbudte produkter skal, hvor det er relevant, sælges med en brugsanvisning eller der skal gives adgang til brugsanvisning via nettet. Brugsanvisning skal indeholde information om hvordan man anvender produkterne på den energimæssigt set bedste måde.

Endvidere skal der for alle produkter hvor det er relevant, gives information om:

•        Bortskaffelse af produkterne i henhold til gældende lov om elektronikaffald

•        Eventuel returordning for udtjent udstyr.

Informationen kan f.eks. gives via internettet.’

 Med reference til "7.5 - Storage".

Har SKI til hensigt at tilgodese eller tage højde for, at der kan tilbydes produkter/løsninger, der tilbyder de-duplikering/Kompression via software, og dermed giver produktet/løsningen en logisk lager kapacitet, der typisk overstiger den fysiske kapacitet med en faktor 10-30? 

I punkterne 5.2.5 og 5.2.7 nævnes Business og HDMI i samme sætning. HDMI er noget man ser på forbrugerudstyr og henvender sig hermed til forbrugere. Når det er Business er det Displayport, der skal bruges.

I udkast til tilbudslisten – udkast-til-tilbudsliste.xlsx – kan vi ikke umiddelbart se, hvor der er afsat plads til Voice elementerne?

Det vil være hensigtsmæssigt, hvis suppleringskøb af Netværks- og kommunikationsservere og Storage også kan foretages ved direkte tildeling, og at disse produkter derfor er prissat i tilbud. Det kan ved udvidelser af installationen være relevant med tilkøb af specifikke produkter, hvor det enkleste vil være direkte tildeling.

Vil der I kontrakten være mulighed for at tilbyde priser til laveste dagspris eller særlige kampagne priser ligsom der har været i andre rammekontrakter, eller er prissætningen alene baseret på SKI 's kostprismodel eller den foreslåede alternative model?

Hvorledes mener SKI at kunne differentiere sig fra fx MS-aftalen, med denne aftale?

Direkte tildelingskriteriet er sat så lavt at kunderne naturligt vil søge andre indkøbsmuligheder, for at kunne tilsikre indkøb uden miniudbud.

Samtidig vil en grænse på det nævnte beløb ikke give producenterne et incitament for at understøtte en prissætning der vil gøre aftalen attraktiv, idet man som producent ved at løsninger af en vis størrelse ryger ind under mini-udbud.

Dermed vil aftalen muligvis ende op med en højere initiel prissætning end den eksisterende aftale, samt en uhensigtsmæssig lav tildelingsgrænse. Dette vil ikke gøre aftalen attraktiv for kunderne, sammenlignet med alternativerne.

Hvilke bevæggrunde ligger bag SKI’s tærskel grænse på 1 mio. DKK, set i lyset af den eksisterende aftale’s markant højere tærskel grænser, som gjorde at producenter og forhandlere havde et attraktivt grundlag for kunderne at handle på.

Hvad er SKI’s tanker omkring den evige problematik der har været med hensyn til udskiftnings vinduer og de problemer vi som forhandlere har haft i forhold til at byde ind på udbuds sager hvor man ikke havde et givent produkt på sortimentet, fordi dette måske ikke var prissat på udbudstidspunktet.

Dette har medført 1 af 2 scenaier:

·        Feltet af forhandlere der har kunnet byde ind har i værste tilfælde været minimeret til den forhandler der har haft et specifikt kendskab til at netop denne komponent skulle kunne tilbydes, og dermed har sikret at netop denne specielle komponent blev tilføjet. Dermed er der ej heller garanti for en optimal prissætning, da der er begrænset konkurrenceudsættelse

·        Kunderne har ikke kunnet få tilbudt nyeste teknologi, da de i visse tilfælde har måtte vente 3 måneder på at et nyt vindue for udskiftning er åbnet.

Kunne det fx indføres at man som forhandler kunne byde ind med produkter som i næste åbne udskiftnings-vindue blev tilføjet sortimentet?

Vi forstår SKI’s baggrund for den først foreslåede prismodel, herunder behovet for at lave en prismodel der bygger på objektive kriterier samt en leverandørfastsat rabat/tillæg.

I relation til den foreslåede alternative model har vi følgende kommentarer:

Ad 1: Prisregulering af udstyr på rammeaftalen

Ift. det udstyr der er på rammeaftalen, frygter vi at den foreslåede model vil blive særdeles tung at administrere både for leverandørerne og SKI. Det skyldes at modellen ligger op til at leverandøren skal kunne redegøre for ændringer i produkternes kostpris for hver enkelt produkt. Modellen er baseret på en manuel proces, hvor der skal redegøres/erklæres fra leverandørens side og derpå behandles/godkendes fra SKI’s side. Med det brede sortiment aftalen må forventes at indeholde samt 8 leverandører på Rammeaftalen frygter vi at det bliver svært at administrere og særdeles procestungt.

Vi foreslår i stedet at basere prisreguleringen af udstyr på listepriser. Vi foreslår en model hvor leverandøren på tilbudstidspunktet melder følgende to parametre ind for hver varelinje: 1) Listepris 2) Rabat. I den tredje kolonne beregnes SKI-prisen automatisk.

Vi er opmærksom på at dette vil betyde at leverandørerne skal regulere deres priser samtidigt (for identiske produkter), hvilket er en ulempe. Dog har vi svært ved at se hvordan en model baseret på manuel justering og redegørelse/godkendelse for ændring i kostpriser reelt vil kunne fungere i et udbud som dette. Derfor mener vi at listepris minus rabatsats er den mest reelle model.

Ad 2: Prisfastsættelse af nyt udstyr på rammeaftalen ved substitution og addition

Vi støtter det foreslåede. Dog gør vi opmærksom på, at rabatsatsen på fremtidige produkter bør kunne fastsættes individuelt på alle undergrupper, således at rabatsatsen kan differentieres imellem produkt-undergrupper.

Herunder er en liste over generelle funktions-krav der kan stilles til DCIM systemer.

• DCIM skal styre alle datacenterlokationer

• Alle rack og alt udstyr skal være aktiver i DCIM, så integreret kapacitetsstyring og –planlægning bliver muligt.

• Grundplaner skal vedligeholdes i DCIM. Brug af lag fra AutoCad-tegninger skal være understøttet.

• Planer og layout for racks skal vedligeholdes i DCIM.

• Styring og konfiguration af netværksrouting skal være tilgængeligt.

• Strøm- og kølingsmetrikker skal indsamles fra PDUer, sensorer og afkølere, som aktuelt understøttes af SNMP.

• Alarmering via SNMP-traps eller e-mail skal være muligt.

• Udtræk af data til opload af lokation-/rack-/serveraktiv og konfiguration til tredjeparts-CMDB skal være muligt.

• DCIM-løsningen skal leveres som et leverandørunderstøttet virtuelt black box-program.

• Rapportering om strøm, køling, temperatur og luftfugtighed skal være muligt.

• Kapacitetsrapportering om rum- og rackbrug skal være muligt.

• Det skal være muligt at have rapportering på et overordnet niveau om styring og tendenser, uden at der skal installers et klientprogram.

• Workflow- og ændringsstyring skal være understøttet. Anmodninger om ændringer skal kunne oprettes fra alt udstyr. En oversigt over kommende begivenheder og ændringer skal understøttes.

• 3D-visning over fordeling af kold og varm luft skal understøttes.

• Administration af brugere. Active Directory-godkendelse skal understøttes. Brugere skal have forskellige adgangsrettigheder.

• DCIM-værktøjet skal understøtte klyngekonfigurationer for at sikre et højere redundansniveau.

• Kontrol af aktiv skal være understøttet. Alle begivenheder tilknyttet specifikke aktiver skal gemmes i databasen og nemt kunne findes.
•  
• Apps til iOS og Android, som viser præstationsindikatiorer på et overordnet niveau, skal understøttes.