ELSAK Tilbud på elektronisk saksbehandlings- og arkivsystem

Transkript

1 ELSAK Tilbud på elektronisk saksbehandlings- og arkivsystem Bilag : 1.2 Tittel: Kundens tekniske spesifikasjon 2008

2 INNHOLDSFORTEGNELSE 1. Generelt Teknisk infrastruktur Nettverk Nettsentriske datarom Leverandørtilknytninger Tjenesteleveranser på leide linjer Tjenesteleveranser på lokal kobber/fiber Tjenesteleveranser over Internett Sentralt driftsmiljø Katalogtjenester og integrasjon Autentisering Integrasjoner Andre krav: Skanning Testmiljø Teknisk Kravspesifikasjon Generelt Kravtabell Generelt Forklaring til svartabellene under Tekniske krav Maskinvare, ytelser og tilgjengelighet/oppetid Vedlikehold og support

3 1. Generelt Dette er en teknisk beskrivelse av sentralt driftmiljø i Oslo kommune og omfatter i tillegg til det sentrale driftsmiljøet også OKDN-MAN fra aksesspunktet på det enkelte tjenestested i en virksomhet og til brannmurene som definerer driftsmiljøet nettverksmessig. Ulike plattformer og tjenester som vil kunne ha innflytelse på valg av applikasjon er også beskrevet. For Undervisningsbygg Oslo KF, heretter kalt Undervisningsbygg må tilbudet omfatte 2 ulike scenarier: I dag har vi et blandet miljø hvor enkelte applikasjoner kjøres sentralt (CP og Agresso), mens de øvrige kjøres lokalt med lokale servere i et tradisjonelt LAN. Det er planen at UNDERVISNINGSBYGG skal over på sentral drift i Oslo Kommune for samtlige systemer slik dette dokumentet beskriver, men tidsplanen er ikke klar. Ved innføring av nytt elektronisk arkiv-/saksbehandlingssystem vil vi derfor måtte forholde oss til den aktuelle situasjonen i implementeringsperioden. Tilbudet må tydelig vise eventuell kostnad ved å implementere systemet i dagens infrastruktur og gå over til sentral drift på et senere tidspunkt. UNDERVISNINGSBYGG har i dag ca. 130 PC-er med Windows XP operativsystem i et 100 Mbit lokalnett. 2. Teknisk infrastruktur 2.1 Nettverk Oslo kommune har etablert et felles nettverk for alle kommunens virksomheter som dekker over 1400 lokasjoner med over brukere. Det er koblet opp mot eksterne nett. Dette nettverket, OKDN-MAN er bærer av alle tjenester fra sentralt driftsmiljø. OKDN MAN består av følgende hovedkomponenter: Et kjernenett bestående av 3 noder, to av disse er lokalisert i kommunens nettsentriske datarom. Kjernenodene er koblet sammen i en ringstruktur med 2 x10gbit/s mellom hver node. Nodene er bygget opp med Cisco MPLS-utstyr. Et distribusjonsnett med ca 20 noder som dekker hele Oslo by. Distribusjonsnettet er bygget opp i ringstrukturer der hver ring er koblet til 2 forskjellige kjernenoder for å oppnå en meget høy grad av redundans. Hver distribusjonsnode har 2 fiberforbindelser i separate traseer. Hastigheten i hver distribusjonsring er 10Gbit/s

4 Et aksessnett som kobler det enkelte tjenestested til distribusjonsnettet. I dette nettet brukes fiberaksesser (1Gbit/s) for de største tjenestestedene og kobberaksesser (SHDSL) til alle øvrige tjenestesteder. Normalt er minimum hastighet 2Mbit/s (2,3Mbit/s SHDSL ATM-overhead), men for noen få tjenestested med dårlig kvalitet på kobber kan hastigheten være lavere. To nettsentriske datarom (Digiplex og Verizone) som inneholder blant annet sentralt nettverksutstyr og nettsentrisk driftsmiljø 2.2 Nettsentriske datarom De nettsentriske datarommene er samlokalisert med to av kjernenodene i OKDN-MAN. Foruten kjernenode og en distribusjonsnode inneholder disse nettsentriske datarommene også andre sentrale nettverkskomponenter som høyhastighets internettaksesser, sentrale brannmurer i tillegg til kommunens sentrale driftsmiljø. Oslo kommune har et sentralt driftsmiljø for felles- og sektorsystemer samt verdiøkende tjenester i tillegg til et felles driftsmiljø for de virksomheter som ikke har egne lokale driftsmiljøer. For en nærmere beskrivelse av plattform som inngår i det sentrale driftsmiljøet se Nettsentrisk driftsmiljø

5 2.3 Leverandørtilknytninger OKDN-MAN er bygget opp for å kunne levere tjenester til sluttbrukerne i kommunen fra de sentrale datasenterne. Veien fra tjenesteproduksjon til sluttbruker kan illustreres slik: Hele topologien fra og med Leverandør-gatewayene (L-GW) er redundant, og spredt over multiple lokasjoner. Internett-baserte tilganger er også redundante, da det er tilkoplinger til Internett på begge de sentrale datasenterne Tjenesteleveranser på leide linjer For å kople til en tjenesteleveranse til OKDN-MAN vha leide linjer (synk/asynk) tilbys hastigheter opptil 2 Mbps. Det finnes L-GWer i begge de sentrale datasenterne for å terminere slike forbindelser. 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 leide linjer én til hvert datasenter. For å bevare fullstendig feiltoleranse må routerne hos leverandøren være koplet sammen, for å registrere evt brudd i bæretjenesten inn mot OKDN-MAN:

6 2.3.2 Tjenesteleveranser på lokal kobber/fiber Dersom leverandøren er til stede på Digiplex og/eller MCI, kan OKDN-MAN tillate lokale tilkoplinger ved hjelp av kobber- eller fiberforbindelser. For slike tilkoplinger tilbyr OKDN-MAN hastigheter på opptil 10 Mbps. Det finnes L-GWer i begge datasentrene for å terminere slike forbindelser. Disse er koplet sammen for å tilby redundans utover (mot leverandøren). Dersom leverandøren ønsker å ta dette i bruk, må ikke det lokale utstyret knyttes sammen i leverandør-enden. Oppkoplingen blir slik: Tjenesteleveranser over Internett OKDN-MAN har også redundante Internett-forbindelser. Disse kan brukes for leverandør-aksess, med eller uten VPN-basert kommunikasjon. Det er bygget redundans i OKDN-MAN 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 OKDN-MANs ståsted

7 2.4 Sentralt driftsmiljø Det pågår en sentralisering og standardisering som på sikt vil gjøre at alle lokale driftsmiljøer vil bli sentralisert. Det sentrale driftsmiljøet er delt på 2 lokasjoner, Ulven og Vollebekk. Det er ca. 16 km mellom lokasjonene og redundante fiberforbindelse mellom dem. Det sentrale driftsmiljøet er satt opp med fail-over mellom lokasjonene. Oslo kommunes nettsentriske driftsmiljø innholder følgende plattformer som er relevante: Terminalservere Applikasjonshotell Databaser Terminalserverfarm: Oslo kommunes har en sentralt terminalserverfarm som de enkelte virksomhetene benytter til å kjøre lokale applikasjoner. Terminalserverfarmen er basert på Citrix Presentation Server 4,5 med Microsoft Windows Applikasjonshotell: Applikasjonshotellet er basert på Vmware ESX 3.0 og benyttes primært til virksomhetsspesifikke applikasjoner og øvrige installasjoner som det er kostoptimalt å virtualisere

8 Databaser: Oslo kommune har innenfor databaser standardisert på Oracle og MsSQL. Det er bygget særskilte databasehoteller. Innenfor MsSQL er det standardisert på SQL Server Innenfor Oracle benyttes alle versjoner fra 8 og oppover. All maskinvarearkitektur er basert på X86 standard med unntak av noen eldre servere av merke SUN. 3 Katalogtjenester og integrasjon 3.1 Autentisering Katalogmiljø i Oslo kommunes sentrale driftsmiljø består av et domene, OsloFelles som er opprette i Microsoft Active Directory og en LDAP installasjon, PRK, Person- og ressurskatalog. All autentisering på nye systemer i kommunen skal fortrinnsvis skje 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 med AD ved hjelp av MetaDirectoryServices, MDS. Alle maskinvareressurser opprettes direkte i AD ved implementering. Det skal være mulig å styre tilgang til ulike deler av systemet individuelt og/eller basert på avdelingstilhørighet, om det er ansatte, innleide, eksterne brukere osv. 3.2 Integrasjoner Systemet skal kunne integreres mot øvrige systemer som benyttes av Undervisningsbygg: Critical Path (CP), CP er Oslo kommunes e-postsystem. I tillegg benyttes CP s kalendertjeneste. For integrasjon mellom CP og øvrige applikasjoner benyttes standard IMAP grensesnitt. Oslo kommunes plattform for interaktive tjenester er basert på BEA og all integrasjon mot øvrige systemer skal fortrinnsvis skje over denne plattformen ved hjelp av Webservices. UNDERVISNINGSBYGG benytter i tillegg følgende applikasjoner som det skal være integrasjon mot: Landlord FDV-system levert av 5D. Landlord benytter Trix for dokumentstyring. Prosmart styringssytem basert på Iknowbase og Oracle levert av evita. Exie prosjektverktøy. MS Outlook som E-post og kalendersystem (benyttes som front end mot CP). Agresso økonomisystem. Dagens arkivsystem Doculive. Det må vurderes integrasjon mot dette og/eller konvertering av data fra Doculive inn i nytt arkivsystem

9 Om CP: Se bilaget CP-API for nærmere beskrivelse av CP. Prosjekt: Elektronisk saksbehandlings- og arkivsystem Om Landlord: Vedrørende filformater som er i bruk i Eiendomsavdelingen: Stort sett standard MS formater doc, exl, + muligens noen project filer, i tillegg PDF og jpg/tiff på bilder, kan også være enkelte html filer der man lagrer mailer. Det lagres ingen dokumenter i Landlord kun tabeller i databasen Dokumenter lagres/skal lagres i Trix. Landlord benytter Progress database. Om Trix: Trix benytter MS SQL database og er levert av Provanum. Om Prosmart: ProSmart er et system som ikke inneholder originaldokumenter, kun en behandlet PDFkopi som legges inn i et databasefelt på vår Oracle-database (via en administratorfunksjon). Det er imidlertid strenge krav til originaldokumenter utarbeidet av Undervisningsbygg. Dette gjelder hovedsakelig struktur, innhold (påkrevd informasjon), språk og godkjenning (to steg). Det er mulig dette kan ivaretas ved saksbehandlingskravene. I tillegg skal originaldokumentene inneholde linker til eksterne URL'er og interne iknowbase registrerte dokumenter. Konvertering til PDF må ta med disse linkene. Dokumentene i ProSmart skal gis et dokumentnummer og skal gis en versjon. Hvordan dette er bygd opp, er spesifisert i dokumentet "Nummererings- og versjonsstyringssystem for Undervisningsbygg". Dokumentet er egentlig kun gyldig for dokumenter knyttet til styringssystemet, men gir inntrykk av å gjelde for alle dokumenter i Undervisningsbygg. Dette er ikke tilfelle. Det er ønskelig at nummer tildeles automatisk for nye dokumenter og at versjonen økes automatisk basert på input om ny versjon skyldes en større eller en mindre endring. I noen dokumenter skal nummer og versjon skrives inn, i andre ikke. Men informasjon om dokumenttype, forfatter (ansvarlig), dokumentets dato, godkjenningsdato skal knyttes til dokumentet. I originale Word-dokumenter skal dette inn i dokumentets "register" for Egenskaper. Når et dokument endres, skal gammel versjon tas vare på (i PDF-format). Dokumenter som utgår skal også tas vare på. Det er et krav at disse historiske dokumentene skal kunne hentes frem etter behov

10 I dag håndterer ProSmart selv de malene som er spesifisert som en del av styringssystemet (dvs. at standard maler for Word, Excel, Powerpoint, etc. ikke er det). Dette er håndtert på den måten at ProSmart må vite hvor malene ligger, og alle malene må ligge på samme sted. Malen må også være av maltype, dvs. *.dot for Word, *.xlt for Excel og *.mpt for Project. Det er også noen spesielle tekniske "krav" knyttet til ProSmart, men disse er mer av programtekniske forhold og vil ikke nødvendigvis ha noe med integrasjonen mellom ELSAK og ProSmart å gjøre. ProSmart benytter en Oracle database. Om Doculive: Hjelperegistre i DocuLive eller andre systemer for mulig overføring til ELSAK: Et hjelperegister kan inneholde opplysninger som ikke er absolutt nødvendige for journalføringen, men som er arbeidsbesparende i forbindelse med registreringen og samtidig er med på å sikre kvaliteten på opplysningene, i tillegg til at det kan tjene som en selvstendig informasjonskilde. Hjelperegistre som kan være ønskelig å få flyttet med over i nytt system er: Sekundærkoder (forkortelse for skolenavn) Prosjekt (prosjektnummer)? Arkivkoder (etter Oslo kommunes arkivnøkkel) Adressater Paragrafer I tillegg kan det være ønskelig å få flyttet over brukeradministrasjon/linjeorganisasjon fra DocuLive Administrator eventuelt fra Agresso. Om Exie: Prosjekter får et prosjektnummer som opprettes i Exie. 3.3 Andre krav: Webcruiter Det kan være aktuelt å mottat søknader fra web via Webcruiter eller lignende verktøy Viewer for tegningsfiler Prosjekthotellet bør ha en tegnings-viewer som kan vise og printe plt-filer, det kan også være en fordel om det er viewer for dwg-filer

11 3.3.3 Sende tegninger for plotting/utskrift hos OsloKopisten Prosjektet har en avtale med OsloKopisten om plotting og utsendelse av tegninger. Det bør være mulig for deltagerne å kunne sende en pakke med tegningsfiler, tegningslister og distribusjonslister direkte fra Prosjekthotellet til OsloKopisten pr. e-post Backup og helpdesk Gode backup-rutiner slik at data ikke går tapt er en forutsetning Backup bør kunne hentes i løpet av kort tid Brukerstøtte med rask respons og svar på spørsmål er en forutsetning. Det kan være en fast kontaktperson, eller et fast telefonnummer Det bør være mulig å melde inn spørsmål på e-post og få svar innen påfølgende virkedag hjelpe-menyer eller brukerveiledning lett tilgjengelig i løsningen eller på internett vil være en fordel Skanning Tilbudet må inneholde en hensiktsmessig løsning i form av maskin- og programvare for innskanning av papirbaserte dokumenter. Dette skal baseres på at opptil 4 brukere i postmottak foretar innskanning, men systemet må likevel kunne håndtere flere brukere i andre funksjoner Testmiljø Tilbudet må inneholde testmiljø (applikasjon/database). Dette skal benyttes for utprøving av nye funksjoner, nye versjoner etc. før de implementeres i vårt produskjonsmiljø. 4 Teknisk Kravspesifikasjon 4.1 Generelt Følgende tekniske kravspesifikasjon bygger på de krav til virksomhetsspesifikke applikasjoner som er gitt av sentralt driftsmiljø med OKDN-MAN som tjenestebærer og den enkelte virksomhets anvendelsesrelaterte behov til integrasjon med øvrige systemer både internt i Oslo kommune og eksternt med øvrige systemer. For øvrig er det slik at Undervisningsbygg som andre virksomheter er i kontinuerlig utvikling og systemet må ha stor grad av fleksibilitet og skalerbarhet slik at det kan håndtere økende volumer så vel som nye måter å jobbe på. Ikke minst må systemet utvikles slik at det dekker til enhver tid gjeldende krav fra myndigheter til arkivering av dokumenter

12 5 Kravtabell 5.1 Generelt Kravtabellene er en sammenfatning av alle krav beskrevet tidligere i dette vedlegget. Kravene er gruppert i henhold til evalueringskriterier og er listet i to tabeller. 5.2 Forklaring til svartabellene under Det kreves at Leverandøren, i tillegg til mer utfyllende løsningsbeskrivelse i øvrige vedlegg, svarer på samtlige rader i svartabellene under. Ferdig utfylte tabeller skal gi en oppsummert oversikt over i hvilken grad Leverandørens tilbud er i samsvar med Kundens forespørsel og det skal være samsvar mellom svar i kravtabellen og den mer utfyllende løsningsbeskrivelsen. Sistnevnte skal komplimentere kravtabellen. Det svares ved å fylle ut Leverandørens svarkolonne J/D/N. Kodene skal forstås slik0 Kode J D N Betydning Ja, kravet/ytelsen innfris/leveres ved leveranse og er inkludert i pristilbudet Delvis, er delvis med i løsningen. Her må leverandør spesifisere hva som er med og hva som ikke er med i tilbudet og inkludert i pristilbudet Nei, er ikke inkludert i tilbudet Leverandøren kan benytte feltene i kolonnen Eventuell kommentar dersom dette er nødvendig for å gi korrekt svar. Dersom Leverandøren har svart J i kolonnen J/D/N kan ikke kommentaren svekke tilbudt ytelse. I så fall må J endres til D eller N. Dersom svar J eller D er betinget av tilpasninger skal dette angis selv om tilpasningen ikke har økonomiske konsekvenser. Kunden ser helst at feltet Eventuell kommentar ikke benyttes med mindre Leverandøren ser dette strengt nødvendig for å gi svar som er korrekt i forhold til tilbudet. Dette for å forenkle sammenlikningen av innkomne tilbud. Under hver kravtabell er det satt av plass til utdypende forklaring. Denne skal fortrinnsvis benyttes dersom det er behov for utfyllende forklaring som omhandler flere (går på tvers ) av kravene i overliggende kravtabell. Manglende utfylte rader tolkes som Nei, ikke inkludert i tilbudet

13 5.3 Tekniske krav Krav Kundens forespørsel Tilbyders svar Nr.: Tekst J/D/N Eventuelle kommentarer 1 Applikasjonen skal kunne benytte Oracle versjon 9 eller høyere som database. 2 Applikasjonen skal kunne benytte den tekniske infrastruktur som er beskrevet i sentralt driftsmiljø. 3 Leverandøren skal som en del av tilbudet levere en detaljert løsningsbeskrivelse på hvordan applikasjonen skal implementeres i sentralt respektive desentralt driftsmiljø 4 Databaser i løsningsforslag skal kunne implementeres på sentralt databasehotell. 5 Applikasjonen skal kunne installeres på virtuell server i applikasjonshotell 6 Testsystem: Leveres testsystem som en del av standard leveranse? 7 Integrasjon mot: Outlook/CP Prosmart Exie Trix Landlord Agresso 8 Konvertering: Kan data fra eksisterende system Doculive konverteres inn i nytt system? Angi i så fall estimert tidsforbruk. 9 Har leverandøren en innarbeidet standard prosedyre for implementering av systemet?

14 6. Maskinvare, ytelser og tilgjengelighet/oppetid Oslo Kommune har en samkjøpsavtale på servere med DELL og Undervisningsbygg må forholde seg til denne. Leverandøren skal derfor ikke levere maskinvare, men må spesifisere og anbefale passende maskinvare for å oppnå tilgjengelighet, ytelse og kapasitet i hht. kravspesifikasjonen. Videre må spesifiseres versjoner og evt. nødvendig patchnivå av operativsystem, databaser osv. Leverandøren må beskrive oppdateringsfrekvens i forhold til når innlagte data er søkbare og annen relevant informasjon i denne forbindelse. 7. Vedlikehold og support Det skal tilbys vedlikeholdsavtale og som opsjon supportavtale