Helsebygg Midt-Norge Side: 1 av 21 Tredjepartsverifikasjon IKT Fase 1: Verifikasjon av byggherrens tilbudsgrunnlag utført av Capgemini
Helsebygg Midt-Norge Side: 2 av 21 Versjonshistorie Versjon Dato Endring 0.8 25.8.06 Draft versjon sendt HBMN (KOS) 1.0 30.8.06 Laget sammendrag og liste med forkortelser. Oppdatert etter kommentarer fra HBMN/KOS 1.1 1.9.06 Korrigert kapittel 3.7 etter tilgang på dokumentasjon. Slått sammen 3.9-3.10 og oppdatert etter kommentarer fra HBMN/KOS. 1.2 16.10.06 Mindre oppdateringer etter intern gjennomgang. 1.2a 19.10.06 Oppdatert etter kommentarer fra HBMN (AOS) 1.2b 20.10.06 Mindre oppdateringer etter intern gjennomgang. 1.2c 22.10.06 Oppdatert etter kommentarer fra HBMN 1.2d 01.11.06 Oppdatert etter kommentarer fra HBMN, Spm 9 og 10 behandles samlet etter avtale med HBMN Vurdering i 3.6.1 som ikke gjelder tilbudsfasen er flyttet til rapport for fase 2 kap. 3.3 Gjennomgang Dato Navn Rolle 29.8.06 Karl Oscar Sandvik (KOS) HMS- og kvalitetssjef HBMN 30.8.06 Karl Oscar Sandvik (KOS) HMS- og kvalitetssjef HBMN 18.10.06 Arve-Olav Solumsmo Informasjonssjef HBMN 20.10.06 Børge Godhavn Prosjektleder HBMN 20.10.06 Tore Indreråk IKT sjef HBMN
Helsebygg Midt-Norge Side: 3 av 21 Sammendrag Verifikasjonen tar utgangspunkt i dokument 720-8001 Tredjeparts-verifikasjon IKT, YTELSES- OG RAPPORTERINGSSPESIFIKASJON av 29/6-06, oppdatert 4/8-06. Verifikasjonen har fokus på B6 Datanett som er et underpunkt til 720 5002 Infrastruktur for IKT og St. Olavs Hospital som er den brukeren med størst krav til datanettet. (Forkortelser er definert i kapittel 1.1.) I sammendraget er svarene gitt på kortform med symboler etter følgende skala: - Ingen avvik - Mindre avvik - Større avvik I fase 1 (av 3) besvares følgende spørsmål, knyttet til verifikasjon av byggherrens tilbudsgrunnlag: 1. Var ambisjonsnivået i visjon/strategi for omfattende i forhold til det som er teknisk mulig? Svar: Ambisjonsnivået i visjon/strategi var ikke for omfattende i forhold til det som var teknisk mulig. 2. Gjenspeilte visjon/strategi tilsvarende visjon og strategi for St. Olavs Hospital? Svar: Visjon/strategi gjenspeilte tilsvarende visjon og strategi for St. Olavs Hospital. 3. Var spesifikasjonene entydige og klar nok? Svar: Vi har funnet krav som kunne vært nærmere presisert, dette bl.a. begrunnet i besvarelsen fra leverandøren. 4. Stemte spesifikasjonen med det som er nedfelt i visjon og strategi? Svar: I hovedsak er det overensstemmelse mellom spesifikasjonen og visjon og strategi. Spesifikasjonen forutsetter nettverksutstyr som rutere og kjernesvitsjer fra Cisco. Konsekvensen av dette er bl.a. at en alvorlig programvarefeil i en kjernesvitsj levert av Cisco kan gi alvorlige driftforstyrrelser i nettverket. 5. Var de innledende føringer på funksjonalitet forenlig med tilgjengelig teknologi og kompetanse? Svar: De innledende føringer på funksjonalitet slik disse fremkommer i B6 var forenlig med tilgjengelig teknologi i denne fasen av prosjektet. Etter vår mening burde det reises tvil om de innledende føringer på funksjonalitet slik disse fremkommer i B6 var forenlig med tilgjengelig kompetanse i denne fasen av prosjektet.
Helsebygg Midt-Norge Side: 4 av 21 6. 1) Ble risiko og sårbarhet vurdert, kompensert og godt nok ivaretatt, og 2) ble failover og alternative løsninger vurdert for å eventuelt kompensere for situasjoner der datanettet ikke fungerer tilfredsstillende? Svar 1: Ut fra tilgjengelig dokumentasjon kan vi ikke se at ROS for teknisk løsning har vært systematisk gjennomført og fulgt opp i tilbudsfasen. Svar 2: Det ble tatt høyde for å benytte alternative løsninger for eventuelt å kompensere for situasjoner der datanettet ikke fungerer tilfredsstillende. 7. Var dette (ROS-analyser) godt nok kommunisert til beslutningstakerne da beslutninger om datanettet ble fattet? Svar: Beslutning om valg av løsning (kravspesifikasjon) for datanettet ble tatt uten at det var gjort formelle ROS-analyser. Beslutningstakerne ved Prosjektstyret fikk presentert overordnede risikobetraktninger med forslag til risikoreduserende tiltak. Vi vurderer det slik at beslutningsgrunnlaget ikke var fullstendig, men at man ved de foreslåtte tiltakene (bl.a. Proof of concept, Fall back) kunne argumentere for beslutningen ved at man utsetter vurdering av risiko for løsningen til et senere tidspunkt. 8. Var visjonen for datanettleveransen avstemt med sannsynlig virkelighet på det tidspunktet det skulle tas i bruk av sykehuset? Svar: Visjonen for datanettleveransen var avstemt med sannsynlig virkelighet på det tidspunktet det skulle tas i bruk av sykehuset. 9. Var det hensiktsmessig å benytte en totalentreprise kontraktsform i dette prosjektet, og hvilke fordeler og ulemper ga kontraktsformen for dette prosjektet? Ble det introdusert risikoer gjennom kontraktsformen? Svar: Det er etter vår vurdering optimalt å benytte en samordnet entreprisemodell for å plassere alt ansvar hos en leverandør, gitt kompleksiteten og mangfoldet av IKT-systemene som skulle leveres og som skulle integreres med eksisterende IKT-system. Det er etter vår oppfatning også en klok avgjørelse å la samme entreprenør få ansvaret for driften. Vi mener at kontraktsformen muliggjør introduksjon av enkelte risikoer, selv om det ikke er avdekket noen avvik i prosjektet.
Helsebygg Midt-Norge Side: 5 av 21 Innhold 1. Innledning...6 1.1 Forkortelser...7 2. Fremgangsmåte...8 3. Spørsmål i fase 1...9 3.1 Var ambisjonsnivået i visjon/strategi for omfattende i forhold til det som er teknisk mulig?...9 3.2 Gjenspeilte visjon/strategi tilsvarende visjon og strategi for St. Olavs Hospital?...10 3.3 Var spesifikasjonene entydige og klar nok?...11 3.4 Stemte spesifikasjonen med det som er nedfelt i visjon og strategi?...13 3.5 Var de innledende føringer på funksjonalitet forenlig med tilgjengelig teknologi og kompetanse?14 3.6 Ble risiko og sårbarhet vurdert, kompensert og godt nok ivaretatt, og ble failover og alternative løsninger vurdert for å eventuelt kompensere for situasjoner der datanettet ikke fungerer tilfredsstillende?...15 3.6.1 Ble risiko og sårbarhet vurdert, kompensert og godt nok ivaretatt?...15 3.6.2 Ble failover og alternative løsninger vurdert for å eventuelt kompensere for situasjoner der datanettet ikke fungerer tilfredsstillende?...18 3.7 Var dette (ROS-analyser) godt nok kommunisert til beslutningstakerne da beslutninger om datanettet ble fattet?...18 3.8 Var visjonen for datanettleveransen avstemt med sannsynlig virkelighet på det tidspunktet det skulle tas i bruk av sykehuset?...19 3.9 Var det hensiktsmessig å benytte en totalentreprise kontraktsform i dette prosjektet, og hvilke fordeler og ulemper ga kontraktsformen for dette prosjektet? Ble det introdusert risikoer gjennom kontraktsformen?...20
Helsebygg Midt-Norge Side: 6 av 21 1. Innledning Verifikasjonen tar utgangspunkt i dokument 720-8001 Tredjeparts-verifikasjon IKT, YTELSES- OG RAPPORTERINGSSPESIFIKASJON av 29/6-06, oppdatert 4/8-06. Helsebygg Midt-Norge ønsker å få verifisert datanettets funksjonalitet og egnethet fra ide og ned til komponenters godhet i den valgte strukturen. For å kunne holde oversikt og fokus gjennom verifiseringen deles oppgaven inn i tre hoveddeler med rapportering for hver del som samles og gis en endelig utforming i felles sluttrapport. Verifikasjonen gjøres i 3 faser: 1. Verifikasjon av byggherrens tilbudsunderlag 2. Verifikasjon av leverandørens design 3. Verifikasjon av leverandørens leveranser Fase 1 Fase 2 Fase 3 Tilbudsfase Designfase Leveransefase Driftsfase Verifikasjonen har fokus B6 Datanett som er et underpunkt til 720 5002 Infrastruktur for IKT og St. Olavs Hospital som er den brukeren med størst krav til datanettet. Det leveres rapport for hver fase. Med fase 1 forstår vi utarbeidelse av forespørsel til og med signering av kontrakt. I fase 1 besvares følgende spørsmål, knyttet til verifikasjon av byggherrens tilbudsgrunnlag: 1. Var ambisjonsnivået i visjon/strategi for omfattende i forhold til det som er teknisk mulig? 2. Gjenspeilte visjon/strategi tilsvarende visjon og strategi for St. Olavs Hospital? 3. Var spesifikasjonene entydige og klar nok? 4. Stemte spesifikasjonen med det som er nedfelt i visjon og strategi? 5. Var de innledende føringer på funksjonalitet forenlig med tilgjengelig teknologi og kompetanse? 6. Ble risiko og sårbarhet vurdert, kompensert og godt nok ivaretatt, og ble failover 1 og alternative løsninger vurdert for å eventuelt kompensere for situasjoner der datanettet ikke fungerer tilfredsstillende? 1 Failover is a backup operational mode in which the functions of a system component (such as a processor, server, network, or database, for example) are assumed by secondary system components when the primary component becomes unavailable through either failure or scheduled down time. Used to make systems more fault-tolerant, failover is typically an integral part of mission-critical
Helsebygg Midt-Norge Side: 7 av 21 7. Var dette (ROS-analyser) godt nok kommunisert til beslutningstakerne da beslutninger om datanettet ble fattet? 8. Var visjonen for datanettleveransen avstemt med sannsynlig virkelighet på det tidspunktet det skulle tas i bruk av sykehuset? 9. Var det hensiktsmessig å benytte en totalentreprise kontraktsform i dette prosjektet, og hvilke fordeler og ulemper ga kontraktsformen for dette prosjektet? Ble det introdusert risikoer gjennom kontraktsformen? 1.1 Forkortelser Liste over viktige forkortelser i dokumentet: FAT Factory Acceptance Test FDR Final Design Review HBMN Helsebygg Midt-Norge HKR Hovedkommunikasjonsrom sentralt i hvert bygg IKT Informasjons og Kommunikasjonsteknologi IT Informasjonsteknologi ITIL IT Infrastructure Library KR Kommunikasjonsrom (KR) på etasjeplan i hvert senter MTBF Mean Time Between Failures MTTR Mean Time To Repair NMS Network Management System PDR Preliminary design review POC Proof of concept ROS Risiko og Sårbarhet SAT Site Acceptance Test SHKR Sentralt hovedkommunikasjonsrom plassert strategisk i bygningsmassen SPOF Single point of failure systems that must be constantly available. Se http://searchstorage.techtarget.com/sdefinition/0,290660,sid5_gci753437,00.html. Eller kortere formulert: The term failover refers to switching to a duplicate hot backup component in real-time when hardware or software failure occurs, which enables the system to continue processing. iht. The CISSP Prep Guide av Krutz og Vines ISBN 0-471- 41356-9.
Helsebygg Midt-Norge Side: 8 av 21 2. Fremgangsmåte For å besvare spørsmålene som reises har vi benyttet dokumentasjon som ble benytte som input til prosessene (eksempelvis IT-strategi for det nye universitetssykehuset) eller dokumentasjon som ble produsert i prosessene (eksempelvis) byggherrens tilbudsgrunnlag. Vi har også hatt oppklarende møter og telefonsamtaler. Spørsmålene angitt i innledningen behandles i neste kapittel i rekkefølge med. bl.a. angivelse av dokumentasjonskilde, svaret og kortversjon av svaret. Som underlag for vurderingen i fase 1 har vi hatt tilgang til følgende dokumentasjon: Strategidokumenter og handlingsplaner; Anbudsforespørsel; Evalueringsrapport av tilbud; Kontraktsdokumenter Sikkerhetsgjennomganger Møtereferater Vi har konsentrer innsatsen rundt dokumenter relatert til strategi, overordnede beskrivelser, datanettverk og delvis kommunikasjonssystemer. Enkelte av spørsmålene er overlappende. Dette fører til at samme argumentasjon kan benyttes til å besvare flere spørsmål. Til å besvare spørsmålene har vi benyttet følgende mal: Kilde: er det formelle navnet på dokumentasjonen vi legger til grunn for å besvare spørsmålet. Dersom vi har benyttet møter eller telefoner, gies det informasjon om det her. Dersom det finnes annen relevant dokumentasjon, ønsker vi en tilbakemelding om dette og hvor denne dokumentasjonen kan finnes; svar på spørsmålet; Svar: er kortversjon av svaret. Rapporten beskriver avvik som er avdekket i gjennomgangen. Avvik defineres som manglende samsvar med visjon, strategi, design eller leveranse. I sammendraget er svarene gitt på kortform etter følgende skala: - Ingen avvik - Mindre avvik - Større avvik Rapportene omhandler i hovedsak avvik. Forhold der ingen avvik er avdekket, beskrives normalt ikke. Gjennomgangen er basert på stikkprøver. Det er derfor ikke sikkert at alle forhold er avdekket. Rapporten bør leses med dette i minne. Sluttrapporten vil inneholde forslag til tiltak basert på avvikene.
Helsebygg Midt-Norge Side: 9 av 21 3. Spørsmål i fase 1 3.1 Var ambisjonsnivået i visjon/strategi for omfattende i forhold til det som er teknisk mulig? Kilder: [IT-strategi for det nye universitetssykehuset Overordnede mål og strategier, 1]; [Handlingsplan for IT i det nye universitetssykehuset, 2]. På side 11 i IT-strategidokumentet [1] finner vi følgende avsnitt: Informasjonsteknologi (IT) Systemer for elektronisk journal og PACS (elektronisk arkivering, distribusjon og behandling av bilder) forutsettes tatt bruk. All rekvirering av prøver, undersøkelser og rekvisita/forsyninger skal skje elektronisk. Alle funksjoner ved sykehuset kan kobles sammen i et internt nettverk som muliggjør bruk av elektroniske meldingssystemer basert på internasjonale standarder. Overføring av pasientopplysninger mellom alle ledd i behandlingskjeden kan skje via regionale nettverk. Nødvendige administrative og styringsmessige systemer vil være tilgjengelig, og muliggjør planlegging og styring av produksjon og kostnader. Dette punktet oppsummerer mye av planene og ambisjonene for IT-anvendelsene i det nye universitetssykehuset. Vi har ingen kommentarer til ambisjonsnivået i utnyttelsen av IT-teknologi, men vi har kommentarer til bruken av IT-teknologi som etter vår mening også burde vurderes i et risikoperspektiv. IT-teknologi har fantastiske egenskaper når teknologien innfrier forventningene, men den kan skape utrolig mange ubehageligheter når den streiker og alternative løsninger ikke umiddelbart finnes. Avhengighet av IT har med andre ord mange elementer av risiko som blir alvorligere når IT-teknologi benyttes i vitale og kritiske prosesser i sykehuset. Strategidokumentet burde etter vår mening sette krav til Risiko og sårbarhetsanalyser (ROS-analyser) før endringer av eksisterende IT-system eller innføring av nye IT-system. Hensikten med en ROS-analyse er med utgangspunkt i sykehusets prosesser, identifisere, kvantifiserte og prioritere risikoene på bakgrunn av sykehusets akseptable risiko. Sikkerhet kan defineres som «en tilstand uten fare». Absolutt sikkerhet med beskyttelse mot alle trusler kan være ønskelig, men er ikke mulig eller har en for høy pris. Dette betyr at det vil være igjen en «restrisiko» etter at sykehusets sikkerhetstiltak er implementert. Kravet må være at denne restrisikoen skal være akseptabel for St. Olavs Hospital. Risikoen tilknyttet en hendelse defineres som sannsynligheten av hendelsen multiplisert med skaden påført av hendelsen. Sannsynligheten for feil i ny IT-teknologi er langt større enn feil i ITteknologi som har vært i markedet i lang tid. IT-strategien burde derfor sette føringer til valg av stabil og velprøvd IT-teknologi. Handlingsplan for IT i det nye universitetssykehuset [2] inneholder et punkt med tittel Sikkerhet og tilgjengelighet. Her sies det at basert på mål og krav til sikkerhet så medfører dette innsats for 3. Kontinuerlig anvende informasjonsregnskap, risiko og sårbarhetsanalyse ved planlegging av sykehusets informasjonssystem. Videre under samme punkt Sikkerhet og tilgjengelighet heter det: Det er gjennomført en kartlegging av alle IT-systemene som er i bruk ved sykehuset i dag. I forlengelsen av denne kartleggingen blir det gjennomført en risiko og sårbarhetsanalyse hvor målsetningen er å få oversikt over kritiske systemer, og utarbeide gode
Helsebygg Midt-Norge Side: 10 av 21 beredskapsplaner dersom datasystemene skulle falle fra. Gjennom ROS-analysen og beredskapsplanene har sykehuset et godt grunnlag for å vurdere risiko og sårbarhet i forhold til problemstillingen IT-sikkerhet, og gjennomføre tiltak for å forbedre denne. Disse sitatene hentet fra [2] viser at ROS-analyse er tenkt anvendt for å bedre informasjonssikkerheten ved sykehuset. For nærmere gjennomgang av ROS-analyser, se kapittel 3.6. Svar: Ambisjonsnivået i visjon/strategi var ikke for omfattende i forhold til det som var teknisk mulig. 3.2 Gjenspeilte visjon/strategi tilsvarende visjon og strategi for St. Olavs Hospital? Kilder: [IT-strategi for det nye universitetssykehuset Overordnede mål og strategier, 1]; [Handlingsplan for IT i det nye universitetssykehuset, 2]; [Teknologistrategi for St. Olavs Hospital, 3]; [720-5002 Infrastruktur for IKT Bilag B6, Datanett, kontrakten, 4]. Teknologistrategi for St. Olavs Hospital [3] er basert på [1] og [2] iht. forutsetningene og gjenspeiler intensjonene i disse dokumentene. Teknologistrategien i kapittel 4 Teknologiske retningslinjer og tiltak bringer imidlertid inn nye og sentrale moment: 1. For å redusere risikoen (og derigjennom kostnadene) skal St. Olavs Hospital ta i bruk teknologi som er fremtidsrettet, men samtidig moden. Videre skal man gjøre teknologi valg innenfor det som må oppfattes som «mainstream», dvs. hvor det er god tilgang på kompetanse og løsninger. Kravet om fremtidsrettet teknologi hang sammen med at det teknologivalget som nå skulle foretas skulle være fremtidsrettet og levedyktig i mange år fremover pga. kostnadene ved et teknologiskifte. Ved et kortere tidsperspektiv, er det blitt fortalt oss, ville sannsynligvis teknologivalget blitt et annet enn for eksempel IP-telefoni. Vi vil være forsiktig med å spå om fremtiden. Men teknologigtrender går ofte i retning av konvergens av teknologier. IP nettverk slik vi ser disse anvendt i dag, er nettverk som kan kombinere tale, data og andre typer signaler i samme nettverk og vil dermed erstatte dedikerte data-, tale- og ulike typer signalnettverk. Vi mener at IPnettverk med de anvendelser som er nevnt her er kommet for å bli. Dette fordi det er klare økonomiske insentiver for denne teknologien. Det er også utfordringer hva angår design, implementering og test av denne infrastrukturen for at brukerne får den tjenestekvalitet (Quality of Service) som de er vant med ved bruk av dedikerte nettverk. Hva angår valg av IT-teknologi vil vi hevde at den bør være fremtidsrettet, moden og «mainstream». «Mainstream» teknologi for oss krever ikke bare kompetanse og løsninger, men også et antall installasjoner som kan vise til tilfredsstillende og stabil drift over tid. Vi savner en nærmere presisering av «fremtidsrettet, men samtidig moden» teknologi i ITstrategien. Det kan virke som om leverandøren har misforstått krav [K6.1-1] i [4] når han hevder at kravet er tilfredsstilt med følgende kommentar. Telenor har valgt det siste innenfor Cisco teknologi for å tilfredsstille dette punktet. Cisco har også funnet fram til moduler som ikke er lansert, men som er like om hjørnet. Dette er garantert av Cisco.
Helsebygg Midt-Norge Side: 11 av 21 Det er en selvmotsigelse at kravet er oppfylt sett i lys av kommentaren til Telenor. Telenors svar forteller oss at de ønsket å benytte umoden Cisco teknologi (moduler som ikke er lansert) med den risiko dette måtte innebære for St. Olavs Hospital. Vi vil hevde at det er usikkerhet ved en eventuell påstand om at en umoden teknologi vil være moden ved et senere installasjonstidspunkt. Svar: Visjon/strategi gjenspeilte tilsvarende visjon og strategi for St. Olavs Hospital. 3.3 Var spesifikasjonene entydige og klar nok? Kilder: [720-5002 Infrastruktur for IKT Bilag B6, Datanett; i forespørselen, 1]; [B6 Datanett kravtabell, kontrakt, 2]; [B6 Datanett Beskrivelse og svar på spørsmål, 3]; [The Uptime Institute, http://www.upsite.com/tuipages/whitepapers/tuitiers.html, white paper: Tier Classification Define Site Infrastructure Performance, 4]. Spesifikasjonen benytter lokale forkortelser (eks. SHKR) som vi ville ønske samlet i et eget kapittel eller dokument for å lette lesbarheten. Det kan virke som om leverandøren har misforstått krav [K6.1-1] i [1] når han hevder at kravet er tilfredsstilt med følgende kommentar. Telenor har valgt det siste innenfor Cisco teknologi for å tilfredsstille dette punktet. Cisco har også funnet fram til moduler som ikke er lansert, men som er like om hjørnet. Dette er garantert av Cisco. Det er en selvmotsigelse at kravet er oppfylt sett i lys av kommentaren til Telenor. Telenors svar forteller oss at de ønsket å benytte umoden Cisco teknologi (moduler som ikke er lansert) med den risiko dette måtte innebære for St. Olavs Hospital. Uttrykket «single point of failure» (SPOF) forkommer i en rekke sammenhenger i [1]: 1. [K6.1-3] Løsningen skal være slik at det ikke er noe single point of failure i hele strukturen helt ut til kantsvitsj i kommunikasjonsrom. 2. [K6.1-74] Sykehusets datanett skal være konfigurert slik at man ikke har noen single point of failures som kan føre til at hele datanettet går ned. 3. [K6.1-136] Løsningen skal være slik at det ikke finnes single point of failure i kommunikasjonsrom, og kun direkte tilknyttete brukere skal bli påvirket av en feil på en kantsvitsj. Vi savner en definisjon av «single point of failure» i [1]. I det første eksemplet har leverandøren gitt følgende svar: Redundant power, redundant supervisormodul og redundante veier i nettet. Svaret indikerer at leverandøren beskriver SPOF med utgangspunkt i maskinvare, programvare og kabling. Vi er kjent med at utstyr kan stanse etter en «høy temperatur advarsel» pga. av problem med kjøling typisk i serverrom. Vi savner hvordan denne situasjonen vil bli håndtert. Ved stans som skyldes feil i en supervisormodul, vil det sannsynligvis ikke være til hjelp om samme supervisormodul er installert på annet utstyr, gitt samme versjon og patchnivå av supervisormodulen. I det andre eksemplet benyttes SPOF i sammenhengen som kan føre til at hele datanettet går ned.
Helsebygg Midt-Norge Side: 12 av 21 Det kan være mange forskjellige feilkilder som kan føre til at datanettet går ned: Stans i nettverksleverandørens samband (hvis det for eksempel benyttets datanettet til Orkdal Sykehus); hardware feil; softwarefeil i svitsjer, rutere, brannmurer, IDS for nettverk og servere; uventet og plutselig økning av båndbreddbehovet i servere; konfigurasjonsproblemer; menneskelig feil (representerer 70 % av alle feil, se kapittel 3.5 med tilleggsinformasjon om dette); feil i krafttilførsel; feil i kjøling av serverrom; sikkerhetsbrudd. Leverandøren gir ingen kommentarer ut over at dette kravet [K6.1-74] er tilfredsstilt. Dette svaret hadde vært klarere dersom SPOF var definert i [1]. Det tredje eksemplet er i samme kategori som eksempel 1. Med referanse til krav [K6.1-73] Levert utstyr skal ha en normal driftstilstand i minst 15 år. Det er uklart hva som legges i begrepet normal driftstilstand. I krav B6.1.3.15 benyttes begrepene MTBF og MTTR (se nærmere beskrivelse i kap 3.5). Dette bør være velkjente begrep. I [3] har imidlertid leverandøren angitt MTTR for diverse Cisco-utstyr i størrelsesorden ett antall år. Dette tyder på at en forklaring av begrepene kunne vært nødvendig likevel. For opsjoner i nettverk (B6.1.6), trådløst datanett (B6.2.6) og system for drift, overvåkning og administrasjon (B6.3.6) savnes tagging [<tekstreferanse>] av leverandørenes svar. I B6.3 System for drift, overvåkning og administrasjon [1] mangler det dokumentasjon av: Krav til tilgjengelighet (en % sats) av NMS (Network Management System); sikkerhetsadministrasjon av datanettet, eventuelt referanse til hvor i dette dokumentet denne administrasjonen er beskrevet, og krav om beskyttelse mot ondsinnet og mobil kode for å bevare integriteten av programvare og data/informasjon. Svar: Vi har funnet krav som kunne vært nærmere presisert, dette bl.a. begrunnet i besvarelsen fra leverandøren.
Helsebygg Midt-Norge Side: 13 av 21 3.4 Stemte spesifikasjonen med det som er nedfelt i visjon og strategi? Kilder 2 : [IT-strategi for det nye universitetssykehuset Overordnede mål og strategier, 1]; [Handlingsplan for IT i det nye universitetssykehuset, 2]; [Teknologistrategi for St. Olavs Hospital, 3]; [720-5002 Infrastruktur for IKT Bilag B6, Datanett; forespørselen, 4] Kildedokument [4] har bl.a. følgende krav: [K6.1-31] Stamnettsvitsjer skal være av fabrikat Cisco. Dette av hensyn til krav om å sikre gjennomgående funksjonalitet mot NTNU og MNH som har standardisert på Cisco i tilsvarende nivå i sine nettløsninger. [K6.1-45] Rutere skal være av fabrikat Cisco. Dette av hensyn til krav om å sikre gjennomgående funksjonalitet mot NTNU og MNH som har standardisert på Cisco i tilsvarende nivå i sine nettløsninger. Denne entydige leverandørpreferansen er nytt i forhold til kildedokumentene [1, 2 og 3]. Kildedokument [3] i punkt 4.8.4 Hardware, har målsetningen om rammeavtale med minimum to ulike utstyrs/systemleverandører og foreslår som tiltak: 6.E. Inngå rammeavtaler med et begrenset antall leverandører. 6.F. Vurdere forløpende alternative produkter/leverandører. Virksomhetskritiske funksjoner som står eller faller avhenghengig av informasjonsteknologig, er sårbare funksjoner. Denne sårbarheten kan reduseres gjennom bruk av alternative løsninger for å utføre samme virksomhetskritiske funksjon. Alternative løsninger kan være bruk av manuelle funksjoner hvis dette er mulig, bruk av annen informasjonsteknologi hvis dette er mulig, eller en kombinasjon av manuelle funksjoner og informasjonsteknologi. Dersom en virksomhetskritisk funksjon må utføres med bruk av informasjonsteknologi vil for eksempel et nettverk som består av komponenter fra samme leverandør representere et «single point of failure» pga. programvarefeil. Et nettverk som bla. er avhengig av firewalls, svitsjer og rutere for å funksjonere er sårbart for programvare feil i disse komponentene uavhengig av hardware redundans, samme boks feiler fordi programvaren kommer fra samme leverandør. Vi vil derfor hevde at design for pålitelighet er en design av multiple heterogene nettverk. Designere av nettverk står derfor ovenfor to uforenlige mål, å minimalisere det totale nettverkskostnaden og tilby redundans som en beskyttelse mot alvorlige driftsforstyrrelser. Dersom det av kostnadsmessige og eller funksjonelle hensyn velges en løsning som i dette tilfellet, er det svært viktig at risiko og sårbarhet blir analysert og forslag til tiltak for å minimalisere effekten av eventuelle feil blir implementert og fulgt opp. Brukerne av nettverket må også være klar over risikoen for at alvorlige feil kan inntreffe og lage beredskapsplaner og gjennomføre katastrofeøvelser for et utvalg av scenarios. Et av flere realistiske scenarioer er at hele datanettverket er nede i flere timer. Svar: I hovedsak er det overensstemmelse mellom spesifikasjonen og visjon og strategi. Spesifikasjonen forutsetter nettverksutstyr som rutere og kjernesvitsjer fra Cisco. Konsekvensen av dette er bl.a. at en alvorlig programvarefeil i en kjernesvitsj levert av Cisco kan gi alvorlige driftforstyrrelser i nettverket. 2 Vi ble henvist til refererte kildedokumenter av vår oppdragsledelse.
Helsebygg Midt-Norge Side: 14 av 21 3.5 Var de innledende føringer på funksjonalitet forenlig med tilgjengelig teknologi og kompetanse? Kilder: [720-5002 Infrastruktur for IKT Bilag B6, Datanett; i kontrakten, 1]; [Teknologi strategi for St. Olavs Hospital, 2]; [B6 DATANETT Kravtabell i kontrakten, 3]. For å besvare dette spørsmålet har vi i kildematerialet (forespørselens kravtabeller[3]) konsentrert oss om krav spesifisert som [Kx.y-z]. [K6.1-1] vedr. bruk av moden teknologi Et sentralt krav i [1] er [K6.1-1] hvor det bl.a. heter: For å redusere risikoen (og derigjennom kostnadene) skal St. Olavs Hospital ta i bruk teknologi som er fremtidsrettet, men samtidig moden på installasjonstidspunktet. Med «moden teknologi» menes at en kan vise til sammenlignbare installasjoner i full drift, fortrinnsvis i Norge. Dette kravet sier klart at teknologien som skal benyttes må være både fremtidsrettet og moden i betydningen at teknologien skal være tatt i bruk med vellykket resultat fortrinnsvis i Norge. Vi ønsker å understreke viktigheten av kontakten med referanseinstallasjoner for å få deres erfaringer på godt og ondt. Dette gjelder også organisatoriske og kompetansemessig erfaringer i tillegg til leverandørerfaringer spesielt hva angår deres evne og vilje til å gi support. I Teknologi strategi for St. Olavs Hospital [2] er dette kravet beskrevet under headingen Overordnede retningslinjer for bruk av teknologistrategien. I denne teknologistrategien savner vi en nærmere presisering av begrepet «fremtidsrettet men samtidig moden teknologi» og viktigheten av at teknologien er moden sett i et risikoperspektiv, at anvendelse av teknologien er innenfor rammen av akseptabel risiko. Leverandøren har til kravet [K6.1-1] angitt at kravet er tilfredsstilt med følgende kommentar. Telenor har valgt det siste innenfor Cisco teknologi for å tilfredsstille dette punktet. Cisco har også funnet fram til moduler som ikke er lansert, men som er like om hjørnet. Dette er garantert av Cisco. Vi oppfatter at det er en selvmotsigelse at kravet er oppfylt sett i lys av kommentaren til Telenor. Telenors svar forteller oss at de ønsket å benytte umoden Cisco teknologi (moduler som ikke er lansert) med den risiko 3 dette måtte innebære for St. Olavs Hospital. Vi vil videre hevde at det er hefter usikkerhet ved en eventuell påstand om at en umoden teknologi vil være moden ved et senere installasjonstidspunkt. Vi har så langt ikke fått avklart hvordan risikoen i å benytte en umoden teknologi ble behandlet av anskaffelsesprosjektet dvs. hvilke tiltak som ble iverksatt for å forhindre eller redusere konsekvensene ved anvendelse av umoden teknologi. For nærmere beskrivelse av risiko og sårbarhet, se kapittel 3.6. De innledende føringer på funksjonalitet slik disse fremkommer i B6 [1] var forenlig med tilgjengelig teknologi i denne fasen av prosjektet. Vår begrunnelse for dette er: Grunnlaget for IP teknologi ble lagt allerede på 1990 tallet. Den første VoIP applikasjonen ble introdusert i 1995 av det Israelske selskapet VocalTec som en «Internett telefon». IP 3 Risikoen tilknyttet en hendelse defineres som sannsynligheten av hendelsen multiplisert med skaden påført av hendelsen. Sannsynligheten for feil i ny IT-teknologi er langt større enn feil i IT-teknologi som har vært i markedet i lang tid.
Helsebygg Midt-Norge Side: 15 av 21 nettverk kan overføre tale, data og andre typer signaler i samme nettverk og dermed erstatte dedikerte data-, tale- og ulike typer signalnettverk. Vi må regne med at IP- nettverk med de anvendelser som er nevnt her er kommet for å bli. Etter vår mening burde det reises tvil om de innledende føringer på funksjonalitet slik disse fremkommer i B6 [1] var forenlig med tilgjengelig kompetanse i denne fasen av prosjektet. Vår begrunnelse for dette er: Leverandøren hevdet at de ville ta i bruk Cisco moduler som ikke var lansert. Vi vil for det første hevde at det er usikkerhet ved en eventuell påstand om at en umoden teknologi vil være moden ved et senere tidspunkt. Det hefter derfor også usikkerhet om det ville bli tilstrekkelig kompetanse på dette produktet hos leverandøren et antall år frem i tide Svar: De innledende føringer på funksjonalitet slik disse fremkommer i B6 [1] var forenlig med tilgjengelig teknologi i denne fasen av prosjektet. Etter vår mening burde det reises tvil om de innledende føringer på funksjonalitet slik disse fremkommer i B6 [1] var forenlig med tilgjengelig kompetanse i denne fasen av prosjektet 3.6 Ble risiko og sårbarhet vurdert, kompensert og godt nok ivaretatt, og ble failover og alternative løsninger vurdert for å eventuelt kompensere for situasjoner der datanettet ikke fungerer tilfredsstillende? Besvarelsen av spørsmålet er delt i 2: Ble risiko og sårbarhet vurdert, kompensert og godt nok ivaretatt? Ble failover og alternative løsninger vurdert for å eventuelt kompensere for situasjoner der datanettet ikke fungerer tilfredsstillende? 3.6.1 Ble risiko og sårbarhet vurdert, kompensert og godt nok ivaretatt? Kilder: [Handlingsplan for IT i det nye universitetssykehuset, 1]; [020.00.R.08.RA-072 Sikkerhetsgjennomgang overordnet forsyning Tele og IT.doc (01.10.2001), 2]; [Presentasjon i styremøte HBMN, sak 076/2003, 3]; [Møtereferater fra IKT-råd (2003-2004), 4]. Project Management Institute (PMI ) (http://www.pmi.org) er et anerkjent organ for beskrivelse av krav til prosjektledelse. De har utgitt en standard A Guide to the Project Management Body of Knowledge (PMBOK Guide) for prosjektledelse. Kapittel 11 i PMBOK Guide beskriver Project Risk Management. I følge denne bør det lages en Project Risk Management Plan som beskriver mål, strategier og metoder for risikoanalyse og håndtering i et prosjekt. Planen skal beskrive alle aspekter for identifikasjon, estimering, evaluering og kontroll av risiko. I store prosjekter er det naturlig å dele risikoanalyse og håndtering i separate deler for kostnad, gjennomføring, teknisk og kvalitet. Planlegging, oppfølging og rapportering bør gjennomføres jevnlig i parallell med andre planleggingsprosesser
Helsebygg Midt-Norge Side: 16 av 21 Kartlegging, analyse og håndtering av Risiko og Sårbarhet (ROS) er en viktig aktivitet som må gjennomføres i alle faser av prosjektet. Systematisk ROS-arbeid kan deles inn i seks trinn: 1. Organisering og planlegging. 2. Etablering av akseptkriterier. 3. Grovanalyse med identifisering av risikoområder. 4. ROS-analyse. Årsaksanalyse Konsekvensanalyse Risikovurdering i forhold til objektive akseptkriterier Kartlegging av tiltak/løsninger 5. Forslag og prioritering av tiltak 6. Handling og oppfølging av tiltak Handlingsplan for IT i det nye universitetssykehuset [1] inneholder et punkt med tittel Sikkerhet og tilgjengelighet. Her sies det at basert på mål og krav til sikkerhet så medfører dette innsats for 3. Kontinuerlig anvende informasjonsregnskap, risiko og sårbarhetsanalyse ved planlegging av sykehusets informasjonssystem. Videre under samme punkt Sikkerhet og tilgjengelighet heter det: Det er gjennomført en kartlegging av alle IT-systemene som er i bruk ved sykehuset i dag. I forlengelsen av denne kartleggingen blir det gjennomført en risiko og sårbarhetsanalyse hvor målsetningen er å få oversikt over kritiske systemer, og utarbeide gode beredskapsplaner dersom datasystemene skulle falle fra. Gjennom ROS-analysen og beredskapsplanene har sykehuset et godt grunnlag for å vurdere risiko og sårbarhet i forhold til problemstillingen IT-sikkerhet, og gjennomføre tiltak for å forbedre denne. Disse sitatene viser at ROS-analyse er tenkt anvendt for å bedre informasjonssikkerheten ved sykehuset. Som et minimum kunne man forvente at ROS-analyser ble gjennomført og/eller oppdatert ved viktige faseoverganger i prosjektet. I forbindelse med tilbudsfasen ville det være naturlig å gjennomføre dette: 1. Ved utarbeidelse av forespørsel 2. Ved evaluering av tilbud 3. Sammen med valgt leverandør i kontraktsfasen ROS-analyser må gjennomføres både fra et teknisk synspunkt og fra et brukersynspunkt. Eksempelvis vil det fra teknisk side være fokus på tiltak for å redusere sannsynligheten for at nettverket får nedetid, mens det fra brukersiden vil være fokus på å begrense konsekvensen dersom nettverket og funksjoner basert på det ikke er tilgjengelig. Status for tiltak må rapporteres til prosjektledelsen og risikoansvarlig i statusrapporter. Søk etter informasjon om ROS i tilgjengelig dokumentasjon inklusive møtereferater [4] har gitt følgende resultater: Det ble gjennomført Sikkerhetsgjennomgang av overordnet forsyning Tele og IT [1]: Arbeidsgruppen har gått gjennom foreliggende planer for overordnede systemløsninger for tele og IT i nye RiT med tanke på sikkerhet i forhold til pasienter, ansatte, besøkende og større økonomiske verdier.
Helsebygg Midt-Norge Side: 17 av 21 Gruppen har hatt deltakere fra det kliniske miljø, fra teknisk side i RiT og NTNU samt fra planleggerne. Ved gjennomgangen ble det pekt på en del punkter som det fortsatt bør rettes stor oppmerksomhet mot i det videre planleggingsarbeidet. Ref Kritiske faktorer Årsak/Konsekvenser Kommentarer (Tiltak). 06 Overføring av kritiske alarmer på ett TCP/IP stamnett. (Mange/alle alarmsystemer på samme nett) til sentral driftskontroll (SD). Svikt i overføring kan medføre økt responstid fra hjelpepersonell og medføre fare for liv/helse. Det enkelte alarmsystem må gjennomgås med hensyn på kabelstruktur. Det er god redundans i TCP/IP nettet, men sannsynligheten for feil i dette systemet ligger ikke i den fysiske kablingen, men i muligheten for nedetid p.g.a. støy, loop,virus, hacking i systemet. I krav til leverandør av alarmsystemer må det spesifiseres hvilket kabelnett man forutsetter at det skal kommunisere gjennom. Sykehusets beredskap må håndtere nedetid på stamnettet (TCP/IP) 17 Tilkalling av akuttteam ved hjerte/ respirasjonsstans. Dersom kommunikasjonen ikke fungerer, kan dette medføre fare for liv/helse for pasienter. Type reservesystem er ikke avklart. Det forventes at det etableres 2 separate sambandsnett. Sambandet mellom nye senter og gamle RiT må opprettholdes med god sikkerhet i byggeperioden, da man vil benytte akutt-team stasjonert i gamle RiT. Systemvalg vil bli tatt så sent som mulig i prosessen m.h.p. den tekniske utviklingen. Ref. Aksjon Ansvarlig / Tid for gjennomføring 404-03-04 Utarbeide beredskapsrutiner for driften i tilfelle nedetid på stamnettet. (En del av Plan for kriser og interne ulykker. ) RIT Før overtagelse Dokumentet viser at risiko knyttet til utilgjengelig nettverk har vært behandlet i tidlig fase av prosjektet (oktober 2001). Det er ikke funnet noe dokument som tilsvarer Project Risk Management Plan eller tilsvarende dokumentasjon. Det er ikke funnet ROS-dokumentasjon for teknisk løsning i forbindelse med utarbeidelse av forespørsel. I forbindelse med evaluering av tilbudet ble Risikoområder gjennomgått før inngåelse av kontrakt med Telenor i styret til HBMN, sak 076/2003 [3]. Dette var en oppsummering av risikoområder, og ikke en ROS-analyse. Der er ikke funnet ROS-dokumentasjon for teknisk løsning i forbindelse med inngåelse av kontrakt. Svar: Ut fra tilgjengelig dokumentasjon kan vi ikke se at ROS for teknisk løsning har vært systematisk planlagt, gjennomført og fulgt opp i tilbudsfasen.
Helsebygg Midt-Norge Side: 18 av 21 3.6.2 Ble failover og alternative løsninger vurdert for å eventuelt kompensere for situasjoner der datanettet ikke fungerer tilfredsstillende? Kilder: Forespørsel: [B2 Overordnet beskrivelse.doc, 1]; [B6 Datanett.doc, 2]; [B31 Prosjektgjennomføring.doc,3]. Dette gjelder vurderinger av kravspesifikasjonen. Den skisserte løsningen i [1] og [2] ser ut til å ha beskrevet redundans som dekker opp failover (se fotnote 1 side 6). Nærmere evaluering av dette vil bli gjort i senere fase av gjennomgangen. Kravene til Prosjektgjennomføring [3] beskriver fall-back som krav til alternativ løsninger: Proof of concept - POC Entreprenøren skal for utvalgte funksjoner/systemer dokumentere at grunnleggende funksjonalitet kan leveres i samsvar med kravspesifikasjonen og systemdesign fastlagt i PDR og omfatte alle hovedfunksjoner i anlegget. Dette er en demonstrasjon av funksjonalitet som skal utføres i Entreprenørens lokaler. Dersom Entreprenøren ikke greier å demonstrere POC, skal Entreprenøren utarbeide plan for ny POC demonstrasjon samt iverksette tiltak for eventuell fall-back løsning. Svar: Det ble tatt høyde for å benytte alternative løsninger for å eventuelt å kompensere for situasjoner der datanettet ikke fungerer tilfredsstillende. 3.7 Var dette (ROS-analyser) godt nok kommunisert til beslutningstakerne da beslutninger om datanettet ble fattet? Kilde: [Møte med Tore Indreråk, HBMN, 9. august 2006, 1]; [Møte med Thore Smevik, St.Olav/Hemit, 22. august 2006, 2]; [SAK 068/2003Prosjektstyremøte HBMN-Entreprisestrategi teknisk IKT ambisjonsnivå og risiki,3]; [SAK 076/2003 Prosjektstyremøte HBMN- Teknisk IKT - ambisjonsnivå ift kostnader - gjenværende risiko innen IKT og prosjektet totalt, 4] Dette omhandler risiko og sårbarhetsanalyser i kravspesifikasjonsfasen inntil forespørselen ble godkjent. Det er ikke funnet dokumentasjon av formelle ROS-analyser i kravspesifikasjonsfasen. Ut fra samtaler [1], [2] kan man anta at risiko ved teknisk løsning er vurdert på et funksjonelt nivå til å omfatte Meldingstjenesten, Trådløs IP Telefoni, MDA, IP Telefoni, IP TV, IP Radio, Posisjonering/gjenfinning. Risiko og risikoreduserende tiltak ble presentert for prosjektstyret [3],[4] i kravspesifikasjonsfasen: Hovedrisiko vedrørende teknisk IKT: - Samkjøring mellom gammel og ny teknologi- krever allsidig kompetanse - Stort og komplekst prosjekt med fremtidsrettet teknologi
Helsebygg Midt-Norge Side: 19 av 21 Svar: - To byggefaser med en lang mellomfase - To sluttkunder St. Olavs og DMF, felles nett og infrastruktur, høyt krav til sikkerhet Våre tiltak for å redusere Helsebygg Midt Norge sin risiko: - Totalansvar hos en IKT-Entreprenør, en langsiktig samarbeidspartner - Tydelig grensesnittansvar hos IKT-Entreprenøren - Hovedsakelig Fastpris-basert - Ikke software-prosjekt, men hardware (mer forutsigbart) - Helsebygg har etterspurt basisleveranser (90% er basis hyllevare) - Prosjektgjennomføringen reduserer risiko (Proof of consept, Fall back) - Svært mange sanksjonsmuligheter, NS4331 Beslutning om valg av løsning (kravspesifikasjon) for datanettet ble tatt uten at det var gjort formelle ROS-analyser. Beslutningstakerne ved Prosjektstyret fikk presentert overordnede risikobetraktninger med forslag til risikoreduserende tiltak. Vi vurderer det slik at beslutningsgrunnlaget ikke var fullstendig, men at man ved de foreslåtte tiltakene (bl.a. Proof of concept, Fall back) kunne argumentere for beslutningen ved at man utsetter vurdering av risiko for løsningen til et senere tidspunkt. 3.8 Var visjonen for datanettleveransen avstemt med sannsynlig virkelighet på det tidspunktet det skulle tas i bruk av sykehuset? Kilde: [IT-strategi for det nye universitetssykehuset Overordnede mål og strategier, 1]. Etter vår vurdering er det ingen selvmotsigelse mellom visjon for datanettleveransen og den virkelighet på tidspunktet den skulle tas i bruk av St. Olavs Hospital. For eksempel ble allerede tidlig på 1990 tallet grunnlaget lagt som senere ble benyttet i VoIP teknologien. En visjon skal være fremtidsrettet og beskrive en ønsket situasjon eller et målbilde. Visjonen for det nye universitetssykehusets inneholder krav som bør kunne stilles ved bygging av et nytt sykehus. Svar: Visjonen for datanettleveransen var avstemt med sannsynlig virkelighet på det tidspunktet det skulle tas i bruk av sykehuset.
Helsebygg Midt-Norge Side: 20 av 21 3.9 Var det hensiktsmessig å benytte en totalentreprise kontraktsform i dette prosjektet, og hvilke fordeler og ulemper ga kontraktsformen for dette prosjektet? Ble det introdusert risikoer gjennom kontraktsformen? Kilde: [Bilag A1 Generell orientering om prosjektet, vedlegg 3: Kontrakts- / entreprisemodeller Entreprisemodell Teknisk Infrastruktur.doc, 1]; [Bilag A2 Informasjon om denne entreprisen, 2]; [NS 3431 2. utgave september 1994 Alminnelige kontraktsbestemmelser for totalentrepriser, 3]; [08 IKT-råd, møtereferater, 4 ]; [Møte med Tore Indreråk, HBMN, 9. august 2006, 5]; [Møte med Thore Smevik, St.Olav/Hemit, 22. august 2006, 6]; [Cisco AS, St. Olavs Network Proactive SAdvisory Review version 1.2, 2/2-06, 7]. Bilag A1 [2] gir bl.a. følgende forklaring på hvorfor det ble benyttet en samordnet entreprisemodell for IKT-anleggene: Samordningen av entreprisene er gjort for å oppnå best mulige løsninger ut fra god driftsøkonomi, samordnet funksjonalitet på tvers av ulike systemer og færrest mulig eksterne grensesnitt. Leverandøren(e) for disse entreprisene vil få det samlede ansvar for design, prosjektering, leveranse, implementering, samlet funksjonalitet og drift av anleggene med tilstøtende grensesnitt. For at tilbyder skal få et best mulig grunnlag for å vurdere kompleksitet og arbeidsomfang er det i dette kapittel gitt en oversikt over entreprisestruktur og senteroversikt for prosjektet. IKT-systemene er «ryggmargen» i sykehusets funksjoner, hvis suksess er avgjørende for suksessen av sykehusets samlede IKT-baserte tjenester. Det er vår vurdering at det er optimalt å benytte en samordnet entreprisemodell for å plassere alt ansvar hos en leverandør, gitt kompleksiteten og mangfoldet av IKT-systemene som skulle leveres og som skulle integreres med eksisterende IKTsystem. Det er etter vår oppfatning også en klok avgjørelse å la samme entreprenør få ansvaret for driften. Det er to årsaker til dette. For det første må entreprenøren også tenke og planlegge drift og vedlikehold i prosjekterings- og oppbyggingsfasene. For det andre vil byggherren trekke ut større veksler på sin investering i entreprenørens kompetanseoppbygging som skjedde i løpet av prosjektering og oppbyggingsfasene. Suksessen av denne entreprisemodellen er imidlertid at hovedleverandøren kjenner sin egen begrensing og benytter seg av underleverandører for å komplettere og kvalitetssikre sin egen «best practice». Suksessen er videre avhengig av at entreprenøren med sin kompetanse faktisk blir sittende med den operative driften av datanettet. Utfordringen for HBMN kan være at det gjennom en totalentrepriseprosess ble mindre behov for koordinering og oppfølging som kunne føre til mindre innflytelse i prosjektløpet eksempelvis styring og bruk av underleverandører og redusert mulighet til inneha en løpende kontrollerende funksjon. Dette gjelder særlig dersom totalentreprisen er kombinert med en generalentreprise, hvor entreprenøren påtar seg å ha alle andre entreprenører i prosjektet som sine underentreprenører, det vil si at byggherren bare har kontrakt med den ene entreprenøren. Etter møter vi har hatt med prosjektdeltakere sitter vi med den oppfatning av at kontraktsformen kunne bidratt til at kompetansen til en underleverandør kunne ha vært bedre utnyttet [4, 5, 6]. Vi har mottatt en Cisco rapport [7] som beskriver tiltak som ble foreslått utført med basis i Ciscos gjennomgang av nettverket i St. Olavs Hospital. Vi har bedt leverandøren om dokumentasjon som viser behandlingen av denne rapporten og status av tiltakene foreslått av Cisco. Vi venter fortsatt på leverandørens tilbakespill på vår henvendelse. Hvilke konsekvenser Cisco rapporten fikk for leveransen har vi derfor ikke fått svar på.
Helsebygg Midt-Norge Side: 21 av 21 Det er etter vår vurdering optimalt å benytte en samordnet entreprisemodell for å plassere alt ansvar hos en leverandør, gitt kompleksiteten og mangfoldet av IKT-systemene som skulle leveres og som skulle integreres med eksisterende IKT-system. Det er etter vår oppfatning også en klok avgjørelse å la samme entreprenør få ansvaret for driften. Det er to årsaker til dette. For det første må entreprenøren også tenke og planlegge drift og vedlikehold i prosjekterings- og oppbyggingsfasene. For det andre vil byggherren trekke ut større veksler på sin investering i entreprenørens kompetanseoppbygging som skjedde i løpet av prosjektering og oppbyggingsfasene. Følgende risikoer kunne blitt introdusert gjennom denne kontraktsformen: Kompetansen til underleverandør av nettverksutstyr kunne sannsynligvis blitt bedre utnyttet; HBMN fikk mindre innflytelse i prosjektløpet og kunne risikere mindre kompetanseoppbygging om datanettet, noe som kan være svært nyttig og avgjørende ved alvorlige driftsforstyrrelser eller i katastrofesituasjoner; HBMN frasa seg muligheten til å utøve en løpende kontrollerende funksjon. Svar: Det er etter vår vurdering optimalt å benytte en samordnet entreprisemodell for å plassere alt ansvar hos en leverandør, gitt kompleksiteten og mangfoldet av IKT-systemene som skulle leveres og som skulle integreres med eksisterende IKT-system. Det er etter vår oppfatning også en klok avgjørelse å la samme entreprenør få ansvaret for driften. Vi mener at kontraktsformen muliggjør introduksjon av enkelte risikoer, selv om det ikke er avdekket noen avvik i prosjektet.