Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje

Transkripcija

1 Organizacija in management delovnih sistemov VPELJAVA SISTEMA G.O.L.D. V VELIKO TRGOVSKO PODJETJE Mentor: red. prof. dr. Robert Leskovar Kandidat: Peter Maldwyn Smolej Kranj, junij 2015

2 ZAHVALA Zahvaljujem se mentorju dr. Robertu Leskovarju za usmerjanje, navodila in strokovno pomoč pri izdelavi diplomske naloge. Hvala g. Janku Purgaju in g. Sebastjanu Medvedu iz podjetja Symphony EYC d.o.o. za pomoč pri dodatnih obrazložitvah dogodkov, ki jih ni bilo mogoče razbrati iz projektne dokumentacije. Zahvaljujem se tudi lektorici Kaji Božiček, ki je lektorirala mojo diplomsko nalogo. Posebna zahvala gre Sanji Šušterič za spodbujanje tekom nastanka diplomske naloge.

3 POVZETEK Naloga obravnava vpeljavo konkretnega informacijskega sistema v veliko trgovsko podjetje. Uporabljeni informacijski sistem G.O.L.D. Central je v splošnem namenjen upravljanju oskrbovalnih verig, je modularno zgrajen, prilagojen posebej za poslovanje trgovskih podjetij in deluje samostojno, ali pa v povezavi z drugimi informacijskimi sistemi. V nalogi je predstavljen poslovni kontekst konkretne uvedbe, ki je zaradi zahtev naročnika kompleksna. Kratko so predstavljene uveljavljene metodologije uvajanja informacijskih sistemov primerljivih ponudnikov informacijskih rešitev. Naloga podrobno predstavi projekt vpeljave od priprave, analize, izdelave projektnega načrta do končne realizacije in analizira odstopanja od prvotnega projektnega načrta. Ugotovili smo, da je do pomembnih odstopanj prišlo zaradi: razkoraka med razumevanjem procesov s strani naročnikovih arhitektov poslovnih procesov in ključnimi uporabniki, neuspešne vzpostavitve kompetenčnega centra, ki naj bi izvajal postopen prehod blagovnih znamk in zagotavljal podporo informacijskemu sistemu. Podali smo predloge za izboljšave vpeljave informacijskega sistema G.O.L.D. Central: večja vključitev ključnih uporabnikov tekom inženiringa zahtev, vzpostavitev kompetenčnih centrov s pomočjo naročnikovih internih človeških virov. Informacijski sistem je z zakasnitvijo vpeljan v naročnikovo poslovno okolje in je že v stanju polnega delovanja. KLJUČNE BESEDE: - informacijski sistem, - vpeljava, - metodologija vpeljave, - G.O.L.D. Central, - trgovina na drobno.

4 ABSTRACT The thesis deals with software implementation of a specific information system in a large retail company. G.O.L.D. Central information system is intended for supply chain management, is modular, tailored specifically for retail and can operate independently or in conjunction with other information systems. The thesis presents a business context of a specific software implementation which is complex due to requirements of the customer. Established software implementation methodologies of comparable software vendors are briefly presented. The thesis presents in detail project implementation from preparation, analysis and initial version of project plan till project completion. It analyses deviations from the initial project plan. We found that there was signification deviation from initial project plan due to: difference in understanding business processes between customer s business process architects and key users, unsuccessful attempt at establishing a competence center which was supposed to handle phased migration of brands and post go-live support. Following suggestions for improving future G.O.L.D. Central implementations were made: greater involvement of key users during requirements engineering, building competence centers with client's internal human resources. Information system was implemented into clients business with a significant delay and is now in production. KEYWORDS: - information system, - implementation, - software implementation methodology, - G.O.L.D. Central, - retail.

5 KAZALO 1. Uvod Metodologija Predstavitev poslovnega okolja Ponudnik Symphony EYC... 4 Naročnik večje trgovsko podjetje... 4 G.O.L.D. Central/Shop Projekt vpeljave informacijskega sistema G.O.L.D. Central/Shop Pregled uveljavljenih metodologij vpeljave Metodologija SEYC ASAP Sure step AIM Primerjava faz metodologij Predprodajni pogovori z naročnikom Faza priprave Analiza Začetni projektni načrt Zasnova sistema Realizacija Testiranje in šolanje Zagon Realizacija projekta Zasnova sistema Realizacija Testiranje in šolanje Zagon Analiza odstopanj Vrzeli Vmesniki Podpora po zagonu Predlog izboljšav metodologije vpeljave Zaključek Literatura in viri... 48

6 1. UVOD Informacijski sistemi so zelo pomemben element upravljanja oskrbovalnih verig. Vsakemu členu v oskrbovalni verigi mora informacijski sistem omogočiti ažuren vpogled v stanje, komunikacijo s poslovnimi partnerji v oskrbovalni verigi (bodisi preko izmenjave sporočil ali pa preko spletnih vpogledov) ter analitiko oziroma poslovno obveščanje. Na prvi pogled enostaven nabor osnovnih funkcionalnosti, ki pa so kompleksne po naravi. Večja kompleksnost tematike pa povečuje možnost neuspeha pri vpeljavi informacijskega sistema. Uspešna vpeljava informacijskega sistema ni tako gotova, kot se mnogokrat zdi. Neuspeh je tako pogost, da kar 43% IT managerjev pravi, da njihovi direktorji in nadzorni sveti sprejemajo težave v IT projektih kot nekaj popolnoma normalnega (IT Projects, 2007). Kot je navedeno v (CHAOS Manifesto, 2013) je bilo v letu 2012 uspešnih (v okviru časovnega načrta, proračuna, z vsem zahtevanimi funkcionalnostmi) samo 39% IT projektov. Preostalih 61% projektov se porazdeli na 18% propadlih projektov (projekt je bil preklican pred zaključkom, programska oprema je bila vpeljana toda nikoli uporabljena) in 43% projektov zaključenih s težavami (zamude, prekoračen proračun, zmanjšanje funkcionalnosti glede na načrt). V nalogi bomo obravnavali konkreten primer vpeljave informacijskega sistema G.O.L.D. Central v veliko trgovsko podjetje, ki deluje na večih trgih. Analizo bomo izvedli na stanju projekta sredi leta Ker naročnik že ima določene rešitve, pomeni to še poseben izziv za vpeljavo novega informacijskega sistema. Naročniku je potrebno dokazati, da je nov sistem enostaven za učenje in uporabo, vpeljava pa takšna, da v nobenem trenutku ni moteno rutinsko poslovanje. Naročnik in implementator bosta dosegla cilj, ko bo nov informacijski sistem v celoti vpeljan, uporabniki usposobljeni za uporabo naročnik pa bo podpisal njegov prevzem. Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 1

7 2. METODOLOGIJA Opredelitev problema Veliko trgovsko podjetje se je zaradi nefleksibilnosti starega informacijskega sistema, neenotnega informacijskega sistema v različnih državah, nezmožnosti avtomatskega obnavljanja zalog na prodajnih mestih, ter šibkega nadzora stroškov zalog odločilo za vpeljavo novega celovitega informacijskega sistema. Naročnik; veliko trgovsko podjetje, ki deluje na več trgih, je v preteklosti že poskusilo uvesti dva druga celovita informacijska sistema. Zato so bili pri vpeljavi v tretjem poskusu še posebej zahtevni do ponudnika, saj bi neuspeh vpeljave slabo vplival na poslovne rezultate tako naročnika, kot tudi ponudnika informacijskega sistema. Problem, obravnavan v nalogi, je časovno trajanje vpeljave sistema G.O.L.D. Central/Shop, ki je bilo daljše od prvotno načrtovanega. Prav tako je bila večja poraba finančnih sredstev, kar je povzročilo manjše zadovoljstvo naročnika, kot bi bilo ob časovno in stroškovni začetno predvideni izvedbi vpeljave. Opredelitev namena in ciljev naloge Namen diplomske naloge je dokumentirati faze procesa vpeljave celovitega informacijskega sistema G.O.L.D. Central v konkretno veliko podjetje. Za vsako posamezno fazo bo dokumentirana, načrtovana in dejansko izvedena realizacija. Proces vpeljave je že zaključen, vendar pa primopredajni zapisnik še ni podpisan, zato bodo rezultati dokumentiranja koristi tako za prihodnje implementacije, kot tudi za morebitne dodatne ukrepe za doseg formalnega zaključka projekta. Cilji diplomske naloge so: kratko predstaviti naročnika in ponudnika informacijskega sistema, kratko predstaviti značilnosti informacijskega sistema G.O.L.D. Central, proučiti metodologijo vpeljave, ki jo uporablja ponudnik programske opreme in metodologije drugih primerljivih ponudnikov, prikazati dinamiko vpeljave informacijskega sistema v konkretno podjetje ter izzive, ki so se pojavili v posameznih fazah, analizirati odstopanja med načrtovanimi in realiziranimi rezultati faz vpeljave. Dodatni cilj je na podlagi preučenih metodologij in analize odstopanj podati predloge izboljšav SEYC metodologije vpeljave v točkah, ki so bile tekom analize odkrite kot vzrok za zamudo pri vpeljavi informacijskega sistema v konkretno podjetje, ter morebitne druge predloge izboljšav postopka vpeljave na podlagi dokumentiranega procesa vpeljave. Uporabljene metode, tehnike in orodja V nalogi bodo uporabljene: študij literature, inženiring programske opreme, metodologija uvajanja SEYC, projektni management, Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 2

8 post-projektna analiza in programska rešitev G.O.L.D. Central/Shop. Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 3

9 3. PREDSTAVITEV POSLOVNEGA OKOLJA 3.1. PONUDNIK SYMPHONY EYC Symphony EYC je mednarodno podjetje s sedežem v Silicijevi dolini, ki izdeluje in implementira sisteme za optimizacijo maloprodaje in za nadzor oskrbovalne verige ter nudi storitve analize trga in obnašanja potrošnikov. Podjetje je nastalo leta 2012 z združitvijo podjetji Aldata; ki je nudilo produkte za optimizacijo maloprodaje in distribucije, ter EYC; ki je nudilo analize podatkov za povezovanje s strankami in optimizacijo asortimanov. Združeno podjetje ima več kot šeststo zaposlenih in zagotavlja svoje storitve v Severni in Južni Ameriki, Evropi in Aziji. Ima petindvajset let izkušenj na področju logistike in maloprodaje. Podružnica imajo tudi v Sloveniji, kjer z okoli tridesetimi zaposlenimi pokrivajo trg Jugovzhodne Evrope in Bližnjega vzhoda. Glavne stranke podjetja so predvsem večji trgovci na drobno, ter proizvajalci. Več kot 1000 strank prihaja iz 70 držav po svetu, kar daje podjetju širok pogled na različne načine poslovanja, ter pravne ureditve držav (Naše podjetje, 2014). Na področju sistemov za optimizacijo maloprodaje, oziroma sistemov za nadzor oskrbovalne verige nudi tako programsko opremo, kot tudi storitve svetovanja in implementacije le-te s pomočjo svojih zaposlenih svetovalcev. Svetovalci so ponavadi specializirani za funkcionalno področje ali pa za tehnično področje sistema in v paru sodelujejo s strankami tekom implementacije sistemov NAROČNIK VEČJE TRGOVSKO PODJETJE Naročnik sistema G.O.L.D. Central/Shop je večje trgovsko podjetje, ki deluje na področju Bližnjega Vzhoda, Severne Afrike, Turčije, Rusije in Evrope. Podjetje deluje kot zastopnik več kot sedemdeset blagovnih znamk s področja oblačil, kozmetike, drogerij, optike, notranje opreme, maloprodaje živil, ter verig s področja prehrane. Zaposluje preko ljudi in kot franšizno podjetje operira z več kot 2800 poslovalnicami za blagovne znamke kot so H&M, Mothercare, Starbucks, Victoria's secret, Topshop, Boots in Make-up Art Cosmetics (MAC). Ker deluje na različnih segmentih od maloprodaje do franšiznih restavracij je v podjetju aktivnih več poslovnih modelov; imajo tako lastne blagovne znamke, kot franšizne prodajalne. Prav tako je prisotnih več logističnih modelov oskrbovanja (regionalni centri, distribucijski centri, zunanji dobavitelji, 3PL logistika). Nabor držav v katerih operirajo poslovalnice pomeni delovanje v različnih časovnih pasovih in pod različnimi zakonodajami. Pred vpeljavo novega sistema se je podjetje srečevalo z uporabo in vzdrževanjem različnih regionalnih informacijskih sistemov za sledenje premikom in stanja zalog.. Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 4

10 3.3. G.O.L.D. CENTRAL/SHOP G.O.L.D. Central/Shop je informacijski sistem za upravljanje oskrbovalnih verig, ki je namenjen in prilagojen trgovskim podjetjem. Sestavlja del modularnih informacijskih rešitev G.O.L.D. in lahko nastopa samostojno ali v povezavi z ostalimi informacijskimi sistemi (Slika 1). Slika 1: Informacijske rešitve G.O.L.D. (G.O.L.D. Handbook, 2007) G.O.L.D. Central je namenjen centralni nabavni pisarni kot informacijski sistem, ki omogoča upravljanje oskrbovalne verige za nabavo in distribucijo blaga prodajnim mestom (G.O.L.D. Handbook, 2007). Med drugim omogoča: upravljanje z matičnimi podatki (parametrizacija, dobavitelji, logistične in komercialne mreže, artikli, nabavni pogoji), optimizacijo oskrbovalnih verig, upravljanje z rabati, upravljanje z asortimani (prodajni, oskrbovalni) in prodajnimi cenami, upravljanje z logističnimi tokovi, izvajanje dodatnega nadzora nad poslovanjem (kontrola prejetih faktur, upravljanje s proračuni dobaviteljev), sledenje zalogam blaga (tako količinsko kot vrednostno), zbiranje naročil s prodajnih mest, generiranje naročil centralnim skladiščem na podlagi zbranih naročil s prodajnih mest, generiranje naročil zunanjim dobaviteljem za potrebe prodajnih mest in logističnih centrov. Ob vpeljavi informacijskega sistema G.O.L.D. Central se izvaja tudi vpeljava rešitve G.O.L.D. Shop, ki je neločljivo povezana s sistemom G.O.L.D. Central Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 5

11 (Slika 2) in je namenjena podpori poslovnim procesom na prodajnem mestu (G.O.L.D. Handbook, 2007): upravljanju z lokalnimi dobavitelji, nadzoru nad cenami na prodajnem mestu, avtomatskemu generiranju naročil blaga, prevzemu blaga, prenosu blaga na drugo prodajno mesto, vračilu blaga dobaviteljem, razpisu inventure, spremembi ali odpisu zalog. Slika 2: Povezave Central in Shop (G.O.L.D. Handbook, 2007) Informacijski sistem je sestavljen iz tri nivojske arhitekture odjemalec/strežnik (Slika 3) (G.O.L.D. Overview, 2009): podatkovna plast, aplikacijska plast, predstavitvena plast. Podatkovna plast Podatkovno plast prestavlja podatkovna baza, ki teče na podatkovnem strežniku Oracle. Osnovo G.O.L.D. Central/Shop rešitve predstavlja centralizirana podatkovna baza, ki lahko teče centralizirano ali pa je razpršena na več podatkovnih strežnikov Oracle. Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 6

12 Aplikacijska plast Aplikacijska plast služi kot posrednik med odjemalcem (predstavitvena plast) in podatkovno zbirko (podatkovna plast). Aplikacijski strežnik predstavlja lastna rešitev GAIA vmesno programje. Aplikacijski strežnik zbira zahteve za podatke, ki jih odda odjemalec, dostopa do podatkovne zbirke, pretvori podatke iz podatkovne baze v primeren format in jih posreduje nazaj odjemalcu. Prav tako skrbi za izvedbo programov, ki jih zahteva uporabnik preko odjemalca. Večnivojska arhitektura omogoča, da je lahko aktivnih več aplikacijskih strežnikov, ki delujejo samostojno. Delujejo lahko kot posrednik med klasičnim uporabniškim odjemalcem JAVA, ali pa kot posrednik za odjemalce ki tečejo na mobilnih napravah. Predstavitvena plast Predstavitvena plast (oziroma uporabniški odjemalec) je namenjena končnim uporabnikom informacijske rešitve. Uporabniški odjemalec verzije temelji na JAVA tehnologiji, ki omogoča uporabo na vseh napravah, ki podpirajo JAVA aplete. Uporabniki preko odjemalca dostopajo do podatkov in izvajajo operacije v sistemu. Slika 3: Trinivojska arhitektura (G.O.L.D. Overview, 2009) Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 7

13 4. PROJEKT VPELJAVE INFORMACIJSKEGA SISTEMA G.O.L.D. CENTRAL/SHOP 4.1. PREGLED UVELJAVLJENIH METODOLOGIJ VPELJAVE Metodologija vpeljave informacijskega sistema je skupek smernic, pravil in pogledov ki razlagajo, kako se implementator informacijskega sistema loti vpeljave kompleksnega informacijskega sistema v procese naročnikove organizacije (Product Software Implementation Method, 2014). Metodologija posameznega podjetja predstavlja skupek dobrih praks, ki jih je podjetje identificiralo skozi pretekle implementacije ali skozi implementacije, ki so jih izvedli drugi. Zaradi tega se lahko metodologije različnih implementatorjev istega informacijskega sistema razlikujejo, oziroma so si metodologije različnih implementatorjev različnih informacijskih sistemov lahko podobne. V poglavju bo predstavljena splošna metodologija implementacije SEYC, ki služi kot vodilo pri vpeljavi informacijskega sistema G.O.L.D. Central/Shop. Metodologija ni toga, zaradi česar ni nujno, da se bo dejanski način vpeljave pri naročniku popolnoma ujemal s predstavljeno metodologijo. Prav tako bodo na kratko predstavljene metodologije primerljivih ponudnikov večjih informacijskih sistemov METODOLOGIJA SEYC Pri implementaciji informacijskih sistemov G.O.L.D. se uporablja splošno metodologijo SEYC, ki je sestavljena iz pristopa v šestih fazah (Slika 4): 1. Priprava 2. Analiza 3. Zasnova sistema 4. Realizacija 5. Testiranje in šolanje 6. Zagon Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 8

14 Slika 4: Splošna metodologija SEYC (Aldata Implementation Methodology, 2009) Priprava Faza priprave vključuje aktivnosti, ki so potrebne za večjo organiziranost med projektom uvajanja informacijskega sistema G.O.L.D. in vključuje (PSO Delivery Methodology, 2015): določitev projektne strukture, identifikacijo ključnih deležnikov, pripravo projektnega načrta, rezervacijo ljudi za delo na projektu, pripravo načrta komunikacije z naročnikom, določitev predvidenih funkcionalnosti, groba časovna ocena trajanja implementacije, določitev upravljalskega odbora, izdelavo strategije za prehod v živo. Rezultat faze priprave so sledeči dokumenti: projektna listina, projektni načrt, finančni načrt, strategija prehoda v živo, komunikacijski načrt. Analiza Ta faza postavi osnovo za izvedbo projekta. Zajame sliko stanja procesov in potrebe naročnika. Aktivnosti, ki se izvedejo v tej fazi so (PSO Delivery Methodology, 2015): Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 9

15 izdelava modela poslovnih procesov, zajem pravil poslovanja, načrt procesov v G.O.L.D., konferenčni pilot / predstavitvena delavnica, identifikacija vrzeli v delovanju standardne aplikacije, identifikacija potrebnih vmesnikov, izdelava načrta šolanja, določitev pravil za uvajanje sprememb. Rezultati faze analize so: pravilnik potrjevanja sprememb in dodelav, načrt šolanja, poslovni model. Zasnova sistema Faza zasnove sistema natančno formalizira funkcionalnosti, ki jih bo sistem pokrival, določi obseg dodatnega razvoja funkcionalnosti in način integracije dodatnega razvoja. Aktivnosti obsegajo (PSO Delivery Methodology, 2015): določitev konfiguracije G.O.L.D., tehnično zasnovo: o podroben načrt uvoza starih podatkov, o definicije vmesnikov z drugimi sistemi, o načrt zagona avtomatiziranih programov, o podrobno analizo vrzeli v sistemu; načrt priprave matičnih podatkov, strategijo uporabniških profilov, načrt razvoja in testiranja programov oziroma funkcionalnosti razvitih za naročnika, načrt testiranja procesov. Rezultat faze zasnove so: natančen poslovni model, funkcionalne specifikacije, tehnične specifikacije, načrt testiranja, dokument integracije informacijskega sistema. Realizacija V fazi realizacije se izvedejo predhodno načrtovane aktivnosti iz faze zasnove. Prične se razvoj dodatnih funkcionalnosti, prilagoditev obstoječih funkcionalnosti in razvoj dodatnih vmesnikov. Izvede se namestitev testnega okolja in konfiguracija informacijskega sistema glede na predhodno izdelani poslovni model. Za potrebe testiranja se pripravi testne scenarije in testne skripte. Aktivnosti ki se izvedejo v tej fazi so (PSO Delivery Methodology, 2015): razvoj: o razvoj programov za konverzijo podatkov, o razvoj dodatnih vmesnikov, o razvoj specifičnih paketnih (t.i. batch) programov, Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 10

16 o razvoj sprememb na standardnih programih/zaslonih; priprava podatkov za uvoz v informacijski sistem, razvoj testnih skript, priprava gradiva za šolanje, priprava standardiziranih postopkov (SOP), izdelava seznama za izvedbo prehoda v živo. Rezultat faze razvoja so: vmesniki po meri naročnika, specifične funkcionalnosti/programi za naročnika, gradivo za šolanje, skripte za izvedbo testiranja, testno okolje pri naročniku. Testiranje in šolanje Ta faza vključuje zagon cikličnega testiranja procesov v aplikaciji, priprave podjetja na spremenjeno poslovanje v novem informacijskem sistemu, ter šolanje uporabnikov. Aktivnosti, ki jih vključuje so (PSO Delivery Methodology, 2015): izvedba testov programov: o migracija podatkov, o test specifičnih funkcionalnosti, o test funkcionalnosti (test delovanja, test sprejemljivosti UAT), o test vmesnikov (test delovanja posameznega vmesnika, ter integracije vmesnikov); stresni testi (obremenitveni testi, performančni testi), nastavitve za izboljšanje zmogljivosti, tehnični pregled sistema, testiranje procesov s strani ključnih in končnih uporabnikov, priprava produkcijskega okolja, analiza pripravljenosti podjetja za prehod (vključuje odločitev za prehod na nov informacijski sistem). Rezultati testiranja in šolanja so: potrditev skladnosti s pričakovanji, odločitev za prehod v živo, standardni obratovalni postopki (SOP). Zagon Faza zagona pomeni prehod podjetja na poslovanje v informacijskem sistemu G.O.L.D.. Aktivnosti, ki jih vključuje so (PSO Delivery Methodology, 2015): migracija podatkov, izvedba pilota, zagon v živo, podpora po zagonu v živo, prehod na standardni kanal podpore, analiza prehoda v živo. Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 11

17 Uvedba informacijskega sistema G.O.L.D. Central/Shop je odvisna od strategije implementacije. Zagon je lahko izveden na različne načine: postopen prehod po skupinah poslovalnic (glede na format poslovalnic, območje delovanja, blagovne znamke), postopen prehod po trgovskih segmentih poslovalnic (prehod dela poslovalnic glede na tip maloprodaje; živila, gradbena oprema, pohištvo), celoten prehod vseh poslovalnic. Celoten prehod za podjetje ni priporočljiv, ker vključuje veliko tveganja pri prehodu in ne dopušča možnosti za izboljšave v postopku prehoda poslovanja (Aldata Implementation Methodology, 2009). Največkrat je uporabljen postopek postopnega prehoda po skupinah poslovalnic, saj se lahko t.i. najboljšo prakso prehoda prenese, oziroma uporabi pri prehodu sledečih skupin poslovalnic. Prehod po trgovskih segmentih se uporabi v podjetjih, ki imajo prodajna mesta iz različnih tržnih področjih (trgovine gradbenega materiala, trgovine z oblačili, trgovine z živili), saj ima vsak tip trgovskega segmenta svoje posebnosti v poslovanju. Ob zaključku faze zagona se podpiše primopredajni podpisnik sistema, naročnik sistema pa preide na standardne podporne kanale ASAP 8 Metodologijo ASAP 8 (Advanced Delivery Management Concept) uporabljajo SAP in SAP pooblaščeni partnerji pri vpeljavi informacijskega sistema SAP. Sestavljena je iz naslednjih faz (Slika 5): priprava projekta, poslovni model, realizacija, končna priprava, zagon in podpora, delovanje. Slika 5: ASAP metodologija (ASAP Implementation Roadmap, 2015) Faza 1: Priprava projekta Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 12

18 V tej fazi implementacijska ekipa izvede začetno pripravo in načrtovanje za SAP projekt. Na delavnicah se z naročnikom definira obseg, namen in cilje vpeljave informacijskega sistema SAP (5 Phases of ASAP Methodology in SAP, 2012). Rezultati te faze so: projektna listina; definira namen in cilje spremembe poslovnih procesov, projektni načrt; začetni projektni načrt, ki definira projektne mejnike in okvirni načrt dela, obseg projekta; postavi začetni okvir in definicijo projekta, pripravljen je na podlagi predprodajnih aktivnosti, organizacija projektne ekipe; kdo in zakaj bo delal na projektu. Faza 2: Poslovni model Namen faze je doseči skupno razumevanje o tem, kako namerava naročnik uporabljati SAP za podporo poslovanju. Potrebe in zahteve so analizirane za vsako SAP referenčno strukturo posebej ter definirane na podlagi CI (customer input) predloge. Iz CI predlog je narejen poslovni model, ki vsebuje natančne opise nameravanega poslovanja, ki so zajeti tekom delavnic za definiranje potreb. Dokument predstavlja dogovorjeno razumevanje predvidenega poslovanja v sistemu SAP in je osnova za tretjo fazo (5 Phases of ASAP Methodology in SAP, 2012). Faza 3: Realizacija Namen te faze je vpeljava vseh zahtev poslovnega procesa na podlagi prej pripravljenega dokumenta poslovnega modela. Metodologija konfiguracije informacijskega sistema SAP je izvedena v dveh delih: osnova (večina predvidenih funkcionalnost) in končna konfiguracija (preostali obseg funkcionalnosti) (5 Phases of ASAP Methodology in SAP, 2012). Rezultati faze so: glavni seznami definirajo poslovne scenarije in transakcije, ki jih bo vršil SAP sistem, BPP primeri poslovnih transakcij, ki so uporabljene za osnovno testiranje in dokumentacijo, načrtovanje definicija konfiguracije informacijskega sistema ter testov konfiguracije, razvojne specifikacije natančni dokumenti potrebnega dodatnega razvoja, EU (End User) gradivo - gradivo za končno šolanje uporabnikov in natančen popis procesov. Faza 4: Končna priprava Namen faze je dokončati priprave (vključuje testiranje, šolanje končnih uporabnikov, upravljanje z informacijskim sistemom, ter aktivnosti za migracijo) za zagon v živo. Prav tako se izvede šolanje končnih uporabnikov in izvede stresne ter obremenitvene teste. Faza končne priprave služi tudi kot točka, kjer se dokončno razreši vse ključne odprte točke. Ob zaključku te faze je naročnik pripravljen za zagon informacijskega sistema SAP v živo (5 Phases of ASAP Methodology in SAP, 2012). Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 13

19 Rezultat faze je načrt za migracijo v živo. Faza 5: Zagon in podpora Namen faze je migracija SAP projekta iz testnega okolja v živo produkcijsko okolje. V fazi se izvaja aktivnost nadzora nad delovanjem aplikacije in rešuje odprta vprašanja uporabnikov (ASAP Implementation Roadmap, 2015). Faza 6: Delovanje Namen te faze je zagotavljanje operativnosti informacijske rešitve. Predstavlja tranzicijo naročnika na standardne SAP podporne kanale SURE STEP Metodologijo Sure Step uporabljajo Microsoft in Dynamics partnerji pri implementaciji informacijskega sistema Microsoft Dynamics NAV (Andijeva, 2010). Sestavljena je iz šestih faz (Slika 6) (Andijeva, 2010): diagnostike, analize, snovanja, razvoja, uvajanja, operativne faza. Faza diagnostike V fazi diagnostike je potrebno zbrati dovolj informacij za grobo definicijo obsega projekta. Faza se izvaja tekom predprodajnih sestankov. V tem času se dogovori o načinu pristopa k projektu in naredi krajšo definicijo obsega (Andijeva, 2010). Rezultat faze diagnostike je krajši dokument obsega projekta. Faza analize Faza predstavlja pravi začetek implementacije informacijskega sistema. Naredi se grobo sliko poslovnih procesov, saj je cilj razumevanje naročnikovih poslovnih procesov. Na podlagi posnetka stanja se lahko predlaga učinkovitejše delovne procese (Andijeva, 2010). Končni rezultat faze analize je dokument funkcionalnih potreb, ki vsebuje: podrobno določitev obsega projekta, analizo poslovnih procesov, predloge za izboljšavo procesov, analizo vrzeli (GAP). Faza snovanja Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 14

20 Cilj faze snovanja je določitev načina implementacije naročnikovih zahtev v obstoječo aplikacijo. Faza vključuje tako načrt konfiguracije standardne aplikacije, kot tudi specifikacijo morebitnih dodelav. Vanjo je prav tako vključeno načrtovanje procesa migracije podatkov (Andijeva, 2010). Končni rezultat faze snovanja so dokumenti: dokument konfiguracije, načrt migracije podatkov, testni scenariji in načrt testiranja, tehnične specifikacije, funkcionalne specifikacije. Faza razvoja Cilj faze razvoja je razvoj vrzeli, vmesnikov in skript za migracijo podatkov. Ob dobavi razvitih dodelav se izvede testiranje in potrdi delovanje skladno s specifikacijo (Andijeva, 2010). Končni rezultat faze razvoja so: zaključen razvoj dodatnih funkcionalnosti, zaključena integracija dodatnih funkcionalnosti v okolje, zaključeno testiranje dodatnih funkcionalnosti, opravljen test migracije podatkov. Faza uvajanja Faza uvajanja pomeni zadnji korak pred zagonom sistema. V tej fazi se izvede konfiguracijo okolja pri naročniku v skladu z zajetimi zahtevami oziroma dokumentom konfiguracije. V tej fazi se prav tako izvede test sprejemljivosti (UAT), kjer naročnik potrdi ali je delovanje sistema v skladu s pričakovanji. Izvede se šolanje uporabnikov. V primeru potrditve skladnosti se izvede prehod v živo (Sure Step Training, 2015). Operativna faza Namen operativne faze je zagotavljanje podpore naročniku ob začetnem delovanju informacijskega sistema. Podporo se zagotavlja na licu mesta in pripravi naročnika na standardizirano oddaljeno podporo. Sklepno dejanje operativne faze je končna potrditev uspešnosti zaključka projekta in podpisan zapisnik prevzema informacijske rešitve (SSYH Implementation Methodology, 2015). Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 15

21 Slika 6: Sure Step metodologija (BSE Consulting, 2015) AIM AIM (Oracle Application Implementation Methodology) je metodologija, ki jo uporablja Oracle, ter certificirani partnerji pri implementaciji Oracle Financial Services (Oracle Aim Methodology, 2010). Sestavljena je iz šestih faz (Slika 7): projektni management, analiza potreb, načrtovanje rešitve, priprava rešitve, šolanje, stresni testi in UAT, prehod v živo in konec finančnega meseca. Faza 1: Projektni management Ta faza se začne ob pričetku projekta in nadaljuje tudi po zagonu v živo. Pripravi se projektni načrt in načrtovanje potrebnih človeških virov v okviru osnovnega obsega projekta. Določijo se namen in cilji projekta. Projektni načrt mora biti potrjen s strani naročnika (Phases of Oracle Implementation, 2011). Rezultata faze sta začetni ter aktualni projektni načrt. Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 16

22 Faza 2: Analiza potreb V tej fazi svetovalci organizirajo delavnice s ključnimi poslovnimi uporabniki ali arhitekti poslovnih procesov na katerih poskušajo razumeti trenutno poslovanje naročnika (Phases of Oracle Implementation, 2011). Svetovalci: dokumentirajo trenutno organizacijsko strukturo naročnika, pripravijo dokument slike trenutnih poslovnih procesov (AS-IS), dokument pričakovanih poslovnih procesov (TO-BE), zabeležijo kje so vrzeli standardnih procesov (GAP), od naročnika pridobijo podpisan dokument vseh potreb in zajetih zahtev. Analiza potreb predstavlja ključni korak po metodologiji AIM. V kolikor zanjo ni predvideno dovolj časa in niso vključeni pravi deležniki s strani naročnika, lahko pride do zamud in nezadovoljstva pri implementaciji informacijskega sistema. Prav tako je lahko zaradi napak povratek investicije manjši (Phases of Oracle Implementation, 2011). Rezultata faze sta dokument trenutne finančne in organizacijske strukture (RD10), ter dokument poslovnih potreb in zahtev (RD50). Faza 3: Načrtovanje rešitve V tej fazi se bolj natančno analizira vrzeli za zahteve, ki jih standardna rešitev ne odpira in pripravi osnutke rešitev za zahtevane in zaželjene funkcionalnosti. Po pripravi osnutka rešitve je le-ta predstavljena naročniku na delavnici. Za predstavitev osnutka procesov se uporabi diagram poteka. Korak predstavitve je obvezen, saj mora naročnik razumeti in potrditi predlog rešitve. Področja s katerimi naročnik ni zadovoljen se ponovno analizira in ponudi alternativne rešitve (Phases of Oracle Implementation, 2011). Rezultat faze so dokumenti: analiza vrzeli (BR10), zapis poslovnih potreb (BR30), funkcionalna specifikacija dodelave (MD50), tehnična specifikacija dodelave (MD70). Faza 4: Priprava rešitve V tej fazi je na strežnik nameščena informacijska rešitev in opravljena nastavitev parametrov rešitve tako, da ustrezajo načrtu rešitve. Prav tako se izvede razvoj dodelav, ki so bile definirane v prejšnji fazi. Obseg faze se razlikuje od projekta do projekta in je odvisen on količine dodelav in vmesnikov, ki so dodatno razviti. Takšni projekti imajo fazo priprave rešitve naprej razdeljeno v sklope sistemskih in integracijskih testiranj (Phases of Oracle Implementation, 2011). V tej fazi so izvedene sledeče aktivnosti: svetovalci zaključijo parametrizacijo informacijskega sistema, izvede se testiranje standardiziranih poslovnih procesov in odpravi morebitne težave, Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 17

23 tehnični svetovalci zaključijo in dostavijo prilagoditve (izdelane na podlagi dokumentov MD50 in MD70), da so na voljo za testiranje, funkcionalni svetovalci izvedejo testiranje prilagoditev in dodelav. V tej fazi nastanejo sledeči dokumenti: parametrizacija aplikacije (BR100), skripte za tehnično testiranje (TE20), skripte za testiranje sistema (TE40), načrt testiranja sistemske integracije (TE120), skripte za testiranje sistemske integracije (TE50). Faza 5: Testiranje, šolanje in UAT V tej fazi so ključni uporabniki prvič izpostavljeni aplikaciji. Funkcionalni svetovalci pripravijo gradivo za šolanje in uporabniške priročnike, da povečajo raven udobja. V kolikor je število ključnih uporabnikov veliko, se uporabi pristop šolanja učiteljev drugih ključnih uporabnikov (Phases of Oracle Implementation, 2011). Faza je ponavadi ločena na dva dela: pilot v konferenčni sobi: svetovalci gredo skupaj s ključnimi uporabniki skozi aplikacijo in zabeležijo pripombe, test sprejemljivosti: ključni in končni uporabniki izvedejo testiranje aplikacije in potrdijo delovanje v skladu s pričakovanji. Ključna dokumenta, ki nastaneta v tej fazi sta uporabniški priročnik, ter poročilo testa sprejemljivosti (TE130). Stresni testi Dodatno se v tej fazi izvedejo še stresni testi. Testiranje vključuje tudi testiranje obremenitev in performančno testiranje. Za kompleksne projekte je ta test zelo kritičen, saj je informacijski sistem izpostavljen količini podatkov, kot jih obdela tekom delovanja v živo. Za projekte, kjer je v uporabi veliko število novih dodelav, je ta faza ključna, saj je potrebno testirati delovanje vseh novih dodelav in vmesnikov v primeru večje količine podatkov (Phases of Oracle Implementation, 2011). Faza 6: Prehod v živo in konec finančnega meseca Po testih sprejemljivosti (UAT) in uspešnih stresnih testih (NFT) se vzpostavi enako produkcijsko okolje kot je bilo okolje, kjer so bili izvedeni testi sprejemljvosti, ter stresni testi. Izvede se sestanek, kjer se ključni deležniki odločijo, ali je rešitev zrela za prehod v živo. Produkcijsko okolje se vzpostavi samo v primeru, da je sprejeta odločitev za prehod v živo. Prav tako se vzpostavi kopijo produkcijskega okolja, ki služi kot predprodukcijsko okolje, ki je kasneje uporabljeno za končno testiranje dodelav, sprememb in popravkov. Po vzpostavitvi okolij je izvedena migracija in zagon sistema. Po zagonu sistema svetovalci na lokaciji naročnika nudijo podporo do zaključka prvega finančnega meseca. Po zaključku prvega finančnega meseca se podpora prenese na standardne podporne kanale. Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 18

24 V tej fazi nastane zapisnik prevzema informacijskega sistema (Phases of Oracle Implementation, 2011). Po Oracle AIM metodologiji se lahko faze uporabijo tudi drugače ali pa določene faze tečejo vzporedno (Oracle Aim Methodology, 2010). Slika 7: Oracle AIM metodolgija (Oracle AIM Methodology diagram, 2015) PRIMERJAVA FAZ METODOLOGIJ Pregled metodologij je pokazal, da so vse metodologije sestavljene iz šestih faz (Tabela 1). Zaporedna SEYC SAP Microsoft Oracle Faza /Ponudnik 1 priprava priprava diagnostik projektni management projekta a 2 analiza poslovni analiza analiza potreb model 3 zasnova realizacija snovanje načrtovanje rešitve sistema 4 realizacija končna priprava razvoj priprava rešitve 5 testiranje in zagon in uvajanje šolanje, stresni testi in šolanje podpora uat 6 zagon delovanje operativna faza prehod v živo in konec finančnega meseca Tabela 1: Prikaz zaporedja in nazivov faz metodologij vpeljave Nazivi faz oziroma korakov v metodologijah se med ponudniki razlikujejo, toda aktivnosti, ki se izvajajo v posamezni fazi metodologije so si podobne. Edino odstopanje je vidno v metodologiji ASAP, kjer sta v fazi 2 -»poslovni model«- Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 19

25 združeni tako začetna analiza poslovanja in zajem slike procesov kot detajlno specificiranje delovanja rešitve in morebitnih vrzeli. Specifikacije delovanja rešitve in morebitnih vrzeli ostale metodologije definirajo v tretji fazi. Tako so tudi nadaljnje faze metodologije ASAP zamaknjene. Faza t.i. realizacije prestavlja pri ostalih metodologijah četrto fazo, medtem ko je v ASAP metodologiji to tretja faza. Nadalje večjo razliko predstavlja šesta faza ASAP metodologije»delovanje«. Ostale metodologije aktivnost tranzicije na standardne podporne kanale vključijo v fazo prehoda sistema v živo PREDPRODAJNI POGOVORI Z NAROČNIKOM Začetni pogovori in predprodajni sestanki s predstavniki trgovskega podjetja so se pričeli že tekom leta 2010, ko je bila s strani podjetja izražena želja po uvedbi novega informacijskega sistema. Konec leta 2010 se je naročnik dokončno odločil za vpeljavo informacijskega sistema G.O.L.D. Central/Shop in kupil licence (Sebastjan Medved, osebna komunikacija, april 2015). Pred uvedbo informacijskega sistema G.O.L.D. Central/Shop, je podjetje poizkusilo z uvedbo drugih dveh informacijskih sistemov, ki nista bila uspešna. Zavoljo tega dejstva je bilo za podjetje zelo pomembno, da bo implementator novega informacijskega sistema dovolj prilagodljiv, da lahko izvede implementacijo ne glede na morebitne težave, ki bi se lahko pojavile tekom uvajanja (Sebastjan Medved, osebna komunikacija, april 2015). Zaradi hitrosti odvijanja aktivnosti na projektu je bil projektni načrt pripravljen šele ob koncu faze analize (Sebastjan Medved, osebna komunikacija, april 2015). Prvi dve fazi standardne metodologije SEYC bosta zato obravnavani ločeno, medtem ko bo za sledeče faze predstavljen okvirni načrt in realizirani potek FAZA PRIPRAVE Faza priprave se je odvijala v aprilu V dneh med in je bila organizirana prva delavnica, kjer so bili z naročnikove strani prisotni tako arhitekti IT rešitev, kot tudi arhitekti poslovnih procesov. Na delavnici je bila izvedena predstavitev funkcionalnosti G.O.L.D. Central/Shop na podlagi katere je bil določen okvirni obseg implementacije. Nabor predstavljenih funkcionalnosti je bil na podlagi predprodajnih sestankov skrčen na funkcionalnosti, za katere so bile izražene želje na predprodajnih sestankih. Določeno je bilo, da bo informacijski sistem G.O.L.D. Central/Shop v primarni vlogi informacijski sistem za vodenje in sledenje premikomzaloge. Dodatne vloge za katere bo mogoča uporaba pa bodo: avtomatsko obnavljanje zalog, ciklične inventure, upravljanje promocij, mobilne operacije na prodajnem mestu. Na delavnici je bilo predvideno, da bo sistem uvrščen v obstoječe rešitve naročnika tako, da bo delovanje vmesnikov avtomatizirano (Projektni zapisniki, 2011). Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 20

26 Tekom delavnice so bili določeni člani upravljalnega odbora projekta, komunikacijski načrt ter strategija prehoda v živo. Člani upravljalnega odbora so bili sestavljeni iz sponzorjev in ključnih oseb tako s strani naročnika, kot tudi podjetja SEYC. Osebe, ki so bile določene v upravljalni odbor projekta, naj ne bi bile neposredno vključene v ostale aktivnosti med implementacijo (Projektni zapisniki, 2011). Komunikacijski načrt je predvideval komunikacijo z naročnikom tako preko e- pošte, kot tudi v živo, na sedežu naročnika. Ker je sedež naročnika precej oddaljen od sedeža SEYC Slovenija, je bila prav tako predvidena komunikacija preko video konferenčnega sistema, ki je bil na voljo tako na lokaciji naročnika, kot tudi na lokaciji podjetja SEYC. Za potrebe komunikacije preko e-pošte je bil ustanovljen poseben poštni naslov (e-poštna skupina), ki je zagotavljal, da so sporočila prejemali vsi deležniki podjetja SEYC, ki so sodelovali na projektu. Prav tako je komunikacijski načrt zajemal izdelavo tedenskega poročila o stanju na projektu, ki ga bo pripravil projektni vodja SEYC in poslal vodji projekta na strani naročnika (Projektni zapisniki, 2011). Za strategijo prehoda v živo je bil določen postopni prehod po blagovnih znamkah za katere je naročnik imel v lastni franšizne prodajalne. Strategija prehoda je predvidevala vzpostavitev ekipe kompetenčni center, ki bi izvajal postopen prehod poslovalnic na nov informacijski sistem. Prehod začetne franšize naj bi se izvedel s pomočjo svetovalcev ekipe EYC (Projektni zapisniki, 2011). Določena je bila okvirna struktura začetne projektne ekipe na strani SEYC in na strani naročnika. V dneh med in je bila organizirana druga delavnica, kjer se je predstavilo funkcionalnosti, ki niso bile zajete na prvi delavnici. Tako je bil na drugi delavnici bolj natančno določen obseg projekta. Dosežen je bil dogovor, da se preide v fazo analize (Projektni zapisniki, 2011). Rezultat začetnih delavnic je bil dokument opisa projekta, ki je definiral: člane upravljalnega odbora, komunikacijska pravila in kanale, okvirni obseg projekta, proces izmenjave dokumentacije, proces potrjevanja specifikacij ANALIZA Faza analize se je pričela v maju Na lokaciji naročnika je v dneh med in potekala delavnica, na kateri je bilo predstavljeno konceptno delovanje sistema G.O.L.D. Central/Shop na podlagi obsega zajetega v fazi priprave. Pred delavnicami je bila pripravljena demonstracijska instalacija informacijskega sistema. Tekom konceptne delavnice (POC proof of concept) se je v sistem vneslo predvideno parametrizacijo in strukturo matičnih podatkov, ter izvedlo poenostavljene postopke, ki se uporabljajo v podjetju. Delavnice so potekale pod vodstvom svetovalcev SEYC, na delavnicah pa so bili prisotni naročnikovi arhitekti IT rešitev in arhitekti poslovnih procesov. Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 21

27 Na podlagi delavnice je nastala začetna verzija dokumenta poslovnega modela naročnika. Dokument opisuje predviden način rabe informacijskega sistema G.O.L.D. Central/Shop, predvideno organizacijo matičnih podatkov in funkcionalnosti predvidene za rabo. Prav tako opisuje tok podatkov in zahteve za integracijo informacijskega sistema G.O.L.D. Central/Shop v druge informacijske rešitve naročnika (Projektni zapisniki, 2011). S pomočjo konceptne delavnice se je naredil podrobnejši seznam zaznanih vrzeli v delovanju, za katere bo potreben dodaten razvoj. Prav tako je bil določen seznam predvidenih dodatnih vmesnikov za komunikacijo z ostalimi informacijskimi sistemi. Na ločeni delavnici je bila predstavljena tehnična struktura in zahteve informacijskega sistema G.O.L.D. Central/Shop. S skrbniki IT infrastrukture je bilo definirano na kakšni strojni in programski opremi bo nameščen informacijski sistem. Na podlagi delavnice je nastal tehnični dokument, ki je bil osnova za vzpostavitev tehnične infrastrukture, potrebne za nadaljnje faze (Projektni zapisniki, 2011). Po konceptni delavnici se je v dneh med 15. in na lokaciji naročnika organiziralo predstavitev projekta ključnim poslovnim uporabnikom. Na delavnici so bile predstavljene G.O.L.D. Central/Shop funkcionalnosti, namen projekta vpeljave informacijskega sistema, obseg vpeljave ter časovni načrt. Detajlnih predstavitev predvidenih poslovnih procesov na predstaviti ni bilo. Ob zaključku delavnice so ključni poslovni uporabniki potrdili oziroma izrazili strinjanje za izvedbo projekta (Projektni zapisniki, 2011) ZAČETNI PROJEKTNI NAČRT Na podlagi predvidenih funkcionalnosti in zaznanih vrzeli določenih v fazi priprave in fazi analize se je v času med in pripravil začetni projektni načrt. Vključeval je tako predvidene aktivnosti in človeške vire, kot tudi časovni potek projekta. Projektni načrt se je pripravil in vzdrževal v preglednici Microsoft Excel. Začetni projektni načrt je predvideval sledeče glavne aktivnosti (Slika 8) (Začetni projektni načrt, 2011): zasnova in razvoj vmesnikov, preverjanje in testiranje kakovosti vmesnikov 1. faza, preverjanje in testiranje kakovosti vmesnikov 2. faza, dobava in integracija razvitih vmesnikov v testno okolje naročnika, testiranje vmesnikov v testnem okolju naročnika, vrzeli (GAP) zasnova in razvoj specifičnih funkcionalnosti, vrzeli dobava in integracija specifičnih funkcionalnosti, vrzeli testiranje v testnem okolju naročnika, prilagoditve aplikacije za mobilne naprave, vzpostavitev in šolanje kompetenčnega centra, stresni in zmogljivostni testi, pilot v konferenčni sobi (CRP), delavnica za zagon pilota, pilot v konferenčni sobi (CRP) druga potrditev, Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 22

28 podpora implementaciji na sedežu naročnika. Slika 8: Gantogram začetnega projektnega načrta (Začetni Projektni načrt, 2011) Začetni projektni načrt je predvideval, da bo časovni okvir trajanja projekta od do Predvideval je sledeče mejnike v izvedbi projekta (Slika 9): potrditev projektnega načrta, potrditev specifikacij prve skupine vmesnikov, potrditev dokumenta slike procesov, zaključen razvoj prve skupine vmesnikov, potrditev specifikacije druge skupine vmesnikov, izveden začetni konferenčni pilot, zaključen razvoj druge skupine vmesnikov, zaključena analiza in specifikacije za vrzeli, potrjene specifikacije za dodaten razvoj na mobilnih napravah, pripravljeni strežniki za produkcijsko okolje, osnovana ekipa kompetenčnega centra, izveden prvi pilot v konferenčni sobi, zaključeno testiranje vseh vmesnikov, zaključeno testiranje mobilnega dorazvoja, zaključeno testiranje dorazvoja za vrzeli, izveden končni pilot v konferenčni sobi, zaključeni stresni testi, zaključeno šolanje končnih uporabnikov, potrjena dokumentacija za vzdrževanje sistema, konec šolanja ekipe kompetenčnega centra, začetek pilota. Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 23

29 Slika 9: Projektni mejniki (GOLD milestones, 2011) Projektni načrt je definiral tudi pogostost sestankov upravljalskega odbora katerega naloga je, da na vsake dva do tri mesece preveri potek projekta in potrdi, ali je potek v skladu s cilji in smernicami, oziroma določi popravke v usmeritvi implementacije. Načrt je predvideval šest sestankov za preučitev poteka projekta (Začetni projektni načrt, 2011): začetek julija 2011, začetek septembra 2011, začetek decembra 2011, sredina februarja 2012, začetek aprila 2012, sredina maja V okviru projektnega načrta je prav tako potekala določitev predvidenega obsega dela in števila sodelujočih ljudi na projektu. Obseg dela na projektu se je meril v človek dnevih (8 delovnih ur) - ČD. Začetni projektni načrt je predvideval, da bo za projekt porabljenih 1947 človek dni. Od tega 557 ČD za razvoj vmesnikov, dorazvoj za vrzeli, ter prilagoditev za mobilne naprave. Projektni načrt je že na začetku predvideval, da bo razvoj vmesnikov, vrzeli in mobilnih prilagoditev potekal preko partnerskega podjetja Symphony Teleca iz iste poslovne skupine Symphony Technology Group. Za potrebe implementacije je bilo predvideno, da bo na projektu potrebovanih devetnajst oseb. Vloge oziroma specializacije svetovalskih kadrov so se delile na sledeče profile (Začetni projektni načrt, 2011): administrator podatkovnih baz Oracle, GOLD sistemski administrator, GOLD arhitekt rešitev GOLD razvijalec, Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 24

30 GOLD trener, GOLD funkcionalni strokovnjak, GOLD tester, GOLD podpornik ZASNOVA SISTEMA Po metodologiji SEYC v fazo analize uvrščamo sledeče aktivnosti iz projektnega načrta: pilot v konferenčni sobi (CRP), zasnova vmesnikov, zasnova funkcionalnosti za vrzeli (GAP), zasnova sprememb na mobilnih napravah. Pilot v konferenčni sobi (CRP) Piloti v konferenčni sobi (CRP) so predvidevali delavnice z arhitekti poslovnih procesov, kjer se predstavi ključne zahtevane funkcionalnosti sistema G.O.L.D. Central/Shop. Arhitektom poslovnih procesov naj bi prinesle globlje razumevanje procesov v informacijskem sistemu in pripomogle k lažji parametrizaciji sistema v fazi testiranja. Predstavitve, ki naj bi potekale v času med in , naj bi zajemale sledeče funkcionalnosti (Začetni projektni načrt, 2011): načini sledenja zalogam v informacijskem sistemu, avtomatsko naročanje ciklične inventure, promocijske akcije izdelkov Mix & Match. Nabor predstavljenih funkcionalnosti je bil majhen, saj naj bi imel sistem G.O.L.D. Central/Shop ob zagonu vlogo transakcijskega informacijskega sistema. Zasnova vmesnikov Ker je G.O.L.D. Central/Shop zamišljen kot vmesni informacijski sistem med informacijskimi sistemi za upravljanje matičnih podatkov, skladiščnim informacijskim sistemom (WMS) Manhattan, Oracle finančnim informacijskim sistemom, ter podatkovnim skladiščem, so bili vmesniki ključnega pomena za uspešnost integracije. G.O.L.D. Central/Shop ima že obstoječe standardizirane vmesnike, vendar ti zahtevajo velik nabor podatkov, ki pa jih naročnik ni mogel zagotoviti, oziroma je bilo ugotovljeno, da izračun določenih vrednosti lahko zagotovijo dodatni vmesniški sistemi. Namen vmesnikov bi lahko opisali kot kontrolni vmesniški sistem, ki samodejno dodatno obogati podatke v obliko primerno za uporabo v standardnih G.O.L.D. vmesnikih. Za potrebe integracije je bila predvidena zasnova osemnajstih vhodnih vmesnikov (Začetni projektni načrt, 2011): dobavitelji, lokacije, blagovne skupine, artikli, nadomestni artikli, Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 25

31 združevanje artiklov, tečaji valut, kiti, prodajne cene, najave prevzema, prevzemnice, distribucija blaga, premiki zalog, slika stanja zalog, koledar cikličnih inventur, promocije Mix & Match, izbris rezervacij za skladiščne lokacije, rezervacija zalog blaga za COMS. Za izvoz podatkov v finance je bila predvidena zasnova treh vmesnikov: stroškovna vrednost zalog, stroškovna vrednost zalog v transportu, fakture lokalnih dobaviteljev. Dodatno so bili predvideni še trije izhodni vmesniki za različne informacijske sisteme: za podatkovno skladišče je bil predviden vmesnik premikov zalog, za potrebe prevzema blaga v trgovinah je bil predviden izhodni vmesnik prevzemnih nalogov, za skladiščni sistem je bil predviden izhodni vmesnik za naročila skladišču. Skupaj je začetni projektni načrt predvideval zasnovo štiriindvajsetih različnih vmesnikov. Delavnice za zasnovo vmesnikov naj bi potekale na lokaciji naročnika. Na podlagi delavnic naj bi se izdelala funkcionalna in tehnična dokumentacija, ki bi bila kasneje predana zunanjemu razvojnemu podjetju. Predvideni termin za izdelavo specifikacij vmesnikov je bil od do in naj bi zahteval 323 ČD (Začetni projektni načrt, 2011). Zasnova vrzeli Na začetnih delavnicah so bile identificirane potencialne vrzeli v funkcionalnostih G.O.L.D. Central/Shop. Na podlagi identificiranih pomanjkljivosti je bilo predvideno, da se na delavnicah podrobno analizira in izdela specifikacije za sledečih enajst vrzeli (Začetni projektni načrt, 2011): podaljšane črtne kode, identifikacijske šifre tekstilnih izdelkov, upravljanje avtomatskega razpisa inventur, štiri dodatna poročila za inventure, nabavni pogoji za variantne artikle, prilagojeni zasloni za pregled matičnih podatkov artikla, prilagojeni zasloni za pregled zaloge, opozorila o negativni zalogi, upravljanje znižanj stroškovnih cen, številčenje dobaviteljevih faktur, Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 26

32 naročanje v več skladišč hkrati. Delavnice za podrobno analizo vrzeli naj bi potekale v času med in Za analizo in pripravo specifikacij vrzeli je bilo predvidenih 151 ČD (Začetni projektni načrt, 2011). Zasnova sprememb na zaslonih za mobilne naprave Začetne delavnice so predvidele uporabo aplikacije za mobilne naprave, vendar je bilo predvideno, da bodo potrebne spremembe na zaslonih in funkcionalnostih za mobilne naprave. Začetni projektni načrt je predvideval šest sprememb zaslonov, ki so zahtevale dodatno analizo in podrobne specifikacije sprememb (Začetni projektni načrt, 2011): naročanje, prevzem blaga, informacije o artiklih, popravki zalog blaga, vračilo blaga v skladišče, preverjanje prodajnih cen. Delavnice za spremembe na zaslonih za mobilne naprave naj bi potekale v času med in Za analizo in pripravo specifikacij sprememb na mobilnih zaslonih je bilo predvidenih 46 ČD (Začetni projektni načrt, 2011) REALIZACIJA Predviden začetek faze realizacije naj bi bil takoj po izdelavi prvih funkcionalnih in tehničnih specifikacij za vmesnike. Na začetku bi potekala vzporedno s fazo zasnove. Skupno naj bi razvoj potekal v času med in (Začetni projektni načrt, 2011). Razvoj vmesnikov V načrtu je bila predvidena postopna izdelava specifikacij za vmesnike, ter pričetek razvoja posameznega vmesnika takoj po potrditvi specifikacije, kar bi pomenilo vzporeden potek faze zasnove in faze realizacije. V vodstvu podjetja SEYC je bila sprejeta odločitev, da razvoj vmesnikov prevzame zunanji partner; podjetje, ki je član skupine Symphony Technology Group Symphony Teleca. Razvoj vmesnikov naj bi potekal v razvojni ekipi locirani v Indiji, kamor naj bi se posredovale specifikacije za izdelavo posameznega vmesnika. V začetnem projektnem načrtu so bile določene okvirne ocene zahtevnosti in začetna ocena stroškov razvoja posameznega vmesnika. Skupno je bilo za razvoj vmesnikov predvideno 367 ČD. Prve specifikacije in začetek razvoja naj bi se pričel , predviden zaključek razvoja vmesnikov pa je bil Za hitrejše testiranje vmesnikov naj bi se dobava razvitih vmesnikov izvedla v dveh fazah. Prvi del vmesnikov naj bi bil dobavljen implementatorju SEYC , drugi del vmesnikov pa (Začetni projektni načrt, 2011). Razvoj za vrzeli (GAP) Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 27

33 Razvoj identificiranih in analiziranih vrzeli v funkcionalnostih informacijskega sistema naj bi izvedel implementator SEYC interno. Pričetek razvoja naj bi bil in se zaključil Skupno je bilo za razvoj vrzeli predvidenih 150 ČD (Začetni projektni načrt, 2011). Razvoj sprememb na zaslonih za mobilne naprave Najmanjši obseg razvoja je bil predviden na spremembah zaslonov za mobilne naprave. Prav tako kot razvoj vrzeli, naj bi razvoj sprememb za mobilne naprave potekal v podjetju SEYC. Razvoj sprememb na skupno šestih zaslonih je bil predviden v času med in Skupni ocenjeni strošek sprememb za mobilne naprave je bil 40 ČD (Začetni Projektni načrt, 2011) TESTIRANJE IN ŠOLANJE V fazi testiranja in šolanja so bile predvidene sledeče aktivnosti (Začetni Projektni načrt, 2011): testiranje vmesnikov s strani SEYC, testiranje vmesnikov s strani naročnika na njegovi lokaciji (integracijsko testiranje), testiranje vrzeli s strani naročnika, testiranje dodelav za mobilne naprave s strani naročnika, stresni, zmogljivostni ter obremenitveni testi, šolanje ekipe kompetenčnega centra, testiranje migracije na nov informacijski sistem, test sprejemljivosti s ključnimi poslovnimi uporabniki, priprava gradiva za šolanje končnih uporabnikov, šolanje končnih uporabnikov. Testiranje vmesnikov s strani SEYC Testiranje vmesnikov dostavljenih s strani zunanjega razvijalca Symhony Teleca je bilo predvideno v dveh fazah. Prvi del vmesnikov naj bi bil dostavljen in s tem dnem naj bi se začelo testiranje skladnosti vmesnikov s specifikacijo. Testiranje prvih vmesnikov naj bi trajalo vse do , v ta čas pa je bil vštet tudi predviden čas za morebitne popravke delovanja. Testiranje drugega dela vmesnikov naj bi se pričelo in zaključilo Projektni načrt je predvideval da bodo na vmesnikih potrebni popravki in je vključeval kar 28 ČD za odpravo odkritih napak in pomanjkljivosti. Popravke naj bi naredil razvijalec vmesnikov. Priprava za integracijo in dobava naročniku naj bi bila zaključena do Skupno je bilo za testiranje prvega in drugega dela vmesnikov, popravke in pripravo na dobavo predvideno 82 ČD (Začetni projektni načrt, 2011). Testiranje vmesnikov s strani naročnika na lokaciji naročnika Testiranje s strani naročnika je bilo predvideno na lokaciji naročnika. Izvedlo naj bi se tako test integracije, kot tudi sistemski test. Test s strani naročnika je bil predviden tudi kot test sprejemljivosti (UAT), ki bi potrdil ali pa zavrnil delovanje vmesnikov v skladu s pričakovanji. Testiranje integracije vmesnikov v končno Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 28

34 okolje naj bi izvajalo IT osebje naročnika ob podpori svetovalcev podjetja SEYC ter razvijalcev iz podjetja Symphony Teleca. Terminski načrt je predvideval izvedbo testiranja med in Testiranje je predvidevalo prisotnost treh različnih profilov človeških virov oziroma petih oseb (Začetni projektni načrt, 2011): funkcionalni svetovalec SEYC dva tehnična svetovalca SEYC dva razvijalca Symphony Teleca Skupno je bilo za testiranje vmesnikov predvidenih 75 ČD. Testiranje vrzeli s strani naročnika Prav tako kot testiranje vmesnikov, naj bi tudi testiranje vrzeli predstavljajo končni test sprejemljivosti delovanja dodelav. Testiranje naj bi potekalo v času med in in naj bi vključevalo enega tehničnega svetovalca SEYC ter enega funkcionalnega svetovalca SEYC. Za podporo testiranjem naročnika je bilo predvideno 30 ČD (Začetni projektni načrt, 2011). Testiranje dodelav za mobilne naprave s strani naročnika Testiranje mobilnih dodelav naj bi se izvedlo na testih sprejemljivosti krajšega obsega, ki naj bi potekali med in Skupno je bilo predvidenih 20 ČD za podporo izvedbi testiranj (Začetni projektni načrt, 2011). Stresni testi Stresni testi so bili predvideni za analizo morebitnih obremenitvenih ter performančnih pomanjkljivosti. Ker je naročnik veliko trgovsko podjetje z zelo veliko količino podatkov, so stresni testi predstavljali pomemben element, ki naj bi pripomogel k uspešni uvedbi informacijskega sistema. Končni rezultati testov naj bi pokazali tako primernost zmogljivosti vmesnikov, kot tudi pripravljenost strojne opreme. Ker je bila predvidena uporaba avtomatskega naročanja je bilo v stresne teste vključeno tudi testiranje nočne obdelave podatkov, kjer se vrši ugotavljanje stanja zalog, ter njihovo avtomatsko obnavljanje (izdelava naročil). Stresni testi so predvidevali izvedbo sledečih aktivnosti (Začetni projektni načrt, 2011): priprava testnih scenarijev, testiranje zmogljivosti podatkovne baze, testiranje zmogljivosti vmesnikov, testiranje obremenitve vmesnikov, test nočne obdelave podatkov. Aktivnosti naj bi potekale med in Predvidevale so porabo 115 ČD. Šolanje ekipe kompetenčnega centra Šolanje ekipe kompetenčnega centra naj bi bil eden izmed stebrov uspešne implementacije informacijskega sistema. Ekipa kompetenčnega centera naj bi zagotavljala podporo informacijskemu sistemu po prehodu v živo. Prav tako naj bi kompetenčni center prevzel podporno vlogo pri postopnem prehodu oziroma migraciji novih tržnih znamk na nov informacijski sistem po začetni izvedbi pilota. Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 29

35 Osebje kompetenčnega centra naj bi na željo naročnika zagotavljalo podjetje Symphony Teleca, šolanje pa izvajali strokovnjaki iz SEYC. Šolanje je predvidevalo, da bodo izšolani sledeči profili strokovnjakov: administrator podatkovnih baz, GOLD arhitekt rešitev, GOLD sistemski administrator, GOLD funkcionalni strokovnjak, GOLD tehnični strokovnjak. Ker je projektni načrt predvideval šolanje samostojnih strokovnjakov je časovni termin predvideval izvedbo šolanja v času med in Skupno je ocena porabe časa predvidevala 136 ČD za izvedbo šolanja (Začetni projektni načrt, 2011). Testiranje migracije na nov informacijski sistem Ker je potrebno prehod iz obstoječega na nov informacijski sistem skrbno načrtovati in testirati, je načrt predvideval izvedbo delavnic z naročnikom. Tam bi se testiralo migracijo obstoječih podatkov iz starega na nov sistem. Delavnice naj bi potekale v času med in v skupnem obsegu 83 ČD (Začetni projektni načrt, 2011). Test sprejemljivosti s ključnimi poslovnimi uporabniki Pred odločitvijo o izvedbi pilotnega zagona je bilo dogovorjeno testiranje sprejemljivosti s ključnimi poslovnimi uporabniki. Šele v primeru potrditve ključnih poslovnih uporabnikov bi lahko stekel zagon pilota. Za testiranje je bila predvidena delavnica med in oziroma 5 ČD (Začetni p rojektni načrt, 2011). Pomoč pri pripravi in šolanju končnih uporabnikov Šolanje končnih uporabnikov naj bi izvedla ekipa kompetenčnega centra, vendar pa naj bi pri pripravi gradiva (skripte, predstavitve) pomagali svetovalci SEYC. Pomoč naj bi vršili tudi med izvedbo šolanja. Skupno naj bi priprava šolanja in šolanje končnih uporabnikov trajalo od do v obsegu 28 ČD (Začetni projektni načrt, 2011) ZAGON Strategija prehoda je predvidevala postopno migracijo franšiz različnih blagovnih znamk. Pilotno migracijo naj bi izvedla ekipa SEYC, medtem ko naj bi nadaljnje migracije izvajala ekipa kompetenčnega centra. Pilotna migracija naj bi se izvedla , naknadno pa naj bi bili na lokaciji do prisotni štirje svetovalci podjetja SEYC, ki bi nudili morebitno pomoč v primeru težav. Skupno je bilo ocenjeno, da bo za začetno podporo ob zagonu potrebnih 110 ČD (Začetni projektni načrt, 2011) REALIZACIJA PROJEKTA Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 30

36 Realizacija projekta je opisana od točke, ko je bil pripravljen projektni načrt, zato poglavje realizacije zajema samo faze od zasnove sistema naprej. Predhodne faze so se odvijale brez projektnega načrta, saj se je obseg funkcionalnosti, ki bodo v uporabi, šele določal ZASNOVA SISTEMA Pilot v konferenčni sobi Delavnice, kjer so bile natančneje predstavljene funkcionalnosti predvidene za uporabo, so potekale v času med in Arhitektom poslovnih procesov so bile predstavljene sledeče funkcionalnosti: načini sledenja zaloge v informacijskem sistemu, avtomatsko naročanje, ciklične inventure, promocijske akcije izdelkov Mix & Match. Na podlagi razprav na delavnici je bil posodobljen dokument poslovnega modela naročnika, ki je služil kot nadaljnja osnova za zasnove vmesnikov in vrzeli. Za pripravo in izvedbo delavnic je bilo potrebnih 28 ČD (Končni projektni načrt, 2014). Zasnova vmesnikov Začetna zasnova vmesnikov je potekala med in Proces analize je potekal na lokaciji naročnika, ter oddaljeno preko videokonferenčnega sistema. S tehničnim svetovalcem SEYC, funkcionalnim svetovalcem SEYC, ter naročnikovimi arhitekti IT rešitev se je zajelo zahtevane funkcionalnosti vmesnikov. Na podlagi začetnih zahtev se je na lokaciji SEYC pripravilo funkcionalne in tehnične specifikacije za razvoj, ki so bile poslane preko elektronske pošte naročniku v pregled. Dokončna potrditev specifikacij je potekala na delavnicah na lokaciji naročnika ob prisotnosti arhitektov IT rešitev. Ustreznost tehnične specifikacije je morala biti prav tako potrjena s strani razvojne ekipe zunanjega razvijalca Symphony Teleca. V fazi zasnove je bilo predvidenih in specificiranih devetnajst vhodnih vmesnikov: dobavitelji, lokacije, črtne kode, artikli, nadomestni artikli, združevanje artiklov, tečaji valut, definicije kitov (sestavljenih artiklov), prodajne cene, najave prevzemov, prevzemnice, distribucije blaga, premiki zaloge, inventurna štetja, izbrisi rezervacij za skladiščne lokacije, Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 31

37 rezervacije zalog blaga za COMS, nastavitve avtomatskega obnavljanja zalog (CAR), seznami artiklov, preklici naročil. Za izvoz podatkov v finance so bili zasnovani trije vmesniki: stroškovna vrednost zalog, stroškovna vrednost zalog v transportu, fakture lokalnih dobaviteljev. Skupno je bilo v prvem delu zasnove predvidenih dvaintrideset vmesnikov (Slika 10). Skupno je bilo za analizo in zasnovo dvaintridesetih vmesnikov porabljenih 532 ČD (Končni projektni načrt, 2014). Slika 10: Shema vmesnikov G.O.L.D. ARES (GOLD Integration, 2012) Analiza in specifikacija za razvoj vrzeli Analiza in specifikacija za vrzeli je potekala med in Vrzeli so bile identificirane že v fazi priprave in analize, tako da je v tem času potekala priprava funkcionalnih in razvojnih specifikacij. Priprava specifikacij je potekala samostojno na lokaciji SEYC, komunikacija z naročnikom pa je potekala preko videokonferenčnega sistema. Tako kot za potrditev razvoja vmesnikov so bile tudi specifikacije za vrzeli najprej posredovane preko elektronske pošte, naknadno pa potrjene na delavnicah na naročnikovi lokaciji. Posamezne vrzeli so bile predane v razvoj takoj, ko je bila pripravljena in s strani naročnika potrjena razvojna specifikacija. Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 32

38 Poleg enajstih vrzeli identificiranih na začetnih delavnicah, sta bili v fazi analize in priprave specifikacij zaznani in zajeti še dve dodatni vrzeli: spremembe procesa naročil, zagotavljanje zalog za distribucijo. Skupno je bilo za analize in pripravo specifikacij porabljenih 224 ČD (Končni projektni načrt, 2014). Zasnova sprememb na zaslonih za mobilne naprave Analiza potrebnih sprememb na zaslonih za mobilne naprave je potekala na lokaciji naročnika med in Analizo je izvedel svetovalec SEYC skupno z naročnikovim osebjem, ki je zadolženo za analizo in prenovo poslovnih procesov. Za analizo je bilo potrebovanih 11 ČD. Priprava funkcionalnih in razvojnih specifikacij je potekala na lokaciji SEYC z občasnimi posvetovanji preko videokonferenčnega sistema. Potekala je v času med in in je zahtevala 44 ČD. Funkcionalne ter tehnične specifikacije so bile posredovane naročniku v pregled, potem pa so bile potrjene na delavnici na lokaciji naročnika (Končni projektni načrt, 2014) REALIZACIJA Realizacija oziroma razvoj vmesnikov in dodelav je stekel takoj po potrditvah prvih funkcionalnih in tehničnih specifikacij in sicer za potrjene vmesnike oziroma dodelave. Začetni razvoj je potekal od , ko so bile potrjene prve specifikacije pa vse do (Končni projektni načrt, 2014). Razvoj vmesnikov Za analizo in specifikacije je bil zadolžen implementator SEYC. Razvoj vmesnikov pa je potekal pri zunanjem partnerju Symphony Teleca, kot je bilo dogovorjeno med vodstvom SEYC in naročnikom. Po razvoju določenega vmesnika je Symphony Teleca le-tega predala SEYC. Razvoj na dvaintridesetih vmesnikih se je pričel , dobave vmesnikov pa so potekale v času do Za razvoj vmesnikov je bilo porabljenih 283 ČD (Končni projektni načrt, 2014). Razvoj za vrzeli (GAP) Razvoj dodelav za vrzeli je potekal interno v podjetju SEYC. V času med in se je vršil razvoj na vseh trinajstih zahtevanih dodelavah. Skupno je bilo za razvoj in interno testiranje porabljeno 203 ČD (Končni projektni načrt, 2014). Razvoj sprememb na zaslonih za mobilne naprave Vzporedno z razvojem dodelav za vrzeli je potekal v podjetju SEYC razvoj sprememb za zaslone mobilnih naprav. Med in je bilo za razvoj in interno testiranje sprememb porabljenih 48 ČD (Končni projektni načrt, 2014) TESTIRANJE IN ŠOLANJE Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 33

39 Testiranje vmesnikov s strani SEYC Interno testiranje vmesnikov, ki jih je razvil zunanji partner, je potekalo postopoma v dveh fazah na sedežu podjetja SEYC. V primeru odkritih napak, neskladnosti ali pomanjkljivosti je bil razviti vmesnik zavrnjen in zahtevana je bila odprava napak v delovanju. Prvi del razvitih vmesnikov je bil testiran v času od do Za prvi del testiranja je bilo porabljenih 28 ČD, ter 28 ČD za izvedbo popravkov s strani Symphony Telece. Drugi del razvitih vmesnikov se je testiral v času med in Za testiranje je bilo porabljenih 16 ČD, ter kar 34 ČD za izvedbo popravkov napak ugotovljenih tekom internega testiranja. Skupno je interno testiranje vzelo 44 ČD, popravilo ugotovljenih napak pa 62 ČD. Po zaključenem testiranju se je izvedla priprava in dobava vmesnikov naročniku, kateremu so bili posredovani (Končni projektni načrt, 2014). Tekom internega testiranja so se pokazale pomanjkljivosti v kvaliteti dobavljenih vmesnikov, zato se je po dobavi vseh vmesnikov nadaljnje sodelovanje na razvoju vmesnikov z zunanjim razvijalcem Symphony Teleca prekinilo. Vse nadaljnje spremembe in popravke so izvajali razvijalci SEYC (Janko Purgaj, osebna komunikacija, maj 2015). Testiranje s strani naročnika na lokaciji naročnika Testiranje je potekalo na lokaciji naročnika. Način testiranja je predvidel dve vrsti testov: integracijsko ter sistemsko testiranje (end-to-end), test sprejemljivosti ključnih poslovnih uporabnikov (UAT). Integracijsko ter sistemsko testiranje Sistemsko testiranje (end-to-end) je zajemalo tako testiranje razvitih vmesnikov (integracijsko testiranje), kot tudi testiranje razvitih vrzeli in sprememb mobilnih zaslonov. Obenem je sistemsko testiranje zajelo še spremembe na informacijskih sistemih in vmesnikih, ki niso bili razviti ali dobavljeni s strani SEYC. Tako se je poleg dobavljenih sprememb testiralo še izvoz podatkov iz obstoječih informacijskih sistemov naročnika, ter integracijo vmesniškega sistema SIW, ki ga je naročniku dobavilo podjetje Symphony Teleca (vmesniški sistem SIW ni bil dobavljen v okviru uvedbe informacijskega sistema G.O.L.D. Central/Shop). Skupno je tako sistemsko testiranje zajelo testiranje kar petih različnih elementov. Na testiranju so bili prisotni razvijalci vmesnika SIW iz podjetja Symphony Teleca, tehnični in funkcionalni svetovalci podjetja SEYC, ekipa kompetenčnega centra, ter predstavniki naročnika IT osebje in arhitekti poslovnih procesov. Testiranje je bilo organizirano v sklopih posameznih poslovnih procesov. Za potrebe testiranja so bili vnaprej pripravljeni testni scenariji in pričakovani rezultati, ki so jih pripravili naročnikovi arhitekti poslovnih procesov. Test sprejemljivosti ključnih poslovnih uporabnikov Po sistemskem testiranju se je izvedel test sprejemljivosti s ključnimi poslovnimi uporabniki (UAT). Testiranje in predstavitev delovanja novih procesov je potekalo v učnem centru na lokaciji naročnika. Prisotni so bili svetovalci podjetja SEYC, Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 34

40 ekipa kompetenčnega centra, naročnikovi arhitekti poslovnih procesov, ter ključni poslovni uporabniki. Na podlagi pripomb, oziroma zahtev ključnih poslovnih uporabnikov so naročnikovi arhitekti poslovnih procesov skupaj s svetovalci SEYC pripravili predloge za spremembo delovanja. Prvi krog testiranja Prvo testiranje je potekalo v času med in Na lokaciji naročnika je bilo prisotnih šest strokovnjakov podjetja SEYC in ekipa kompetenčnega centra. Prav tako so bili prisotni svetovalci podjetja Symphony Teleca, ki so zagotavljali podporo pri testiranju sistema SIW. Prisotnost vseh vpletenih deležnikov je omogočala, da so se ugotovljene nepravilnosti odpravile takoj, kar ni povzročalo večjih zamud pri testiranju integracije. Potek testiranja je bil zaradi nepripravljenosti integracije med naročnikovimi obstoječimi informacijskimi sistemi in vmesnim sistemom SIW zamudno in je trajalo dlje od začetno predvidenega načrta. Skupno je bilo za testiranje porabljenih 226 ČD (Končni projektni načrt, 2014). Po sistemskem testiranju se je opravil test sprejemljivosti (UAT), ki so ga izvedli ključni poslovni uporabniki trgovskega podjetja. Testiranje je potekalo med in Test sprejemljivosti je pokazal razkorak med specificiranimi zahtevami ki so jih pripravili naročnikovi arhitekti poslovnih rešitev, ter željami ključnih poslovnih uporabnikov. Zaradi tega je bila na podlagi ugotovljenih dodatnih zahtev v času med in izvedena dodatna analiza zahtev in pripravljene specifikacije za spremembe na vmesniki in vrzelih. Med drugim se je izkazalo, da je potreben popolnoma nov vmesnik za izvoz prevzemnih nalogov. Analiza in razvoj so sta potekala vzporedno, tako da so bile spremembe in nove funkcionalnosti dobavljene Razvoj spremembe je potekal interno v podjetju SEYC. Skupno je drugi krog analiz, specifikacij in razvoja terjal 364 ČD, ki so bili porazdeljeni sledeče (Končni projektni načrt, 2014): 49 ČD analiza in specifikacija za vmesnike, 74 ČD analiza in specifikacija za vrzeli, 89 ČD razvoj vmesnikov, 152 ČD razvoj vrzeli. Drugi krog testiranj Drugi krog testiranj sistemskega in integracijskega testiranja se je izvajal na lokaciji naročnika med in Na lokaciji je bilo prisotnih šest svetovalcev podjetja SEYC, ter ekipa kompetenčnega centra, ki se je v tej točki popolnoma zamenjala. Pri sistemskem testiranju so sodelovali IT osebje naročnika, arhitekti poslovnih procesov, ter svetovalci za SIW sistem iz Symphony Teleca. Po sistemskem testiranju se je opravil test sprejemljivosti s ključnimi poslovnimi uporabniki. Test sprejemljivosti je potekal med in Skupno je bilo za drugi krog testiranj porabljenih 216 ČD. Test sprejemljivosti s ključnimi poslovnimi uporabniki je ponovno pokazal, da so potrebne spremembe v funkcionalnostih in integraciji informacijskega sistema. Analize in priprave posameznih specifikacij so potekale že med testiranji, razvoj sprememb pa je bil zaključen Skupno so analize, specifikacije in razvoj sprememb Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 35

41 drugega kroga testiranj terjale 232 ČD, ki so bile porazdeljene sledeče (Končni projektni načrt, 2014): 35 ČD analiza in specifikacija za vmesnike, 73 ČD analiza in specifikacija za vrzeli, 31 ČD razvoj vmesnikov, 92 ČD razvoj vrzeli. Tretji krog testiranj Tretji in zadnji krog testiranj se je izvedel med in Na lokaciji naročnika je bilo za potrebe testiranja prisotnih devet svetovalcev SEYC, ter ekipa kompetenčnega centra. Sistemsko testiranje je potekalo po enakem postopku kot predhodna sistemska testiranja in je potekalo med in Tretji krog testiranja sprejemljivosti s ključnimi poslovnimi uporabniki se je pričel in zaključil Skupno je tretji krog testiranja zahteval 320 ČD (Končni projektni načrt, 2014). Tretji test sprejemljivosti je pomenil tudi končni test sprejemljivosti in potrditev ključnih poslovnih uporabnikov za pripravljenost informacijskega sistema na pilotno migracijo. Stresni testi Stresni testi so testirali obnašanje vmesnikov in strojne opreme pod veliko obremenitvijo v pogojih odpovedi posameznih strojnih komponent. Izvedeni so bili tako, da se je preko vmesnikov poslalo v obdelavo veliko količino podatkov in zmanjševalo razpoložljivost strojne opreme. Prav tako je bil izveden obremenitveni test, ki je simuliral pričakovano normalno obremenitev sistema. Končno je bil izveden tudi performančni test, ki je preveril časovno trajanje obdelave podatkov. Za testiranje je bila najprej potrebna priprava na testiranje (priprava skript za simuliranje velikega toka podatkov), ki je potekala na lokaciji SEYC, kasneje pa se je izvedelo testiranje še na lokaciji naročnika. Prvi stresni test je potekal med in in je zahteval 87 ČD in prisotnost dveh SEYC svetovalcev (Končni projektni načrt, 2014). Stresni test je ugotovil nekaj performančnih pomanjkljivosti, ki so bile odpravljene tekom razvoja sprememb zahtevanih po prvem testu sprejemljivosti. Zaradi velikega števila sprememb je bil po prvem načrtovan tudi drugi stresni test. Test in priprave nanj so se izvajale v času med in po zaključenem drugem testu sprejemljivosti. Drugi krog stresnih testov je izvedel svetovalec SEYC, zahtevali pa so dodatnih 54 ČD (Končni projektni načrt, 2014). Šolanje ekipe kompetenčnega centra Šolanje ekipe kompetenčnega centra je predstavljalo ključni element za uspešno podporo postopnim migracijam po zagonu pilota. Ker je bilo predvideno, da bodo za postopno miogracijo vseh blagovnih znamk potrebna tri leta, naj bi se po izvedbi pilota ekipa svetovalcev SEYC umaknila iz lokacije naročnika. Ekipo kompetenčnega centra je sestavljalo šest svetovalcev podjetja Symphony Teleca, od tega je bila polovica funkcionalnih svetovalcev in polovica tehničnih Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 36

42 svetovalcev. Symphony Teleca je že zagotavljala podporo za integracijo lastnega informacijskega vmesnika SIW, tako da je načrt podpore predvideval, da bo celotno podporo vmesnikov med naročnikovimi informacijskimi sistemi in informacijskim sistemom G.O.L.D. Central /Shop izvajala ekipa kompetenčnega centra, ter dodatni svetovalci zadolženi za vmesniški sistem SIW. Dodatno naj bi ekipa kompetenčnega centra zagotavljala še nameščanje popravkov za sistem G.O.L.D. Central/shop, ter prvi nivo podpore za procese v G.O.L.D. Central/shop. Predviden obseg šolanja je predvideval šest mesecev za vzpostavitev usposobljene ekipe kompetenčnega centra. Šolanje kompetenčnega centra se je pričelo vzporedno z izvedbo sistemskih testiranj Za potrebe šolanja so bile vnaprej pripravljene preglednice, prav tako pa je šolanje vključevalo tudi prakso na dejanski primerih. Šolanje je obsegalo tako osnove informacijskega sistema G.O.L.D. Central/Shop, kot tudi delovanje vmesnikov med SIW ter G.O.L.D. Central/Shop. Prva faza šolanja se je zaključila , saj so udeležencem ekipe potekle vize za vstop v državo naročnika. Druga faza šolanja se je pričela vzporedno z drugim krogom testa sprejemljivosti dne , vendar so na pričetek šolanja prispeli popolnoma novi svetovalci podjetja Symphony Teleca, tako da se je šolanje začelo od začetka. Šolanje ekipe je tako potekalo vzporedno z drugim in tretjim krogom testiranj in je bilo zaključeno Ob zaključku šolanja se je izvedlo testiranje znanja ekipe. Testiranje je pokazalo, da znanje ni zadostno za izvajanje potrebnih aktivnosti ob migraciji. Na tej točki je bila sprejeta odločitev, da se nadaljnja podpora ob postopnih migracijah popolnoma prenese na implementatorja informacijskega sistema SEYC. Za šolanje ekipe kompetenčnega centra je bilo potrebovanih 120 ČD, saj se je del aktivnosti izvedel med sistemskim testiranjem (Končni projektni načrt, 2014). Testiranje migracije na nov informacijski sistem Priprave na postopek pilotne migracije so potekale po zadnjem testu sprejemljivosti v decembru Priprave so se pričele in zaključile s pričetkom pilotne migracije V tem času se je izvedlo testno migracijo matičnih podatkov, stroškovnih cen in stanja zaloge. Za testiranje migracije je bilo na lokaciji naročnika prisotnih kar sedem svetovalcev SEYC, za priprave pa je bilo potrebovanih 168 ČD (Končni projektni načrt, 2014). Pomoč pri pripravi in šolanju končnih uporabnikov Šolanje končnih uporabnikov je izvajal naročnik, svetovalci SEYC so pomagali samo pri pripravi testnih primerov za izvedbo šolanja. Skupno je priprava na šolanje potekala med in za kar je bilo porabljenih 20 ČD (Končni Projektni načrt, 2014) ZAGON Migracije franšiz na informacijski sistem G.O.L.D. Central/Shop so se izvajale postopoma. Pilotna migracija je stekla dne , ob zaključku finančnega meseca naročnika (finančni meseci se ne ujemajo popolnoma s koledarskimi meseci). Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 37

43 V času pilota je bila zagotovljena podpora s strani svetovalcev SEYC, zato so bili na lokaciji naročnika vedno prisotni dva do štirje svetovalci. Skupno s svetovalci ki so delovali oddaljeno, pa je bilo na voljo osem svetovalcev SEYC. Pilot se je odvijal od do Ker so vlogo kompetenčnega centra prevzeli svetovalci SEYC je bilo v času migracij franšiz na lokaciji vedno prisotnih od tri do šest svetovalcev SEYC oziroma najmanj osem podpornih svetovalcev skupaj z viri, ki so delovali oddaljeno z lokacije SEYC. Od do so potekale postopne migracije franšiz. Migracije novih franšiz so se odvijale ob koncu meseca, v vmesnem času pa so svetovalci zagotavljali podporo procesom in analizo novih zahtev naročnika. Skupaj s podporo ob zagonu pilota je podpora na lokaciji naročnika zahtevala dodatnih 5385 ČD (Končni projektni načrt, 2014). Nove zahteve in vrzeli odkrite po zagonu pilota so obsegale 1298 ČD skupaj z analizo in pripravo specifikacij ANALIZA ODSTOPANJ Spodnji graf prikazuje predvideno skupno porabo ČD po izdanih projektnih načrtih. (Slika 11). Š t e v i l o 12000, , , , , ,00 Predvidena poraba ČD po izdanih projektnih načrtih Skupaj ČD ČD razvoj Č D 0, Datum priprave projektnega načrta Slika 11: Predvidena poraba ČD v projektnem načrtu pripravljenem na datum Po zaključku faze analize je začetni projektni načrt predvideval porabo 1947 ČD za izvedbo implementacije informacijskega sistema G.O.L.D. Central/Shop. Za zaključek implementacije je bil predviden Načrtovana poraba ČD je na začetku faze zasnove naraščala zmerno. Prvi večji skok načrtovane porabe je zabeležen v projektnem načrtu proti koncu analize in zasnove vmesnikov, ki se je odvijala med in Predvidena skupna poraba ČD je narasla za 455 ČD. Prav tako se je zgodil zamik datuma zaključka pilota na Nadalje skupna vrednost ČD narašča med in V tem času je potekala analiza in izdelava specifikacij za vrzeli. Skupno je predvidena poraba narasla za 300 ČD, predvideni konec pilota pa se je zamaknil na Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 38

44 Šttevilo ČD Naslednji večji skok projekcije porabe ČD se je zgodil v času med in Takrat so na lokaciji naročnika potekala sistemska testiranja in testi sprejemljivosti. Velik skok na grafu je mogoče zaslediti v projekciji porabe na dan Predvidena projekcija porabe ČD je v tem času narastla za 2576 ČD. Skok v projekciji porabe je mogoče pripisati odločitvi, da bodo podporo na lokaciji tudi po zaključku pilota zagotavljali svetovalci SEYC. Predviden konec uvedbe sistema G.O.L.D. Central/Shop in s tem podpore na lokaciji naročnika je prestavljen na V času med in je rast skupne porabe zmerna, vendar stalna. Ujema se s krivuljo porabljenih ČD za razvoj, saj je bila rast skupnega števila ČD rezultat naročil novih funkcionalnosti. Drugi večji skok je mogoče zaslediti v načrtu Vzrok je mogoče poiskati v premiku predvidenega zaključka implementacije in sicer iz na Skupna poraba od te točke do končnega projektnega načrta še vedno raste, vendar se ne ujema z rastjo krivulje dodatnega razvoja. Projekcija porabe je rastla zaradi povečanega števila svetovalcev (zadolženih za izvedbo migracij zadnjih franšiz blagovnih znamk) na lokaciji naročnika. Skupno število ČD potrebnih za izvedbo je tako naraslo za 456%, iz 1947 ČD na ČD Primerjava porabe ČD Začetni projektni načrt Končna poraba Slika 12: Načrtovana in končna poraba po aktivnostih Primerjava porabe ČD v začetnem projektnem načrtu izdelanem ob koncu faze analize in končna poraba ČD (Slika 12Error! Reference source not found.) nam pokaže, da so bile poleg podpore po zagonu, za porast skupne porabe števila ČD v največji meri zaslužne sledeče aktivnosti: vodenja projekta, analiza in izdelava specifikacij, razvoj vmesnikov, Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 39

45 razvoj vrzeli, sistemski testi ter testi sprejemljivosti. Povečanje porabe števila ČD za vodenje projekta je mogoče razložiti z dvema vzrokoma. Prvi je daljše trajanje projekta začetno načrtovani konec aktivnosti je bil , dejanski konec aktivnosti pa Skupno se je trajanje implementacije iz predvidenega enega leta zamaknilo na tri leta oziroma je časovno naraslo za 200%. Drugi vzrok je naraščanje kompleksnosti projekta in s tem povezano upravljanje aktivnosti. Povečanje porabe ČD na aktivnostih»analiza in izdelava specifikacij«,»razvoj vmesnikov«,»razvoj vrzeli«ter»sistemski testi ter testi sprejemljivosti«izvira iz nenačrtovanih dodatnih krogov razvoja in testiranj. Spremembe potrjenih specifikacij je mogoče razdeliti na dve področji: spremembe/nove vrzeli, spremembe/novi vmesniki VRZELI Začetni projektni načrt je predvideval analizo in razvoj za enajst vrzeli. Tekom faze zasnove se je izkazalo, da sta v delovanju še dve dodatni vrzeli, ki nista bili vključeni v prvotno oceno porabe časa. Skupno je strošek za analizo in specifikacijo vrzeli že tekom faze zasnove narastel z 73 ČD na 224 ČD. Na testu sprejemljivosti izvedenem med in se je izkazalo, da se pričakovanja oziroma potrebe poslovnih procesov, ki so jih izrazili ključni uporabniki, ne ujemajo s potrjenim poslovnim modelom, ki je bil zasnovan z naročnikovimi arhitekti IT rešitev, ter arhitekti poslovnih procesov. Arhitekti poslovnih procesov so po prvem krogu testiranj ponovno zajeli sliko stanja procesov, kjer so ključni uporabniki izrazili nestrinjanje na testu sprejemljivosti. S svetovalci SEYC so izvedli analize za novo razkrite vrzeli v funkcionalnostih, svetovalci pa so pripravili nove specifikacije. Prvi test sprejemljivosti je tako razkril kar petnajst novih vrzeli in eno spremembo že obstoječe specifikacije vrzeli. Strošek dodatne analize in izdelave specifikacij je tako narastel za 74 ČD, strošek razvoja vrzeli pa za dodatnih 152 ČD. Drugi test sprejemljivosti, ki je potekal med in je ponovno razkril razkorak med razumevanjem ključnih uporabnikov in arhitektov poslovnih rešitev. Na novo so bile definirane dodatne dve vrzeli, tri razvite pa so potrebovale spremembe. Skupno je strošek analize in specifikacije narastel za 73 ČD, strošek razvoja pa za 92 ČD. Tako je strošek za analizo in pripravo specifikacij zavoljo sprememb, zahtevanih tekom testov sprejemljivosti, narastel za 65%. Iz začetnih 224 ČD na skupno 371 ČD. Strošek razvoja vrzeli pa ja narasel za 197%, iz začetne ocene 150 ČD na 447 ČD. Zaradi ponovnih sistemskih testov, ter testov sprejemljivosti se je prav tako povečal strošek aktivnosti»sistemski testi ter testi sprejemljivosti«, poleg tega pa so se zamaknile nadaljnje aktivnosti. Predviden konec testiranj v začetnem projektnem načrtu je bil , dejanski konec testiranj pa je bil Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 40

46 VMESNIKI Začetni projektni načrt je predvideval analizo in specifikacijo 24-ih različnih vmesnikov. Tekom faze analize je število vmesnikov naraslo na 32, tako da je strošek analize in specifikacije narasel iz predvidenih 323 ČD na 532 ČD. Tako kot za vrzeli, se je tudi za vmesnike ugotovilo, da ne zagotavljajo vseh podatkov potrebnih za funkcioniranje novo odkritih vrzeli. Spremembe po prvi fazi testiranj so zahtevale en nov vmesnik ter kar petnajst sprememb na obstoječih vmesnikih. Skupno je strošek analize in specifikacij narasel za 49 ČD, strošek razvoja pa za 89 ČD; na skupno 372 ČD. Drugi krog testiranj je zaradi novih vrzeli predvidel sedem sprememb na vmesnikih ter štiri dodatne vmesnike. Strošek analize in specifikacij za vmesnike je narastel za 35 ČD, strošek razvoja pa za 31 ČD. Skupno je bilo pri analizi in specifikacijah vmesnikov za 91% več stroškov od predvidenih 323 ČD v začetnem projektnem načrtu. Razvoj pa se je od predvidenega zneska 367 ČD povečal za 39% na 447 ČD PODPORA PO ZAGONU Daleč največji delež skupne porabe ČD na projektu je imela podpora na lokaciji naročnika. Delež porabe ČD po aktivnostih Vodenje projekta Analiza in izdelava specifikacij Razvoj vmesnikov 1% 50% 12% 8% 10% 5% 7% 1% 4% 0% 2% 0% 0% Razvoj vrzeli Razvoj mobilnih zaslonov Delavnice Celostna ter potrditvena testiranja Gradivo za končne uporabnike Stresni test Priprava na pilot Podpora po zagonu Šolanje kompetenčnega centra Spremembe po zagonu Slika 13: Delež porabe po aktivnostih Peter Maldwyn Smolej: Vpeljava sistema G.O.L.D. v veliko trgovsko podjetje stran 41