erp ciklus

8/10/2019 ERP Ciklus

1/36

1

Sveuilite u ZagrebuFakultet Elektrotehnike i raunarstva

ivotni ciklus ERP sustava

Lidija Pape

Zagreb, srpanj 2007.


2/36

2

Sadraj

1. Uvod ....................................................................................................................................... 3

2. ERP sustav .............................................................................................................................. 42.1 Vodei dobavljai ERP paketa ......................................................................................... 52.2 Podruja sadrana u ERP sustavu .................................................................................... 62.3 Nedostaci .......................................................................................................................... 7

2.4 Prednosti ........................................................................................................................... 8

2.5 Zato se korisnici odluuju na ERP sustav..................................................................... 103. ivotni ciklus ERP sustava.................................................................................................. 12

3.1 ImplementacijaI. faza ................................................................................................. 143.1.1 Analiza (Project planning)....................................................................................... 14

3.1.2 Specifikacija zahtjeva (Business blueprint) ............................................................ 15

3.1.3 Implementacija i testiranje (Realization) ................................................................ 15

3.1.4 Kontrola kvalitete i obuka (Final preparation) ........................................................ 15

3.1.5 Going live i podrka................................................................................................ 163.2 ImplementacijaII. faza i iza ........................................................................................ 163.3 Poveanje vrijednosti (Extending Value) ....................................................................... 163.4 Odravanje vrijednosti (Maintaining Value).................................................................. 173.5 Opadanje vrijednosti (Declining Value) ........................................................................ 17

4. Primjer ERP sustava: SAP R/3 okruenje ............................................................................ 184.1 Metodologija implementacije - ASAP ........................................................................... 18

4.2 Okruenje SAP ERP sustava .......................................................................................... 194.3 lanovi tima ................................................................................................................... 21

4.4 Alternativne kombinacije konzultant-korisnik-programer ............................................. 234.5 Nivoi i vrste prilagodbe/razvoja u SAP R/3 okruenju................................................. 234.6 Razvojni alati u SAP R/3 okruenju............................................................................. 254.7 Model razvoja i metodologija ........................................................................................ 29

5. Smjernice razvoja ERP sustava u budunosti...................................................................... 316. Zakljuak.............................................................................................................................. 337. Literatura .............................................................................................................................. 34

8. Dodatak ................................................................................................................................ 35

8.1 Primjer funkcionalne dokumentacije ............................................................................. 35

8.2 Primjer programa ............................................................................................................ 35

8.3 Tehnika dokumentacija................................................................................................. 36


3/36

3

1. Uvod

ERP sustavi su cjeloviti sustavi za upravljane poslovanjem. U ovom seminaru e prvo bitiobjanjeno to je ERP sustav, koje su njegove karakteristike, nedostaci i prednosti.

U nastavku je prkazan ivotni ciklus ERP sustava.Najvei razvoj i definicija projekta je samaimplementacija pa je taj dio malo opirnije objanjen. Nakon implementacije dolazidugotrajan proces odravanja koji moe sadravati manje projekte unutar sustavakao zasebnecjeline.

SAP R/3 sustav je opisan detaljnije kako bi se dobio bolji uvid u jedan od ERP sustava. Samo

su ukratko opisani osnovni principi rada sustava kako bi se mogao dobiti uvid u osnovne

procese pri razvoju i lanovima tima koji sudjeluju pri tome.

U dodatku su navedeni primjeri dokumentacije, samoga koda i izgleda suelja ERP sustava.


4/36

4

2. ERP sustav

ERP (Enterprise Resource Planning)sustav je integrirani informacijski sustav za podrkuposlovanju koji se koristi u razliitim dijelovima organizacije nekog poduzea.

Inicijalno, izraz ERP je potekao iz okoline proizvodnje. Dananje koritenje izraza ERPsustav ima puno vei opseg. ERP sustavi pokuavaju pokriti sve osnovne funkcijeorganizacijepotujui njeno poslovanje.

Razvoj takvih vrsta rjeenja je poeo 80-ih godina kada je zamiljen kao klijentski pristup sjednom bazom. Dananji rjeenja se sve vie orijentirana, djelomino ili u cijelosti, kaoInternet rjeenja. Pojam ERP paket prvenstveno podrazumijeva prilagodbu i uporabugotovogsoftverskog paketa, a tek onda programsku podrku napisanu po mjeri odreenogkorisnika. Zamiljeni su tako da se mogu prilagoditi potrebama konkretne organizacije i

postojeem softveru ili informacijskom sustavu te organizacije.

Za ERP paket vrijedi sljedee: sastoji se od vie podsustava(modula) i velikog broja predefiniranih opcija, ovisno o potrebama poduzea instaliraju se pojedini moduli, podrava stotine razliitih poslovnih funkcija i procesa rada, realiziran je s vie milijuna linija programskog koda, u razvoj je utroeno vie stotina ili tisua ovjek-godina visoko kvalificiranog rada. vee se na jedinstvenu bazupodataka

Prilagodba ERP modula konkretnom korisniku obavlja se posebnim alatima i posebnim ili

standardnim programskim jezicima. Posao prilagodbe i uvoenja u primjenu zahtijevaposebna znanja i dugo vrijeme implementacije.

Praksa i svjetske reference pokazuju da uspjena instalacija i primjenu ERP paketa ovisi ovelikom broju faktora. Neke od njih su prikazane su u tablici 1 (rezultati ankete u asopisuComputerwoche)[15]u kojoj se navode najei razlozi neupjeha ili kanjenja.

80 % Vie panje optimizaciji procesa65 % Implementacija sukladna praenju ciljeva organizacije60 % Vie panjekooperacije poslovnih segmenata

55 % Uvoenje voditelja projekta iz redova relevantnih odjela50 % Istovremena implementacija MIS-a45 % Intenzivnija edukacija

35 % Jae ukljuenje predstavnika djelatnika35 % Hrabriji pristup promjenama

30 % Bolji dokaz ekonominosti20 % Izbjegavanje big-bang implementacije

Tablica 1. to bi menadment promijenio pri ponovnom uvoenju ERP sustava?

Kljuno svojstvo svakog ERPpaketaje koritenje jedinstvene bazekako bi pohranio podatkeiz raznih modula. Takoer jedna od glavnih karakteristika ERP sustava je neovisan izbor baze

podataka o samome ERP sustavu. Veina ERP paketa podrava vie proizvoaa baze


5/36

5

podataka koji ne ovisi o samom ERP paketu (npr. Oracle, MS SQL Server, DB2). Princip

jedinstvene baze podataka omoguava dodatne prednosti kao to su standardizacija sustava,manje odravanja (jedan sustav umjesto najmanje dva), lake izvjetavanjei vee mogunostiizvjetavanja (svi se podaci nalaze u jednoj bazi).

2.1 Vodei dobavljai ERP paketa

ERP paketi su se tijekom godina razvijali, kupovali gotova rjeenjai ugradili ih u postojea,radili transformacije postojeih rjeenja i proirivali funkcionalisti i/ili broj modula. Svjetski

poznatih rjeenja ima 20-ak, a u svakoj od zemalja postoji mnotvo lokalnihERP rjeenja.

Lokalna ERP rjeenja mogu biti bolja nego velika ERP rjeenja [1], ali su primjenjivauglavnom samo u granicama drave jer ih veina ima ugraene specifinosti vezane za

pojedinu dravui granu industrije ili djelatnosti za koje je rjeenje inicijalnonapisano. Takvarjeenja zadovoljavanju organizacijekoja imaju jednostavne procese ali stvar se moe uvelikezakomplicirati ako organizacija ima sloene procese ili se proiri izvan granica.

U takvim sluajevima se prelazi na openitijeERP pakete koji mogu obuhvati cjelokupnoposlovanje organizacije.

Prema Gartneru najveih 5 ERP dobavljaaprikazana su tablici 2. Moe se vidjeti da svaki oddobavljaaima po vie rjeenja i nadogradnji na postojee osnovno rjeenje.

DOBAVLJA ERP SUSTAVDOBIT

(MILION

$)

UDIO

TRITA

(%)SAP SAP R/3

mySAP

4726 28,70

Oracle Applications JD EdwardsEnterpriseOne & JD

Edwards World

Oracle e-Business Suite

PeopleSoft

1674 10,20

The Sage Group Accpac

Sage MAS 500

1221 7,40

Microsoft

Microsoft Dynamics 616 3,70SSA GlobalTechnologies[1]

BPCS

ERP LN

Visual Enterprise

464 2,80

Tablica 2.Trino stanje 2005 prema Gartner Dataquest


6/36

6

2.2Podruja sadrana u ERP sustavu

Podruja u ERP sustavu su raznolika. Svaki od ERP sustava ima specifine naine prilagodbei voenja procesa, ali su veinom obuhvaeni glavni procesi poslovanja i iznimke. U nastavkusu prikazana podruja koja se mogu i ne moraju nalaziti u ERP paketu. Osnovna podrujasuFinancijsko raunovodstvo i Upravljako raunovodstvo koje je osnova svake organizacije.Ovisno o potrebama organizacije implementiraju se i ostalapodruja.

U SAP ERP okruenju svako od podruja se naziva modul. S jedne strane, svaki od modula semoe i ne mora implementirati. S druge strane moduli su meusobno ovisni pa je potrebnoznati meusobne ovisnosti modula kako bi eljeni modul mogao biti implementiran. Stoga semoe dogoditi dase moraju implementirati neki dijelovi pojedinih modula koji su preduvjetza eljeni modul.

Podruja(moduli) koja mogu obuhvaati ERP paketi su: Financijsko raunovodstvo

o Upravljanje glavnom knjigom.o Bilanca i Raun dobiti i gubitka (financijski izvjetaji).o Analitika kupaca.o Analitika dobavljaa.o Raunovodstvo osnovnih sredstava.o Raunovodstvo zaliha.o Porezno raunovodstvo

Upravljako raunovodstvo (Kontroling)o Raunovodstvo trokovnih centara.

o Raunovodstvo profitnih centara.o Raunovodstvo internih naloga.o Raunovodstvo profitabilnosti.

Prodaja i distribucijao Upravljanje nalozima za prodaju.o Upravljanje ugovorima.o Fakturiranje.

Nabava, skladitenje i logistikao Zahtjevnice.o Obrada narudbenica.o Evidencija primki materijala.o Ovjera faktura (likvidacija).o Upravljanje ugovorima.o Upravljanje zalihama i skladitem, ukljuujui inventuru i fiziki promet robe.

Upravljanje ljudskim kapitalomo Kadrovska evidencija.o Obraun plaa.

Proizvodnjao Planiranje proizvodnje.o Izvrenje proizvodnje.


7/36

7

o Proizvodnja po narudbi.o Procesna proizvodnja.

Upravljanje kvalitetomo Ispitivanje kvalitete.

Izvjetajio Financijsko i upravljako izvjetavanje.o Financijsko planiranje i budetiranje.o Upravljanje profitabilnou.o Upravljanje reijskim trokovima.o Analitika nabave.o Analitika upravljanja zalihama i skladitem.o Prodajna analitika.

2.3 Nedostaci

Nakon nabavke i prilagodbe ERP paketa, a najkasnije za 3 godine poinje pritisakdobavljaada se kupi nova verzija. Pritisak se pojaava prestankompodrka za kupljenuverziju[16].

Imajui u vidu da inicijalno ulaganje bez predstojee prilagodbe predstavlja priblinotreinu ukupnih trokova, trokovi uvoenja ERP paketa mogu u poetku izgledati nii uodnosu na trokove izgradnje po mjeri korisnika.

ERP paketi su veliki paketi unaprijed predefiniranih rjeenja i mogunosti. To im je velika

prednost, ali istovremeno i nedostatak jer[1]: se ugradnja i prilagodba programske podrke obavlja koritenjem nestandardnih

jezika etvrte generacije i specijalnih rutina za upravljanje transakcijama. Sustavisu projektirani kao veliki skup unaprijed odreenih funkcija tako da korisnik zakojeg ne postoji odgovarajue rjeenje mora svoju organizacijsku strukturu i nain

poslovanja prilagoditi sustavu. U suprotnom, administriranje nije mogue ili jedodatni razvoj toliko skup (vremenski, brojem konzultanata) da je neisplativ.

Takoer, gornjim nainom moe doi do razvijanja svog ERP rjeenja unutarERP rjeenja.

zbog velikog broja tablica i predefiniranih funkcija i programa programski kod nemoe biti optimiziran u odnosu na to kada se radi rjeenje po mjeri korisnika.

administriranje sustava podrazumijeva poznavanje velikog broja parametara i

postupaka. Objanjenje parametara i postupaka je opisano u ogromnim koliinamai vrstama dokumentacije. Pronalaenje eljene strukture podataka i eljenefunkcije je oteano uslijed velikog broja predefiniranih podatkovnih tablica i

programskih funkcija. Zbog gornjih razloga je prilagodba i ugradnja dugotrajan i

sloen posao.

Baza podataka ERP sustava je velika i svakodnevno ju koristi veliki broj korisnika. Da bi se

izbjeglo dodatno optereenje i usporavanje rada pri unosu podataka koriste se razliite metodeizvjetavanja.Najee opcijesu[1]:

Programi za izvjetaje imaju nii prioritet od transakcija. Takav je, na primjer,

SNAPpack proizvod tvrtke Information Builders, New York, za dobivanjeizvjetaja iz vodeih ERP paketa (SAP, J.D. Edwards i PeopleSoft).


8/36

8

Baza podataka ERP sustava se kopira na drugi medij pa se izvjea rade iz kopijepodataka. Na primjer, EMC Corp., Massachussets, nudi posebno sklopovsko i

programsko rjeenje Time Finder, koje kreira duplikat baze podataka na posebnomposluitelju koji osim za generiranje izvjea slui i kao sigurnosna kopija bazepodataka.

Podaci se iz baze podataka ERP sustava prepisuju u posebnu, razliitostrukturiranu bazu podataka. Ovo je najei oblik skladitenja podataka (Data

Warehousing), za koje se obino koristi i posebna strojna oprema. Kombinacijaprethodnih naina, pri emu se dio izvjetaja radi dodatnim programima iz bazepodataka ERP, a dio iz posebnog sustava u koji se prepisuju podaci iz baze

podataka ERP sustava. Kao primjer moe posluiti Crystal Decisions, tvrtkeSeagate Software, koji generira izvjea iz ERP baze podataka i Data Warehousingsustava.

2.4 Prednosti

Tijekom godina ERP paketi su se razvijali u skladu s potrebama organizacija za koje jeERP paket i napravljen. Kako je rastao broj organizacija koje su koristile rjeenje uvidjelisu se radni tokovi poslovnih procesa koji su morali zadovoljiti raznolike djelatnosti

organizacija. Tako je pokriven velik broj podruja poslovanja. Radi toga to su mnogapodruja poslovanja pokrivena za razne djelatnosti podran je i velik broj poslovnihfunkcija, odnosno radnih procesa (vie od tisuu). Kako svaka organizacija ima definiraneindividualne procese omoguen je podrka velikog broja varijacija naina izvoenja posla.

Postoji vie naina na koji se moguimplementirati ERP paketi. Jedan pristup je big-bang kojim se implementiraju svi potrebni moduli

odjednom. Taj pristup je jako riskantan i veoma dugotrajan. Organizacija

odjednom mora prilagoditi sve svoje poslovne procese bez obzira na prioritet

samih izmjena. Takoer je veoma zahtjevna jer zahtjeva dobru koordinaciju i velikbroj konzultanata. Takoer, mora se organizirati i edukacija u isto vrijeme za velikbroj zaposlenika koji poinju istovremeno raditi na novome sustavu.

Poto je implementacijski postupak ERP paketa dugotrajan, skup i zahtjeva mnogoresursa organizacije, obino se implementacija odvija u vie faza. Kakoorganizacija raste i upoznaje mogunosti ERP rjeenja poinju zahtjevi zanadogradnjom i implementacijom dodatnih modula. Prednost ERP paketa je da je

to mogue uiniti naknado, u malim koracima, ili kao dio projekta koji jenadogradnja na postojei sustav.

Instalacija ERP paketa izvodi se koritenjem brzih implementacijskih i predefiniranihtehnika. Postoje predefinirani obrasci kojima dobavljai ERP paketa ele pomoi priimplementaciji njihovog paketa.

Velika prednost ERP paketa je: omoguena integracija ERP paketa sa aplikacijama drugih dobavljaa ime se tite

i maksimalno koriste prijanje IT investicije.Izmeu ostalog sadrepredefiniranasuelja zakomunikaciju sa drugim aplikacijama.

zasnovani su na modernim tehnologijama koji olakavaju komunikaciju sa drugimsustavima


9/36

9

Karakteristika svakog ERP paketa je da je podloga jedinstvena baza podataka. Poto sepodaci nalaze u jednom sustavu jednostavnije je, bre i tonije raditi s praviminformacijama u stvarnom vremenu. Prednosti takvoga rada je da je izvjetavanje tono

jer su podaci realni. Isto tako sami poslovni procesi se mogu obavljati kontinuirano bez

koritenjasinkronizacije i dodatnih uparivanja s podacima iz drugih aplikacija i baza.

Pouzdanost ovih sustava je jednaka pouzdanosti sustava koji su pojedinano razvijeni pomjeri korisnika[1].

Standardna rjeenja nude mnotvo predefiniranih izvjetaja. Korisnici mogu do odreenemjere prilagoditi te izvjetaje svojim potrebama (postoje ekrani sa mogunou odabirakljunih atributa koji su potrebni za izvjetavanje, razmjetaj, vidljivost i irine kolona,sputanje podataka u Excel i druge formate, direktno ispisivanje, i sl.). Ukoliko

predefinirani izvjetaji ne postoje uvijek je mogue kreirati nove izvjetaje. Uspjenostkreiranih izvjetaja ovisi o tome koliko su vjeti konzultanti u povezivanju podataka isamoj mogunosti povezivanja podataka vezanih za razliite poslovne procese.

ERP paketi su opsena rjeenja s velikim brojem mogunosti i velikim brojem razvijateljarjeenja diljem svijeta. Stoga je postojanje dokumentacija jako bitna stvar, ne samo zbogdodatnog razvoja ve i zbogsamog odravanja i administriranja sustava.

Ukoliko se dogodila pogreka u sustavu ili je potrebno dodati/promijeniti dodatnufunkcionalnost bitnu za poslovanje, a organizacija ne zna kako rijeiti problem postoji

proces kako ga otkloniti(npr. SAP R/3):

Potraiti na pripadajuem vendorovom portalu da li postoji opis problema irjeenje. Uvijek je navedeno za koju verziju sustava promjena vrijedi. Ako jerjeenje pronaeno sastoji se od detaljnog opisa po koracima kako implementirati

promjenu. Ukoliko je pogreka programska dodan je programski kod koji seimplementira na sustavu prema uputama.

Ukoliko nije naeno rjeenje za problem mogue se konzultirati sa podrkom ERPpaketa. Ona upuuju na rjeenje dajui broj ve jednom rijeenog takvog problemaili daju savjet kako bi se neto moglo rijeiti.

Ako se takav problem ne nalazi u bazi i ne postoji procedura, podrka rjeavaproblem. Mogue je spajanje ERP sustava na korisnikov sustav kako bi se tonovidjelo u emu je problem i kako ga ispraviti. Kada je problem rijeen, pie se u

bazu vidljivu na portalu i korisniku se alje ifra pod kojom gleda rjeenje iimplementira promjenu prema uputama.


10/36

10

2.5Zato se korisnici odluuju na ERP sustav

Kada organizacija sazrije eliimati centralizirani sustav u kojem e voditi svoje poslovanje.Organizacija kupuje ili razvija aplikacije ovisno o zahtjevima i procesima do nekoga stupanja.

Kako organizacija raste, a tako i broj aplikacija, sloenost izmjene podataka meu njimapostaje viestruka, dohvaanje i sloenost dohvaanja podataka oteano. U tom trenutkupoinje se teiti integraciji aplikacijskih rjeenja, odnosno tei se jedinstvenom sustavu ukojem e se nalaziti cjelokupno poslovanje.

Kako je vrijeme za razvijanje cjelokupnog rjeenja veoma dugotrajno, veina organizacija seodluuje na gotovo rjeenje. ERP paket predstavlja standardiziran sustav koji sadricjelokupno poslovanje na jednome mjestu, a ne bezbroj malih aplikacija koje treba dodatno

odravati.

Dobavljai ERP paketa potencijalne korisnike impresioniraju brojem prethodnih instalacija,svojim financijskim pokazateljima i referentnom listom koja ukljuuje najpoznatije svjetskekompanije. Ono to korisnik stvarno dobije kupnjom ERP paketa su sadraj i struktura baze

podataka te velika koliina parcijalnih rjeenja za operativne funkcije meu kojima se mogu,ali ne moraju, nalaziti ona rjeenja koja korisnik stvarno treba [1]. Funkcionalnost kojanedostaje nadoknauje se dodatnim komponentama (tzv. konceptima), primjerice: CustomerRelations Management (CRM), Supply Chain Management (SCM), Aplication Link Enable

(ALE), Data Warehousing i Data Mining. Skup svih parcijalnih rjeenja koji nastajekomponentizacijom naziva se najboljim od najboljeg (best of breed). Broj predefiniranihfunkcija je toliko velik da moe ostaviti dojam da se radi o programskim paketima u kojima jesve ve rijeeno, iako se zapravo radi o nedovrenim rjeenjima koja treba razvijati do pune

funkcionalnosti i primjenjivosti[1].

Uobiajeno je da velike organizacije, koje se raire izvan granica kupnjom drugih organizacijau tim zemljama prolaze kroz proces integracije. Da bi se integracija uspjeno provela vrlo jevano imati unificirani informatiki sustav. Procesi organizacija uglavnom ostajunepromijenjeni, ali se informatiki sustavi moraju unificirati. Tu do izraaja dolaze velikiERP sustavi koji su dovoljno unificirani da se mogu prilagoditi svakom poslovnom procesu,

ali ne opet toliko specijalizirani da funkcioniraju samo u jednoj organizaciji.

Integracija moe iiu 2 smjera:

Postoji jedan sustav u kojem se odravaju procesi svih kompanija. Tada je sustav dovoljnoopenit da svaka organizacija moe svoje procese provoditi u tome sustavu i normalno

funkcionirati. Na taj nain: dobiva se centralizirani sustav smanjuju se trokovi odravanja esto puta se ne moe optimizirati i prilagoditi poslovni proces po organizaciji ako

im poslovni procesi nisu jednaki

uteda je na licencama i raunalnim resursima (serverima) u sluaju separacije neke od organizacija mora se kreirati projekt za segregaciju

podataka vezanih za tu organizaciju.

Svaka organizacija ima svoj ERP sustav (Sustav je od istog proizvoaa, ali ga jeprilagoen iskljuivo poslovnim procesima te organizacije). Time je omogueno:


11/36

11

Mogue je odravanje sustava pomou jednog IT-asmanjenje trokova Bolja prilagodba poslovnih proces po organizaciji Jednostavnije povezivanje podataka iz sustava u sustav Mora postojati centralni sustav kojim se uparuju podaci i time omoguavaglobalne

analize (Data Warhousing, Data mining)

Ukoliko doe do segregacije neke od organizacija, odvajanje podataka je puno lakejer se podaci ve nalaze u odvojenim sustavima


12/36

12

3. ivotni ciklusERP sustava

ERP sustav je polugotov proizvod koji treba prilagoditi organizaciji i njenom poslovanju.

Radi toga potrebno je znati to sustav podrava i kako to napraviti.

Znaenje rijei razvoj (engl. development) kad se govori o ERP sustavu ne znai razvojproizvoda iz nule nego dodavanje dijelova koji nedostaju ili mijenjanje postojeeg dijela takoda se prilagodi korisniku. Najosnovnija prilagodba je prilagodba sustava (customizing)

predefiniram sueljima u kojima se odabiru i kreiraju opcije. To je posao funkcionalnihkonzultanata koji razumiju poslovne procese i module i znaju prilagoditi sustav tako da

prilagode rjeenje korisnikovim potrebama.

ERP rjeenje nije kratkorono rjeenje, stoga treba dobro razmisliti prije same implementacijekoliki ebiti opseg implementacije. Takoer, jednom kadje sustav ERP implementiran, i kadzaivi, to je samo jedna od faza ivota ERP sustava.

Nakon faze prilagodbe, koja je otprilike 6 mjeseci, organizacija napokon poinje imati koristiod rjeenja. Nakon faze implementacije, nastavlja se danji razvoj.

Danji razvoj moe biti u razliitim smjerovima: dodavanje dodatnih funkcionalnosti,

ugradnja novih modula,

povezivanje sa drugim sustavima u jednu cjelinu.

Cijeli ivotni ciklus najbolje je vidljiv na slici 1. gdje je predstavljen klasian ERP ivotniciklus. Ciklus se sastoji od 6 glavnih faza:

ImplementacijaI. faza ImplementacijaII. faza i odlazak u produkciju Proirenje vrijednosti (Extended Value) Odravanje vrijednosti (Maintainig Value) Slabljenje vrijednosti (Declining Value)

U nastavku e biti opisana detaljnije znaajke samih faza.


13/36

13

Slika 1. ERP ivotni ciklus


14/36

14

3.1 ImplementacijaI . faza

Na dananjem tritu ERP paketa mnogi od najboljih konzultanata su bivi zaposlenici ERPsoftverskog tima. Prema rijeima Andy Klee, predsjednika Klee Asociations Inc., najboljikonzultanti po fer cijeni su oni neovisni. Njegova je preporuka uzeti bar jednu neovisnog

konzultanta u igru. Na taj nain se mogu postii dobri datumi (npr. krai vremenskiangaman).

Treba dobro obratiti panju na edukaciju zaposlenika prije samog poetka projekta. Mnogitimovi prije same implementacije idu na mnogobrojne teajeve bez da imaju ikakvoga

predznanja o samome sustavu. Preporuka je da vanjski konzultanti implementacijskom timu

unutar organizacije daju pregled cijelog dijela softverskog rjeenja koji se implementira u 4 ili5 dana. Neka lanovi tima prou u cijelosti jednostavne transakcije kako bi dobili uvid ucijelo rjeenje. Na kraju toga tjedna trebali bi imati dovoljno dobru ideju kako dizajniratirjeenje.

Detaljnija, modulski specifina rjeenja mogu biti obavljena kad doe vrijeme za to. Prvo segleda pregled postojeeg stanja (As-is). U skladu s timom konzultanata i lanovimaimplementacijskog tima sastavlja se dokument kojim se definiraju budui procesi (To-be).U nekim tokama diskusijebiti e potrebne dodatne edukacijei konzultanti mogu odvojiti pardana za dodatnu edukaciju lanova tima. Poanta je da je potrebno da konzultanti dajudovoljno edukacije kako bi se moglo poeti s postavljanjem novog modela. U poetku netreba inzistirati na sloenim stvarima jer i s osnovama ima dosta problema.

Sama implementacija se sastoji od vie faza. Neki od ERPpaketa imaju svoje preporuke kakoprovesti implementaciju (npr. SAP svoju implementacijsku metodologiju naziva ASAP Accelereted SAP) i nude razne obrasce i dokumente kako bi se moglo lake pratiti svaku odfaza.

Detaljniji koraci implementacije sastoje se od:

Analiza (Project Planning)

Specifikacija zahtjeva (Business Blueprint)

Implementacija i testiranje (Realization)

Kontrola kvalitete i obuka (Final Preparation)

Going Live i podrka

3.1.1 Analiza (Project planning)

U fazi analize potrebno je odrediti opseg procesa koji su specifini zaorganizaciju te uoitimogue slabe toke. U sluaju da ERP paket ne pokriva adekvatno procese organizacijemoraju se vidjeti naini kako rijeiti problem.

Takoer se mora razluiti to su procesi organizacije, a to su elje korisnika koje nemajuveze sa procesima vezanim za organizaciju. Korisnici su obino naueni raditi na neki nain,ili na nain kako je zahtijevala dotadanja aplikacija i teko im je prihvatiti promjenu u nainurada.


15/36

15

3.1.2 Specifikacija zahtjeva (Business blueprint)

U ovoj fazi definira se kompletan opseg implementacije ERP sustava na nain da se odredeposlovni procesi koji e biti podrani sustavom.

U sluaju da se uoe nedostaci sistemske funkcionalnosti, referentni model je mogue proiritinovim elementima koji e te zahtjeve opisati. Na taj nain osigurana je identifikacijarazvojnih zahtjeva u toku ove faze. tovie, model organizacije mogue je proiriti i onimfunkcijama koje se obavljaju runo, koje se rade u drugim aplikacijama.

Referentni model takoer sadri i korisnike uloge. Na taj nain se u ranoj faziimplementacije mogu raspraviti informacije o autorizaciji, a kasnije pomou izvjetaja dobitineophodne informacije za ostvarivanje autorizacije u ERP rjeenju.

Informacije o organizacijskim jedinicama postaju znaajne za kasniju obuku zaposlenika, a

pruaju i podlogu za brojne analize.

3.1.3 Implementacija i testiranje (Realization)

Na razvojnom sustavu se rade prilagodbe sustava u skladu sa blueprintom (dokument u kojem

se specificiraju zahtjevi organizacije i opseg implementacije). Tu se rade manja testiranja jer

obino ima jako malo podataka. Nakon to se ovdje napravi kostur implementacije u oblikuprilagodbe ERP sustava prema zahtjevima projekta i ustanovi se da je to to, sve promjene se

sele na sustav kvalitete.

Konzultantiprilagoavaju sustav i testiraju da li su prilagodbekorektno napravljene. Ukolikoima nedoumica komuniciraju se stvari sa poslovnom stranom kako bi ih se razrijeilo.

Sve to se odnosi na prilagodbu sustava radi se iskljuivo na razvojnom sustavu. Postojetono definirane procedure i transakcije u kojima se odreene prilagodbe rade. Takoer semora znati redoslijed transakcija i procedura pri prilagodbi. Nikada se direktno ne pune takvi

podaci runo direktno u bazu nego se to radi pomou tono predefiniranih transakcija iekrana.

Prijenos prilagodbe se izvrava transportiranjem promjena na ostale sustave. Obino seistestirane i provjerene prilagodbe prebacuju na sustav kvalitete.

3.1.4 Kontrola kvalitete i obuka (Final preparation)

Na sustavu kvalitete se rade detaljna testiranja. Sustav kvalitete puni se pravim podacima

(npr. popis poslovnih partnera, aktualna organizacijska struktura). Time se takoer djelominoprovjerava da li e kod unosa takvih podataka doi do neoekivane pogreke koja se ondaispravlja. Na sustavu kvalitete se nita ne ispravlja i ne razvija. To je sustav koji slui samo zasimulaciju produkcijskog sustava i testiranje.

Sve pogreke otkrivene na sustavu kvalitete se ispravljaju na razvojnom sustavu i zatim setransportiraju sa razvojnog sustava na sustav kvalitete. Takoer je poeljno da se prije

prebacivanja zahtjeva na produkcijski sustav, na sustavu kvalitete detaljno provjeri da li jegreka zaista ispravljena i da li se moda neto drugo promijenilo.


16/36

16

Kada se iz faze razvoja prijee u fazu testiranja tu se aktivno ukljuuje poslovna strana. Udijelu testiranja na sustavu kvalitete sudjeluju sami korisnici. Obino postojibar jedan kljunikorisnik (key user) po modulu. Kljuni korisnici su osobe koje najbolje znaju svoj dio

poslovanja u organizaciji, pa su stoga veinom zaposlenici s poslovne strane . Nakon

implementacije i dalje usko surauju s informatikom i obino definiraju zahtjeve premainformatici/konzultantima to se tie dijela njihovog poslovanja.

3.1.5 Going live i podrka

Prije Going live-a potrebno je zavriti sa svom dokumentacijom. Nakon to se dokumentacijazavri (projektna, tehnika i korisnika), moraju se svi unit testovi proi i zadovoljiti. Tek kad

poslovna strana kae da je zadovoljna projekt prelazi iz faze implementacije u produkciju.

Sve promjene nastale na razvojnom sustavu, i provjerene na sustavu kontrole, se prebacuju na

produkcijski sustav. Na tome sustavu korisnici samostalno obavljaju poslove.

3.2 Implementacij aI I . faza i iza

Jednom kad se doe u produkciju treba oko est mjeseci da se sustav stabilizira. Tada sedolazi u drugu fazu.

Ovisno o tome kako je prola prva faza moda e biti potrebno poveati tim za nekolikolanova. Ako je krenulo loe neki od najboljih internih kadrova e vrlo vjerojatno bitinedostupni i stvari e se dodatno zakomplicirati.

Druga faza je takoer dobro vrijeme za procjenu vrijednosti konzultantske kompanije. Akoniste bili zadovoljni njome u prvoj fazi, neete biti zadovoljni njima niti poslije. Ako postojiinformatika unutar organizacije ona dalje preuzima odravanje sustava i nastavlja daljnjirazvoj istog.

3.3 Poveanjevri jednosti (Extending Value)

Nakon to je druga faza implementacije prola i stanje se stabiliziralo dolazi se do stupanja dase obeane stvari i dugovi nastali tijekom implementacije trebaju rijeiti.

To jejedna od najduih faza koja moe trajati i po nekoliko godina. Dodaci mogu poeti kao

mali, ali kako se nadograuju, moe se poeljeti ii dalje i dalje i kada se uzme u obzir svadodana funkcionalnost moe narasti u veliki projekt koji ukljuuje Business intelligence irazliite nadogradnje koje mogu biti vezane natrag na osnovni ERP sustav to je mnogo

posla. U tom periodu veina organizacija eli ubrzati tempo zavravanja projekata koji se tiunadogradnji kako bi to prije imali dobiti od njih u odnosu na to manje trokove.

Tijekom te faze lanovi tima sazrijevaju i dolaze u fazu kada su eljni sve vie znanja i kadaupoznaju rad s dobavljaevim Help Deskom. Taj se status moe definirati najbolje kadarazgovarate s novim zaposlenicima koji znaju vrlo malo o softveru ili kako ga koristiti u

realnom svijetu i s kojim razgovor tee otprilike ovako: To je veoma interesantno, nisamznao da se to moe tako, Moete li mi poslatisliku ekrana, Ne znam, ali uvidjeti pa vamse javimi sl.


17/36

17

Nakon par takvih poziva shvaase da se je to vraanjenatrag ERP komuni omoguavajuiedukaciju novim zaposlenicima iako moda i nije va zaposlenik. Sljedei korak je da seodustaje od zvanja Help Deska i da se samostalno rijeiproblem makar to znailo i promjeneu kodu to znai da se vie nikada ERP sustav nee moi vratiti u prijanje stanje.

3.4 Odravanje vrijednosti (Maintaining Value)

Prolo je ve 5 do 7 godina od implementacijei vrijeme je za novo doba ERP rjeenja. eljaje samo da slijedeih 5 - 10 godina sustav ivi. Poslovanje treba neophodne promjene.Shvaaju se promjene, sustav se mijenja i prilagodba se integrira kako bi se dodala dodatnafunkcionalnost.

Jednog dana netko primijeti da se plaa 22% trenutne softverske cijene, a ne 22% cijene spopustom koja je plaena, za godinje odravanje. Poinjete razmatranje odravanjaod stranetreekompanije jer neke od njih imaju dobru povijest softverskog odravanja svojih klijenataza djeli cijene koja se sada plaa.

Sklapanje ugovara s treom kompanijompoinje imati smisla i istrauju sealternative. Traise kompanija koja zadovoljava potrebe organizacije. Prodajni predstavnik trenutnog ERP

rjeenja vas prestaje zvati, ali prije toga alje upozorenje da ete morati platiti 150%povratnog honorara kako bi se vratili u krug. U tom trenutku se najee shvatida ete nakon4 godine imati dosta uteevine da ionako kupite novo rjeenje.

3.5 Opadanje vri jednosti (Decli ning Value)

Poslovanje se mijenja i dolaze nove tehnologije koje su nune u radu. Dajte im par godina da

se ustale.

Vrijeme prolazi, a uteda raste. Poslovanje zahtijeva daljnje izmjene. Kua od karata se drijo jedino flasterom i poinje se polako raspadati. Vrijemeje da se ugovori sastanak sa novimERP strunjakoms kojim ese ui u sljedei krug ERP ciklusa.

Spremni za jo 10-20 godina? Ovoga puta ete to napraviti kako treba!


18/36

18

4. Primjer ERP sustava: SAP R/3 okruenje

4.1 Metodologija implementacije - ASAP

SAP je razvio svoj nain implementacije nazvan ASAP (Accelerated SAP). Ta se metodatemelji na viegodinjem iskustvu implementacija. U skladu s metodologijom SAP nudi

predefinirane obrasce u excel i word formatu kako bi olakao voenje implementacijskogprocesa. Na slici 2 prikazan je tijek implementacije tom metodom i poslovi definirani po

pojedinoj fazi.

Slika 2.ASAP metodologija

Projektni plan

Izraditi projektnicharter

Postavitiimplement.standarde iprocedure

Kick-offsastanak

Postavljanjesustava (DEV &QA)

Instalacija

produkcijskoghardvera

Provjerakvalitete:Priprema

projekta

Monitoriranjeivim

okruenjem

Zatvaranjeotvorenihzadataka

Zapoinjanjeplan dugotrajnepodrke

Kontrolakvalitete:Putanje uprodukciju (GoLive)

Zatvaranjeprojekta

Proienjecutover planova

Postavljanjeplana zadugotrajnupodrku

Treniranjekrajnjihkorisnika

Kreiranjezaposlenika nahelp desku

Upravljanjesustavom

Izvoenjecutovera

Konanaprovjera:Konanepripreme

Kretanje uprodukciju

Realizacija Zavrna priprema Go Live &Podrka

Sadanjerjeenje/imple

mentacijskipristup

Validacijakupevogsustava

Postavitioekivanja sakupcem

Kreiranjeponudbenogdokumenta

Pregled i

potvrdaponude

Prototiptrenutnog

rjeenja

Kompleksnostdohvatapodataka

Identificiranjedelta zahtjeva

Dizajniranjedelta rjeenja

Potpisivanjebluprinta sadeltama odstrane kupca

Dati konaanoblik izvjetajao poslu

Procjena Predprojektneaktivnosti

Delta zahtjeva

Procjena Implementacija

Validacijaorganizac.

konfiguracije

Validiranjeposlovnihprocesa

Realizacijadelta zahtjeva

Upravljanjeorganizac.promjenama

Planiranjeprodukcijskepodrke i

cutovera

Pokretanjeintegracije ipotvrdnihtestova

Planiranjeedukacijekrajnjihkorisnika

Internarevizija

Vrijeme

Putanje uprodukciju

Kick-offprojektaPoetak

Pripremne radnjero ekta

Kvalificiranjekupca

Potpisivanjeugovora

Pregledzahtijevanih

podataka i planienjapodataka

Edukacijaprojektnog tima

Pripremaorganizacijskihpromjena

Postavljanjeokruenjaprojektnog tima

Definiranje

sistemskeokoline iinstalacijahardvera


19/36

19

4.2 OkruenjeSAP ERP sustava

SAP okruenje(landscape) se definira sa tri okruenja kojasu meusobno ovisni. To su: Razvojni sustav (DEV),

o SAND okruenje programera. Razvijaju promjene vezane za promjenuobjekata. Tu se razvijaju klijentski neovisne promjene

o CUST Prilagodba sustava sa strane konzultanta modula. Tu se razvijajuklijentski ovisne promjene

o TEST Klijent za testiranje promjena nastalih na klijentima vezanim zaSAND i CUST okolini (klijentima).

Sustav kvalitete (QAS)o QTSTTestiranje na sustavu kvalitete. Potrebno je proi sve testove (unit test)

kako bi promjena mogla prei na produkcijski sustav.o TRNGKlijentska okolina koja se koristi pri edukaciji krajnjih korisnika

Produkcijski sustav (PRD)o PRODProdukcijski klijent.

Na slici 3 je prikazano SAP klasino okruenje. Kamioni predstavljaju transportne zahtjevekoji sadre promjene pomou kojih se promjeneprenose sa sustava na sustav.

Slika 3.Trostruko sistemsko SAP okruenje

Unutar istog sustava SAP podrava vie klijenta. Klijent se najjednostavnije definira kaopodsustav unutar sustava koji ima zasebne podatke. SAP ima definirane klijentski ovisne i

neovisne objekte. Tako na primjer programi, tablice i funkcije su neovisne o klijentu. Kada se

jednom kreiraju, promijene ili izbriu promjene su vidljive na svim klijentima istog sustava

(npr. razvojnog sustava).


20/36

20

Stvari koje se tiu prilagodbe sustava ovisne su o klijentu tako da se vrijednosti u samimtablicama razlikuju ovisno o klijentu. To znai da na svakomklijentu moe postojatirazliito

prilagoen sustav. Primjer klijentski ovisnih stvari su potanski kodovi, ifre zemalja, ifarnicimaterijala. Primjer koritenja razliitih klijenata na istom sustavu je primjer organizacija.Svaka od kompanije moe biti na svome klijentu. Koriste se isti programi, tablice i funkcije,

ali se organizacijski podaci razlikuju.

Svaka promjena, kreiranje novog objekta ili nova prilagodba se biljei. Prije snimanja sustavtrai da se definira vrsta promjene (vrsta transporta) i dodjeljuje automatski broj novogtransportnog zahtjeva. Ukoliko je promjena vezana za prilagodbu sustava (i obino jeklijentski ovisna) onda je to Customizing request, a ako se vee za promjenu/kreiranje nekogobjekta (program, tablica, ) i klijentski je neovisna onda je to Workbench request.

Transportni zahtjevi slue za prijenos sa sustava na sustav, a transportni zahtjevi koji suklijentski ovisni koriste se i za prijenos sa klijenta na klijent na istome sustavu. Kada se

transportni zahtjev otpusti onda moe prei na drugi sustav. Prijenos sa sustava na sustav

moe se definirati tako da se obavlja runo ili automatski. Svaki od pristupa ima prednosti inedostatke. Kod automatskog prijenosa dobro je da sve to je napravljeno ide na sve unaprijeddefinirane sustave tako da su svi sustavi jednaki. Takoer, redoslijed otputanja transportnihzahtjeva je jednak importu na produkcijski sustav pa se time smanjuje mogunost greke kojemogu nastati kada se runo prenose zahtjevi. S druge strane, gubi se uvid to se uistinu

prenosi.

Kod runog prijenosa ima se kontrola tono koji zahtjev ide na koji sustav. Ti m nainom se sdruge strane optereuju lanovi sistemakog (BC)tima koji moraju svaki transportni zahtjev

prebaciti runo nakon neije potvrde. Poto mnogo ljudi istovremeno radi na istome sustavu,moe se dogoditi da razliitiljudi mijenjaju isti objekt. Poto zahtjevi ne idu automatski moguse prebrisati promjene nad istim objektom i time zakomplicirati situaciju, pogotovo ako se to

dogodi na produkcijskom sustavu. Takoerse moedogoditi da se ne prebace sve promjenetako da sustavi nee isto ponaati.

Sve to se tie bilo kakve promjene na sustavu radi se na razvojnom sustavu . Obino se narazvojnom sustavu moe nalaziti vie klijenata. Svaki od klijenata moe imati razliite

postavke, korisnike koji se mogu prijaviti na taj klijent i mogu imati razliito dodijeljene role.Nakon to je razvoj istestiran na razvojnom sustavu transportnim zahtjevom se promjeneprebacuju na sustav kontrole kvalitete. Na razvojnom sustavu obino se imaju sva prava.Natom sustavu imaju prava samo lanovi tima informatike ili konzultantske kompanije koja

odrava sustav.Sustav kontrole kvalitete bi trebala biti kopija produkcije, sa kopiranim pravima i rolama s

produkcije. Produkcija bi se trebala to eekopirati kako bi testiranje bilo to korektnije.Ukoliko se otkrije pogreka, ispravljanje se radi iskljuivo na razvojnom sustavu. Za tu se

promjenu kreira novi transportni zahtjev. Kada je iztestirano da radi na razvojnom sustavu,

ispravci se alju na sustav kvalitete. Tu se rade ponovna testiranja. U implementacijskomdijelu, ili pri projektima na postojeem ERP rjeenju, preporuljivo je da se testiraju unittestovi kako bi se provjerilo da sve uistinu radi.

U ovom dijelu testiranje vre kljuni korisnici s poslovne strane. Kada oni daju odobrenje da

je to dobro, sve transportne zahtjeve vezane za tu promjenu/prilagodbu se prebacuje na


21/36

21

produkcijski sustav. Vano je da se transportni zahtjevi prebacuju istim redoslijedom kako sunastajali jer u suprotnome e se promjenemeusobno prebrisati.

4.3 lanovi tima

U ERP paketima koji su veliki sami po sebi postoje odreene uloge lanova timakoje radeodreene vrste poslova. Svako od njih ima specijalizirana znanja za neko od podruja samogERP paketa.

U SAP-u veinom se uloge dijele na slijedee:

BC konzultanto Najvie odgovara opisu sistem administratora. On je zaduen za postavljanje i

odravanje sustava, instaliranje upgrade-a, prati i radi analizu optereenosti sustava ibaze, komunikacije s drugim sustavima i sl.

o Osoba sa tom rolom odgovorna je za kontinuiran rad sustava i to operativnog sustavana kojem se nalazi ERP sustav, baze s kojom ERP sustav radi i samog ERP sustava.

o Pri instalaciji novog sustava BC konzultant je prvi. Instalira operacijski sustav,odgovarajuu bazu i inicijalni ERP sustav.

o Poslove koje su u domeni BC konzultanta su: dodjeljivanje rola korisnicima sustava prema zahtjevu (tj. koji korisnik ima koju

rolu. Rola sama po sebi ima odreena prava nad transakcijama i tablicama) Optimizaciju sustava

Transportiranje promjena sa sustava na sustav BC konzultant seli promjenesadrane u zahtjevima sa razvojnog sustava (DEV) na sustav kvalitete (QA) iliprodukciju tog sustava (PROD). Isto vrijedi i za transport zahtjeva sa sustava na

sustav (npr. neki program se nalazi na jednom razvojnom sustavu i elimo gaprebaciti na neki drugi). ABAP konzultant moe program prebaciti u zahtjev, aliga BC konzultant prebacuje sa sustava na sustav

Kreiranje i odravanje konekcija sa drugim sustavima Implementacija patch-eva na sustavu Arhiviranje sustava (kada se pohranjuju i izbacuju podaci iz sustava u datoteke) Upgrade sustava

ABAP konzultanto Najvie odgovara opisu programera ali u irem smislu te rijei. Sve promjene,

proirenjai dodatni razvoj vezan za objekte definirane us sustavu odrauje ABAPkonzultant.

o ABAP konzultant ne mora znati poslovne procese kako bi mogao napraviti posao(iako je naravno topoeljno).

o Nikada ne razvija rjeenje samostalno nego u dogovoru s analitiarom (poslovnimkonzultantom) pojedinog modula

o Poslovi koje obavlja ABAP konzultant: Programiranje rjeenja prema zahtjevima analitiara


22/36


23/36

23

4.4 Alternativne kombinaci je konzul tant-kori snik-programer

Ovisno o organizaciji posla, broju lanova tima i vrsti poslova koje obavljaju neke se funkcijei poslovi mogu preklapati. Tako na primjer u manjim poduzeima tehnika osoba obavlja

funkciju ABAP konzultanta i BC konzultanta.

Poto veina funkcionalnih konzultanata dolazi iz svijeta ABAP konzultanata poneki puta istaosoba obavlja funkciju analitiara i programera.

U nekim poduzeima je vrlo veliki obim poslova, tako da na primjer neki programer radiiskljuivo jednu vrstu poslova (kreiranje samo suelja za unos podataka, samo izvjetavanje,samo spajanje sa vanjskim sustavima, sl.).

Takoer u nekim poduzeima analitiari su analitiari jednog modula, a neki puta suanalitiari vie modula. Isto tako poneki puta neki modul ima vie analitiara za taj modul. Ovisi o poslovnim procesima i veliini poduzea te o samoj preraspodijeli poslova unutarmodula.

4.5 Nivoi i vrste pri lagodbe/razvoja u SAP R/3 okruenju

Postoje viestruki nivoi promjena kojima se omoguava prilagodba sustava. Na slici 4 suprikazani nivoi promjena u SAP R/3 sustavu.

Slika 4.Nivoi promjena u SAP R/3 sustavu


24/36

24

SAP R/3 se moe mijenjatina slijedee naine kako bi se zadovoljile potrebeorganizacije: Prilagodba (Customizing): postavljanje specifinih poslovnih procesa i funkcija

za korisnikov sustav u skladu sa implementacijskom vodiem (ImplementationGuide - IMG). Potreba za takvompromjenom je ve predviena sa strane SAP-a iimplementacijska procedura je implementirana. Potrebno ju je znati koristiti. Uz

svaku od transakcija je dokumentacija koja ukratko opisuje svrhu transakcije iopcije. Pomou tih transakcija funkcionalni konzultanti prilagoavaju sustav.Promjene definirane na ovome nivou se prenose Customizing transportom i

klijentski su neovisne. Neke promjene se moraju neovisno raditi na svakome

klijentu.

Personalizacija (Personalization):prilagodba je vezana za globalno prikazivanjeatributa pojedinih polja ( npr. postavljane inicijalnih vrijednosti ili skrivanje polja,

kreiranje korisnikih menija). Na te promjene mogu utjecati krajnji korisnici.

Promjene (Modifcation): ove promjene se rade samo ako druge opcije ne postoje

jer se ovom promjenom mijenja originalni SAP-ov objekt. Prije svake promjeneSAP sustav trai SSCR klju. SSCR klju se dobiva tako da se korisnik prijavi naSAP-ove Internet stranice i pod svojim imenom trai SSCR klju navodeiinstalaciju SAP-a, verziju SAP-a, vrstu objekta (npr. da li se radi o tablici,

programu, funkciji, ), i naziv objekta koji mijenja. Generiranje kljua se biljeiucentralnom sustavu SAP-a za korisnikovu instalaciju i objekt. Generirani klju(SSCR klju) se upisuje u korisnikov SAP sustav u predefinirano polje i nakontoga su promjene doputene na tom objektu. Ako SAP dostavi promijenjenuverziju takvog objekta (npr. nova verzija, ili ispravak koda), korisniki sustavmora biti naknadno runo prilagoen da podrava tu promjenu.Velikih potekoamoe biti prilikom upgrade-a kada promjene SAP-ovih originalnih objekata mogu

biti velike. Jedna od opcija za izbjegavanje tog problema je kopiranje SAP-ovog

objekata u Z/Y korisnikov objekt.

Proirenje (Enhancment): SAP je predvidio proirenja nekih dijelova svojihobjekata. U skladu s time je predvidio naine na koji je mogue ta proirenjauiniti. Razliiti su naini proirivanja za razliite objekte. Na primjer, tablica semoe proiriti pomou include strukture predefinirane od SAP-ovog programera ili

pomou append strukture koju moe svaki korisnikov programer proiriti. Kodfunkcija i programa, takoer su omogueniprazni include-ovi, podekrani, meniji isl. pomou kojih se omoguuje korisnikovom programeru da nadopuni

funkcionalnost prema potrebama. Prednost takvog naina rada je se upgade-om iliispravljanjem koda ne mijeaju i korisnikov i SAP-ov kod.

Dodatni razvoj (Customer Development): Omogueno je da se u korisnikovomnamespace-u (svi objekti imaju poetni prefiks Y i Z) kreiraju novi objekti. Tomogu biti funkcijske grupe, funkcije, programi, transakcije, ekrani, klase, tablice,

pogledi i sl. Poneki puta se promjene (Modifications) rjeavaju tako da se SAP-ovoriginalni objekt(i) kopira kako korisnikov objekt i onda se taj objekt mijenja

prema zahtjevima. Mana takvog pristupa da se gubi veza s originalnom.

Proirenje, promjene i dodatni razvoj se radi pomou ABAP Workbench alata. Za te su

promjene odgovorni ABAP konzultanti jer se mijenjaju objekti (tablice, funkcije, programi,klase, .)


25/36

25

Prilagodba i personalizacija se mijenjajupomou IMG-a. Za taj dio su odgovorni funkcionalnikonzultanti jer mijenjaju postavke sustava.

4.6 Razvojni alati u SAP R/3 okruenju

Osnovni meni nakon prijave u sustav sa strane korisnika je prikazan na slici 5. Dio vezan za

razvojne alate sa strane SAP se nalazi pod SAP menu>Tools.

Slika 5.Osnovni meni

SAP pomou Database interface-a komunicira sa bazom podataka. Na taj nain se

omoguava rad sustava neovisno o bazi podataka. Veza sa bazom podataka vidljiva je prekomenija ABAP Dictionary. Dictionary sadri podatke o tipovima elemenata, o pogledima,strukturnima tablicama, transparentnim tablicama (te tablice sadre podatke). Postoje razliititipovi podataka i struktura koje ne prikazuju jednako stanje bazi podataka. To je glavni razlog

zato se pri mjenjaju, unoenju i brisanju podataka to ne radi direktno sa tablicamadefiniranim uDictionary-iju ve preko predefiniranih suelja i funkcija.

ABAP Editor je glavni alat koji se koristi za programiranje programa u SAP-u. Program u

SAP-u se naziva Izvjetaj (Report) iako ne slui samo za izvjetavanje. U njemu se piu,izmeu ostalog, i suelja sa rad s bazompodataka. Udodatkuse nalazi primjer koda pisan uABAP progamskom jeziku.


26/36


27/36

27

Slika 7.Transakcijom SPRO dobiva se stablo sa linkovima na transakcije prilagodbe

Kada se korisnici ulogiraju u sustav vide samo linkove transakcija koje su postavilifunkcionalni konzultanti korisnicima u njihovo stablo. Na slici 8 je prikazan meni kako ga

vide korisnici. Klikom na neki od linkova korisnici, ukoliko se radi o izvjetaju e vidjetiekrane kao u poglavlju 8.3.


28/36

28

Slika 8.Prikaz osnovnog menija gledanog sa strane korisnika


29/36

29

4.7 Model razvoja i metodologija

Model razvoja koji se koristi u SAP razvojnom okruenje u odnosu na teorijski poznatemodele najvie odgovaravodopadnom i pseudostrukturnom vodopadnom modelu. Osnovne

karakteristike tih modela su[3]:

Klasini vodopadni modelo slijedno napredovanje iz faze u fazuo nisu dozvoljene naknadne promjene rezultata prethodnih fazao primjeren velikim projektima (investicijama)o prikladan za dobro definirano okruenje, gdje postoje razraene procedurerune

obrade ili raunalski sustav koji treba unaprijeditio Nedostaci

problem u sluaju pogreaka ili novih/promijenjenih zahtjeva uvoenje prema gore (bottom up): moduli, podsustavi, sustav sustav nije upotrebljiv dok nije gotov u potpunosti problem predodbe o produktu na temelju pisane specifikacije

Pseudostrukturni vodopadni modelo povratna veza i mogunost promjene rezultata prethodnih fazao uvoenje prema dolje: moduli na viim, pa na niim razinamao primjena tehnika strukturiranog programiranjao Strukturni (radikalni)o aktivnosti razliitih faza mogu se obavljati istovremenoo

koritenje rjenika podataka, 4GL i generatora aplikacijao prikladan kada se unaprijed ne zna konani izgled sustavao mora nastati (papirnati) model sustava

Ukoliko je proces prilagodbe/razvoja poznat koristi se vodopadni model. Implementacije se u

grubo moe gledati kao klasini vodopadni model jer su koraci unaprijed poznati i prije sameizrade se radi detaljna analiza poslova koje treba napraviti. Pie se blueprint u kojem se jasnodefinira to e sustav sadravati i kako e se ponaati.


30/36

30

Slika 9.Vodopadni i pseudostrukturni vodopadni model

Kod proirenja, mijenjanja ili razvoja novog dijela u ERP sustavu koristi se pseudostrukturnivodopadni model u kojem su koraci definirani, ali ako se uvidi da u nekom od koraka se ne

dolazi do rjeenja mogu je povratak sve do faze oblikovanja gdje se kree drugim nainom

rjeavanja problema. To je uglavnom zbog toga to je SAP R/3 sustav veoma kompleksan ivelik sustav u kojem nigdje nisu definirane jasno vidljive ovisnosti. Zbog toga analiza zna biti

dugotrajan i mukotrpan proces. Poneki puta sustav nema predvienu neku funkcionalnostzbog kojeg se rjeavanje problemamora mijenjati od predvienoga i traiti novi nain kako tonapraviti. Obino je povratna veza koja se koristi pri takovom nainom ona iz faze izrade ufazu oblikovanja i iz faze evaluacije u fazu izrade.

Drugi pristup je puno vie fleksibilniji jer doputa pogreku i njeno pravovremenoispravljanje. Takoer se tim nainom zahtijeva dokumentiranje rjeenja poto je ononepoznato do trenutka primjene.


31/36

31

5. Smjernice razvoja ERP sustava u budunosti

Kako tehnologija napreduje, informacije postaju sve vanije a i konkurencija sve bolja, stalnose nalaze novi naini kako biti najbolji i doi do kupca.

Novi naini kojima se tei: Internet rjeenja

o Svako od ERP paketa ima svoja Internet rjeenja, bilo da su to nadogradnje(CRM) na osnovni sustav ili samostalno rjeenje. Popularizacijom internetaotvorene su razne mogunosti.Najvea je prednost Internet rjeenja omoguen

pristup s bilo kojeg mjesta i raunalazaposleniku.o Za koritenje ERP rjeenjaje dovoljan browser bez dodatnih instalacija.o Veliki trokovi su licence po zaposleniku. Takoer poanta svakog sustava je u

konanici mogunost besplatnogizvjetavanja to veem broju zaposlenika.

Internet se pokazuje kao odlino rjeenjeza oba sluaja.

Lake povezivanje s drugim aplikacijamao Shvaa se da ERP rjeenja ne mogu u potpunosti zadovoljiti sve uvjete

poslovanja.

o Takoer poslovanje se ne eli ili ne moe odrei raznih aplikacijapomoukojih se vodi dio poslovanja.

o U oba sluaja obje strane (aplikacija i ERP rjeenje) sadre podatke koji sumeusobno ovisni. Stoga postoje mnogobrojni naini razmjenjivanja podatakaizmeu aplikacija koji mogu biti automatski, periodini ili po potrebi.

Integrirana rjeenja s drugim programskim jezicimao Jedno od takvih rjeenja je SAP-ov NetWeaver. Omogueno je kreiranje

samostalnih aplikacija neovisnih o SAP-u u Javi li .NETu, ali je puno lakedoi do podataka i razmjenjivati podatkeSAP R/3 rjeenjem. Ovim nainomdoputa se da poslovanje definiraposlovne procese prema svojim zahtjevima, a

podatke vezane za matini ERP sustav jednostavno dohvaa i mijenja. Svakaaplikacija obino sadri bazu. U ovom sluaju definira se baza, ali je odvojenaod baze matinog ERP sustava. Prijenos podataka se vri pomou SAP R/3funkcija.

o Takoer je omogueno sa strane raznih programskih jezika spajanje sa ERPrjeenjima pomou dodatnih klasa i objekata (npr. php, .NET)

Industrijska rjeenjao Industrijska rjeenja su obino proizala iz specijaliziranih poslovnih procesa

vezanih za neku industriju. Neka su rjeenja kupljena od informatike kuekoja je razvila dodatnu funkcionalnost standardnog ERP rjeenja za tuindustriju i nastavljen je dodatni razvoj od strane ERP dobavljaa.

Predefinirano rjeenjeo Trite velikih organizacija je ve iskoriteno tako da su se ERP proizvoai

poeli usmjeravati na mala i srednja poduzea. Najvea prepreka je bila u tomeda su trokovi implementacije i odravanja preskupi za takva poduzea, pa seona nisu zanimala za rjeenje. Zato je osmiljen sustav brzog i jeftinijegimplementiranja.


32/36

32

o Prednost takvog sustava je da je uglavnom prilagoen standardnom poslovanjuprosjene kompanije istoga je vrijeme implementacije veoma kratko. Poto jeimplementacija brza trokovi su takoer puno manji, a vrijeme implementacijese jako skrauje. Uz osnovno rjeenje postoje opcije raznih vertikalnih i

industrijskih rjeenja. Treba napomenuti takoer da to ovisi o zemlji u kojoj senudi takvo rjeenje, jer je ono razvijeno od strane partnera iz te zemlje.o Nedostatak je da je sustav uglavnom predefiniran i svaki dodatni zahtjev se

dodatno naplauje kao delta razvoj i poskupljuje samu implementaciju.Takoer zbog velike predefiniranosti, poduzee mora odluiti moe li svojuorganizaciju prilagoditi ponuenom rjeenju ili ne. Predefiniranost je tolikovelika da uzima neke stavke vezane za samu zemlju (npr. vrste poreza i

njihove vrijednosti, ogranien i predefiniran jezik na kojem se moe raditi)tako da se ne moe koristiti rjeenje predvieno za neku drugu zemlju.

o Primjer takvog rjeenja je All-In-One sa strane SAP-a.


33/36

33

6. Zakljuak

ivotni ciklus ERP sustava traje po 10-ak i vie godina. Nakon to proe odreeno vrijeme,korisnik obino nastavlja sa istim sustavom jer je utroeno puno novaca, sustav sadri

ogromne koliine podataka koje moraju biti dostupne u svakom trenutku i lanovi timaposjeduju specijalistika znanja koja su sakupljena godinama. Takoer je sustav ve uvelikeprilagoenposlovnim procesima specifinim za kompaniju, pa se obino odluuje na upgradepostojeeg ERP sustava.

ERP sustavi imaju mnogo mana, ali imaju i jako puno prednosti tako da jednom kad se usvoji

promijenjen nain razmiljanja organizacije da poslovni procesi ne postoje zbog njih negozbog poslovanja organizacije, sustav postaje funkcionalan.

Sustav je velik, neoptimiziran i skup za odravanje, ali prua konstantnu podrku, sigurnostsvojih podataka i provjerenu postojanost kod velikih organizacija.

Potencijalni kupci vie nisu velike organizacije jer su one ve pokrivene nego se usredotoujuna male i srednje organizacije. Razvijatelji ERP rjeenja odluili su napraviti rjeenja koja ezadovoljiti i manje korisnike. Rjeenja se razliku. Osnovna je poanta da su takvi ERP paketi

jeftiniji jer je implementacije puno kraa, postoje predefinirani scenariji koji se odmahinstaliraju korisniku. Treba uzeti u obzir da je opseg takvog rjeenja ogranien u odnosu nastandardnu implementaciju, ali pokriva poslovanje u malim i srednjim poduzeima. S drugestrane ne ukida im se mogunost i nadogradnja sustava ako bude potrebno to je za takveorganizacije benefit.

DobavljaiERP paketa su svjesni da su njihova rjeenja kruta i da korisnici ele imati rjeenjeprilagoeno njihovim potrebama. Stoga razvijaju platforme koje podravaju standardne jezikekako bi olakali integraciju ERP rjeenja i dodatnih aplikacija.

Sve je vie interesantno podruje poslovne inteligencije (Business intelligence), povezivanjepodataka i izrada razliitih analiza. Stoga se sve vie usmjerava panja na integraciju togdijela u same sustave ili kreiranje dodatnih alata kao nadogradnja na osnovni paket (npr. SAP-

ovo rjeenje je Business WarehouseBW).


34/36

34

7. Literatura

[1] Fertalj K.; Mornar V.; Kova D.; Haina N.; Pale P.; itnik B.; Zagreb; FER; 01/2002:Komparativna analiza programske potpore informacijskim sustavima u Hrvatskoj

[2] Bailor, Coreen (2006-07-05).For CRM, ERP, and SCM, SAP Leads the Way.Retrieved

on2007-03-29.

[3] Fertalj, K. ; Kalpi, D. Projektiranje informacijskih sustava / Fertalj, Kreimir ; Kalpi,Damir (ur.). Zagreb : FER, 2001. (folije s predavanja),http://www.zpm.fer.hr/courses/pis

[4] E. L. Appleton, How to Survive ERP, Datamation, 43, 3, 1997, pp. 50-53,http://www.datamation.com/entap/03erp.html, 1/7/2000.

[5] Applix Enterprise: Total Cost of Ownership Study for Enterprise Applications, whitepaper, Applix. Inc,http://www.applix.com

[6] B. Bae.; Paul Aschcroft. (2004) Implementation of ERP Systems:Accounting andAuditing Implications,

[7] Signe Ellegaard Borch: Business Process Models as Design Artefacts in ERPDevelopment

[8] Andy Klee, Klee Associates, Inc.: The ERP Life Cycle: From Birth to Death and BirthAgain

[9] IDS Scheer: Presentation: SAP R/3 Implementation,http://www.idsscheer.com/sixcms_upload/media/169/presentation_sap_r3_implementation_2

00203_en.pdf

[10] IDS Scheer: Presentation: Facts about ERP Implementations,http://www.idsscheer.com/sixcms_upload/media/169/presentation_facts_about_erp_impleme

ntations_200203_en.pdf

[11] IDS Scheer: Presentation: Model Based SAP R/3 Implementation,http://www.idsscheer.com/sixcms_upload/media/169/presentation_model_based_sap_r3_impl

ementation_200203_en.pdf

[14] Campbell, R.B. (2001) ERP: Show me the Money!, Axislogic Consulting Inc.,http://www.axislogic.com/erpstory.htm

[15]Niki Dekovi(2003): Procesni pristup u uvoenju SAP R/3 sustava - primjena ARISmetodologije

[16] M. Levinson: How Bad Software Pays Dividends, CIO Magazine, 15.10.2001
http://www.destinationcrm.com/articles/default.asp?ArticleID=6162http://www.destinationcrm.com/articles/default.asp?ArticleID=6162http://www.destinationcrm.com/articles/default.asp?ArticleID=6162http://en.wikipedia.org/wiki/2007http://en.wikipedia.org/wiki/2007http://en.wikipedia.org/wiki/March_29http://en.wikipedia.org/wiki/March_29http://en.wikipedia.org/wiki/March_29http://www.zpm.fer.hr/courses/pishttp://www.zpm.fer.hr/courses/pishttp://www.applix.com/http://www.applix.com/http://www.idsscheer.com/sixcms_upload/media/169/presentation_sap_r3_implementation_200203_en.pdfhttp://www.idsscheer.com/sixcms_upload/media/169/presentation_sap_r3_implementation_200203_en.pdfhttp://www.idsscheer.com/sixcms_upload/media/169/presentation_sap_r3_implementation_200203_en.pdfhttp://www.idsscheer.com/sixcms_upload/media/169/presentation_facts_about_erp_implementations_200203_en.pdfhttp://www.idsscheer.com/sixcms_upload/media/169/presentation_facts_about_erp_implementations_200203_en.pdfhttp://www.idsscheer.com/sixcms_upload/media/169/presentation_facts_about_erp_implementations_200203_en.pdfhttp://www.axislogic.com/erpstory.htmhttp://www.axislogic.com/erpstory.htmhttp://www.idsscheer.com/sixcms_upload/media/169/presentation_facts_about_erp_implementations_200203_en.pdfhttp://www.idsscheer.com/sixcms_upload/media/169/presentation_facts_about_erp_implementations_200203_en.pdfhttp://www.idsscheer.com/sixcms_upload/media/169/presentation_sap_r3_implementation_200203_en.pdfhttp://www.idsscheer.com/sixcms_upload/media/169/presentation_sap_r3_implementation_200203_en.pdfhttp://www.applix.com/http://www.zpm.fer.hr/courses/pishttp://en.wikipedia.org/wiki/March_29http://en.wikipedia.org/wiki/2007http://www.destinationcrm.com/articles/default.asp?ArticleID=6162


35/36

35

8. Dodatak

Ovdje je naveden dio dokumentacije kako to izgleda u PLIVI/Barr-u. U proizvodnim

organizacijama se dokumentacija zahtjeva radi raznih komisija i mora sadravati odreeneinformacije. Neke od vanih informacija su odgovorne osobe, datumi i verzije koje suzahtjevane od strane raznih kontrola vezane za samo poslovanje PLIVE/Barr-a.

Pri izradi dokumentacije poeljno je da se prate standardi dokumentiranja i dokumenata kojizadovoljavaju ISO standarde.

Primjeri dani ovdje nisu neto to je definirano sa strane ERP sustava ve do sameorganizacije. Ovdje su navedeni samo osnovni tipovi dokumentacije pot postoje mongidokumenti ovisni o vrstama promjena i njihovom opsegu. Naveden je primjer zahtjeva za

programamom tipa izvjetaj.

8.1 Primjer funkcionalne dokumentacije

Svaka promjena ili dodatni razvoj se dokumentira. Funkcionalni konzultant obrascem definira

zahtjev. Zahtjev dolazi do ABAP konzultanta koji prema zahtjevu kreira ili mjenja objekte.

Ovisno o sloenosti i znanju konzultanta modula zahtjev moe biti vie ili manje tehnikinapisan. U njemu treba biti navedeno to se trai i kako doido potrebnih podataka.

Primjer se moe vidjeti u prilogu. Ovisno o tome kako je pisana moe biti i tehnikadokumentacija.

Microsoft Word

Document

8.2 Primjer programa

ABAP je programski jezik koji se koristi SAP R/3 okruenju. Moe se pisati proceduralno iliobjektno. U prilogu se nalazi programski kod izvjetaja koji je opsian u gornjem zahtjevu.

Microsoft Word

Document

Izgled izvjetaja i rezultata, napisanog u gornjem prilogu, vidljiv je u donjem prilogu.

Microsoft Word

Document


36/36

8.3 Tehnika dokumentacija

Svaka promjena na sustavu se mora dokumentirati stoga svaki konzultant mora napisati

tehniku dokumentaciju u kojoj opisuje to je tonopromijenjeno na objektima i kako. Na tajnain se mogu pratiti promjenepo verzijama.

Svaka tehnika dokumentacija morala bi sadravati i unit testove kojima se potvrujeprevieno ponaanje promjene.To bi u pravilu trebali zahtjevatelji promjene (poslovna stranaorganizacije) testirati, i ako se slau s promjenom, i potpisom definirati da su unit testovidobri. Time je razvoj zavren i sve promjene vezne za taj zahtjev se mogu prenijeti na

produkciju.

Primjer jedne popunjene tehnike dokumentacije, vezane za ABAP konzultanata, prikazan jeu donjem prilogu. Svaku prilagodbu sustava funkcionalni i BC konzultant takoer moraevidentirati u pripadajuoj vrsti dokumentacije.

Microsoft Word

Document

erp ciklus

Documents