INTEGRACIJA INFORMACIJSKEGA SISTEMA PO PREVZEMU …

Diplomsko delo visokošolskega strokovnega študija Informatika v organizaciji in managementu

INTEGRACIJA INFORMACIJSKEGA SISTEMA PO PREVZEMU PODJETJA

Mentor: viš. pred. dr. Gregor Lenart Kandidat: Edin Kumalić

Kranj, junij 2014

ZAHVALA Iskreno se zahvaljujem mentorju dr. Gregorju Lenartu za hitro odzivnost, koristne predloge, dostop do uporabnega gradiva, priporočila, komentarje in usmeritve. Hvala go. Maji Leban iz podjetja Kolektor Group in g. Jaki Križaniču iz podjetja Turboinštitut za sodelovanje. Obema se zahvaljujem tudi za soglasje za objavo. Zahvaljujem se tudi go. Teji Bačar za trud, ki ga je vložila v to, da je besedilo v skladu s pravili slovenskega jezika.

POVZETEK

Diplomska naloga opisuje potek integracije informacijskega sistema (IS) podjetja Turboinštitut v IS Kolektor Group, s podrobnejšo analizo uvajanja proizvodnega modula sistema SAP ECC 6.0. Prevzem družbe Turboinštitut se je zgodil oktobra 2013, integracija IS pa se izvaja v letu 2014. Po prevzemu podjetja si vodilni želijo hitrega vključevanja prevzetega podjetja v organizacijsko kulturo in način dela prevzemnika. Pri tem igra pomembno vlogo informacijska tehnologija (IT), saj si danes brez nje ne predstavljamo učinkovitega doseganja strateških ciljev in sinergijskih učinkov. Problem uspešne IT integracije po prevzemu podjetja smo obravnavali s splošnega organizacijskega vidika in tudi konkretno na primeru uvajanja proizvodnega IS v podjetju Turboinštitut potem, ko ga je prevzela Skupina Kolektor. V prvem delu diplome smo proučevali, kako pomembno je IT področje za prevzemni posel, kakšna tveganja prinaša in po katerih kriterijih bi lahko ocenjevali uspešnost integracije. Pri tem smo se dotaknili tem, kot so: pravočasno vključevanje IT v prevzemne pogovore, strategija integracije, IT kultura, obvladovanje odpora pri IT projektih, IT podpora. Za navedena tveganja smo poiskali rešitve v literaturi in jih primerjali z izvedbo integracije na obravnavanem primeru. Nekatere odgovore smo poiskali tudi s pomočjo intervjujev z vodilnimi v IT oddelkih Turboinštituta in Skupine Kolektor. V drugem delu diplome smo na vzorčnem primeru opisali uvajanje IS SAP v proizvodnji obravnavanega podjetja. Tudi pri tem projektu smo poiskali tveganja in izvedbo primerjali s priporočeno prakso v literaturi. S primerjalno analizo smo ugotovili, da je bila izbrana primerna strategija integracije, da se je ta izvajala hitro in v času pisanja diplomskega dela brez večjih težav, na katere nas opozarjajo primeri iz literature. Uvajanje SAP-a je potekalo po priporočeni metodologiji ASAP. Podali smo nekaj predlogov, ki se tičejo izobraževanja uporabnikov, in priporočilo glede zgodnejšega vključevanja oddelka IT pri prevzemnem procesu.

KLJUČNE BESEDE:

- IT integracija - prevzem - informacijski sistem - planiranje proizvodnje

ABSTRACT The thesis describes the course of the integration of information systems (IS) of Turboinštitut in IS Kolektor Group, with detailed analysis of the SAP ECC 6.0 production module implementation. The acquisition of Turboinštitut took place in October 2013, IS integration has been carried out in the year 2014. After taking over the company, CEOs want to speed the integration of target company into the organizational culture and working methods of the bidder company. There is an important role for information technology (IT) in this process. Actually, today we can’t imagine efficient achieving of strategic goals and synergistic effects without it. We discussed the problem of successful IT integration after the acquisition from general organizational point of view and also specifically in the case of the introduction of SAP in the Turboinštitut’s production after it was taken over by Kolektor Group. In the first part of the thesis we studied the importance of the IT field for acquisition deal, the risks associated with it and what criteria should be taken into account to evaluate integration success. In doing so, we considered subjects such as: the right time to engage IT in takeover process, strategy of integration, IT culture, resistance management in IT projects, IT Service Desk. For those risks, we have found solutions in the literature and compared them with the practice in the presented case. We searched for some answers in interviews with leaders of IT departments in Turboinštitut and Kolektor Group. In the second part of the thesis we described the sample case for implementation of SAP IS in the production of the target company. Also, in this project we searched for risks and compared realization with recommended practice referenced in the literature. With comparative analysis, we have found that in this case appropriate integration strategy was selected, that integration was implemented quickly and at time of writing the thesis without major problems like described in the literature. The introduction of SAP was conducted according to the recommended methodology ASAP. We have given some suggestions concerning the education of users and recommendation regarding the earlier engagement of the IT department in the acquisition process.

KEYWORDS:

- IT integration - acquisition - information system - production planning

KAZALO

1 PREDSTAVITEV PROBLEMA ............................................................ 1

1.1 Metodologija ...................................................................... 1 1.2 Omejitve diplomskega dela ..................................................... 2

2 PREVZEMI PODJETIJ .................................................................... 2

2.1 Vrste prevzemov .................................................................. 2 2.2 Predstavitev tarče ................................................................ 4 2.3 Predstavitev prevzemnika ....................................................... 4 2.4 Primerjava obeh podjetij ....................................................... 6

3 INFORMACIJSKI SISTEM ................................................................ 7

3.1 Strojna oprema ................................................................... 7 3.1.1 Ethernet mrežna arhitektura ................................................. 7 3.1.2 Strežniška infrastruktura ...................................................... 7 3.2 Programska oprema .............................................................. 8 3.2.1 GoSoft ........................................................................... 8 3.2.2 SAP ............................................................................... 8 3.2.3 IBM Notes ....................................................................... 10 3.2.4 Microsoft Exchange ........................................................... 11 3.2.5 SharePoint...................................................................... 11 3.3 Komunikacijska oprema ........................................................ 12 3.3.1 IP telefonija in VoIP .......................................................... 12 3.3.2 Microsoft Lync ................................................................. 12

4 INTEGRACIJE INFORMACIJSKEGA SISTEMA PRI PREVZEMIH .................... 13

4.1 Strategije integracije ........................................................... 14 4.2 Kulturne razlike .................................................................. 15 4.2.1 IT vrednote in konflikti ....................................................... 15 4.3 Uporabniški vidik ................................................................ 17 4.3.1 Podpora ......................................................................... 17 4.3.2 Premagovanje odpora ........................................................ 18 4.4 Ocenjevanje uspešnosti ........................................................ 20

5 ANALIZA OBSTOJEČEGA STANJA ................................................... 21

5.1 IT podjetja Turboinštitut ....................................................... 21 5.2 IT Skupine Kolektor ............................................................. 22

6 OPIS PROJEKTA INTEGRACIJE ...................................................... 23

6.1 Strategija in cilji................................................................. 23 6.2 Tveganja za kulturni konflikt .................................................. 24 6.3 Projektne aktivnosti ............................................................ 25 6.4 Težave ............................................................................ 25 6.5 Uporabniška izkušnja ........................................................... 26

7 PRENOVA PROIZVODNEGA INFORMACIJSKEGA SISTEMA ....................... 27

7.1 Uvod ............................................................................... 27 7.1.1 Predstavitev modulov SAP ECC 6.0 ......................................... 28

7.2 Organizacijska struktura v SAP-u .............................................. 28 7.3 Priporočena metodologija ...................................................... 29 7.4 Obstoječe stanje ................................................................ 30 7.5 SCOR ............................................................................... 34 7.6 Prenova proizvodnje s programsko rešitvijo SAP ............................ 35 7.7 Vzorčni primer ................................................................... 36 7.7.1 Izobraževanje uporabnikov .................................................. 46 7.7.2 Podeljevanje vlog in dostopov .............................................. 46 7.7.3 Priprava podatkov ............................................................. 46

8 VREDNOTENJE ......................................................................... 47

8.1 Integracija informacijskega sistema .......................................... 47 8.2 Uvedba ERP SAP ................................................................. 49

9 PRIPOROČILA .......................................................................... 50

9.1 Integracija informacijskega sistema .......................................... 50 9.2 Uvedba ERP SAP ................................................................. 50 9.3 OSTALI PREDLOGI ................................................................ 51

10 ZAKLJUČEK .......................................................................... 52

LITERATURA IN VIRI ........................................................................ 53

PRILOGI .................................................................................. 56 KAZALO SHEM ........................................................................... 56 KAZALO SLIK ............................................................................. 56 KAZALO GRAFOV ........................................................................ 57 KAZALO TABEL .......................................................................... 57 POJMOVNIK .............................................................................. 58 KRATICE IN AKRONIMI .................................................................. 58

Univerza v Mariboru – Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija

Edin Kumalić: Integracija informacijskega sistema po prevzemu podjetja stran 1

1 PREDSTAVITEV PROBLEMA Diplomska naloga opisuje potek integracije IS podjetja Turboinštitut v IS Kolektor Group, s podrobnejšo analizo uvajanja proizvodnega modula sistema SAP ECC 6.0. Prevzem družbe Turboinštitut se je zgodil oktobra 2013, integracija IS pa se izvaja v letu 2014. Po prevzemu podjetja po navadi sledijo organizacijske spremembe, vključevanje v poslovno kulturo prevzemnika in integracija informacijskega sistema in procesov. Glede na to, da so ti procesi relativno kompleksni, obstaja tveganje, da ne bodo potekali tako, kot je bilo načrtovano. Posledično to lahko ogrozi celoten posel. Marsikaj gre lahko narobe. V prvem delu diplomskega dela se bomo osredotočili na tveganja pri integraciji informacijskega sistema. Kot problem smo zaznali pozno vključenost IT oddelka v prevzemne aktivnosti. Večina podjetij, ki se ukvarjajo s prevzemi, tega problema niti ne zaznajo, vendar je v literaturi zabeležen in raziskan. Omenjeni so primeri, ko je ponudnik odstopil od posla zaradi prevelikih investicij, ki bi bile potrebne za integracijo informacijskega sistema (Huges, 2013). Dotaknili se bomo še drugih tveganj, kot so kulturne razlike, odpor uporabnikov in izbira najprimernejše strategije integracije. Prevelike razlike med podjetjema v infrastrukturi lahko integracijo časovno razvlečejo, kar ima lahko negativne učinke na motivacijo zaposlenih. Na koncu bomo omenili vrednotenje uspešnosti integracije, pri katerem je problem, da niso na voljo znanstveni kazalci, ki bi določali, ali je neka integracija uspešna ali ne. Do nekaterih odgovorov si bomo pomagali z intervjuji vodij oddelkov informacijske tehnologije Turboinštituta in Kolektor Group. V drugem delu pa bomo kot problem obravnavali uvajanje proizvodnega informacijskega sistema, s katerim želimo odpraviti zamude pri naročanju materialov, doseči optimalno izkoriščenost proizvodnih kapacitet in pričeti z informacijsko bolje podprtim planiranjem proizvodnje in potreb.

1.1 METODOLOGIJA Pri izdelavi diplomskega dela smo uporabili naslednje metode: študija literature, študija primera, primerjalna analiza informacijske tehnologije in intervju.



1.2 OMEJITVE DIPLOMSKEGA DELA V diplomskem delu se bomo iz širše perspektive osredotočili na ožjo, za navadnega informatika, ki je skrbel za podporo uporabnikov v prevzetem podjetju, precej neznano. V drugem delu smo obravnavali vzorčni primer, ki je bil uporabljen pri usposabljanju zaradi lažjega spoznavanja s sistemom SAP in spremenjenimi procesi v proizvodnji. To je tudi razlog, zaradi katerega nismo podali podrobnejše analize in bolj poglobljene kritike uporabnosti sistema s tehtnejšimi predlogi za izboljšanje. To bi bilo možno šele po nekajmesečni uporabi, spremljanju in tudi kvantitativni evaluaciji na osnovi podatkov, ki bodo na razpolago v novem sistemu. Projekt uvajanja SAP-a v Turboinštitutu je trajal 3 mesece. Zaradi integracije informacijskega sistema je bil preostali čas, v katerem sem asistiral pri vodenju projekta, relativno omejen.

2 PREVZEMI PODJETIJ

2.1 VRSTE PREVZEMOV Biološka teorija organizacije (Morgan, 2004) pravi, da je organizacija živ organizem, element odprtega sistema, v katerem troši omejene količine energije, da bi si zagotovila obstoj. Ko te energije zmanjka, ne preostane veliko rešitev. Med pogostejšimi je prodaja podjetja oz. prevzem ali akvizicija (ang. takeover ali aquisition) s strani drugega podjetja. Prvemu podjetju pravimo tarča, drugemu prevzemnik, oblike prevzema pa prikazuje shema 1.

NAKUPIAKTIVE

Prevzemi z odkupom delnic /deležev

Združitve

Prevzemi s pridobitvijo pooblastil za zastopanje

Odkupi z zadolžitvijo

Spojitve

Pripojitve

NAKUPIPASIVE

Prevzemi z odkupom premoženja

PREVZEM

Shema 1 – Oblike prevzemov po Andreju Bertonclju (2008)

Aktiva se nanaša na premoženje (stanje sredstev), pasiva pa na vire tega premoženja oziroma obveznosti do virov sredstev. O združitvah (ang. merger) govorimo, ko se dve ali več podjetij združi v eno. Pri pripojitvah od vseh podjetij, ki se združujejo, ostane samo eno, ki prevzame aktivo in pasivo ostalih podjetij (Tajnikar, 2000). Spojitev je ustanovitev nove kapitalske družbe, na katero preide premoženje družb, ki se spajajo (Bertoncelj, 2008).



Proces vključevanja v nov poslovni model in kulturo imenujemo integracija. Organizacijske kulturne razlike med partnerjema so po nekaterih avtorjih (Recklies, Steffen) najpogostejši razlog, da prevzemni proces ne doseže zastavljenih ciljev. Prevzemi in združevanja segajo v začetek 19. stoletja, ko so bili spodbujeni s pozitivnim gibanjem na delniškem trgu in poskusom ustvarjanja monopolov. Če gre za nakup konkurenčnega podjetja, ki ga potem s sistematičnim zmanjševanjem stroškov integriramo v matično podjetje, govorimo o horizontalnem prevzemu. V primeru, ko gre za nakup podjetja, ki se nahaja v verigi (ang. supply chain), ki sega od dobavitelja surovin do končnega uporabnika, govorimo o vertikalnem prevzemu. Pri slednjem je pred sklenitvijo posla pomembno, da ima podjetje izdelano strategijo nastopa na enem ali več industrijskih področjih, na katerih želi nastopati. Pri tem pazi predvsem na stroške in učinek na osnovno področje delovanja. Kupuje tista podjetja, s katerimi doseže nižjo ceno izdelka, kot je treba odšteti za isti izdelek na tržišču. Oceniti mora, ali bo nastop na drugem področju ali panogi oslabil osnovno dejavnost, saj bosta upravljanje in nadzor težja (Jurevicius, 2013). Nekateri avtorji (Stuckey & D.White, 1993) odsvetujejo vertikalne integracije, razen če je to nujno. Kot razlog navajajo visoko tveganje in stroške ter nereverzibilnost procesa. Vertikalne integracije terjajo temeljit strateški premislek. To pa ne pomeni, da druge oblike prevzemov niso tvegane. Dvajsetletna študija, ki jo je opravil Robert F. Bruner, je pokazala, da se je tretjina poslov končala z izgubami, tretjina je ostala na istem, približno tretjini pa so se v 5-letnem obdobju, kolikor je Bruner spremljal podjetja iz 120 znanstvenih študij, finančni kazalci obrnili navzgor. Kot najpogostejše razloge, zaradi katerih so bili prevzemni posli neuspešni, Gartner (Mack, 2005) navaja naslednje:

Mešanje vizije in strategije (strategija mora jasno opredeliti poslovni model, ki mora biti razumljiv vsem vpletenim).

Kulturni šok (podcenjevanje zaposlenih, zaradi česar »začnejo veslati« v nasprotno smer).

Preplačilo kupljenega podjetja (vloga IT-ja je tukaj bolj na strani stroškov). Slabo opravljen skrbni pregled podjetja (ang. due diligience). Slaba izvedba (zaradi slabega vodenja prevzema). Neupoštevanje strank in poslovnih partnerjev. Negativen odziv trga. Preveč sprememb (več kot jih lahko absorbira prevzeto podjetje).

V literaturi (Salame, 2006) smo poleg navedenih odkrili še naslednje:

Izguba ključnih kadrov Slaba komunikacija Pomanjkanje usposabljanja Slaba vpletenost kadrovske službe Neuspešno planiranje Moč politike

Po raziskavi, ki jo je leta 2005 izvedlo podjetje Accenture z intervjuji v 334 ameriških podjetjih, so vodilni kot najbolj kritično točko pri prevzemu zaznali ravno integracijo IT (glej graf 1).



Graf 1 – Kritični faktorji uspeha pri prevzemu – rezultati raziskave (Accenture, 2005)

2.2 PREDSTAVITEV TARČE Turboinštitut je bil ustanovljen leta 1948 s strani gospodarskega ministrstva Jugoslavije z namenom, da postane center za raziskave in razvoj hidravličnih strojev v takratni državi. Petdeset let pozneje se je spremenil v delniško družbo, v kateri imajo zaposleni večinski delež. Osrednja dejavnost podjetja je razvoj, izdelava in obnova turbin in črpalk za male hidroelektrarne (MHE) od 0,5 do 20 MW moči po agregatu ter inženiring in oprema celotne hidroelektrarne. Pomembna dejavnost so tudi raziskave in razvoj na področju simulacij toka in dinamike tekočin. Turboinštitut je eden od dveh neodvisnih laboratorijev na svetu, ki je sposoben in opremljen za preizkušanje turbin in črpalk po standardu IEC 60193 (Letno poročilo 2012). Turboinštitut je posebno ponosen na svoje poslanstvo proizvajanja okolju prijaznega obnovljivega vira energije in konstantnega izboljšanja delovanja hidravličnih strojev.

2.3 PREDSTAVITEV PREVZEMNIKA Koncern Kolektor je lani (2013) praznoval jubilejno 50. obletnico obstoja. Ob slovesnosti je aktualni (četrti) direktor, Stojan Petrič, ponosno predstavil nekaj kazalcev: 450 milijonov evrov prihodkov, od tega eno tretjino v tujini, in 3076 zaposlenih, od tega več kot 800 v tujini (Rupnik, 2013). Vse skupaj se je začelo leta 1963, ko je bila v Idriji ustanovljena družba Tovarna kolektorjev Idrija. Zamišljeno je bilo, da bo skupaj z Iskro zagotavljala potrebe takratne jugoslovanske avtomobilske industrije. Pomemben mejnik je bilo leto 1968, ko s takratnim tretjim največjim evropskim proizvajalcev kolektorjev, nemškim podjetjem Kautt&Bux, podpišejo licenčno pogodbo in tako pridobijo



know-how1 (Šemrl, 2012). Nemci so s prodajo znanja in (dosti manj) z naložbami v idrijski tovarni pridobili 49-odstotni delež podjetja, vendar pa so si poleg tehnologije in strojev (ki so bili pogosto že odsluženi) zagotovili tudi kredite in trg za izdelke, ki so bili pod cenovnim pritiskom (Šemrl, 2012). Zaradi notranjih nesoglasij je šel Kautt&Bux leta 1993 v stečaj. Kolektor je poravnal obveznosti do stečajnega upravitelja in si izboril vpliv na izbiro novega družbenika. To je postalo ameriško podjetje Kirkwood, takrat največji ameriški proizvajalec komutatorjev, ki je kupilo 51-odstotni delež Kolektorja, vendar je moral spoštovati pogodbo, ki je terjala 75-odstotno soglasje za vse pomembne odločitve. Lahko so vplivali le na imenovanje direktorja (Šemrl, 2012). Z novim družbenikom so bile Kolektorju odprte nove možnosti za razvoj, saj je dobil neposreden dostop do kupcev (prej so na zahodnem trgu nastopali prek nemškega partnerja). V letu 2002 se je Idrijčanom ponudila priložnost za odkup deleža, ki so ga obvladovali Američani, kar so tudi izkoristili. Poleg tega so kupili še večinski delež podjetja Kautt&Bux in si tako utrdili položaj na svetovnem tržišču, kjer so obvladovali 15-odstotni delež, v Evropi pa 50-odstotni (Šemrl, 2013). Kolektor se je leta 2003 preoblikoval v koncern, pred tem je dokončal proces lastninjenja in pristal stoodstotno v slovenskih rokah. Poslovne dejavnosti, kot so kadrovska in pravna funkcija, informatika, kakovost, finance, prodaja in nabava, vodi Kolektor Group za vsa podjetja v skupini (na sredini leta 2014 jih je že 30). Vodstvo Kolektorja se je leta 2000 odločilo za diverzifikacijo proizvodnega programa, deloma zaradi tega, ker že obvladujejo doberšen del trga komutatorjev in pri razvoju ni pričakovati takšnih sprememb kot v preteklosti, deloma pa zaradi razpršitve naložbenih tveganj. Podjeta znotraj koncerna spadajo v eno od treh divizij:

Komponente in sistemi (komutatorji, elektronske komponente, magnetne komponente, rotorji, hibridne komponente, interier in eksterier, elektronika in pogoni)

Stavbna tehnika in izdelki za dom (inženiring objektov, inštalacije, klimatizacija, sanitarna tehnika, izolacija, sesalniki)

Energetika in industrijska tehnika (transformatorji, avtomatizacija in inženiring, namenski proizvodi za avtomatizacijo, orodjarstvo, strojegradnja in avtomatizacija)

Turboinštitut izpolnjuje vrzel v energetski diviziji. Način prevzemanja podjetij Skupine Kolektor opisuje izvršni direktor Radovan Bolko: »Sam proces prevzema kot postopek niti ni zahteven. Običajno se začne z identifikacijo prevzemne tarče. Sledi vzpostavitev kontakta in v primeru, da podjetje ni že v procesu prodaje, preverjanje, če pri lastnikih obstaja interes za prodajo. Po pregledu predstavitvene dokumentacije se pripravi neobvezujočo ponudbo, ki ji sledi skrben pregled, kjer se preveri vse razpoložljive podatke in izvrši tudi pregled in groba analiza vseh poslovnih procesov. Sledi obvezujoča ponudba. Če je sprejeta, preide prevzem tarče v last kupca po plačilu kupnine. To je seveda opisano skrajno poenostavljeno. Redki procesi se zaključijo prej kot v enem letu in vsi koraki so povezani z zelo zahtevnimi odločitvami. Na koncu moram še poudariti – po prevzemu se pravo delo šele začne. Prevzemno tarčo je treba vključiti v koncern in začeti koristiti sinergije« (Bolko, 2013).

1 Prenos načina dela in znanja



2.4 PRIMERJAVA OBEH PODJETIJ Za primerjavo smo vzeli število zaposlenih, letni promet in izobrazbeno strukturo iz poslovnega poročila obeh podjetij za leto 2012.

Graf 2 – Prihodki v letu 2012

Graf 3 – Število zaposlenih na dan 31. 12. 2012

Graf 4 – Delež zaposlenih z vsaj visoko izobrazbo (31. 12. 2012)



3 INFORMACIJSKI SISTEM Informacijski sistem (IS) zajema množico med seboj odvisnih komponent (strojna oprema, programska oprema, komunikacijska oprema, ljudje), ki zbirajo, posredujejo in obdelujejo podatke. »Ljudje z uporabo informacijske tehnologije pridobivajo in posredujejo podatke, da si z njimi oblikujejo informacije v zvezi s procesi« (Gričar, 2002; 625). IS torej potrebujemo, da bi lažje obvladovali procese. Zagotavlja pretok informacij (ne samo podatkov). »Informacija je problemsko usmerjeno in na nekoga naslovljeno sporočilo o problemih, povezanih z izvajanjem« (Gričar, 2002; 626). Omejili se bomo na tiste sestavine IS, ki se nanašajo na integracijo, ki je predmet diplomskega dela. Glede na to, da gre za znana in dobro raziskana področja, bomo podali samo osnovni opis.

3.1 STROJNA OPREMA 3.1.1 Ethernet mrežna arhitektura Ethernet (standard IEEE 802.3 s kasnejšimi hitrejšimi inačicami u, z, ab in ae) je najbolj razširjena mrežna arhitektura za lokalno omrežje (LAN – ang. kratica za Local Area Network), ki je bila razvita l. 1970. Za komunikacijo potrebuje protokol TCP/IP ali SPX/IPX (komunikacijski protokoli so zaradi zapletenosti razdeljeni v plasti; referenčni model razdelitve po plasteh se imenuje OSI). Prednosti etherneta so hitrost, zanesljivo delovanje, nizka cena, enostavna postavitev in dobra programska in strojna podpora. Slabost pa je precej na strani varnosti. Je enostaven za prisluškovanje ali sabotažo. Obstaja več tipov etherneta: standardni (10BASE5), s parico (10BASET), z optičnimi kabli (10BASEFL), hitri (100BASETX ali 100VGAnyLAN), gigabitni (1000BASET ili 1000BASE) itd. Prva številka označuje hitrost, BASE je skrajšano za osnovnopasovno omrežje (ang. baseband). Imamo tudi širokopasovno (ang. broadband). V tem primeru bi bila oznaka npr. 10BROAD36. Zadnja številka označuje največjo dovoljeno dolžino, izraženo v 100 metrih, zadnje črke pa označujejo prenosni medij. Glavne topologije omrežja so: vodilo (ang. bus), zvezda (ang. star) in obroč (ang. ring). V našem primeru je gigabitni ethernet urejen po topologiji zvezde. Na fizičnem nivoju imamo UTP kabel 5e (1000BASE-T) in optično povezavo (1000BASE – SX). 3.1.2 Strežniška infrastruktura Termin strežnik označuje sistem, ki odjemalcem (klientom) nudi storitve, kot so: dostopanje do omrežnega diska, brskanje po spletnih straneh, nadgradnja programske opreme, uporaba elektronske pošte, upravljanje z mrežnimi licencami programske opreme itd. Gre torej za enega najpomembnejših sestavnih delov informacijskega sistema. Strežnik ne more opravljati svoje funkcije brez operacijskega sistema, ki upravlja s posameznimi strojnimi komponentami. Najbolj uveljavljeni operacijski sistemi so bodisi različice Unixa ali Windows. Medtem ko ima slednji več kot 90-odstotno prevlado na področju namiznih računalnikov (Net Applications, marec 2014), operacijski sistemi na osnovi Unixa



obvladujejo 67 % spletnih strežnikov (W3Techs, januar 2014) in 98 % superračunalnikov (TO500, november 2013). Omenili bomo nekatere karakteristike sodobnih strežnikov, ki jih zagotavljajo vsi večji proizvajalci:

Prilagojenost virtualizaciji in računalništvu v oblaku Zanesljivost, razpoložljivost in podpora (ang. reliability, availability and

serviceability – RAS) Podpora grafičnim procesnim enotam in diskom SSD z visokim številom

vhodno/izhodnih operacij na sekundo (IOPS) Redundantnost strojnih komponent Orodja za optimalno upravljane strežniških zmogljivosti Energetska učinkovitost Nadgradljivost

3.2 PROGRAMSKA OPREMA 3.2.1 GoSoft GoSoft-2000 je ERP2 podjetja GOinfo, d. o. o., iz Nove Gorice. Sistem je prilagojen proizvodnim podjetjem in javnim ustanovam. Omogoča kompletno spremljanje in nazor proizvodnje (MRP-II3), vključno z aktivnostmi, tehnično dokumentacijo (kosovnice, tehnološki postopki), delovnimi nalogi, zasedenostjo kapacitet, analizami, knjiženjem prometa, upravljanjem zalog itd. Ta proizvodni modul v Turboinštitutu ni bil implementiran, čeprav je bilo to načrtovano, saj je zelo težko spremljati projekte brez informacijsko podprte proizvodnje. Uvedba ERP sistema SAP, o kateri bomo več napisali v nadaljevanju, bo tako največ novosti prinesla ravno proizvodnji. 3.2.2 SAP SAP4 je programski izdelek istoimenskega nemškega podjetja iz Walldorfa. Gre za enega največjih svetovnih razvijalcev programske opreme z več kot štiridesetletno tradicijo (od leta 1972), nedvomno pa zasedajo prvo mesto na svetu med razvijalci sistemov ERP, zato ne preseneča, da je bil ERP za začetku sinonim za SAP. Z vidika nadaljnjega razvoja velja za varno naložbo, ki pa ni tako poceni. Stroški na uporabnika, vključno z izobraževanjem, strojno opremo, licenco, strokovno pomočjo in vzdrževanjem, so v prvem letu uporabe ocenjeni na približno 20.000

2 ERP je angleška kratica za Enterprise Resource System. Gre za poslovni informacijski sistem, ki zajema praktično vsa pomembna področja poslovanja, od računovodstva, financ, kontrolinga, prodaje, nabave do kadrovske funkcije in še bi lahko naštevali. ERP je pomemben podatkovni sistem v podjetju, saj vodstvu omogoča spremljanje rezultatov poslovanja. 3 MRP-II je angleška kratica za Manufacture Resource Planning. Lahko bi ga zamenjali za MRP, kar pomeni Material Requirements Planning, vendar gre v prvem primeru za načrtovanje uporabe proizvodnih resursov, v drugem (ki je modul od MRP-II) pa za upravljanje s proizvodnimi materiali. Oba sta predhodnika sodobnih sistemov ERP. 4 Systemanalyse und Programmentwicklung in der Datenverarbeitung po nemško ali Systems, Applications, and Products in Data Processing po angleško bi lahko prevedli tudi kot sistemi, aplikacije in produkti pri obdelavi podatkov.



evrov. Seveda pa imajo organizacije možnost te stroške tudi zmanjšati. Skupina Kolektor ima na primer lastno ekipo zaposlenih, ki izobražuje uporabnike znotraj koncerna. Pri tem jim pomaga eden zunanji svetovalec. SAP-ov cilj od začetka je bil spremeniti svet (Anderson, 2011) in to danes niti ne zveni tako utopično. Njihov izdelek uporablja več kot milijon uporabnikov po celem svetu, na različnih platformah, v 40 jezikih in 50 valutah. Če upoštevamo dejstvo, da organizacije poslovne procese v glavnem prilagajajo njihovim rešitvam, jim daje to ogromno moč in tudi odgovornost. Za SAP je značilna podpora različnih platform in operacijskih sistemov. Narejen je po konceptu specializacije in integracije. To v praksi pomeni, da ima modularno zgradbo (vsak modul pokriva posameznih poslovno področje; nekateri moduli so napisani za specifične potrebe posamezne industrije), ki je povezana v enotno bazo podatkov. SAP je izdelal nepregledno množico izdelkov, vendar jih lahko v grobem časovno razvrstimo na R/2, prvi izdelek, ki je deloval na velikih računalnikih – mainframe. Konkurenčna prednost so bili že takrat integrirani moduli. Uporabniški vmesnik R/2 spominja na čase operacijskega sistema DOS. Sledila je različica R/3 (od verzije 1.0 do verzije 4.7), ki je uvedla client-server5 OLTP6 okolje. Potem je prišel SAP Enterprise. SAP ERP (ali SAP ECC), ki je nasledil R/3, ima trenutno oznako 7.0. Za uporabnike SAP-a je pomembno, da poznajo termine, kot so: komponenta, modul, transakcija. SAP uporablja izraz komponenta za poslovno aplikacijo. To so moduli, ki se imenujejo po področjih: SD (Sales & Distribution) – prodaja, MM (Material Management) – nabava, WM (Warehouse Management) – skladišče, FI (Finance) – finance, CO (Controlling) – kontroling, PP (Product Planning) – proizvodnja, PS (Project System) – projektni sistem, HR (Human Resources) – kadri, QM (Quality Management) - kakovost idr. Združeni moduli predstavljajo SAP ERP komponento (obstaja več različnih komponent, npr. CRM7, SCM8 itd.). Transakcija pa se nanaša na poslovne procese (ali poslovne scenarije, kot jih tudi imenujejo v SAP-u) na način, da je za uspešno dokončanje nekega delovnega procesa potrebno zaključiti vse transakcije, ki so v tem procesu predvidene (Anderson, 2011). Za lažjo predstavo si lahko pogledamo spodnjo shemo.

5 Odjemalec-strežnik. Po navadi izraz pomeni, da imamo na eni strani enega ali več odjemalcev (klientov), ki pošljejo strežniku zahtevo, da izvrši neko operacijo. V SAP-ovem primeru pa se izraz klient uporablja tudi za samostojno poslovno enoto znotraj sistema. 6 OLTP – ang. Online transaction processing system. Gre za razred programske opreme, ki je sposobna podpirati aplikacije, ki so vezane na transakcije. Uporabnikom nudi takojšen odgovor in lahko obdela večje število transakcij. 7 CRM (ang. Customer Relationship Management) je programska rešitev za upravljanje odnosov s strankami. 8 SCM (ang. Supply Chain Management) je programska rešitev za upravljanje oskrbovalne verige.



SAP ERP

FI modul

PPmodul

MMmodul

...

Na FI modulu se izvede samo ena transakcija

SAP SCM

DPmodul

SNPmodul

Poslovni proces se lahko nadaljuje tudi na module druge aplikacije (SAP SCM)

Shema 2 – SAP pojmi: transakcije (v zelenem) so združene v proces. V modrem so moduli, z rdečo pa so obarvane aplikacije (Anderson, 2011; 10). 3.2.3 IBM Notes Poenostavljeno in v uporabnikom razumljivem jeziku povedano, IBM Notes je Microsoft Outlook, SharePoint, SQL Server, FrontPage in Lync v enem. Omogoča torej uporabo elektronske pošte (uporablja standardne protokole POP3 in SMTP) in koledarja, razvoj aplikacij in spletnih strani ter neposredno komuniciranje. Ima integrirano lastno podatkovno bazo, ki je poleg varnosti in platforme za hiter razvoj aplikacij konkurenčna prednost IBM Notesa. Nekatere lastnosti smo povzeli na sliki 1.

IBM NOTESSTREŽNIK / ODJEMALEC(DOMINO / NOTES)

ŠIROKA PODPORAWindows, Linux, Unix,

OS X, AS/400

VARNOST Neodvisna od OS in AD Možnost urejanja dostopov do

najnižjega nivoja Enkripcija podatkov

PODATKOVNA BAZA ACL (Access control list) omogoča

podrobno določanje dostopa za vsako bazo podakov

Enostavna shranjevanje baze (.nsf) omogoča dostop do podatkov tudi brez internetne povezave.

Dokumentna struktura Dobro podprto indeksiranje

Deluje na različnih platformah Enostavno varnostno kopiranje

(prekopiramo samo Data direktorij) Dobro obvladuje večje količine podatkov Dostop do pošte s pametnih telefonov s

pomočjo IBM Notes travelerja.

RAZVOJ APLIKACIJ

Podpira LotuScript, JavaScript , Java, XML

Web 2.0 templates Podpira Security Assertion

Markup Language (SAML) in Open Standard for Authorization (Oauth)

Slika 1 – IBM Notes (glavne lastnosti)



3.2.4 Microsoft Exchange Microsoft Exchange je programski izdelek, ki deluje na Windows Server platformi, omogoča pa uporabo elektronske pošte, koledarja in kontaktov. Nekatere lastnosti navajamo na spodnji sliki.

VARNOST

Antispam in antivirusna zaščita Enkripcija IRM (Information Rights Management) –

kontrola kopiranja, uporabe print screena, urejanja, tiskanja itd.

DLP (Data Loss Prevention) – pravila za zaščito občutljivih podatkov

Politika arhiviranja Podvajanje podatkovne baze

ADMINISTRACIJA

Možnost pisanja skript Administracija preko spleta Dodeljevanje administrativnih vlog

Enostavno dodajanje arhivske baze (povleci in spusti pst datoteko)

Integracija s SharePointom in Lyncom (uporaba enotnih kontaktov in fotografij)

ŠIROKA PODPORA

Mobilna pošta Outlook Web App (uporabno za

pametne telefone in tablice) Voicemail Možnost razvoja aplikacij

MICROSOFT EXCHANGE

UPORABNIŠKA IZKUŠNJA

Slika 2 – Microsoft Exchange (glavne lastnosti) 3.2.5 SharePoint SharePoint je Microsoftova platforma, ki (od leta 2001) omogoča razvoj aplikacij, sodelovanje, shranjevanje dokumentov, izdelovanje obrazcev, anket, kreiranje spletnih strani itd. Ima uporabno zasnovo za projektno delo. Enostavno kreiramo spletno stran, na katero shranjujemo projektne dokumente, si delimo koledar, naloge, diskutiramo itd. Pri tem lahko uporabnikom dodelimo eno od petih vlog. Našteli jih bomo od tistega z največ do tistega z najmanj pravicami: owner (lastnik), designer (oblikovalec), editor (urednik), contributor (avtor) in reader (bralec). Pravice je možno nastaviti na nivoju celotne zbirke strani ali na posamezni strani, lahko pa imamo tudi znotraj ene strani različne pravice na različnih knjižnicah. SharePoint deluje po principu strežnik-odjemalec. Uporablja bazo podatkov SQL in spletni strežnik IIS. Dobro je združljiv s programi Microsoft Office, pa tudi z Visiom in Projectom. Glede na to, da se po določenemu času uporabe generira nepregledna množica dokumentov in spletnih strani, je razumljivo, da ima SharePoint zmogljiv brskalnik. Posebna značilnost SharePointa je to, da ga je mogoče prilagoditi posebnim zahtevam in delovnim procesom, konkurenčna prednost pa je uporaba v znanem okolju in dobra povezljivost z glavnimi Microsoftovimi izdelki. Trenutno je možno dobiti SharePoint v štirih različicah: Foundation, Standard, Enterprise in SharePoint Online. Foundation je del Windows Serverja, Online je del Office 365 (Office na naročnino), Enterprise pa je namenjen poslovni rabi in omogoča nekaj dodatnih zmogljivosti (poslovno poročanje).



3.3 KOMUNIKACIJSKA OPREMA 3.3.1 IP telefonija in VoIP IP telefonija je pojem, ki združuje tehnologije, ki uporabljajo internetni protokol (IP) za prenos telefonskega pogovora, faksa, SMS-a itd. VoIP (ang. voice over IP) pa je poskus standardizacije IP telefonije. Uporablja protokol RTP (ang. real time protocol) za časovno usklajevanje poslanih podatkovnih paketov. V bistvu gre za združevanje internetne in klasične telefonije. Tehnologija VoIP za delovanje uporablja različne protokole: H.323, Skype, SIP, H.248 itd. Kot prednost uporabe IP telefonije Gartner (Lassman, 2013) navaja komunikacijsko združevanje, centralizirano administracijo, ki lahko vključuje tudi oddaljene lokacije, poslovno celovitost in platformo za nove aplikacije in storitve.

PBX preusmerjanje klicev

SIP požarni zid

Usmerjevalnik

PoE stikalo

WLANWiFi SIPtelefoni

PSTN

Operater

Ethernet, IP Phone VLANSIP telefon

Shema 3 – Prikaz osnovnega sistema VoIP (vir: www.voipsupply.com, dostop 31. 5. 2014)

3.3.2 Microsoft Lync Microsoft Lync je združena komunikacijska platforma, ki omogoča neposredno sporočanje, videokonference (podpira video HD), klice v mobilna in stacionarna omrežja, deljenje datotek, namizja idr. Za podjetja je lahko posebno uporaben imenik, če je nastavljen tako, da vsebuje kontaktne podatke od zaposlenih (iz Active Directoryja), ki jih lahko na zelo enostaven način poiščemo. Je povezljiv s Skypom, torej lahko komuniciramo tudi z uporabniki tega priljubljenega programa. Lync ima poleg namizne še različico v računalniškem oblaku (Lync Online) in na spletu (Lync Web App). Možno ga je uporabljati tudi na drugih operacijskih sistemih in pametnih telefonih (Windows Phone, iPhone, iPad, in Android).



4 INTEGRACIJE INFORMACIJSKEGA SISTEMA PRI PREVZEMIH

Več virov (Mack, 2005; Huges, 2013; Curtis, 2005; Zhao, 2006) priporoča, da je IT vključen v prevzemne aktivnosti vse od začetne faze. Na spodnji shemi je razvidna vloga, ki naj bi jo imel IT po posameznih fazah.

Groba ocena IT stroškov

Podpora pri preračunavanju

Sestanki s kandidatom

Groba analiza razlik obeh IT-jev

Podrobnejša analiza IT-ja tarče

Zbiranje informacij

Podrobna ocena IT stroškov

Priprava podatkov za intervjuje

Plan integracije

Vodenje projekta integracije

Izvedba v predvidenem roku

Poročilo

1. FAZAISKANJE

PRILOŽNOSTI

2. FAZAPRVA OCENA KANDIDATA

3. FAZAPODROBNA

OCENA KANDIDATA

4. FAZASKLENITEV

POSLA

5. FAZAIZVRŠEVANJE PREVZEMA

6. FAZAVREDNOTENJE

Shema 4 – Vloga informacijske tehnologije pri prevzemu (Gartner, 2005) V praksi se pogosto dogaja, da je IT prisoten šele po tretji ali četrti fazi, kar je dodatno tveganje za celoten posel. Obstaja možnost, da bi bil prevzem finančno neuspešen, ker tarča nima urejenih vseh licenc programske opreme ali pa bi infrastrukturne razlike dvignile stroške integracije. Če bi bil IT vključen v pogovore že prej in bi pripravil ustrezno analizo, bi se tem tveganjem lahko izognili.

Graf 5 – Točka vključevanja IT pri integraciji, rezultati raziskave (Accenture, 2005)



Po raziskavah podjetja Accenture iz leta 2005 (Curtis, 2005), ki je zajela 334 podjetij, ki so imela več kot milijardo dolarjev skupnih letnih dohodkov, so tiste organizacije, ki so vključile IT že v začetnih pogovorih, kasneje uspešneje izvedle integracijo. IT je pri prevzemih pomemben, saj igra glavno vlogo pri doseganju učinkov sinergij.

Graf 6 – Kritični faktorji uspeha pri IT integraciji – rezultati raziskave (Accenture,

2005) Menedžerji si po navadi želijo, da se po tem, ko je posel že sklenjen, prevzeto podjetje čim prej integrira. Pri tem je posebna pozornost usmerjena k uvajanju enotnega sistema ERP, saj bo ta poleg enotnega načina poslovnega poročanja posredno vplival tudi na sprejemanje nove organizacijske kulture, glede na to, da posega na vsa pomembna poslovna področja v podjetju. Pomembno je, da ima prevzemnik nadgradljiv informacijski sistem, tako infrastrukturno kot aplikacijski del, in tudi dobro internetno povezavo, ki lahko prenese dodatne obremenitve podatkovnega prenosa.

4.1 STRATEGIJE INTEGRACIJE Literatura omenja tri modele oz. strategije integracije (Mack, 2005; F. Wijnhoven, 2006):

Absorpcija (ang. absorption) ali popolna integracija. Omenjata se tudi izraza takeover9 in rip and replace10. Pri tej integraciji tarča sprejme vse IT procese prevzemnika. IT tarče se ukine.

Samostojna (ang. stand-alone) ali delna integracija – tarča ostane samostojna z nekaterimi skupnimi funkcijami.

9 V prevodu »prevzem«. 10 V dobesednem prevodu »strgaj in zamenjaj«.



Standardizacija (ang. standardization): od obeh IT sistemov vzamemo najboljše, kar postane novi standard združene organizacije.

Koeksistenca (tudi merger of equals) – oba IT-ja ostaneta nespremenjena, razen na področjih, kjer je konsolidacija nujno potrebna.

Pri prevzemih je najbolj pogosta prva, predvsem v primerih, ko ima prevzemnik bolje razvit ali enakovreden IT od tarče (Garcia-Canal, 2013). Ostale so bolj verjetne pri združitvah podjetij. Standardizacija se uporablja, ko sta oba IT-ja edinstvena, vendar komplementarna (Zhao, 2006). Ne glede na to, za katero strategijo se odločimo, je pomembno, da je ta usklajena s poslovno strategijo.

4.2 KULTURNE RAZLIKE 4.2.1 IT vrednote in konflikti Obstaja več kot 160 definicij kulture. Nekateri avtorji pri opisovanju tega pojma poudarjajo pomen norm in praks, pa tudi rituale, mite, ideologijo, jezik in ceremonije, drugi pa govorijo o osnovnih predpostavkah, ključnih vrednotah, pomembnih prepričanjih in kolektivnih željah (Leidner, 2006). Nesoglasja glede definicije in tudi kompleksnost otežujejo znanstveno delo na tem področju. Raziskovalci so ugotovili, da ima lahko specifično področje »IT kulture« tudi vpliv na proces integracije. Pri tem se misli na vrednote, ki si jih skupina informatikov pripisuje. Ugotovili so, da obstajajo trije tipi IT vrednot (Leidner, 2006):

Skupinske vrednote (člani skupine se zavzemajo za tiste vrednote, ki so jim pomembne)

Specifične IT vrednote (vrednote, ki so prevzete v IT delovnem okolju) Splošne vrednote (vrednote, ki jih skupina pripisuje IT področju na splošno)

Seveda je treba upoštevati tudi vpliv nacionalne, lokalne in organizacijske kulture. Temu niso izpostavljeni samo informatiki. Zgodilo se je že, da je npr. prišlo do letalske nesreče zaradi tega, ker člani posadke niso želeli izraziti nestrinjanja ali sporočiti slabe novice pilotu (Helmreich, 1994). V tem primeru je imela širša kultura precejšen vpliv na takšno obnašanje. Pomen kulture je po navadi zapostavljen, vse dokler ne pride do konflikta. »Ljudje se večinoma kulture ne zavedajo, vse dokler ne pridejo v stik z nasprotno kulturo« (Leidner, 2006; 373).



NIŽJINIVO

IT VREDNOTE

SKUPINSKE VREDNOTE

SPECIFIČNE IT VREDNOTE

NACIONALNI NIVO

ORGANIZACIJSKI NIVO

Konflikt pri sodelovanju

Sistemski konflikt

Konflikt vizije(različni pogledi)

Shema 5 - Tristranski pogled na IT kulturni konflikt (Leidner, 2006; 374)

Konflikti se lahko pojavijo pri interakciji treh definiranih IT vrednot na katerem koli nivoju. Prvi, sistemski konflikt se pojavi, če so specifične IT vrednote v nasprotju z vrednotami uporabnikov sistema. Avtorji so ga poimenovali sistemski (ang. system conflict), ker je sistem povod za ta konflikt. Drugi, konflikt pri sodelovanju, se pojavi zaradi razlike med skupinskimi in IT vrednotami. Avtorji so ga poimenovali konflikt sodelovanja (ang. contribution conflict), ker je osrednja tema tega konflikta percepcija o tem, kako pomemben je IT za dopolnjevanje skupinskih vrednot. Pogosto se pojavlja v organizacijah, kjer na IT gledajo zgolj kot na strošek, ki ga je treba zmanjševati, da bi ostalo več sredstev za razvoj osnovne dejavnosti, ki prinaša realne dohodke, merljive v številkah. Tretji konflikt poimenovan konflikt vizije (ang. vision conflict) se pojavlja zaradi razlik med IT vrednotami in sistemskimi vrednotami. Skupina uporabnikov mora tehtati med vrednotami, ki jih uvaja določen informacijski sistem sam po sebi (IT ga le vzpostavi), in IT vrednotami. Primer je recimo sistem ERP, ki ga povezujejo z avtoriteto in kontrolo. IT ga uvaja, vendar uporabniki lahko IT oddelek povezujejo z neodvisnostjo. Drugi primer je uvajanje informacijske tehnologije, ki promovira učinkovitost za skupino uporabnikov, ki na IT gledajo kot na nepotreben strošek (Leidner, 2006). Kulturni IT konflikt s perspektive integracije informacijskega sistema po združitvi dveh bank je na študiji primera obravnaval Chao (2009). Na primeru združitve zasebne banke, ki je prevzela državno banko na Tajvanu, je ugotovil, da je med enim in drugim IT-jem prišlo do naslednjih razlik, ki so sprožali IT kulturne konflikte po Leidnerju:

Različna infrastrukturna platforma (zasebna banka je uporabljala AS/40011, državna banka IBM mainframe12; prva se je tako odločila zaradi cene, druga zaradi zanesljivosti).

11 Strežnik proizvajalca IBM (predstavljen l. 1988), namenjen srednjim in večjim podjetjem z lastnim operacijskim sistemom (OS/400) in bazo podatkov (IBM DB2). Še vedno se prodaja pod imenom IBM i (i je oznaka za integracijo). Leta 2008 je spremenil operacijsko platformo, ki sedaj podpira Unix (AIX) in Linux.



Različni IT procesi in vodenje (za zasebno banko je bila značilna fleksibilnost, za državno hierarhija in formalnost).

Različne strokovna usposobljenost (strojna oprema državne banke je terjala več strokovne usposobljenosti in znanja).

Različna kultura opravljanja nalog (IT zasebne banke je bil bolj vpet v poslovne procese, IT državne banke pa bolj osredotočen na tehnologijo kot na procese; zaposleni v zasebni banki so bili bolj inovativni, v državni banki pa so bolj sledili pravilom).

V opisanem primeru je šlo v strateškem smislu za kombinacijo polne integracije (»mainframe je preživel«) in standardizacije. IT zasebne banke je bil zadolžen za integracijo procesov, medtem ko je IT državne banke skrbel za integracijo sistema. Konflikte, ki so se pojavljali zaradi naštetih razlik, so reševali na naslednje načine:

z izobraževanjem, s spreminjanjem skupnih vrednot, s promoviranjem novih skupnih vrednot.

4.3 UPORABNIŠKI VIDIK 4.3.1 Podpora Področje podpore gre v smeri avtomatizacije, izobraževanja uporabnikov (da si lahko pomagajo sami) in večjega prilagajanja poslovnim potrebam (Greene, 2012). Z računalništvom v oblaku izginja tradicionalni način podpore, saj je ta deležna ostrih kritik, da je »draga, neučinkovita in poslovno nepomembna« (Greene, 2012; 2). IT procesi so pred izzivi. Z današnje perspektive (2014) se zdi, da je Gartnerjeva napoved izpred dveh let dobro zastavljena:

Podpora uporabnikom

2012 Podpora uporabnikom

2017

Odgovornosti Določanje prioritet, iskanje in odstranjevanje težav, eskalacija

Izolacija incidentov na nivo komponente

Delovno okolje Večino delovnega časa v pisarni Mobilno – del časa v pisarni, del

na terenu

Kriterij uspešnosti

Rešitev ob prvem kontaktu, manj govorjenja

Omogočena produktivnost uporabnikov, zadovoljstvo strank, zaključene naloge in delo v skupnosti

Izobraževanje in urjenje Znanje in izkušnje s področja reševanja težav

Strokovni certifikati, ITIL foundation in/ali obsežen proces urjenja

Znanje in strokovne Tehnične veščine, pisna in Razumevanje ključnih

12 Letos je ta arhitektura proizvajalca IBM (International Business Machines) praznovala 50 let obstoja. Skozi čas je spreminjal imena (najprej IBM System/360). Danes je znan kot zEnterprise Mainframe System. Namenjen je državnim ustanovam in večjim organizacijam.



veščine ustna komunikacija prek e-pošte in spletnih klepetalnic

poslovnih procesov, poznavanje področja, mehke veščine, pisna komunikacija prek socialnih medijev

Način delovanja

Usmerjenost na problem, večopravilnost, reševanje težav, upravljanje časa, zunanja motivacija

Sposobnost prepoznavanja vzorcev in rešitev, pripravljenost na sodelovanje, notranja motivacija, vedno v iskanju priložnosti za izboljšanje produktivnosti uporabnikov

Orodja

Računalnik, IP telefon, programska oprema za podporo uporabnikom, tehnično usmerjena baza znanja

Mobilne naprave, programska oprema za podporo na daljavo, orodja za upravljanje s klienti, baza znanja, usmerjena na uporabnike

Tabela 1 – Razlike med podporo uporabnikom danes in v prihodnosti (Gartner, 2012) To temo omenjamo zato, ker bodo uporabniki v Turboinštitutu z integracijo deležni nekaterih sprememb v skladu s smernicami, ki jih je predvidel Gartner in jih Skupina Kolektor izvaja tudi v praksi. 4.3.2 Premagovanje odpora Odpor do sprememb med uporabniki je praviloma večji, če gre za projekte, ki posegajo na različna področja poslovanja. Pomembno je opraviti analizo (ugotoviti razlike med oblikami in vzroki za nastanek odpora), na osnovi česar se planira strategija ravnanja z odporom, ki je prilagojena posameznemu primeru. Navajamo primere strategij: motivacija uporabnikov, podpora spremembi z zgledom, vključevanje uporabnikov, odprava komunikacijskih ovir, usklajevanje vrednot, evolucija uporabnikov, ustvarjanje spremembi ugodnega okolja in vključitev zunanjih sodelavcev (S. Vrhovec, 2011).

Ponovitev postopka od A do E, če je potrebno

Določitev spremembe

Ocenjevanje rezultatov strategije

Določitev vzrokov za odpor Razvoj strategije

Implementacija strategije

A B C

DEF

Shema 6 – Model premagovanja odpora (Hultman, 2003; 699) V Turboinštitutu pri integraciji informacijskega sistema in tudi pri projektu uvajanja sistema SAP ni bilo zaznati večjih težav z odporom uporabnikov, kot se to dogaja pri takšnih projektih. Od devetih udeležencev izobraževanja smo odklonilen odnos zaradi preobremenjenosti zaznali pri dveh. Pri pripravi projekta zamenjave programa za CAD je prišlo tudi do nasprotnih mnenj glede smiselnosti projekta. Standard v Skupini Kolektor je uporaba programske opreme Creo. Glede na to, da inženirji v Turboinštitutu že vrsto let



uporabljajo Autodeskovo programsko opremo za računalniško podprto načrtovanje, so se pojavili določeni zadržki z utemeljitvijo, da je Creo uporabniku manj prijazen in ne omogoča vseh funkcionalnosti. Nekaj slabe volje je bilo prisotne pri posameznikih, ko so jih ključni uporabniki proizvodnega modula SAP seznanili z novim načinom dela in vnašanjem kosovnic v sistem. Omenjeni dogodki niso razvili problemskega stanja do te mere, da bi bilo treba razvijati posebno strategijo. Pri menjavi programske opreme CAD se je vodstvo odločilo za potrpežljiv pristop in več komunikacije. Kljub temu je treba poudariti, da gre za oceno v času, ko integracija še ni zaključena. Povečano tveganje za odpor uporabnikov se bo po našem mnenju pojavilo potem, ko bo IS v celoti integriran, vključno z novim sistemom ERP.



4.4 OCENJEVANJE USPEŠNOSTI Obstaja zelo malo znanstvene literature, ki bi ponudila teoretično dobro utemeljene kriterije za ocenjevanje uspešnosti integracije po prevzemu podjetja (Alaranta, 2005). Kot ocenjuje avtorica, je to predvsem zaradi kompleksnosti teme, pa tudi dejstva »da ni sprejemljivega in merljivega načina, da kvantitativno in objektivno ocenimo uspeh informacijskega sistema« (Saarinen, 1996; 116). Menedžerji bi se verjetno strinjali, da je hitrost integracije pomembna pri ocenjevanju uspešnosti integracije. Hitrost integracije se nanaša na čas, ki je potreben za integracijo sistemov, struktur, aktivnosti in procesov združenih podjetij (Homburg, 2006). Pričakuje se hitra integracija, vendar to ni vedno enostavno doseči, kajti razmerje med ciljem prevzema in strategijo integracije je bolj kompleksno, kot je videti (F. Wijnhoven, 2006), poleg tega pa lahko hitrost integracije zmanjšajo kulturni konflikti (Chao, 2009). Študija integracije španskih bank (Garcia-Canal, 2013) potrjuje, da je s stališča hitrosti integracije najprimernejša strategija absorpcija ali standardizacija. V primerih, ko prevzeto podjetje nima svojega IT sistema, je integracija še hitrejša. Predhodne izkušnje lahko pozitivno vplivajo na hitrost integracije. V primerih, ko je prevzeto podjetje večje in ima dobro razvit IT sistem, pa to hitrost zmanjšuje (Garcia-Canal, 2013). Hitrost integracije pa je kljub vsemu relativen pojem. Treba je všteti vse okoliščine. Imamo primere, ko je normalni čas za hitro izvedbo 3 mesece, pri drugih pa je uspeh že, če je izvedena v roku koledarskega leta. Raziskovalci so postavili nekaj kriterijev, ki definirajo uspešnost integracije po prevzemu. Izpostavili bi naslednje (Stylianou, 1996):

Sposobnost koriščenja priložnosti, ki jih ponuja prevzem Sposobnost izogibanja problemov, ki se pojavijo Zadovoljstvo uporabnikov z novim sistemom in procesom integracije Izboljšanje sposobnosti informacijskega sistema, kar prispeva k doseganju

ciljev, zaradi katerih je bil posel sklenjen Učinkovitost in zmogljivost koriščenja resursov v času integracije

K temu bi morda lahko dodali:

Redno obveščanje uporabnikov o poteku integracije Obvladovanje stroškov integracije v mejah zastavljenega proračuna



5 ANALIZA OBSTOJEČEGA STANJA

5.1 IT PODJETJA TURBOINŠTITUT Stanje informacijske tehnologije v podjetju pred prevzemom: lokalno omrežje (optika, infinibend13, UTP), optična povezava z internetom, IP telefonija (Avaya), razvejana strežniška infrastruktura na operacijskem sistemu Linux in superračunalnik LSC Adria z 2048 procesorskimi jedri (512 štirijedrnih procesorjev), skupno 4,1 TB pomnilnika (RAM-a) in 22 TB diskovnega polja.

Slika 3 – Superračunalnik (levo), slika toka v Francisovi turbini (desno) Na najzmogljivejši infrastrukturi se izvajajo numerične metode za simulacije toka pri vodnih, parnih in vetrnih turbinah, črpalkah, ventilatorjih, kompresorjih itd. Zahtevnejši uporabniki imajo na razpolago grafične postaje in thin cliente14, ki so povezani na IBM BladeCenter H. Ključna programska oprema je zajemala: ERP Gosoft, IBM Notes, Time&Space, sistem za videonadzor, Autocad, Inventor, Mathlab, ThinkDesign, ANSYS, Numeca, CFX, WSCAD, MS Office, Open/Libre office itd. Vse strežnike vključno s superračunalniškim centrom je poganjal Linux CentOS. Izjema sta dva licenčna strežnika in strežnik za kontrolo dostopa. Uporabniki so imeli administratorske pravice, s tem da so morali podpisati politiko, ki je predpisovala namestitve izključno licenčne programske opreme. IT je dnevno spremljal namestitve programske opreme na računalnikih s pomočjo programa Lansweeper. Oddelek informatike sta ob prevzemu sestavljala dva zaposlena (vodja informatike in podpora uporabnikom). V času pred prevzemom ga je zapustil sistemski administrator. Informatika je bila organizirana kot del poslovnih dejavnosti, kar pomeni, da vodja informatike ni neposredno sodeloval na sestankih z upravo. Vodstvo se je glede

13 Infiniband je komunikacijska povezava, ki omogoča hiter in zanesljiv prenos podatkov med različnimi elementi strojne opreme. Uporablja se v zmogljivih podatkovnih centrih. 14 Najpogosteje gre za terminal – del strojne opreme, ki omogoča predvajanje grafike iz oddaljenega sistema. Uporabnik v našem primeru prek terminala uporablja strežniško rezino, ki je v podatkovnem centru. Prednosti: manj hrupa pri uporabniku (ni brnenja ventilatorja), večja varnost opreme, lažja administracija.



nekaterih IT strategij in infrastrukturnih investicij odločalo samostojno, kar je imelo škodljive posledice, ki so vplivale tudi na slabše poslovne rezultate podjetja.

5.2 IT SKUPINE KOLEKTOR Skupina Kolektor ima eno centralno vodeno službo informatike, ki nudi storitve podjetjem na 17 lokacijah v šestih različnih državah. Stroške si potem podjetja med seboj razdelijo. Vodja informatike je članica uprave, tako da ima besedo pri pomembnih odločitvah na svojem področju. Kako velik je sistem, ki ga upravlja, govori tudi citat ge. Maje Leban, vodje IT sektorja Skupine Kolektor: »Imamo 560 uporabnikov poslovnega sistem SAP, več kot 100 uporabnikov aplikacij CAD in le nekaj manj kot 2000 uporabnikov vseh naših storitev. Programska oprema teče na 280 strežnikih. V celotnem koncernu je več kot 1200 osebnih računalnikov in grafičnih postaj ter le malo manj kot 500 prenosnih računalnikov« (Rupnik, 2013). IT oddelek sestavlja petnajst zaposlenih. V letu 2009 so izvedli prenovo upravljanja infrastrukture. Strojna in programska oprema je standardizirana (PTC za tehnično programsko opremo, SAP-ov ERP in Microsoft za strežniško okolje in pisarniške programe). Podjetja nabavljajo računalniško opremo po internem katalogu. Tudi nabava programske opreme gre prek IT oddelka. Uporabniki, ki so na različnih kontinentih sveta, so večinoma v domeni in razen nekaterih izjem nimajo administratorskih pravic. Strežniki so virtualizirani (Virtual Machine Manager), na lokacijah imajo po navadi datotečni strežnik (po potrebi SAN) in strežnik za prijavo v domeno (domain controller), Standard Distribution Point za razdeljevanje popravkov ter požarni zid, print server in morda še kakšen poseben virtualni strežnik.

Slika 4 – IT Kolektorja uporablja družino izdelkov Microsoft System Center (vir: www.agileit.com, dostop 20. 4. 2014).



6 OPIS PROJEKTA INTEGRACIJE

6.1 STRATEGIJA IN CILJI IT Kolektorja opravi eno ali dve integraciji letno. Uporabljajo standardiziran način integracije. Odvisno od potreb podjetja ponujajo dve možnosti (Berglez, 2014), in sicer:

End to end solution (E2ES), ki bi jo lahko prevedli tudi kot rešitev na ključ. Gre za zagotovitev vseh potreb podjetja, od programske in strojne opreme do vzdrževanja in varnosti.

Cloud based solution, kar bi lahko dobesedno prevedli kot rešitev v oblaku, in sicer na tri načine:

• SAAS – Software as a Service (uporaba programske opreme v oblaku) • IAAS – Infrastructure as Service (najem strojne opreme) • PAAS – Platform as a Service (uporabnik upravlja s programsko

opremo, za vse ostalo poskrbi ponudnik) Pri cloud based rešitvi lahko podjetje samo skrbi za infrastrukturo, do storitev Skupine Kolektor pa dostopajo prek portalov. V primeru Turboinštituta je izvedena popolna integracija (End to end solution). Pri strojni opremi, če je le možno, izberejo takšno, ki je standardizirana in jo uporabljajo na različnih lokacijah. To je običaj tudi pri drugih izkušenih akviziterjih (Crosman, 2011), saj je tako manj težav z nastavitvami in vzdrževanjem. V obravnavanem primeru je prav tako izveden nakup novih strežnikov, stikal in sistema SAN za omrežno hranjenje podatkov, čeprav je obstajala sicer amortizirana, vendar nerabljena oprema na lokaciji. Ko bo integracija zaključena, bo IT Kolektorja prevzel nadzor nad celotno infrastrukturo ter skrbel za vzdrževanje, nadgradnje, varnost informacijskega sistema, podporo uporabnikov, varnostno kopiranje itd. Uporabniki bodo dobili enotno izkušnjo uporabe opreme, kot jo imajo v drugih podjetjih koncerna (uporaba storitev Exchange, Lync, SharePoint, SAP itd.). Držati se bodo morali nove varnostne politike (redno spreminjanje gesel, posodobitve, pravila IPSec15 na delovnih postajah, selektivni dostop do interneta itd.), Turboinštitut pa bo vključen v Microsoft Enterprise Agreement (Berglez, IT integracija Turboinštitut, 2014). Delovne postaje in strežniki bodo dobili nov naslovni prostor. Stari strežniki bodo migrirani (IBM Notes na Exchange, ERP GoSoft bo do izvedbe vseh modulov SAP-a deloval na novi Windows platformi, licenčni strežniki bodo tudi dobili novo virtualno Windows okolje, program za kontrolo dostopa (Špica) bo centraliziran naknadno, prav tako tiskalniške rešitve).

15 IPSec – ang. Internet Protocol Security. Protokol, ki omogoča šifriranje podatkov.



TI FW, pfSense

HP ProLiant DL145

NS1, mailserver

HP ProLiant DL145

postfix, named

WWW

HP ProLiant DL145

CentOS 5.10

httpd, named (dns2)

WAN

IBM DS4700

SCG FW

HP ProLiant DL145

Komrac (ERP)

Supermicro

CentOS

Samba, gosoft

Domino

HP BL20p G3

CentOS

Fileserver

HP BL20p G3

CentOS

samba

Intranet portal

HP ProLiant DL145

CentOS

httpd, dhcp (telefonija)Avaya – PBX + SIP

Špica

HP ProLiant DL360 G3

Windows XP

Grafična postaja

Lenovo ThinkStation D20

Windows XP x64

HP LaserJet 5100N

Kyocera KM-4850w

HP LaserJet 5200Kyocera FS-C5020N

Konica Minolta bizhub c203 Image scanner IS300e

Licence, ESET, Lansweeper

HP dx2200 MT

Windows XP

Licenčni WSCAD

HP rp5000

Windows XP Embedded

IBM BladeCenter H

14 HC10 rezin

Windows XP x64

IBM BladeCenter H

14 HC10 rezin

Windows XP x64

Telemach (optika)

100/30 MB/s

Axis 207W

LSC storage

IBM DS4700

Grafična

Lenovo TS D10

CentOS

samba

LSC Adria

Slika 5 – Strežniki v Turboinštitutu pred integracijo Strežniki, ki so na sliki 5 označeni z rdečo barvo, se ukinjajo. Strežniki, označeni z zeleno barvo, nadaljujejo delo, vendar na drugi (Windows), virtualni platformi, z izjemo požarnega zida, ki bo integrirana varnostna rešitev.

6.2 TVEGANJA ZA KULTURNI KONFLIKT V obravnavanem primeru smo lahko med obema IT-jema zaznali naslednje razlike:

IT Turboinštituta (tarča)

IT Kolektorja (prevzemnik)

Okolje manj dinamično zelo dinamično

Strežniška platforma Linux Windows

Strokovna usposobljenost splošni pristop specialistični pristop

Vodenje IT ni del uprave IT del uprave

Vpetost v poslovne procese srednja večja

Tabela 2 – Razlike med IT-jem tarče in prevzemnika Kljub navedenim razlikam ni prišlo do IT kulturnih konfliktov. Kot glavne razloge bi lahko omenili strategijo integracije, hitro implementacijo in tudi dobre odnose med zaposlenimi v obeh IT oddelkih.



6.3 PROJEKTNE AKTIVNOSTI Projekt integracije je vključeval kar nekaj nalog:

Zbrati podatke o infrastrukturi in programski opremi. Pripraviti stroškovno oceno integracije. Sprejeti odločitev glede uporabe strojne opreme. Pripraviti mrežni plan, strežnike in požarni zid. Izvesti testiranje programske opreme. Postaviti storitve Microsoft System Center. Pripraviti načrt uvedbe SAP. Izvesti izobraževanja za ključne uporabnike SAP. Pregledati aplikacije IBM Notes in sprejeti odločitev o tem, kaj se migrira. Predstaviti SharePoint uporabnikom Turboinštituta. Preizkusiti delovanje Lotus Notes migratorja (Quest Software). Preizkusiti delovanje programske opreme na novi platformi. Migrirati IBM Notes aplikacije. Izobraževati uporabnike novih aplikacij na SharePointu. Pripraviti tiskalniški strežnik (print server). Postopoma migrirati delovne postaje. Izobraževanje uporabnikov za delo na novem sistemu. Pripraviti podatke za prenos iz GoSoft v SAP. Organizirati podporo uporabnikom ob zagonu SAP-a. Migrirati strežnike iz obstoječe infrastrukture. Poskrbeti za varnostne nastavitve. Pripraviti obvestila za uporabnike. Predstaviti nov način dela podpore uporabnikov. Zaključna dela.

6.4 TEŽAVE Za kritično točko integracije so izvajalci določili migracijo aplikacij IBM Notes. Tiste, ki niso bile nujne za preoblikovane delovne procese, so ukinjene, podatki pa arhivirani. Za ostale pa je bodisi obstajala alternativa na SharePoint portalu Kolektor Groupa bodisi jih je razvijalec razvil na novo. Čeprav je integracijo sestavljalo nekaj tehnično zahtevnih postopkov, je potekala brez večjih problemov in izpada delovnega procesa. Nekaj težav je bilo pri prejemanju elektronske pošte in namestitvah operacijskega Windows 7 Enterprise zaradi tega, ker strojna oprema ni bila ustrezno podprta. Nekatere računalnike je bilo treba nadgraditi z dodatnim pomnilnikom. Pojavile so se tudi bojazni posameznih uporabnikov zaradi nove politike. Poudarjali so, da bodo imeli brez administratorskih pravic na terenu (pogosto na nedostopnih krajih brez internetnega dostopa) znatno omejene možnosti za reševanje težav. Problem odvzema administratorskih pravic je bil posebno poudarjen pri operaterjih v laboratoriju in uporabnikih, ki se ukvarjajo s krmiljenjem, regulacijo in avtomatizacijo. Treba je poudariti, da je bilo okolje v Turboinštitutu akademsko. Prejšnje vodstvo ob podpori direktorjev programov ni bilo naklonjeno pretiranim omejitvam uporabnikov.



6.5 UPORABNIŠKA IZKUŠNJA Uporabniki obravnavanega prevzetega podjetja so bili po prevzemu vključeni v različne izobraževalne aktivnosti, s pomočjo katerih so se seznanili z načinom dela, vrednotami in cilji novega lastnika. K temu so pripomogla tudi srečanja s zaposlenimi iz drugih podjetij, ki so prav tako del Skupine Kolektor. Pomemben korak v to smer pa je vsekakor tudi izkušnja z novim informacijskim sistemom. Uporabniki bodo med integracijo prejeli računalnik z na novo nameščenim operacijskim sistemom, ki bo del domenskega okolja. To pomeni, da bodo z novim uporabniškim računom lahko dostopali do vseh IT storitev. Namesto poštnega odjemalca IBM Notes bodo sedaj uporabljali Microsoft Exchange. Poštni predal bo dostopen tudi prek spleta in mobilnih naprav. Še vedno bodo lahko dostopali do službenega omrežja tudi preko spleta, veljala bo nova uporabniška politika, ki jim bo onemogočala nemoteno brskanje po internetu in nameščanje programske opreme, če ta ne bo odobrena s strani odgovorne osebe. Potrebo po programski opremi bodo oddali prek spletnega portala, ki je namenjen podpori uporabnikom. Ko bo zahtevek odobren, bodo o tem obveščeni po elektronski pošti. Program si bodo nato lahko namestili sami prek centralnega sistema za nameščanje programske opreme. Sami si bodo lahko nameščali tudi tiskalnike prek za to namenjenega strežnika. Naučiti se bodo morali novega načina dela, ki bo terjal več lastne udeležbe in manj obremenjevanja IT oddelka z vsako podrobnostjo. Manj zahtevne naloge bodo lahko uporabniki opravljali samostojno, npr. dodeljevanje pravic do skupnih omrežnih pogonov, odklepanje računa na sistemu ERP, restavriranje podatkov, dodeljevanje dostopnih podatkov do brezžičnega omrežja za goste itd. Ko pa se bo nepremostljiv problem le pojavil, ga bodo prijavili prek portala za podporo in prijavo napak. Prijava bo sicer možna tudi s telefonom, vendar le izjemoma v primeru, da je narava problema takšna, da ne omogoča oddajanje zahtevka prek portala. Tam so tudi navodila o tem, kako si lahko pomagajo sami.



7 PRENOVA PROIZVODNEGA INFORMACIJSKEGA SISTEMA

7.1 UVOD Prednosti uvedbe celovite programske rešitve SAP:

Omogoča big picture, celovit pogled na poslovanje vseh poslovnih enot Analize in poročila v realnem času Uveljavljanje procesov, ki so vodilni v industriji Zagotovljen razvoj (stabilnost razvijalca programske opreme) Vpliva na produktivnost in učinkovitost Zmanjšuje stroške dela, materiala in storitev (Anderson, 2011) Zviša nivo upravljanja, dostavljanja, optimiziranja, sledenja in izboljšanja

izdelkov in storitev podjetja (Anderson, 2011) Glede na naše izkušnje bi lahko k temu dodali še:

Pozitivno vpliva na organizacijsko kulturo in odnos do dela Zaposlenim ponuja priložnost, da osvojijo nova znanja

Tveganja pri uvedbi:

Podpora vodstva na vseh nivojih Svetovalci vzamejo s seboj znanje o nastavitvah sistema (Fidler, 2008) Izgubljanje celotne slike zaradi reševanja manj pomembnih podrobnosti

Glede na naše izkušnje bi lahko k temu dodali še:

Odpor uporabnikov do sprememb lahko zmanjša transfer znanja Visok finančni vložek glede na donosnost podjetja Potrebno je podrobno poznavanje procesov in poslovanja Usklajevanje rednih delovnih obveznosti in projekta uvajanja SAP-a

Slovenska raziskava iz leta 2007, ki je zajela 152 velikih in srednjih podjetij (Kovačič A.), je pokazala, da je 9 % teh podjetij prilagajalo sisteme ERP svojemu poslovanju, 10 % jih je delalo obratno, 40 % jih je delalo oboje in 41 % nič od tega. Tudi v našem primeru se bodo procesi večinoma prilagodili obstoječi programski rešitvi, ki je v uporabi znotraj Skupine Kolektor, in v prvi fazi ni predviden dodatni razvoj. Do sedaj so ključni uporabniki FI in SD modula zaznali potrebo po dodatnem razvoju pri poročanju Banki Slovenije za potrebe statistike in pri pisanju akreditivov v dokumentaciji za odpremo. Na področju proizvodnje pa vidijo potrebo po lažjem vnašanju ur in način prikaza plana dela po strojih v proizvodnji. Pri projektnem sistemu bi bilo uporabno, če bi imeli možnost nekam na strukturo WBS (morda v PPS element glave projekta) dodati skenirano pogodbo in tekst z osnovnimi podatki o projektu. To je bilo do sedaj možno prek aplikacije IBM Notes za odpiranje delovnih nalogov.



7.1.1 Predstavitev modulov SAP ECC 6.0

FI

CO

AM

PS

MM

PP

SD

QM

PM

HR

SLCM

FI - Finance Glavna knjiga Obveznosti Terjatve Upravljanje sredstev

CO - Kontroling Računovodstvo po centrih Priprava proračuna Upravljanje kapitala

AM – Upravljanje nepremičnin

PS – Projektni sistem Strukturiranje in načrtovaje projektov Planiranje kapacitet in delovne sile Materialno planiranje in kooperacija Upravljanje s proračunom

SLCM – Študentski modul Storitve namenjene študentom Študentsko računovodstvo Ocenjevanje in svetovanje Informacijski management Univerzitetna struktura Napredovanje

HR – Kadrovska funkcija Organizacijski vidik Novačenje kadrov Plače

PM – Vzdrževanje Planiranje vzdrževanja Izvedba vzdrževanja

QM – Kvaliteta Certifikati kakovosti QM informacijski sistem

SD – Prodaja Prodajni inf. sistem Administracija naročil Cene in davki Upravljanje posojil Promet s tujino Izstavljanje računov

PP – Proizvodnja Upravljanje s spremebami Planiranje operacij Planiranje potreb po materialih Proizvodni procesi

MM – Nabava Preskrbovanje Upravljanje z zalogami Kupovanje

LOGISTIKA

Shema 7 – Moduli SAP ECC 6.0 (vir: http://www.g-business.co.th) SAP sestavljajo moduli, ki jih uporabljamo glede na potrebe organizacije. V obravnavanem primeru bodo uvedeni moduli, ki zajemajo: prodajo (SD – sales & distrubution), skladiščno poslovanje (WM – warehouse management), finance, kontroling, projektni sistem, proizvodnjo (z glavnimi podatki o materialu).

7.2 ORGANIZACIJSKA STRUKTURA V SAP-U

ŠIFRA PODJETJA

OBRAT – POSEBNI

PC UPRAVA

PC PROIZVODNJA

PC TURBINE

PC PUMPE

PC HYDRO

PC MODELI

OBRAT – PROJEKT

OBRAT - SPLOŠNI

Shema 8 – Organizacijska struktura Turboinštituta v SAP-u



Profitni centri (PC) so računovodske organizacijske enote, ki odražajo vodstveno strukturo organizacije za potrebe kontrolinga. PC so časovno opredeljeni, kar pomeni, da med glavnimi podatki nastavimo njihovo časovno veljavnost, npr. ob menjavi finančnega leta ali ob menjavi odgovorne osebe (SAP Library, 2014). S pomočjo profitnih centrov bomo lahko v SAP-u analizirali stroške in dohodke po posameznih programih podjetja: proizvodnja, turbine, črpalke, hydro in modeli. Če se spremenijo podatki na enem profitnem centru, se spremenijo tudi na nivoju obrata in podjetja. Hierarhično nadrejen enoti, ki se nanaša na podjetje, je lahko še ena enota kontrolinga, ki lahko združuje več podjetij iz istega sektorja. Nad to enoto pa je potem klient, kot mu pravijo v SAP-u, torej v našem primeru Kolektor Group. Vse entitete iz sheme 8 imajo v SAP-u svojo šifro.

7.3 PRIPOROČENA METODOLOGIJA SAP je razvil posebno metodologijo uvajanja. Imenuje se ASAP (Accelerated SAP). Projekt uvajanja so razdelili na 6 faz (Anderson, 2011):

PRIPRAVAPOSLOVNI NAČRT

(BLUEPRINT)IZVEDBA

ZAKLJUČNEPRIPRAVE

ZAGONIN PODPORA

UPORABA(RUN SAP)

1 2 3 4 5 6

Shema 9 – Faze uvajanja po priporočilih SAP-a V fazi priprave se določi vodstvo projektnega tima in prične zbiranje in upravljanje orodij in sredstev, ki so potrebni za izvedbo. V tej fazi je pomembno naslednje:

Zagotoviti podporo lastnikov in menedžmenta Jasno določiti projektne cilje Razviti učinkovit sistem odločanja Ustvariti takšno delovno okolje, ki je ugodno za spremembe Sestaviti kvalificiran in sposoben projektni tim

Namen druge faze (blueprint) je pridobiti koristne informacije o organizaciji, ki uvaja SAP, in obstoječe poslovne procese prilagoditi novim. Podatki se zbirajo s pomočjo vprašalnikov oz. vnaprej pripravljenih predlog (ang. templates). Vprašanja se nanašajo na različne poslovne funkcije (npr. kateri podatki so potrebni za finančno poročilo ali zahtevek za nabavo). Faza izvedbe je časovno najbolj potratna. Ko je zbiranje informacij končano, se začne priprava prototipa in nastavitev v SAP-u. Približno 80 % nastavitev je možno nastaviti že prej, preostalih 20 % kasneje, ker gre za podrobnejše nastavitve. Ob prehodu na četrto fazo se funkcionalni, integracijski in stres testi že približujejo h koncu. V četrti fazi se izvajajo podrobnejše nastavitve in zadnji prenosi podatkov iz starega sistema v SAP. Zaključijo se vsa testiranja. Projektna skupina se znajde pod precejšnjim pritiskom, ko ugotavlja, kaj vse ne deluje, kot bi moralo, in kateri podatki manjkajo. Ni časa za ukvarjanje s podrobnostmi. Treba je



zagotoviti, da bo nov sistem po zagonu omogočal normalno poslovanje. Priporočljivo je, da si vzamemo dovolj časa za strategijo zagona. Poleg rednih IT operacij pri vzdrževanju je treba zagotoviti tudi ekipo, ki bo skrbela za podporo uporabnikom ob zagonu. Peta faza (zagon) je videti enostavno, vendar pomeni, da bodo uporabniki z vnaprej določenim dnem začeli uporabljati nov sistem in nič več starega. Za uspešno izvedbo te faze so pomembne priprave, vključno z različnimi scenariji, ki ne zajemajo samo poslovnih procesov, pač pa tudi infrastrukturo, ki bo vse skupaj poganjala. Ne smemo pozabiti tudi na pogodbo SLA (ang. Service Level Agreement), ki določa pogoje vzdrževanja. Prav tako je uporabnikom treba zagotoviti tudi ustrezno podporo. Cilj zadnje faze (Run SAP) je zagotoviti operativnost in izvedbo sistema tudi v bodoče. Zajema področje sistemske administracije, nadzor obremenjenosti sistema, odpravljanje napak itd.

7.4 OBSTOJEČE STANJE Turboinštitut proizvaja turbine in gonilnike za male in srednje hidroelektrarne. Gre za projektno in ne serijsko proizvodnjo.

GENERALNI DIREKTOR

TEH

NO

LOG

DIREKTORPROIZVODNJE

POSLOVNASEKRETARKA

VODJATEHNOLOGIJE

VODJADELAVNIC

VODJA SPEC.DELAVNICE

VODJA STROJNEOBDELAVE

VODJAMONTAŽE

MIZ

AR

TEH

NO

LOG

CN

C

OBL

IKO

VALE

C KO

VIN

PESK

AR

VAR

ILEC

VIL

IČA

RIST

VAR

ILEC

SPE

CIAL

IST

BRU

SILE

C R

OČN

I

TEH

NO

LOG

CN

C

(REZ

KAN

JE)

OBL

IKO

VALE

C KO

VIN

STR

OJN

I VZD

RŽE

VA

LEC

MO

NTE

R

PLES

KAR

SKLA

DIŠ

ČNIK

SKLA

DIŠ

ČNIK

(DI)

SPLO

ŠNI V

ZDRŽ

EVAL

EC

Shema 10 – Organigram proizvodnje v Turboinštitutu pred uvedbo SAP-a Ključne aktivnosti v proizvodnji pred uvedbo SAP-a so bile:

Projektno planiranje in preskrba virov Preliminarno naročanje kritičnih materialov Tehnološka obdelava konstrukcijske dokumentacije Naročanje potrebnih materialov Lansiranje proizvodne dokumentacije in operativno planiranje Izdelava in montaža Kontrola in izvedba funkcijskih preizkusov Skladiščenje Priprava orodij in pripomočkov Proizvodno vzdrževanje



Notranji transport Embaliranje in odprema Administracija

Ponudba je bila izračunana glede na specifične zahteve kupca s pomočjo programa Microsoft Excel, ki je obračunaval stroške za material, delo in ostalo. V prodajni fazi (torej pred podpisom pogodbe) je direktor proizvodnje na povpraševanje generalnega direktorja ali direktorjev programov ugotovil možnosti realizacije projekta v delavnici glede na trenutno zasedenost proizvodnih kapacitet. Ko je bila pogodba podpisana, se je v sistemu IBM Notes odprl delovni nalog, na katerem so se zbirali vsi stroški izdelave posameznih delov in montaže. Vodja tehnologije je poskrbel za naročanje tistih kritičnih materialov, ki so imeli dolg dobavni rok. Potem, ko so drugi oddelki in programi definirali projektne zahteve (hidravlične posebnosti, regulacija itd.), na osnovi katerih je konstrukcija izdelala tehnično dokumentacijo, so se okrepile aktivnosti v proizvodnji. Planiranje je bilo izvedeno v programu Microsoft Project. Glede na terminske zahteve, ki morajo biti v skladu s projektom, je ocenjena sposobnost izvedbe z lastnimi resursi oz. po potrebi s pomočjo kooperantov, glede na naslednje kriterije:

Zasedenost kapacitet Tehnične lastnosti obdelovancev Izvedba operacij, ki jih ne izvajamo v lastnih delavnicah Sposobnost kooperantov za kakovostno izvedbo del

Če je sprejeta odločitev, da bo izvedba v podjetju, so izbor materialov in naročanje tehnično zahtevnejših materialov izvedli tehnologi. Naročila so lansirali glede na sledeče zahteve:

Specifikacije materiala, polizdelka ali storitve (načrt, skica itd.) Kriterije sprejemljivosti glede na tehnične standarde Zahtevo po spremni dokumentaciji (certifikati, zapisi o kakovosti itd.)

Potem ko so v tehnologiji prek elektronske pošte prejeli ponudbe od dobaviteljev, je nabava poslala naročilnico. Naročanje tehnično nezahtevnih materialov, orodja in opreme so izvedli v oddelku komerciale. Po prejetju konstrukcijske dokumentacije so izdelali tehnološko razpisni list (TLR), ki služi za izdelavo in kontrolo sestavnih delov. Na TLR so beležili aktivnosti, vključno s tehnološkimi postopki, dimenzijami, stanjem, datumi prejema in izdaje itd. Za kooperante so vodili aktivnosti v programu Microsoft Excel. Za lansiranje proizvodne dokumentacije je bil zadolžen vodja tehnologije, posamezen projekt pa je spremljal za to določen tehnolog. Izdelava in montaža se je izvajala po delovnih nalogih v skladu s terminskim planom (Kosem, D., Laznik, T., 2013).



PR

OIZ

VO

DN

I PR

OC

ES

- T

UR

BO

INŠT

ITU

T (

OB

STO

JEČ

E S

TAN

JE)

Te

hn

olo

gija

Skla

diš

čeK

om

erci

ala

/ N

aba

vaV

od

stvo

Pro

izvo

dn

ja /

M

on

taža

Kak

ovo

st

Priskrba virovProjektno planiranje

Prednaročanje kritičnih

materialov

Tehnološka obdelava

konstrukcijskih risb

Izdelava

Pogodba je podpisana

Naročanje potrebnih materialov

Lansiranje proizvodne

dokumentacije

Operativno planiranje

Vhodna kontrola

Skladiščenje

Odprema

Priprava orodij in pripomočkov

Vmesna kontrola

Dobava

Montaža

Funkcijski preiskus

Project

IBM Notes, GoSoft CAD, Excel

GoSoft

GoSoft Word, NitroPDF

IBM Notes, GoSoft

Pošiljanje naročilnice

GoSoft

MS Office

Shema 11 – Proizvodni proces po modelu SCOR z uporabo programske opreme (obstoječe stanje)



Slika 6 – Primer kosovnice, izdelane v programu CAD

Slika 7 – Tehnološko razpisni list (TLR) Čeprav ima sistem ERP GoSoft možnost spremljanja in planiranja proizvodnje (zaradi česar je bil med drugim tudi izbran), ta modul v Turboinštitutu ni bil uveden, čeprav so se nekatere aktivnosti v tej smeri že izvajale.



7.5 SCOR SCOR (ang. Supply Chain Reference Model) je metodologija, ki pomaga organizacijam na sistematičen način izboljšati funkcije nabavne verige (ang. supply chain). Omogoča izobraževanje, ogrodje, model in orodja za zbiranje, analizo in primerjavo podatkov ter uvedbo sistemov in praks, ki so praktično postali industrijski standard na tem področju. SCOR je razvila neprofitna organizacija Supply Chain Council, ki je bila ustanovljena leta 1996. SCOR (trenutno je aktualna različica 10) pomaga svojim članom16 priti do izboljšav na petih področjih, in sicer:

1. Kakovostna podpora strankam 2. Upravljanje stroškov 3. Planiranje in upravljanje tveganj 4. Izboljšanje odnosov s partnerji/dobavitelji 5. Prepoznavanje in iskanje nadarjenih menedžerjev

Pri učinkovitem upravljanju z nabavno verigo se vse vrti okoli »dostavljanja pravega izdelka v pravi količini, stanju in dokumentaciji na pravo mesto, ob pravem času in pravi ceni« (Supply Chain Operations Reference (SCOR®) modelOverview – Version 10.0; 3).

Slika 8 – Model SCOR, stopnja 1 (vir: https://supply-chain.org/f/SCOR-Overview-Web.pdf, dostop 11. 5. 2014)

Procesi SCOR (plan – planiranje, source – nabava, make – izdelava, deliver – dobava, return – podpora kupcu) segajo od dobavljalčevega dobavljalca do kupčevega kupca. Model SCOR je lahko zanimiv za vsako podjetje, ki ima več dobaviteljev in podizvajalcev. V našem primeru je zanimiv tudi zaradi tega, ker je izoblikoval procesni referenčni model, ki je zelo pregleden, zato ga bomo uporabili za prikaz procesne slike v proizvodnji Turboinštituta pred uvedbo SAP-a in po njej.

Referenčni model SCOR ima 5 stopenj, in sicer (Cheng, 2010):

1. Nivo 1 – definira število nabavnih verig, širša perspektiva (glej sliko 8). 2. Nivo 2 – razdeli pet glavnih procesov SCOR, ki smo jih našteli zgoraj, na

procesne kategorije, ki organizacijam omogočajo, da opišejo konfiguracije

16 Med člani SCC so številne velike svetovne korporacije. Seznam je javno dostopen: https://supply-chain.org/membership-by-type, dostop 11. 5. 2014.



nabavnih verig. Na tej stopnji se opredelijo odnosi in interakcije med posameznimi člani nabavne verige.

3. Nivo 3 – procesni potek dela. Omogoča podrobnejše informacije za planiranje in zastavljanje ciljev. Na tem nivoju se definirajo osnove za določanje metrike, s katero merimo učinkovitost nabavne verige.

4. Nivo 4 – ta nivo se ukvarja z izvedbo in je specifičen za vsako podjetje, zato ga model SCOR ne opisuje.

5. Nivo 5 – podrobna konfiguracija programske opreme. Analiza uvajanja modela SCOR na več kot 100 projektih v različnih organizacijah po svetu je pokazala nekaj rezultatov (Bolstorff, 2012):

Povečanje operativnih prihodkov na račun znižanja stroškov in storitev. Povprečno triodstotno povečanje prodaje. Povračilo investicije je ocenjeno na dva- do šestkrat v enem letu. Spodbuda sistemskim kapitalskim naložbam. Pospešeno vračanje investicije

v tehnologijo. Zmanjšanje operativnih IT stroškov zaradi manjše potrebe po prilagajanju

in razvijanju rešitev. Uporaba standardiziranih sistemskih funkcij. Povečanje dobička med polovico in enim odstotkom na letni ravni s

konstantno uporabo izboljšav nabavne verige.

7.6 PRENOVA PROIZVODNJE S PROGRAMSKO REŠITVIJO SAP Proizvodni – PP (Production Planning and Control) modul zajema:

Glavne podatke materiala (Material Master Data) Kosovnice (Bills of Material – BOM) Tehnološke postopke (Routhings) Delovne naloge (Work Orders – Order Managing) Delovna mesta (Work Centers) Planiranje kapacitet (Capacity Planning) Planiranje materialnih potreb (MRP)

Kosovnica je sklop elementov, ki sestavljajo nek izdelek. Vsebuje tudi tehnične podatke. Bolj kompliciran je izdelek, več nivojev ima kosovnica. SAP pozna več vrst kosovnic, podpira pa dva tehnična tipa (Poženel, 2006):

Variantne kosovnice (združujejo različne kosovnice, ki imajo velik delež enakih materialov)

Multiple kosovnice (združujejo kosovnice enega izdelka iz različnih kombinacij materialov glede na postopke izdelave)

Tehnološki postopek opisuje procese, ki so potrebni za obdelavo materiala. Delovno mesto določa kapacitete proizvodne linije oz. obdelovalnega stroja v našem primeru. Vezano je na stroškovno mesto. Delovni nalog je dokument, ki opredeljuje, katere naloge je treba izvesti v nekem delovnem procesu. Če gre za proizvodni delovni nalog v SAP-u, potem ti določajo: kaj in kdaj se bo proizvajalo, na katerih kapacitetah in s kakšnimi proizvodnimi



stroški. Lahko se ustvarjajo ročno ali s pretvorbo planskih v proizvodne naloge v MRP (Poženel, 2006). Takoj ko je delovni nalog (DN) kreiran, sistem izvede naslednje stopnje:

Izbere tehnološki postopek in ga prenese na DN. Izbere kosovnico in jo prenese na DN. Kreira rezervacije za vse skladiščne komponente v kosovnici na DN. Izračuna planirane stroške na DN. Kreira (rezervira) kapacitete za vsa delovna mesta. Kreira zahteve za nabavo za vse materiale, ki jih ni v skladišču, in za

zunanje storitve (Poženel, 2006).

7.7 VZORČNI PRIMER Kot reprezentančni primer pri uvajanju proizvodnega modula smo izbrali disipator (uničevalca) energije DN800, ki služi za zmanjšanje kinetične energije vodnega toka na koncu cevovoda za uravnavanje pritiska. Disipator je sestavni del hidroelektrarne, s pomočjo katerega lahko zmanjšamo erozijo na nasipe in dno reke. Tehnične lastnosti uničevalca energije so prilagojene zahtevam posameznega projekta. En projekt lahko sestavlja eden ali več takšnih uničevalcev energije, možno pa ga je prodati tudi samostojno. Za lažjo predstavo smo izdelek razdelili po sklopih: model, tlačni test, ohišje, dušilec, aktivator, vodilna regulacija, električno krmilje, montažne naprave. Za potrebe preizkušanja smo vključili še izdelavo modela in el. krmilje, da bi lahko skozi SAP izvedli tudi prodajo storitve (modeli PC) in izdelkov programa Hydro, ki se ukvarja s projektiranjem elektroopreme ter s turbinsko regulacijo in avtomatiko. Pripravili smo namišljen terminski plan projekta in prilagojeno stroškovno analizo. Tehnična dokumentacija (risbe, kosovnice) in tehnološki postopki pa so ustrezali dejanskemu stanju. Različne barve na shemi 12 predstavljajo različne profitne centre (modeli, turbine, hydro).

Slika 9 - Disipator energije DN800



Shema 12 – Uničevalec energije DN800 po sklopih Na začetku je bilo najprej treba oddati zahtevek za odpiranje novih materialov v SAP-u (identov17). Pri nas je za to poskrbel ključni uporabnik modula GPM (glavni podatki o materialu). Zahtevek se pripravi v Excelovi datoteki, v katero se vpisujejo naziv, obrat, profitni center, skladiščno lokacijo, enote, št. načrta itd. Označimo tudi, ali gre za končni izdelek, izdelek lastne proizvodnje, polizdelek lastne proizvodnje, material za predelavo in vgradnjo ali kooperacijo (zunanjo izvedbo). Nazive je treba vpisati v treh jezikih: slovenskem, angleškem in nemškem. Zahtevek je mogoče oddati tudi prek intranet portala. Materiali se v sistem dodajajo centralno za celotno Skupino Kolektor. S tem se izognemo pogostim napakam in podvajanju podatkov. Na tem področju so napake pogoste, zato verjetno obstaja nekaj prostora za razvoj varovalk pri odpiranju novih materialov. Potem ko bo SAP v uporabi, se bodo lahko materiali odpirali šele, ko bo pripravljena konstrukcijska risba. Stroškovni izračun, ki je potreben za izdelavo ponudbe, bo opravljen v programih MS Excel ali Project. V SAP-u bo projekt odprt šele takrat, ko bo pogodba že podpisana. To je tudi razumljivo, glede na to, da v podjetju oddajo veliko število ponudb za različne razpise. Vnašanje vseh teh podatkov v SAP bi bilo nepotrebno obremenjevanje resursov. Za potrebe testa smo predpostavili, da je pogodba že podpisana. Vodja projekta je poskrbel, da je odprt nov projekt, bodisi s pomočjo pripravljene predloge, s kopiranjem že obstoječega projekta ali na novo. Ko sta določena ECP (ang. Easy Cost Planning oz. planiranje stroškov po slovensko) in proračun, se projekt lansira. Prodajni oddelek izdela prodajni nalog, inženirji pripravijo konstrukcijske risbe, na osnovi katerih se odprejo novi materiali v glavnih podatkih, in potem je na vrsti proizvodnja.

17 Ident je pogosto uporabljen izraz za vsakega, ki se spoznava s SAP-om. Gre za identifikacijsko številko, ki je unikatna, torej se lahko uporabi kot ključ v podatkovnih relacijah.



TURB

OIN

ŠTIT

UT

- PR

OC

ESI S

AP

EC

C 6

.0

PS m

odu

lSD

mo

dul

MM

mod

ulPP

mo

dul

CO

mo

dul

FI m

od

ul

Odpiranje projekta ECP Lansiranje projekta

Prodajni nalog

Zahtevek za odpiranje novih

materialov

Odpiranje novih materialov

Izdelava konstrukcijske risbe

Izdelava kosovniceCA01

Proizvodni nalog Planski nalogTehnološki postopek MRP planiranje Izdelava Prevzem na zalogo

Zahtevek za nabavo Nabavni nalog

Prodaja (dobavnica) Račun

Pregled stroškov projekta

Pregled računovodskih dokumentov

Zaključek

Pogodba je podpisana

Dvig iz zalogePrevzem na zalogo

CJ20N

CA01CS01

MM01

MD01

MD04

MIGO

MIRO

MIGO

MIGOMD04

ME21N

VL01NVA01

CJ41

Shema 13 – Procesi SAP po modelu SCOR (s transakcijami)



Procesi v proizvodnji se dejansko pričnejo že prej. V fazi pogajanj pred podpisom pogodbe je treba posredovati podatke o zasedenosti proizvodnih kapacitet, da bi lahko postavili realne roke za izvedbo. Z uvedbo novega proizvodnega sistema se bodo proizvodni procesi spremenili, kot je razvidno iz primerjave med shemama 11 in 13. Materialov ne bo možno naročati, preden bo izdelana kosovnica, kar pomeni, da se bo pripravljanje tehnične dokumentacije moralo začeti prej, kot je bila dosedanja praksa. Izkušnje iz drugih podjetjih (Bizjak, 2013) kažejo, da je pravočasna priprava tehnične dokumentacija ključna za planiranje kapacitet, pravočasno izvedbo naročil in planiranje proizvodnje. Z novim sistemom bo manevrski prostor za improvizacijo omejen. To zahteva tudi spremembo poslovne filozofije vodstva. Tudi kupce bo treba obvestiti o novem načinu dela, saj bodo morali zaradi sprememb na projektu, ki niso planirane, plačati višjo ceno. V našem testnem primeru se je proces v proizvodnji začel pri izdelavi kosovnice. Na novo jo izdelamo s pomočjo transakcije CS01, za spremembo obstoječe uporabimo CS02, za prikaz pa CS03 (slika 10) oz. CS11, ki je razčlenjena in bolj pregledna (slika 11).

Slika 10 – Prikaz kosovnice izdelka (transakcija CS03) Pri transakciji CS02 dobimo podobno sliko. Edina razlika je možnost spreminjanja podatkov in dodajanje novih komponent kosovnice.



Slika 11 – Prikaz dela večstopenjske kosovnice (transakcija CS11) Ko so kosovnice pripravljene, vnesemo tehnološke postopke (transakcija CA01). Tukaj izberemo delovno mesto, opis proizvodne operacije, čas priprave stroja (če je potreben), strojni čas, delo delavca itd.

Slika 12 – Sprememba tehnoloških postopkov (transakcija CA02) Ko je proces priprave tehnoloških postopkov zaključen, sledi planiranje MRP. To je sistem planiranja materialnih potreb, prek katerega se izda zahtevek za nabavo na podlagi vnesenih terminov in količin. Če je material izdelan v hiši, na osnovi kosovnice in stanja zaloge, izdela zahteve za nabavo manjkajočih materialov. Tukaj lansiramo proizvodnjo, tj. spremenimo planski nalog v proizvodni nalog. Planiranje MRP omogoča boljši izkoristek dela in zalog (vzdržujemo čim manjšo zalogo in planiramo pravočasno dobavo) ter pretok informacij. Za planiranje potreb po materialih potrebujemo operativni plan, stanje zalog in kosovnice. Planiranje MRP torej rešuje naslednje probleme:

premalo pogosto uporabljenih materialov na zalogi naročanje napačnih materialov naročanje prevelikih količin prilagajanje potrebam strank prepozna ali prezgodnja dobava materialov



Graf 7 – Sawtooth graf prikazuje zalogo skozi čas (Stevenson, 2006).

Na točki ponovnega naročila, ki jo vidimo na grafu 7, je sistem upravljanja z zalogami mogoče nastaviti tako, da izvede zahtevek za nabavo. Če bi imeli varnostno zalogo (tj. definirano količino materiala, ki je na zalogi vedno ne glede na povpraševanje), ki bi jo nastavili npr. na tej točki, bi se zahtevek izvedel že prej. V tem primeru bi bila to točka minimalne zaloge. Slika 13 prikazuje nastavitev točke ponovnega naročila v SAP-u. S transakcijo MD02 najprej izberemo material in pogled (MRP1). Izberemo karakteristiko MRP (V1 – ročno ali V2 – avtomatsko ponovno naročanje), planerja, ki skrbi za zalogo, in nivo ponovnega naročila. V našem primeru je nastavljena vrednost 100. Ko bo zaloga vijaka padla pod ta nivo in bo MRP zagnan, bo sistem kreiral zahtevek za nabavo.

Slika 13 – Planiranje zaloge materiala (transakcija MD02)



Slika 14 – Nastavitev glavnih podatkov za material – izbira skupine MRP in karakteristike (transakcija MM03)

Planiranje MRP lahko razdelimo na več skupin, odvisno od nastavitev glavnih podatkov. Pravilo je, da ima lahko več različnih proizvodnih linij isto skupino MRP, ne more pa imeti ena proizvodna linija več skupin MRP. Tudi skladišče je lahko dodeljeno le eni skupini MRP, medtem ko ima ena skupina MRP lahko več skladišč. Z deljenjem po skupinah bi lahko proizvodnjo ene linije ali skupine strojev planirali neodvisno od ostalih. V našem primeru to ne bo potrebno. Pri planiranju kritičnih materialov (visokega cenovnega razreda, z dolgim dobavnim rokom, pomembnih z vidika proizvodnega procesa itd.) si pomagamo z MPS-jem (ang. Master Production Scheduling), katerega cilj je zmanjšanje nepotrebnega skladiščenja materialov in povečanje zanesljivosti pri naročanju. Potem ko je planiranje MPS zaključeno, je na vrsti planiranje ostalih materialov. MPS deluje samo na enem nivoju kosovnice, medtem ko MRP deluje na vseh nivojih. MPS poženemo posebno, pred MRP-jem. Transakcije, ki jih uporabljamo za zagon MSP-ja: MD40 – za vse materiale na obratu MD41 – posamezen material, večstopenjsko planiranje MD42 – posamezen material, enostopenjsko planiranje



Transakcije, ki jih uporabljamo za zagon MRP-ja: MD01 – za vse materiale na obratu (običajno poženemo pred zagonom) MD02 – za izdelek z večstopenjsko kosovnico MD03 – za izdelek enonivojsko brez kosovnice MD04 – seznam potreb/zalog

Slika 15 – Planiranje MRP – večstopenjsko (transakcija MD02)



Slika 16 – Prikaz lansiranja proizvodnega naloga (transakcija MD04)

Slika 17 – Proizvodni nalog (transakcija CO03)



Ko prek transakcije CO01 vpišemo potrebne podatke o količinah, datuma planiranega začetka in konca del. naloga in ko smo pregledali pomembne postavke (kosovnice, stanje zalog in potreb), preidemo na terminiranje oz. razporejanje operacij po tistih delovnih mestih, ki smo jih zaznali za kritične. Transakcije, ki se nanašajo na razporejanje kapacitet:

MC01 – Obremenitev del. mesta CM03 – Vrednotenje del. mesta CM05 – Preobremenitve na del. mestu CM04 – Zaostanki na del. mestu CM21 – Grafična planska tabla (izbira strategije planiranja) CM27 – Grafična planska tabla – izravnava kapacitet

Slika 18 – Osnovni pojmi pri planiranju kapacitet (Poženel, 2006)

S potrditvijo del. naloga se prenesejo kosovnice in tehnološki postopki na nalog in terminirajo operacije. Z izbiro menija (prehod – stroški – analiza) se nam pojavi stroškovna analiza. Ko je nalog lansiran, lahko začnemo izvajati operacije. Pred tem se izvede analiza razpoložljivosti materiala glede na kosovnico. Če materiala ni na zalogi, nam javi napako, vendar lahko kljub temu izvedemo lansiranje. Potem ko je nalog lansiran, dobi vsaka operacija svojo številko, na katero se vežejo porabljene ure. V času pisanja diplomskega dela še ni bila izbrana rešitev za vpisovanje delovnih ur in prikaz razporeda po delovnih mestih v proizvodnji.



7.7.1 Izobraževanje uporabnikov Izobraževanje ključnih uporabnikov je potekalo po priporočeni metodologiji ASAP, ki smo jo opisali v poglavju 7.3. Ključni uporabniki v Turboinštitutu (TI) so imeli poleg planiranih izobraževalnih aktivnosti možnost obiskati posamezna podjetja znotraj skupine, kjer so jim predstavili svoje izkušnje z uvajanjem informacijskega sistema SAP. Pridobili so koristne informacije in učno gradivo. Opozorili so jih tudi na morebitne težave pri izvedbi. Vsak ključni uporabnik v prevzetem podjetju je imel svojega mentorja, ključnega uporabnika na nivoju skupine družbe, v sodelovanju s katerim je razreševal probleme. Ta način dela se je pokazal kot uspešen. Organiziranih je bilo kar nekaj delavnic po posameznih področjih, ena skupna vaja in dva integracijska testa. Na zadnjem so vzorčni projekt od podpisa pogodbe do izdaje računa izvedli ključni uporabniki TI. Izvedli so tudi interno izobraževanje drugih uporabnikov (konstruktorji, tehnologi). 7.7.2 Podeljevanje vlog in dostopov Že ob začetku projekta so bili določeni ključni uporabniki po posameznih modulih. Kasneje je bilo treba določiti še nabavnika in planerja MRP, ki skrbi za pravočasno preskrbo, skladno s potrebami, in ima pregled nad razpoložljivostjo materialov. Treba bo določiti tudi planerja kapacitet. Ta skrbi za razpored dela po delovnih mestih na način, da je delo opravljeno pravočasno in so kapacitete strojev optimalno izkoriščene. 7.7.3 Priprava podatkov Za razliko od finančnega modula pri proizvodnem modulu (PP) ni bilo veliko prenosa podatkov. Z izjemo materialov, ki jih je bilo treba pregledati, kar je vključevalo inventuro v skladišču in standardizacijo pri poimenovanju zaradi odpiranja identov, je bilo treba naslednje podatke prilagoditi glede na obstoječe ali jih zastaviti na novo:

delovna mesta v proizvodnji s podatki o kvadraturi, moči strojev, stroškovnimi mesti, tarifnimi skupinami, profitnimi centri in osnovnimi sredstvi (v sodelovanju s FI in CO)

operacije v proizvodnji (poimenovanje, ovrednotenje) tehnološki postopki (sproti) določiti strojni čas, obremenitve strojev in čas za pripravo stroja pripraviti ustrezno združevanje strojev glede na delovna mesta pripraviti seznam materialov, ki bodo rezervirani za projekte pripraviti seznam osebnih zadolžitev in podatke o zadolžencih oblikovati predlogo za delovni plan določiti vse skladiščne lokacije pregledati seznam obstoječih materialov v bazi in pripraviti tabelo za vnos

novih odločiti se o načinu označevanja izdelkov in morebitni klasifikaciji najti rešitev glede vodenja razreza pločevine v SAP-u



8 VREDNOTENJE Na osnovi uporabljene metodologije ob študiju literature in s spoznavanjem dobrih praks na področju ter ob časovno določenem praktičnem delu lahko v obravnavanem primeru izpostavimo naslednje ugotovitve, ki smo jih razdelili na področje integracije informacijskega sistema in uvedbo sistema SAP.

8.1 INTEGRACIJA INFORMACIJSKEGA SISTEMA

IT Kolektorja je bil aktivno vključen v prevzemne aktivnosti šele potem, ko je bil posel že sklenjen. Zaradi tega sicer po našem mnenju ni bilo večjih posledic. Investicije v infrastrukturo bi verjetno sledile v enakem obsegu ne glede na rezultate morebitne predhodne analize, saj si Kolektorjev IT oddelek želi standardizirane rešitve na vseh področjih. Malo verjetno je tudi, da bi predhodna analiza IT v fazi prve ocene kandidata za prevzem v konkretnem primeru vplivala na ceno delnice.

Prevzemnik je izbral primerno strategijo. Popolna integracija je hitra in omogoča doseganje ciljev strategije Skupine Kolektor, ki je na isti ravni z IT strategijo, kar je zelo pomembno in je eden od ključnih faktorjev uspešne integracije.

V prvem delu smo večkrat poudarili pomen časa za uspešnost integracije. Ne samo da lahko podjetje hitreje doseže učinke sinergije, hitrost integracije je pomembna tudi s kadrovskega vidika. Tranzicija, če jo lahko tako imenujemo, ima lahko – če traja predolgo – negativne posledice na motivacijo zaposlenih, predvsem zaradi nestanovitnosti, ki jo spremlja. Od prevzema Turboinštituta do začetka junija je iz podjetja samovoljno odšlo pet zaposlenih. Ključni kadri so ostali. Temu je verjetno pripomogla tudi hitro izvedena integracija. Trenutno vse kaže, da se bo zaključila po sedmih mesecih od prevzema, kar je po naši oceni realno časovno obdobje, če vzamemo v obzir razpoložljive vire, strategijo in obseg integracije.

Izkušnja uporabe informacijskega sistema na strani prevzetega podjetja se bo spremenila v skladu s smernicami, ki jih je Gartner zaznal kot trend na področju podpore uporabnikom že leta 2012. Uporabniki bodo tako bolj samostojni pri odpravljanju napak, rutinska IT opravila bodo avtomatizirana (spreminjanje gesel, odklepanje računov, dodajanje novih uporabnikov, omogočanje dostopov do datotečnega strežnika in omrežja za goste itd.), informatiki pa bodo bolj vpeti v poslovne procese.

Med integracijo informacijskega sistema nismo imeli možnosti podrobneje

raziskovati pojava odpora uporabnikov in praktično analizirati katero od priporočljivih metod, ki smo jih našli v literaturi, saj do zaključka tega diplomskega dela nismo zaznali odpora uporabnikov kot problem. Eden od razlogov je verjetno to, da so zaposleni po prevzemu pričakovali spremembe. Nekaj nasprotujočih mnenj je bilo podanih pri načrtovani menjavi programske rešitve za računalniško podprto načrtovanje (CAD). Ta problematika se je reševala postopoma, s pomočjo komunikacije in premisleka, v času zaključevanja tega diplomskega dela pa še ni bila



zaključena. Kljub navedenemu predvidevamo, da se lahko stopnjo tveganja do odpora uporabnikov poveča potem, ko bo integracija popolnoma končana. Identificirali smo naslednje kritične točke:

o Odvzem administratorskih pravic zaposlenim, ki pogosto delajo na terenu v odročnih krajih.

o Uvajanje programske opreme CREO za računalniško podprto načrtovanje.

o Vnašanje podatkov v SAP, na začetku oz. dokler to ne postane rutinsko opravilo.

V obravnavanem primeru nismo zaznali značilnosti kulturnega konflikta

med IT oddelki obeh podjetij. To temo smo obravnavali, ker je področje IT kulture slabo raziskano, v splošnem pa je organizacijska kultura tema, ki jo je treba upoštevati pri prevzemu podjetja. V literaturi lahko najdemo primere, kot je združevanje Droge in Kolinske (Planinšek, 2009). Avtor je kot notranji opazovalec ugotovil, da so kulturni konflikti v tem primeru zelo slabo vplivali na uspešnost integracije. Primer IT konflikta pa smo navedli v poglavju 4.3 na primeru združevanja dveh tajvanskih bank, kjer je menedžment zaznal to kot problem18, ki so ga reševali z izobraževanjem in spreminjanjem kulturnih vrednot.

Vodja IT-ja prevzetega podjetja, g. Jaka Križanič, je v intervjuju kot tveganje pri integraciji izpostavil nasičenost uporabnikov s spremembami, kar lahko pripelje do padca storilnosti in uspešnosti. Ta problem bi po njegovem mnenju lahko reševali s komunikacijo in izobraževanjem. Na vprašanje o kriterijih za uspešno integracijo, o katerih smo v poglavju 4.4 ugotovili, da so zaradi kompleksnosti teme težko merljivi, je g. Križanič odgovoril, da je to bolje organiziran sistem, ki ga je možno učinkovito in centralizirano upravljati, ter ohraniti stik med uporabniki in oddelkom podpore. Kot največjo pomanjkljivost integracije informacijskega sistema Turboinštituta je izpostavil pozno vključevanje IT oddelka v prevzemni proces s podobnimi razlogi, kot so navedeni v literaturi. Celoten intervju je na voljo v prilogi 1.

Vodja IT sektorja Skupine Kolektor ga. Maja Leban je v intervjuju povedala, da se vedno znova pokaže pomembnost IT-ja v prevzemnem procesu, vendar to ne pomeni, da je pred prevzemom treba podrobno pregledati stanje informatike. Kot tveganje pri integraciji je izpostavila podporo vodstva in primerno izbiro poslovnega modela za prevzeto podjetje. To je pomembno tudi pri uvajanju sistema ERP, saj je treba napačne odločitve kasneje odpravljati z veliko več vložene energije. Posebno pozornost pri uvajanju sistema SAP posvečajo integracijskim testom, na katerih lahko preverijo več kot 80 % procesov. Na vprašanje o izkušnjah z integracijami v tujini je ga. Leban odgovorila, da ni bistvenih razlik od integracij doma. Največji izziv tako doma kot na tujem ostaja trk dveh organizacijskih kultur, zato ima Kolektor Group jasno definirane vrednote.

18 Velja: »Če menedžer problema ne vidi (ali ga ne more ali noče videti), potem problema ni in o ničemer se mu ni treba odločati.« (Gričar, 2002; 619)



Glede ocene kriterijev uspešne integracije je po njenem mnenju pomembno, da so doseženi cilji projekta. Ta mora biti dokončan znotraj terminskega in stroškovnega plana. S perspektive koncerna je integracija uspešna takrat, ko omogoča celosten pregled nad poslovanjem podjetja. Prvi učinki po uvedbi SAP-a se pokažejo po šestih mesecih od uvedbe. Celoten intervju je na voljo v prilogi 2.

8.2 UVEDBA ERP SAP

Uvajanje sistema SAP je cenejše in lažje v skupini podjetij z istim lastnikom, saj si ta med seboj brez pomislekov delijo znanja in izkušnje. Na tem področju so opazni učinki sinergije.

Glede na to, da je bila proizvodnja v Turboinštitutu pred integracijo

informacijsko slabo podprta, bo med vsemi oddelki deležna največjih sprememb, ki bodo omogočale večjo učinkovitost, lažje planiranje kapacitet, podrobno stroškovno analizo in boljši nadzor nad nabavnim procesom. To je po naši oceni najpomembnejši rezultat celotnega projekta integracije.



9 PRIPOROČILA

9.1 INTEGRACIJA INFORMACIJSKEGA SISTEMA

Z vključevanjem IT-ja v pogovore pred prevzemom podjetja lahko vodstvo dobi realnejšo sliko o tem, kako hitra in učinkovita bo integracija in tudi kakšni so pričakovani stroški. Te informacije pa bi lahko vplivale tudi na vrednotenje podjetja ali pa celo spremenile odločitev glede nakupa. Čeprav do sedaj nismo opazili večjih posledic zaradi poznejšega vključevanja IT-ja, se strinjamo, da je pri integracijah s stališča obvladovanja stroškov in hitrosti doseganja sinergijskih učinkov to nedvomno tveganje, ki ga je možno zelo enostavno zmanjšati.

Na področju komunikacije z uporabniki obstaja po našem mnenju nekaj

prostora za izboljšave. Čeprav ima IT Kolektorja pripravljeno sporočilo za uporabnike ob vstopu v domeno in čeprav je IT Turboinštituta pošiljal obvestila o spremembah na informacijskem sistemu, ostaja vtis, da uporabniki niso bili dobro obveščeni o tem, kaj se dogaja in kakšne spremembe se obetajo. Drugi problem je to, da nekateri niso dobro razumeli prejetih sporočil. Rešitev bi bila predstavitev projekta integracije že na samem začetku, v jedrnatem in razumljivem jeziku, vključno s planiranim terminskim planom. Sporočilo bi lahko pred pošiljanjem prebral en uporabnik, ki bi podal povratno informacijo. Pohvalimo pa lahko izobraževanje uporabnikov potem, ko so pričeli delo v domeni Kolektor.

Za podjetje, ki pogosto integrira informacijske sisteme, bi bilo lahko koristno, če bi vodilo dokumentacijo o preteklih izkušnjah, aktivnostih in strategijah. To bi bila potem dobra referenčna točka za pripravo scenarijev za integracije, vrednotenje in konstantne izboljšave.

9.2 UVEDBA ERP SAP

Na področju izobraževanja uporabnikov bi bilo po našem mnenju koristno, če bi za uporabnike uvedli sistem praktičnih vaj, kot ga uporablja SAP University Alliances. Interne skripte, ki so jim bile na voljo, so uporabne, vendar so usmerjene v okolje produkcije. V fazi učenja bi bilo za uporabnike koristno, če bi imeli testni sistem nastavljen tako, da gredo lahko sami skozi vnaprej pripravljene vaje. Ko uporabnikom dodelimo dostopne podatke na testnem sistemu, se v praksi zgodi, da ne vedo, kaj naj bi z njimi počeli. Če so motivirani za učenje in se lotijo študija gradiva, ki jih potem usmerja k večji praktični uporabi programa, se pogosto zalomi, ker morajo za preizkušanje posameznih funkcionalnosti delo pred njim opraviti uporabniki, ki so v procesnem toku pred njimi.

Uporabnikom je treba slikovito, podrobno in pravočasno predstaviti potek procesov, tako da jih razumejo. To predstavlja izziv, saj se v prvi fazi



istočasno dogaja tudi obratno. Ekipa, ki uvaja SAP, poskuša pridobiti čim več informacij o obstoječih procesih v podjetju. Po našem mnenju je treba več energije usmeriti v procese SAP, saj bodo v veliki večini primerov ostali nespremenjeni. Koristno bi bilo, če bi imeli uporabniki na voljo video predstavitev testnega primera, od podpisa pogodbe do izstavitve računa. Zaželeno bi bilo čim več praktičnega dela uporabnikov, ki se izobražujejo že od samega začetka. Teoretični del bi se lahko prilagodil na način, da se v začetni fazi predstavijo osnove, podrobnosti in posebnosti pa postopoma.

Pri prenosu podatkov iz starega sistema bi bilo koristno, če bi imeli vnaprej pripravljene relacije podatkovnih baz novega in starega sistema. Tako bi bil prenos podatkov bolje planiran in izveden. Lahko bi se v največji možni meri izognili ročnemu popravljanju.

Še več predlogov za izboljšave lahko pričakujemo, ko bo sistem SAP zaživel

v produkciji.

9.3 OSTALI PREDLOGI

Na področju standardizacije ima Skupina Kolektor dovolj izkušenj, zato tukaj ni treba izgubljati besed. V podjetju Turboinštitut se že odvijajo aktivnosti v smeri pridobivanja potrebnih certifikatov ISO in koncepta vitke proizvodnje s ciljem povečanja kakovosti, uspešnosti, učinkovitosti in konkurenčnosti.

Za Skupino Kolektor, ki že ima centralizirano nabavno službo, bi bilo morda

zanimivo ocenjevanje funkcije nabavne verige po metodologiji SCOR, ki smo jo opisali v poglavju 7.5.



10 ZAKLJUČEK Podjetje Turboinštitut se je v zadnjem polletju znašlo sredi dinamičnega okolja. Spremembe, ki so se zgodile na področju organizacije, IT, strategije, kulture in filozofije, bodo nedvomno vplivale na njegovo prihodnost. V diplomskem delu smo obravnavali enega glavnih nosilnih stebrov teh sprememb – informacijsko tehnologijo oziroma preoblikovanje IT, ki predstavlja razvojni korak v smeri izboljšanja poslovanja podjetja. Učinkov teh sprememb tukaj ne moremo kvantitativno oceniti, saj bi to presegalo zastavljene okvire in bi terjalo dodaten čas, vendar na osnovi opisanega lahko pričakujemo, da bodo rezultati pozitivni. Z gotovostjo pa lahko že sedaj trdimo, da bo izpolnjen pomemben pogoj za boljše odločanje. To je pravočasna informacija. S tem ko je v sistemu evidentiran vsak vijak in ovrednotena vsaka ura dela, lahko stroškovno obvladujemo proizvodnjo vsakega sklopa izdelka. Te podatke lahko uporabimo za analizo, ki nam omogoča lažje reševanje problemov in planiranje razvojne strategije. Naj omenimo tudi negativne plati takšne informatizacije: manjša prilagodljivost, dodatna obremenjenost delavcev z administrativnimi deli, višji stroški v primeru sprememb pri projektu so nekateri, ki nam najprej pridejo na misel. Kljub temu pozitivne plati po našem mnenju pretehtajo. Sicer pa, razvoja ni mogoče ustaviti. Če ga ne oblikuješ, mu lahko samo slediš. Diplomsko delo bi zaključil z željo, da bi omenjene spremembe Turboinštitutu pripomogle, da bo tudi v prihodnje nosilec razvoja na svojem strokovnem področju. Po trinajstih letih dela v tem podjetju sem prepričan, da so moji sodelavci tega zmožni in da si to tudi zaslužijo.



LITERATURA IN VIRI (2010). Pridobljeno 11. 5. 2014 iz Supply Chain Operations Reference (SCOR®)

modelOverview - Version 10.0: https://supply-chain.org/f/SCOR-Overview-Web.pdf.

Alaranta, M. (2005). Evaluating Success in Post-Merger IS Integration: A Case Study. Electronic Journal of Information Systems Evaluation, 8(3), 143–150.

Anderson, G. W. (2011). Sams teach yourself SAP in 24 hours. Indianapolis: Sams Publishing.

Berglez, B. (14. 1. 2014). IT integracija Turboinštitut. Pridobljeno 2. 5. 2014 iz https://extranet.kolektor.com.

Berglez, B. (2014). IT integracija Turboinštitut. Interni dokument, Kolektor, IT, Idrija. Pridobljeno 29. 4. 2014 iz https://extranet.kolektor.com.

Bertoncelj, A. (2008). Prevzemi in združitve: model uravnoteženega upravljanja ključnih dejavnikov uspeha. Koper: Fakulteta za management Koper.

Bizjak, M. (2013). Prenova planiranja proizvodnje s programsko rešitvijo SAP R/3. Diplomsko delo. Kranj.

Bolko, R. (2013). Za prevzem podjetja moraš imeti znanje, izkušnje in poslovni občutek. Komunitator, 34–35. (F. Šemrl, Izpraševalec)

Bolstorff, P. R. (2012). Supply Chain Exellence, A Handbook for Dramatic Improvement Using the SCOR Model, 3rd edition. New York: American Management Association.

Chao, R. L. (2009). A multiple case study on post-merger IT integration with IT culture conflict perspective. Proceedings of the 42nd Hawaii International Conference on System Sciences (str. 1–10). Waikola, Big Island, HI, USA: IEEE.

Cheng, J. L. (2010). Modeling and monitoring od construction supply chains. Advances Engineering Informatics, 24(4), str. 435–455.

Crosman, P. (November 2011). IT Lessons of a Serial Acquirer. Bank Technology News, str. 23–25.

Curtis, G. A. (2005). Reconcilable differences: IT and post-merger integration. Pridobljeno 27. 4. 2014 iz http://www.accenture.com/SiteCollectionDocuments/PDF/integration.pdf.

F. Wijnhoven, T. S. (2006). Post-merger IT integration strategies: An IT alignment perspective. Journal of Strategic Information Systems, 15(1), 5–28.

Fidler, M. (2008). Uvajanje standardne programske rešitve SAP v podjetju za dostavo pošiljk v razmerah združevanja podjetij. Magistrska naloga. Ljubljana.

Garcia-Canal, E. R.-C.-C. (2013). Speed of ICT integration strategies in absorptions: Insights from a qualitative study. European Management Journal, 31(3), 295–307.

Greene, J. (2012). IT Service Desks Must Modernize User Experiences or Get Out of the Way. Gartner. Pridobljeno 11. 5. 2014 iz http://www.gartner.com.

Gričar, J. (2002). Management informacijske tehnologije in e-poslovanja. V Management: nova znanja za uspeh. Ljubljana: Didakta.

Helmreich, R. L. (1994). Anatomy of a System Accident: The Crash of Avianca Flight 052. The International Journal of Aviation Psychology, 4(3), str. 265–284.



Homburg, C. B. (2006). Is speed of integration really a success factor of mergers and acquisitions? An analysis of the role of internal and external relatedness. Strategic Management Journal, 27(4), 347–367.

Huges, C., Farhan, M., Shubradeep, G. (Junij 2013). Winning with an IT M&A Playbook.

Hultman, K. (2003). Resistance to Change, Managing. Encyclopedia of Information Systems, 3, 693–705.

Jurevicius, O. (15. 4. 2013). Vertical Integration. Pridobljeno 15. 4. 2014 iz http://www.strategicmanagementinsight.com/topics/vertical-integration.html.

Kosem, D., Laznik, T. (15. 4. 2013). Poslovnik procesa Proizvodnja, interni dokument. Ljubljana.

Kovačič A., I.-Š. M. (2007). Zakaj modelirati poslovne procese pri informatizaciji poslovanja s celovitimi programskimi rešitvami. Uporabna informatika, 15(4), str. 192–200.

Lassman, J. J. (11. 11. 2013). Critical Capabilities for Corporate Telephony. Leidner, D. K. (2006). A review of culture in information system research: Toward

a theory of information technology culture conflict. MIS Quarterly, 30(2), str. 357–399.

(2013). Letno poročilo 2012. Ljubljana: Turboinštitut. Pridobljeno 15. 4. 2014 iz http://www.turboinstitut.si/files/Company/annual_reports/letno2012.pdf.

Mack, R. (2005). IT Handbook on Mergers, Acquisitions and Divestitures. Gartner. Morgan, G. (2004). Podobe organizacij. Ljubljana: Fakulteta za družbene vede. Planinšek, B. (2009). Proces združevanja / prevzema podjetij – Droga Kolinska.

Diplomska naloga. Velenje. Poženel, B. (maj 2006). Kosovnice, SAP/R3 – ver. 4.6 c, uporabniško navodilo. Poženel, B. (maj 2006). Proizvodni delovni nalogi, SAP/R3 –– ver. 4.6 c,

uporabniško navodilo. Idrija. Profit Center - Profit Center Accounting (EC-PCA) - SAP Library. Pridobljeno 3. 5.

2014 iz SAP Help portala: http://help.sap.com/saphelp_46c/helpdata/en/eb/13710f43c411d1896f0000e8322d00/content.htm?frameset=/en/eb/13712943c411d1896f0000e8322d00/frameset.htm.

Rupnik, P. (2013). Idrija je praznovala 50 let Kolektorja. Komunitator, časopis koncerna Kolektor, 13(67), 24–26.

Rupnik, P. (2013). Oddelek informatike ima novo direktorico. Komunitator, časopis koncerna Kolektor, 13(66), str. 54–55.

S. Vrhovec, R. R. (2011). Model obvladovanja odpora pri projektih in programih IT. Elektrotehniški vestnik, 78(1-2), 73–78.

Saarinen, T. (1996). An expanded instrument for evaluating information system success. Information & Management, 31, 103–118.

Salame, R. (januar 2006). Why Do Mergers Fail? What Can Be Done to Improve their Chances of Success? Pridobljeno 15. 4. 2014 iz www.key-strategy.com.

Stevenson, W. (30. 1. 2006). SJSU Bus 140. Stuckey, J., & D.White. (avgust 1993). When and when not to vertically integrate.

Pridobljeno 15. 4. 2014 iz McKinsey & Company: http://www.mckinsey.com/insights/strategy/when_and_when_not_to_vertically_integrate.



Stylianou, A. C. (1996). Corporate mergers and the problems of IS integration. Information & Management, 31(4), 203–2013.

Sušnik, M. (27. 11. 2009). Infrastruktura? Z lahkoto! Pridobljeno 29. 4. 2014 iz Monitor PRO: http://www.monitorpro.si/41048/praksa/infrastruktura-z-lahkoto/.

Šemrl, F. (december 2012). Bilo je desetletje korenitih sprememb. Informator, časopis koncerna Kolektor, str. 4–8.

Šemrl, F. (december 2012). Dolga je bila pot do samostojnosti, intervju. Informator, časopis koncerna Kolektor, str. 9–10.

Šemrl, F. (marec 2012). Kako se je začelo. Informator, časopis koncerna Kolektor, str. 2–5.

Šemrl, F. (2013). Zgodba o podjetju, ki se je iz podrejenega partnerja prelevilo v gospodarja. Komunitator, časopis koncerna Kolektor, 16(66), str. 30–33.

Tajnikar, M. (2000). Pripojitve, spojitve in prevzemi. Zbornik združitve in prevzemi gospodarskih družb. Ljubljana: Društvo ekonomistov.

Wikipedia. (25. 4. 2014). IBM Notes. Pridobljeno 2. 5. 2014 iz Wikipedie: http://en.wikipedia.org/wiki/IBM_Notes.

Zhao, J. (marec 2006). The IT Integration of Mergers & Acquisitions. Master of Science in Engineering and Management. Massachusetts Institute of Technology.



PRILOGI Priloga 1 – Intervju z g. Jakom Križaničem, vodjo IT Turboinštituta, d. d. Priloga 2 – Intervju z go. Majo Leban, vodjo IT Kolektor Groupa, d. o. o.

KAZALO SHEM Shema 1 – Oblike prevzemov po Andreju Bertonclju (2008) ........................... 2 Shema 2 – SAP pojmi: transakcije (v zelenem) so združene v proces.. .............. 10 Shema 3 – Prikaz osnovnega sistema VoIP ................................................ 12 Shema 4 – Vloga informacijske tehnologije pri prevzemu (Gartner, 2005) ......... 13 Shema 5 - Tristranski pogled na IT kulturni konflikt (Leidner, 2006; 374) ......... 16 Shema 6 – Model premagovanja odpora (Hultman, 2003; 699) ....................... 18 Shema 7 – Moduli SAP ECC 6.0 (vir: http://www.g-business.co.th) ................. 28 Shema 8 – Organizacijska struktura Turboinštituta v SAP-u .......................... 28 Shema 9 – Faze uvajanja po priporočilih SAP-a ......................................... 29 Shema 10 – Organigram proizvodnje v Turboinštitutu pred uvedbo SAP-a ......... 30 Shema 11 – Proizvodni proces z uporabo programske opreme (obstoječe stanje) . 32 Shema 12 – Uničevalec energije DN800 po sklopih ..................................... 37 Shema 13 – Procesi SAP po modelu SCOR (s transakcijami) ........................... 38

KAZALO SLIK Slika 1 – IBM Notes (glavne lastnosti) ..................................................... 10 Slika 2 – Microsoft Exchange (glavne lastnosti) ......................................... 11 Slika 3 – Superračunalnik (levo), slika toka v Francisovi turbini (desno) ............ 21 Slika 4 – IT Kolektorja uporablja družino izdelkov Microsoft System Center ....... 22 Slika 5 – Strežniki v Turboinštitutu pred integracijo ................................... 24 Slika 6 – Primer kosovnice, izdelane v programu CAD ................................. 33 Slika 7 – Tehnološko razpisni list (TLR) ................................................... 33 Slika 8 – Model SCOR, stopnja 1 ........................................................... 34 Slika 9 - Disipator energije DN800 ........................................................ 36 Slika 10 – Prikaz kosovnice izdelka (transakcija CS03) ................................. 39 Slika 11 – Prikaz dela večstopenjske kosovnice (transakcija CS11) ................... 40 Slika 12 – Sprememba tehnoloških postopkov (transakcija CA02) .................... 40 Slika 13 – Planiranje zaloge materiala (transakcija MD02) ............................ 41 Slika 14 – Nastavitev glavnih podatkov za material (transakcija MM03) ............ 42 Slika 15 – Planiranje MRP – večstopenjsko (transakcija MD02) ........................ 43 Slika 16 – Prikaz lansiranja proizvodnega naloga (transakcija MD04) ............... 44 Slika 17 – Proizvodni nalog (transakcija CO03) .......................................... 44 Slika 18 – Osnovni pojmi pri planiranju kapacitet (Poženel, 2006) .................. 45



KAZALO GRAFOV Graf 1 – Kritični faktorji uspeha pri prevzemu........................................... 4 Graf 2 – Prihodki v letu 2012................................................................ 6 Graf 3 – Število zaposlenih na dan 31. 12. 2012 ......................................... 6 Graf 4 – Delež zaposlenih z vsaj visoko izobrazbo (31. 12. 2012) ..................... 6 Graf 5 – Točka vključevanja IT pri integraciji, rezultati raziskave .................. 13 Graf 6 – Kritični faktorji uspeha pri IT integraciji ...................................... 14 Graf 7 – Sawtooth graf prikazuje zalogo skozi čas (Stevenson, 2006). .............. 41

KAZALO TABEL Tabela 1 – Razlike med podporo uporabnikom danes in v prihodnosti .............. 18 Tabela 2 – Razlike med IT-jem tarče in prevzemnika .................................. 24



POJMOVNIK CRM: programska rešitev za upravljanje odnosov s strankami ERP: poslovni IS, ki zajema praktično vsa pomembna področja poslovanja IPSec: protokol za šifriranje podatkov MRP: upravljanje s proizvodnimi materiali MRP-II: načrtovanje uporabe proizvodnih resursov OLTP: razred programske opreme, ki podpira aplikacije, vezane na transakcije SAP: poslovni informacijski sistem (ERP) nemškega podjetja SCM: programska rešitev za upravljanje oskrbovalne verige VPN: zasebno omrežje, dostopno prek interneta

KRATICE IN AKRONIMI IT: informacijska tehnologija IS: informacijski sistem



PRILOGA 1 Intervju z g. Jakom Križaničem, vodjo IT Turboinštituta, d. d., 1. 6. 2014 1. V kateri fazi je bil IT Turboinštituta vključen pri procesu prevzema s strani Kolektorja? IT oddelek podjetja Turboinštitut pri procesu prevzema pravzaprav ni sodeloval. Prvi stiki z IT oddelkom prevzemnega podjetja so bili navezani naknadno, več tednov po tem, ko je bil posel že sklenjen in je bila imenovana tudi nova uprava podjetja Turboinštitut. 2. Kakšen je pogled na integracijo s perspektive vodje IT-ja prevzetega podjetja? S perspektive vodje IT-ja prevzetega podjetja imam seveda določene zadržke. Matični IT oddelek z integracijo izgublja pristojnosti in neodvisnost, določene storitve se selijo na oddaljeno lokacijo, druge se ukinjajo. Med slednjimi so tudi takšne, ki so zaposlenim lajšale ali pospešile delovni proces, a jih žal ne moremo več umestiti v okvire nove, »koncernske« politike. Če smo prej delovali neodvisno oz. je bila neodvisnost vezana zgolj na upravo in skromen finančni vložek v IT sisteme, smo sedaj tudi operativno odvisni od IT specialistov na oddaljeni lokaciji. Seveda pa ta pogled ni edini. Z vidika koncerna je postopek integracije, kot jo prestajamo ta hip, nujno potreben in menim, da jo lahko ocenim kot pozitivno. Glede na kompleksnost obeh sistemov in povsem različno prakso do trenutka prevzema integracija poteka relativno tekoče in znotraj zastavljenih rokov. 3. V literaturi omenjajo možnost IT kulturnega konflikta med oddelkoma informacijske tehnologije prevzemnika in tarče. Kakšne so izkušnje med integracijo informacijskega sistema v Turboinštitutu na tem področju? Izkušnja sodelovanja med nami ter oddelkom informacijske tehnologije prevzemnika je izredno pozitivna. Vsekakor pa obstajajo močna razlikovanja v kulturi in politiki delovanja. Kulturni konflikt, morda bi bilo v našem primeru boljše poimenovanje kulturni šok, je prisoten na vseh področjih. Tako na področju uporabljene strojne kot tudi programske opreme, podpore uporabnikom in sistemske administracije, nabave opreme, merjenja uspešnosti in planiranja itd. se soočamo z velikimi spremembami. V IT oddelku Turboinštituta sva le dva in po moji oceni sva se relativno hitro prilagodila novim smernicam oz. zahtevam. Osnovni cilj nama je bil (in je še vedno) čim bolj tekoče in profesionalno izpeljati integracijo na način, ki bo uporabniku prijazen in bo hkrati v skladu z zahtevami novega lastnika oz. njegove IT službe. Menim pa, da pravi šok šele sledi, in sicer po zaključeni migraciji in integraciji uporabnikov Turboinštituta v domeno Kolektor. Določeni, morda manj fleksibilni uporabniki, bodo omenjene spremembe v kulturi zagotovo doživljali bolj stresno in z manj razumevanja kot IT oddelek sam po sebi. Takrat se bo šele pokazala prava uspešnost integracije in sposobnost obeh IT oddelkov reševanja takšnih konfliktov.



4. Uvajanje ali nadgradnja informacijskega sistema posega na široko področje organizacije, zato obstaja možnost, da pride do odpora uporabnikov. Ali je bilo moč zaznati odpor uporabnikov v obravnavanem primeru? Da. Deloma sem se tega dotaknil že v prejšnjem vprašanju. Dejstvo je, da je politika velikega koncerna precej bolj restriktivna – takšna že po svoji naravi mora biti, v kolikor hoče obvladovati veliko število storitev z omejenimi resursi. Dejstvo je tudi, da posegi v delovni proces, kot ga denimo prinaša vpeljava novega sistema ERP, odvzem administrativnih pravic na osebnih računalnikih, spremembe nabavnih postopkov ipd. sami po sebi prinašajo določeno nezadovoljstvo, ki mu do določene mere ni moč ubežati. Ne glede na to, ali gre pri tem (z vidika organiziranosti) za korak na bolje ali ne. S tem se deloma soočamo tudi v našem primeru, za pravo oceno odpora uporabnikov pa je seveda še nekoliko prezgodaj. Kljub vsemu do sedaj večjih oz. nepredvidenih težav iz tega naslova nismo zabeležili. 5. Katera tveganja se pojavljajo pri integraciji informacijskega sistema in kakšen pristop za njihovo obvladovanje je po vašem mnenju najbolj učinkovit? Po mojem mnenju je največje tveganje, sploh v našem primeru, ko gre za integracijo dveh v vseh pogledih različnih sistemov, zasičenost uporabnikov zaradi prevelike množice sprememb. Do prevzema podjetja Turboinštitut je prišlo zaradi finančne krize, v kateri se je znašlo podjetje. In ko se močno poveča delež časa, ko se uporabniki ukvarjajo z vpeljavo novih IT sistemov, v primerjavi s časom, ko se ukvarjajo s pridobivanjem ali izpeljavo novih projektov, je rezultat nezadovoljstvo. Slednje lahko privede do dodatnega padca storilnosti in uspešnosti. Morda najboljši pristop za obvladovanje tovrstnih težav je komunikacija z uporabniki in natančna opredelitev vseh prednosti, ki jih takšna integracija prinaša – tako za koncern kot za prevzeto podjetje in seveda za končnega uporabnika. Treba je poskrbeti tudi za izobraževanje vseh vpletenih. Velik del strahu in nezadovoljstva nad spremembami običajno izhaja iz strahu pred neznanim. 6. Kakšni so po vašem mnenju kriteriji uspešne IT integracije prevzetega podjetja? Glavni kriterij uspešne IT integracije je po mojem mnenju bolje organiziran sistem, ki ga je možno učinkovito in centralizirano upravljati ter hkrati ohraniti stik med uporabniki in IT oddelkom oz. tistim delom, ki je odgovoren za podporo. Posledica vsega tega je hitro reševanje in odpravljanje težav, hiter odziv na nove potrebe ali zahteve uporabnikov, lastnikov ali okolja, stabilnost sistema, povečana storilnost in ne nazadnje večje zadovoljstvo uporabnikov. 7. Kako ocenjujete dosedanji potek IT integracije v Turboinštitutu? Kot rečeno, integracija kljub številnim preprekam poteka relativno tekoče, komunikacijo med obema IT oddelkoma ocenjujem kot zelo dobro in sodelovanje v tem smislu ni težavno. Prav tako je zadovoljiv prenos znanja ob soočanju z novimi izzivi ali novimi orodji za upravljanje z infrastrukturo. Operativno integracija torej



poteka nad mojimi pričakovanji, sploh po začetnem obdobju po prevzemu, ko se je nekaj tednov zdelo, da (še) ni pravega plana v tej smeri. Glavna prepreka, ki jo trenutno vidim, bi lahko bilo zgolj pomanjkanje resursov, predvsem v smislu financ, za pridobitev zadovoljive strojne in zadostne količine licenčne programske opreme. Na tem mestu bi se lahko vrnil na prvo vprašanje. Morda edina, zagotovo pa največja napaka pri samem postopku integracije je po mojem mnenju nevključitev IT oddelka v postopek prevzema podjetja. Prav v IT-ju se lahko skrivajo številni stroški, ki jih novi lastnik predhodno ni upošteval in rezultat katerih je lahko dolgotrajna in stroškovno manj uspešna integracija.



PRILOGA 2 Intervju z go. Majo Leban, vodjo IT Kolektor Groupa, 3. 6. 2014 1. V kateri fazi je IT Kolektorja običajno vključen pri prevzemu podjetja? Že pri iskanju priložnosti, podrobni oceni (due diligence) ali kasneje po sklenitvi posla? O potrebnosti vključevanja zaposlenih iz oddelka IKT v procese prevzemov se odloča od primera do primera. Organiziranost informatike, vrsta ERP informacijskega sistema, tehnične rešitve na področju informatike itd. navadno niso dejavniki, ki bi vplivali na odločitev o prevzemu. 2. Ali je po vaših izkušnjah uspešnost IT integracije odvisna od pravočasnega vključevanja IT-ja v prevzemni proces? Vsekakor. Vedno znova se izkaže, da je dobro, da je informatika pomemben del prevzemnega procesa. To ne pomeni, da je pred prevzemom treba natančno pregledati stanje informatike – je pa uspešnost IT integracije v naslednjih korakih v veliki meri odvisna od informacij iz prevzemnega procesa. Tu seveda ni govora le o informacijah o samih IT rešitvah, govorimo tudi o splošni »kondiciji« tarče in o kulturi podjetja. Že v fazi prevzema postane jasno, katerim segmentom je v postopku integracije potencialne tarče treba posvetiti posebno pozornost. Z veliko informacijami o tarči je tudi IT integracija hitrejša, bolj kakovostna in na koncu tudi uspešnejša. 3. Katere so najpogostejše težave, s katerimi se srečujete pri integracijah? Smernice koncerna Kolektor na področju informatike so jasne. Čeprav so podjetja koncerna razsejana po vsem svetu, po vseh časovnih pasovih, je Kolektorjev IKT oddelek organiziran centralizirano. Zato je nujno potrebno, da je na področju IKT narejena standardizacija procesov ter strojne in komunikacijske opreme. Za pomoč končnim uporabnikom je vpeljan sistem HelpDeska, ki nam omogoča hitro komuniciranje in odpravljanje težav. V postopku integracije gre v glavnem za implementacijo standardov koncerna, ki na eni strani lahko omejujejo, čeprav na drugi strani veliko nudijo. Zaposleni za omejevanje smatrajo tudi npr. standardizacijo računalniške opreme, kot so PCji, prenosni računalniki in tiskalniki, pa čeprav je lahko oprema tehnično zmogljivejša, kot so jo trenutno navajeni. Kakorkoli že, dejstvo je, da uporabniki najprej naletijo na omejitve ali pa nov sistem vsaj doživljajo tako. Vedno do sedaj pa se je izkazalo, da je podjetje z vključitvijo kljub omejitvam pridobilo precej novih funkcionalnosti oz. storitev, ki so jih bili prej prisiljeni iskati na trgu oz. reševati po principu trenutnih možnosti. Največjo težavo pri integracijah po mojem mnenju predstavlja prav zamenjava »miselnosti« in odpor proti spremembam. 4. Skupina Kolektor je prevzemala tudi podjetja v tujini. Ali je zaradi kulturnih in drugih razlogov pri IT integraciji tam več težav? V postopku integracije se srečujemo z različnimi izzivi. Kulturni izzivi iz naslova geografske lokacije podjetja so vedno prisotni. Vendar lahko rečem, da se težave



v tujini bistveno ne razlikujejo od težav, ki smo jim priča pri integraciji slovenskih podjetjih. Na nivoju informacijskih tehnologij namreč le redko najdemo temo, na katero bi kulturno okolje lahko vplivalo na rešitev. Nekaj nejasnosti iz naslova tujine se po navadi pokaže iz možnosti nakupa standardiziranega HW in v posameznih procesih (posebnosti določene države), vendar se te uskladijo. Vpelje se kompromisna rešitev, ki zadošča zahtevam okolja, kot tudi zahtevam koncerna. Ne glede na makro lokacijo podjetja je med IT integracijo skorajda največji izziv trk dveh kultur. Tu ne mislim o kulturah npr. zahodnih ali vzhodnih držav, ampak o organizacijski kulturi podjetja. V koncernu se namreč že več leta intenzivno dela na organizacijski kulturi. V okviru tega projekta smo izpeljali precej sprememb, definirali smo pomembne vrednote, ki izhajajo iz našega načina poslovanja. Periodično izvajamo meritve organizacijske klime. In vse to so dejstva, ki koncern in s tem njegove zaposlene same po sebi naredijo drugačne. 5. V večini prevzetih podjetij Skupine Kolektor, predvsem tistih z lastno proizvodnjo, se standardno uporablja informacijski sistem SAP. Pri katerem modulu se v praksi pojavi največ težav in od česa je to odvisno? Integracija informacijskega sistema je samo ena izmed točk IT integracije. V koncernu so določena pravila, kdaj je določeno podjetje pripravljeno za vpeljavo poslovno-informacijskega sistema SAP. V tej točki govorimo o implementaciji informacijskega sistema. O integraciji govorimo le v tolikšni meri, kolikor se mora podjetje prilagajati standardiziranim procesom v informacijskem sistemu. Pri implementaciji gre v glavnem za proces prikazovanja postopkov, preverjanja ustreznosti in ne nazadnje tudi prepričevanja. Zaposleni v podjetju svoj dvom utemeljujejo predvsem iz prepričanja o posebnih in specifičnih zahtevah, ki izhajajo iz poslovanja posameznega podjetja. Tako je v fazi implementacije največji izziv postaviti ustrezen poslovni model – najti pravo kombinacijo med rešitvami poslovanja podjetja in zahtevami koncerna. Napačne odločitve v fazi implementacije namreč pomenijo težave v poslovanju, ki jih je kasneje z veliko več vložene energije treba reševati. V fazi integracije poslovno-informacijskega sistema največ časa odpade za izobraževanje uporabnikov in za pripravo in prenos podatkov za prenos iz obstoječega v nov informacijski sistem. 6. Kako hitro in na kakšen način se pokažejo prvi učinki po uvedbi SAP-a? Težko vprašanje. Iz izkušenj se učinki praviloma pokažejo v povprečju po 6 mesecih od konca uvedbe SAP-a. Takrat namreč šele pride ustrezen čas, da lahko informacije iz informacijskega sistema spremljamo in se o njih pogovarjamo. Dejstvo namreč je, da mora preteči nekaj časa, da se z zaposlenimi v integriranem podjetju lahko pogovarjamo o sami vsebini (ki je za številko) in ne le o samih številkah. 7. Kateremu področju je po vašem mnenju treba posvetiti posebno pozornost pri uvajanju SAP-a? Če je to mišljeno v smislu, kateri modul je pomembnejši, potem takega modula ne morem izpostaviti. Vsak modul ima svoje funkcionalnosti, kot je vsak proces v podjetju v določeni fazi pomemben za uspešno poslovanje. O širini oz. modulih, ki jih bomo implementirali, se odločamo glede na zahteve poslovanja. Tako



nepomembnih modulov v procesu implementacije ni. Zavedati se je namreč treba, da je informacijski sistem SAP popolnoma integriran. Posebno pozornost v procesu integracije posvečamo t. i. integracijskim testom, kjer člani celotne projektne skupine v več urah simulirajo in preverjajo pravilnost nastavitev posameznih procesov. Po naših izkušnjah tako preverimo cca 80–85 % vseh procesov, ki jih v SAP uporabljamo. Ker nam integracijski test služi tudi kot oblika izobraževanja uporabnikov, je tak obseg popolnoma sprejemljiv. V preostalem delu, ki ga ne testiramo na integracijskem testu, gre v glavnem za mesečne in letne obdelave. Podpora uporabnikom pri delu s SAP-om poteka tudi po »teku v živo«. 8. Katera tveganja bi izpostavili pri IT integraciji in uvajanju sistema SAP? Največje tveganje je podpora vodstva samega podjetja, ki ga želimo integrirati, kot tudi podpora celotnega vodstva Kolektor Groupa. Integracija informacijskega sistema je obsežen projekt, ki terja veliko energije in časa zaposlenih – ne glede na to, ali so to zaposleni v IT Kolektor Groupa ali v povezanih podjetjih. Implementacija informacijskega sistema je tudi projekt, ki vključuje ogromno deležnikov iz različnih podjetij, oddelkov, funkcijskih modulov Itd. Zaradi številčnosti deležnikov takega projekta je tudi zaupanje v »pravilnost in potrebnost« novega informacijskega sistema precej pomembno. Poleg samega človeškega faktorja, ki močno vpliva na uspešnost integracije, pa je s stališča podjetja samega še pomembneje, da skupaj izberemo ustrezen poslovni model za podjetje. 9. Kakšni so po vaših izkušnjah kriteriji uspešne IT integracije prevzetega podjetja? Kratkoročno opredeljujem uspešno integracijo takrat, ko je projekt integracije izveden v skladu s cilji projekta. Projekt mora biti dokončan znotraj terminskega in stroškovnega plana. Dolgoročno je integracija na nivoju koncerna uspešna takrat, ko koncernu omogoča celosten pogled na poslovanje integriranega podjetja z enake perspektive, kot velja za ostala podjetja. S perspektive povezanega podjetja je implementacija uspešna takrat, ko kratkoročno gledano uspešno pokriva zahteve poslovanja, dolgoročno pa zaradi kompleksnosti rešitve ponuja več informacij. Velikokrat se srečujemo s trenutnim nezadovoljstvom zaposlenih v podjetju, kjer je bila integracija izvedena, vendar tega ne smatram za neuspešno implementacijo. Nezadovoljstvo v veliki meri izhaja iz odklonilnega odnosa do sprememb. V manjši meri je lahko celo res, da se pretočnost posameznih procesov zmanjša, kar pa je pogosto le posledica prerazporeditve posameznih procesov med zaposlene. Zavedamo se, da lahko naredimo super integracijo, ki pa lahko ostane le na tehničnem nivoju. Če informacijskega sistema ne uporabljajo zaposleni, nismo naredili dovolj. 10. Kako ocenjujete dosedanji potek IT integracije v Turboinštitutu? Projekt integracije v Turboinštitut je potekal v skladu s pričakovanji. Pred začetkom implementacije smo pripravili več načinov oz. načrtov za integracijo



poslovno-informacijskega sistema. Odločitev o načinu smo na koncu sprejeli na nivoju uprave koncerna in je bila kot taka deležnikom projekta tudi predstavljena. Obseg integracije ni bil majhen, terminski načrt precej kratek. Ne glede na to, da smo v koncernu izvedli že več integracij, je bil potrjen predlog implementacije precej ambiciozen. Z junijem smo startali tek v živo. Po dosedanjih izkušnjah iz drugih integracij verjamem, da smo tudi tokrat integracijo naredili dobro. Vse skupaj ne bi bilo mogoče brez zainteresiranih sodelavcev na Turboinštitutu.