2002 ŠTEVILKA 4 OKT/NOV/DEC LETNIK X ISSN 1318-1882 tematska številka: celovite rešitve DONATORJI 11433748 vsebina ■ Uvodnik Spremna beseda Andrej Kovačič Celovite rešitve Razprave Vesna Bosilj Vukšič, Andrej Kovačič Information Technology and Enterprise Resource Planning tovvards Business Process Renovation Robert Srabotič Strateško načrtovanje in uvajanje celovitih informacijskih sistemov v slovenskih majhnih in srednje velikih podjetjih Mitja Cerovšek, Matej Jevšček Procesni pristop prenove in informatizacije poslovanja v skupini TPV Ksenča Bokovec, Talib Damij Pomembnost globalnega računovodskega modela v večnacionalnih uvedbah celovitih sistemov Matic Kovačič, Zvone Es Ključni dejavniki uspeha projekta celovite rešitve v teoriji in praksi - primer Elan Aleš Zajc Navision in koncept celovitih poslovnih rešitev z odprto poslovno logiko Edvard Dolenc Upravljanje oskrbovalnih verig in načrtovanje z APS Obvestila Portorož 2003 SOR 2003 Terminološki slovar informatike Koledar prireditev 189 191 198 210 218 226 235 241 248 248 249 250 ■ ■ ■ To revijo sofinancira Ministrstvo za šolstvo, znanost in šport mmm Navodila avtorjem Revija Uporabna informatika objavlja originalne prispevke domačih in tujih avtorjev na znanstveni, strokovni in informativni ravni. Namenjena je najširši strokovni javnosti, zato je zaželeno, da so tudi znanstveni prispevki napisani čim bolj mogoče poljudno. Članke objavljamo v slovenskem jeziku, prispevke tujih avtorjev pa tudi v angleškem jeziku. Vsak članek za rubriko Strokovne razprave mora za objavo prejeti dve pozitivni recenziji. Prispevki naj bodo lektorirani, v uredništvu opravljamo samo korekturo. Po presoji se bomo posvetovali z avtorjem in članek tudi lektorirali. Polno ime avtorja naj sledi naslovu prispevka. Imenu dodajte naslov organizacije in avtorjev elektronski naslov. Prispevki za rubriko Strokovne razprave naj imajo dolžino cca 30.000 znakov, prispevki za rubrike Rešitve, Poročila, Obvestila itd. pa so lahko krajši. Članek naj ima v začetku Izvleček v slovenskem jeziku in Abstract v angleškem jeziku. Izvleček naj v 8 do 10 vrsticah opiše vsebino prispevka, dosežene rezultate raziskave. Abstract naj se začenja s prevodom naslova v angleščino. Pišite v razmaku ene vrstice, brez posebnih ali poudarjenih črk, za ločilom na koncu stavka napravite samo en prazen prostor, ne uporabljajte zamika pri odstavkih. Revijo tiskamo v črno beli tehniki s folije, zato barvne slike ali fotografije kot originali niso primerne. Objavljali tudi ne bomo slik zaslonov, razen če so nujno potrebne za razumevanje besedila. Slike, grafikoni, organizacijske sheme itd. naj imajo belo podlago. Po možnosti jih pošiljajte posebej, ne v okviru članka. Članku dodajte kratek življenjepis avtorja (do 8 vrstic), v katerem poudarite predvsem delovne dosežke. Z vsa vprašanja se obračajte na tehnično urednico Katarino Puc. Prispevke pošiljajte na disketi in papirju na naslov Katarina Puc, Slovensko društvo informatika, Vožarski pot 12, 1000 Ljubljana, ali samo po elektronski pošti na naslov katarina.puc@drustvo-informatika.si. Po odločitvi uredniškega odbora, da bo članek objavljen v reviji, bo avtor prejel pogodbo, s katero bo prenesel vse materialne avtorske pravice na društvo INFORMATIKA. Po izidu revije pa bo prejel plačilo avtorskega honorarja po tedaj veljavnem ceniku ali po predlogu glavnega in odgovornega urednika. © Slovensko društvo INFORMATIKA, Ljubljana Naslov uredništva je: Slovensko društvo INFORMATIKA, Uredništvo revije Uporabna informatika, Vožarski pot 12, 1000 Ljubljana www.drustvo-informatika.si/posta uvodnik Spoštovane bralke in bralci, deset let življenja je že kar dolga doba v življenju človeka, kaj šele v življenju neke revije, in prav to smo dočakali z revijo, ki je pred vami. Začeli smo jo izdajati davnega leta 1993 in letos s pričujočo številko zaključujemo deseto leto izhajanja. Naše ambicije na začetku so bile zelo skromne, pričakovanja prav tako. Zdelo se nam je, da v Sloveniji tedaj ni bilo specializirane znanstveno-strokovne revije v slovenskem jeziku, ki bi se ukvarjala samo in predvsem z informatiko, čeprav je že tedaj obstajalo nekaj drugih revij, ki so in še deloma pokrivajo tudi to področje. Tudi sicer se nam je zdelo, da bi moralo biti eno od temeljnih poslanstev našega stanovskega društva, to je Slovenskega društva Informatika, ki je že tedaj izdajalo tudi revijo Informatica v angleškem jeziku, da poskrbi za razvoj stroke in strokovnega jezika in da začne izdajati še eno, nekoliko drugačno revijo, v slovenskem jeziku. Začetek je bil po pričakovanju zelo težak, vendar smo očitno preživeli. Programski cilji, ki smo si jih na samem začetku zadali, se v vseh desetih letih niso bistveno spreminjali. Imeti čim boljšo revijo, ki se ne bo branila zahtevnejših znanstvenih vsebin in bo tako pripomogla prenosu domačih in tujih znanj iz akademskih krogov v prakso, niti bolj praktično usmerjenih prispevkov, poročil in prikazov rešitev, iz prakse za prakso. Ne z enim ne z drugim programskim ciljem nismo povsem uspeli in ju bo treba še naprej skrbno razvijati ter negovati. Revija za akademsko sfero dolgo časa ni bila posebno zanimiva. Zaradi znane, in tudi na tem mestu kritizirane, habilitacijske politike obeh slovenskih univerz, objavljanje v domačih revijah univerzitetnim učiteljem ne prinaša veliko dragocenih, habilitacijskih točk, ki so potrebne za napredovanje, zato so le-ti veliko rajši objavljali tudi v bolj obskurnih revijah v tujini. Praktiki, to je naša druga ciljna skupina avtorjev, pa pri nas tako ali tako niso posebno nagnjeni k pisanju, zato kakovostnih in zanimivih prispevkov iz prakse še vedno zelo primanjkuje. V zadnjih dveh letih pa je bil vendar dosežen neke vrste preboj. Jeseni leta 2001 je bila revija uvrščena v mednarodno bibliografsko bazo INSPEC, s čimer seji njen 'rejting' tudi v akademski sferi bistveno izboljšuje, kar bo nedvomno vplivalo na interes pri potencialnih avtorjih, posledično pa tudi pri bralcih. Revija je postala čvrsta, finančno je prav tako v tem času splavala, posluje s pozitivno ničlo in je sposobna samostojnega preživetja. To je pravi čas za spremembe. Potrebni so nov zagon, nove ideje, novi pristopi, prav je, da se po tolikem času spremembe začnejo pri glavi, to je pri uredništvu. S to številko se s svojih mest umikava glavni in odgovorni urednik in tehnična urednica, ki sva to delo opravljala od samega začetka izhajanja revije. Zato bi rad izkoristil to zadnjo priložnost, da se zahvalim za požrtvovalno sodelovanje vsem nekdanjim in sedanjim članom uredniškega odbora in vsem recenzentom, ki so žrtvovali veliko svojega prostega časa, daje revija bila in je, taka kot je. Prav posebna zahvala gre tehnični urednici Katarini Puc, ki je bila od prve številke pa vse do danes motor revije. Njej gre zasluga, da v vseh desetih letih ni izostala niti ena sama številka, in da so bile tudi sicer zamude redke in majhne. V eni osebi je združevala toliko funkcij in opravljala toliko nalog, da jih je težko našteti. Od novega leta bo na čelu uredniškega odbora Andrej Kovačič, ki z revijo prav tako sodeluje že od samega začetka. Za 'ogrevanje' smo ga že v letošnjem letu zaprosili, če bi lahko, kot gostujoči urednik, prevzel uredništvo tematske številke, kije sedaj postala že tradicionalna, kar je ljubeznivo sprejel. Številka, ki je pred vami, zato že nosi njegov pečat. S tehnično urednico mu revijo predajava z lahkim srcem, čeprav je bil to neke vrste najin otrok. Vendar, ta otrok je že zdavnaj shodil in je že dolgo krepko na nogah. Prepričan sem, da bo tudi v prihodnje v dobrih rokah, Mirko Vintar Vsem članom Slovenskega društva INFORMATIKA, sponzorjem revije in drugim bralcem želimo d$ech& JŽ003 * * * Uredništvo revije upombncA NFORMATIKA mmuuiiMi Celovite rešitve Celovito rešitev1 lahko opredelimo kot celovito povezano in na poslovnem modelu organizacije temelječo sestavo uporabniških programov, ki ob uporabi sodobne informacijske tehnologije zagotavlja vsem poslovnim procesom tako organizacije kot tudi z njo povezanih poslovnih partnerjev optimalne možnosti načrtovanja, razporejanja virov in ustvarjanja dodane vrednosti. Uvajanje celovitih rešitev je eden od pomembnih pristopov k poslovni prenovi in informatizaciji poslovanja, ki vodi zlasti k učinkovitejšemu obvladovanju poslovnih procesov in podatkov ter k natančnejšemu napovedovanju poslovnih dogodkov in odločanju. Uvajanje temelji na konceptu prenove poslovanja, ta pa na prenosu najboljše prakse, zajete v teh rešitvah v posamezno organizacijo in njeno neposredno okolje. Gre torej za strateško pomemben, pogosto tudi nujen projekt, ki ima lahko dolgoročno bodisi zelo pozitivne bodisi pogubne posledice. Tuja in domača praksa na tem področju kažeta, da gre za projekte z visoko stopnjo tveganja in relativno nizko uspešnostjo. V svetu je uspešnih le med 9 in 17 odstotkov (različni viri) projektov uvajanja sistemov celovitih rešitev, vsi drugi so bili neuspešni ali predčasno prekinjeni. Pri teh analitiki ponavadi izpostavljajo nekajkratno prekoračevanje rokov in stroškov uvajanja ( nad 200%) in nedoseganje začrtanih ciljev oziroma funkcionalnosti (manj kot 50%). Ocenjujemo, da so pri nas ti negativni odstotki še izrazitejši. 250 mio SIT — ^ dejanski stroški pričakovani stroški skupni stroški lastništva 50 mio SIT - uvajanje vzdrževanje dograjevanje rešitev Svetovni trg celovitih programskih rešitev zajema po nekaterih podatkih 300 milijard ameriških dolarjev (napoved Gartner Group za leto 2002), ob sicer rahlo upočasnjeni, vendar še vedno občudovanja vredni letni rasti (malo pod 30%). Takšen trend rasti je nedvomno posledica konca evforije povezane z letom 2000, manjše (od predvidene) absorbcijske moči organizacij in množice neuspešnih projektov uvajanja, ki so temeljili na ustaljenem pravilu 80% pokrivanja informacijskih potreb in praksi prilagajanja programov potrebam poslovanja. Raziskave na področju uvajanja celovitih rešitev so pokazale, da je to pravilo treba opustiti in postopke uvajanja korenito spremeniti. Tudi najboljše celovite rešitve v praksi pokrivajo največ 70% potreb organizacije. Kaj narediti z ostankom? Organizacije morajo v ta namen prilagoditi svoje procese, preostalih 30% pa pozabiti ali urediti s posebnimi, največkrat specializiranimi rešitvami. Te rešitve (obstoječe ali nove) je treba v nadaljevanju programsko in procesno povezati s celovito rešitvijo. Držimo se torej načela, da prilagajamo svoje procese najboljši praksi, ki se nahaja v celoviti rešitvi, saj v nasprotnem primeru stroški prilagajanja, vzdrževanja in dopolnjevanja (upgrade) prerastejo mnogokratnik (v naši praksi tudi do desetkratnik) vrednosti kupljene rešitve. Spodnja slika kaže povprečen potek izvajanja uspešnega projekta v naših razmerah. V naši praksi pogosto naletimo na nepripravljenosti vodstva organizacije za neposredno vključevanje pri projektih uvajanja celovitih rešitev. Ljudje, ki odločajo (menedžerji, lastniki) običajno zmotno ugotavljajo, da naj projekt uvajanja celovite rešitve informacijski projekt načrtujejo in izvedejo njihovi informatiki. Ker se očitno niso sposobni ali pripravljeni spoprijeti s problematiko prestrukturiranja (reinženiringa) organizacije v smislu celovite prenove in informatizacije poslovanja (to je, roko na srce, zahteven in tvegan, a poslovno potreben projekt), nesorazmerno veliko vlagajo v strojno in komunikacijsko opremo ter pogosto zelo nekritično in neuspešno v (predvsem tuje) celovite uporabniške programske rešitve. Posledice nepretehtanih odločitev: le desetina projektov uvajanja celovitih rešitev je popolnoma uspešnih. Vendar ljudje z močjo odločanja o podrobnostih svojih zablod največkrat molčijo. Molčijo o tem, da so bili zavedeni, da so jih impresionirale tuje reference, da so verjeli ponudnikom rešitev o poznavanju njene tehnološke ustreznosti in primernosti informacijskim in poslovnim potrebam njihove organizacije. Molčijo tudi o stroških, ki nekaj desetkrat presegajo načrtovane stroške. Preden se vodstvo organizacije loti odločanja o razvoju ali nakupu oziroma izbiri celovite programske rešitve in njenem uvajanju, mora nujno najprej ugotovitvi svojo obstoječo in bodočo poslovno strategijo ter načrtovano izvajanje poslovnih procesov. To je še posebej pomembno, 1 Izraz celovita, povezana, integrirana ... (uporabniška), (programska) rešitev se pri nas (še) ni uveljavil. Tudi neposreden prevod angleške izvorne, vsebinsko neustrezne kratice ERP (Enterprise Resource Planning), nam ne bi kaj dosti pomagal. Zato predlagamo slovenski izraz, ki je blizu pravemu pomenu pojma: celovita rešitev. Spremna beseda saj uspešno uvajanje večinoma tujih (nekaj je tudi domačih) celovitih rešitev pogojuje procesno organiziranost poslovanja. V ta namen je torej običajno treba najprej odpraviti ali omiliti vplivnost tradicionalno prisotne funkcijske organiziranosti in urediti celovitost in preglednost poslovnih procesov organizacije. Predhodno omenjena praksa in negativne izkušnje namreč kažejo, da je prilagajanje celovitih rešitev izredno zahtevno in tvegano opravilo ter običajno povzroča prekoračitve trajanja in stroškov projektov. Prilagajanje obstoječim (običajno nepreglednim in necelovitim) procesom močno zavira proces uvajanja, s spreminjanjem programov pa ustvarja potencialno nevarnost dodatnih programskih napak in necelovitosti rešitve, ki se pojavi ob dopolnjevanju z novimi verzijami (upgrade). Zato naj odločevale! pred odločitvijo o nakupu ugotovijo primernost rešitve in skladnost njene informacijske podpore s postopki in poslovnimi procesi, ki jih izvajajo v njihovi organizaciji. Dilema o nakupu ali lastnem razvoju ostaja. Iz literature in vsakdanje prakse so znane prednosti in slabosti nakupa že izdelanih programskih rešitev. Vse bolj pa velja pravilo: če ponujena rešitev v veliki meri ustreza potrebam organizacije, jo kupimo. Z nakupom znatno skrajšamo čas, potreben za razvoj, in znižamo raven tveganja glede ustreznosti rešitve, ki smo mu priča pri lastnem razvoju. Pridobimo tudi morebitna tuja poslovna in tehnološka znanja, ki jih vsebujejo kakovostne celovite rešitve. Slabosti nakupa se kažejo v razmeroma visoki ceni nakupa in stroških osnovnega prilagajanja rešitev. Le-ti še bolj pridejo do izraza, če organizacija ni sposobna v zadostni meri opredeliti svojih potreb ali v primeru, da uvajalec premalo pozna možnosti rešitve, kar je pri takšnih projektih žal običajen pojav. Poleg težav, povezanih s časom in stroški uvajanja ter z neprilagojenostjo rešitve informacijskim potrebam uporabnikov, se pojavi še problematika prenosa znanj informatikom iz organizacije, ki jih bodo le-ti potrebovali za vzdrževanje in nadaljnji razvoj rešitev. Odločitev o nakupu posameznih modulov ali o njihovem lastnem razvoju se lahko izvede le na osnovi podrobno opredeljenih ter z modelom procesov in podatkov formaliziranih in prikazanih informacijskih potreb izvajanja postopkov v poslovnem procesu. Se nedavno (in v dobi parcialnih, necelovitih rešitev) je veljalo pravilo, da je v normalnih tržnih pogojih odločitev za nakup smotrna, če aplikativna rešitev pokriva vsaj 80 % informacijskih potreb obravnavanega področja. Z normalnimi pogoji imamo poleg ustrezne cene v mislih tudi razpoložljivost ustreznih rešitev v izvorni obliki in ponudnikovo pripravljenost za sodelovanje pri uvedbi in prilagajanju rešitve. Ocenjevanje ustreznosti odločitve o nakupu programske rešitve nikakor ni preprosto opravilo. Organizacija v primeru nakupa rešitve strategije in postopkov uvajanja ne sme slepo zaupati izbranemu ponudniku. Če organizacija še nima uveljavljenega lastnega strateškega načrta informatizacije, mora najprej izdelati strategijo uvajanja rešitve. Ta ponavadi zajema postopke priprave za uvajanje in odločitvene kriterije izbire. Uredniški odbor revije Uporabna informatika se je zaradi obetavnosti obravnavanega področja in prisotnosti zgoraj navedene problematike odločil področju načrtovanja, razvoja ali nakupa, uvajanja in prilagajanja celovitih rešitev nameniti posebno številko revije. V ta namen smo javno povabili k sodelovanju strokovnjake, ki se pri nas ukvarjajo z navedeno problematiko. Odziv je bil zelo dober. Od vseh prispelih del je uredniški odbor na osnovi predlogov recenzentov izbral polovico prispelih del, kijih predstavljamo v tej tematski številki revije. V prvem prispevku »Information technology and enterprise resource planning tovvards business process renovation” avtorja izpostavljata strateški pomen in vplivnost informacijske tehnologije in celovitih rešitev na možnosti prenove poslovanja. Pri tem podajata tudi opredelitve pojmov in stanja na področju celovitih rešitev in prenove poslovanja v razmerah globalizacije. Sledijo prispevki, ki se ukvarjajo z obravnavo strateških izhodišč, pristopov in modelov na katerih temelji uspešna uvedba celovitih rešitev. Robert Srabotič v svojem prispevku na tem področju izpostavlja pomen strateškega načrtovanja informatizacije, avtorja Mitja Cerovšek in Matej Jevšček prikazujeta in pojasnjujeta procesni pristop prenove in informatizacije poslovanja na primeru podjetij skupine TPV, Ksenča Bokovec in Talib Damij pa izpostavljata pomembnost globalnega računovodskega sistema pri uvajanju celovitih rešitev. Verjamemo, da bodo k odpravi strahu pred celovitimi rešitvami, pa tudi nekaterih zablod in napak, ki so prisotne v naši praksi, pripomogli zlasti prispevki, ki prikazujejo uspešne projekte uvajanja celovitih rešitev. Avtorja Matic Kovačič in Zvone Es prikazujeta in izpostavljata ključne dejavnike uspeha projekta, uspešno izvedenega v podjetju Elan. V prispevku predstavljata tudi primerjavo rezultatov projekta z ugotovitvami predhodnih študij s tega področja. Aleš Zajc predstavlja v svojem prispevku koncept celovitih rešitev z odprto poslovno logiko na primeru rešitve ponudnika Navision, Edvard Dolenc pa obravnava področje celovite informatizacije oskrbovalnih verig in njihov pomen pri povezovanju podjetij. Dr. Andrej Kovačič, gostujoči urednik Razprave Information Technologv and Enterprise Resource Planning towards Business Process Renovation Vesna Bosilj Vukšič University of Zagreb, Faculty of Economics, Department of Information Science and Business Computing 10000 Zagreb, Croatia, vbosilj@efzg.hr and Andrej Kovačič University of Ljubljana, Faculty of Economics, Department of Information & Management Science 1000 Ljubljana, Slovenia andrej.kovacic@uni-lj.si Abstract: INFORMATION TECHNOLOGV AND ENTERPRISE RESOURCE PLANNING TOVVARDS BUSINESS PROCESS RENOVATION The main goal of the paper is to stress the impact of information technologv (IT) and enterprise resource planning (ERP) systems in business process renovation and discuss some aspects of business processes and information modeling. Business process renovation is presented as the key element of the new business orientation and the highest level of strategy for managing change that commonly cannot be handled by continuous improvement and reengineering methods or organizational restructuring. In this transformation process we recognize ERP systems as the core functionality that facilitates the flow of information among different business activities of an enterprise, and also enabling information sharing across organizational units on different locations. Povzetek: Osnovni cilj prispevka je opozoriti na vplivnost informacijske tehnologije in celovitih rešitev na možnosti prenove poslovanja ter pri tem izpostaviti vidike in povezave med poslovnim (procesnim) in informacijskim modeliranjem. Prenova poslovnih procesov je predstavljena kot ključna dejavnost v smeri novih poslovnih usmeritev organizacije in je najpomembnejša strateška usmeritev upravljanja s spremembami, ki je ni moč izvesti z obstoječimi metodami korenite prenove in stalnih izboljšav ali pa z znanimi metodami sprememinjanja organizacij. Celovite rešitve vidimo v tem procesu kot ključne dejavnike, ki zagotavljajo informatizacijo poslovnih procesov oziroma informacijske povezave posameznih aktivnosti, kot tudi nudenje informacijskih virov organizacije njenim enotam na različnih lokacijah. 1. INTRODUCTION In order to survive in highly competitive business en-vironments, companies have to continuously change their business processes. New conditions in the mar-ketplace have given a special stimulus to modelling business processes over the past ten years: product expansion, competitive sales conditions, development of global, vvorld distribution netvvorks, better informed customers, and orientation of the businesses tovvard their customers and satisfying their individual needs. In the light of this, re-engineering of business processes has often been employed, and information technology is a frequently utilized approach used to improve business processes. The paper stresses the necessity for organisation-al restructuring in the context of global information connectivity. Business Process Reengineering (BPR) is an organizational method demanding radical rede-sign of business processes in order to achieve more efficiency, better quality and more competitive pro-duction (Hammer and Champy, 1993). It means ana-lyzing and altering the business processes of the orga-nization as a vvhole. A business process includes activities and tasks that cross functional and/or organizational bound-aries. Information technology (IT) is the most impor-tant factor in enabling new redesigned processes. Modern information technology is oriented tovvards business processes and Communications between per-sons using these processes, and is therefore called process and information technology (Ould, 1995). In that way BPR can be described as organizational process redesigning, vvith the direct influence of IT. Despite the fact that many academics and practitioners agree on this idea, BPR and information systems modelling are stili performed separately. The goal of this paper is to examine this domain and propose the framevvork for business process modelling and IT integration. The main goal of the paper was to explore the re-lationship between IT, ERP and business process renovation. The evaluation of BPR is described in Chap-ter 2. A brief overvievv of ERP systems is presented in Chapter 3. The framevvork for business process renovation and ERP systems modelling is provided in Chapter 4. Finally, conclusions outline the main find-ings of this research in Chapter 5. 2. BPR EVOLUTION BPR has become one of the most popular topics in organizational management, creating new ways of doing business (Tumay, 1995). Many leading organi-zations have conducted BPR in order to improve pro-ductivity and gain competitive advantage. Hovvever, regardless of the number of companies involved in re-engineering, the rate of success of re-engineering projects is less than 50% (Hammer and Champy, 1993). Some of the frequently mentioned problems related to BPR include the inability to accurately pre-dict the outcome of radical change, the difficulty in capturing existing processes in a structured way, the lack of creativity in process redesign, the level of costs incurred in implementing the new process, and the inability to recognize the dynamic nature of the processes. On the other hand, CPI integrates methods such as industrial engineering, systems analysis and design, socio-technical design and total quality management (Davenport, 1993; Galliers, 1998). Continuous im-provement refers to programs and initiatives that emphasize incremental improvement in work processes and outputs over a n open-ended period of time (Davenport and Beers, 1995). Several researchers sug-gest that using CPI techniques dramatically increases competitive advantage. Furthermore, it is particularly suggested that TQM be integrated with BPR (Al-Mashari and Zairi, 1999). Business Renovation (BR) integrates the radical strategic method of BPR and more progressive methods of Continuous Process Improvement (CPI) vvith adequate IT (Kovačič et al., 2001). Process renovation is a reengineering strategy that critically examines current business practices and procedures, re-thinks them through and then redesigns the mission-critical products, processes and Services (Prassad, 1999). The analysis of published BPR cases suggested that Ham-mer's well-known definition of BPR is too limited since it focuses on processes and ignores other impor-tant aspects of institutions such as organizational structure, people, communication and IT (Grant, 2002). In the 90s, BPR focused on internal benefits such as cost reduction, the dovvnsizing of a company and operational efficiency, which are more tactical than strategically focused. Nowadays, e-business renovation strategies focus on the processes between business partners and the applications supporting these processes. These strategies are designed to address different types of processes vvith the emphasis on dif-ferent aspects (Phipps, 2000), (Kalakota and Robinson, 2001): customer relationship management, supply chain management, selling-chain management, and enterprise resource planning. By strictly pursuing a process perspective, busi-nesses are restructured across functional and hierar-chical boundaries. To accommodate these changes, organizations may need to be restructured around these new business processes (Grover and Malortha, 1997). BPR driven by e-business could not be based only on radical redesign of intra-organisational processes, but should be extended to the entire business netvvork (internal and external). An enhancement geared to include also inter-organisational processes is called Business Netvvork Redesign (Alt et al, 2000). Business Netvvork Redesign (BNR) is driven by global Information connectivity and e-commerce. It identi-fies the inter-organisational processes to redesign and extend the strengths of BPR to the netvvorking among business partners. An Online partnership must extend far beyond presenting promotional and pre-sales ac-tivities on companies' Web sites. It has to drill deep into a company's processes in order to create totally different business models. Therefore, most companies need to re-evaluate and Web-enable core processes to strengthen customer Service operations, streamline supply chains and reach nevv customers. Traditional companies are forced to change their current business models and create nevv ones. It must be stressed that the application of IT has the strongest impact on standardization or elimina-tion of process variations. For that reason, BPR and IT infrastructure strategies, vvhich are both derived from organizational strategy are in need of effective align-ment to ensure the success of the BPR initiative (Al-Mashari and Zairi, 1999). The merger of the tvvo con-cepts has resulted in the latest concept: business engineering (BE). The entirety of BE lies in radical, process oriented Solutions that have been greatly en-hanced by the IT. 3. ERP 0VERVIEW Enterprise Resource Planning systems automate and integrate the core functionality of an organization. ERP facilitates the flovv of information among the different functions of an enterprise, but it also enables information sharing across organizational units and geographical locations (Markuš et al., 2000). 3.1. Brief history of ERP According to Kalakota and Robinson (2000) the evo-lution of ERP systems could be devided in 4 phases: Manufacturing Integration, Enterprise Integration, Customer-centric Integration and Inter-enterprise Integration. Phase 1: Manufacturing Integration (MRP) In the 1970s, the production oriented Information sys-tems were known as manufacturing resource planning (MRP) systems. The aim of the MRP was to schedule and release manufacturing work orders and purchase orders. Irt the 1980s the extended version of MRP called MRP II was developed in order to focus into other business functions, including order process-ing, manufacturing and distribution. Since its data and processes were not integrated with those in the rest of the enterprise, MRP II was improved and re-named ERP. Phase 2: Enterprise Integration (ERP) In the mid-1990s ERP is the latest enhancement of MRP II with the added "back-office" functions such as finance, vvarehousing, distribution, quality control and human resources management, integrated to handle global business needs of a netvvorked enterprise (Siriginidi, 2000). The main goal of the ERP was to facilitate Information sharing and integration across these different functions and provide automated Solutions to a wide range of business processes. The goal of integration was: Use technology to develop process standardization across multiple business units in order to improve the efficiency and generate greater return on Capital (Kalakota and Robinson, 2000). Phase 3: Customer-centric Resource Planning (CRP) The range of ERP functions has expanded at the end of 1990s to include "front-office" functions such as šale, marketing and e-commerce. E-commerce appli-cations needed to be connected to back-end systems and thus forced many of the ERP software providers (including SAP, PeopleSoft and Baan) to reinvent themselves as CRP providers. While traditional ERP Solutions were equipped to support the "make-to-stock/configure-to-order business model", CRP sys-tems are able to meet the e-commerce "build-to build-to-order/fulfil-to-order" requirement. Effective manufacturing and Service delivery in the e-commerce model requires customer-centric, continuous planning instead of the classic ERP assumption of long planning cycles. Phase 4: Inter-enterprise Integration (XRP) Since the world of the 2000s has become one of inter-connected enterprises creating global information sys-tems, the scope of ERP systems comprises the entire value chain of the enterprise, its customers, suppliers and trading partners. The main goal of the XRP sys- tem is to provide intelligent decision support capabil-ities in order to reduce inventories, foster strategic pricing, improve cycle times and increase customer satisfaction throughout the supply chain and selling chain management. To achieve the goal, an XRP model must support the integration of external and inter-nal business activities vvith supplier's and customer's information and processes. 3.2. ERP Softvvare lndustry Trends Competition in the ERP software industry is very strong, vvith over 500 softvvare producers fighting for market share. The producers could be divided in tvvo groups: (1) the companies that offer an integrated suite of applications and (2) those that make innova-tive niche products and Solutions for supply change management, customer relationship management, advanced demand planning softvver (APS) and e-business applications. The major players in the first group are SAP AG, Oracle, PeopleSoft and J.D. Ed-vvards, vvhile the second group consists of several leaders like Siebel Systems and Ariba. Table 1 pro-vides a breakdovvn by company of license revenue, market share and estimated grovvth. By 2001 SAP re-ported that it alone accounted for more then 36.000 softvvare installations in 15.000 companies across 120 countries (SAP, 2001). Company Sales Market Estimated (2000 data) (in $ millions) Share Grovvth SAP AG 5.939 30% 10% Oracle 2.870 15% 14% PeopleSoft 1.736 9% 17% J.D. Edwards 980 5% 2% Geac 901 5% 0% Others 7.228 36% 8% Table 1: Profile of leading ERP companies (Source: AMR, 2001) VVhile businesses such as Cisco Systems, Eastman Kodak, and Tektronix have gaincd the expected ben-efits of ERP systems, many companies like Hershey (Stedman, 1999), Nike (Konicki, 2001) and Whirpool (Collet, 1999) have experienced difficulty. For exam-ple, FoxMeyer Drug, a $5 billion pharmaceutical vvholesaler, recently filed for bankruptcy. FoxMeyer argued that major problems vvere generated by a failed ERP system, vvhich created excess shipments resulting from incorrect orders (Kalakota and Robinson, 2000). Dell Computer spent tens of millions of dollars on an ERP system that vvas too monolithic and too rigid for their changing global operations. A study conducted by the Boston Consulting Group showed that only one out of three ERP appli-cations could be classified as successful (Soh et al., 2000). A recent study indicates that ERP failure rate may even be greater than 50 percent: 40 percent of ali ERP installations only achieve partial implementation and 20 percent of attempted ERP adoptions are scrapped as total failures (Trunick, 1999, Escalle et al., 1999). Ptak and Schragenheim (1999) also rcport that betvveen 60 and 90 percent of ERP implementations do not achieve the return on investment identified in the project approval phase. Despite the problems identified in ERP applica-tions, the number of companies going in for ERP sys-tems will grow continuously, changing in 3 directions: (1) the ERP vendors will integrate their Solutions sup-porting the e-business and workflow-management; (2) the ERP applications will be upgraded to target additional functional niches (CRM, SCM, APS) and (3) the ERP Solutions will be simplified to target hun-dreds and thousands of midsize and small companies. 4. FRAMEVVORK FOR BPR AND ERP INTEGRATION Recent BPR research papers demonstrated the eri tičal role of Information technology in Business process restructuring (Broadbent et al.,1999; Ten g et al., 1998). Previously, IT was used to help companies automate Business processes, but rečently, technology is being used to change those processes radically. IT plays the key role as a n enabler in Business process renovation and there is a strong correlation betvveen the quality of Information systems vvithin an organization; and the improvement of an overall corporate culture and the organizations' strategies (Lederer and Sethi, 1996). The principal claim of several authors is that Ham-mer's vvell-knovvn definition is too limited because it suggests BPR is about making changes to processes, vvhile IT plays only an enabling role (Grant, 2002; Koch, 2001; Siriginidi, 2000). The contributions of IT in BPR could be categorized in tvvo different ways (Chang, 2000). First, IT contributes heavily as facilita-tor to the process of reengineering. Second, IT contributes in the reengineering process as enabler to master the new process in the most effective way (Davenport and Short, 1990). The advantages and disadvantages of IS modelling and ERP system as a tool for realising Business renovation is discussed further. 4.1 Business process modelling and Information system modelling integration Different methods are used in order to achieve the goals of BPR. There exist a number of formal tech-niques for modelling Business processes vvhich are based on textual programmable languages or graph-ical notations, such as dataflovv diagrams, State tran-sition diagrams, role activity diagrams (RAD), IDEF, Petri-nets and related notations. Those formalisms can be used to structure properly the softvvare of a process support system. Hovvever, to achieve the proper func-tioning of a support system in a particular domain, a formal model should be filled with a specific content, i.e. deseription of the actual Business processes. The need to establish an explicit lin k betvveen Business and IS modelling has been recognised, but there has been little success to date in achieving the integration and co-ordination betvveen process and IS modelling methods and tools. Information system modelling should be derived from a model of Business processes and the corporate strategic IS plan. Business process modelling is usually follovved by IS (ERP systems) development and Business process automation. An automated Business process is referred to as a vvorkflovv (WF), vvhile a VVork-flow Management System (WFM) is softvvare used for its coordination and control (Mohan et al, 2000). The IS/VVF modelling environment provides a structured way of identifying and capturing ali Information, re-lationships and Business rules that constitute a Business process (Kovačič et al, 2001). For efficient vvorkflovv development, the process of defining and under-standing Business processes should be finished before specifying and implementing the corresponding vvorkflovv applications. Rather than only vievving the flovv of processes, future VVF/ERP systems vvill model and monitor processes affecting the performance of the Business. There is also an intention of integrating process modelling tools into the vvorkflovv environment to minimise implementation cost. In practice, mostly ali interfaces (methods and tools) betvveen BPM and VVFM simply implement a 1:1 coupling betvveen these models. The Solutions could be divided in 2 catego-ries: ■ The VVorkflovv Management Coalition's (WfMC's) vvork group vvas (in 1996) developing the integration betvveen a Business process and a vvorkflovv model (Interface 1) based on a modelling language. Interface 1 Definition deals vvith passing Process Definitions from external modelling tools to the vvorkflovv engine vvhere there are enaeted. The Co-alition published a nevv language as a precursor to the Interface definition. This interface includes a common meta-model for deseribing the process definition and also textual grammar for the inter-change of process definitions (Workflovv Process Definition Language - WPDL). This model meets standardisation requirements but has very limited practical applicability. ■ There are different tools for the transformation of BPM to VVFM and also some 'tool-supported' ap-proaches to the dcployment of Business process models (i.e. ARIS method and tools) for selected application. Applications can be implemented ei-ther by: (1) adapting and assembling process-ori-ented Business objects or by developing applica-tions front scratch; (2) implementing standard Business applications (i.e. SAP); (3) implementing workflow systems; or (4) an object-oriented system development using the Unified Modelling Lan-guage (UML) (Sheer, 1999). Here, the BR frame-work consists of the follovving four levels: Process design, Process management, Workflow and Application. The connections between particular levels are explained, yet the refinement method which supports the transition is not defined. Event-driven Process Chains (EPCs) have become a vvidespread process-modelling technique be-cause of the success of products such as SAP/R3 (ERP) and ARIS (tools). Unfortunately, neither the syntax nor semantics of EPCs are well defined. As a result, an EPC may be ambiguous and it is not possible for consistency and completeness. These problems are serious because EPC models are used as the specification of Business rules processed by WF systems. In using these approaches, experi-ence has shown the tendency to over-analyse ex-isting Business processes and IS implementation problems. To resolve this problem of complexity, some authors propose a rule dictionary or rule repository where Business rules have to be represented. This reposito-ry is the core of a development environment provid-ing appropriate tools for process, workflow, data aitd organisation modelling, process refinement, as well as import and export capabilities. A rule-repository sys-tem also provides the opportunity to implement capabilities for analysis and simulation. The experience leads to the conclusion that this rule-based methodol-ogy has advantages over established tool-supported Petri nets (i.e. INCOME) and EPC (i.e. ARIS) rule-re-finement approaches. 4.2 The role of ERP in reengineering business practices In the past, companies used to decide how they vvant-ed to do business and then made a decision about a software package that best supported their business processes. It vvas changed with ERP systems that re-quired the business processes to be modified to fit the system (Davenport, 1998). Recent ERP Solutions are modular and flexible, thus could be customized to a certain degree. There are, hovvever, constraints in design possibilities, vvhile major modifications are com- plex and extremely costly. The implementation delays and ERP products modifications could result in expo-nential growth in direct and indirect costs. From the above analysis, it wou!d be always better to finish BPR project in advance of information system modelling and ERP system development. Since the implementation of large information systems is not possible vvith-out first changing business processes, reengineering is essential to obtain the most benefit out of the ERP products. Hovvever, the analysis of businesses' practices shovved a different approach. Initiating BPR projects in advance of ERP means that the companies must provide resources for two successive projects. It vvas the reason for many companies to conduct ERP sys-tem development, trying to solve ali their organiza-tional problems vvithout previously reengineering business processes. An ERP implementation impacts significantly the company's culture, its organization-al structure, business processes, procedures and rules. In addition, ERP applications integrate many best business practices and knovvledge that could be vvorth including as a part of BPR projects. By taking the best practices inherent in ERP applications, companies can change their processes simultaneously vvith techno-logical change. As a result, a lot of companies changed their business processes to fit the ERP system require-ments and the possibilities of ERP systems have been used to underpin BPR (Kooch, 2001, Chen, 2001)). As ERP systems have traditionally taken too long to implement, a dynamic and incremental implementation of ERP components is proposed rather than a massive reengineering. It must be stressed that a lack of matching business processes vvith a company's ERP system can derail even the best-run firms. Managers and employees must be able to assess the technological and business process issues involved vvith specific ERP applications. It is vvell knovvn that overcoming employee re-sistance could be a critical factor for the successful completion of a project and top management must provide leadership for ali changes, efforts, objections and disagreements that arise in the process of reengineering and ERP implementation. The large sample of enterprises has shovvn that several approaches to the combination of BPR and ERP are in play and that they lead to different levels of integration. Many agree that in today's business environment intangible assets comprise 80% of organizational val-ue. Intangible assets usually bring long-term benefits to the organizations. The synergy created and mani-fested by ERP and BPR, along vvith new employee energy can provide organizations vvith unprecedent-ed capabilities they never envisioned prior to ERP implementations (Chenn, 2001). Ahmed (1999) also point out that evidence of practical experiences of success of business process change related programs require ongoing effort for at least three to five years, even reaching time frames of around 10-20 years for realization of tuli potential. Consequently, the focus of ERP implementations moved from matching business processes with the ERP system to developing "knovvl-edge-workers" that can quickly understand and work with redesigned processes and realize the ERP-en-abled benefits. 5. Conclusion The paper investigates the problem of realizing benefits of business process restructuring and ERP sys-tems development. Enterprises could use ERP capa-bilities to improve coordination and information ac-cess across their units and to enable effective links between the enterprise and its customers, suppliers and trading partners. This changes the emphasis from an internal focus to an external orientation. ERP sys-tems reinvent the way a company and its people op-erate. Therefore, as an organization introduces ERP, it also must take simultaneous changes in its business processes and business strategy. According to the literature, BPR is concerned with making changes to business processes, vvhile IT serves only to enable or-ganizational improvements. The practitioners shovved that BPR methodology was too restrictive and it should adopt a much broader view on the role of ERP systems in BPR projects. ERP systems impact overall operational perfor-mance in two phases. In the short term the focus should be on stabilizing new processes managed by ERP technology. In this phase it is very important for the companies to understand their business processes before altering them through ERP implementation. Therefore, different methods and tools used to model and measure business processes and requirements were discussed in this paper. In the post-implemen-tation period the ERP investment could be extended in new directions, towards CRM (Customer Relation-ship Management) and KM (Knovvledge Management) systems enabling people to maximize the appli-cation of their knowledge to achieve companies' stra-tegic goals. References: 1. Ahmed, P.K. (1999), “Magic bullets of process change? TQM and BPR”, Business Process Management Journal, Vol. 5, No. 4, pp 294-296. 2. Al-Mashari, M., and Zairi, M. (1999), “BPR implementation process: an analysis of key success and failure factors”, Business Process Management Journal, Vol. 5, No. 1., pp 87 - 112. 3. Alt, R., Fleisch, E. and Reichmayr, C., (2000), “Developing eCommerce within Business Networks -The Čase of ETA SA”. In Proč. of Thirteenth International Bled Electronic Conference, Bled, Slovenia, June 2000, pp 182-199. 4. AMR (2001), “The Report on Enterprise Management”, AMR Research, lnc:42 5. Broadbent, M., VVeill, R, St.Clair, D. (1999), The implications of information technology infrastruc-ture for business process redesign, MIS Quarterly, Vol. 23, No 2., pp 159-182. 6. Chang, S. L. (2000), Information technology in business processes, Business Process Management, Vol. 6, No. 3., pp 224-237. 7. Chenn, IJ. (2001), “Planning for ERP systems: analysis and future trend”, Business Process Management Journal, Vol.7, No. 5, pp. 374-386. 8. Collet, S. (1999), "SAP Gets Stuck in the Spin Cycle”, Computervvorld, Vol. 33. No. 45 (November 8, 1999), pp.l. 9. Davenport, T. H. (1993), "Process Innovation: Reengineering VVork Through Information Technology”, Harvard Business School press, Boston 10. Davenport, T. H. and Beers, M. C. (1995), “Managing Information about Processes”, Journal of Management Information Systems, Vol. 12, No. 1, pp 57-81. 11. Davenport, T.H. (1998), “Putting the enterprise into the enterprise system”, Harvard Business Revievv, Vol. 76, No. 4, pp. 121-31. 12. Davenport,T.H. and Short,J.E. (1990), “The New Industrial Engineering: Information Technol-ogy and Business Process Redesign”, Sloan Management Revievv, pp 11-27. 13. Galliers, R. D. (1998), "Reflections on BPR, IT and Organizational Change”, in: Galliers, R. D., W. R. J. Baets, (ed.), Information Technology and Organizational Transformation, John Wiley & Sons, New York 14. Grant D. (2002), “A VVider Vievv of Business Process Reengineering”, Communications of the ACM, February 2002, Vol. 45, No. 2, pp 85-90. 15. G rover, V., Malortha, M. (1997), “Business process re-engineering: a tutorial on the concept, evolution. Method, technology and applica-tion”, Journal of Operations Management, Vol. 15, pp 192-213. 16. Hammer, M. and Champy, J. (1993), “Reengineering the Corporation: a manifesta for business evolution”, Harper Collins Publishers 17. Kalakota R. and Robinson M. (2000), “e-Business 2.0”, Addison-Wesley. 18. Koch, C., (2001), "BPR and ERP: realising a Vision of process with IT", Business Process Management Journal, Vol.7, No. 3, pp. 258-265. 19. Konicki, S. (2001), "Nike Just Didn't Do it Right, Says 12 Technologies", Informationvveek (March 5, 2001), pp. 32. 20. Kovačič A., Groznik A. and Krisper M. (2001), “Business Renovation: From Business Process Modeliing to Information System Modelling", Journal of Simulation, Vol.2, No. 2, pp 41-50. 21. Lederer, A. L. and Sethi V. (1996), “Key Prescriptions for Strategic Information Systems Planning”, Journal of MIS, Vol. 13, No 1., pp 35 - 62. 22. Markuš M., Taniš C. and Fenema R (2000), “Multisite ERP Implementation”, Communication of the ACM, Vol. 43, No. 4, pp. 42-46. 23. Mohan C., Barber R., VVatts S. et. al (2000), “Evolution of Groupvvare for Business Applications: A Database Perspective on Lotus Domino/Notes”, in Proč. VLDB2000 - 26lh International Conference on Very Large Databases, Cairo, Egypt, September, VLDB Publications, USA, pp 684-687. 24. Ould.M.A (1995), "Business Processes: Modelling and Analysis for Reengineering and Improvement”, Willey 25. Phipps, D. (2000), “IT Strategies for E-Business That VVork”, Proceedings of Symposium ITexpo, Gartner Group, Orlando, Florida 26. Prassad B. (1999), “Hybrid re-engineering strategies for process improvement”, Business Process Management Journal, Vol. 5, No. 2, pp 178-197. 27. SAP (2001), “SAP Corporate Press Release - June 13, 2001”, www.sap.com 28. Sheer A.W. (1999), “ARIS-Business Process Modelling”, Springer, Berlin-Heidelberg. 29. Siriginidi S.R. (2000), “Enterprise Resource Planning in Reengineering Business”, Business Process Management Journal, Vol. 6, No. 5, pp. 376-391. 30. Soh, C., Kein, S. and Yap, T.J. (2000), “Cultural fits and misfits; is ERP a universal solution?”, Communication fo ACM, Vol. 43, No. 4, pp. 47-51. 31. Stedman, C. (1999), "Failed ERP Gamble Haunts Hershey”, Computerworld, Vol. 33, No. 44 (November 1, 1999), pp. 1. 32. Teng, J.T., Fiedler, K.D., Graver, V. (1998), “An Exploratory Study of Influence of the IS Function and Organizational Context on Business Process Reengineering Project Initiatives”, Omega, Vol. 26, No. 6., pp 679 - 698. 33. Tumay K. (1995), "Business process simulation", Proceedings of the 1995 VVinter Simulation Conference, VVashington DC, 1995, pp. 55-60. ♦ Vesna Bosilj-Vukšič received a Dipl.Econ., M.Sc and Ph.D. in Information Systems from the University of Zagreb. She is an associate professor of Simulation Modelling and Business Computing at the Faculty of Economics, University of Zagreb, at the Department of Information Sciences. Her current research interests focus on graphical methods in simulation modelling, business process reengineering, information systems development and knovvledge management. She is a former president of the Croatian Society for Simulation Modelling (CROSSIM). ♦ Andrej Kovačič received his Ph.D. in Information Science at University of Ljubljana in 1992. In the past he was project and business manager at the company PRIS Consulting and lecturer at the Faculty of Economics and at the School of Public Administration. Currently he is an associate professor at the Faculty of Economics, University of Ljubljana. Flis main research interests are business process reengineering, business renovation, e-business and strategic IS planning. He is founding president and member of the Association for Informatics at Slovenian Chamber of Commerce and member of editorial board of the Slovenian magazine "Uporabna informatika (Applied Informatics)". ♦ Razprave Strateško načrtovanje in uvajanje CELOVITIH INFORMACIJSKIH SISTEMOV V SLOVENSKIH MAJHNIH IN SREDNJE VELIKIH PODJETJIH - PRIMER IZVEDBE ZAGONSKEGA NAČRTA ZA PODJETJE Iskra Transmission Robert Srabotič Izvleček Namen pričujočega članka je osvetlitev problematike projekta uvedbe celovitega informacijskega sistema s poudarkom na majhnih in srednje velikih slovenskih podjetjih. Obenem članek predstavlja, kaj so celoviti IS, katere so njihove prednosti za majhna in srednje velika podjetja, prikazani so trendi na omenjenem področju, hkrati pa članek opozarja na probleme managerjev in informatikov majhnih in srednje velikih slovenskih podjetij, ki se morajo soočiti z uvedbo novih celovitih rešitev. V članku je še posebej izpostavljen nabor priporočil ali usmeritev, ki smo jih zbrali med obdelavo zelo razdrobljenega gradiva. Ključni dejavniki, ki bistveno vplivajo na uspeh tako kompleksnega projekta, kot je uvajanje celovite rešitve v podjetje, so: podpora vodstva projektu uvedbe, predanost bodočih uporabnikov, primerni viri, dovolj časa za izvedbo šolanja uporabnikov, sposobnost upravljanja sprememb in pravšnja stopnja prenove poslovnih procesov. Abstract STRATEGIC ERP PLANNING AND IMPLEMENTATION IN SLOVENE SMALL AND MEDIUM ENTERPRISES The purpose of the article is highlighting of the key success factors for enterprise systems implementations (ERP-Enterprise Resource Planning) focusing on Slovene SME. The article a/so presents what the ERP is, its benefits for SME's, trends on SME’s ERP market. At the same time there are exposed probiems which managers or owners of SME’s should face during the implementation process. Exposed is a/so a set of recommandations taken from various sources. The key success factors which mostly impact the outcome of such a compiex project as ERP implementation are: strong management support, the right sources, sufficient time for users' training, abiiity for change man-agement and the right level of business process reenginering (BPR). mmm 1. Uvod Živimo v obdobju velikih sprememb na področju poslovanja, ki jih prinaša napredek informacijske tehnologije (v nadaljnjem besedilu IT). Dogajajo se siloviti svetovni procesi, ki izbrana podjetja zavihtijo med uspešna, ostala pa povsem zavržejo. Vse bolj se zdi, da močni informacijski tokovi podjetja, ki ne ujamejo zadnjega vlaka v informacijsko družbo, izrivajo na stranpoti, kjer praviloma samo še usahnejo. Sodobno podjetništvo zahteva od današnjih informacijskih sistemov (v nadaljnjem besedilu IS) podporo odločanja tako vodstvu podjetja za potrebe strateškega odločanja kot tudi na vseh nižjih nivojih za potrebe taktičnega in operativnega odločanja v posameznem podjetju. Podjetje namreč obvladuje IS, če mu uspe iz podatkov pridobiti kvalitetna znanja hitreje od konkurence. IS se danes obravnavajo kot strateška in nikakor le podporna dejavnost. Dandanes se morajo majhna in srednje velika podjetja, če hočejo biti uspešna, usmeriti na trg in se izdatno osredotočiti na potrebe kupcev. Bistveno je, da se znajo spremenljivim potrebam hitro oziroma pravočasno prilagoditi. Da pa bi lahko reakcijski čas čimbolj skrajšali, morajo predvsem dobro poznati sami sebe. Nova organizacijska paradigma zagovarja sodobno reklo "Nič ni stalnega, razen sprememb". Obstoječi, večinoma nepovezani IS, so za današnji čas zelo togi. Mnoga podjetja investirajo ogromna sredstva v njihovo prilagajanje, vendar so rezultati pogosto porazni. Navadno v podjetjih zelo pozno ugotovijo, da so v nadgradnjo obstoječih IS vložili precejšnje vsote denarja ter s tem le za določen čas podaljšali življenjski cikel starega IS. Natančni izračuni bi namreč v večini primerov pokazali, da je čimprejšnji prehod na celovit IS bolj smotrn, tako z ekonomskega kot tudi strateškega stališča. Med kazalci, ki kažejo na potrebo po zamenjavi IS, so visoki stroški samega vzdrževanja IS in dejstvo, da je večina procesov v podjetju togih, ker so podrejeni togemu IS. Celoviti IS ali, kot so najpogosteje imenovani tako v domači kot tuji literaturi, sistemi ERP (ang. Enterprise Resource Planning), so IS, ki upravljajo vse razpoložljive vire, sredstva in aktivnosti v določeni organizaciji oziroma podjetju ter v veliki meri odpravljajo zgoraj naštete težave. So komercialni programski paketi, ki omogočajo integracijo transakcijsko usmerjenih podatkov in poslovnih procesov preko celotne organizacije, pa tudi vzdolž celotne oskrbovalne verige, ki sega skozi več organizacij. Te sisteme tvorijo funkcionalni moduli, ki jih je mogoče kupiti in uvesti neodvisno, glede na potrebe konkretne organizacije. Ponudniki celovitih rešitev so imeli v preteklosti ogromen tržni potencial v velikih podjetjih oziroma sistemih, tako da o majhnih ni nihče niti razmišljal. V zadnjem času pa v literaturi s področja informatike zaznavamo dramatičen zasuk, ko je opaziti veliko tekmo tudi med največjimi svetovnimi ponudniki celovitih rešitev za osvojitev trga majhnih in srednje velikih podjetij. Ponudniki morajo vstopati na trg s povsem drugimi prijemi, na primer s cenejšimi, predhodno nastavljenimi in enostavno namestljivimi programskimi rešitvami. Kljub vsemu pregledne literature za to ciljno skupino še ni moč najti, obstaja le množica člankov, ki pa so večinoma iz sponzorskih razlogov pristranskega izvora. Majhna in srednje velika podjetja ne moremo obravnavati enako kot velika podjetja. Od teh se razlikujejo po organizaciji, načinu dela in informacijskem sistemu. V Sloveniji lahko po določilih Zakona o gospodarskih družbah 93,2% podjetij opredelimo kot majhna podjetja, 4,4% kot srednje velika podjetja in 2,2 % kot velika podjetja (VVerber, Zupančič, 2002, str. 23-24). Majhna in srednje velika podjetja imajo realne možnosti za uspeh, če bodo le znala izpolniti dva osnovna pogoja: hitro odzivanje na spremembe in veliko mero inovativnosti na vseh ravneh poslovanja. Zaradi njihove pomembnosti jim je treba pomagati predvsem na področjih, ki so povezana z novimi IT in elektronskim poslovanjem. Glavne težave pa predstavljajo pomanjkanje informacijskih znanj, nizka ozaveščenost o možnostih IT in slaba informiranost (Hribar, 2002, stran 936). 2. Prenova poslovnih procesov v slovenskih organizacijah Največja ovira slovenskih podjetij pri vključevanju v svetovno poslovno okolje je pomanjkanje konkurenčnosti v primerjavi s podjetji, ki poslujejo v raz- vitih okoljih. Nujni so procesi kot preoblikovanje, prestrukturiranje in prenova poslovnih procesov. Cilji so očitni: nižji stroški poslovanja, krajši izvajalni časi in izboljšava kakovosti nasploh. V preteklosti, ko so še prevladovali IS, ustvarjeni z lastnim razvojem, je uspešno in učinkovito izvajanje poslovnih procesov zahtevalo, da se poslovanje najprej prenovi in šele nato informatizira. Za majhna in srednje velika podjetja je dandanes pravzaprav edina možnost nakup licence komercialnega ponudnika. Z nakupom celovite rešitve smo dandanes priča obratnemu procesu, ko moramo potek poslovnih procesov prilagoditi programski rešitvi, ki nam že ponuja "svoje" poslovne procese (t.i. "best practice"). V nasprotnem je pričakovati velike težave pri namestitvah obnovljenih izdaj in nadgradnjah že uvedene rešitve (VVerber, Zupančič, 2002, str. 248). Pravzaprav se za večje spremembe oziroma predelave celovite rešitve odločamo zgolj pri poslovnih procesih, ki podjetju prinašajo dejansko konkurenčno prednost oziroma so tako specifični, da jih standardno orodje ne more ustrezno programsko rešiti. Pri tem pa zelo trdno velja načelo: vse napake, ki jih naredimo, so zelo drage, dodatno pa nas še zavrejo v razvoju! Vsaka sprememba v podjetju prinaša s seboj nov način delovanja podjetja, nova pravila in procese ter ponavadi spremembo v organizaciji podjetja sami, kar praviloma naleti na določene odpore, ki so povsem naravni. Če spremembe znamo pravilno voditi, se ti odpori lahko povsem nevtralizirajo, tendenca upravljanja sprememb (ang. Change Management) pa je, da se animira uporabnike in vzpostavi pozitivno vzdušje namesto negativnega. Vse to nujno zahteva preskok v mentaliteti zaposlenih oziroma dvig poslovne kulture podjetja. Bistveno je, da tovrstne spremembe podpira vodstvo podjetja in pri njih dejavno sodeluje. Psihološkega vidika uvajanja nikakor ne smemo zanemariti, saj uvedba novega IS močno vpliva na zaposlene, ki so se prisiljeni učiti in spremeniti nekatere ustaljene načine dela. Pri manjših podjetjih so tovrstne težave še izrazitejše, saj imajo ta podjetja največkrat zelo malo zaposlenih šolanih informatikov, v ekstremnem primeru pa celo nobenega. Ker se določena delovna mesta z uvedbo novega IS povsem ukinejo oziroma se temeljito spremenijo, je potrebno, da vodstvo pravočasno obvestimo, naj pripravi program vrednotenja novih delovnih mest, izvede kompenzacijske programe v vmesnem času, če novih delovnih mest ni moč postaviti takoj, ter prenovi sistem nagrajevanja v skladu s spremembami in pričakovanimi rezultati. Brez pravočasne ureditve teh aktivnosti lahko pričakujemo močan odpor ravno tam, kjer bi potrebovali podporo (Chen, 2001, str. 381; Ala-dwani, 2001, str. 269). 3. Vzroki in posledice neustreznega uvajanja celovitih programskih rešitev Med najpogostejša tveganja pri uvedbi celovite rešitve uvrščamo (Gams, 1998, str. 53): ■ nerealno oziroma pomanjkljivo specifikacijo zahtev; ■ neustrezno definiran pogodbeni odnos med kupcem in izvajalcem; e težave pri obvladovanju sprememb; e nepripravljenost naročnika na uvedbo programske rešitve (organizacijsko, kadrovsko, tehnološko); e neustrezen ali nedoločen način komuniciranja med kupcem in dobaviteljem (manjka poslovnik projekta); e nepričakovane stroške uvajanja; e neustreznost kontrolnih pregledov v procesih dobave, uvajanja in vzdrževanja rešitve; e nezadostna ali neustrezna računalniška oprema naročnika; e neustrezno izobraževanje uporabnikov. Določene študije kažejo, da je vzrok za visoke stroške uvajanja velikokrat bolj v kompleksnosti velikih podjetij kot pa kompleksnost rešitev samih. Študija uvajanja celovitih IS v 14 organizacijah na Irskem nakazuje, da je trajanje in kompleksnost uvajanja tovrstnih sistemov močno odvisna od kompleksnosti organizacije (Ahlin, Zupančič, 2001, str. 284). Zato je na mestu ugotovitev, da je uvajanje v manjših organizacijah cenejše in enostavnejše, kot bi lahko sklepali iz ugotovitev in analiz, opravljenih na primerih velikih organizacij. Na drugi strani pa prav manjšim organizacijam še posebej primanjkuje znanja in finančnih sredstev. Zahtevni in kompleksni celoviti IS, ki jih srečujemo v velikih slovenskih podjetjih oziroma sistemih, za manjše organizacije večinoma niso najbolj primerna rešitev. Majhna in srednje velika podjetja namesto teh običajno uvajajo celovite programske pakete, ki so pa v večini primerov povsem primerljivi z največjimi integriranimi rešitvami. Tovrstne rešitve je tudi veliko bolj enostavno vzdrževati in dopolnjevati kot tiste, ki so posebej razvite za neko organizacijo. Običajno njihovo uvajanje ne zahteva tako radikalnih organizacijskih sprememb kot uvajanje velikih celovitih rešitev. So veliko cenejše, lažje jih je prilagajati in mogoče jih je uvesti v relativno kratkem času. Običajno so tudi dokaj dobro prilagojene poslovni kulturi v okolju, za katero so jih razvili. Po drugi strani pa ti celoviti programski paketi ne nudijo takšne palete možnosti kot "pravi" celoviti informacijski sistemi, saj modeli, na katerih so osnovani, niso tako dobro optimizirani in ne pokrivajo vseh poslovnih funkcij. Lahko pa so odvisni tudi od računalniškega okolja ali prilagojeni specifičnim potrebam določene panoge. Kljub prednostim, ki jih ponujajo celovite rešitve, so lahko le-te za določene organizacije tudi zelo neprimerna rešitev. Tak primer so hitro rastoča podjetja, ki hitro (npr. vsako leto) spreminjajo svojo organizacijo. V dinamičnih organizacijah se deli organizacije pogosto prodajajo, novi dodajajo ipd. Za vsako poslovno transakcijo je potreben velik poseg v celoviti IS in je ta strošek potrebno načrtovati že v načrtu projekta. Za tovrstna podjetja je najboljša možnost oddaja informatike v zunanje izvajanje, čeprav ta segment pri nas še ni razvit kot drugod po svetu. 4. Priprava zagonskega načrta za uvedbo celovite rešitve v podjetje Iskra Transmission d.d., Ljubljana V letošnjem letu smo se za uvedbo celovitega IS odločili tudi v podjetju Iskra Transmission d.d. iz Ljubljane, ki zaposluje 150 ljudi. Podjetje se je znašlo pred dilemo: ali obstoječi IS, ki ima sicer določene lastnosti celovitega IS, nadgraditi ali sprožiti projekt uvedbe povsem novega IS. Po analizi stanja projektnega tima, kateremu je vodstvo zaupalo to nalogo, se je izkazalo, da je glede na več kriterijev (navedeni v poglavju 4.1) praktično edina možnost uvedba novega IS. Med glavne kazalce upravičenosti prehoda na povsem nov IS se poleg spodaj navedenih kriterijev (poglavje 4.1) uvrščajo: organizacija se bo v prihodnosti spreminjala, zato bodo potrebne nenehne prilagoditve IS, prisotnost želje managementa po uvedbi procesnega pristopa zaradi lažje optimizacije virov, lažjega vzdrževanja in nadgradenj v novem, celovitem IS. Tržna analiza je izpostavila kot zmagovalca med ponudniki rešitev Navision Attain. Zagonski načrt, ki smo ga v ta namen pripravili, zagotavlja relativno varnost naložbe. Projekt uvedbe celovitega IS se je pričel aprila 2002, t. i. "tek v živo" z vsemi načrtovanimi moduli pa je predviden za marec 2003. V tem obdobju, kakor predvideva zagonski načrt, bomo v podjetju sledili metodologiji proizvajalca, ki je bila le nekoliko prirejena za potrebe podjetja naročnika, panoge, ki ji podjetje pripada ter dosedanjim izkušnjam podjetja izvajalca. Zagonski načrt pokriva vso bistveno problematiko, ki bi lahko kakorkoli ogrozila sam projekt. Zelo pomembna bo kontrola poteka načrtovanih aktivnosti, vrednotenje odstopanj ter dinamičen pristop k morebitnim alternativnim scenarijem. Za uvedbo celovite rešitve je potreben projektni pristop. Preden projekt dejansko zaženemo, je potrebno izvesti temeljito pripravo. To fazo imenujemo zagonski načrt projekta. Na knjižnih policah lahko danes najdemo ogromno literature o projektnem vodenju ter o pripadajočemu zagonskemu načrtu, osnova pa je največkrat skupna. Osnovo izdelave zagonskega načrta ter dodatna znanja o projektnem vodenju smo črpali iz literature o sodobnem vodenju projektov (Stare, 2002; PMBOK, 2000; Hallows, 1998). Ob zagonskem načrtu se vzporedno poskrbi še za dokumentiranje poteka projekta oziroma določi se programsko orodje, s katerim se spremlja in vrednoti potek projekta. Analizirati je potrebno še morebitna tveganja, poleg tega določiti zadolžitve in pristojnosti članov projektnega tima ter določiti poslovnik projekta. Zagonski načrt je odvisen od vrste projekta, običajno ga sestavljajo sledeči elementi (Stare, 2002, str. 30): ■ ideja projekta; ■ ugotovitev skladnosti ideje s poslovno strategijo podjetja; ■ namenski in končni objektni cilj projekta; ■ opis storitve ali izdelka; b potencialni uporabniki, uporaba; b okvirna tržna analiza ali študija izvedljivosti. 4.1. Zagonski načrt projekta Hkrati z izdelavo zagonskega načrta se v podjetju izvajajo intervjuji s ključnimi uporabniki programskih rešitev. Izdelava zagonskega načrta je ena od najpomembnejših aktivnosti in je predhodnica samega projekta uvedbe celovitega IS. Preko zagonskega načrta se ocenijo viri, ki bodo potrebni za izpeljavo projekta, ocenijo se stroški, ki bodo nastajali v posameznih fazah uvedbe, določi se poslovnik projekta ter poda se ocena tveganosti posameznih predvidljivih ovir, do katerih v tako kompleksnem projektu prihaja. Na osnovi teoretskih dognanj smo v podjetju Iskra Transmission d.d., Ljubljana, najprej pristopili k oblikovanju strateškega načrta informatike, ki sledi iz strateškega načrta podjetja. Na osnovi tega je ena od prioritetnih nalog uvedba celovitega IS v podjetje Iskra Transmission d.d., ki se ukvarja z razvojem in proizvodnjo prenosnih telekomunikacijskih sistemov in po vseh kriterijih ZGD' sodi med srednje velika slovenska podjetja. Proces uvedbe se prične z diagnostično študijo, katere cilj je analiza obstoječega stanja, želja uporabnikov, različnih ciljev ter zahtev. Analogno je potrebno ugotoviti ustrezne potrebe po strojni in programski opremi ter ustreznem ožičenju. Projekt bo zaključen, ko bo programska oprema podrobno testirana glede zadovoljevanja zahtev uporabnikov (naročnika projekta) ter pripravljena za uporabo. 1 1 Zakon o gospodarskih družbah; Uvedba novega integriranega poslovnega IS bo zagotovila izvedbo naslednjih strategij: omogočanje novih poslovnih strategij (uvedba novih programov); omogočanje strategije rasti (penetracija na nove trge); raztegnitev nabavne verige (znižanje stroškov, povečanje kvalitete); povečanje odzivnosti kupcev (zadovoljstvo kupcev). Operativni cilji podjetja za obdobje od 3-5 let, ki jih bo omogočila uvedba celovte-ga IS, so: povečati produktivnost; izboljšati kvaliteto informacij in vpogled vanje; izboljšati tehnološko infrastrukturo; povezati poslovne procese; zmanjšati stroške poslovnih procesov; zmanjšati odzivne čase. V podjetju menimo, da je trenutek za uvedbo novega, celovitega IS, zelo ugoden iz več razlogov: b obstoječi IS je razdrobljen na več parcialnih rešitev (t. i. informacijski otočki), med katerimi ni direktne povezave; b prihaja do neažurnosti podatkov in večkratnih vnosov istih podatkov; b informatizirani so le delni in ne celoviti poslovni procesi; b razdrobljene podatkovne baze ne omogočajo podpore odločanja vodstvu in drugim odločevalcem v podjetju; b obstoječi IS omogoča le zelo omejene nadgradnje in je slabo dokumentiran; b število uporabnikov in struktura organizacije se bosta v prihodnosti bistveno spremenila, potrebne bi bile obsežne nadgradnje obstoječega IS; b poslovni procesi v podjetju so nepregledni, izvajalci nanje gledajo parcialno in ne kot na celovit poslovni proces; b poslovni procesi niso optimizirani; b trenutne razmere v podjetju (združitev več podjetij) same po sebi motivirajo uporabnike programskih rešitev, da razmišljajo o poslovnih procesih, v katere so vpleteni; b kadrovsko je podjetje pripravljeno za prehod na celovit IS, saj je pristop k informatizaciji poslovanja temeljit in projektno voden. 5. Cilji in mejniki projekta Namenski cilj projekta je uspešna uvedba celovitega IS Navision Attain z načrtovanimi lastnostmi v načrtovanem terminskem načrtu in v okviru načrtovanih stroškov. Zelo pomemben cilj je tudi kakovost uvedbe. V nadaljevanju so izpostavljeni načrtovani merljivi cilji, ki jih bo podjetje doseglo v času uvajanja metode. Grobe ocene prihrankov oziroma izboljšav poslovanja, izražene v odstotkih izboljšav, primerjalno z aktualnimi vrednostmi, so: b 20 % skrajšanje časa interne in eksterne oskrbovalne verige (oskrbovalna veriga); ■ 80 % izboljšanje podpore odločanju vodstveni strukturi (analitika); ■ 25 % povečanje prodaje zaradi učinkov CRM modula; ■ 30 % zmanjšanje administrativnih stroškov zaradi izpada podvajanja podatkov in optimizacije procesov, kot posledica uvedbe integriranega IS; ■ 15 % delavcev prerazporejenih na deficitarna delovna mesta zaradi povečanega izkoristka integriranega IS. Poleg tega so strateško zelo pomembni nemerljivi učinki uvedbe IS, kot so povečanje kakovosti izdelk- ov, ohranjanje konkurenčne prednosti, zadovoljstvo kupcev in samih uporabnikov IS, pregled nad poslovanjem na vseh nivojih ter podpora odločanju na vseh nivojih "Mehke" koristi bomo v podjetju po internem posvetovanju ustrezno obtežili s posameznimi faktorji v skladu s tem, koliko so za podjetje pomembne, da bomo lahko določili donosnost same naložbe po standardnih metodah za določitev donosnoti projektov. Mejniki projekta (ang. milestones) so kontrolne točke projekta, kjer še posebej natančno ugotavljamo vmesni cilji strategija projekta obremenitev izvajalcev načrt časovnega nadzora izvajanja vmesni in končni rok za izvedbo stroški preostalih virov (tima, materiala) časovne ocene taktika izvedbe NAČRT STROŠKOV načrt prihodkov oz. koristi razpoložljivi izvajalci mejniki stroški izvajalcev medsebojna povezanost aktivnosti načrt nadzora stroškov projekta matrika RAC MREŽNI IN TERMINSKI NAČRT IZRAČUN DONOSNOSTI PROJEKTA PREDLOG PROJEKTA namenski cilj končni objektni cilj VVBS-RETROGRADNA ČLENITEV PROJEKTA Legenda: WBS - ang. Work Breakdown S tructure: struktura seznama aktivnosti; RAC - ang. Responsibility and Competence Matrik: matrika odgovornosti in pristojnosti; Slika 1: Proces načrtovanja projekta Vir: Stare, 2002, str. 29. odstopanja od načrtovanih vrednosti. Osnovna kriterija sta vsekakor čas in stroški, vseskozi pa preverjamo tudi kakovost storitev izvajalca ter prilagajamo v okviru novih spoznanj možne alternativne rešitve, vezane na kritične dejavnike projekta, ki bi se utegnili zgoditi. Iz metodologije proizvajalca Navision z imenom "On target" (glej sliko 2) smo za naš projekt definirali naslednje mejnike: diagnostična študija, ponudba sistema, pogodba, analiza, dokument funkcionalnih potreb, oblikovanje sistema, sistemski test, implementacija ali uvedba, predaja rešitve ter vzdrževanje. 6. Strategija projekta Strategija projekta izhaja iz izraženih zahtev za celovit IS in končnih ciljev projekta. Je posledica strateškega načrta informatike, ki izhaja iz strateškega poslovnega načrta podjetja. 6.1. Proces uvedbe integriranega informacijskega sistema v majhno oziroma srednje veliko podjetje Ker ima vsak ponudnik celovitih rešitev lastno metodologijo uvajanja, smo v nadaljevanju za nazoren prikaz izbrali kot osnovo metodologijo "On Target" ponudnika Navision (interno gradivo družbe Avto-tehna d.d., sektor RIS - razvoj informacijskih sistemov, Ljubljana). Analiza - namen analitskega dela uvajanja je, da neprestano spremljamo projekt uvajanja novega IS, ki postane s tem sistematičen in transparenten. S sprotnimi potrditvami korakov metodologije se zagotovi stalen in sproten nadzor naročnikav. V tej fazi se izvede celovita analiza poslovnih procesov naročnika in oceni sistemske potrebe. Te ugotovitve se dokumentirajo v Dokumentu funkcionalnih potreb. Osnovni predpogoj za premik v naslednjo fazo projekta je nesporno strinjanje naročnika z dokumentom. Fazo analize tvorijo: ■ priprava projekta in načrtovanje; ■ namestitev testne programske opreme pri stranki; ■ usposabljanje ključnih uporabnikov; ■ zbiranje vseh baz podatkov; ■ osnovni intervjuji in delavnice za zbiranje podatkov o potrebah posameznih oddelkov v podjetju; ■ priprava in revidiranje funkcionalnih potreb. V praksi diagnostično ali uvodno študijo (Vintar, 1996, str. 82) poimenujejo tudi idejni projekt ali študija upravičenosti (ang. feasibility study). Cilji so: ■ preveriti realnost projekta samega (ali je podjetje dovolj pripravljeno); ■ določiti delovna področja, kamor naj bo projekt usmerjen; ■ podrobno opredeliti cilje izboljšav (nova funkcija v procesu, sledenje informacij, znižanje stroškov ipd.); kvalifikacija stranke kontrolni vprašalnik Metodologija Navision Metodologija prodaje pozicioniranje diagnostika ponudba ponudba metodologije diagnostična študija ponudba sistema obveza pogodba Metodologija implementacije ► analiza oblikovanje razvoj implementacija podpora ► dokument funkcionalnih potreb oblikovalni dokument sistemski test revizija implementacije vzdrževalna pogodba Slika 2: Shema metodologije "On Target" Vir: interna dokumentacija Avtotehna d.d., sektor R/S - razvoj informacijskih sistemov ■ podrobno opredeliti način, kako bomo projekt izvedli (tehnologija, standardi ipd.); ■ ugotoviti potrebe po znanjih izven podjetja naročnika in jih ovrednotiti. Diagnostična študija pomaga pri določanju obsega projekta in pokaže okviren obseg potrebnega dodatnega dela, tveganja in stroške, ki so povezani z njim. Na osnovi izdelane študije lahko naročnik razpiše natečaj ali pa neposredno kontaktira ponudnike celovitih rešitev in na osnovi dodatnih kriterijev oceni njihovo primernost. Po opravljeni izbiri se naročnik z izbranim partnerjem pogaja o določilih pogodbe in jo finalizira. S podpisom pogodbe projekt preide v fazo uvedbe IS. Diagnostična študija je relativno kratko poročilo (brez izrazitih podrobnosti), kjer so jasni predlogi, namenjeni vodstvu podjetja naročnika. Študija je za naročnika križišče treh alternativ: nadaljnje delo odobri, zahteva, da se definicija naloge spremeni v skladu z ugotovitvami študije ali pa nadaljnje delo zavrne (Vintar, 1996, str. 84). Diagnostika se praktično izvede bodisi z preučevanjem razpoložljivega pisnega gradiva (ISO procesi, star poslovni IS, proizvodni procesi ipd.), intervjujev s ključnimi uporabniki, z anketami, z opazovanjem, z merjenjem oziroma vzorčenjem (količine podatkov, določene čase izvedbe, frekvence transakcij ipd.). Vsaka od metod ima svoje prednosti in slabosti, glede na stanje, v katerem je podjetje. Oblikovanje - sledi oblikovanje sistema oziroma izdelava Oblikovalnega dokumenta, kjer se vizualni vmesnik prilagaja potrebam in željam naročnika. Končna oblika sistema se vpiše v Oblikovalni dokument, ki v bistvu predstavlja kar priročnik za uporabo sistema. Vsekakor mora biti dokument napisan na način, ki bo razumljiv končnemu uporabniku. Po podpisu sklepne dokumentacije se izvrši nastavitev rešitve glede na dokumentacijo ter se pripravi vse potrebno za uvedbo rešitve. Pogodbeni partner oblikuje in predstavi arhitekturo in načrt uvedbe novega sistema v Oblikovalnem dokumentu. Fazo oblikovanja tvorijo: ■ oblikovalni sestanki s člani projektne skupine; ■ oblikovanje prototipov uporabniških vmesnikov, zaslonskih slik in poročil; ■ zaključek načrtovanja migracije podatkov in integracije sistemov; ■ priprava načrta testiranja sistema; ■ priprava in predstavitev Oblikovalnega dokumenta projektni skupini; b priprava in predstavitev Predloga implementacije nadzorniku projekta; b podpis in potrditev Oblikovalnega dokumenta in Predloga uvajanja; b podrobnejše oblikovanje sistema in priprava načrta delovnih verzij. Razvoj in testiranje - v tej fazi so razvite in testirane posebne prilagoditve programske rešitve za naročnika. V tem času se pri naročniku namesti testna programska oprema. Fazo razvoja in testiranja tvorijo: b modifikacije tabel, obrazcev, rutin in uporabniških vmesnikov; b uvajanje programske opreme; b razvoj vmesnikov za konverzijo podatkovnih baz; b razvoj vmesnikov med različnimi celovitimi sistemi; b usposabljanje osebja za testiranje; b testiranje delovnih verzij in celotnega sistema. Na tej točki se preveri delovanje sistema, po potrebi se izvedejo dodelave, predelave; s tem se izognemo kasnejšim podvajanjem dela. Vse programsko delo se dokumentira. Po zadnjem preizkusu se sistem namesti, združen notranji in zunanji uvajalski tim pa izvede končno preizkušanje sistema. S podpisom uspešno opravljenega sistemskega preizkusa je delo pri naročniku končano. V odvisnosti od tega, kako ob uvedbi vodimo dokumentacijo v naštetih fazah, je odvisna tudi nadaljnja podpora izvajalca. Namestitev - v fazi namestitve se sistem v celoti namesti pri naročniku, splošno šolanje uporabnikov se zaključi. Fazo namestitve tvorijo: b dokončanje uporabniške dokumentacije; b dokončanje nastavitev sistema; b vnos ali prenos začetnih računovodskih stanj; b vnos ali prenos preteklih transakcij; b usmerjeno usposabljanje uporabnikov; b potrjevanje sistema na nižjih in višjih nivojih uporabnikov; b začetek delovanja sistema ("tek v živo" ali ang. "Go Live"). Skladno z uvedbo novega IS je potrebno pripraviti tudi bazo podatkov. Kompleksnost podatkov IS se odraža skozi število tipov entitet, število atributov in številom povezav med tipi entitet. Vse skupaj ponazarja podatkovni model, ki je opisan v katalogu podatkov (ta je podan kot rezultat analize sistema ter informacijskih potreb naročnika). Le-ta služi kot model za načrtovanje podatkovne baze. Večina organizacij upravičeno postavlja čas tranzicije na nov sistem za enega ključnih kriterijev pri izbiri novega IS. Zato je potrebna visoka stopnja doslednosti prav v obdobju priprave na prehod. Smiselno je torej izbrati način prehoda, ki bo čim manj tvegan in ki bo čim manj motil tekoče poslovanje podjetja. Med številnimi kombinacijami prehodov so se v praksi še najbolj uveljavili (Gradišar, Resinovič, 2001, str. 427) direktni ali neposredni prehod (ang. big bang), vzporedni (paralelni) tek, pilotni tek, fazni ali postopni prehod. Z naborom funkcionalnih modulov, ki smo jih določili za prvo fazo uvedbe (izbran je bil fazni prehod) na osnovi diagnostične študije, pridobimo v podjetju rešitev za obe področji poslovanja, navznoter in navzven. Slabost faznega prehoda je v tem, da bo projekt raztegnjen na 216 dni, seveda pa bo zaradi tega nekoliko zmanjšano tveganje samega prehoda. Na osnovi dosedanjih analiz ocenjujemo, da bo možno večino (približno 90 %) poslovnih procesov prilagoditi procesom, ki jih vsebuje programska rešitev. Ker smo z večino odgovornih funkcijskih vodij, ki sodelujejo pri projektu uvedbe celovitega IS, enotni, da predlagani poteki procesov prinašajo določene prednosti, smo mnenja, da večjih posegov v programsko rešitev ne bo treba. 7. Taktika izvedbe projekta S taktiko opredelimo orodja in tehnike za izvedbo projekta, določi se stil vodenja projekta, izbira izvajalcev ipd. Že pred samo namestitvijo programske rešitve je potrebno izšolati ključne uporabnike. Namen dodatnega preliminarnega šolanja ključnih uporabnikov je ozaveščenost in seznanjanje s funkcionalnostjo ter zgradbo IS. S pozitivnim odnosom do projekta uvedbe naj bi ključni uporabniki potegnili za seboj tudi ostale pripadnike svojih oddelkov. Da bi ponudnik pripravil ustrezno ponudbo, mora pridobiti čimveč relevantnih informacij o načinu poslovanja podjetja. Za pripravo izhodiščnih kriterijev za ponudbo obstaja obilo napotkov in literature, za vse aktivnosti tega dela projekta pa bi priporočili praktičen pregled možnih napak (Petersen, Carco, 1998, str. 79-97 in str. 123-175), ki jih lahko zaradi pomanjkanja izkušenj naredi podjetje, ki celovit IS uvaja. Projekt je v pravno-formalnem smislu razdeljen na dva dela, in sicer pred in po podpisu kupoprodajne pogodbe oziroma v primeru uvedbe IS govorimo o definiranju obveze. Pogajanja vodi vodja projekta ob pomoči finančnega nadzornika projekta in interne pravne službe. Ob tem je potrebno poznati tudi pravne vidike in standarde, ki veljajo v Sloveniji za programsko opremo. Prav tako je zelo dobrodošlo poznavanje splošnih uzanc v panogi računalništva. 8. Izbira programske rešitve in njenega ponudnika Pri izbiri najboljšega ponudnika smo se v podjetju držali priporočil (Ahlin, Zupančič, 2001, str. 287) za majhno ali srednje veliko podjetje, ki se odloča za uvajanje integriranega IS: ■ obvezno je potrebno opraviti analizo obstoječega stanja, ki naj bo kar se da temeljita v bistvenih postavkah; ■ analizo naj po možnosti izvaja neodvisni svetovalec (neobremenjen s podjetjem ali programsko reš- itvijo), čeprav je to v našem prostoru zaradi nerazvitosti trga še velika redkost; ■ če v analizi stanja sodelujejo ljudje, ki so že delali analizo v sorodnih podjetjih, je to precejšnja prednost; ■ programska rešitev naj zagotovlja podporo tudi dislociranim enotam podjetja, pri čemer naj vse enote uporabljajo isto bazo podatkov. Pri izbiri smo upoštevali sledeče kriterije (Ahlin, Zupančič, 2001, str. 288): ■ izvajalno podjetje nam je moralo podati seznam referenčnih projektov; ■ že pred projektom uvajanja smo natančno opredelili naloge, ki jih je potrebno realizirati v procesu uvajanja celovitega programskega paketa; ■ izvajalno podjetje je dolžno zagotoviti dovolj močno ekipo; velja nepisano pravilo, da mora imeti za vsak del programskega paketa usposobljena vsaj dva človeka, od katerih eden dela poln delovni čas oziroma v skladu s terminskim načrtom na projektu; ■ izvajalno podjetje mora določiti kompetentnega koordinatorja oziroma vodjo eksternega tima, ki predstavlja vhodno točko za naročnika; ■ od proizvajalca programske opreme mora izvajalec pridobiti vsa potrebna dokazila, da zna rešiti vse dogovorjene oziroma pričakovane tehnične probleme; ■ proizvajalec programske opreme mora imeti certifikat kakovosti. Za izbrano rešitev je projektni tim postavil kriterije, katerih ustreznost je presodila interna komisija podjetja, ki rešitev uvaja. Posamezne odgovore na spodnje kriterije smo vrednotili in ugotovili primernost posameznega ponudnika: ■ enostavna uporaba programa; ■ prijetnost videza uporabniškega vmesnika; b popolnost funkcij, ki so povezane z določenim poslovnim procesom; b preglednost razpoložljivih informacij; b navzkrižna dostopnost informacij; b zaščita programske rešitve pred nedovoljenimi operacijami; b prilagodljivost programa lastnim potrebam; b povezanost delov IS. V nadaljevanju so podana splošna izhodišča za sodobni integriran IS (Kovačič, 1997, str. 11): b izdelan mora biti s sodobnim orodjem, ki omogoča objektni pristop k razvoju in uporabi rešitve; b imeti mora z odzivom na dogodke krmiljeno zasnovo; b rešitve ne pogojuje okolje operacijskega sistema (odprti OS - npr. Unix, MS); b razvit in dokumentiran mora biti z ustreznim orodjem ČASE (ang. Computer-Aided Softvvare Engineering); ■ rešitev mora imeti rta voljo v izvorni ali vsaj pa-rametrizirani kodi; ■ rešitev mora uporabljati skupno in enovito bazo podatkov; ■ omogočena mora biti tipizirana uporaba funkcij na vseh modulih; ■ dobavitelj mora sodelovati pri uvedbi rešitve (zagotoviti zadostno število izvajalcev); ■ vnaprej mora biti definirano vzdrževanje programske rešitve. Celovit IS mora imeti naslednje lastnosti2, ki so pomembne za poslovanje podjetja: ■ povezan je v vseh poslovnih funkcijah; ■ zagotovljena je varnost podatkov in zanesljivost delovanja; ■ skladen je z zakonodajo in standardi; ■ izdelan je s sodobnim objektno usmerjenim informacijskim orodjem ČASE; ■ rešitev ne pogojuje okolje OS (odprti sistemi, npr. UNIX, Microsoft); ■ zagotovljen je dolgoročen partnerski odnos z dobaviteljem; ■ rešitev je na voljo v izvorni (ali parametrizirani) kodi; ■ ima primeren (kratek) čas uvajanja; ■ je cenovno sprejemljiv. Pri vseh ponudnikih smo poleg dokazanih referenčnih projektov in pridobljenih certifikatov preverjali tudi samo demonstracijo in odzivnost v času vrednotenja morebitnih izvajalcev. Nekaj pomembnejših kriterijev omenjene faze: ■ prepričljivost demonstratorja; m demonstratorjevo poznavanje problematike; ■ demonstratorjevo poznavanje specifičnih problemov; ■ razumljivost in nedvoumnost demonstratorjevih problemov ter e splošni vtis. 9. Ekonomika projekta Skupni stroški lastništva (ang. TCO -Total Cost of Ovvnership) obsegajo licence, stroške uvajanja, izobraževanja uporabnikov, prenos podatkov iz starega v novi sistem in tekoče vzdrževanje. Načeloma lahko pride tudi do dodatnih, nepredvidenih stroškov, toda skupni stroški lastništva ponavadi obsegajo vsaj 90 % vseh stroškov. Če se osredotočimo na donosnost naložbe (ang. Return on Investment - ROI) v celovit IS, ugotovimo, da celoviti IS vplivajo praktično na vse vidike poslovanja in dele organizacije, zato je težko opredeliti merila, ki opisujejo uspešnost uvajanja teh sistemov. Zavedati pa se je potrebno predvsem dejstva, da celovit IS sam po sebi ne prinaša donosnosti naložbe, temveč izboljšanje poslovnih procesov, ki jih ta IS omogoča. Ne glede na to, kako dober je nov IS, ne prinaša velikega vpliva na izboljšanje poslovanja, če razen uvedbe ne naredimo ničesar drugega. V tem primeru lahko pričakujemo podobne, če ne celo slabše rezultate poslovanja, kot smo jih imeli pred uvedbo. Na drugi strani pa lahko novi IS omogoči in podpre veliko novih poslovnih procesov, pod pogojem, da se v podjetju teh procesov zavedajo, sprejmejo njihovo uporabo in dejavno podprejo njihovo informatizacijo. Donosnost naložbe nam zagotavljajo racionalizacija, standardizacija ter poenostavitev poslovanja. Večje "probleme" pri ocenjevanju donosnosti naložbe pa nam ustvarjajo koristi celovitega IS, ki jim pravimo tudi "neotipljive" koristi in jih ne moremo enostavno kvantificirati. Več ko imamo neotipljivih koristi, težje določimo čas povrnitve naložbe. In prav majhna in srednje velika podjetja prednjačijo v teh koristih. V okviru zagonskega načrta je potrebno pripraviti strategijo financiranja projekta, kjer so razvidni stroški po seznamu aktivnosti, podan mora biti načrt financiranja posameznih materialnih in nematerialnih virov. Investicija projekta mora biti usklajena s poslovnim in finančnim načrtom podjetja, vsebinsko in časovno. Prav tako morata biti usklajena preskrba in aktiviranje načrtovanih sredstev projekta. Med stroške projekta informatizacije uvrščamo: Stroške dela: nagrajevanje članov projektnega tima; poznati je potrebno čas udeležbe posameznih članov na projektu; poznati je potrebno strošek dela na enoto časa; Stroški storitev: stroški svetovalnih storitev zunanjih sodelavcev projekta; analogno z gornjo točko je tudi tu potrebno poznati potreben čas in stroške na enoto; Materialni stroški: so neposredno povezani z izvajanjem projekta; tu mislimo bolj neposredne stroške, ki nastanejo zaradi projekta samega (določena strojna oprema, potrebna za namestitev in testiranja, učilnica za izobraževanje ipd.). Stroški pisarniškega materiala, energije ipd., se običajno ne obračunavajo po porabljenem materialu, temveč se v stroškovniku posamezni fazi uvedbe IS doda neko ocenjeno pavšalno vrednost in s tem pokrije omenjene stroške. Izdelan predračun stroškov projekta se po potrditvi nadzornika ter finančnega nadzornika projekta vgradi v globalni načrt financiranja projekta za celotno obdobje trajanja projekta. Poleg predračuna stroškov je potrebno z naložbeno politiko podjetja izdelati in uskladiti tudi predračun naložb, ki vsebuje: 2 Zahteve oblikuje interni projektni tim na osnovi poznavanja podjetja, trendov na področju integriranih IS in analize ponudnikov. ■ naložbe v stalna sredstva: pri našem projektu je to strojna oprema, nadgradnja računalniške opreme, programske licence; ■ naložbe v gibljiva sredstva: denarna sredstva za financiranje tekočih stroškov projekta. Predračun naložb skupaj s predračunom stroškov sestavljata globalni načrt financiranja projekta. 10. Projektna organizacija Projekt ima poleg vodje projekta tudi nadzornika projekta in finančnega nadzornika projekta. Oba, skupaj z vodjo projekta in vodjo izvajalnega tima, tvorita projektni svet, ki je najvišji organ projekta, kjer se rešujejo zgolj strateška vprašanja. Odgovorni funkcijski vodja je odgovoren za izvajanje nalog na svojem funkcijskem področju. V dogovoru z izvajalci določa prioritete posameznih aktivnosti in nato spremlja verodostojnost njihovega izvajanja. Nudi razpoložljivost načrtovanih kadrov oziroma virov, izvajalcem zagotavlja čas, da se dosežejo cilji projekta. V skladu s poslovnikom poroča vodji projekta. Projektni svet sestavljajo nadzornik projekta, finančni nadzornik projekta, vodja projekta ter vodja projekta podjetja izvajalca. Naloga je potrjevanje zagonskega načrta projekta, iskanje in potrjevanje najustreznejših virov financiranja, določa kontrolne točke projekta ter skrbi, da so kazalniki uspešnosti projekta ves čas ugodni. Projektni svet poroča neposredno glavnemu direktorju podjetja, ki programsko rešitev uvaja. Odgovornosti vodje projekta so podane v posebni matriki, imenovani matrika RAC (ang. Responsibil-ity and Competence), poleg tega vodja projekta v splošnem skrbi za doseganje rezultatov projekta, določa vloge in odgovornosti članom tima, dodeljuje naloge, kontrolira napredovanje projekta, v primeru odstopanja od načrta poskrbi za ustrezne ukrepe, je v stalnem stiku z nadzornikom projekta in finančnim nadzornikom projekta. Nadzornik projekta zagotavlja in skrbi, da je usmeritev projekta v skladu s strateškimi cilji podjetja. Osnovne naloge: ■ potrjuje proračun in načrt za projekt uvedbe rešitve Navision Attain; m opredeli pričakovanja in kazalnike uspešnosti za projekt; ■ sprejema odločitve glede politike podjetja; ■ ustvarja ustrezno okolje za spremembe; ■ preverja status projekta; ■ potrjuje ključne dokumente ob zaključku pomembnejših faz projekta. Finančni nadzornik projekta ima sledeče osnovne naloge: ■ zagotavlja vire financiranja za potrebe projekta; ■ skupaj z vodjo projekta sestavi globalni načrt financiranja projekta; ■ določi finančne kazalnike uspešnosti projekta; ■ pravočasno poroča nadzorniku projekta ter vodji projekta o morebitnih težavah v zvezi s financiranjem. 10.1. Poslovnik projekta Poslovnik projekta določa način delovanja projektnega tima. Projekt se vodi in kontrolira s programskim orodjem večuporabniške verzije, kjer imajo lahko vsi člani tima trenuten vpogled v stanje na projektu, v načrtovane aktivnosti in pričakovane stroške, ki so načrtovani za izvedbo le-teh. Poleg tega lahko tudi aktivno posegajo v program glede na pristojnosti, ki so jim dodeljene na projektu. Vsako spremembo lahko interaktivno prikažejo tudi na intranetu podjetja, jo izvozijo v določen format in pošljejo izbranim naslovnikom ipd. Z istim orodjem se tudi preverja razpoložljivost kadrov, saj programsko orodje omogoča delo s konsolidiranimi projekti in pa nadzor zasedenosti virov, ki so dodeljeni več projektom hkrati. V načrtu kontrole izvajanja projekta so definirani datumi kontrole izvajanja projekta. Datumi soupadajo z Tabela 1: RAC ali matrika odgovornosti in pristojnosti na projektu: VP VI NP FN Definicija ciljev 1 P Tržna analiza 1 p P Zahteve za IS S 0 p S Izdelava zagonskega elaborata 1 s p p Priprava poslovnika projekta 1 s p Vzpostavitev projektne organizacije 0 s p Organiziranje virov, vodenje tima, motivacija izvajalcev 0 s s Ukrepanje v primeru odstopanj 0 s p s Upravljanje in nadzor stroškov s p s Časovni nadzor projekta s s p Skrb za kakovost s s Komuniciranje 0 s Pogajanja z izvajalcem (pravni, finančni vidik) s p 0 Poročanje nadzorniku projekta 1 s Zaključno poročilo projekta 1 p p Legenda: VP-vodja projekt, I—izdela, Vl-vodja podjetja izvajalca, P-potrdi, NP-nadzornik projekta, S-sodeluje, FN-finančni nadzornik projekta, 0-poda odgovore datumi v mrežnem načrtu in soupadajo z vmesnimi cilji projekta. Nadzornik projekta bo imel vpogled v programsko orodje, preko katerega se bodo izvajale kontrole poteka projekta (npr. Microsoft Project), kjer je možno v vsakem vmesnem trenutku pogledati presek stanja projekta in morebitna odstopanja od zastavljenega načrta projekta (ang. "baseline"). 11. Ključni dejavniki ali dejavniki uspešnosti projekta Obvladovanje motenj oziroma analiza dejavnikov tveganja projektov (ang. Risk Management) je področje projektov, ki je še vedno preveč zapostavljeno. Bolj ko imamo predvidene določene negotovosti in izdelane alternativne scenarije, ki te negotovosti nevtralizirajo, manj smo ranljivi pri ovirah, ki nam prihajajo naproti, manjše so zamude na projektu in manjši so tudi stroški. V ta namen je potrebno tveganja identificirati, oceniti verjetnosti, da se tveganja zgodijo, oceniti možne posledice, ki jih tveganja nosijo s seboj ter posledično izračunati faktor rizika. Projektni svet določa, katera stopnja faktorja rizika sproža vnaprej določene varnostne mehanizme, ki tveganja učinkovito odpravijo. Posamezne verjetnosti, da do potencialnega problema pride, so rangirane od 1 do 5, pri čemer je 1 najmanjša verjetnost, 5 pa največja. Prav tako so od 1 do 5 rangirane ocene posledic, kjer so z 1 ocenjene posledice, ki povzročijo najmanj škode, s 5 pa največ. Morebitna tveganja se lahko rešujejo tudi z rezervacijo dodatnega časa na projektu. Ker je v obravnavanem primeru čas kritičen, smo pripravili strategijo reševanja problemov za projektni tim in koordinacijo vodje projekta. Kritična meja (določi jo Projektni svet), ko je potrebno urgentno zasedanje nadzornikov projekta in vodstva projekta, nastopi pri faktorju rizika 15. Iz tabele lahko ugotovimo, da se pri projektu najbolj bojimo izraženega odpora do sprememb med trajanjem projekta (16), zaradi polne zasedenosti resursov obstaja možnost težav z razpoložljivostjo kadrov (15), bistvena pa sta tudi kontinuirana podpora vodstva ves čas trajanja projekta (15) ter minimalna fluktuacija ključnih kadrov v času trajanja projekta. 12. Zaključek Ko je celovit IS enkrat nameščen, je projekta uvedbe sicer konec, a zavedati se je treba, da je IS del podjetja in da z njim živi. Vsekakor celovit IS ni nekaj statičnega, zato je potrebno poskrbeti za primerno Tabela 3: Opredelitev tveganj projekta Potencialni problem VE OP FR Predlog rešitve 1 Pomanjkanje ustreznih virov sredstev 2 5 10 preveriti vire sredstev in alternativne možne vire 2 Sinergija skupinskega dela 3 4 12 pogovor s člani tima 3 Ni podpore vodstva 3 5 15 ponovna predstavitev projekta s scenarijem možnih posledic in analizo konkurence 4 Nedorečene zahteve za IS 4 3 12 dodatni intervjuji s ključnimi uporabniki programskih rešitev 5 Pomanjkanje strokovnega kadra 2 5 10 pripraviti alternativno rešitev, rezervacija kadrov 6 Člani tima niso motivirani 3 4 12 natančnejša opredelitev ciljev, dodatna motivacija članov tima 7 Uporabniki izražajo močan odpor do sprememb 4 4 16 predstavitev projekta po funkcijskih skupinah in po oddelkih 8 Ustreznost vodje projekta 2 5 10 zamenjati vodjo projekta 9 Ustreznost izvajalca 2 5 10 hitra in učinovita analiza izvajalca, po potrebi zamenjava izvajalca 10 Neustrezna oziroma pomanjkljiva komunikacija 3 3 9 revizija poslovnika, ojačati neformalni del komunikacije med člani tima 11 Odstopanja od strateškega načrta podjetja 1 5 5 revizija poslovnega načrta podjetja na kolegiju podjetja 12 Neustrezna razpoložljivost načrtovanih kadrov 3 5 15 intervencija pri nadzorniku projekta, ki poskrbi za dodelitev virov 13 Neustrezno izobraževanje uporabnikov 2 5 10 revizija načrta šolanja uporabnikov 14 Neustrezne spremembe poslovnih procesov 3 4 12 analiza možnosti in stroškov prilagoditve programske rešitve poslovnemu procesu 15 Reševanje ozkih grl 4 2 8 hitro in učinkovito odločanje 16 Fluktuacija ključnih ljudi projekta 3 5 15 dobro definirani pogodbeni in partnerski odnosi Legenda: VE - verjetnost, da do potencialnega problema pride, OP - ocena posledic, če do problema pride, FR - faktor rizika (zmnožek obeh) vzdrževanje. S tem ni mišljeno le "klasično" vzdrževanje, temveč povsem aktiven pristop v smislu spremljanja trendov, možnosti nadgradnje, oblikovalnih možnosti same programske rešitve ter vseh drugih možnosti, ki jih na trg periodično plasira proizvajalec rešitve. Vsekakor je ves čas potrebno imeti pred očmi končni cilj, to je uvedba novega IS, ki bo v čim boljši korelaciji oziroma v definiranih tolerančnih mejah z načrtovanimi stroški in terminskimi roki. S tem bo izpolnjen potreben pogoj uspešnosti projekta. Za izpolnitev zadostnega pogoja se bodo morali opredeliti uporabniki, vodstvo podjetja in zaposleni s preprostim kriterijem - z zadovoljstvom uporabe. 13. Literatura Hallovvs Jolyon: Information Systems Project Management. New York: Amacom - American Management Association, 1998. 283 str. Stare Aljaž: Priprava in izvedba projekta. Ljubljana: Agencija Poti, 2002. 47 str. Interni arhiv podjetja Avtotehna d.d., Sektor RIS, Ljubljana: Programska rešitev Navision Attain. PMBOK, A Guide to the Project Management Body of Knovvledge. ZDA: Project Management Institute, 2000. 216 str. Ahlin Tomaž, Zupančič Jože: Uvajanje celovitih programskih paketov. Kranj, revija Organizacija, letnik 34, št. 5, maj 2001. str. 283-289. Aladwani Adel M.: Change Management strategies for successful ERP implementation. MCB University Press: Business Process Management Journal, Vol. 7, No. 3, 2001. str. 266-275. [URL: http://www.emerald-library.com/ft], 12.2.2002. Chen J. Injazz: Planningfor ERP systems: analysis and future trend. MCB University Press: Business Process Management Journal, Vol.7, No. 5, 2001. str. 387-393. [URL: http:// www.emerald-library.com/ft], 23.3.2002. Gams Matjaž: Informacijska družba 1998. Prva izdaja. Ljubljana: Institut Jožef Stefan: Državna založba Slovenije, december 1998. 148 str. Gradišar Miro, Resinovič Gortan: Informatika v poslovnem okolju, 3. dop. in razšir. natis. Ljubljana, Ekonomska fakulteta, 2001. 508 str. Hribar Uroš: Elektronsko poslovanje malih in srednje velikih organizacij v Sloveniji. Kranj: založba Moderna organizacija, Zbornik konference z mednarodno udeležbo (Portorož), 2002. str. 936-946. Kovačič Andrej: Kakšne uporabniške programske rešitve potrebujemo? Ljubljana: Revija Uporabna Informatika, letnik V, št. 1, 1997. str. 8-15. Kovačič Andrej et ab: Prenova poslovnih procesov v slovenskih organizacijah. Ljubljana: revija Uporabna informatika, letnik Vlil št. 1, 2000. str. 22-27. Petersen Brad L., Carco Diane M.: The Smart Way to Buy Information Technology: How to Maximize Value and Avoid Costly Pitfalls. Amacom: American Management Association, 1998. 258 str. VVerber B., Zupančič J.: Uporaba informacijske tehnologije v malih podjetjih v Sloveniji. Kranj: založba Moderna organizacija, revija Organizacija, letnik 35, št. 1, 2002. str. 23-32. ♦ Robert Srabotič, diplomant Fakultete za elektrotehniko in računalništvo v Ljubljani, je leta 2002 magistriral na Ekonomski fakulteti v Ljubljani, smer Podjetništvo, z magistrskim delom Strateško načrtovanje integriranih informacijskih sistemov v slovenskih majhnih in srednje velikih podjetjih. Raziskovalno delo teorije integriranih informacijskih sistemov je imel priložnost še istega leta uvesti v praksi, in sicer kot vodja projekta uvedbe poslovno-informacijskega sistema v družbi Iskra Transmission d. d. iz Ljubljane. ♦ Razprave Procesni pristop PRENOVE IN INFORMATIZACIJE POSLOVANJA V SKUPINI TPV Mitja Cerovšek, Matej Jevšček Izvleček Proces prenove in informatizacije poslovnih procesov odpira številna ključna vprašanja v podjetju: kaj delamo, zakaj to delamo in kako to delamo. Iskanje ustreznih odgovorov nanje vodi posledično v spremembe, od katerih seveda dolgoročno pričakujemo ustrezne ekonomske učinke. V Skupini TPV smo k spremembam pristopili tako, da smo najprej na novo začrtali strategijo. Ugotovili smo, da obstoječi poslovni procesi ne zagotavljajo njenega optimalnega izvajanja, zato smo se v naslednjem koraku lotili prenove poslovnih procesov. Zadnji korak v procesu sprememb pa je informatizacija poslovnih procesov, ko je potrebno preurejene poslovne procese ustrezno informacijsko podpreti. Članek skuša pokazati, kako smo se v Skupini TPV v praksi in na osnovi procesnega pristopa lotili teh velikih sprememb ter predstavlja nekatere ugotovitve, do katerih smo pri tem prišli. Abstract PROCESS APPROACH TO REDEVELOPMENT AND COMPUTERIZATION OF MANAGEMENT IN TPV GROUP The process of redevelopment and computerization of business processes raises a number of crucial questions in companies: what, why and how we do things. In search of appropriate answers to these questions, the company meets the changes which are expected to bring the desired long-term economic results. In TPV group, the first step within our approach to these changes was to re-establish the strategy. l/Ve realized that the existing business processes didn’t ensure any longer the optimal implementation of the newly established strategy, therefore, the foiiov/ing step consisted of redevelopment of business processes. The final step within the procedure of changes implementation is the computerization of business processes which determines a proper Computer support of reorganized business processes. The purpose of the article is to show how TPV Group proceeded with changes implementation by means of process approach. 1 Uvod Podjetja danes delujejo v izjemno dinamičnem, nepredvidljivem in nestabilnem okolju. Če želijo jutri uspešno in učinkovito poslovati, morajo že danes, četudi so morda na vrhu različnih lestvic kazalcev uspešnosti, dejavno slediti najnovejšim smerem poslovanja in tako aktivno spreminjati obstoječi sistem, pri čemer imamo še posebno v mislih spremembe na področjih poslovnih strategij, poslovnih procesov, informatizacije, organizacije in upravljanja s kadri. Posebno pomembna in zanimiva se zdi povezava med strategijo podjetja, prenovo in informatizacijo poslovanja ter posledično organizacijo podjetja. Tudi v Skupini TPV se srečujemo s potrebo po zagotovitvi sinergijskih učinkov, ki jih lahko dosežemo v primeru sistemske povezave med strategijo podjetja, med poslovnimi procesi, ki so naravnani v smer njenega izvajanja in med informatizacijo preurejenih in v strateške cilje organizacije usmerjenih poslovnih procesov. Zelo pomembno je, da je odziv podjetij na spremembe v okolju pravočasen in primeren. Osnova za ukrepanje so kakovostne informacije in vzpostavljen sistem, ki jih zagotavlja. Soočimo se s strateškim upravljanjem kot nenehno odvijajočim se (trajnim) procesom, ki ga lahko opredelimo kot stalen proces prilagajanja poslovnega sistema okolju ter tudi njegovo delovanje na okolje v skladu s cilji poslovnega sistema. Določanje ciljev poslovanja, oblikovanje in izvajanje strategij ter nadzor njihove izvedbe postajajo ključni dejavniki tega procesa. V Skupini TPV smo se na omenjene izzive odzvali tako, da smo ob močni podpori vodstva podjetja pričeli z izvajanjem treh ključnih projektov: ■ strateški management v Skupini TPV, ■ projekt postopne prenove poslovnih procesov (5P) ter ■ informatizacija poslovnih procesov. Uspešno in učinkovito poslovanje je običajno osnovni cilj, ki ga želimo v podjetju doseči. Pri tem 'delati prave stvari na pravi način' (oz. biti uspešen in hkrati tudi učinkovit) pomeni, da je potrebno sistemsko skrbeti za strateško vodenje in usmerjanje podjetja ter tako tudi za nenehno spreminjanje (kar pomeni: izboljševanje) obstoječega stanja. Projekti celovite prenove so pogosto (Kovačič, 1998) iskanje ustreznih odgovorov na ključna vprašanja o načinu in predmetu poslovanja podjetja. 'Kaj počnemo', 'zakaj to počnemo' in 'kako nekaj počnemo' so zelo pomembna vprašanja. Zato danes proces postopnih sprememb vključuje najprej razumevanje značilnosti obstoječih poslovnih procesov, ki jih je potrebno v nadaljevanju (in ob sodelovanju s procesom strateškega planiranja) prenoviti. V naslednjem koraku pa prenovljene poslovne procese informatiziramo in jim zagotovimo ustrezno organizacijsko in kadrovsko podporo. Kot izhodišče pri tem nam služi strateški načrt razvoja informatike, pripravljen na osnovi strateškega načrta podjetja. Odločitev o informacijskem okolju je za Skupino TPV ena od ključnih strateških odločitev. Dobro opredeljene informacijske potrebe, ki so jih podali lastniki posameznih procesov v Skupini TPV, vodijo k učinkovitemu bodočemu informacijskemu sistemu in k zadovoljstvu z njim. 2 Predstavitev Skupine TPV Ko so tranzicijske, zgodovinske in politične spremembe konec osemdesetih let prejšnjega stoletja pretresle tudi takratnega gospodarskega velikana Industrijo motornih vozil (IMV) iz Novega mesta, so se organizacijske in programske spremembe leta 1989 izlile v ustanovitev štirih delniških družb, ki so (vsaka s svojim proizvodnim programom) nasledile in nadgradile dotedanje dejavnosti omenjenega podjetja. Ena izmed njih je bila tudi družba TPV. Ker takratni IMV sam ni zmogel programsko in tržno preoblikovati podjetja, je leta 1992 prenesel kapital na Sklad Republike Slovenije za razvoj, ki ga je država določila za upravljavca podjetij z motnjami v poslovanju. Zaposleni so leta 1993 od Sklada v celoti odkupili podjetje TPV d.d.. Novi TPV se je preusmeril v proizvodnjo opreme za avtomobile in avtomobilske prikolice. Ker je podjetje TPV želelo postati dobavitelj sestavnih delov v avtomobilski industriji, je ves čas iskalo zunanje strateške povezave s poslovnimi partnerji. Specializacija in delitev proizvodnje v avtomobilski industriji je spremenila odnos med proizvajalci avtomobilov in dobavitelji sestavnih delov in opreme. TPV ni mogel postati razvojni dobavitelj, zato je moral sprejeti povezave z večjimi proizvajalci avtomobilske opreme v svetu. Z njimi je ustanovil mešana podjetja. Danes sestavljajo Skupino TPV naslednja podjetja v mešani lasti: ARSED d.o.o. (partner: Faurecia, proizvodnja kovinskih ogrodij avtomobilskih sedežev), TPV Johnson Controls (partner: Johnson Controls, sestava sedežev za prvo vgradnjo v vozila Renault, ki jih izdelujejo v novomeškem Revozu) in TPV Prikolice (partner: Bockmann, proizvodnja avtomobilskih prikolic). Poleg njih pa so del skupine tudi naslednja podjetja, ki so v 100 % lasti TPV d.d.: TSB d.o.o. (ustanovljeno leta 1998 z namenom proizvodnje izdelkov za avtomobilsko industrijo iz žic in cevi), TPV Suhor d.o.o. (ustanovljeno leta 1993 z namenom proizvodnje sestavnih delov za avtomobilsko in prikoličarsko industrijo) ter TPV Avto d.o.o. (ustanovljeno leta 2001 z namenom prodaje in servisiranja vozil). Razmere pred začetkom procesa prenove in informatizacije poslovnih procesov v Skupini TPV in pripadajočo organizacijsko shemo Skupine iz prve polovice leta 2002 prikazuje Slika 1. Materinsko podjetje TPV d.d. skrbi za strateški razvoj in trženje, ekonomiko poslovanja, intelektualne storitve ter nadzor poslovanja in kapitala. Znotraj TPV d.d. sta organizirana tudi dva profitna centra (krajše: PC): PC Storitve (zagotavljanje energetske oskrbe in vzdrževanja v podjetjih ter profitnih centrih Skupine TPV) in PC Avtomobilski deli (proizvodnja različnih sestavnih delov za prvo vgradnjo v avtomobil Renault Clio, ki ga izdelujejo v tovarni Revoz v Novem mestu.). Največji del proizvodnje pa poteka v hčerinskih podjetjih obvladujoče družbe. Znotraj krovnega podjetja so organizirana tudi področja informatike, kakovosti, razvoja kadrov, ekonomike, trženja in razvoja ter (kot že omenjeno) profitni centri, JOHNSON CONTROLS FAURECIA BOCKMANN TPV Suhor d.o.o. TPV Prikolice d.o.o. TSB d.o.o. JOHNSON CONTROLS d.o.o. ARSED d.o.o. TPV Avto d.o.o. TPV, Trženje in proizvodnja opreme vozil d.d. PC Avtomobilski deli PC Storitve Slika 1: Organizacijska shema Skupine TPV ki nimajo formalnega statusa pravne osebe, vendar so znotraj podjetja obravnavani kot samostojne profitne enote in pomenijo zametke novih podjetij. Glavna naloga krovnega podjetja je strateški razvoj trgov in izdelkov ter kapitalsko povezovanje vseh podjetij Skupine TPV. Približno 500 zaposlenih v Skupini TPV je v letu 2001 glede na leto prej povečalo promet za več kot 20 % in skoraj podvojilo doseženi čisti dobiček. Nadaljuje se zaposlovanje novih strokovnjakov. Vzroke za pozitivne, spodbudne in vsako leto boljše poslovne rezultate gre po mnenju vodstva podjetja iskati predvsem v usmeritvi k razvojni naravnanosti, pravilni izbiri komercialnih partnerjev, zasledovanju priložnosti, ki jih nudijo novi proizvodi, poslovnih povezavah z novimi podjetji ter v posledicah pridobitve certifikata za kakovost ISO 9001 v decembru leta 1993 ter okoljskega certifikata ISO 14001 v juniju 2000. Dobri poslovni rezultati pa niso povod za samovšečno zadovoljstvo. Nove zahteve glede obvladovanja poslovnih procesov (kot jih določata standarda ISO 9001:2000 in ISO TS 16949) narekujejo pospešeno uvajanje novih pristopov organizacije in vodenja podjetja. Tudi Skupina TPV aktivno deluje v tej smeri, saj uspešno zaključuje projekte Strateški management, Prenovo poslovnih procesov in Informatizacijo poslovnih procesov. Zaključki vseh teh projektov pa so temelji, ki jih bo potrebno spraviti v življenje, jih oplemenititi s svojim znanjem in delom ter jih prodati na trgu. Procesni pristop prenove in informatizacije poslovnih procesov na osnovi sprejetih strateških ciljev in z novo organizacijsko podobo je za Skupino TPV izziv in priložnost hkrati. V naslednjih treh poglavjih na kratko predstavljamo osnovna metodološka izhodišča, ki so usmerjala aktivnosti na področju prenove in informatizacije poslovnih procesov v Skupini TPV. VHOD IZHOD PROCES Slika 2: Shema procesa Procesno usmerjena organizacija ne pozna meja funkcij, oddelkov in služb. Proces postaja enotna celota in se ga tako tudi preučuje, analizira in organizira. V tem duhu in kot odgovor na vprašanje, kako naj združba dejansko odgovori na nove gospodarske izzive, bi lahko našteli pet pomembnih orožij (Vila, 1999), ki jih velja uporabiti: ■ fleksibilnost (zaposlenih, tehnologije, managerjev, organizacijskih struktur), ■ timsko delo, ■ primerjavo z najboljšimi (angl.: benchmcirking), m popolno usmerjenost h kupcu in ■ procesno organizacijo. Z vzpostavitvijo procesne strukture organiziranosti preidemo od navpične na vodoravno organiziranost. Procesna organizacijska struktura ima navadno tri ravni: vršnega vodjo oz. generalnega managerja, vodje posameznih procesov (oz. lastnike posameznih procesov) in time znotraj teh procesov. Razmeroma enostavno je procesno organizacijo uvesti v razne institucije, svetovalna podjetja, oddelke za raziskave in razvoj, računalniška podjetja in podjetja za intelektualne storitve, mnogo težje pa v velika industrijska podjetja. Omeniti velja, da je tudi naj novejši standard sistema vodenja kakovosti ISO 9001:2000 procesno usmerjen. Če 3 Procesni vidik poslovanja podjetja Proces lahko opredelimo kot (Harrington 1997) povezan nabor dejavnosti in nalog, ki imajo namen vhodnim elementom v proces za naročnika ali kupca dodati uporabno vrednost na izhodni strani procesa. Proces ni prepoznaven po opravilih, ki jih opravljajo njegovi izvajalci, pač pa predvsem po zaporedju dejavnosti in opravil, ki jih je potrebno izvesti, da bi na izhodni strani procesa dobili predvidene rezultate. Govorimo o ureditvi delovnih aktivnosti skozi čas in prostor, za začetkom in koncem ter z jasno zaznanimi vhodi in izhodi. -► aktivnosti, ki dodajajo vrednost -► tok informacij Slika 3: Model sistema vodenja kakovosti, osnovan na procesih želi podjetje oz. združba delovati učinkovito, mora identificirati in voditi povezane aktivnosti. Aktivnost, ki uporablja vire in ki jo vodimo z namenom, da omogoči spremembo vhodov v izhode, lahko obravnavamo kot proces. Procesni pristop poimenuje kot uporabo sistema procesov znotraj organizacije, vključno z njihovo identifikacijo in njihovimi medsebojnimi vplivi. Prednost procesnega pristopa je v tem, da omogoča nenehen nadzor nad povezavami med posameznimi procesi znotraj sistema procesov. V skladu s tem standardom in s procesnim pristopom tako posamezni proces zapišemo po aktivnostih, ki potekajo v smeri realizacije ciljev tega procesa, ne glede na organizacijsko enoto, v kateri se aktivnost izvaja. Potrebno je zagotoviti vzajemno delovanje proizvodnih in neproizvodnih procesov ter tudi ustrezno obvladovati zunanje procese (t.j. procese izven podjetja oz. združbe). Vse to vodi k našemu cilju: identificirati, zapisati, analizirati in prenoviti obstoječe poslovne procese. 4 Prenova poslovnih procesov Prenova poslovnih procesov (angl.: Business Process Reengineering - BPR) je temeljit in zahteven pristop k izboljševanju celostnega delovanja podjetij in drugih organizacij z analiziranjem in spreminjanjem celotnega poslovnega procesa. Osnovno idejo je razvil in populariziral Hammer, danes pa je v poslovnem svetu močno prisotna in se v praksi pogosto uporablja. Gre za korenito preoblikovanje podjetniških procesov, organizacije in kulture podjetja. Delne izboljšave poslovnih procesov ne vodijo do pričakovanih učinkov, zato so opuščanje temeljnih vzorcev današnje organiziranosti, procesna usmeritev poslovanja ter opravljanje dejavnosti, ki vodijo k novi vrednosti za kupca, osnovni poudarki ideje prenove poslovnih procesov. Na tem mestu velja tudi omeniti, kaj preurejanje poslovnih procesov ni. Hammer in Champy (1995) pravita, da preurejanje poslovnih procesov ne moremo enačiti z avtomatizacijo, prestrukturiranjem, preurejanjem programske opreme ali reorganizacijo, prav tako pa preurejanje poslovnih procesov tudi ni isto kot neprestano dvigovanje kakovosti (TQM). Od strokovnjakov, ki vodijo in izvajajo prenovo poslovnih procesov, se pričakuje poznavanje področij industrijskega inženiringa, ekonomike, trženja, informatike, proizvodnih procesov in ravnanja s človeškimi viri. Prenova se namreč pomembno dotakne treh zelo pomembnih in soodvisnih področij: organizacijskega področja, področja informatike in kadrovskega področja. Zato se pri tem zahtevnem in enkratnem procesu, ki pa se seveda lahko ponavlja, uporablja projektni pristop. Delo mora potekati skrbno načrtovano, spremljati pa ga je potrebno z us- trezno metodologijo in ustreznim orodjem za vodenje projektov. Različni avtorji v ta proces vključujejo podobne faze projekta. Harrington (1997) ga deli na naslednjih 5 faz: (1) organiziranje in pripravo projekta, (2) dokumentiranje poslovnih procesov, (3) izvedbo analize obstoječega stanja, (4) načrtovanje novega stanja ter (5) uvedbo izboljšav v prakso. Cilji, ki jih želimo pri tem doseči (Kovačič 1998), pa so: ■ poenostavitev poslovnih postopkov, ■ skrajševanje poslovnega cikla, ■ povečevanje dodane vrednosti, ■ zniževanje stroškov izvajanja postopkov, pri čemer se ohranjata kakovost in dobavni roki, ■ dvigovanje zanesljivosti izvajanja postopkov (in s tem kakovosti proizvodov in storitev), ■ usmerjanje v lastne zmožnosti in razmislek o prenosu določenih procesov izven podjetja, ■ tesnejše in bolj neposredno povezovanje z dobavitelji. Med, posebno aktualne pobude, ki sprožajo aktivnosti prenove, pa poleg zgoraj naštetih ciljev danes prištevamo predvsem: procese povezovanja, združevanja in prevzemanja podjetij ter uvajanje elektronskega poslovanja v podjetja oz. združbe. 5 Informatizacija poslovnih procesov Informatizacija poslovanja je proces uvedbe informacijske tehnologije, ki s spremembo starih pravil delovanja podjetij ter skupaj z energijo, ki jo prinaša prenova poslovnih procesov, vodi k zagotavljanju konkurenčne prednosti na trgu. Smiselno jo je izvajati le na primeru urejenih (optimiranih) poslovnih procesov. Pri informatizaciji poslovanja se zagotovo srečamo s strateškim načrtovanjem informatike v podjetju oz. združbi, s preurejanjem poslovnih procesov in postavitvijo ustrezne informacijske arhitekture, s snovanjem podatkovne baze in uporabniških rešitev ter s preverjanjem, povezovanjem in nadziranje kakovosti posameznih rešitev. Pot torej vodi od preurejanja poslovnih procesov k njihovi informatizaciji. Vezno tkivo je strategija celotnega sistema. V nasprotnem primeru se lahko zgodi, da bodo organizacije, ki so pred uvedbo računalnikov v poslovne procese delale slabo, to v bodoče delale še hitreje. Osnovni koraki tega procesa so: ocena obstoječe informacijske podpore (predvsem ugotavljanje zaznanih težav in novih potreb v podjetju v povezavi s ključnimi dejavniki uspeha), načrtovanje potrebnih sprememb (definiranje strojne in programske opreme ter izhodov iz informacijskega sistema na osnovi dejanskih potreb podjetja) ter prehod iz obstoječega na prenovljeni informacijski sistem. 6 Procesni pristop k prenovi in informatizaciji poslovnih procesov v Skupini TPV V Skupini TPV smo se procesnega pristopa prenove in informatizacije lotili po načelih, ki so predstavljena v predhodnih treh poglavjih tega članka. Kljub uspešnemu poslovanju v preteklih letih se zavedamo, da poslovni procesi zlagoma sami postanejo neučinkoviti. Poslovni sistem moramo nenehno prilagajati zahtevam trga, čemur pa z ustrezno hitrim odzivom ne sledijo vedno tudi posamezne strukture znotraj poslovnega sistema. Poslovni procesi se zato prilagajajo tem togim strukturam znotraj sistema, kar posledično vodi v neučinkovitost. Naša izhodiščna ugotovitev se glasi: "Za izpolnitev ciljev, sprejetih v strateškem planu Skupine TPV, je potrebno prenoviti in informatizirati izbrane poslovne procese." Moč novih tehnologij je ravno v tem, da nam omogočijo prekršiti stara in ustaljena pravila delovanja. To je za pridobivanje konkurenčne prednosti izjemno pomembno. Njihova moč torej ni v tem, da le izboljšajo delovanje starih procesov. Na omenjene izzive smo se odzvali tako, da smo poleg že delujočega projekta Strateški management v Skupini TPV sprožili še dva nova projekta: projekt 5P (Projekt postopne prenove poslovnih procesov) in projekt IPP (Informatizacija poslovnih procesov). Ločeno vodeni, a med seboj dobro koordinirani in vsebinsko tesno povezani projekti, naj bi pripravili pot za spremembe, ki jih v podjetju želimo izpeljati. V vseh treh projektih so člani projektnega sveta predstavniki najvišjega vodstva podjetja! Temelj vseh naših aktivnosti je glavni proizvod projekta Strateški management v Skupini TPV: Strateški plan Skupine TPV 2001 - 2011. Na njegovi osnovi in ob stalnem in nikoli zaključenem procesu njegovega preverjanja skušamo graditi naprej. Namenski cilj projekta 5P smo poimenovali: izvedba prenove poslovnih procesov, ki bo usmerjena k učinkovitemu doseganju strateških ciljev in vzpostavitev mehanizma optimizacije poslovnih procesov. To dosegamo z izdelavo posnetka obstoječega stanja in identifikacijo poslovnih procesov, analizo posnetka stanja, določitvo ključnih (temeljnih) in podpornih poslovnih procesov, z njihovo prenovo, z oblikovanjem novih organizacijskih struktur, z implementacijo prenovljenih poslovnih procesov in z vzpostavitvijo mehanizmov nadaljnjega spremljanja in optimizacije. Zelo pomembno se nam zdi poiskati in razumeti: ■ procese, ki prispevajo k dodani vrednosti v očeh kupcev, ■ procese, ki so potrebni z vidika potreb in zahtev podjetja in ■ procese, ki ne prispevajo k vrednosti v očeh kupcev in tudi niso potrebni z vidika potreb in zahtev podjetja. Predvidevamo, da bodo pozitivni učinki teh aktivnosti predvsem povečanje konkurenčne sposobnosti Skupine, lažje in hitrejše doseganje strateških ciljev, povečanje prilagodljivosti na spremembe v okolju, skrajšanje procesnih časov, povečanje učinkovitosti poslovnih procesov ter uskladitev z zahtevami standarda ISO 9001: 2000. Dokumentiranje obstoječih poslovnih procesov smo izvajali postopoma in sicer najprej v obvladujoči družbi TPV d.d.. Pri tem smo uporabljali orodje za modeliranje poslovnih procesov ARIS Easy Design, ki se je izkazalo kot koristno in uporabno. Sledila je analiza zgrajenih posnetkov, pri čemer se je v okviru projekta IPP ta osredotočila predvsem na analizo obstoječega stanja z vidika informacijske podpore Procesni model Skupine TPV "kot je" in "kot bo" predlog A . preurejenih poslovnih procesov prenova poslovnih procesov predlog informatizacije izbranih poslovnih procesov informatizacija poslovnih procesov ORGANIZACIJA strateški management v Skupini TPV ključne fr' strateške usmeritve podrobna razgradnja strateških usmeritev Slika 4: Povezanost prenove poslovnih procesov in strategije Skupine TPV z informatizacijo upombna\ NFORMATIKA 2002-številka4-letnikX procesom. Pri tem smo zaznali in zapisali informacijske potrebe uporabnikov ter največje težave, s katerimi se le-ti na tem področju srečujejo. V projekt IPP sta torej kot pomembna vhodna podatka nastopila: predlog preurejenih poslovnih procesov (izhod iz projekta "5P") ter ključne strateške usmeritve (izhod iz projekta "Strateški management v Skupini TPV"). Poglejmo sedaj še namenski cilj projekta IPP in seveda glavne aktivnosti, preko katerih ga skušamo doseči: Namenski cilj projekta IPP: priprava predloga informatizacije izbranih poslovnih procesov (z namenom učinkovite podpore izvajanju sprejetih strateških usmeritev) Objektni cilji projekta: A ocena trenutnega stanja B povezovanje s strategijo Skupine TPV C dokumentiranje obstoječih poslovnih procesov D analiza zgrajenih posnetkov obstoječe info podpore E izbor poslovnih procesov za informatizacijo F izdelava predlogov načrtovanih sprememb (priprava strateškega načrta razvoja informatike v Skupini TPV!) G določitev vsebine nadaljnjega dela in razvoja Pri izvajanju projekta IPP smo v nekem trenutku ugotovili, da bi velik del ciljev projekta zajeli in uresničili že tako, da bi pripravili in sprejeli dokument 'Strateški načrt razvoja informatike v Skupini TPV'. Ocenili smo, da je sedaj pravi čas, da obstoječe aktivnosti na področjih strategije, prenove in informatizacije poslovnih procesov izkoristimo tudi za pripravo prvega strateškega načrta razvoja informatike v Skupini TPV. Dokument, izdan vsakih 3 do 5 let in letno dopolnjevan, opredeljuje želje, potrebe in usmeritve organizacije na področju informatike v naslednjih mesecih in letih. Izhaja neposredno iz strateškega načrta organizacije. Vanj smo vključili tako poslovna kot tudi informacijska znanja. Zapisali smo 16 negativnih lastnosti obstoječega informacijskega sistema, ki izhajajo iz ugotovitev analize obstoječega stanja in nakazali možne poti odprave težav. Priložili smo model poslovnih procesov 'kot je' in tudi model 'kot bo'. Pripravili smo globalni model podatkov Skupine TPV. Skušali smo povezati razvoj informacijskega sistema s poslovno strategijo, predlagati uporabo tehnologij, ki so skladne s svetovnimi standardi in dejavnostjo sistema ter postaviti standarde in pravila delovanja v sistemu informatike. Dokument pomeni osnovo za kasnejšo izdelavo enoletnega operativnega informacijskega plana v obliki podrobno obdelanih projektov z jasnimi željami in pričakovanimi rezultati ter podanimi časovnimi roki za izvedbo. Če zelo zgoščeno in posplošeno strnemo ugotovitve, ki izhajajo iz 'Strateškega načrta razvoja informatike v Skupini TPV', lahko opazimo, da posamezne informacijske rešitve bolj ali manj uspešno rešujejo potrebe posameznih poslovnih procesov, pri čemer množica teh parcialnih rešitev ne zagotavlja ustrezne in učinkovite medsebojne povezljivosti. Različnost operacijskih sistemov, prisotnost številnih baz podatkov in ponudnikov posameznih aplikativnih rešitev še povečujejo pestrost obstoječega informacijskega sistema in težave z njim in nas učinkovito oddaljujejo od celovite in povezane informacijske rešitve. Namesto procesnega pristopa je povsod opaziti funkcijski pristop obvladovanja procesov in njihove pripadajoče informatizacije. Na tem mestu se zdi spogledovanje s celovitimi informacijskimi sistemi in rešitvami (ERP: Enterprise Resource Planning) povsem upravičeno. Potrebujemo torej celovit informacijski sistem, ki bo obvladoval vse izbrane poslovne procese ter podpiral odločanje na osnovi dejanskih podatkov o stanju proizvodnje in vseh preostalih funkcij. 7 Primer: definiranje procesov realizacije proizvodov Skupine TPV Pri dokumentiranju in kasneje analiziranju poslovnih procesov (s temi postopki smo seveda začeli pri 'vrhu' podjetja, torej v obvladujoči družbi TPV d.d.) smo ugotovili, da obstoječe vloge posameznih struktur znotraj sistema niso vedno dobro definirane in jih je potrebno spremeniti. Ugotovili smo, da imamo znotraj Skupine TPV tri vsebinsko in procesno različne dejavnosti: (1) proizvodnjo avtomobilskih delov (podjetja v 100 % lasti TPV d.d.), (2) lastninsko mešana proizvodna podjetja in pa (3) izvajanje koncesije. Na podlagi teh ugotovitev smo obstoječo organizacijsko shemo (Slika 1) preoblikovali v novo organizacijsko shemo Skupine TPV (Slika 5). Pomembna razlika med staro in novo organizacijsko shemo je tudi v tem, da smo vse proizvodne dejavnosti, ki so bile v obliki profitnih centrov do sedaj del TPV d.d., izključili iz obvladujoče družbe in jih postavili na področje (1), .........J.......... avtomobilski deli TPVTADIS d.o.o. Tovarna Novo mesto - zvarjenci - sklopi Tovarna Suhor - odpreški - zvarjenci - sklopi Tovarna Brežice - žice - cevi TPV d.d. strateške usmeritve in cilji kapitalske naložbe zasnove in zagon novih projektov postopki in predpisi za delo sistemov intelektualne storitve mešana podjetja TPV Johnson Controls d.o.o. sedeži ARSED d.o.o. ogrodja TPV Prikolice d.o.o. prikolice 73L... koncesija TPV Avto d.o.o. - Novo mesto - Brežice prodaja in servisiranje vozil Slika 5: Nova organizacijska shema Skupine TPV torej med proizvodnjo avtomobilskih delov v domači lasti. Hkrati smo zaradi boljše obvladljivosti, racionalnosti in pričakovanih sinergijskih učinkov vsa ta podjetja združili v eno novo (večje) podjetje TADIS d.o.o.. Ob tem se je spremenila tudi vloga obvladujoče družbe, ki bo z novo definiranimi procesi zagotavljala naslednje proizvode: strateške usmeritve in cilje, kapitalske naložbe, zasnove in zagon novih projektov, postopke in predpise za delo sistemov ter intelektualne storitve. 8 Zaključek Kakovostni podatki in ustrezno upravljanje z njimi zagotavljajo danes podjetjem vir konkurenčnih prednosti. Nove možnosti, kijih ponuja informacijska tehnologija, je treba z novimi znanji zliti v sistem, ki ne bo usmerjen le v učinkovito obvladovanje posameznih poslovnih funkcij v podjetju, pač pa bo usmerjen v učinkovitost in uspešnost poslovanja celotnega podjetja. Doseči je potrebno harmonijo med strategijo podjetja, med poslovnimi procesi, ki so naravnani v smer njenega izvajanja in med informatizacijo preurejenih in v strateške cilje organizacije usmerjenih poslovnih procesov. Odločitev o informacijskem orodju in razvojnem okolju na področju informatike pomeni za podjetje eno ob ključnih strateških odločitev. Vse omenjene in opisane aktivnosti v Skupini TPV pa nakazujejo bodoči zasuk v smer celovitega informacijskega sistema ter tako imenovanega "strateškega informacijskega sistema" (SIS). Razvojno okolje, ki ga podpira proizvajalec s sorazmerno visokim tržnim deležem, je lahko eden izmed primernih kriterijev pri izboru okolja podatkovnih baz in programskih rešitev. Pri tem velja razmisliti o celovitih rešitvah ter prav tako tudi o lokalno razvitih celovitih programskih paketih, ki so po funkcionalnosti podobni. Pri izbiri je potrebno tehtati med dobrimi in slabimi lastnostmi enih in drugih v skladu z našimi potrebami, cilji in zmožnostmi. Procese realizacije proizvodov hčerinskih družb skupine TPV prikazuje slika 6. Nekatera dejstva, navedena v prispevku, se bodo morda zaradi hitrih sprememb ob objavi članka že nekoliko razlikovala od dejanskega stanja. TPVTADIS d.o.o. proizvajanje avtomobilskih komponent TPV AVTO d.o.o. izvajanje dejavnosti koncesije S, L Proizvod: avtomobilske komponente Proizvod: A storitev servisiranja (zadovoljitev potreb kupcev, ki se hočejo voziti) POSLOVANJE MEŠANIH PODJETIJ proizvajanje ARSED proizvajanje TPV JC proizvajanje TPV Prikolice L Proizvod: avtomobilski deli prikolice Slika 6: Procesi realizacije proizvodov Skupine TPV Literatura in viri [1] Hammer, Michael, Champy, James (1995): Preurejanje podjetja: Manifest revolucije v poslovanju, Gospodarski Vestnik, Ljubljana [2] Harrington, J., Esseling, E. K. C., Nimvvegen, H. V. (1997): Business Process Improvement VVorkbook: Documen-tation, Analysis, Design and Management Business Process Improvement, McGraw-Hill, New York 3 [3] Kovačič, Andrej (1998): Informatizacija poslovanja, Ekonomska fakulteta, Ljubljana [4] Standard SIST ISO 9001:2000 (sl.,en.), Sistemi vodenja kakovosti - Zahteve, tretja izdaja, 2000 [5] Strateški plan Skupine TPV [6] Strateški načrt razvoja informatike v Skupini TPV [7] Vila, Antun (1999): Postmoderna družba in organizacija, Sodobna razlaga organizacije, Kranj: Moderna organizacija, str. 327-375 ♦ Mitja Cerovšek je diplomiral na Fakulteti za elektrotehniko v Ljubljani, smer procesna informatika. Je absolvent podiplomskega magistrskega programa Ekonomija na ljubljanski Ekonomski fakulteti. Zaposlen je v Skupini TPV kot pomočnik generalnega direktorja za strateški management in informatiko, kjer trenutno vodi proces informatizacije poslovanja. ♦ Matej Jevšček je diplomiral na Fakulteti za strojništvo v Ljubljani. Od leta 7 992je kot vodja razvoja, vodja različnih projektov prenosa tehnologij ter prenove in uvajanja sistemov vodenja zaposlen v Skupini TPV. Sedaj je pomočnik generalnega direktorja za sistem vodenja ter predstavnik vodstva za kakovost in ravnanje z okoljem. ♦ Razprave Pomembnost globalnega RAČUNOVODSKEGA MODELA V VEČNACIONALNIH UVEDBAH CELOVITIH REŠITEV Ksenča Bokovec, Sapphir d.o.o. ksenca.bokovec@sapphir.si Talib Damij, Ekonomska fakulteta Univerze v Ljubljani talib.damij@uni-lj.si Izvleček Sodobni sistemi celovitih rešitev vplivajo na preoblikovanje procesov v podjetjih, ki prehajajo od tradicionalnih, funkcijsko in lokalno usmerjenih okolij h globalnemu delovanju, kjer je pomembno združevanje funkcij, procesov in lokacij. Če jih primerno uvedemo, lahko podpirajo specifične procese posameznega podjetja v okviru globalno definiranih organizacijskih struktur in procesov. Prispevek je namenjen področju večnacionalnih uvedb celovitih rešitev. Predstavlja študije primerov, ki so bile izvedene v veliki maloprodajni korporaciji. Poudarek je na globalnem računovodskem modelu z vidika projekta uvajanja celovitih rešitev. Študije primerov analizirajo glavne gradnike globalno zasnovanega modela finančnega in upravljalnega računovodstva in njihovo preslikavo v strukture in procese celovitih rešitev. Poleg tega prikazuje tudi pomembnost uporabe metodologije v zgodnjih stopnjah projekta. Na koncu se prispevek dotakne tudi problemov osrednje standardizacije in vzdrževanja globalnega računovodskega modela. Abstract THE RELEVANCE OF A GLOBAL ACCOUNTING MODEL IN MULTI-SITE ERP IMPLEMENTATIONS ERP systems and their processes are cross-functional. They transform company practice from traditional functional and local oriented environments to globa/ operations, where they integrate functions, processes and locations. If properly implemented, they can support company-specific processes in the framework of globally defined organisa-tional structures and procedure s. The paper seeks to contribute to the area of multi-site ERP implementations. A čase study of severa/ companies in a large retail Corporation is presented, focusing on the globa/ accounting modeI from the perspective of an ERP implementation project. The čase study analyses the most important elements of a globally designed financial and management accounting model and their 'translation' to the structures and processes of the ERP system. Moreover, it demonstrates the importance of the application methodology in early project phases. Central standardisation and maintenance issues of the globa/ accounting model are a/so outlined. Ključne besede: celovite rešitve, mednarodna podjetja, globalne uvedbe, finančno in upravljalno računovodstvo 1. Uvod Podjetja danes prehajajo od nacionalno orientiranega poslovanja k mednarodni razpršenosti dela in usklajevanja dejavnosti. Novo poslovno okolje nujno vnaša spremembe ne samo v načine poslovanja podjetij, ampak tudi v podporno informacijsko tehnologijo. Moderne organizacije so globalne korporacije ter podjetja, ki so del globalnih nabavnih verig in zato potrebujejo najnovejšo tehnologijo za podporo večnacionalnega poslovanja. V preteklosti so mednarodna podjetja upravljala svoje poslovanje na ravni posameznih držav s pomočjo različnih nepovezanih informacijskih sistemov. Znane so nekatere izjeme, kot sta Hevvlett Packard (Lee in Billington, 1995) in Ford (Treece et al., 1995). Po drugi strani visok nivo mednarodnega usklajevanja tudi ni bil potreben, saj so bila podjetja v glavnem nacionalno usmerjena, inovativnih poslovnih strategij, kot so, na primer, nabavne verige, pa še ni bilo. Da bi izboljšala upravljanje globalnega poslovanja in zagotovila boljše usklajevanje notranjih in zunanjih dejavnosti, so podjetja začela zamenjevati obstoječe informacijske sisteme z novimi celovitimi rešitvami, ki so bile zasnovane za podporo globalnih korporacij. Celovite rešitve so kmalu postale 'de facto' standard za mednarodne organizacije (Holland in Light, 1999). SAP je na primer prisoten v več kot 60% mednarodnih korporacij (Bowley, 1998). Celovite rešitve so korporacijsko čudo, ki ima neverjeten vpliv tako na poslovni kot na informacijsko-tehnološki svet (0'Leary, 2000). V pričujočem prispevku se želimo osredotočiti predvsem na globalizacijo finančnih in upravljalnih računovodskih modelov v večnacionalnih korporacijah. Uvajanje povezanih sistemov celovitih rešitev v mednarodnem okolju je zelo kompleksna naloga. Globalizacija zahteva tesno usklajevanje dejavnosti ter standardizacijo in postavljanje skupne strategije v vseh delih organizacije. Eno najpomembnejših področij organizacije, kjer je nujno slediti tem smernicam, sta finančno in upravljalno računovodstvo. Zato je bistvenega pomena razpoznavanje tistih lastnosti in zmožnosti celovitih rešitev, ki lahko z vidika finančnega in upravljalnega računovodstva podprejo večnacionalno okolje. Lastnosti, ki zagotavljajo razvoj večnacionalnega računovodskega sistema, so: ■ večjezikovno okolje, ■ večvalutno okolje in ■ prilagodljive organizacijske strukture ter specifične rešitve na ravni držav. Cilj teh študij primerov je predstaviti tiste gradnike globalnega računovodskega sistema, ki bi v večnacionalni korporaciji omogočali vzpostavitev: ■ skupnega računovodskega sistema na ravni korporacije, ■ računovodskih sistemov na ravni posameznih podjetij ter ■ sinergijo računovodskih sistemov posameznih podjetij in korporacije. 2. Uporabljene metode Ker celovite rešitve sodijo v sodobno informacijsko tehnologijo, kjer lahko učinkovito uporabljamo kvalitativne raziskovalne metode, smo kot raziskovalno metodo uporabili študije primerov. Študije več primerov so intenziven empirični raziskovalni pristop, primeren za preučevanje novo nastajajočih, kompleksnih pojavov (Vin, 1994). Študije primerov so tudi osnovna kvalitativna metoda pri raziskavah informacijskih sistemov (Orlikovvski in Baroudi, 1999). Raziskovanje globalizacije računovodskih modelov je predvsem organizacijsko vprašanje, ki ga moramo podpreti s primerno informacijsko tehnologijo, da bi lahko dosegli pričakovane rezultate. Metoda študij primerov je še posebno primerna za raziskovanje informacijskih sistemov, saj je predmet naše discipline preučevanje informacijskih sistemov v organizacijah, zanimanje na tem področju, kot pravi Benbasat, pa prehaja iz tehničnih na organizacijska vprašanja. (Benbasat ct al., 1987). Glavna vprašnja, ki so vodila našo raziskavo, so bila: 1. Kako lahko v celovite rešitve uvedemo globalno organizacijsko strukturo, ki bo zagotavljala globalen računovodski sistem? 2. Katere računovodske gradnike moramo globalizi-rati, da bi zagotovili skupno poročanje na ravni korporacije? 3. Kako lahko istočasno zagotovimo upoštevanje računovodskih standardov in zahtev na ravni posameznih držav in podjetij? V okviru raziskave smo izbrali pet podjetij s področja maloprodaje. Da bi lahko razumeli naravo in kompleksnost procesov, smo v skladu s cilji teh študij uporabili primere iz različnih nacionalnih okolij (Benbasat et al., 1987; Eisenhardt, 1989). Izbrana maloprodajna podjetja so pripadala večnacionalni korporaciji in so bila iz različnih držav, tako da bi lahko upoštevali dejansko različnost nacionalnih okolij kot podlago teh študij primerov. Da bi lahko razumeli pomen globalnega finančnega in up-ravljalskega računovodskega sistema v večnacionalni korporaciji, smo izbrali podjetja, ki so se bistveno razlikovala po svojih specifičnih računovodskih sistemih in so bila vključena v eno od stopenj projekta uvajanja celovitih rešitev. Naslednja dejstva so opredeljevala študije primerov: ■ izbrani sistem je bil SAP R/3 z industrijsko rešitvijo 'IS Maloprodaja'; ■ vseh pet podjetij je bilo v času študij vključenih v eno od stopenj projekta uvajanja celovitih rešitev; ■ vseh pet podjetij je imelo obstoječe bolj ali manj izpopolnjene računovodske aplikacije, ki so bile delno ali pa nepovezane s POS in zalednimi sistemi; ■ vseh pet podjetij je vodilo računovodstvo po nacionalnih standardih v okviru lokalnih poslovnih knjig; ■ računovodska poročila za lastne potrebe so podjetja pripravljala v obstoječih računovodskih aplikacijah in delno s pomočjo Excela; ■ poročila za potrebe korporacije so podjetja pripravljala ročno v Excelu na osnovi podatkov, zbranih iz obstoječih računovodskih aplikacij. V okviru projekta smo uporabljali t.i. pristop izpeljave (roll-out). S takim pristopom ustvarjamo model uvajanja na posameznem podjetju in ga nato prenesemo na druga podjetja (VVelti, 1999). V okviru tega skupnega pristopa smo v štirih podjetjih uporabili t.i. pristop 'velikega poka' z uvajanjem vseh modulov 'IS Maloprodaje' skupaj s pilotno maloprodajno trgovino. V enem od podjetij pa smo uporabili večstopenjski pristop, kjer smo najprej uvedli računovodske module brez pilotne trgovine. Tako smo pristop izpeljave dejansko uporabljali na dveh ravneh: ■ kot izpeljavo maloprodajnih trgovin v posameznem podjetju in ■ kot izpeljavo modelnega podjetja na podjetja v drugih državah. 2.1 Zbiranje podatkov V okviru študij smo uporabljali kvalitativne nestruk-turirane intervjuje kot tudi kvantitativne vprašalnike z vnaprej podanim izborom odgovorov. Anketirance smo izbrali iz vseh sodelujočih podjetij kot tudi iz uprave korporacije. Intervjuje smo grupirali v dve skupini: (1) tiste, ki so predstavljali vidike posameznih držav in (2) tiste, ki so predstavljali skupen korporacijski vidik. Da bi lahko ugotovili glavna problemska področja med nacionalnimi in globalnimi računovodskimi pristopi, smo obe skupini intervjujev analizirali ločeno. Na ta način smo lahko dosegli osvetlitev podatkov in vpogledov iz različnih zornih kotov (Broadbent et al., 1999). Analizirali smo tudi organizacijsko dokumentacijo, notranja poročila in računovodske standarde posameznih držav. Posebnega pomena je bilo preučevanje obstoječih računovodskih aplikacij, ki nam je omogočilo vpogled v postopke in rezultate posameznih procesov in poročanja. Na ta način smo lahko ocenili čas, ki je bil potreben za izdelavo zahtevanih poročil na ravni posameznih podjetij in korporacije kot celote. To nam je omogočilo določeno primerjavo s časom, ki bi bil po naših izkušnjah potreben za izvajanje teh nalog v novem sistemu, upoštevajoč uvedbo globalnega računovodskega modela. Poleg tega smo poglobljeno analizirali tudi računovodsko prakso na globalni ravni korporacije, kjer so na sedežu izdelovali skupne, konsolidirane računovodske izkaze. 2.2 Študije primerov V pričujoče študije primerov smo vključili pet podjetij večnacionalne korporacije, ki smo jo poimenovali ReCor. ReCor je globalna korporacija, ki ima sedež v ZDA s podjetji v več kot 100 državah sveta. Njeno poslovanje se deli na dva sektorja - (1) veleprodajni sektor, ki vključuje tudi nekaj proizvodnih podjetij in (2) maloprodajni sektor. V vsaki državi je običajno eno maloprodajno podjetje z verigo trgovin. Maloprodajna podjetja smo poimenovali RC1 do RC5. Vsa maloprodajna podjetja prodajajo različno po-trošno blago, ki ga nabavljajo iz dveh virov: 80% izdelkov nabavijo neposredno od ReCor-jevih veleprodajnih podjetij (poimenovali smo jih WHC), medtem ko 20% artiklov kupujejo od drugih nacionalnih dobaviteljev. Le-te morajo izbrati iz referenčnega seznama dobaviteljev, ki ga pripravljajo na ravni korporacije. Posamezno RC podjetje tako neposredno trguje z WHC podjetjem iz iste države. Poslovanje RC in WHC podjetij je tesno povezano. Hierarhično strukturirani odnosi poročanja so prikazani na Sliki 1. RC1 država 1 WHC1 država 1 RC2 država 2 WHC n država n RC n država n ReCor uprava WHC2 država 2 Slika 1: Struktura poročanja v korporaciji ReCor Vsako maloprodajno podjetje periodično poroča svoje finančne, nabavne in prodajne podatke veleprodajnemu podjetju iz iste države. Le-to nato pripravi konsolidirana finančna, nabavna in prodajna poročila in jih pošlje na naslednji nivo - korporacijski informacijski sistem, kjer se izdelujejo globalna konsolidirana poročila. Poleg tega se v upravi ReCor-ja vzporedno pripravljajo tudi konsolidirana poročila, ki združujejo podatke vseh RC podjetij (gre bolj za agregirana poročila, saj RC podjetja med seboj ne trgujejo in tako ne moremo govoriti o pravi konsolidaciji). 3. Projekt uvajanja celovitih rešitev Ko smo pričeli raziskovati študije primerov, je projekt uvajanja že potekal, saj se je začel leta 1997 v eni od držav Evropske Unije. Razlog za začetek projekta na 'ad hoc' osnovi je bil zagotoviti prehod na leto 2000 in enotno valuto Euro, kar obstoječi informacijski sistem ni omogočal. Zato projekt že od samega začetka ni bil pripravljen na globalno strateški način, kar je kasneje povzročalo številne probleme v finančnem in up-ravljalskem računovodstvu. Uvajanje celovitih rešitev je bilo zasnovano le na specifičnih zahtevah posameznega podjetja in njegovega okolja, čeprav so se v tem času že uporabljale skupne ReCor-jeve računovodske in finančne smernice v določenih WHC podjetjih. Strateški odgovor podjetij pogosto zahteva nove načine dela in nove organizacijske oblike, ki jih podpirajo informacijski sistemi (Holland in Light, 1999). Usklajenost poslovnih in informacijskih strategij je nujno potrebna (Henderson in Venkatraman, 1991; Reich in Benbasat, 1996). Da bi zagotovili izpolnjevanje ReCor-jevih zahtev ter zanesljivost, primerljivost in nadzorljivost podatkov RC podjetij, smo projekt morali uskladiti z globalnimi smernicami. Preučevanje študij primerov smo začeli konec leta 2000. Naš cilj je bil določiti globalne gradnike finančnega in upravljalskega računovodstva ter njihovo preslikavo v strukture in funkcije sistema celovitih rešitev, ki bi jih nato lahko uporabili v prihodnjih projektih izpeljave. Za osnovo smo vzeli ReCor-jeve strateške smernice in pravila na področju finančnega in upravljalskega računovodstva. Slika 2 prikazuje razvoj projekta v RC podjetjih v času med pričetkom v letu 1997 in danes. Medtem smo rezultate študij primerov uspešno vključili v odločilne stopnje projektov v podjetjih RC3 in RC4 kot tudi v nadaljnje projekte izpeljave. Ugotovili smo, da je za uspeh projekta še posebno pomembno, v kateri njegovi stopnji smo začeli uporabljati globalni računovodski model. Večina projektov je neuspešnih že v stopnji definicije, saj so koncepti na začetku povečini precej 'mehki' (Lewis, 2001). Stopnja načrtovanja, kjer razvijamo zasnovo projekta, se je izkazala za najbolj odločilno fazo za uspeh projekta. Njegov uspeh smo merili v smislu doseganja ciljev ter časovnih in proračunskih okvirov. V času, ko pišemo ta prispevek, sta podjetji RC3 in RC4 v skladu z globalnim računovodskim modelom uspešno prešli v produkcijsko delovanje sistema. V vseh drugih načrtovanih projektih izpeljave smo začeli uporabljati novo zasnovo že v stopnji načrtovanja. Podjetje RC2 smo kasneje delno prilagodili novemu modelu, kar pa je bilo zamudno in utrudljivo delo, ki je povzročilo precej dodatnih stroškov. Podjetje RC1 še vedno deluje v okviru svoje specifične zasnove. Prilagoditev na novi model bo zahtevala precejšen vložek dodatnega dela in stroškov. Vendar pa bomo morali, upoštevajoč zahteve korporacije, v naslednjih dveh letih podjetji RC1 in RC2 popolnoma uskladiti z globalnim računovodskim modelom, saj njuni podatki niso dovolj zanesljivi in primerljivi. 4. Gradniki globalnega računovodskega modela Glavna procesa v preučevanih RC podjetjih sta prodaja in nabava. Oba procesa je bilo v toku projekta potrebno v določeni meri prenoviti, da bi bila v skladu z rešitvami najboljše prakse v maloprodajnih podjetjih, ki jih vsebuje izbrani sistem celovitih rešitev. Določena stopnja preoblikovanja poslovnih procesov je neizogibna, še posebno tedaj, ko prehajamo iz obstoječih informacijskih sistemov na celovite rešitve (Parr in Shanks, 2000). Vrednostni tok vhodnih in izhodnih podatkov omenjenih procesov se vedno konča v finančnem računovodstvu. V obstoječih sistemih so podjetja določene naloge, povezane z integracijo funkcij, opravljala povečini ročno ali s pomočjo vmesnikov, ki so zapisovali vrednosti v računovodske knjige v določenih časovnih intervalih. Visoko integrirani sistemi celovitih rešitev pa omogočajo sprotno ažuriranje računovodskega sistema. Ker je bil eden od ciljev projekta uvajanja celovitih rešitev poenotenje poslovnih procesov v vseh RC podjetjih, je tudi to dejstvo bistveno vplivalo na finančne in upravljalske računovodske sisteme preučevanih podjetij. Tabela 1 prikazuje skupne globalne računovodske gradnike, ki smo jih ocenili kot odločilne pri uvajanju celovitih rešitev. Uporaba globalnih računovodskih gradnikov je zagotovila medsebojno povezovanje tako specifičnih finančnih in upravljalskih računovodskih sistemov faza 1 RC5 RC6 RC7 Faza načrtovanja v skladu z globalno računovodsko strukturo načrtovanje faza II RC4 Faza realizacije v skladu z globalno računovodsko strukturo realizacija faza III RC3 Faza priprave v skladu z globalno računovodsko strukturo priprava faza IV RC2 Faza zagona sistema na osnovi specifičnih zahtev prodaje zagon sistema podpora in Kasnejša delna uskladitev z globalnim računovodskim modelom izpeljava trgovin zaključek RC1 Zaključek projekta na osnovi specifičnih zahtev podjetja projekta Slika 2: Razvoj projekta uvedbe celovitih rešitev Entiteta v sistemu Pomen gradnika Opomba Organizacijska struktura Šifra podjetja lokalen podjetje kot ekonomski subjekt Poslovno področje globalen definiran je bil globalen seznam poslovnih področij Funkcijsko področje globalen definiran je bil globalen seznam funkcijskih področij Kontrolinško področje globalen za vsa RC podjetja je bilo določeno enotno stroškovno področje Profitni centri globalen za vsa RC podjetja je bila določena enotna struktura profitnih centrov Področje dobičkonosnosti globalen za vsa RC podjetja je bilo določeno enotno področje dobičkonosnosti Kontni načrt Skupni konti korporacije globalen določeni v upravi korporacije Lokalni konti lokalen določeni v upravi korporacije Korporacijski konti globalen določeni v upravi korporacije Valute in tečajna politika Podjetje (valuta države) lokalen lokalna valuta, v kateri se vodi glavna knjiga Vzporedna valuta globalen valuta korporacije (USD) Metode valutnega prevrednotovanja globalen za ugotavljanje realiziranih in nerealiziranih tečajnih razlik po državah Postopki prevrednotovanja globalen odvisno od lokalne valute podjetja Jezik Primarni jezik sistema globalen angleščina Jezik države lokalen samo za statutarno poročanje Tabela 1: Gradniki globalnega računovodskega sistema RC in WHC podjetij kot tudi povezavo z glavnim korporacijskim računovodskim sistemom. 4.1 Organizacijska struktura Organizacijska struktura glede uporabljenih entitet sistema celovitih rešitev, ki odražajo organizacijo podjetja, je tvorila osnovo za uvajanje globalnega računovodskega sistema. Ker je bil izbran sistem SAP R/3, smo uporabili njegove notranje organizacijske strukture, s katerimi smo orisali različne ravni organizacije korporacije ReCor. To nam je omogočilo primerljivost različnih poslovnih sektorjev in oddelkov vzdolž celotne korporacije in njenih podjetij. Vsakega od šestih gradnikov smo uporabili za točno določen namen v sistemu poročanja: ■ šifro podjetja za zunanje, statutarno poročanje, ■ poslovno področje za poročanje vzdolž glavnih poslovnih sektorjev (veleprodaja, proizvodnja, maloprodaja), ■ funkcijsko področje za ponazoritev stroškov prodaje, ■ kontrolinško področje za upravljalno računovodstvo in porazdelitve stroškov, ■ profitne centre za poročanje o notranji uspešnosti in ■ področje dobičkonosnosti za poročanje o zunanji, tržno segmentirani uspešnosti. Tak pristop nam je omogočil poročanje po posameznih poslovnih sektorjih, podjetjih ter notranjih in zunanjih segmentih dobičkonosnosti v splošnem korporacijskem konsolidiranem sistemu poročil. Posamezni segmenti poročanja so bili namreč jasno opredeljeni s pomočjo entitet organizacijske strukture. 4.2. Kontni načrt Vsak kontni načrt mora biti podroben in urejen seznam vrednostnih kategorij, s pomočjo katerih beležimo ekonomski položaj podjetja. Večina držav od podjetij zahteva možnost vpogleda v finančne dokumente skupine kot celote kot tudi njenih posameznih podjetij (ASAP World Consultancy, 1998). V ta namen je bilo potrebno vzpostaviti globalen kontni načrt, ki bi zagotavljal statutoma in korporacijska poročila na več ravneh: ■ globalni ravni skupine (skupni konti celotne skupine), ■ lokalni ravni podjetja (lokalni konti v skladu z zakonskimi zahtevami posameznih držav), ■ ravni sedeža podjetja (konti v skladu z zakonskimi zahtevami ZDA). Nekatera podjetja (npr. podjetje RC2) niso imela posebnih lokalnih zahtev glede kontov, medtem ko so bila druga (npr. podjetja RC3 in RC4) prisiljena uporabljati specifične, lokalne konte. Slika 3 prikazuje različne kombinacije računovodski knjig v večnivojskem sistemu poročanja. poročanje na ravni globalnih knjig skupni konti korporacijski konti lokalni konti Slika 3: Vidiki poročanja v globalnem računovodskem sistemu Vsa RC podjetja iz pričujočih študij primerov so morala uporabljati globalni kontni načrt, kije vseboval vse potrebne konte. Podjetje RC2 je uporabljajo samo globalne konte in mu ni bilo treba izvajati dvojnih knjižb. Podjetji RC3 in RC4 sta za namene statutornega poročanja poleg globalnih uporabljali tudi nekatere lokalne konte. V teh primerih sta morali izvajati dvojna knjiženja hkrati v lokalne in korporacijske knjige (ta pristop se je uporabljal za določene računovodske kategorije, kot so rezervacije, davki na plače in osnovna sredstva, kjer je uprava korporacije uporabljala drugačne metode izračunov v skladu z ameriškimi zakoni). S pomočjo tako strukturiranega kontnega načrta smo, ob upoštevanju različnih računovodskih standardov, zagotovili usklajeno poročanje tako na ravni posameznih držav kot na ravni korporacije kot celote. Ob računovodskem zaključku mesecev oziroma poslovnega leta ni bilo potrebno izvajati zamudnih preknjiževanj ter združevanj in preslikav kontov. Računovodske knjige podjetij smo lahko enostavno vključili v korporacijski računovodski sistem, saj smo načelo ujemanja kontov, konceptov in organizacijske strukture upoštevali že od spodaj navzgor. 4.3 Valute in tečajna politika Podjetja globalnih korporacij običajno poslujejo v različnih monetarnih okoljih. Na eni strani imamo podjetja s stabilnimi valutami, na drugi pa podjetja v državah z relativno visoko stopnjo inflacije. Poleg tega pogosto obstajajo tudi zahteve, da korporacijske knjige vodimo v skupni valuti korporacije, ki velja za celotno skupino. Pričujoče študije primerov so obsegale štiri podjetja iz Evropske Unije in eno iz Latinske Amerike. Tako smo imeli dve vrsti valutnih okolij: 1. EUR stabilno okolje (podjetja RC1, RC2, RC4 in RC5) in 2. LAV1 nestabilno okolje (podjetje RC3). Ker SAP R/3 podpira večvalutno okolje, smo lahko zasnovali več ravni valut: ■ transakcijsko valuto (valuto dokumentov), ■ lokalne valute (v katerih so podjetja vodila svoje poslovne knjige) in ■ valuto skupine (USD). S pomočjo ameriškega dolarja kot valute skupine, se je vsaka knjižba v sistemu istočasno odrazila tako v lokalni valuti kot v valuti skupine po točno določenem tekočem menjalniškem tečaju med lokalno valuto in ameriškim dolarjem. Kot rezultat večnivojske valutne zasnove in stabilnih oziroma nestabilnih monetarnih okolij smo razvili kompleksen globalni model valutnega prevredno-tovanja, ki je vseboval naslednje gradnike: ■ seznam kontov, ki jih je potrebno prevrednotiti, ■ metode prevrednotovanja v različnih monetarnih okoljih, ■ postopke knjiženj izidov prevrednotovanja, ■ uporabo različnih tečajnic (povprečni tečaji, tečaji konec meseca itd.). Ob koncu meseca, po izvajanju avtomatskega procesa prevrednotovanja, so bili vsi konti izraženi v valuti skupine v skladu z različnimi valutnimi tečaji, določenimi za posamezna monetarna okolja. S pomočjo globalnega modela valutnega prevrednotovanja so bile poslovne knjige vseh podjetij prevedene v ameriški dolar in tako, brez večjega truda, pripravljene za poročanje na ravni korporacije. 4.4 Jezik Glavni sistemi celovitih rešitev podpirajo več-jezikovno okolje. SAP R/3, na primer, podpira vedno več jezikov. Globalne korporacije ponavadi želijo uporabljati le en jezik. Korporacija ReCor se je odločila, da bo v vseh podjetjih po svetu uporabljala angleščino kot primarni jezik poslovanja. To pomeni, da je bilo potrebno sistem nastaviti v angleščini, ki je 1 LAV pomeni fiktivno valuto Latinske Amerike bila obenem tudi jezik prijave na sistem. Ta metoda temelji na nizu standardnih besedil, ki jih pripišemo poročilom, zaslonom in tiskanim dokumentom (ASAP VVorld Consultancy, 1999). Vsako podjetje je moralo uporabljati funkcionalnost SAP v angleškem jeziku. Na splošno smo zasledili dva problema v zvezi z uporabo jezika: ■ raven znanja angleščine ni bila povsod enaka, ■ obstajale so zahteve za izdelavo statutarnih poročil v lokalnem jeziku. Odločitev za uporabo angleščine je temeljila na dejstvu, da bi bilo potrebno mnogo nastavitev sistema izvesti v obeh jezikih, če bi želeli uporabljati sistem v domačem jeziku. To bi seveda povzročilo dodatne stroške in ReCor se je odločil za uporabo enega samega jezika. Se vedno pa je obstajal problem statutarnega poročanja , ki smo ga rešili z vpeljavo alternativnih kontnih načrtov po posameznih državah, kjer so globalni konti z opisom v angleščini dobili še opis v lokalnem jeziku. Korporacijska poročila pa so bila s pomočjo standardne SAP-funkcionalnosti izdelana samo v angleškem jeziku. V določenih državah (podjetja RC2, RC3 in RC4) je bilo znanje angleščine med uporabniki na precej nizki stopnji, zato smo se mnogokrat srečali s problemom jezikovnih pregrad, kar je vplivalo na šolanje in samo delo. Vendar pa smo po drugi strani prihranili mnogo svetovalnih dni, saj smo nastavitve sistema in matične podatke pripravljali samo v enem jeziku. 5. Zaključek Ker večina uvajanj celovitih rešitev preseže postavljene proračunske in časovne okvire, so raziskovalci začeli analizirati projekte celovitih rešitev na študijah primerov, da bi tako prišli do spoznanj, ki bi omogočila večjo učinkovitost projektov (Parr in Shanks, 2000). Namen pričujočih študij primerov je prispevati metodološki pristop za izboljšavo učinkovitosti globalnih uvajanj celovitih rešitev na področju finančnega in upravljalskega računovodstva. Zavedati se moramo, da finančno in upravljalsko računovodstvo tvori podlago poslovanja v vsakem podjetju in je ključnega pomena za upravljanje podjetja z vidika zunanjih (statutarnih) kot tudi notranjih odnosov. To dejstvo je za nas pomenilo osnovno vodilo, in nas je napeljalo k temu, da smo raziskavo pričeli prav na računovodskem področju. Prišli smo do zaključka, da obstajajo štirje globalni gradniki, ki so ključnega pomena za uspešnost projekta uvajanja celovitih rešitev v globalnih večnacionalnih korporacijah. Ti štirje gradniki - organizacijska struktura, zasnova in uporaba kontnega načrta, valutni model ter jezik - so igrali odločilno vlogo pri globalni standardizaciji in poenotenju korporacijskih poslovnih procesov. Ne samo da so poenotili in standardizirali organizacijske entitete v celotni korporaciji in njenih sestavnih podjetjih, ampak so tudi omogočili uporabo skupnega kontnega načrta, neodvisnega od posebnosti držav in zakonskih predpisov. S pomočjo nove metodologije so se podjetja pri pripravi korporacijskih poročil in poročil na ravni posameznih podjetij izognila dvojnemu delu. Preslikava specifičnih in korporacijskih kontov, ki je bila značilna za obstoječe informacijske sisteme, in jo pogosto srečamo tudi v sodobnih uvedbah celovitih rešitev, ni bila več potrebna. S pomočjo globalnega računovodskega modela smo lahko uporabili enoten kontni načrt in enotno globalno organizacijsko strukturo na več ravneh poročanja - globalnem, lokalnem in korporacijskem, kar je bistveno zmanjšalo kompleksnost uvajanja in vzdrževanja sistema. Z uporabo te metodologije smo v precejšnji meri zmanjšali potreben čas in stroške uvedbe vsakega nadaljnjega projekta izpeljave. Izračunali smo, da se je čas uvajanja v podjetjih RC3 in RC4 zmanjšal za 30% v primerjavi s podjetjema RC1 in RC2. Z nadaljnjimi izboljšavami tega modela pričakujemo v prihodnjih projektih še večje prihranke pri času in denarju (podjetja RC5, RC6 in RC7). Pri tem moramo omeniti dve lastnosti, ki sta se nam zdeli izjemno pomembni za uspešno uporabo metodologije: ■ stopnjo projekta, v kateri smo začeli uporabljati globalni računovodski model ter ■ centralizirano in standardizirano vzdrževanje globalnih računovodskih gradnikov. Na podlagi ocene časa uvajanja celovitih rešitev v RC podjetjih je postalo očitno, da je bila metodologija bolj učinkovita, če smo jo uporabili že v zgodnjih stopnjah projekta. To pomeni, da so bili projekti, kjer smo globalni računovodski model uporabili že v stopnji načrtovanja, uspešnejši v smislu časa in stroškov potrebnih za dokončanje projekta (podjetji RC3 in RC4). Uporaba metodologije v stopnji realizacije je bila še sprejemljiva, vendar je povzročala dodatne napore in stroške (podjetje RC2), medtem ko so bile kasnejše stopnje projekta neprimerne za njeno uporabo, saj je bil sistem že zasnovan na drugih načelih. Prehod na globalni računovodski sistem (podjetje RC1) bi, zaradi bistvenih sprememb v zasnovi celovitih rešitev v podjetju z 'živim' sistemom, zahteval popolnoma nov projekt. Vsako spremembo je namreč treba izvesti, ne da bi bistveno vplivali na redno dnevno delo uporabnikov in delovanje sistema. Poudariti moramo tudi pomen osrednjega vzdrževanja gradnikov globalnega računovodskega modela, saj le-ta zahteva centralizirano določanje in vzdrževanje posameznih elementov. V ta namen je bila v upravi ReCor-ja ustanovljena posebna skupina za podporo, ki je upravljala globalni računovodski model. Posamezna podjetja so bila prisiljena upoštevati postavljene standarde. Osrednja skupina za podporo je določala organizacijske strukture v SAP R/3, njihov namen in številčenje. Tudi osnovni niz globalnih in korporacijskih kontov je bil postavljen centralno. Vsako lokalno zahtevo po novih kontih je bilo potrebno posredovati osrednji skupini za podporo v odobritev. Razvita je bila enotna baza podatkov, ki je vsebovala enoten kontni načrt z globalnimi, lokalnimi in korporacijskimi konti kot tudi že vnaprej določene organizacijske strukture z obsežnimi razlagami. Posamezna podjetja so lahko izbirala konte in druge gradnike iz osrednje baze podatkov. Včasih smo bili priča dolgim odzivnim časom osrednje skupine za podporo, vendar pa smo po drugi strani izkusili mnoge prednosti centraliziranega upravljanja globalnih računovodskih gradnikov. Globalizacija celovitih rešitev je imela pomemben vpliv na korporacijske procese na področju finančnega in upravljalnega računovodstva in se je istočasno odražala tudi na vseh drugih poslovnih funkcijah. Sistemi celovitih rešitev namreč utelešajo bistvo organizacije, njenih struktur, procesov in vlog posameznikov (Holland in Light, 1999). 6. Literatura ASAP World Consultancy, 1998. Administering SAP R/3: The Fl-Financial Accounting and C0-Controlling Modules, Que Corporation. USA. ASAP VVorld Consultancy, 1999. Using SAP R/3, Que Corporation. USA, Special Edition. Benbasat I,, Goldstein D.K., Mead M., 1987. The Čase Research Strategy in Studies of Information Systems, MIS Quarterly (11:3). Str. 369-386. Bowley G, 1998. Silicon Valley’s Transplanted Sapling. Financial Times, March 27,1998. Broadbent M., Weill R, St. Clair D., 1999. The Implications of Information Technology Infrastructure for Business Process Redesign, MIS Quarterly (23:2). Str. 159-182. Eisenhardt K.M., 1989. Building Theories from Čase Study Research, Academy of Management Revievv (14:4). Str. 532-550. Henderson J.C., Venkatraman N., 1991. Understanding Strategic Alignment, Business Quarterly, VVinter, 1991. Str. 72-78. Holland C.R, Light B.,1999. Global Enterprise Resource Planning Implementation. In Proceedings of the 32nd Annual Havvaii International Confer-ence on System Sciences IEEE. Computer Society Press. Los Alamitos, CA. Lee H.L., Billington C., 1995. The Evolution of Supply-Chain Management Models and Practice at Hevvlett-Packard, Interfaces, Vol.25, No. 5. Str. 42-63. Lewis J.R, 2001. Project Planning Scheduling and Control: A Hands-on Guide to Bringing Projects in on Time and on Budget, McGraw-Hill. New York. 0'Leary D.E., 2000. Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk, Cambridge University Press. Cambridge, UK. Orlikowski, W.J., Baroudi, J.J., 1991. Studying Information Technology in Organisations: Research Approaches and Assumptions, Information Systems Research (2). Str. 1-28. Parr A.N., Shanks G., 2000. A Taxonomy of ERP Implementation Approaches. In Proceedings of the 33,d Hawaii International Conference on System Sciences. Reich B.H., Benbasat L, 1996. Measuring the Linkage between Business and Information Technology Objectives, MIS Quarterly, May, 1996. Str. 55-81. Treece J.B., Kerwin K., Dawley H., 1995. Alex Trotman’s Daring Global Strategy. Business Week, 3 April, 1995. Str. 36-44. Vin, R., 1994. Čase Study Research: Design and methods, Sage Publica-tions. Newbury Park, CA, 2nd Edition. ♦ Mag.Ksenča Bokovec ima diplomo druge stopnje na Filozofski fakulteti in magisterij iz ekonomske informatike na Ekonomski fakulteti Univerze v Ljubljani. V informatiki jo še posebno zanimajo naslednja področja: projektno vodenje, integracija kompleksnih poslovnih informacijskih sistemov, finance, računovodstvo in kontroling. Kot svetovalka in projektni vodja pri uvajanju sistemov ERP ima že desetletne izkušnje. Od leta 1997 je zaposlena pretežno v tujini, kot projektni vodja in svetovalka - ekspert pri uvajanju SAP R/3. ♦ Dr. Talib Damij je izredni profesor za področje poslovne informatike na Ekonomski fakulteti. Na tej fakulteti je nosilec predmetov: objektno-orientirane metodologije in vodenje informacijskih projektov. Raziskovalno se ukvarja s področji: metodologije razvoja informacijskih sistemov, vodenje informacijskih projektov in operacijske raziskave. ♦ Razprave Ključni dejavniki uspeha projekta ERP V TEORIJI IN PRAKSI - PRIMER ELAN Matic Kovačič, ITS Intertrade Sistemi d.o.o., Ljubljana (matic.kovacic@its.si) Zvone Es, Elan d.d., Begunje na Gorenjskem (zvone.es@elan-line.si) Povzetek V članku poskušamo odgovoriti na vprašanje, kateri dejavniki vplivajo na uspeh projektov uvajanja celovitih rešitev in na kakšen način. Predstavljamo ugotovitve predhodnih študij tega področja in lastne ugotovitve na konkretnem projektu. Ugotavljamo, da so imeli pri projektu največji vpliv izkušnje izvajalca, partnerski odnos med naročnikom in izvajalcem ter podpora vodstva podjetja projektu. Namen študije je uporaba spoznanj pri novih projektih. Abstract CRITICAL SUCCES FACTORS OF ERP PROJECTS IN THEORY AND PRAXIS - ČASE OF ELAN In the article we are trying to discover what factors have the strongest influence on the success of ERP projects. We present the findings of other studies and own experience from our project. We identified the following CSFs that were more important than others: the experience of the Consulting company, good partner relationship between the Consulting company and the customer, and top-management support to the project. The goal of the study is to use this experience when starting nevv projects. 1 UVOD Utemeljevanje potrebe po sodobnih celovitih informacijskih sistemih in ukvarjanju z njimi po našem mnenju ni potrebno. Težave organizacij s preobremenjenostjo s podatki ter milijoni, ki se vsako leto investirajo v informatiko, povedo dovolj. Članek, ki je pred vami, predstavi uspešen primer projekta uvedbe rešitve BaanERP v skupino družb Elan. O tem, kateri dejavniki so ključni za uspeh oz. neuspeh tovrstnih podvigov, je na voljo cela vrsta virov. V članku združimo ta teoretična izhodišča z lastnimi opažanji ob delu pri projektu z namenom ugotoviti, kateri dejavniki so se v našem primeru pokazali kot pomembni, kateri pa morda nekoliko manj. S tem želimo ponuditi iztočnico za razmislek ob novih projektih. Članek je organiziran takole: ■ najprej predstavimo različne vire, ki na podlagi prakse različnih preteklih projektov in teorije informacijskih ved ponujajo odgovor, kateri dejavniki vplivajo na uspeh projektov celovitih rešitev; ■ nato opišemo sam projekt, metodologijo, ki je bila uporabljena, potek projekta, ki je tej metodologiji sledil (ali pa tudi ne), zaključek in končni rezultat projekta ter njegov pomen za nadaljnji razvoj poslovnega sistema Elan in njegove informatike; ■ v tretjem delu članka pa soočimo ključne dejavnike uspeha, ki smo jih pričakovali iz teorije in dosedanje prakse, z ugotovitvami pri projektu in izpostavimo bistvene. Članek metodološko izhaja iz študije razpoložljivih virov in enega poslovnega primera. To do neke mere omejuje pričakovane rezultate - naša ambicija ni najti univerzalne kriterije za izbiro celovite rešitve, saj je en sam primer premalo za to, da bi izločili vse posebnosti, ki so bile značilne za konkreten projekt (posebnosti organizacije, kadrovski vidiki, zgodovinske in tehnološke okoliščine...). Članek obravnava izbrano rešitev kot dano dejstvo in poskuša poiskati in izpostaviti dejavnike, ki na uspeh projekta pozitivno ali negativno vplivajo potem, ko je bila rešitev že izbrana. 2 KUUČNI DEJAVNIKI USPEHA PROJEKTOV CELOVITIH REŠITEV Zahvalo za kratico ERP ('Enterprise Resource Plan-ning') strokovni tisk pripisuje podjetju Gartner Group [6], ki naj bi s tem pojmom označilo sisteme, ki so zgodovinsko nastali kot nadgradnja sistemov oz. programov za načrtovanje materialnih potreb in planiranje proizvodnje v podjetjih. Ta zgodovinska okoliščina pa je danes precej nepomembna, saj se pod ta pojem že dolgo uvrščajo praktično vse celovite standardne programske rešitve za podjetja.1 Projekti uvajanja celovitih rešitev sodijo po svoji kompleksnosti med najzahtevnejše projekte, ki se odvijajo v sodobnih organizacijah [6], saj se morajo za 1 V tem prispevku bomo „rešitve ERP" imenovali ..celovite rešitve “.(op. uredništva) njihov uspešen zaključek pričakovanja uporabnikov in poslovni procesi organizacij uskladiti s tehničnimi danostmi uvedene rešitve. Ta kompleksnost in iz nje izhajajoča potreba po iskanju kompromisov je povzročila, da so se mnogi projekti iz tega področja končali neuspešno, po nekaterih virih kar tri četrtine [4]. Uspeh projekta se v praksi ([6], str. 9) malce presenetljivo meri predvsem po tem, ali se je projekt zaključil v predvidenem času in v okviru predvidenih stroškov. Redkeje se uporabljajo vsebinski kriteriji, kot naprimer čas, ki je potreben za izpeljavo določene poslovne transakcije, nivo zalog pred in po uvedbi in podobno. Nekateri projekti so ocenjeni kot uspešni že samo zaradi tega, ker je sistem ob prehodu zaživel, ne glede na to, kakšne in kolikšne so bile težave. V redkih primerih se podjetja odločijo za revizijo informacijskega sistema, ki poda osnovo za oceno uspešnosti. Ocene vpliva uvedene rešitve na uresničevanje strateških ciljev organizacije med kriteriji za presojo uspešnosti projektov nismo zasledili. Skupni imenovalec vseh kriterijev je, da so blagi in celovitim rešitvam naklonjeni, pa se kljub temu dogaja, da je število uspešnih projektov relativno majhno. Očitno je potrebno problem uspešnosti vzeti resno; to je glavni razlog za analizo dejavnikov, ki vplivajo na uspeh teh projektov. Stroka te dejavnike že vrsto let poskuša izluščiti iz mnogih uspešnih in neuspešnih projektov iz poslovne prakse. Ne glede na to, da je področje celovitih rešitev in projektov relativno mlado, pa je praksa že zelo obširna. Ravno tako vsako leto raste tudi zakladnica virov, ki o tej temi govorijo. Dejavnike uspeha lahko z namenom njihovega obvladovanja razdelimo po različnih kriterijih. Najprej bomo predstavili ključne dejavnike uspeha, ki sledijo iz teorije splošnega projektnega vodenja in lahko upravičeno pričakujemo, da igrajo pomembno vlogo tudi na projektih celovitih rešitev. Dejavniki se tu delijo glede na logično zaključene aktivnosti znotraj projekta. Delitev povzemamo po [1], saj je bila metodologija 'Goal Directed Project Management' (GDPM) uporabljena pri načrtovanju in vodenju projekta Elan. Tabela 1 prikazuje aktivnosti in nekatere dejavnike uspeha v skladu s to metodologijo. Seveda obstajajo tudi dejavniki, ki so specifični za projekte ERP, in na te dejavnike se želimo v tem članku osredotočiti. Pregled teh dejavnikov bomo naredili glede na izvor, od koder posamezen dejavnik vpliva na projekt. Tako poznamo dejavnike celovite rešitve, dejavnike dobavitelja in uvajalca, dejavnike organizacije, znotraj katere projekt poteka, ter dejavnike projekta samega. 2.1 Dejavniki celovite rešitve Funkcionalnost (vsebinske lastnosti) rešitve. Omenja se kot največkrat uporabljeni kriterij za izbiro celovite rešitve. Iz tega bi lahko sklepali, da ima funkcionalnost odločilen vpliv na uspeh projekta. Podjetja navadno na začetku projekta v fazi izbire rešitve izvedejo obsežno primerjavo značilnosti rešitev različnih dobaviteljev, kjer poskušajo strokovnjaki za posamezno področje s pomočjo zelo podrobnih točkovnikov ovrednotiti primernost posamezne rešitve. Na ta način sicer lahko grobo ugotovimo, katera področja rešitev podpira in katerih ne, kako kakovostno jih podpira, pa kljub vsemu izvemo šele v teku projekta. Zato je možna predpostavka, da je funkcionalnost rešitve eden najpomembnejših dejavnikov, naša zmožnost, da bi ga primerno upoštevali, pa zelo majhna. Ugled proizvajalca rešitve. Ugled vpliva na uspeh projekta na dva načina: po eni strani uveljavljeno ime Tabela 1: Projektne aktivnosti in dejavniki njihovega uspeha Aktivnost Dejavniki Zasnova projekta podpora vodstva jasnost ciljev projekta usklajenost znanja in sposobnosti organizacije ter tehnoloških rešitev, vsebovanih v uvedenem sistemu Načrtovanje projekta nivo podrobnosti načrtov strukturiranost načrtov realnost načrtov in ocene razpoložljivosti virov Organiziranje projekta razdelitev odgovornosti motivacija udeležencev reševanje konfliktov projektne in linijske organizacije komunikacija med udeleženci Nadzor nad potekom projekta formalizirana komunikacija povezava med načrti in poročili o napredku pooblastila vodje projekta Izvedba projekta nadzor nad spremembami ciljev obvladovanje razlik v organizacijski kulturi udeležencev Vir: [1] proizvajalca povečuje možnost, da bo uvedeno rešitev vsaj še nekaj let po uvedbi podpiral, jo razvijal in dopolnjeval. Po drugi strani je lahko eden od nakupnih motivov in ciljev projekta želja, da z nakupom uveljavljene rešitve podjetje vpliva na rast lastne vrednosti in ugleda. Zanesljivost delovanja rešitve. Zanesljivost se navadno izkaže šele po prehodu rešitve v živo. Najbolj kritični so tisti deli rešitve, ki so povezani s komunikacijo podjetja z okoljem, saj lahko povzročijo precejšnje težave pri vsakodnevnih aktivnostih. Ena izmed študij ugotavlja, da se je približno tretjina projektov soočila z resnimi težavami, povezanimi z zanesljivostjo delovanja programske opreme, po prehodu v živo [6]. Možnost uporabe referenčnih modelov. Projekt lahko precej prispeva k dvigu kakovosti in učinkovitosti poslovanja podjetja, če podjetju uspe v svoje poslovanje vključiti poslovno znanje, zajeto v standardnih programskih rešitvah. Za to je potrebno najti primeren kompromis med prilagoditvijo rešitve in prilagoditvijo poslovanja, o čemer pišemo v nadaljevanju članka. Tehnološka dovršenost (sodobnost) rešitve. Tehnološka sodobnost rešitve na uspeh projekta vpliva v manjši meri, se jo pa zato toliko večkrat omenja kot kriterij za izbiro rešitve. Sodobnost se izkaže šele na daljši rok, saj je sodobna rešitev trajnejša in bolje povezljiva z ostalimi obstoječimi in bodočimi podsistemi informacijske arhitekture podjetja. Prilagojenost rešitve lokalni zakonodaji in lokalni poslovni praksi. Prilagajanje rešitve lokalni zakonodaji in praksi (ang. lokalization) pomeni za dobavitelje programske opreme ogromen strošek, zato se kakovost prilagojenosti od rešitve do rešitve lahko precej razlikuje. Tudi v svetovnem merilu (glej npr. [4], str. 26), še posebej pa v slovenskem okolju, se večkrat omenjajo težave prilagajanja v povezavi z uspehom projektov. 2.2 Dejavniki dobavitelja oz. ovajalca Izkušnje uvajalca pri podobnih projektih. Izkušnje, ki jih svetovalci izvajalca pridobijo na predhodnih projektih, so neprecenljive za projekte, ki sledijo. Običajno je zato lahko uvedba hitrejša, uporabijo pa se že preizkušeni prijemi in rešitve, ki so se izkazali v praksi. Zato lahko podjetja upravičeno pričakujejo od uvajalca določene koncesije, če teh izkušenj primanjkuje. Kadrovska zasedba uvajalca. Ustrezna kadrovska zasedba izvajalca zmanjšuje tveganje, povezano s 'človeškim faktorjem'. Fluktuacija zaposlenih je na področju informacijske tehnologije velika in lahko hitro prinese težave, povezane z diskontinuiteto dela pri projektu. Partnerski odnos med podjetjem in dobaviteljem (ovajalcem) rešitve. Projekti uvajanja navadno vključujejo udeležence tako iz podjetja, v katerega se rešitev uvaja, kot udeležence zunanjega izvajalca storitev, zato so lahko uspešni le, če lahko obe strani pri projektu uresničita svoje cilje. Zaupanje uporabnikov v usposobljenost izvajalca. Študija, ki jo je izvedel Gefen [3], statistično ugotavlja močno povezavo med zaupanjem stranke v usposobljenost izvajalca in uspehom projekta, ko govorimo o projektih, ki zahtevajo veliko prilagoditev programske opreme. 2.3 Dejavniki organizacije Podpora vrhovnega managementa. Če nekoliko pretiravamo, lahko zatrdimo, da ima vsak projekt celovite rešitve podporo vrhovnega managementa. Šele oblika te podpore pa je dejavnik uspeha. Primer aktivne podpore je, ko je vodstvo nekega podjetja odobrilo drago zamenjavo pred nedavnim kupljene (praktično nove) računalniške opreme, ko se je ugotovilo, da v povezavi z celovito rešitvijo, kupljeno za tem, ne bo delovala optimalno [2]. Usklajenost informatike in projekta s strategijo podjetja. Strokovna literatura pogosto omenja potrebo po usklajenosti informacijske in poslovne strategije. Podjetje mora izbrati svojim ciljem primerno rešitev, v nasprotnem primeru se zelo hitro pokažejo težave zaradi cenovne ali vsebinske 'neustreznosti'. Transparentnost podatkov in postopkov v organizaciji. Pride do izraza v organizacijah, ki želijo prenoviti informacijski sistem ob majhnih spremembah v podatkih in postopkih (glej npr. [2], str 278), zato pa je to manj pomemben dejavnik v primerih, kjer se nova rešitev uvaja ob postavitvi ali prenovi poslovnih procesov. Široka podpora projektu na različnih nivojih organizacije. V literaturi večkrat omenjan dejavnik, ki omogoča ustvariti ugodno klimo za projekt. Ustvari se z ustreznim ravnanjem vodstva, ki mu uspe to vzdušje pripraviti, in v teku projekta s profesionalnim pristopom in kakovostjo opravljenega dela. Stabilnost poslovanja organizacije. Mnoge študije ugotavljajo, da je precej projektov utrpelo precejšnjo škodo zaradi fluktuacije zaposlenih. Na splošno velja, da je potrebno ob odhodu že usposobljenega človeka najti novega, njegovo usposabljanje pa zahteva svoj čas in dodatne napore v fazi projekta, kjer bi si tega najmanj želeli. Opremljenost z informacijsko tehnologijo (IT) in njeno obvladovanje. Nedvomno je primerno obvladovanje IT v podjetju predpogoj za uspeh projektov, na kar je potrebno misliti, še preden se za nov projekt odločimo. Uporaba sodobnih načinov komunikacije in skupinskega dela. Že v uvodu smo omenjali, da so projekti celovitih rešitev med nakompleksnejširni, saj pri njih sodeluje ogromno ljudi in organizacij, katerih individualni cilji ne vodijo nujno v isto točko: skoraj nič ni odvisno od posameznika, pač pa je timsko delo nujnost. Način vodenja in organizacijska kultura. Koristno je, če iniciativa za projekt ne pride samo od vodstva, pač pa potrebo po prenovi informatike izrazijo tudi na nižjih nivojih organizacije. Pazljiv pristop k uvajanju (nenaklonjenost tveganju) in sodelovanje vseh zaposlenih pri odločitvah lahko pomenita ključno razliko med uspešnim in neuspešnim projektom [7]. 2.4 Dejavniki projekta Nivo obvladovanja tehnik projektnega vodenja. V tem članku se ne bomo spuščali v podrobnosti teorije projektnega vodenja. Vsak projekt poteka v skladu z izbrano metodologijo in naloga vodje projekta je, da poskrbi za njeno udejanjanje. Nekateri avtorji prav urejenemu in učinkovitemu vodenju projekta pripisujejo zasluge za njegov uspeh [2]. Obseg in kakovost usposabljanja. Prehod v živo se ne sme odobriti, če zaposleni niso dovolj usposobljeni za delo na sistemu. Obstajajo različni pristopi k usposabljanju glede na različne metodologije uvajanja: nekateri zaposlene usposabljajo takoj na začetku projekta in jih na ta način v največji možni meri vključijo v delo pri projektu, nekateri pa se odločijo za usposabljanje tik pred prehodom, kar je stroškovno ugodnejše. Usklajenost rešitve s poslovnimi potrebami. Celovita rešitev naj bi bila izbrana tako, da bi že v standardni obliki kar najbolje pokrila poslovne potrebe organizacije. Če je prilagoditev (rešitve ali poslovanja) preveč, to negativno vpliva na uspeh projekta. Obseg (stopnja) sprememb v organizaciji. Ko se odločamo med prilagoditvijo rešitve in poslovanja, praksa kaže, da se je varneje odločiti za slednje, saj lahko podjetje potrebne spremembe spelje avtonomno in se mu pri tem ni potrebno zanašati na dejavnike, ki niso pod njegovim nadzorom (izvajalec, tehnologija rešitve ipd.). Obseg (stopnja) sprememb rešitve. Celovite rešitve se v praksi pri vsakem projektu vsaj nekoliko prilagaja. Študija [4] kaže, da je vpliv prilagajanja na uspeh projektov pozitiven, če so razlike med poslovnimi potrebami in rešitvijo velike. V primeru precejšnjega ujemanja rešitve s poslovanjem pa je bolje prilagajati poslovne procese. Tip prehoda (postopen ali vse-naenkrat). O tej temi se v strokovnih krogih doslej ni izoblikovalo jasno mnenje, kateri pristop je boljši. Dejstvo je, da imamo tako uspešne kot neuspešne primere projektov na obeh straneh. Mi bomo poskušali na primeru projekta Elan dodatni prispevati k debati o tem vprašanju. Čas (na voljo za projekt). Skupna izkušnja različnih projektov celovitih rešitev je, da pretesen plan negativno vpliva na možnosti, da bi projekt uspešno zaključili. K temu dodajamo le pripombo, da pa po drugi strani le konkreten rok, postavljen z razlogom, zagotavlja, da bo projekt v predvidenem času tudi zaključen. 3 PRIMER PROJEKTA UVAJANJA CELOVITE REŠITVE-ELAN 3.1 Opis položaja v podjetju pred odločitvijo za projekt V začetku leta 2000 je po razrešitvi lastniških vprašanj vodenje podjetja prevzela nova uprava. Elan je bil (in je še) organiziran kot skupina lastniško povezanih podjetij, z jedrom družbe, smučarskim programom, programom jadrnic in čolnov ter veleprodajo za področje Slovenije na lokaciji v Begunjah na Gorenjskem; poleg tega ta v skupino Elan vključena še podjetje za proizvodnjo snežnih desk v Brnci na avstrijskem Koroškem ter obsežna distribucijska mreža po svetu. Da bi se Elan rešil iz izgub, si utrdil blagovno znamko in postal gospodarsko uspešna družba, je bilo nujno treba reorganizirati poslovanje, racionalizirati stroške, ohraniti konkurenčne prednosti, učinkoviteje tržiti, obvladati poslovne procese, uspešno se spopasti z izzivi dinamičnega svetovnega trga in se hitro odzivati na nove priložnosti [5]. Elan je bil potreben temeljite prenove tako poslovanja kot tudi informatike. Obstoječi informacijski sistem na lokaciji v Begunjah je temeljil na zastarelem strežniku IBM 4381, ki je za podjetje povzročal po eni strani velike stroške vzdrževanja, po drugi strani pa ogromno tveganje morebitnega izpada delovanja. Poleg tega je v podjetju delovalo še nekaj ločenih podsistemov: glavna knjiga na strežniku IBM AS400, obdelave proizvodnje, osnovnih sredstev in še česa pa so potekale na osebnih računalnikih - delovnih postajah. Uprava Elana je ravno prenovo informatike ocenila kot enega od ključnih vzvodov za doseganje zastavljenih strateških ciljev. 3.2 Odločitev za projekt V stanju, kakršnega smo opisali, je bila odločitev za uvajanje celovite rešitve logična, čeprav kljub vsemu povezana z nekaterimi tveganji. Kljub kakovostnemu in motiviranemu kadru, ki si je želel spremembe sistema, je bila odločitev omejena s sredstvi, ki so bila na voljo, ter ponudbo na slovenskem trgu, postavljen pa je bil tudi izjemno kratek rok za izvedbo projekta (dobrega pol leta) [5]. Faza izbire rešitve je vključevala izvedbo povpraševanja, po katerem so pri ponudnikih, ki so se uvrstili v ožji krog izbire, naročili in plačali izdelavo projektnega načrta. Na ta način so zbrali zadosti podatkov, da so se lahko na podlagi objektivnih kriterijev (točkovanja) in drugih zbranih podatkov odločili za eno izmed ponujenih rešitev. Izbrana je bila rešitev BaanERP ponudnika ITS Intertrade Sistemi d.o.o. na operacijskem sistemu VVindovvs NT in podatkovni bazi Oracle. 3.3 Organizacija projekta Pri načrtu projekta in njegovi izvedbi so se naslonili na metodologijo, ki jo za uvajanje BaanERP priporoča izvajalec. Pristop se imenuje Baan Target, sloni na vodenju projektov na način postavljanja sprotnih ciljev (Goal Directed Project Management, GDPM [1]) in vsebuje naslednje poudarke: ■ projektno delo je potrebno razdeliti na merljive mejnike, ki se zdijo dosegljivi in ki služijo kot vmesni cilji v teku projekta, ■ nivo podrobnosti teh ciljev je potrebno prilagoditi časovnemu horizontu (ne planirati preveč natančno zelo oddaljenih aktivnosti in obratno), ■ s projektno organizacijo je potrebno zagotoviti vključitev vodstva podjetja v projektno delo, ■ potrebno je jasno opredeliti odgovornosti posameznikov in skupin v projektu, ■ formalizirati je potrebno organizacijo projekta in komunikacijo. Posamezne faze projekta in glavne mejnike prikazuje tabela 2: Projektna organizacija po tej metodologiji vključuje več različnih elementov: ■ nadzorni odbor projekta, v katerega je vključeno vodstvo naročnika in izvajalca ter vodstvo projekta, odgovoren pa je za potrjevanje mejnikov in odločanje o pomembnih vprašanjih, ki se pojavijo v teku projekta; ■ vodstvo projekta sestavljata notranji in zunanji vodja projekta, odgovorna sta za taktično odločanje na projektu, razporejanje virov in izdelavo poročil; ■ po posameznih vsebinskih področjih se imenujejo ključni uporabniki podjetja in svetovalci izvajalca; ključni uporabniki so odgovorni za prevzem znanja in uvedbo rešitve na svojem področju, svetovalci pa jih morajo za to usposobiti, ■ projektna skupina je sestavljena iz ključnih uporabnikov in vodstva projekta, služi pa kot forum za razreševanje odpritih vprašanj, ki se tičejo celotnega projekta, in koordinacijo uvajanja posameznih funkcijskih področij, ■ delovne skupine po posameznih področjih, sestavljene iz ključnega uporabnika, svetovalca izvajalca ter izbranih končnih uporabnikov, izvajajo aktivnosti uvedbe po teh funkcijskih področjih. Ker je Elan poslovni sistem, sestavljen iz več podjetij na različnih lokacijah, so oblikovali en sam nadzorni odbor projekta ter dve projektni skupini, eno na lokaciji v Begunjah in eno v Brnci. Vzporedno s pripravo načrta projekta je padla odločitev, da informatizacija v prvi fazi ne bo zajela distribucijskih podjetij po svetu. Vodstvo je v projektno delo vključilo tudi zunanjega svetovalca, ki je deloval kot moderator, skrbel za neovirano komunikacijo in s pomočjo natančne projektne dokumentacije opozarjal na neuresničene mejnike in odgovornost posameznikov. To vlogo ocenjujemo kot zanimivo in koristno dopolnitev projektni organizaciji po predstavljeni metodologiji. Eno od vodil projekta je bilo, da se celovita rešitev ne prilagaja oz. se prilagaja samo toliko, kolikor je to nujno potrebno, a se je izkazalo, da je število prilagoditev vendarle preseglo načrtovani obseg. Drugo vodilo je bilo pristop vse-naenkrat, kar pomeni, da vsa funkcijska področja istočasno preidejo na novi sistem. Tak pristop je priporočil izvajalec, prav tako pa velja, da bi bil postopen prehod zaradi tehnologije, ki se je uporabljala pred uvedbo celovite rešitve, povezan z velikimi stroški medsebojne integracije modulov. 3.4 Potek projekta September 2000. Oblikovani so bili organi projekta. Izdelana je bila končna različica projektnega načrta in Tabela 2: Faze projekta po metodologiji Baan Target Faza Aktivnosti Mejnik Dokument Inicializacija projekta Posnetek stanja. Svetovalci izvajalca poskusijo ERP rešitev preslikati na poslovni model naročnika. Simulacija testnega modela Načrt 1 Prenos testnega modela na ključne uporabnike Usposabljanje ključnih uporabnikov. Prilagoditev rešitve in poslovanja. Simulacija pilotskega modela Načrt 2 Priprava operativnega modela Izvedba vseh potrebnih korekcij modela. Izobraževanje končnih uporabnikov. Simulacija operativnega modela Navodila za delo Prehod v živo Vir: [8]. predstavljena projektni skupini. Določen je bil rok uvedbe, 15. februar 2001. Oktober 2000. Izvajalec je izdelal natančen posnetek stanja in v obsežnem dokumentu predstavil ključne točke, kjer se poslovanje Elana razlikuje od postopkov in rešitev, ki jih vsebuje BaanERP. Izdelan je bil predlog prvih prilagoditev rešitve. November 2000. V oktobru in novembru so potekala izobraževanja ključnih uporabnikov Elana. Pričelo seje z izdelavo prvih prilagoditev. Začeli so se prvi testni prenosi obstoječih Elanovih matičnih podatkov v novi sistem. December 2000 in januar 2001. Izveden je bil prvi test usposobljenosti ključnih uporabnikov. Januarja se je na podlagi do tedaj opravljenega dela nadzorni odbor projekta odločil, da načrtovani prehod v živo na lokaciji Brnca prestavi na l.april 2001, na lokaciji Begunje pa na 1. maj 2001. Iz osebnih razlogov je bila opravljena zamenjava svetovalca za področje distribucije, kar je pomenilo vsaj mesec dni diskontinuitete dela na tem področju. Februar in marec 2001. Nadaljevalo se je z izdelavo prilagoditev in testiranjem postopkov. V Brnci se je opravil prenos podatkov. Konec meseca je Brnca uspešno prešla na novi sistem. V Begunjah se je kot prvi uspešno uvedel modul Kadri in plače. April 2001. V Brnci je potekalo odpravljanje operativnih težav po prehodu, polnjenje nekaterih manjkajočih podatkov in svetovanje pri uporabi. V Begunjah so se izdelovala navodila za končne uporabnike in usposabljanje le-teh, opravljen je bil prenos podatkov. Delni testni prehod je sicer pokazal določene pomanjkljivosti, vendar je uspel, zato se je vodstvo projekta odločilo, da odobri prehod v živo. Konec meseca je tudi lokacija Begunje uspešno prešla na poslovanje z novo programsko opremo. Po opravljenem prehodu se je izkazalo, da je bilo usposabljanje ključnih uporabnikov uspešno. Poslovni procesi so bili skoraj v celoti podprti z novo rešitvijo, seveda pa so se pokazale tudi nekatere težave. Določeni predpisani postopki so se izkazali kot neustrezni. Nekatere izdelane prilagoditve v časovni stiski niso bile dovolj stestirane in jih je bilo potrebno dopolniti. Pokazale so se potrebe po dodatnih prilagoditvah. Zato so v naslednjih mesecih potekale nenačrtovane aktivnosti, povezane z dodatnim svetovanjem in izdelavo prilagoditev. Delo na novem sistemu se je dokončno ustalilo šele v oktobru 2001. Ne glede na nekoliko več težav po prehodu pa je vodstvo Elana uvedbo ERP rešitve ocenilo kot uspešno, saj je uvedba uspela v izjemno hitrem času, ob znosno preseženem proračunu ter na pričakovani ravni kakovosti. 3.5 Pomen uvedbe celovite rešitve za nadaljnji razvoj Elana Vodstvo Elana je celovito rešitev vedno videlo le kot osnovni del informacijske arhitekture podjetja. Tako kot velja, da brez te osnove ne gre in je bilo treba zanjo poskrbeti v najkrajšem času, se moramo zavedati, da ta rešitev nikoli ne bo mogla podpreti prav vseh poslovnih procesov znotraj skupine Elan. Zato se je kmalu po prehodu celovite rešitve v živo začela priprava nekaterih drugih projektov na področju informatike [9]: ■ projekt e-distribucije: internetni B2B portal za komunikacijo med Elanovimi distributerji in ERP sistemom, ki vključuje prenos cenikov, napovedi prodaje, nabavnih naročil distributerjev, podatkov o trenutnih statusih poslov in drugih podatkov, ki so potrebni za učinkovito spremljanje in vodenje procesa svetovne distribucije; ■ projekt poslovne analitike: zagotovitev podpore upravljanju na najvišjem nivoju organizacijske strukture, kjer bodo uporabniki lahko sami pridobivali za njih relevantne informacije ne glede na to, kje se nahajajo; ■ projekt nenehnih izboljšav celovite rešitve: dopolnitev že uvedene funkcionalnosti in uvajanje novih, kot so blagajniško poslovanje, vzdrževanje, integracija z maloprodajo in podobno. V septembru 2002, dobro leto po prehodu celovite rešitve v živo, lahko ugotovimo, da je projekt e-distribucije tik pred začetkom delovanja, projekt izboljšav že intenzivno poteka, medtem ko je poslovna analitika na začetku uvajanja. Poleg naštetih projektov v informatiki Elana poteka tudi kar nekaj drugih manjših razvojnih dejavnosti, kot so uvedba uporabe črtne kode na nekatera nova področja, izdelava nekaterih uporabniku prijaznih vmesnikov za delo, uvajanje sistema za vodenje razvojne dokumentacije, uvajanje celovite rešitve v nekatera nova podjetja itd. 4 KUUČNI DEJAVNIKI USPEHA PROJEKTA ELAN Kot smo že omenili, velja projekt uvajanja rešitve BaanERP v podjetje Elan kljub nekaterim pridržkom za uspešen projekt. Na konkretnem primeru je nemogoče dokazati splošno veljavnost vpliva določenih dejavnikov na uspeh projektov, je pa mogoče ovreči vpliv nekaterih dejavnikov, ki jih teorija razglaša za splošno veljavne, ter izpostaviti nekatere dejavnike, ki so se na konkretnem projektu izkazali. To bomo v zaključnem delu članka tudi storili. 4.1 Dejavniki, ki so se izkazali kot pomembni S strani rešitve naj najprej izpostavimo ugled proizvajalca. Podjetje Baan je že doživljalo boljše čase in prav v trenutku odločitve zanj so bile napovedi o njegovem nadaljnjem razvoju precej črnoglede. Vendar je to kljub vsemu ponudnik z zelo velikim številom instalacij v svetovnem merilu, ki same po sebi zagotavljajo obstoj in nadaljnji razvoj rešitve tudi na srednji rok. V primeru izbire manj uveljavljenega ponudnika bi sicer lahko ne bilo nikakršnih težav, vendar bi bilo tveganje gotovo večje. To je eden izmed razlogov, zakaj se bolje prodajajo rešitve znanih proizvajalcev (SAP, Baan,...) - zato kupujemo blagovno znamko. Rešitev s seboj prinaša poslovni model, preizkušen in dograjevan skozi več let obstoja in razvoja rešitve. Z uporabo standardnega poslovnega modela nam je uspelo na nekaterih področjih poslovanje vsebinsko posodobiti. Spet na drugih področjih smo rešitev tudi prilagajali - obseg prilagoditev rešitve na projektu Elan lahko označimo kot precejšen. Prilagoditve, ki jih je logika poslovanja Elana nedvoumno zahtevala in tiste, pri katerih je šlo za manjše korekcije v smislu prijaznosti do uporabnikov, so zastopane približno v enaki meri. V trenutku izdelave te analize se izbrani pristop kaže kot pozitiven, vendar še ni povsem jasno, kako se bo izkazal v daljši časovni perspektivi, zato bomo vpliv uvedbe poslovnega modela, ki ga rešitev prinaša, in usklajenosti rešitve s poslovnimi potrebami, ocenili pozitivno s pridržkom. S prilagojenostjo rešitve zakonodaji ni bilo nikakršnih težav, kar lahko pripišemo dejstvu, da je bila enaka rešitev že prej vpeljana v več kot deset slovenskih podjetij. Iz tega sklepamo, da obstaja negativna povezava med številom instalacij v neki državi in stroški, povezanimi z neprilagojenostjo rešitve lokalnim razmeram. Pri izvajalcu smo opazili tako pozitivne kot negativne dejavnike; več prvih kot drugih. Na projekt je izvajalec dodelil svetovalce z večletnimi izkušnjami pri podobnih projektih. Delo je zato potekalo hitro in učinkovito, število napak pa je bilo majhno. To se je v slednjič odrazilo tudi v kratkem roku, v katerem je bil projekt izveden. Izvajalec pa v trenutku, ko je bilo potrebno v najkrajšem času tik pred prehodom v živo izdelati veliko število prilagoditev, ni mogel zagotoviti ustreznega števila razvijalcev. Tej težavi se objektivno gledano lahko izognemo le s kakovostnejšim načrtovanjem. Zato priporočamo posebno pazljivost pri oceni potrebnih prilagoditev, da se predvidi ustrezen čas in viri za njihovo izdelavo. Posebej poudarjamo potrebo po negovanju kakovostnega partnerskega odnosa med naročnikom in izvajalcem. Zakaj neki - kupec je vendar kralj!? Dejstvo je, da je investicija v celovito rešitev visoka, projekt dolgotrajen. Kaj kmalu po začetku projekta pridemo do tega, da se o izbiri ponudnika težko premislimo, saj to postane povezano tako s stroški, ki smo jih pri projektu že naredili, kot s stroški, povezanimi s tem, da bomo do rešitve prišli toliko kasneje. Celovito rešitev se ne da kakovostno uvesti 'na ključ'. Ko pride do odstopanj od načrta, in do teh zagotovo pride, je potrebno priznati skupno odgovornost tako naročnika kot izvajalca za ta odstopanja, izvajalcu priznati njegove stroške, povezane z večjim obsegom dela, in se namesto na iskanje krivca raje osredotočiti na iskanje rešitev iz zapletenih položajev. Ker to pomeni dodatno porabo finančnih sredstev, ki so omejena, se včasih da partnerski odnos graditi tudi na načine, ki ne zahtevajo neposredno visokih finančnih izdatkov, kot je sodelovanje pri trženjskih aktivnostih, pisanje strokovnih člankov... H graditvi partnerskega odnosa je pozitivno vplival tudi angažma zunanjega svetovalca, ki je s svojimi izkušnjami skrbno spremljal izvajanje projekta in vodstvo projekta opozarjal na pomanjkljivosti in potencialne težave. Poleg tega je pomagal premostiti komunikacijske ovire, ki so pri takih projektih pogoste tako med naročnikom in izvajalcem kot med posameznimi oddelki in ljudmi v podjetju, ki celovito rešitev uvaja. Na podlagi lastne izkušnje priporočamo oblikovanje take funkcije pri projektih, je pa potrebno to vlogo ločiti od vloge svetovalca pri izbiri rešitve. Pri izbiri se tudi v Sloveniji vse prerado pojavlja, da se ti svetovalci predvsem ukvarjajo s tem, pri katerem ponudniku bo več kapnilo v njihov žep. Taki svetovalci so škodljivi in se jim je priporočljivo izogniti. V Elanu je bila opazna močna podpora manage-menta projektu tako v besedah kot v dejanjih. Vodstvo je vseskozi spremljalo dejavnosti projekta in na podlagi argumentov potrdilo tudi nekatere spremembe in odstopanja od načrta. Očitna je bila močna povezava med projektom in strateškimi cilji podjetja -rast, uveljavitev blagovne znamke, znižanje stroškov poslovanja itd. Pri projektu nikoli ni bilo slišati: »Ali je to sploh potrebno,« zato smo se lahko osredotočili na delo. Menimo, da je bila ta pozitivna naravnanost, pogojena tudi z vključitvijo mladih in ambicioznih ljudi v projekt, eden od pomembnejših dejavnikov uspeha. Na projekt je nekoliko negativno vplivala nestabilnost v poslovnih procesih in organizaciji podjetja. Kakor je bilo po eni strani koristno, da se je prenova informatike izvajala hkrati s prenovo poslovanja, pa je bilo zelo težko slediti vsem sproti nastajajočim spremembam (organizacija dela po pravnih osebah, število vključenih pravnih oseb in dejavnosti,...). Rezultat je bil kakšen dan proračuna manj na voljo za nujnejše aktivnosti. Glede posebnosti samega projekta in njegove organizacije nismo zasledili dejavnikov, ki bi ključno vplivali rta rezultat. Menimo, da je bil način prehoda 'vse-naenkrat' izbran pravilno, saj bi bil postopen prehod bistveno počasnejši in povezan z dodatnimi stroški. Tudi izkušnje izvajalca kažejo, da so bili projekti, kjer je bil izbran ta tip prehoda, uspešnejši od postopnih. Ta izkušnja se ne sklada z ugotovitvami nekaterih drugih raziskav, zato bi se dalo o tej temi izdelati ločeno študijo. Menimo, da je kratek rok, ki je bil postavljen, pozitivno vplival na angažiranost udeležencev projekta in sam po sebi prispeval k uspehu. Znanje, ki so ga uporabniki pridobili, se ni izgubilo, kot se to rado dogaja v primerih, ko od usposabljanja do uporabe znanja preteče veliko časa. Zato izkušnja projekta Elan pravi, da je rok uvedbe dobro postaviti ambiciozno, če pa se rok izkaže kot neizvedljiv, pa ga je vsekakor potrebno prestaviti in na njem ne vztrajati za vsako ceno. 4.2 Dejavniki, ki na uspeh projekta niso vplivali Omenili bomo zgolj dejavnike, ki jih dosedanje študije ERP področja navajajo kot pomembne, pa se njihov vpliv na projektu Elan ni pretirano izkazal. Arhitektura rešitve BaanERP je tipa odjemalec-strežnik. Arhitektura je sicer odprta in prilagodljiva, a vendarle rešitev ni zasnovana kot spletna aplikacija. V času, ko se vse rešitve pišejo za splet, bi to lahko pomenilo slabost, ki bi negativno vplivala na uspeh projekta, a tovrstnega vpliva ni bilo zaslediti. Deli poslovanja, ki zahtevajo uporabo spleta, so se bodisi podprli s pomočjo ločenih aplikacij (e-distribucija), ali pa se bodo podprli z BaanERP, ko bo njen razvoj to omogočil. Težko bi rekli, da je projekt doživel široko podporo na vseh nivojih organizacije Elana. Kar nekaj odpora lahko pripišemo naravni nenaklonjenosti ljudi spremembam, delno pa so bile težave povezane tudi s tem, da so posamezniki ocenili, da uvedena rešitev ni najboljša za njihovo funkcijsko področje. Iskanje kompromisov je v takih primerih vsekakor potrebno. Velikokrat pa se zgodi, da celovita rešitev, ki je npr. ugodna za prodajo, povzroči velike preglavice proizvodnji, s katero je povezana. Ravno zato je tu in tam potrebno kakšno rešitev vpeljati tudi brez konsenza vseh vpletenih. Tudi pri projektu Elan smo v nekaj Tabela 3: Matrika ključnih dejavnikov uspeha in ocene njihovega vpliva Dejavnik Vpliv Funkcionalnost rešitve brez ocene Ugled proizvajalca rešitve + Zanesljivost delovanja rešitve brez ocene Uporaba referenčnih modelov +? Tehnološka sodobnost rešitve 0 Prilagojenost lokalnim zakonom in običajem + Izkušnje izvajalca + + Razpoložljivost kadrov - Partnerski odnos med naročnikom in izvajalcem + + Zaupanje uporabnikov v izvajalca brez ocene Angažma zunanjega svetovalca na projektu + Podpora vrhovnega managementa + + Usklajenost s strategijo podjetja + Kakovost podatkov in postopkov brez ocene Široka podpora projektu na vseh nivojih 0 Stabilnost organizacije med projektom - Opremljenost z IT in njeno obvladovanje brez ocene Uporaba sodobnih metod skupinskega dela brez ocene Način vodenja in organizacijska kultura brez ocene Kakovost projektnega vodenja brez ocene Obseg in kakovost usposabljanja 0 Usklajenost rešitve s poslovnimi potrebami +? Tip prehoda (postopen ali vse-naenkrat) + Čas, na voljo za projekt + primerih tako storili. Ocenjujemo, da je uvedba celovite rešitve prezahteven in za podjetje preveč stresen projekt, da bi ga lahko izpeljali zgolj z uporabo demokratičnih sredstev. To pa še ne pomeni, da si za to ni treba prizadevati. O vplivu obsega in kakovosti usposabljanja lahko rečemo, da ni bil zares relevanten. Pomembno je, da na ključne uporabnike prenesemo del odgovornosti za uspeh projekta. V tem primeru bodo sami zahtevali toliko usposabljanja, kolikor ga potrebujejo, eni več, drugi manj. Vse prevečkrat se nam je pri drugih projektih zgodilo, da smo usposabljali ljudi, ki si tega usposabljanja niso preveč želeli. Rezultat je bil temu primeren. Zato menimo, da pretirano usposabljanje v začetnih fazah projekta predvsem zvišuje stroške ob negotovem vplivu na uspeh projekta; ta verjetno ni negativen, je pa lahko zanemarljiv. 4.3 Matrika dejavnikov in njihovega vpliva Kot povzetek opravljene analize smo preučevane dejavnike in oceno njihovega vpliva strnili v tabeli 3. Kot smo navedli že v uvodu, je kar nekaj potencialnih dejavnikov ostalo neocenjenih, saj ocena njihovega vpliva presega okvir tega članka in možnosti, ki jih nudi študija enega samega primera. Dejavniki, kot so funkcionalnost in zanesljivost rešitve, so po opravljeni izbiri rešitve projektu uvajanja dani od zunaj in na njih ni mogoče vplivati, zato njihova ocena niti ne bi bila smiselna z vidika ciljev študije. Naša izkušnja potrjuje, da se da na uspeh projekta odločilno vplivati z močnim osebnim angažmajem vodstva podjetja, s previdno izbiro izkušenih sodelavcev in z graditvijo dolgoročnega partnerskega odnosa med strankami, vpletenimi v projekt. Pri tem je potrebno paziti na previdno načrtovanje razpoložljivosti kadrov in se raje izogniti drastičnim reorganizacijam poslovanja v kasnejših fazah projekta. Po drugi strani ugotavljamo, da je mogoče projekt uspešno pripeljati do konca kljub naravni nenaklonjenosti ljudi spremembam, tehnološki konservativnosti uvedene rešitve in skopemu usposabljanju uporabnikov. Možnosti za nadaljnje raziskave vidimo predvsem v smeri, da bi vzeli v pregled še nekaj primerov tako uspešnih kot neuspešnih projektov uvajanja. Na ta način bi lahko ocenili tudi vpliv nekaterih dejavnikov, ki so v našem primeru ostali neocenjeni, in študijo razširili tudi na vpliv funkcionalnosti in zanesljivosti celovitih rešitev samih na uspeh projektov. Izkušnje nakazujejo, da funkcionalnost rešitve nima znatnega vpliva na uspeh projekta, in študija več primerov bi to hipotezo morda potrdila. Trdimo pa, da že na podlagi ugotovitev tega članka zasluži marsikateri »opomnik«, ki ga podjetja uporabljajo pri odločanju o prihodnosti svoje poslovne informatike, pošteno revizijo. 5 LITERATURA IN VIRI [1] Andersen Erling S, Kristoffer V Grude, Tor Haug: Goal directed project management. London : Kogan Page, 1995. 244 str. [2] Ang James S.K., Chee-Chuong Sum, Lei-Noy Yeo: A multiple-case design methodology for studying MRP success and CSFs. Information & Management 39, 2002. Str. 271-281. [3] Gefen David: Nurturing clients’ trust to encourage engagement success during the customization of ERP systems. Omega 30, 2002. Str. 287-299. [4] Hong Kyung-Kwon, Kirn Young-Gul: The critical success factors for ERP implementation: an organizational fit perspective. Information & Management 40, 2002. 16 str. [5] Jakupovič Esad: Fokus: Kako preprečiti informacijski mrk. Ljubljana : Gospodarski vestnik 14, 2002. Str. 18. [6] Kumar Vinod, Bharat Maheshvvari, Uma Kumar: An investigation of critical management issues in ERP implementation: emperical evidence from Canadian organizations. www.elsevier.com/locate/technovation, 2001. 15 str. [7] Motwani Jaideep et al.: Successful implementation of ERP projects: Evidence from two čase studies. International Journal of Production Economics 75, 2002. Str. 83-96. [8] Načrt projekta Elan in druga interna dokumentacija podjetja ITS Intertrade Sistemi d.o.o. 2000 - 2001. [9] Načrt razvoja informatike 2002/2003. Interna dokumentacija podjetij Elan d.d. in M2M informacijski sistemi d.o.o. 2002. ♦ Matic Kovačič, dipl. ekon., je vodja projektov v podjetju ITS Intertrade Sistemi d.o.o. Diplomiral je na Ekonomski fakulteti, kjer nadaljuje s podiplomskim študijem informatike. Leta 1998 se je zaposlil v Intertrade ITS kot svetovalec pri uvajanju informacijskih rešitev na področju računovodstva in financ, nato pa kot vodja projektov uvajanja celovitih rešitev. V Elanu je sodeloval pri prenovi informacijskega sistema kot zunanji vodja projekta. V podjetju Intertrade ITS je zadolžen tudi za področje informacijskih rešitev za podporo upravljanju. ♦ Zvone Es, dipl. ing., je podpredsednik uprave podjetja Elan d. d. Do leta 1992 je bil zaposlen v podjetju Gorenje Elektronika, najprej kot vodja operativne konstrukcije, nato pa kot tehnični direktor podjetja. Leta 1992 je soustanovil podjetje Elektronika Velenje in bil do leta 2000 podpredsednik uprave tega podjetja. V podjetju Elan je odgovoren za zimski program ter nekatere skupne projekte, med njimi tudi za prenovo informacijskega sistema. ♦ Razprave Navision IN KONCEPT CELOVITIH REŠITEV Z ODPRTO POSLOVNO LOGIKO Aleš Zajc Povzetek Navision Attain je v svetovnem merilu ena od vodilnih celovitih rešitev, namenjenih srednje velikim podjetjem. Hkrati je verjetno tudi najbolj razširjena celovita rešitev, ki uvajalcu skoraj v celoti dovoljuje spreminjanje obstoječe in dodajanje nove funkcionalnosti. Uvajal ec, ki nastopa kot partner proizvajalca, ob tem prevzema celotno odgovornost za uspešno dokončanje projekta. V prvem delu pričujočega prispevka smo analizirali Navision-ov poslovni model, način delitve odgovornosti med proizvajalcem in ovajalcem ter prednosti tega modela za naročnika. V nadaljevanju smo ocenili prednosti in slabosti tovrstnih rešitev z vidika njihove učinkovitosti. To smo ocenjevali na podlagi ustreznosti nove funkcionalnosti in skupnih stroškov lastništva, med katerimi smo izpostavili stroške uvajalnih storitev in vzdrževanja ter internih resursov. V zadnjem delu prispevka obravnavamo različne vidike uvajanja tovrstnih rešitev, predvsem ustrezen pristop k analizi in dizajnu ter k razvoju novih funkcionalnosti. Abstract NAVISION AND THE CONCEPT OF ERP SOLUTIONS WITH OPEN BUSINESS LOGIC Besides being one of leading ERP Solutions for mid-size companies, Navision Attain is probably the most vvidespread ERP in which the implementing partner is able to change ali of the existing and add new functionaiity using the integrated development environment. On the other hand implementing partner a/so take s fuli responsibiity for a successful completion of the impiementation project. In the first part of this article the Navision business model is presented and its advantages for the customer and other stakeholders are discussed. The second part analyses the efficiency of Navision and similar ERP Solutions using as criteria the appropriate functionality and total costs of ovvnership among vvhich costs of impiementation Services and internal resources are the most significant. In the last part of the article different aspects of implementations of Navision and similar ERP Solutions are discussed, in particular the design and development of additional functionalities. 1 Uvod Razvoj strojne in sistemske programske opreme omogoča učinkovito obvladovanje velikega števila podatkov. Večja dostopnost infrastrukturne opreme tako tudi srednje velikim in manjšim podjetjem omogoča uvedbo celovitih informacijskih sistemov, t.i. celovitih rešitev (enterprise resource planning, ERP), ki podpirajo celoten ali večji del poslovnega procesa. V primerjavi s klasičnimi informacijskimi sistemi, ki so namenjeni zgolj podpori na istih standardih temelječem računovodskemu evidentiranju (vsaj v isti državi), se pri podpori celotnega poslovnega procesa soočamo z zelo širokim spektrom najrazličnejših specifičnih zahtev. Medtem ko je samo računovodstvo primerljivo, pa je organizacija poslovanja odvisna od panoge in velikosti podjetja, zgodovinskih dejavnikov, poslovnega okolja, tehnologije ipd. Ponudniki celovitih rešitev (predvsem v razredu rešitev za »velike« stranke), so na specifične zahteve odgovorili s pripravo t.i. »panožnih« rešitev, ki so nastale iz izkušenj (in dograditev), pridobljenih pri uvajanju v posameznih panogah. Večina teh rešitev je zelo kompleksnih in izhajajo iz razmeroma velikih projektov pri naročnikih s podrobno obdelanimi poslovnimi procesi. V podjetjih, ki z vidika celovitih rešitev sodijo v t.i. segment srednjih podjetij (za slovenske razmere so to seveda »velika« podjetja z npr. 500 zaposlenimi in 50 uporabniki sistema ERP), so procesi velikokrat drugače organizirani kot v nekaj desetkrat večjih multinacionalkah. »Velike« rešitve ERP se temu prilagajajo z vnaprej konfiguriranimi različicami, ki za ceno nekoliko omejene funkcionalnosti zmanjšujejo kompleksnost potrebne parametrizacije. Nekateri drugi (zlasti manjši in lokalni) ponudniki celovitih rešitev pa so prav segment srednjih podjetij razumeli kot svojo tržno nišo in ponudili manj kompleksne rešitve, ki naj bi pri uvajanju zahtevale manj resursov. Vendarle pa srednjih podjetij v informacijskem smislu ne gre vedno razumeti kot »pomanjšane« različice velikih. Običajno so podjetja v srednjem segmentu specializirana za določeno storitveno dejavnost ali pa so kot specializirano proizvodno podjetje vpeta v eno ali več preskrbovalnih verig. Gre torej za podjetja, ki pokrivajo določeno tržno nišo in v kateri so uspešna prav zaradi posebnih postopkov in organizacije. Te posebnosti v ključnem delu poslovanja srednjih podjetij pa od celovitih rešitev velikokrat zahtevajo tudi posebej prilagojeno funkcionalnost. Večina konkurenčnih celovitih rešitev v srednjem segmentu nudi le omejene možnosti prilagajanja in dograditev. Nekatere rešitve (pri nas prilagojena in v Evropi med najbolj uspešnimi je danska rešitev Navision Attain) pa omogočajo prost dostop oz. spreminjanje in dograjevanje celotnega podatkovnega modela in vse poslovne logike. V nadaljevanju bomo analizirali vidike uvajanja tovrstnih rešitev (imenujmo jih celovite rešitve z odprto poslovno logiko), še prej pa bomo v kratkem predstavili za uspešno uvedbo zelo pomembno razdelitev odgovornosti med proizvajalcem in uvajalcem rešitve (partnerjem). 2 Delitev odgovornosti med proizvajalcem in uvajalcem K širitvi rešitve Navision Attain in njenih predhodnih različic je močno pripomogel poslovni model, s katerim je urejeno »partnerstvo« med proizvajalcem in uvajalcem. Proizvajalec oz. njegov lokalni distributer, ki skrbi za prilagoditev lokalnemu tržišču (običajno je pristojen za eno državo ali za regijo), preprosto proda standardno različico rešitve kot polproizvod uvajalen (Centru za rešitve Navision) po načelu »videno - kupljeno«. Morebitne napake v poslovni logiki standardne rešitve se seveda sporočajo proizvajalcu, ki jih odpravi v naslednji različici. Neke vrste »garancijo« za poslovno logiko zagotavlja sistem prodaje, ki od kupca zahteva obvezno doplačilo za brezplačno migracijo na vse v enem letu od nakupa licence izdane različice, v katere so seveda vključeni tudi vsi popravki. Razen pri večjih mednarodnih projektih proizvajalec ne skrbi za nikakršno poprodajno podporo oz. ne prevzema nobene odgovornosti za potek projekta. Le v primeru morebitnega konflikta med uvajalcem in naročnikom posreduje lokalni distributer, ki načeloma varuje interese naročnika in po potrebi uredi sodelovanje z drugim uvajalcem. Prav možnost zamenjave uvajalca močno povečuje varnost naložbe v Navision-ovo licenco, saj v primerjavi z običajnim modelom, kjer je uvajalec kar proizvajalec rešitve (oz. njegov ekskluzivni distributer), naročnik ni odvisen zgolj od enega dobavitelja uvajalnih storitev. Zaradi prepustitve odgovornosti za celoten projekt lahko proizvajalec uvajalcu brez omejitev prepusti tudi dostop do celotne poslovne logike. Izvajanje sprememb brez »odobritev« proizvajalca po eni strani znatno poceni pripravo morebitne dodatne funkcionalnosti, hkrati pa projekt oz. naročnika močno izpostavi sposobnostim in razpoložljivosti uvajalske ekipe. Nakup rešitve Navision lahko torej primerjamo z nakupom MS Access-a z demo »Northvvind« bazo. Microsoft je prodal zgolj produkt, odgovornost za končno funkcionalnost pa je na strani razvijalcev oz. uporabnikov. Pri gradnji partnerske mreže je Navision v začetku izbral izrazito »liberalen« pristop. Vstop v partnerstvo je bil razmeroma preprost in trg naj bi sam izbral boljše ekipe od slabših. S prihodom prve različice Windows se je partnerska mreža začela hitro širiti. Kljub tveganju zaradi minimalne podpore proizvajalca, je bil namreč Navision ena boljših alternativ za vse tiste ponudnike aplikacij v okolju DOS (npr. rešitev razvitih v Clipper-ju), ki niso zmogli financirati prehoda svoje obstoječe rešitve v okolje VVindovvs in katerih glavni »kapital« je bilo podrobno poznavanje poslovanja nekaj ključnih strank. V zadnjih letih se Navision-ov partnerski sistem bolj zapira, saj proizvajalec postopoma viša »vstopni prag«. K temu je posredno pripomogla tudi vse večja kompleksnost rešitve, saj se je npr. obseg vrstic kode poslovne logike v treh letih več kot podvojil. Potrebna specializacija strokovnjakov po vzoru »večjih« rešitev zahteva zadostno velikost uvajalske ekipe. Uveden je bil tudi poseben sistem certificiranja. Število Centrov za rešitve Navision se je tako nekoliko zmanjšalo, saj se manjši pridružujejo k večjim. Na dovolj velikih »zrelih« trgih se je uveljavila tudi na neki način »naravna« delitev trga po panogah. Posamezne razvojne ekipe so na podlagi standardne rešitve Navision razvile tudi povsem specializirane panožne rešitve, ki le v manjši meri uporabljajo standardno funkcionalnost in katerih dodana vrednost je zlasti v dobro strukturiranem poslovnem procesu in vanj vgrajenem organizacijskem znanju (»best practice«), Te rešitve lahko uvajajo le posebej usposobljeni Centri za rešitve Navision ali pa sami proizvajalci. Tipični in mednarodno razširjeni tovrstni rešitvi sta Incadea za avtomobilsko servisno in prodajno dejavnost in NaviMeat za mesno predelovalno industrijo. Zaradi velikega števila Centrov za rešitve Navision se je razvil tudi trg dodelav (»add-on«), ki podpirajo za splošne ERP rešitve manj pogoste procese. Tako Centri za rešitve Navision tržijo dodelave za leasing podjetja, za podrobno stroškovno računovodstvo, vmesnike za poročanje davčni upravi ipd. Nekatere od teh dodelav, npr. podporo proizvodnji in servisu, je Navision odkupil in jih postopno vključil v standardno različico rešitve. V Sloveniji so bile razvite predvsem dodatne rešitve, ki dopolnjejo standardno funkcionalnost s podporo lokalnim posebnostim. Tako sta na voljo dve različici obračuna plač, podpora za poenostavljene carinske postopke in carinsko skladišče, slovenski praksi prilagojena kadrovska evidenca, lokacijsko skladišče, (sedaj neobvezna) revalorizacija osnovnih sredstev in druge manjše dodelave. Analizo Navision-ovega poslovnega modela bomo zaključili z ugotovitvijo, da za ponudnike običajnih (»tipskih«) celovitih rešitev posebne zahteve naročnikov v splošnem predstavljajo težavo in odmik od nadaljnjih razvojnih načrtov, medtem ko so za ponudnike celovitih rešitev z odprto poslovno logiko morebitne posebne zahteve naročnikov in lokalne posebnosti predvsem priložnost za trženje lastnih storitev. Razumljivo je, da je običajno funkcionalna ustreznost dobro uvedene celovite rešitve z odprto poslovno logiko boljša od enakemu obsegu poslovanja namenjene »tipske« rešitve ERP, po drugi strani pa se lahko naročnik v prvem primeru sooči tudi z večjimi (in včasih nepotrebnimi) stroški uvajalskih storitev. 3 Učinkovitost celovitih rešitev z odprto poslovno logiko Učinkovitost celovitih rešitev poskušamo po eni strani oceniti s skupnimi stroški lastništva, po drugi strani pa z ustreznostjo nove funkcionalnosti. Na skupne stroške lastništva vplivajo predvsem nakupne cene licenc in morebitne dodatne strojne in programske opreme, stroški uvedbe ter stroški vzdrževanja. Velikokrat pa pozabljamo upoštevati v skupnih stroških lastništva stroške internih resursov podjetja, ki so potrebni za vzpostavitev in delovanje sistema. 3.1 Stroški računalniške opreme V cenovno primerjavo stroškov licenc se v tem prispevku ne bomo spuščali, saj načeloma proizvajalci (oz. trg) skrbijo za to, da je njihova rešitev glede na zmogljivosti cenovno dovolj konkurenčna. V splošnem pa velja, da je licenca po uporabniškem mestu za rešitve, namenjene srednjim podjetjem, cenejša kot za rešitve namenjene velikim. Hkrati morebitne »posebej ugodne« ponudbe manjših lokalnih ponudnikov kažejo na njihova omejena sredstva za dolgoročni razvoj in s tem na visoko tveganost naložbe v rešitev, ki jo ponujajo. Prav tako ne bomo analizirali stroškov potrebne infrastrukturne opreme, saj načeloma majhna razlika v potrebni konfiguraciji strežnika dolgoročno ne sme pomeniti ključnega dejavnika pri izbiri celovite rešitve. Seveda pa tudi tu velja, da so rešitve namenjene srednjim podjetjem v splošnem glede infrastrukturne opreme manj zahtevne od rešitev, ki so namenjene velikim. Hkrati so »svetovne« rešitve z vidika infrastrukturnih zahtev večinoma bolj optimizirane od enakemu obsegu poslovanja namenjenih rešitev manjših lokalnih proizvajalcev. 3.2 Stroški uvajalskih storitev Stroški zunanjih uvajalskih storitev se običajno ocenjujejo na med 50% in 400% vrednosti izhodiščne licence (odvisno od cene storitev na lokalnem trgu in vrste projekta). Če k temu dodamo še zelo pomembne a težko merljive stroške notranjih resursov in potencialne stroške neuspešne uvedbe (ponoven proces izbire, omajana avtoriteta vodstva in oddelka informatike) vidimo, da je v splošnem ključna razlika v skupnih stroških lastništva pri konkurenčnih rešitvah prav v stroških »mehkega« dela projekta. Te stroške (tudi potencialne) bomo torej v nadaljevanju upoštevali kot enega od dveh ključnih kriterijev učinkovitosti celovitih rešitev. Izkušnje uvajanja rešitve Navision v Sloveniji in na Hrvaškem kažejo, da se obseg svetovalnih storitev pri manjših projektih (npr. storitveno ali razmeroma preprosto trgovsko podjetje) giblje med 150 in 500 svetovalnimi urami. V takih implementacijah so prilagoditve seveda omejene bolj ali manj zgolj na »standardne« dodelave, ki jih je uvajalec razvil tudi za svoje ostale stranke. V primeru ustrezne razpoložljivosti kadrov na obeh straneh je čas priprav na začetek dela v živo lahko tudi zelo kratek, od nekaj tednov do dveh ali treh mesecev. Ob tem dodajmo še, da pogosto znaten del stroškov svetovalnih storitev v »manjših« projektih povzročijo procesi, ki niso ključna dejavnost podjetja, vendar so zahtevni za uporabnike (npr. obvladovanje osnovnih sredstev, obračun plač ipd.). V primeru zahtevnih uvajanj (storitveno podjetje z veliko dejavnostmi, proizvodno podjetje na več lokacijah in z MRPII planiranjem proizvodnje, povezave z drugimi informacijskimi rešitvami, znaten obseg povsem specifičnih prilagoditev, veliko število uporabnikov) pa je za uspešno dokončanje projekta lahko potrebnih tudi 300 ali več svetovalnih dni. Projekti takega velikostnega razreda v splošnem zahtevajo vsaj pol leta priprav do začetka dela »v živo«, nato pa še enak čas za stabilizacijo obvladovanja procesov z novo rešitvijo. Ti časovni okviri pa se lahko znatno podaljšajo v primerih, ko se v podjetjih posamezni procesi tudi vsebinsko razvijajo šele hkrati z implementacijo nove rešitve. 3.3 Ustreznost Ustreznost implementirane funkcionalnosti je povezana s samo strategijo informacijske funkcije. Podjetje mora svoje resurse usmerjati na tiste poslovne funkcije oz. njihove dele, kjer je korist od tega največja. Uporaba kompleksne celovite rešitve za podporo klasični prodajni in nabavni funkciji s skladiščem na eni lokaciji in nekaj deset transakcijami dnevno seveda ni smiselna investicija. Pogosto velja, daje bolje v celoti in temeljito uvesti manj zahtevno (in cenejšo) ERP rešitev, kot investirati v nakup kompleksnejše in dražje ter ostati brez sredstev za uvedbo kaj več kot le osnovnih funkcionalnosti. 3.4 Prednosti in slabosti z vidika investitorja Če torej kot ključna kriterija učinkovitosti izberemo stroške uvajalskih storitev in ustreznost nove funkcionalnosti, lahko v primerjavi z drugimi, enakemu velikostnemu razredu podjetij namenjenimi celovitimi rešitvami z vidika investitorja opredelimo naslednje prednosti in slabosti rešitve Navision, v splošnem pa tudi drugih celovitih rešitev z odprto poslovno logiko: Prednosti: 1. Dobra uvajalska ekipa lahko v celovitem razvojnem okolju hitro spreminja vso obstoječo in dodaja poljubno novo funkcionalnost v skladu s specifičnimi zahtevami naročnika (doseči je moč zelo visoko funkcionalno ustreznost). 2. Odprtost sistema omogoča razmeroma enostaven razvoj vseh potrebnih dodelav, kar je še posebej pomembno na z vidika celovitih rešitev majhnih trgih. 3. Razvojno orodje je posebej prilagojeno poslovni naravi rešitve, zaradi česar je razvoj specifične funkcionalnosti običajno hitrejši kot v »splošnih« orodjih. Med prednostmi Navision-ovega razvojnega okolja posebej izstopa učinkovito definiranje sumarnih indeksov po prometnih tabelah. 4. Možno je postopno prilagajanje funkcionalnosti spremembam v podjetju, s čimer je zagotovljeno dolgoročno spremljanje razvoja podjetja. 5. Uvajanje lahko poteka postopno in z manj tveganja. Zaradi prilagodljivosti rešitve je razmeroma enostavno podpreti z novim sistemom zgolj omejen del poslovnega procesa (npr. glavna knjiga in nabava), preostale podatke pa črpati še iz starega informacijskega sistema. Manjše tveganje posledično pomeni tudi nižje stroške testiranja (vzporednega teka) in s tem nižje stroške internih resursov. 6. Prilagodljivost sistema omogoča večjo obvladljivost tveganja neuspešnosti projekta (npr. uporabniške zavrnitve sistema) tudi v »slabo organiziranih« podjetjih, kjer management nima ustreznega vpliva na posamezne poslovne funkcije. 7. V manjših podjetjih je možna »hitra« uvedba, ker se sistem v fazi testiranja sproti prilagaja šele takrat ugotovljenim specifičnim zahtevam. 8. Dobra povezljivost s drugimi sistemi. Poleg posebne funkcionalnosti za uvoz, izvoz in ustrezno obdelavo podatkov iz drugega sistema je moč v obstoječi podatkovni model in poslovno logiko rešitve Navision vgraditi tudi vse morebitne potrebne referenčne podatke. Slabosti: 1. Tveganje neuspešnega razvoja dodelav, ki so ključne za uspešnost uvedbe. Za obvladovanje tovrstnega tveganja je pomembna temeljita in za obe strani povsem razumljiva specifikacija, z vidika naročnika pa tudi izbira uvajalca, ki razpolaga z ustreznimi vsebinskimi in tehničnimi znanji. 2. Tveganje nepotrebnega razvoja (in močno povečanih uvajalskih stroškov) zaradi prilagodljivosti rešitve. V primeru neustreznega internega projektnega vodenja ali premajhnih pooblastil internega projektnega vodje, lahko uporabniki na nižjih ravneh v zadnjih fazah uvajanja izsilijo razvoj nepotrebnih funkcionalnosti, saj s tem pogojujejo svoje sodelovanje pri projektu. Uvajalec, ki ima običajno nasproti uporabnikom na nižjih ravneh le omejeno pogajalsko moč, pod časovnim pritiskom bližnjega pričetka dela v živo »čez noč« razvije zahtevano dodatno funkcionalnost, ki običajno na dolgi rok zahteva precej popravkov in vzdrževanja. Če je prilagodljivost celovite rešitve manjša in se mora poslovanje prilagajati vgrajeni poslovni logiki, je tovrstno tveganje za investitorja precej manjše. Povzamemo lahko, da so Navision in druge celovite rešitve z odprto poslovno logiko zelo učinkovite z vidika funkcionalne ustreznosti in so nedvomno tudi stroškovno najboljša izbira v primerih, ko naročnik v analizo možnih alternativ resno vključi tudi lasten razvoj. Iz prilagodljivosti tovrstnih rešitev pa izhajajo tudi ključne slabosti oz. tveganja, ki jih je moč omejiti predvsem z dobrim projektnim vodenjem pri naročniku in z ustreznim operativnim nadzorom poslovodstva nad poslovnimi funkcijami v podjetju. Verjetnost uspešne uvedbe je torej tudi pri rešitvah z odprto poslovno logiko večja v podjetjih z dobro organizacijo in z dobro kadrovsko strukturo ter z jasno definiranimi cilji projekta. Prilagodljivost teh rešitev pa omogoča, da lahko ob večjih naporih uvajalske ekipe in daljši dobi uvajanja postopno zaživijo tudi v bolj togih in že desetletje nespremenjenih poslovnih okoljih, kjer je uvajanje celovitih sistemov izrazito tvegano. 4 Vidiki uvajanja rešitev z odprto poslovno logiko 4.1 Analiza in dizajn Uvajanje rešitev z odprto poslovno logiko lahko pomeni zgolj parametrizacijo rešitve v okviru standardne funkcionalnosti (izvzemši prilagoditve izpisov poročil), lahko pa gre za zahteven razvojni projekt, ki se le v omejenem obsegu navezuje na standarno funkcionalnost. Razvoj dodatne funkcionalnosti v okviru projekta uvajanja celovite rešitve zahteva tudi ustrezen pristop. Tako imenovana »gap-fit« analiza mora voditi k specifikaciji sprememb obstoječe funkcionalnosti oz. specifikaciji funkcionalnosti, ki jo je potrebno dodatno razviti. Ključna razlika med običajnimi razvojnimi projekti in razvojnimi projekti v okviru celovitih rešitev z odprto poslovno logiko je vpetost razvoja v obstoječ podatkovni model in logiko. Slednja običajno dovolj dobro pozna zgolj uvajalec, ne pa tudi vodja projekta pri naročniku in investitorji. Tako specifikacija dodelav, ki jo pripravlja uvajalec, ne sme temeljiti zgolj na opisu sprememb oz. dodatkov k podatkovnemu modelu in logiki s tem povezanih procesov, temveč mora nujno definirati funkcionalnost celotnega »novega« sistema, torej »predelane« različice celovite rešitve in po potrebi izrecno navesti tudi funkcionalnosti, ki jih načrtovana rešitev ne bo podprla. Le na ta način se lahko obe strani zadovoljivo zavarujeta pred neugodnimi presenečenji. Se pred pripravo specifikacije (in morda tudi pred sklenitvijo pogodbe) je priporočljivo splošno izobraževanje vodje projekta in izdelava preprostih pilotnih rešitev (še zlasti če je potencialni naročnik pripravljen v to investirati). 4.2 Razvoj Navisionov podatkovni model in poslovna logika sta zgrajena iz posameznih »objektov«: tabel, form, poročil, objektov za uvoz in izvoz podatkov (»dataports«) in objektov s programsko kodo (»code-units«). Ob izdaji novih različic rešitve Navision se spremenita podatkovni model in poslovna logika (struktura tabel in programska koda) v nekaterih, ob menjavi »generacije« rešitve pa celo v večini »objektov«. Navisionova običajna licenca omogoča naročniku (oz. njegovemu internemu oddelku informatike) dostop do razvojnega okolja in oblikovanje dodatnih tabel, form in poročil. Določeno doplačilo je potrebno le glede na število uporabljenih novih »objektov«. Vso samostojno razvito funkcionalnost lahko naročnik povezuje s standardnim podatkovnim modelom, ki pa ga ne sme spreminjati oz. posegati v poslovno logiko. V primeru tovrstnih zahtev se mora obrniti na Center za rešitve Navision. Uvajalci (Centri za rešitve Navision) razpolagajo z licenco, ki omogoča tudi poljubno spreminjanje »objektov« standardne rešitve in delo z istim razvojnim orodjem, kot ga uporabljajo tudi razvijalci poslovne logike samega proizvajalca. Standardna različica rešitve Navision je neke vrste polprodukt. Večji Centri za rešitve Navision projekta namreč običajno ne začnejo s povsem standardno različico, temveč že vgradijo nekatere svoje »običajne« dodelave, ki so povezane s panogo naročnika ali splošno poslovno prakso. V Sloveniji so takšne tipične dodelave povezane z obračunom DDV, s kompenzacijami, z analitiko danih posojil, z gotovinsko blagajno, s poročanjem Banki Slovenije ipd. Pri razvoju dodatne funkcionalnosti morajo razvijalci slediti naslednjim načelom: ■ popolne dokumentiranosti vseh posegov v kodo in tabele (v praksi se to izvaja predvsem z obilico komentarjev v kodi in sistemom označevanja sprememb); ■ dodatno funkcionalnost kar najbolj razvijati v ločenih (»lastnih«) objektih in spreminjati standardne objekte zgolj tam, kjer je to nujno potrebno; ■ dodatna funkcionalnost mora čimbolj podpirati vse standardne funkcionalnosti, ki so razpoložljive v celotnem sistemu (npr. stroškovna mesta, tuje valute, vrtanje po sumarnih podatkih ipd.) tudi če njihove uporabe v trenutku dizajna dodatne funkcionalnosti ne pričakujemo (z vidika uporabnika mora biti dodatna funkcionalnost povsem integrirana). Razvoj funkcionalnosti v ločenih objektih ima za razvijalce več prednosti: ■ manjše tveganje, da »povozimo« ali na nek način narobe uporabimo obstoječo standardno funkcionalnost (razvijalci ne potrebujejo tako podrobnega poznavanja standardne programske kode); ■ lažje migriranje na novo različico rešitve (lastni objekti se enostavno uvozijo, spremembe v programski kodi v standardnih objektih pa je potrebno prenesti bolj ali manj ročno); ■ lažje testiranje nove funkcionalnosti. Tipična značilnost celovitih sistemov je velikansko število možnih sosledij interakcij uporabnikov s sistemom. Enako velja tudi za dodelave in spremembe poslovne logike v odprtih celovitih sistemih. Ob omejenih resursih naročnika in izvajalca je popolno testiranje vseh možnih sosledij interakcij uporabnika s prilagojenim sistemom praktično nemogoče (oz. naročnik običajno tega ne financira). Če se zanesemo na to, da je proizvajalec standardne rešitve ustrezno testiral vso funkcionalnost, potem nam ne preobsežen uporabniški vmesnik nove dodelave in njena strogo omejena interakcija s standardno funkcionalnostjo močno zmanjšata potrebni obseg testiranja. Eno od najpomembnejših in zelo učinkovitih orodij pri razvoju v Navision-ovem okolju je sistem »plavajočih polj« (»flow fields«). Tako lahko npr. saldo v tabeli »konto glavne knjige« definiramo kot sumarno polje vsote postavk na tem kontu, ki so znotraj želenega datumskega obdobja (plavajočega filtra), definiranega na kartici konta. Sistem nam ob prikazu plavajočih polj omogoča tudi vrtanje v globino: dostop do postavk, ki ustrezajo datumskemu obdobju in ki tvorijo saldo. Vmesne salde sistem vodi sproti (kot su-marne indekse), zato je prikaz in aplikacija filtrov praktično trenutna tudi v veliki zbirki podatkov. 4.3 Povezljivost Velikokrat naročnik v določenem delu svojega poslovanja že uporablja neko specifično aplikacijo, ki je narejena na podlagi ene od »standardnih« podatkovnih baz (Oracle ali MS SQL) in evidentira določene analitične transakcije. Tovrsten primer je npr. sistem za spremljanje borznega poslovanja, ki v bistvu vodi analitično evidenco zalog, terjatev in obveznosti. Za zagotovitev prave integracije ERP rešitve in dodatnega informacijskega podsistema je poleg samega tehničnega prenosa podatkov (za kar je še posebej primerna verzija Navision-a na MS SQL bazi) potrebno ustrezno prilagoditi tudi poslovno logiko. Tipično je npr. potrebno sporočati dodatnemu podsistemu, katere od postavk terjatev, ki jih je predhodno posredoval osrednji ERP rešitvi se zapirajo z današnjimi plačili. Odprtost Navision-a v takem primeru omogoča vgradnjo referenčnih podatkov za dodaten podsistem v podatkovni model in definiranje ustrezne poslovne logike za te podatke znotraj logike standardnih transakcij knjiženja. 5 Zaključek Navision je verjetno najbolj razširjena celovita rešitev, namenjena srednje velikim podjetjem, ki temelji na konceptu odprte poslovne logike. Uvajalec, ki nastopa kot lastniško neodvisen partner proizvajalca, po eni strani prevzame celotno odgovornost za uspešno dokončanje projekta, po drugi strani pa dobi dostop in možnost spreminjanja in dograjevanja celotnega podatkovnega modela in poslovne logike, za kar ima na voljo tudi posebno finančnim aplikacijam prilagojeno razvojno orodje. Učinkovitost rešitve Navision in podobnih ERP rešitev smo ocenjevali na podlagi ustreznosti uvedene funkcionalnosti in skupnih stroškov lastništva, med katerimi smo izpostavili stroške uvajalskih storitev in vzdrževanja ter internih resursov. Ob tem smo pou- darili, da poslovnih procesov v srednjih podjetjih zaradi njihove vse večje specializiranosti in vpetosti v poslovno okolje ne gre več razumeti zgolj kot pomanjšane različice procesov v velikih podjetjih, iz česar izhajajo tudi povsem specifične funkcionalne zahteve. Ugotovili smo, da so Navision in druge celovite rešitve s povsem odprto poslovno logiko zelo učinkovite z vidika ustreznosti in zmožnosti uvajanja ter so verjetno najboljša alternativa v primerih, ko naročnik razmišlja tudi o razvoju lastne rešitve. Iz prilagodljivosti tovrstnih rešitev pa izhajajo tudi ključne slabosti oz. tveganje, ki ga je moč omejiti predvsem z dobrim projektnim vodenjem na strani naročnika in izvajalca ter z ustreznim operativnim nadzorom poslovodstva nad poslovnimi funkcijami v podjetju. Za učinkovito uvedbo mora biti naročnik dobro organiziran in imeti ustrezno kadrovsko zasedbo ter jasno definirane cilje projekta. Hkrati pa velika prilagodljivost tovrstnih rešitev omogoča, da lahko ob večjih naporih uvajalske ekipe in daljši dobi uvajanja postopno zaživijo tudi v bolj togih in že desetletje nespremenjenih poslovnih okoljih. Reference 1. Kindermann TCV GmbH: Expertenwissen zu Navision Financials. SRC Lehrbuch Verlag, Berlin, 1999. 2. Navision a/s: Navision Attain Essentials. Navision a/s, Voedbek, 2001. 3. Akkermans, Henka A.: The impact of ERP on supply Chain management: exploration findings from a European Delphi study. Fontainbleau: INSEAD, 1999. 4. Ahlin Tomaž: Uvajanje celovitih programskih paketov. Organizacija, letnik 34, št. 5 (maj 2001) str. 283-289. 5. Ptak, Carol A. ERP: tools, technipues and applications for integrating the supply Chain. St. Lucie Press, Falls Church, 2000. 424 str. 6. Donovan Mike: Why the Controversy over ROl from ERP? http://www.rmdonovan.com. 7. Mello Adrian: ERP Fundamentals. http://techupdate-zdnet.com 8. Harold Dave: How Manufacturing Benefits by Understanding ERP and IT. http://techupdate-zdnet.com ♦ Mag. Aleš Zajc je diplomiral leta 1996 in magistriral leta 1999 na Ekonomski fakulteti v Ljubljani, kjer je asistent na katedri za računovodstvo. V času študija se je izpopolnjeval tudi v tujini. Od leta 2000 je zaposlen v podjetju Adacta programska oprema d.o.o. kot direktor področja »Poslovne rešitve«. Aktivno je vodil več vsebinsko in razvojno zahtevnih projektov uvajanja rešitve Navision v Sloveniji in v tujini. ♦ Upravljanje oskrbovalnih verig IN NAČRTOVANJE Z APS Razprave Edvard Dolenc Domel, d. d., Otoki 21, 4228 Železniki edvard.dolenc@domel.com Izvleček Prispevek obravnava razvoj sistemov za napredno načrtovanje v oskrbovalnih verigah in analizira ustreznost sedanjih celovitih rešitev (ERP) glede na potrebe proizvodnih podjetij pri povezovanju v verige. Sistemi ERP informatizirajo procese samo v podjetju, pri načrtovanju se kapacitete virov upoštevajo kot neomejene. Informacijske rešitve za upravljanje oskrbovalnih verig z naprednejšim načinom načrtovanja so izboljšana razširitev ERP Prispevek opisuje izboljšan način načrtovanja s konceptom MRP III (Material Repuirement Planning). Operativna raven je dopolnjena s taktično, kije namenjena načrtovanju mreže dobaviteljev, in strateško ravnjo, ki pri načrtovanju upošteva statistične podatke iz podatkovnega skladišča. Upravljanje oskrbovalnih verig vključuje upravljanje z materialom, informacijami in s finančnimi sredstvi v mreži, ki jo sestavljajo kupci, proizvajalci in dobavitelji. Abstract SUPPLY CHAIN MANAGEMENT AND ADVANCED PLANNING BASED ON APS SYSTEMS The paper discusses the development of advanced planning systems (APS) in supply chains. It analyses the suitabil-ity of the existing Enterprise Resources Planning (ERP) Solutions concerning the needs of manufacturers as they combine into chains. The ERP systems only provide IT support to processes on an enterprise level by treating resource capacities as unlimited. The IT Solutions for Supply Chain Management using a more advanced method of planning are an improvement of ERP Solutions. The paper describes an improvement in the method of planning using the MRP lil concept. In addition to the operational planning level, two other /eve/s are used: the tactical level, designed for planning the supplier netvvork and the strategic level, which uses past statistical data from the data vvarehouse. Supply Chain Management includes management of materials, information and financiaI flows in a netvvork consisting of customers, manufacturers, and suppliers. 1 Uvod Podjetja se morajo pod vplivom globalizacije prilagajati novim razmeram na trgu in so zato prisiljena v prilagajanja. Razvojni in proizvodni cikli se skrajšujejo, zaradi boljše učinkovitosti se podjetja povezujejo v verige. Do danes so se poslovni procesi avtomatizirali in informatizirali v glavnem samo v okviru podjetja. Povezav med podjetji in informacijskih povezav skoraj ni ali so ohlapne, načrtovanje proizvodnje poteka na ravni obrata. Ugotavljamo, da to ni dovolj. Razmere na trgu narekujejo tesnejše povezovanje med podjetji, ki jim mora slediti tudi informatizacija. Razvoj informacijske tehnologije (IT) to omogoča. Medpodjetno povezovanje je treba informatizirati do stopnje, da bo proces potekal brez razmejitve med kupcem in dobaviteljem. Celoviti sistemi (ERP) ne omogočajo zadovoljive podpore, zato jih je treba nadgraditi, posebej kar zadeva načrtovanje potreb po materialu in kapacitetah. Stopnjo informatizacije v proizvodnem podjetju je treba dvigniti dovolj visoko, da bo omogočala izboljšan način načrtovanja v obratu, med obrati in med podjetji. 2 Razvoj celovitih rešitev, osnova razvoja oskrbovalnih verig 2.1 Razvoj V začetkih razvoja informacijske tehnologije (IT) so nastajale v podjetjih raznovrstne aplikacije, ki so informatizirale posamezna opravila zaposlenih na različnih delovnih mestih. Aplikacije so bile navadno slabo povezane ali sploh ne. Pred letom 1960 je bila informacijska podpora namenjena izključno nadzoru zalog in upravljanju z njimi ter upravljanje z materialom; v glavnem za evidentiranje transakcij (Ljubič, 2001). Takšni sistemi so bili razviti zelo individualno, navadno za znanega uporabnika. Cene računalnikov so bile zelo velike, zmogljivosti pa majhne. Zavedanje menedžmenta v podjetjih o pomembnosti informacijske tehnologije v podjetjih je bilo majhno, zato naložbe vanjo niso bile bistvenega pomena. Tarn, Ven in Beaumont (2002) poudarjajo, da je treba v podjetju zagotoviti integriran tok informacij osrednjega sistema, ki zagotavlja potrebne podatke za vse dele podjetja. Težnja k izboljšanju informatizacije v podjetju in težnja k integriranosti je vodila razvoj in nadgradnjo z današnjimi celovitimi rešitvami, ki so zrasle iz sistemov za načrtovanje materialnih potreb (Materini Requirement Planning - MRP). Razviti so bili konec šestdesetih, v sedemdesetih in osemdesetih letih preteklega stoletja predvsem za potrebe velikih proizvodnih podjetij z namenom upravljanja materiala v podjetju. Evolucija ERP je v osnovi odziv na zahteve globalnega trga, zahteve kupcev in spremembe v poslovnem svetu ter zahteve, ki jih narekuje IT (Keller, Teufel, 1998). Rešitve ERP so zbirke povezanih aplikacij, Slotten in Yap (1999) sta ERP definirala kot povezan in večdimenzionalen sistem za vse funkcije v podjetju, ki temelji na poslovnem modelu za načrtovanje in nadzor, ter temelji na IT, vključuje notranje in zunanje dejavnike. Značilnost ERP je, da uporabljajo enotno bazo podatkov, vsi poslovni procesi so izpeljani iz enotnega informacijskega sistema (Tarn, Yen, Beaumont, 2002). ERP ponavadi integrirano pokriva poslovne procese samo znotraj podjetja. Informacijske povezave med podjetji so ohlapne, največkrat pa jih sploh ni. ERP je bil v devetdesetih letih dopolnjen. Združeval je funkcije MRP II (Manufacturing Resource Planning) in MRP, ki so bile razvite predvsem za proizvodno industrijo (Shtub, 1999). MRP je nastal kot razmeroma preprosto orodje za analizo strukture kosovnic in proizvodnih postopkov, ki z eksplozijo kosovnic ugotovi, kakšne bodo potrebe po komponentah in kapacitetah, po sortimentu in količinah, da bi izpolnil načrt proizvodnje. Za časovno razporeditev potreb MRP uporablja standardizirane dobavne čase za kupljene komponente in izračunane pretočne čase za izdelane sestavne dele in generira priporočila za izdelavo sestavnih delov (predloge proizvodnih akcij) ter priporočila nabavnih naročil (predloge nabav) za kupljene komponente. Pri tem predvideva, da so kapacitete virov v proizvodnji in nabavi neomejene, ne upošteva nobenih omejitev in ne skuša optimirati predlogov (Ljubič, 2001). Koncept MRP II je osnovni MRP obogatil tako, da je pokril še dodatne procese načrtovanja, predvsem pa je uvedel povratne zanke (feedback), sicer ne toliko, da bi avtomatsko optimiral in popravljal načrt proizvodnje, pač pa, da bi ugotavljal in opozarjal na premajhne zmogljivosti virov; pri dobaviteljih in v proizvodnji (Ljubič, 2000). MRP II se navadno šteje za koncept načrtovanja potreb po vseh virih na vseh ravneh proizvodnje. Ob tem se je sistem razvijal in dodajal ter razširjal nove rešitve (npr. v finančnem nadziranju podjetja). 2.2 Zahteve trga Potreba po skrajševanjih proizvodnega cikla in zagotovitvi preglednosti proizvodnega procesa je vedno večja - vse od zahtevka kupca po izdelku do pravočasne dostave (Kovačič, 1998). Podjetja se soočajo z novimi trgi, novo konkurenco in čedalje večjimi zahtevami ter pričakovanji kupcev (Ljubič, 2001). Pri tem moramo nedvomno upoštevati trend proizvajanja za znanega kupca z natančno opredeljenimi količinami in roki, ki pogojujejo drugačen način načrtovanja, časovnega razvrščanja proizvodnje in zniževanje količin v seriji ter s tem povečevanje števila vzporedno potekajočih delovnih nalogov (Kovačič, 1998). To postavlja pred proizvajalce velike zahteve (Ljubič, 2001): ■ zniževanje stroškov proizvodnje, ■ krajšanje izdelovalnih časov in proizvodnega ciklusa, ■ zmanjšanje zalog, ■ prilagajanje izdelkov zahtevam kupcev in s tem večja izbira izdelkov, ■ povečevanje kakovosti izdelkov in poslovanja, ■ kratke dobavne čase in zanesljivost dobavnih rokov, ■ dislokacija in decentralizacija, ■ učinkovito usklajevanje globalnega povpraševanja, preskrbe in izdelave. Zahteve kupcev neposredno vplivajo na nadzor in upravljanje proizvodnih sistemov ter se ne morejo preprosto uravnovesiti z zalogami in velikimi kapacitetami. Bistveni problem proizvodnih podjetij je, kako učinkovito uporabljati razpoložljive vire, ki pa so omejeni, in hkrati vzdrževati visoko raven servisiranja kupcev. Uspešnost podjetja je odvisna od hitrega toka informacij prek celotne oskrbovalne verige, od kupca do proizvajalca in od proizvajalca do dobavitelja (Ljubič, 2001). 3 Oskrbovalne verige Pojem upravljanja oskrbovalnih verig (Supply Chain Management - SCM) vključuje upravljanje z materialom, informacijami in s finančnimi sredstvi v mreži, ki jo sestavljajo dobavitelji, proizvajalci in kupci (SAP, 2001). SCM omogoča vsem sodelujočim v oskrbovalni verigi skupno delo, skupno koordinacijo na osnovi skupnih informacij z namenom, da pospeši vzajemno delovanje od kupca do dobavitelja in da čim bolj zmanjša stroške transakcij (Lavvrence, 1999). Koordinacija tako širokega kroga udeležencev, da delujejo ustrezno povezano, je kompleksna. Namen oskrbovalnih verig je znižati stroške proizvodnje polizdelkov in končnih izdelkov, izboljšati storitve, znižati stroške poslovanja in optimalno izkoristiti resurse podjetij. Ključna sestavina učinkovite oskrbovalne verige je informatizacija vseh funkcijskih področij poslovanja (Talluri, 2000). Kar zadeva oskrbovalne verige, je zelo pomembno, da nanje gledamo kot enovit poslovni proces, ali kot pravi Armistead (1996): »Pomembneje komuniciranje med členi verige na osnovi poslovnega procesa in ne iste funkcije ali lokacije«. Na podlagi tega lahko rečemo, da organizacije, ki so povezane v proces, sestavljajo eno samo veliko navidezno organizacijo. Povezave med tako vključenimi podjetji pa so kompleksne in težko obvladljive. Delovanje tovrstnih sistemov je mogoče samo z ustrezno informatizacijo, ki procese avtomatizira in ustrezno nadzoruje. Od sredine osemdesetih let je moč opaziti, da številne uspešne organizacije sodelujejo s partnerji v njihovih oskrbovalnih verigah (Porter, 1987). Posledica sodelovanja in povezanega zunanjega oddajanja posameznih del (ang. outsourcing) neposredne dejavnosti organizacije so medorganizacijske mreže (McAdarn, McCormack, 2001). Christopher (1992) definira upravljanje oskrbovalne verige kot potrebo za podaljšanje logistike zunaj meja podjetja s tem, da vključi dobavitelje in stranke. Klasični ERP (in MRP) zahtevam kupca in časa ne ustreza več v celoti. Sam koncept načrtovanja in upravljanja proizvodnje, ki ga podpira, sicer ni sporen, a ni zadosten. Zato si mnogi proizvajalci programske opreme prizadevajo za naprednejši sistem načrtovanja proizvodnje in razširitev učinkovitosti ERP predvsem v nekaj smereh (Ljubič, 2000): e spremljanje trga in napovedovanje potreb, e takojšnje upoštevanje omejitev virov pri načrtovanju, e preverjanje razpoložljivosti v realnem času, e simulacija obnašanja proizvodnega sistema v različnih okoliščinah in podpora odločanju, e podpora specifičnim metodam in tehnikam načrtovanja, podpora tehnikam zagotavljanja kakovosti, podpora upravljanja s človeškimi viri, e koncentracija, integracija in analiza informacij za menedžment (OLAP) in podpora odločanju. S tega razloga mnogi ponudniki rešitev ERP in sistemov APS (Advanced Planning and Scheduling) integrirajo module za optimizacije v svoje rešitve SCM. Naslednji ponudniki rešitev ERP npr. načrtujejo (Tal-luri, 2000) ali že ponujajo rešitve za optimizacijo kapacitet. Podjetje PeopleSoft razvija Enterprise Re-source Optimization (ERO) (Talluri, 2000), Baan razvija svojo rešitev, SAP, npr., razvija SCM s tem, da svojo osrednjo rešitev ERP R/3 integrira s sistemom Advanced Planner and Optimizer (APO). 3.1 Sistemi APS Pri informacijskih rešitvah za oskrbovalne verige je osrednja rešitev, ki je namenjena načrtovanju, najpomembnejše del načrtovanja, in sicer za proizvodne obrate znotraj podjetja in obrate pri dobaviteljih. Pri večini ponudnikov so svoje sisteme zasnovali tako, načrtovanje strateško načrtovanje strateška usmeritev podjetja načrtovanje mreže oskrbovalne verige načrt povpraševanja dobavitelj načrtovanje v mreži dobaviteljev (SNP) taktično načrtovanje zunanji proces načrtovanja (SNP-> PP-DS) načrtovanje proizvodnje (SNP -> PP-DS) partnerji operativno načrtovanje nabava (materialno poslovanje) proizvodnja (npr. delovni nalogi) zunanja nabava izvajanje v ERP izvajanje Slika 1: Ravni oskrbovalne verige (SCM) da so načrtovanje izvzeli iz osrednjega transakcijskega sistema (ERP) in ga vzpostavili kot samostojni strežnik, v samostojni sistem APS (Advanced Plan-ning and Scheduling), ki je seveda tesno povezan s transakcijskem sistemom. Razlog za to je predvsem hitrejše delovanje. Rešitve za informacijsko podporo oskrbovalnim verigam lahko razdelimo na dva dela: ■ raven načrtovanja (APS) in ■ raven izvajanja (ERP). APS je nova generacija sistemov za načrtovanje z istočasnim načrtovanjem potrebnih količin in potreb po kapacitetah (SAP, 2001). MRPIII ali njegov koncept v APS, ki je njegov osrednji del, se razlaga kot izboljšana različica MRP II. Začne se z natančnim napovedovanjem povpraševanja, ker se predvideva, da je prav ta napoved gonilo vsega poslovanja. Pri tem izhaja iz statističnih podatkov iz preteklosti (Ljubič, 2000). Načrtovanje je razdeljeno na več ravni: ■ strateško, ■ taktično in ■ operativno. Strateško načrtovanje je dolgoročno in se navadno izvaja vsakih nekaj let, ko podjetja razširjajo ali spreminjajo svoje zmožnosti (Talluri, 2000). Začetni del oskrbovalne verige je načrtovanje mreže oskrbovalne verige, to pomeni določitev lokacije, nato velikosti in optimalnega števila dobaviteljev, proizvodnih obratov ter distributerjev, ki so vključeni v mrežo (Advanced Manufacturing Research, 1998). S pomočjo orodij za načrtovanje mreže se pripravi povezave z zunanjim sistemom, iz katerih APS pridobi podatke (SAP, 2001) o: ■ lokacijah (obrati, distribucijski centri, dobavitelji, stranke), ■ kapacitetah ali virih, ■ proizvodnji, ■ skladiščih, transportih, ■ izdelkih, ■ tehnoloških postopkih in kosovnicah. Orodja za načrtovanje mreže so del celovitih orodij, združenih v nadzorno ploščo (Supply Chain Control Panel ali Supply Chain Cockpit), preko katere je mogoče spremljati več parametrov, ki so pomembni za upravljanje oskrbovalne verige: ■ upravljanje in nadzor nad modelom oskrbovalne verige, ■ nadzor nad informacijami APS, e pregled glavnih podatkov (lokacij, kapacitet, izdelkov itd.), e spremljanje opozoril, e spremljanje delovanja APS. K osrednjemu delu strateškega načrtovanja prištevamo načrtovanje povpraševanja (Demand Planning - DP). Namenjeno je procesu načrtovanja povpraševanja kupcev in pomeni dolgoročno načrtovanje. Orodja omogočajo vključitev več oddelkov, obratov, pa tudi drugih podjetij in njihovih obratov z namenom napovedovanja prodajnega procesa. Omogoča napovedovanje na osnovi statističnih podatkov prodaje iz preteklosti (SAP, 2001). Tehnike napovedovanja temeljijo na algoritmih, ki iz podatkov prodaje posameznih izdelkov v preteklosti kreirajo korelacije za prepoznavanje povezav med preteklo prodajo in napovedovanjem datuma in količine (velikosti serije) dobave. Koncept delovanja DP je namenjen izključno načrtovanju in ne transakcijskemu delu. Podatke, ki jih potrebuje za delo, zato pridobi iz dveh virov: e iz osrednjega ERP. Iz tega sistem ASP črpa podatke, kot so podatki prodajnih naročil (datumi, količine), podatki lokacij (obrati, kupci, dobavitelji ...), izdelkov, resursov, kosovnic, tehnoloških postopkov, stanje zalog, prodajna hierarhija in drugi prodajni podatki; e iz sistema podatkovnih skladišč (Business Wnre-house - BW). Podatki v njem prestavljajo skupno bazo za vsa prodajna dogajanja, ki so se odvijala v preteklosti. DP izrablja podatke za napovedovanje prodaje. Taktično načrtovanje obravnava načrtovanje pri dobaviteljih, ki v osnovi vsebuje optimizacijo toka materiala in storitev skozi omenjeno mrežo. Na tej ravni se odloča o tem, kateri izdelki se bodo izdelovali v posameznih obratih, kakšne kakovosti in kakšne vrste surovin ter polizdelkov morajo izdelati. Taktično načrtovanje je srednjeročno načrtovanje, kar navadno pomeni mesečno ali nekajmesečno obdobje (Talluri, 2000) in je nadaljevanje strateške ravni načrtovanja. Odločilno vpliva na operativno načrtovanje ter na izvajanje, in sicer zato, ker oblikuje pogoje načrtovanja v podjetju (načrtovanje oseb, sistemi IT, njihova izbira, uporaba in nastavitev parametrov, procesa načrtovanja), kakor tudi posameznih delov, kjer se načrtovanje izvaja. Osrednji del taktičnega načrtovanja je načrtovanje v mreži dobaviteljev (Supply Netvvork Planning -SNP). SNP integrira nabavo, proizvodnjo, distribucijo ter transport in pomeni obsežen načrt na taktični ravni. Rezultat takšnega načrta je optimizacija funkcij v oskrbovalni verigi. SNP kreira grob načrt proizvodnje in distribucije - ki temelji na količinah in med-lokacijski proizvodnji - z individualnimi kosovnicami in s tehnološkimi postopki. SNP omogoča, da so ob določenem času na voljo ustrezne količine (SAP, 2001) in uskladi logistiko celotne oskrbovalne verige. Pri tem je pomembno, da kosovnice vsebujejo izdelke, ki so lahko ozka grla z vidika resursov. Glavna vsebina SNP je zato (SAP, 2001): ■ načrtovanje količin izdelkov pri dobaviteljih, ■ integrirana nabava, proizvodnja in distribucija, ki je povezana v celotno skupno mrežo, ■ časovno usklajene aktivnosti in načrtovanje toka materiala skozi oskrbovalno verigo. Operativno načrtovanje je kratkoročno, to je načrtovanje dnevnega ali celo urnega terminiranja za vse vključene obrate (Talluri, 2000) - torej načrtovanje proizvodnje in podrobno terminiranje (Production Planning and Detailed Scheduling - PP-DS). S tem, ko se načrtovane zahteve prek SNP prenesejo v območje proizvodnje, prehajamo v načrtovanje proizvodnje. PP-DS se izvaja s posebnimi orodji. Načrtovanje proizvodnje je odvisno od različnih načinov proizvodnje, kot so npr. proizvodnja na zalogo, za naročilo in seveda vmesne možnosti. Od tega je odvisen tudi proces načrtovanja in terminiranja v proizvodnji. Rešitve APS posameznih proizvajalcev so med seboj podobne, vsak pa posamezno delovanje rešuje nekoliko drugače. Naj omenimo samo nekaj lastnosti, ki jih predstavlja PP-DS: ■ sočasno načrtovanju zahtev po materialu in kapacitetah na operativni ravni, v proizvodnih obratih. V primeru, da izdelka ni na voljo, sistem neposredno sproži postopek za proizvodnjo. Če se sproži naročilo za proizvodnjo znotraj podjetja, APS kreira načrtovalske naloge za želene količine. Če so kapacitete za želeni datum zapolnjene, APS sočasno načrtuje zahteve po materialu in kapacitetah, zato da najde ustrezen datum, pri katerem bi se lahko kreiral načrtovalski nalog; ■ orodja za načrtovanje in terminiranje proizvodnje; grafična orodja, ki jih sistemi ponujajo, uporabniku z grafično predstavitvijo olajšajo delo. Načrtovanje in terminiranje poteka prek načrtovalskih desk, ki so namenjene interaktivnemu načrtovanju. Posamezne objekte (npr. naloge) je mogoče izbirati neposredno s pomočjo miške. Pogledi načrtovalske deske se lahko prilagajajo (npr. pregled resursov in naročil), priredijo različna urejanja itd.; ■ optimizacija terminiranja; orodja omogočajo optimizacijo in najboljšo izrabo zasedenosti proizvodnje in virov. Njihova naloga je kreiranje najustreznejših načrtov proizvodnje in povečanje zmogljivosti proizvodnje. Pri tem je mogoče nastaviti vrednost in pomembnost več parametrov (npr. nastavitveni časi, točnost dobave ...), ki služijo kot uteži za določanje najbolj optimalnega načrta. Orodja omogočajo simulacijo načrta proizvodnje, in sicer tako, da uporabnik sistema načrt potrdi in ga prenese v raven izvajanja šele takrat, ko je z njim zadovoljen. Izvajalske funkcije, kot so npr. knjiženja, se odvijajo zunaj APS, in sicer v osrednjem transakcijskem sistemu ERP. Naročila kupca se vnesejo v ERP, APS podatke samo uporablja. Vsi podatki - kot so podatki o zalogah, stanje v proizvodnji, podatki o kupcih ter dobaviteljih, kapacitetah itd. - se vnašajo in nahajajo v ERP. Kot smo že omenili, je APS zbirka orodij, namenjena samo načrtovanju, in ne transakcijskemu delu, zato APS podatke obdela in jih vrne v ERP, in sicer (SAP, 2001): ■ razpoložljive datume in količine, ■ načrt nabave, ■ načrt distribucije, ■ načrt proizvodnje. APS je namenjen načrtovanju, vse druga opravila se odvijajo na ravni izvajanja v sistemu ERP (npr. izpis delovne dokumentacije), in sicer na povsem enak način kot pri standardnem načinu dela v ERP. Na naslednji sliki je simbolično prikazana zgradba APS, njegovi sestavni deli strateške, taktične in operativne ravni ter ravni izvajanja in medsebojno povezanosti, kot jo navaja SAP (2001). Globalno preverjanje razpoložljivosti dobav (Available To Promise - ATP) je v oskrbovalnih verigah namenjeno vsakovrstnim naročilom v procesu. Preverjanje razpoložljivosti se sproža ob raznovrstnih dogodkih v sistemu OLTP. Delovanje je neprestano -ves čas preverja zmožnosti za zagotavljanje potrebnih izdelkov zahtevane kakovosti, v dobavnih rokih, ki jih zahteva kupec. ATP navadno poznajo že rešitve ERP, sistem globalnega ATP je v APS dopolnjen tako, da ne omogoča dela samo na ravni enega obrata, ampak širše, na ravni več obratov, podjetij oz. dobaviteljev. Upravljanje transporta je integrirano v zgoraj omenjeni proces načrtovanja in vsebuje naslednje funkcije: ■ načrtovanje in urejanje transporta, ■ terminiranje prevozov, usklajevanje cestnih poti v dinamičnem okolju, ■ upravljanje z večtokovnim nakladanjem in razkladanjem tovora, ■ upravljanje v primerih določenih izjem. Upravljanje transporta se izvaja na taktični in operativni ravni načrtovanja, deluje na ravni vseh udeležencev v oskrbovalni verigi. 3.2 Hitra odzivnost nove tehnologije Najnovejše rešitve za načrtovanje proizvodnje APS, kot so npr. rešitve proizvajalcev Baan ali SAP, svoje hitro delovanje in odzivnost dosegajo predvsem na osnovi novejše tehnologije. Bistveno pri njih je, da ločujejo osrednji transakcijski sistem OLTP (Online Transnctional Processing) ali sistem ERP in rešitev, ki je namenjena načrtovanju (APS). To pomeni, da se vse APS OLTR nadzorna plošča OLAP podatki iz preteklosti logistični podatki, kontrola, kadri, finance prodajni nalogi nadzor proizvodnje parametri upravljanje z zalogami transport razvrščevalec načrtovanje proizvodnje in podrobno terminiranje globalni ATP načrtovanje v mreži dobaviteljev načrtovanje transporta načrt povpraševanja Slika 2: Zgradba APS Vir: Povzeto po arhitekturi sistema APS, sistem APO v SAP, 2001 transakcije, kot je npr. vnos glavnih podatkov materiala ali pa npr. vnos naročila, izvajajo na transakcijskem strežniku OLTP, načrtovanje proizvodnje, ki zahteva velike zmogljivosti računalnika, pa se odvija na povsem ločenem in zelo zmogljivem strežniku. Podrobneje sistem načrtovanja deluje tako, da APS dobi podatke iz ERP in iz sistema OLAP (Online An-alytical Processing), potrebne podatke (načrt proizvodnje) pa v realnem času vrne v ERP. Sistem OLAP v tem primeru predstavlja bazo podatkov za vse podatke iz preteklosti. APS in ERP sta povezana prek vmesnikov, ki čim bolj učinkovito združuje oba sistema, npr. Core Interface je vmesnik, ki povezuje izmenjavo podatkov med APO (APS proizvajalca SAP) in R/3 (ERP proizvajalca SAP) (SAP, 2001). Vendar razvijalci gradijo ERP in APS tako, da ni nujno imeti osrednjega ERP na eni strani in APS na drugi strani istega proizvajalca. V primeru različnih proizvajalcev uporabijo standardizirane vmesnike, kot je standardni vmesnik Business Application Programming Interface (BAPI). Povezava do sistemov OLAP ali podatkovni skladišč poteka na povsem enak način. Kot smo že omenili, je za hitro delovanje APS pomembno to, da tečejo na povsem drugem strežniku kot osrednji ERP. V preteklih letih si ne bi mogli predstavljati povsem ločenih sistemov samo zato, da bi na enem tekel sistem načrtovanja proizvodnje. Po eni strani so cene strojne opreme v zadnjih letih precej padle, na drugi so se zmogljivosti močno povečale, kar je vodilo proizvajalce v to, da so začeli razvijati rešitve za načrtovanje na povsem ločenih strežnikih. V primerjavi z načrtovanjem proizvodnje v osrednjem ERP je druga bistvena razlika ta, da se zmanjša potreba po dostopu podatkov in branju podatkov z diska. To je mogoče doseči na način, da ima strežnik APS zelo veliko pomnilnika in da med delom samih podatkov ne bere s podatkovnih diskov. APS je narejen tako, da se ob zagonu - v povezavi z ERP -preberejo vsi potrebni podatki (lokacije, viri, kapacitete, kosovnice, tehnološki postopki) neposredno v pomnilnik, s tem pa strežnik med delom ne izgublja časa z branjem z diskov. Pri tem, ko se vsi podatki nahajajo neposredno v pomnilniku, se poveča hitrost delovanja oz. dostop do podatkov tudi za stokrat. Če aplikacija dostopa do podatka na disku, porabi več kot eno milisekundo, če pa aplikacija dostopa do podatkov neposredno v pomnilnik, se hitrost dostopa poveča na deset mikrosekund (SAP, 2001). 4 Zaključek Klasični ERP, s sedanjo vsebino in zmogljivostmi, zahtevam kupca in časa ne ustreza več v celoti. Rešitve ERP, ki jih poznamo, informatizirajo poslovne procese v podjetju. Razvijalci ERP nadgrajujejo z rešitvami SCM in s tem upravljanje z materialom, informacijami in s finančnimi sredstvi razširijo v mrežo, ki jo sestavljajo dobavitelji proizvajalci in kupci. Osrednjo vlogo v oskrbovalnih verigah imajo sistemi za načrtovanje ASP. Ti sistemi nadgrajujejo ERP tako, da uvajajo strateško, taktično in operativno načrtovanje. Strateška raven načrtovanja na osnovi podatkov iz ERP in podatkovnih skladišč omogoča izdelavo načrta povpraševanja. ERP je omogočal načrtovanje znotraj podjetja, učinkovito samo v okviru enega obrata. Rešitve SCM uvajajo taktično načrtovanje in omogočajo vzajemno načrtovanje med različnimi obrati v podjetju in pri dobaviteljih. Operativno načrtovanje dopolnjuje načrtovanje proizvodnje ERP. Prinaša kar nekaj izboljšav, ker omogoča sočasno načrtovanje materialnih potreb in kapacitet v več obratih podjetja in pri dobaviteljih z možnostmi izdelave simulacij. 5 Literatura 1. Armistead C. (1996): Principles of business process management. Journal of Managing Services Quality, Vol. 6, No. 6, 1996, str. 48-52 2. Christopher M. (1992): Logistics and Supply Chain Management, Pitman Publishing. London 3. Keller G., TeuferT. (1998): SAP R/3 Process-Oriented Implementation, Addison-Wesley: VVorkingham 4. Kovačič A. (1998): Informatizacija poslovanja. Ekonomska fakulteta, Ljubljana 5. Lavvrence B. (1999): Closing the logistics loop: a tutorial. Production and lnventory Management Journal. Vol. 40 No. 1, lst quarter, 1999, str. 43-51 6. Ljubič T. (2001): MRP/CRR MRP II, ERP ... in kaj potem? Zbornik posvetovanja z mednarodno udeležbo, Portorož 2001. Portorož : Moderna organizacija, 2001, str. 214-223 7. Ljubič T. (2000): Planiranje in vodenje proizvodnje - modeli, metode, podatki. Moderna organizacija, Kranj 8. McAdam R., McCormack (2001): Integration business processes for global alignment and supply chain management. Business Process Management Journal. MCB University, Vol. 7, No. 2, 2001, str 113-130 9. Porter M. (1987): Managing value - from competitive advantage to corporate strategy. Harvard Business Revievv. 10. SAP (2001): Advanced Planner and Optimizer - Overvievv. SAP AG 11. Shtub A. (1999): Enterprise Resource Planning (ERP). The Dynamic of Operation Management. Kluwer Academic Publishers, Norvvell, Ma 12. Talluri S. (2000): An IT/IS acquisition and justification model for supply-chain management. Business Process Management Journal. MCB University, Vol. 30, No. 3/4, 2000, str 221-236 13. Tam J. M., Ven C. D., Beaumont M. (2002): Exploring the rationales for ERP and SCM integration. Industrial Management & Data Systems. MCB UP Limited, 2002, str. 26-34 ♦ Edvard Dolenc je diplomiral na Fakulteti za organizacijske vede Univerze v Mariboru, podiplomski študij nadaljuje na Ekonomski fakulteti v Ljubljani. Zaposlen je v Dometu, d. d., kjer je nekaj let delal kot programer. Ob informacijski prenovi poslovanja v Dometu je vodil projekt vpeljave poslovnega informacijskega sistema SAP R/3. Trenutno je zadolžen za načrtovanje in vodenje poslovnega informacijskega sistema in za njegovo nadaljnjo nadgradnjo. ♦ Vabilo k sodelovanju na 10. posvetovanje Dnevi slovenske informatike 2003 SLOVENSKA INFORMATIKA ZA TRETJE TISOČLETJE: V DRUŽBI NAJ RAZVITEJŠIH Kongresni center Grand hotel Emona, Portorož, 16. - 18. april 2003 Organizatorji: Slovensko društvo INFORMATIKA Gospodarska zbornica Slovenije - Združenje za informatiko in telekomunikacije Infos, d.o.o., Ljubljana Dnevi slovenske informatike 2003 so deseto jubilejno posvetovanje slovenskih informatikov, ki si je priborilo ugled najpomembnejšega slovenskega strokovnega srečanja na področju informatike. Postalo je viden dogodek, ki se ga kot vabljeni predavatelji radi udeležijo tudi tuji strokovnjaki in tisti slovenskega rodu, ki delujejo v tujini. PROGRAM DSI 2003 pokriva vse vidike informatike, zaokrožene v naslednje sklope: ■ poslovna informatika in elektronsko poslovanje ■ informacijske tehnologije in internet ■ informacijska kultura in družba Vabimo vas, da kot strokovnjak iz prakse, uporabnik ali raziskovalec posredujete svoje izkušnje drugim ali pa svoje kolege seznanite z novostmi ter dosežki svojega dela in nam pošljete svoj prispevek. Prispevke bomo letos sprejemali samo v elektronski obliki preko spletnih strani posvetovanja http://www.dsi2003.org, kjer so na voljo tudi navodila za avtorje in dodatne informacije. Vaše prispevke pričakujemo najkasneje do 15.1.2003. O uvrstitvi v program in morebitnih potrebnih spremembah vas bomo obvestili do 15.2.2003. Končno obliko prispevkov pričakujemo najkasneje do 10.3.2003. Vse želene informacije dobite na naslovu dsi2003@drustvo-informatika.si The 7th International Symposium on Operations Research (SOR’03) 24. - 28. september 2003, Podčetrtek Organizator: Slovensko društvo INFORMATIKA - Sekcija za operacijske raziskave http://www.drustvo-informatika.si/sekcije/sor/novosti.jsp. Cilji srečanja: Področje operacijskih raziskav in aplikacij operacijskih raziskav v ekonomijo, poslovne znanosti, organizacijo, proizvodnjo, ekologijo, itd. se v svetu in pri nas zelo hitro razvija. Na mednarodnem simpoziju iz operacijskih raziskav SOR’03 pričakujemo izmenjavo izkušenj, pretok novih spoznanj in rešitev v mednarodnem in slovenskem okviru, identifikacijo praktičnih problemov ter operativni pristop k tržni ekonomiki. Tridnevni program simpozija sestavljajo različne tematske sekcije: ■ Metodologija in tehnike operacijskih raziskav (kombinatorična optimizacija, teorija odločanja, strateške igre, linearno programiranje, celoštevilsko programiranje, večkriterialno odločanje, mrežno planiranje in grafi, nelinearno programiranje, numerične metode, simulacija, statistika, stohastični procesi, vektorska optimizacija, itd.) ■ Aplikacije operacijskih raziskav v agronomiji, bančništvu, ekologiji, ekonomskih sistemih, energiji, varovanju okolja, financah, proizvodnji, zalogah, transportu, itd. ■ Informatika in računalništvo v operacijskih raziskavah (umetna inteligenca, sistemi za podporo odločanja, ekspertni sistemi, informacijski sistemi, računalniški programi s področja operacijskih raziskav, itd.) Uradni jezik simpozija je angleščina. Kot običajno bomo tudi letos izdali zbornik recenziranih prispevkov. Vabilo udeležencem: Na konferenco vabimo vse, ki pri svojem delu razvijajo ali uporabljajo operacijske raziskave. Izpolnjeno prijavnico pošljite na naslov: Slovensko društvo INFORMATIKA - Sekcija za operacijske raziskave, Organizacijski odbor SOR’03, Vožarski pot 12,1000 Ljubljana. Udeleženci, ki želijo na simpoziju predstaviti svoje prispevke, naj pošljejo prispevek najkasneje do 1. junija 2003. Obvestilo o sprejetju boste prejeli do 1. julija 2003. Prijavnico in navodilo za pisanje prispevka dobite na http naslovu: http://www.drustvo-informatika.si/sekcije/sor/ ali pa se javite na naslov: lidija.zadnik@uni-lj.si. TERMINOLOŠKI SLOVAR INFORMATIKE Slovensko društvo INFORMATIKA je kot organizacija, ki izdaja dve reviji s področja informatike in zbornike strokovnih srečanj, spoznalo potrebo po sistematičnem pristopu k razvoju strokovnega jezika. Izraz tega spoznanja je bila ustanovitev sekcije za jezik, ki je svoje poslanstvo kratko in jedrnato izrazila z geslom: ni strokovne odličnosti brez odličnega strokovnega jezika. Kot najpomembnejšo nalogo si je sekcija zadala sestavo terminološkega slovarja informatike. Slovarje namenjen članom društva in najširši javnosti: znanstvenim delavcem s področja informatike, prevajalcem strokovnih besedil, avtorjem znanstvenih, strokovnih in poljudnih besedil, avtorjem navodil za uporabo računalniških naprav in programskih rešitev, univerzitetnim, srednješolskim in osnovnošolskim učiteljem, študentom, učencem, skratka vsem Slovencem, ki se srečujejo z informacijsko tehnologijo. Slovar je dostopen na spletu in odprt javnosti že skoraj dve leti, najprej kot prototip in zdaj že kot prva spletna izdaja slovarja. To je slovenski terminološki slovar, kjer so slovenski izrazi opremljeni z angleškimi ustreznicami in s slovarskimi razlagami. Pomagal naj bi reševati številne jezikovne probleme, s katerimi se srečujemo ob hitrem razvoju informacijske tehnologije. Oblikovno in vsebinsko se zgleduje po nekaterih terminoloških slovarjih, ki so že izšli v slovenščini v knjižni obliki, izkorišča pa številne možnosti, kijih nudi sodobna tehnologija. Naj navedemo le dve, najbolj pomembni lastnosti slovarja: odprtost za sodelovanje številnih strokovnjakov in uporabnikov pri zbiranju izrazja in javna, brezplačna dostopnost slovarja vsem, ki imajo dostop do interneta. Odprt internetni pristop omogoča povsem nove oblike slovarskega dela, pri čemer je aktivna vloga uporabnikov slovarja možnost, ki je klasična slovaristika ne pozna. Slovar je razdeljen v dva dela: 1. uporabniški del 2. uredniški del Uporabniki iščejo izraze pod naslovom Iskanje. Iščejo lahko po slovenskih ali po angleških izrazih. Za izraze, ki so v slovenščini opremljeni z razlago, se izpiše tudi razlaga. Izraz in razlaga sta opremljena z imenom avtorja in uporabniki lahko zapišejo svoje mnenje glede pravilnosti zapisanega. Če izraza v slovarju ni, ga lahko uporabniki prispevajo, seveda če poznajo in vpišejo tudi njegovo angleško ali slovensko ustreznico. Pri tem morajo vnesti svoje ime, ki se v slovarju navaja kot ime avtorja izraza. Poglavje Naključni izraz je namenjeno pregledovanju po slovarju; prikaže se naključno izbran izraz skupaj z razlago in imenom avtorja, pri čemer lahko uporabnik vpiše svoje mnenje. Seznam nenajdenih besed daje uporabniku še več možnosti za sodelovanje pri slovarju. Ta seznam je zbirka vseh izrazov, ki sojih uporabniki iskali, pa jih niso našli. Uporabnik lahko nenajdeni izraz vnese, če prispeva tudi njegovo slovensko ali angleški ustreznico. Dodajanje novega izraza je namenjeno uporabnikom, ki bi želeli dodati izraze v slovar; lahko ga tudi opremijo z razlago. Urejanje lastnih izrazov pokaže uporabniku - avtorju vse njegove izraze, ki jih lahko spreminja ali briše. Forum je namenjen najširšim razpravam o prevajanju, pomenu ali slovenskih izrazih. Razpravo lahko odpre tudi vsak uporabnik, ki se je prijavil v slovar. Uredniki imajo dostop v poseben uredniški del slovarja. Pri tem sodeluje večje število urednikov, ki so zadolženi vsak za svoje področje. Sedanja področja slovarja so naslednja: 1. informatika in informacijska tehnologija 2. internet, omrežja, komunikacije 3. podatkovne baze 4. poslovna informatika, elektronsko poslovanje 5. objektna tehnologija 6. umetno zaznavanje 7. varovanje informacijskih sistemov, 8. operacijska raziskovanja 9. metode razvoja informacijskih sistemov 10. uporabniški vmesniki 11. kakovost, izboljšanje procesa razvoja programske opreme 12. teoretično računalništvo in programiranje 13. računalniške naprave (strojna oprema) 14. sociološki vidiki in 15. kratice. Uredniki delajo neposredno v spletnem slovarju, vnašajo in popravljajo slovarske sestavke, pregledujejo in brišejo nenajdene izraze, se udeležujejo razprav o zbranih sestavkih, pregledujejo in popravljajo nove izraze. O pomembnejših vprašanjih odloča uredniški odbor slovarja. Ker je področje informatike izredno široko in s tem priprava slovarja zelo zahtevna, se bo število področij kakor tudi število sodelujočih urednikov brez dvoma še povečalo. Slovar bo izšel tudi v knjižni obliki, ki sicer ne bo omogočala ažurnosti in odprtosti, ki jo ima spletni slovar, bo pa pomemben prispevek na področju slovenskega jezika in kulture. Urejanje spletnega slovarja je za informatiko dolgoročna naloga, ki bo opravljena tem bolje, čim več ljudi bo slovar uporabljalo in čim več sodelavcev se bo pridružilo. Zato vas vabimo, da obiščete naslov http//:www.ef.uni-lj.si/termi-noloskislovar. Razvoj slovarja podpirata Statistični urad Republike Slovenije, ki sekciji omogoča delo v računalniški učilnici, in Ekonomska fakulteta Univerze v Ljubljani, ki gosti slovar na strežniku. Brez te pomoči bi bilo naše delo veliko manj uspešno. Zato se obema na tem mestu zahvaljujemo. Uredništvo slovarja Koledar prireditev CD l 3 i g S f s f C c Tt ~ TO S S ■§ m f f S ^ 8 + g- 2 x O 0 X £ 1 §? jj 2 s o §1 0 E 1 1 S S I s V. S O ”=f d s € m 5 O) + Ifl £ 1 "O <§> § I $1 f e s | II El $ S II S 5 -y ©8 ™ CO M % 3 m -g 5,8 m *§ - Pristopna izjava Želim postati član Slovenskega društva Informatika Prosim, da mi pošljete položnico za plačilo članarine SIT 5.200 (kot študentu SIT 2.400) in me sproti obveščate o aktivnostih v društvu. (ime m priimek, s tiskanimi črkami) (poklic) (domači naslov in telefon) (službeni naslov in telefon) (elektronska pošta) Datum: Podpis: Včlanite se v Slovensko društvo INFORMATIKA. Članarina SIT 5.200,- (plačljiva v dveh obrokih) vključuje tudi naročnino za revijo Uporabna informatika. Študenti imajo posebno ugodnost: plačujejo članarino SIT 2.400,- in za to prejemajo tudi revijo. Izpolnjeno naročilnico ali pristopno izjavo pošljite na naslov: Slovensko društvo INFORMATIKA, Vožarski pot 12, 1000 Ljubljana. Lahko pa izpolnite obrazec na domači strani društva http://www.drustvo-informatika.si ■ ■■ NTERNBT ■ INTERNIH' ■ INTERNET ■ INTERNET ■ INTERNET ■ INTERNET Vse člane in bralce revije obveščamo, da lahko najdete domačo stran društva na naslovu: http://www.drustvo-informatika.si Obiščite tudi spletne strani mednarodnih organizacij, v katere je včlanjeno naše društvo: IFIP: www.ifip.or.at, EC D L: www.ecdl.com, CEPIŠ: www.cepis.com Revija Uporabna informatika je od številke VI11/4 dalje vključena v mednarodno bazo INSPEC. Naročilnica Naročam(o) revijo UPORABNA INFORMATIKA Q s plačilom letne naročnine SIT 4.600 Q .......izvodov, po pogojih za podjetja SIT 13.800 za eno letno naročnino in SIT 8.900 za vsako nadaljnjo naročnino Q po pogojih za študente letno SIT 2.000 Naročnino bom(o) poravnal(i) najkasneje v roku 8 dni po prejemu računa (ime in priimek, s tiskanimi črkami) (podjetje) (davčna številka) (ulica, hišna številka) (pošta) Datum: Podpis: -------------------------------------------------------------------------------------------------------->g------ UPORABNA INFORMATIKA ISSN 1318-1882 Ustanovitelj in izdajatelj: Slovensko društvo Informatika, 1000 Ljubljana, Vožarski pot 12 Glavni in odgovorni urednik: Mirko Vintar Uredniški odbor: Vesna Bosilj Vukšič, Dušan Caf, Aljoša Domijan, Janez Grad, Milton Jenkins, Andrej Kovačič, Tomaž Mohorič, Katarina Puc, Vladislav Rajkovič, Heinrich Reinermann, Ivan Rozman, Niko Schlamberger, John Taylor, Ivan Vezočnik, Mirko Vintar Tehnična urednica: Katarina Puc Oblikovanje: Zarja Vintar, Dušan Weiss, Ada Poklač Naslovnica: Bons Tisk: Prograf Naklada: 700 izvodov Revija izhaja četrtletno. Cena posamezne številke je 3.500 SIT. Letna naročnina za podjetja SIT 13.800, za vsak nadaljnji izvod SIT 8.900. Letna naročnina za posameznika SIT 4.600, za študente SIT 2.000. Celotni Oraclov E-Business Suite. Oracle E-Business Suite Marketing <žf Spletna trgovina (vf Prodaja (žf Podpora uporabnikom sf Nabava (žf Dobavna veriga sf Finance sf Človeški viri (žf Aplikacijski strežnik <žf Podatkovni strežnik Oraclove rešitve so razvite za povezano delovanje. Aplikacije različnih proizvajalcev zahtevajo sistemsko integracijo. Sistemska integracija stane veliko več kot sama programska oprema. Razmislite o tem. ORACLE SOFTVVARE POVVERS THE INTERNET M www.oracle.si Razprave Vesna Bosilj Vukšič, Andrej Kovačič Information Technology and Enterprise Resource Planning towards Business Process Renovation Robert Srabotič Strateško načrtovanje in uvajanje celovitih informacijskih sistemov v slovenskih majhnih in srednje velikih podjetjih Mitja Cerovšek, Matej Jevšček Procesni pristop prenove in informatizacije poslovanja v skupini TPV Ksenča Bokovec, Talib Damij Pomembnost globalnega računovodskega modela v večnacionalnih uvedbah celovitih sistemov Matic Kovačič, Zvone Es Ključni dejavniki uspeha projekta celovite rešitve v teoriji in praksi - primer Elan Aleš Zajc Navision in koncept celovitih poslovnih rešitev z odprto poslovno logiko Edvard Dolenc Upravljanje oskrbovalnih verig in načrtovanje z APS