INTEGRACIJA INTRANETOV PODJETJA S POUDARKOM NA UPRABNIŠKI IZKUŠNJI

Transcription

1 UNIVERZA V MARIBORU FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO Mirko Tenšek INTEGRACIJA INTRANETOV PODJETJA S POUDARKOM NA UPRABNIŠKI IZKUŠNJI Diplomsko delo Maribor, julij 2016

2 Smetanova ulica Maribor, Slovenija Integracija intranetov podjetja s poudarkom na uporabniški izkušnji Diplomsko delo Študent: Študijski program: Smer: Mentor: Lektorica: Mirko Tenšek, dipl. inž. rač. in inf. Univerzitetni študijski program Računalništvo in informatika Programska oprema doc. dr. Milan Ojsteršek Suzana Grobelšek, prof. Maribor, julij 2016

3 i

4 ZAHVALA Zahvaljujem se doc. dr. Milanu Ojsteršku za pomoč pri opravljanju diplomske naloge. Prav tako se za pomoč in možnost izvedbe diplomske naloge zahvaljujem avstrijskemu podjetju in sodelavcem. Zahvala za podporo pri opravljanju diplomske naloge velja tudi staršem in še posebej moji partnerici Tadeji. ii

5 Integracija intranetov podjetja s poudarkom na uporabniški izkušnji Ključne besede: intranet, portal, SharePoint, Lotus notes, Documetum, migracija UDK: (043.2) Povzetek Diplomsko delo obravnava problem združevanja več intranetov v podjetju s preko deset tisoč zaposlenimi. Najprej je predstavljena zgodovina intraneta in njegova pomembnost v podjetjih. Nato predstavimo nekatere obstoječe intranetne rešitve. Zatem smo opisali problematiko razčlenjenih intranetov v podjetju in kako le te združiti v en intranet, ki temelji na SharePointu Predstavljeni so predlagani postopki migracije in dejanski potek migracije iz obstoječih intranetov. Na koncu smo predstavili rezultate migracije kot tudi postopek nastajanja novega intraneta. Skozi diplomsko delo smo predstavili, kako pomembna je komunikacija z uporabniki v času migracije za uspešno dokončanje projekta in posledično znižanje stroškov podjetja. iii

6 Integration of company intranets with emphasis on user experience Key words: intranet, portal, SharePoint, Lotus notes, Documentum, migration UDK: (043.2) Abstract The diploma thesis presents how to deal with the problem of combining several intranets in a company with more than ten thousand employees. First, we present the intranet history and how important is intranet within the company. We then present the issue of disaggregated intranets in an enterprise environment and how to migrate them into a single global intranet based on SharePoint We propose the migration procedures and the actual course of the migration as well. The results of migrations are presented as well as the emergence of a new intranet through this process. Throughout the study, we illustrate the importance of communication with users during the course of the migration to successfully complete the project and consequently reduce the company s costs. iv

7 KAZALO 1 UVOD Namen in cilj diplomskega dela Struktura diplomskega dela INTRANET Kratek opis razvoja intraneta Potreba intraneta v podjetju Intranet produkti, s katerimi se bomo soočili v diplomskem delu SharePoint Documentum Lotus Notes Drugi intranet produkti za primerjavo Upravljanje intraneta PREDSTAVITEV PROBLEMATIKE RAZČLENJENIH INTRANETOV NA RAZLIČNIH LOKACIJAH V PODJETJU Predstavitev obstoječih portalov, ki jih bomo zajeli v integraciji Intranet za pet različnih lokacij na platformi Lotus Notes Švedski intranet na platformi SharePoint Avstrijski intranet na platformi SharePoint Avstrijski prehodni intranet na platformi SharePoint USA 1 intranet na rešitvi, ki uporablja tehnologijo ASP Documentum z Web Publisherjem Prehodni intranet podjetja na platformi SharePoint Poljski intranet na platformi WSS Belgijski intranet na platformi SharePoint Italijanski intranet na platformi SharePoint USA 2 intranet na platformi SharePoint MIGRACIJA METODE, VSEBINA, ORODJA IN LASTNE REŠITVE Pristopi k migraciji predlagani s strani drugih vodilnih podjetij Predlogi podjetja ShareGate Pristop podjetja Metalogix Najboljši primeri podjetja OpenText v

8 4.2 Prikaz pristopov k migraciji na naših primerih Migracija Lotus Notes 6.5 v avstrijski intranet SharePoint Migracija švedskega intraneta v avstrijski intranet Migracija prehodnega avstrijskega intraneta Migracija oziroma ukinitev prehodnega intraneta v podjetju Migracija Documentum v nov globalni intranet SharePoint NOV GLOBALNI INTRANET Aktivnosti pri uvajanju intraneta Gradniki intraneta Zbiranje podatkov o vsebinski strukturi obstoječih intranetov Prototipi Ustavitev projekta vzpostavitve novega intraneta in prehod na obstoječ sistem za nov intranet Arhitektura novega globalnega intraneta Napotki podjetja Metalogix Anketa o uporabi intranetov in SharePointa Primeri lastnih rešitev Stran za usposabljanje uporabnikov Nov prikaz koledarja Predstavitev z grafi kot pomoč pri pregledu pomembnih podatkov Intranet na zahtevo ZAKLJUČEK LITERATURA IN VIRI PRILOGE Priloga A Priloga B Priloga C vi

9 KAZALO SLIK SLIKA 1: OBDOBJA SISTEMOV ECM PO TOMU JENKINSU (2010) [20]... 6 SLIKA 2: PRIMER NOVE STRANI V SHAREPOINT 2013 PORTALU... 7 SLIKA 3: PRIMER STRUKTURE KABINETA Z MAPAMI IN DOKUMENTI V DOCUMENTUMU SLIKA 4: PRIMER SEZNAMA APLIKACIJ DOSTOPNIH V ODJEMALČEVI APLIKACIJI LOTUS NOTES CLIENT SLIKA 5: POVPREČNI ČAS PORABLJEN ZA VZPOSTAVITEV INTRANETA OD LETA 2001 DO SLIKA 6: STRUKTURA INTRANETOV V PODJETJU Z AKTIVNIMI IMENIKI KATERIM PRIPADAJO SLIKA 7: METRIKE OBISKA AVSTRIJSKEGA INTRANETA V ZADNJIH TREH LETIH SLIKA 8: NOTES MIGRATOR FOR SHAREPOINT CONSOLE IN DESIGNER, PRODUKTA, KI SMO JIH UPORABILI ZA MIGRACIJO IZ LOTUS NOTES V SHAREPOINT SLIKA 9: PRIMER ANALIZE ŠTEVILA DOSTOPOV POSAMEZNIKOV IN ŠTEVILA DOSTOPOV UPORABNIKOV PO MESECIH DO ŠE UPORABLJENIH APLIKACIJ V LOTUS NOTES SLIKA 10: PRIMER PRESLIKAVE POLJ APLIKACIJE LOTUS NOTES V POLJA UPORABLJENA V SHAREPOINTU S POMOČJO APLIKACIJE QUEST NOTES MIGRATOR FOR SHAREPOINT DESIGNER SLIKA 11: PRIMER APLIKACIJE V LOTUS NOTES Z OBRAZCEM ZA ELEMENT IN PRIKAZ MIGRIRANE VSEBINE SHAREPOINTU SLIKA 12: UPORABA ORODJA WINDOWS EXPLORER ZA PRENOS DOKUMENTOV MED OKOLJI SHAREPOINT 38 SLIKA 13: PRIMER DOKUMENTNE KNJIŽNICE PRED IN PO MIGRACIJI SLIKA 14: MATRIKA DOSTOPA DO PREHODNEGA INTRANETA ENO LETO PO MIGRACIJI, DECEMBER SLIKA 15: SHAREGATE ORODJE S PRIKAZOM OKNA ZA IZVOR IN CILJ MIGRACIJE DOKUMENTOV SLIKA 16: DELOVNA STRAN NA NOVEM INTRANETU ZA SPREMLJANE POTEKA MIGRACIJE VSEBINE SISTEMA DOCUMENTUM SLIKA 17: BALZAMIQ OKOLJE S PRIMEROM POSNETKA SHAREPOINT 2013 STRANI SLIKA 18: PRIMER POSNETKA ZAČETNE STRANI NOVEGA INTRANETA SLIKA 19: ARHITEKTURA STREŽNIKOV VEČ OKOLIJ GLOBALNEGA INTRANETA SLIKA 20: ODGOVORI NA VPRAŠANJE ANKETE, KDO VAM UREJA SPLETNO INTRANET STRAN SLIKA 21: IZGLED STRANI ZA USPOSABLJANJE UPORABNIKOV NA NOVEM INTRANETU SLIKA 22: STAREGA SEZNAMA DOGODKOV IN NAŠA PREDSTAVITEV KOLEDARJA NA NOVEM PORTALU SLIKA 23: PRIMER UPORABE NADZORNE PLOŠČE Z GRAFI KOT POMOČ PRI ODLOČITVAH SLIKA 24: OBRAZEC ZA VNOS ZAHTEVKA ZA NOVO PROJEKTNO STRAN V SHAREPOINTU vii

10 KAZALO TABEL TABELA 1: METRIKA OBISKA, ISKANJA IN VSEBINE USA 2 INTRANETA TABELA 2: PRIMER TABELE ZA EVIDENCO IN STATUSA MIGRACIJE APLIKACIJ V LOTUS NOTES TABELA 3: METRIKE OBISKA ŠVEDSKEGA INTRANETA, JULIJ TABELA 4: TABELA AKTIVNOSTI VODIJ PROJEKTA OZIROMA INTERESNE SKUPINE TABELA 5: VSEBINSKA STRUKTURA NEKATERIH OBSTOJEČIH INTRANETOV TABELA 6: SKRIPTA, KI AVTOMATSKO PRIPRAVI SHAREPOINT STRAN ZA ODDELEK UPORABLJENE KRATICE IT informacijska tehnologija oziroma oddelek za podporo informacijskim tehnologijam v podjetju (Information technology) HTTP protokol za prenos informacij po spletu (HyperText Transfer Protocol) IP internetni protokol(internet Protocol) CMS sistem za upravljanje z vsebino (Content Management System) ECM upravljanje z vsebino v podjetju (Enterprise Content Management) RM vodenje zapisov (Record Management) ASP aktivne strežniške strani (Active Server Pages) MB megabajt - enota informacije, ki obsega 1024 kilobajtov (Megabyte) GB gigabajt enota informacije, ki obsega 1024 megabajtov (Gigabyte) TB terabajt - enota informacije, ki obsega 1024 gigabajtov (Terabyte) WSS Windows Sharepoint storitve (Windows SharePoint Services) AD aktivni imenik (Active Directory) viii

11 1 UVOD Vsako večje podjetje ima svoje oddelek IT. Takšen oddelek lahko deluje v sklopu podjetja, ali pa deluje kot zunanji partner in ga podjetje najema po potrebi. Vloga oddelka IT je opravljanje podpornih funkcij podjetja ter zagotavljanje delovanja sistemov, ki jih podjetje potrebuje za svoje vsakodnevno delo. Oddelek IT sestavlja več podskupin, ki skrbijo za strojno ali programsko opremo podjetja. V večini primerov je ena izmed teh podskupin ali posameznik zadolžena za intranet v podjetju. Intranet v podjetju lahko združuje veliko tehnologij in storitev za zaposlene in s tem posredno ali neposredno vključuje prav tako druge podskupine oddelka IT, da se uporabniku zagotovi nemoteno delo. S hitrim napredkom na vseh področij računalništva se prav tako na področju intraneta pojavlja vedno znova potreba po napredku in ponujanju čim boljših rešitev. Posledica napredka se v oddelku IT večjega podjetja odraža tako, da se pod eno streho skriva veliko tehnologij, ki tečejo na vzporednih sistemih. Pogosto se namreč zgodi, da ob prihodu nove verzije produkta podjetje ne posodobi obstoječih intranetov, saj je veliko internih produktov, ki uporabljajo intranet, odvisnih od starejše verzije, kar seveda posledično privede do tega, da lahko istočasno v podjetju uporabljamo tudi nekaj različnih verzij istega produkta oziroma več verzij podobne rešitve. Do več vzporednih sistemov lahko v podjetju pride tudi v primeru, ko podjetje prevzame drugo podjetje ali pa je bilo le-to prevzeto in s tem pridobi še eno podobno strukturo oddelka IT, kot je že obstajala. Iz tega sledi, da je treba oddelek IT z vsemi njegovimi funkcijami in rešitvami združiti pod eno okrilje in eden izmed izzivov je seveda, kako integrirati obstoječe intranete. 1.1 Namen in cilj diplomskega dela Namen naloge je podati smernice in navodila, kako naj se podjetja spopadejo z združevanjem intranetov in na kaj morajo biti ob tem pozorna. Izsledki in ugotovitve iz tega dela bodo služili kot pomoč pri izvedbi integracije še obstoječih intranetov v podjetju. Zbrati želimo vse intranete podjetja na enem mestu, pregledati postopke migracije in uporabnikom zagotoviti nemoteno delo med samim procesom integracije. Ugotoviti želimo, ali je integracija izboljšala delo ekip in ali takšen način prinaša v podjetje bolj enotno in razumljivo spletno delovno okolje. Na podlagi izkušenj in preverjanja nekaterih 1

12 postopkov vpeljevanja novega intraneta želimo sprejeti ali ovreči trditev, da ni možno prenesti celotne vsebine iz stare na novo intranetno rešitev. 1.2 Struktura diplomskega dela Diplomsko delo sestavlja osem poglavij. V drugem poglavju bomo spregovorili nekaj besed o intranetu, kjer bomo na kratko povzeli zgodovino intraneta ter predstavili pomembnost intraneta v podjetju in prestavili glavne intranet produkte na tržišču. Z nekaterimi od njih se bomo srečali v nadaljevanju diplomskega dela. V tretjem poglavju bomo predstavili problematiko razčlenjenih intranetov v podjetju, pogledali bomo, kako so ti intraneti v podjetju razdeljeni, jih vsakega posebej na kratko opisali in razložili, zakaj je prišlo do problema razčlenjenih intranetov. Nato se bomo v naslednjem poglavju posvetili metodam in procesu migracije vsebine iz obstoječih intranetov v en skupen intranet, pri čemer bomo predstavili pristope migraciji s strani drugih podjetij in z naše strani. Peto poglavje povzema aktivnosti, ki so potrebne za vzpostavitev novega intraneta. Prikaže gradnike, ki smo jih uporabili pri gradnji prototipa, predstavi arhitekturo novega intraneta in povzema analizo opravljene ankete o uporabi intranetov in SharePointa na splošno. Na koncu podamo manjše primere rešitev, ki se lahko zelo hitro implementirajo na platformi SharePoint 2013 in smo jih dodali kot primer za popestritev portala. Zaključne misli bomo podali v šestem poglavju, kjer bomo povzeli teme iz diplomskega dela in ugotovitve, predstavili trenutno stanje skupnega intraneta in nakazali smernice za nadaljnji razvoj intraneta v podjetju glede na željene cilje. 2

13 2 INTRANET Kot navajajo na spletni strani Wikipedije, se izraz intranet uporablja za poimenovanje več različnih stvari. V našem primeru se bomo osredotočili na intranet kot spletno mesto oziroma spletišče ali tudi intranet portal, ki ga predstavlja več spletnih strani in drugih vsebin, povezanih v celoto preko enotnega URL-ja. Kot navajajo še na Wikipediji, je spletišče [22] nameščeno na enem ali več spletnih strežnikih in dostopno s pomočjo protokola HTTP. Intranet [23] lahko razumemo kot zasebni analog interneta ali kot zasebni podaljšek interneta, ki je omejen na organizacijo. Prva intranetna spletišča in domače strani so bile objavljene leta 1991, v ne izobraževalnih organizacijah pa so se pojavili leta Pri podjetjih se intranet lahko ustvari preprosto z uporabo razponov zasebnih naslovov IP. Takrat je na intranet mogoče dostopati samo neposredno iz računalnika v lokalnem omrežju. Z uporabo virtualnega zasebnega omrežja, ali drugih metod z uporabo avtentikacije in šifriranja pa lahko podjetje omogoča dostop tudi zaposlenim, ki delajo na zunanjih lokacijah izven podjetja (npr. v tujini, od doma ). Da bomo v našem primeru nekoliko poenostavili razumevanje intraneta, ga bomo poimenovali centraliziran sistem za upravljanje z vsebino CMS (angl. centralized content management system). 2.1 Kratek opis razvoja intraneta Podjetja so znotraj svojega omrežja začela z vzpostavljanjem intranetov zaradi hitrejšega obveščanja njihovih zaposlenih. Uporabniki pri oblikovanju intraneta niso imeli možnosti prav veliko sodelovati, kajti postavitev intraneta je bila dodeljena določeni skupini. Vse, kar so uporabniki lahko storili, je, da so vsebino, ki so jo hoteli imeti prikazano na intranetu, posredovali skrbnikom in ti so vsebino pretvorili v pravilno obliko. Pripravljena koda se je izvajala na spletnem strežniku in se prikazoval pri uporabniku v spletnem brskalniku, kar je pomenilo, da se je ob osveževanju spletne strani vedno znova prenesla celotna pripravljena vsebina strani s strežnika do zaslona pri uporabniku. Podpora takšni programski rešitvi je bila na začetku zelo zahtevna, saj postopki, kako uveljavljati spremembe na primer na več straneh hkrati, niso bili vpeljani. Strani so bile statične, tako so se morale vse spletne strani, ki smo jih hoteli na primer posodobiti z enako vsebino, spremeniti ročno vsaka posebej. 3

14 V podjetju še vedno uporabljamo takšno rešitev, zgrajeno s pomočjo aktivnih strežniških strani ASP (angl. active server pages) in v primerjavi z ostalimi lahko trdimo, da je podpora dokaj zahtevna in dolgotrajna, kajti v primeru le majhnih sprememb je potreben poseg v kodi v ozadju in ni možnosti poseganja uporabnika v sam videz strani brez tehničnega znanja, kako so te strani zgrajene. Če je bil na začetku intranet razvit v večini od začetka iz tako rekoč nič, si zdaj težko predstavljamo, da bi začeli graditi intranet brez kakšnega vnaprej pripravljenega produkta, ki ga enostavno namestimo in nam že ponuja osnovne gradnike za delo, brez dodatnega programiranja. Prav želja po tem je izoblikovala prve portale, ki so združevali več funkcionalnosti pod enim okriljem, ki pa so bili sestavljeni tako, da jih je bilo mogoče namestiti na strežnik in so že ponujali več funkcionalnosti na samem začetku. Iz teh rešitev, ki so še vedno bile v večini enosmerne, namenjene uporabniku na podlagi tega, kakšna vsebina se pripravi na strežniku, je šel razvoj v smer tako imenovanega spleta 2.0. Pod tem imenom se je skrivala glavna funkcionalnost intraneta, ki je bila ta, da so lahko uporabniki sami ustvarjali vsebino, jo shranjevali in spet poljubno urejali, iz česar se je razvila možnost urejanja lastnih intranetnih strani glede na uporabnikove želje. Novejši intranetni programi oziroma platforme gredo še dalje in nam ponujajo funkcionalnosti Spleta 2.0, ki predstavljajo možnost neposrednega sodelovanja z drugimi ljudmi, z njimi se lahko neposredno pogovarjamo, sledimo njihovemu delu, delimo zanimivo dogajanje na njihovem lastnem intranet mestu. Razvoj intranetov je tako daleč, da so različne intranet platforme že v naprej kategorizirane glede na to kakšen tip intraneta potrebujemo oziroma v kakšnem okolju deluje naše podjetje. Intranet v novi generaciji pridobi še večjo vrednost, ko se začne uporabljati v oblaku, ker je dostopen prav vsem uporabnikom preko intraneta, ob tem se ponuja boljša uporabniška izkušnja, ki vključuje boljšo uporabnost na vseh mobilnih napravah in enostavnejše ter hitrejše prehajanje na nove verzije produkta, seveda z vsemi prej navedenimi funkcionalnostmi, ki jih imajo intraneti v okviru omrežja podjetja. Novi intranetni produkti ne bi obstajali brez pomoči ogrodij za razvoj spletnih rešitev, kar v tem primeru predstavlja ravno to, da so novi produkti zgrajeni na teh ogrodjih in razvijalci lahko vzamejo obstoječo platformo in z uporabo poznane tehnologije vgradijo nove komponente. Razvoj tako poteka hitreje zahvaljujoč prvotnim lastnim rešitvam, ki so se 4

15 zalo hitro razvijale v kompleksnejše produkte. Na kratko, vendar zelo dobro, je v članku [18] predstavljena zgodovina in evolucija intranetnih programov. 2.2 Potreba intraneta v podjetju Za svoj uspeh morajo podjetja točno vedeti, kako najbolj uporabiti informacije in vsebino, ki obstaja v njihovi organizaciji. Ampak katere informacije bi morali poznati? Kako vzpostaviti intranet infrastrukturo, ki bo omogočala podjetju razumeti lastno vsebino? Tom Jenkins, vodilni mož iz podjetja OpenText, ki je vzpostavilo prvi intranet, navaja [19]:»Podjetja, ki razumejo informacije v svoji organizaciji v ta namen implementirajo sistem za upravljanje z vsebino v podjetju ECM (angl. Enterprise Content Management)«. To je tehnologija, ki zagotavlja način kreiranja, shranjevanja, upravljanja, zaščite, distribuiranja in objave katerihkoli podatkov in vsebin podjetja. ECM ne obravnava številk, poudarek daje besedam. Večina industrije za informacijsko tehnologijo se je v prejšnjih 50-ih letih osredotočala na zaledne podatkovne baze in njihovo upravljanje v sistemih za upravljanje z viri ERP (angl. Enterprise Resource Planing). ECM je edinstven v tem, da je bil razvit za upravljanje kreiranja in konzumiranja naraščajočih ne številčnih podatkov, kot so dokumenti, spletne strani, preglednice, diagrami in slike, kar je v veliki meri vplivalo na porast priljubljenosti intraneta. V novi izdaji svoje knjige s poudarkom na ECM 2.0 Tom Jenkins dopolnjuje svoje ugotovitve in pravi naslednje [20]:»Vsa podjetja ustvarjajo, distribuirajo in konzumirajo vsebino«. Med tem ko količina in kompleksnost podatkov narašča, tako narašča tudi potreba po razumevanju, iskanju, upravljanju in izmenjavi le-te. Med tem ko se količina internih podatkov podvoji vsakih 9 do 12 mesecev, se poveča tudi potreba po upravljanju teh podatkov. Organizacije potrebujejo ECM, da jim pomaga pri nadzoru rasti podatkov in skrbi, da se ne izgubi znanje, ki je v nestrukturirani vsebini, le-ta namreč obsega več kot 80 % pomembnih informacij podjetja. Organizacije se zanašajo, da ECM nadzira preobremenitev z informacijami. S strani tehnologije ECM 2.0 opisuje zbirko medsebojno povezanih tehnologij, ki pomagajo organizaciji ustvarjati, shranjevati, urejati, zaščititi, distribuirati in objavljati digitalne podatke za uporabo v podjetju. Slika 1 nam prikaže, kako avtor vidi obdobja ECM sistemov in posledično intranetov. 5

16 Slika 1: Obdobja sistemov ECM po Tomu Jenkinsu (2010) [20] Trenutno je v porastu ECM 3.0, tako imenovani pomensko usmerjeni intraneti, ki uporabniku vsebino pripravlja na podlagi kompleksnejših algoritmov in z naborom metapodatkov, ki jih ustvarja uporabnik sam. Leta 2010 so bile to ideje šele v povojih, vendar vidimo, da so bile dobro sestavljene in napeljane v smer pametnejših sistemov, ki bi uporabniku omogočal večjo dinamičnost in boljše predloge in ne samo statične vsebine. 2.3 Intranet produkti, s katerimi se bomo soočili v diplomskem delu SharePoint Najbolj promoviran intranetni produkt s strani podjetja Microsoft je vsekakor SharePoint v vseh njegovih različicah. Ponuja velik nabor nekaterih ključnih funkcionalnosti za uporabnike in skrbnike. Uporaben je za podjetja z veliko zaposlenimi in različnimi scenariji, ki jih lahko pokriva za različne ekipe v podjetju. Prav na ta izdelek, natančneje SharePoint 2013 (Slika 2), se bomo osredotočili v diplomskem delu in bo služil kot platforma, ki bo naš ciljni sistem integracije obstoječih intranetov. 6

17 Slika 2: Primer nove strani v SharePoint 2013 portalu SharePoint je največkrat uporabljen produkt za namene Intraneta. Na njegov račun je veliko kritik, da ne opravlja dobro svoje vloge in ne opravičuje svoje cene. Po drugi strani pa je sam produkt zelo prilagodljiv in obširen, da lahko opravlja vse naloge, ki jih za intranet potrebujemo. Za dobre končne izdelke v SharePointu je v veliki meri potrebno dodatno delo s strani uporabnikov in skrbnikov, kar pa tudi ni ovira, saj SharePoint ponuja integriran model razvoja in uporabe aplikacij. V veliko pomoč pri napredku in razvoju samega produkta pa nam je na voljo tudi spletna baza uporabnikov, z različnimi primeri in dokumentacijo, ki se iz dneva v dan veča. Navedimo nekaj izmed pomembnejših funkcij oziroma tako imenovanih aplikacij, ki jih SharePoint ponuja že na samem začetku uporabe. To so vedno vidne moje naloge s časovnico, dokumentne knjižnice, uporaba podstrani, organizacija aplikacij na eni strani, integracija s pisarniškimi produkti podjetja Microsoft, enostavno deljenje vsebine in sledenje, napredno iskanje, uporaba naprednih delovnih tokov, vprašalniki, integracija s storitvami za izdelovanje poročil, izvoz seznamov v druge produkte, integrirana poslovna inteligenca, spletni dnevniki, wiki strani in veliko drugih [12]. Vse te aplikacije nam omogočajo hitro spopadanje s problemi, ki se pojavljajo v podjetju, kot je na primer postavitev strani za globalno razpršene ekipe, vzpostavitev enostavnih projektnih strani, priprava procesa za koordinacijo in pripravo pogodb, rešitve za vprašanja in odgovore zaposlenih, izmenjava idej o določenih temah, predstavitvene strani podjetja s fiksno ali dinamično vsebino in še več. Pokritih je mnogo manjših scenarijev, kjer si lahko uporabniki na hitro pripravijo tabele za vodenje različnih evidenc, kreirajo si podstrani, da logično ločijo vsebino, uporabijo skupen koledar, sinhroniziran s poštnim odjemalcem in seveda še mnogo drugih akcij, ki jih potrebujemo za poslovno delo v pisarni. Ob vsem tem pa seveda ponuja integriran model razvoja in uporabe lastnih 7

18 aplikacij in kot spletni produkt uporabo najnovejših spletnih tehnologij, ki omogočajo obdelovanje podatkov v realnem času. Zaradi vseh njegovih lastnosti je SharePoint prava platforma ECM in v marsikaterem pogledu prekaša že dlje obstoječe konkurenčne sisteme. V najnovejših različicah ponuja Microsoft produkt tudi v oblaku. Nadgradnja pa je hibrid med produktom v oblaku in v podjetju Documentum Kot produkt podjetja EMC je eden večjih konkurentov SharePointu in je bil v uporabi že veliko pred njim, vendar je njegova glavna naloga upravljanje s podatki. V diplomskem delu bomo opisali sistem, ki je temeljil na tej platformi verzije 6.5. Kako je sistem sestavljen in koliko funkcionalnosti združuje, podrobneje zajema dokumentacija [8], ki pravi, da je Documentum sestavljen iz treh enot, in sicer iz strežnika z vsebino, relacijske podatkovne baze in prostora za shranjevanje datotek, ki pa je lahko prav tako na samem strežniku z vsebino. Nabor funkcionalnosti, ki jih ponuja, so indeksiranje vsebine, verzije dokumentov, varnost na različnih nivojih, virtualni dokumenti in ostalo. Struktura je podobna strukturi na datotečnem sistemu in lahko enostavno krmarimo po njej (Slika 3). Slika 3: Primer strukture kabineta z mapami in dokumenti v Documentumu 6.5 V sklopu rešitve Documentum je mogoče uporabljati veliko dodatnih produktov, eden izmed teh je recimo Web Publisher, ki se lahko uporablja za dodatne funkcije znotraj sistema Documentum, kot je priprava delovnih tokov za odobritev dokumentov ali tiskanje 8

19 dokumentov, kot tudi sinhronizacija dokumentov. Za samo delovanje potrebuje WebPublisher svoj strežnik, na katerem deluje in preko katerega se prijavljajo uporabniki [13] Lotus Notes Starejši strežniški sistem za upravljanje z dokumenti je bil prvotno v lasti podjetja Lotus, ki ga je nato zelo hitro prevzelo podjetje IBM. Lotus Notes različica 6.5 se je v podjetju uporabljal zelo dolgo in majhen del nove verzije je še zmeraj v uporabi zaradi svoje enostavnosti. Pod svojim okriljem je Lotus Notes združeval naslednje funkcije elektronsko pošto, koledar, imenik oseb, podatkovno bazo in spletni strežnik. Zakaj je uporaba zelo enostavna? Ker so rešitve vedno shranjene v eni datoteki, ki jo lahko imenujemo tudi baza nsf. Kako točno je Lotus Notes zgrajen, so opisali na spletni strani nsftools [14], ki je namenjena za pomoč uporabnikom orodja. Ker sistem vsebuje rešitve, shranjene v posameznih datotekah, je prenosljiv in zelo pregleden. Da bi lahko uporabljali Lotus Notes rešitve, morajo imeti uporabniki na svojih računalnikih nameščeno posebno odjemalčevo aplikacijo imenovano Lotus Notes Client (Slika 4). Ta aplikacija je tista, ki služi kot uporabniški vmesnik za vse rešitve oziroma Lotus Note aplikacije, ki tečejo na samem strežniku. Do njih lahko dostopamo ločeno in vsaka posebej je predstavljena s sličico na delovnem prostoru (angl. Workspace). Odjemalčeva aplikacija omogoča eno zelo močno funkcionalnost, in sicer uporabnik si lahko ustvari kopijo Lotus Notes aplikacije na svojem računalniku in jo uporablja tudi, ko ni prijavljen v omrežje ter ob ponovni vzpostavitvi z omrežjem prenese oziroma sinhronizira spremembe nazaj na strežnik. Odjemalčeva aplikacija vsebuje tudi aplikacijo za elektronsko pošto in aplikacijo, kjer je viden celotni imenik uporabnikov v podjetju. 9

20 Slika 4: Primer seznama aplikacij dostopnih v odjemalčevi aplikaciji Lotus Notes Client Produkt Lotus Notes je veliko let obdržal svoje prvotno ime, kljub temu da je bilo v lasti novega podjetja, vendar se je pred kratkim produkt preimenoval v IBM Notes, ki še vedno ponuja to, kar je ponujal produkt v začetnih različicah, vendar z novim pristopom. Sedaj pod svoje okrilje vključuje tudi funkcionalnosti Spleta 2.0, ki jih ponuja v drugih produktih pod skupnim imenom IBM Collaboration Solutions Drugi intranet produkti za primerjavo Na trgu je trenutno veliko intranetnih produktov, ki se iz dneva v dan izboljšujejo in med seboj tekmujejo za čim večji tržni delež v določenih segmentih. Navedli bomo le nekaj zanimivih, ki se vedno bolj uveljavljajo in ponujajo zelo privlačne rešitve. Prav zaradi tolikšne konkurence je v zadnjih nekaj letih napredek na področju intraneta izjemen in ne pojenja. Navajamo intranet produkte oziroma rešitve, ki trenutno najbolj izstopajo: Intranet Suite iz podjetja Intelli Enterprise [1]: Orodje ponuja podobne komponente kot SharePoint, na primer iskalnik zaposlenih, organizacijsko strukturo, osebne strani zaposlenih, urejevalnik besedila kar v brskalniku, integracijo s pisarniškimi programi, pregled nad datotekami v že znanem načinu MS Windows raziskovalca, spletni dnevnik, novice, iskalnik in še nekaj dodatnih komponent. Produkt je nekoliko cenejša 10

21 različica SharePointa s podobnimi lastnostmi. Dodaten zelo zanimiv produkt, ki ga ponuja isto podjetje, je Modeler [2], ki nam omogoča hitro sestavo žičnega modela interaktivnega intraneta, kar je vsekakor zelo uporabno orodje pri vzpostavitvi intraneta in spremembi obstoječe strukture portala. Igloo podjetja Igloo software [9]: Dokaj mlado podjetje, ki ponuja svojo intranet rešitev v oblaku in jo oglašujejo kot alternativo SharePointu. Trdijo, da je njihova rešitev enostavna, lepa na pogled in enostavna za vzpostavitev. Glavno vodilo podjetja je povezovanje ljudi in posla ter jim omogočiti bolj efektivno sodelovanje in deljenje informacij. Rešitev ponuja uporabnikom že znane komponente, kot so spletni dnevnik, koledar, deljenje datotek, forum, naloge, wiki in mikro dnevnik in jih zelo dobro umestijo v celoto, kjer uporablja tudi tehniko»povleci in spusti«za enostavno delo. Zelo mamljiva glede na druge produkte je cena, ki jo zahtevajo za uporabniško licenco. Intranet connections [10]: Svojo ponudbo intranetov delijo na intranet za podjetja, intranet za finančni sektor in intranet za zdravstvo, vsak od navedenih ima pripravljene tematske funkcionalnosti. Trdijo, da delajo in gradijo svoje produkte po petih vrednotah enostavnost, pozitivnost, celovitost, kreativnost in empatija. Sam produkt ponuja že znane komponente, kot je delo z dokumenti, možnost hierarhične organizacije dokumentov glede na organizacijsko strukturo podjetji, pomočnik za gradnjo obrazcev, koledar, pomočnik za izdelavo spletnih strani zaposlenih, iskalnik, forum, pomočnik za gradnjo vprašalnikov, novice, določanje delovnih tokov in drugo. Kar pa nekoliko izstopa pri tem produktu, so funkcionalnosti za e-učenje in organizacijska socializacija, kar imenujejo Onboarding, vključuje usposabljanja uporabnikov, vprašalnike in teste na spletu kot tudi avtomatsko ocenjevanje testov, prijave na tečaje in interaktivna navodila. OpenText Content Suite Platform [15]: LiveLink [16] produkt je bil prva zbirka intranetnih aplikacij predstavljenih leta 1997 v podjetju OpenText. Od takrat naprej je podjetje vodilno pri vzpostavitvi sistemov ECM, kar dokazuje tudi z najnovejšim poslovnim paketom Content Suit, ki združuje strežnik za upravljanje z vsebino, upravljanje z zapisi, komponenta za povezljivost s produkti za kreiranje dokumentov iz drugih podjetij, center za arhiviranje, rešitev za skenirane dokumente za zmanjšanje 11

22 tiskanih dokumentov in komponenta za varno sinhronizacijo in deljenje podatkov. Prav tako ponujajo velik nabor dodatnih komponent, kot so mobilni dostop itd. 2.4 Upravljanje intraneta Na podlagi nekajletnih izkušenj dela z intranetnimi rešitvami smo se v našem podjetju soočali z različnimi tehnikami pristopa oblikovanja intraneta. Prav tako so se sčasoma spreminjali načini podpore sistemov. Vsekakor je iz leta v leto zahtevnost uporabnikov naraščala, kot je naraščala tudi količina podatkov. Vse kaže na to, da tehnološko naprednejši kot postajajo intraneti, bolj jih uporabniki vzamejo za svoje in jih bolj pogosteje uporabljajo. Naloga upravljavcev oziroma skrbnikov sistema je, da skrbijo za nemoteno delovanje in vpeljevanje novih funkcionalnosti. Vloga ustvarjanja vsebine, rešitev, oblike in ostalih funkcij, ki jih platforma ponuja, mora preiti v čim večji količini iz skrbnikovih rok v roke uporabnikov. Z večjimi zahtevami uporabnikov se veča kompleksnost rešitev, kar pomeni da mora oddelek skrbnikov intraneta obsegati veliko večjo ekipo, da lahko zagotovi kakovostno podporo. Prav tukaj pride v ospredje malo spremenjena vloga skrbnikov, ki se morajo prav tako prilagajati spremembam in odigrati vlogo učiteljev oziroma trenerjev, da uporabnike naučijo uporabljati nova okolja in jim s tem olajšajo prehode iz starih različic in zagotovijo, da novo okolje ostaja zanimivo in vedno znova privablja uporabnike. Prav tako pa morajo skrbniki ostati v vlogi razvijalcev, ampak v nekoliko drugačnem merilu, in sicer tako, da uporabnikom ponudijo zanimive nove funkcionalnosti, ki jim olajšajo že znane postopke pri delu. Zelo zanimive študije navajajo v članku podjetja NngGroup [3], kjer pravijo, da novi intraneti presenečajo z oblikovnimi idejami, vsebinsko podporo, raziskavami o uporabniški izkušnji, odzivni obliki, sodobnih slikah in potiskanje SharePointa do roba njegovih zmogljivosti. Predstavijo nam, kakšen je bil čas izgradnje intranetov v podjetjih v zadnjih 15-ih letih (Slika 5), kjer lahko zasledimo, da je bil do leta 2013 do prihoda SharePointa 2013 povprečen čas za razvoj intraneta 3.1 leto (na Slika 5 prikazano z rdečo črto), po tej prelomnici pa v zadnjih letih razvoj novega intraneta traja le 1.3 leta v povprečju (na Slika 5 prikazano s sinje modro črto). 12

23 Slika 5: Povprečni čas porabljen za vzpostavitev intraneta od leta 2001 do 2016 Poseben poudarek v članku je namenjen podporni ekipi, ki skrbi za vzpostavitev intraneta in kako številčne so le-te. Na podlagi statistike, zbrane v zadnjih 15-ih letih, so nam postregli s predstavitvijo nekaj grafov in kot rezultat tega prišli do enačbe, ki predstavlja približek pri oceni, koliko skrbnikov oziroma ljudi za podporo intranetu potrebujemo glede na število zaposlenih v podjetju. Ta enačba pravi, da je razmerje ljudi za podporo intranetu enako 9,4596-kratniku števila zaposlenih na -0,976 potenco, kar pokriva 88 % vseh primerov. Kljub temu pa podporne ekipe še vedno sodelujejo z zunanjimi sodelavci in s tem pripomorejo k hitrejši implementaciji v zadnjih letih. Zaključek analize je bil ta, da se ekipe za podporo intranetu iz leta v leto izboljšujejo in podjetja posvečajo vedno več pozornosti intranetu ter njegovemu vplivu. Ob tem pa mora biti podjetje pozorno, da se ekipa za podporo intranetu veča sorazmerno s številom zaposlenih. 13

24 3 PREDSTAVITEV PROBLEMATIKE RAZČLENJENIH INTRANETOV NA RAZLIČNIH LOKACIJAH V PODJETJU Poglavitni problem razčlenjenih intranetov je ta, da je uporabnik primoran dostopati do različnih intranetnih lokacij, da pridobi vse potrebne podatke, ki jih v nekem trenutku potrebuje. To vsekakor vnaša zmedo pri uporabnikih in nerazumevanje povezav med sistemi, če le-te sploh obstajajo. Za uporabnika bi seveda moralo biti vsekakor lažje dostopati do podatkov, ne glede na to, na katerem sistemu se le-ti nahajajo, vendar je to s toliko različnimi razpršenimi sistemi skoraj nemogoče enostavno doseči. V nadaljevanju bomo predstavili, s katerimi intraneti imamo opravka v podjetju, kako so med samo povezani, kako so sestavljeni in kako obširni so. Skupek intranetov, ki jih moramo v podjetju migrirati v nov globalni intranet prikazuje Slika 6, kjer lahko vidimo njihovo razpršenost s tem, kateremu aktivnemu imeniku AD (angl. active directory) pripadajo. Slika 6: Struktura intranetov v podjetju z aktivnimi imeniki katerim pripadajo 14

25 Pred začetkom projekta integracije v en globalni intranet, katere začetek sega v leto 2011, je v podjetju obstajalo enajst intranetov za katere je skrbelo več intranet ekip. Tak scenarij se je v podjetju pojavil kot posledica večkratne združitve podjetja, z nakupi drugih podjetij ali prevzemom podjetja. Z leti so posamezni intraneti postali tudi zastareli in za njih več ni bilo podpore s strani proizvajalca produktov kot s strani strojne opreme in s strani operacijskega sistema. To je bila glavna pobuda, da se začne postopna migracija v novejše sisteme ter s časom v še novejše. Na tem mestu smo se začeli soočati s prvimi izzivi integracije intranetov. Vsak od predstavljenih intranetov je imel enega ali več skrbnikov, povprečno število zadolženih za podporo je bilo 1,5 osebe na en sistem. Ta številka se je do letošnjega leta zmanjšala na skupno šest zadolženih za globalno intranet rešitev in podporo še delujočih starih intranetov. Zato smo se lotili zmanjšanja količine intranetov na najmanjše možno število, vendar pa po dosedanjih izkušnjah in ob večanju podjetja idealni scenarij, ki predstavlja popolno odpravo vseh starih intranetov, ni realno dosegljiv. To trditev bomo potrdili skozi preostali del diplomskega dela na podlagi izkušenj, ki smo jih pridobili s podporo obstoječih intranetov in pri procesu migracij že nekaterih od teh. 3.1 Predstavitev obstoječih portalov, ki jih bomo zajeli v integraciji V opisu posameznega intraneta bomo zajeli arhitekturo sistema, približno število rešitev, ki jih sistem vsebuje ali je vseboval, kakšnega tipa so te rešitve in koliko uporabnikov približno ta intranet uporablja oziroma je uporabljalo. Opisa se bomo lotili kronološko glede na to, po katerem vrstnem redu smo portale že integrirali oziroma je integracija v teku. V procesu integracije bomo zajeli samo intranete, ki se nanašajo na globalne rešitve v podjetju in na področje globalne komunikacije. Samih namestitev intranet produktov je v podjetju še več, vendar se ti uporabljajo lokalno samo za eno rešitev znotraj ekip ali oddelkov in samo v zastonjskih različicah in ne pod licenco podjetja. Tudi te platforme bodo sčasoma zastarele, vendar bomo kasneje videli, ali bodo ekipe izrazile potrebo po posodobitvi sistema in ali bomo prenesli njihove rešitve v globalni intranet. Morda bodo pa samo migrirali rešitve, na katero izmed drugih novih platform v sklopu posodobitve internih procesov brez pomoči globalne ekipe za intranet. 15

26 3.1.1 Intranet za pet različnih lokacij na platformi Lotus Notes 6.5 Podjetje je v pisarnah v Avstriji, Nemčiji, Monaku, Peruju in Ameriki imelo v uporabi Lotus Notes 6.5 od leta Arhitektura sistema je vsebovala pet fizičnih strežnikov Lotus Notes Domino na zgoraj navedenih lokacijah in en dodaten glavni strežnik, ki je bil namenjen sinhronizaciji in varnostnemu kopiranju podatkov iz vseh lokacij. Vsi strežniki so nazadnje tekli na operacijskem sistemu Windows 2003 (Slika 6 oznaka E). Strežniška struktura Lotus Notes je vsebovala porazdeljene strežniške sisteme in uporabniško aplikacijo, ki jo je imel vsak uporabnik v podjetju nameščeno na svojem računalniku, od koder je dostopal do aplikacij na strežniku. Za tem je stal licenčni sistem, ki je vključeval vse strežnike in uporabniško licenco za vsakega uporabnika. Sistem Lotus Notes 6.5 je bil eden prvih, ki mu je potekla uradna podpora in smo ga začeli migrirati v novejše verzije intraneta. Sistem je združeval okvirno 30 tako imenovanih Lotus Notes aplikacij za veliko število oddelkov v podjetju, nekateri oddelki so imeli v lasti tudi več aplikacij. Približno 500 uporabnikov je do teh Lotus Notes aplikacij lahko dostopalo iz namizne aplikacije Lotus Notes Client. Namenske rešitve v Lotus Notes so bile sestavljene iz treh kategorij gradnikov: seznami, obrazci in dokumentne shrambe. Vsaka izmed rešitev je bila shranjena v eni datoteki, imenovani aplikacija. Te aplikacije so se lahko v nekaterih primerih med seboj tudi povezovale in tvorile kompleksnejšo rešitev. Vse aplikacije so bile razvite s strani zunanjih partnerjev podjetja, s katerimi podjetje več ne sodeluje oziroma sodeluje samo še občasno za druge namene. Skupna velikost aplikacij, ki jih je sistem vseboval in jih je bilo potrebno prenesti na nov intranet, je bila 30 GB. Sistem Lotus Notes je v že navedenih lokacijah bil zadolžen tudi za namen elektronske pošte, tako je vsak uporabnik v podjetju preko namizne aplikacije Lotus Notes Client dostopal tudi do svoje elektronske pošte, kot tudi do poštnih predalov za skupine. Tako so se na strežnikih Lotus Notes shranjevali tudi vsi poštni predali, ki so bili shranjeni po sistemu ena datoteka na en poštni predal Švedski intranet na platformi SharePoint

27 Švedski del podjetja je imel od leta 2007 v uporabi SharePoint 2007 za namene shranjevanja podatkov v oddelku IT. V postopku odpravljanja švedskega aktivnega imenika se je morala migrirati tudi vsebina njihovega intraneta. Sistem je sestavljal samo en fizični strežnik, ki je imel vlogo spletnega strežnika in podatkovnega strežnika. Na njem je bil nameščen Windows 2003 (Slika 6 oznaka B) in bil zelo enostaven sistem tako imenovan farma z enim strežnikom (angl. Single Server Farm). Sam sistem je bil sredi leta 2014 velik približno 1.1 GB in je vseboval 10 podstrani, od tega je bila v zadnjem letu aktivna samo ena stran, ki je vsebovala dve kategoriji gradnikov: sezname in dokumentne shrambe. Od začetka je intranet uporabljalo približno 100 uporabnikov, na koncu, ko se je sistem moral preseliti na drugo okolje, je zadnjo rešitev uporabljalo še samo 15 uporabnikov Avstrijski intranet na platformi SharePoint 2007 Glavni avstrijski intranet je v uporabi od leta Prvotni namen tega intraneta je bil vzpostavitev pravega informacijskega intranet portala in seveda nadomestitev strežnikov Lotus Notes. Sestavljata ga dva fizična strežnika (spletni strežnik in drugi podatkovni strežnik), ki sta potrebovala kar nekaj nadgradnje (Slika 6 oznaka D). Čeprav je sistem trenutno še veliko v uporabi, pa je le-ta v popolnosti nepodprt s strani operacijskega sistema in tudi s strani SharePointa. Tudi zato je ta intranet prav visoko na seznamu migracije, ki pa že poteka po fazah. Intranet kot platformo uporablja SharePoint 2007 in vključuje rešitve, kot so pomočnik za izgradnjo obrazcev, dokumentna shramba, vprašalniki, seznami, iskalnik dokumentov in zaposlenih, namenske aplikacije, ki smo jih razvili sami ter prilagojen uporabniški vmesnik. Intranet uporablja skoraj 800 zaposlenih iz istih pisarn, kjer je se uporabljal Lotus Notes in še v nekaterih drugih pisarnah. V zadnjem času je seveda zaradi migracije in postopne vpeljave novega globalnega intraneta uporaba avstrijskega intraneta nekoliko upadla s strani novih uporabnikov. Trenutno intranet uporablja še približno 200 uporabnikov za aplikacije, ki se uporablja samo še v avstrijski pisarni. Iz metrik na Slika 7 je razvidno, da se obisk uporabnikov, ki še uporabljajo aktivne aplikacije, povečuje. Intranet je trenutno v fazi optimizacije, kar pomeni, da se čisti vsa nepotrebna vsebina, da bo na zadnje na voljo samo vsebina, ki se bo res morala migrirati. 17

28 Slika 7: Metrike obiska avstrijskega intraneta v zadnjih treh letih Avstrijski prehodni intranet na platformi SharePoint 2010 Že samo ime pove, da je ta intranet bil namenjen prehodu obstoječega avstrijskega intraneta na nov intranet, zgrajen na platformi SharePoint 2010, vendar se to ni v popolnosti zgodilo. Sistem sestavljajo trije strežniki, in sicer dva strežnika za spletni vmesnik in podatkovni strežnik. Prav tako pa sistemu pripada še dodaten podatkovni strežnik, ki se lahko vzpostavi v primeru, če prvi strežnik izpade. Vendar tega ne zajemamo na sliki, kajti dodaten podatkovni strežnik se uporablja tudi za druge namene (Slika 6 oznaka C). Skupno je bilo na strežniku osem podstrani, ki so bila v pomoč pri migracijskih postopkih različnim ekipam v IT-ju. Rešitve so sestavljali prilagojeni seznami, dokumentne shrambe, wiki strani in koledarji. Sistem se je začel uporabljati leta 2011, ko se je začel projekt migracije starega intraneta. Aktivno je sistem uporabljalo skoraj 30 uporabnikov skupno 2 leti, ker se je vzporedno že začel projekt za nov intranet, ki bi vključeval več ekip. Glavni razlog za opustitev tega intraneta je bil prevzem podjetja in 18

29 potreba po skupnem komunikacijskem portalu, kar je postal "Prehodni Intranet podjetja SP2010 ", ki ga bomo opisali v poglavju USA 1 intranet na rešitvi, ki uporablja tehnologijo ASP V ameriškem delu podjetja so leta 1998 začeli razvijati svoj intranet, ki temelji na rešitvi, ki kot tehnologijo uporablja ASP. V svoji drugi verziji je še vedno v uporabi in dokaj dobro obiskan. Sistem vsebuje podatkovni strežnik in dva spletna strežnika (Slika 6 oznaka G), ki skrbita za dve logični enoti intraneta, in sicer en strežnik skrbi za portal in njegovo vsebino, drugi spletni strežnik pa je namenjen lastnim rešitvam, kot so vprašalniki, splošni obrazci in aktivne vsebine, ki se hranijo v podatkovni bazi. Lastnih rešitev je na sistemu vedno manj, vendar tiste, ki ostajajo, so še kljub temu dobro obiskane. Skupno je še najbolj aktivnih šest rešitev. Sam portal vsebuje veliko podstrani za oddelke, kot so kadrovski oddelek, finance, pravni oddelek, kot tudi informacije za druge večje oddelke, ki imajo lastne predstavitvene strani. V večini so na teh informacije o kontaktnih podatkih oseb, organizacijska struktura oddelkov ter razna dokumentacija. Ker pa samo portali v podjetju niso bili dovolj, se je podjetje zateklo k podporni dokumentni rešitvi Documentum, ki je predstavljana pod naslednjo točko v S tem se je uporabnost intraneta vsekakor povečala in nudila uporabnikom predstavitev več boljše strukturiranih informacij. Intranet je v preteklosti uporabljajo skoraj 4000 uporabnikov, vendar se je to število kar drastično zmanjšalo z uvedbo novejših rešitev. Nekatere skupine so si za interno uporabo ustvarile lastne rešitve in intranet uporabljajo občasno samo za nujno dokumentacijo, ki jo posreduje podjetje za vse zaposlene. Skupna velikost uporabne vsebine ameriškega intraneta se giba okrog 15 GB, kar zajema velikost že omenjenih lastnih rešitev in vsebine namenjene portalu Documentum z Web Publisherjem 6.5 Ameriški del podjetja je, kot pomožno dokumentno rešitev k USA 1 intranetu, uporabljal še dokumentni sistem Documentum, ki je omogočal shranjevanje dokumentov, urejanje pravic, vodenje verzij dokumentov, revizij dokumentov in še nekaj dodatnih možnosti. Uporabniki niso dostopali do svoje vsebine samo preko portala kot odjemalci, ampak so dostopali tudi neposredno v sistem Documentum, za kar je skrbel uporabniški vmesnik 19

30 Web Publisher 6.5. Namen rešitve je bil ponuditi uporabnikom prostor za dodatno organizacijo njihovih dokumentov vzporedno s portalom opisanim v Nekateri so uporabljali neposredno samo sistem Documentum, da so vodili dokumente za ekipo ali oddelek. Naloga skrbnikov je bila dodeljevanje pravic in po potrebi skrbeti, da je bila vsebina iz sistema Documentum pravilno povezana na USA 1 intranet, kjer so lahko imeli vpogled v te vsebine tudi drugi. Sistem so sestavljali trije strežniki (Slika 6 oznaka F): spletni strežnik, ki je skrbel za dostop in uporabniški vmesnik, podatkovni strežnik, ki je hranil relacijsko podatkovno bazo in datotečni strežnik, na katerem so bili shranjeni dokumenti. Skupno je sistem uporabljalo s strani portala približno enako številko uporabnikov kot sam portal, sam sistem Documentum pa je aktivno uporabljalo približno 300 uporabnikov, ki so skrbeli, da so bili dokumenti aktualni in na voljo ostalim zaposlenim. Skupna velikost sistema je bila leta 2013 pred začetkom migracije 4 TB (terabajte) Prehodni intranet podjetja na platformi SharePoint 2010 Iz imena je razvidno, da gre tukaj za intranet portal, ki služi samo kot prehodni portal. In sicer je bil ta intranet portal zgrajen za namene obveščanja uporabnikov o integraciji dveh podjetij v eno in je bil voden in koordiniran s strani oddelka za komunikacijo v podjetju. Intranet je bil in je še vedno dostopen vsem uporabnikom, vendar je svojo glavno vlogo igral samo dve leti od leta 2012 in v tem času še enkrat popolnoma preoblikovan. Bil je glavna točka dostopa za informacij o podjetju še pred novim globalnim intranetom. Sistem sestavljata dva virtualna strežnika (Slika 6 oznaka H), spletni strežnik in podatkovni strežnik. Do njega je v času največje uporabe dostopalo približno 8 tisoč uporabnikov, vendar samo za uporabo vnaprej pripravljenih dokumentov in pregled informacij, ki jih podjetje posreduje zaposlenim. Platforma SharePoint je bila popolnoma preoblikovana in je dobila predlogo, ki jo je narekovalo podjetje. Uporabljene komponente so bili dokumentna shramba, spletni dnevniki, vprašalniki, prilagojeni obrazci, seznami in prilagojene predloge za različne lokacije podjetja. Skupna velikost podatkov na intranetu je znašala 2 GB. 20

31 3.1.8 Poljski intranet na platformi WSS 3.0 Intranet imajo v pisarni na Poljskem v uporabi od leta Deluje na zastonjski verziji SharePoint 2007, imenovani WSS 3.0 (angl. Windows SharePoint Services). Uporablja ga kar nekaj ekip in je bil dokaj priljubljeno mesto za zaposlene, saj ima portal svoj prostor za zaposlene, ki se ukvarjajo z različnimi konjički in tako lahko delijo svoje izkušnje kar na portalu podjetja. Ekipe imajo svoje podstrani za svoje namene in uporabljajo samo funkcionalnosti, ki jih SharePoint omogoča že ob sami namestitvi. Dodana je bila samo ena lastna rešitev. Intranet deluje kot farma z enim strežnikom (Slika 6 oznaka I), vsebuje spletni strežnik in podatkovni strežnik, vendar se obe vlogi izvajata na enem strežniku. Ker je uporabljena zastonjska verzija SharePointa, se prav tako uporablja zastonjska verzija podatkovne baze. Skupno ima intranet 40 do 50 uporabnikov in nekaj več kot 12 GB vsebine Belgijski intranet na platformi SharePoint 2010 V Belgiji imajo vzpostavljen intranet od leta 2009 in služi potrebam deljenja informacij na svoji lokaciji, saj kot smo opisali, pred tem intranet USA 1 ni ponujal vsega, zato so se posamezne ekipe zatekle k drugim rešitvam, kot je ta. Intranet temelji na platformi imenovani SharePoint Foundation 2010, ki je zastonjska različica SharePointa Intranet vsebuje dokaj malo podatkov predvsem za dokumentacijo, kot je dokumentacija, potrebna za certificiranje podjetja. Skupno je postavljenih 7 strani za potrebe različnih ekip, ki jim osnovna funkcionalnost SharePointa zadostuje, saj v sklopu tega portala ni razvite nobene dodatne lastne rešitve. Sistem vsebuje ločen spletni strežnik in podatkovno bazo (Slika 6 oznaka J). Skupno intranet uporablja v zadnjem času le še približno 20 uporabnikov s skupno nekaj več kot 5 GB podatkov Italijanski intranet na platformi SharePoint 2010 V italijanskem delu podjetja je intranet zelo priljubljen, saj ponuja veliko zanimivosti za zaposlene. Sistem je postavljen v italijanski pisarni, kjer je lociranih nekaj več kot tri tisoč 21

32 zaposlenih in vsi so tudi uporabniki intraneta. Portal deluje od leta 2010 in je med tem že spremenil svoje ime in videz, vendar kljub temu ostal na isti platformi. Sama vsebina intraneta je že, kot navedeno, zelo raznolika in je razporejena v logične skupine. Sistem je vzpostavljen na petih strežnikih (Slika 6 oznaka K), od katerih dva opravljata vlogo spletnega vmesnika, en je aplikacijski strežnik, ki skrbi za iskanje in ostale SharePoint storitve ter dva podatkovna strežnika, ki sta eden drugemu v pomoč, če kateri od njiju izpade USA 2 intranet na platformi SharePoint 2010 Zanimiv intranet na drugi lokaciji v Ameriki, ki je zelo priljubljen in ga uporablja približno tri tisoč uporabnikov. Dnevno uporablja ta intranet blizu dva tisoč ljudi, kar je razvidno iz matrike v Tabela 1. Sestavljata ga dva strežnika (Slika 6 oznaka A), spletni in podatkovni strežnik. Sam portal vsebuje 8 podstrani za iskalnik, koledar za prireditve, evidence namestitev sistemov, stran za potovanja in druge spletne strani. Vsebina na portalu je namenjena predstavitvam oddelkov in komunikaciji z uporabniki, zato je vsebine relativno malo (samo okrog 5 GB), vendar je intranet povezan s strežnikom za vodenje projektov, kjer pa se podatki vodijo posebej. Tabela 1: Metrika obiska, iskanja in vsebine USA 2 intraneta 22

33 4 MIGRACIJA METODE, VSEBINA, ORODJA IN LASTNE REŠITVE Postopek integracije obstoječega intranet okolja pomeni prenos podatkov iz teh obstoječih sistemov na nov sistem. Način prenosa se razlikuje od sistema do sistema, zato se moramo lotiti integracije organizirano v vsakem okolju posebej. Preden se lotimo prenosa samih podatkov oziroma migracije, je treba preučiti tehnike prenosa in združljivosti med sistemi. V nekaterih primerih lahko podatke prenesemo z obstoječimi orodji, v drugih primerih je treba za to pripraviti in razviti lastne rešitve. Da bi bil postopek prenosa podatkov kar se da natančen in bi potekal čim bolj tekoče, je treba temeljito razmisliti in načrtovati postopke za migracijo. V načrt moramo vključiti komunikacijo z lastniki vsebine, razmisliti moramo o količini podatkov, ki so na obstoječih sistemih, pomemben člen je kritičnost obstoječe rešitve. Prav tako moramo biti pozorni na to, ali bomo vsebino lahko prenesli z obstoječimi orodji ali potrebujemo kakšne dodatne rešitve, zato je prav, da takšne primere uporabljamo testno okolje, kjer lahko testiramo različne postopke migracije. Lotili se bomo pregleda intranetov, ki smo jih že migrirali, kakšne postopke smo uporabili in zakaj. Za intranete, ki pa jih še nameravamo migrirati, bomo zbrali nekaj novih napotkov, ki jih ponujajo vodilna podjetja za migracijo podatkov v intranetu in s katerimi si bomo v prihodnje pomagali pri odločitvah in sami migraciji intranetov, ki jih še imam imamo na seznamu za integracijo. 4.1 Pristopi k migraciji predlagani s strani drugih vodilnih podjetij Predlogi podjetja ShareGate V tem trenutku eno najbolj poznanih podjetij v povezavi s SharePointom je vsekakor Sharegate. Podjetje se ukvarja z razvojem produkta, ki pomaga uporabnikom lažje upravljati intranet zgrajen na platformi SharePoint. Ponuja orodje za migracijo podatkov in za skrbništvo SharePointa. 23

34 Kako bi iz njihove strani morala potekati migracija obstoječega intraneta, nam predstavijo v kratkem članku naslovljenem»migracijski kontrolni seznam«(angl. migration checklist) [5]. V članku navajajo naslednje nujne korake: Popis inventarja intraneta. V kolikor je seznam inventarja dovolj natančen, lahko sprejemamo boljše odločitve in ocenimo, koliko časa in truda bo potrebnega za migracijo. Več informacij kot zberemo, lažje lahko načrtujemo in se držimo rokov. Očistiti obstoječ intranet. Intranet je sistem, ki uporabnikom omogoča in jim pomaga pri izgradnji rešitev, ki jih potrebujejo za svoje delo, ampak to še ne pomeni, da so vse stvari še vedno aktualne in se potrebujejo. Treba si je vzeti čas, da najdemo, odstranimo in reorganiziramo vsebino. Priprava novega okolja. Migracija je pravi trenutek, ko lahko pozabimo na stare stvari in začnemo znova. Treba si je vzeti čas, da naredimo dober načrt in preoblikujemo novi intranet, kot nam najbolj ustreza. Verjetnost, da dobimo kmalu spet takšno možnost, je zelo mala. Komunikacija z uporabniki. Največji izziv, s katerim se pri migraciji soočamo, so vsekakor spremembe za uporabnika. V kolikor želimo, da bodo uporabniki sprejeli spremembe in pri migraciji tudi pomagali, jih moramo večkrat obveščati o tem, kaj se z njihovo vsebino dogaja in zakaj prihaja do teh sprememb ter preveriti, ali sami razumejo, kaj želimo doseči. Začetek migracije. Če smo pravilno sledili vsem prejšnjim korakom, nam sam postopek migracije ne bi smel delati prevelikih težav. Konec koncev se v tem procesu ukvarjamo samo s prenosom vsebine in pazimo, če pride do katerih nepričakovanih napak, ki jih med samim testiranjem nismo predvideli. Po migraciji. Preden uporabnikom dejansko omogočimo dostop in delo na novem okolju, se moramo prepričati, da je prav vse pripravljeno. Rešitve po meri. V kolikor v obstoječem okolju oziroma intranetu obstajajo rešitve, razvite posebej po meri in niso del rešitev, ki jih sistem ponuja že v osnovi. 24

35 4.1.2 Pristop podjetja Metalogix Je eno večjih podjetjih na področju rešitev za intranet. Ukvarjajo se s podporo vsem intranetnim platformam na skoraj vseh področjih. Najbolj znani so po svojih skrbniških orodjih za SharePoint. Ponujajo svetovanja o migraciji in sodelujejo s številnimi podjetji po celem svetu. Njihov pristop je nekoliko drugačen od drugih kar je razvidno v njihovem priročniku za boljše načrtovanje SharePoint migracije [7]. Trdijo, da je migracija ovira pri strategiji novega intraneta in ko nam drugi navajajo postopke za migracijo, nam ne podajo nobenih praktičnih napotkov. Resnica je, da se migracija izvaja po fazah, iterativno, je polna napak in ni naš dejanski cilj. Zakaj moramo načrtovati sedaj in migrirati kasneje? Razumeti moramo obseg, preden začnemo migracijo ali graditi novo rešitev, vzpostavimo in sledimo točno definirani metodologiji zato, da so naše aktivnosti predvidljive in jih je mogoče meriti. Treba je dokumentirati informacijsko strukturo in natančno izluščiti, kdo so lastniki vsake vsebine. Delati je potrebno male korake nalogo za nalogo in uporabljati ponavljajočo se, a preoblikovano strategijo, kjer moramo biti najprej osredotočeni na ključne uporabniške vzorce in čez čas povečamo obseg. Ustvariti je potrebno kulturo nenehnih izboljšav, ki predstavljajo proces upravljanja sprememb. Razumeti obseg migracije. Definirati je potrebno jasne metrike za uspeh, da nam pomagajo pri napredku in nadrejenim. V kolikor ne zavzamemo popolnoma vseh elementov, se bo pri migraciji vedno našel nekdo, ki bo trdil, da je treba migrirati še nekaj, česar nismo zajeli in s tem podaljšujemo rok projekta. Primer metrik za uspešno migracijo: uspešna migracija uporabnikov na nov sistem (100 % migracija je idealna, ampak ali je 85 % migracija je sprejemljiva? Verjetno.), ali pa morda uspeh pomeni, da je bilo migrirano merljivo število strani z določeno količino podatkov (mogoče 90 % baz), še ena ključna meritev bi lahko bila, kolikšen odstotek datotečnih sistemov je bilo migriranih in koliko strojne opreme odpravljene, ki je bila s tem povezana. Vsekakor morajo biti metrike veljavne in razumljive za vse vpletene. Priprava novega intraneta na preoblikovanje informacijske arhitekture. Pregledati je potrebno metrike obstoječe vsebine, ki bodo povedale, kako je potrebno reorganizirati vsebino na novem intranetu, v kolikor ne razumemo, kako se uporablja trenuten intranet bomo toliko težko zapolnili vrzeli med 25

36 starim in novim sistemom. Poznati in razumeti moramo metrike kot so, pravice uporabnikov, poročila o uporabi in aktivnostih, poročila o diskovnem prostoru, revizijska poročila, število uporabnikov trenutnega intraneta. Razumevanje urnika migracije. Potrebno je razumeti, kaj je poslovna gonilna sila takšnega projekta. Ali je projekt zastavljen z realnimi cilji, ali so termini določeni s strani vodstva, ki hoče uresničiti svoje cilje v čim krajšem času ne glede na rezultat? S časom migracije je povezanih veliko stvari, ki jih vsak projekt mora imeti, vendar se velikokrat zgodi, da se tak projekt migracije začne ne da bi se sledilo kakršnimkoli pravilom vodenja projekta. Potrebno je razumeti in dokumentirati, kakšno stanje intraneta sploh hočemo zagotoviti. Potrebno je sodelovati z uporabniki in interesno skupino ter določiti prioritete. Potrebno je dobiti uporabnike in interesno skupino na eno stran, kjer se oboji strinjajo. Natančni nasveti. Narediti varnostno kopijo sistema preden se karkoli prične migrirati, vzpostaviti komunikacijski načrt in vedno znova obveščati uporabnike, kakšni so naslednji koraki in kaj je že bilo narejeno, obvezno zagotoviti čas za testiranje, le tako si lahko zagotovimo, da bodo napake v migraciji tudi najdene, določitev časovnega obdobja, ko se sistemi zaklenejo in spremembe niso dovoljene. Migracija je priložnost, da se podjetje nekoliko očisti, preoblikuje in uresniči intranetno vizijo. Migracija ni samo tehnična aktivnost, ampak mora biti mnogo bolj premišljen in načrtovan proces. Pri migraciji moramo še posebej paziti na naslednje: Hiteti pri migraciji ni priporočljivo, čeprav lahko na začetku izgleda vse lepo in enostavno, se težave začnejo kazati komaj čez nekaj mesecev. Ne smemo spregledati lastnih rešitev v predhodnem intranetu, saj lahko povzročijo precej preglavic, v kolikor jih je potrebno naknadno implementirati. Obravnavati vse uporabnike enako ni priporočljivo, saj se njihove rešitve in potrebe razlikujejo (od ekipe do ekipe, če ne celo med posamezniki). Zahtevnim rešitvam se je potrebno še bolj posvetiti. Izogibanje testiranju ni dobra praksa, kajti testiranje je pravi trenutek, ko lahko preverimo, ali smo zajeli vso vsebino in ali se držimo vseh pravil, ki smo jih na začetku načrtovali, tudi končni uporabniki morajo testirati nov intranet pred uvedbo v produkcijo. Začeti projekt brez načrta, kako povrniti sistem v začetno stanje, vsekakor ni dober pristop. Potrebno je poskrbeti, da lahko v vsakem trenutku, ko gre kaj narobe, spet vzpostavimo prejšnje stanje sistema. Če pride do težav, jih bomo 26

37 kasneje le s težavo odpravili, če jih bomo sploh lahko. Za vsako fazo je potrebno poskrbeti za načrt za povrnitev stanja. Ne smemo pozabiti, da je potrebno uporabnike vključiti v proces migracije. Ni važno, kako so vključeni v informiranje ali zbiranje informacij, važno je le, da se vnaprej točno določi, kako se bo z njimi komuniciralo. Prav tako je potrebno preveriti kdo so uporabniki in kakšne izkušnje imajo. Ali razumejo sisteme ali samo prebirajo vsebino? Preveriti je tudi potrebno, ali so se na obstoječe okolje navadili in ali moramo te znane elemente prevzeti v novem sistemu, ali pa se lahko lotimo novosti in jih seveda podučiti, kako se uporabljajo. Preveriti je potrebno tudi, ali je važno samo premakniti vsebino ali pa je potrebno popolnoma preoblikovati vse na ciljnem sistemu Najboljši primeri podjetja OpenText Kot smo že omenili se to podjetje že od samih začetkov uvedbe intraneta ukvarja s sistemi ECM. Podjetjem pomagajo, da s pomočjo intranetov lažje upravljajo interne vsebine. Tudi oni so podali nekaj napotkov kako se je po njihovih izkušnjah najbolje lotiti postopkov migracije vsebine. Informacije niso več samo podatki za podjetje ampak vsebina, ki se lahko interpretira, integrira in se prikaže kot bolj smiselna za uporabnika. Pomembno vlogo pri migraciji na en sistem seveda igra spoznanje, da prinaša en sistem enak pogled na vse podatke, s čemer si lahko zagotovimo večjo efektivnost in povečamo doprinos [17]. Dobre prakse migracije podatkov: Definiranje ciljne vsebine. Ciljni intranet je potrebno zelo dobro poznati, preveriti je potrebno kaj imamo na razpolago in kako iz tega iztržiti najboljšo rešitev. Pri tem seveda ne smemo odstopati preveč od trenutne rešitve, zato je potrebno preveriti kaj uporabniki uporabljajo, kaj potrebujejo in kako uporabljajo vsebino. Nato je potrebno vse skupaj preslikati v nov sistem tako, da dobimo najboljši izkoristek. Razumevanje obsega in meril. Potrebno je vložiti čas za podrobno analizo sistema. Kako kompleksen je? Kako velik je? Ali vključuje še katere druge sisteme? Preveriti je potrebno ali je mogoče opustiti kakšne storitve ali ovreči katero vsebino. Tudi če v analizo 27

38 vključimo zunanje partnerje, moramo imeti na projektu vedno vodjo iz podjetja, ki se drži pravil in nadzira rezultate. Strategija. Pripraviti je potrebno vso analizo ali je podatke res mogoče prenesti v nov intranet, ali bi za to bil mogoče bolj primeren drug sistem, kjer imajo ti podatki večji smisel. Zagotoviti je potrebno tudi primerno taksonomijo. Dostop do izvornih podatkov. Oceniti je potrebno kompleksnost podatkov ter kako so podatki med seboj povezani in kje se vsebina nahaja, če ni samo v enem sistemu ali morda prihaja iz drugih aplikacij, ob tem je komunikacija z uporabniki nepogrešljiva. Čiščenje vsebine. Pomembno je da si lastniki vsebine vzamejo čas in pregledajo obstoječe podatke, saj s tem pripomorejo k zmanjšanju migrirane vsebine in posledično nov sistem pridobi na kvaliteti informacij. Preslikati vir v cilj. Pripraviti dokumentacijo, kako bo vsebina prenesena na nov intranet. Tu mora biti vključena samo vsebina in vsi podatki povezani z njo, od metapodatkov do delovnih tokov. Določitev migracijskih metod. Obstajajo tri glavne strateške možnosti migracije vsebine big bang, vzporedno in po fazah ali postopno. Obstaja še sekundarna možnost, to je migracija brez izpadov, ki jo lahko uporabimo pri vzporedni ali postopni migraciji. Analizirati tveganja in načrtovati ukrepe, če pride do tveganj. Ta korak vključuje razvoj in testiranje prototipa. Reprezentativni podatki bodo dali neko oceno med samim testiranjem, vendar moramo izvesti celotno migracijo na testnem sistemu ter dodobra oceniti tveganja. Ta tveganja moramo predelati z uporabniki in ugotoviti možne rešitve, s katerimi se vsi strinjajo. Migracija vsebine. Ko smo naslovili vse predhodne dobre prakse, izučili uporabnike na novem intranetu, potrdili vse metode migracije in določili datum za migracijo, lahko nadaljujemo z vodenjem same migracije. Potrditev in dokumentacija. Migracija ni zaključena dokler ni potrjeno, da je bila vsa vsebina migrirana na nov sistem. Dobra revizija mora vključevati komunikacijo z uporabniki, kjer se preveri, ali so z novo rešitvijo in migracijo zadovoljni. Na koncu shranimo vse skripte, ki smo jih uporabili pri migraciji, če bi jih morda potrebovali na drugih 28

39 projektih in pripravimo dokumentacijo o migracijskem postopku, da se le ta lahko kadarkoli ponovi. 4.2 Prikaz pristopov k migraciji na naših primerih Da bi čim bolje lahko opredelili vsebino na obstoječih portalih in ugotovili, kaj uporabniki uporabljajo ter kdo je dejansko po vseh teh letih uporabe še zadolžen za vsebino na portalih, uporabljamo različne pristope. Kako smo se lotili migracije, bomo opisali nekoliko kasneje, pri vseh procesih pa smo migracijo izvedli v naslednjem zaporedju. Naprej smo preučili možnosti migracije, ki jih platforma ponuja. Seznanili smo se s tem kaj nam sama platforma nudi, nato smo preverili, ali imamo na voljo kakšne rešitve, ki jih lahko kupimo ter seveda, kakšni so licenčni pogoji. Nazadnje smo preverili, kako odprta je platforma in ali nam ponuja možnost za izdelavo lastne rešitve, ki bi se povezala s platformo in ponudila vse podatke, ki jih potrebujemo za migracijo. Šli smo od najenostavnejših do najzahtevnejših rešitev na koncu, v kolikor ni bilo drugih možnosti. Še preden smo vzpostavili komunikacijo z lastniki vsebine, smo izvedli nekaj testnih poizkusov migracije, da se prepričamo, katere scenarije lahko pokrijemo in s katerimi informacijami lahko kontaktiramo odgovorne za vsebino. Naslednji korak je bil nagovoriti osebo, ki je na spletni strani navedena kot odgovorna oseba. Tak pristop je najboljši, saj je zelo možno, da je stran aktualna in da odgovorna oseba ve, kaj se dogaja z vsebino na spletni strani in kako aktualna je vsebina. Tako imamo kontakt, ki nam je pri procesu prenosa vsebine na nov portal lahko vedno oziroma v večini primerov zelo hitro na voljo. Kontakt z odgovorno osebo predhodnega intraneta nam omogoča hitrejše posredovanje in zaključek prenosa podatkov iz starega sistema na novega. Seveda obstaja vedno tudi možnost, da kontaktne osebe ni mogoče dobiti, zato se moramo do teh podatkov dokopati z analizo vsebine znotraj posameznih logičnih enot, kar nam lahko poda informacije o tem, kdo največ uporablja vsebino oziroma jo spreminja. Na podlagi takšne analize lahko najdemo tudi več kontaktnih oseb. Med njimi izberemo najprimernejše. 29

40 Po dogovoru z uporabniki pripravimo načrt migracije. V našem primeru je načrt bil skoraj vedno podoben, in sicer je vseboval več faz, ki predstavljajo različne migracije in odobritve uporabnikov. V vsaki fazi migracije smo prosili uporabnike, naj rešitev preverijo in opravijo test ustreznosti glede na predhodni dogovor. Po potrebi smo zbirali informacije o napakah in jih postopoma odpravljali. V večini primerov smo migracijo zaključili po dveh ponovitvah. V nekaterih primerih pa je bilo potrebnih še nekoliko več ponovitev, da nam je uspelo priti do želenega rezultata. Migracij smo se lotili od najenostavnejših do najzahtevnejših, da smo se lahko v procesu migracije rešitev istega sistema sproti učili na napakah in izboljševali proces, veliko elementov migracije smo ob tem lahko ponovno uporabili. Eden izmed možnih scenarijev je bil tudi tak, da smo rešitev za migracijo že imeli pripravljeno, vendar se je skupina uporabnikov v zadnjem trenutku odločila, da obstoječo rešitev še vedno potrebuje. Pojavila se je potreba po podaljšanju licenc in posledično so nastali večji stroški. Prav tako niso hoteli naše ponujene rešitve za migracije vsebine, ampak so hoteli implementirati lastno rešitev, ki bi jim nekako omogočala večjo prilagodljivost Migracija Lotus Notes 6.5 v avstrijski intranet SharePoint 2007 Migracija sistema se je začela 2011, končala pa uradno v sredini leta Večina rešitev je bila zaključenih leta 2013 vendar se je nekaj ekip odločilo, da razvijejo rešitve znotraj svojega oddelka. Sistem je zato še naprej vzporedno deloval, čeprav nepodprt, vse dokler se ni ukinila zadnja rešitev ter s tem tudi pogodba do zunanjega partnerja. Za migracijo vsebine iz Lotus Notes v SharePoint 2007 smo uporabili program Notes Migrator for SharePoint 6.0 [21] iz podjetja Quest Software, ki ga je prevzelo podjetje Dell. Program je vseboval dva različna produkta. Prvi imenovan Console, za popoln pregled nad aplikacijami in uporabniki v okolju Lotus Notes. Drugi imenovan Designer za definiranje elementov v samem migracijskem postopku, kot so polja, ki se bodo uporabljala pri migraciji, kateri elementi se bodo migrirali, izvor in cilj migracije, izjeme in podobno. Primer obeh programov je prikazan na Slika 8. 30

41 Slika 8: Notes Migrator for SharePoint Console in Designer, produkta, ki smo jih uporabili za migracijo iz Lotus Notes v SharePoint 2007 Prvi korak pri migraciji okolja je bila analiza okolja. Zanimalo nas je, kdo so uporabniki, ki dostopajo do okolja, do katerih podatkov dostopajo in količina podatkov. Te odgovore smo dobili s programom za analizo, ki nam poda vse informacije o določeni aplikaciji v Lotus Notes. Dobljene rezultate smo si nato zaradi lepše predstavitve in poročanja prenesli v Excelove table, kar se vidi na primeru Slika 9. 31

42 Slika 9: Primer analize števila dostopov posameznikov in števila dostopov uporabnikov po mesecih do še uporabljenih aplikacij v Lotus Notes Po analizi in pred začetkom migracije smo uvedli nekaj osnovnih pravil: Seznanili smo vse uporabnike, da se bo migracija pričela in na kakšen način bo potekala, kot tudi kako naj bodo pripravljeni na sodelovanje in vnovično kontaktiranje z naše strani z dodatnimi specifičnimi informacijami in navodili. Pripravili smo seznam uporabnikov Lotus Notes in navedli njihova imena iz trenutnega aktivnega imenika, da se bodo le ta lahko preslikala ob migraciji, saj potrebujemo podatke, kdo je ustvaril vsebino, tudi po migraciji. Če nekaterih uporabnikov ni več v podjetju in nimajo računa v aktivnem imeniku, bomo uporabili sistemski račun. Pripravili smo tabelo z informacijami o vsakem koraku migracije (Tabela 2) za vsako aplikacijo z informacijo o kontaktni osebi velikosti aplikacije in novi lokaciji aplikacije. Zagotovili smo dovolj prostora na testnem sistemu za testne migracije kot tudi dovolj prostora na produkcijskem sistemu avstrijskega intraneta in na strežniku za arhiv. Zastavljen cilj je bila migracija vseh aplikacij, ki so še vedno v uporabi. Po migraciji smo aplikacijo arhivirali. V kolikor aplikacija ni bila uporabljena že več kot dve leti, smo jo izbrisali. Če je vsebovala podatke, povezane s podjetjem, smo te podatke arhivirali. Migracijo smo opravili v najmanj treh korakih. Definirali smo globalnega Lotus Notes uporabnika, ki je imel pravice do vseh aplikacij, saj smo morali nastaviti pravice preden smo arhivirali aplikacije. 32

43 Tabela 2: Primer tabele za evidenco in statusa migracije aplikacij v Lotus Notes Ko smo si pripravili vsa pravila in si zastavili cilje migracije, smo lahko začeli proces migracije. Kot navedeno, je morala biti migracija izvedena vsaj trikrat in je potekala na sledeč način: 1. V kolikor je analiza aplikacije pokazala, da jo lahko izbrišemo, smo jo odstranili iz Lotus Notes Domino strežnika, lastnikov o tem nismo obveščali. 2. V kolikor je bila aplikacija za arhiv, smo: a. naprej nastavili pravice globalnemu uporabniku za poln dostop do aplikacije, b. zaklenili aplikacijo za urejanje, c. aplikacijo (datoteko.nsf) prenesli v arhiv tako, da smo se povezali z Lotus Notes Domino strežnikom in jo iz strežnika, kjer se je datoteka za aplikacijo nahajala, kopirali na arhivski strežnik 3. Migracijo posamezne aplikacije v avstrijski intranet 2007 smo izvedli v naslednjih korakih: a. Prvi korak je bila prepoznava vzorca aplikacije, kar pomeni prepoznati, ali je bila aplikacije sestavljena samo iz shranjenih datotek, samo seznamov ali pa je uporabljala obrazce. b. Na podlagi ugotovitve o tipu aplikacije smo najprej izvedli testno migracijo na tesno okolje s pomočjo produkta Designer, iz prej omenjenega programa Quest Notes Migrator for SharePoint, ki nam je omogočal, da smo lahko polja iz aplikacije ena proti ena preslikali v SharePoint (Slika 10). V primeru, da je bilo potrebno migrirati obrazce, smo za to uporabili produkt Console, ki nam je ponujal nekoliko večji nadzor nad migracijo v InfoPath (Microsoftov produkt iz družine Microsoft Office) obrazce. 33

44 Slika 10: Primer preslikave polj aplikacije Lotus Notes v polja uporabljena v SharePointu s pomočjo aplikacije Quest Notes Migrator for SharePoint Designer. c. V kolikor so se pojavile enostavne napake, kot so na primer predolga imena ali imena datotek z neveljavnimi znaki, smo te napake poskušali sami odpraviti in ponovno izvesti migracijo na testno okolje. d. V kolikor je bila migracija na testno okolje uspešna ali z napakami, ki jih ni bilo potrebno odpraviti, smo obvestili lastnika aplikacije, kako migracija poteka. Dovolili smo mu dostop do testnega sistema, mu s kratko dokumentacijo pokazali, kako izgleda nova rešitev na SharePointu 2007 ter ga prosili, da nam pomaga razrešiti napake, ki jih mi nismo mogli odpraviti. e. Ko je bila testna migracija potrjena in je lastnik z nami definiral potek nadaljnje migracije, smo se lotili migracije na produkcijsko okolje. f. Po prvi uspešni migraciji na produkcijski sistem smo ponovno obvestili lastnika aplikacije, naj preveri vsebino, ki je bila migrirana in potrdi, ali to ustreza rešitvi, ki jo bodo lahko uporabniki uporabljali. V tem koraku so lastnik in uporabniki imeli samo dostop za branje. V kolikor je prišlo do kakšnih sprememb, smo te spremembe tudi naredili in ponovno komunicirali z lastnikom. g. Po potrditvi smo bili pripravljeni na zadnji korak migracije, ki je predstavljal uskladitev urnika, kdaj se bo migracija izvedla. Takrat smo zaklenili aplikacijo Lotus Notes in izvedli zadnjo migracijo na produkcijski sistem. S tem smo povozili vse podatke, ki so bili migrirani v predhodnih fazah migracije na produkcijo. h. Na produkciji smo lastniku in uporabnikom odklenili dostop in jim zagotovili, da lahko začnejo uporabljati podatke v novem okolju. 4. Po uspešni migraciji smo bili lastniku in uporabnikom na voljo za dodatno pomoč in individualno usposabljanje pri uporabi novega okolja. Prav tako smo zagotovili, da 34

45 je bila Lotus Notes aplikacija vsaj za branje dosegljiva še mesec dni po migraciji. Na tak način so lahko uporabniki preverili, ali smo res migrirali celotno vsebino ali pa je morda prišlo do kakšnih napak. 5. Na primeru iz Slika 11 lahko vidimo uporabniški vmesnik pred in po migraciji. Seveda se je vsa funkcionalnost ohranila. Z migracijo v SharePoint smo uporabniku lahko ponudili veliko več svobode pri urejanju njegovih podatkov in prav tako zagotovili bolj enostavno uporabo. To je prispevalo k temu, da so uporabniki prišli z novimi idejami za izboljšave, kot tudi to, da sedaj rešitev uporablja več uporabnikov. Podatkov sedaj ne pošiljajo več k enemu uporabniku, ki je vzdrževal in vnašal podatke. Slika 11: Primer aplikacije v Lotus Notes z obrazcem za element in prikaz migrirane vsebine SharePointu Migracija švedskega intraneta v avstrijski intranet Švedski del podjetja se je v sredini leta 2014 ukvarjal z ukinitvijo velikega dela opreme oddelka IT in s tem tudi ukinitvijo svojega lokalnega intranet okolja. Žal z njihove strani 35

46 skrbnika intraneta več ni bilo na voljo, zato je ekipa IT dodelila pravice naši globalni intranet ekipi na strežniku, od koder smo lahko vstopili v SharePoint. Najprej smo se lotiti preverjanja stanja sistema, kako je le ta velik v smislu strojne arhitekture in strukture intraneta. Po pregledu okolja smo ugotovili, da ne gre za prav kompleksen intranet in sam proces migracije naj ne bi bil zahteven. Poročilo sistema je obsegalo tri A4 strani in je vsebovalo velikost SharePoint farme, število strani portala, velikost podatkovnih baz, število aktivnih strani, določitev vsebin, ki so še v uporabi glede na zadnji dostop. Pripravili smo tabelo, ki je vsebovala ime aplikacije v SharePointu, število elementov v njej in kdaj so bili elementi v njej nazadnje spremenjeni. Ugotovili smo, da je bilo samo nekaj knjižnic zanimivih za nas, pri vseh ostalih je preteklo že 3 leta ali več od zadnje spremembe. Iz statistike strani smo uspeli razbrati tudi, kolikokrat so uporabniki dostopali do strani v zadnjih tridesetih dneh in koliko elementov je bilo spremenjenih v tem času. Metrike so nam pokazale tudi, kakšno je povprečno število obiskov na dan (Tabela 3) in koliko uporabnikov skupno še preverja, ali ureja vsebino. Tabela 3: Metrike obiska Švedskega intraneta, Julij 2014 Metrika Vrednost Povprečno število zahtevkov na dan za zadnjih 30 dni 8 Število različnih uporabnikov za zadnjih 30 dneh 9 Število različnih uporabnikov samo včeraj 3 Število zahtevkov samo včeraj 14 Zbrano statistiko smo posredovali odgovornim za odpravo strojne opreme in samim uporabnikom te vsebine. Statistika je vsebovala tudi prvo testno migracijo na naše testno okolje, kjer smo hoteli preveriti tudi, ali imajo uporabniki dostop za testiranje, saj so se njihovi računi nahajali v drugi domeni. Ker je švedski intranet tekel na SharePointu 2007, smo za lažjo migracijo kot cilj izbrali prav SharePoint 2007 okolje in ker je bil avstrijski intranet najprimernejši in aktiven kot tudi dokaj blizu, smo izbrali tega. Za orodje migracije smo uporabili kar ukazno vrstico, ki je bila dovolj za ta namen. Najprej smo izvedli ukaz za izvoz vsebine, na kar se je želena stran shranila v datoteke na lokalnem strežniku, kjer je sistem tekel. Nato smo novo ustvarjene paketne datoteke tipa.bak prenesli na ciljni strežnik. Na ciljnem strežniku smo 36

47 nato naredili novo prazno stran, za tem pa pognali ukaz iz ukazne vrstice za uvoz paketov. Na našem testnem sistemu se je tako kreirala kopija strani iz švedskega intraneta. Uporabniki so ugotovili, da imajo nekaj težav z dostopom do novega sistema, kot tudi, da manjka nekaj podatkov. Po ponovni analizi smo ugotovili, da podatki res manjkajo, čeprav je na prvi pogled kazalo, da se je preneslo vse, je bil prenos samo navidezen in brez podatkov. Ker so nekateri izmed seznamov bili med sabo povezani, uvoz ni znal kreirati knjižnic ob pravem času in je zato izgubil referenco. Vajo z izvozom in uvozom smo morali ponoviti na testnem sistemu tako, da smo najprej ustvarili osnovne sezname, ki so nato služili kot referenčni seznami za druge sezname. Ko nam je uspelo popraviti to napako, smo ugotovili, da več kot ene verzije elementov ne moremo izvoziti zaradi prevelike količine podatkov. Po ponovnem pogovoru z uporabniki smo dobili zeleno luč, da lahko migracijo izvedemo samo z zadnjo verzijo elementov. Za njihovo delo in sledljivost zgodovina podatkov ni bila nujna, zato smo jo lahko ob migraciji izpustili. Izvedli smo še zadnjo migracijo na testni sistem in obvestili uporabnike, naj preverijo stanje. Zgodilo se je ponovno nekaj nepričakovanega. Za nekaj časa se je ustavil proces ukinitve strojne opreme na Švedskem zaradi nekaterih kadrovskih postopkov. Z njihove strani več kot pol leta nismo slišali nobenih novic v povezavi z migracijo podatkov. Nakar so nas obvestili, da je migracija sedaj nujno potrebna in da jo moramo izpeljati v roku tedna dni. Ker smo si celotno dokumentacijo in potek migracije nazadnje shranili, nam sedaj ni bilo težko ponoviti hitre analize, ker je bila situacija podobna. Za tem smo izvedli migracijo na produkcijski sistem. Ponovno je prišlo do nepredvidljive situacije, ko smo zaradi nujnosti migracijo izvajali v delovnem času in je sistem v trenutku postal počasen in nestabilen. Migracijo smo morali preklicati in jo izvesti izven delovnega časa. Nato je potekalo vse, kot mora, le indeks, ki beleži spremembe v sistemu, je nekoliko dlje potreboval ob naslednjem indeksiranju. Po zaključeni in odobreni zadnji migraciji smo povzeli celoten proces migracije tega okolja in prišli do naslednjih zaključkov. Uporabniki bodo še naprej uporabljali tisto, kar poznajo, če jim ne omejimo dostopa do vsebine. Ker se ciljno okolje ni dosti razlikovalo od vira razen malih sprememb v obliki, uporabniki niso imeli težav za vpeljevanjem. Takoj so začeli uporabljati vsebino od tam naprej, kjer so ostali v starem sistemu. Ugotovili smo 37

48 tudi, da se noben uporabnik podrobneje ne poglablja v vsebino, ki ni neposredno povezana z njim in se zanjo ne počuti odgovornega. Iz tega razloga stare vsebine nismo migrirali, čeprav bi po našem mnenju katera od vsebin še prišla prav nekomu drugemu. Vendar po zaključeni migraciji stara vsebina ni več dosegljiva in je migracija uradno potrjena in zaključena. Iz te enostavne migracije smo odnesli tudi to, da ni važno, kako enostavno izgleda vsebina, tudi samo z uporabo osnovnih gradnikov SharePointa pride do zapletov. Kaj bi šele bilo, če bi bila v ozadju implementirana lastna rešitev, katere zgradbo ne bi poznali Migracija prehodnega avstrijskega intraneta Zaradi zelo nizke uporabe tega intraneta, čeprav je bilo vanj vloženih veliko sredstev, ni bilo potrebno migrirati veliko vsebin. Celotno vsebino intraneta smo lahko hitro analizirali in tudi sama migracija vsebine je potekala relativno hitro. Večji del vsebine na tem intranetu je bil v lasti skupine IT. Prav zaradi tega smo skrbniki dokaj hitro lahko opravili pogovore in dogovore o migraciji z lastniki. Migracija je v večini obsegala dokumentne knjižnice, kjer ni bilo potrebno vključiti metapodatkov in smo za migracija lahko uporabili orodje Windows Explorer (Slika 12). Na tak način je migracije podatkov potekala na popolnoma enak način kot poteka kopiranje dokumentov na samem računalniku v okolju Microsoft Windows. Slika 12: Uporaba orodja Windows Explorer za prenos dokumentov med okolji SharePoint Pri takšni migraciji obdržimo strukturo dokumentov in do manjšega odstopanja lahko pride samo pri prikazu dokumentov na novi SharePoint strani (Slika 13Error! Reference source not found.). 38

49 Slika 13: Primer dokumentne knjižnice pred in po migraciji Migracija je zajemala tudi sezname, ki so bili pripravljeni s posebej definiranimi stolpci. Prav tako tudi pristop migracije seznamov ni bil zahteven, kajti možno jih je bilo odpreti v načinu za urejanje, od koder je bilo celotno vsebino mogoče kopirati. Na ciljni lokaciji smo pripravili popolnoma enak seznam z enako poimenovanimi stolpci, kjer smo le-tega lahko prav tako odprli v načinu za urejanje in vanj prilepili vsebino iz vira. Po prenosu vsebine na novo lokacijo so uporabniki lahko hitro spet nemoteno nadaljevali z delom. Migracija ni zajemala wiki strani in spletnih dnevnikov, kajti po pogovorih z uporabniki ta vsebina ni bila več relevantna, zato smo omejili dostop za uporabnike do preostale vsebine. Celoten postopek migracije vsebine na tem intranetu smo zaradi nizke stopnje kompleksnosti lahko zaključili v roku treh tednov in strežniki so bili pripravljeni na izklop Migracija oziroma ukinitev prehodnega intraneta v podjetju Kot smo navedli, je prehodni intranet v podjetju služil namenu komunikacije podjetja z zaposlenimi in obveščanje uporabnikov o dogodkih v podjetju kot tudi o spremembah in drugih novostih. Obiskanost intraneta je bila v začetku leta 2012 zelo visoka, saj je vseboval zanimive informacije o podjetjih, ki so se združevala v eno. Nato je obiskanost v letu 2015 padla, kar lahko lepo vidimo tudi iz metrike na Slika

50 Slika 14: Matrika dostopa do prehodnega intraneta eno leto po migraciji, december 2015 Po analizi prehodnega intraneta smo ugotovili, da so podatki na portalu neprimerni za migracijo na nov globalni intranet. Sestavljeni so bili iz nekoliko zastarelih podatkov, prilagojenih spletnih dnevnikov in informacij o podjetju, ki niso bile več aktualne. Prav tako so se posamezni oddelki, ki so imeli svojo vsebino na tem intranetu, v času analize nekoliko spremenili. Zato smo se odločili kontaktirati lastnike vsebine in jim na kratko razložili, zakaj migracija za njihovo vsebino ni primerna oziroma, kako bi najbolje bilo vsebino, ki jo imajo na intranetu, prenesti na nov intranet. Komunikacija in migracija je potekala po naslednjem načinu: 1. Lastnike vsebine smo kot prvo obvestili o migraciji njihove vsebine. 2. Po pregledu vsebine smo skupaj poiskali postopek migracije oziroma rešitev. a. Vsebina ne bo migrirana, ampak bodo lastniki pripravili novo vsebino. b. Nova vsebina po pripravljena neposredno na novem intranetu. c. Dostop do prehodnega intraneta se omeji oziroma zapre. 3. Ko smo se o spremembah dogovorili z oddelki, smo na prehodnem intranetu pustili delovati samo še nekaj strani z video posnetki, ki pa od tega leta naprej več niso pomembni. 4. Ob prenosu oziroma pripravi vsebine na novem intranetu smo bili skrbniki intraneta nenehno na voljo za pomoč in usposabljanje ter uvajanje uporabnikov na SharePoint Prehodni portal se nahaja v fazi popolnega zaprtja portala in odstranjevanja strežnikov, vendar ta del ne bo del našega diplomskega dela Migracija Documentum v nov globalni intranet SharePoint 2013 Ta migracija je bila najkompleksnejša in je zajemala delo naše ekipe kot tudi sodelovanje zunanjega partnerja. Postopek migracije se je za sistem Documentum pričel že v letu 2013 in je bil razdeljen v dve fazi. Prvo fazo smo opravili sami, kjer smo ugotovili, da za tak obsežen projekt v oddelku nimamo dovolj osebja. Zato smo v drugi fazi vključili zunanjega partnerja in našo podporo pri določenih skrbniških delih. 40

51 Projekta smo se v oddelku IT skrbniki sistema lotili tako, da smo najprej preverili obstoječe stanje sistema Documentum in preverili zgradbo in vsebino. Documentum je bil zgrajen po podobni strukturi, kot so na primer datoteke na našem zasebnem računalniku, vendar se najvišji nivo map imenuje kabinet. Vsak kabinet ima lahko dodeljene unikatne pravice za dostop. Kabineti so bili zgrajeni za posamezne oddelke v podjetju, kar pomeni, da so oddelki lahko imeli enega ali več kabinetov. Nato smo preverili, kdo so lastniki teh kabinetov in kateri so uporabniki. Pregledali smo samo vsebino sistema in ugotovili, da si lahko kot osnovno pravilo zadamo migracijo dokumentov, ki so mlajši od dveh let. Seveda brez potrditve takšnega pristopa s strani lastnikov kabinetov nismo smeli sami sprejeti, zato smo potrebovali njihovo odobritev, ali smemo uporabiti tako grob selektiven pristop. Prav tako smo morali paziti na vse metapodatke dokumentov, da se ne bi izgubile dodatne informacije o dokumentih, ki so jih uporabniki pripravljali nekaj let. Na podlagi teh podatkov smo sklenili, da sistem Documentum ne bomo migrirali v nov intranet v enem koraku, ampak bo to moralo potekati v korakih za vsak kabinet oziroma vsaj za vsak oddelek posebej Enostavna definicija migracije sistema Documentum: Definirali smo, da bomo začeli migracijo dokumentov s kabineti z najmanj podatki in nadaljevali proti kabinetom z več vsebine. S tem se bomo imeli na začetku hitrejšo migracijo in manj možnosti za napake, ki jih je pri manjšem vzorcu lažje obdelati. Določili smo, da bomo najprej obvestiti vse zaposlene v podjetju, da se bo pričela migracije sistema Documentum in kakšna bodo pravila migracije, kot na primer to, da bomo migrirali samo dokumente mlajše od dveh let in kam bomo migrirali vsebino. V primeru, ko se lastniki ne odzovejo našim sporočilom, obvestimo še uporabnike, v kolikor se tudi ti ne odzovejo po drugem pozivu, migriramo dokumente stare manj kot dve leti iz določenega kabineta v arhiv in ne na nov intranet. V kolikor se lastniki oziroma uporabniki odzovejo, sledimo njihovim navodilom in migriramo določeno vsebino na nov intranet in/ali v arhiv. Proces migracije sistema Documentum: 1. Kontaktirati lastnika kabineta ali več kabinetov in se pozanimati, ali je v njihovi lasti še kakšen kabinet. Nato seznam kabinetov za lastnika pošljemo skrbniku sistema Documentum. 2. Skrbnik pripravi tabelo vseh dokumentov, ki so v izbranih kabinetih in jih pošlje lastniku za odobritev ali posodobitev. 41

52 3. Ko lastnik potrdi dokumente, ki so potrebni za migracijo, skrbnik vse navedene dokumente kopira iz sistema Documentum v definiran prostor na arhivskem strežniku. 4. Istočasno skrbnik ustvari tabelo, v kateri zbere metapodatke o kopiranih dokumentih. Ta tabela vsebuje tudi točno pot, v katerih mapi se dokument nahaja. 5. Ustvari tudi tabelo samo s strukturo map izbranih kabinetov. 6. Na novem intranetu pripravimo stran za kabinet, ki bo migriran in dodelimo dovolj prostora, tako na testnem sistemu kot produkciji. 7. Začetek migracije v testno okolje novega intraneta z orodjem ShareGate: a. V orodju izberemo uvoz v SharePoint. b. Izberemo izvor dokumentov in izberemo naslov SharePoint 2013 strani in na njej ciljno dokumentno knjižnico kamor želimo migrirati dokumente (Slika 15). Slika 15: ShareGate orodje s prikazom okna za izvor in cilj migracije dokumentov c. Iz menija izberemo uvoz iz Excel tabele, kjer izberemo tabelo, ki jo je skrbnik pripravil in vsebuje vse metapodatke o dokumentih kopiranih v začasen arhiv. d. V naslednjem oknu izberemo predlogo, ki jo bomo uporabili za migracijo. e. Uredimo predlogo tako, da pregledamo polja z metapodatki. Preverimo, iz katerih in v katere polja se bodo prenesli podatki, preverimo tudi, ali so nastavljeni datumi in preverimo polja o avtorjih, nastavimo vse ostala polja, ki ustrezajo tipu vsebine in shranimo predlogo. f. Ko imamo vse nastavitve v predlogi pripravljene lahko zaženemo migracijo z izbiro predloge, ki smo jo pravkar uredili. g. Ko se migracija datotek začne, moramo spremljati, ali je prišlo do kakšne napake, na kar nas program obvesti z oknom za obvestila. h. Ko se migracija zaključi, pripravimo poročilo o migraciji, ki je dostopno iz menija. Popravimo ga tako, tako da so vsa obvestila o napakah in kritični statusi na vrhu dokumenta ter pripravljeno poročilo pošljemo skrbniku sistema Documentum. 42

53 i. Preden lahko opravimo naslednjo testno migracijo brez napak, je potrebno odpraviti napake v poročilu prve migracije. Napake, kot na primer predolgo ime oziroma nedovoljene datoteke so morale biti odpravljene s strani skrbnika sistema Documentum. j. Ko so napake opravljene, ponovno zaženemo migracijo na testno okolje, pri čemer ni potrebno brisati že migrirane dokumente, ker bodo dokumenti preneseni v prejšnji ponovitvi avtomatsko preskočeni. 8. Preden lahko začnemo migracijo na produkcijski sistem, je potrebno korake pod točko 6. ponoviti nekajkrat, da odpravimo vse napake in šele nato lahko začnemo z migracijo na produkcijski sistem. 9. Preden začnemo migracijo v produkcijsko okolje, obvestimo lastnika in uporabnike, da bomo njihovo vsebino zaklenili za pisanje in omogočili samo branje. To je samo varnostni sistem, da med postopkom migracije ne pride do sprememb izvorne vsebine. 10. Migracijo v produkcijo izvedemo po enakem postopku kot migracijo v testno okolje. a. Skrbnik sistema Documentum izvede popoln izvoz datotek v datotečni sistem in ustvari tabelo z vsemi zadnjimi podatki in odpravljenimi napakami. b. Ko so vsi dokumenti pripravljeni na datotečnem sistemu, začnemo z migracijo v produkcijsko okolje novega intraneta. Uporabimo enak postopek kot pri migraciji na testno okolje, le da spremenimo ciljno lokacijo. 11. Vzporedno, ko je migracija na testni sistem uspešna in migracija produkcijo pripravljena, nas čaka najpomembnejši del, in sicer uvajanje uporabnikov. a. Lastnika in uporabnike obvestimo, da smo pripravljeni z migracijo podatkov in določimo datum za skupinsko uvajanje. b. Kot prvo z uporabniki opravimo trening na testnem okolju, kjer imajo vse potrebne pravice za nadaljnje delo. Na testnem sistemu imajo vse dokumente na voljo, ki jih poznajo in se s pomočjo le teh naučijo uporabe osnovnih funkcij SharePointa. c. Po osnovnem usposabljanju uporabnikom pustimo proste roke za samostojno uvajanje, nakar jim v roku tedna dni, odvisno od predznanja uporabe SharePointa, predamo v roke novo lokacijo na produkciji. To lokacijo začnejo uporabniki uporabljati za svoje vsakdanje delo, ko je med tem uspešno zaključena migracija na produkcijo. 12. Migracija je zaključena, ko lastnik potrdi, da so bili vsi definirani dokumenti migrirani na nov intranet in ko imajo vsi definirani uporabniki dostop do teh dokumentov. Zgoraj navedeni koraki so se izvajali v obdobju treh mesecev, nakar se je interna delovna ekipa zmanjšala in so ostali člani postali s tem zahtevnim in dolgotrajnim postopkom preobremenjeni. Pojavila se je potreba po vključitvi zunanjega partnerja, ki bi projekt lahko nekoliko hitreje izpeljal. Tako se je projekt migracije zaustavila za obdobje pol leta, dokler ni bilo vse pripravljeno za drugo fazo. V tej fazi je bilo delo razdeljeno na sledeč način. 43

54 Zunanje podjetje je zadolženo za celotno komunikacijo in trening z uporabniki, kar zajema iskanje lastnikov in uporabnikov vsebine ter zagotavljanje pravilne potrditve načina in vsebine migracije. Skrbniki intraneta smo bili zadolženi, da kreiramo zahtevane strani za kabinete in da se dodeli dovolj prostora kot tudi, da se uporabnikom dodelijo vse potrebne pravice. Poseben poudarek smo skrbniki posvetili nadzoru in spremljanju napredka migracije. V namen nadzora migracije smo pripravili stran na novem globalnem intranetu (Slika 16), kjer se je vodil celoten potek in status migracije. Zunanji partner je navajal vse statuse in dodajal dokumentacijo o poteku migracije. Navedena je bila celotna komunikacije z lastniki kabinetov. Prav tako so vsi uporabniki imeli in še imajo dostop do te strani, kjer lahko zelo hitro najdejo podatke, kam se je migriral njihov kabinet. Slika 16: Delovna stran na novem intranetu za spremljane poteka migracije vsebine sistema Documentum Migracija je s pomočjo zunanjega partnerja potekala podobno kot pred tem naša interna migracija. Skrbniki smo imeli manj dela s samo vsebino, ki se je migrirala in smo se lahko posvetili vzpostavitvi ciljnega intraneta. 1. Zunanjemu podjetju smo posredovali seznam kabinetov za migracijo. 2. Podjetje se je migracije lotilo po fazah, in sicer so nam v paketih pošiljali naslednje informacije: ime kabineta za migracijo, seznam lastnikov oziroma uporabnikov, ki potrebujejo dostop, velikost in datum testne migracije. 3. Naloga skrbnikov intraneta je bila pripraviti novo stran za oddelek, ki bo nosila ime kabineta po postopku opisanega v poglavju pod temo priprava strani za 44

55 oddelek. Tu smo si pomagali z avtomatsko skripto, kjer smo določili velikost za to stran. 4. Na novi intranet strani smo pripravili tri skupine za različne pravice, in sicer za branje, pisanje in poln dostop in v njih pravilno razporedili uporabnike s seznama, ki nam je bil posredovan. 5. Ko so bile zahteve potrjene in pripravljene, smo o tem obvestili zunanjega partnerja, ki je nato pričel z migracijo. 6. Migracija se je najprej izvedla na testni sistem, kamor so migrirali 5 30 % vsebine iz sistema Documentum in obvestili uporabnike. Uporabniki so preverili ali je prava vsebina na voljo in ali lahko vidijo vse metapodatke, ki jih potrebujejo. 7. Po vseh odpravljenih napakah in potrditvi uporabnikov so pričeli z migracijo kabineta na produkcijsko okolje in za tem zaprli dostop do kabineta v sistemu Documentum. 8. Za uporabnike smo izvedli izobraževanje in jih usposobili za uporabo novega sistema, prav tako smo jim star sistem pustili dostopen samo za branje vse do konca vseh migracij. Odziv uporabnikov na novo pridobitev je bil zelo dober. Veliko uporabnikov je imelo težave pri poznavanju novega okolja, predvsem pa so se vsi spopadali z obsežno možnostjo dodeljevanja pravic na vseh nivojih v SharePointu Skrbniki intraneta so uporabnikom zato zmeraj na voljo za individualna usposabljanja oziroma v pomoč pri vsakodnevnih nalogah, pri dodeljevanju pravic in podobno. Na podlagi tako obširne migracije, kot je bila migracija sistema Documentum, so uporabniki spoznali delo z dokumenti v SharePointu, kar zajema zelo mali del funkcionalnosti SharePointa. Na omejeno uporabo novega sistema smo postali pozorni pri opravljanju naše ankete, ki jo podrobneje opišemo v poglavju 5.6. Na podlagi teh spoznanj uporabnike vedno bolj obveščamo o dodatnih možnostih, ki jih SharePoint ponuja v primeru, ko zahtevajo individualna usposabljanja za delo z intranetom. Migracija sistema Documentum je bila zahtevana in dolgotrajna, vendar na koncu so vsi uporabniki bili zadovoljni, da je vse potekalo tako, kot je potrebno in da so bili obveščeni o vsakem koraku migracije, ki je bil pomemben za njih. Odziv uporabnikov na izboljšanje dela z dokumenti je bil zelo pozitiven, vsi so sprejeli novo okolje z navdušenjem. Manjša težava se je pojavila na temo pravic, kjer se je zataknilo veliko uporabnikom in so se novega okolja ustrašili in ga mogoče zato uporabljajo manj, kot bi ga v primeru, če bi pravice bile rešene enostavneje. Zato smo več poudarka posvetili tudi temu poglavju in sedaj pravic ne omejujemo več, le če se uporabniki s tem strinjajo in hočejo sami urejati dostope, do njihove vsebine in razumejo, kako bodo to uredili. 45

56 5 NOV GLOBALNI INTRANET Tu se bomo osredotočili na samo nekaj komponent novega globalnega intraneta. Najprej bomo izpostavili, na katere aktivnosti moramo biti pozorni pri vzpostavitvi intraneta. Nato bomo povzeli našo zgodbo, ki zajema začetne analize in izgled portala, do arhitekture in oblikovanja novega intraneta. Ob uvajanju novega intraneta preko ukinjanja starih rešitev se v podjetju lahko zanašamo na izkušnje. Vendar vedno znova so nam v zelo veliko pomoč napotki, ki nam jih ponujajo podjetja, ki se dnevno ukvarjajo s postavitvijo intranetov in migracijami ter imajo za sabo že veliko več projektov. Zato bomo najprej preverili, kako bi postavili nov intranet na podlagi lastne analize obstoječih okolij, nato si bomo pomagali na primeru napotkov podjetja Metalogix. Izdelali smo lastno anketo in manjši skupini uporabnikom zastavili nekaj splošnih in nekaj konkretnih vprašanj o SharePointu, kajti to je platforma, ki nas najbolj zanima. 5.1 Aktivnosti pri uvajanju intraneta Izkušnje, ki smo si jih nabrali v nekaj letih uporabe intraneta in po vzpostavitvi že nekaterih starejših različic intraneta, niso vedno dovolj, da uberemo dober postopek za nov intranet. Zato si moramo pri vzpostavitvi novega intraneta pomagati tudi z dokumentiranimi izkušnjami drugih uporabnikov. V našem primeru smo si za referenco izbrali seznam, katere aktivnosti moramo upoštevati pri vzpostavitvi in vodenju novega intraneta, le-te navajamo v Priloga B. Najpomembnejše so začetne aktivnosti, preden začnemo z vzpostavitvijo intraneta. V podjetju je sodelovanje z interesno skupino, ki v popolnosti stoji za projektom, v tem primeru ena od ključnih aktivnosti, da lahko projekt uspešno začnemo. Aktivnosti, namenjene interesni skupini, so prikazane v Tabela 4, kjer lahko vidimo tudi zahtevnost posamezne aktivnosti. Preostale aktivnosti pri uvajanju intraneta v podjetju se zraven že navedene aktivnosti vodji projekta delijo še v aktivnosti o ozaveščanju uporabnikov, kar pomaga pri uporabi SharePointa in aktivnosti izobraževanja uporabnikov, kar jim pomaga razumeti vrednost portala. Vse aktivnosti so zbrane in natančno opisane v [11]. 46

57 Tabela 4: Tabela aktivnosti vodij projekta oziroma interesne skupine Aktivnosti Pred zagonom Zahtevnost Identifikacija ključne interesne skupine X Nizka Vključitev izvršnih pokroviteljev X Nizka Določitev aktivnih ciljev in pot do rešitev v SharePointu X Srednja do visoka Določitev meril za uspešen projekt X Srednja do visoka Priprava komunikacijskega načrta X Nizka Usposobitev tehnične podpore X Nizka do visoka 5.2 Gradniki intraneta Pri oblikovanju novega združenega intraneta smo se zatekli k že preverjenim metodam obstoječih portalov. Iz le teh bi radi izvzeli tiste gradnike, ki so zaposlenim najpomembnejši oziroma jih največ uporabljajo. Prav tako pa bi radi ponudili tudi nabor novih možnosti, ki jih uporabniki intraneta do zdaj niso poznali. Predvsem hočemo iti v smer, kjer bomo uporabniku ponudili dobre predloge, ki jih bodo sami ali z našo pomočjo v prihodnje lahko poljubno nadgradili. Za ta namen smo se v intranet ekipi odločili, da se posvetimo analizi obstoječih intranetov in preverimo njihovo strukturo ter elemente, ki jih naša že obstoječa intranet okolja vsebujejo. V lastni režiji bomo do potankosti analizirali obstoječe intranete, poiskali bomo skupne točke med temi intraneti in jih poskušali združiti, v kolikor bo le-to mogoče. Na podlagi teh raziskav bomo nato postavili prototip. Naredili bomo nekaj ponovitev, skozi katere bomo opazovali, kako pomembni so posamezni gradniki za nov intranet. Važno je predvsem to, da dobimo odgovor, ali potrebujemo obstoječe gradnike, ali jih smemo zavreči, ali pa jih moramo morda posodobiti Zbiranje podatkov o vsebinski strukturi obstoječih intranetov Za lažje razumevanje zgradbe in uporabe obstoječih intranetov smo se lotiti analize le teh na višjem nivoju. S tem smo hoteli ugotoviti, kateri gradniki so trenutno v uporabi, kako je sestavljena navigacija in ali imajo intraneti kaj skupnih gradnikov. Predvsem pa nas je 47

58 zanimalo, ali lahko ponovno uporabimo katere od elementov, ki so uporabnikom najbolj zanimivi in jih privabljajo na obstoječe portale. Iz že predstavljenih obstoječih intranetov smo sestavili vsebinsko strukturo portalov, kar je razvidno iz Tabela 5. Tukaj smo izpostavili menije in kaj natančno se nahaja pod vsakim od teh menijev. Dobili smo logično strukturo posameznih intranetov, ki nam je pokazala poglavitne elemente oziroma gradnike, ki pripomorejo k prepoznavnosti intraneta in njegovi uporabi. Opazili smo, da intraneti, ki ne vsebujejo nekaterih gradnikov, niso tako obiskani kot drugi. To spoznanje je bilo pomembno za nas pri nadaljnji analizi, da ugotovimo, katere točke menija uporabiti, kako jih poimenovati, in kaj predstaviti pod vsako od teh točk. Morda bi bilo nekatere elemente lažje združiti, preimenovati, ali pa kar popolnoma odstraniti. Celotna struktura nam je služila za lažje delo na prototipih in oblikovanju novega intraneta. Tabela 5: Vsebinska struktura nekaterih obstoječih intranetov Intranet Meni Kategorija vsebine Tip vsebine Avstrijski intranet - SP2007 Home Info Corner Company Departments Great People O podjetju Služba za trženje Kadrovska služba Oddelek za komunikacije Statične vsebine SharePoint vsebine Statične povezave navzven Vgrajene aplikacije Ne deluje Great Products Collaboration Area Processes Services/Tools Ostali oddelki Orodja in servisi Italijanski intranet SP2010 Home Company Corporate Life Work Quality ICT Security O podjetju Kadrovska služba Varnost Delovni prostor in delo v skupini B2B storitve Poslovni razvojni sistem Produkti Oddelek za kakovost Delo na terenu Statične vsebine SharePoint vsebine Statične povezave navzven Vgrajene aplikacije 48

59 Medijske komunikacije Skladnost in pravna služba Novi projekti Ostali oddelki Tveganja USA 1 intranet IntraConnect Oddelek za Statične vsebine ASP Home komunikacije SharePoint vsebine uspace Kadrovska služba Statične povezave navzven Departments Pravna služba Vgrajene aplikacije Resources Finance in nadzor Neznano, ne deluje Applications Vladni odnosi Documetnum vsebina Common Tasks Služba za trženje Directories Ostali oddelki Forms Inovacije Policy Documents Mednarodna Products proizvodnja User Documentation Vodenje projektov Produkti in servisi USA 2 intranet insidecompany.com Oddelek za SharePoint vsebine SP2010 Departments komunikacije Statične povezave navzven (Departmental sites) Kadrovska služba Vgrajene aplikacije Services Pravna služba Microsoft Project Finance in nadzor Neznano, ne deluje Vladni odnosi Služba za trženje Informacijske tehnologije Poslovanje in proizvodnja Globalni Servisi Vodenje projektov Razvoj Sistemi Zaposleni 49

60 5.2.2 Prototipi Pri izgradnji in oblikovanju novega intraneta bomo uporabili gradnike, ki smo jih analizirali v prejšnjem poglavju. Za lažjo predstavo si bomo v procesu oblikovanja intraneta pomagali z mrežnimi oziroma žičnimi modeli (angl. wireframes). Ti modeli nam pomagajo pri predstavi spletnih strani in njihovih gradnikih. Z uporabo žičnih modelov si olajšamo proces priprave strani, saj lahko elemente v teh primerih zelo hitro prilagajamo, zamenjamo in prestavimo. Prav tako so žični modeli odlično orodje za sestanke in osnovne ideje za končne produkte. Za izdelavo žičnih modelov smo uporabili posebno orodje Balzamiq [4], ki zelo dobro opravlja nalogo priprave takšnih modelov in posledično prototipov. To orodje je trenutno najboljše in najbolj enostavno za hitro in zelo efektivno izdelavo žičnih modelov strani. Ker so žični modeli pomemben člen pri pripravi oblike in izgleda ter s tem spletnih ali intranetnih strani in ker nam je orodje v času, ko smo ga testirali, prineslo najboljše rezultate, smo se odločili za nakup orodja. Priprava strukture intranetne strani je dokaj enostavna, prav tako nam orodje ponuja, da uporabimo gradnike, ki so jih pripravili drugi uporabniki. S tem smo imeli na voljo gradnike, ki so prepoznavni za SharePoint, kar nam je v veliko pomoč, da ne prihaja pri pogovorih z uporabniki do nesporazumov. Zelo enostaven primer osnovnih gradnikov SharePoint v orodju Balzamiq si lahko ogledamo na Slika 17. Slika 17: Balzamiq okolje s primerom posnetka SharePoint 2013 strani 50

61 S pomočjo orodja smo sestavili model (angl. mockup) začetne strani intraneta (Slika 18), navigacije in namenske podstrani. Vsak teden smo interno sklicali sestanek, kjer je sodelovalo tri do pet oseb in smo izmenjevali mnenja o gradnikih na posameznih straneh. Skupno smo se prepričali, kateri gradniki so pomembni, kateri zanimivi in katerih sploh ne potrebujemo. Po fazah smo sestavili celoten prototip, ki sestoji iz več posameznih modelov strani. Več primerov pripravljenih modelov smo prikazali v Priloga A. Slika 18: Primer posnetka začetne strani novega intraneta 5.3 Ustavitev projekta vzpostavitve novega intraneta in prehod na obstoječ sistem za nov intranet V postopku priprave novega intraneta leta 2014 se je v podjetju pojavil nov problem, in sicer odhod nekaterih članov drugih intranetnih ekip. To je posledično povzročilo nekaj velikih sprememb, ki jih na začetku projekta novega globalnega intraneta nismo načrtovali. Po tem, ko se je ena ekipa zmanjšala in so prišle njihove naloge na nas, smo spoznali, da so oni že postavili novo Sharepoint okolje, ki bi bilo namenjeno samo za odpravo obstoječega sistema Documentum, katerega migracijo smo opisali v poglavju Vendar po natančnejši analizi se je pokazalo, da bi to obstoječe okolje lahko uporabili za naš novi globalni intranet brez velikih dodatnih posegov v samo okolje. Sam 51

62 sistem je bil že zelo dobro zastavljen, vseboval je glavne komponente, ki smo jih potrebovali na novem intranetu in seveda migracija sistema Documentum se je že začela. Tako ni bilo smiselno postavljati še enega dodatnega okolja. Opustili smo naš že začeti projekt novega intraneta in začeli delo na obstoječem okolju. Ker strukture, ki smo si jo zamislili, nismo mogli tako enostavno vpeljati, smo se dogovorili, da dokončamo migracije v teku in kasneje analiziramo vsebino. Delo na vzpostavitvi novega portala oziroma globalnega intraneta bi tako nadaljevali šele nekoliko kasneje. 5.4 Arhitektura novega globalnega intraneta Za vzpostavitev SharePoint platforme je pomembno, da je arhitektura, na kateri je platforma vzpostavljena, natančno določena, dobro zgrajena in da se ve, katere komponente so za kaj zadolžene. Važno je, da ima sistem produkcijo»prod«(ang. production), testno okolje namenjeno za zagotavljanje kakovosti»qa«(angl. quality assurance) in razvojno okolje,»dev«(ang. development). Vse to je na našem obstoječem okolju že bilo pripravljeno, obenem je vključevalo še okolje za prikaz funkcionalnosti»demo«in okolje, imenovano peskovnik»sbx«(angl. sandbox). Na Slika 19 je prikazano, kako so okolja zgrajena in da so medsebojno neodvisna. Z večjimi okolji si zagotovimo varno delovanje vseh nivojev sistema, kar nam seveda prinaša tudi nekoliko večjo svobodo pri določenih akcijah, kot je migracija, razvoj, testiranje, nadgradnja, uvajanje uporabnikov itd. Nekoliko slabša stran več sistemov je vzdrževanje, kar je časovno zelo potratno, vendar nujno. 52

63 WFE 01 WFE 02 WFEQA 01 WFEQA 02 WFEDEV 01 APP 01 APP 02 WAC 01 APPQA 01 APPQA 02 APPDEV 01 DB 01 DB 02 DBQA 01 DBQA 02 DBDEV 01 WFEDEMO WFESBX 01 DBDEMO DBSBX 01 Slika 19: Arhitektura strežnikov več okolij globalnega intraneta Peskovnik okolje je okolje, kjer naprej namestimo našo platformo z minimalnimi strežniškimi viri in izvedemo vse teste, ki nas zanimajo na novem okolju. Kreiramo vse namenske uporabniške račune, uredimo namestitev zadnje SharePoint verzije, aktiviramo različne storitve, preverimo povezave z našimi ostalimi okolji ter ob tem dokumentiramo vse postopke, vse napake in vse opazke. Šele nato, ko potrdimo scenarije, ki jih hočemo pokrivati, zgradimo in vzpostavimo ostala okolja. Demo okolje nekako izpopolnjuje peskovnik okolje, vendar se razlikuje v tem, da nam to okolje koristi predvsem za demonstracijo elementov, ki jih ne bi radi takoj prenesli na ostala okolja v uporabi. Tu na primer lahko namestimo kakšne aplikacije drugih proizvajalcev in jih testiramo ali demonstriramo. To okolje je tudi prvo, kjer namestimo nove verzije SharePoint produkta in jih tudi testiramo, s čimer preverimo, ali bi nam na ostalih okoljih ta posodobitev prinesla novosti, ki bi jih lahko uporabili, ali pa so nujno potrebne. Prav tako je demo okolje tisto, ki nam ponuja možnosti za opravljanje stres testov, testiranje strojne opreme, opravljanje testov na bazi ali samih nastavitvah SharePointa. Pri čemer lahko hitro naredimo kopijo okolja in v primeru kakršnihkoli napak vzpostavimo staro stanje kar interno na samem okolju. Produkcijsko okolje je seveda najpomembnejše v novem intranetu. Mora biti najhitrejše in imeti na voljo dovolj strežniških virov. V kolikor vemo, da se bo sistem počasi večal, lahko začnemo z minimalno količino strežniških virov. Seveda načrt vsebuje točne določitve, 53

64 vendar lahko v začetnih enostavnejših fazah začnemo z nekoliko šibkejšo različico, da dobimo sliko, kako dobro se opravljajo manjše naloge in nato v kratkem času povečamo strežniške vire na primerno velikost prostora. V kolikor je potrebno več strežniških virov kot smo načrtovali. imamo dovolj časa, da te zahteve popravimo oziroma primerno ukrepamo. Testno okolje je tisto, ki nam služi kot nadomestno okolje v primeru, če bi na produkciji bilo karkoli narobe, zato mora biti arhitektura povsem enaka kot na strežniku, to pomeni enako število strežnikov z enakimi vlogami in enakimi verzijami programov. To okolje je namenjeno predvsem testiranju lastnih rešitev, preden se le-te namestijo na produkcijski sistem. Največjo uporabnost testnega okolja vidimo pri izvajanju usposabljanj uporabnikov. Tukaj jim lahko poljubno definiramo pravice in jih vodimo skozi vse korake uvajanja. Na tem okolju si lahko po usposabljanju uporabniki ustvarijo lastno okolje in izvajajo različne teste, da preverijo funkcionalnosti in delovanje sistema. S tem zagotavljamo večjo kakovost na produkcijskem sistemu, kjer so uporabniki lahko bolj samozavestni pri uporabi okolja za lastne potrebe. Na podlagi testov in izkušenj se uporabniki večkrat vračajo k skrbnikom SharePointa, da se usposabljanja ponovijo, ali pa se uporabnike nauči uporabe naprednejših funkcij okolja. Razvojno okolje je namenjeno predvsem razvoju lastnih rešitev in še pomembneje testiranju, ki ga opravljajo skrbniki, SharePoint analitiki ali drugi uporabniki, ki opravljajo teste, ki niso primerni za produkcijo. Na testnem okolju si lahko namestimo različne aplikacije, ki jih preverimo, ali so morda uporabne na nadaljnje rabo in za produkcijo. Vsekakor je to okolje, ki je namenjeno temu, da opravljamo večje teste na SharePointu in ga v primeru večjih težav s SharePointom lahko hitro podremo in na novo postavimo. Na tem okolju so nameščene programske licence za razvoj različnih rešitev. Tudi zato mora imeti to okolje dovolj strežniških virov, da lahko hitro razvijemo novo intranet rešitev. Vsa tri zadnja okolja se morajo popolnoma ujemati z verzijo in storitvami samo v takšnih primerih lahko po potrebi rešitve prenašamo med sistemi, še posebej, ko potrebujemo že zgrajeno strukturo iz produkcije v razvojnem ali testnem okolju. Le na ta način lahko preverimo robne rešitve, ne da bi s tem uničili produkcijo in nenamerno zaustavili delo uporabnikov. V našem primeru so vsa okolja bila na nekoliko zastareli verziji SharePointa, tako da smo se najprej morali lotili posodobitve sistema. Nato smo nadaljevali z migracijo, ki smo jo opisali v poglavju

65 5.5 Napotki podjetja Metalogix Podjetje nam na podlagi kratkega članka [6] predstavi, kako naj oblikujemo intranet po tem, ko smo že izvedli migracije. Opozarja nas, na kaj se je potrebno osredotočiti in zakaj si je potrebno vzeti čas. Ker smo se nahajali prav v takšnem delovnem scenariju, si bomo pogledali, katere točke izpostavljajo in bi bile za nas pomembne. Devet korakov uspešne preobrazbe SharePoint strani: Poenostavite svoje okolje. Ker se veliko podjetij ukvarja z migracijo obstoječih okolij, je pomembno, da se naredi prehod na samo eno skupno okolje in se obvezno opusti stare intranete. S tem zmanjšamo licenčne stroške, kot tudi vzdrževanje in podporo. Standardizacija strani, strukture in predlog. S standardizacijo se izognemo nepotrebni raznolikosti. Ker ima podjetje en izgled, je prav, da je takšna struktura kot tudi strani in predloge. Vsi se tako držijo enakih pravil in okolje ostaja konsistentno. Poenotenje tipov vsebine. Ob pregledu obstoječega intraneta bi to morala biti ena izmed prvih akcij. V kolikor imamo več tipov vsebine lahko načrtujemo storitve za upravljanje z metapodatki, s čimer bi dobili boljši nadzor nad tem, kakšni tipi vsebine se uporabljajo kje. Očistiti strukturo map. S SharePoint 2010 verzijo se je zgodil velik premik iz map v metapodatke, kar izboljšuje samo iskanje vsebine. Dobro je, da se vse mape premaknejo v eno nivojsko strukturo z metapodatki, v drugačnem primeru morajo biti uporabniki obveščeni kakšne so slabosti uporabe map. Zožimo pravice. Iz sistema odstranimo vse uporabnike, ki več ne obstajamo, naredimo analizo dostopov in dodeljevanje neposrednih pravic zamenjamo z skupinami. Izboljšamo razvrstitev ključnih besed. Pri uporabi tipov vsebine in map je pomembno, da povzamemo in razvrstimo ključne besede za lažje upravljanje vsebine v prihodnje. Zgraditi dosledno navigacijo. Pomembno je imeti logično poenoteno strukturo navigacije in počistiti vse nepomembne elemente, da bodo uporabniki hitreje in lažje našli njihovo vsebino. Spodbujanje novih funkcionalnosti. 55

66 Z velikim naborom novih funkcionalnosti imamo možnost, da le-to predstavimo uporabnikom, morda so nekatere med njimi, ki prej zahtevne postopke, sedaj pohitrijo. Izboljšanje (uvajanje) upravljanja. Ena izmed boljših praks, ki jih poudarjajo vsi, je pomembnost upravljanja intraneta. SharePoint ni zapakiran produkt, potrebna je premišljena namestitev, prilagojena nastavitev in nenehno upravljanje, da zagotovimo podjetju najboljši izkoristek. Skupino za upravljanje naj sestavlja interesna skupina, skrbniki in končni uporabniki. SharePoint je teko rekoč poslovna platforma, ki je vredna več kot samo vsota njenih delov. Ni samo programska oprema in ne samo vrsta strežnikov, zbirka orodij ali podatkov. To je platforma, s katero se posel lahko poistoveti, sodeluje in izboljšuje. Torej, zakaj se večina namestitev začne s strani oddelka IT in brez glasu poslovnega uporabnika? Kako to spremeniti v treh korakih? Izgraditi je potrebno intranet s poslovno rešitvijo v mislih. SharePoint naj se nikoli na vzpostavlja brez jasne poslovne rešitve v mislih. Čeprav so večje sodelovanje in eno intranet okolje dobri tehnični odgovori, s tem nismo ustvarili dodane vrednosti. Potrebno je pripraviti rešitev z več vsebine, kot so na primer dodati tematska poročila ali diagrame, ki se posodabljajo na podlagi realnih podatkov iz zaledja. Imeti jasno sliko rešitev pomaga pri načrtovanju in uspešni rešitvi. V proces je potrebno vključiti končne uporabnike. Nikoli ni preveč, če se poudari, da je uporabnike potrebno vedno vključevati, saj so oni edini tisti, ki zares poznajo svoje podatke in vsebino, s katero delajo, zakaj jih torej ne vključiti. Tem bolj so uporabniki ozaveščeni o projektu, večja je verjetnost, da bodo novo platformo tudi sprejeli. Izrisati si je potrebno informacijsko infrastrukturo v podjetju. V SharePointu ni nič bolj pomembnega kot trdna informacijska infrastruktura. Metapodatki in taksonomija bodo naredili platformo uporabno, dobro za iskanje in funkcionalno. Natančen in jasen izris strukture, navigacije predlog spletnih strani bo vsekakor pomagal pri razumevanju upravljanja v prihodnosti. In seveda, za kaj točno bodo potrebna sredstva za obvladovanje SharePointa na poti naprej. 56

67 5.6 Anketa o uporabi intranetov in SharePointa Za namene ugotavljanja uporabe obstoječih intranetov in dejanskih izkušenj uporabnikov s SharePointom smo pripravili anketo, ki bi nam pomagala vsaj malo razumeti vzorce uporabe intraneta. Anketo sestavlja skupno 21 vprašanj, ki so razdeljena v dve skupini in dodatna možnost za oddajo lastnega mnenja o anketi, intranetu ali SharePointu. Prva skupina vprašanja so vprašanja, kako dobro uporabniki poznajo obstoječe intranete in katere elemente oziroma strani obiskujejo na njih. Iz tega dela smo hoteli pridobiti informacije, kdo uporablja posamezne intranete in katere stvari so za uporabnike zanimive. Druga skupina vprašanj se je nanašala na SharePoint platformo na splošno, našteli smo komponente SharePointa in preverili, katere od teh uporabniki najbolje poznajo. Vprašalnik smo poslali 75 zaposlenim, o katerih menimo, da bi lahko posredovali najzanimivejše informacije o SharePointu in ostalih obstoječih intranetih v podjetju. Skupno smo dobili 48 odzivov, ki so nam v prvem koraku podali zelo zanimive ocene. V prilogi C lahko vidimo vsa vprašanja in odgovore na anketo. Po prvem delu vprašanj vidimo, katere strani uporabniki uporabljajo na posameznih intranetih. Vsekakor smo bili presenečeni, da uporabniki ne poznajo vseh intranetov, kot tudi to, da na njih ne uporabljajo veliko zanimivih strani. Čeprav je bila izbrana skupina ljudi, ki nekako največ sodelujejo z ekipo skrbnikov za SharePoint in še nekaj naključno izbranih, tak rezultat ni bil pričakovan. Na podlagi teh odgovorov imamo sedaj boljšo predstavo o tem, katere strani so zanimive za uporabnike in katere gradnike moramo najprej bolje predstaviti na novem intranetu. Če v prilogi C preverimo sedemnajsto vprašanje, lahko vidimo zelo zanimiv vzorec. Uporabniki res uporabljajo SharePoint, ampak dejansko ne poznajo niti vrha ledene gore, čeprav so jim vse komponente na razpolago. V večini primerov uporabljajo samo dokumentno knjižnico, kot so se naučili pri oziroma ob postopku migracij, morda še koledar in se tu uporaba zaključi. Nekaj jih še uporablja funkcijo kreiranja podstrani, ker se ob kreiranju novih strani avtomatsko ustvari tudi dokumentna knjižnica ki jo potrebujejo. Prav zaradi uporabe dokumentov jih večina uporablja urejanje pravic in opcijo za deljenje dokumentov. Vse ostale funkcije so neuporabljene. Zakaj je to tako? Kje delamo napake in kaj je potrebno spremeniti? Prav na ta vprašanja dobimo odgovore v naslednjem 18. vprašanju, kjer se vsi strinjajo s tem, da bi radi veliko več individualnega usposabljanja na SharePointu. Odgovore na vprašanje 16, prikazuje Slika 20. Odgovori so nas presenetili v 57

68 tej meri, da veliko uporabnikov samih ureja svojo vsebino. Čeprav smo mislili, da smo skrbniki tisti, ki jim urejamo strani, ta del je vsekakor bil zelo pozitiven. Slika 20: Odgovori na vprašanje ankete, kdo vam ureja spletno intranet stran Rezultati ankete so pripomogli k temu, da smo dobili trenutno sliko o tem, kako so uporabniki seznanjeni z intraneti. Nekako se je pojavilo še več vprašanj, kot pa smo dobili odgovorov. Na teh odgovorih bomo poskušali graditi boljšo komunikacijo z uporabniki. Vsekakor pa je to bila priprava na naslednji korak, ki bo ponovno vprašalnik, vendar bo zajemal za večjo skupino ljudi in bo usmerjen bolj globalno in poslovno, od koder si prizadevamo dobiti informacije, katere poslovne scenarije bomo v prihodnje morali pokrivati. 5.7 Primeri lastnih rešitev Novi intranet na platformi SharePoint 2013 se je začel uporabljati prvotno samo kot dokumentni sistem, saj so uporabniki potrebovali prostor za svoje podatke iz starih sistemov. Šele kasneje smo na novem SharePointu vzpostavili portal, ki služi kot novi intranet. Za sam postopek migracije smo morali na primer implementirati avtomatsko kreiranje strani za ekipe, voditi evidenco teh strani in jih še prej preizkusiti na testnem sistemu. Avtomatsko kreiranje strani za oddelek ali ekipo se je implementiralo s skripto. Na portalu smo počasi začeli ponujati enostavne, a učinkovite elemente, ki povečajo uporabnost informacij na strani. Ti elementi so pripravljeni s pomočjo kode, ki se izvaja na strani uporabnika in ni potrebno pošiljati vseh elementov iz strežnika do uporabnikovega 58

69 računalnika. Ker je procesorska moč računalnikov vedno večja, si lahko privoščimo implementacijo dokaj zahtevnih rešitev. Vključitev SharePointa v proces dela različnih ekip ni enostavna naloga. Ker pa intranet okolje ponuja delo z delovnimi tokovi, je zadeva seveda nekoliko lažja. Ko se uporabnikom prikaže možnost potrditve različnih aktivnosti, kot so potrjevanje dopustov, potovanj ali potrditve sprememb v dokumentih, se različni scenariji uporabe delovnih tokov komaj začnejo. Kako ostati inovativen in ponuditi dodano vrednost uporabnikom intraneta, so vsekakor dnevni izzivi skrbnikov intraneta, ki morajo svoje okolje poznati do potankosti, da se s temi izzivi čim lažje spopadajo Stran za usposabljanje uporabnikov Za enostavnejši začetek dela s SharePointom smo uporabnikom pripravili SharePoint stran za usposabljanje. Na Slika 21 lahko vidimo vstopno stran, kjer lahko uporabniki najdejo v sliki in videu vse akcije, ki jih za začetek svojega dela potrebujejo. Stran za usposabljanje uporabnikov je odlična lokacija za uvajanje uporabnikov, kot tudi za vse napredne funkcije SharePointa, ki jih uporabniki lahko sami najdejo. V kolikor uporabniki z vsebino še vedno niso zadovoljni, jim skrbniki SharePointa ponujamo tudi možnost dodatnega individualnega usposabljanja. Opažamo, da si uporabniki ne vzamejo nekaj minut časa, da bi prebrskali vsebino na straneh za usposabljanje. Prav zato so individualna usposabljanjaena naboljj priljubljenih metod podajanja znanja novim in obstoječim uporabnikom, kar je pokazala tudi anketa opisana v

70 Slika 21: Izgled strani za usposabljanje uporabnikov na novem intranetu Nov prikaz koledarja Ena prvih lastnih rešitev, ki smo jih uporabili, je bil razumljiv in jedrnat prikaz dogodkov iz koledarja. Veliko projektnih ekip ali oddelkov na svojih intranetnih straneh uporablja SharePoint aplikacijo za koledar, kar vsekakor samo po sebi prinaša veliko dodano vrednost. Za urejanje in vnašanje dogodkov v koledar je funkcionalnost dokaj uporabna, tudi zato, ker je koledar možno sinhronizirati s poštnim odjemalcem programom Microsoft Outlook. Vendar pri prezentaciji oziroma prikazu koledarja SharePoint ne omogoča veliko fleksibilnosti. Prav zato smo se odločili, da s pomočjo HTML5, CSS3 in JavaScipt implementiramo lasten prikaz koledarja, ki bo ekipi na prvi pogled prikazal, kaj se dogaja v naslednjih dneh. Ideja in namen takšnega koledarja sta bila ta, da na prvem mestu zaseda zelo malo prostora na strani in da ob enem ponudi največ možnih informacij. Pri tem smo si pomagali z barvami in kraticami. Slika 22 nam prikazuje primer seznama starega SharePoint koledarja in na drugi sliki je primer našega koledarja, ki se lahko uporabi na starem ali novem intranet portalu. 60

71 Slika 22: Starega seznama dogodkov in naša predstavitev koledarja na novem portalu Predstavitev z grafi kot pomoč pri pregledu pomembnih podatkov Pod nadzorna plošča (angl. dashboard) razumemo velikokrat različne stvari. Glavni namen je ta, da nam na en pogled poda vse pomembne informacije, ki jih znotraj neke logične celote ali rešitve potrebujemo. V našem primeru se nadzorne plošče nanašajo na dokumente v dokumentnih knjižnicah SharePointa ali na sezname, ki jih urejajo uporabniki. Kot recimo sezname z nalogami, kjer lahko vizualiziramo, kakšen je napredek posameznih nalog in kako dolgo je še potrebno, da bodo vse naloge opravljene oziroma koliko nalog je še potrebno zaključiti kot tudi seznam projektov, kjer lahko spremljamo, v katerih fazah se projekti nahajajo in v kakšnem statusu so. V povezavi z dokumenti, metapodatki le teh in delovnimi tokovi (angl. workflows) smo pripravili zelo privlačno rešitev za nadzorno ploščo, ki jo lahko vidimo na Slika

72 Slika 23: Primer uporabe nadzorne plošče z grafi kot pomoč pri odločitvah S pomočjo JavaScripta predstavljamo enostavno ponovno uporabnost in hitro prilagajanje za drug projekt. Hiter pregled nad tem, v kateri fazi je koliko dokumentov, je zelo velika dodana vrednost in pomeni enostavno, hitro preverjanje projektov ali katerih drugih seznamov. Nadzorna plošča vsebuje elemente, s katerimi želimo uporabnikom ponuditi tisto dodano vrednost, ki jo pričakujejo od svojih podatkov. Vsekakor zelo uporabna komponenta, vendar jo je potrebno uporabljati zmerno in na strateških mestih znotraj projekta, pri pregledu projektov ali druge vsebine iz različnih seznamov Intranet na zahtevo Pri postavitvi intraneta je eno izmed večjih vprašanj tudi to: "Kaj omogočiti uporabnikom?" Pod tem vprašanjem se skriva kompleksno poglavje, ki zajema kar nekaj podvprašanj, kot recimo, kaj bodo lahko uporabniki počeli sami, kje bodo omejitve, ali sploh bodo omejitve, kdo od uporabnikov bi lahko urejal vsebino, dostopnost intraneta na več nivojih. Dovoliti uporabniku dovolj svobode za delo, vendar kljub temu še vedno imeti dovolj kontrole kot skrbnik intraneta, da lahko določamo smernice. Ne nazadnje se to vse skupaj skriva v dobri strukturi intraneta. Sam SharePoint pri svobodi uporabnikov igra zelo pomembno vlogo, saj že v osnovni namestitvi ponuja veliko možnosti, kako prilagoditi vsebino za uporabnike, kaj jim 62

73 omogočiti in kaj ne. Seveda so nam pri postavitvi novega intraneta in sami strukturi pomagale izkušnje iz obstoječih okolij, kjer se je pokazalo, kakšne so navade uporabnikov in v katero smer razvijati intranet. Groba struktura intraneta je povezana s samo strukturo podjetja, oddelkov v podjetju, projektov v oddelku in ne nazadnje slehernega posameznika. Da bi uporabnikom omogočili čim hitrejšo uporabo SharePointa 2013 in s tem novega intraneta, smo se zatekli k rešitvi avtomatske priprave strani za oddelke in projekte na podlagi zahtev, ki so nam jih posredovali uporabniki oziroma delovne ekipe. Kreiranje projektnih strani. Osnova projektnih strani za sodelovanje ekip v intranetu so vsekakor različni manjši projekti v podjetju, ki se pojavljajo iz dneva v dan, ne trajajo pretirano dolgo in vključujejo različno število ljudi, od enega do nekaj deset, iz različnih ekip. Prav v ta namen smo za uporabnike uvedli možnost zahtevka za svojo projektno stran v SharePointu, ki mora biti odobrena z naše strani oziroma preverjena. Na Slika 24 je prikazan obrazec za novo projektno stran, ki ga uporabnik izpolni. Ko je zahtevek oddan, ga skrbniki dodatno preverijo in odobrijo. Na podlagi odobrenega zahtevka SharePoint avtomatsko poskrbi, da se zahtevana stran v roku ene ure postavi sama. To se zgodi s pomočjo periodičnega opravila (angl. timer job), v katerem je definirano, katera predloga se bo uporabila, koliko prostora bo dodeljenega in kako dolgo bo projektna stran veljavna. Avtomatsko se dodelijo tudi zahtevanje pravice. 63

74 Slika 24: Obrazec za vnos zahtevka za novo projektno stran v SharePointu Kreiranje strani za oddelke ali delovne skupine. Glavni razlog za ločevanje med projektnimi stranmi in stranmi za oddelke je bil ta, da morajo strani za oddelke biti vedno na voljo in se ne smejo več izbrisati. Služijo lahko tudi za predstavitev oddelka na intranet portalu. Te strani so vezane predvsem na logične oddelke ali skupine, ki imajo v organizacijski strukturi tudi svoje mesto. Zahtevek za takšno stran uporabniki pošljejo neposredno skrbnikom intraneta preko orodja za zbiranje zahtevkov IT. Ob danem zahtevku moramo preveriti, ali podobna stran še ne obstaja oziroma ali lahko uporabnikov zahtevek umestimo v že obstoječo strukturo strani. Zahtevno stran ustvarimo s pomočjo lastne skripte, prikazane v Tabela 6, kjer natančno definiramo vse parametre. Ko je stran pripravljena in so dodeljene vse pravice, kontaktiramo uporabnike in se z njimi dogovorimo za individualna usposabljanja, če so leti potrebni. 64

75 Tabela 6: Skripta, ki avtomatsko pripravi SharePoint stran za oddelek $sourcexml=get-content $args[0] [xml]$xmlvar = $sourcexml $contentdbserver=$xmlvar.sitecollections.sitecoll.contentdbserver $contentdb=$xmlvar.sitecollections.sitecoll.contentdb $url=$xmlvar.sitecollections.sitecoll.urlprefix+$xmlvar.sitecollections.sitecoll.url_name $createdbscriptpath = " CreateDB.ps1" $createsitecollectionscriptpath="createsitecollections.ps1" $activatesitecollectionfeaturesscriptpath="activate-deactivate_site_collection_features.ps1" $activatesitefeaturesscriptpath="activate-deactivate_site_features.ps1" $uploadmasterpagescriptpath=" UploadMasterPages.ps1" #Create the database Invoke-Command -ComputerName $contentdbserver -FilePath $createdbscriptpath -Args $contentdbserver,$contentdb #Create site collection & $createsitecollectionscriptpath $sourcexml #Activate site collection features & $activatesitecollectionfeaturesscriptpath $sourcexml #Activate site features & $activatesitefeaturesscriptpath $sourcexml #Upload master page & $uploadmasterpagescriptpath $url Write-Host "Process complete. Press any key to continue..." $x = $host.ui.rawui.readkey("noecho,includekeydown"). 65

76 6 ZAKLJUČEK V podjetju, ki je predhodno imelo veliko intranetnih portalov, smo začeli projekt za združitev le-teh pod eno platformo SharePoint V prihodnje nam ostaja še vedno nekaj intranetov, ki jih moramo integrirati v globalni intranet, vsa dosedanja spoznanja in izkušnje nam bodo pri tem v veliko pomoč. Sam proces bo potekal podobno kot pri dosedanjih migracijah, vendar se tudi sproti prilagajamo glede na okolje in glede na standarde, ki so v tistem trenutku priporočljivi. Prav tako seveda moramo upoštevati želje uporabnikov in skrbeti, da so pri tem oni na prvem mestu, kar se tiče uporabniške izkušnje ob sami migraciji in seveda posledično boljša uporabniška izkušnja na novi platformi. V diplomskem delu smo postavili nekaj vprašanj in trditev, na katere smo skozi primere podali odgovore. Če povzamemo, v veliko primerih nam uspe prenesti na nov sistem celotno vsebino starega sistema. Vsekakor govorimo tu samo o vsebini in ne o predstavitvi vsebine. Uporabniškega vmesnika v nove rešitve ne prenašamo, saj nam nove platforme ponujajo veliko lepše in boljše rešitve že same po sebi. V kolikor izrecno potrebujemo prilagoditev prenesene vsebine, moramo na novem sistemu pripraviti vse znova. Delo migracije je veliko lažje z v ta namen pripravljenimi orodji. V kolikor se soočamo z manjšo količino podatkov za to seveda ne potrebujemo nakupa posebnega orodja, ampak se dela lotimo ročno in z nekaj koraki pridemo do enake rešitve. Ugotovili smo tudi, da se je v primeru združevanja več podjetij v dokaj kratkem časovnem obdobju nemogoče znebiti vseh intranetov v trenutku, ampak jih vedno nekaj obstaja istočasno. Pravilna tehnika reševanja takšnega problema je ta, ki smo jo izpostavili, in sicer predstaviti eno vstopno točko za vse zaposlene. Od tod se potem v največ dveh korakih usmerjajo naprej do cilja oziroma svoje vsebine neodvisno od intraneta in lokacije rešitve. Tako je lažje nekomu opisati, kje se rešitev nahaja tudi, če se med navigacijo izgubimo, dokaj hitro spet najdemo pot do želene vsebine oziroma cilja. Pri integraciji intranetov oziroma portalov znotraj podjetja je pomembna komunikacija z lastniki vsebin. Da bo prehod na nov sistem kar se da enostaven in ne obremenjujoč za uporabnika, mora poskrbeti tisti, ki bo vsebino prenašal. Natančno mora biti določena lokacija trenutne vsebine in lokacija migrirane vsebine, katera vsebina se bo prenesla, kdo bo imel dostop, kakšne prednosti oziroma slabosti ima nov sistem. Uporabniki morajo 66

77 poznati vzorce novega sistema in po možnosti imeti že nekaj izkušenj s testiranjem, preden preidejo na delo z lastnimi dokumenti v tem okolju. Uporabnikov ne smemo pustiti prepuščene samim sebi, moramo jih voditi in jim dati vedeti, da je v podjetju skupina, ki jim lahko priskoči kadarkoli na pomoč. Prisluhniti in svetovati moramo tudi, ko imajo lastne ideje za izboljšanje svojega dela. V tem primeru moramo mi poznati sistem do potankosti, da lahko svetujemo na pravi način oziroma se lotimo dela na primerni rešitvi. Zanimalo nas je, katere aktivnosti so najpomembnejše pri vpeljevanju novega intraneta in katere aktivnosti so pomembne tudi, ko je intranet že v uporabi, da uporabnike vedno znova privabimo na intranet. Na tej točki nam vsekakor manjkajo nadaljnje analize, ki jih moramo še izpeljati. Preveriti je potrebno vzorce dela uporabnikov in kakšen je njihov poslovni model. Delo vsake skupine nam ni znano vnaprej. Da uporabnika pritegnemo na intranet, je to znanje ključnega pomena. Prihodnje analize vključujejo potrebo po uporabi mobilnih naprav, intranetov v oblaku za lažji dostop zaposlenih. Zajeti moramo tudi preverjanje, v kolikšni meri lahko uporabniku olajšamo in pohitrimo dnevne naloge z že vgrajenimi funkcionalnostmi ali je za izboljšanje dela potrebna implementacija dodatnih rešitev. Kot že navedeno, smo trenutno na sredi poti pri samem postopku integracije obstoječih intranetov, najtežji del integracije obsežnejših intranetov šele prihaja. Vendar na drugi strani zremo v prihodnost, kako uporabnikom ponuditi nove rešitve za tiste, ki so pripravljeni poizkusiti nekaj novega in bi jim pri njihovem delu koristilo in izboljšalo produktivnost. Pri novih rešitvah imamo v mislih SharePoint v oblaku, kjer skrbnikom ni potrebno več skrbeti za najnovejše namestitvene pakete, ampak se to zgodi neposredno s strani ponudnika storitve. Ta pristop pa je vsekakor nekaj, kar bi nam zelo pomagalo v prihodnje, kajti ko bi nekoč integrirali vse v en sistem, morda v SharePoint v oblaku, nam več ne bi bilo potrebno skrbeti, da bi se pojavila težava z zastarelim sistemom in bi ponovno morali izvajati migracijo, ampak se sistem v oblaku sproti posodablja in je vedno dosegljiv v najnovejši različici. V vsakem primeru pa nas čaka delo na oblikovanju izgleda portalov, kot ga sistemi v osnovi ponujajo in lepših, uporabnejših ter enostavnejših rešitev za uporabnika. Morda bo sama uporaba portalov naslednje generacije že v osnovi veliko lažja tudi za uporabnika. Ne nazadnje izkušnje nam kažejo, da intranet kot tak še kmalu ne bo izgubil svoje vloge, kajti tako kot smo zapisali na začetku, je intranet dostopen samo znotraj omrežja podjetja in s tem nedostopen za zunanje vsiljivce, kar posledično naredi sistem veliko varnejši. V 67

78 prihodnje se bomo ukvarjali tudi s tem, kako smiselno je razdeliti vsebino na tisto v oblaku in tisto vsebino, ki je ključnega pomena za podjetje in mora ostati v intranetu. Ob vsem tem pa moramo uporabniku še vedno pustiti dovolj svobode, da bo lahko sam določal način svojega vsakodnevnega dela in uporabljal orodja, s katerimi je najbolj produktiven na katerikoli napravi. Svet se hitro spreminja, področje računalništva je še posebej izpostavljeno spremembam. Z veseljem pričakujemo, kar nam prinašajo nove tehnologije na področju intraneta in izzive pri delu s sodelavci na različnih področjih v podjetju. 68

79 7 LITERATURA IN VIRI [1] Adenin Technologies, IntelliEnterprise, 2016, Dostopno na: [ ]. [2] Adenin Technologies, Modeler, Dostopno na: [ ]. [3] Amy Schade, Kara Pernice and Patty Caya, 10 best Intranets of 2016, Januar Dostopno na: [ ]. [4] Balzamiq Studios, Balzamiq, Dostopno na: [ ]. [5] Benjamin Niaulin, Sharegate Migration Checklist Dostopno na: Free ShareGate ebooks, The Ultimate SharePoint Migration Checklist, [ ]. [6] Christian Buckley, Metalogix, Beyond Migration: How To Transform Your SharePoint Environment, September Dostopno na: SharePoint-Migration-White-Papers.aspx, Resources, Beyond Migration: How to Transform Your SharePoint Environment [ ]. [7] Christian Buckley, Metalogix, The deffinitive guide to better SharePoint migration planning, September Dostopno na: SharePoint-Migration-White-Papers.aspx, Resources, The Defenitive guide to better SharePoint Migration Planning [ ]. [8] ECM Corporation, ECM Documentum Content Server, Dostopno na: s.pdf [ ]. [9] Igloo software, Igloo, Dostopno na: [ ] [10] Intranet Connections, IntranetConnections, Connect, Collaborate, Create, Dostopno na: [ ]. [11] Loren Johnson, Jean-Marc Krikorian, Mark Miller, ImproveIT! A collection of essays on using analytics to accomplish more with SharePoint, (ur.) Richard Harbridge, Real World Activities: How Organizations Drive Adoptation, ImproveIT, April 2015, str Dostopno na [ ]. [12] Microsoft, SharePoint Overview, Dostopno na: [ ]. 69

80 [13] Nicki DuBose,Web Publisher Technical Arhitecture: A Primer, November, Dostopno na: [ ]. [14] NSFTools, Julijan Robichaux, What is Lotus Notes?, [ ]. [15] Open Text Corporation, Opentext Content Suite Platform, 2016 Dostopno na: - [ ]. [16] Open Text Corporation, Open text Livelink Demonstrates First Intranet Application Suite for Network computers, Julij Dostopno na: [ ]. [17] Open Text Corporataion, Top 10 best practices in content migration, Maj Dostopno na: st_practices_report.pdf [ ]. [18] Ryan Hall, The history and evolution of intranet software, September 2013, [ ]. [19] Tom Jenkins, Enterprise Content Management (ECM), Kanada: Open Text Corporation, Januar 2005, str [20] Tom Jenkins, Managing Content in the Cloud, Enterprise Content Management 2.0, Kanada: Open Text Corporation, Maj 2010, str [21] Quest Software (Dell), Migrator for Notes to SharePoint Release Notes, Marec Dostopno na: [ ]. [22] Wikipedija, Spletišče, 12. junij Dostopno na: [ ]. [23] Wikipedija, Intranet, 5. december Dostopno na: [ ]. 70

81 8 PRILOGE 8.1 Priloga A Primeri posnetkov oziroma prototipov intranetnih strani

82

83 8.2 Priloga B Activity Aktivnosti ob vzpostavitvi novega intraneta [11] Pre- Launch Launch Post- Launch Ongoing Level of Effort Identify Key Stakeholders X Low Leadership Engage Executive Sponsors X Low Leadership Determine Actionable Medium to Goals & Map to X High Solutions in Office 365 Leadership Define Your Metrics for Medium to X Success High Leadership Create Your Communication Plan X Low Leadership Train Your Helpdesk X Low to High Leadership Leverage Champions X X Low Awareness Create Countdown Campaigns X Low Awareness Broadcast Portal Announcements X X Low Awareness Post Internal Advertisement X Low Awareness Show Teaser Video X Low to Medium Awareness Stage an Awareness Event X Low Awareness Send Announcement s X Low Awareness Host a Launch Event X Low to High Awareness Conduct a Baseline Survey & Follow-Up X Medium Awareness Send Weekly or Biweekly Tips & Tricks s X X Low Awareness Include an FAQ Listing & FAQ Finder Schedule Buzz Days (Continual Awareness Events) Conduct User Experience Survey Showcase Spotlight Days Report on Success Metrics Create a Feedback & Improvement Yammer Group Type X X Medium Awareness X X Low to Medium Awareness X X Low Awareness X X Low to Medium Awareness X X Low to Medium Awareness X X Low Awareness

84 Incorporate Daily Performance Metrics X X Low Awareness into Your Portal Incorporate Engaging Content into Your Portal X X Low Awareness Create Mock Profiles X X Low Awareness Create real Organizational Profiles X X X Low Awareness Incorporate Profile Links in Employee Signature X X Low Awareness Hold Contests & Competitions X X X Low Awareness Run "For Charity" reward Campaigns X X X X Low Awareness Define Portal & Site Identities X X Low Awareness Incorporate feedback in Portal X X X X Low Awareness Create Baited Hooks X X Low Awareness Remove Alternatives & Make it Mandatory X X X Low Awareness Create Pilot & early Adopter Yammer X Low Education Group Create Training Site X Low Education Connect, Teach & Empower Champions X X X Low to High Education Hold In-Person Training Events X X X Low to High Education Conduct Baseline Survey on Office 365 (SharePoint) X Low Education Understanding Announce & Explain New Features & X Low to Medium Education Capabilities Conduct Champion Experience Survey X Low Education Communicate Policies & Guidelines X X X Low to High Education Share Summaries of Top Searches & Correct Failed/Abandoned X X Low to Medium Education searches Review Usage Reports & Relevant Audited X X Low to Medium Education Activity Incorporate Portal into New-Hire Orientation X X Low to Medium Education

85 Incorporate Portal into Annual Training or Skills Validation Collect, Share & Support Success Stories Hold YamJams, Use #YamWin & Create Starter Yammer Groups Provide Best-in-Class & Solution Showcases Provide Community Showcases Provide Guidance on What Tools to Use for What Purpose X X Low to Medium Education X X Low to High Education X X X X Low to Medium Education X X X Medium to High Education X X Low Education X X X Seed Content X X X Provide Internal Classified/Marketplace Provide Specialized Search Provide Usability Testing, diary Studies, card Sorting Exercise & More Develop Communities & User Groups Provide Internal Content services Support Provide Business Intelligence (BI) Services and a BI Community Medium to High Medium to High Education Education X X X Low to High Education X X X X Low to High Education X X X X Low to High Education X X X X Low to Medium Education X X X X Medium to High Education X X X X Low to High Education

86 8.3 Priloga C Odgovori na anketo o uporabi internetov v podjetju in SharePointa na splošno

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101