METODOLOGIJA IMPLEMENTACIJE SISTEMA E-BUSINESS SUITE

AIM metodologija (Application Implementation Methodology) Saga Infotech za impelentaciju informacionog sistema E-Business Suite primenjuje AIM (Application Implementation Methodology) metodologiju. Primenom ove specijalovane metodologije, Saga Infotech implementaciju ovog sloenog informacionog sistema izvodi efikasno i sa vrhunskim rezultatima. Kompanija Oracle je namenski razvila AIM metodologiju za implementaciju sistema E-Business Suite. Metodologija podrava implementaciju svih delova E-Business Suite-a: Enterprise Resource Planning (ERP), Customer Relationship Management (CRM). AIM podrava i sve aktivnosti projekta ukljuujui planiranje, definiciju zahteva, modelovanje poslovnih procesa, prilagoavanje, integraciju s drugim sistemima, konverziju podataka, projektovanje arhitekture aplikacije i tehnike arhitekture (ukljuujii mreu i servere), sistem izvetavanja, zatita i kontrola prava pristupa sistemu. AIM metodologija se sastoji iz precizno definisanih procesa kojima se moe upravljati na vie naina za vreme izvoenja projekta imlementacije. AIM obezbeuje alate potrebne za efikasno i efektivno planiranje, voenje i kontrolisanje aktivnosti projekta kako bi se uspeno implementirao novi poslovni informacioni sistem. AIM je skalabilna metodologija koja se moe primeniti kako na velike, multinacionalne projekte koji se odvijaju na vie lokacija, tako i na male projekte ogranienog obima. AIM je metodologija koja obezbeuje skalabilnost koju projekat zahteva. AIM omoguava brzu i efikasnu implementaciju poslovnih aplikacija. AIM definie osnovne i opcione zadatke to omoguava projektnom timu da se fokusira na zadatke i aktivnosti koje su najznaajniji za projekat implementacije. Na taj nain se eliminiu nepotrebne aktivnosti i zadaci iz projekta i smanjuje se vremenski period projekta implementacije. AIM metodologija reava brojne probleme sa kojima se organizacije trenutno suoavaju, kao to su:

neodgovarajui kontni plan - AIM obezbeuje instrukcije i usmerenja za jednostavno podeavanje novog kontnog plana,

str 2 od 11

korienje zastarelih tehnologila i procesa AIM odgovara na potrebu kompanije za prelazak na web zasnovane aplikacije, i obezbeuje smernice za implementaciju novih tehnologija,

prerastanje postojeeg informacionog sistema AIM obezbeuje smernice za brzu implementaciju novog sistema koji e se razvijati paralelno sa organizacijom,

zastareli poslovni procesi AIM omoguava restruktuiranje tekuih poslovnih procesa,

otpor prema promenama u organizacijama u kojima je ovo prva implemenatacija informacionog sistema korisnici mogu imati otpor i negativan stav prema novom sistemu. AIM vodi organizaciju kroz aktivnosti upravljanja promenama,

nemogunost prilagoavanja organizacionim promenama AIM omoguuje postavljanje nove organizacione strukture u sluajevima reorganizacije preduzea ili akvizicije.

Faze projekta implementacije prema AIM metodologiji Projekti implementacije sistema E-Business Suite prema metodologiji AIM podeljeni su u faze. Tokom svake faze projekta projektni tim paralelno obavlja aktivnosti vezane za razliite procese. Osnovne faze i najvanije aktivnosti po fazama projekta su sledee:

1) Faza definicije

Planiranje projekta Organizacija logistike projekta Definisanje procedura i standarda Obuka projektnog tima

2) Faza analize

Analiza poslovanja Definicija poslovnih zahteva Preslikavanje poslovnih zahteva Definicija tehnike arhitekture Definisanje strategije konverzije podataka Definisanje strategije testiranja

3) Faza dizajna

Instalacija tehnike osnovice i razvojne okoline Dizajniranje buduih poslovnih procesa Definisanje arhitekture sistema Definisanje strategije konverzije podataka Definisanje tranzicije Dizajn interfejsa Dizajn nadogradnji sistema Definisanje temeljnih parametara sistema Prezentacija i diskusija dizajna rjeenja Dokumentovanje konanog dizajna reenja

str 3 od 11

4) Faza izgradnje Postavljanje zajednikih parametara Setap modula (moduli se mogu postavljati paralelno) Definisanje sistemskih procedura Razvoj interfejsa (ukoliko su potrebni) Razvoj izvjetaja (FSG) Razvoj nadogradnji sistema Testiranje (Razvoj scenarija testiranja, Testiranje modula i testiranje sistema,

Testiranje interfejsa) Auriranje dokumentacije postavljanja sistema

5) Faza tranzicije i konverzije

Priprema korisnike dokumentacije Obuka korisnika Instalacija produkcione okoline Testiranje procedura konverzije Konverzija i test podataka u novi sistem

6) Faza produkcije

Zavrna faza implementacije Poetak rada s novim sistemom

slika 1. Faze i procesi AIM metodologije

Faza definicije Tokom faze definicije pravi se plan projekta, razmatraju se poslovni ciljevi i poslovni procesi organizacije. Neophodno je proceniti mogunost ostvarenja ciljeva projekta u predvienom vremenskom roku, sa raspoloivim resursima i u okviru predvienog budeta. U ovoj poetnoj fazi implementacije definie se obim projekta i ostvariv plan rada. Takoe se definiu strategije, ciljevi i nain rada za svaki AIM proces.

str 4 od 11

U ovoj fazi projekta projektni tim izrauje model procesa kako bi se ostvarilo rano razumevanje tekuih poslovnih operacija i buduih procesa. Cilj je da se identifikuju budui poslovni i sistemski zahtevi, da se predloi budui poslovni model i da se odredi arhitektura aplikacije i tehnika arhitektura. Projektni tim razmatra finansijske, operativne, tehnike i administrativne procese i vodi sastanke sa predstavnicima organizacije kako bi se potvrdilo da se svi uesnici projekta slau sa definicijom poslovnih zahteva. Svi poslovni zahtevi se povezuju sa buduim poslovnim procesima. Ukoliko je potrebno da doe do promene poslovnih procesa projektni tim kreira dizajn buduih poslovnih procesa sa malo detalja. Dizajn buduih poslovnih procesa koristi se da bi se ocenio nivo uklapanja buduih procesa organizacije i standardnih funkcionalnosti aplikacije. Utvruju se razlike i razvija se odgovarajue reenje koje e to premostiti. Ovaj dizajn poslovnih procesa razvija se u detaljniji model poslovnih procesa u fazi analize. U fazi definicije, izvrni menadment organizacije uestvuje na interaktivnim sastancima. U ovoj fazi projekta vri se organizacija i obuka projektnog tima. Kritini faktori uspeha faze definicije su:

podrka projektu od strane visokog rukovodstva firme na takav nain da je to vidljivo svim uesnicima projekta,

jasna definicija poslovnih ciljeva, aktivno uestvovanje menadmenta kompanije, korisnika koji dobro poznaju

poslovne procese i tehnikih predstavnika organizacionih jedinica koje uestvuju u projektu,

ostvariti pristup informacijama koje se odnose na tekue poslovne procese organizacije.

Faza analize U fazi analize projektni tim razvija Scenario poslovnih zahteva (RD.050 Business Requirements Scenarios) koji se zasniva na rezultatima proisteklim u fazi definicije. Cilj je da se proceni koliko standardne funkcionalnosti aplikacije odgovaraju na poslovne zahteve kompanije u koju se uvodi sistem E-Business Suite. Nakon utvrivanja nedostataka razvija se predlog novog reenja. Analiza rezultuje predlogom za voenje poslovnih operacija u kontekstu osmiljene tehnike arhitekture aplikacije. Predlog reenja za nedostajue funkcije razvija se u detaljan dizajn u narednoj fazi projekta. U ovoj fazi projekta kreira se model arhitekture aplikacije i razvija se model tehnike arhitekture. Tehnika arhitektura sadri osnovne odrednice implementacije mrea, potrebnih servera i softvera koji e podravati budui poslovni sistem. Dokumenti o arhitekturi aplikacije i tehnikoj arhitekturi se koriste za razvoj detaljnog dizajna u fazi dizajna, koja predstavlja sledeu fazu projekta. Da bi se razvio model buduih poslovnih procesa, neophodno je razmotriti prvobitne predloge reenja za nedostajue funkcije sistema. Moe se desiti da je potrebno nainiti

str 5 od 11

samo neznatne modifikacije na formama, izvetajima i programima. Pre nego to se donese odluka da se radi prilagoavanje aplikacije ili da se radi novi razvoj potrebno je razmotriti da li se postoji neko zaobilazno reenje kojim mogu da se prevaziu funkcionalni nedostaci aplikacije. Ukoliko postoji potreba za prilagoavanjem aplikacije, projektni tim izrauje dokument sa poetnim dizajnom potrebnih dorada sistema. Ovaj dokument sadri opti opis potrebnih funkcionalnosti i procenu potrebnog vremena za izradu dorada sistema. Pre nego to se krene u detaljan dizajn potrebnih dorada u fazi dizajna potrebno je da naruilac odobri potrebne dorade i procenjeno vreme za izradu dorada. U ovoj fazi projekta definie se strategija testiranja. Kreira se model za testiranje karakteristika performansi novog sistema. Ovi modeli testiranja se fokusiraju na kljune obrade u sistemu koje su vezane za glavne poslovne funkcije i transakcije. U ovoj fazi projekta na radnim sastancima je prisutan srednji nivo i najnii nivo menadmenta kompanije koji nisu lanovi projektnog tima, kako bi preuzeli svoju ulogu u projektu implementacije. Na kraju ove faze izrauje se strategija tranzicije preduzea sa starog na novi sistem (PM.010 Transition Strategy). Faza dizajna Cilj faze dizajna je da se razvije detaljan dizajn novog sistema koji e zadovoljavati budue poslovne zahteve organizacije. Tokom ove faze lanovi projektnog tima kreiraju detaljan dokument Dokumantacija poslovnih procesa (BP.090 Business Procedure Documentation). Zadovoljenje poslovnih zahteva moe da zahteva izradu nadogradnji standardnih funkcija sistema. Tokom faze analize definisano je nekoliko moguih reenja. Projektni tim paljivo razmatra ove mogunosti i vri odabih najekonominije alternative. Da bi se razvio efektivan poslovni sistem potrebno je da se proveri da su korisnike uloge i procedure rada efikasne. Kada se dizajnira nov sistem potrebno je razmotriti potrebu za organizacionim promenama, poboljanjem procesa i za reorganizacijom, do nivoa do kog te promene ulaze u obim projekta. Dok se dizajn novog sistema finalizira, arhitektura aplikacije i tehnika arhitektura poinju da dobijaju formu. Tehniko osoblje dizajnira tehniku arhitekturu koja podrava standardnu konfiguraciju aplikacije, i razmatra buduu arhitekturu sistema. Tehniko osoblje takoe projektuje programe za testiranje performansi i okruenje za izvrenje testiranja performansi. Ciljevi faze dizajna su sledei:

napraviti dizajn koji zadovoljava funkcionalne zahteve, dokumentovati dizajn sistema kako bi se olakalo budue odravanje sistema, definisanje setovanja sistema i plana testiranja, projektovanje sistema zatite,

str 6 od 11

razvoj funkcionalnog i tehnikog dizajna za nadogradnje sistema, interfejse, programe za konverziju i nadogradnje baze,

dizajn testnih skripti, skripte za testiranje transakcionih programa i skripte za testiranje programa koji pune bazu podataka,

analiziranje potreba za obukom korisnika i razvoj plana obuke korisnika (AP.140 User Learning Plan )

Faza izgradnje Tokom faze izgradnje vri se kodiranje i testiranje svih dorada sistema ukljuujui nadogradnje, konverziju podataka i interfejse. Testiranje aplikacije se vri da bi se proverilo da li funkcionalnost sistema zadovoljava poslovne zahteve. Faza izgradnje je jako bitna faza projekta ak i u sluajevima kada nema potrebe za izradom dorada, nadogradnjom i konverzijom podataka. U fazi izgradnje vri se testiranje poslovnog sistema koje se obino sprovodi u vidu pilot testa (Conference room pilot CRP). Testiranjem poslovnog sistema se proverava konfiguracija novog sistema, a obavlja se u okruenju koje je slino okruenju produkcije. Paralelno sa izradom dorada i nadogradnji sistema izrauje se dokumentacija kojom se opisuju te izmene. Kako se sistem poboljava i dokumentacija se ponovo preispituje i dorauje. Programeri razvijaju programe koji se testiraju lokalno. Nakon lokalnog testiranja vri se integralno testiranje povezanih programa. Vri se testiranje sistema i testiranje integracije sistema sa drugim aplikacijama (ukoliko postoji integracija). Kao rezultat faze izgradnje dobija se iztestiran poslovni sistem. Tokom faze izgradnje, tim odgovoran za testiranje performansi sistema kreira komponente za testiranje performansi i vri testiranje. U ovoj fazi projekta kreiraju se materijali za obuku korisnika i setuje se okruenje za obuku. Na kraju faze izgradne pravi se Plan tranzicije i plan za nepredviene situacije (Transition and Contingency Plan PM.030). Kritini faktori uspeha faze izgradnje su:

precizna i kompletna dokumentacija o dizajnu sistema, dizajn i testiranje platforme, mree i drugih tehnikih faktora, odgovarajue angaovanje izabranih isporuioca hardvera u konfiguraciji

hardverskog okruenja sistema, testirani programi za konverziju podataka, rezultati testiranja performansi koji zadovoljavaju oekivanja, korisnici snabdeveni materijalima za obuku, jasno razumevanje ciljeva projekta, efektivno uee izvrnog menadmenta firme i korisnika, ispunje vremenskih rokova, efektvino upravljanje projektom, produktivan projektni tima iji lanovi poseduju odgovarajua znanja i vetine.

str 7 od 11

Faza tranzicije i konverzije Tokom faze tranzicije i konverzije projektni tim uvodi novi sistem u organizaciju. Projektni tim vri obuku korisnika dok tehniki tim vri konfiguraciju produkcionog okruenja i vri konverziju podataka. U fazi tranzicije i konverzije korisnici vre prijemno ispitivanje novog sistema. Faza tranzicije je veoma zahtevna kako za projektni tim tako i za korisnike koji moraju da odravaju dva sistema paralelno dok se zvanino ne pone sa radom u novom sistemu. Upravljanje promenama i odbrana organizacije od negativnih uticaja predstavljaju najvie prioritete u ovoj fazi projekta. Pripreme i planiranje prethode procesu tranzicije na novi sistem. Tranzicija je gotova u trenutku kada se zvanino pree na korienje novog sistema i kada korisnici ponu da izvravaju svoje poslovne aktivnosti koristei novi sistem. U sluaju fazne implementacije, faza tranzicije se sastoji iz nekoliko implementacija koje se mogu odvijati na razliitim geografskim lokacijama u razliitim vremenskim periodima. Faza produkcije Ova faza oznaava poslednju fazu projekta implementacije i poetak ciklusa odravanja sistema. U ovoj finalnoj fazi obavljaja se niz aktivnosti poboljavanja sistema i aktivnosti merenja performansi sistema. Kadrovi odeljenja informacionih tehnologija rade na tome da stabilizuju sistem kako bi poele aktivnosti redovnog odravanja. Oni e pruati potrebnu podrku i obavljati aktivnosti odravanja sistema u buduem periodu. Tokom faze produkcije uporeuju se stvarni rezultati sa ciljevima projekta, i razmatra se da li je potrebno napraviti odreena poboljanja. Na kraju projekta implementacije novog sistema kompanija poinje da planira svoj budui poslovni i tehniki razvoj. Ciljevi faze produkcije su:

pruiti odgovarajuu korisniku podrku, merenje performansi sistema i izvriti poboljanja ukoliko je potrebno, odravanje produkcionog sistema, prestanak korienja starog sistema, predlog i plan budueg poslovnoh i tehnikog usmerenja i napretka kompanije, poboljanje efektivnosti organizacije kroz kontinualnu primenu programa za

poboljanje, posvetiti panju vanim pitanjima vezanim za period nakon implementacije.

str 8 od 11

Procesi projekta implementacije sistema E-Business Suite Zadaci koji se obavljaju u okviru projekta implementacije po AIM metodologiji grupisani su u procese. Svaki proces karakterie skup povezanih ciljeva, zahtev za odgovarajuim strunim znanjima i vetinama, potrebni ulazni elementi i zahtevani rezultati. Zadatak moe da se vee samo za odreeni proces. lanovi projektnog tima obavljaju procese za koje su specijalizovani i za koje imaju odgovarajua znanja i iskustvo. AIM metodologija definie 11 procesa:

1) Arhitektura poslovnih procesa

Arhitektura poslovnih procesa ima za cilj da sagleda poslovne procese organizacije i da utvrdi poslovne zahteve koje poredi sa aplikacijom koja se implementira. Utvruje se koji su sve podaci potrebni na osnovu kojih se moe oceniti kako se trenutno izvravaju poslovni procesi. Ukoliko projekat obuhvata promenu poslovnih procesa organizacije, ovim procesom se utvruju potrebne izmene i dizajniraju se novi ili izmenjeni poslovni procesi. Dizajn izmenjenih poslovnih procesa poredi se sa funkcionalnostima aplikacije, i utvruje se koje e izmene aplikacije biti potrebne. Arhitektura poslovnih procesa rezultira optimalnim dizajnom poslovnih procesa koji balansira izmeu potrebnih izmena aplikacije i potrebnih izmena procesa organizacije.

2) Definicija poslovnih zahteva

Definicijom poslovnih zahteva definiu se potrebe organizacije koje je potrebno ispuniti implementacijom novog poslovnog sistema. Projektni tim analizira i dokumentuje tekue poslovne zahteve, zatim konstruie budue poslovne procese i modele kako bi prikazao i budue poslovne zahteve.

3) Mapiranje poslovnih zahteva

Mapiranje poslovnih zahteva je proces kojim se uporeuju budui poslovni zahtevi sa standardnom funkcionalnou aplikacije. Na osnovu poreenja utvruju se funkcionalni nedostaci aplikacije koji se moraju reiti kako bi se u potpunosti ispunili poslovni zahtevi organizacije. Neke od metoda za premoavanje razlika izmeu zahteva organizacije i funkcionalnosti aplikacije su:

iznalaenje zaobilaznih reenja, nadogradnja aplikacije, novi razvoj, promena poslovnih procesa organizacije.

str 9 od 11

Nakon to su poslovni procesi i zahtevi uporeeni sa funkcionalnostima aplikacije, i nakon iznalaenja reenja za prevazilaenje nedostataka aplikacije, projektni tim dokumentuje kako e organizacija funkcionisati koristei novi sistem.

4) Arhitektura aplikacije i tehnika arhitektura

Tokom ovog procesa dizajnira se arhitektura informacionog sistema koja reflektuje poslovnu viziju organizacije. Dosledna i dobro dizajnirana arhitektura informacionog sistema predstavlja kritian faktor uspeha svakog projekta implementacije. Proces arhitekture aplikacije i tehnike arhitekture poinje u najranijoj fazi projekta implementacije. Iako se ovaj proces odvija samo tokom faza definicije, analize, dizajna i izgradnje, rezultati ovog procesa su potrebni i koriste se tokom celog projekta implementacije. Dizajn i arhitektura aplikacije i tehnike arhitekture postaje detaljniji i konkretniji kako projekat napreduje iz faze definicije u fazu analize, dizajna i izgradnje.

5) Dizajn i izgradnja

U procesu dizajna i izgradnje prave se nadogradnje i dorade aplikacije kojima se prevazilaze funkcionalni nedostaci aplikacije uoeni u procesu mapiranja poslovnih zahteva. Nadogradnje sistema sastoje se iz programskih modula (formi, izvetaja, trigera i slino) koje je potrebno dizajnirati, iskodirati i testirati pre nego to se prikljue novom sistemu. Tehniki i poslovni analitiari definiu potrebne nadogradnje sistema i procenjuju vreme potrebno za njihov dizajn, izradu i testiranje. Nakon toga izrauju detaljnu funkcionalnu i tehniku specifikaciju potrebnih nadogradnji. Na osnovu dokumenata sa detalnim dizajnom nadogradnji sistema programeri kodiraju nove forme i izvetaje ili modifikuju postojee.

6) Konverzija podataka

U procesu konverzije podataka definiu se zadaci i rezultati koji su potrebni kako bi se podaci iz prethodnog sistema konvertovali u tabele Orakl aplikacije. Konvertovani podaci se mogu koristiti za testiranje sistema, obuku i za kasniju fazu produkcije. Potrebno je definisati strategiju kojom se predvia kako e se zahtevi za konverzijom podataka ispuniti. Potrebno je razmotriti i automatski i runi metod konverzije podataka kao mogue opcije. AIM obezbeuje podrku za oba metoda konverzije podataka. Proces konverzije ukljuuje dizajn, programiranje i testiranje programa za konverziju, kao i sam proces konverzije podataka iz prethodnog sistema.

7) Dokumentacija

Koliina i detaljnost dokumentacije zavise od projekta. Kompleksnost implementacije i zahtevi za dokumentacijom su direktno zavisni. AIM metodologija daje ablone za dokumente koji bi trebalo da se kreiraju kao rezultat odreenih faza projekta implementacije.

str 10 od 11

8) Testiranje poslovnog sistema

Testiranje poslovnog sistema fokusira se na povezivanje zahteva za testiranjem sa poslovnim zahtevima, i na obezbeivanje potrebnih resursa za testiranje. Testiranje poslovnog sistema bazira se na formalnom integrisanom pristupu testiranju, iji je osnovni rezultat aplikacija visokog kvaliteta.

9) Testiranje performansi

Proces testiranja performansi sastoji se iz aktivnosti definisanja, izgradnje i izvravanja testa performansi. Obim testa performansi moe biti razliit. Moe se definisati kompleksan test koji e se sprovesti na celom sistemu ili se moe definisati jednostavniji test na odreenom delu sistema. Tetsiranje se moe sprovesti vie puta tokom projekta u razliitom obimu i sa razliitim ciljevima, kako bi se testirali razliiti aspekti performansi sistema. Ovaj proces predstavlja kvalitetan i direktan nain da se oceni kvalitet performansi sistema. Na osnovu ove ocene sistema moe se zakljuiti da li su performanse sistema prihvatljive i da li zadovoljavaju potreba organizacije. Ukoliko karakteristike performansi nisu zadovoljavajue pravi se predlog potrebnih promena arhitekture sistema kako bi se ostvarila eljena poboljanja. Testiranje performansi je blisko povezano sa arhitekturom aplikacije i tehnikom arhitekturom.

10) Usvajanje i obuka Proces usvajanja i obuke ubrzava i podstie kvalitet timskog rada projektnog tima. U okviru ovog procesa formiraju se materijali za obuku i kreira se okruenje za obuku. lanovi projektnog tima organizuju za korisnike novog sistema raznovrsne aktivnsoti obuke.

11) Migracija produkcije

Procesom migracije na produkciju kompanija poinje da koristi novi poslovni informacioni sistem. Nakon prelaska sistema u fazu produkcije vri se praenje i unapreivanje sistema. Proces migracije na produkciju obuhvata prelazak sistema iz faze tranzicije u produkcionu i post-produkcionu fazu sistema u kojoj sistema prelazi u reim redovnog odravanja. Tokom ovog procesa projektni tim uvodi novi sistem u organizaciju. Proces migracije na produkciju zavisi od uspeha prethodnih proseca mapiranja poslovnih zahteva, dizajna i izgradnje, konverzije podataka, izrade dokumentacije, testiranja poslovnog sistema i usvajanja i obuke. Migracija na produkciju je gotova kada su podaci konvertovani i verifikovani i kada korisnici ponu da koriste novi sistem. Redovno odravanje sistema poinje kada se sistem stabilizuje.

str 11 od 11

Osnovni i opcioni zadaci AIM metodologije Projekti implementacije E-Business Suite aplikacije se razlikuju od jednostavnih do veoma kompleksnih projekata. Nain na koji AIM metodologija prevazilazi razlike u sloenosti implementacija je definisanje osnovnih i opcionih zadataka. Osnovni zadaci odreuju minimalan skup aktivnosti potrebnih za implementaciju Orakl aplikacije. U zavisnosti od specifinih okolnosti projekta moe biti potrebno da se ukljui odreeni broj opcionih zadataka. Na primer, ako je za u okviru projekta implemenatcije potrebno napraviti interfejse ka nekoj spoljnoj aplikaciji, mogu se ukljuiti odreeni opcioni zadaci za ispitivanje, auriranje i testiranje tih interfejsa. Preporuljivo je da se tokom planiranja projekta pregledaju svi osnovni zadaci i da se proceni da li e njihovo izvrenje biti dovoljno da se odgovori na zahteve organizacije. Odreivanje koji e se AIM zadaci ukljuiti u plan projekta je odgovornost rukovodioca projekta. Da bi se olakao proces izbora opcionih zadataka, AIM metododlogijom definisano je vie kriterijuma za izbor opcionih zadataka koji slue kao indikatori za prikljuivanje odreenog opcionog zadatka