Transcript Bilag 1 - Oppdragsgivers behovsspesifikasjon v10 endelig.pdf

2013
Bilag 1
Behovsspesifikasjon
Rammeavtale på konsulenttjenester ifm innføring av Microsoft
infrastruktur ved Høgskolen i Lillehammer
BJØRNULF HAFSTAD 27.9.2013
Innholdsfortegnelse
1
Innledning ...................................................................................................................................3
1.1
2
Prosjektet ...................................................................................................................................3
2.1
Del 1: Migrering fra Novell til Microsoft infrastruktur for server nettverk. ............................3
2.1.1
Hyper-V og Azure .........................................................................................................3
2.1.2
IDM konnektor til AD ...................................................................................................3
2.1.3
Konnektor til O365 .......................................................................................................4
2.2
Del 2: Migrering fra Lotus Notes/Domino til Outlook/Exchange ...........................................4
2.2.1
Synkronisering av TimeEdit ..........................................................................................4
2.2.2
Avvikling av Lotus Notes...............................................................................................4
2.3
Del 3: Implementering av ny programvare ...........................................................................5
2.3.1
Lync .............................................................................................................................5
2.3.2
Etablering av løsning for «følg meg» trykk....................................................................5
2.3.3
Microsoft System Center ..............................................................................................5
2.3.4
SharePoint ...................................................................................................................5
2.4
Del 4: Diverse ......................................................................................................................5
2.4.1
Selvbetjeningsportal ....................................................................................................5
2.4.2
Serviceavtaler ..............................................................................................................6
2.4.3
Rest av oppgaver som ikke er tatt under andre punkter ...............................................6
2.5
Generelt om helheten i prosjektet .......................................................................................6
2.5.1
Bør krav og skal krav ....................................................................................................6
2.5.2
Forprosjekt ..................................................................................................................6
2.5.3
Arkitektur ....................................................................................................................6
2.5.4
Programvarelisenser ....................................................................................................7
2.5.5
Outsourcing og skytjenester .........................................................................................7
2.5.6
Automatisering ............................................................................................................7
2.5.7
Prosjektledelse, kompetanseoverføring og utnyttelse av interne medarbeidere...........7
2.5.8
Lync og videokonferanser ............................................................................................8
2.5.9
Opplæring....................................................................................................................8
2.6
3
Rammeavtale ......................................................................................................................3
Fremdriftsplan for gjennomføring av prosjektet...................................................................8
Dokumentasjon av IT-organisasjon og eksisterende tekniske løsninger........................................8
3.1
IT- tjenesten ........................................................................................................................8
3.1.1
Organisasjon ................................................................................................................8
3.1.2
Intern kompetanse ......................................................................................................9
1
Versjon 1.0
3.2
Dokumentasjon av eksisterende IT-løsninger .......................................................................9
3.2.1
3.2.1.1
Hardware med VMware ...........................................................................................9
3.2.1.2
Virtuelle serverere med Windows 2003/2008 R2 (13) ............................................ 10
3.2.1.3
Virtuelle servere med Netware 6.5 (4) .................................................................... 10
3.2.1.4
Virtuelle servere med SLES / OES 2 (10) .................................................................. 10
3.2.1.5
RedHat/Debian/ Ubuntu (12) ................................................................................. 10
3.2.1.6
Fysiske servere: ...................................................................................................... 11
3.2.2
Lagring ....................................................................................................................... 11
3.2.3
Backup ....................................................................................................................... 11
3.2.4
DNS ........................................................................................................................... 12
3.2.5
DHCP ......................................................................................................................... 12
3.2.6
IDM ........................................................................................................................... 12
3.2.6.1
Novell trestruktur................................................................................................... 14
3.2.6.2
Metakat trestruktur ............................................................................................... 15
3.2.7
5
6
Fagsystemer .............................................................................................................. 15
3.2.7.1
Arkivsystem ........................................................................................................... 15
3.2.7.2
OTRS ...................................................................................................................... 15
3.2.7.3
Trio ........................................................................................................................ 15
3.2.7.4
TimeEdit ................................................................................................................ 15
3.2.8
4
Servere ........................................................................................................................9
Nettverk .................................................................................................................... 15
Tildelingskriterier ...................................................................................................................... 16
4.1
Pris 40%............................................................................................................................. 16
4.2
Kvalitet 60% ...................................................................................................................... 16
4.2.1
Kompetanse og erfaring ............................................................................................. 16
4.2.2
Estimater ................................................................................................................... 16
4.2.3
Kompetanseoverføring .............................................................................................. 17
4.2.4
Tidsrammer ............................................................................................................... 17
4.2.5
Kompletthet .............................................................................................................. 17
Krav til tilbudet ......................................................................................................................... 17
5.1
Løsningsforslag .................................................................................................................. 17
5.2
Prisskjema ......................................................................................................................... 17
5.3
Øvrige krav til dokumentasjon ........................................................................................... 17
Tilbudsskonferanse ................................................................................................................... 17
2
Versjon 1.0
1 Innledning
Høgskolen i Lillehammer (HiL) har som sitt formål å drive høyere utdanning og forskning. Høgskolen
har ca. 4800 studenter, 700 av dem er deltids- og fjernundervisningsstudenter, og over 300 tilsette.
HiL har hatt en dynamisk utvikling de siste årene. Studentantallet har blitt fordoblet på 10 år, det
same gjelder avlagte eksamener, utdanning av kandidater i bachelor- og masterutdanninger, antall
søkere og antall studieprogrammer på bachelornivå.
Høgskolen i Lillehammer er inne i en periode med omstilling til ny IT-infrastruktur som er beskrevet
nedenfor. Vi skal skifte ut hele vår grunnleggende arkitektur og satse på Microsoft løsninger som
hovedplattform på servere og infrastruktur. Men på noen supplerende områder vil vi likevel velge
noen annet der vi mener å ha en god begrunnelse for det.
1.1 Rammeavtale
Vi er ute etter å få en rammeavtale med en leverandør der vi velger et konsulentfirma til å bistå oss
med overgang til med Microsoft infrastruktur de nærmeste 3 år.
2 Prosjektet
2.1 Del 1: Migrering fra Novell til Microsoft infrastruktur for server nettverk.
Vi skal migrere fra Novell/eDirectory til Microsoft/AD. Vi vil skifte ut alle våre Novell servere som i
dag betjener fil og print. Det nye Microsoft nettverket bør senest være i drift i løpet av januar 2014.
Del 1 innebærer følgende oppgaver (se punkt 2.5 for mer detaljer):









2.1.1
Mulig etablering av Hyper-V miljø for de nye serverne i kombinasjon med Azure.
Ny trestruktur i AD
Migrering av lagrede data
Konnektor fra IDM til AD
Konnektor fra IDM til O365 (eller fra AD til O365)
Etablering av en løsning for utrulling av programvare som kan benyttes til f.eks. oppgradering
og utskifting av OS på alle klientmaskiner.
Annen nyttig automatisering ved hjelp av (System Center)
Kompetanseoverføring
Avvikling av Novell servere
Hyper-V og Azure
Med noen forbehold tror vi at all ny infrastruktur bør etableres i Hyper-V. 2/3 av kapasiteten i
nåværende VMware løsning er ikke utnyttet så det er interessant å benytte eksisterende hardware.
Får å bli helt sikre på at vi skal benytte Hyper-V må ha trygghet for er at det ikke er tekniske
bindinger til eksisterende løsninger som ikke kan løses i Hyper-V. Vi er interessert i å benytte Azure i
kombinasjon med lokale løsninger. Vi er også opptatt av å få maksimalt ut av System Center. Den
økonomiske siden med lisensiering er også en faktor for at vi skal bli sikre på at vi går for Hyper–V.
2.1.2
IDM konnektor til AD
HIL benytter NetIQ IDM til Identiy Management (se punkt 3.2.6). For å populere AD med brukerdata
trenger vi en konnektor mellom IDM og AD. Den skal stort sett gjøre det samme som «edir2edir»
konnektoren gjør i dag (se bilag 1a). Dette handler først og fremst om å konfigurere og tilpasse en
standard NetIQ AD konnektor som allerede finnes. Konnektoren skal opprette og slette brukere i
3
Versjon 1.0
henhold til deres status i IDM-katalogen. Det går frem av bilag 1a hvilke datafelter vi flytter over til
produksjonssiden.
Det er noen detaljer med hensyn til håndtering av epostadresser som denne konnektoren tar seg av
som er litt spesielt for HIL. Men dette tror vi ikke er spesielt kompliserende. Privat epostadresse blir
kopiert til offisiell epostadresse og skrevet tilbake til IDM-basen. Utenom dette så er det ganske
standard det som gjøres med overføring av data.
2.1.3
Konnektor til O365
O365 konnektoren skal levere persondata til Office 365. Den skal både opprette nye brukere og
slette brukere som har sluttet. Synkronisering av passord er også en viktig funksjon. O365
konnektoren kan løses på to forskjellige måter. I utgangspunktet vil vi ha en direkte konnektor fra
IDM til O365 fordi vi intuitivt mener at det blir best. Men vi er åpne for at dette også kan løses med
en kobling via AD dersom det finnes overbevisende argumenter for at det er en fordel.
Spesifikasjonene blir ikke veldig forskjellig fra AD konnektoren. Det finnes det også allerede en
standard O365 konnektor for IDM som kan tilpasses. (jfr. Denne linken:
https://www.netiq.com/documentation/idm402drivers/office365/data/bookinfo.html).
2.2 Del 2: Migrering fra Lotus Notes/Domino til Outlook/Exchange
Dette innebærer følgende:









2.2.1
Etablering av Outlook/Exchange for ca. 325 brukere
Arkivering av en andel av lagrede data (antakelig meldinger fra det siste året + overlapp og
backupløsning for resten).
Migrering av lagrede data
Synkronisering av fraværsmarkering med telefonsentral via Trio eller tilsvarende.
Synkronisering av kalendere fra TimeEdit timeplansystem via ICAL.
Etablering av epost og kalender tjeneste for mobiltelefoner.
Etablering av SharePoint. I første omgang som plattform for vårt nye arkivsystem «Public
360».
Kompetanseoverføring
Avvikling av Lotus Notes (inkludert erstatning av funksjoner. Noe av dette kan utsettes)
Synkronisering av TimeEdit
Dette dreier seg om en helt triviell synkronisering via iCal grensesnitt og er antakelig standard
funksjonalitet i epostsystemet. Se for øvrig vårt TimeEdit grensesnitt:
https://no.timeedit.net/web/hil/db1/timeplan/ri1Q7.html.
2.2.2
Avvikling av Lotus Notes
Når det gjelder epost og kalender er det klart at Outlook/Exchange kan erstatte dette. Det er likevel
noen utfordring med hensyn til overgangsordninger mellom gammel og ny epost. Her blir oppgaven å
finne en løsning som ivaretar både det kortsiktige behovet for overlapp og den mer langsiktige
arkivering. Det er også mye vi bruker Notes til når det gjelder deling av data som ikke vil bli løst via
Exchange. Det blir en del av denne fasen å legge en plan for hva vi skal gjøre, ikke nødvendigvis å
gjennomføre alt her.
Det er flere veier vi kan gå. Den mest nærliggende mulighet er å tenke det nye arkivsystemet og
øvrige muligheter i SharePoint. Medarbeiderportalen (Compendia) og Wiki-sidene våre kan også
være kandidater for å overta deler av det vi nå benytter Notes til. Uansett valg av løsning innebærer
4
Versjon 1.0
det en form for migreringsjobb som må gjøres. Deler av dette kan evt. avtales å gjøres i senere faser
av prosjektet.
2.3 Del 3: Implementering av ny programvare
Tidspunktene for gjennomføring av denne delen er mer fleksible og vi kan avklare det i forbindelse
med forprosjektet.
2.3.1
Lync
Vi skal innføre Lync som felles helhetlig kommunikasjons plattform. Målet er at vi etter hvert skal
avvikle telefonsentralen og fjerne telefonapparatene slik at PCen også blir det primære
telefonapparatet. Mobile enheter vil også spille en viktig rolle. Men denne migrerings-prosessen må
vi ta gradvis. Første skritt blir å få opp Lync for alle ansatte. I løpet av 2014 kan det komme en
beslutning om at vi vil fase ut telefonsentralen og avvikle telefonapparatene. Vi tenger veiledning på
hvordan vi evt. best gjør denne prosessen. Forbildet vårt er Høgskolen i Nord-Trøndelag som har
gjort et vellykket prosjekt på dette.
2.3.2
Etablering av løsning for «følg meg» trykk
Vi har sett på Equitrac som en løsning for «følg meg trykk», som andre høgskoler har gode erfaringer
med. Vi ønsker å implementere en tilsvarende løsning.
2.3.3
Microsoft System Center
System Center er en omfattende applikasjon med mange muligheter. SC skal allerede være etablert i
del 1 av prosjektet. Men vi ønsker å gå dypere i utnyttelsen av dette i denne fasen. Her vil vi ha
anbefalinger fra leverandøren og vi ønsker å avklare i forprosjektet hva vi vil prioritere. Vi har tatt i
bruk flere av ITIL prosessene og har et eget verktøy (OTRS) for service desk. Vi ser muligheter for å få
en erstatning for OTRS og ytterligere støtte for ITIL-prosesser.
2.3.4
SharePoint
Når vi likevel må ha SharePoint i forbindelse med arkivsystem er det verdt å se på hva vi ellers kan
bruke dette til.
Vi henviser til drøftingen under punkt 2.2.2 angående erstatning for Notes. Her kan SharePoint være
et alternativ. SharePoint har for øvrig egne kvaliteter utover dette som kan være interessante. Vi
ønsker en optimal utnyttelse av SharePoint. Her trenger vi råd før vi bestemmer detaljene.
2.4 Del 4: Diverse
2.4.1
Selvbetjeningsportal
Vi har en del manuelle rutiner som tar mye tid som vi derfor ønsker å automatisere. Det gjelder f.eks.
opprettelse og avvikling av datakontoer i forbindelse med tiltredelse og fratredelse av ansatte. Vi
bruker pr. i dag SAP som personalsystem. SAP har flere eksportmulighet og vi ønsker å importere
data herfra og automatisk generere kontoer via IDM løsningen vår.
Vi har lagt merke til at flere leverandører har produkter som benytter System Center som motor i
løsninger som ligger på nivået over og forenkler bruken av SC. Vi har sett på slike løsninger og
bedømmer at vi vil ha gevinst av å innføre noe slikt. Det som imidlertid er et viktig krav for oss er at vi
får utnyttet persondata i IDM løsningen (se punkt 3.2.6). Det kan løses enten via AD eller ved en
direkte konnektor til IDM. Det siste er i utgangspunktet den foretrukne løsningen. Selvbetjening for
brukere er et viktig stikkord i dette bildet.
5
Versjon 1.0
En annen viktig side ved et verktøy av denne typen er å få en hjelp til, raskere å ta i bruk System
Center. Vi har inntrykk av at det tilbys støtte for flere nyttige prosesser som er alminnelige i de fleste
organisasjoner. Vier også spesielt interessert i løsninger som kan støtte ITIL prosesser.
2.4.2
Serviceavtaler
Vi vet ikke nøyaktig hva vi trenger av serviceavtaler. Vi forplikter oss ikke til å tegne serviceavtale
under denne anskaffelsen. Men i det minste vil vi antakelig trenge en form for beredskapsavtale der
vi kan eskalere saker som vi ikke klarer selv. I en innledende fase bør det være korte responstider
som kan forlenges når vi selv er blitt mer fortrolig med løsningene.
Vi ønsker konkret tilbud på beredskapsavtale for 12 måneder med tilgang til 30 minutter rask
konsultasjon om det oppstår en krisesituasjon og deretter en responstid på 8 virketimer med å sette
konsulenter på jobben med konkret problemløsning. Arbeid betales i så fall etter timepris.
2.4.3
Rest av oppgaver som ikke er tatt under andre punkter
De øvrige delene av prosjektet kan ha gjort oss oppmerksom på ting som vi ikke har klart å beskrive
så langt. Det kan også være at det er biter av ting som vi underveis i prosjektet har valgt å utsette i
første omgang og vil gjennomføre i slutten av prosjektet i stedet.
2.5 Generelt om helheten i prosjektet
2.5.1
Bør krav og skal krav
På grunn av at noe av det vi etterspør er knyttet til spesiell teknologi som vi ikke forventer at alle
leverandører skal beherske har vi en del punkter der vi ikke krever at tilbyderne må gi tilbud på. Men
vi understreker at det er en fordel om de kan alliere seg med underleverandører. Det vil også bli tatt
hensyn til hvor komplett tilbudet er under kvalitet i evalueringen av de enkelte tilbudene. I
prisskjema (bilag 7a) er det lagt inn koder (SK og BK) som angir hvilke krav som vi anser som bør krav
og skal krav.
Det er også noen felter uten kode. Det betyr at det er helt åpent om man vil legge inn noe på dette
punktet. Det dreier seg om evt. egne tiltak for kompetanseoverføring. Vi lar det være opp til
leverandøren om de vil ha noen egne tiltak for dette eller om de vil ta det som en integrert del av det
andre. Vi har ingen preferanser i så måte.
Vi forbeholder oss retten til å kjøpe deler som er bør krav fra alternative leverandører dersom den
som vinner anbudet ikke kan gi oss dette med en tilstrekkelig kvalitet.
Hvis det ikke er gitt tilbud på skal-kravene vil tilbudet bli forkastet.
2.5.2
Forprosjekt
Detaljer i hva som skal gjennomføres ønsker vi å avklare med den valgte leverandøren i gjennom et
forprosjekt.
Når det gjelder framdrift har vi noen tidsrammer for når ting må være gjennomført. Overgang til MS
AD servernettverk og skifte av epost til Exchange må gjennomføres tidligst januar 2014 og senest
mars 2014. Andre deler av prosjektet er mer fleksibelt og må avklares i løpet av forprosjektet.
2.5.3
Arkitektur
Vi ønsker å fjerne mye av det som er basert på Novell i vår arkitektur. Men vi ønsker å beholde NetIQ
IDM løsningen (se punkt 3.2.6) som pr. dato benytter SUSE Linux som serverplattform og edirectory
som database. Vi ønsker i prinsippet å kjøre IDM på MS server, men vi avventer at noen problemer
som andre har erfart med dette blir løst først.
6
Versjon 1.0
2.5.4
Programvarelisenser
Programvarelisenser er ikke en del av anbudet fordi det er allerede tatt hånd om via et anbud som
hele sektoren hadde sammen. Det er Crayon som er leverandør av softwarelisenser for
Microsoftprodukter. Vi benytter oss av Selct og Campus (EES) lisensiering. Dette kan være en faktor i
prosjektet fordi det kan ha betydning for hvilke løsninger vi skal velge. Som utdanningsinstitusjon får
vi spesielle vilkår. Dette er det viktig å være klar over når det skal gis råd om hvilke tekniske løsninger
som anbefales for oss.
2.5.5
Outsourcing og skytjenester
Vi lever også i en tid der forskjellige typer outsourcing blir et mer og mer levedyktig alternativ til egne
servere. Det er forøvrig på gang løsninger for sentrale serverfarmer som skal betjene hele UH
sektoren. Vi har også sett på Azure og tror at vi kan ha nytte av en slik fleksibel løsning. Vi er derfor
interessert i å benytte oss Azure.
Det vi tenker i utgangspunktet er at vi skal kjøre det meste av det vi spesifiserer på egne virtuelle
servere med Hyper-V. Men vi er åpne for at det kan tenkes andre modeller både i retning av
dedikerte servere og i retning av at servere kan ligge utenfor huset. Vi tror det optimale er en
blanding. Men vi kan ikke beskrive nøyaktig hvordan denne blandingen bør se ut, bortsett fra at
Office365 for studentene skal leveres som en skytjeneste. Vi ønsker å finne ut av dette i samarbeid
med leverandøren.
2.5.6
Automatisering
En del av prosjektet blir å innføre System Center. Men vi innser samtidig at det er et stort og
omfattende arbeid å ta i bruk dette i hele sin bredde. Vi ønsker derfor å være pragmatiske, med
hensyn til hvor fort vi tar i bruk forskjellige muligheter.
Det vi vil prioritere er det som direkte kan hjelpe oss i migrasjonsprosjektet slik som f.eks.
mekanismer for utrulling av programvare. Ellers er vi åpne for råd fra leverandøren om hva annet vi
bør innføre som gir rask gevinst.
Mot slutten av prosjektet har vi tenkt oss innføring av en selbetjeningsløsning for brukerne som
antakeligvis vil bygge på System Center.
2.5.7
Prosjektledelse, kompetanseoverføring og utnyttelse av interne medarbeidere
Vi ønsker at prosjektet skal gi størst mulig utbytte i form av kompetanseoverføring til egen IT
avdeling. Prosjektet skal gjennomføres sammen med leverandøren og vi forventer at den lokale IT
avdelingen sine egne ressurser skal utnyttes optimalt.
Vi ønsker en ekstern prosjektleder med erfaring fra tilsvarende prosjekter som samarbeider med en
intern prosjektleder og at oppgavene blir tydelig fordelt. Vi ønsker innledningsvis i forbindelse med
forprosjektet å finne den optimale blanding av bruk av egne ressurser og kjøp av konsulenttjenester.
Det betyr ikke bare mindre konsulentbruk, men like mye at konsulentene brukes slik at det skjer en
kompetanseoverføring, f.eks. gjennom veiledning av våre medarbeidere som selv gjennomfører de
mer tidkrevende deler av oppgaven. Vi kan også f.eks. leie inn noen studenter til enkle, men
tidkrevende oppgaver.
Oppsummert kan vi si at vi ikke skal bruke egen arbeidskraft til det som er vanskelig og spesielt og
som vi sjelden vil få bruk for i det daglige. Vi skal heller ikke bruke for mye interne ressurser på det
som er enkelt, men tidkrevende så lenge det stjeler kapasitet fra viktigere andre oppgaver.
7
Versjon 1.0
2.5.8
Lync og videokonferanser
Vi har allerede etablert prøvedrift på Lync og alle medarbeidere på IT pluss en del andre vi har
installert Lync. Det betyr at vi i gjennomføringen av prosjektet kan avholde videomøter og at
samarbeid for øvrig kan skje over avstand med skjermdeling osv.
2.5.9
Opplæring
Opplæring kjører vi som eget anbud. Det gjelder både kursing av IT- tjenesten og opplæring av andre
ansatte. Men det blir likevel behov for en koordinering mot dette prosjektet på flere faktorer. Den
kompetanseoverføring som skjer i gjennom deltagelse i prosjektet er selvfølgelig en viktig faktor
utover formell opplæring.
Når det gjelder vanlige ansatte tenker vi oss å organisere et korps av superbrukere som vi gir spesiell
kursing. Disse er tenkt som en førstelinje support på sin avdeling. Vi tenker oss også å tilby en
elæringsløsning for de ansatte der de kan gjennomføre kurs i eget tempo når det passer dem.
I tillegg bør vi, som en del av prosjektet, ha på plass noen supporttjenester i form av hjelpesider,
gjerne med video instruksjoner.
2.6 Fremdriftsplan for gjennomføring av prosjektet
Vi ser for oss at vi kan komme i gang med prosjektet i mot slutten av november. Det vil bli noen uker
med forberedelser og så tenker vi oss to punkter (helger) der vi gjennomfører migrasjonen fra det
ene til det andre. Del1 bør gjennomføres i januar 2014. Det neste blir del 2 som vi kan gjennomføre
området januar - februar 2014. Det neste punktet blir del3. Dette tenker vi kan gjennomføres i
februar-mars 2014. De øvrige delene av prosjektet er mer fleksible, men tenker oss at hoveddelen
som vi trenger ekstern hjelp til skal være gjennomført innen utgangen av april 2014. IT-tjenesten har
forøvrig arbeid i flere år med å ta i bruk alle muligheten som ligger i de nye løsningene. Det er også
sannsynlig at vi vil fortsette å trenge noe bistand videre utover.
3 Dokumentasjon av IT-organisasjon og eksisterende tekniske
løsninger
3.1 IT- tjenesten
3.1.1
Organisasjon
Oversikten nedenfor viser hvordan IT avdelingen er organisert. Det er meningen at den som vinner
anbudet skal samarbeide med IT-tjenesten og utnytte interne medarbeidere. Derfor er det viktig å
8
Versjon 1.0
kjenne til hva vi har av ressurser.
IT-direktør
Ledelse og koordinering
Personalansvar
Nettverksteam
Serverteam
Supportteam
2 personer
3 personer
3 personer
Anvendt IKT
1 person
IT--sikkerhed
Licensstyring
OTRS
Dokumentere(Servere mv.)
e-learning/pedagogisk IT
Beredskab
Dokumentation (alt annet)
Internregister (servere)
Smart learning/digitale tjenester
Beredskabsplaner
Internregister (alt annet
VMWare/HyperV
Windows server infrastruktur
Servicekatalog / SLA
QoS
Dokumentere(Nettverk mv.)
Passwords
Klientmaskiner Hardware
Internregister (nettverk)
Microsoft White Papers
Lotus Notes
ITIL
Nettverks infrastruktur
Active Directory
Utlån (undersøge mulighed for at
Biblioteket kan stå for utlån)
Microsoft White Papers
Bruger administration
Windows klient infrastruktur
Cisco Network Design White Papers
Infrastruktur i undervisningsrum og
auditorier
Applikations administration
AV i undervisningsrum og auditorier
(ansvarfordeling i forhold til
Driftsavdelingen skal afklares)
Microsoft Office 2010
Eduroam
Netwerk (fysisk)
Nettverk (Wireless)
Switche
Routere
Authentication
Exchange/epost, kalender
Web Server
Klient maskin administration
Systemcenter 2012
Firewalls/pakkefilter
Domino
VPN
Backup/Storage
Digital eksamen
Enable innovation
IDM (Oprydding inden migrering)
Wiki (innhold)
Prosjektstyring
Office 365
Eksamen
Dokumentation
Datasaler
Kontrol av auditorier
Overvåkning av projektorer
Overvåkning av printere
Bruker support
Utskrifter
Ansettelse/fratredelse
Flytting datapunkter
Konfigurering - og flytting
telefonpunkter
Lærlinger og
studentassistent
Infoskerme
Fil/print
Lync/Telefoni (ansvarfordeling i
forhold til Driftsavdelingen skal
afklares)
Vagtordning/organisering
Sharepoint og/eller Portalløsninger
Lærlingerne
5 personer
Studentbyerne
Alarmsystem
Fotosystem
Serverovervåking
Datahjelp
Bestillingsrutiner
Adgangskontrol/alarm/låsesystem
Windows XP
(ansvarfordeling i forhold til
Driftsavdelingen skal afklares)
Windows 8
Mac
Linux
Teknisk drift av Wiki
Nettverksovervåking
Windows 7
Ipad
Iphone
Androide
Tablet
3.1.2
Intern kompetanse
To av våre interne medarbeidere på serverteamet har erfaring fra Microsoft driftsmiljø. Vi har for
øvrig lenge hatt Windows 2003 servere i drift som nå er oppgradert til Windows 2008. Men dette har
ikke vært sentrale ting i vårt driftsmiljø.
Vi har allerede gjennomført første del av kurspakken til «Windows Server Administration» for alle
ansatte på IT. Vi planlegger å fortsette med kurs i september og oktober og videre. Det er meningen
alle med tiden skal opp på MCSA nivå. I tillegg vil noen spesialisere seg på aktuelle ting som
Exchange, Lync og System Center. Det må derfor forventes at et visst kjennskap til at den aktuelle
teknologien vil være på plass under gjennomføringen av prosjektet.
Det er rimelig å anta at vil ha 3-4 medarbeidere med sertifisering på de første delene av WSA kursene
og noen med grunnleggende System Center før vi starter prosjektet.
Gjennomføring av prosjektet er prioritert oppgave
3.2 Dokumentasjon av eksisterende IT-løsninger
3.2.1
Servere
3.2.1.1 Hardware med VMware
 3x IBM BladeCenter HX5 7873
9
Versjon 1.0

ESXi 5 (VMWare)

Totalt 48 prosessorer

Totalt 384 G minne

Leie fra august 2012 (Atea)

Ca. 40 virtuelle servere i produksjon

Benytter ca 1/3 av kapasistet i dag
3.2.1.2 Virtuelle serverere med Windows 2003/2008 R2 (13)
 Backup

IBM Lotus Domino

vCenter

Wsus

Sentralbord (Trio)

Zenworks 11 (brukes til utrulling)
3.2.1.3 Virtuelle servere med Netware 6.5 (4)
 Fil/print

Zenworks 7

Autentisering (Novell)
3.2.1.4 Virtuelle servere med SLES / OES 2 (10)
 NetIQ IDM med LDAP autenisering

Selvbetjeningsportal (konto.hil.no)

Zenworks 11 (vlan: basisservere (adm))

Radius

SMT (subscription management tool)

iFolder

ZAP for administrasjon av ansatte mot IDM

Hjemmekataloger studenter
3.2.1.5 RedHat/Debian/ Ubuntu (12)
 Cisco Prime Netware Control System
10
Versjon 1.0

Samson3 (DNS)

Ubuntu (9)

Wiki

OTRS

LAMP

Subversion

Ezproxy

Konferanseweb(avvikles)
3.2.1.6 Fysiske servere:
 I tillegg kommer 3 fysiske SLES servere til
o
webtjenester og
o
mySql databaser, og en
o
googlesøkemotor.

Øvrige fysiske servere

Rita (adgangskontroll)

DHCP servere (linux)

Manager.hil.no
3.2.2
Lagring

San/bladecenter svitsjer

Oppretting av LUN i SAN

Lagring (SAN)

Hitachi AMS 2100

Leid fra Proact i 3 år (gjenstår 1)

34,7 TB (serverrom1) SAS og SATA

80,5 TB (serverrom2) kun SATA

Ca. 50% utnyttelse i dag begge rom
3.2.3
Backup

Backup til disk med Veeam Backup & Replication 6.1. til VMware backup av hele VM.

Bacup av filer til disk med HP OpenView Storage Data Protector 6.20.
11
Versjon 1.0
3.2.4
DNS
Vi benytter Uninett sin DNS løsning. Serveren er en Linux server som står lokalt hos oss med en
reserve hos Uninett. Administrasjonsprogrammet som benyttes er GOsa2 på Linux servere sentralt
hos Uninett.
3.2.5
DHCP
Vi har to DHCP servere som begge går på Ubuntu Linux. Den ene serveren betjener studentnettet,
både lokalt og på studentbyene. Den andre betjener resten, som vil si ansatt-nett og øvrige nett.
3.2.6
IDM
Vår «Identity Mangement»-løsning er basert på Feide sin konseptuelle arkitektur (se bilag 1b).
Autentisering av brukere er det viktigste formålet med Feide. Det er et stort antall eksterne tjenester
som benytter denne mekanismen.
En vellykket Feide-autentisering foregår i følgende steg:
1. Brukeren forsøker å åpne en web-side for den tjenesten han ønsker å benytte.
2. Tjenesten sender en autentiseringsforespørsel til Feide, som åpner et innloggingsskjema for
brukeren.
3. Brukeren skriver inn sitt Feide-navn og passord i innloggingsskjemaet og returnerer det til
Feide. Feide sender navn og passord til brukerens vertsorganisasjon for kontroll.
4. Vertsorganisasjonen returnerer til Feide en bekreftelse på at brukeren er autentisert, samt
de attributter vertsorganisasjonen har lagret for denne brukeren. Feide videreformidler til
12
Versjon 1.0
tjenesten bekreftelse på brukerens autentisering, samt de brukerattributtene som tjenesten
har avtale om at skal utleveres.
Figuren over er en oversiktlig framstilling av feidearkitekturen (for detaljer se bilag 1b).
Vi har implementert Feide ved hjelp av NetIQ IDM (tidligere Novell IDM). Figuren nedenfor viser en
grafisk framstilling av vår løsning.
METAKAT hos oss er det som i Feide omtales som BAS. Rundt dette har vi forskjellige kilde systemer
som leverer data til METAKAT (BAS) og systemer som det eksporteres til. Det er en av koblingene
som er litt spesiell. Det er den som kalles «eDir2Edir». Dette er en konnektor som synkroniserer med
det lokale nettverket som i dag er basert på Novell. På det lokale nettverket skjer det en
synkronisering av passord og ikke en autentisering via Feide systemet. Det er denne koblingen vi skal
skifte ut i forbindelse med at vi skal ha Microsoft nettverk i stedet for Novell. Resten vil i stor grad bli
som før.
«Arkiverer» er en konnektor som bare jobber lokalt på BAS for å rydde vekk brukere som er utdatert.
«Rita» er en konnektor som leverer data til låssystemet som styrer elektroniske adgangskort til
dørene i bygget. «Fronter»-konnektoren leverer data til LMS-systemet for administrasjon av
studentaktiviteter. «ZAP-HR» er et system for manuelt å legge inn og vedlikeholde ansatte i BAS.
13
Versjon 1.0
«FKS-FSWS Student Transport» er en konnektor
som er utviklet i et samarbeid mellom 8
institusjoner. Den har som oppgave å flytte data
fra FS, som er det studieadministrative systemet
og inn i BAS. De øvrige 4 konnektorene gjør
forskjellige oppgaver knyttet til intern
administrasjon av brukere og hører med i FKSfamilien som hjelpe-konnektorer.
3.2.6.1 Novell trestruktur
Bildet til høyre viser hvordan trestrukturen ser ut
pr. i dag på HIL (produksjonssiden) av det som er
vist ovenfor. Det er det vi kaller produksjonstreet.
Det er dette som skal byttes ut med AD, mens
METAKAT beholdes.
I tillegg til det som vises på bildet har vi ca. 30
grupper som styrer forskjellige rettighetene. De
langt fleste av disse benyttes av ansatte.
14
Versjon 1.0
3.2.6.2 Metakat trestruktur
Til venstre er vist trestrukturen som er på metakatalog/IDMsiden. Herfra blir brukerdata levert til produksjonssiden. Dette
vil ikke bli endret som en konsekvens av prosjektet og kan
muligens gi noen impulser til hvordan AD treet skal se ut.
3.2.7
Fagsystemer
3.2.7.1 Arkivsystem
Vi har et arkivsystem som leser epost via IMAP. Det er på vei
inn et nytt arkivsystem som baserer seg på SharePoint. Det
ventes innført i april-mai 2014.
3.2.7.2 OTRS
OTRS er vårt servicedesksystem der vi registrerer og
administrerer saker. Dette benyttes av flere enn IT. OTRS leser
epost via IMAP.
3.2.7.3 Trio
Trio sørger for synkronisering av fraværsmeldingen mellom
telefonsystemet og
3.2.7.4 TimeEdit
TimeEdit er et system for timeplaner og bruk av rom. Serveren er plassert eksternt og har mulighet
for å eksportere og synke iCal filer. Vi ønsker å benytte oss av kalendersynk herfra. (Se denne linken
for hvordan det ser ut: https://no.timeedit.net/web/hil/db1/timeplan/ri1Q7.html).
3.2.8
Nettverk
Bildet nedenfor viser uninett-forbindelsene våre til Internett. De tykkeste strekene er 10G
forbindelser. Det er 10G hele veien både til Oslo og Trondheim. Som vist på bildet er det flere
redundante forbindelser og gatewayer som gjør at vi kan godt kan ha kritiske tjenester lokalisert
utenfor huset. Det mangler foreløpig en swich som snart vil være på plass slik at vi også har to
sentrale swicher.
15
Versjon 1.0
4 Tildelingskriterier
4.1 Pris 40%
Vi ber om at leverandørene gir oss timepriser sammen med estimater på forbruk av timer, som er i
samsvar med det løsningsforslaget de legger frem (se punkt 5.1). Når vi sammenligner pris så vil vi
bruke gjennomsnittet av estimatene fra alle tilbydere og gange det opp med prisen. Tilbys det flere
kategorier konsulenter vekter vi dem i henhold til time-estimat. Selve timeestimatene gir vi en
vurdering under kvalitet.
4.2 Kvalitet 60%
4.2.1
Kompetanse og erfaring
Vi vil legge vekt på at leverandøren har kompetanse og erfaring fra denne typen prosjekter. Vi innser
også at bredden i det vi etterspør er så stor at det ikke er gitt at alle leverandører kan ha alt vi er ute
etter i eget hus. Det er ikke plikt til å gi tilbud på det vi har satt opp som bør-krav, men det er en
fordel som vi tar i betraktning under kompletthet.
Vi vil legge vekt på at tilbyder har erfaring fra tilsvarende prosjekter. Det også viktig at de har tilgang
til personer med hele bredden av kvalifikasjoner som vi er ute etter.
4.2.2
Estimater
Estimater når det gjelder timeforbruk tar vi i betraktning som en kvalitetsvurdering. Lavt anslag kan
f.eks. tyde på mangel på erfaring og en undervurdering av oppgaven. Men kan også være et uttrykk
for det motsatte hvis det finnes en begrunnelse. Noen leverandører har mer erfaring og har ferdige
rutiner og prosjektplaner og kan jobbe mer effektivt. Høyt anslag er heller ikke alltid negativt, hvis
det i tilbudet ligger inne en forklaringer som viser at vi får mye verdi tilbake f.eks. i form av
kompetanseoverføring. Veldig store avvik i begge retninger er negativt uten at det er en god
16
Versjon 1.0
forklaring. Uansett skal det ikke lønne seg å være taktiske i sine estimater. Skal det scores på lavt
estimat (noe vi gjerne ser) så må det også finnes en god begrunnelse som gjør at vi tror på det.
4.2.3
Kompetanseoverføring
Vi vil legge vekt på at leverandøren viser at han forstår vårt behov for kompetanseoverføring og kan
gi oss en beskrivelse av sin plan for hvordan dette kan skje på en optimal måte.
4.2.4
Tidsrammer
Vi vil legger vekt på leveringsdyktighet innenfor de rammene vi har skissert i beskrivelsen
4.2.5
Kompletthet
Bredden i det vi etterspør er såpass stor at det antakelig er få leverandører som kan tilby alt med like
stor faglig tyngde. Det er en fordel om tilbudet er så komplett som mulig og at de som ikke har
kompetanse i eget hus har skaffet seg underleverandører. Når det gjelder konnektorer og
selvbetjeningsportal har vi ikke stilt krav om at det må være med i tilbudet. Men det er en fordel.
5 Krav til tilbudet
5.1 Løsningsforslag
Dette anbudet handler vesentlig om konsulentbistand. Tilbyderen skal ikke konkurrere bare på pris,
men også på løsninger og kvalitet. Detaljene i prosjektet vil først bli bestemt i forprosjektet vi gjør
sammen med den valgte leverandøren. Men vi vil likevel at tilbyderne skal skissere et løsningsforslag
der det beskrives nærmere hvordan forespørselen tenkes løst med hensyn til de krav vi har
spesifisert. Løsningsforslaget bør minimum omhandle de punktene som er spesifisert i prisskjema (se
bilag 7a).
Før oppstart blir det forhandlinger utfra løsningsforslaget som vil legge føringer for prosjektet.
5.2 Prisskjema
I tillegg til løsningsforslaget vil vi at tilbyderne fyller ut vedlagte regneark (se bilag 7a). Her spør vi om
timepriser på forskjellige kategorier konsulenter og estimater på timeforbruk. Vi har også en kolonne
for bruk av interne medarbeidere på HIL. Vi ønsker at leverandøren skal planlegge å utnytte våre
interne ressurser optimalt. Timeestimater er ikke forpliktende siden vi først i forprosjektet og
underveis i prosjektet vil bestemme detaljer.
5.3 Øvrige krav til dokumentasjon
Vi ønsker dokumentasjon på erfaring og kompetanse for firma, samarbeidspartnere og de personene
som skal delta i prosjektet. Vi ønsker ikke å bli «bombet» med overflod av informasjon som er dårlig
organisert. Vi ber om en kortfattet og oversiktlig framstilling slik at vi fort kan kjenne igjen de
punktene vi har spurt etter i anbudet. Men ta gjerne med fyldigere detaljer i form av vedlegg.
6 Tilbudsskonferanse
Vi legger opp til at det skal arrangeres en tilbudskonferanse på Høgskolen i Lillehammer den 14.10.13
kl. 12.00 der vi presenterer prosjektet og leverandørene kan få stille spørsmål.
17
Versjon 1.0