Bilag til avtale om løpende tjenestekjøp over internett
Bilag til avtale om løpende tjenestekjøp over internett
Statens standardavtaler for IT-anskaffelser bilag til SSA-L - versjon 2018
Bilag til SSA-L
Bilag til SSA-L – Avtale om løpende tjenestekjøp over internett– versjon 2018
Bilag 1: Kundens kravspesifikasjon 3
Bilag 2: Leverandørens beskrivelse av tjenesten 4
Bilag 3: Plan for etableringsfasen 8
Bilag 4: Tjenestenivå med standardiserte kompensasjoner 9
Bilag 5: Administrative bestemmelser 12
Bilag 6: Samlet pris og prisbestemmelser 13
Bilag 8: Endringer av tjenesten etter avtaleinngåelsen 15
Bilag til SSA-L – bilag 1
Bilag 1: Kundens kravspesifikasjon
Avtalens punkt 1.1 Avtalens omfang
Avtalen gjelder løpende levering av programvaretjenester for et ‘Datastyrt Renholdsprogram’. Det er forstått at programvaretjenesten kan leveres i ulike tilgangsformat f. eks. via en web- leser, applikasjon for nettbrett/mobiltelefon eller eventuelt lokal installasjon. Avtalen omfatter også drift og vedlikehold/support av den aktuelle tjenesten. Avtalen vil også omhandle en eventuell etableringsfase med oppsett av kundespesifikke data og opplæring av brukere.
Det er estimert 120 unike brukere av programmet hvorav 120 brukere vil kunne benytte programmet samtidig. Det er et samlet bygningsareal(formålsbygg) på cirka
230 000 kvadratmeter, hvorav cirka 180 000 kvadratmeter krever renhold. Mulighet og pris for skalering av brukere og bygningsmasse er beksrevet i avtalen.
Opsjoner
I tillegg til Universitetssykehuset i Nord-norge HF, skal det være en opsjon for Nordlandssykehuset HF, Finnmarkssykehuset HF og Helgelandssykehuset HF å benytte seg av avtalen hvis ønskelig. Ved eventuell tiltredelse av en eller flere av de overnevnte helseforetakene, skal priser oppgitt i denne avtalen kunne benyttes. Nye tiltredelser fordrer egne utgaver av SSA-L for hver tiltredende kunde. Det presiseres at opsjonelle
kunder i stedet for å benytte seg av opsjonen, kan kan velge å gjennomføre en egen anskaffelse av tilsvarende tjeneste.
Anslag omfang for opsjonelle kunder: Finnmarkssykehuset HF: 50 unike brukere Nordlandssykehuset HF: 50 unike brukere Helgelandssykehuset HF: 50 unike brukere
Bilag 2: Leverandørens beskrivelse av tjenesten
Avtalens punkt 2.1. Tjenesten
Datec Norge AS vil levere et «nøkkelferdig» produkt i henhold til oppdragsgivers forespørsel. Dette gjelder produktleveranse fra A til Å, samt implementering, opplæring og oppfølging.
Utover dette er tjenesten beskrevet i medfølgende vedlegg til denne besvarelse.
Det stilles ingen krav til Kundens tekniske plattform utover det som er beskrevet i Vedlegg C_IT teknisk beskrivelse CleanPilot.
Avtalens punkt 6.2 Personopplysninger
I forhold til personopplysninger og GDPR, henvises det til vår personvernerklæring i følgende link:
Det er en innebygd GDPR godkjenning i systemet som alle brukere må godkjenne før bruk av systemet. Administrator har oversikt over hvem som har godkjent og ikke til enhver tid.
Kravspesifikasjon | Tilbyder: | Datec | ||||
Ref. | Oppdragsgivers beskrivelse av krav | Krav type | Tildelingskriterium | Svar | Tilbyders beskrivelse/henvisning til nærmere beskrivelse | |
Ja | Nei | |||||
Tema: Programfunksjonalitet | ||||||
1 | Programmet skal være et brukervennlig planleggingsverktøy for renholdsoppgaver. | O | X | Se vedlegg A for nærmere beskrivelse | ||
2 | Det skal være mulig å opprette renholdssoner som kombinerer flere bygg og etasjer. | O | X | Xxxxxxxxxxxxx kan settes opp etter egne ønsker. Man kan sette dette på tvers av lokasjoner, bygg og etasjer. Her kan man fleksibelt velge etter eget ønske. | ||
3 | Programmet skal inneholde en tegningsoversikt over rom. | O | X | Systemet er tegningsbasert og viser tegninger med fargekoder pr rom. Se vedlegg A for visuell visning. | ||
4 | Det bør være mulig å legge inn planer for periodisk renhold. Beskriv kort løsningen. | EK | Funksjonalitet | X | I CleanPilot Plan kan man lage egne periodise planer som differensierer seg fra den daglige planen. Denne vil legge seg i tillegg til den daglige planen. Renholder vil innen en gitt tidsfrist (for eksempel uken før) få opp et varsel i det aktuelle rommet om at tidsfrist på den periodeiske oppgaven nærmer seg. | |
5 | Det bør være mulig å legge inn planer for renhold utenom fast plan (f.eks helgevask, byggevask, smitterenhold). | EK | Funksjonalitet | X | I systemet kan man lage akkurat de planer man ønsker, såkalte Smartplaner. Disse kan gå paralelt og eventuelt legges inn med start og slutt dato. | |
6 | Faste renholdsplaner bør kunne enkelt endres (f.eks ved lavdriftsperioder eller lignende). Beskriv hvordan dette gjøres. | EK | Funksjonalitet | X | Man kan i systemet lage flere planer som beskrevet over. Disse kan setts med eventuelle start og slutt datoer eller kobles inn ved ønske. Typiske planer i sykehusdrift kan være beredskapsplaner ved for eksempel smitteutbrudd. Planer kan som tidligere beskrevt gå paralelt med hverandre ved ønske. | |
7 | Det skal være mulig å midlertidig stenge av rom og dermed automatisk unnlate de i renholdsplaner. | O | X | Man kan enkelt "slå av " renhold i et rom og denne tas da ut av renholdsplanen. | ||
8 | Det skal være mulig å angi ulike profiler for rom - ulike romprofiler krever ulike renholdsprosdyrer. | O | X | Man kan legge inn NS - Insta 800 profiler for det enkelte rom, med dertil tilhørende renholdsprosedyrer. Datec Norge AS jobber også med tilrettelegging for andre kvalitetssystemer og nye standarder vil ha mulighet for funksjonalitet i systemet. | ||
9 | Det bør kunne tas ut en prognose for ressurbehov. | EK | Funksjonalitet | X | Med systemet følger et standard nøkkeltallsett. Man kan også importere egne nøkkeltall. Ut i fra disse nøkkeltallene, samt blant annet frekvenser vil man få en oversikt over ressursbehov på de enkelte områdene. | |
10 | Det bør kunne fremstilles en oversikt over kapasitet (f. eks areal/time) per renholder. | EK | Funksjonalitet | X | I CleanPilot Plan kan man få ytelse pr rom, tid pr område(renholder), tid pr rom, tir pr renholdsplan (smartplan) og tid pr lokasjon. Man jobber fortsatt med utvikling av dette, men da med fokus på behovsbasert renhold og dynamiske prosesser. Dette vil være noe annerledes enn tradisjonell planlegging, med blant annet vektet nøkkeltall ut i fra frekvenser. Denne leveransen leveres også med Xxxxxxxx Xxxxx ved ønske og her har man et titalls rapporter som går på etterspurt funksjonalitet. | |
11 | Programmet må ha funksjonalitet for kontroll mot NS-INSTA 800 av rom/flater. | O | X | Systemet er integrert med et fullstendig verktøy for utførelse av Insta 800 – kontroller. Funksjoner for dette er: •Sette opp kontroller •Fleksibelt velge ulike stratifiseringsvalg per kontrollprosjekt •Kan sette opp doble stikkprøvekontroller •Fordele kontrollarbeidet mellom flere kontrollører (også renholdere) •Få automatiske stikkprøveutvalg i interaktive kontrollplaner på nettbrettet •Gjennomføre stikkprøvekontroll på nettbrettet med enkel registrering som inkluderer status på rommet (om det er rengjort, om det har rengjøring i dag, estimert rengjøringstidspunkt etc) •Automatisk få generert ferdig kunderapport ved avslutning av kontroll. Når siste rom på kontroll er gjennomført, vil en rapport generes automatisk. Denne kan sendes til kunde pr mail eller kunden vil kunne få denne automatisk i sin kundeportal. •Ha fullstendig historikk liggende på utførte og pågående kontroller | ||
12 | Renholder bør kunne utføre egenkontroll mot NS-INSTA 800. | EK | Funksjonalitet | X | Systemet er laget for at renholder skal kunne adoptere kunnskap av Insta800 gjennom verktøyet i arbeidsdagen. Systemet er utstyrt med hjelpefunksjoner og beskrivelser av Insta800, samt en egenkontroll som gir renholder umiddelbar tilbakemelding på om rommet er i henhold til avtalt kvalitet eller ikke. Dette hjelpeverktøyet er visuelt og kalles InstaMeteret. Dette er med på å trygge renholdere i det å levere riktig kvalitet i henhold til avtale. | |
13 | Programmer bør kunne vise en oversikt over områder som ikke er godkjent på basis av registrerte NS-INSTA 800 kontroller. | EK | Funksjonalitet | X | Systemet vil automatisk etter gjennomførte kontroller vise status pr rom eller område. Dersom et rom ikke er godkjent i henhold til avtale, vil dette rommet være markert med rød farge. Godkjente rom vises som grønne. | |
14 | Det bør være mulig å hente ut historikk/oversikt over tidligere gjennomførte NS-INSTA 800 kontroller. | EK | Funksjonalitet | X | All historikk/oversikt over tidligere NS Insta 800 - kontroller ligger lagret i systemet på de aktuelle områdene. Disse vil også vøre tilgjengelige i portaler for den aktuelle kunde. Det er også analysefunksjonalitet i systemet for historikk på gjennomførte NS Insta 800 - kontroller. | |
15 | Det bør være mulig å beregne tidsbruk for hver enkelt renholdsoppgave. | EK | Funksjonalitet | X | Med systemet så følger et nøkkeltallsett som sier noe om tidsbruk for hver enkelt renholdsoppgave. Man kan benytte seg av medfølgende nøkkeltallsett | |
16 | Det bør være mulig å ta ut statistikk/logg over utført renhold. Data bør kunne eksporteres ut i excel-format for etterbehandling. | EK | Funksjonalitet | X | I CleanPilot Direct så har man "live" status på utført renhold. Man kan se dette for hele organisasjonen, for et område, for et bygg, for en etasje eller kun for et rom. Dette kan vises i liste og eksporteres til Excel. Man kan også se dette visuelt. I tegnig kan man også velge valgt dato tilbake i tid for å se utført arbeid og ikke utført arbeid. Dette vil vises i tegning som henholdsvis røde og grønne rom. | |
17 | Det bør kunne legges inn tidsfrister for når renhold skal være utført | EK | Funksjonalitet | X | Man kan sette tidsfrister på når renhold skal være ytført. Dette kan være spesifikke tidspunkt som man setter på forhånd. Det kan også være en tidsfrist med tid etter at en bestilling er "trigget". Eksempel kan være at når det kommer bestilling på en smittevask, skal denne utføres for eksempel innen 30 minutter. Dette predefineres i systemet i henhold til inngått avtale mellom renholdsavdeling og kunde. |
18 | Det skal være mulig å ta ut overordnede nøkkeltall (f. eks. av areal/time). Nøkkeltall skal kunne sorteres på ulike lokasjoner/soner. | O | X | Med systemet følger et standard nøkkeltallsett. Man kan også importere egne nøkkeltall. Nøkkeltallene kan følge lokasjoner, soner(områder), forskjellige renholdssoner etc. | |||
19 | Nøkkeltall bør kunne sammenlignes med tall fra andre brukere av lignende system. Beskriv hvordan nøkkeltall kan brukes for intern og ekstern benchmarking | EK | Funksjonalitet | X | Man kan eksportere ut alle nøkkeltallsett fra CleanPilot Plan og benchmarke disse mot andre brukere som også har eksportert sine xxxx.Xxx kan også importere andre sine organisasjoner sine nøkkeltallsett og buke dette i egne planer for å se på forskjeller. På samme måte vil man kunne gjøre dette på tvers av lokasjoner, områder etc i egen organisasjon.Datec Norge AS har egne nettverksgrupper for brukere av systemet innen helsefortak i Norge. Disse sitter og benchmarker seg mot hverandre og alle kommend ekunder av Datec Norge AS blir tildelt en plass i en slik nettverksgruppe. | ||
20 | Programmet bør ha en kundeportal for å melde inn ad-hoc behov som kommer utenom fast renholdsplan. Kundeportalen bør i stor grad kunne tilpasses ulike kunder. Beskriv kort denne løsningen. | EK | Funksjonalitet | X | CleanPilot Value er en egen kundeportal som renholdsleverandør kan gi til den respektive kunde. Her setter man opp hvilke muligheter den respektive kunde skal ha. Dette kan differensieres fra kunde til kunde. Mn kan legge inn ad hoc bestillinger, fremtidige bestillinger og repeterende bestillinger. Dette kan gjøres i liste eller tegning. Videre vil renholdsleverandør kunne gi egen portal til den enkelte kunde med diverse visninger i henhold til leveranse. Se vedlegg A, side 6. | ||
21 | Det bør være mulig å eksportere ut faktura/timeforbruk over utførte jobber (spesielt med tanke på ad-hoc behov utenom fast renholdsplan). Beskriv kort prosess og hvilke eventuelle filformat data kan eksporteres til. | EK | Funksjonalitet | X | I CleanPilot Direct kan man enkelt eksportere ut all data til Excel eller pdf. Man kan her få ut rapporter for all bygningsmasse eller helt ned til romnivå. Man kan også segmentere dette på hvem som har vestilt en oppgave. Eksempel kan være at man skal fakturere en spesiell avdeling for ekstra renhold og man filtrerer da enkelt ut de oppgave som er bestilt av repektive avdeling( eller person) i en gitt tidsperiode. Dette kan også gjøres på ekstraoppgaver som ikke er bestilt av kunde, men som renholder har myndighet til å dokumentere selv som ekstra renhold utover inngått avtale. | ||
22 | Det skal være mulig for renholdere å kvittere for utført arbeid. | O | X | Tankesettet i CleanPilot for renholder er at de skal kvittere ut og dokmnetere alle oppgaver de gjør. Dette være seg de planlagte oppgavene, men også det som gjøres i tillegg av renholder. Dette for å få oversikt over faktisk levereanse, som vil gi god dokumentasjon på fremtidig ressursbehov og eventuelle justeringer av renholdsplaner. | |||
23 | Det bør være mulig å filtrere rom basert på ulike kriterier (f.eks kvalitetsprofil, renholdsfrekvens etc.). | EK | Funksjonalitet | X | I systemet så kan man få tegningsvisning på frekvens, kvalitetsprofil i henhold til NS Insta 800, historisk status dagplan og områdeinndeling. | ||
Tema: Brukergrensenitt | |||||||
24 | Programmet skal kunne kjøres via mobile enheter som nettbrett eller mobiltelefon | O | X | Systemet er utviklet for for iPad (IoS) og kan brukes på iPad og iPad Mini. | |||
25 | Det skal være mulig for flere brukere å benytte samme mobile enhet. | O | X | Hver bruker vil få egen innloggingsidentitet og kan fritt benytte hvilket som helst nettbrett i organisasjonen for å logge sseg inn på sin egen bruker. | |||
26 | Programmet bør inneholde en hjelpefunksjon tilgjengelig for renholder. | EK | Funksjonalitet | X | I systemet er det egne opplæringsfilmer som er intuitive og lett tilgjengelig for renholder. Det er også en "direkte link" til utviklingsavdelinge hos leverandør ved tekniske problem. Egen opplæringsfunksjonalitet i NS Insta 800 er også tilgjengelig for renholder. Videre kan organisasjonen fritt "linke" inn den informasjon man ønsker i form av web-linker inn i hvert enkelt rom i systemet, slik at renholder får riktig informasjon på riktig plass. Dette kan være arbeidsprosesdyrer, bruk av maskiner etc. | ||
27 | Tekst i programmet skal være på norsk. | O | X | Prgrammet leveres på norsk. Det finnes også svensk, dansk og engelsk versjon. | |||
28 | Tekst i programmet bør kunne endres til engelsk | EK | Funksjonalitet | X | Systemet kan leveres med engelsk versjon. | ||
29 | Det bør være mulig å legge inn renholdsprosedyrer som et oppslagsverk i programmet – enten som tekst eller video. | EK | Funksjonalitet | X | I systemet er det en såkalt "Inweb" funksjon som gjør at man kan speile alt som ligger på internett/intranett inn i systemet og inn i det aktuelle rom. Dette kan være filmer, tekst, prosedyrer etc. I tillegg har man en "gul lapp" funksjon, hvor tekst kan "poppe" opp på skjermen til renholder ved klikking i det aktuelle rommet. Dette er ment som viktig informasjon som renholder ikke skal kunne unngå å legge merke til. | ||
30 | Rom i tegninger bør være klikkbare på mobile enheter, og renholdsprosedyrer bør være synlig og intuitivt tilgjengelig for renholder for hvert rom (dette er spesielt viktig for unike som som krever spesialprosedyrer). | EK | Funksjonalitet | X | For at renholder skal dokumenetere arbeid i CleanPilot GO, så må renholder dobbeltklikke seg inn i rom på tegningen for å få opp dagens oppgaver og mulighet for dokumentasjon. Her vil også eventuelle prosedyrer for den enkelte romtype være tilgjengelig. Se Vedlegg A_pkt.4.1 og 4.1.1. for mer informasjon. | ||
31 | Renholder bør se en kartoversikt med fargekoder for aktuell renholdsplan. | EK | Funksjonalitet | X | Renholder får en kartoversikt over egne områder og eventuelt over hjelpeområder. Rom kan være blå (renhold i dag), lyseblå (fleksiplan med renhold denne uke, men ikke spesifisert dag), grønn (renhold utført), lilla (hjelpeområde med renhold i dag), lyse lilla(hjelpeområde fleksiplan), mørke blå (bestilling med tidsfrist). | ||
32 | Programmet skal inneholde en løsning for kommunikasjon mellom renholder og leder. | O | X | Det finnes en egen meldingstjeneste i systemet. Her kan man kommunisere med leder og eventuelt mellom renholdere for effektiv oversendelse av informasjon. Meldingene grupperer seg i forhold til de samtalene man har hatt, på samme måte som en smarttelefon. Videre ser også avsender om melding er lest av mottaker eller ikke for å sikkerstille at informasjonen har blitt lest av rette vedkommende. Man kan også sende meldinger som leder fra webportal til renholder på nettbrett. | |||
33 | Kommunikasjonsløsningen bør være så enkel og intuitiv som mulig. Beskriv løsningen. | EK | Funksjonalitet | X | Se pkt.32. | ||
34 | Det skal være mulig for renholder å melde inn avvik på rom (f. eks sperrede rom, nye rom, etc.). | O | X | Se Vedlegg A-pkt 4.1.2. | |||
35 | Avviksmelding bør være så intutiv som mulig. Beskriv løsningen. | EK | Funksjonalitet | X | Se Vedlegg A_pkt.4.1.2 | ||
36 | Programmet bør kunne vise en oversikt over daglig progresjon og status av renholdsplaner og -oppgaver. | EK | Funksjonalitet | X | Renholder kan se sin egen renholdsprogresjon, se beskrivels pkt.37. Videre kan progresjon på påbegynt renholdsplan vises i webportal for leverandør for hele organisasjonen, Bygg, område, etasje og ned på romnivå. Man ser progresjon på nivået man selv ønsker. Dette kan også gjøres tilgjengelig for kunde gjennom kundeportal. Se Vedlegg A_pkt.3.1 og 4.2. | ||
37 | Oppgavene i en renholdsplan vil kunne utføres i forskjellig rekkefølge. Renholder bør ha mulighet til å se hvor mye av en påbegynt renholdsplan som allerede er utført. Beskriv hvordan dette kan gjøres. | EK | Funksjonalitet | X | Renholder vil ved start av en arbeidsdag få oversikt over hvor mange rom som skal rengjøres på det respektive område/etasje. Dette markeres med tall på den spesifikke etasje. Når et rom kvitteres ut blir det grønt (fra blått) og tallet med antall rom vil da minke med ett. Når hele område/etasjen er ferdig vil tallet stå i "0" og få en grønn markering. Dette gjelder også hjelpeområder man eventuelt har tilgang til. | ||
Tema: IKT og etablering av programmet |
38 | Leverandør skal tilby en supportavtale. | O | X | Datec Norge AS har egne supportavtaøer og dette er an del av dette tilbudet. | ||
39 | Software-oppdateringer som retter feil i tidligere utgaver skal leveres vederlagsfritt og uoppfordret. | O | X | Alle feilrettinger og oppgraderinger av valgt programvare er inkludert via abonnemnetetskostnadene. Disse sendes kunde uoppfordret. | ||
40 | Utstyret skal leveres med nyeste versjon av software. | O | X | Kunden har til enhver tid tilgang til nyeste versjon av software og ved innstallasjon vil nyeste proramvare benyttes. | ||
41 | Software-oppdateringer og -oppgraderinger skal dokumenteres og informeres om før de innføres. | O | X | Software-oppdateringer og oppgraderinger varsles kunde i god tid før de innføres. Det sendes ut også dokumentasjon på hvilke endringer som er gjort i softwaren. | ||
42 | Løsningen skal kunne håndtere minimum 120 påloggede brukere samtidig (med dette menes sum av renholdere, ledere og kunder). | O | X | Løsningen hånfterer et større antall enn etterspurt her. Den største kunde har ca. 500 brukere logget på samtidig. | ||
43 | Løsningen bør kunne skaleres for en større brukermasse ved behov. | EK | Funksjonalitet | X | Systemet kan skaleres til betraktelig høyere brukere enn etterspurt i dette anbud. | |
44 | Plantegninger i dwg-format skal kunne importeres inn i programmet. | O | X | Denne leveransen leveres også med Xxxxxxxx Xxxxx som et alternativt arbeidsverktøy. Her er det støtte for import av DWG/IFC. Det jobbes med import av DWG/IFC i CleanPilot Plan i utviklingen av systemet, men i en overgangsfase kan kunden bruke Jonatrhan Clean. Datec Norge AS gir også kunden til å ta dette via oss som leverandør, slik at de sender DWG tegninger til oss og vi klargjør de og legger de inn i driftssystemet. | ||
45 | Eksisterende renholdslister i excel-format bør kunne importeres inn i programmet. Beskriv hvordan import av eksisterende lister gjøres. | EK | Funksjonalitet | X | Denne leveransen leveres også med programvare Xxxxxxxx Xxxxx som enkelt kan importeree romlister via excel. Listene importeres ved å lage kolonneroppsett som er importvennlig for Xxxxxxxx Xxxxx. Man tar da utgangspunkt i Romnr, romnummer, etg, m2, Insta osv. Planer i listeform vil da tilgjengeliggjøres. Dette er under utvikling i CleanPilot Plan og Datec Norge AS kan gjøre denne importen via Xxxxxxxx XXxxx dersom kunden ønsker dette i påvente av funksjonaliteten i CleanPilot Plan. | |
46 | Oppetid på program bør være så høy som mulig. Oppgi gjennomsnittelig nedetid eller lengde på perioder med nedsatt responstid per år. | EK | Funksjonalitet | X | Systemet har ikke noe generell nedetid. Dette skyldes at oppdateringer av systemet skjer ved nedlasting av ny versjon av App eller at systemet oppgraderes på web umiddelbart. Det har vært en større oppgradering inneværende år, hvor servere måtte oppgraderes grunnet klargjøring for sensorteknologi. Dette ble utført en søndag kl.17-20. Systemet for renholder kunne fortsatt brukes, grunnet at systemet fungerer offline. Oppetid på servere fra AWS (Amazon) og Smart IT ligger på 99,8%. | |
47 | Oppgi gjennomsnittelig responstid på telefonsupport i timer eller minutter. | EK | Funksjonalitet | X | Vi i Datec Norge AS etterstreber å ha en responstid på = i forhold til telefonsupport. Ved stor pågang vil kunden ha mulighet til å benytte seg av support via mail og vår chatte funksjon på web. Generell responstid på telefonsupport ligger innenfor 1 minutt, men kan være avvikende ved mange henvendelser samtidi. | |
48 | Programmet bør være delvis operativt for brukere selv ved midlertidig tap av nettverkstilgang. Beskriv løsning. | EK | Funksjonalitet | x | Systemet er laget slik at oppleves likt for bruker selv om systemet er offline. Man trenger i utgangspunktet kun nettdekning ved oppstart av arbeidsdagen slik at man får lastet ned dagens oppgaver. Systemet vil etter å ha vært i offline modus automatisk synkronisere lagret data ved overgang til online. Dette gjelder for App for renholder/leder og ikke for portaler som er webbasert. | |
49 | Leverandør skal tilby en ferdig løsning for bruk inklusiv opplæring og kundespesifikt oppsett. | O | X | I dette tilbudet leverer Datec Norge AS et "nøkkelferdig" produkt i henhold til kundens ønsker beskrevet i denne forespørsel. Ved eventuell valg av våre løsninger, vil vi ved en kontraktsinngåelse samkjøre en implementering med kunde for en best mulig utnyttelse av ressurser hos kunde og oss. Her vil vi legge frem en "beste praksis" som vi har brukt ved de fleste helseforetak i Norge som er våre kunder. | ||
50 | Programmet bør være så selvforklarende som mulig. Gi en oversikt over estimert omfang på opplæring og kurs. | EK | Funksjonalitet | X | Se Vedlegg B_Implementering | |
51 | En etableringsfase bør være så smidig som mulig. Gi en kort beskrivelse av estimert omfang på kundespesifikt oppsett og etableringsfase. | EK | Funksjonalitet | X | Se Vedlegg B_Implementering | |
52 | Det ønskes gjennomgang av aktuelle lisenstyper/mulighetsrom innenfor lisenstyper/prismodell før kontraktskriving ved behov for endring som avklares etter utsendt konkurranse og innsyn i kostnader. | I | X | Som forståelse av spørsmål, skal dette sees på ved en eventuell inngåelse av kontrakt og kommenteres ikke grunnleggende her. Til info finnes følgende lisenser i CleanPiot konseptet: CleanPilot Go - for renholder. CleanPilot GO - for leder. CleanPilot Direct - for leder/administrasjon. CleanPilot Value - for kunde/bruker. CleanPilot Plan - for planlegger/avdelingsansvarlige. Videre er Datec Norge AS sine prismatrise bygget opp på prinsippet av at jo høyere volum av lisenser, jo lavere enhetspris. | ||
53 | Det ønskes en gjennomgang av eventuell nødvendig infrastruktur eller programvare utover installert nettleser for å kjøre programmet. | I | X | Se Vedlegg_It teknisk beskrivelse |
Bilag til SSA-L – bilag 3
Bilag 3: Plan for etableringsfasen
Etter avtaleinngåelse, vil det sannsynligvis være behov for å kjøre en etableringsfase før systemet er klart til bruk. Hovedaktivitetene i etableringsfasen vil være:
- Innlasting av kundespesifikke data (f. eks. plantegninger og renholdsprosedyrer) inn i leverandørens lagringsløsning.
- Eventuelle mindre tilpasninger av grensesnitt som vil være spesifikke for kunde.
- Testing av system i samråd med kunde.
- Opplæring av administrator/superbruker til forventet nivå.
I denne fasen vil interne ressurser fra Kunden være tilgjengelige, og det bes om at Leverandørens kostnader knyttet til etableringen fylles ut i vedlegg 3 – Prisskjema.
Etableringsfasen skal ha en varighet på maksimum 30 dager.
For nærmere beskrivelse av etableringsfasen, se vedlegg B - implementering.
Bilag til SSA-L – bilag 4
Bilag 4: Tjenestenivå med standardiserte kompensasjoner
SLA – Service Level Agrement
Følgende support er omfattet av avtalen:
1. Supporttjenester
Supporttjenestene består av bistand ved følgende situasjoner som kan oppstå ved bruk av Programvaren (CleanPilot Server eller CleaPilot Go, CleanPilot Direct og CleanPilot Value);
• Spørsmål knyttet til bruk av Programvaren
• Spørsmål i forbindelse med installasjon og oppgraderinger av Programvaren
• Spørsmål i forbindelse med drift av Programvaren
• Hjelp til løsning ved andre feilsituasjoner som oppstår under bruk av Programvaren
Datec vil bestrebe å besvare henvendelsene så raskt som mulig og i samsvar med responstidene. Supporten skal i hovedsak rutes gjennom 1 hovedkontakt for support hos kunden, men kan benyttes direkte av de brukerne hos kunden som har brukerlisenser CleanPilot Go leder/ CleanPilot Direct.
Supporten leveres på følgende måter:
• Telefonsupport - pr telefon x00 00000000 innvalg 2 innenfor normal kontortid kl. 0800-1600 mandag – fredag, unntatt offentlige norske fri- og helligdager samt jul- og nyttårsaften.
• Innmelding pr mail til xxxxxxx@xxxxx.xx. Saken vil behandles etter åpnings- og responstid beskrevet i pkt.3
• Chat
2. Organisering av og betingelser for support
Levering av supporttjenestene skal foregå etter følgende retningslinjer og betingelser:
• Kunden skal utpeke en supportkontakt som skal fungere som kundens hovedkontaktpunkt mot Datec.
• Kunden lager liste over de personer i egen organisasjon (de brukerne hos kunden som har brukerlisenser CleanPilot Go leder/ CleanPilot Direct) som skal ha tilgang til support tjenesten fra Datec. Det er kun disse brukere som på forhånd er skriftlig navngitt av Xxxxxx som kan kontakte Datec med forespørsler om support.
• Kunden skal etter beste evne forsøke å identifisere årsaken til problemet, og dele nødvendig informasjon med Datec. Det er en forutsetning for Datecs forpliktelser til å yte support at feilen eller problemet slik det oppfattes av Kunden lar seg gjenskape/rekonstruere.
Bilag til SSA-L – bilag 4
• Datec forbeholder seg retten til å kreve at Kunden oppgraderer til en nyere eller siste versjon av Programvaren dersom dette vil løse problemet.
• Datec forbeholder seg retten til å fakturere Xxxxxx for brukt tid samt å anbefale kurs eller konsulenttjenester, dersom supporten tar form av ren opplæring. Supporten og løsning av feil kan innebære at Kunden må endre rutiner eller prosesser for å omgå problemet.
• Xxxxxx skal ha gyldig lisensavtale med Datec for den relevante Programvaren som ønskes supportert og Xxxxxx skal ikke være i mislighold etter noen avtale med Datec.
• Bistand utover det supporten dekker faktureres etter de til enhver tid gjeldende satser for konsulentbistand.
• Når det ansees nødvendig av Datec må Kunden samarbeide med Datec og utføre handlinger i eller med Programvaren etter veiledning fra Datec for å rekonstruere, feilsøke eller løse problemet.
• Kunden plikter vederlagsfritt å stille kompetent personell og ressurser til rådighet dersom Datec ber om det og Kunden skal legge forholdene til rette for at Datec skal få utført sine plikter, bl.a. ved å gi Datec nødvendig tilgang til sine lokaler
3. Åpningstider og responstider
Kunden skal melde feil uten ugrunnet opphold. Når Datec har verifisert at det er en feil som faller innenfor Supportavtalen og at problemet lar seg gjenskape/rekonstruere vil Datec klassifisere feilen på følgende måte:
Nivå | Kategori | Beskrivelse |
I | Alvorlig feil | Feil som medfører at Programvaren ikke responderer, at data går tapt eller at funksjoner som er vesentlige og kritiske for Programvaren ikke virker i samsvar med dokumentasjonen. |
II | Mindre alvorlig feil | Feil som fører til at funksjoner som er sentrale for Programvarens samlede funksjonalitet ikke virker i samsvar med dokumentasjonen og som det er tids- og ressurskrevende å omgå. |
III | Lite alvorlig feil | Feil som fører til at enkeltfunksjoner ikke virker i samsvar med dokumentasjonen, eller som Kunden relativt lett kan omgå. |
IV | Annet | Andre forhold og spørsmål |
Når feilen er klassifisert av Datec, vil Datec sende en bekreftelse på mottak av feilmeldingen til Kunden. Tidspunktet for sending av slik melding er utgangspunktet for beregning av starttidspunktet for Datecs responstid. Responstider for de ulike feilnivåene er:
1 1. Januar, Skjærtorsdag, Langfredag, Første Påskedag (søndag) , Xxxxx Xxxxxxxx, 1. mai, 17. mai, Xxxxxx Xxxxxxxxxxxxxx, Første Pinsedag (søndag), Xxxxx xxxxxxxx, 25. desember og 26. desember.
Bilag til SSA-L – bilag 4
Nivå | Kategori | Responstid |
I | Alvorlig feil | Arbeidet med å utbedre feilen eller løse problemet skal være påbegynt innen 7 timer etter at Datec har sendt Kunden bekreftelse på mottak og klassifisering av feilmeldingen. |
II | Mindre alvorlig feil | Arbeidet med å utbedre feilen eller løse problemet skal være påbegynt innen 21 timer etter at Datec har sendt Xxxxxx bekreftelse på mottak og klassifisering av feilmeldingen. |
III | Lite alvorlig feil | Ingen krav til responstid men Datec skal påbegynne arbeidet med å forsøke å løse feilen inne rimelig tid hensyntatt sakens natur og alvorlighetsgrad. |
IV | Annet | Ingen krav til responstid. |
Ved beregningen av responstid, skal fristen for påbegynnelse av feilretting kun anses å løpe innenfor Åpningstiden. Når feilretting er påbegynt, vil Datec informere Xxxxxx og fristen for responstid blir avbrutt. Hvis igangsetting av feilretting ikke kan skje grunnet forhold som anses å ligge utenfor Datecs kontroll, inkludert men ikke begrenset til forhold på Kundens side, herunder Kundens driftspartner, suspenderes Datecs forpliktelser så lenge forholdet varer og kravene til responstid gjelder ikke. Nødvendig tid for arbeid med utbedring av meldte feil vil variere og være avhengig av den aktuelle feils alvorlighetsgrad, kompleksitet og omfang, samt eventuell bistand fra Kunden selv og tredjeparter. Datec kan derfor ikke garantere når eller om feil vil bli utbedret. Datec vil imidlertid, så langt mulig og hensiktsmessig, holde Kunden orientert om status for det pågående arbeid.
Nye feilrettede versjoner av CleanPilot App distribueres gjennom Appstore, vil normalt være begrenset at behandlingstid hos Apple, og vil være avhengig av godkjenning av Apple før den blir tilgjengelig på Appstore. Datec har ikke kontroll over behandlingstiden hos Apple. Normalt(3 dager til 2 uker)
Nye feilrettede versjoner av CleanPilot Direct og CleanPilot Value, kan gjøres løpende og så snart Datec har rettet feilen.
Ny feilrettede versjoner av Xxxxxxxx Xxxxx varsles direkte til kunden gjennom e-mail og link til nedlastingsfil, så snart Datec har rettet feilen
Bilag til SSA-L – bilag 5
Bilag 5: Administrative bestemmelser
Avtalens punkt 1.5 Partenes representanter
Fra Kunde:
Xxxxx Xxxx Xxxxxx, Universitetssykehuset i Nord Norge HF Xxxxx.Xxxx.Xxxxxx@xxx.xx
For avviksmelding på avtale: xxxxxxxxxxxxxxxxx@xxxxxxxxxxxxxx.xx
Fra leverandør:
Xxxxxx Xxxxxx
Senior Key Account Manager xxxxxx@xxxxx.xx
930 06 227
Avtalens punkt 5.1 Varighet
Avtalen skal ha en varighet på 2 år regnet fra signering. Oppdragsgiver kan deretter forlenge avtalen med inntil 1 år av gangen. Maksimal samlet avtaleperiode er 4 år. Avtalen forlenges automatisk og på likelydende vilkår med mindre Oppdragsgiver tar andre initiativ.
For opsjonelle kunder vil den respektive avtalen gjelde fra signering hos den
opsjonelle kunden. Frist for å tiltre avtalen for opsjonelle kunder er satt til utgangen av år 3 av hovedavtalen for Universitetssykehuset i
Nord-Norge HF.
Statistikk
Leverandøren plikter å utarbeide kvartalsvis statistikk, uten ekstra kostnad for Kunden eller Sykehusinnkjøp HF. Kvartalsvis statistikk utarbeides pr 20.04 (Q1). 05.08 (Q2), 20.10 (Q3) og 20.01 (Q4). Statistikken skal oversendes Sykehusinnkjøp HF uoppfordret innen disse fristene. Statistikk skal vise forbruk og omsetning eks. mva. pr. type tjeneste fordelt på de ulike Kunder. Statistikken skal leveres på den enhver tids gjeldende mal utarbeidet av Sykehusinnkjøp HF. Statistikken skal inneholde alt salg til Kunden, både tjenester som står i prislisten og øvrige tjenester på området avtalen gjelder (spesielt avrop på løpende konsulenttjenester).
Statistikk leveres via Sykehusinnkjøp HF sin portal for statistikkinnlevering (xxx.xxxxx.xx) i Microsoft Excel-format. Brukernavn og passord fås ved henvendelse til xxxxxx@xxxxxxxxxxxxxx.xx. Leverandøren skal i god tid før første innlevering av statistikk sørge for at egen statistikkansvarlig får brukernavn og passord for pålogging. Leverandøren skal straks gjøre seg kjent med portalen og rutinene knyttet til denne, og har selv ansvaret for at innrapporteringen er i tråd med kravene som er stilt. Leverandøren skal oppdatere og holde vedlike kontaktinformasjon slik det fremgår av portalen.
Priser oppgis i NOK og eks. mva.
Som utgangspunkt for prissetting kan det gås ut i fra et omfang ved etablering på 120 brukere ved Universitetssykehuset i Nord-Norge HF, hvorav 120 vil kunne være innlogget samtidig. Det er et samlet
bygningsareal(formålsbygg) på cirka 230 000 kvadratmeter, hvorav cirka 180 000 kvadratmeter krever renhold. Det presieres at prisen som bes oppgitt er basert på et anslag av omfanget og eksakt pris vil kunne bli justert ved avtaleinngåelse i samråd mellom kunde og leverandør.
Det bes om at priser fylles ut i tilgjengelige celler. Vennligst ikke opprett nye rader.
Tilbyders navn
Datec Norge AS
Årlige lisens- og supportkostnader (driftskostnader)
Lisenskostnader oppgitt omfang Evt. grunn-/fastpris supportavtale *
Evt. Årlig tillegg/fratrekk per 10 ekstra/færre samtidige innloggede brukere**
Årlig prisvekst
Forventet årlig prisvekst i prosent
Pris eks. mva per år
Kommentar
kr
kr kr
528 756,00 Inkluderer server, 12 ledere og 108 renholdere, samt fritt bruk for kunder(CleanPilot Value)
26 160,00 Support for 24 t i CleanPilot Plan
33 960,00
kr
3,00 Følger standard KPI regulering (ca. 3%)
* Ved en ren timebasert supportavtale, bes det om at timesatser fylles ut under 'Eventuelle løpende tilleggstjenester'.
** Dette priselementet vil ikke være gjenstand for evaluering. Ved lisensieringsmodeller som tillater ekstra brukere uten pristillegg, bes dette (samt eventuell øvre grense for ekstra brukere uten pristillegg) beskrives i kravspesifikasjonen (krav nr. 43).
Etableringskostnader (engangs)
Etablering/oppsett *
Opplæring/kursing av administrator/superbruker ** Etableringskostnader annet
Pris eks. mva
Kommentar
kr
kr kr
195 000,00 Inkludert innleggelse av 230 000m2 tegninger og eksisterende renholdsplaner
40 000,00 Opplæring 3 dager på 3 lokasjoner
-
* Med etablering, menes blant annet engangs lisenskostnader, bistand til innlasting av tegninger og renholdsprosedyrer, eventuelle kundetilpasninger og testing før drift. Eventuelle reisekostnader og
lignende skal inkluderes i denne prisen.
** Kursing til forventet nivå. Eventuelle reisekostnader og lignende skal inkluderes i denne prisen.
Eventuelle løpende tilleggstjenester *
Konsulenttjenester utvikling/spesialtilpasninger
Pris per time eks. mva Kommentar
kr
1 190,00 Senior konsulent
* Dette priselementet vil vektes i mindre grad enn drifts- og etableringskostnader. Med løpende tilleggstjenester menes "ekstraordinært" arbeid som ikke er dekket av etableringskostnader eller årlige
lisens- og supportkostnader.
Bilag 6: Samlet pris og prisbestemmelser
Priser oppgis i NOK og eks. mva.
OPSJONER
Som utgangspunkt for prissetting kan det gås ut i fra et omfang ved etablering på 50 brukere ved opsjonelle brukere, hvorav 50 vil kunne være innlogget samtidig. Det presieres at prisen som bes oppgitt er basert på et anslag av omfanget og eksakt pris vil kunne bli justert ved avtaleinngåelse i samråd mellom kunde og leverandør.
Det bes om at priser fylles ut i tilgjengelige celler. Vennligst ikke opprett nye rader.
Tilbyders navn
Datec Norge AS
Årlige lisens- og supportkostnader (driftskostnader)
Lisenskostnader oppgitt omfang Evt. grunn-/fastpris supportavtale *
Evt. Årlig tillegg/fratrekk per 10 ekstra/færre samtidige innloggede brukere**
Årlig prisvekst
Forventet årlig prisvekst i prosent
Pris eks. mva per år
Kommentar
kr
kr kr
237 288,00 Inkluderer server, 45 renholdere og 5 ledere, samt fritt bruk for kunder(CleanPilot Value)
26 160,00 Support for 24t i CleanPilot Plan 33 960,00
kr
3,00 Følger standard KPI regulering (ca. 3%)
* Ved en ren timebasert supportavtale, bes det om at timesatser fylles ut under 'Eventuelle løpende tilleggstjenester'.
** Dette priselementet vil ikke være gjenstand for evaluering. Ved lisensieringsmodeller som tillater ekstra brukere uten pristillegg, bes dette (samt eventuell øvre grense for ekstra brukere uten pristillegg) beskrives i kravspesifikasjonen (krav nr. 43).
Etableringskostnader (engangs)
Etablering/oppsett *
Opplæring/kursing av administrator/superbruker ** Etableringskostnader annet
Pris eks. mva Kommentar
kr 39 900,00 Helgelandssykehuset og Nordlandssykehuset benytter i dag systemet og vil ikke måtte betale dette. kr 11 900,00 Kurs pr dag
0,8/m2 Innleggelse av eksisterende tegninger og renholdsplaner
* Med etablering, menes blant annet engangs lisenskostnader, bistand til innlasting av tegninger og renholdsprosedyrer, eventuelle kundetilpasninger og testing før drift. Eventuelle reisekostnader og
lignende skal inkluderes i denne prisen.
** Kursing til forventet nivå. Eventuelle reisekostnader og lignende skal inkluderes i denne prisen.
Eventuelle løpende tilleggstjenester *
Konsulenttjenester utvikling/spesialtilpasninger
Pris per time eks. mva Kommentar
kr
1 190,00 Senior konsulent
* Dette priselementet vil vektes i mindre grad enn drifts- og etableringskostnader. Med løpende tilleggstjenester menes "ekstraordinært" arbeid som ikke er dekket av etableringskostnader eller årlige
lisens- og supportkostnader.
Bilag til SSA-L – bilag 8
Bilag 8: Endringer av tjenesten etter avtaleinngåelsen
Avtalens punkt 1.4 Endringer av tjenesten etter avtaleinngåelsen
Eksempel på endringskatalog:
[Eventuell tekst]
Dette bilaget skal ikke fylles ut før avtaleinngåelse, men må ligge ved selv om det foreløpig er tomt.
Dersom Kunden og Leverandøren har kommet til enighet om en endringsavtale (både i forhold til innhold, eventuelt endring i vederlag og endring i tidsplan), skal endringen (innhold, justert vederlag og justert tidsplan) fremkomme her.
Hver endring skal være underskrevet av bemyndiget representant for partene.
Det er Leverandøren som er ansvarlig for at det føres en fortløpende katalog over endringene som utgjør bilag 8. Leverandøren er også ansvarlig for at Kunden uten ugrunnet opphold gis en oppdatert kopi. Kunden må selv holde oversikt over hvilke endringsanmodninger de har sendt og hvilke endringsoverslag de har mottatt.
Xxxxxx er ansvarlig for at endringene det er anmodet om ikke er i strid med regelverket for offentlige anskaffelser. Endringer som anses som vesentlige vil kunne bli betraktet som en ulovlig direkte anskaffelse. Ulovlige direkteanskaffelser er sanksjonsbelagt med et overtredelsesgebyr på inntil 15 % av den ulovlige anskaffelsens verdi. Kontrakten kan også kjennes «uten virkning»
Endringsnummer | Beskrivelse av endringen samt eventuell vederlagsjustering og justering av tidsplan | Ikraftsettelsesdato |