3-2 ERP sistemi

Seminarski rad Analiza implementacije ERP reenja

Alfa Univerzitet - Fakultet informacionih tehnologija Strana

3.3 UVOENJE ERP

Uvoenje softverskih reenja je generalno veoma zahtevan, dugotrajan i skup proces. U zavisvnosti od veliine i uticaja na organizaciju, ERP samo pogorava tu kompleksnost. Dakle, organizacija pre uvoenja ERP reenja ima plan u uvoenju i razume ivotni ciklus ovih reenja koji je prikazan na slici 28. Pored toga, vano je da se koristi dokazana metodologija, jer se sa velikom verovatnoom moe desiti da emo prei ogranien budet, a da se ne uvedu nameravane funkcionalnosti

Slika 28: ivotni ciklus ERP reenja[148]

Poto su ERP softverska reenja razvijena na programerskoj kui je prilagoenje instalirane u odnosu na potrebe organizacije za automatizaciju i integraciju u razliite poslovne procese. Zbog sloenosti, vreme uvoda, cene i automatizacije stotine poslovnih procesa unutar organizacije moe se shvatiti kao aplikacija, ija aktivnost zavisi od rada organizacije. Bilo kakvo nefunkcionisanje ERP reenja moe biti veoma skupo i remetiti rad organizacije, tako da smo napravili detaljan ivotni ciklus ERP implementacije, koja je opisana u vie detalja u poglavlju Strategije uvoenja. Organizacija mora da ima plan za uvoenje ERP, to je mapa koja definie trokove, obim i vreme ostvarenja. Ovo se odnosi na uvoenje razliitih metodologija koje promoviu razni provajderi ERP reenja i konsultantske firme. Adekvatnost plana zavisi od projekta, organizacije i razloga za uvoenje ERP-a. Postoje tri selekcije uvoenja [148]:

1. Uvoenje sveobuhvatnog plana integracije (engl. comprehensive ERP integration plan) je najskuplji i najdui pristup. Podrazumeva uvoenje pune funkcionalnosti ERP reenja i industrijskih specifinih modula. Uvoenje potpune funkcionalnosti ERP zahteva visok stepen reinenjeringa poslovnih procesa sa velikim promenama u poslovnim procesima i prilagoavanju ERP.

Uvoenje ERP

reenja

Implementacija

Osnovni kadarPotrebno odravanje

Osnovna analiza

Dizajn i analiza

Razvoj Testiranje Putanje u radReavanje

zaostalih problemaNovi moduli

Vee nadgradnje

Upravljanje ERP

reenjima

Stabilizacija rada

Zahte

vi z

a r

esurs

ima

Ope

racija



2. Plan uvoenje srednjeg puta (engl. middle-of-the-road ERP implementation plan) ukljuuje neke promene u glavnim ERP modulima i manji reinenjering poslovnih procesa. Nije tako skup kao sveobuhvatni plan implementacije i nije tako orijentisan kao vanila plan implementacije.

3. Vanila plan implementacije (engl. vanilla ERP implemention plan) koristi glavnu funkcionalnost ERP reenja i koristi najbolju praksu poslovnih procesa, koja je integrisana u ERP reenje. Organizacije koje prate uvoenje vanile, treba da prilagode svoje poslovne procese, ERP procesima, a ne da se prilagode reenju za svoje poslovne procese. Eliminisana je ili minimizirana potreba za reinenjeringom poslovnih procesa, smanjeni su trokovi i vreme potrebno da se uvede projekat.

ilds (2001) navodi da je jedan od razloga za probleme u IT projekatima nerazumevanje odnosa izmeu nameravanog okvira projekta, projekta resursa i vremena za zavretak projekta. Promenom jednog od odnosa takoe dovodi do promena u druga dva. Na primer, ako projekat odlae zavretak zadatka u roku, onda e poveati resurse zbog kanjenja projekta ili smanjiti obim projekta. Isti autor takoe navodi da, uprkos fundamentalnim odnosima izmeu vremena, resursa i obima oblika trougla menjamo sa dodatnim promenljivama - za upravljanje projektima (poslovni menadment, PM nadalje). ERP implementacija obuhvata skup aktivnosti koje obino ne ulaze u okvir redovnog ciklusa aktivnosti u okviru organizacije. PM se sastoji od projekata organizacije, obima projekta, rasporeda projekta, budeta projekta, reavanja problema vezanih za projekat, procene rizika, upravljanja i performansi provajdera [96]. PM u veini IT projekata nije dovoljno dobro implementiran. Uz dobar PM moe se postii da se smanji vreme i povea obim projekta, ili smanje resursi tako da se za krae vreme dostigne unapred odreen opseg (Sl. 29).

Slika 29: Uinak dobro projektovanog menadmenta

Svaki projekat implementacije ERP se sastoji od dva pod-projekata: (1) izbora ERP reenja i (2) uvoenja ERP. Dakle, imamo dva odvojena projektna tima: projektni tim za izbor reenja i ERP projektni tim za uvoenje ERP-a.

3.3.1 Strategije uvoenja

Razliite kombinacije stratekih ciljeva organizacije dovode do raznih standarda odabira strategije i ERP implementacije [22]:

Brza strategija (engl. breakneck strategy) Strategija niskog rizika (engl. low risk strategy).



Strategija budeta (engl. budged strategy) Strategija sopstvenog razvoja (engl. in-house approach strategy) Strategija zvezde (engl. star strategy) i Strategija kljua (engl. turnkey strategy).

Kod uvoenja ERP reenje najee koriena strategija je brz i mali rizik, tako da e biti detaljnije opisana u nastavku. Strategije malog rizika se koristi u uvoenju kod veoma velikih organizacija i u organizacijama gde je stepen adaptacije je visok, u drugim sluajevima, reenje koje provajderi ERP vole da predloe je brza strategija.

3.3.1.1 Brza strategija

Dananja poslovna dinamika organizacije nema vremena da uvodi ERP reenja za mnogo godina. Iskustvo je pokazalo da dugotrajna indukcija poveava rizik od neuspeha projekta uvoenja ERP reenja, poveavajui uticaj funkcionalnosti i/ili integracije sistema i smanjujui posveenost i poverenje projektnog tima u uspeh ERP implementacije. Kao rezultat toga, ERP provajderi i sistem integratori zadovoljavaju potrebe organizacija za brzim i lakim uvoenjem ERP reenja. Oni su pripremili metodologiju, na osnovu brze strategije. Ideja brze strategije je da organizacija identifikuje i uvede ERP reenje to je bre mogue inajjeftinije. Prednosti brze strategije su [22]: jednostavnost, brzina, zahteva malo planiranja i niske poetne trokove. Dok su glavni nedostaci ove strategije: veliki rizik, ogromna koliina dorade potrebnih organizacionih funkcionalnosti, problemi sa kapacitetom ERP i funkcionalni problemi.

Danas, veina kompanija u implementaciji ERP reenja koristi brzu strategiju iz sledeih razloga [22,194]: druge strategije su se pokazale manje uspene, ekonomija elektronske trgovine zahteva brza reenja problema, 80/20 pravilo, koje je korisno manjim projektima i brzom uvoenju donosi poslovne koristi bre nego druge strategijame. Provajderi ERP reenja, koji koriste ovu strategiju, je jo zovu brzo razmetanje (engl. rapid implementation). Brzo uvoenje sadri mali broj faza. Brza strategija vodeih provajdera ERP reenja i konsultantskih kua zasnovana je na njihovoj primeni metodologije, koja ukljuuje sve potrebne alate za kreiranje, predloge za modelovanje interfejsa i integracije. Tabela 23 daje spisak metodologija vodeih provajdera ERP reenja i konsultantskih kua.

Tabela 23: Spisak metodologija provajdera ERP reenja i konsultantskih kua Naziv reenja Naziv metodologije

SAP MySAP.com Accelerated SAP (ASAP) Microsoft Microsoft Dynamics Microsoft Dynamics Sure Step Konsultantska kua Ernst & Young

Total Solution Konsultantska kua Deloitte & Touche

Fast Track Konsultantska kua Gateway

Rapid Re



Metodologija koja je zajednika za sve osnovne podele u nekoliko faza (engl. Work Breakdown Structure) koji se odvijaju pre, tokom i nakon uvoenja ERP. Struktura faza se moe podeliti u tri grupe (Slika 30):

1. pred projektne aktivnosti, koji ukljuuje faze obaveze ; 2. projektne aktivnosti, koja se sastoji od faze: inicijacije, menadmenta, analize,

konfiguracije, testiranja, modifikacije, pomoi, konverzije, proizvodnje; 3. posle projektne aktivnosti, gde pripada faza poboljanja.

Slika 30: Mapa brze strategije

I. Obaveza. Pre poetka uvoenja ERP organizacija mora da sprovedei odreene aktivnosti. Prvo, potrebno je da izaberete menadera projekta i lanove projektnog tima. Pored izbora odgovarajueg projektnog tima mora da se upusti u fazu pripreme biznis plana, koji je usmeren na one ciljeve koji e doneti najvee prednosti (merljive i nemerljive koristi). Pored toga, neophodno je pripremiti radnu sobu (engl. war room) u kojoj projektni tim moe da razvija i testira verzije programa. U sluaju da organizacija nije u mogunosti da na vreme obezbedi adekvatnu radnu sobu, onda moe iznajmiti dobavljaa softverskih usluga (ASP). Potrebno je pripremiti poetni plan projekta, koji ukljuuje: plan upravljanja krizom, plan rada i organizacionu strukturu projekta. II. Poetak. Poetak implementacije poinje sa inicijalnim sastankom projektnog tima (engl. kickoff meeting). Zatim sledi osnovna obuku lanova projektnog tima. Obuka obino traje 4 do 5 dana i pokriva metode i pristupe implementacije ERP koji e se koristiti u projektu. III. Liderstvo. Ova faza obuhvata projektovanje i nadzor projekta od strane rukovodioca projekta. Rukovodilac projekta je odgovoran za projekat plana rada. Plan rada projekta sadri hronologiju svih zadataka koje treba da se urade za vreme uvoenja. Plan rada na projektu iznosi kljune zadatke, vreme, resurse i status projekta. Plan rada sadri dva nivoa: transparentan plan i detaljan



plan, koji mora da sadri sve projektne aktivnosti. Rukovodilac projekta prilikom pripreme rauna da nijedan zadatak zbog 80/20 pravila nee uzeti vie od 2 dana. IV. Analiza. Projektni tim odreuje kako da se postigne viziju i ciljeve koji su postavljeni u prethodnim fazama i kako da se pobolja poslovne procese i reavanje poslovnih problema. ovo moe da se uradi analizom praznine (engl. fit/gap analysis), koja uporeuje postojee poslovne procese, budue poslovne procese i sposobnost ERP reenja [157]. V. Konfigurisanje. Konfiguracija je proces prilagoavanja ERP reenje za nae potrebe. Svako ERP reenje sadri hiljade parametara koje mogu da se izmene. Da biste podesili parametre mogu se koristiti tri pristupa [22]: manuelni pristup, delimino automatizovani pristup i automatizovan pristup. U runom pristupu, obino ERP provajder da spisak pitanja koja se odnose na funkcionalnost organizacije. Pitanja su dizajnirana tako da su odgovori ve povezani sa parametrima konfiguracije. Delimino automatizovan pristup koristi isti pristup kao prethodni, ali rezultati ulaze u kompjuterski sistem, a zatim program automatski odreuje parametre konfiguracije. U automatizovanom pristupu projektni tima takoe moe da pomogne savetniku da odgovori na pitanja, nakon ega ERP automatski aurira postavke konfiguracije. VI. Testiranje. Testiranje obuhvata nekoliko koraka, koji bi trebalo da ukljuuje kljune korisnike. Ovi koraci su: stvoriti test sluajeve, pripremiti test podatke, utvrditi oekivane rezultate, evaluacija testiranih rezultate, eliminisanje problema i ponovno testiranje, dokumentovanje. Aktivnosti faze analize, konfiguracije i testiranja se ponavlja tako dugo da zadovolji sva postavljena oekivanja sa poetka projekta. Tada projektni tim sauva podeavanja konfiguracije i dokumentuje ih.

VII. Promene. Sa uvoenjem ERP u organizaciji mogu postojati tri vrste promena: promene u tehnologiji, promene procesa i promene u organizacionoj strukturi. Kako bi projektni tim izbegao neuspeh, mora obratiti panju na sledee oblasti: mora da proveri ko su saveznici i protivnici uvoenja ERP u organizaciji kako bi se osiguralo uee kljunih korisnika tokom uvoenja, obezbediti komunikaciju izmeu lanova proirenog projektnog tima za pripremu dokumentacije i edukovati korisnike. Komunikacija izmeu lanova tima projekta ukljuuje sastanke, izvetaje o statusu, biltene, e-mail, itd. Osnovna dokumentacija mora biti na raspolaganju od strane provajdera ERP reenja u vidu prirunika. esto, informacije su dostupne u elektronskom obliku, koji se moe prilagoavati potrebama organizacije. Korisnicima ERP je potrebno obezbediti adekvatno obrazovanje ako elimo da projekat uspe. Dobro obrazovanje zahteva kvalitetne edukativne materijale i instruktore koji su dobro pripremljeni od strane projektnog tima ili savetnike/nastavnike od strane provajdera ERP reenja. VIII. Pomo. Pomo se odnosi na aktivnosti IT odeljenja. U prvoj fazi, IT odeljenje priprema radne stanice za sve lanove projektnog tima i glavni razvojni server. U vreme uvoenja treba da: stvori uslove za razvoj, testiranje i proizvodnju verzije aplikacije, definiei prava pristupa novom sistemu, pripremi rezervne kopije, napie program za konvertovanje podataka, da trai potencijalne greke sistema, pripremi posebne izvjetaje i obrasce pomou alatke predviene od strane provajdera, itd. IT odeljenje moe biti tehniki konsultanat za PB, bezbednost, operativni sistem, itd. Ako se utvrdi da organizacija ne moe da prui odgovarajuu podrku iz IT odeljenja, onda ima smisla da se razmotri korienje softverskih usluga provajdera (ASP).



IX. Konverzija. Ovaj korak je neophodan za prenos podataka iz postojeih sistema na novi sistem PB. Konverzija podataka se sastoji od pet koraka: (1) neophodno je razmotriti koje podatke iz postojeeg sistema na novi sistem treba prebaciti; (2) podaci moraju biti oieni, jer su podaci u postojeim sistemima u viestruki to znai i netani (kao tehnoloki viak), nesistematini ili ne sadre sve potrebne atribute; (3) punjenje novog sistema podacima moe da se uradi na tri naina: automatski, preko interfejsa ili runog unosa; (4) verifikacija podataka, to znai tanost i integritet podataka; (5) na kraju, sledi sinhronizacija gde treba uivo preuzimati sve potrebne podatke u PB novog sistema. Statiki podaci, kao to su podaci o kupcima, dobavljaima, itd., organizacija moe preneti u novi PB pre poetka online povezivanja, ali to nemoe da uradi za dinamike podatke, kao to su otvoren nalog.

X. Priprema. Kljuni zadaci koje treba izvriti pre poetka rada novog sistema se odnosi na testiranje svih komponenti (veliki broj razliitih procesa) integracioni test, uenje korisnika (2 do 4 nedelje pre pocetka rada), priprema proizvodnog okruenja, konverziju podataka i uspostavljanje stalne pomoi.

XI. Poetak rada. Kada ponete da koristite novi sistem u organizaciji mora se oekivati da se bez obzira na opsene pripreme i planiranja dolazi do problema. Iznad svega, zaposlenima e trebati mnogo pomoi u danima nakon poetka rada, tako da organizacija mora imati vei broj strunjaka koji e pokuavati da ree probleme. Kada problemi nestanu, ima smisla da se uradi revizija uvoenja i na taj nain poboljaju anse za uspeh novog lansiranja. Ima smisla da se organizuje sastanak o konanom projektu i ispitati prednosti i mane projekta. XII. Poboljanja. Ukljuuje pomo nakon uvoenja i kontinuirano obrazovanje i odravanje ERP reenja. Ovde ima smisla da se razmotre prednosti i trokovi brzog uvoenja pre poetka nove brze implementacije.

3.3.1.2 Strategija malog rizika

Strategija mali rizik (engl. low risk strategy) ima veliki broj koraka. Autori Motovilla i Tompson (2009) imenuju tradicionalne strategije uvoenja ERP i koriste ih kod implementacije u velikim organizacijama. Ovde na kraju svake faze (koraka) se formira izvetaj, pregledan od strane menadmenta od kojih zavise odluke da se nastavi projekat. Fokus je na prilagoavanju programa, kao i promeni poslovnih procesa i gde se dalji razvoj novih aplikacija moe odrediti na osnovu zahteva korisnika. Vreme uvoenja je oko dve godine. Strategija malog rizika se sastoji od pojedinanih koraka koje moe da ima projekat za uvoenje ERP reenja. Ova strategija ukljuuje i proces revizije i veliki broj aktivnosti koje e biti sprovedene istovremeno. Mali rizik strategija se sastoji od sledeih faza: faza obima i posveenosti, faza analize i projektovanja, faza usvajanja i razvoja, faze uvoenja i faza delovanja [148]. Faza integracije je prikazana na slici 31.



Slika 31: Tradicionalna strategija uvoenja ERP reenja [148]

U fazi planiranja i procene vri se ocena izvodljivosti implementacije (engl. feasibility study). Rezultat ove faze je da se definiu planirani trokovi i prihodi u duem vremenskom periodu. Jedan od prvih koraka koji se definie je obim uvoenja neophodnih resursa i vremenski okvir. Pored toga, u ovoj fazi, identifikuju se karakteristike ERP implementacije. Priprema potrebna dugorona vizija novog sistema i plan implementacije kratkoronih ciljeva i prua podrka za viziju administracije i plana za implementaciju. Neophodno je da se definiu strukture tima uvoenja, uloge spoljnih konsultanata (vreme i kotanje) i uloge osoblja, ukljuujui i konsultanata sa poznavanjem poslovnih procesa i oblika izvetaja. U ovoj fazi, potrebno je proceniti i utvrditi granice i obim analize praznina, fizikog obima uvoenja (broj pregrada, broj korisnika, itd.), obim reinenjeringa poslovnih procesa, tehnikog obimu (broj podeavanja), obima sredstava i obim uvoenja (broj modula). Faza analize i dizajna. Pored analize korisnikih zahteva ERP projektni tim mora prvo da odlui o provajderu ERP reenja i konsultanata. Identifikovati izmene postojeih poslovnih procesa i procesa u integrisanim softverom (engl. fit/gap analysis) i da razvije dugoroni plan ili promenite poslovne procese organizacije ili da se prilagode ERP reenje koje e podrati postojee procese. Na osnovu analize praznina mora da pripremi tim dizajnera koji ukljuuje upravljanje promenama plana liste ugraenih procesa i izvetaja koji treba da se podesi u ERP. Ostale aktivnosti ukljuuju izradu plana konverzije konverzije podataka i sistema obuke. Da bi bio uspean, projektni tim treba da razvije detaljne strategije za upravljanje promenama i implementacije plana za prenos novog sistema rada. Faza usvajanja i razvoja. Organizacija mora da kupi licencu ERP reenja i pripremi proizvodnu verziju sistema. Proizvodna instanca mora biti prilagoena (konfigurisana). Pored toga, ona takoe mora biti spremna da podri hardver, mree, bezbednosni softver, PB i stvarne podatke o proizvodnji. Praznine u analizi je neophodno u ovoj fazi da se uklone, obuhvatajui adaptaciju (kostumizaciju) ugraenih softverskih pravila, dodajui polja tabele PB, pripreme obrasce i izvetaje, itd. Iako se tehniki tim bavi realizacijom, tim za upravljanje promenama se bavi korisnicima (uvesti promene u poslovnim procesima). Osnovati tim, koji se bavi radom na



konverziji podataka na osnovu podataka sa starog na novi sistem IS. Na kraju, potrebno je konfigurisati ERP zatitu i takoe uvesti proveru prisustva i ovlaenja za pristup reenjima korekcije koje su preporuene u fazi projektovanja. U fazi uvoenja fokus je na instalaciji i predaji na korienje ERP sistema korisnicima (engl. end users) ime poinje uivo praenje i funkcionisanje sistema. Proizvodna instanca je rezultat razvoja. Greke u proizvodnom procesu su sadrane u podrci (engl. help desk). Sve promene napravljene u razvojnom stepenu, ponovo se testiraju i potom prebacuju u proizvodnu instancu. Pristup uvoenja ERP je osnovna delatnost ovog koraka. Vana aktivnost ove faze je edukacija i obuka korisnika. Anderegg sa koautorima (2000) istie da su prednosti ove strategije: tanije predvianje rezultata, nisko korienje kapaciteta, bolja adaptacija na budet, maksimalno iskorienje bez velikih iznenaenja. On takoe ukljuuje i neke nedostatke: dugaak uvod, konceptualno teko za uenje, zahteva podrku menadmenta, zahteva namenska sredstava i poveane trokove.

3.3.2 Metodologija uvoenje ERP reenja

Metodologija definie standardni pristup odreenom poslovnom procesu ili proceduri [194]. Metodologija implementacije ERP obuhvata: metod struktuiranja projekta (WBS), opis zadatka (engl. task description) i primere delovanja (engl. deliverable examples). Pored toga, danas su obino na raspolaganju Onlajn metodologije, koje olakavaju rad projektnim timovima. Metodologija mora da sadri glavne prekretnice u uvoenju ERP reenja i njihove ishode. Rezultati moraju da budu odobreni pre nego to oni mogu prei na sledeu fazu implementacije ERP. Konceptualni model brzog uvoenja ima tri faze, i to: aktivnosti pre projekta, projektne aktivnosti i aktivnosti nakon zavretka projekta. Svaki od faza je podeljena u nekoliko aktivnosti, a druga se deli u nekoliko zadataka. Sve aktivnosti i individualni zadaci su definisani u WBS strukturi i slui kao mapa radne grupe u obavljanju pojedinanih zadataka omoguivi im da pogledaju veze izmeu pojedinanih zadataka. Opta struktura WBS ERP reenja za pojedinane organizacije prilagoava se specifinostima projekta i obino dokumentuje u planu projekta. Svaka faza, aktivnost i zadatak u opisu metodologije treba da se uradi da bi preli na sledei zadatak ili aktivnost. Detaljne informacije su dostupne za nivo zadatka, gde metodologija prua informacije o ciljevima zadatka, kljune ulaze i izlaze, podrazumevane procedure za obavljanje poslova kako bi izbegli zamke uvoenja. Dakle, metodologija uvoenja ERP obezbeuje nekoliko prednosti, kao to su [194]: bolja konzistentnost izmeu lanova projektnog tima, kako svi lanovi obavljaju isti posao i rade po istom postupku, tako da se mogu oekivati isti rezultati, detaljni nivo zahteva, to je lake da se definie i kvalitet rada i status zadatka.

Nakon inicijalnog sastanka (engl. kick off meeting), projektni tim se sastaje i ui da primenjuje metodologiju uvoenja izabranih ERP reenja. Svaki lan tima treba da razume pristup ERP implementacije i kako e se aplikacija biti ukljuena u ukupan projekat. Zbog specifinosti pojedinih ERP reenja danas veina provajdera ERP reenja i konsultantskih firmi nude svoje ERP



metodologije implementacije (npr. ASAP metodologija za SAP ERP). Pored toga, nudi veinu usluga i metoda, kao to su, na primer procesni modeli prilagoeni za izabrano ERP reenj; unapred prilagoena verzija ERP organizacije tzv. vertikalna reenja; obrazovanje projektnog tima; dodatne aplikacije i module ili ERP reenja provajdera i njenih partnera koji prevazilaze osnovne funkcionalnosti ERP reenja, kao to su modul e-trgovine, korisnikih prirunika i procedura; online pomo provajdera ERP reenja; prirunike za obrazovanje potroaa; podrku prilagoavanja pomou unapred prilagoene verzije i dizajn knjiga (engl. design book) koji opisuju postavke parametara i njihov uticaj na funkcionisanje ERP i drugih parametara; automatizovane interfejse konverzije podataka i unapred pripremljene interfejse (engl. Application Programming Interfaces, v nadaljevanju API), itd.

3.3.3 Pristupi uvoenju ERP

ERP implementacija je proces instaliranja ERP sistema. U poetnom periodu primene ERP reenja, organizacije koriste tradicionalni pristup uvoenja, koji je sastavljen od pet uzastopnih faza: obim i planiranje, vizija, razvoja, implementacija i rasporeivanje [194]. Nedostatak ovog pristupa je niz faza gde sledea moe da pone kada je prethodna faza je zavrena i verifikovana. Dakle, za implementaciju ERP je potrebno nekoliko godina, rezultati su vidljivi samo na kraju. Zbog slabosti tradicionalnog pristupa uvoenja ERP reenja danas se koriste sledei pristupi [22,157,177]: pristup velikog praska (engl. big bang), fazni pristup (engl. phased approach), paralelni pristup (engl. parallel approach), procesno orijentisan pristup (engl. proces line strategy) i hibridni pristup (engl. hybrid strategy). Pristup velikog praska pretpostavlja da znamo datum kada kompletiramo rad u okviru postojeeg IS i pone da obavlja zadatke realizuje ERP reenja. Ako elite da je ovaj pristup uspean, potrebno je da paljivo planirate uvoenje ERP i dobro testirate ERP reenje pre datuma putanja u rad. Glavna prednost pristupa velikog praska je da nije potrebno da se pripremi interfejse izmeu postojeih IS i uvedenog ERP reenja [22]. Ostale prednosti ovog pristupa su 157]: nii trokovi instalacije, manji rizik, mogunost da se ceo tim projekta posveti projektu zbog ega su vie fokusirani i koordinirani tokom implementacije projekta i uvoenje novog sistema krae traje. Nedostaci ovog pristupa su: vreme i trokovi pripreme, nedostatak kritikih resursa i nedostatak profesionalnog iskustva u implementaciji ERP [22]. O'Leari (2000) navodi da je posle neuspene ERP implementacije nemogue da se vrati na stari IS. Rizici zbog nedostatka sredstava se mogu smanjiti metodom mali-veliki prasak (engl. mini big bang), gde je proces uvoenja ERP podeljen na dva ili vie delova. Svaki deo se sastoji od nekoliko meusobno povezanih modula kao to su finansije, distribucija i proizvodnja, koje su uvedene na isti nain kao i sa metodom velikog praska. Pored malog-velikog praska, tu je i pristup mega veliki prasak (engl. mega big bang) i multi-veliki prasak (The Big Bang). Mega veliki prasak se koristi kada organizacija ima vie mesta i sva mesta istovremeno uvode ERP reenja na uivo. Mega veliki prasak se koristi kada su podruja implementacije na razliitim geografskim podrujima. Fazni pristup omoguava sekvencijalno uvoenje ERP modula, tako da prvo moramo uvesti jedan modul, a kada je uveden, uvodimo sledei modul. Proces se ponavlja sve dok se ne instaliraju svi



izabrani moduli ERP reenja. Obino, prvi uveden je finansijski modul. Kao to je naveo O'Leari (2000), prednosti ovog pristupa je manji rizik, jer se istovremeno uvodi jedan modul, projektni tim sa svakim uvoenjem modula u dobija vie znanja i iskustva za uvoenjem ostalih. Glavni nedostatak ovog pristupa je linearnost fazne realizacije tako da je potrebno pripremiti interfejse izmeu starog IS i implementiranih ERP modula to poveava trokove i vreme uvoenja. Pored toga, ovo iziskuje i vie opreme obzirom da paralelno rade dva sistema (postojei IS i ERP). Paralelni pristup se koristi od strane organizacija kojima je brzina izvoenja operacije od najveeg znaaja (npr. banke i farmaceutske kompanije). Ovaj pristup je znaajan u tome to postojei IS i uvedeno ERP reenje, koegzistiraju nekoliko meseci. Prednost ovog pristupa je mogunost brzog oporavka postojeeg IS posle neuspeha ERP reenja. Pored toga, moemo proveriti tanost podataka izmeu starog i novog sistema. Kao rezultat toga, postoji potreba za vie resursa (hardvera, softvera, ljudi, itd). Pored toga, podaci se dupliraju, kao zaposleni moraju uneti podatke dva puta za oba sistema, to stvara dodatne trokove. Dodatni trokovi se mogu izbei sa paralelnom verzijom pristupa zvanom papirni paralelni pristup (engl. paper parallel approach), gde umesto vie operativnih sistema (stari i novi) sve transakcije se tampaju.

3.3.4 Kritini faktori uspeha u ERP reenja

Poto organizacije obino ne znaju da je neophodno da se uvoenje zavri u kratkim rokovima, projekat uvoenja ERP reenja se smatra sloenim i veoma rizinim. Rizik se ogleda u vremenu, obimu i ceni lansiranja projekta. U veini sluajeva, to je najvei projekat IS, koji je ikad uveden u organizaciji [20]. Istraivanje organizacije Standi Grupe je pokazalo da 90% od ERP implementacija nisu uvedene u predvienom roku ili procenjenog budeta [226]. Iz tog razloga, mnogi autori, poput Adur et al. (2002), i Akkermans Helden (2002), Bancroft et al. (2001), Bradford i Florin (2003), Estaves et al. (2002), Jarrar et al. (2000), Khan (2002), Mabert (2003), Sternad (2005) i drugi istrauju faktore koji utiu na uspeno uvoenje ERP reenja. Oni su doli do zakljuka da se mora organizaciono pripremiti uslovi pod kojima se izabrano ERP reenje realizuju u okviru predvienog vremena i procenjenih trokova. To znai da organizacije moraju da budu svesne ta su kritini faktori ERP implementacije (engl. Critical Success Factors, nadalje CDU ; [207]). Najkritiniji faktori u fazi implementacije, istaknuti od strane autora Nah et al. (2001), Somers i Nelson (2004) i Sternad i Bobek (2004, 2005, 2006a, 2006b, 2008) su: integracija i podrka za upravljanje, jasni ciljevi, strategija i obim ERP implementacije, organizaciji projektnog tima i svojim nadlenostima, obuka i edukacija korisnika ERP reenja, reinenjering poslovnih procesa, upravljanje promenama, komunikacija u okviru projektnog tima i ostatka organizacije i ukljuivanje korisnika u ERP implementacije, prenos podataka sa starog ERP reenja, ukljuujui spoljne konsultante, primena principa upravljanja projektima, izbor tehnologije arhitekture, minimalno prilagoavanje specifinostima ERP organizacija, itd. Tabela 24 rezimira pomenute faktore navedenih autora sa opisom u Aneksu 5.



Svi faktori imaju isti znaaj u rasporedu i korienju, tavie, nisu jednako vani u svim fazama primene i upotrebe, to takoe varira u zavisnosti od veliine preduzea i uvoenja metodologije, kao to je navedeno u istraivanju Nah s soavtorji (2001), Estaves i Pastor (2001) i Sternad sa koautorima (Sternad et al., 2007, Sternad i Bobek, 2008, Sternad et al. 2009 Sternad 2005).

Tabela 24: Objavljeni radovi o kritinim faktorima uspeha Faktori uspeha (KFU) Autori

Ukljuivanje i podrka Upravnog odbora

Aduri et al. 2002, Akkermans i Helden 2002, Al-Mashari et al. 2003, Al-Sehali 2000, Bradford i Florin 2003, Estaves et al. 2002, Gattiker i CFPIM 2002, Jarrar et al. 2000, Mabert et al. 2003, Nah et al. 2001, Ngai et al. 2007, Parr i Shanks 2000, Skok i Legge 2002, Somers i Nelson 2004, Sternad 2005, Stratman 2002, Umble et al. 2002, Welti 1999, Zhang et al. 2002.

Jasni ciljevi, strategija i obim ERP implementacije

Aduri et al. 2002, Akkermans i Helden 2002, Al-Mashari et al. 2003, Al-Sehali 2000, Bradford i Florin 2003, Estaves et al. 2002, Finney i Corbett 2007, Gargeya i Brady 2005, Holland i Light 1999, Khan 200.; Mabert 2003, Ngai et al. 2007, Parr i Shanks 2000, Reif 2001, Somers i Nelson 2003, Sternad 2005, Umble et al. 2002, Welti 1999.

Organizacija projektnog tima i njegove nadlenosti

Aduri et al. 2002, Akkermans i Helden 2002, Bancroft et al. 2001, Estaves et al. 2002, Holland i Light 1999, Jarrar et al. 2000, Khan 2002, Mabert 2003, Parr i Shanks 2000, Reif 2001, Skok i Legge 2002, Somers i Nelson 2003, Umble et al. 2002, Wang et al. 2007, Welti 1999.

Obuka i edukacija korisnika ERP reenja

Aduri et al. 2002, Akkermans i Helden 2002, Al-Mashari et al. 2003, Al-Sehali 2000, Bancroft et al. 2001, Bradford i Florin 2003, Estaves et al. 2002, Jarrar et al. 2000, Mabert 2003, Markus i Tanis 2000, Markus et al. 2003, Motiwalla i Thompson 2009, Olsen 2004, Reif 2001, Shanks et al. 2003, Shelly et al. 2003, Skok i Legge 2002, Somers i Nelson 2003, Sternad 2005, Umble et al. 2002, Zhang et al. 2002, Wheatley 2000.

Reinenjering poslovnih procesa

Akkermans i Helden 2002, Al-Mashari et al. 2003; Bancroft et al. 2001; Bradford in Florin 2003; Davenport 1999, Estaves et al. 2002; Gargeya i Brady 2005, Gattiker i CFPIM 2002; Jarrar et al. 2000; OLeary 2000, Olsen 2004, Markus i Tanis 2000, Markus et al. 2003, Ngai et al. 2007, Skok i Legge 2002, Somers i Nelson 2003, Sternad 2005, Welti 1999, Zhang et al. 2002.

Upravljanje promenama Akkermans i Helden 2002, Al-Mashari et al. 2003, Al-Sehali 2000, Bancroft et al. 2001, Estaves et al. 2002, Jarrar et al. 2000, Olson 2004, Parr i Shanks 2000, Skok i Legge 2002, Somers i Nelson 2003, Sternad 2005, Stratman 2002, Umble et al. 2002.

Efektivna komunikacija Akkermans i Helden 2002, Al-Mashari et al. 2003, Al-Sehali 2000, Bancroft et al. 2001, Estaves et al. 2002, Holland i Light 1999, Khan 2002, Mabert 2003, Somers in Nelson 2003, Sternad 2005.

Angaovanje korisnika Al-Sehali 2000, Estaves et al. 2002, Gattiker i CFPIM 2002, Holland i Light 1999, Khan 2002, Skok i Legge 2002, Somers i Nelson 2003, Sternad 2005, Wang et al. 2007, Welti 1999, Zhang et al. 2002.

Prenos podataka iz starog ERP

Akkermans i Helden 2002, Al-Sehali 2000, Gattiker i CFPIM 2002, Ngai et al. 2007, Reif 2001, Somers i Nelson 2003, Sternad 2005, Umble et al. 2002, Welti 1999, Zhang et al. 2002.

Angaovanje spoljnih konsultanata

Akkermans i Helden 2002, Al-Mashari et al. 2003, Al-Sehali 2000, Estaves et al. 2002, Khan 2002, Skok i Legge 2002, Somers i Nelson 2003, Sternad 2005, Wang et al. 2007, Welti 1999.

Korienje principa upravljanja

Akkermans i Helden 2002, Al-Mashari et al. 2003, Al-Sehali 2000, Reif 2001, Somers in Nelson 2003, Sternad 2005, Stratman 2002, Umble et al. 2002, Welti 1999, Zhang et al. 2002.

Aktivna uloga projekta sponzora

Akkermans i Helden 2002, Bancroft et al. 2001, Estaves et al. 2002, Finney i Corbett 2007, Khan 2002, Ngai et al. 2007, Parr i Shanks 2000; Skok i Legge 2002, Somers i Nelson 2003, Sternad 2005.

Izbor odgovarajueg ERP reenja

Akkermans i Helden 2002, Al-Sehali 2000, Estaves et al. 2002, Gattiker i CFPIM 2002, Jarrar et al. 2000, Ngai et al. 2007, Somers i Nelson 2003; Sternad 2005, Zhang et al. 2002.

Minimalno prilagoavanje ERP specifinostima organizacije

Akkermans i Helden 2002, Al-Sehali 2000, Estaves et al. 2002, Finney i Corbett 2007, Khan 2002, Mabert 2003, Nah et al. 2001, Parr i Shanks 2000, Somers i Nelson 2003, Sternad 2005.

3-2 ERP sistemi

Documents

Transcript of 3-2 ERP sistemi