INNHOLD... 1 BILAG 1 KUNDENS KRAVSPESIFIKASJON...

Størrelse: px
Begynne med side:

Download "INNHOLD... 1 BILAG 1 KUNDENS KRAVSPESIFIKASJON..."

Transkript

1 Innhold INNHOLD... 1 BILAG 1 KUNDENS KRAVSPESIFIKASJON BRUKERE OG BRUKSOMRÅDER... 2 Innledning... 2 Brukerebegreper og organisering av opplæring KRAV TYPE KRAV FUNKSJONELLE KRAV GENERELLE KRAV HOVEDFUNKSJONER KRAV TIL RAPPORTFUNKSJONALITET OG VISUALISERING KRAV TIL BRUKERGRENSESNITT (SØK, RAPPORTERING OG LOGGFUNKSJONALITET) KRAV TIL SYSTEM- OG BRUKERADMINISTRASJON KRAV TIL TILGANGSRETTIGHETER, ROLLER OG BRUKERE KRAV TIL SYSTEMKONFIGURASJON OG SYSTEMADMINISTRASJON YTELSE OG ANTALL BRUKERE TEKNISKE KRAV TIL TJENESTEKVALITET TEKNISKE KRAV, KLIENTER GRENSESNITT IKT-ARKITEKTUR FELLES IKT-ARKITEKTUR DRIFTSMESSIGE FORHOLD KRAV I FORBINDELSE MED TJENESTELEVERANSEN MERKANTILE KRAV KRAV TIL VEDLIKEHOLDSAVTALE/SUPPORT DRIFTSSPESIFIKASJON, OPPLÆRING, KURSING OG DOKUMENTASJON KRAV TIL BISTAND KONSULENTBISTAND OG OPPDRAG BILAG 2 LEVERANDØRENS LØSNINGSSPESIFIKASJON BILAG 3 KUNDENS TEKNISKE PLATTFORM BILAG 4 PROSJEKT- OG FREMDRIFTSPLAN FOR LEVERANSE AV VERKTØY BILAG 5 TESTING OG GODKJENNING BILAG 6 ADMINISTRATIVE BESTEMMELSER BILAG 7 SAMLET PRIS OG PRISBESTEMMELSER BILAG 8 ENDRINGER I DEN GENERELLE AVTALETEKSTEN BILAG 9 ENDRINGER AV LEVERANSEN ETTER AVTALEINNGÅELSEN VEDLEGG

2 Bilag 1 Kundens kravspesifikasjon Målet med avtalen: Avtalen omhandler et verktøy som fremstår som en rapport- og presentasjonsløsning. Overordnet funksjonalitet kan karakteriseres ved: - Rapportene vil inneholde styringsdata på utdanningsområdet på en visualisert måte. - Vise standardrapporter og tilrettelegger for kundens behov for egendefinerte rapporter og ad hoc-rapporter. - er tilrettelagt for kobling og bruk mot flere typer datakilder (kildesystem og datavarehus) Kravene i det følgende er fullstendig med hensyn til funksjonelle og tekniske krav som verktøyet skal tilfredsstille og som leverandøren slik leverandøren har beskrevet i bilag 2 og øvrige bilag har forpliktet seg til. Avtalen skal legge grunnlag for en effektiv og trygg leveranse og gi en ramme for samarbeid mellom kunde og leverandør i etableringsfasen frem til godkjenning og samarbeid knyttet til vedlikehold og mulig utvidet bruk av verktøyet. Innledning 1.1 BRUKERE OG BRUKSOMRÅDER For at leverandøren skal ha en forståelse av Kundens bruk av verktøyer innleder vi her med en beskrivelse av brukerbegreper som Kunden har etablert. Disse brukerne skal forstås hierarkisk slik at brukere med de mest avanserte rettighetene, også har samtlige rettigheter som er mindre avansert. Brukerebegreper og organisering av opplæring Aktører: Personer, enheter eller eksterne systemer som kan defineres med oppgaver/roller i forhold til verktøyet. Konkrete personer eller enheter kan opptre samtidig i roller knyttet til ulike aktører. Roller: I et verktøy kan begrepet roller spesielt knyttes til verktøyets autentiseringssystem, som identifiserer brukere og deres rettigheter. Verktøyet kan ha egne autentiseringssystemer, men må kunne knyttes til institusjonenes ordinære autentiseringssystemer, og brukernes roller bør kunne defineres der. Systemadministrator: Systemadministrator er UTVIKLER for standardrapportene systemet skal inneholde. Systemadministrator har brukerstøtte for institusjonenes superbrukere, og trenger derfor tilgang til data for de institusjonene de skal drive brukerstøtte for. Ekspertbrukere: Det vil være en ekspertgruppe for bruken av verktøyet. Denne vil bestå av et utvalg superbrukere fra 4-6 av institusjonene som bruker verktøyet. Ved behov kan andre institusjonsbrukere inkluderes i gruppen. Deres rolle vil være å definere hvilke rapporter som skal være standardrapporter. Superbruker: Roller skal innehas av en eller et fåtall personer ved den enkelte institusjon. Superbruker er UTVIKLER for internrapporter for institusjonen. og kan utvikle rapporter på vegne av institusjonen. Superbruker har førstelinje-brukerstøtte for brukere på den enkelte 2

3 institusjon. Superbruker skal kun ha tilgang til data fra egen institusjon. Superbruker skal opprette brukere og administrere roller på sin institusjon. Sluttbruker: Verktøyets sluttbrukere. Disse skal kun ha tilgang til ferdigutviklede rapporter. Sluttbrukeren skal ha tilgang til drillfunksjoner i rapportene og skal ha mulighet for å lagre rapportene med ulike utplukk. Det vil være mange ulike kategorier sluttbrukere. Noen vil kun forholde seg til et fåtall rapporter som viser situasjonen på et gitt tidspunkt. Andre brukere vil ha større behov for gode drillfunksjoner og utvalgsparametre. Sluttbruker skal kun ha tilgang til data for egen institusjon. Sluttbruker kan inngå i flere brukergrupper. Organisering av opplæring av personale: Systemadministrator og ekspertgruppe(se bilag 3 for beskrivelse av brukere) hos kunden skal gis nødvendig og tilstrekkelig opplæring i verktøyet til å kunne benytte verktøyet til å utvikle og gjøre tilgjengelig standardrapporter i verktøyet. Likeledes skal opplæringen være slik at de kan ivareta videre opplæring og hensiktsmessig forvaltning av verktøyets funksjonelle innhold. Driftsansvarlig hos kunden for verktøyet gis nødvendig og tilstrekkelig opplæring i de grensesnitt som verktøyet benytter for import og eksport av data slik at de selv kan foreta hensiktsmessig og sikker drift av systemet og aktiv forvaltning av systemets grensesnitt. Superbruker hos kunden vil bli opplært av systemadministratorer og ekspertgruppe hos kunden basert på dokumentasjon av de konfigureringene og rapporter som genereres ved etablering av løsningen. Brukerstøtte: Kunden vil selv etablere brukerstøtte til sluttbrukere, superbrukere og ekspertbrukere. Hvordan dette skal organiseres vil avklares i forbindelse med utrullingen av systemet. 2 Krav 2.1 TYPE KRAV Kravene er enten kategorisert som -krav eller BØR-krav. - : betyr et OBLIGATORISK krav. Svar JA(kravet oppfylles) eller NEI (kravet oppfylles ikke). Krav hvor det eksplisitt etterspørres spesifikasjon/beskrivelse er angitt i kravspesifikasjonen. - BØR: betyr en ØNSKET EGENSKAP. Svar JA (kravet oppfylles) eller NEI (kravet oppfylles ikke). Det er mulig å gi en beskrivelse av hvordan kravet oppfylles og om og evt. når kravet kan bli oppfylt. Krav hvor det eksplisitt etterspørres spesifikasjon/beskrivelse er angitt i kravspesifikasjonen. 2.2 FUNKSJONELLE KRAV Verktøyet skal ha flere bruksnivåer, med ulike behov: - Enkel bruk: Innebærer bruk av ferdige rapporter/dashbord med kun muligheter for å gjøre foreta utvalg (for eksempel å velge år/semester, fakultet/avdeling). - Rapportutvikling: Utvikling av nye rapporter/dashbord/portaler - Administrasjon og installasjon: Installasjon av verktøyet, administrasjon av brukere/roller, oppsett av sluttbrukerlag 3

4 2.3 GENERELLE KRAV Generelle krav ID Krav Verktøyet skal være et standardsystem, Med standardsystem mener vi ferdigutviklede systemer. Standardsystemer kan bestå av ulike moduler som kan berike funksjonalitet, utvide grensesnitt og annet. Det skal gis en tydelig beskrivelse av hvilke elementer som inngår i tilbudet og hvilke elementer eller moduler som kan anskaffes i tilegg Verktøyet må kunne håndtere flere ulike juridiske enheter (institusjoner) Verktøyet må kunne brukes av flere institusjoner som kun har tilgang til institusjonens data og som hver har rettigheter til å opprette brukere, tildele roller og utvikle og distribuere rapporter for egen institusjon. Beskriv løsning. 2.4 HOVEDFUNKSJONER Hovedfunksjoner er rapporter og analyse i systemet. Krav til støtte for hovedfunksjoner ID Krav Det må være mulig å definere og visualisere rapporter for superbruker/systemadministrator som grunnlag for videre analyse. Rapportene skal enten bli tilgjengeliggjort som standardrapport for alle institusjoner, for en enkelt institusjon eller en enkelt sluttbruker/ gruppe av sluttbrukere. Beskriv løsning Beskriv eventuell analysefunksjonalitet i verktøyet BØR Verktøyet skal være rollebasert slik at det kan benyttes av ulike brukerkategorier, f.eks. sluttbrukere og superbrukere. Spesifiser løsning for brukeradministrasjon, opprettelse og administrering av roller, grupper m.m Det skal være funksjonalitet for å vise rapporter på egne websider, portal, dashboard osv. Beskriv løsning. 2.5 KRAV TIL RAPPORTFUNKSJONALITET OG VISUALISERING I verktøyet skal det utvikles standardrapporter i tillegg til at den enkelte superbruker/utvikler skal kunne lage egne rapporter. Her beskrives krav til viktige egenskaper i forhold til rapportene. Krav til funksjoner for rapportgenerering og oppfølging ID Krav Det skal være mulighet for flere grafiske og tabellariske fremstillinger i samme oversiktsbilde. Beskriv løsning Det skal være mulig å fremvise enkeltelementer i hovedtabellen, f. eks topp fem eller lignende. Beskriv løsning Det skal være mulighet for å generere aggregerte rapporter med drill-downeffekt. Beskriv løsning I tilfeller der rapportenes forekomster blir 5 eller lavere, er ikke lenger dataene tilstrekkelig anonymisert og det blir behov for å ivareta dette. Hvilke muligheter finnes i verktøyet for å løse dette? Beskriv løsning. BØR 4

5 ID Krav Beskriv verktøyets sikkerhetsmekanismer for kryptering, anonymisering osv Superbruker/systemadministrator skal kunne velge om valgte filter skal vises for sluttbruker i overskriften i rapporten. Beskriv løsning Rapportgeneratoren må ha funksjon til å velge filter ved hjelp av enkle pek/ klikk eller rullegardinvalg for systemadministrator/superbruker. Dette må også være tilgjengelig for sluttbruker. Beskriv løsning Det må være mulig å lage formatterte rapporter og eksportere disse til Office og HTML. Beskriv løsning Ved eksport til andre standard programpakker som Office, bør man BØR fremdeles kunne benytte rapportens funksjoner Rapportenes SQL-kode må være tilgjengelig for superbruker/systemadministrator. Beskriv løsning Rapportens SQL-kode bør kunne endres av BØR superbruker/systemadministrator. Beskriv løsning Det skal finnes et egnet felt hvor superbruker/systemadministrator kan legge inn beskrivelse av rapporter/dashbord som er tilgjengelig/leselig for sluttbruker. Beskriv løsning Verktøyet skal ha støtte for style sheets /maler, slik at rapporter får et BØR standardisert utseende. Beskriv løsning Verktøyet skal ha et utvalg av diagramtyper. Beskriv utvalget Under forutsetning av at det i løsningen er etablert standarder for presentasjon av rapporter som tabell og grafisk, skal brukere selv kunne veksle mellom grafisk og tabell fremstilling. Beskriv hvorledes dette gjøres Verktøyet bør vise hvilke rapporter/dashbord som er avhengig av et gitt felt BØR (impact-analyse) og hvilke kolonner som er kilder til et element i en rapport/dashbord (data lineage). Beskriv løsning Verktøyet bør kunne schedulere rapporter og dashbord slik at man kan BØR kjøre rapporter til fastsatte tider. Beskriv løsning Verktøyet bør kunne ta i bruk tabellrelasjonene fra kilde. Beskriv løsning. BØR Tabellrelasjonene fra kilde som benyttes av verktøyet bør kunne vises og BØR manipuleres i verktøyet av systemadministrator og superbruker. Beskriv løsning Det må være mulig å dele lokalt utviklede rapportspørringer til andre institusjoner, slik at de kan benytte disse for sine institusjonsdata. Beskriv løsning for distribusjon. 5

6 2.6 KRAV TIL BRUKERGRENSESNITT (SØK, RAPPORTERING OG LOGGFUNKSJONALITET) Krav til egenskaper ved brukergrensesnittet ID Krav Verktøyet skal ha et Web-basert brukergrensesnitt for sluttbrukere. Beskriv løsningen Design av rapportene for systemadministrator/superbruker må være skjermbasert, dra og slipp, fortrinnsvis syntaksfritt. Beskriv løsning Det skal finnes hjelpetekster i brukergrensesnittet ved utvikling av rapporter, administrasjon av verktøyet, brukergrensesnittet for sluttbruker m.m. på minimum engelsk, men det er ønskelig med norsk Det bør være mulig å legge inn egne hjelpetekster i rapporter/dashboards av BØR systemadministrator/superbruker som kan benyttes av sluttbruker ved bruk av rapporter/dashboards. Beskriv løsning Verktøyet skal kunne settes opp til å tilpasses ulike roller. Beskriv løsningen Hvilke muligheter finnes for individuell konfigurering for sluttbruker f.eks. BØR for å gjøre lokale tilpasninger i sin arbeidsflate som kan lagres. Spesifiser muligheter Beskriv eventuelle muligheter for logg, spesielt med tanke for logg av BØR responstider Verktøyet bør ha mulighet for søk i metadata og selve dataene. Søk i metadata er søk før man har kjørt rapporter, som hvilke rapporter finnes innenfor et gitt tema. Søk i selve dataene er søk etter at rapport er kjørt. Beskriv løsning. BØR 3 Krav til system- og brukeradministrasjon 3.1 KRAV TIL TILGANGSRETTIGHETER, ROLLER OG BRUKERE Rettigheter omfatter både funksjonsrettigheter (for eksempel retten til å kunne lage rapporter og hente ut datasett) og adgangsrettigheter (for eksempel retten til å lese data fra flere institusjoner). Funksjonsrettigheter styres på rollenivå. Adgangsrettigheter styres på brukernivå. Krav til tilgangskontroll og sikkerhet ID Krav Dokumenter verktøyets datasikkerhet og dokumenter rutiner for å fange opp og korrigere eventuelle sikkerhetshull Beskriv hvordan brukeradministrasjon og tilgang håndteres i verktøyet av systemadministrator/superbrukere i henhold til spesifikasjoner i bilag Roller og tilganger må kunne administreres med et GUI med dra og slipp. Beskriv løsning IT-verktøyet må tillate bruk av brannmur. Beskriv løsning All tilgang til verktøyets funksjoner skal reguleres gjennom en unik brukeridentitet og brukerprofil (inneholder for eksempel brukerrolle, org.tilhørighet). Beskriv løsning. 6

7 ID Krav Verktøyet skal kunne støtte ekstern autentisering basert på protokoller for autentisering gitt i bilag 3, slik som FEIDE og MinID, evt. skal det kunne utvikle slik støtte. Beskriv løsning eller beskriv muligheter for å utvikle slik støtte hvor det sies noe om tid og kostnad for en slik utvikling Verktøyet må støtte ekstern autorisasjon basert på protokoller for autorisasjon gitt i bilag 3. Alternativt skal verktøyet støtte provisjonering av autorisasjonsdata basert på standardisert import av tilgangsdata gjerne via en WebService basert på SOAP. Beskriv løsning Institusjonene skal selv kunne administrere tilgangskontroll på de forskjellige roller og nivåer på institusjonen. Systemadministrator skal ha tilgang til å gjøre dette for alle institusjoner. Beskriv løsning Superbrukere skal kunne definere rapporter og gjøre disse tilgjengelig for andre brukere på sin institusjon. Beskriv løsning Rettigheter bør kunne kopieres eller arves mellom brukergrupper på ulikt nivå i hierarkiet. Beskriv hvordan dette løses, samt hvordan en rettighet kan overstyre en annen. Beskriv løsning Det bør være mulig å ta ut rapporter pr rolle og/eller institusjon for å se hvilke rapporter som er knyttet til disse. Beskriv løsning Sluttbruker skal kun ha tilgang til data for egen institusjon. Superbrukere skal kun ha tilganger innenfor egen institusjon og institusjoner det er avtalt å samarbeide om forvaltning med. Systemadministrator skal ha tilgang til data for de institusjonene de skal drive brukerstøtte for. Beskriv løsning. BØR BØR 3.2 KRAV TIL SYSTEMKONFIGURASJON OG SYSTEMADMINISTRASJON Krav til systemkonfigurasjon og systemadministrasjon ID Krav Verktøyet må ha unicode UTF8 støtte. Beskriv løsning Det skal være mulig endre navn på felter som kommer fra kilde. Det må også være mulig for den enkelte institusjon å endre navn på slike felter i ettertid på rapporter slik at de kan tilpasses bedre den enkelte institusjon hvis dette er nødvendig. Beskriv løsning Det skal være mulig å definere faste tekster i rapportene, som for eks. overskrifter. Beskriv løsning Det skal være mulig å definere tilleggsfelter som f.eks. egne beregninger utover felter hentet fra kilde. Beskriv løsning Verktøyet skal ha funksjonalitet for automatisk avlogging av en bruker som har vært inaktiv i et definert antall minutter. Beskriv løsning Det er ønskelig å kunne parametersette hvor mange funn som kan vises pr. BØR skjermbilde. Beskriv løsning Beskriv løsning for drift av brukeradministrasjon, samt hvordan testing og produksjonssetting kan være adskilt 3.3 YTELSE OG ANTALL BRUKERE 7

8 Krav til ytelse og skalering ID Krav Verktøyet må ha en arkitektur som er i stand til å håndtere institusjonenes behov for bearbeiding av store datamengder og stort antall brukere i henhold til beskrivelser i bilag 3. Beskriv skaleringsmuligheter Hva slags high-availability-løsning fungerer sammen med verktøyet? Beskriv løsning. 4 Tekniske krav til tjenestekvalitet 4.1 TEKNISKE KRAV, KLIENTER Krav til tekniske krav for klienter ID Krav Verktøyet skal ha en flerlagsarkitektur med et metadatalag som danner et felles grunnlag for brukere av rapporter/dashbord. Beskriv løsning Verktøyet må ha 0-klientversjon for sluttbrukere som bare skal kjøre ferdige rapporter (dvs. en browser-versjon). Beskriv løsning Verktøyet må ha en 0-klientversjon for superbrukere som skal utvikle rapporter (dvs. en browser-versjon). Beskriv løsning Det bør være støtte for lesetavle (tablet) med mer for å kunne lese/bruke BØR ferdigutviklede rapporter/dashboards. Beskriv løsning All funksjonalitet i tjenesten skal være minst støtte nettlesere gitt i bilag 3. Redegjør for rutiner for å sikre støtte til nyere versjoner når de kommer Websidene skal følge standarder for websider gitt i bilag Det skal være støtte for 64-bits arkitektur (gjelder applikasjonsserver). Beskriv løsning Beskriv løsning for cashing og in-memory-bruk (gjelder applikasjonsserver) Repository/metadata og kildedata må kunne legges i database gitt i bilag 3. Beskriv løsning Verktøyet må kunne benytte VPD i database, se bilag 3, eller evt ha egen løsning for denne type håndtering. Beskriv løsning Applikasjonsserver må kunne bruke plattformer gitt i bilag 3. Beskriv løsning Beskriv hvilke verktøy applikasjonsserver benytter som f. eks Resin, Apache, Jboss. Beskriv løsning. 4.2 GRENSESNITT Krav til grensesnitt mot andre systemer ID Krav Beskriv muligheter for grensesnitt mot epostsystem Verktøyet må kunne lese fra Oracle-kilder Verktøyet bør kunne lese de vanligste og mest utbredte kilder slik som BØR PostGreSQL, SQLserver, MySql og tekstfiler. Beskriv hvilke kilder man kan lese data fra Beskriv hvordan verktøyet kommuniserer med en database, er det applikasjonsserver som kommuniserer med databasen, tykk-klient osv.? Beskriv løsning. 8

9 5 IKT-arkitektur 5.1 FELLES IKT-ARKITEKTUR Forbruker- og administrasjonsdepartementet (FAD) har i rundskriv nr P 4/2009 (datert ) kunngjort at det vil bli stilt nye krav til planlegging av IKT-investeringer i staten. FAD har besluttet at ved utvikling av nye IKT-systemer eller ved vesentlig ombygging av eksisterende systemer skal disse utvikles i tråd med noen felles arkitekturprinsipper. Prinsippene er obligatoriske for statlige IKTinvesteringer (jf. Rundskriv P 3/2009 Fellesføringer i tildelingsbrevet for 2010). Direktoratet for forvaltning og IKT (Difi) er gitt i oppdrag å forvalte og videreutvikle prinsippene. Se mer: og Gjeldende faktaark med Prinsipp for planlegging av IKT-løysinger (se vedlegg XX) er en sjekkliste for generelle arkitekturkrav som bør oppfylles og som vi ber leverandøren kommentere. Krav om felles IKT-arkitektur ID Krav Tjenesteorientering: IKT-systemer skal bygges opp som en samling avgrensede delsystemer som legger til rette for mest mulig gjenbruk Interoperabilitet: IKT-systemer må kunne utveksle og dele data og informasjon med andre systemer gjennom standardiserte grensesnitt Tilgjengelighet: Elektroniske brukertjenester skal være universelt utformet, og brukerne skal kunne benytte disse uten hensyn til tid, sted og kanal Sikkerhet: Informasjon og tjenester skal tilfredsstille krav til konfidensialitet, kvalitet og tilgjengelighet Åpenhet: Offentlige IKT-systemer skal være basert på åpne eller godkjente standarder. Systemene skal ikke sette spesielle krav til teknologi hos brukerne Fleksibilitet: Forvaltningen skal etablere og utvikle IKT-systemer på en slik måte at de er forberedt på endringer i bruk, innhold, organisering, eierskap og infrastruktur Skalerbarhet: IKT-systemer skal være forberedt på endringer i antall brukere, datamengde og levetiden til tjenesten. 5.2 DRIFTSMESSIGE FORHOLD Krav til støtte for driftsmessige forhold ID Krav Alle endringer i IT-verktøyet må skje kontrollert og gjøres til gjenstand for sikkerhetsmessig godkjenning og testing. Leverandøren må kunne vise til rutiner for systemvedlikehold og oppgraderinger. Oppgraderinger som Leverandøren leverer vil Kunden selv installere i testversjon, foreta verifisering før det settes i produksjon. Beskriv rutiner knyttet til levering av oppgradering og programvarevedlikehold Hvordan oppgraderes verktøyet? Kan en oppgradering foretas når verktøyet er oppe? Beskriv løsning Oppgraderinger må kunne gjøres av kundens systemadministrator og kundens driftsorganisasjon.. Beskriv løsning. 9

10 ID Krav Beskriv teknisk spesifikasjon og krav til miljøene som kunden skal benytte til å drifte, utvikle/vedlikeholde/teste verktøyet og rapporter i henhold beskrivelser i bilag 3 og alternativ 1,2 og 3 i bilag 3 Videre forklar rutiner for produksjonssetting av rapporter i henhold til alternativ 1,2 og 3 i bilag For alle passord mellom applikasjonsserver og andre grensesnitt som f. eks databaser hvor passord er tatt i bruk, må passord kunne endres. Beskriv løsning Beskriv håndtering av passord i verktøyet. 6 Krav i forbindelse med tjenesteleveransen Krav til tjenesteleveranse ID Krav 6.0 Omfanget av nødvendig tjenesteleveranse må beskrives 6.1 Timeprisen for konsulenter skal være iht. kompetansenivå 6.2 CV eller andre opplysninger vedr kvalifikasjoner til det personell som skal BØR benyttes i leveransen skal være tilgjengelig for oppdragsgiver. Oppdragsgiver forbeholder seg retten til å godkjenne bruken av konsulenter. 6.3 Leverandør plikter å opprettholde tilbudt kompetansenivå og det antallet ressurser som er nødvendig for å gjennomføre leveransen uavhengig av bytte av konsulenter, ferieavvikling, permisjoner, sykdom m.m. 6.4 Det skal leveres terminvise timelister per konsulent, som i detalj viser hva som er gjort og til hvilken pris. 6.5 Det skal foretas kompetanseoverføring til institusjonsrepresentanter/ekspertgruppe, driftspersonell og systemadministratorer. Beskriv løsning. Beskriv kostnader i bilag Hver institusjon skal kunne kjøpe ekstra lisenser. Pris for ekstra lisenser utenom definert brukeromfang må spesifiseres av leverandør. Se bilag Omfanget av tjenesteleveranser skal være godkjent av kunden før igangsetting 7 Merkantile krav Merkantile krav ID Krav 7.1 Prismodellen for tilbudte verktøy må inkludere alle produkter, tjenester, lisenser, utvikling/tilpasning, installasjon osv som er nødvendig for at verktøyet kan implementeres iht. leverandørens løsningsbeskrivelse. 7.2 Lisensbestemmelser skal være faste i avtaleperioden, og være vedlagt til Avtalen. 7.3 Leverandørens målemetodikker for oppdragsgivers bruk av tilbudte lisenser må foreligge. 10

11 ID Krav 7.4 Leverandørens lisensbestemmelser i forbindelse med test, utvikling, recovery, standby osv må foreligge. 7.5 Detaljert beskrivelse av Leverandørens support & vedlikeholdsbetingelser, inkl tilgjengelig supportapparat og supportnivå inkl priser for de forskjellige supportnivåene pr lisenstype må foreligge 7.6 Kontrakter som skal benyttes for denne anskaffelsen er Difi s standardkontrakter for kjøp av Programvare, samt Difi s standard avtale for Support & vedlikehold 7.7 Spesifikasjon av opplæring inkl priser skal fremkomme. 7.8 Alle priser skal oppgis i NOK 7. 9 Betaling og forvaltningsansvar for lisenser inntrer først for Pilot og Full BØR implementering 7.10 Tilleggstjenester faktureres kun på bakgrunn av bestilling fra kunde, og skal alltid medføre en endringsordre fra kunde. En hver endring skal være skriftlig kontraktsfestet. 8 Krav til vedlikeholdsavtale/support Id Krav 8.1 Teknisk, funksjonell og Best-Practice support for driftspersonell og systemadministratorer. Beskriv tjeneste og gi pris på denne type support. 8.2 Beskriv innhold og omfang i tilbudt support og vedlikeholdsavtale. Denne skal også inneholde en overordnet beskrivelse av support organisasjonen og hvor den er lokalisert. 8.3 Vedlikeholdsavtalen må omfatte og inkludere oppgraderinger og nye versjoner av verktøyet. 9 Driftsspesifikasjon, opplæring, kursing og dokumentasjon (Avtalen punkt Opplæring og avtalen punkt Dokumentasjons og opplysningsplikt) Krav til brukerdokumentasjon og veiledningsmateriell Id Krav 9.1 All dokumentasjon ment for sluttbrukere skal være skrevet på norsk/engelsk. Dokumentasjon som kun er ment for superbrukere og teknisk personell kan være skrevet på engelsk. Beskriv tilgjengelige utførelser og formater for dokumentasjonen. 9.2 Det skal finnes komplett, detaljert, oppdatert brukerdokumentasjon i tillegg til oversiktlig og lettfattet brukerveiledning til verktøyet. Det er tilstrekkelig at dokumentasjonen gjøres tilgjengelig for kunden elektronisk. Oppdatering av dokumentasjonen skal helst foreligge før installasjon i kundens test, og helst 3 uker før endringer i tjenesten settes i produksjon. 11

12 9.3 Det bør være enkelt å skrive ut brukerdokumentasjon for både enkeltfunksjonalitet, og hele moduler / funksjonalitetsgrupper samlet. Utskrift av dokumentasjonen må danne et brukervennlig og pedagogisk alternativ for alle brukergrupper. 9.4 Det bør finnes en hjelpefunksjon tilrettelagt for søk etter et spesielt tema. Beskriv hvordan dette fungerer. 9.5 Det bør finnes rutiner for dokumentasjon av funksjonalitetsendringer av verktøyet. Beskriv rutinene. BØR BØR BØR Krav til opplæring Id Krav 9.6 Det skal være mulig å benytte seg av leverandørens opplæringstilbud i hele avtaleperioden. Opplæring kan ytes til personer med drifts-, opplærings- og forvaltningsoppgaver hos kunden. Beskriv hvorledes opplæringsaktiviteter kan koordineres, gjennomføres og prises. 9.7 Det er ønskelig med mulighet for nettbasert opplæring som e-læring. Beskriv BØR opplæringstyper med eventuelle påbyggingsmoduler. 9.8 Det må være en supportorganisasjon. Beskriv denne. 10 Krav til bistand Det er viktig å sikre at kunden får den støtte til implementering av verktøyet som behøves i forhold til tidsplan, verktøyets hensikt og evt. behov for prosessendringer KONSULENTBISTAND OG OPPDRAG Leverandøren skal på forespørsel og etter egen avtale yte kunden bistand til: - Bistand til optimalisering av kundens drift - Bistand Videreutvikling av kundenes felles driftsløsning av verktøyet - Kundespesifikke resultat av bistand og oppdrag med unntak av eventuell testing og implementering, skal gjøres tilgjengelig for Samarbeidstiltaket FS. 12

13 Bilag 2 Leverandørens løsningsspesifikasjon Leverandøren skal beskrive sin løsning i forhold til Kundens kravspesifikasjon i bilaget. Dette gjøres normalt ved at Leverandøren besvarer Kundens kravspesifikasjon punkt for punkt. Behov for oppgradering av Kundens tekniske plattform: (Dersom slik oppgradering er nødvendig for å utnytte leveransen skal Leverandøren påpeke dette her) Åpenbare feil, mangler eller uklarheter i Kundens kravspesifikasjon: (Dersom det er slike åpenbare feil, mangler eller uklarheter i Kundens kravspesifikasjon skal Leverandøren påpeke disse) Krav til Kundens medvirkning: Avtalen punkt 10.5 Fri programvare Fri programvare som benyttes i leveransen: Navn på fri programvare Fri programvarelisens Kopi av aktuelle fri programvarelisenser skal vedlegges Leverandøren redegjørelse for sin vurdering av hvorvidt den frie programvare kan krenke tredjeparts rettigheter: Virkning av videredistribusjon: (Leverandøren må oppgi hvis videredistribusjon innebærer at også andre deler av leveransen enn det som opprinnelig var fri programvare vil bli omfattet av vilkårene i en fri programvarelisens) 13

14 Bilag 3 Kundens tekniske plattform Driftsmiljø I relasjon til avtalens begrepsbruk skal ulike subjekter i bilag 3 forstås avtalemessig som kunden. Uninett drifter i dag alle FS-institusjonene i samarbeidstiltaket, med unntak av UiO, UiB, UiT, NHH, UNIS og NTNU. Disse har egne databaser. Dette innebærer at de som driftes av Uninett har en felles AD-katalog, de som er utenfor har egne. De som driftes av Uninett vil i løpet av 2013 tar i bruk VPD (Virtual Privat Database). Datavarehuset vil være kilde for et nytt rapport- og presentasjonsverktøy, i tillegg til rapportering direkte mot kildesystemet FS. Datavarehuset er delt opp i utvikling, test og produksjonsmiljø, og et verktøy må kunne ha tilsvarende miljøer. I datavarehuset finnes data fra FS, i tillegg til data for økonomi for UIO/UIB og forskning (CRISTIN). Brukeromfang og teknisk rammeverk Antall brukere: Antall brukere FS: Antall brukere hos institusjonene vil variere avhengig av den enkelte institusjons størrelse. Antallet brukere vil også være avhengig av hvor enkelt verktøyet oppfattes og hvor mange rapporter man vil få tilgang til via nettsider. Hver institusjon (54 stk) får tildelt lisens for en superbruker og en sluttbruker. Institusjoner med studenter over 5000 vil få tildelt lisenser for to sluttbrukere. Ved full implementering antas det at det vil være i underkant av ti systemadministratorer, superbrukere og sluttbrukere. Hver institusjon skal i tillegg kunne kjøpe ekstra lisenser. Pris for ekstra lisenser utenom definert brukeromfang må spesifiseres av leverandør. Antall andre brukere: Det kan i tillegg komme flere brukere gjennom opsjoner. Dette gjelder: o o Forskningsinformasjonssystemet CRIStin som er et verktøy for forskere og forskningsmiljøer i Norge for å registrere og profilere publikasjonsdata, prosjekter, enheter og kompetanseprofiler. Systemet brukes også til innrapportering av publikasjonspoeng. CRIStin har i dag ca 160 institusjoner. Økonomisystemene i UH-sektoren, herunder primært BOT-samarbeidet. BOT er et samarbeidsprosjekt mellom universitetene i Bergen, Oslo og Tromdheim. Datamengde o Datavarehus: Antall rader: Antall tabeller:

15 o FS Antall GB: 389 Antall tabeller: 2585 pr institusjon Antall rader: for stor institusjon (UIO), for mindre institusjon rader (FSHIM?) Antall GB: ca 812 GB for 58 institusjoner (inkl minus 30% overhead ) Protokoller for autentisering: SAML2.0 Protokoller for autorisasjon: SAML2.0 eller LDAP Nettlesere: Firefox versjon 3.5, Internet explorer versjon 8, Safari versjon 4 eller nyere. Standard for websider: HTML 4.01/XHTML 1.0 standard eller nyere Applikasjonsserver: 64-bits arkitektur Plattform for applikasjonsserver: Red Hat 5 eller nyere alternativt Windows server 2008 R2 eller nyere Databaser: Oracle 11.2.x eller nyere versjoner. VPD- opsjon er tatt i bruk blant annet for å realisere institusjonsspesifikk tilgang til egne data, både for datavarehus og FS. Beskrivelse av kilder Datavarehus Kilde: Oracle Modellering: Stjernemodell Miljø: Utvikling, Test, Produksjon FS Kilde: Oracle Modellering: relasjonsdatabase Miljø: Utvikling, Test, Produksjon 15

16 LDAP for institusjo Veiledende bilag til SSA-K Alternativer arkitekturskisser som verktøyet skal realiseres i: Det ønskes en sentral innstallasjon av Applikasjonstjener uavhengig av kilder, evt at det blir to sentrale innstallasjoner av applikasjonstjener, en mot datavarehus og en for produksjonsbaser for FSkilder. Alternativ 1 er foretrukket løsning, men Levererandør bes om å få frem kostnad for Drift og innstallasjon m.m. for begge alternativene under. Alternativ 1 1. Pålogging: 3. Applikasjonstjener: Organisasjon velges av bruker Brukernavn og passord oppgis til Feide som etablerer en autentisert sesjon til verktøyet Det finnes 60 FS-institusjoner som potensielt vil benytte verktøyet. Samtlige støtter SAML2.0 enten ved at de er med i Feide eller via IDporten/MinID. Applikasjonstjener Mobil Browser Nettbrett Autentisering/autorisasjon Autentisering skal foregå ved hjelp av SAML2.0. Når støtte for SAML 2.0 er tilgjengelig for verktøyet kan protokollen også benyttes for autorisasjon. Kundene må tilgjengeliggjøre rolledata for relevant personell i avtalt attributt og på avtalt format i sin Feide-katalog (LDAP med Feide-skjema). Støtter ikke verktøyet autorisasjon via SAML2.0 må det foreligge støtte for oppkobling til eller innhenting av data fra multiple autoritative kildesystemer. 2. Feide har implementert en såkalt WAYF-tjeneste ( where-are-you-from ) som tillatter brukeren å velge hvilken vertsinstitusjon skal avgi autentiserings- og autorisasjonsdata. Feide sørger for at korrekt back-end (LDAP-katalog) velges på bakgrunn av angitt vertsinstitusjon. Verktøyet skal hente relevante data fra multiple, veldefinerte datasettsamlinger via spesifiserte grensesnitt SAML 2.0 FEIDE LDAP for institusjo LDAP for institusjo Datavarehus Felles Studentsystem (FS) UNINETT UiO UiT NTNU UiB KILDER 16

17 1. Pålogging: 3. Gitt at det pga av krav til sikkerhet og driftsløsning ikke er ønskelig at verktøyet skal kunne lese både fra datavarehus og direkte mot FS produksjonsbaser, kan det være en løsning å ha en applikasjonstjener for tilgang til data fra datavarehus og en for tilgang til data fra FS produksjonsbaser. Applikasjonstjener 1: Verktøyet skal hente relevante data fra et definert datasettsamling via spesifisert grensesnitt. Alternativ 2 Organisasjon velges av bruker Brukernavn og passord oppgis til Feide som etablerer en autentisert sesjon til verktøyet Det finnes 60 FS-institusjoner som potensielt vil benytte verktøyet. Samtlige støtter SAML2.0 enten ved at de er med i Feide eller via IDporten/MinID. Applikasjonstjener 1 Mobil Browser Nettbrett Applikasjonstjener 2 Autentisering/autorisasjon Autentisering skal foregå ved hjelp av SAML2.0. Når støtte for SAML 2.0 er tilgjengelig for verktøyet kan protokollen også benyttes for autorisasjon. Kundene må tilgjengeliggjøre rolledata for relevant personell i avtalt attributt og på avtalt format i sin Feide-katalog (LDAP med Feide-skjema). Støtter ikke verktøyet autorisasjon via SAML2.0 må det foreligge støtte for oppkobling til eller innhenting av data fra multiple autoritative kildesystemer. 2. Feide har implementert en såkalt WAYF-tjeneste ( where-are-you-from ) som tillatter brukeren å velge hvilken vertsinstitusjon skal avgi autentiserings- og autorisasjonsdata. Feide sørger for at korrekt back-end (LDAP-katalog) velges på bakgrunn av angitt vertsinstitusjon. SAML 2.0 FEIDE LDAP instit LDAP instit LDAP instit Applikasjonstjener 2: Verktøyet skal hente relevante data fra multiple, veldefinerte datasettsamlinger via spesifiserte grensesnitt Datavarehus UNINETT Felles Studentsystem (FS) UiO UiT NTNU UiB KILDER 17

18 Bilag 4 Prosjekt- og fremdriftsplan for leveranse av verktøy Oppgave Ansvar Tidsfrist Merknad Opplæring Leverandør Installasjon, brukeradm, bruk av verktøy, systemadm. tilgang Installasjon av verktøy Leverandør I samarbeid med Kunde for kompetanseoverføring av installasjon. Kompetanseoverføring skal sikre at kunden er i stand til å tilgjengeliggjøre verktøy for institusjonene som ikke er inkludert i akseptansetest. Akesptansetest Kunde Opplæring: Opplæring gis til et gitt antall brukere for et gitt antall institusjoner. Antall systemadministratorer: ca 10 Antall fra ekspertgruppe/institusjonsrepresentant: 6-10 Antall superbrukere:6 Antall sluttbrukere: 11 Antall institusjoner: 6 Installasjon av verktøy: Installasjon av verktøyet som tilgjengligjør verktøyet for et gitt antall bruker på et gitt antall institusjoner.verktøyet skal innstalleres med miljø for utvikling, test og produksjon. Akseptansetest: Skal teste at vertøy er levert i henhold til kravspesifikasjon. Antall systemadministratorer: 5 Antall fra ekspertgruppe: 6-10 Antall superbrukere:6 Antall sluttbrukere: 11 Antall institusjoner: 6 Avtalen punkt Dokumentasjon, opplysningsplikt mv. Frist for levering av dokumentasjon for utstyr og standardprogramvare: Avtalen punkt Tidsfrist for forberedelse av installasjon, og leverandørens avsluttende inspeksjon Frist for forberedelse til installasjon: 18

19 Leverandøren skal ikke foreta en avsluttende inspeksjon av om fysiske og/eller tekniske forhold er slik at Leverandøren godkjenner at installasjon kan finne sted: (Angis dersom partene har avtalt at slik inspeksjon ikke er relevant for leveransen) Starttidspunkt for installasjon: Avtalen punkt Plan for Kundens akseptansetest Frist for å utarbeide grunnlagsmateriale til akseptansetestplanen: Andre frister for akseptansetestplanen: (Fylles ut dersom partene avtaler andre frister enn det som følger av avtalen) Avtalen punkt Definisjon av feilnivåer Følgende definisjoner av feil skal legges til grunn: (Fylles ut dersom partene avtaler andre definisjoner enn det som følger av avtalen) Avtalen punkt Gjennomføring av Kundens akseptansetest Dato for påbegynnelse av Kundens akseptansetest: Dato for avslutning av Kundens akseptansetest: Avtalen punkt Idriftsettelse Frist for at leveransen settes i ordinær drift: Partenes plikter i forbindelse med idriftsettelse: Avtalen punkt 6.1 Kundens ansvar og medvirkning Frister for Kundens medvirkning til leveransens gjennomføring:?? Avtalen punkt Dagbot ved forsinkelse Frist det er knyttet dagbot til: (Fylles ut dersom partene har avtalt andre frister enn det som følger av avtalen) 19

20 Dagbotsatser: (Fylles ut dersom partene avtaler annet enn det som følger av avtalen) Løpetid for dagbot: (Fylles ut dersom partene avtaler annet enn det som følger av avtalen) Avtalen punkt Tidsfrist for forberedelse av installasjon, og leverandørens avsluttende inspeksjon Frist for forberedelse til installasjon: (Dato) Leverandøren skal ikke foreta en avsluttende inspeksjon av om fysiske og/eller tekniske forhold er slik at Leverandøren godkjenner at installasjon kan finne sted: (Angis dersom partene har avtalt at slik inspeksjon ikke er relevant for leveransen) Starttidspunkt for installasjon: (Dato) Avtalen punkt Plan for Kundens akseptansetest Frist for å utarbeide grunnlagsmateriale til akseptansetestplanen: (Dato) Andre frister for akseptansetestplanen: (Fylles ut dersom partene avtaler andre frister enn det som følger av avtalen) Avtalen punkt Definisjon av feilnivåer Følgende definisjoner av feil skal legges til grunn: (Fylles ut dersom partene avtaler andre definisjoner enn det som følger av avtalen) Avtalen punkt Gjennomføring av Kundens akseptansetest Dato for påbegynnelse av Kundens akseptansetest: Dato for avslutning av Kundens akseptansetest: Avtalen punkt Idriftsettelse Frist for at leveransen settes i ordinær drift: (Dato) Partenes plikter i forbindelse med idriftsettelse: Avtalen punkt 6.1 Kundens ansvar og medvirkning 20

21 Frister for Kundens medvirkning til leveransens gjennomføring: Avtalen punkt Dagbot ved forsinkelse Frist det er knyttet dagbot til: (Fylles ut dersom partene har avtalt andre frister enn det som følger av avtalen) Dagbotsatser: (Fylles ut dersom partene avtaler annet enn det som følger av avtalen) Løpetid for dagbot: (Fylles ut dersom partene avtaler annet enn det som følger av avtalen) Bilag 5 Testing og godkjenning Her beskrives prosedyrer for testing og godkjenning med testkriterier, rutiner osv. Nedenfor følger punkter som avtalen henviser til dette bilaget. Avtalen punkt Akseptansetestens omfang Kundens akseptansetest skal omfatte følgende tester: (Fylles ut dersom partene avtaler andre tester enn det som følger av avtalen) Akseptansetest etter erfaring fra pilot Avtalen punkt Gjennomføring av Kundens akseptansetest Beskrivelse av gjennomføringen av Kundens akseptansetest: Avtalen punkt Varighet Godkjenningsperiodens varighet: (Fylles ut derom det er avtalt annen varighet enn det som følger av avtalen) Avtalen punkt Kundens undersøkelsesplikt Spesifisering av innholdet i godkjenningsperioden med konkret angivelse av de undersøkelsene som Kunden skal gjennomføre: Oppgave Ansvar Merknad Installasjon Kunde Bistand fra leverandør Leverandør tester Leverandør Leverandør spesifiserer Kunde tester Kunde Test iht. Kravspesifikasjon. Test periode 1 måned etter leverandørens test er gjennomført Godkjenning Kunde Etter test fra oppdragsgiver. 21

22 Kunden vil så langt det er mulig gjennomføre tester som verifiserer at alle krav i Bilag 2 er oppfylt. Særlig -kravene vil bli testet. Alle feil/avvik vil bli loggført og meldt til leverandøren fortløpende. Feil vil bli kategorisert i henhold til definisjonen i del 2, kontrakten kapittel Undersøkelsesplikt. Når testing er gjennomført og leverandøren har rettet meldte feil, vil kunden lage en sluttrapport for testingen. Denne danner grunnlaget for evt. godkjenning. Verktøyet vil bli godkjent hvis det ikke inneholder kjente A- eller B-feil. I motsatt fall kan kunden oppheve kontrakten. Avtalen punkt Håndtering av feil Prosedyrer om melding av feil fra Kunden til Leverandøren: Frist for utbedring av feil: (Fylles ut dersom partene har avtalt annen frist enn innen utgangen av godkjenningsperioden) Bilag 6 Administrative bestemmelser Bilaget brukes til å samle administrative rutiner for avtaleforholdet og samarbeidet mellom partene. Avtalen punkt 1.6 Partenes representanter Bemyndiget representant for partene: For Kunden Navn: Stilling: Telefon: E-post: For Leverandøren Navn: Stilling: Telefon: E-post: Prosedyrer og varslingsfrister for utskifting av bemyndiget representant: Avtalen punkt 5.2 Krav til Leverandørens ressurser og kompetansen Leverandørens prosjektleder: Navn: Stilling: Telefon: E-post: 22

23 Leverandørens nøkkelpersonell: Navn Stilling Kompetanseområde Avtalen punkt 5.3 Bruk av underleverandør Leverandørens godkjente underleverandører: Navn Org.nr Leveranseområde Avtalen punkt 5.4 Samarbeid med tredjepart Omfang av Leverandørens samarbeid med tredjepart valgt av Kunden: Avtalt vederlag: (Fylles ut dersom det er avtalt særlig vederlag for samarbeid med tredjepart) Avtalen punkt 5.5 Lønns- og arbeidsvilkår Aktuell tariffavtale samt samsvarserklæring: (Her identifiseres allmenngjort tariffavtale eller aktuell landsomfattende tariffavtale, samt inntas egenerklæring evt. tredjepartserklæring om samsvar mellom aktuell tariffavtale og faktiske lønns- og arbeidsvilkår for oppfyllelse av Leverandørens og eventuelle underleverandørers forpliktelser) Avtalen punkt 6.2 Bruk av tredjepart Kundens valgte tredjeparter: Navn Org.nr Arbeidsområde Avtalen punkt 16.3 Uavhengig ekspert Uavhengig ekspert valgt av partene: Navn Kompetanseområde Avtalen punkt 7.1. Møter Frist for innkallelse til møter: (Fylles ut dersom partene avtaler annen frist enn det som følger av avtalen) 23

24 Rutiner for gjennomføring av møter: (Her kan det f. eks spesifiseres hvem som skal møte, hvor møtene holdes, krav til referat, hyppighet osv) 24

25 Bilag 7 Samlet pris og prisbestemmelser Alle priser og nærmere betingelser for det vederlaget Kunden skal betale for Leverandørens ytelser skal fremgå av bilag 7. De samlede prisene og samlet sluttvederlag skal fremkomme her. Som en del av grunnlaget for totalprisen skal eventuelle spesielle betalingsordninger, rabatter, forskudd, delbetaling og avvikende betalingstidspunkt også fremgå Dersom partene avtaler annet enn det som følger av avtalen vedrørende vederlag, skal det spesifiseres i dette bilaget. Avtalen punkt 8.1 Vederlag Utgangspunktet er at prisene oppgis i norske kroner og eksklusiv merverdiavgift. Annet må spesifiseres særskilt. Det må oppgis hvorvidt prisen er per enhet eller f. eks per måned/år/avtaleperioden. Tabellene bør tilpasses prisstrukturen for leveransen. Totalkostnader: Element Referanse Totalkostnad Kjøp av lisenser Tabell 1 Etablering Vedlikehold TOTALT Tabell 1 Pris lisenser: Beskrivelse/navn Pris i NOK Antall Total (eksl. mva) Vedlikeholds kostnad Sum: Pris opplæring: Beskrivelse/navn Pris i NOK Antall Total (eksl. mva) Sum: Pris vedlikehold/support: Beskrivelse/navn: Tilbudspris i NOK Antall Total(eksl. Mva) Pris dokumentasjon: Beskrivelse/navn Pris i NOK Antall Total (eksl. mva) Sum: 25

26 Pris disposisjonsrett: Beskrivelse/navn Pris i NOK Antall Total (eksl. mva) Sum: Pris per time tjenester: Beskrivelse/navn Pris i NOK Antall Total (eksl. mva) Sum: Totalpris: Pris i NOK Antall Total (eksl. mva) Følgende utlegg dekkes: (Fylles ut dersom partene avtaler at utlegg skal dekkes, og her spesifiseres det hvilke utlegg som er omfattet) Reise- og diettkostnader skal dekkes etter følgende satser: (Fylles ut dersom partene avtaler at Statens satser ikke skal legges til grunn) Følgende reisetid kan faktureres: (Hovedregelen er at reisetid ikke faktureres. Reisetid kan derfor bare faktureres hvis det er avtalt. Det bør i tilfelle spesifiseres i hvilke tilfeller eller hvilke reiser som kan faktureres) Avtalen punkt 3.2. Endringsoverslag Priser og betingelse for tilleggsarbeid: Standardpriser for utarbeidelse av endringsoverslag: Avtalen punkt 8.2 Fakturering Betalingsplan: Øvrige betalingsvilkår: Vilkår for implementering av EHF (elektronisk handelsformat): Leveranse av elektroniske fakturaer skal skje på den av Direktorat for økonomistyring (DFØ) sin til enhver tid valgte kommunikasjonsmetode. Ved endring av kommunikasjonsmetode vil Leverandøren bli varslet seks måneder før nødvendig endring finner sted. Faktureringstidspunkt: (Fylles ut dersom partene avtaler annet enn det som følger av avtalen) 26

27 Fakturaadresse: Faktura skal merkes med referansenummer navn Avtalen punkt 8.5 Prisendring Avtalt prisendring: Timepris kan endres i henhold til følgende indeks: (Fylles ut dersom partene avtaler regulering etter annen indeks enn konsumprisindeksen, f. eks lønnsindeks for bransjen) Avtalen punkt 2.4 Avbestilling Avtalt avbestillingsgebyr: (Fylles ut dersom partene har avtalt annet avbestillingsgebyr enn det som følger av avtalen) Avtalen punkt 10.1 Eiendomsrett til utstyr Avtalt salgspant: (Fylles ut dersom partene har avtalt salgspant) Avtalen punkt Disposisjonsrettens varighet (Disposisjonsretten løper uten tidsbegrensning etter avtalen. Dersom partene avtaler disposisjonsretten med løpende vederlag fylles det ut her.) 27

28 Bilag 8 Endringer i den generelle avtaleteksten Endringer til den generelle avtaleteksten skal samles i bilag 8, med mindre den generelle avtaleteksten henviser slike endringer til et annet bilag. Det er mulig å gjøre endringer til alle punkter i avtalen, også der hvor det ikke klart henvises til at endringer kan avtales. Endringene til avtaleteksten skal fremkomme her, slik at teksten i den generelle avtaleteksten forblir uendret. Det må fremkomme klart og utvetydig hvilke bestemmelser i avtalen det er gjort endringer til. Leverandøren bør imidlertid være oppmerksom på at forbehold og endringer i avtalen ved tilbudsinnlevering kan medføre at tilbudet blir avvist av Kunden. Punkt Erstattes med 28

29 Bilag 9 Endringer av leveransen etter avtaleinngåelsen Endringer av leveransen etter avtaleinngåelsen skal følge prosedyrene i kapittel 3 og gjøres skriftlig. Leverandøren skal føre en fortløpende katalog over endringene som utgjør dette bilaget. Nr Dato Endringen gjelder 29

30 Vedlegg Vedlegg: Statens Prinsipp for planlegging av IKT-løysinger 30

31 Faktaa Prinsipp for planlegging av IKT-løysingar Vedlegg 4: Statens Prinsipp for planlegging av IKT-løysinger Staten må sikre god utnytting av dei store IKT-investeringane. IKT-systema må leggje grunnlaget for enklare samhandling og utveksling av informasjon. Gode verkemiddel er gjenbruk og fleirbruk av IKTløysingane i forvaltninga og standardisering av mellom anna format og protokollar. I tillegg er det viktig å ha nokre felles prinsipp å halde seg til i utviklinga av nye IKT-løysingar i staten eller når eksisterande system skal byggjast om. Felles prinsipp sikrar at dei IKTløysingane som kvar etat eller sektor kjøper, utviklar og nyttar, vert underlagde sentrale krav om betre brukarorientering og meir samordning på tvers av offentlege einingar. Einsarta prinsipp for forvaltninga kan over tid gjere forvaltninga meir endringsdyktig ved at datasystem i verksemdene i større grad vert sette i samanheng med systema i andre verksemder. Det gjer integrering av systema enklare. Prinsippa vil vere eit rammeverk for ein felles IKTarkitektur i offentleg sektor. Denne arkitekturen må ha ein fornuftig balanse mellom universelle og lokale løysingar og ha respekt for at delar av forvaltninga treng spesialisert teknologi og eigne program for å få utført oppgåvene sine slik lovverket krev og dei politiske styresmaktene forventar. Regjeringa legg til grunn at statlege verksemder skal nytte følgjande prinsipp i planlegginga av nye IKTløysingar eller ved vesentleg ombygging av eksisterande løysingar: Tenesteorientering: IKT-system skal byggjast opp som ei samling avgrensa delsystem som legg til rette for mest mogleg gjenbruk. Interoperabilitet: IKT-system må kunne utveksle og dele data og informasjon med andre system gjennom standardiserte grensesnitt. Tilgjenge: Elektroniske brukartenester skal vere universelt utforma, og brukarane skal kunne nytte dei utan omsyn til tid, stad og kanal. Tryggleik: Informasjon og tenester skal tilfredsstille krav til konfidensialitet, kvalitet og tilgjenge. Openheit: Offentlege IKT-system skal vere baserte på opne eller godkjende standardar. Systema skal ikkje setje spesielle krav til teknologi hos brukarane. Fleksibilitet: Forvaltninga skal etablere og utvikle IKTsystem på ein slik måte at dei er føre-budde på endringar i bruk, innhald, organisering, eigarskap og infrastruktur. Skalerbarheit: IKT-system skal vere føre-budde på endringar i talet på brukarar, datamengd og livs-lengda til tenesta. 31

Jfr. kundens kravspesifikasjon.

Jfr. kundens kravspesifikasjon. Bilag 1 Kundens beskrivelse av Oppdraget Kundens krav til Oppdraget beskrives her. Dette gir grunnlag for hva som skal leveres fra Konsulenten til slutt, og har også betydning for hva som regnes som mangler

Detaljer

Bilag 1 Kundens kravspesifikasjon

Bilag 1 Kundens kravspesifikasjon Bilag 1 Kundens kravspesifikasjon 1. Instrumentet bør kunne: a) måle på DAB/DAB+ og DMB signaler b) dekke frekvensområde 175 240 MHz og 1452 1492 MHz c) enkelt scanne frekvensområdene d) måle FIC/MSC BER

Detaljer

Bilag 1 Utstyr og/eller programvare som skal vedlikeholdes Her angis det utstyr og/eller programvare som vedlikeholdstjenesten omfatter.

Bilag 1 Utstyr og/eller programvare som skal vedlikeholdes Her angis det utstyr og/eller programvare som vedlikeholdstjenesten omfatter. Bilag 1 Utstyr og/eller programvare som skal vedlikeholdes Her angis det utstyr og/eller programvare som vedlikeholdstjenesten omfatter. Post Produktnavn Ref. nr Bilag 2 Utdypende spesifikasjon av ytelsen,

Detaljer

Bilag 1 Kundens beskrivelse av Oppdraget

Bilag 1 Kundens beskrivelse av Oppdraget Bilag 1 Kundens beskrivelse av Oppdraget Å anskaffe et CMS (publiseringsverktøy), brukeropplevelse/design og implementering på valgte plattform. Løsningen skal driftes internt, og det skal derfor ikke

Detaljer

Jf. kundens kravspesifikasjon.

Jf. kundens kravspesifikasjon. Bilag 1 Kundens beskrivelse av Oppdraget Kundens krav til Oppdraget beskrives her. Dette gir grunnlag for hva som skal leveres fra Konsulenten til slutt, og har også betydning for hva som regnes som mangler

Detaljer

Bilag 1: Kundens kravspesifikasjon

Bilag 1: Kundens kravspesifikasjon Bilag 1: Kundens kravspesifikasjon I bilaget skal Kunden spesifisere driftstjenester som skal leveres etter avtalen. Kunden skal på bakgrunn av sine formål og behov fremstille sine krav som en kravspesifikasjon.

Detaljer

SSA Bilag 7. Bilag 7: Samlet pris og prisbestemmelser

SSA Bilag 7. Bilag 7: Samlet pris og prisbestemmelser SS Bilag 7 Bilag 7: Samlet pris og prisbestemmelser 1 SS Bilag 7 Versjon Dato Beskrivelse av endring Forfatter(e) 1.0 05.03.2015 Dokument opprettet og overlevert KS. Sopra Steria 2 SS Bilag 7 Innhold 1

Detaljer

Hvilke punkter i avtalene bør man være oppmerksom på?

Hvilke punkter i avtalene bør man være oppmerksom på? Hvilke punkter i avtalene bør man være oppmerksom på? SSA-konferansen 11. mars 2009 advokat Ingvild Hanssen-Bauer ihb@wr.no WIKBORG REIN 1 Innledning Utgangspunkt i kjøpsavtalen og de viktigste endringene

Detaljer

Bilag 1 Beskrivelse av Bistanden

Bilag 1 Beskrivelse av Bistanden Bilag 1 Beskrivelse av Bistanden 1. Om Undervisningsbygg Undervisningsbygg er et kommunalt foretak i Oslo kommune, som har til oppgave å utvikle, bygge, drifte og forvalte skolebyggene i Oslo. Vår visjon

Detaljer

Konkurransegrunnlag Utredning om allmennhetens bruk av utmark i Finnmark. Tilbudsfrist: 15. april 2010, Klokken 12:00

Konkurransegrunnlag Utredning om allmennhetens bruk av utmark i Finnmark. Tilbudsfrist: 15. april 2010, Klokken 12:00 Forside Konkurransegrunnlag Utredning om allmennhetens bruk av utmark i Finnmark Tilbudsfrist: 15. april 2010, Klokken 12:00 Finnmarkskommisjonen inviterer med dette leverandører til å delta i konkurranse

Detaljer

Bilag 1 Kundens beskrivelse av Oppdraget

Bilag 1 Kundens beskrivelse av Oppdraget Bilag 1 Kundens beskrivelse av Oppdraget 1.1 Generelt om Undervisningsbygg Undervisningsbygg har normalt prosjekter for rundt 70 skoleanlegg per år. Det årlige investeringsbudsjettet er på ca. 3 milliarder

Detaljer

Bilag 1 Beskrivelse av Bistanden

Bilag 1 Beskrivelse av Bistanden Bilag 1 Beskrivelse av Bistanden Avtalen punkt 1.1 Avtalens omfang Bistanden omfatter følgende ytelser: Vikartjenester IKT 1. og 2. linjes support til Statsbygg IKT seksjon og IKT supportenheten (Teknotorget).

Detaljer

Bilag 7 Samlet pris og prisbestemmelser

Bilag 7 Samlet pris og prisbestemmelser Bilag 7 Samlet pris og prisbestemmelser 1 / 12 Versjonshåndtering Versjon Dato Initiert av Endringsårsak 1.0 16.05.2013 Difi Dokument distribuert til tilbydere 2.0 20.08.2013 Difi Endret

Detaljer

AVTALE OM LEIE AV IKT-RELATERT UTSTYR FOR STATENS LANDBRUKSFORVALTNING

AVTALE OM LEIE AV IKT-RELATERT UTSTYR FOR STATENS LANDBRUKSFORVALTNING AVTALE OM LEIE AV IKT-RELATERT UTSTYR FOR STATENS LANDBRUKSFORVALTNING Leieavtale av maskinvare Avtale om leie av IKT-relatert utstyr for Statens landbruksforvaltning mellom: (heretter kalt Utleieren)

Detaljer

Vedlegg 5 til konkurransegrunnlaget Prisbestemmelser

Vedlegg 5 til konkurransegrunnlaget Prisbestemmelser Vedlegg 5 til konkurransegrunnlaget Prisbestemmelser Avtale om IKT-utstyr med tilhørende programvare, service og vedlikehold, samt telefoniutstyr for Statens landbruksforvaltning Bilag 4 til Rammeavtale

Detaljer

BILAG 1 Oppdragsgivers beskrivelse av oppdraget

BILAG 1 Oppdragsgivers beskrivelse av oppdraget BILAG 1 Oppdragsgivers beskrivelse av oppdraget Plan- og bygningsetatens prosjekt «elektroniske tjenester» leverer digitale selvbetjeningsløsninger som skal forenkle våre kunders hverdag. Oslo kommune

Detaljer

Bilag 1: Leverandørens løsningsspesifikasjon

Bilag 1: Leverandørens løsningsspesifikasjon Bilag 1: Leverandørens løsningsspesifikasjon Løsningen «Tjenester for Sensitive Data TSD» er pr. som beskrevet med enkel systembeskrivelse, dyptgående Whitepaper og risikovurderinger på : https://www.uio.no/tjenester/it/forskning/sensitiv/mer-om/systembeskrivelse/

Detaljer

Veiledende bilag til SSA R Rammeavtalen versjon 2015

Veiledende bilag til SSA R Rammeavtalen versjon 2015 Veiledende bilag til SSA R Rammeavtalen versjon 2015 Innhold: Bilag 1: Overordnet beskrivelse av de ytelser rammeavtalen gjelder og oversikt over de oppdragsgivere som kan tildele kontrakter under rammeavtalen...

Detaljer

Bilag 1 Beskrivelse av Bistanden

Bilag 1 Beskrivelse av Bistanden Bilag 1 Beskrivelse av Bistanden Bakgrunn Regjeringen har besluttet at det skal utarbeides en ordinær konseptvalgutredning (KVU) for grensestasjonen Storskog. Regjeringens beslutning er bl.a. tatt på bakgrunn

Detaljer

RAMMEAVTALE nr xxxxx

RAMMEAVTALE nr xxxxx RAMMEAVTALE nr mellom Pasientreiser ANS (org nummer 994 11 1841) heretter benevnt Kunden og «Leverandør» (org nummer ) heretter benevnt Leverandør AVTALEN GJELDER: «Beskrivelse av tjeneste» AVTALEN GJELDER

Detaljer

Teletrafikk BILAG 6. til kontrakten. Bilag 6 Administrative bestemmelser

Teletrafikk BILAG 6. til kontrakten. Bilag 6 Administrative bestemmelser BILAG 6 til kontrakten Administrative bestemmelser Side 1 av 6 Innholdsfortegnelse 1 Alminnelige bestemmelser...3 2 Oppdragsgivers og leverandørs plikter...4 2.1 Leverandørens nøkkelpersonell...feil! Bokmerke

Detaljer

SSA 2015. Gjennomføring av leveransen i SSA-T og SSA-D. seniorrådgiver Mari Vestre, Difi

SSA 2015. Gjennomføring av leveransen i SSA-T og SSA-D. seniorrådgiver Mari Vestre, Difi SSA 2015 Gjennomføring av leveransen i SSA-T og SSA-D seniorrådgiver Mari Vestre, Difi Mål med endringene i gjennomføring av leveransen i SSA-T og SSA-D Legge til rette for mindre detaljerte kravspesifikasjoner

Detaljer

Vedr. sak 4 Anskaffelse av nytt rapport- og presentasjonsverktøy

Vedr. sak 4 Anskaffelse av nytt rapport- og presentasjonsverktøy Felles studentsystem Telefon: 22852738 USIT, Universitetet i Oslo Telefax: 22852970 Postboks 1086, Blindern E-mail: fs-sekretariat@usit.uio.no 0316 Oslo URL: www.fs.usit.uio.no FS-12-135 IG/ALL Til: Styret

Detaljer

FORESPØRSEL. Fra. Innherred samkommune (ISK) Bestående av Verdal kommune og Levanger kommune. leveranse av:

FORESPØRSEL. Fra. Innherred samkommune (ISK) Bestående av Verdal kommune og Levanger kommune. leveranse av: Innherred samkommune FORESPØRSEL Fra Innherred samkommune (ISK) Bestående av Verdal kommune og Levanger kommune på leveranse av: Leveranse av programvare for personalstyring, turnusplanlegging, vikarpool

Detaljer

Utarbeidelse av kravspesifikasjon for anskaffelse av NOARK system

Utarbeidelse av kravspesifikasjon for anskaffelse av NOARK system Utarbeidelse av kravspesifikasjon for anskaffelse av NOARK system Mars 2013 Astrid Øksenvåg Om EKOR Konsulenthus spesialisert på informasjonsforvaltning Bistår kunder med: Behovskartlegging Kravspesifisering

Detaljer

Bilag 6 Vedlegg 3 Definisjoner

Bilag 6 Vedlegg 3 Definisjoner Bilag 6 Vedlegg 3 Definisjoner Saksnummer 13/00203 1 / 7 Versjonshåndtering Versjon Dato Initiert av Endringsårsak 0.1 16.05.2013 Difi Dokument distribuert til tilbydere 02. 01.11.2013 Difi Ny definisjon

Detaljer

Anskaffelse av Farmasøytiske Isolatorer for Sykehusapotekene. Negativtrykk Isolatorer (alle størrelser) Bilag 7 Samlet pris og prisbestemmelser

Anskaffelse av Farmasøytiske Isolatorer for Sykehusapotekene. Negativtrykk Isolatorer (alle størrelser) Bilag 7 Samlet pris og prisbestemmelser Anskaffelse av Farmasøytiske Isolatorer for Sykehusapotekene Negativtrykk Isolatorer (alle størrelser) Bilag 7 Samlet pris og prisbestemmelser Tittel: Isolator Sykehusapotekene HF, Sykehusapotek Midt-Norge

Detaljer

Samarbeid om IKT-løysingar lokalt

Samarbeid om IKT-løysingar lokalt Delavtale mellom XX kommune og Helse Førde HF Samarbeid om IKT-løysingar lokalt Avtale om samarbeid om IKT-løysingar lokalt 1. Partar Avtalen er inngått mellom XX kommune og Helse Førde HF. 2. Bakgrunn

Detaljer

TILSLUTNINGSAVTALE FOR CAMTASIA RELAY

TILSLUTNINGSAVTALE FOR CAMTASIA RELAY TILSLUTNINGSAVTALE FOR CAMTASIA RELAY Mellom UNINETT AS ("UNINETT") og ("Virksomheten") heretter samlet omtalt som "Partene", er det i dag inngått følgende avtale ("Avtalen"): 1/6

Detaljer

Systemer i UH-sektoren. 31. Oktober 2012 Tromsø. Alf Hansen Seniorrådgiver

Systemer i UH-sektoren. 31. Oktober 2012 Tromsø. Alf Hansen Seniorrådgiver Systemer i UH-sektoren 31. Oktober 2012 Tromsø Alf Hansen Seniorrådgiver 1. Innledning Agenda 2. Systemer i forhold til viktige prosesser i UH-sektoren: PBO-prosessen (Plan budsjett og oppfølging) BTB

Detaljer

Kort om anskaffelsesgrunnlag for nytt fagsystem for digital

Kort om anskaffelsesgrunnlag for nytt fagsystem for digital Kort om anskaffelsesgrunnlag for nytt fagsystem for digital cm byggesaksbehandling Versjon 1.0 2015 KOMMUNESEKTORENS ORGANISASJON The Norwegian Association of Local and Regional Authorities Dokumenthistorikk

Detaljer

Kravspesifikasjon, digitale skilter. Utkast v4 25/9-2015

Kravspesifikasjon, digitale skilter. Utkast v4 25/9-2015 Kravspesifikasjon, digitale skilter Terje Kvernes, AV-koordinator Det Matematisk-naturvitenskapelige fakultet August, 2015 1. Bakgrunn På det matematisk-naturvitenskapelige fakultetet benyttes det i dag

Detaljer

SSA-V Bilag 1. Vedlikeholdsavtalen (SSA-V) Bilag 1: Kundens kravspesifikasjon

SSA-V Bilag 1. Vedlikeholdsavtalen (SSA-V) Bilag 1: Kundens kravspesifikasjon SS-V Bilag Vedlikeholdsavtalen (SS-V) Bilag : Kundens kravspesifikasjon SS-V Bilag Dokumenthistorikk Versjon Dato Beskrivelse av endring Forfatter(e) 0.8 08.2 20 Dokumentet som ble sendt ut på innspillsrunden

Detaljer

Finansportalen Historiske bankdata

Finansportalen Historiske bankdata Bilag 6: Administrative bestemmelser For Finansportalen Historiske bankdata Åpen anbudskonkurranse Bilag 6 Administrative bestemmelser Innholdsfortegnelse 1 AVTALEN PUNKT 1.9: PARTENES REPRESENTANTER...

Detaljer

Saksnummer: 14/XXX KONKURRANSEGRUNNLAG. Kjøp av bærbare PC er og nettbrett Til Stangnes videregående skole

Saksnummer: 14/XXX KONKURRANSEGRUNNLAG. Kjøp av bærbare PC er og nettbrett Til Stangnes videregående skole Saksnummer: 14/XXX KONKURRANSEGRUNNLAG Kjøp av bærbare PC er og nettbrett Til Stangnes videregående skole 1 OPPDRAGET 1.1 Oppdragsgiver Stangnes videregående skole innbyr til begrenset anbudskonkurranse

Detaljer

Den lille kjøpsavtalen Avtale om kjøp, disposisjonsrett og andre ytelser ved IT-anskaffelser i mindre omfang Statens standardavtaler for

Den lille kjøpsavtalen Avtale om kjøp, disposisjonsrett og andre ytelser ved IT-anskaffelser i mindre omfang Statens standardavtaler for Den lille kjøpsavtalen Avtale om kjøp, disposisjonsrett og andre ytelser ved IT-anskaffelser i mindre omfang Statens standardavtaler for IT-anskaffelser SSA-K lille SSA-K_lille 19-03-2009 Avtale om kjøp,

Detaljer

Arbeids- og sosialdepartementet. Omlegging av AFP og tilpasninger i tjenestepensjonsordningene i privat sektor. Konkurransegrunnlag

Arbeids- og sosialdepartementet. Omlegging av AFP og tilpasninger i tjenestepensjonsordningene i privat sektor. Konkurransegrunnlag Til tilbydere Vår dato 04.05.2015 Omlegging av AFP og tilpasninger i tjenestepensjonsordningene i privat sektor Konkurransegrunnlag Anskaffelse iht. FOA del I Sak 15/1485 Innholdsfortegnelse Konkurransegrunnlag...

Detaljer

Bilag 6 Vedlegg 9 - Oversikt over dokumentasjon, planer og rapporter

Bilag 6 Vedlegg 9 - Oversikt over dokumentasjon, planer og rapporter Bilag 6 Vedlegg 9 - Oversikt over dokumentasjon, planer og rapporter Versjonshåndtering Versjon Dato Initiert av Endringsårsak 1.0 16.05.2013 Difi Dokument distribuert til tilbydere 2.0 20.08.2013 Difi

Detaljer

4.1. Kravspesifikasjon

4.1. Kravspesifikasjon 4.1. Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker. 4.1.1. Innledning Informasjon om hvordan kravspesifikasjonens

Detaljer

Generell Rammeavtale om Konsulenttjenester

Generell Rammeavtale om Konsulenttjenester Generell Rammeavtale om Konsulenttjenester Side 2 av 10 RAMMEAVTALE OM KJØP AV KONSULENTTJENESTER Avtalen er inngått mellom: (heretter kalt Leverandøren) og Helse Nord RHF (heretter kalt Kunden) Sted og

Detaljer

Standardisering og gjenbruk / sambruk av IT-komponenter i offentlig sektor

Standardisering og gjenbruk / sambruk av IT-komponenter i offentlig sektor Standardisering og gjenbruk / sambruk av IT-komponenter i offentlig sektor IKT-konferansen Høgskolen i Buskerud 4. november 2010 Kristin Kopland (Difi) (kristin.kopland@difi.no) Agenda Hvilke oppgaver

Detaljer

1 INNLEDNING... 2. 1.1 Om Altinn... 2. 1.2 Skjemaer som støttes... 2 2 INSTALLASJON OG OPPSTART... 3. 2.1 Nedlasting... 3. 2.2 Registrering...

1 INNLEDNING... 2. 1.1 Om Altinn... 2. 1.2 Skjemaer som støttes... 2 2 INSTALLASJON OG OPPSTART... 3. 2.1 Nedlasting... 3. 2.2 Registrering... INNHOLD Mamut for Altinn INNHOLD 1 INNLEDNING... 2 1.1 Om Altinn... 2 1.2 Skjemaer som støttes... 2 2 INSTALLASJON OG OPPSTART... 3 2.1 Nedlasting... 3 2.2 Registrering... 5 2.3 Opprett en bruker... 7

Detaljer

Vedlegg 9.4 KONTRAKTSBETINGELSER RAMMEAVTALE FOR ADVOKATTJENESTER

Vedlegg 9.4 KONTRAKTSBETINGELSER RAMMEAVTALE FOR ADVOKATTJENESTER Vedlegg 9.4 KONTRAKTSBETINGELSER RAMMEAVTALE FOR ADVOKATTJENESTER 1. FORMÅL Rammeavtalens formål er å sikre at kommunenes behov for advokattjenester blir dekket når kapasiteten og kompetansen til egne

Detaljer

Kravspesifikasjon for

Kravspesifikasjon for for ANSKAFFELSE AV Utarbeide WEB løsning samt maler for dokumenter og publikasjoner Luftambulansetjenesten ANS 21. juni 2012 INNHOLDSFORTEGNELSE: 1. FORORD... 3 2. KRAVSPESIFIKASJONENS OMFANG... 3 2.1

Detaljer

Bilag 7 Vedlegg 2 - Tjenestekatalog med standardpriser

Bilag 7 Vedlegg 2 - Tjenestekatalog med standardpriser Bilag 7 Vedlegg 2 - Tjenestekatalog med standardpriser Versjonshåndtering Versjon Dato Initiert av Endringsårsak 1.0 16.05.2013 Difi Dokument distribuert til tilbydere 2.0 20.08.2013 Difi Endret til ny

Detaljer

Dataforeningens kontraktsstandard for IT-drift. Del III - Bilag

Dataforeningens kontraktsstandard for IT-drift. Del III - Bilag Dataforeningens kontraktsstandard for IT-drift Del III - Bilag DEN NORSKE DATAFORENING Versjon : 1.0 Dato oppdatert : 03.12.2008 Kunde: Leverandør:USIT Driftsavtale nr.: Parafering: / Dataforeningens kontraktsstandard

Detaljer

Norsk standardisering i samarbeid med EU. Jan Mærøe Seniorrådgiver Direktoratet for forvaltning og IKT (Difi)

Norsk standardisering i samarbeid med EU. Jan Mærøe Seniorrådgiver Direktoratet for forvaltning og IKT (Difi) Norsk standardisering i samarbeid med EU Jan Mærøe Seniorrådgiver Direktoratet for forvaltning og IKT (Difi) OFFENTLIG SEKTOR SOM PÅDRIVER FOR STANDARDISERING OG DIGITALISERING Direktoratet for forvaltning

Detaljer

Bilag 8 Endringer i den generelle avtaleteksten

Bilag 8 Endringer i den generelle avtaleteksten Bilag 8 Endringer i den generelle avtaleteksten 1 / 16 Versjonshåndtering Versjon Dato Initiert av Endringsårsak 1.0 16.05.2013 Difi Dokument distribuert til tilbydere 2.0 20.08.2013 Difi

Detaljer

IKA kjernen SAMDOK konferansen Gardermoen

IKA kjernen SAMDOK konferansen Gardermoen IKA kjernen SAMDOK konferansen Gardermoen VÅRT LØSNINGSFORSLAG 1. Gi kommunene tilbake kontrollen over sine egne arkiv > Distribuere åpen kildekode Noark 5 kjerne 2. Etablere kostnadseffektive prosesser

Detaljer

Risikoanalysen beskriver status per 30.04.13 med tiltak/kommentarer for hver enkel risikofaktor.

Risikoanalysen beskriver status per 30.04.13 med tiltak/kommentarer for hver enkel risikofaktor. Felles studentsystem Telefon: 22852738 USIT, Universitetet i Oslo Telefax: 22852970 Postboks 1086, Blindern E-mail: fs-sekretariat@usit.uio.no 0316 Oslo URL: www.fs.usit.uio.no FS-13-089 ALL Til: Styret

Detaljer

TILSLUTNINGSAVTALE FOR Mediasite Tjeneste

TILSLUTNINGSAVTALE FOR Mediasite Tjeneste TILSLUTNINGSAVTALE FOR Mediasite Tjeneste Mellom UNINETT AS ("UNINETT") og INSTITUSJON INN HER ("Virksomheten") heretter samlet omtalt som "Partene", er det i dag inngått følgende avtale ("Avtalen"): 1/6

Detaljer

Del B Konkurransegrunnlag Kravspesifikasjon. Rammeavtale telefoniprodukter:

Del B Konkurransegrunnlag Kravspesifikasjon. Rammeavtale telefoniprodukter: spesifikasjon Del B Konkurransegrunnlag spesifikasjon Rammeavtale telefoniprodukter: Telefonsentraler Støttesystemer Fasttelefoner Satelittelefoner Tilhørende tjenester Dokumentets dato: 08.05.2013 Saksnummer:

Detaljer

Konkurransegrunnlag Medieovervåking for Riksrevisjonen

Konkurransegrunnlag Medieovervåking for Riksrevisjonen Konkurransegrunnlag Medieovervåking for Riksrevisjonen Side 1 av 9 Innholdsfortegnelse 1. Opplysninger om anskaffelsen... 3 1.1 Oppdragsgiver... 3 1.2 Kunngjøring... 3 1.3 Beskrivelse av anskaffelsen...

Detaljer

Konkurransegrunnlag Forprosjekt for innsamling om bruk og rettsoppfatninger fra muntlige kilder

Konkurransegrunnlag Forprosjekt for innsamling om bruk og rettsoppfatninger fra muntlige kilder Forside Konkurransegrunnlag Forprosjekt for innsamling om bruk og rettsoppfatninger fra muntlige kilder Konkurranse med forhandling (FoA) Tilbudsfrist: 21. mars 2011 Kl. 12:00 Finnmarkskommisjonen inviterer

Detaljer

KONTRAKT NS 8406 BYGG- OG ANLEGGSARBEIDER

KONTRAKT NS 8406 BYGG- OG ANLEGGSARBEIDER KONTRAKT NS 8406 BYGG- OG ANLEGGSARBEIDER mellom (heretter kalt byggherren) og (heretter kalt entreprenøren) Organisasjonsnr.:. om (kort beskrivelse av kontraktsarbeidet) Kontrakt NS 8406:2009 Forenklet

Detaljer

KONTRAKT FOR VEKTERBEMANNING TIL OSLO TINGRETT I FORBINDELSE MED AVVIKLING AV SAKEN ETTER HENDELSENE 22.07.11.

KONTRAKT FOR VEKTERBEMANNING TIL OSLO TINGRETT I FORBINDELSE MED AVVIKLING AV SAKEN ETTER HENDELSENE 22.07.11. KONTRAKT FOR VEKTERBEMANNING TIL OSLO TINGRETT I FORBINDELSE MED AVVIKLING AV SAKEN ETTER HENDELSENE 22.07.11. Kontraktsreferanse: Kontraktsområde: [Sett inn korrekt kontraltsnr./-referanse] [Kort beskrivelse

Detaljer

Web-rapportering og Web Økonomi i Agresso. Terje Aandalen, UNINETT

Web-rapportering og Web Økonomi i Agresso. Terje Aandalen, UNINETT Web-rapportering og Web Økonomi i Agresso Terje Aandalen, UNINETT Bakgrunn Agresso Økonomi har vært i bruk i sektoren siden 1997 Plattformen har vært Windows-basert Pålogging og brukergrensesnitt for rapporteringsbrukere

Detaljer

Lotteri- og stiftingstilsynet

Lotteri- og stiftingstilsynet www.isobar.no Isobar Norge Org.nr. 990 566 445mva Pilestredet 8 / N- 0180 Oslo. hello@isobar.no Lotteri- og stiftingstilsynet - Vurdering av publiseringsløysingar basert på open kjeldekode Utarbeida for:

Detaljer

Generell Feide-arkitektur

Generell Feide-arkitektur Generell Feide-arkitektur Introduksjon Feide er i stor grad innført i universitets- og høgskolesektoren, og blir nå innført i grunnopplæringen. Samtlige fylkeskommuner er enten ferdige eller godt i gang

Detaljer

Tilbyder kan også legge ved andre opplysninger om den tilbudte løsningen som han mener er av betydning for leveransen.

Tilbyder kan også legge ved andre opplysninger om den tilbudte løsningen som han mener er av betydning for leveransen. 1. INNLEDNING en fastslår hvilke konkrete krav oppdragsgiver stiller til leveransen, samt de grunnleggende forhold som må være tilstede for at tilbudet skal komme i betraktning. Leverandør må påse at det

Detaljer

Bilag 7 Samlet pris og prisbestemmelser

Bilag 7 Samlet pris og prisbestemmelser Anskaffelse av fakturadistribusjon for Fjellinjen AS Bilag 7 Samlet pris og prisbestemmelser INNHOLD 1 DOKUMENTINFORMASJON... 2 2 INTRODUKSJON... 2 2.1 Veiledning til utfylling av tabeller og evalueringsmodell...

Detaljer

VEDLEGG B PRIS OG BETALINGSBETINGELSER GASS

VEDLEGG B PRIS OG BETALINGSBETINGELSER GASS DEL II Vedlegg B Pris og betalingsbetingelser Side 1 av 7 VEDLEGG B PRIS OG BETALINGSBETINGELSER GASS DEL II Vedlegg B Pris og betalingsbetingelser Side 2 av 7 1 PRIS... 3 1.1 Generelt... 3 1.2 Bruksretter...

Detaljer

Tertialrapport for FS Første tertial 2012. 14.06.2012 Felles studentsystem

Tertialrapport for FS Første tertial 2012. 14.06.2012 Felles studentsystem Tertialrapport for FS Første tertial 2012 14.06.2012 Felles studentsystem Tertialrapport for FS Første tertial 2012 Dette er en tertialrapport for FS for første tertial 2012. Punktene i rapporten refererer

Detaljer

KONTRAKT. UNINETT AS (org nr. 968 100 211) Organisasjon (org.nr. )

KONTRAKT. UNINETT AS (org nr. 968 100 211) Organisasjon (org.nr. ) DEL 1 FEIDE TILKNYTNINGSKONTRAKT K00-000 KONTRAKT mellom UNINETT AS (org nr. 968 100 211) (heretter kalt UNINETT) og Organisasjon (org.nr. ) (heretter kalt Organisasjonen) vedrørende tilknytning og bruk

Detaljer

AVTALE. MELLOM OG UNINETT FAS AS. TILSLUTNING TIL RAMMEAVTALE MELLOM UFD OG UNINETT FAS AS OM Teknisk drift av TROFAST-tjenere

AVTALE. MELLOM <Høgskole> OG UNINETT FAS AS. TILSLUTNING TIL RAMMEAVTALE MELLOM UFD OG UNINETT FAS AS OM Teknisk drift av TROFAST-tjenere AVTALE MELLOM OG UNINETT FAS AS TILSLUTNING TIL RAMMEAVTALE MELLOM UFD OG UNINETT FAS AS OM Teknisk drift av TROFAST-tjenere AVTALE OM TILSLUTNING TIL RAMMEAVTALE MELLOM UFD OG UNINETT FAS AS

Detaljer

KUNDENS BESKRIVELSE AV OPPDRAGET

KUNDENS BESKRIVELSE AV OPPDRAGET BILAG 1: Bakgrunn KUNDENS BESKRIVELSE AV OPPDRAGET Byggsøk-byggesak: ByggSøk er et web-basert system for utfylling og innsending av byggesøknader. ByggSøk-bygning ble lansert 01.07 2003 i hht plan- og

Detaljer

Konkurransegrunnlag. Tipskanal

Konkurransegrunnlag. Tipskanal Konkurransegrunnlag Tipskanal Innholdsfortegnelse INNHOLDSFORTEGNELSE 2 1. OPPLYSNINGER OM ANSKAFFELSEN 3 1.1 OPPDRAGSGIVER 3 1.2 KUNNGJØRING 3 1.3 BESKRIVELSE AV ANSKAFFELSEN 3 1.3.1 Bakgrunn for anskaffelsen

Detaljer

Struktur og arkitektur

Struktur og arkitektur Struktur og arkitektur Sammenhengen mellom strukturmeldingen og arbeidet med IT-arkitektur i sektoren. Kan arkitektur bidra til at strukturendringer forenkles? Konsentrasjon for kvalitet En formidabel

Detaljer

AVTALE OM KONSULENTTJENESTER

AVTALE OM KONSULENTTJENESTER AVTALE OM KONSULENTTJENESTER Avtale basert på NS 8401 - oppdrag etter fast pris (forutberegnelighet knyttet til omfanget) Større avvik fra avtale mal avtales med teknisk sjef. Mellom: Oppdragsgiver: Trondheim

Detaljer

Avtale om leie av abonnementsystemet Zubarus. er inngått mellom Crowd Services AS, org.nr 982 895 219 (heretter kalt Leverandøren) og

Avtale om leie av abonnementsystemet Zubarus. er inngått mellom Crowd Services AS, org.nr 982 895 219 (heretter kalt Leverandøren) og Avtale om leie av abonnementsystemet Zubarus er inngått mellom Crowd Services AS, org.nr 982 895 219 (heretter kalt Leverandøren) og (heretter kalt Kunden) Sted og dato: Crowd Services AS Kundens underskrift

Detaljer

Anvendelsesområder for bruk av e-id med og i offentlig sektor- forprosjekt

Anvendelsesområder for bruk av e-id med og i offentlig sektor- forprosjekt Anvendelsesområder for bruk av e-id med og i offentlig sektor- forprosjekt Standardiseringsrådsmøte 23.-24. november 2011 Prioriterings/informasjons -sak Om forprosjektet sett på de mest aktuelle anvendelsesområdene

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

KONTRAKT NS 8406 BYGG- OG ANLEGGSARBEIDER

KONTRAKT NS 8406 BYGG- OG ANLEGGSARBEIDER KONTRAKT NS 8406 BYGG- OG ANLEGGSARBEIDER mellom Bymiljøetaten (heretter kalt byggherren) og (heretter kalt entreprenøren) Organisasjonsnr.:. om Bygging av turvei A10 Sollerudstranda Kontrakt NS 8406:2009

Detaljer

Hva jeg skal snakke om

Hva jeg skal snakke om Noark 5 Del 2 Hva jeg skal snakke om Litt om programvare Proprietær og åpenkildekode Tjeneste orientert arkitekturer Moderne utviklingsmetodikk dots Noark 5 kjerne Viktig men ikke noe som er tatt opp i

Detaljer

KONKURRANSEGRUNNLAG DETALJPLAN FOR BUSTADOMRÅDE SULDAL KOMMUNE

KONKURRANSEGRUNNLAG DETALJPLAN FOR BUSTADOMRÅDE SULDAL KOMMUNE KONKURRANSEGRUNNLAG DETALJPLAN FOR BUSTADOMRÅDE SULDAL KOMMUNE Frist tilbod 15.11.2015 kl.12 15/1076 Detaljplan bustadområde side 1 av 6 INNHALDSLISTE 1 OM KONKURRANSEN... 2 2 KVALIFIKASJONSKRAV... 4 3

Detaljer

BILAG 1 DATABEHANDLERAVTALE

BILAG 1 DATABEHANDLERAVTALE BILAG 1 DATABEHANDLERAVTALE Inngått iht.personopplysningslovens 13, jf. 15 og personopplysningsforskriftens kap. 2 mellom UNINETT AS ("Databehandler") og Virksomheten ("den Behandlingsansvarlige") heretter

Detaljer

KONTRAKT NS 8406 BYGG- OG ANLEGGSARBEIDER

KONTRAKT NS 8406 BYGG- OG ANLEGGSARBEIDER KONTRAKT NS 8406 BYGG- OG ANLEGGSARBEIDER mellom Oslo kommune v/vann- og avløpsetaten (heretter kalt byggherren) og (heretter kalt entreprenøren) Organisasjonsnr.:. om Ullern Bru, kryssing av T-bane Anskaffelse

Detaljer

Delavtale mellom Sørlandets sykehus HF og Lund kommune

Delavtale mellom Sørlandets sykehus HF og Lund kommune Delavtale mellom Sørlandets sykehus HF og Lund kommune Delavtale nr. 9 Samarbeid om IKT-løsninger lokalt Enighet om hvilke plikter og ansvar som partene er ansvarlig for, knyttet til innføring og forvaltning

Detaljer

KONKURRANSEGRUNNLAG FOR ANSKAFFELSE AV

KONKURRANSEGRUNNLAG FOR ANSKAFFELSE AV KONKURRANSEGRUNNLAG FOR ANSKAFFELSE AV Lederutviklingsstøtte ANSKAFFELSESNR. A-92459 FRA NSB Konsern (Oppdragsgiver) UTSENDT DATO: 15. mai 2013 ANSKAFFELSESNR.: A-92459 Lederutviklingsstøtte Side 2 av

Detaljer

KONTRAKT FOR BISTAND TIL ADGANGSKONTROLL I OSLO TINGRETT I FORBINDELSE MED AVVIKLING AV SAKEN ETTER HENDELSENE 22.07.11.

KONTRAKT FOR BISTAND TIL ADGANGSKONTROLL I OSLO TINGRETT I FORBINDELSE MED AVVIKLING AV SAKEN ETTER HENDELSENE 22.07.11. KONTRAKT FOR BISTAND TIL ADGANGSKONTROLL I OSLO TINGRETT I FORBINDELSE MED AVVIKLING AV SAKEN ETTER HENDELSENE 22.07.11. Kontraktsreferanse: Kontraktsområde: [Sett inn korrekt kontraltsnr./-referanse]

Detaljer

TILBUD VISMA PROFILKOM KVINNHERAD KOMMUNE VISMA UNIQUE AS TIL OG VISMA LINK

TILBUD VISMA PROFILKOM KVINNHERAD KOMMUNE VISMA UNIQUE AS TIL OG VISMA LINK TILBUD VISMA PROFILKOM OG VISMA LINK TIL KVINNHERAD KOMMUNE VISMA UNIQUE AS 2. desember 2010 Visma tilbyr en totalleveranse av programvare og tjenester tilknyttet installasjon, oppsett, testing og opplæring

Detaljer

Regulering av fri programvare i SSA

Regulering av fri programvare i SSA Regulering av fri programvare i SSA Advokat dr. juris Rolf Riisnæs WIKBORG REIN rri@wr.no SSA-konferansen 11. mars 2009 1 Hva er fri programvare En fri programvare lisens gir kunden rett til å bruke programvaren

Detaljer

Rollebeskrivelser e-handel

Rollebeskrivelser e-handel Rollebeskrivelser e-handel I dette dokumentet beskrives roller tilknyttet e-handelsprosessen. Beskrivelsen av de ulike rollene er retningsgivende, men må tilpasses den enkelte virksomhet. Følgende roller

Detaljer

Innføring i. av Bent J. Syversen. - seniorrådgiver i Difi

Innføring i. av Bent J. Syversen. - seniorrådgiver i Difi Innføring i av Bent J. Syversen - seniorrådgiver i Difi Fagdag IKT-anskaffelser - Gardermoen 16. januar 2014 «Hvilke avtaler finnes, oppbygning og bruksområder. For deg som vet lite eller ingenting om

Detaljer

Statens legemiddelverk. Generelt om Altinn. EYRA - Digital samhandling med Statens legemiddelverk

Statens legemiddelverk. Generelt om Altinn. EYRA - Digital samhandling med Statens legemiddelverk Statens legemiddelverk Generelt om Altinn EYRA - Digital samhandling med Statens legemiddelverk 10467siwox 03.05.2012 Innhold Hva er Altinn?... 3 Hvorfor benytte Altinn?... 3 Videre utviklingsplan for

Detaljer

Innleveringsløsning, regelverksimplementering og digitalisering

Innleveringsløsning, regelverksimplementering og digitalisering Innleveringsløsning, regelverksimplementering og digitalisering André Hoddevik Seksjonssjef, Difi Generalsekretær OpenPEPPOL AISBL Viktigste Difi-bidrag til digitalisering av anskaffelser Standardisering

Detaljer

KONTRAKT NS 8406 BYGG- OG ANLEGGSARBEIDER. Gjemnes kommune

KONTRAKT NS 8406 BYGG- OG ANLEGGSARBEIDER. Gjemnes kommune KONTRAKT NS 8406 BYGG- OG ANLEGGSARBEIDER mellom Gjemnes kommune og.. (heretter kalt entreprenøren) Organisasjonsnr.: om Rammeavtale (kort beskrivelse av kontraktsarbeidet) Kontrakt NS 8406:2009 Forenklet

Detaljer

Forstudie innføring av unike identifikatorer for studier i Norge. André Løvik Prosjektleder Utdanning.no ved Senter for IKT i utdanningen

Forstudie innføring av unike identifikatorer for studier i Norge. André Løvik Prosjektleder Utdanning.no ved Senter for IKT i utdanningen Forstudie innføring av unike identifikatorer for studier i Norge André Løvik Prosjektleder Utdanning.no ved Senter for IKT i utdanningen Føringer for prosjektet Senter for IKT i utdanningen har i sin virksomhetsplan

Detaljer

Kompetanseforum Vest-Finnmark

Kompetanseforum Vest-Finnmark Kompetanseforum Vest-Finnmark innbyr til tilbudskonkurranse vedrørende anskaffelse av: Lederutdanning Undervisningstjenester til eget personale, Kompetanseforum Vest-Finnmark Innhold: 1. OPPDRAGSGIVER...

Detaljer

Valg av kontraktsstandard Fugleperspektiv («intro til dagen»)

Valg av kontraktsstandard Fugleperspektiv («intro til dagen») Valg av kontraktsstandard Fugleperspektiv («intro til dagen») Bent J. Syversen - seniorrådgiver i Difi IT-kontraktsdagen 2014 Dataforeningen Dato KISS Agenda 1. Hvilke standardkontrakter finnes på IT-området?

Detaljer

KONTRAKT. mellom. (heretter kalt Oppdragsgiver) (heretter kalt Konsulenten) Organisasjonsnr.: ( navn på oppdraget)

KONTRAKT. mellom. (heretter kalt Oppdragsgiver) (heretter kalt Konsulenten) Organisasjonsnr.: ( navn på oppdraget) KONTRAKT mellom (heretter kalt Oppdragsgiver) og. (heretter kalt Konsulenten) Organisasjonsnr.: om. ( navn på oppdraget) For denne kontrakten gjelder Standard kontraktsvilkår for Kongsbergregionens kjøp

Detaljer

Nasjonal løsning for elektronisk faktura og e-handel

Nasjonal løsning for elektronisk faktura og e-handel Nasjonal løsning for elektronisk faktura og e-handel Løsningen med størst vekst i Norge Roadshow 2014 Olav Kristiansen, prosjektleder - elektronisk faktura, Difi Per Martin Jøraholmen seksjonssjef, DFØ

Detaljer

Småteknisk Cantor Controller installasjon

Småteknisk Cantor Controller installasjon Cantor AS Småteknisk Cantor Controller installasjon 10.10.2012 INSTALLASJON OG OPPSETT AV CANTOR CONTROLLER 3 Nedlasting av programfiler 3 Nyinstallasjon server / enbruker 3 A. Controller instansen som

Detaljer

Strategi Samarbeidstiltaket og systemet FS (Felles studentsystem)

Strategi Samarbeidstiltaket og systemet FS (Felles studentsystem) Strategi Samarbeidstiltaket og systemet FS (Felles studentsystem) Versjon 10. juni 2013 1 Bakgrunn Samarbeidstiltaket FS er et samarbeid mellom norske universiteter og høgskoler med ansvar for å videreutvikle

Detaljer

Operatør av Doffin er EU-Supply Holding Ltd. (EU-Supply). Direktoratet for forvaltning og IKT (Difi)

Operatør av Doffin er EU-Supply Holding Ltd. (EU-Supply). Direktoratet for forvaltning og IKT (Difi) 1 Informasjon om Doffin Den nasjonale publiseringstjenesten www. Doffin.no er databasen hvor oppdragsgivere publiserer innkjøp. Alle innkjøp over den norske terskelverdi, pålydende 500 000 NOK skal publiseres

Detaljer

Kommentarer til kravspesifikasjon

Kommentarer til kravspesifikasjon Kommentarer til kravspesifikasjon 1 Innledning Universitets- og høgskolesektoren(uh-sektoren) har gått sammen om anskaffelse av rekrutteringssystem. Prosjektet har 26 rettighetshavere. Prosessen eies og

Detaljer

Rammeavtale 14/4768 Unntatt offentlighet jf. offentlighetsloven 13 og forvaltningsloven 13 1. ledd nr.2.

Rammeavtale 14/4768 Unntatt offentlighet jf. offentlighetsloven 13 og forvaltningsloven 13 1. ledd nr.2. Rammeavtale 14/4768 Unntatt offentlighet jf. offentlighetsloven 13 og forvaltningsloven 13 1. ledd nr.2. mellom Lørenskog kommune (Oppdragsgiver) og xxxxxxxxxxxxxxxxxx (Leverandør) Kjøp av Vikartjenester

Detaljer

Avvisning av klage på offentlig anskaffelse

Avvisning av klage på offentlig anskaffelse Klagenemnda for offentlige anskaffelser CustomPublish AS Møllergata 24 0179 OSLO Norge Deres referanse Vår referanse Dato: 2012/0204-6 01.07.2014 Avvisning av klage på offentlig anskaffelse Det vises til

Detaljer

En bedre måte å håndtere prosjekt, team, oppgaver og innhold

En bedre måte å håndtere prosjekt, team, oppgaver og innhold En bedre måte å håndtere prosjekt, team, oppgaver og innhold Bedre prosjekthå ndtering med metådåtå M-Files går langt utover bare enkel dokumenthåndtering. Den unike arkitekturen drevet av metadata lar

Detaljer