Anskaffelse av programvare for balansert målstyring KONKURRANSEGRUNNLAG Trondheim, 26.mai 2004
SAMMENDRAG NGU skal anskaffe programvare for balansert målstyring. Anskaffelsen gjennomføres etter prosedyren konkurranse med forhandlinger iht. lov om offentlige anskaffelser m/forskrifter. Anskaffelsen kunngjøres i Norsk Lysningsblad. Frist for mottak av tilbud er 10.juli 2004 kl. 12.00. Tilbud merkes "Balansert målstyring" og sendes til Norges geologiske undersøkelse Att: Helge Hugdahl 7491 Trondheim Følgende kriterier legges til grunn ved vurdering av tilbudene (kriteriene er satt opp i vilkårlig rekkefølge): Tilbudte priser, løsningens totaløkonomi og betalingsbetingelser Systemenes brukervennlighet og grad av oppfyllelse av funksjonelle behov Grad av oppfyllelse av krav og anbefalinger Tekniske plattformer systemene kan kjøres på Omfang av utviklet web-basert brukergrensesnitt og integrasjonsmuligheter i intranett Tillit til tilbyder og tilbyders økonomiske soliditet Omfang av fagmiljø rundt systemet, og systemets posisjon hos tilbyderen Grad av utbredelse i markedet og systemets velprøvethet Referanseuttalelser Tilbyderens planer for videreutvikling, herunder evne og vilje til å videreutvikle systemene Omfang av tilbyderens forbehold til kjøp- og vedlikeholdsavtalen Tilbyders forståelse for utfordringene knyttet til prosjektet Tilbyder skal, innen tilbudsfristens utløp, legge frem skatteattest for merverdiavgift og skatteattest for skatt som ikke er eldre enn 6 måneder, regnet fra tilbudsfristens utløp. Tilbud som ikke oppfyller dette kravet forkastes. Tilbyder skal, innen tilbudsfristens utløp, legge fram en erklæring om at leverandøren oppfyller lovbestemte krav i Norge innen helse, miljø og sikkerhet (HMS). Dette er krav iht. vedlegg 3 i forskrift om offentlige anskaffelser. Tilbyder bes om å oppgi referanser til andre sammenlignbare prosjekter. Videre skal tilbyder legge frem foretakets årsregnskap eller utdrag fra dette. Inntil bindende avtale er inngått har NGU rett til å velge hvilket som helst tilbud, alternativt forkaste samtlige tilbud. Eventuelle spørsmål kan rettes til Ola Vikhammer eller Helge Hugdahl på telefon 73 90 40 00. Det vil ikke bli anledning til å presentere produkter/løsninger før tilbudsfristens utløp. NGU NGU er en etat under Nærings- og handelsdepartementet (NHD). NGU er landets sentrale institusjon for kunnskap om berggrunn, mineralressurser, løsmasser og grunnvann og skal aktivt bidra til at geofaglig kunnskap utnyttes til en effektiv og bærekraftig forvaltning av landets naturressurser og miljø. Hovedkontoret ligger på Østmarkneset i Trondheim. NGU har ca 200 ansatte, hvorav 130 er vitenskapelig personale. ORGANISASJON NGUs organisasjon fremgår av vedlegg til dette dokument. Virksomheten er organisert i 4 programmer. Hvert program har en programleder og et antall lag som har en samling prosjekter. For nærmere informasjon henvises det til http://www.ngu.no. TEKNISK STATUS NGU har et datanett som er skissert i vedlegg. Lokalnettet er koblet til UNINETT med fiberkabel. Tromsøkontoret er koblet sammen med hovedkontoret via en VPN-forbindelse over Internett. 2
I nettverket har NGU 12 servere av forskjellig størrelse. De aller fleste kjører Windows 2k. Datanettet har ca. 220 arbeidsstasjoner av forskjellig størrelse. Alle kjører Windows av en eller annen type. Normalt vil en arbeidsstasjon kjøre samme Windows-versjon i hele sin levetid. WEB er det strategiske valg når det gjelder å gjøre NGUs data og kunnskap tilgjengelig for brukerne. Her brukes Microsoft IIS som verktøy. Det foregår nå et omfattende arbeid med å klargjøre systemene for kartbasert aksess til NGUs informasjon. Andre viktige valg er: Oracle v9i MS Office 2000 Exchange 2000 Agresso Financials Public 360 KRAV TIL TILBUDET Tilbudet skal leveres i tre eksemplarer på papir. Tilbyder plikter å vedstå seg tilbudet i fire måneder etter tilbudsfristen. Ved inngåelse av kontrakt skal statens standardkontrakter benyttes (se http://www.statskonsult.no/it/ssa/index.htm). Tilbudet skal inneholde forslag til utfylte bilag til avtalen, jfr. beskrivelse nedenfor. SAMLET PRIS OG PRISBESTEMMELSER Alle priser på tilbudt programvare og systemavhengige tjenester skal samles og spesifiseres i tilbudet. Tilbudet skal således inneholde totale kostnader for prosjektet: Anskaffelse programvare maskinvare prosjektbistand tilpasning/utvikling integrasjon opplæring eventuelt andre kostnader Løpende utgifter vedlikeholdskostnader brukerstøtte konsulentbistand BETALINGSBETINGELSER De deler av leveransen som er fast og avtalt på forhånd betales med 1/3 av kontraktsbeløpet ved avtaleinngåelse, 1/3 ved godkjenning av installasjon og 1/3 ved godkjenning av akseptansetest. Betalingsbetingelsene for øvrig er fri leveringsmåned + 30 dager etter mottatt og godkjent faktura. Det skal ikke beregnes gebyrer eller tillegg på fakturaene. Alle priser er faste i avtaleperioden. Tilbyderen kan likevel med virkning fra hvert årsskifte kreve justeringer av prisene i henhold til endringer i Statistisk sentralbyrås konsumprisindeks over siste 12 måneder. Tilbyderens justering av prisene i henhold til konsumprisindeksen skal fremgå i tilbudet. Endringer i norske toll- og avgiftssatser som påvirker prosjektet vil bli godtgjort i sin helhet. Tilbyderens utgifter til ekspedisjon og fakturering, samt intern organisering av arbeidet med leveransen skal være innkalkulert i de oppgitte prisene. 3
KRAVSPESIFIKASJON Kravspesifikasjonen er basert på at NGU ønsker å anskaffe et standardsystem ( hyllevare ), som allerede er i bruk hos kunder med tilsvarende behov som NGU. De to kolonnene til venstre angir om kravet Må eller Bør oppfylles. 1. GENERELLE KRAV TIL SYSTEMET Systemet skal være en versjonert standardløsning. NGU skal selv kunne oppgradere tilbudt løsning når ny versjon utgis. Systemet må enkelt kunne utveksle data med Agresso Financials, kontorstøtteverkøy i MS Officepakken og sak/arkivsystemet Public360. Løsningen må være web-basert. Samtlige moduler i tilbudt løsning skal være totalintegrert slik at data kun registreres én gang. Systemet skal være basert på anerkjent teknologi og internasjonale standarder. Systemet skal ha solid markedsposisjon, med dokumenterte referanser. Systemet skal benytte norsk språk i alle deler av systemet med brukergrensesnitt. Leverandør skal redegjøre for kvalitetssikringssystemet som er benyttet i systemutviklingsarbeidet Leverandør skal redegjøre for organisering av kundesupport (teknisk support og brukerstøtte), herunder dokumentere den kapasitet og kompetanse som anses nødvendig. Leverandør skal redegjøre for eventuelle utviklingsplaner som innebærer endringer i grunnleggende oppbygging, funksjonalitet, teknologi, arkitektur, database/verktøy mv. Konsekvenser endringene vil medføre for en leveranse til NGU skal beskrives. 2. FUNKSJONALITET 2.1. Modellmessig oppbygging Løsningen skal være organisert i.h.h.t. BSCol s krav til en BSC-applikasjon. Løsningen støtter at en kan sette inn forskjellige grenseverdier (for beregning av trafikklys) for forskjellige måneder (innenfor et år) Ved beregning av trafikklys bør det være mulig å regelstyre trafikklysberegningen ved hjelp av formler. Målekortet bør støtte forskjellige tidsfrekvenser. Løsning må ha drill-down funksjonalitet. I hvilken grad har bruker/ administrator mulighet til å konfigurere egne drilldown rapporter. Løsningen bør ha en intutitiv navieringslogikk. Det må være mulig å legge inn beskrivelser for det enkelte nøkkeltall. Løsningen bør ha mulighet for å kunne operere med flere målekort for en organisasjon/ enhet. Det må være mulig å generere alarmrapporter slik at en på overordnet nivå kan få rapportert alle indikatorer som viser rødt signal. Løsningen bør enkelt kunne gi tall for denne periode og hittil i år. Under utarbeidelse av målekort er det ønskelig med en publiseringsfunksjon som gjør at en kan sette nøkkeltallene i Aktive / inaktive modus. Løsningen bør inneholde vekting av nøkkeltall slik at en får vektede trafikklysresultater på overliggende nivåer. 4
Løsningen bør ha en fleksibel håndtering av tidsperioder. Angi i hvilken grad tidsperiodebegrepet stiller krav til lagringsstrukturer. Funksjonalitet for å vise trender. 2.2. Handlingsplaner Løsningen må ha funksjonalitet for oppfølgning av handlingsplaner. En handlingsplan bør bestå av aktiviteter og milepæler. Det går an å definere eiere/ansvarlige for handlingsplaner eller deler av en handlingsplan. Løsningen varsler ansvarlige om oppfølgningsdatoer via e-mail. 2.3. Strategikart Løsningen har funksjonalitet for å definere årsaks- og virkningskart (strategikart). 2.4. Manuell datafangst Løsningen inneholder egen funksjonalitet for manuell datafangst. Bruker som skal gi inn manuelle data blir varslet via e-mail. Løsning inneholder funksjonalitet for verifikasjon av manuellt ingitt verdier. Løsning purrer ved manglende datainput. Løsning gir administrator oversikt over manglende datainput. Manuell datafangst kan styres ut mot enkeltbrukere. Når avgitte data er registrert oppdateres nøkkeltallsverdier automatisk. 2.5. Kommentarer Det skal være mulig å knytte kommentarer til det enkelte nøkkeltall. Det skal være mulig å generere egne kommentarkategorier innenfor hvert av nøkkeltallene. Det skal være mulig å begense tilgang på hvem som skal kunne legge inn kommmentarer/ se kommentarer. Løsningen må ha funksjonalitet for å se hvem som har registrert en kommentar. Løsning må ha funksjonalitet for å vise kommentarer for flere perioder på en gang. 2.6. Forvaltning av løsning Det er ønskelig å operere med målekortmaler som distribueres til den enkelte enhet slik at en ikke trenger å opprette all målekortlogikk flere ganger (når det er lik behandling). Administrator kan enkelt klippe og lime nøkkeltall og strategiske fokusområder. Adminstrator kan enkelt gå inn og lese, oppdatere og slette data fra løsningen. Administrasjonsverktøyet (etablering og vedlikehold av løsningen) bør være en flerbrukerløsning. Det skal være mulig å gi forskjellige tilganger til de forskjellige administratorene. 5
2.7. Grafisk grensesnitt Løsningen bør ha et fleksibelt grafisk grensesnitt. Administrator styrer selv hvilke informasjonselementer (grafer, tabeller, kommentarer mm.) som skal vises for det enkelte nøkkeltall. Det skal være mulig selv å definere språk på sluttbrukergrensesnitt. 2.8. Spørreundersøkelser Har løsningen funksjonalitet for spørreundersøkelser? Spørreundersøkelsesfunksjonaliteten er en integrert del av målstyringssystemet. 2.9. Endringer/ dynamikk i strukturer Det skal være mulig å legge til nøkkeltall underveis i løsningen. Løsningen skal ha stor grad av dynamikk med hensyn til oppdatering av datastrukturer. Hvordan håndterer løsningen nye begreper? 2.10. Automatisert datafangst Løsningen innbefatter automatisert datafangst fra andre datasystemer. Beskriv hvilke kilder som det leses fra. Datafangst kan scheduleres opp til å hente data fra forskjellige kildesystemer til forskjellige tidspunkt. Det finnes roll-back funksjonalitet for å tilbakeføre overførte data. Løsningen har varslingsmekanismer ved feil i dataoverføring/ oppdatering. Løsningen har logg funksjonalitet. 3. TEKNISK MILJØ 3.1. Generelle teknisk krav Alle data for alle enheter som benytter systemet må kunne lagres i en sentral database. Angi krav til op.system, database og versjon, evt. odbc- drivere, etc. Angi maskinvarekrav server(e). Angi maskinvarekrav til klienter. Angi hvilket verktøy applikasjonen er utviklet i, både på klient- og tjenersiden. Systemet må kunne driftes på Windows 2000 Systemet bør kunne benytte Oracle database. Systemet bør kunne benytte MS SQL database Ved tegning av vedlikeholdsavtale bør systemet kunne leveres på ny versjon av operativsystem og database i løpet av maksimalt et halvt år etter at kommersiell versjon av operativsystemet/databasen foreligger. Angi hvilke brukergrensesnitt som benyttes. Angi hvilken systemarkitektur applikasjonen har. Angi hvilke programvarelisenser som forutsettes på klient- og tjenerside. 6
4. SIKKERHET/AUTENTISERING 4.1. Krav til pålogging NGU har standardisert på operativsystemet Windows 2000. Leverandøren må skissere hvilke planer/løsninger som foreligger m.h.t. å tilpasse løsningen til katalogtjenesten Active directory i Win2000 for at brukerne skal slippe pålogging til selve fagsystemet. Den ansattes brukerid må kunne registreres i fagsystemet for å kunne skille tilgangen til den ansatte. Når en oppretter påloggingsid er skal påloggingsid gis en default minimums tilgang (eks bare lesetilgang) på database nivå. Enhver bruker av løsningen skal autentiseres individuelt før han/hun gis tilgang til systemet. Autentisering skal skje ved at brukeren oppgir et passord. Enhver brukeridentitet i systemet skal være entydig knyttet til en - og bare en - fysisk person. Systemet skal etter en periode - definert av systemadministrator - uten aktivitet fra en bruker, gjennomføre ny autentisering før brukeren får tilgang til systemet. Brukeridentiteten skal være nøkkelen for tilgang til moduler, skjermbilder, funksjoner, menyer, felt og organisasjonsnivå. Adgangen må kunne reguleres i forhold til hva den enkelte bruker kan gjøre med datafelt (lese, skrive, endre eller slette). Mulighet for å begrense/sladde menyer/bilder i forhold til de funksjoner brukeren skal ha tilgang til. Systemet må kunne autorisere brukerne etter roller. 4.2. Krav til loggføring Systemet skal logge endringer i brukernes autorisasjon. Loggen skal inneholde utførende brukers id, id for bruker med endret autorisasjon og tidspunkt for endring. Opprettelse og sletting av brukerkonto regnes som endring i autorisasjon. Systemet skal logge forsøk på uautorisert tilgang, feil i autentisering og andre hendelser som har betydning for sikkerheten. Loggen skal inneholde de opplysninger som er nødvendig for dette formålet, og systemadministrator skal enkelt kunne hente ut rapporter fra loggen. Systemet må kunne logge endringer som utføres av bruker vedr. enkeltpersoner. Loggen må dokumentere når og hvem som har utført endringen. 4.3. Krav til validering/datakvalitet Ved import av data skal det skrives ut en feilliste som viser hvilke transaksjoner som er avvist og hvilke feil som er oppdaget i transaksjonene. 4.4. Sikkerhetslogikk Uansett aksessmetode og aksessverktøy til databasen, skal definerte sikkerhetskrav være ivaretatt. Forretningslogikk som angår sikkerhet skal ligge i databasen. 5. KRAV TIL DOKUMENTASJON 5.1. Generelle krav til dokumentasjon Alle applikasjoner skal inneholde overordnet IT-rutinebeskrivelse, referanse til bibliotek/rutiner som den enkelte rutine er avhengig av/bruker. 7
Oversikt over manuelle og maskinelle kontroller i systemet med henvisning til flytdiagrammet. Dokumentasjon av i hvilken grad regler er realisert i databasesystemet - i form av triggere, lagrede prosedyrer eller views. Beskrivelse av adgangskontrollsystemet. Beskrivelse av systemutviklingsmetode. Beskrivelse av prosjektstyringsmetode. Beskrivelse av utviklingsmiljø/utviklingsspråk. Beskrivelse av rutiner for vedlikehold og videreutvikling av systemet. Beskrivelse av testplan med modultester og integrasjonstester. Beskrivelse av hvordan systemet er designet mht. klient-/tjener-løsning. Beskrivelse av hvilke standarder som er anvendt ved design av brukergrensesnitt. Brukerhåndbok. Må kunne legges på intranett og nås fra applikasjonen. Systemdokumentasjon og driftsdokumentasjon skal kunne gjøres tilgjengelig for revisjonen ved forespørsel - eventuelt på maskinlesbart medium. 5.2. Krav til dokumentasjon av backuprutiner Teknisk beskrivelse (systemkrav og maskin/utstyrskrav). Brukermanual, bør også finnes online. Driftshåndbok - feilmeldingsoversikt med aksjoner. 5.3 Kontrakt Lisensieres 3 parts programvare inn i løsningen? Alle aktuelle kontrakter som gjelder for systemet skal legges ved. 6. TJENESTER I FORBINDELSE MED LEVERANSEN 7.1. Installasjon Leverandør skal gjennomføre installasjon hos kunden ved anskaffelse av system. 6.2. Opplæring Leverandør skal levere forslag til komplett opplæringsprogram med nødvendig kursmateriell. Forslaget skal inneholde pris pr. kursdag, basert på det antall kursdeltagere som leverandør mener er hensiktsmessig. Prisene baseres på kurslokaler hos kunde. Det må oppgis om prisene forutsetter et visst volum. 6.3. Innføringsprosjekt Leverandør skal med utgangspunkt i de overordnede målsettinger for prosjektet skissere: Eventuelle særlige krav til kunden i forbindelse med innføringen. Fremlegge forslag til innføringsprosjekt med angivelse av aktivitets- og ansvarskart (kunde/leverandør) med tidsplan, estimert timeforbruk pr. aktivitet for hhv. kunde og leverandør totalt. 8
6.4. Godkjenningstest Leverandøren skal levere forslag til godkjenningsprosedyre og godkjenningstest med blanketter for testene. 6.5. Konsulentbistand Det kan oppstå behov for konsulentbistand i tillegg til de tjenester som er beskrevet ovenfor. Leverandør må redegjøre for hvilken type bistand som kan tilbys samt oppgi prismatrise etter personellkategori og uttak av timer. Oppgi også eventuelle andre kostnader. 6.6. Support, brukerstøtte og vedlikehold Leverandør skal beskrive opplegg for telefonisk brukerstøtte og teknisk support, der leverandør skal kunne dokumentere tilstrekkelig kapasitet og kompetanse for nødvendig bistand til kunden. Det er en fordel om leverandør har kvalifisert personell fast til stede i Trondheim for nødvendig bistand. Leverandør skal tilby avtale om brukerstøtte basert på Statens standardavtale. Regler om omfanget skal oppgis. Leverandør skal tilby avtale om telefonisk teknisk support for kundens tekniske driftspersonell og systemansvarlige basert på Statens standardavtale. Teknisk support skal kunne eskaleres til support hos kunden. Regler knyttet til omfanget skal oppgis. Leverandør skal tilby avtale om programvareoppgradering basert på Statens standardavtale. Leverandør skal kunne tilby deltagelse i brukerforum/fagutvalg. Kursmateriell og system- og brukerdokumentasjon skal fritt kunne kopieres av kunden. 6.7. Support avtale Ved oppgraderinger/versjonsendring eller lignende, skal leverandøren levere ny oppdatert dokumentasjon samtidig. 9
213.145.168..65---------------------213.145.168.66 Internet Router mot internet (Står hos Uninett) 193.156.2.2 193.156.2.12 193.156.54.190 SonicWall VPN konsentrator Oslo 193.156.54.160/255.255.255.224 193.156.54.187 Hemmelig_1 IP: 172.16.26.0/255.255.255.0 193.156.2.1 172.16.26.1 193.156.54.192/255.255.255.224 Hemmelig_2 IP: 172.16.27.0/255.255.255.0 172.16.27.1 BV IP: 172.16.30.0/255.255.255.0 172.16.30.1 DMZ Sone IP: 193.156.55.0/255.255.255.0 193.156.55.1 10.3.15.10 SonicWall VPN konsentrator FW1 172.16.25.1 172.16.25.12 172.16.25.10 193.156.54.222 Løkken 172.16.25.11 ISDN/Analog dial-in DMZ-2 IP: 172.16.25.0/255.255.255.0 www.ngu.no 193.156.55.201-210 ArcIMS1 193.156.55.211 ArcIMS2 193.156.55.212 seismo 193.156.55.253 Radius 10.6.1.27 10.3.14.10 DNS 193.156.55.201 aps 193.156.55.249 Versjon 2.0 Terje Nonås ETERRA Versjon 3.0 Jostein Holthe NGU Sept. 2002 Internt nett 10.0.0.0/8 AD/NT Compaq1 10.6.1.1 Fil/print Compaq2 10.6.1.2 Agresso Compaq3 10.6.1.11 Mail Compaq4 10.6.1.12 Intranett Compaq5 10.3.5.100 PDC Compaq6 ArcIMS1 Compaq7 ArcIMS2 Compaq8 10.6.1.30 ArcSDE Compaq9 10.6.1.31 Oracle Compaq20 10.6.1.23 Citrix Radius 10.6.1.27 Dell1 10.11.4.10 Backup Dell3 www Dell4 10.6.1.22 Diverse Dell5 10.6.1.24 Oracle test
11