IKT-verktøy for Kvalitetsstyring og internkontrollsystem Bilag
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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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. Sektoren består ved siden av byrådsavdelingen også av Beredskapsetaten, Brann- og redningsetaten, Bymiljøetaten, Energigjenvinningsetaten, Renovasjonsetaten, Vann- og avløpsetaten samt Oslo Havn KF. 2.255 Kultur,frivillighet og idrett (KFI) Sektoren består ved siden av byrådsavdelingen også av 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. Sektoren består ved siden av byrådsavdelingen også av 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». 1.4 Kundens krav til leveransen I Leverandørenes besvarelse (Bilag 2) skal kravene dokumenteres slik det fremgår av krav til dokumentasjon i kravtabellene. 1.5 Kundens krav til leveransen 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Avviksrapportering og avvikshåndtering Innledende tekst til tabell (Oslo kommunes krav fremkommer av tabellene): 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 hvilke løsninger de 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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, eiendom- og 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 Innledende tekst til tabell (Oslo kommunes krav fremkommer av tabellene): 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 hvilke løsninger de 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 hvilke løsninger de 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 Innledende tekst til tabell (Oslo kommunes krav fremkommer av tabellene): 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 hvilke løsninger de har ift varsling. Side 18 av 111 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Risiko og sårbarhetsanalyser Innledende tekst til tabell (Oslo kommunes krav fremkommer av tabellene): 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 hvilke løsninger de 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Innledende tekst til tabell (Oslo kommunes krav fremkommer av tabellene): Å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 hvilke løsninger de 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Krav til gjennomføring Innledende tekst til tabell (Oslo kommunes krav fremkommer av tabellene): 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 Leverandøren skal i samarbeid med Oslo kommune i Fase 4 oppsett, installering og test, (ref. bilag 4) bidra 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 Leverandøren skal i samarbeid med Oslo kommune i Fase 4 oppsett, installering og test, (ref. bilag 4) bidra 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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. Avtalens punkt 4.3 Fri programvare 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 6.3.3 Tilgang til Oslo kommunes konsernnett (OK-MAN) ............................................65 Figuroversikt..................................................................................................................65 Tabelloversikt ................................................................................................................66 Side 31 av 111 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Tabell. 5.3 Sonemodeller Side 61 av 111 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Vedlegg 1, bilag 3: Arkitekturprinsipper i Oslo kommune Side 67 av 111 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 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. 10. Levetid Før implementering av systemer og infrastruktur skal det gjøres en teknologisk og kostnadsmessig levetidsvurdering Side 76 av 111 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Prinsipp 1: Tjenesteorientering IKT-systemer skal bygges opp som en samling avgrensede delsystemer som legger til rette for mest mulig gjenbruk. Hvordan skal prinsippet forstås? • • • • 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. Motivasjon og begrunnelse for 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Prinsipp 2: Interoperabilitet IKT-systemer må kunne utveksle og dele data og informasjon med andre systemer gjennom standardiserte grensesnitt Hvordan skal prinsippet forstås? 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. Motivasjon og begrunnelse for 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Prinsipp 3: Tilgjengelighet Elektroniske brukertjenester skal være universelt utformet, og brukerne skal kunne benytte dem uten hensyn til tid, sted og kanal. Hvordan skal prinsippet forstås? 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. Motivasjon og begrunnelse for 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Prinsipp 4: Sikkerhet Informasjon og tjenester skal tilfredsstille krav til konfidensialitet, integritet og tilgjengelighet. Hvordan skal prinsippet forstås? 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. Motivasjon og begrunnelse for 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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. Hvordan skal prinsippet forstås? Å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ø. Motivasjon og begrunnelse for 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Prinsipp 6: Fleksibilitet IKT-systemene skal være forberedt på endringer i bruk, innhold, organisering, eierskap og infrastruktur Hvordan skal prinsippet forstås? 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 Motivasjon og begrunnelse for 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Prinsipp 7: Skalerbarhet. IKT-løsningene skal være forberedte på endringer i antall brukere, datamengde og levetid for tjenesten Hvordan skal prinsippet forstås? 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 Motivasjon og begrunnelse for 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Prinsipp 8: Helhetlig oversikt Oslo kommune skal alltid ha en oppdatert og helhetlig systemoversikt. Hvordan skal prinsippet forstås? • • • • • 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. Motivasjon og begrunnelse for 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Prinsipp 9: Oppetid, åpningstid og stabilitet Oslo kommunes IKT-systemer og -infrastruktur skal oppfylle definerte krav til oppetid, åpningstid og stabilitet Hvordan skal prinsippet forstås? • • • 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. Motivasjon og begrunnelse for 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Prinsipp 10: Levetid Før implementering av systemer og infrastruktur skal det utføres en teknologisk og kostnadsmessig levetidsvurdering Hvordan skal prinsippet forstås? 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. Motivasjon og begrunnelse for 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Systemeiere, IKTansvarlige Godkjenner FIN Systemeiere, IKTansvarlige Systemeiere, IKTansvarlige FIN Virksomhetsledere, Systemeiere, IKTansvarlige 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Vedlegg 2, bilag 3: Godkjente produkter Side 92 av 111 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Virtuell infrastruktur Citrix NetScaler VPX 10 - Enterprise edition Godkjent til dato januar 2020 Fornyes årlig Clusterware 11.2 Oracle databasehotell desember 2018 Clusterware 12.1 Oracle databasehotell 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 MS SQL databasehotell juni 2022 MS SQL Server 2014 MS SQL databasehotell juli 2024 MySQL / MariaDB Sentrale basistjenester tba MySQL 5.5.44 Applikasjonshotell desember 2018 Oracle databasemotor til 11.2 Oracle databasehotell desember 2020 Oracle databasemotor til 12.x Oracle databasehotell juli 2021 Oracle db v.11.2 Oracle databasehotell desember 2016 Oracle db v.12.1 Oracle databasehotell juli 2021 PostgreSQL Sentrale basistjenester 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 Virtuell infrastruktur 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll Universaldriver OCE Periferiutstyr tba Universaldriver Richo Periferiutstyr tba Universaldriver Xerox Periferiutstyr tba VMware ESXi 5.5 Virtuell infrastruktur august 2018 VMware ESXi 6.0 Virtuell infrastruktur mars 2020 VMware vRealize Cloud Management plattform Virtuell infrastruktur tba vSphere Enterprise+ tba WIN CE 6.0 Sentrale basistjenester april 2018 WIN Embedded Standard Sentrale basistjenester 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 Virtuell infrastruktur 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Gjennomføre anskaffelsen Gjennomføre anskaffelsen Gjennomføre anskaffelsen Kontraktsoppfølging Oppsett, installering og test Oppsett, installering og test Oppsett, installering og test Oppsett, installering og test Oppsett, installering og test Oppsett, installering og test Oppsett, installering og test Oppsett, installering og test Oppsett, installering og test Opprette felles forvaltning for EHS Opprette felles forvaltning for EHS Etablere felles kvalitetssytem for EHS Etablere felles kvalitetssytem for EHS Etablere felles kvalitetssytem for EHS Metode for forberedelser, mottak og realisering Metode for forberedelser, mottak og realisering Metode for forberedelser, mottak og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Forberede systeminnføring og realisering Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning Realisering og overføring til systemforvaltning 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 oppstart med virksomhetenes mottaksprosjekt er gjennomført- pulje 2 Når ledelsesgjennomgang i virksomheten er gjennomført- pulje 2 Når superbrukere i virksomheten er lært opp- pulje 2 Når virksomhetene er klar for realisering- pulje 2 Når oppstart med virksomhetenes mottaksprosjekt er gjennomført- pulje 3 Når ledelsesgjennomgang i virksomheten er gjennomført- pulje 3 Når superbrukere i virksomheten er lært opp- pulje 3 Når virksomhetene er klar for realisering- pulje 3 Når oppstart med virksomhetenes mottaksprosjekt er gjennomført- pulje 4 Når ledelsesgjennomgang i virksomheten er gjennomført- pulje 4 Når superbrukere i virksomheten er lært opp- pulje 4 Når virksomhetene er klar for realisering- pulje 4 Når oppstart med virksomhetenes mottaksprosjekt er gjennomført- pulje 5 Når ledelsesgjennomgang i virksomheten er gjennomført- pulje 5 Når superbrukere i virksomheten er lært opp- pulje 5 Når virksomhetene er klar for realisering- pulje 5 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 systeminnføring og migrering er gjennomført for pulje 2 Når systemet er i stabil drift for pulje 2 Når opplæring er gjennomført for pulje 2 Når pulje 2 er overført til systemforvaltning Når systeminnføring og migrering er gjennomført for pulje 3 Når systemet er i stabil drift for pulje 3 Når opplæring er gjennomført for pulje 3 Når pulje 3 er overført til systemforvaltning Når systeminnføring og migrering er gjennomført for pulje 4 Når systemet er i stabil drift for pulje 4 Når opplæring er gjennomført for pulje 4 Når pulje 4 er overført til systemforvaltning Når systeminnføring og migrering er gjennomført for pulje 5 Når systemet er i stabil drift for pulje 5 Når opplæring er gjennomført for pulje 5 Når pulje 5 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll ● 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll MP 14 Når test i produksjonsmiljø er godkjent MP 52 Når system er i stabil drift for pulje 1( 13 bydeler) MP 56 Når system er i stabil drift for pulje 2 (HEL) MP 60 Når system er i stabil drift for pulje 3 (BGA, BSN) MP 64 Når system er i stabil drift for pulje 4 (VEL) MP 68 Når system er i stabil drift for pulje 5 (BFE, OVK, EHS) Tabell MP1: Milepæler 30 % av lavest estimert omfang lisenser EHS - basisfunksjonalitet 30 % av lavest estimert omfang lisenser EHS - basisfunksjonalitet 10 % av lavest estimert omfang lisenser EHS - basisfunksjonalitet 10 % av lavest estimert omfang lisenser EHS - basisfunksjonalitet 10 % av lavest estimert omfang lisenser EHS - basisfunksjonalitet 10 % 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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 Veiledende bilag til SSA-K – IKT verktøy for Kvalitetsstyring og internkontroll 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. Avtalens punkt 4.3 Fri programvare 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
© Copyright 2024