IKT-verktøy for Kvalitetsstyring og internkontrollsystem Bilag

Transcription

Oslo kommune
Byrådsavdelingen for Eldre, Helse og
sosiale tjenester
IKT-verktøy for Kvalitetsstyring og internkontrollsystem
Bilag 1-10 til SSA-K, versjon 2015
Veiledende bilag til SSA-K
Veiledende bilag til SSA-K – Kjøpsavtalen – versjon 2015
Innhold:
Bilag 1: Kundens kravspesifikasjon .............................................................................................. 2
Bilag 2: Leverandørens beskrivelse av leveransen ........................................................................27
Bilag 3: Kundens tekniske plattform ...........................................................................................29
Bilag 4: Leveringstidspunkt og andre frister ................................................................................95
Bilag 5: Godkjenningsprøve ......................................................................................................98
Bilag 6: Administrative bestemmelser ........................................................................................99
Bilag 7: Samlet pris og prisbestemmelser..................................................................................102
Bilag 8: Endringer i den generelle avtaleteksten ........................................................................107
Bilag 9: Endringer av leveransen etter avtaleinngåelsen .............................................................110
Bilag 10: Lisensbetingelser for standardprogramvare og fri programvare ......................................110
Side 1 av 111
Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll
Bilag 1: Kundens kravspesifikasjon
Avtalens punkt 1.1 Avtalens omfang
1. Formål med anskaffelsen
Oslo kommune har behov for å anskaffe et felles IKT-verktøy for å understøtte arbeidet med
Kvalitetsstyring og internkontroll. I første omgang er det sektoren eldre, helse og sosiale tjenester
(EHS) som skal ta i bruk systemet. Øvrige byrådsavdelinger vil håndteres via opsjoner i avtalen, som
kan utløses på et senere tidspunkt.
Kvalitetsstyring og internkontrollverktøyet som anskaffes skal bidra til å understøtte nødvendige
prosesser på ulike nivåer, og må være robust nok til å takle hele Oslo kommune sin organisasjon med
ca. 55.000 ansatte. Oslo kommune har forventinger om at:





Anskaffet løsning skal være ett felles system for Oslo Kommune, der sektoren EHS i første
omgang skal implementere og ta i bruk anskaffet løsning. Virksomheter i andre sektorer kan
innlemmes og implementeres via opsjoner i kontrakten
Myndighetenes kvalitetskrav for dokumenthåndtering og forvaltning av prosedyrer skal
oppfylles for alle nivåer i alle virksomheter som tar i bruk systemet
Alle ansatte skal bruke løsningen som sin foretrukne kilde til informasjon om rutiner,
prosedyrer, aktuelle lover og forskrifter.
Virksomhetene skal ha en enhetlig og korrekt håndtering av avvik, uønskede hendelser og
forbedringsforslag.
Oslo kommune skal med nyanskaffet løsning til enhver tid ha mulighet til å fremskaffe
totaloversikt over innmeldte avvik, uønskede hendelser og forbedringsforslag
Kort om EHS sitt ansvarsområde:
EHS har ansvar for oppfølging av tjenesteutvikling og drift av helse- og omsorgstjenester,
eldreomsorg, tiltak for personer med nedsatt funksjonsevne, forebyggende barne- og
ungdomsarbeid og barnevern, sosiale tjenester og rusomsorg. Se figur 1, Oslo kommunes
organisasjonskart.
Organisasjonsstruktur i Oslo kommune
Oslo kommune, med sine ca 55.000 ansatte er en stor organisasjon som er fordelt på tre nivåer:
 Byråd
 8 byrådsavdelinger
 24 etater, 5 kommunale foretak og 15 bydeler
Oslo kommune styres etter en parlamentarisk styringsmodell som innebærer at byrådet står
ansvarlig overfor bystyret. Det foretas valg hvert 4 år noe som kan medføre behov for endring i
organisasjonen og derav endring i den systematiske oppbygningen av anskaffet kvalitet- og
internkontrollsystem.
Side 2 av 111
Figur 1: Oslo kommunes organisasjonskart
Fellesnivåer
Oslo kommune har behov for et kvalitet- og internkontrollsystem som omfatter minimum 3
fellesnivåer (ref. Oslo kommunes organisasjonskart, figur 1):
Nivå 1 – Fellesområde for alle Byrådsavdelinger (hele Oslo kommune)
Nivå 2 – Fellesområde for den enkelte Byrådsavdeling
Nivå 3 – Fellesområde for den enkelte virksomhet (etat, kommunalt foretak eller bydel)
Systemet må være robust til å kunne håndtere Oslo kommunes organisasjon som helhet samt på en
enkel måte kunne håndtere organisasjonsendringer. Det foretas valg hvert 4 år noe som kan medføre
behov for endring i organisasjonen og derav endring i den systematiske oppbygningen av anskaffet
kvalitetsstyring og internkontrollsystem.
1.1 Roller og tilganger
Kvalitet- og internkontrollsystemet vil ha en betydelig mengde brukere som skal ha ulik tilgang/roller
til løsningen. Det er derfor viktig å forstå hvordan ansettelsesforhold, virksomheter, brukere og roller
henger sammen i Oslo kommune sett opp mot strukturen i løsningen. I avsnittene under beskriver vi
brukeromfang, ansettelsesforhold på et organisatorisk nivå.
Roller og tilganger
I Oslo kommune kan en ansatt ha flere ansettelsesforhold, både innenfor samme virksomhet eller i
andre virksomheter. Ved ansettelsesforhold i flere virksomheter vil den ansatte ha ett unikt
Side 3 av 111
brukernavn i hver av virksomhetene. Innenfor en og samme virksomhet har den ansatte samme
brukernavn uavhengig av hvor mange enheter den ansatte har et arbeidsforhold i. Det er
eksemplifisert i scenario 1 under.
Scenario 1:
En bruker har et ansettelsesforhold i hjemmetjenesten i Bydel Østensjø, og har i tillegg et ojobber i
Bydels Østensjø har den ansatte for eksempel denne brukeridenten BOS12345, når den ansatte
jobber i Sykehjemsetaten er det brukerident SYE12345 som gjelder. Figuren under illustrerer
scenarioet. BOS12345 og SYE12345 er samme ansatt i Oslo kommune.
Figur 2: illustrerer scenario 1
Dokumentstruktur, avvikshåndtering og rettigheter
Figur 2 illustrerer også hvordan avviksmelding/behandling, og dokumentbiblioteket er tenkt i
løsningen. Dette er beskrevet nærmere under.
1. Oslo kommune ønsker full åpenhet i strukturen for dokumenter, prosedyrer og rutiner, men
med mulighet for å avgrense innsyn der hvor det er behov for det, helt ned på enkelt
dokumenter, prosedyrer eller rutiner. Figuren (figur 2) over illustrerer at ansatte kan søke å
lese dokumenter i hele strukturen, gitt at det ikke er satt spesielle avgrensninger.
2. Avvik meldes av ansatte til den enhet som den ansatte er tilknyttet når avviket inntreffer. Er
den ansatte på jobb for eksempel ved Sykehjem 1 skal avviket meldes dit. Avviket sendes til
og behandles av nærmeste leder. Avviket skal kun behandles eller leses av den som har
meldt avviket, avviksbehandler (default nærmeste leder) og eventuelt andre som er gitt
innsyn – for eksempel vernetjeneste eller tilsvarende.
Oslofelles, Oslo kommunes felles driftsplattform
Oslofelles er Oslo kommunes felles driftsplattform og driftes av Utvikling- og kompetanseetaten UKE.
Plattformen leverer arbeidsflatetjeneste, applikasjonstjenere, databasetjenere, basistjenester og
Side 4 av 111
lignende til mange virksomheter i Oslo kommune. Plattformen er bygget på moderne og velkjent
teknologi. Se bilag 3 Kundens tekniske plattform for nærmere informasjon.
Administrasjon av roller og tilganger
Person- og ressurskatalogen, PRK, er en felles hovedkilde for person- og ressursdata i Oslo kommune.
PRK er masterdatasystem for personopplysninger som overføres blant annet til Active Directory i
Oslofelles. PRK samhandler med HR systemet slik at masterdata vedlikeholdes ett sted.
PRK er verktøyet som brukes for brukeradministrasjon for brukerkontoer og tilganger til ulike
systemer og data. Innhold i PRK kan via integrasjonsplattformen ITAS eksportere ut
organisasjonsstruktur for virksomheter, brukerinformasjon med organisasjonstilhørighet(er) og roller
til forskjellige formater, som for eksempel JSON eller XML. Se bilag 3 Kundens tekniske plattform for
nærmere beskrivelse av PRK og ITAS.
1.2 Leveransens omfang
Avtaleforholdet mellom Kunde og Leverandør er regulert av denne SSA-K, SSA-V, samt
databehandleravtalen (vedlegg til SSA-V: Databehandleravtale). Krav til etablering, test og
godkjenning av løsningen fremgår av SSA-K med bilag, dog slik at SLA-krav og krav til ordinær drift
iht. SSA-V kap. 2.2 flg. gjelder i godkjenningsperioden.
1.2.1 Hovedleveransen
EHS sektoren består av 15 bydeler og 4 virksomhetene. Basert på kartlegging kan omfanget
oppsummeres i tabellen under.
Funksjonalitet
Antall brukere (basisfunksjonalitet)
Antall brukere ROS
Antall brukere Årshjul
Antall brukere mobilitet
Antall virksomheter som trenger
migrering
Tabell omfang: oversikt over omfang
Omfang
38000 - 40000
1000 - 2000
1000 - 2000
4000 - 6000
15
Lavest estimert omfang
38000
1000
1000
4000
15
Lisensomfang
Prosjektet vil i samarbeid med leverandøren i fase 4, Oppsett, installering og test (ref bilag 4)
fastsette totalomfanget for EHS basert på uttrekk fra PRK/opptelling av brukere i løsningen. Denne vil
danne grunnlag for totalomfanget av lisenser og utløse betaling i henhold til tabell MP1: Milepæler
(ref. bilag 7).
Leverandøren må påregne justering av antall lisenser som resultat av omorganisering, organisatorisk
vekst/reduksjon i Oslo kommune. En eventuell omorganisering vil kunne resultere i en økning av
lisensomfanget så vel som en reduksjon.
1.2.2 Opsjoner
Vedrørende innføring i andre sektorer: Innføring i andre sektorer ligger utenfor prosjektets mandat.
Slik innføring gjennomføres først etter at systemet er innført i EHS sektoren. Opprettet
forvaltningsorgan og kontaktpunkt for leverandør vil koordinere opsjonsutløsningen.
Side 5 av 111
Sektorer
Tilknyttede virksomheter
Ca. antall
ansatte
12.000
Oppvekst og
kunnskap
(OVK)
Miljø- og
samferdsel
(MOS)
Sektoren består ved siden av byrådsavdelingen også av
Utdanningsetaten.
Beredskapsetaten, Brann- og redningsetaten, Bymiljøetaten,
Energigjenvinningsetaten, Renovasjonsetaten, Vann- og
avløpsetaten samt Oslo Havn KF.
2.255
Kultur,frivillighet
og idrett (KFI)
Gravferdsetaten, Kulturetaten, Næringsetaten, Boligbygg Oslo KF,
Kultur og idrettsbygg Oslo KF, Omsorgsbygg Oslo KF samt
Undervisningsbygg Oslo KF.
1.220
Byutvikling
(BYU)
Finans
(FIN)
Sektoren består ved siden av byrådsavdelingen også av Eiendomog byfornyelsesetaten, Plan- og bygningsetaten, Byantikvaren.
Kemnerkontoret og Utviklings- og kompetanseetaten.
600
540
Byrådslederens
Ingen virksomheter
kontor (BLK)
Bystyrets
Ingen virksomheter
sekretariat (BYS)
Kommunerevisjon Ingen virksomheter
en
(KRV)
Tabell opsjoner: oversikt over størrelse på opsjoner
85
50
50
1.3 Kundens krav til leveransen
Kravspesifikasjonen er inndelt i disse grupperingene:
● Generelle krav
● Krav til informasjonssikkerhet og tilgangsstyring
● Funksjonelle krav
● Krav til gjennomføring
● Krav til opplæring
● Eksterne rettslige krav
Det er satt minimumskrav (Må-krav), dette er obligatoriske krav som må oppfylles. I tillegg er det satt
Bør-krav, disse kravene vil bli evaluert under tildelingskriteriet «Kvalitet».
I Leverandørenes besvarelse (Bilag 2) skal kravene dokumenteres slik det fremgår av krav til
dokumentasjon i kravtabellene.
Det er i kravtabellene benyttet 2 typer krav, disse vil hensyntas forskjellig ved evaluering.
Kravene i tabellene nedenfor skal leses slik:
Type krav
Forklaring
Kode
Må-krav
Vurderes som oppfylt eller ikke ut i fra etterspurt
M
Side 6 av 111
Bør-krav
dokumentasjon/leverandørenes egenerklæring.
Manglende oppfyllelse vil føre til avvisning.
Vurderes under tildelingskriteriet «Kvalitet» og
evalueres ut i fra beste oppfyllelses av hvert krav.
For funksjonelle krav i tabellene F3 – F11 vil best
oppfyllelses av krav og brukervennlighet bli
evaluert.
B
Ved vurdering av oppfyllelse av Bør-krav, brukes både skriftlig dokumentasjon og
videopresentasjoner.
I kravtabellene fremgår det på hvilket format vi ønsker kravene dokumentert.
 Der vi ber om skriftlig dokumentasjon, ønske vi kravet dokumenter i Word og PDF format. For
videopresentasjoner ber vi om at det lages i formater som støttes av standardprodukter som
følger Windows 7.
 Der vi ber om video ønsker vi video av hele prosessen, men at det klart fremgår i videoen
hvilket krav som presenteres. For eksempel ber vi om video på flere krav i tabell F4. Vi ønsker
én video som beskriver hele prosessen i tabell F4, men at det klart fremgår i videoen når
hvert enkelt krav beskrives. Videoene ønskes kommentert med lyd.
 Der vi ber om video og leverandørens beskrivelse mener vi at videoen skal vise
funksjonaliteten av kravet, men at leverandørens beskrivelse utdyper funksjonaliteten
nærmere.
1.5.1 Tildelingskriteriet Kvalitet
Det vil bli benyttet en poengskala fra 0-10, hvor det beste tilbudet oppnår 10 poeng og videre
forholdsmessig lavere poeng. Poengene pr. Bør-krav multipliseres deretter med vekting som
beskrevet under. Det er verdt å merke seg at Generelle krav, Krav til informasjonssikkerhet og
tilgangsstyring, samt funksjonelle krav består av Må og Bør krav.
Krav til gjennomføring, krav til opplæring og eksterne rettslige krav består kun av Må krav og
vurderes om oppfylt/ikke oppfylt basert på leverandørens besvarelse.
Tildelingskriteriet Kvalitet er vektet til 60 % som følger:
Gruppering
Vekt Undervekting av Bør-kravene
Generelle krav (tabell G1)
30 % Krav G 1.10 vektes 30%, resterende bør-krav i de
Krav til informasjonssikkerhet og
to tabellene vektes til sammen 70%
tilgangsstyring (tabell S2)
Funksjonelle krav basisfunksjonalitet
60 %
(tabell F3-F9)
Funksjonelle krav ROS og Årshjul,
10 %
(tabell F10-F11)
1.5.2 Tildelingskriteriet Pris
Pristilbudet skal inneholde:
Oppstartskostnader:
A. Installasjon og tilrettelegging for omfang beskrevet i tabell omfang i kapitel. 1.2.1
Hovedleveransen dette bilaget, og tabell GJ 12: Krav til gjennomføring, ref krav GJ 12.1.
Herunder:
o Installasjonskostnader for basisfunksjonalitet (beskrevet i tabell F3-F9)
o Installasjonskostnader for ROS, Årshjul (beskrevet i tabell F10 og F11) og mobilløsning.
Side 7 av 111
B. Etablering av testplaner sammen med Oslo kommune og test av selve løsningen etter
installasjon og tilrettelegging (inkluderer ikke test av migrering, Single sign-on, PRK import og
Exchange integrasjon).
C. Opplæring (ihht punkt 2.1.4 i dette bilaget)
o Opplæring skal prises pr. rolle basert på klasseromsundervisning for inntil 15 personer.
Oslo kommune er ansvarlig for å fremskaffe undervisningslokaler og administrere
påmelding.
Lisenskostnader:
D. Lisenser basisfunksjonalitet pr. bruker/pr. år.
E. Lisenser på ROS, Årshjul og mobilløsning pr. bruker pr. år
Hva vi mener med Basisfunksjonalitet fremkommer i kravtabellene F3-F9
Hva vi mener med ROS og Årshjul fremkommer i kravtabellene F10 og F11
Med mobilitet menes tilgang fra mobile enheter
Omfanget er beskrevet i tabell omfang i kapittel 1.2.1 Hovedleveransen
Opsjoner:
F. Prising av Opsjoner (nye virksomheter som fases inn), herunder:
opprette ny virksomhet i løsningen
tilpasse etablert organisasjonsstruktur med nye virksomheter
tilpasse avviksskjema og avviksgrupperinger ved behov
Øvrig funksjonalitet:
G. Øvrig funksjonalitet/moduler som leverandøren tilbyr. Evalueres ikke.
H. Dersom leverandøren tilbyr e-læring. Evalueres ikke.
Tildelingskriteriet Pris er vektet til 40 % som følger:
Gruppering
Undervekting
Oppstartskostnader:
15 % av
oppstartskostna
 Installasjon og tilrettelegging,
samt etablering av testplaner og der (ref. punkt
A, B og C).
testing(ihht beskrivelse over,
punkt A og B)
 Opplæring (punkt C).
Lisenskostnader:
75 % av
lisenskostnader
 Lisenser, Basisfunksjonalitet
(ref. punkt D, og
(punkt D)
E)
 Lisenser, ROS, Årshjul og
mobilitet (punkt E)
Opsjoner:
10 % (ref. F)
 Tilrettelegging av systemet for
nye virksomheter (punkt F)
Dersom løsningen krever 3. partslisenser skal det fremkomme av pristilbudet. Kostnadene av slike
lisenser vil bli lagt til den totale lisenskostnaden i evaluering av tilbudene.
Samlet pris og prisbestemmelser (bilag 7) gir ytterligere informasjon om prising av tjenestene.
2. Generelle krav
Tabell G1: Generelle krav til systemet
Side 8 av 111
Krav nr
Krav
M/B
Dokumentasjon
Leverandøren
beskriver hvilke
standarder de
tilfredsstiller.
Leverandørens
bekreftelse
Leverandørens
bekrefter om
deres løsning kan
installeres på
Oslofelles og
oppgir systemkrav
til deres løsning.
G 1.1
Systemene bør tilfredsstille anerkjent standarder for
kvalitetsstyring og internkontroll.
B
G 1.2
Brukerdialoger og menyer skal være på norsk.
M
G 1.3
Løsningen må fungere på Oslo kommunes (Oslofelles)
tekniske plattform og støtte bruk av arbeidsflatene
Citrix (AKS), VDI, Lokal desktop (via VPN), samt
fungere sammen med utskriftsløsningen i Oslo
kommune. Se Bilag 3 Kundens tekniske plattform.
M
G 1.4
Løsningen må støtte Single sign-on for brukere som
er pålogget Oslo kommunes interne nettverk
(brukernavn og passord fra kommunens person- og
ressurskatalog, PRK).
M
Leverandøren
beskriver hvordan
dette skal løses i
Oslofelles.
M
Leverandørens
beskrivelse.
Løsningen må også støtte pålogging med brukernavn
og passord fra f.eks mobile enheter.
G 1.5
Løsningen må ha støtte for disse hovedområdene:
 Avvikshåndtering
 Dokumenthåndtering
 Statistikk og rapportering
 Risiko- og sårbarhetsanalyse
 Aktivitetsplanlegging (årshjul)
Side 9 av 111
G 1.6
Løsningen bør være plattformuavhengig (pc, mac,
mobiltelefoner, nettbrett)
B
G 1.7
Løsningen bør støtte anerkjente standarder for
informasjonsutveksling, som f.eks JSON eller XML.
B
G 1.8
Leverandøren bør bidra til at løsningen holder tritt
med teknologiutviklingen.
B
G 1.9
Løsningene bør være utviklet i henhold til
Referansekatalog for IT-standarder i offentlig sektor.
B
http://standard.difi.no/forvaltningsstandarder
Leverandøren
beskriver hvilke
deler av løsningen
som er spesielt
tilpasset bruk på
mobil/ nettbrett
og hvordan
samvirke mellom
nettsted og
smarttelefon/nett
brett gjøres, for
eksempel ved
responsivt design
og/eller «app».
Leverandørene
bes spesielt
beskrive hvordan
løsningen fungerer
sammen med
smarttelefoner
med Windows
operativsystem
Leverandørens
beskrivelser hvilke
standarder de
støtter.
Leverandørens
beskrivelse sine
aktiviteter for å
videreutvikle
løsningen som for
eksempel
brukerforum,
utviklingsplaner,
og lignende.
Leverandøren skal
beskrive hvordan
de imøtekommer
de obligatoriske
kravene i
standarden og
spesielt krav til
universell
utforming.
Side 10 av 111
G 1.10
Løsningen bør være en felles løsning for Oslo
kommune og være robust samt fleksibel til å
understøtte Oslo kommunes organisasjon med 3
fellesnivåer og størrelse, ref. organisasjonskart figur 1
i kapitel 1 Formål med anskaffelsen.
B
G 1.11
Grensesnittet til systemet skal følge åpne standarder
ift kommunikasjonsprotokoller. Det er krav om bruk
av HTTPS som protokoll på applikasjonslaget, men
åpent for forskjellige kommunikasjonsprotokoller
utenpå dette.
REST er å foretrekke der det er mulig, alternativt Web
Services.
Dersom løsningen krever 3. partsløsninger eller
lisenser så skal dette opplyses om.
Løsningen skal benytte ITAS tjenestebuss for
utveksling av data med systemer i Oslo kommune. Se
Bilag 3 Kundens Tekniske plattform.
Løsningen må kunne etableres og virke på databaser
hvor det benyttes innholdskryptering, som for
eksempel TDE (Transparent Data Encryption).
M
G 1.12
G 1.13
G 1.14
M
M
M
Oslo kommune
ønsker at
leverandørene
beskriver
hvorledes deres
system er
fleksibelt til å
understøtte Oslo
kommunes
størrelse og
egenart, og
fleksibilitet i
forhold til
omorganisering.
Leverandørens
beskrivelse.
Leverandørens
beskrivelse.
Leverandørens
bekreftelse.
Leverandøren
beskriver sine
erfaringer med
løsningen på
innholdskrypterte
databaser og
hvilke
databasesystemer
de støtter.
Krav til informasjonssikkerhet og tilgangsstyring
Oslo kommune er opptatt av at løsningen understøtter vern av den som melder avvik og at innholdet
i avviket er sikret godt nok mot innsyn. Kravene til beskyttelse av data fremkommer i tabellen under,
men også i andre tabeller i dette bilaget.
Tabell S2: Informasjonssikkerhet og tilgangsstyring
Krav nr Krav
S 2.1
Løsningen bør ha funksjonalitet som muliggjør
tilgangsbegrensning til data på grunnlag av dataenes
alder. Dette slik at det skal være mulig å styre tilgang
ut fra når dataene ble lagt inn eller fra når siste
behandling av dataene av navngitt rolle fant sted.
M/B
B
Dokumentasjon
Leverandørens
beskrivelse.
Side 11 av 111
S 2.2
S 2.3
S 2.4
S 2.5
S 2.6
Løsningen bør ha funksjonalitet som muliggjør
sletting av data på grunnlag av dataens alder. Dette
slik at det skal være mulig å slette data ut fra når
dataene ble lagt inn eller fra når siste behandling av
dataene av navngitt rolle fant sted.
Løsningen skal ha funksjonalitet for logging av så vel
oppslag/lesetilgang til avvik som for editering og
sletting av avvik.
Systemadministrator eller andre med rettigheter skal
kunne ta ut denne type informasjon ved behov.
Løsningen har en rollebasert tilgangs- og
rettighetsstyring som støtter differensierte
rettigheter for brukere knyttet til ulike enheter
og/eller organisatoriske nivåer/roller.
Løsningens rollebaserte tilgangs- og rettighetsstyring
skal være fleksibel og kunne tilpasses eventuelle
endringer i organisering. Systemet må kunne
konfigurere brukerhierarkier på minimum 3 nivåer.
Systemet skal enkelt konfigureres slik at bruker bare
skal kunne se saker innenfor sin
gruppe/organisasjonsenhet/rolle
Brukerens profil og logg slettes ikke når ansatt
slutter. Tilganger opphører ved sluttdato.
B
Leverandørens
beskrivelse.
M
Leverandørens
beskrivelse.
M
Leverandørens
beskrivelse.
M
Leverandørens
beskrivelse.
M
Leverandørens
beskrivelse.
3. Funksjonelle krav
Systemadministrasjon
Innledende tekst til tabell (Oslo kommunes krav fremkommer av tabellene):
Løsningen skal ivareta kommunens ønske om en felles forvaltning, men den enkelte virksomhet kan
ha ulike behov for tilgangsstyring og konfigurering av løsningen.
Det stilles derfor krav til både sentral styring av løsningen og en fleksibel tilgangsstyring for
systemadministrasjon som kan delegeres og avgrenses
For å få et bedre innblikk i organisasjonsstruktur og roller refereres til kap 1.1 Roller og tilganger
Tabell F3: Funksjonelle krav systemadministrasjon
Krav nr Krav
F 3.1
Løsningen bør ha en enkel og brukervennlig måte å
ivareta systemadministrasjon på.
M/B
B
Dokumentasjon
Leverandørens
beskrivelse
Side 12 av 111
F 3.2
Det må være mulig å automatisere
oppretting/deaktivering av brukere og roller
M
Leverandøren skal
beskrive hvordan
de ser for seg
dette løst og
oppgir hvilke
formater de kan
importere data
fra, som f.eks
JSON eller XML.
B
Leverandøren skal
beskrive hvordan
de ser for seg
dette løst og
oppgir hvilke
format de
foretrekker for
denne type
informasjonsutvek
sling.
Leverandørens
beskrivelse
Det er i kapitel 1 Formål med anskaffelsen, avsnitt
Administrasjon av roller og tilganger beskrevet at det
er mulig å eksportere ut brukere,
organisasjonstilhørighet og rolle fra PRK. Dette kan
gjøres i flere kjente formater for
informasjonsutveksling, som f.eks JSON eller XML.
F 3.3
Det bør være mulig å automatisere opprettelse av:
 organisasjonsstruktur
Organisasjonsstrukturen i Oslo kommune kan hentes
ut fra PRK.
F 3.4
F 3.5
F 3.6
F 3.7
Løsningen bør være fleksibel i forhold til å kunne
ivareta systemadministrasjon i Oslo kommunes
organisasjon.
Løsningen bør støtte muligheten for å kunne
distribuere enkelte deler av systemadministrasjon til
andre roller, avgrenset til organisatorisk enhet.
Løsningen gir muligheter til å administrere alle
parametere innenfor det organisatoriske området
som det er gitt rettigheter til.
Som eksempelvis:
 opprette og endre roller, samt å gi
rettigheter til roller
 Tildele roller til brukere utover det
som de får fra import, ref krav F 3.2
 sletting av data i løsningen
Det må være mulig manuelt å opprette
organisasjonsstrukturer utover det som ønskes
importert i krav F 3.3
Det bør enkelt være mulig for rollen leder og selv
velge stedfortredere.
B
B
Leverandørens
beskrivelse
M
Leverandørens
beskrivelse
B
Leverandørens
beskrivelse
B
Leverandørens
beskrivelse
Stedfortreder skal automatisk arve rettigheter som
ligger i tildelt rolle.
F 3.8
Systemadministrator bør kunne definere og endre
arbeidsflyt på avviksbehandling.
Side 13 av 111
Avviksrapportering og avvikshåndtering
Systemet skal oppfylle myndighetskrav til systematisk og helhetlig avviksbehandling i Oslo kommune.
Det betyr at alle typer uønskede hendelser skal, på en enkel måte, kunne registreres i systemet og
følges opp, behandles og lukkes på de nivåer som organisasjonen selv ønsker. Systemet må være
fleksibelt og gi støtte for forbedringsarbeid som hovedmålsetting i avviksbehandlingen.
Avviksrapporteringen kan enten gjøres i skjema eller i veiledet dialog. Når vi skriver avviksskjema i
kravtabellene skal det leses som enten skjema eller veiledet dialog.
Tabell F4: Funksjonelle krav til avviksrapportering og avvikshåndtering – melding av avvik
Krav nr Funksjonelle krav
M/B
Dokumentasjon
F 4.1
Den ansatte bør kunne melde avvik og
forbedringsforslag med ferdigdefinert organisatorisk
tilhørighet.
F 4.2
Samme avviksskjema bør kunne benyttes til alle typer B
avvik. Skjemaet bør ha forhåndsdefinerte valg på
viktige felter som for eksempel alvorlighetsgrad og
kunne velge mellom ulike type avvikskategorier. Det
bør være mulighet for obligatoriske felter.
Effektiv prosess for å melde avvik med ledetekster
B
som hjelper i utfyllingen.
Video av
funksjonalitet og
leverandørens
beskrivelse
Avviksmelder bør til enhver tid kunne følge
B
behandlingen av avviket og se hvem som har innsyn i
avviket. Løsningen bør ha mulighet for automatisk
varsling til avviksmelder når avviket lukkes.
Video av
funksjonalitet og
leverandørens
beskrivelse.
F 4.3
F 4.4
B
Video av
funksjonalitet.
Video av
funksjonalitet.
Leverandøren
beskriver spesielt
hvilke løsninger de
har ift varsling.
Video av
funksjonalitet og
leverandørens
beskrivelse
Video av
funksjonalitet
F 4.5
Det bør være mulig å tilføye informasjon i
avviksskjema etter at det er sendt. Det må
fremkomme når tilføyelser er gjort og av hvem.
B
F 4.6
Systemet gir brukeren oversiktlig informasjon over
alle egne meldte hendelser eller forbedringsforslag
og status på disse.
B
F 4.7
Avviksrapportering og avvikshåndtering bør kunne
B
behandles fra ulike type enheter (PC, nettbrett, mobil
o.l)
Leverandørens
beskrivelse
F 4.8
Det bør være mulig å knytte vedlegg til avviket.
B
Leverandørens
beskrivelse
Side 14 av 111
Tabell F5: Funksjonelle krav til avviksrapportering og avvikshåndtering – mottak og behandling av
avvik
Krav nr Krav
M/B
Dokumentasjon
F 5.1
Som avviksbehandler bør man på en enkel,
brukervennlig måte ha tilgang til og oversikt over
avvik som skal behandles.
B
Video av
funksjonalitet
Ansvarlig avviksbehandler får automatisk varsel når
det er registrert et nytt avvik. Systemet bør også
kunne gi proaktive varsler før behandlingsfrist
utløper.
B
Leverandørens
beskrivelse.
Brukergrensesnittet bør være definert slik at det
enkelte avvik med alle detaljer vises i samme
skjermbilde.
Det bør være mulig for avviksbehandler å korrigere
forhåndsdefinerte felter i avviket, men ikke endre
fritekstfelter.
Det bør være mulig for avviksbehandler ved
videresending å fjerne navn på avviksmelder.
Det bør være mulig for avviksbehandler å
kommentere avviket på eget fritekstfelt.
Alle endringer må kunne spores i etterkant av
avviksmelder og andre med innsynstilgang. Det skal
fremgå hvem som har gjort endringer i avviket.
Løsningen bør gi mulighet til å opprette tiltak med
tidsfrist og ansvarlig.
B
Dersom en avviksbehandler har ansvar for flere
organisatorisk enheter bør det enkelt være mulig å
velge enhet.
F 5.2
F 5.3
F 5.4
F 5.5
Leverandøren
beskriver spesielt
har ift varsling.
Video av
funksjonalitet
B
Video av
funksjonalitet og
leverandørens
beskrivelse
B
Video av
funksjonalitet og
leverandørens
beskrivelse
Leverandørens
beskrivelse
F 5.6
Det bør være støtte for videresending av avvik til alle B
enheter i Oslo kommune, som benytter løsningen,
men også mulighet for å sende dokumentasjon i avvik
til andre virksomheter i eller utenfor Oslo kommune.
Det bør være muligheter for å dokumentere/registre
hvor avviket er sendt.
F 5.7
Systemet bør ha mulighet for funksjonalitet som
B
understøtter eskalering av avvik hvor behandlingsfrist
er overskredet.
Leverandørens
beskrivelse
Side 15 av 111
F 5.8
Det skal klart fremgå i avviket hvem som har innsyn i
avviket (f.eks. for HMS avvik; Verneombud).
M
Leverandørens
beskrivelse
F 5.9
Løsningen bør kunne generere forhåndsdefinerte
standardtiltak ved spesifikke avvikstyper. For
eksempel ved personskade, eiendomog branntiltak
eller feil på medisinteknisk utstyr.
B
Leverandørens
beskrivelse
F 5.10
I saksbehandlingsbildet bør avviksmottaker enkelt få B
oversikt over, samt kunne sortere og vise avvikene på
områder, tidsperioder med mer. Resultatet bør
kunne overføres til kjente filformater for videre
analyse.
Video av
funksjonalitet og
leverandørens
beskrivelse
Dokumentstyring og dokumenthåndtering
Systemet bør ha en oversiktlig og fleksibel måte å håndtere dokumenter på. Løsningen bør ha gode
søkefunksjoner og det bør være mulig å søke opp dokumenter i en forhåndsdefinert struktur.
Løsningen bør ha ulike forhåndsdefinerte dokumentmaler og være oversiktlig med hensyn til
dokumentstyring. Det bør være gode muligheter for å navigere seg rundt i systemet og være
oversiktlig for den enkelte ut i fra hvilke rettigheter brukeren er tildelt.
Tabell F6: Funksjonelle krav dokumentstyring og dokumenthåndtering som ansatt
Krav nr Krav
M/B
Dokumentasjon
F 6.1
Basert på organisasjonstilhørighet bør den ansatte
enkelt få opp aktuelle dokumenter, rutiner og
prosedyrer. Det bør være oversiktlig å se hvor
dokumentene tilhører i organisasjonsstrukturen.
B
Video av
funksjonalitet og
leverandørens
beskrivelse
F 6.2
Løsningen bør ha god søkefunksjonalitet og med
mulighet til utvidet fritekstsøk.
B
F 6.3
Det bør være enkelt å navigere i dokumentstrukturen
og det går klart frem hvor i strukturen man er.
B
Video av
funksjonalitet og
leverandørens
beskrivelse
Video av
funksjonalitet
F 6.4
Løsningen bør ha støtte tilpasning til hver bruker slik
at brukeren f eks kan lage «snarvei» til sine
favorittdokumenter.
B
F 6.5
Dokumentstyring og dokumenthåndtering bør kunne
behandles fra ulike typer enheter (PC, nettbrett,
mobil o.l).
B
Video av
funksjonalitet og
leverandørens
beskrivelse
Leverandørens
beskrivelse
Side 16 av 111
Tabell F7: Funksjonelle krav dokumentstyring og dokumenthåndtering som leder
Krav nr Krav
M/B
Dokumentasjon
F 7.1
Ledere eller andre med rettigheter bør ha mulighet
for å distribuere ut dokumenter som de mener
ansatte skal ha tilgjengelig som «snarveier»
B
Video av
funksjonalitet og
leverandørens
beskrivelse
B
Video av
funksjonalitet og
leverandørens
beskrivelse.
Distribusjonen kan gjøres til enkelt brukere, et utvalg
brukere eller basert på organisasjonsstruktur.
F 7.2
Løsningen bør ha funksjonalitet som støtter at ledere
eller andre med rettigheter kan distribuere
dokumenter som skal leses (obligatorisk leseplikt).
Det bør være mulighet å sette frist for når
dokumenter skal være lest, og for den ansatte og
kvittere at dokumentet er lest.
Leverandøren
beskriver spesielt
har ift varsling.
Distribusjonen skjer til enkelt brukere,
organisasjonsenheter eller egne definerte grupper av
brukere. Brukere bør få varsel om at det er lagt ut
dokumenter med en frist for gjennomlesing.
F 7.3
Løsningen bør ha oversikt over status på dokumenter
som er i en publiserings- og revisjonsprosess. For
eksempel på om dokumentet er til godkjenning,
revidering og lignende.
B
Video av
funksjonalitet og
leverandørens
beskrivelse
Tabell F8: Funksjonelle krav dokumentstyring og dokumenthåndtering som forfatter
Krav nr Krav
M/B
Dokumentasjon
F 8.1
Det bør være en enkel og brukervennlig måte å
opprette og editere dokumenter, prosedyrer og
rutiner. Løsningen bør være fleksibel og kunne
håndtere klipp og lim funksjonalitet fra kjente
formater uten at originalformatering endres.
B
Leverandørens
beskrivelse
F 8.2
Dokumenter bør enkelt kunne sendes til godkjenning,
sletting, eller høring.
B
Video av
funksjonalitet
Side 17 av 111
F 8.3
Løsningen bør kunne varsle automatisk når det
nærmer seg revisjon av dokumenter. Dokumentene
bør kunne revideres med eller uten endring.
B
F 8.4
Løsningen bør gi mulighet til å bruke ulike predefinert
dokumentmaler.
B
F 8.5
Det bør være integrasjon mot lover, forskrifter og
kunnskapsbaserte prosedyrer.
B
Leverandørens
beskrivelse.
Leverandøren
beskriver spesielt
har ift varsling.
Leverandørens
beskrivelse
Leverandørens
beskrivelse
Leverandørens beskriver hvilke lover, forskrifter og
kunnskapsbaserte prosedyrer (som f.eks Praktiske
Prosedyrer i Sykepleietjenesten) de har integrasjon
mot og hvordan dette er løst i løsningen.
Statistikk og rapportering
Rapporteringen i kvalitetssystemet er et styringsverktøy som bidrar til at kommunen når sine mål
gjennom og følge med på avviksrapportering innenfor HMS- og tjenesteområdene. Rapporteringen
har som mål å bidra til kontinuerlig forbedring. Oslo kommune skal selv kunne legge inn aktuelle
måleindikatorer på alle organisatoriske nivåer.
Rapporteringene bør gi et bilde på status over tid, variasjoner, måloppnåelse, benchmarking internt i
kommunen og tillegg gi mulighet for data til andre aktuelle rapporteringer eksempelvis årsrapporter.
Tabell F9: Funksjonelle krav statistikk og rapportering
Krav nr Krav
F 9.1
F 9.2
Løsningen bør ha en overordnet lett tilgjengelig side
hvor man kan se oppdatert «nå-status». Nå-statusen
vil typisk inneholde predefinert søk hvor nøkkeltall
som organisasjonen bestemmer vises i graf og i tall.
Sidens predefinert søk bør være redigerbare.
Det bør være mulig å legge inn terskelverdier på
avvikskategorier eller avvik på enkeltprosedyrer det
er ønskelig å følge over tid.
Definert leder bør få varsel når terskelverdien
overskrides.
M/B
Dokumentasjon
B
Video og
leverandørens
beskrivelse
B
Video og
leverandørens
beskrivelse.
Leverandøren
beskriver spesielt
har ift varsling.
Side 18 av 111
F 9.3
Det bør være mulig å distribuere ferdigdefinerte
statistikkspørringer i systemet til enkelt brukere,
egendefinerte distribusjonslister, eller basert på
organisasjonsstruktur.
Slike spørringer bør være mulige å gjøre også uten å
ha tilgang til detaljer vedrørende avvik.
B
Leverandørens
beskrivelse
F 9.4
Brukere med tildelt rettighet bør kunne definere/lage
egne spørringer. Systemet bør kunne gi veiledning
under utarbeidelse av spørringer.
Løsningen bør legge til rette for at lagrede spørringer
kan gjenbrukes og redigeres på en fleksibel måte.
B
Det bør være mulig å velge hvilke felter som skal
være med i utskrift/rapportering, for eksempel ved
innsynsbegjæring.
B
Video og
leverandørens
beskrivelse
Video og
leverandørens
beskrivelse
Leverandørens
beskrivelse
F 9.5
F 9.6
F 9.7
F 9.8
F 9.9
F 9.10
F 9.11
F 9.12
F 9.13
Leverandøren beskriver hvilke muligheter som finnes
i løsningen i forbindelse med innsynsbegjæringer og
sladding av informasjon.
Det bør være mulig å legge inn kommentarer i
grafene, løsningen bør også kunne støtte ulike
presentasjonsformer.
Statistikkfunksjonen bør kunne sammenligne 2
tidsserier i en og samme graf. Grafene bør kunne
presenteres i ulike diagramtyper.
Rapporter bør kunne konverteres til kjente
filformater for videre bearbeidelse og benyttelse i for
eksempel presentasjoner
Det bør være mulig å ta ut spørringer på alle data
som legges i tabeller i systemet (full drill down),
herunder:
 Avvikshåndtering
 Dokumenthåndtering
 Risiko- og sårbarhetsanalyse
 Aktivitetsplanlegging (årshjul)
Det bør være mulig å genere rapporter på
dokumenthåndteringsstatus eks. antall dokumenter
til godkjenning, hvem det ligger hos, dokumenter
aktuelle for revisjon også videre.
Ved generering av rapporter og oversikter vises en
fremdriftsindikator som informerer brukeren om
status.
Det bør være mulig å ta ut rapporter som gir status
på dokumenter med obligatorisk leseplikt, ref. krav F
7.2 i kravtabell: F7 Funksjonelle krav dokumentstyring
og dokumenthåndtering som leder
B
B
B
B
Video og
leverandørens
beskrivelse
Video og
leverandørens
beskrivelse
Leverandørens
beskrivelse
B
Leverandørens
beskrivelse
B
Leverandørens
beskrivelse
B
Leverandørens
beskrivelse
B
Leverandørens
beskrivelse
Side 19 av 111
Risiko og sårbarhetsanalyser
Risiko -og sårbarhetsanalyser skal gi støtte til ivaretakelse av krav knyttet til internkontroll innenfor
ulike tjenesteområder og skal være et viktig styringsverktøy for hele organisasjonen.
Tabell F10: Funksjonelle krav til ROS
Krav nr Krav
F 10.1
F 10.2
F 10.3
F 10.4
F 10.5
F 10.6
M/B
Dokumentasjon
Løsningen bør ha et godt skjematisk verktøy som
bygger på metodikken matrise, analyse,
handlingsplan og evaluering. Løsningen bør støtte
anerkjente standarder for ROS-analyse.
Løsningen bør gi mulighet for å dokumentere
bestilling med frist og iverksettelse av risikovurdering
som en del av risikostyringen.
Prosessansvarlig for den enkelte ROS analysen bør
kunne velge deltakere fra systemet, men også
eksterne som skal være deltakere i analysen
B
Video og
leverandørens
beskrivelse
B
Leverandørens
beskrivelse
B
Leverandørens
beskrivelse
Løsningen bør være fleksibel i forhold til
gjennomføring av ROS-analyse. For eksempel bør det
være mulig å:
 vurdere og kommentere analysen før og etter
foreslåtte tiltak
 sette akseptansegrenser for krav til tiltak
 sette obligatoriske tiltak der
akseptansegrensen er overskredet
Løsningen bør være fleksibel i forhold til å utarbeide
egendefinerte variabler og matriser.
B
Leverandørens
beskrivelse
B
Leverandørens
beskrivelse
Tiltak bør kunne gis frist, varsel og ansvarlig.
Det bør finnes mulighet for oversikt over fullførte og
ikke fullførte tiltak på enhetsnivå.
B
Leverandørens
beskrivelse.
Leverandøren
beskriver spesielt
har ift varsling.
F 10.7
F 10.8
F 10.9
Det bør være mulighet for oversikt over status på
ROS-vurderinger.
ROS-vurderinger bør kunne organiseres i
forhåndsdefinerte og egendefinerte prosessområder
f.eks. tjeneste, HMS, økonomi, informasjonssikkerhet
m. fl.
Ferdigstilte ROS-analyser bør kunne gjenbrukes i nye
analyser og/eller sammenfattes i overordnet analyse
for flere enheter
B
B
B
Leverandørens
beskrivelse
Leverandørens
beskrivelse
Leverandørens
beskrivelse
Side 20 av 111
F 10.10
F 10.11
F 10.12
Risikoer som er avdekket i tidligere ROS-analyser bør
kunne gjenbrukes i nye analyser.
ROS-analysen bør på en enkel måte kunne knyttes
som vedlegg til andre dokumenter i systemet f. eks.
til prosedyrer
Det bør være mulig å skrive ut ROS-analysen på en
utskriftsvennlig måte og omgjøres til andre filformat
for eksempel PDF.
B
B
B
Leverandørens
beskrivelse
Leverandørens
beskrivelse
Leverandørens
beskrivelse
Årshjul – aktivitetsplanlegging
Årshjul skal gi en samlet oversikt over aktiviteter som skjer i virksomheten under et kalenderår og
underlette planlegging og overholdelse av frister. Årshjul kan vises med aktiviteter for hele sektoren
eller for hver virksomhet.
Tabell F11: Funksjonelle krav til Årshjul
Krav nr Krav
M/B
F 11.1
Løsningen bør gi mulighet for å beskrive aktiviteter i
en kalenderplan på en oversiktlig måte.
B
F 11.2
Det bør være mulig å distribuere aktiviteter i årshjul
til enkeltbrukere, en liste over brukere eller brukere
basert på organisasjonsstruktur.
Det bør være mulighet for automatisk varsel ved
endring av aktiviteter.
B
Aktiviteter bør kunne opprettes enkeltvis og som
regelmessige aktiviteter. Det bør være mulig å
kommentere og kvittere aktiviteter som fullført.
Det bør fremgå av årshjulet hvem som er eier.
B
Det bør være mulig å knytte dokumenter fra
kvalitetsbiblioteket til aktiviteter.
Det bør være mulig å opprette aktiviteter med
sjekklistefunksjonalitet og kvittere ut enkeltaktivteter
i sjekklisten.
Løsningen bør kunne gi oversikt over ikke fullførte og
fullførte aktiviteter. Oversikten bør være enkel og
brukervennlig
Aktiviteter i årshjulet bør kunne synkroniseres med
Exchange.
B
F 11.3
F 11.4
F 11.5
F 11.6
F 11.7
F 11.8
B
B
Dokumentasjon
Video og
leverandørens
beskrivelse
Video og
leverandørens
beskrivelse.
Leverandøren
beskriver spesielt
har ift varsling.
Video og
leverandørens
beskrivelse
Leverandørens
beskrivelse
Leverandørens
beskrivelse
Leverandørens
beskrivelse
B
Leverandørens
beskrivelse
B
Leverandørens
beskrivelse
Side 21 av 111
Krav til gjennomføring
Oslo kommune er opptatt av et godt samarbeid med leverandøren gjennom hele kontraktsperioden.
Kravene under er rettet mot selve gjennomføring av leveransen og etablering av løsningen. Bilag 4
Leveringstidspunkt og andre frister, vil synliggjøre de ulike fasene i gjennomføringen.
Tabell GJ12: Krav til gjennomføring
Krav nr Krav
GJ 12.1
GJ 12.2
GJ 12.3
GJ 12.4
Leverandøren skal i Fase 4 oppsett, installering og
test, (ref. bilag 4) bistå med installasjon og
kundespesifikk tilpasning av løsningen.
For eksempel:
 Tilpasning av avviksskjema til Oslo kommune
 Opprette organisasjonsstruktur, dersom det
ikke lar seg gjøre å hente ut dette fra PRK
 Opprette avviksgrupperinger
Listen er ikke uttømmende.
Leverandøren må også bistå Oslo kommunes
driftspersonell med installasjon av løsningen i Oslo
kommunes miljøer (prod, test og lignede). Det skal i
denne prosessen foregå kompetanseoverføring til
Oslo kommunes driftspersonell og utarbeides
driftsdokumentasjon.
Leverandøren skal i samarbeid med Oslo kommune i
Fase 4 oppsett, installering og test, (ref. bilag 4) bidra
med:
 Testing og utarbeidelse av testplaner
med ulike migreringsaktiviteter av data fra dagens
løsninger til ny løsning. Eksempler på data som
ønskes migrert er:
 Rutiner, prosedyrer og dokumenter
 Avvik
 ROS-analyser
 Årshjul
med:
 Utarbeide importrutiner av data fra PRK inn i
nytt system, ref. krav F 3.2 og F 3.3 tabell F3:
Funksjonelle krav systemadministrasjon
 Oppsett av Single sign-on
 Exchange integrasjon (ref. krav som
fremkommer ift varsling og årshjul)
M/B
Dokumentasjon
M
Leverandøren bes
kort beskrive
hvordan de ser for
seg dette løst.
M
Leverandøren bes
kort beskrive
hvordan de ser for
seg dette løst.
M
Leverandøren bes
kort beskrive sin
kompetanse og
erfaring med
migrering fra
andre løsninger.
M
Leverandøren bes
kort beskrive
hvordan de ser for
seg dette løst.
Side 22 av 111
Nærmere beskrivelse av krav GJ 12.3
I dagens løsninger har hver virksomhet sin egen installasjon og database. Oslo kommune ønsker en
felles løsning. Det betyr at det må migreres data fra alle dagens installasjoner til den nye løsningen. I
tabellen omfang i kap. 1.2.1, er opplyst om antall virksomheter som har en løsning i dag. Hvordan og
hva som skal/kan migreres vil være en del av oppgavene i Fase 4 oppsett, installering og test (ref
bilag 4).
Nærmere beskrivelse av krav GJ 12.4
I Fase 4 oppsett, installering og test (ref. bilag 4) vil det i samarbeid med Oslo kommune bestemmes
hvilke data som skal hentes ut fra PRK og importeres inn i løsningen. Leverandørens løsninger ift
Single sign-on vil være av betydning her.
Avtalens punkt 2.1.2 Tilpasninger og installasjon mv.
Leverandøren må påregne og måtte gjøre tilpasninger dersom Oslo kommune ber om det i egne
avrop på denne avtalen.
Avtalens punkt 2.1.4 Dokumentasjon og opplæring
Oslo kommune har krav om at system- og brukerdokumentasjon skal være på norsk, utover det
gjelder avtalens punkt 2.1.4. Dette kravet fremkommer også i tabell O13: Krav til opplæring og
dokumentasjon.
Krav til dokumentasjon i forhold til opplæring fremkommer av krav i tabell O13: Krav til opplæring og
dokumentasjon under.
Opplæring
Oslo kommune ønsker tett samarbeid med leverandøren i forbindelse med utarbeidelse av
opplæringskonsept. Oslo kommuner ønsker at leverandøren skal forestå opplæring for rollene
systemadministrator og superbrukere. Superbrukerne er på et senere tidspunkt tiltenkt ansvaret for
videre opplæring i egen virksomhet.
Oslo kommune er ansvarlig for å fremskaffe undervisningslokaler og administrere påmelding.
Kompetansebehov i aktuelle roller:
Systemadministratorer skal ha god kompetanse i kvalitetssystemets totale funksjonalitet. I tillegg må
systemadministrator tilføres kompetanse som gjør det mulig å opptre som systemadministrator for
løsningen.
Superbruker skal ivareta 1. første linje support ute i virksomheten. De skal være godt kjent med
praktiske bruken av systemet. Rollen skal også fungere som opplæringsansvarlig i egen virksomhet.
Side 23 av 111
Krav til opplæring og dokumentasjon
Tabell O13: Krav til opplæring og dokumentasjon
Krav nr Krav
O 13.1
M/B
Leverandør skal tilby praktisk og tilpasset opplæring
inklusiv kursmateriell i henhold til faseplan i bilag 4,
ref. fase 7 og 8. Kursmateriellet skal være på norsk.
Dokumentasjon
M
Leverandørens
beskrivelse
Leverandøren skal sammen med prosjektet i Oslo
kommune utforme et opplæringsopplegg for
etterspurte roller.
O 13.2
Leverandørens instruktører skal i tillegg til å ha
inngående kunnskap til eget system inneha
kompetanse i kvalitetsarbeid i offentlig sektor.
M
Leverandørens
beskrivelse
O 13.3
Leverandøren skal sammen med Oslo kommune
etablere en plan for opplæringen som skal
gjennomføres ihht Fase 7 metode for forberedelse,
mottak og realisering (ref. bilag 4).
M
Leverandøren bes
kort beskrive
hvordan de ser for
seg dette løst.
Se tabell: Omfang av opplæring under
O 13.4
All dokumentasjon som følger produktet skal være på
norsk
M
Leverandørens
bekreftelse.
O 13.5
Leverandøren må tilby kurs til systemadministratorer
og superbrukere gjennom hele kontraktens levetid.
Leverandøren må også tilby kurs til overnevnte roller
ved oppgraderinger, ny funksjonalitet og lignede.
M
Leverandørens
bekreftelse.
Gruppe
Systemadministrator
Antall
EHS
Ca. 5
Tabell: Omfang av opplæring
Superbruker
Antall
150 - 250
Tidsperiode
Ihht bilag 4
Avtalens punkt 2.2.2 Undersøkelsesplikt
Oslo kommune anser leveransen å omfatte selve løsningen, migrering av data fra dagens løsninger,
import av brukere og organisasjon fra PRK og oppsett av Single sign-on, samt Exchange integrasjon.
Testing og godkjenning av leveransen vil derfor omfatte overnevnte. Bilag 5 Godkjenningsprøve, gir
nærmere beskrivelse.
Side 24 av 111
Avtalens punkt 2.7 Eksterne rettslige krav
Tabell E14: Eksterne rettslige krav
Krav nr Krav
E 14.1
Leverandøren er ansvarlig for å sikre at løsningen til
enhver tid oppdateres slik at denne er i samsvar med
generell krav i norsk lovgivning som gjelder for IKT
systemer. Oppdateringer skal gjøres slik at disse er
implementert innen aktuell lovgivnings
ikrafttredelse.
Leverandøren er tilsvarende ansvarlig for å sikre at
løsningen til enhver tid oppdateres slik at denne er i
samsvar med spesielle krav som gjelder for den
aktuelle virksomhet i Oslo kommune, dog slik at
Kunden er ansvarlig for å opplyse Leverandøren om
de aktuelle kravene.
M/B
M
Dokumentasjon
Leverandørens
bekreftelse
Som generelle krav regnes bl.a. krav som fremkommer i følgende lovgivning (listen er ikke
uttømmende):
1. [POL] (2000): Lov om behandling av personopplysninger (personopplysningsloven),
http://lovdata.no/all/hl-20000414-031.html
2. [POF] (2000): Forskrift om behandling av personopplysninger
(personopplysningsforskriften),http://www.lovdata.no/cgi-wift/ldles?doc=/sf/sf/sf-200012151265.html
3. [PJL] (2015): Lov om behandling av helseopplysninger ved ytelse av helsehjelp
(pasientjournalloven), https://lovdata.no/dokument/NL/lov/2014-06-20-42?q=pasientjournal
4. [HRL] (2015): Lov om helseregistre og behandling av helseopplysninger (helseregisterloven),
https://lovdata.no/dokument/NL/lov/2014-06-20-43?q=helsereg
5. [OMS] (2015): Lov om kommunale helse- og omsorgstjenester m.m. (helse- og
omsorgstjenesteloven), https://lovdata.no/dokument/NL/lov/2011-06-24-30?q=omsorg
6. [HPL] (1999):Lov om helsepersonell m.v. (helsepersonelloven).
https://lovdata.no/dokument/NL/lov/1999-07-02-64?q=helseperson
7. [PBRL] (2001): Lov om pasient- og brukerrettigheter (pasient- og brukerrettighetsloven).
https://lovdata.no/dokument/NL/lov/1999-07-02-63?q=pasient%20og%20bruker
8. [BVL] (1992): Lov om barneverntjenester (barnevernloven),http://lovdata.no/all/hl-19920717100.html#7-4
9. [FVL] (1967): Lov om behandlingsmåten i forvaltningssaker
(forvaltningsloven),http://lovdata.no/cgi-wift/wiftldles?doc=/app/gratis/www/docroot/all/nl19670210-000.html&emne=forvaltnings*&&
10. [EFF] (2004): Forskrift om elektronisk kommunikasjon med og i forvaltningen
(eForvaltningsforskriften), https://lovdata.no/dokument/SF/forskrift/2004-06-25-988?q=eforvalt
11. [SOS] (2016): Lov om sosiale tjenester i arbeids- og velferdsforvaltningen (sosialtjenesteloven),
https://lovdata.no/dokument/NL/lov/2009-12-18-131?q=sosial
12. [OPPLL] (1998): Lov om grunnskolen og den vidaregåande opplæringa (opplæringslova)
https://lovdata.no/dokument/NL/lov/1998-07-17-61, jf. FVL
Side 25 av 111
Norm for informasjonssikkerhet i helse- og omsorgstjenesten
Leverandøren påtar seg å etterleve krav i Norm for informasjonssikkerhet i helse- og
omsorgstjenesten (Normen - www.normen.no) og gjelder for kommunalavdelinger og virksomheter
som er tilknyttet Norsk Helsenett.
Normen bygger på en rekke norske bestemmelser om personvern og informasjonssikkerhet, bl.a.
reglene i personopplysningsloven, pasientjournalloven og helseregisterloven. Disse reglene er basert
på EUs personverndirektiv. Personverndirektivet bygger igjen på grunnleggende
menneskerettigheter.
Kravene i Normen er basert på gjeldende regler på personvern- og informasjons-sikkerhetsområdet.
Avtalens punkt 4.3 Fri programvare
Dersom deler av leveransen er basert på fri programvare, herunder tilpasning og videreutvikling av
denne, skal det opplyses om dette. Herunder skal det opplyses hvilke typer fri programvare som
benyttes.
Leverandøren skal i tilfelle beskrive sine rutiner for bruk av fri programvare, herunder:
 Opplæringsprogram som er etablert ifm. Leverandørens bruk av fri programvare
 Rutiner for å etabler lisensoversikt/lisensavtalebibliotek
 Rutiner for å sikre overholdelse av lisensvilkår for aktuell fri programvare
 Rutiner for revisjon av oppfyllelse av lisensvilkår
Leverandøren plikter fortløpende å underrette Kunden hvis denne tar i bruk nye typer fri
programvare.
Side 26 av 111
Bilag 2: Leverandørens beskrivelse av leveransen
Avtalen punkt 1.1 Avtalens omfang
Dersom det etter Leverandørens mening er åpenbare feil eller uklarheter i Kundens
kravspesifikasjon, skal Leverandøren påpeke dette her.
Leverandøren skal svare på Bilag 1 som beskrevet under:
Må krav
I må kravene er det stilt dokumentasjonskrav om beskrivelse eller leverandørens bekreftelse. Vi
ønsker svarene presentert på denne måten:
Krav X x.x
<Leverandørens egen beskrivelse av Må-kravet> eller
<Leverandørens bekreftelse>
Det skal klart fremgå og refereres til krav nummer i henhold til bilag 1.
Bør krav
I bør kravene er det stilt dokumentasjonskrav om beskrivelse, og/eller videopresentasjon. Vi ønsker
svarene presentert på denne måten:
Krav X x.x
<Leverandørens egen beskrivelse av Bør-kravet> og/eller
<Leverandørens videopresentasjon av Bør-kravet >
Det skal klart fremgå og refereres til krav nummer i henhold til bilag 1. Det skal i besvarelsen her i
bilag 2 også refereres til hvilken videoprestenasjon kravet er dokumentert i dersom det kreves video
som dokumentasjon.
Avtalens punkt 2.1.1 Utstyr og programvare
Dersom tilbudt programvare og utstyr ikke har slike funksjoner, egenskaper og kvalitet som følger av
standard produktbeskrivelse/-spesifikasjon, brukerveiledning mv. som Leverandøren lar følge med
ved salg av disse produktene, skal dette fremkomme her.
Dersom det er nødvendig å oppgradere Kundens tekniske plattform, slik den er beskrevet i bilag 3,
for at Leverandørens ytelser skal fungere som avtalt, skal dette spesifiseres her.
Side 27 av 111
Avtalens punkt 2.1.3 Forholdet til standard lisens- og
avtalevilkår
I den utstrekning standardprogramvare som er omfattet av leveransen må leveres under standard
lisensbetingelser, skal dette fremkomme her. Kopi av lisensbetingelsene skal være vedlagt som bilag
10.
I den utstrekning det er avvik mellom lisensbetingelsenes bestemmelser om disposisjonsrett og
denne avtalens bestemmelser om disposisjonsrett, skal dette fremkomme her.
Avtalens punkt 2.1.6 Garantiperiode og garantiytelser
Dersom Leverandøren stiller krav til vedlikehold som må være utført for at garantien for utstyr skal
gjelde, skal dette spesifiseres her.
Avtalens punkt 2.7 Eksterne rettslige krav
Leverandøren skal beskrive hvordan Leverandøren ivaretar eksterne rettslige krav gjennom sin
leveranse her.
Dersom fri programvare skal benyttes i forbindelse med leveransen, skal Leverandøren utarbeide en
oversikt over den aktuelle fri programvare. Oversikten inntas her. Kopi av lisensbetingelsene som
gjelder for den aktuelle frie programvare inntas i bilag 10.
I den utstrekning Leverandøren er kjent med at fri programvare som er krevet brukt av Kunden som
en del av leveransen er uegnet til å oppfylle Kundens krav eller krenker eller av noen hevdes å krenke
tredjeparts opphavsrett, skal Leverandøren påpeke dette her.
Side 28 av 111
Bilag 3: Kundens tekniske plattform
Innhold
1.
Innledning .....................................................................................................................32
1.1
Formålet med bilaget...............................................................................................32
2.
Arkitekturprinsipper for Oslo kommunes felles infrastruktur ...........................................32
2.1
Oversikt over Arkitekturprinsippene........................................................................33
3.
4.
Felles funksjonalitet i Oslo kommunes felles IKT infrastruktur .........................................34
Integrasjonsløsninger i Oslo kommunes felles IKT infrastruktur .......................................34
4.1.1
Integrasjoner mot eksterne fellesregistre, bruk av ITAS ..................................36
5.
4.1.2
Design av integrasjonene ................................................................................36
4.1.3
Kommunikasjonsprotokoller ............................................................................37
4.1.4
Komponenter på ITAS-plattformen ..................................................................37
4.1.5
Sikkerhet .........................................................................................................38
4.1.6
Ansvar for løsningen .......................................................................................38
4.1.7
Ansvar for grensesnitt .....................................................................................38
4.1.8
ITAS sitt hovedansvar .....................................................................................38
4.1.9
Utenfor ITAS sitt ansvar ..................................................................................39
Gjeldende felles IKT infrastruktur i Oslo kommune ..........................................................39
5.1
Mål for gjeldende infrastruktur i Oslo kommune .......................................................39
5.2
Rammeverk for livssyklus for produkter i felles infrastruktur og klienter ..................39
5.2.1
Driftstjenester ..................................................................................................40
5.3
Overordnet design...................................................................................................40
5.4
Datasenter (Facilities) .............................................................................................41
5.5
Lagringsløsning .......................................................................................................41
5.5.1
Sikkerhetskopiering .........................................................................................41
5.6
Datasenternettverk .................................................................................................41
5.7
Kontroll og overvåking ............................................................................................42
5.7.1
Avgrensning .....................................................................................................42
5.8
Sikkerhet ................................................................................................................42
5.9
Virtuell infrastruktur ...............................................................................................44
5.9.1
vSpehere Datacenter Design ..........................................................................44
5.9.2
VDI Overordnet design ....................................................................................45
5.9.3
Terminalservere ..............................................................................................46
5.10
Oracle databasehotell ..............................................................................................47
5.11
MSQL databasehotell ...............................................................................................48
5.12
Sentrale fysiske basistjenester .................................................................................49
5.12.1
Serverløsning ..................................................................................................49
5.12.2
DFS - Filserverdesign......................................................................................49
5.13
Applikasjonshotell ..................................................................................................49
Side 29 av 111
5.14
Sentrale basistjenester ............................................................................................50
5.14.1
AD – Active Directory ......................................................................................51
5.14.2
DNS – Domain Name System .........................................................................52
5.14.3
PRK – Person- og ressurskatalogen ...............................................................52
5.14.4
PKI – Public Key Infrastructure ........................................................................53
5.14.5
DHCP – Dynamic Host Configuration Protocol ................................................54
Fig. 5.18 Plassering av DHCP tjeneste ..........................................................................55
5.14.6
NTP – Network Time Protocol .........................................................................55
5.14.7
SMTP – Simple Mail Transfer Protocol ............................................................55
5.14.8
Anti-spam ........................................................................................................55
5.14.9
Utskriftstjenester .............................................................................................55
5.14.10
5.15
MS SQL- og Oracle-databasehotell ............................................................................56
5.16
Klientkonsept..........................................................................................................56
5.17
Leverandøraksess i OKMAN .....................................................................................57
5.17.1
Tjenesteleveranser på leide linjer / faste forbindelser ......................................58
5.17.2
Ethernetforbindelser ........................................................................................58
5.17.3
Tjenesteleveranser over Internett ....................................................................58
5.17.4
Tjenester ute på internett ................................................................................58
5.17.5
Site2site IPSec VPN-tunell ..............................................................................58
5.17.6
Sonemodellen for datasenter ..........................................................................58
5.18
6.
Programvarepakking og distribusjon ............................................................56
Sikkerhetssoner- og systemtekniske sikkerhetsløsninger ..........................................59
5.18.1
Sikkerhetsmodell .............................................................................................59
5.18.2
Autentisering ...................................................................................................62
5.19
Nettverks- og kommunikasjonsløsninger .................................................................62
5.20
Klienter i Oslo kommune .........................................................................................62
Standardiserte driftstjenester levert fra intern leverandør i Oslo kommune ......................63
6.1
Arbeidsflatetjenester ...............................................................................................63
6.1.1
Brukertilgang ...................................................................................................63
6.1.2
Drift av klienter (arbeidsstasjon) ......................................................................63
6.1.3
Drift av skrivere og tilleggsutstyr ......................................................................63
6.1.4
Virtuell brukerflate – VDI..................................................................................63
6.2
Systemtjenester ......................................................................................................64
6.2.1
Leverandørtilgang ............................................................................................64
6.2.2
Systemdrift ......................................................................................................64
6.2.3
Systemdrift ......................................................................................................64
6.3
Nettverkstjenester ..................................................................................................64
6.3.1
Drift av lokalnett (LAN) ....................................................................................64
6.3.2
Trådløst nettverk (WLAN) ................................................................................65
Side 30 av 111
6.3.3
Tilgang til Oslo kommunes konsernnett (OK-MAN) ............................................65
Figuroversikt..................................................................................................................65
Tabelloversikt ................................................................................................................66
Side 31 av 111
1. Innledning
1.1 Formålet med bilaget
Formålet med bilaget er å gi Leverandøren en oversikt over hvordan IKT-infrastrukturen i Oslo
kommune ser ut i dag, og hvilke komponenter i denne infrastrukturen en ekstern tjenesteleverandør
kan eller må benytte seg av.
Felles tjenester og systemkomponenter i Oslo kommune må gjenbrukes der det er formålstjenlig, på
tvers av IKT-system og virksomheter.
2. Arkitekturprinsipper for Oslo kommunes
felles infrastruktur
Oslo kommune har utviklet IKT-arkitektur til bruk som styringsverktøy for utvikling og forvaltning av
IKT-porteføljen. IKT-arkitekturen handler på et overordnet nivå om forholdet mellom
arbeidsprosessene og informasjon (data) som inngår i disse, hvilke funksjoner IKT-systemene
benytter til å håndtere informasjonen, og hvilken underliggende infrastruktur (maskiner og nettverk)
systemene benytter, ref. figur 2.1.
Prinsippene følges så langt det er hensiktsmessig innen
rammen av prosjektet.
Visjon for IKT-arkitekturen:
●
Fremtidsrettede tjenester og løsninger
Mål for IKT-arkitekturen:
●
å bidra til effektiv administrasjon, sterk
brukerorientering og gode elektroniske tjenester.
●
å legge grunnlag for god IKT-støtte til
virksomhetsprosesser, tjenesteproduksjon og elektronisk samhandling med innbyggerne,
næringsliv, andre offentlige samarbeidspartnere og kommunens ansatte.
●
å legge grunnlag for rask og kostnadseffektiv utvikling, innføring, endringer og
oppgradering av IKT-løsninger gjennom en helhetlig og fleksibel IKT-portefølje.
●
å sikre en styrbar og enhetlig IKT-portefølje gjennom tydelige målbilder, prinsipper og
standarder.
●
å bidra til tilgjengelige og stabile IKT-tjenester.
●
å legge til rette for å ivareta god informasjonssikkerhet i Oslo kommune.
Fig. 2.1 IKT-arkitektur
Side 32 av 111
2.1 Oversikt over Arkitekturprinsippene
Det er utarbeidet 10 arkitekturprinsipper, ref. tabell 2.1. Prinsippene gjelder både ved anskaffelser,
endringer, løpende forvaltning og drift av IKT-systemer. Kommunale virksomheter legger prinsippene
til grunn ved både nyutvikling og/eller endringer i sine IKT-løsninger. Ytterligere detaljer av hvert
enkelt prinsipp er nærmere beskrevet i Vedlegg 1 Arkitekturprinsipper i Oslo kommune.
#
Arkitekturprinsippene for IKT i Oslo kommune
Grønn skrift: DIFI-prinsippene. Blå Skrift: Oslo kommunes tillegg
0.
Arkitekturvurdering
Arkitekturvurdering skal utføres for alle IKT-leveranser
1.
Tjenesteorientering
IKT-systemer skal bygges opp som en samling avgrensede delsystemer som legger til rette for mest
mulig gjenbruk.
2.
Interoperabilitet
IKT-systemer må kunne utveksle og dele data og informasjon med andre systemer gjennom
standardiserte grensesnitt
3.
Tilgjengelighet
Elektroniske brukertjenester skal være universelt utformet, og brukerne skal kunne benytte dem uten
hensyn til tid, sted og kanal.
4.
Sikkerhet
Informasjon og tjenester skal tilfredsstille krav til konfidensialitet, integritet og tilgjengelighet.
5.
Åpenhet
Offentlige IKT-systemer skal være basert på åpne eller godkjente standarder. Systemene skal ikke
sette spesifikke krav til teknologi hos brukerne
6.
Fleksibilitet
IKT-systemene skal være forberedt på endringer i bruk, innhold, organisering, eierskap og
infrastruktur.
7.
Skalerbarhet
IKT-løsningene skal være forberedte på endringer i antall brukere, datamengde og levetid for
tjenesten.
8.
Helhetlig oversikt
Oslo kommune skal alltid ha en oppdatert og helhetlig systemoversikt.
9.
Oppetid, åpningstid og stabilitet
Oslo kommunes systemer og infrastruktur skal oppfylle definerte krav til oppetid, åpningstid og
stabilitet.
Side 33 av 111
10.
Levetid
Før implementering av systemer og infrastruktur skal det gjøres en teknologisk og kostnadsmessig
levetidsvurdering
Tab. 2.1. Arkitekturprinsipper
3. Felles funksjonalitet i Oslo kommunes felles
IKT infrastruktur
Oslo kommune har som visjon å realisere digitalt førstevalg for tjenester til innbyggere og næringsliv.
Ref. Difi rapport 2011:3 Digitalt førstevalg, ISSN 1890-6583.
Byrådet ønsker å tilby flere elektroniske tjenester til innbyggere og næringsliv på en samlet og
brukervennlig måte gjennom digitale kanaler. Økt selvbetjening for kommunens brukere og
helelektroniske prosesser i saksbehandling og tjenesteyting er sentralt. Økt tilgjengeliggjøring av
kommunens åpne data og grensesnitt vil gi grunnlag for innovasjon i markedet og skape et økt og
bredt tjenestetilbud.
4. Integrasjonsløsninger i Oslo kommunes
felles IKT infrastruktur
Interaktive Tjenester ApplikasjonsServere, heretter kalt ITAS, er Oslo kommunes sentrale
integrasjonsplattform med tjenestebuss (også kalt ESB) og applikasjonsserverplattform for
interaktive tjenester.
ITAS tar seg også av konvertering mellom ulike dataformater. Meldinger som sendes inn til ITAS,
sendes av og til flere mottakere. Konverteringen til mottakernes formater skjer da i ITAS, slik at
systemene selv slipper å forholde seg til de ulike formatene.
Integrasjonsløsningen kan benyttes for alle integrasjoner som benytter eksterne og interne felles
komponenter. Som hovedregel vil all integrasjon mot interne og eksterne felleskomponenter benytte
sentral integrasjonsløsning.
Som skissen nedenfor illustrerer, er det 3 forskjellige måter å integrere med ITAS på.
Side 34 av 111
Fig. 4.1 ITAS integrasjon
ITAS tilgjengeliggjør grensesnitt for fagsystem og eksterne systemer slik at disse kan hente/sende
informasjon fra/til ITAS, som igjen distribuerer dette til aktuelle systemer. Her vil det være det
eksterne systemet/fagsystemet som er initiativtager til kommunikasjonen.
Oslo kommunes integrasjonsplattform er basert på åpne standarder og tjenestebuss. Det eksisterer
en rekke allerede utviklede integrasjoner mot støttesystemer og registre som kan og bør gjenbrukes
der dette er hensiktsmessig. Informasjonstjenester i fagsystemet/api'er som bør være JSON-baserte
REST-tjenester. SOAP/ Web Services er et alternativ. Noen eksempler på allerede utviklede
integrasjoner er:
● ID-Porten (ekstern autentisering)
● Altinn integrasjon (ekstern autentisering)
● LDAP og AD integrasjon (intern autentisering)
● Agresso (økonomi)
● NETS (betaling på nett)
● Mail / SMS
● Brønnøysundregistrene
Tjenester legges til, utvides og forbedres fortløpende.
Side 35 av 111
Sammen med integrasjonsrammeverket og kjøremiljø for Java og .NET er dette Oslo kommunes
plattform for interaktive tjenester.
4.1.1 Integrasjoner mot eksterne fellesregistre, bruk av ITAS
Eksempler på eksterne fellesregistre:
-
Enhetsregistret
Sentral matrikkel
Det sentrale folkeregister
I henhold til Oslo kommunes IKT-arkitekturprinsipper, realisering av gevinst i forbindelse med
konsernets bruk av fellesfunksjonalitet, leverandøruavhengighet, fleksibilitet og implementering av
tjenesteorientert arkitektur skal all integrasjon mot eksterne fellesregistre gå via ITAS. Fag/arkivsystemer som benytter standard grensesnitt mot eksterne fellesregistre, og som allerede har
ferdigutviklede grensesnitt mot de eksterne fellesregistrene, skal også gå via ITAS.
ITAS tilbyr allerede en del identiske grensesnitt (proxy) mot de eksterne fellesregistrene. Det skal ikke
være nødvendig å tilpasse fagsystemene i forbindelse med kobling mot ITAS istedenfor direkte mot
de eksterne fellesregistrene. Fagsystemene vil kun rette pekeren mot ITAS istedenfor eksternt. Der
hvor det ikke allerede fins en identisk tjeneste (proxy) på ITAS må det utvikles av kunden.
I forbindelse med løsninger der meldinger innholdskrypteres vil fagsystemene få tildelt nøkler av ITAS
forvaltning. Videre nøkkelhåndtering mot eksternt fellessystem løses av ITAS felles for alle løsninger
som bruker de spesifikke eksterne fellesregistre.
Det skal meldes avvik, inkludert begrunnelse, til kunde hvis prinsippet om bruk av ITAS for
integrasjon mot eksterne fellesregistret ikke følges.
4.1.2 Design av integrasjonene
Ved etablering av en løsning vil Oslo kommune involveres og i samarbeid med prosjekt og leverandør
detaljere en spesifikasjon for grensesnitt som skal benyttes. Det konkrete designet vil være spesifikt
for hver enkelt løsning. Som integrasjonsplattform ligger det i ITAS sin natur å kunne tilpasses et
antall protokoller, teknologier og bruksmønstre. Det er derfor ikke hensiktsmessig å skulle liste opp
alternative måter å benytte ITAS på.
Fig. 4.2 Synkrone kall
Side 36 av 111
Et kall på et grensesnitt på ITAS fra andre systemer skal ikke kunne resultere i et nytt kall på et
eksternt system uten at det førstnevnte kallet termineres. I tilfeller hvor denne type funksjonalitet er
ønsket, kan dette f.eks. endres til følgende mønster:
Ved små datamengder og begrenset krav til øyeblikksbilde kan ITAS inneholde en cache av data, som
kan returneres i det første kallet.
Første kall kan starte en jobb på ITAS og deretter returnere. Jobben kontakter de(t) ekstern(e)
system(et) som er definert, og resultatet leveres til det kallende systemet (evt. et annet) via et eget
grensesnitt.
Evt. kan andre mønstre også tenkes.
Kommunikasjon med systemer på Sikker Sone kan ikke initieres fra ITAS
I tilfeller hvor denne type funksjonalitet er ønsket, kan dette f.eks. endres til følgende mønster:

Informasjonen som skulle vært formidlet til systemet på sikker sone, mellomlagres på ITAS.
Systemet på sikker sone forespør med jevne mellomrom etter ny informasjon, og henter den
aktuelle informasjonen ved neste forespørsel.
Dersom det er flere integrasjoner mellom sikker sone og ITAS som har behov for denne type
funksjonalitet, kan forespørselmekanismen, som beskrevet ovenfor, sentraliseres og gjøres felles.
Informasjonselementene vil i tilfelle også inneholde informasjon om hvor de skal leveres slik at
felleskomponenten kan rute disse riktig. Felles tjenester i Oslo kommune sikres i henhold til
sikkerhetsnivå og vha. demilitariserte soner.
4.1.3 Kommunikasjonsprotokoller
Nyutviklete grensesnitt følger åpne standarder ift. kommunikasjonsprotokoller. I de tilfeller hvor
eksisterende grensesnitt benyttes/justeres, kan imidlertid dette fravikes.
For grensesnitt tilgjengelig fra andre systemer er det et ytterligere krav om bruk av HTTP/HTTPS som
protokoll på applikasjonslaget, men åpent for forskjellige kommunikasjonsprotokoller utenpå dette.
Eksempelvis Web Services, REST. Plattformen støtter også andre mekanismer for kommunikasjon
med løsninger slik som filoverføring og databasekoblinger, men man anbefaler sterkt at moderne
elektronisk samhandlingsformer benyttes for å sikre god forvaltning og stabilitet.
4.1.4 Komponenter på ITAS-plattformen
Som en del av en integrasjonsløsning kan det også være hensiktsmessig og implementere visse
komponenter på ITAS-plattformen. Dette kan for eksempel være forretningsregler som understøtter
routing av informasjon til korrekt system og/eller transformasjoner mellom forskjellige dataformater.
Det kan også være større applikasjoner som inneholder brukergrensesnitt.
Det settes følgende krav til kildekode for slike komponenter:
● Komponenter som driftes på ITAS-plattformen forvaltes av Oslo kommune.
● Komponenter på ITAS kjører på enten java-plattform eller .NET-plattform.
● Komponenter på ITAS benytter, eller kan oppgraderes til å benytte, rammeverk som er
tilgjengelige på den versjon av kjøreplattformen som ITAS benytter.
Side 37 av 111
4.1.5 Sikkerhet
Sikkerheten på ITAS-plattformen er ivaretatt på flere nivåer, og kan kobles inn etter behov i
løsningen. En ikke uttømmende liste over sikkerhetsmekanismer er:
● Autentisering mot ID-Porten og Oslo kommunes AD og LDAP
● Autorisering mot Oslo kommunes Person- og ressurskatalog
● Kryptering av trafikk på innholds- og/eller transportnivå
● Transaksjonssikker leveranse av meldinger
● Demilitariserte soner
● mm.
4.1.6 Ansvar for løsningen
Fig. 4.3 ITAS som integrasjonsplattform
En løsning med ITAS som integrasjonsplattform vil inneholde et antall komponenter som noe
forenklet kan fremstilles som vist i figur 4.3 ovenfor. Det er et system (eller en bruker) som kaller
ITAS via et nettverk, og det er et (eller flere) systemer som blir kalt av ITAS via et nettverk.
4.1.7 Ansvar for grensesnitt
Grensesnittene som blir benyttet for å kommunisere mellom systemene opprettes på systemet som
tilbyr tjenesten, med andre ord systemet som mottar en henvendelse. Ansvaret for et grensesnitt
ligger derfor på dette systemet.
4.1.8 ITAS sitt hovedansvar
Komponenter og grensesnitt som driftes på ITAS-plattformen (ref. punkt om grensesnitt ovenfor) tar
Oslo kommune et utviklings- og oppfølgingsansvar for. Dette ansvaret innebærer:
● Etablering av grensesnitt og komponenter
● Etablering av transportvei fra internett til grensesnittene
● Overvåkning og oppfølging av oppetid på grensesnittene og komponentene
● Informasjon om evt. nedetid på enkelte tjenester
Side 38 av 111
4.1.9 Utenfor ITAS sitt ansvar
ITAS tar ikke totalansvar for deler som ligger utenfor ITAS-plattformen. Konkret er dette definert
som:
● Alt som skjer før en henvendelse når ITAS sin interne proxy for trafikk som initieres utenfor
ITAS.
● Alt som skjer etter utgående brannmur for trafikk som initieres fra ITAS.
Selv om ITAS ikke tar ansvar for disse delene vil det bli gitt hjelp til følgende:
● Bidrag til utvikling og test av tjenester på andre systemer
● Informasjon om nedetid på systemer som kalles fra ITAS
● Forvaltning og videreutvikling av tjenester på ITAS som er avhengige av tjenester på eksterne
systemer
5. Gjeldende felles IKT infrastruktur i Oslo
kommune
5.1
Mål for gjeldende infrastruktur i Oslo kommune
Utviklings- og kompetanseetaten leverer funksjonelle, sikre, stabile og kostnadseffektive IKT
driftstjenester til Oslo kommunes virksomheter.
Det er helt vesentlig at sikkerheten i infrastrukturen er tilfredsstillende. For å ivareta dette er blant
annet målet at alle systemer som driftes i gjeldende felles infrastruktur skal være på supporterte
versjoner og driftes av en plattform som består av supporterte produkter med produktversjoner
godkjent for bruk i Oslo kommune.
5.2 Rammeverk for livssyklus for produkter i felles infrastruktur og
klienter
For å ivareta krav om sikkerhet, kvalitet og framtidsrettethet er alle tekniske komponenter i sentral
infrastruktur på standardiserte og supporterte versjoner. Det åpnes for å introdusere nye godkjente
produkter i sentral infrastruktur basert på teknologiutvikling og behov.
Godkjente produkter, GPL, i Oslo kommune er listet opp i egne lister, se Bilag 3, vedlegg 2 Godkjente
produkter. Disse inneholder produkter, applikasjoner og objekter som er frigitt for bruk i kommunen,
dvs. at de er testet og integrert i løsningen med beskrevet versjon. Disse vil løpende oppgraderes for
å erstatte utgåtte produkter og/eller versjoner.
Systemer som driftes på standardisert applikasjonsdriftsplattform flyttes til tilpasset drift om
systemet ikke er tilknyttet avtale med leverandør om support, eller om systemet ikke kan driftes på
de godkjente og standardiserte komponentene på applikasjonsdriftsplattformen.
Side 39 av 111
5.2.1 Driftstjenester
Løpende vedlikehold av sentral infrastruktur bidrar til kostnadseffektive driftstjenester.
5.3
Overordnet design
Overordnet design for IKT-infrastruktur er bygget for å ivareta Oslo kommunes totale og helhetlige
behov for en modernisert plattform. Designet understøtter en strategisk og helhetlig styring innenfor
IKT-området. En modernisert IKT-infrastruktur er et strategisk virkemiddel for effektiv gjennomføring
av organisasjonsendringer, og tilrettelegger for fleksibel videreutvikling som støtter kommunens
endringsbehov. Designet benytter sentralisering og standardisering som virkemidler for å øke
brukertilfredsheten ved blant annet å redusere nedetid og levere tilfredsstillende svartider gjennom
stabile IKT-systemer.
Fig. 5.1 Viser det logiske overordnede designet for IKT-infrastruktur. Det overordnede designet baseres på to fysiske
datasentra som har likeverdig funksjonalitet.
Designet understøtter gevinstmålene:
-
Modernisert IKT-Infrastruktur
Økt brukertilfredshet
Forbedret responstid
Mer stabil infrastruktur
Økt tilgjengelighet
Etablere løsninger som legger til rette for akseptabelt risikonivå
Tilrettelegge for nye elektroniske tjenester for brukerne
Side 40 av 111
5.4
Datasenter (Facilities)
Oslo kommune har to separate datasentre, med redundante tilføringsveier for strøm og
kommunikasjon.
Fig. 5.2 Skisse over datasenter-løsning
5.5
Lagringsløsning
Oslo kommune har en lagringsløsning som er i stand til å håndtere det funksjonelle bruksmønsteret
og krav om lagringskapasitet for virksomhetene med skalerbare løsninger.
Sluttbruker blir kun indirekte berørt av funksjonaliteten. IKT-ansvarlige har en lagringsløsning som er
skalerbar. Systemeier blir kun indirekte berørt av funksjonaliteten.
Lagringsløsningen består av en redundant SAN løsning, med to likeverdige lokasjoner, hvor data
speiles mellom disse.
5.5.1 Sikkerhetskopiering
Det benyttes en distribuert modell med lagringsnoder for å gi en god ytelse med tanke på kapasitet
til å flytte data fra backupklienter til backupdestinasjonen. Sikkerhetskopiering og tilbakekopiering
kan utføres uavhengig fra Oslo kommunes to datasentre.
Løsningen benytter dedupliseringsteknologi (DataDomain) og dedikert nettverk for å transportere
backupdata fra backupserver / lagringsnoder til data, server, destinasjonen.
5.6
Datasenternettverk
Datasenterdesignet skiller mellom konsernnettets kjerne og datasenternettverket.
Side 41 av 111
Fig. 5.4 Datasenternettverk
Datasenterets kjerne består av en logisk nettverksnode fordelt over to datasenterlokasjoner.
Kjernenodene har følgende overordnede oppgaver:
● Kommunikasjonsnav mellom datasentrene.
● Sammenknytning av samtlige distribusjonsnoder i datasentrene.
● Tilknytning av tjenesteproduksjon til øvrig nettverk.
5.7
Kontroll og overvåking
Driftsleverandør overvåker og rapporterer på de komponentene som Oslo kommune har avtalt
overvåkning på. Dette benyttes også for å følge opp SLA.
Driftsleverandør har verktøy til å overvåke og feilsøke. Systemeier har tilgjengelig måleparametere i
SLA og leverandørs oppfyllelse av disse.
Overvåkning av sentralt miljø og integrasjon leveres som en tjeneste av driftsleverandør.
Overvåkning av nettverksmiljø leveres som en tjeneste av driftsleverandør for nettverk.
5.7.1 Avgrensning
Overvåkning gjøres for all IKT infrastruktur for basisdrift. Applikasjonsspesifikk overvåkning defineres
pr. prosjekt ved innrulling.
5.8
Sikkerhet
Sikkerhetsmodellen har segmentering på tjenestenivå, slik at de forskjellige tjenestene
(applikasjonene) som leveres fra den sentrale infrastrukturen blir separert fra hverandre. Dette for å
Side 42 av 111
kunne lage en fleksibel modell som tar hensyn til gjeldende lover og forskrifter, samt dagens
trusselbilde. Modellen understøtter de sikkerhetskrav som Oslo kommunes virksomheter har.
Tjenester i sikre og interne systemer nås på sikker måte via terminalserver/VDI over SSL/TLS eller
IPSecter i sikre og interne systemer nås på sikker måte via terminalserver/VDI over SSL/TLS eller
IPSec.
For å beskytte de publikumsnære tjenestene benyttes applikasjonsbrannmurer i laget mot Internett.
For tjenester som er sensitive og der man ønsker ekstra skjerming av innholdet, vil Sentrale og
nettverksmessige funksjoner styre tilgangen til systemene og bidra til å beskytte sensitiv informasjon.
Sikkerhetsmodellen åpner for en rekke sikkerhetsmekanismer som er med på å beskytte informasjon
i Oslofelles, samtidig som den er enkel og fleksibel for den enkelte bruker.
For å møte trusselbildet, samt å beskytte informasjonen som behandles på klientene, benyttes
følgende mekanismer:
Antiskadevare
Beskyttelse mot skadevare inngår som en del av basis programvare for alle klienter og servere.
Løsningen støtter automatiske oppdateringer av virusdefinisjoner slik at de til enhver tid er
oppdatert.
Innholdsfiltrering
Primær oppgave er å stanse skadelig programvare som distribueres via kjente infiserte/ondsinnede
websider
Kryptering på klienter
Bærbare klienter er krypterte. Krypteringsløsningen har et sentralt grensesnitt for brukerstøtte og
administrasjon.
Sikker utskrift
Utskrift kommer først ut på skriver når bestiller har identifisert seg på skriveren
Mediekontroll
Klientene leveres med mediekontroll, som sørger for at Oslo kommune har kontroll på type medier
som kobles til maskinen. En sentral management løsning sørger for at disse enhetene kan
administreres på gruppe og brukernivå.
Oppdateringer
Klientene er til enhver tid oppdaterte med sikkerhetsoppdateringer. Det er etablert løsninger for
sentralisert administrasjon og automatiske oppdateringer for klienter.
Side 43 av 111
5.9
Virtuell infrastruktur
5.9.1 vSpehere Datacenter Design
Designet består av to separate lokasjoner A og B. Lokasjon A vil være hovedlokasjon og lokasjon B vil
også bli brukt til produksjon. I VMware-sammenheng vil disse områdene fremstå som ett Datacenter
for å legge til rette for vedlikehold uten å måtte ta ned viktige VM.
I VMware vSphere er det høyeste nivået logisk grense som benyttes til å avgrense separate fysiske
lokasjoner eller vSphere infrastrukturer med helt uavhengige formål.
Innenfor vSphere datasentre, er ESX / ESXi vertene vanligvis organisert i klynger. Klynger grupperer
lignende verter i en logisk enhet av virtuelle ressurser som muliggjør slike teknologier som VMware
VMotion, High Availability (HA), og VMware Fault Tolerance (FT). Alle klynger i dette designet vil bli
strukket mellom lokasjon A og lokasjon B.
Side 44 av 111
Fig. 5.5 Overordnet konseptuelt design på virtuell infrastruktur
5.9.2 VDI Overordnet design
Virtuell Desktop Infrastruktur (VDI) er basert på at det kjøres en virtuell PC på sentrale servere og
skjermbildet presenteres for brukeren. Datakraft til VDI-miljøet leveres primært av servervirtualiseringsplattformen, men i enkelte tilfeller også fra klienter. Et felles VDI miljø vil gi tilgang til
Side 45 av 111
interne og sikre tjeneste-soner. Lastbalansering benyttes for å styre brukersesjoner og for å få jevn
belastning på tilgjengelige ressurser. Lastbalanseringen vil samtidig kunne gi instruks til
underliggende klient- og server-virtualiseringsplattform om endret behov for datakraft for VDImiljøet.
VDI miljøet er skalerbart.
Med et slikt behov har man valgt Citrix XenDesktop som VDI løsning. XenDesktop er Citrix sin
entrepriseløsning for sentralisering av arbeidsflater.
Man oppnår en sømløs migrering fra XenApp til XenDesktop med forutsigbare kostnader, og hvor
man også har muligheten til å migrere tilbake ved behov.
For å løse utfordringene med flere formater av klientenheter som for eksempel nettbrett og
smarttelefoner, vil man virtualisere brukerprofilen slik at profilen følger brukere og ikke klienten.
Dette betyr at brukere som beveger seg fra klienttype til klientype f. eks. fra en terminalserver sesjon
til en VDI sesjon får med seg hele brukerprofilen.
5.9.3 Terminalservere
Datakraft til terminalservermiljøet leveres av server-virtualiseringsplattformen. Det er to
terminalservermiljøer som er skilt med bruk av nettverksfunksjonalitet. Dette gjør at datakraft kan
allokeres mellom terminalservermiljøene for interne og sikre tjenestesoner. Lastbalanseringen
benyttes for å styre brukere til riktig terminalservermiljø og for å få en jevn belastning på
tilgjengelige ressurser. Lastbalanseringen vil samtidig kunne gi instruks til underliggende servervirtualiseringsplattform om endret behov for datakraft for terminalservermiljøet.
Fig. 5.6 Terminalservermiljø
Side 46 av 111
Applikasjonsstreaming benyttes for å håndtere ulike versjoner av applikasjoner i samme
terminalservermiljø. Terminalservermiljøet er basert på ledende praksis fra sammenlignbare
installasjoner. Miljøet er skalerbart slik at det alltid er ressurser tilgjengelig for miljøet/brukere.
Miljøet er virtualisert og basert på 64bits teknologi.
For å kunne levere applikasjoner som har spesielle avhengigheter tilbyr terminalservermiljøet
applikasjonsstreaming (også kalt applikasjons-virtualisering). Løsningen som benyttes for å realisere
denne funksjonaliteten er Microsoft App-V. Dette muliggjør bruk av ulike versjoner av samme
applikasjon i samme terminalservermiljø. Man installerer ikke programvaren i operativsystemet, men
man lager en fil for å kjøre applikasjonen på ett eller flere steder utenfor den installerte masteren.
Dette gjør at det ikke er behov for lokal konfigurasjon, og slike applikasjoner er mye enklere å
vedlikeholde og distribuere. Applikasjonene kjører isolert, og man unngår konflikt med andre
programmer. Det betyr også at man kan kjøre flere versjoner av samme applikasjon parallelt, f.eks.
kan Office 2003 og Office 2007 kjøres samtidig. Programmene kjøres med vanlige bruker-rettigheter,
og man unngår problemer med å måtte gi tilleggs-privileger til brukere for installasjon av
applikasjoner.
Dette muligjør at alle applikasjoner kan tilgjengeliggjøres for brukerne. Tilgangsbegrensning i forhold
til lisenser, grupper osv. kan bestemmes i Active Directory og pakkes sammen med den eksekverbare
filen. Tilganger kan også tidsbegrenses, eller for eksempel begrenses til IP-adresser.
Komponenter for applikasjonsstreaming/virtualisering er også etablert på VDI plattformen og på
tykke klienter – de virtualiserte applikasjonene gjøres tilgjengelig på alle plattformene fra samme
verktøy.
Applikasjonsstreaming gir følgende fordeler:
●
●
●
●
●
●
●
krever mindre ressurser
sparer tid til test og vedlikehold
kostnadsbesparende ved at eneste kostnad er lisenser for programvare
push-out mulighet
ingen erstatning for applikasjons-administrasjon, men vedlikehold av bare én instans
fjerner all avhengighet mellom OS og applikasjon, all info bæres i programfilen
forenkler installasjon og distribusjon
5.10 Oracle databasehotell
Oslo kommune har etablert et Oracle databasehotell basert på dedikert infrastruktur.
Databasehotellet ivaretar krav til katastrofeberedskap. Dette er løst ved at hotellet er etablert med
en primær og en sekundær lokasjon. For å kunne feile over til sekundær lokasjon benyttes Oracle
DataGuard. Databasehotellet er etablert i 4 soner. I intern sone og sikker sone er det egne servere
for test-, kurs- og utviklingsdatabaser. I intern og ekstern DMZ benyttes sekundær lokasjon også til å
kjøre test-, kurs- og utviklingsdatabaser.
Hotellet er skalerbart slik at man kan endre kapasiteten ved behov. Til dette er det valgt å bruke
Oracle Clusterware. Dette muliggjør flytting av databaser mellom servere i samme cluster med et
minimum av nedetid. En database kan bare være oppe på en node i motsetning til Oracle RAC hvor
lasten fordeles over alle nodene i clusteret.
Databasehotellet er delt opp i 4 soner:
Side 47 av 111

Intern sone (IS)
Her kjøres databaser som har normalt sikkerhetsnivå.

Sikker sone (SS)
Her kjøres databaser som har svært høye sikkerhetskrav. Typisk vil det være
databaser som inneholder sensitive personopplysninger.

Intern DMZ (IZ)
Dette er en sone som sikkerhetsmessig ligger mellom intern og sikker sone, og kan
nås både fra intern og sikker sone.

Ekstern DMZ (EZ)
Her kjøres databaser som skal aksesseres fra eksterne brukere, f.eks. fra internett
I tillegg kommer isolert miljø for intern sone og isolert miljø for sikker sone. Her plasseres databaser
med Oracle versjoner som ikke lenger er supportert.
5.11 MSQL databasehotell
SQL – hotellet kjører på standard virtuell infrastruktur (VMWare) i Oslofelles. tilsvarende SQL –
hotellet er etablert i tre soner og har totalt 8 cluster. Disse skisseres nedenfor.
SQLIntern: Dette er hoved-hotellet på intern sone og inneholder primært databaser for
kapasitetsapplikasjoner men også for infrastruktur som for eksempel Citrix, AKS, Antivirus, AppV og
Backup.
SQLInternSSRS: Dette er et DB Hotell på intern sone som støtter en del tilleggskomponenter for
MSSQL som benyttes av en del applikasjoner og som ikke støttes på SQLIntern. Dette gjelder feks SQL
Server Reporting Services (SSRS) og SQL Server Integration Services (SSIS).
SQL Intern Isolert : Dette er et DB Hotell etablert på isolert plattform og innholder databaser for
systemer som ikke lar seg oppgradere til supporterte versjon av MSSQL.
SQLSikker: Dette er hoved-hotellet på sikker sone og inneholder primært databaser for
kapasitetsapplikasjoner men også for infrastruktur som for eksempel vCenter, AKS, Antivirus, AppV
og Backup. Dette hotellet inneholder også en del databaser tilknyttet kritiske systemer.
SQLSikkerSSRS: Dette er et DB Hotell på sikker sone som støtter en del tillegskomponenter for MSSQL
som benyttes av en del applikasjoner og som ikke støttes på SQLIntern. Dette gjelder feks SQL Server
Reporting Services (SSRS) og SQL Server Integration Services (SSIS).
SQLDmz: Dette er hoved-hotellet på DMZ intern sone.
SQL Dmz intern Isolert : Dette er et DB Hotell etablert på isolert plattform og innholder databaser for
systemer som ikke lar seg oppgradere til supporterte versjon av MSSQL.
P360 DB Hotell: Dette er et DB Hotell etablert på Dmz intern og inneholder databaser for
kapasitetsapplikasjoner. DB Hotellet er dedikert for Public 360 forekomster.
MSSQL 2014 Prod: På IDMZ er det etablert et nytt DB Hotell satt opp med MSSQL 2014. Dette
hotellet er tenkt skal erstatte SQLDmz hotellet på sikt.
Side 48 av 111
Gerica: Gerica er ikke definert som et DB Hotell men er et dedikert DB miljø for Gerica som er er en
SLA applikasjon benyttet av HEL. Gerica testmiljø ligger på samme miljø som prod.
Socio og Winmed: Socio og Winmed er ikke definert som et DB Hotell men er et dedikert DB miljø for
Socio og Winmed som er er en SLA applikasjon benyttet av HEL. Socio og Winmed testmiljø ligger på
samme miljø som prod.
5.12 Sentrale fysiske basistjenester
5.12.1
Serverløsning
Serverløsningen håndterer det funksjonelle bruksmønsteret for virksomhetene. Kommunen har en
helhetlig serverløsning, og bestillinger av nye tjenester kan leveres raskere fordi det er tilgjengelig
datakraft samt at arkitekturen tar høyde for fremtidig teknologi. Servermiljøet er etablert slik at
konsolidering og standardisering kan gjennomføres.
For å sikre redundans og god utnyttelse av tilgjengelig datakraft benyttes lastbalanseringsverktøy.
Sentral serverløsning er en helhetlig serverløsning som omfatter interne og sikre tjenestesoner, hvor
alle servere er virtualisert og applikasjoner er løsrevet fra fysiske servere.
Fig. 5.14 Løsningen gir mulighet for dynamisk allokering mellom datasentre etter behov, uten nedetid.
5.12.2
DFS - Filserverdesign
Virtuelle filservere benytter Windows server 2008 R2 file services. DFS felles lagringsområder er
basert på Windows server 2008 R2 DFS. Dagens virtuelle filservere oppgradert til Windows server
2008 R2 file services. Dagens fysiske plassering av lagringsområder er etablert på Compellent SAN.
5.13 Applikasjonshotell
Applikasjonshotellet håndterer det funksjonelle bruksmønsteret for virksomhetene. Nye tjenester
kan leveres og implementeres raskere og mer dynamisk. Det er etablert testmiljø som er dynamisk
og i samsvar med produksjonsmiljøet.
Side 49 av 111
Det er etablert logiske applikasjonshotell for likeverdige applikasjoner og tjenester. Hotellene
gjenspeiler de responstids-krav som er avtalefestet i tjenesteavtalen, og SLA-krav avtalefestet mot
driftsleverandør. Applikasjonshotellet er tilpasset sikkerhetsmodellen slik at det ikke oppstår
lekkasjer mellom interne og sikre applikasjoner.
Fig. 5.15 Applikasjonshotell 1 til n illustrerer likeverdige applikasjoner i virtuelle hoteller. Hotellet størrelse, tilgang til interne
og sikre tjenestesoner, ressurstilgang og prioritering styres ved parametersetting i samsvar med tjenesteavtaler.
5.14 Sentrale basistjenester
Det er definert basis-tjenester for interne- og eksterne løsninger. Basis-tjenester for eksterne
løsninger kan deles i de som driftes felles i Oslo kommune, virksomhetsspesifikke individuelle
løsninger som driftes av virksomheten selv og de som driftes utenfor Oslo kommune av eksterne
leverandører.
Felles og
internt
Individuelt og internt
Ekstern
Integrasjonstjenester (ITAS)
● Arrangementsløsning (kurs
etc)
● Info Inn
● Info ut
● Info sak
X
X
X (begrenset)
PRK
X
X
X
AD
X
DNS
X
DHCP
X
Filserver
X
X
X
Side 50 av 111
PKI
X
SMTP
X
Anti-spam (Barracuda)
X
X
Tabell. 5.1 Sentrale basistjenester
Active Directory (AD) er Microsofts katalogtjeneste for håndtering av brukere, brukerrettigheter, og
ressurskontroll. Det er bygd opp som X.500, og er delvis LDAP-kompatibel.
Active Directory (AD) brukes til autentisering av maskiner og brukere mot Windows-domenet.
Gjennom AD har man også muligheter for å administrere maskiner, kjøre script og tilpasse lokale
oppsett.
AD i Oslofelles er implementert både på fysisk maskinvare og virtuell infrastruktur. I henhold til beste
praksis er minimum en av AD serverne på fysisk maskinvare, og alle de andre kjører på virtuell
infrastruktur.
Interne brukere:
AD brukes først og fremst for interne løsninger i dag. AD er satt opp i Oslo kommune som single
forest, single domain, hvilket betyr at alle interne brukere blir håndtert sentralt og under ett regime.
Eksterne brukere:
Denne tjenesten er ikke tilgjengelig for eksterne brukere.
5.14.1
AD – Active Directory
Interne tjenestesoner omfatter applikasjoner og tjenester som er interne, sikre tjenestesoner
omfatter applikasjoner og tjenester som er sikre. Sync PRK beskriver datautveksling mellom Active
Directory og ”Person- og ressurskatalogen” (PRK). Trust 1 til Trust N beskriver hvordan brukere i et
domene kan benytte resurser i et annet domene.
Fig. 5.16 AD Active Directory
Løsningen er implementert som single forest, single domain design som er ledende praksis for
sammenlignbare installasjoner. Alle domenekontrollere er DNS-servere. Dette gir økt feiltoleranse i
de tilfeller der en av DNS-serverne er utilgjengelig. Alle domenekontrollerne benytter seg selv som
Side 51 av 111
primær DNS-server, og en annen som sekundær. Alle domenekontrollere er en global katalog
servere.
AD i Oslofelles er implementert både på fysisk maskinvare og virtuell infrastruktur. I henhold til beste
praksis er minimum en av AD servere på fysisk maskinvare og alle de andre kjører på virtuell
infrastruktur.
5.14.2
DNS – Domain Name System
Domain Name System (DNS) er navnetjener-standarden spesifisert i TCP/IP-protokollsuiten. DNS
løsningen i Oslofelles består av Linux og Windows instanser. Alle Windows DNS instanser er AD
integrerte. Linux DNS benyttes som oppslag for de Windows baserte DNS’ene, Windows DNS er
basert på Windows server 2008 R2 og kjører på virtualiseringsplattform.
Interne brukere:
Denne tjenesten er tilgjengelig for interne brukere både i intern sone og sikker sone.
Eksterne brukere:
Tjenesten brukes også av virksomheter i Oslo kommune som ikke er rullet inn på sentral
driftsplattform for å nå sentrale fellessystemer som e-post, HR-løsning, økonomisystem, etc.
5.14.3
PRK – Person- og ressurskatalogen
Person- og ressurskatalogen, PRK, er en felles hovedkilde for person- og ressursdata i Oslo kommune.
PRK er masterdata system for personopplysninger som overføres til Active Directory. PRK
samhandler med HR systemet slik at masterdata vedlikeholdes ett sted.
PRK er verktøyet som brukes for brukeradministrasjon for brukerkontoer og tilganger til ulike
systemer og data.
PRK inneholder en oversikt (database) over
● alle ansatte i kommunen
● eksterne personer (f.eks. innleide konsulenter)
● ulike ressurser (f.eks. et møterom, teknisk utstyr, servere) som er knyttet til den enkelte
virksomhet
PRK brukes blant annet til:
● elektronisk samhandling mellom datasystemer og korrekt sikkerhetsmessig håndtering av
personer og ressurser (tilgangsadministrasjon). Alle som er registrert i Person- og
ressurskatalogen har fått en unik ID (ikke fødselsnummer)
● ajourhold og presentasjon av Person- og ressursinformasjon
● administrere e-postadresser, organisasjonshierarki og grupper for virksomheten
● gjøre oppslag - finne telefonnummer, adresser, e-postadresser etc. på ansatte/ressurser i
kommunen (White-pages)
Side 52 av 111
PRK er i kontinuerlig utvikling og får stadig nye bruksområder. Alle virksomheter har utpekt en
ansvarlig kontaktperson for Person- og ressurskatalogen, og oppdateringen av PRK skjer ute i
virksomhetene.
En del av informasjonen om ansatte blir daglig oppdatert med data fra kommunens lønns- og
personalsystem.
Interne brukere:
Denne tjenesten er tilgjengelig kun for interne brukere og lokale administratorer i Oslo kommunes
virksomheter.
Eksterne brukere:
Kan benyttes for brukere som gir tilgang som eksterne konsulenter og administreres i PRK.
5.14.4
PKI – Public Key Infrastructure
PKI løsningen utsteder og trekker tilbake sertifikater som benyttes i Oslo kommunes nettverk til de
klientene som benytter trådløs aksess i Oslo kommune, samt nødvendige manuelle sertifikat for å
understøtte serversiden av trådløs aksess.
Løsningen er designet generisk, uavhengig av type tjeneste den understøtter. Når det kommer til
sertifikater tilbys 3 typer sertifikat; maskin, bruker og web-server sertifikat.
PKI-løsningen støtter også nødvendige manuelle sertifikater. Løsningen benytter Microsoft Windows
Server infrastruktur og Microsoft Certification Authority (CA). Den følger kravspesifikasjon for PKI i
offentlig sektor (Direktoratet for forvaltning og IKT (Difi) / Fornyings- og
administrasjonsdepartementet (FAD) 2005). Løsningen er integrert med eksisterende Active
Directory for Oslofelles.
Fig. 5.17 PKI - Oslofelles, interne og eksterne soner
Side 53 av 111
Root CA holdes offline og startes opp ved behov for endringer som replikeres til utsteder servere.
Disse plasseres ut i interne og sikre tjenestesoner, slik at alle disse har ivaretatt en PKI løsning.
Klienter får sertifikater utstedt av utsteder server via Group Policy i AD.
PKI tjenesten i Oslofelles kjører på Windows server 2008 R2.
Interne brukere:
Tjenesten er standard benyttet for alle interne brukere i Oslo kommune.
Eksterne brukere:
Tjenesten er ikke tilgjengelig for eksterne brukere.
5.14.5
DHCP – Dynamic Host Configuration Protocol
Oslo kommune har valgt Split Scope fordi denne løsningen har færre ulemper fremfor en clustret
løsning, herunder oppsett av MS cluster på VMware og redundans ved korrupsjon av databasefil. Selv
om det vil medføre mer administrasjon med Split Scope, vil dette på sikt være en bedre løsning.
DHCP tjenesten plasseres sentralt i fellessonen og kan nås via IP Helper i aksessnett switchene.
Side 54 av 111
Fig. 5.18 Plassering av DHCP tjeneste
5.14.6
NTP – Network Time Protocol
NTP-tjenesten i Oslofelles består av åtte fysiske servere som kjører Red Hat Enterprise Linux.
5.14.7
SMTP – Simple Mail Transfer Protocol
Oslo kommunes SMTP-infrastruktur er lagdelt med et ytre lag som håndterer inn- og utgående epost, i tillegg til blokkeringslister for spam fra Spamhaus. E-post leveres derfra videre til en anti-spam
løsning beskrevet i neste kapittel før den leveres til indre SMTP-lag for videre fordeling til brukers
postboks i MS Exchange eller andre anvendelser.
5.14.8
Anti-spam
Det er etablert en anti-spam løsning fra Barracuda Networks som er satt opp i en redundant løsning
med en maskin på hver av de sentrale driftslokasjonene i en klynge. Denne står mellom ytre og indre
SMTP-lag og sjekker om inn- og utgående e-post potensielt er spam. Løsningen aksepterer, blokkerer
eller setter meldinger i karantene basert på hvordan innholdet tolkes. Bruker mottar varsling når
meldinger har havnet i karantene, og må selv behandle meldingene via en personlig karanteneinnboks.
5.14.9
Utskriftstjenester
Utskriftstjenesten håndterer det funksjonelle bruksmønsteret for virksomhetene. Funksjonalitet
knyttet til ”sikker utskrift” og ”FollowMe” er etablert som en standard, og er tilgjengelig for brukere.
Utskriftsløsningen håndterer alle klienttyper og understøtter sentrale driftsmiljø. Utskrifts
administrasjon omfatter alle utskriftskøer og enheter. Løsningen tilbyr sikker utskrift og follow-me.
Løsningen forenkler administrasjon, høyner sikkerheten og øker brukervennligheten.
Side 55 av 111
Fig. 5.19 Utskriftsløsning
5.14.10
Programvarepakking og distribusjon
Applikasjonspakking er effektivisert ved at pakker kan gjenbrukes på tvers av virksomheter og
plattformer. Distribusjon av applikasjoner er effektivisert og standardisert slik at løsningen oppleves
som effektiv og strukturert. Det benyttes testrutiner for å verifisere pakkede applikasjoner.
Programvarepakking og distribusjon håndterer alle miljøer fra ett rammeverk. Driftsleverandør for
Oslofelles utfører programvarepakking og distribusjon.
5.15 MS SQL- og Oracle-databasehotell
Databasehotell er etablert med redundans/datakraft og i stand til å håndtere det funksjonelle
bruksmønsteret for virksomhetene.
For Oracle og MS SQL er det etablert databasehotell som gir økt stabilitet, høyere sikkerhet og bedret
responstid. Alle Oracle og MS SQL databaser er flyttet inn til databasehotellet. Databasehotellene er
bygget opp slik at de kan skaleres etter etterspørsel og behov.
Fig. 5.20 MS SQL- og Oracle databasehotell
MS SQL databasehotellet benytter seg av servervirtualiseringsplattformen. Oracle databasehotell
benytter dedikert datakraft kun tilgjengelig for Oracle.
5.16 Klientkonsept
Denne delen av designet beskriver kommunens klientkonsept. Dette konseptet har 3
leveransemodeller:
● Bruk av tykke bærbare klienter med lokalt installerte applikasjoner
● Bruk av tynne klienter med sentralt installerte applikasjoner
● Bruk av virtuelle klienter (VDI) med sentralt installerte applikasjoner
Side 56 av 111
Alle sentrale fagapplikasjoner i tjenestesonene leveres igjennom en terminalserverløsning.
Terminalserveren håndterer sameksistens av flere versjoner av samme programvare for å understøtte spesielle bindinger mellom fagapplikasjoner og basis programvare. Det tilbys standardiserte
skrivere og periferutstyr som er testet og godkjent for bruk i Oslofelles. For brukere med spesielle
behov eller der applikasjoner av driftsmessige årsaker ikke kan benytte terminalserver, leveres
applikasjonen ved bruk av virtuelle klienter (VDI).
Designet for klienter støtter følgende typer:
Tykke klienter
● Bærbare klienter (PC)
● Stasjonære klienter (PC)
Tynnklienter
● Tynnklienter (produktplattform HP t510)
Virtuelle klienter (VDI)
●
●
●
●
Bærbare klienter (PC)
Stasjonære klienter (PC)
Andre klienttypder (privat, BYOD)
Aksess gjennom klientutrustningen til Fjernarbeidsplass (se under)
5.17 Leverandøraksess i OKMAN
OKMAN (Oslo kommunes konsern nett) er bygget opp for å kunne levere tjenester til sluttbrukerne i
kommunen fra de sentrale datasenterne. Veien fra tjenesteproduksjon til sluttbruker kan illustreres
slik:
Fig. 5.21 Nettverks tjenesteproduksjon til sluttbruker
Hele topologien fra og med leverandør-gatewayene (LEV-GW) er redundant, og spredt over multiple
lokasjoner. Internettbaserte tilganger er også redundante, da det er tilkoplinger til Internett på begge
de sentrale datasentrene.
Side 57 av 111
5.17.1
Tjenesteleveranser på leide linjer / faste forbindelser
Redundans vha. L2-failover over leverandørforbindelsene er ikke støttet.
5.17.2
Ethernetforbindelser
For å kople til en tjenesteleveranse til OKMAN vha. forbindelser som terminerer i en
ethernetforbindelse, kan OKMAN ta imot både kobber- eller fiberbaserte forbindelser. Forbindelsene
vil bli L3-terminerte i LEV-GWer i begge de sentrale datasenterne. Disse er koplet opp for å tilby
redundans utover (mot leverandøren), dersom leverandøren ønsker å ta dette i bruk. Dette vil i
tilfelle kreve 2 stk. forbindelser – én til hvert datasenter. Det er et krav om at det for redundante
forbindelser benyttes en dynamisk rutingprotokoll (BGPv4) mellom OKMAN og leverandøren. For å
bevare fullstendig feiltoleranse er ruterne hos leverandøren koplet sammen/utveksle
rutinginformasjon seg imellom for å registrere evt. brudd i bæretjenesten inn mot OKMAN:
OKMAN støtter følgende rutingprotokoller for slike tilkoblinger i følgende prefererte rekkefølge:
● BGPv4
● RIPv2
● Statiske ruter
5.17.3
Tjenesteleveranser over Internett
OKMAN har også redundante Internett-forbindelser. Disse kan brukes for leverandør-aksess, med
eller uten VPN-basert kommunikasjon. Det er bygget redundans i OKMAN for å ha feiltolerante
Internett-forbindelser. Dette vil en leverandør ha glede av uansett om det ikke er feiltoleranse i
leverandør-enden.
Det er også mulig for leverandøren å ha redundante Internett-tilkoplinger, da er lokal
sammenkopling likegyldig, sett fra OKMANs ståsted.
5.17.4
Tjenester ute på internett
Dersom en tjeneste er tilgjengelig over internett samt at tjenestens natur og brukere befinner seg på
kompatible sikkerhetsnivåer, kan det åpnes i Oslo kommunes brannvegger for å slippe brukerne inn
på tjenestene. Dette dersom det er porter som er utenfor standardåpningene i kommunen. Merk at
slike åpninger i mange tilfeller må gjennomgå en risiko- og sårbarhetsanalyse (ROS-analyse).
I tilfeller hvor en tjeneste ute hos en leverandør eller hvor en leverandør skal ha tilgang inn i noen av
Oslo kommunes systemer brukes det autentisert og kryptert kommunikasjon.
5.17.5
Site2site IPSec VPN-tunell
Oslo kommune benytter en redundant Cisco ruterbasert IPSec-løsning som tar i mot standard IPSec
VPN-tuneller.
5.17.6
Sonemodellen for datasenter
Datasenter (DCN) er bygd opp etter følgende implementasjon av sonemodellen til UKE.
Side 58 av 111
Fig. 5.24 Sonemodell
Det er her delt opp i følgende sikkerhetsnivå:
●
●
●
●
●
Sikkerhetsnivå «klient/aksess», KA
Sikkerhetsnivå «intern», IS
Sikkerhetsnivå «sikker», SS
Sikkerhetsnivå «DMZ» intern, IZ
Sikkerhetsnivå «DMZ» ekstern, EZ
5.18 Sikkerhetssoner- og systemtekniske sikkerhetsløsninger
Designet for sikkerhetssoner og sikkerhetsløsninger ivaretar krav til informasjonssikkerhet, og
effektiv og stabil drift. Sikkerhetsløsninger inkluderer sporbarhet til flyt og utveksling av personopplysninger i infrastrukturen. Løsningen for sikkerhetssoner understøtter virksomhetsbehovet.
5.18.1
Sikkerhetsmodell
Sikkerhetsmodellen har segmentering på tjenestenivå, slik at de forskjellige tjenestene
(applikasjonene) som leveres fra den sentrale infrastrukturen, blir separert fra hverandre. Ideen med
dette er å kunne lage en fleksibel modell som tar hensyn til lover og forskrifter, dagens trusselbilde.
Modellen understøtter de sikkerhetskrav som kommunens virksomheter har i henhold til IKTreglement.
Side 59 av 111
Fig. 5.25 Logisk oversikt over sikkerhetsmodellen
Sikkerhetsløsningen gir sterk tilgangskontroll på klientnivå og kryptering mellom alle typer klienter og
tjenere ved behov. Løsningen understøtter også fremtidige behov for å kunne tilby flere tjenester
som skal være tilgjengelige for publikum.
Side 60 av 111
Tabell. 5.3 Sonemodeller
Side 61 av 111
5.18.2
Autentisering
Katalogmiljøet i Oslo kommunes sentrale driftsmiljø består av et Active Directory-domene, Oslofelles
og flere generiske LDAP-tjenester. PRK, Person- og ressurskatalogen, er en egenutviklet applikasjon
hvor virksomhetene i Oslo kommune kan administrere grunndata for sine brukere og andre ressurser
for videre bruk i katalogmiljøet. Denne informasjonen lagres i en felles SQL-database og
provisjoneres videre til bl.a. Active Directory og OpenLDAP. All autentisering på nye systemer i
kommunen skjer fortrinnsvis mot disse og kun unntaksvis mot egne brukerdatabaser i
applikasjonene.
Alle brukerdata hentes fra kommunens lønnssystem og importeres til PRK. Fra PRK synkroniseres
brukerdata til Active Directory via av ITAS, som beskrives under neste punkt. Alle
maskinvareressurser opprettes direkte i AD ved implementering.
Det anbefales at nye systemer i Oslo kommune benytter seg av LDAP (OpenLDAP eller Active
Directory er begge tilgjengelige) for autentisering og autorisasjon.
5.19 Nettverks- og kommunikasjonsløsninger
Designet for nettverks- og kommunikasjonsløsninger, OKMAN inkluderer standardiserte og helhetlige
løsninger som er skalerbare for Oslo kommune. Designet dekker konsern nett, lokalnett (trådbundet
og trådløst), gjestenett og fjernarbeidsløsning, samt ende-til-ende overvåking av nettverket.
Trafikkprioritering, og tilgangskontroll i nettverket beskrives også, sammen med internettaksess og
bruk av mobile enheter.
5.20 Klienter i Oslo kommune
Det benyttes i dag ulike klienter i Oslo kommune. De har pr. 01.02.2016 minimum følgende ytelser:
Bærbare PC’er:
- CPU Intel(R) Core(TM)2 Duo CPU
- Minne 2GB
- Harddisk 64GB
U9400 @ 1.40GHz
Stasjonære PC’er:
- CPU Intel(R) Pentium(R) Dual CPU E2140 @ 1.60GHz
- Minne 2GB
- Harddisk 64 GB
Tynne klienter:
- HP T510: 16 GB flash, 2 GB RAM og VIA Eden X2 U4200 @ 1.0+ Ghz
- HP T520: 16GB flash, 2,5 GB RAM og AMD GX-212J SOC with Radeon R2E Graphics @ 1,2 Ghz
Side 62 av 111
6. Standardiserte driftstjenester levert fra
intern leverandør i Oslo kommune
Det inngås tjenesteavtaler mellom den enkelte virksomhet og UKE. Tjenesteavtalene regulerer
leveranse av IKT-tjenester fra gjeldende tjenestekatalog. Tjenestekatalogen har følgende kategorier
og tjenester:
6.1
Arbeidsflatetjenester
6.1.1 Brukertilgang
Brukertilgang er en obligatorisk tjeneste for alle som skal ha tilgang til «Standard fellessystemer» (se
definisjon under)
Tjenesten inkluderer drift, vedlikehold og forvaltning av nødvendig infrastruktur av disse sentrale
systemene.
6.1.2 Drift av klienter (arbeidsstasjon)
Tjenesten «Drift av klienter» sørger for vedlikehold og oppgradering av programvare på den fysiske
arbeidsstasjonen (tynn eller tykk.) Tjenesten inneholder også distribusjon, sikkerhetspatching og
overvåking av programvare.
Tjenesten forutsetter at «Brukertilgang» er opprettet. Den fysiske klienten er ikke en del av
tjenesten.
6.1.3 Drift av skrivere og tilleggsutstyr
Tjenesten inkluderer «follow me print» løsning hvor brukerne kan hente utskriften på en hvilken som
helst skriver i Oslofelles. Brukeren logger seg på den skriveren han/hun ønsker utskrift fra (via
adgangskort eller dedikert brikke). Dette gir bedre sikkerhet da utskrifter ikke blir liggende uavhentet
- og det er miljøvennlig da utskriftsjobber som ikke blir skrevet ut, automatisk slettes etter 24 timer.
Tjenesten benyttes når en virksomhet ønsker å koble til en skanner, plotter, multifunksjonsskriver
eller en nettverksskriver til Oslofelles. Tjenesten inkluderer drift av skrivere og tilleggsutstyr,
inkludert vedlikehold av SafeCom-utstyr (som sørger for «follow me print»).
Det forutsettes at skriveren regnes som godkjent av produktlisten, GPL.
6.1.4 Virtuell brukerflate – VDI
Tjenesten gir brukeren tilgang til en virtuell PC. Den virtuelle PC-en befinner seg i det sentrale
servermiljøet, men presenteres for brukeren på den lokale arbeidsstasjonen (tynn eller tykk). Den
virtuelle brukerflaten kan tilpasses spesielle behov utover det som er standardisert i Oslofelles. Det
gis applikasjonstilgang som en standard bruker, men kan ved behov gis tilgang til andre programmer.
Side 63 av 111
6.2
Systemtjenester
6.2.1 Leverandørtilgang
Leverandørtilgang gir eksterne leverandører tilgang til applikasjoner/systemer på Oslofelles. Et
eksempel kan være en ekstern applikasjonsleverandør som har behov for tilgang til systemer for
utviklings- og forvaltningsarbeid. Leverandørtilgangen gis i form av en VDI-tilgang aksess til en eller
flere avtalte applikasjoner. Leverandørtilgang til produksjonsmiljø forutsetter «skygging» (eventuelt
sidemannskontroll) av sesjonen.
6.2.2 Systemdrift
Tjenesten inkluderer alt som skal til for å tilgjengeliggjøre en applikasjon på Oslo kommunes sentrale
plattform. Den omfatter alt fra infrastruktur og servere til driften av selve applikasjonen. Tjenesten
består av 3 hovedkomponenter:
Basisdrift
Inneholder drift og overvåking av sentral infrastrukturkomponenter og virtuelle servere.
Databasedrift
Inneholder tilgang til databasehotell med det antall databaseinstanser som ønskes.
Applikasjonsdrift
Sørger for at en gitt applikasjon er tilgjengelig for brukerne til enhver tid i henhold til avtalt service
nivå.
6.2.3 Systemdrift
Tjenesten inkluderer alt som skal til for å tilgjengeliggjøre en applikasjon på Oslo kommunes sentrale
plattform. Den omfatter alt fra infrastruktur og servere til driften av selve applikasjonen. Tjenesten
6.3
Nettverkstjenester
6.3.1 Drift av lokalnett (LAN)
De lokale nettverkene (LAN) ute hos virksomhetene er virksomhetenes eget ansvar. Med denne
tjenesten kan virksomheten overlate drifts- og forvaltningsansvaret av lokalnettene til UKE.
Tjenesten leveres i tre ulike nivåer:
Overvåkning og drift
Tjenesten omfatter drift, vedlikehold og overvåkning av lokalnett, samt drift av nettverksutstyr som
er plassert i virksomhetens lokaler. Arbeid ved feil og fjernendringer er inkludert.
Enkel overvåking
Tjenesten omfatter enkel overvåking av driftsstatus på avtalt utstyr. Driftsleverandøren kontakter
virksomheten hvis feil oppstår på avtalt utstyr. Arbeid som utføres prises etter medgått tid og
materiell.
Timebasert bistand
Side 64 av 111
Ved feil må virksomheten ta kontakt med leverandøren. Arbeidet prises etter medgått tid og
materiell.
6.3.2 Trådløst nettverk (WLAN)
WLAN gir brukere muligheten til å aksessere Oslofelles uten å være tilkoblet lokalnettet via kabel.
Dette gjøres ved hjelp av ett eller flere aksesspunkter på den fysiske lokasjonen som ønsker
tjenesten.
6.3.3 Tilgang til Oslo kommunes konsernnett (OK-MAN)
Tjenesten gir virksomheten tilgang til Oslo kommunes konsernnett (OK-MAN). Virksomheten kan
velge mellom ulike hastigheter basert på fiber eller SHDSL. I tjenesten inngår overvåking, vedlikehold
og feilretting. Tjenesten gir også tilgang til Internett.
Figuroversikt
Figur nr
Beskrivelse
2.1
IKT-arkitektur
4.1
ITAS integrasjon
4.2
Synkrone kall
4.3
ITAS som integrasjonsplattform
5.1
Viser det logiske overordnede designet for IKT-infrastruktur. Det overordnede
designet baseres på to fysiske datasentra som har likeverdig funksjonalitet.
5.2
Skisse over datasenter-løsning
5.4
Datasenternettverk
5.5
Overordnet konseptuelt design på virtuell infrastruktur
5.6
Terminalservermiljø
5.14
Løsningen gir mulighet for dynamisk allokering mellom datasentre etter behov, uten
nedetid.
5.15
Applikasjonshotell 1 til n illustrerer likeverdige applikasjoner i virtuelle hoteller.
Hotellet størrelse, tilgang til interne og sikre tjenestesoner, ressurstilgang og
prioritering styres ved parametersetting i samsvar med tjenesteavtaler.
5.16
AD Active Directory
5.17
PKI - Oslofelles, interne og eksterne soner
5.18
Plassering av DHCP tjeneste
5.19
Utskriftsløsning
Side 65 av 111
5.20
MS SQL- og Oracle databasehotell
5.21
Nettverks tjenesteproduksjon til sluttbruker
5.24
Sonemodell
5.25
Logisk oversikt over sikkerhetsmodellen
Tabelloversikt
Tabell nr
Beskrivelse
2.1
Arkitekturprinsipper
5.1
Sentrale basistjenester
5.2
Karakteristikker - standard IPSec VPN-tunell
5.3
Sonemodeller
Vedlegg til bilag 3 Kundens tekniske plattform
Vedlegg 1 Arkitekturprinsipper i Oslo kommune
Vedlegg 2 Godkjente produkter
Side 66 av 111
Vedlegg 1, bilag 3: Arkitekturprinsipper i Oslo
kommune
Side 67 av 111
Prinsipper for IKT-arkitektur
i
Oslo kommune
IKT-arkitektur
Arbeidsprosess
Informasjon
Funksjonalitet (systemer)
Infrastruktur
Produsent: Sigmund Evjen
Utskrevet: 15.06.2016
Side 68 av 111
ENDRINGSLOGG
Versj.
0.9.
Dato
28. 04.
2011
Kapittel
Alle
0.9.1
11.05.11
1, 4, 5
0.9.1.
16.06.11
1
Endring
Revidert dokument
etter at FAOSprinsippene er
bygget inn
Justert etter møtet i
IKT-styringsforum
3.5.11
Tidl. Kap.5 flyttet til
underpunkt i kap 1.
Produsent
Sigmund Evjen
Godkjent
Tron Kallum
Sigmund Evjen
Sigmund Evjen
Tron Kallum
Side 69 av 111
INNHOLDSFORTEGNELSE:
1.
2.
INNLEDNING 71
1.1
Bakgrunn............................................................................................................... 71
1.2
Felles arkitekturprinsipper for offentlig sektor ........................................................ 71
1.3
Arkitekturprinsipper for Oslo kommune.................................................................. 72
1.4
Bruk av arkitekturprinsippene ................................................................................ 72
1.5
Målgruppe ............................................................................................................. 73
Visjon og mål 74
2.1
Visjon for bruk av IKT ............................................................................................ 74
2.2
3.
4.
5.
6.
7.
Oversikt over Arkitekturprinsippene 76
Presentasjon av det enkelte prinsipp 77
Forslag til Innføringsplan
88
Bruk og Oppfølging av prinsippene
89
Økonomiske konsekvenser
89
7.1
Innføringskostnader............................................................................................... 89
7.2
8.
IKT-arkitektur - visjon og mål ................................................................................. 74
Andre konsekvenser/effekter ................................................................................. 90
Definisjoner
91
Side 70 av 111
1.
1.1
INNLEDNING
Bakgrunn
IKT-reglementets kapittel 2, ”Overordnet IKT-styring og ledelse og informasjonssikkerhet”
legger overordnet ansvar for IKT-styring og ledelse til byråden for finans, som bla omfatter
overordnet ansvar for kommunens IKT-arkitektur.
IKT-arkitektur er Oslo kommunes sitt styringsverktøy
for utvikling og forvaltning av IKT-porteføljen. IKTarkitekturen handler på et overordnet nivå om
forholdet mellom arbeidsprosessene og informasjon
(data) som inngår i disse, hvilke funksjoner IKTsystemene benytter til å håndtere informasjonen, og
hvilken underliggende infrastruktur (maskiner og
nettverk) systemene benytter, ref. figuren ved siden
av.
Analogt med begreper fra byplanleggingen, kan IKTarkitektur forklares som en ”byplan” for utforming av
IKT-løsninger. Hensikten med en slik ”byplan” på IKTområdet er å bidra til at ulike IKT-løsninger passer
sammen og kan benyttes i sammenheng med hverandre.
IKT-arkitektur
Arbeidsprosess
Informasjon
Funksjonalitet (systemer)
Infrastruktur
IKT-arkitekturen styres gjennom prinsipper, standarder og målbilder. I IKT-reglementet er
IKT-arkitektur definert som ”forholdet mellom data (informasjon), verktøy, systemer og
infrastruktur nedfelt i et sett av prinsipper, sammenhenger og tekniske valg for å oppnå
ønsket forretningsmessig og teknisk standardisering og integrasjon”.
Med bakgrunn i dette, har FIN tatt initiativ til å etablere et sett med prinsipper for IKTarkitektur i Oslo kommune. Prinsippene skal være kjørereglene for utforming av IKTarkitekturen. Ved utforming av prinsippene er det lagt vekt på å sikre at IKT-utviklingen
underbygger kommunens virksomhetsmessige behov. Samtidig er det ønskelig at Oslo
kommune bidrar til bedre samordning av intern IKT-utvikling med den IKT-utvikling som skjer
eksternt i offentlig sektor, hvor det jo allerede er etablert samarbeid med andre kommuner og
med statlige virksomheter på en rekke områder. Den overordnede målsettingen for dette er
sterkere brukerorientering og mer effektiv ressursbruk i tjenesteproduksjonen.
1.2
Felles arkitekturprinsipper for offentlig sektor
I Stortingsmelding nr. 17 (2006-2007) Eit informasjonsamfunn for alle, beskrives en helhetlig
og overordnet IKT-arkitektur for offentlig sektor. Det ble her påpekt at det er viktig at den
felles offentlige IKT-arkitekturen reflekterer den enkelte virksomhets egne behov. Men
samtidig må den være fleksibel nok til å imøtekomme de ulike virksomheters og sektorers
behov på tvers, for å legge til rette for samhandling mellom de ulike IKT-løsningene som
finnes i offentlig sektor. Å finne denne balansen er krevende.
I Stortingsmelding nr. 19 (2008-2009) Ei forvaltning for demokrati og fellesskap, fremmet
derfor regjeringen 7 arkitekturprinsipper for offentlig sektor, de såkalte FAOS-prinsippene.
Prinsippene skal fungere som et rammeverk for den felles offentlige IKT-arkitekturen, og er
obligatoriske å bruke for statlige virksomheter, og anbefalt brukt i kommunene. Prinsippene
Side 71 av 111
skal benyttes ved utvikling av nye IKT-løsninger eller ved vesentlige endringer av
eksisterende løsninger.
Prinsippene er utformet for å balansere hensynet til helhet og samordning på den ene siden
mot hensynet til lokale IKT-løsninger og virksomhetsspesifikke behov på den andre siden.
Dette gir seg blant annet utslag ved at prinsippene er forholdsvis generelt formulert. Det er
den enkelte virksomhets ansvar å operasjonalisere og utdype prinsippene, og ta dem i bruk
på et vis som gjør at intensjonen med prinsippene blir ivaretatt samtidig som det enkelte
prinsipp tilpasses virksomhetens virkelighet. Dette innbefatter også å vurdere områder hvor
det er behov for ytterligere prinsipper og flere utdypninger.
Prinsippene blir forvaltet av Direktoratet for forvaltning og IKT - DIFI, og det er derfor etter
hvert blitt vanlig å omtale dem som DIFI-prinsippene.
1.3
Arkitekturprinsipper for Oslo kommune
Når Oslo kommune skal etablere et sett med arkitekturprinsipper, er det nærliggende og
ganske selvfølgelig å legge DIFI-prinsippene til grunn. Prinsippene er utformet slik at de skal
ivareta samordning av IKT-arkitekturen i offentlig sektor, samtidig som den enkelte
virksomhets spesifikke behov for IKT-utvikling blir imøtekommet. Oslo kommune kan selv
utdype det enkelte prinsipp slik at det gir mest mulig relevant styring av kommunens IKTutvikling.
Oslo kommune deltar i det såkalte K10-samarbeidet mellom de 10 største kommunene, hvor
bla felles IKT-arkitektur og felles offentlige/kommunale IKT-løsninger er i fokus. Her henviser
de 10 kommunene til DIFI-prinsippene som et felles grunnlag. Ved å legge DIFI-prinsippene
til grunn oppnår Oslo kommune både å være en del av et større fellesoffentlig initiativ,
benytte de samme føringene som de kommunene vi samarbeider med på IKT-området, og
samtidig ha et instrument som er tilstrekkelig fleksibelt til å sikre den ønskede IKT-utviklingen
i kommunen.
DIFI- prinsippene ivaretar først og fremst et utviklings- og samordningsperspektiv i offentlig
sektor. For Oslo kommune er det også vesentlig å ivareta forvaltning og drift av IKTporteføljen over tid. Oslo kommune har derfor tatt frem et sett med tilleggsprinsipper, som
føyes til de fellesoffentlige DIFI-prinsippene, og som gis likeverdig status ved anvendelse i
kommunen. Dette gjelder 4 prinsipper. For det første at arkitekturvurderinger skal utføres ved
alle IKT-leveranser, for det annet at kommunen til enhver tid skal ha helhetlig oversikt over
systemporteføljen, for det tredje at systemer og infrastruktur skal skal oppfylle krav til
oppetid, åpningstider og stabilitet, og for det fjerde at innføring av nye systemer og
infrastruktur skal være foranlediget av teknisk og kostnadsmessig levetidsvurdering.
Både DIFI-prinsippene og kommunens tilleggsprinsipper skal skape økt gjenbruk og flerbruk
av IKT-systemene, både internt i kommunen, men også mellom kommunen og våre
samarbeidspartnere. Oslo kommune vektlegger spesielt samhandling med fylkeskommunal
og kommunal sektor på IKT-området.
1.4
Bruk av arkitekturprinsippene
Prinsippene gjelder både ved anskaffelser, endringer, løpende forvaltning og drift av IKTsystemer. Kommunale virksomheter skal legge prinsippene til grunn ved både nyutvikling
og/eller endringer i sine IKT-løsninger.
Side 72 av 111
Det vil vanligvis være kostbart og ulønnsomt å bygge om et allerede eksisterende system for
å innfri prinsippene helt og holdent. Fordi prinsippene er overordnede og felles for alle
kommunale virksomheter, vil det bety at ikke alle prinsippene vil passe like godt for alle IKTprosjekter.
Det er viktig å presisere at for hvert enkelt prosjekt må det vurderes konkret hvorvidt
arkitekturprinsippene er hensiktsmessige og hvilke konsekvenser de får. Anvendelsen må
avveies i forhold til den konkrete situasjonen og virksomhetens strategi. I noen
sammenhenger vil det være tilstrekkelig å kun legge enkelte av prinsippene til grunn, men en
slik konklusjon kan først skje etter en vurdering av prinsippene. Flere av prinsippene
refererer imidlertid til lovverk som også er obligatorisk å følge for kommunal sektor.
På denne bakgrunn vil bruk av prinsippene fra og med 2. halvår 2011 gis status som anbefalt
å følge, men ikke obligatorisk. Dersom prinsippene fravikes skal dette likevel begrunnes. I
løpet av 2012 blir det gjort en erfaringsbasert vurdering, og det skal vurderes å justere
innhold og/eller gi dem status som obligatoriske.
1.5
Målgruppe
Prinsippene for IKT-arkitektur henvender seg til byrådsavdelingene, virksomhetsledere, IKTledere, IKT-leverandør (UKE), systemeiere og andre involverte i utvikling og forvaltning av
Oslo kommune’s IKT-portefølje.
For definisjon av begreper benyttet i dokumentet, vises til punkt 8.
Side 73 av 111
2.
Visjon og mål
2.1
Visjon for bruk av IKT
Visjons- og målformulering for utvikling av IKT-arkitekturen må underbygge kommunens
Visjon og målformuleringer for bruk av IKT.
Det er formulert følgende visjonsformulering for bruk av IKT i kommunen:
Bruk av IKT i Oslo kommune skal bidra til enklere og bedre elektronisk hverdag
i form av
- ℮nklere hverdag for innbyggere, næringsliv og kommunens ansatte
- ℮ffektiv og moderne forvaltnings- og tjenesteorganisasjon
- ℮lektroniske tjenester basert på selvbetjening og høy automatiseringsgrad
2.2
IKT-arkitektur - visjon og mål
Arkitekturpyramiden
IKT-arkitekturens visjon og mål er
utledet fra kommunens visjon for
bruk av IKT. Visjon og mål inngår i
et pyramidehierarki, som
overbygning til prinsippene, som på
sin side setter rammer for
operasjonelle standarder på
spesifikke områder, jf. figuren ved
siden av. Dette skal sikre at
prinsippene og standardene former
IKT-arkitekturen slik at IKTløsningene underbygger
kommunens virksomhet på en
målrettet måte.
 Felles ”bilde” av den fremtid vi ønsker for IKTutviklingen.
Visjon
 Målene beskriver hva vi ønsker å
oppnå med IKT-arkitektur.
 Prinsippene er styringsverktøy som
skal gi fokus på områder i IKTarkitekturen der vi ønsker å endre
eller sikre rett kurs.
 Standarder er spesifikke
krav i IKT-arkitekturen
som skal følges.
Mål
Prinsipper
Standarder
Side 74 av 111
Visjon for IKT-arkitekturen er:

Fremtidsrettede tjenester og løsninger
Mål for IKT-arkitekturen er :






å bidra til effektiv administrasjon, sterk brukerorientering og gode elektroniske
tjenester.
å legge grunnlag for god IKT-støtte til virksomhetsprosesser,
tjenesteproduksjon og elektronisk samhandling med innbyggerne, næringsliv,
andre offentlige samarbeidspartnere og kommunens ansatte.
å legge grunnlag for rask og kostnadseffektiv utvikling, innføring og
oppgradering av IKT-løsninger gjennom en helhetlig og fleksibel IKT-portefølje.
å sikre en styrbar og enhetlig IKT-portefølje gjennom tydelige målbilder,
prinsipper og standarder.
å bidra til tilgjengelige og stabile IKT-tjenester.
å legge til rette for å ivareta god informasjonssikkerhet i Oslo kommune
Side 75 av 111
3.
Oversikt over Arkitekturprinsippene
Grønn skrift: DIFI-prinsippene. Blå Skrift: Oslo kommunes tilleggsprinsipper
0.
Arkitekturvurdering
Arkitekturvurdering skal utføres for alle IKT-leveranser
1.
Tjenesteorientering
IKT-systemer skal bygges opp som en samling avgrensede delsystemer som legger til
rette for mest mulig gjenbruk.
2.
Interoperabilitet
IKT-systemer må kunne utveksle og dele data og informasjon med andre systemer
gjennom standardiserte grensesnitt
3.
Tilgjengelighet
Elektroniske brukertjenester skal være universelt utformet, og brukerne skal kunne
benytte dem uten hensyn til tid, sted og kanal.
4.
Sikkerhet
Informasjon og tjenester skal tilfredsstille krav til konfidensialitet, integritet og
tilgjengelighet.
5.
Åpenhet
Offentlige IKT-systemer skal være basert på åpne eller godkjente standarder.
Systemene skal ikke sette spesifikke krav til teknologi hos brukerne.
6.
Fleksibilitet
IKT-systemene skal være forberedt på endringer i bruk, innhold, organisering, eierskap
og infrastruktur.
7.
Skalerbarhet
IKT-løsningene skal være forberedte på endringer i antall brukere, datamengde og
levetid for tjenesten.
8.
Helhetlig oversikt
9.
Oppetid, åpningstid og stabilitet
Oslo kommunes systemer og infrastruktur skal oppfylle definerte krav til oppetid,
åpningstid og stabilitet.
10.
Levetid
Før implementering av systemer og infrastruktur skal det gjøres en teknologisk og
kostnadsmessig levetidsvurdering
Side 76 av 111
4.
Presentasjon av det enkelte prinsipp
Prinsipp 0: Arkitekturvurdering
Arkitekturvurdering skal utføres for alle IKT-leveranser.
Hvordan skal prinsippet forstås?
•
•
•
•
Med IKT-leveranser menes produksjonssetting av endringer i IKT-porteføljen, i form av
nyanskaffelser, større eller små endringer i system og infrastruktur - som ledd i
videreutvikling og/eller løpende vedlikehold. Gjelder eksisterende og framtidig IKTportefølje.
På basis av systemeiers løsningsforslag vurderes oppfyllelse av arkitekturmål og
prinsipper for alle IKT-leveranser.
Alle vesentlige avvik som påvirker IKT-arkitekturen skal konsekvensutredes og
godkjennes.
Systemeier skal definere krav til ytelse, tilgjengelighet og stabilitet for IKT-løsninger .
Motivasjon og begrunnelse for
prinsippet
Prinsippet skal sikre at implementeringsvalg ved
anskaffelser, endringer og forvaltning av IKTløsninger - eksisterende eller nye - blir vurdert i
forhold til arkitekturmessig konsekvens.
Side 77 av 111
Prinsipp 1: Tjenesteorientering
IKT-systemer skal bygges opp som en samling avgrensede delsystemer
som legger til rette for mest mulig gjenbruk.
•
•
•
•
IKT-systemene skal bygges opp og settes sammen av tjenesteorienterte
systemkomponenter som kan gjenbrukes av andre systemer og virksomheter
Felles, likeartede arbeidsprosesser skal bruke tjenester som tilbyr og behandler
informasjon ved bruk og gjenbruk av felles systemkomponenter
Arkitekturen i det enkelte system skal utnytte de muligheter for gjenbruk og deling av
tjenester som tjenesteorientering gir, for å oppnå kostnadseffektiv utvikling og
forvaltning av systemet.
Eksisterende tjenester i en systemkomponent skal alltid vurderes for gjenbruk ved
nye og eller endrede behov.
prinsippet
Formålet med tjenesteorientering som
arkitekturprinsipp i offentlig sektor er å sikre at
brukerne av offentlige tjenester får tilgang til tjenester
og informasjon der de trenger det, uavhengig av
offentlig sektors oppbygging eller portalstruktur. I
tillegg skal prinsippet sikre utvikling av felles
systemkomponenter der dette er mest
kostnadseffektivt for offentlig sektor samlet. Videre er
hensikten å tilrettelegge for mest mulig gjenbruk av
utviklet funksjonalitet på tvers av IKT-system og
virksomheter.
Side 78 av 111
Prinsipp 2: Interoperabilitet
IKT-systemer må kunne utveksle og dele data og informasjon med andre
systemer gjennom standardiserte grensesnitt

Med interoperabilitet menes her den evne et IKT-system eller delsystem har til korrekt
utveksling av informasjon med andre system, og i hvilken grad utvekslingen skjer på en
måte som understøtter de arbeidsprosesser og regelverk informasjonen og systemet skal
støtte.
-Semantisk interoperabilitet skal oppnås ved felles begreps- og informasjonsmodeller innenfor det aktuelle
samhandlingsområde. Begrepsmodeller (metadataspesifikasjoner) og informasjonsmodeller skal være
tilgjengelig. En utfordring i forhold til semantisk interoperabilitet er at det ikke er tilstrekkelig å se på
begrepenes språklige betydning siden disse i stor grad har en tilknytning til regelverk. Harmonisering av
begreper må derfor ikke overstyre lovgivers intensjon.
- Organisatorisk interoperabilitet skal oppnås gjennom samordning av arbeidsprosesser og endringer av
organisatoriske forhold nødvendig for samhandling. Dette inkluderer forretningsmodeller og regelverk.
- Teknisk interoperabilitet skal oppnås ved å bruke tekniske standarder som blant annet definerer klare
grensesnitt, overføringsprotokoller og formater, som gjør det teknisk mulig å samhandle.
I tillegg kommer det som kan kalles juridiske interoperabilitet som krever at alle berørte
parter har rettslig grunnlag for den samhandlingen de behøver eller planlegger å delta i. Det er en
forutsetning for samhandling at det ikke er motstrid mellom regelverk eller uklart rettsgrunnlag for slik
samhandling.


Prinsippet betyr at det skal tilrettelegges for elektronisk samhandling og utveksling av
informasjon internt og eksternt, basert på standard grensesnitt mellom systemene.
Et IKT-system eller delsystem skal utføre korrekt utveksling av informasjon med andre
system, og utvekslingen skal skje på en måte som understøtter de arbeidsprosesser og
regelverk informasjonen og systemet skal støtte.
prinsippet
Formålet med interoperabilitet som arkitekturprinsipp
er i størst mulig grad å sikre korrekt informasjonsflyt
på tvers av system og virksomheter og sikre at den
samlede IKT-utvikling støtter godt opp under
nødvendige arbeidsprosesser og regelverk, både
innen kommunens virksomheter og mellom
kommunen og andre offentlige virksomheter
Side 79 av 111
Prinsipp 3: Tilgjengelighet
Elektroniske brukertjenester skal være universelt utformet, og brukerne
skal kunne benytte dem uten hensyn til tid, sted og kanal.



Enhver tjeneste som etableres skal i størst mulig grad være tilgjengelig for alle som
har bruk for den, til den tid de har bruk for den, og på en måte som gjør det mulig for
dem å ta tjenesten i bruk. Tjenestene skal være enkle å lokalisere når behovet er der.
De skal være tilgjengelig i kommunens portaler eller der det er naturlig for bruker å
søke etter dem.
Tjenester som gjøres tilgjengelig for innbyggerne skal utformes slik at de er
tilgjengelige for alle grupper brukere, uavhengig av alder, kjønn, funksjonsevne og
kulturell/etnisk bakgrunn. Tjenestene bør være språktilpasset den målgruppe
tjenesten tilbys.
Ved etablering av IKT- løsninger skal kravene til universell utforming benyttes. Det
vises her til lov 20. juni 2008 nr. 42 om forbud mot diskriminering på grunn av nedsatt
funksjonsevne (diskriminerings- og tilgjengelighetsloven.
prinsippet
Formålet med tilgjengelighet som arkitekturprinsipp i
offentlig sektor er å gjøre tjenester og informasjon
tilgjengelige for relevante brukere og unngå
diskriminering av brukere eller brukergrupper, og
videre stimulere til utviklingen av en døgnåpen
forvaltning på innbyggernes/næringslivets premisser.
Side 80 av 111
Prinsipp 4: Sikkerhet
Informasjon og tjenester skal tilfredsstille krav til konfidensialitet,
integritet og tilgjengelighet.






Kommunens IKT-systemer skal tilfredsstille gjeldende krav til informasjonssikkerhet.
Med informasjonssikkerhet i denne sammenheng menes at informasjon og tjenester i
IKT-systemene skal tilfredsstille formelle og risikobaserte krav til konfidensialitet,
integritet og tilgjengelighet i forhold til alle potensielle brukergrupper.
IKT-systemene skal oppfylle lovpålagte og kommunens egne definerte krav til
informasjonssikkerhet.
Kommunens IKT-systemer skal legge til rette for en god og hensiktsmessig
praktisering av krav til tilgangskontroll til informasjon. Informasjon skal kun
tilgjengeliggjøres og gjenbrukes innenfor regelverkets fastsatte sikkerhetskrav.
Nye og endrede IKT-systemer skal gjennomgå sikkerhetsmessig risikoanalyse før
etablering.
Sikkerhetsrevisjon av bruk av informasjonssystemer skal gjennomføres jevnlig.
Datatilsynets anbefaling er at dette skjer årlig.
Det skal føres oversikt over hva slags personopplysninger som behandles. Instruks
for kommunens informasjonssikkerhet og IKT-reglementet gir utfyllende
bestemmelser om dette.
prinsippet
Sikkerhetsprinsippet er det viktigste for å
opprettholde tilliten til offentlig sektor. Prinsippet er
blant annet hjemlet i personopplysningsloven,
forvaltningsloven, sikkerhetsloven,
tjenestemannsloven og regler om taushetsplikt.
Formålet med sikkerhet som arkitekturprinsipp er å
sikre at kommunale IKT-løsninger blir etablert og
driftet på en sikkerhetsmessig god måte, samtidig
som informasjon og tjenester blir elektronisk
tilgjengelig for de som behov for og/eller rettigheter
til disse. Samtidig skal det bidra til å styrke
kommunale virksomheters kompetanse,
organisering, kultur og regelverksetterlevelsesevne
rundt informasjonssikkerhet.
Side 81 av 111
Prinsipp 5: Åpenhet
Offentlige IKT-systemer skal være basert på åpne eller godkjente
standarder. Systemene skal ikke sette spesifikke krav til teknologi hos
brukerne.



Åpenhet og bruk av godkjente standarder skal sikre at elektroniske tjenester kan
tilbys gjennom flere kanaler, iht Oslo kommunes kanalstrategi. Dette innebærer at
enhver systemkomponent som etableres skal være basert på åpne eller godkjente
standarder. Det betyr at tjenestene etableres gjennom standardiserte grensesnitt for
samhandling.
IKT- tjenestenes innhold skal være mest mulig transparente slik at tjenestens logikk
og datakilder kan gjøres kjent. Med transparente løsninger menes at tjenestens logikk
og datakilder skal være kjent, slik at man vet hvilke premisser som ligger til grunn for
avgjørelser.
Standarder skal sikre at innhold i funksjoner og data er i henhold til felles, fastsatte
krav. Videre at data kan utveksles med andre systemer innen og mellom
virksomheter på en effektivt og tiltrodd måte. Publikumstjenestenes innhold og
virkemåte skal være transparente på tvers av brukermiljø.
prinsippet
Standarder fastsatt gjennom formelle og avtalte
godkjennings-prosesser er åpne. Anvendt i
kommunen og i offentlig sektor, sikrer dette økt
samhandling på tvers i form av felles og
samvirkende IKT-systemer. Sluttbrukerne vil kunne
samhandle med offentlig sektor mest mulig
uavhengig av teknologi- og systemvalg.
Der hvor tjenesten innebærer rettslige
systemavgjørelser eller støtte til
myndighetsutøvelse, er det særlig viktig at
innbyggerens og næringslivets rettssikkerhet
ivaretas ved at beslutningene er dokumenterbare og
sporbare, og kan gjøres tilgjengelige ved behov.
Dette kan for eksempel være i form av at kildekoden
kan gjennomgås. Denne delen av prinsippet er
hjemlet i forvaltningsloven og
personopplysningsloven (klagerett og retten til
innsyn).
Side 82 av 111
Prinsipp 6: Fleksibilitet
IKT-systemene skal være forberedt på endringer i bruk, innhold,
organisering, eierskap og infrastruktur


Fleksibilitet betyr at IKT-systemer skal etableres og utvikles på en slik måte at de i
løpet av sin livssyklus skal tåle endringer i bruk, innhold, organisering, eierskap og
infrastruktur.
Enhver løsning som etableres skal være utviklet på en slik måte at gjenbruk i andre
sammenhenger og med andre rammevilkår er mulig. En IKT-løsning skal være så
fleksibel at den skal kunne benyttes i andre sammenhenger på en enkel måte til lav
kostnad. Dette krever blant annet at løsningene skal være modulære slik at de verken
er for generelle eller for spesifikke
prinsippet
Det er viktig at kommunens IKT-systemer bygges
med utgangspunkt i de kravene og behovene som
de kommunale virksomheter har for å løse sine
oppgaver. Systemene må kunne endres i takt med
at de virksomhetsmessige behovene endres.
Løsningenes informasjonshåndtering skal også
kunne utvides uten at det initierer utvikling av en helt
ny informasjonstjeneste. For eksempel skal
innsending og rapporteringer av data fra innbyggere
og næringsliv kunne utvides med flere typer data
uten at det påvirker eksisterende innrapportering i en
allerede etablert innrapporteringstjeneste.
Side 83 av 111
Prinsipp 7: Skalerbarhet.
IKT-løsningene skal være forberedte på endringer i antall brukere,
datamengde og levetid for tjenesten




Skalerbarhet betyr at IKT-systemets utvikling og implementering ikke skal være
begrensende for de tilbudte tjenestenes livssyklus og grad av utnyttelse. Skalerbarhet
skal designes i henhold til definerte krav til løsning.
Prinsippet innebærer at tjenestene i utgangspunktet skal være tilpasset alle aktørers
behov – fra de minste til de største.
Det skal gjøres en sannsynlighetsvurdering av skaleringsbehov, samt i hvilken
sammenheng behovet vil treffe løsningen (bruksmønster, samtidige brukere,
transaksjonsvolum i travel time, datamengde, endring i datastruktur, osv.).
Infrastrukturkomponenter skal kunne utbygges og utskiftes modulært og mest mulig
uavhengig av hverandre
prinsippet
IKT-systemer, nåværende eller framtidige, skal være
forberedt for endringer i bruksmønster, innhold,
organisatoriske endringer, eierskap og infrastruktur.
Dette stiller krav til skalerbarhet i begge retninger, og
det er viktig å påpeke at nedskalering er en minst
like viktig egenskap som oppskalering. Når løsninger
planlegges og designes må det legges til rette for at
den også skal kunne fungere under andre miljø, i
andre virksomhetsprosesser og med andre
bruksvolum. Dette kan gi løsningen en forventet
merkostnad initielt, men reduserer kostnadene for
den neste som tar løsningen i bruk.
Side 84 av 111
Prinsipp 8: Helhetlig oversikt
•
•
•
•
•
Systemoversikten beskriver: Det enkelte system på overordnet nivå; programvare og
databaser; evt. nødvendig infrastruktur (maskinvare, nettverk).
Oversikten synliggjør interne og eksterne avhengigheter og grensesnitt for de ulike
deler, og benyttes for å kunne vurdere muligheter og konsekvenser ved endringer.
Systemoversikten viser klassifisering etter: kritikalitet, fellessystem, sektorsystem,
tverrsektorielle og virksomhetsspesifikke system.
Systemoversikten viser kontaktinformasjon til systemeier og evtentuelt andre relevante
bidragsytere innenfor drift, systemutvikling mv.
Systemeier er ansvarlig for vedlikehold av informasjonen i systemoversikten.
prinsippet
Arkitekturstyring forutsetter oversikt over hvordan IKTporteføljen er sammensatt, slik at konsekvenser av
valg kan identifiseres og vurderes opp mot en
helhetlig oversikt. Dette gjelder
konsekvensvurderinger innenfor og mellom systemer,
mellom systemer og infrastruktur, og ikke minst for
informasjonsinnhold og -bruk i arbeidsprosesser innen
og mellom respektive funksjonsområder.
Side 85 av 111
Prinsipp 9: Oppetid, åpningstid og stabilitet
Oslo kommunes IKT-systemer og -infrastruktur skal oppfylle definerte
krav til oppetid, åpningstid og stabilitet
•
•
•
Systemeierne skal fastsette krav til åpningstider, oppetid og responstid for sine
respektive systemer.
Krav til driftsstabilitet i kjøremiljøet skal være basert på systemeiernes krav til
åpningstider, oppetider, og responstid.
Ved anskaffelse eller videreutvikling av et system, skal det være angitt krav til
driftsmiljø, basert på kravene til driftsstabilitet.
prinsippet
Driftsstabilitet, responstid og åpningstid er viktig for
brukernes opplevde tilgjengelighet til systemene –
som direkte påvirker tjenestenivå. Dette må være
basert på virksomhetsmessige krav til tjenestenivå,
fastsatt av systemeier. Krav til kjøremiljø må
fastsettes i kravspesifikasjonsfasen, før systemet går
i produksjon. Kostnadene for valgt tjenestenivå må
være tilstrekkelig identifisert.
Side 86 av 111
Prinsipp 10: Levetid
Før implementering av systemer og infrastruktur skal det utføres en
teknologisk og kostnadsmessig levetidsvurdering





I forbindelse med levetidsvurderinger må man sikre at alle komponenter som inngår i
IKT-løsninger (fagsystemer, basisprogramvare og infrastruktur) har mulighet for
framtidig vedlikehold og støtte fra produsent.
Som del av levetidsvurderingen skal hovedstrømningene i bransjen være en av
faktorene som inngår.
Større investeringer skal baseres på kost/nyttevurdering i valgt økonomisk levetid
Kjøp av standardsystem prioriteres før egenutvikling
Intern leverandør har ansvar for å identifisere, koordinere og gjennomføre godkjente
endringer i Oslo kommune felles og lokal infrastruktur. Livssyklus for tjenester og
ressurser inngår som sentrale elementer i prosesser som intern leverandør benytter.
prinsippet
Arkitekturvurderinger må ledsages av
kostnadsvurderinger ved etterlevelse og/eller avvik,
på kort og lang sikt. Livssykluskostnader gir bedre
beslutningsgrunnlag for slike vurderinger. Tekniske
levetidsvurderinger må også kunne omsettes i
økonomiske konsekvenser for en gitt økonomisk
levetid. Kommunen skal unngå egenutvikling av
systemer på områder det eksisterer
standardsystemer.
Ved anskaffelse av et system skal det vurderes om
løsningen også kan brukes av flere virksomheter i
kommunen.
Side 87 av 111
5.
Forslag til Innføringsplan
Det er utarbeidet forslag til plan for innføring av arkitekturprinsippene i byrådsavdelingene og
i underliggende virksomheter. Planen er utarbeidet av FIN og UKE i fellesskap. Planen
inneholder følgende hovedaktiviteter:
Hovedaktivitet
H1 Informere og forankre
i byrådsavdelingene og
virksomhetene
Ansvarlig
FIN
Utførende
FIN + UKE
H2 Operasjonalisering av
IKT-arkitekturprinsipper
UKE
UKE
H3 Utarbeide Rolle og
prosessbeskrivelser
H4 Pilotering og
evaluering
UKE
UKE
UKE
UKE
H5 Utarbeide standarder
og retningslinjer
UKE
UKE
Medvirker
Byrådsavdelinger,
Virksomhetsledere,
Systemeiere, IKTansvarlige
Godkjenner
FIN
FIN
Virksomhetsledere,
FIN
FIN
De enkelte prinsipper
gjennomarbeides med henblikk
på:
-konsekvenser
-hindringer for etterlevelse
-handlinger for å etablere prinsippet
-relevante modeller for
implementering
-henvisning til relevante standarder
FIN
Hovedaktivitet H1 blir gjennomført som del av en felles forankringsprosess i
byrådsavdelingene og underliggende virksomheter i tilknytning til innføringsplan for IKTreglementet. Innholdet i forankringsprosessen er under drøfting med byrådsavdelingene og
er planlagt startet i september 2011. Det er etablert en egen kontaktgruppe mellom FIN og
de øvrige byrådsavdelingene i denne forbindelse. Ressursmessig omfang vil bli drøftet med
kontaktgruppen.
De øvrige hovedaktivitetene blir planlagt og gjennomført i regi av Utviklings- og
kompetanseetaten (UKE), i henhold til tildelingsbrevet til UKE for 2011.
Varighet for aktivitetene H2 til H5 vil variere fra 6-8 uker, tidspunktet for når de skal
gjennomføres vil bli fastlagt gjennom detaljplanleggingen. Det er forventet at
innføringsprosessen vil pågå ut 2011. Ressursmessig omfang for deltakere fra
virksomhetene i aktivitetene H2, H3 og H5 forventes å bli mellom 2- 4 dagsverk pr person pr
aktivitet. For H4 aktiviteten noe høyere - 5-10 dagsverk .
For UKE vil ressursinnsatsen sjølsagt forventes å bli vesentlig større, da den vil kreve en
eller flere ressurspersoner på tilnærmet full tid under gjennomføring av aktivitetene.
Side 88 av 111
6.
Bruk og Oppfølging av prinsippene
Innføringsaktivitetene nevnt i punkt 5 skal utdype innhold og forklare bruk av
arkitekturprinsippene gjennom å ta frem ytterligere informasjon og dokumentasjon til bruk for
byrådsavdelingene, underliggende virksomheter og/eller leverandører. Informasjons- og
forankringsaktiviteten H1 retter seg mot ledersjiktet i byrådsavdelingene og virksomhetene,
mens de resterende aktivitetene retter seg mot de som skal anvende og følge opp bruk av
prinsippene på operativt nivå.
IKT- reglementet etablerer styringsmodellen for IKT og informasjonssikkerhet. Reglementet
beskriver fullmakts-, ansvars- og oppgaveforhold i fire nivå - byrådet, byråden for finans,
byrådsavdelingene og virksomhetene Det er også gitt bestemmelser om samhandling og
koordinering mellom de ulike nivåene og rollene.
Ansvaret for kommunens IKT - arkitektur er lagt til byråden for finans, og
arkitekturprinsippene representerer som før nevnt et styringsverktøy for utvikling av
kommunens IKT-arkitektur og IKT-løsninger. Det følger av reglementet at byråden for finans
legger prinsippene fram fort behandling i IKT-styringsforum før vedtak fattes. Analogt med
dette, er det IKT-styringsforum som drøfter og tar stilling til viktige spørsmål for IKTarkitekturen. Det vil således være IKT styringsforum som er det sentrale forum behandling av
prinsipale spørsmål i lys av arkitekturprinsippene.
Bruk av prinsippene på operasjonelt nivå vil skje i hos systemeierne, i deres
implementerigsprosjekter og forvaltningsoppgaver, og hos intern leverandør. Forutsetningen
for at dette skal skje er imidlertid at prinsippene blir gitt utfyllende forklaring og
retningslinjer i form av konsekvensbeskrivelser, implementeringsmodeller, identifisering av
relevante standarder knyttet til det enkelte prinsipp, og hva som er til hinder for at prinsippene
skal overholdes. Rutine for avvikshåndtering må etableres, inkludert prosedyre for hvordan
denne skal anvendes.
I tillegg må det utarbeides rolle-og prosessbeskrivelser som ankueliggjør roller og oppgaver
knyttet til anvendelsen av prinsippene. Dette innbefatter prosesskart for å anvendelse,
oppfølgingsprosess og beskrivelse av avvikshåndtering og oppfølging. Kriterier for når
prinsippene må anvendes og eventuelt når de kan fravikes, må også utarbeides. Videre må det
etableres en arkitekturfunksjon som koordinerer samhandlingen om bruk av prinsippene, og
som driver prosessen for oppgølging og avvikshåndtering. På operativt nivå bør denne ligge i
UKE, mens det vil være IKT-styringsforum som behandler spørsmålen på strategisk nivå.
Evaluering og eventuell justering av prinsippene ligger til FIN, som legger eventuelle
endringer fram for IKT-styringsforum.
7.
Økonomiske konsekvenser
7.1
Innføringskostnader
De direkte økonomiske konsekvenser av etablering av arkitekturprinsippene knytter seg til
forankrings- og veiledningsprosesser i forlengelsen av etableringsvedtaket. Dette dreier seg
om :


Planlegging av forankringsprosess og veiledningsopplegg, i første omgang i FIN og
UKE
Personressurser i byrådsavdelingene og i virksomhetene i form av møtetid og
gjennomgang av veiledningsdokumentasjon.
Side 89 av 111


Personalressurser i UKE, til å lage forslag til operasjonalisering av prinsippene i form
av standarder, retningslinjer og prosessbeskrivelser.
Personalressurser i byrådsavdelingene til å følge opp bruken av prinsippene etatene
og virksomhetene
Det er forventet at disse prosessene vil kunne utføres innenfor rammen av tilgjengelig
kompetanse og ressurser i den enkelte virksomhet.
7.2
Andre konsekvenser/effekter
Oslo kommune vil totalt sett kunne oppnå store gevinster ved at kommunale virksomheter
etablerer sine IKT –løsninger over en felles IKT-arkitektur. Dette vil legge til rette for et
bredere og mer effektivt samarbeid og informasjonsflyt mellom sektorer og mellom
kommunale virksomheter, og en potensiell gjenbrukseffekt vil kunne oppnås. Samarbeid om
og eventuelt deling av IKT-løsninger gir en mer helhetlig kravstilling til løsninger og dermed
en mer kostnadseffektiv utvikling eller anskaffelse, dette er kjent erfaring fra tidligere.
Kommunale virksomheter vil dermed kunne fremstå med mer markedsmakt overfor
leverandørmassen enn om de opptrer hver for seg. Felles arkitektur gir også et større
potensiale for gevinster ved utvikling av nye elektroniske tjenester, både for kommunen,
innbyggere og næringsliv.
Oslo kommune har i utgangspunktet de samme utfordringene som andre kommuner når det
gjelder å benytte seg av felleskomponenter og felles "maler" for utvikling av sine tjenester.
K10-samarbeidet har satt dette i fokus, og etablering av et sett felles arkitektuprinsipper gjør
det mulig å etablere systemløsninger på egnede samarbeidsområder, tilpasset den enkelte
kommune, men bygget over en felles lest basert på felleskomponenter og felles tjenester.
I et videre perspektiv vil bruk av felles offentlige prinsipper for IKT arkitektur og etablering av
felles IKT-arkitektur i offentlig sektor, gi en åpenbar gevinst for offentlig sektor samlet sett,
ved at statlig sektor kan forholde seg til kommunal sektor på en mer ensartet måte, både på
det tekniske nivået, men også etterhvert på det semantiske nivået. Dette vil bidra til at
informasjonsutveksling mellom forvaltningsnivåene vil være enklere og mer standardisert
enn i dag. Innbyggerne vil oppleve en enklere hverdag i møte med offentlige myndigheter, og
offentlig sektor vil anvende sine administrative ressurser mer effektivt. Samlet sett kan
totalkostnadene knyttet til bruk av IKT dermed bli lavere, både for Oslo kommune og for
offentlig sektor.
Side 90 av 111
8.
Definisjoner
IKT-arkitektur:
• Forholdet mellom data (informasjon), verktøy, systemer og infrastruktur nedfelt i et
sett av prinsipper, sammenhenger og tekniske valg for å oppnå ønsket
forretningsmessig og teknisk standardisering og integrasjon.
• Er Oslo kommunes samt de enkelte virksomheter sitt styringsverktøy for
utvikling og forvaltning av IKT-porteføljen.
• Viser arbeidsprosesser, informasjon, funksjonalitet (systemer) og infrastruktur,
og sammenhengen mellom dem.
• Styres gjennom prinsipper, standarder og målbilder
System (eller også IKT-system):
• Et eller flere dataprogrammer og databaser utviklet og satt sammen for å understøtte
definerte prosesser i organisasjonen.
• Understøtter en virksomhetsprosess/arbeidsprosess.
• Består av en eller flere applikasjoner.
• Har en systemeier.
Infrastruktur:
• Tjenester, operativsystemer, maskinvare og kommunikasjonsløsninger som er
nødvendig for å få systemer til å fungere og til å samhandle slik at opplysninger kan
utveksles mellom virksomheter internt i Oslo kommune og mellom Oslo kommune og
kommunens innbyggere, brukere, kunder og næringsliv.


•
•
•
Intern leverandør: Leverandør av drift og vedlikehold av systemer og
infrastruktur i henhold til tjenesteavtaler inngått med kommunens
virksomheter. I praksis siktes det her til UKE
IKT-portefølje
– IKT-porteføljen er totaliteten av systemer og infrastruktur.
IKT-løsning: (Avgrenset) del av IKT-porteføljen innenfor et funksjonsområde
Applikasjon: Brukersystem (innenfor IKT), i motsetning til operativsystem eller
driftsverktøy (Hentet fra Veileder til Instruks for Informasjonssikkerhet)
• Inneholder brukerfunksjoner for et spesifikt område, for
eksempel Arkiv, HR-applikasjon, innbygger/folkeregister.
• En eller flere applikasjoner kan utgjøre et IKT-system
• Representerer ingen selvstendig verdikjede, men inngår i dem.
• Eierskapet ivaretas gjennom et av systemene de inngår i.
Komponent: Brukes på flere måter, oftest om en bestanddel i et IKT-system Applikasjon, database, Infrastruktur(maskin, nettverk, kontroller, skriver etc)
Mer spesifikt i arkitektursammenheng: En (programvare) komponent er en
sammensatt programvareenhet med et veldefinert, spesifisert grensesnitt, i eksplisitte
kontekstuelle relasjoner. En komponent kan bli etablert i kjøremiljøet som en
selvstendig enhet eller som del av en større sammensatt enhet (applikasjon eller
system).
Side 91 av 111
Vedlegg 2, bilag 3: Godkjente produkter
Side 92 av 111
Godkjente produkter pr 07.06.2016
Kategori
.Net
Applikasjonshotell
tba
Adaptive Security Appliance
Datasenternettverk
tba
Anyconnect v. 3.1.08009
Datasenternettverk
mars 2018
Anyconnect v. 4.X
Datasenternettverk
tba
Apache HTTPD
Applikasjonshotell
tba
Apache tomcat
Applikasjonshotell
tba
CentOS release 5.x (Final)
Applikasjonshotell
mars 2017
CentOS release 6.2 (Final)
Applikasjonshotell
november 2020
CentOS release 6.x (Final)
Applikasjonshotell
november 2020
Cisco Nexus 1000V
Datasenternettverk
september 2018
BIG-IP (F5)
Datasenternettverk
Citrix NetScaler MPX 14500 - Enterprise edition
Citrix NetScaler VPX 10 - Enterprise edition
Godkjent til dato
januar 2020
Fornyes årlig
Clusterware 11.2
Oracle databasehotell
desember 2018
Clusterware 12.1
juni 2021
DocuDB
Applikasjonshotell
tba
Firebird 2.5.5
Applikasjonshotell
tba
IIS
Applikasjonshotell
tba
Ironport HW
Datasenternettverk
juni 2019
Ironport SW
Datasenternettverk
tba
Microsoft Windows 7
Applikasjonshotell
desember 2019
Microsoft Windows Server 2008 R2
Applikasjonshotell
desember 2019
Microsoft Windows Server 2012
Applikasjonshotell
januar 2023
MongoDB 2.6
Applikasjonshotell
tba
MongoDB 3.0
Applikasjonshotell
tba
MS SQL Server 2008 R2 Enterprise
MS SQL databasehotell
juni 2018
MS SQL Server 2012
juni 2022
MS SQL Server 2014
juli 2024
MySQL / MariaDB
tba
MySQL 5.5.44
Applikasjonshotell
desember 2018
Oracle databasemotor til 11.2
desember 2020
Oracle databasemotor til 12.x
juli 2021
Oracle db v.11.2
desember 2016
Oracle db v.12.1
juli 2021
PostgreSQL
Red Hat Enterprise Linux Server release 5.x
Applikasjonshotell
mars 2017
Red Hat Enterprise Linux Server release 6.x (Santiago)
Applikasjonshotell
november 2020
Red Hat Enterprise Linux Server release 7.x
Applikasjonshotell
juni 2024
Trend Deep Security
tba
Trend Micro OfficeScan Client v.10.6.2108
Klientprogramvare
tba
Trend Micro OfficeScan Client v.11.xx
Klientprogramvare
tba
Universaldriver Canon
Periferiutstyr
tba
Universaldriver HP
Periferiutstyr
tba
Universaldriver Lexmark
Periferiutstyr
tba
tba
Side 93 av 111
Universaldriver OCE
Periferiutstyr
tba
Universaldriver Richo
Periferiutstyr
tba
Universaldriver Xerox
Periferiutstyr
tba
VMware ESXi 5.5
august 2018
VMware ESXi 6.0
mars 2020
VMware vRealize Cloud Management plattform
tba
vSphere Enterprise+
tba
WIN CE 6.0
april 2018
WIN Embedded Standard
tba
Windows 7 Enterprise
Klientprogramvare
desember 2019
Windows Embedded Device Manager 2011 Client Service Pack Klientprogramvare
1 v.1.0.600.0
Windows Embedded Standard (Windows 7) v.2010
Klientprogramvare
september 2020
Windows Essentials 2012 v.16.4.3508.0205
Klientprogramvare
september 2020
Citrix 7.6
Microsoft Office Standard 2010 v.14.0.4763.1000
Klientprogramvare
Internet Explorer 11
Klientprogramvare
Google Chrome
Klientprogramvare
Firefox
Klientprogramvare
september 2020
Side 94 av 111
Bilag 4: Leveringstidspunkt og andre frister
Avtalens punkt 2.1.5 Tid og sted for Leverandørens ytelse
Prosjektet har utarbeidet faseplan som synliggjør hovedaktiviteter med tidsreferanse. Det legges
videre ved forslag til foreløpig puljeplan for å synliggjøre innføringsmetode. Prosjektets milepælplan
synliggjør viktige milepæler ifm. anskaffelsen og senere implementering
Prosjektets faseplan
Fasenr
1
2
3
4
5
6
7
8
9
10
Fase
Jun Jul
2016
Aug (1)Aug (2)Sep Okt Nov Des Jan
2017
2018
Feb Mar Apr Mai Jun Jul Aug (1)Aug (2)Sep Okt Nov Des Jan Feb Mar Apr Mai
Anskaffe prosjektressurser
Gjennomføre anskaffelsen
Kontraktsoppfølging
Oppsett, installering og test
Opprette felles forvaltning for EHS
Etablere felles kvalitetsystem for EHS
Metode for forberedelse, mottak og realisering
Forberede Systeminnføring og realisering (puljevis iht puljeplan)
Realisere og overføring til systemforvaltning (puljevis iht puljeplan)
Prosjektavslutning
Prosjektets foreløpige puljeplan
Forklaringer til puljeplanen:
f:forberedelser i virksomhet
mp: oppstart i mottaksprosjekt
u: implementeringsperiode
Hovedaktiviteter
Pilot: EHS Pilot (SYE)
Pulje 1: EHS Bydel x13
Pulje 2: HEL
Pulje 3: EHS Bydel x2
Pulje 4: VEL
Pulje 5: BFE og EHS byrådsavdeling
Systemforvaltning via prosjektet
Overførsel til linjen- felles systemforvaltning- prosjketavslutning
2016
2017
2018
Nov Des Jan Feb Mar Apr Mai Jun Jul Aug (1)
Aug (2)
Sep Okt Nov Des Jan Feb Mar Apr Mai
mp f
f
u u
mp f
f
f
f
u u
mp f
f
f
u u
mp
f
f
f
u u
mp
f
mp
f
f
f
f
f
f
u
f
u
u
u
Side 95 av 111
Prosjektets Milepæls plan
Fasenr.
1
2
2
2
3
4
4
4
4
4
4
4
4
4
5
5
6
6
6
7
7
7
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
10
10
Fasebeskrivelse
Anskaffe prosjektressurser
Kontraktsoppfølging
Etablere felles kvalitetssytem for EHS
Metode for forberedelser, mottak og realisering
Forberede systeminnføring og realisering
Realisering og overføring til systemforvaltning
Prosjektavslutning
Prosjektavslutning
MP nr
MP1
MP2
MP3
MP4
MP5
MP6
MP7
MP8
MP9
MP10
MP11
MP12
MP13
MP14
MP15
MP16
MP17
MP18
MP19
MP20
MP21
MP22
MP23
MP24
MP25
MP26
MP27
MP28
MP29
MP30
MP31
MP32
MP33
MP34
MP35
MP36
MP37
MP38
MP39
MP40
MP41
MP42
MP43
MP44
MP45
MP46
MP47
MP48
MP49
MP50
MP51
MP52
MP53
MP54
MP55
MP56
MP57
MP58
MP59
MP60
MP61
MP62
MP63
MP64
MP65
MP66
MP67
MP68
MP69
MP70
MP71
MP72
Milepæl
Når prosjektressurser er fremskaffet
Når konkurransen er kunngjort
Når leverandør er valgt
Når avtalen er signert
Når kontrakstsforvaltning er etablert
Når plan for oppsett av driftsmiljø og installering er godkjent
Når oppsett av preprod og testmiljø er gjennomført
Når oppsett av produksjonsmiljø er gjennomført
Når løsning for SSO er etablert
Når løsning for PRK er etablert
Når løsning for migrering er etablert
Når testplan er etblert
Når test i testmiljø er godkjent
Når test i produksjonsmiljø er godkjent
Når mandat og rollebeskrivelser for systemforvaltning er godkjent
Når stillinger i systemforvaltning er besatt
Når kvalitetshåndbok er godkjent
Når behov ift kontinuerlig kvalitetsforbedringer er definert i alle virksomheter
Når fellesstruktur og felleskomponenter i IKT verktøy er utarbeidet
Når metode for forberedelse, mottak og realisering er godkjent
Når puljeplan er besluttet
Når forankring og etablering av mottaksprosjekt er gjennomført
Når oppstart med virksomhetenes mottaksprosjekt er gjennomført- pilot
Når ledelsesgjennomgang i virksomheten er gjennomført- pilot
Når superbrukere i virksomheten er lært opp- pilot
Når virksomhetene er klar for realisering- pilot
Når oppstart med virksomhetenes mottaksprosjekt er gjennomført- pulje 1
Når ledelsesgjennomgang i virksomheten er gjennomført- pulje 1
Når superbrukere i virksomheten er lært opp- pulje 1
Når virksomhetene er klar for realisering- pulje 1
Når systeminnføring og migrering er gjennomført for pilot
Når systemet er i stabil drift for pilot
Når opplæring er gjennomført for pilot
Når pilot er overført til systemforvaltning
Når systeminnføring og migrering er gjennomført for pulje 1
Når systemet er i stabil drift for pulje 1
Når opplæring er gjennomført for pulje 1
Når pulje 1 er overført til systemforvaltning
Når evalueringsrapport er overlevert
Når sluttrapport er godkjent
MP dato
Fasestart
Faseslutt
01.07.2016
01.07.2016
20.06.2016
31.12.2016
17.11.2016
31.12.2016
09.12.2016
31.12.2016
10.12.2016 10.12.2016 31.05.2018
20.01.2017
01.01.2017 30.04.2017
20.02.2017
01.01.2017 30.04.2017
27.02.2017
01.01.2017 30.04.2017
27.02.2017
01.01.2017 30.04.2017
01.03.2017
01.01.2017 30.04.2017
14.03.2017
01.01.2017 30.04.2017
17.03.2017
01.01.2017 30.04.2017
31.03.2017
01.01.2017 30.04.2017
27.04.2017
01.01.2017 30.04.2017
01.10.2016 15.08.2016 30.04.2017
30.04.2017 15.08.2016 30.04.2017
12.02.2017 15.08.2016 15.02.2017
12.02.2017 15.08.2016 15.02.2017
01.03.2017 15.08.2016 15.02.2017
12.02.2017 15.08.2016 15.02.2017
31.01.2017 15.08.2016 15.02.2017
31.10.2016 15.08.2016 15.02.2017
15.02.2017 01.02.2016 31.01.2018
26.04.2017 01.02.2016 31.01.2018
26.04.2017 01.02.2016 31.01.2018
09.05.2017 01.02.2016 31.01.2018
01.03.2017 01.02.2016 31.01.2018
21.08.2017 01.02.2016 31.01.2018
21.08.2017 01.02.2016 31.01.2018
01.09.2017 01.02.2016 31.01.2018
03.05.2017 01.02.2016 31.01.2018
18.09.2017 01.02.2016 31.01.2018
18.09.2017 01.02.2016 31.01.2018
29.09.2017 01.02.2016 31.01.2018
01.06.2017 01.02.2016 31.01.2018
18.10.2017 01.02.2016 31.01.2018
18.10.2017 01.02.2016 31.01.2018
31.10.2017 01.02.2016 31.01.2018
21.08.2017 01.02.2016 31.01.2018
18.12.2017 01.02.2016 31.01.2018
18.12.2017 01.02.2016 31.01.2018
05.01.2018 01.02.2016 31.01.2018
05.09.2017 01.02.2016 31.01.2018
18.01.2018 01.02.2016 31.01.2018
18.01.2018 01.02.2016 31.01.2018
31.01.2018 01.02.2016 31.01.2018
09.05.2017 02.05.2017 31.05.2018
24.05.2017 02.05.2017 31.05.2018
01.07.2017 02.05.2017 31.05.2018
11.05.2017 02.05.2017 31.05.2018
04.09.2017 02.05.2017 31.05.2018
18.09.2017 02.05.2017 31.05.2018
30.10.2017 02.05.2017 31.05.2018
05.09.2017 02.05.2017 31.05.2018
02.10.2017 02.05.2017 31.05.2018
16.10.2017 02.05.2017 31.05.2018
30.11.2017 02.05.2017 31.05.2018
03.10.2017 02.05.2017 31.05.2018
01.11.2017 02.05.2017 31.05.2018
15.11.2017 02.05.2017 31.05.2018
31.12.2017 02.05.2017 31.05.2018
02.11.2017 02.05.2017 31.05.2018
08.01.2018 02.05.2017 31.05.2018
22.01.2018 02.05.2017 31.05.2018
28.02.2018 02.05.2017 31.05.2018
09.01.2018 02.05.2017 31.05.2018
01.02.2018 02.05.2017 31.05.2018
15.02.2018 02.05.2017 31.05.2018
31.03.2018 02.05.2017 31.05.2018
02.02.2018 02.05.2017 31.05.2018
31.05.2018 02.04.2018 31.05.2018
31.05.2018 02.04.2018 31.05.2018
Side 96 av 111
Avtalens punkt 6.2 Dagbot ved forsinkelse
Ingen krav utover avtalens punkt 6.2. Forsinkelsesdato knyttes til MP14 i prosjektets milepælsplan.
Side 97 av 111
Bilag 5: Godkjenningsprøve
Avtalens punkt 2.2.2 Undersøkelsesplikt
I bilag 1 punkt 2.2.2, angir Oslo kommune hva som skal inngå godkjenningsprøven. I tabellen GJ12:
krav til gjennomføring, har vi krav om at leverandørens skal bidra i både planlegging av test og
utarbeide testplaner. Detaljene i hva som skal testes vil materialisere seg gjennom arbeid med
testplaner. Oslo kommune opprettholder de definisjoner av feil som fremgår av avtalens punkt 2.2.2
Det skal gjennomføres en godkjenningsprøve/akseptansetest med fokus på funksjonalitet og ytelse
av selve løsningen, men også av migrering av data fra dagens løsninger, import av brukere/roller og
organisasjonsstruktur, samt Single sign-on og Exchange integrasjon. Testene skal gjennomføres i Fase
4 oppsett, installering og test (ref. bilag 4).
Testen skal først gjennomføres i kundens test-miljø, deretter gjennomføres samme test i
produksjonsmiljøet. Det vil være pilotvirksomhet som danner grunnlag for test i produksjonsmiljø.





Leverandøren skal bistå i planlegging av akseptansetest og foreslå testhendelser som kan
benyttes i Kundens akseptansetest.
Leverandøren skal sette opp testmiljø, i samarbeid med Oslo kommune.
Leverandøren skal lære opp Kundens testbrukere.
Leverandøren skal skaffe testdata i den grad det er nødvendig for å gjennomføre en
tilfredsstillende testing av systemet.
Leverandøren skal dele testlogger med Kunden; testhendelser, antall feil og kategori av feil
som er avdekket igjennom Leverandørens testing.
Systemtest:
Figur 3: forslag til overordnet testplan – testmiljø
Forslag til deltagere:
Leverandør, prosjektets testressurser
Side 98 av 111
Akseptansetest:
Figur 4: forslag til overordnet testplan – preprod og produksjonsmiljø
Forslag til deltagere:
Leverandør, prosjektets testressurser og testressurser fra pilot virksomhet.
SLA-krav under testperiode.
SLA-krav angitt i SSA-V avtalen gjelder også testperioden, testperioden er angitt i Fase 4 oppsett,
installering og test (ref. bilag 4).
Bilag 6: Administrative bestemmelser
Avtalen punkt 1.5: Partenes representanter
Bemyndiget representant for partene:
For Kunden
Navn: Roy Bøhmer
Stilling: Seksjonssjef –
Fagsystemavdelingen/Helseetaten
Telefon: Sentralbord 02 180
E-post: [email protected]
For Leverandøren
Navn:
Stilling:
Telefon:
E-post:
Prosedyrer og varslingsfrister for utskiftning av bemyndiget representant:
Skriftlig, med to ukers varsel.
Prosjektorganisering
Prosjektgjennomføringen styres av en prosjektorganisasjon hos Kunden og en hos Leverandøren.
Hos Kunden er prosjektet en del av EHS program for IKT og rapporterer til en styringsgruppe som
følger i henhold til Prosjektveiviseren (se www.prosjektveiviseren.no):
● Prosjekteier representerer virksomhetens interesser. Dette sikrer både legitimitet og kobling
til ledelsen, samt at prosjektet underbygger EHS sine overordnede mål. Prosjekteier er
prosjektets endelige beslutningstaker. Leder for prosjektets styringsgruppe er ansvarlig for at
prosjektets mål og gevinster realiseres.
● Styringsgruppen er ansvarlig for at prosjektets mål og gevinster realiseres
● Seniorbruker representerer brukernes interesser, og er ansvarlig for at brukernes behov blir
innfridd og prosjektets gevinster kan bli realisert.
Side 99 av 111
● Seniorleverandør er ansvarlig for å sikre produktkvalitet, teknisk integritet og vedlikehold av
nytt kvalitetssystem.
● Prosjektleder er ansvarlig for den daglige styringen av prosjektet. Prosjektlederen har
myndighet og ansvar til å lede prosjektet og levere de nødvendige produktene innenfor de
rammer og begrensninger som er definert av styringsgruppen. De påkrevde produktene skal
produseres innenfor de spesifiserte toleransene for tid, kostnad, kvalitet, omfang, usikkerhet
og gevinst. Prosjektlederen har også ansvaret for at prosjektet produserer et resultat som
gjør at gevinstene som er definert for prosjektet kan oppnås.
Det er en fast rapporteringsfrekvens, månedlig (eller etter behov), til program for IKT i EHS og
prosjektets styringsgruppe med tilhørende møter.
Kundens prosjektorganisering:
Figur 5: kundens prosjektorganisering
Leverandøren beskriver sin prosjektorganisering og hvordan Leverandøren foreslår at samarbeidet
mellom Kunde og Leverandør organiseres:
Side 100 av 111
Krav til leverandørens ressurser og kompetanse
Det er gjennom Bilag 1 spesifisert krav til Leverandørens gjennomføring og kompetanse som skal
besvares i tabellen nedenfor:
Leverandørens nøkkelpersonell:
Navn:
Stilling/rolle:
Telefon:
E-post:
Bruk av underleverandør
Leverandøren fyller ut godkjente underleverandører hvis aktuelt:
Navn:
Org.nr.:
Leveranseområde
Samarbeid med tredjepart
Leverandøren fyller ut hvis aktuelt:
Omfang av bistand:
Avtalt vederlag:
(Fylles ut dersom det er avtalt særlig vederlag for samarbeid med tredjepart)
Kundens ansvar og medvirkning
Leverandøren spesifiserer krav til Kundens kompetanse og deltakelse i prosjektperioden (unntatt
Kundens akseptansetest):
Kompetanseområde
Antall timer i prosjektperioden
Leveranseområde
Bruk av tredjepart
Kundens valgte tredjeparter til bistand i forbindelse med sine oppgaver under avtalen:
Oslo kommunes til hver tid gjeldende driftsleverandør/er
Side 101 av 111
Møter
Avtalte innkallinger, underlag og referater fra møter skal gjøres tilgjengelige for Kunde og
Leverandør.
Avtalens punkt 2.4 Lønns- og arbeidsvilkår
«For avtaler som omfattes av forskrift 8. februar 2008 nr. 112 om lønns- og arbeidsvilkår i offentlige
kontrakter gjelder følgende:
Leverandør og underleverandører plikter å ha lønns- og arbeidsvilkår som ikke er dårligere enn det
som følger av arbeidsmiljølovgivning, gjeldende allmenngjøringsforskrifter eller gjeldende
landsomfattende tariffavtale for den aktuelle bransje. Dette gjelder bare for arbeidstakere som
direkte medvirker til oppfyllelse av Leverandørs forpliktelser under avtalen.
Leverandør plikter å ha tilsvarende kontraktsbestemmelse i sine kontrakter med underleverandører
og skal gjennomføre nødvendig kontroll hos sine underleverandører for å påse at plikten overholdes.
Dersom det er grunn til å tro at kravet til lønns- og arbeidsvilkår ikke etterleves, har Oppdragsgiver
rett til å holde tilbake deler av kontraktssummen til det er dokumentert at forholdet var, eller er
brakt, i orden. Summen som blir holdt tilbake skal tilsvare ca. 2 ganger besparelsen for
arbeidsgiveren.
Oppdragsgiver har rett til innsyn i dokumenter og rett til å foreta andre undersøkelser som gjør det
mulig for Oppdragsgiver å gjennomføre nødvendig kontroll med at kravet til lønns- og arbeidsvilkår
overholdes. Leverandør plikter på oppfordring å legge frem slik etterspurt dokumentasjon.
Dokumentasjonsplikten omfatter også underleverandører.
Brudd på plikter etter denne bestemmelsen som ikke er av ubetydelig karakter gir Oppdragsgiver rett
til å heve kontrakten. Selv om Leverandør retter ovenfor arbeidstakerne, er ikke det til hinder for at
Oppdragsgiver kan heve.
Oppfyllelse av Leverandørens forpliktelser som nevnt ovenfor skal dokumenteres på forespørsel ved
enten en egenerklæring eller tredjepartserklæring om at det er samsvar mellom aktuell tariffavtale
og faktiske lønns- og arbeidsvilkår for oppfyllelse av Leverandørens og eventuelle
underleverandørers forpliktelser.»
Bilag 7: Samlet pris og prisbestemmelser
Priser skal oppgis i tabellene under. Det er verdt å merke seg at i pristabellene refereres det til
tabeller og kapitler andre steder i bilagene for ytelser som skal prises.
Oppstartskostnader
Se bilag 1, 1.5.2 Tildelingskriteriet Pris, lisenskostnader, underpunkt A, B og C for nærmere
beskrivelse.
Side 102 av 111
Oppstartskostnader - vektes 15%
Ytelse:
Installasjon og tilrettelegging
 Tildelingskriteriet Pris, kap. 1.5.2
bilag 1 (Punkt A og B)
 Krav GJ 12.1 i kravtabell GJ12:
krav til gjennomføring (bilag 1)
Fast pris (NOK)
Mva.
Total
Pris pr. bruker
(NOK)
Mva.
Totalt
Pris pr. bruker
(NOK)
Mva.
Totalt
1)
Opplæring superbruker, ref.
Tildelingskriteriet Pris, kap. 1.5.2 bilag 1
(Punkt C)
2)
Opplæring systemadministrator ref.
Tildelingskriteriet Pris, 1 kap. 1.5.2 bilag
(Punkt C)
Tabell P1: Oppstartskostnader
1)
Opplæring skal prises for superbruker basert på klasseromsundervisning for inntil 15 personer.
Roller og krav er spesifisert i punkt 2.1.4 bilag 1. Oslo kommune er ansvarlig for å fremskaffe
undervisningslokaler og administrere påmelding.
2)
For rollen systemadministrator oppgis prisene for undervisning pr. bruker.
Lisenskostnader
Oslo kommune ønsker at leverandørene priser lisenser basert på en årlig kostnad pr. bruker pr. år.
Det vil si at vi ønsker samme pris pr. bruker pr. år i 2017 som siste år av avtalen, med tillegg for
prisendringer i henhold til avtalen punkt 3.5 Prisendringer i dette bilaget. Vedlikehold og brukerstøtte
skal inngå i lisenskostnadene. Krav i forhold til brukerstøtte og vedlikehold reguleres i SSA-V med
bilag.
Se bilag 1, 1.5.2 Tildelingskriteriet Pris, lisenskostnader, underpunkt D og E for nærmere beskrivelse.
Lisenser - vektes 75%
Ytelse:
Pris pr. bruker pr.
år (NOK)
Mva.
Total
Basisfunksjonalitet (punkt D)
ROS (punkt E)
Årshjul (punkt E)
Mobilitet (punkt E)
Tabell P2: lisenskostnader
Ved evaluering vil pris pr. bruker bli ganget med en faktor på 10 som er livsløpskostnadene og med
lavest estimert antall i Tabell omfang: oversikt over omfang, kap. 1.2.1 Hovedleveransen.
Tilleggslisenser basert på organisk vekst
Oslo kommune forventer at pris på lisenskostnader basert på organisk vekst prises i henhold til
tallene i tabell P2: lisenskostnader.
Side 103 av 111
Lisensomfang
Prosjektet vil i samarbeid med leverandøren i fase 4, Oppsett, installering og test fastsette
totalomfanget for EHS basert på uttrekk fra PRK/opptelling av brukere i løsningen. Denne vil danne
grunnlag for totalomfanget av lisenser og utløse betaling i henhold til tabell MP1: milepæler.
Som grunnlag for betaling fra 2019 og påfølgende år vil det gjøres et uttrekk fra PRK/opptelling av
brukere i løsningen pr. 1. juni hvert år som vil være grunnlag for totalomfanget av lisenser dette året.
Leverandøren må påregne justering av antall lisenser som resultat av omorganisering i Oslo
kommune. En eventuell omorganisering vil kunne resultere i en økning av lisensomfanget så vel som
en reduksjon.
Oslo kommune forventer at det ikke vil bli fakturert for lisenser i andre miljøer en produksjon (f.eks
test og/eller kurs).
Opsjoner
Se bilag 1, 1.5.2 Tildelingskriteriet Pris, lisenskostnader, underpunkt F for nærmere beskrivelse.
Opsjoner - vektes 10%
Ytelse:
Tilrettelegning av systemet for nye
virksomheter (punkt F)
Tabell P3: Opsjoner
Fast pris (NOK)
Mva.
Total
Kjøp av lisenser basert på utløsning av opsjoner
Oslo kommune forventer at pris på lisenskostnader basert på utløsning av opsjoner i avtalen prises i
henhold til tallene i tabell P2: lisenskostnader.
Pris på opplæring basert på utløsning av opsjoner
Oslo kommune forventer at prisene på opplæring følger prisene oppgitt i tabell P1:
oppstartskostnader.
Øvrig funksjonalitet
Dersom leverandøren ønsker å tilby øvrig funksjonalitet eller tjenester som ikke inngår i kravene til
denne avtalen, kan det spesifiseres i tabellen under. Øvrig funksjonalitet eller tjenester vil ikke bli
evaluert eller vektet.
Se bilag 1, 1.5.2 Tildelingskriteriet Pris, lisenskostnader, underpunktene G og H for nærmere
beskrivelse.
Øvrig funksjonalitet – evalueres ikke
Ytelse:
Pris pr. bruker pr.
år (NOK)
Mva.
Total
Side 104 av 111
Ytelse
Fast pris
Mva.
Total
Tabell P4: Øvrig funksjonalitet
Avtalens punkt 2.1.2 Tilpasninger og installasjon mv
Det er i tabell GJ12: Krav til gjennomføring, stilt krav til leverandøren om hvilke områder Oslo
kommune ønsker bistand til i forbindelse med tilrettelegging av Single sign-on, Exchange integrasjon,
PRK import, migrering samt testing av disse områdene. I tabellen under skal leverandøren fylle inn
timepriser for aktuelle ressurser.
Oslo kommune forventer at leverandørene overholder gjeldene markedspris for konsulenttjenester.
Eksempel på pristabell for Leverandørens standard timepris for konsulenttjenester:
Beskrivelse
Timepris eks. mva.
Konsulentnivå 3 (Konsulent med mer enn 8 års
relevant erfaring)
Konsulentnivå 2 (Konsulent med mer enn 4 og mindre
enn 8 års relevant erfaring)
Konsulentnivå 1 (Konsulent med inntil 4 års relevant
erfaring)
Tabell P5: Konsulenttjenester
Satser for reise- og diettkostnader:
Oppgitte timepriser skal være inkludert alle Leverandørens kostnader for reise- og diett.
Avtalens punkt 2.1.4 Dokumentasjon og opplæring
Opplæringskostnader skal oppgis i tabell P1:Oppstartskostnader og tabell P3: Opsjoner i dette bilaget.
Avtalens punkt 2.1.6 Garantiperiode og garantiytelser
Oslo kommune har ingen krav utover det som står i avtalens punkt 2.1.6.
Avtalens punkt 3.1 Vederlag
Utgangspunktet er at prisene oppgis i norske kroner og eksklusiv merverdiavgift. Annet må
spesifiseres særskilt.
Avtalens punkt 3.2 Faktureringstidspunkt og
betalingsbetingelser
Betalingsplan skal gjenspeile prosjektets milepæler og fremdrift som omfatter milepælene i tabellen
under.
Milepæl
Leverandørens forslag til fakturering
MP 4 Avtalen er signert
Oppstartskostnader
Side 105 av 111
MP 14 Når test i produksjonsmiljø er
godkjent
MP 52 Når system er i stabil drift for pulje
1( 13 bydeler)
2 (HEL)
3 (BGA, BSN)
4 (VEL)
5 (BFE, OVK, EHS)
Tabell MP1: Milepæler
30 % av lavest estimert omfang lisenser
EHS - basisfunksjonalitet
Oslo kommune ønsker at fakturering av lisenser skjer en gang pr. år med forfall 1/7 fra og med 2019.
For 2017 og 2018 gjelder:
For 2017 - fakturering i henhold til milepæl MP 14, MP 52, MP 56, MP 60.
For 2018 - fakturering i henhold til MP64, MP 68 og lisenser knyttet til 80% av det totale
lisensomfang (kjøpt 2017).
Som grunnlag for betaling fra 2019 og påfølgende år vil det gjøres et uttrekk fra PRK pr. 1. juni hvert
år som vil være grunnlag for totalomfanget av lisenser dette året
Tabellen under fremstiller det som er beskrevet over.
2017
2018
Oppstartskostnader
x
Lisenskostnader
MP 14, MP 52, MP 56,
MP 64, MP 68 + kjøp
MP60
2017 (M 52,M 56, M 60)
2019
Alle lisenser baser
på PRK uttrekk pr.
1. juni
Fakturering av lisenser for ROS, Årshjul skjer i henhold til puljeplanens bestilling og faktura knyttes til
overnevnte milepæler, ref. tabell M1:milepæler. Enkelte virksomheter implementerer ROS og Årshjul
høsten 2018 og kan faktureres ved oppstart av disse.
Implementering av mobilitet planlegges høsten 2018 og kan faktureres ved oppstart.
For konsulenttjenester knyttet til teknisk implementering som migrering, Single sign-on og PRKimport gjelder time for time fakturering basert på innleverte og godkjente timelister til prosjektet.
Betaling skjer etterskuddsvis pr. 30 dager.
Øvrige betalingsvilkår:
Leverandøren plikter å tilby elektroniske fakturaer i Elektronisk handelsformat (EHF) fra dato for
kontraktsinngåelse. Som Leverandør må det inngås en egen avtale med et aksesspunkt.
Dersom Leverandøren ikke oppfyller kravet til e-faktura påløper et gebyr pålydende kroner 100,- per
faktura Kunden mottar på papir. Det skal utstedes månedlig kreditnota pålydende kroner 100,- for
hver faktura Kunden mottar på papir.
Faktura sendes til:
Oslo Kommune Fakturasentralen
Helseetaten
Postboks 6532 Etterstad
0606 OSLO
Side 106 av 111
Faktura skal merkes med:
Ressursnummer: 44970216
Avtalens punkt 3.5 Prisendringer
Lisenskostnader og timepriser kan endres ved hvert årsskifte tilsvarende økningen i Statistisk
sentralbyrås konsumprisindeks (hovedindeksen), første gang med utgangspunkt i indeksen for den
måned avtalen ble inngått.
Bilag 8: Endringer i den generelle avtaleteksten
Punkt i avtalen
Erstattes med
Brudd på skatte- og avgiftsforpliktelser
«Leverandøren og eventuelle underleverandører skal til enhver tid
oppfylle sine forpliktelser til å betale skatter og/eller avgifter.
Oppdragsgiver kan til enhver tid foreta kontroll av Leverandøren og
eventuelle underleverandørers oppfyllelse av forpliktelser til å
betale skatter og/eller avgifter.
Dersom Leverandøren i ikke uvesentlig grad misligholder sine
forpliktelser til å betale skatter og/eller avgifter, kan
Oppdragsgiver, etter at Leverandøren er gitt en frist til å rette, heve
kontrakten. Dersom Leverandøren vesentlig misligholder sine
forpliktelser til å betale skatter og/eller avgifter kan Oppdragsgiver
heve kontrakten uten at Leverandøren er gitt en frist til å rette.
Retten til å heve gjelder ikke dersom kravet formelt er bestridt
overfor kompetent myndighet og Leverandøren overfor
Oppdragsgiver kan sannsynliggjøre at kravet ikke er berettiget.
Dersom Leverandørens underleverandører i ikke uvesentlig grad
misligholder sine
forpliktelser til å betale skatter og/eller avgifter, kan
Oppdragsgiver, etter at underleverandøren er gitt en frist til å
rette, kreve at Leverandøren snarest mulig skifter ut sin
underleverandør, uten kostnad for Oppdragsgiver. Retten til å
kreve utskifting gjelder ikke dersom kravet er formelt bestridt
overfor kompetent myndighet, og Leverandøren overfor
Oppdragsgiver kan sannsynliggjøre at kravet mot
underleverandøren ikke er berettiget. Dersom Leverandøren ikke
skifter ut underleverandørsom den er forpliktet til å skifte ut, kan
Oppdragsgiver heve avtalen.»
Brudd på konkurranselovgivningen
«Dersom det er klar sannsynlighetsovervekt for at Leverandøren
Side 107 av 111
har brutt konkurranselovens §§ 10 eller 11 eller tilsvarende
bestemmelser, kan Oppdragsgiver heve kontrakten dersom dette
etter en konkret vurdering anses for å være forholdsmessig.
Dersom det er klar sannsynlighetsovervekt for at Leverandørens
underleverandør har brutt konkurranselovens §§ 10 eller 11 eller
tilsvarende bestemmelser kan Oppdragsgiver kreve at
Leverandøren snarest mulig skifter ut sin underleverandør, uten
kostnad for Oppdragsgiver. Retten til å kreve utskifting gjelder ikke
dersom kravet er formelt bestridt overfor kompetent myndighet,
og Leverandøren overfor Oppdragsgiver kan sannsynliggjøre at
kravet mot underleverandøren ikke er berettiget. Dersom
Leverandøren ikke skifter ut underleverandør som den er forpliktet
til å skifte ut, kan Oppdragsgiver heve avtalen.
Før heving etter første ledd og før krav om utskiftning av
underleverandør i annet ledd skal oppdragiver vurdere den tid som
er gått siden bruddet på konkurranselovens §§ 10 eller 11 ble
begått, hvilke selfcleaningstiltak som er iverksatt fra Leverandøren
eller underleverandørens side og eventuelt andre momenter som
kan ha betydning for vurderingen av om hevingen eller
utskiftningen er forholdsmessig. Dersom bruddet på
konkurranselovgivningen direkte har rammet eller berørt Oslo
kommune, vil heving alltid anses å være forholdsmessig.»
Side 108 av 111
Avtalens punkt 2.4 Lønnsog arbeidsvilkår utgår og
erstattes med følgende
tekst
«For avtaler som omfattes av forskrift 8. februar 2008 nr. 112 om
lønns- og arbeidsvilkår i offentlige kontrakter gjelder følgende:
Leverandør og underleverandører plikter å ha lønns- og
arbeidsvilkår som ikke er dårligere enn det som følger av
arbeidsmiljølovgivning, gjeldende allmenngjøringsforskrifter eller
gjeldende landsomfattende tariffavtale for den aktuelle bransje.
Dette gjelder bare for arbeidstakere som direkte medvirker til
oppfyllelse av Leverandørs forpliktelser under avtalen.
Leverandør plikter å ha tilsvarende kontraktsbestemmelse i sine
kontrakter med underleverandører og skal gjennomføre nødvendig
kontroll hos sine underleverandører for å påse at plikten
overholdes.
Dersom det er grunn til å tro at kravet til lønns- og arbeidsvilkår
ikke etterleves, har Oppdragsgiver rett til å holde tilbake deler av
kontraktssummen til det er dokumentert at forholdet var, eller er
brakt, i orden. Summen som blir holdt tilbake skal tilsvare ca. 2
ganger besparelsen for arbeidsgiveren.
Oppdragsgiver har rett til innsyn i dokumenter og rett til å foreta
andre undersøkelser som gjør det mulig for Oppdragsgiver å
gjennomføre nødvendig kontroll med at kravet til lønns- og
arbeidsvilkår overholdes. Leverandør plikter på oppfordring å legge
frem slik etterspurt dokumentasjon. Dokumentasjonsplikten
omfatter også underleverandører.
Brudd på plikter etter denne bestemmelsen som ikke er av
ubetydelig karakter gir Oppdragsgiver rett til å heve kontrakten.
Selv om Leverandør retter ovenfor arbeidstakerne, er ikke det til
hinder for at Oppdragsgiver kan heve.
Oppfyllelse av Leverandørens forpliktelser som nevnt ovenfor skal
dokumenteres på forespørsel ved enten en egenerklæring eller
tredjepartserklæring om at det er samsvar mellom aktuell
tariffavtale og faktiske lønns- og arbeidsvilkår for oppfyllelse av
Leverandørens og eventuelle underleverandørers forpliktelser.»
Nytt punkt
Nytt punkt
Ved vesentlig mislighold av kjøpsavtalen har oppdragsgiver også
rett til å heve vedlikeholdsavtalen
Avtalen skal gjelde i 10 år fra kontraktsignering, med opsjon på
forlengelse i 2+2 år.
Kunde kan når det foreligger saklig grunn si opp avtalen med 6
måneders varsel.
Leverandøren kan når det foreligger saklig grunn si opp avtalen
med 12 måneders varsel, men først etter 6 år.
Side 109 av 111
Bilag 9: Endringer av leveransen etter
avtaleinngåelsen
Eksempel på endringskatalog:
Endringsnr.
Beskrivelse
Ikraftsettelsesdato
Arkivreferanse
Bilag 10: Lisensbetingelser for
standardprogramvare og fri programvare
Avtalens punkt 2.1.3 Forholdet til standard lisens- og
avtalevilkår
I den utstrekning standardprogramvare som er omfattet av leveransen må leveres under standard
lisensbetingelser, skal dette være uttrykkelig angitt i et eget kapittel i bilag 2 og kopier av lisensbetingelsene
skal være vedlagt her.
Dersom fri programvare skal benyttes i forbindelse med leveransen, skal Leverandøren utarbeide en
oversikt over den aktuelle frie programvare. Oversikten inntas i et eget kapittel i bilag 2. Kopi av de
lisensbetingelsene som gjelder for den aktuelle frie programvare inntas i bilag 10.
Side 110 av 111

IKT-verktøy for Kvalitetsstyring og internkontrollsystem Bilag

Transcription

Similar documents

Reiseregning - Ringerike kommune

Samlet oversikt over nye tabeller etter mellomoppgjøret 2015

Refusjon div. utlegg privat for LAR NETT NORGE.

Last ned PDF her

Vedlikeholdsavtalen (SSA-V) Bilag 4: Prosjekt

Forslag til oppsett av økonomiperm

Oversikt over standarder for kvalitetsstyring per