UNIVERZITET U BEOGRADU FAKULTET ORGANIZACIONIH NAUKA ZAVRŠNI (MASTER) RAD Tema: Upravljanje projektima u elektronskom poslovanju MENTOR STUDENT Doc. dr Zorica Bogdanović Jovana Dadić 3503/2012 Beograd Novembar, 2013.
UNIVERZITET U BEOGRADU
FAKULTET ORGANIZACIONIH NAUKA
ZAVRŠNI (MASTER) RAD
Tema: Upravljanje projektima u elektronskom poslovanju
MENTOR STUDENT
Doc. dr Zorica Bogdanović Jovana Dadić 3503/2012
Beograd
Novembar, 2013.
2
Komisija koja je pregledala rad
kandidata DADIĆ (VOJISLAV) JOVANE
pod naslovom UPRAVLJANJE PROJEKTIMA U ELEKTRONSKOM POSLOVANJU i
odobrila odbranu:
Mentor: dr ZORICA BOGDANOVIĆ, docent
_______________________________________
Član: dr MARIJANA DESPOTOVIĆ ZRAKIĆ, vanredni profesor
_________________________________________________________
Član: dr MARKO MIHIĆ, docent
_________________________________________________________
3
Apstrakt
Pojava Interneta je redefinisala način na koji poslovanje funkcioniše širom sveta.
Upotreba Interneta u svim slojevima poslovanja uzorkovala je pojavu koncepta koji je
danas poznat pod imenom elektronsko poslovanje. Imajući u vidu da u razvijenim
delovima sveta danas većina kompanija koristi Internet za realizaciju jednog ili više
poslovnih procesa, može se smatrati da je elektronsko poslovanje dominantan oblik
poslovanja.
Obzirom na vrlo dinamično okruženje u kome se elektronsko poslovanje sprovodi,
realizacija inicijativa elektronskog poslovanja se sve češće sprovodi kroz projekte
elektronskog poslovanja.
Cilj ovog rada jeste analiza specifičnosti upravljanja projektima elektronskog poslovanja.
Predmet ovog rada predstavlja primenu discipline upravljanja projektima u elektronskom
poslovanju.
U radu će biti dat pregled oblasti upravljanje projektima pri čemu će posebna pažnja biti
posvećena specifičnostima projekata elektronskog poslovanja kroz sve faze upravljanja
projektima. Na osnovu izvršene analize, biće date preporuke za upravljanje projektima
elektronskog poslovanja, i biće istaknute dobre prakse i relevantni standardi. Zaključni
deo rada predstavlja studijski primer upravljanja projektom u oblasti kartičarskog
poslovanja.
Abstract
The emerging Internet technologies have redefined the way business works all around
the globe. Using Internet on all levels of business processes caused the emergence of
the e-business concept. Having in mind that most of the companies in the developed
world use the Internet for conducting one or more business processes, e-business can
be considered as the dominant business model of today.
Taking into consideration the highly dynamic environment for conducting e-business,
companies are turning their focus on managing e-business initiatives as projects.
The purpose of this paper is to analyze the peculiar aspects of managing e-business
projects. The topic of this paper is the application of project management in e-business.
4
The paper will provide an overview of project management topics, while noting the
specific attributes of e-business projects in all the phases of project management. Based
upon the performed analysis, recommendations, good practices and relevant standards
for managing e-business projects will be defined. The final part of the paper will be a
case study, representing an example of payment cards e-business project managment.
5
Sadržaj
1 Uvod ........................................................................................................................... 9
2 Upravljanje projektima u elektronskom poslovanju ............................................ 10
2.1 Uvod u upravljanje projektima ............................................................................. 10
2.1.1 Definicije upravljanja projektima ................................................................... 11
2.1.2 Metodologije za upravljanje projektima ......................................................... 12
2.2 Organizacija projekta .......................................................................................... 13
2.2.1 Učesnici projekta........................................................................................... 13
2.2.2 Životni ciklus projekta .................................................................................... 17
2.2.3 Faze upravljanja projektima .......................................................................... 18
2.2.4 Upravljanje različitim dimenzijama projekta .................................................. 19
2.3 Specifičnosti projekata elektronskog poslovanja ................................................. 20
2.3.1 Tipovi razvoja softverskih proizvoda ............................................................. 21
2.3.2 Inicijacija projekata elektronskog poslovanja ................................................ 23
2.3.3 Planiranje projekata elektronskog poslovanja ............................................... 30
2.3.4 Izvršenje projekata elektronskog poslovanja ................................................ 32
2.3.5 Kontrola projekata elektronskog poslovanja ................................................. 42
2.3.6 Zatvaranje projekata elektronskog poslovanja .............................................. 45
3 Preporuke za upravljanje projektima u elektronskom poslovanju ..................... 47
3.1 Preporuke za iniciranje projekata elektronskog poslovanja ................................. 47
3.1.1 Kreiranje business case-a za iniciranje projekta elektronskog poslovanja .... 47
3.1.2 Preporuke za formiranje cost benefit analize kao deo business case-a ....... 50
3.2 Preporuke za planiranje projekata elektronskog poslovanja ............................... 51
6
3.2.1 Vremenski plan ............................................................................................. 52
3.2.2 Plan troškova ................................................................................................ 52
3.2.3 Plan upravljanja rizicima ............................................................................... 53
3.2.4 Plan upravljanja zainteresovanim stranama ................................................. 55
3.3 Preporuke za izvršavanje projekata elektronskog poslovanja ............................. 58
3.3.1 Testiranje softvera ........................................................................................ 58
3.4 Preporuke za kontrolu projekata elektronskog poslovanja .................................. 59
3.4.1 Formiranje KPI sistema za praćenje performansi na projektu ....................... 60
3.4.2 Kontrola obuhvata projekta elektronskog poslovanja .................................... 65
3.4.3 Osiguranje kvaliteta softvera ......................................................................... 65
3.5 Preporuke za zatvaranje projekata elektronskog poslovanja .............................. 66
3.5.1 Validacija i analiza postavljenih projektnih ciljeva ......................................... 68
4 Studijski primer - upravljanje projektom u oblasti kartičarskog poslovanja ..... 69
4.1 Uvod u kartičarsko poslovanje ............................................................................ 69
4.2 Studijski primer - implementacija novog proizvoda - Gift kartica ......................... 73
4.2.1 Inicijacija projekta.......................................................................................... 73
4.2.2 Planiranje projekta ........................................................................................ 76
4.2.3 Izvršavanje projekta ...................................................................................... 80
4.2.4 Kontrola projekta ........................................................................................... 82
4.2.5 Zatvaranje projekta ....................................................................................... 83
5 Zaključak ................................................................................................................. 84
6 Literatura ................................................................................................................. 85
7
Lista slika i tabela
Slika 1 - Proces identifikacije i upravljanja zainteresovanim grupama
Slika 2 - Najčešće zainteresovane grupe i njihov odnos sa projektom
Slika 3 - Tradicionalni model životnog ciklusa projekta
Slika 4 - Iterativni model životnog ciklusa projekta
Slika 5 - Procesi upravljanja projektom prema PMI
Slika 6 - Trougao upravljanja projektima
Slika 7 - Analiza obuhvata funkcionalnosti inicijativa elektronskog poslovanja
Slika 8 - Analiza investiranja u projekte u odnosu na NPV i diskontnu stopu
Slika 9 - Proces kreiranja koda
Slika 10 - Tipovi testiranja prema fazama sprovođenja softverskog projekta
Slika 11 - Proces kontrole projekta
Slika 12 - Grupe argumenata na kojima se može zasnivati business case inicijative
Slika 13 - Uticaj kompleksnosti projekta na rizičnost projekta
Slika 14 - Matrica strategija za upravljanje zainteresovanim stranama na projektu
Slika 15 - Opravdanost automatizovanog testiranja
Slika 17 - Analiza ostvarenja ciljeva za pojedinačne delove projekta
Slika 17 - Analiza ostvarenja ciljeva za pojedinačne delove projekta iz projektnog
portfolija
Slika 18 - Procesi u kartičarskom poslovanju
Slika 19 - Vremenski plan projekta u MS Project-u
Slika 20 - Specifikacija projektnih aktivnosti iz MS Project-a
Tabela 1 - Šablon za identifikaciju bitnih elemenata business case analize
Tabela 2 - Šablon registra rizika
Tabela 3 - Preporuke za upravljanje različitim grupama zainteresovanih strana
8
Tabela 4 - KPI koji se najčešće koriste na projektima elektronskog poslovanja
Tabela 5 - Šablon za specifikaciju očekivanih izlaznih rezultata projekta
Tabela 6 - Elementi koji su deo business case analize
Tabela 7 - Cost benefit analiza
Tabela 8 - Registar rizika za projekat implementacije gift kartica
Tabela 9 - Identifikacija zainteresovanih strana za projekat implementacije gift kartica
Tabela 10 - Specifikacija KPI sa definisanim zonama rizičnosti
Tabela 11 - Očekivani izlazi iz projekta implementacije gift kartice
9
1 Uvod
U prethodnim decenijama, pojava Interneta je redefinisala način na koji poslovanje
funkcioniše širom sveta. Upotreba Interneta u svim slojevima poslovanja uzorkovala je
pojavu koncepta koji je danas poznat pod imenom elektronsko poslovanje. Imajući u
vidu da u razvijenim delovima sveta danas većina kompanija koristi Internet za
realizaciju jednog ili više poslovnih procesa, može se smatrati da je elektronsko
poslovanje dominantan oblika poslovanja.
Cilj ovog rada jeste analiza specifičnosti upravljanja projektima u elektronskom
poslovanju.
Predmet ovog rada predstavlja primenu discipline upravljanja projektima u elektronskom
poslovanju.
U drugom poglavlju dat je pregled oblasti upravljanje projektima i definisane su
specifičnosti projekata u elektronskom poslovanju.
Na osnovu prethodno izvršene analize, u trećem poglavlju date su preporuke za
upravljanje projektima u elektronskom poslovanju.
Četvrto poglavlje prikazuje studijski primer upravljanja projektom u oblasti kartičarskog
poslovanja.
10
2 Upravljanje projektima u elektronskom poslovanju
2.1 Uvod u upravljanje projektima
Savremene kompanije, kao i državne i neprofitne organizacije, su prepoznale značaj
fleksibilnog i responzivnog poslovanja, te se projektno poslovanje sve češće javlja kao
dominantan oblik sprovođenja aktivnosti u okviru organizacije. Upravljanje projektima u
savremenim organizacijama podrazumeva veliki broj aktivnosti, uključujući planiranje,
koordinaciju i kontrolu kompleksnih i raznovrsnih aktivnosti iz različitih oblasti
poslovanja: prodaje, marketinga, IT-a itd. Orijentisanost na projekte se u praksi za veliki
broj organizacija pokazala izuzetno korisno, te danas najveći broj savremenih
organizacija teži da projektno organizuje sve aktivnosti koje imaju karakteristike projekta.
U najširem smislu, upravljanje projektima predstavlja usmeravanje ljudi na zajednički cilj
koji je potrebno ostvariti na sistematičan način, i kao takvo, postoji još od drevnih
civilizacija. Za neke od velikih projekata iz drevne istorije, poput izgradnje piramida u
Gizi, Kineskog zida ili Transkontinentalne pruge, danas znamo da su upravljani po
principima upravljanja projektima. Kako bi se ovi projekti realizovali bilo je potrebno
organizovati jako veliki broj ljudi na sistematičan način, i sa resursima na raspolaganju
postići ciljni kvalitet.
Za nastanak upravljanja projektima u obliku u kojem ga poznajemo danas, vrlo je
značajna pojava dva najpoznatija alata projektnog menadžmenta: CPM - Metoda
kritičnog puta (Critical path method) i PERT - Tehnika evaluacije projekta (Project
Evaluation Review Technique). Ovi alati su se pojavili pedesetih godina prošlog veka, a
koristili su se prvobitno u složenim vojnim i državnim projektima velikog obima. Danas
se ovi alati koriste u svim vrstama projekata, i pogodni su za korišćenje u svim
projektima koji imaju međuzavisne aktivnosti. Od 1960-ih godina oblast upravljanja
projektima je počela intenzivno da se razvija i modernizuje. Veliku ulogu u razvoju
oblasti upravljanja projektima igraju i profesionalne organizacije, među kojima su
najznačajnije PMI - Institut za projektni menadžment (Project Management Institute) i
IPMA - Internacionalna asocijacija projektnih menadžera (International Project
Management Association).
11
Projektna orijentacija kompanije u sprovođenju poslovnih inicijativa ima brojne benefite,
koji su danas već opšte poznati. Mnoga istraživanja su pokazala da je veliki broj
uspešnih kompanija prepoznao značaj projektne orijentacije, te efikasno upravljanje
projektima smatra svojim prioritetom. Oko 60% vodećih rukovodilaca smatra da bi jaka
disciplina upravljanja projektima trebalo biti među tri najvažnija strateška prioriteta za
njihovu kompaniju u budućnosti (McKinsey&Company, 2010).
Imajući u vidu kako lokalne, tako i globalne tržišne trendove, dominantna orijentacija u
upravljanju projektima postaje ostvarenje efikasnosti i umanjenje rizika na projektu.
Prema globalnom istraživanju Instituta za upravljanje projektima, rizik od finansijskog
gubitka na projektima u 2013. iznosi 13.5%, tj na milijardu dolara, organizacije rizikuju
gubitak od 135 miliona dolara (Project Management Institute, 2013). Rezultat ovog rada
bi trebalo da doprinese uspostavljanju kvalitenije prakse upravljanja projektima
elektronskog poslovanja, a sve u cilju minimizacije rizika sprovođenja projekta i
uspostavljanja kontrolabilnih procesa upravljanja projektima.
2.1.1 Definicije upravljanja projektima
U literaturi se pojavljuje veći broj definicija projekta. Prema Tumanu, projekat predstavlja
organizovanje ljudi usmereno na specifičan cilj, koje uglavnom podrazumeva poduhvate
koje je potrebno preduzeti u određenom roku, sa određenim budžetom i isporučiti
očekivani nivo kvaliteta (Tuman, 1983). Turner projekat definiše kao poduhvat u kome
se ljudski, finansijski i materijalni resursi organizuju kako bi obuhvatili jedinstvenu celinu
posla sa definisanom specifikacijom, u okviru ograničenja vezanih za vreme i troškove, a
sa ciljem stvaranja pozitvne promene definisane kvantitativnim i kvalitativnim ciljevima
(Turner, 1999). U jednom od najšire prihvaćenih vodiča za upravljanje projektima, A
Guide to Project Management Body of Knowledge, projekat se definiše kao privremeni
poduhvat čiji je cilj da stvori jedinstveni proizvod ili uslugu. U navedenoj definiciji,
izdvajaju se dve ključne tačke: privremenost, koja govori da je projekat aktivnost koja
mora imati definisan početak i kraj, i jedinstvenost rezultata projekta (Project
Management Institute, 2013).
Na osnovu pregleda literature iz oblasti upravljanja projektima, Diallo i Thuillier definisali
su skup ključnih dimenzija koje se javljaju u definicijama projekta (Diallo & Thuillier,
2003):
12
Tri tradicionalna ograničenja projekta: vreme, troškovi, obuhvat (eng. scope)
Zadovoljstvo klijenata
Zadovoljenje postavljenih ciljeva
Uticaj projekta
Institucionalni ili organizacioni kapacitet ugrađen u organizaciju projekta
Finansijski povraćaj
Inovativni izlazi iz projekta
Koncept upravljanja projektima je takođe sagledan sa aspekta različitih autora. Kerzner
definiše upravljanje projektima kao planiranje, organizovanje, usmeravanje i
kontrolisanje kompanijskih resursa za relativno kratkoročnu svrhu koji je definisana radi
ispunjenja konkretnih ciljeva (Kerzner, 2009). Prema PMI, upravljanje projektima
predstavlja primenu znanja, veština, alata i tehnika na projektne aktivnosti, kako bi se
ispunili zahtevi projekta (Project Management Institute, 2013).
2.1.2 Metodologije za upravljanje projektima
Metodologije za upravljanje projektima predstavljaju skup procesa, metoda i alata za
postizanje određenog cilja u upravljanju projektom. Metodologije najčešće daju
kontrolnu listu ključnih deliverabli i aktivnosti na koje treba obratiti pažnju kako bi se
izbeglo ispuštanje bitnih delova u upravljanju projektom (KLR). Ukoliko se u upravljanju
projektom koristi određena metodologija, neophodno je da svi učesnici na projektu budu
upoznati sa istom i da razumeju propisani okvir za realizaciju. Projektni timovi koji
koriste neku od metodologija za upravljanje projektom su značajno efikasniji i sve
aktivnosti na projektu sprovode uz veći nivo konzistencije, a manji nivo rizika. U
savremenom upravljanju projektima izdvajaju se dve opšte prihvaćene metodologije:
PMBoK (The Project Management Body of Knowledge) i PRINCE2.
Prvu verziju Project Management Body of Knowledge metodologije objavio je 1996.
godine Institut za Projektni Menadžment. PMBoK predstavlja najšire prihvaćenu
metodologiju za upravljanje projektima, pre svega u Severnoj Americi. PMBoK uključuje
znanja o dokazanim tradicionalnim praksama koji se široko koriste u upravljanju
projektima, kao i znanja o inovativnim i naprednim metodama. Prema PMBoK projekti se
sastoje od procesa, pri čemu je proces definisan kao niz akcija koje donose rezultat.
13
PMBoK opisuje 47 procesa projektnog menadžmenta koji su grupisani u 5 grupa
procesa, i to (Project Management Institute, 2013):
1. Procesi inicijacije
2. Procesi planiranja
3. Procesi izvršenja
4. Procesi kontrole
5. Procesi zatvaranja
PRINCE2 je metodologija za upravljanje projektima, inicijalno razvijena 1989. godine za
vladu Velike Britanije. PRINCE2 se najviše koristi u Evropi, a pre svega u razvoju
softverskih projekata. Prema PRINCE2, postoji 7 tipova procesa i to (Murray, 2011):
1. Pokretanje projekta (SU - Starting Up a Project)
2. Inicijacija projekta (IP - Initiating a Project)
3. Upravljanje projektom (DP - Directing a Project)
4. Kontrola projektne faze (CS - Controlling a Stage)
5. Upravljanje isporukom projekta (MP - Managing Product delivery)
6. Upravljanje opsegom faze projekta (MB - Managing a Stage Boundary)
7. Zatvaranje projekta (CP - Closing a Project)
Osim navedene dve metodologije, veliki broj konsultantskih kuća i organizacija koje se
profesionalno bave upravljanjem projektima poseduju svoje interno razvijene projektne
metodologije.
2.2 Organizacija projekta
2.2.1 Učesnici projekta
Učesnici projekta mogu biti neposredno ili posredno zainteresovane strane na projektu,
ili direktni učesnici u projektu, tj projektni tim. Učesnici na projektu mogu imati različite
nivoe uticaja na projekat, kao i različite interese za sam projekat.
2.2.1.1 Zainteresovane grupe na projektu
Identifikovanje svih zainteresovanih grupa predstavlja jednu od ključnih aktivnosti koje je
potrebno sprovesti u fazi iniciranja projekta, kako bi se na ispravan način upravljalo
zainteresovanim grupama, a u cilju uspešne realizacije projekta. Tok procesa
upravljanja zainteresovanim grupama prikazan je na Slici 1. Ulaz u proces upravljanja
14
zainteresovanim grupama na projektu predstavljaju dokumenta na osnovu kojih je
moguće utvrditi koji pojedinci, grupe i organizacije imaju interesa i/ili uticaja na projekat, i
to su najčešće sledeća dokumenta:
Projektna povelja
Dokumentacija vezana za proces nabavke
Dokumentacija koja opisuje korporativno okruženje
Dokumentacija procesa
Koristeći tehnike i alate koji su na raspolaganju projektnim menadžerima, menadžment
projekta kreira Registar zainteresovanih grupa i definiše strategiju za upravljanje
zainteresovanim grupama.
Slika 1 - Proces identifikacije i upravljanja zainteresovanim grupama
Zainteresovane grupe na projektu najčešče su sledeće (Slika 2):
Grupe koje direktno utiču na razvoj projekta
o Projektni sponzor
o Projektni tim: projektni menadžer, tim za upravljanje projektom, drugi
članovi projektnog tima
Grupe koje manje utiču na projekat, a koje imaju interesa za projekat:
o Kupci i/ili korisnici projekta
o Vendori i poslovni partneri
o Funkcionalni rukovodioci
o Kancelarija za upravljanje projektima
o Menadžer programa
o Druge grupe
15
Slika 2 - Najčešće zainteresovane grupe i njihov odnos sa projektom
2.2.1.2 Projektni tim
Projektni tim uključuje projektnog menadžera i grupu ljudi koji zajednički deluju i
izvršavaju aktivnosti na projektu, a sve u cilju dostizanja ciljeva projekta. Projektni timovi
se najčešće sastoje od ljudi u različitim ulogama, kao što su (Project Management
Institute, 2013):
Projektni menadžeri - Predstavljaju članove time koji rade na aktivnostima
upravljanja projektom, kao što su planiranje, budžetiranje, izveštavanje, kontrola,
komunikacije, upravljanje rizikom i administrativna podrška. Ova uloga je u nekim
organizacijama vezana za kancelariju za upravljanje projektima - PMO (Project
Management Office)
Projektno osoblje - Predstavljaju članove tima koji izvršavaju projektni posao u
cilju stvaranja projektnih deliverabli.
Domenski eksperti - Predstavljaju članove tima koji su zaduženi za izvršavanje
određenih aktivnosti iz projektnog plana, a najčešće se bave ugovaranjem,
nabavkom, finansijskim menadžmentom, logistikom, sigurnošću, testiranje,
16
kontrolom kvaliteta ili slično. Po potrebi, domenski eksperti mogu biti angažovani
puno radno vreme na projektu.
Predstavnici naručioca projekta - Predstavljaju osobe koje će primiti deliverable
projekta. U toku projekta, zaduženja predstavnika naručioca projekta najčešće se
odnose na validaciju izlaza projekta i pružanje konsultacija vezanih za zahteve
koji se postavljaju pred projekat.
Vendori - Predstavljaju eksterne kompanije koje je potrebno da obezbede
određene komponente ili usluge kako bi se projekat u potpunosti izvršio. U
projektima koji uključuju aktivnosti vendora, najčešće se delegiraju određeni
članovi projektnog tima koji su zaduženi za nadgledanje i kontrolu aktivnosti koje
vendor sprovodi.
Predstavnici poslovnih partnera - Predstavljaju osobe koje su delegirane od
strane poslovnog partnera organizacije koja sprovodi projekat, a koje bi trebalo
da obezbede korektnu koordinaciju na projektu i eventualno potrebne
konsultacije.
Poslovni partneri - Predstavljaju eksterne organizacije sa kojima organizacija koja
sprovodi projekat ima specijalne odnose, na osnovu kojih poslovni partneri
pružaju određene vrste podrške na projektu. Navedena podrška se često odnosi
na podršku i/ili izvršenje procesa sertifikacije, instalacije, prilagođavanja, treninga
i slično.
Članovi u projektnom timu mogu biti angažovani na sprovođenju projektnih aktivnosti u
različitom opsegu. Dva osnovna oblika angažovanja koja se javljaju su:
Potpuno angažovanje (dedicated) - Članovi tima koji su potpuno angažovani na
projektu rade puno radno vreme na projektnim aktivnostima, i direktno odgovaraju
projektnom menadžeru.
Delimično angažovanje (part-time) - Članovi tima koji su delimično angažovani na
projektu rade paralelno i na drugim aktivnostima (drugim projektima ili drugim
tekućim aktivnostima), i najčešće odgovaraju svom funkcionalno nadređenom
rukovodiocu. Kod delimično angažovanih članova tima, ključno je da se uspostavi
sistem koji obezbeđuje pravilnu alokaciju vremena, kako bi se osiguralo
ispunjenje vremenskih planova, kako na projektu, tako i na drugim aktivnostima
na kojima je osoba angažovana.
17
2.2.2 Životni ciklus projekta
Životni ciklus projekta predstavlja niz faza kroz koje projekat prolazi od inicijacije do
zatvaranja. U zavisnosti od načina na koji se projektom upravlja i na koji se projekat
sprovodi, životni ciklus može imati drugačije oblike. Neki od modela živnotnog ciklusa
projekta su sledeći:
Tradicionalni model životnog ciklusa projekta - vodopad (waterfall model)
Tradicionalni model životnog ciklusa projekta podrazumeva da se sve faze projekta
sprovode sekvencijalno i bez preklapanja. Ovo je vrlo rigidan model čiji je glavni
nedostatak vrlo visok nivo rizika na samom početku projekta, kao i visoki troškovi
eventualnih zahteva za promenama kasnije u toku projekta (Kruchten, 2001). Obzirom
da se svi funkcionalni zahtevi definišu na početku projekta, ovaj model ne predviđa
eventualni nastanak zahteva za izmenama, što zbog vrlo dinamičnog okruženja u
današenjem upravljanju projektima, očekivana pojava. Tradicionalni model prikazan je
na Slici 3.
Slika 3 - Tradicionalni model životnog ciklusa projekta
Iterativni model životnog ciklusa projekta
Iterativni model životnog ciklusa projekta podrazumeva postojanje više iteracija u okviru
istog projekta, pri čemu svaka iteracija rezultira opipljivom deliverablom koju je moguće
dostaviti podnosiocu zahteva/klijentu, a u okviru svake iteracije sprovode se sve
potrebne aktivnosti na projektu. Prednosti iterativnog modela su: mogućnost
18
dostavljanja dela proizvoda klijentu, što dovodi do bržeg povraćaja investicije,
mogućnost bržeg identifikovanja grešaka i nelogičnosti, alokacija rizika ravnomerno
kroz različite iteracije projekta. Iterativni model prikazan je na Slici 4.
Slika 4 - Iterativni model životnog ciklusa projekta
2.2.3 Faze upravljanja projektima
Prema PMBoK Guide, procesi upravljanja projektom mogu se svrstati u jednu od 5
grupa, prikazanih na Slici 5 (Project Management Institute, 2013):
1. Procesi inicijacije projekta - procesi koji se izvršavaju kako bi se definisao novi
projekat i pridobila autorizacija za početak projekta
2. Procesi planiranja projekta - procesi koji se izvršavaju kako bi se utvrdio obuhvat
projekta, precizirali ciljevi i definisao detaljan plan aktivnosti potrebnih da bi se
ostvarili navedeni ciljevi
3. Procesi sprovođenja projekta - procesi koji se izvršavaju kako bi se sproveo
posao definisan u planu upravljanja projektom u cilju zadovoljenja projektne
specifikacije
4. Procesi monitoringa i kontrole projekta - procesi koji se izvršavaju kako bi se
pratio, revidirao i regulisao progres i uspešnost projekta, kao i u cilju identifikacije
eventualnih neophodnih zahteva za izmenama na projektu
5. Procesi zatvaranja projekta - procesi koji se izvršavaju kako bi se finalizovale sve
aktivnosti i kako bi se projekat formalno zatvorio
19
Slika 5 - Procesi upravljanja projektom prema PMI (Project Management Institute, 2013)
2.2.4 Upravljanje različitim dimenzijama projekta
Svaki projekat podrazumeva da postoje specifična ograničenja pri realizaciji.
Tradicionalna ograničenja projekta predstavljaju osnovna ograničenja koja moraju biti
ispunjena kako bi projekat bio uspešno realizovan. Većina autora napominje ova
ograničenja, i to su: vreme, troškovi i obuhvat. Navedena ograničenja su često
predstavljena u obliku "trougla upravljanja projektima", kao što je prikazano na Slici 6,
gde je svako od ograničenja stranica trougla.
Slika 6 - Trougao upravljanja projektima
Trougao upravljanja projektima prikazuje međuzavisnost ispunjenja projektnih
ograničenja, pre svega prilikom izmene nekog od tri glavna projektna ograničenja. U
praksi, ovo znači da će izmena u jednom od ograničenja zahtevati i probijanje nekog od
druga dva ograničenja. Na primer, na projektu izrade softvera za obračun plata u
20
kompaniji, naknadno je proširen obuhvat projekta dodavanjem inicijalno neplanirane
funkcionalnosti za online uvid u plate. Ovo proširenje obuhvata rezultiraće:
Promenom u novcu potrebnom za sprovođenje projekta (povećanjem budžeta),
kako bi se projekat sproveo na vreme, ili
Promenom u vremenu potrebnom za sprovođenje projekta (produženjem roka),
kako bi se projekat sproveo u okviru planiranog budžeta
2.3 Specifičnosti projekata elektronskog poslovanja
Prema definiciji IBM, elektronsko poslovanje predstavlja proces korišćenja internet
tehnologija u cilju sprovođenja poslovnih procesa, povećanja produktivnosti i efikasnosti.
U tom smislu elektronsko poslovanje omogućava kompanijama da na jednostavan način
komuniciraju sa partnerima, dobavljačima i kupcima, povežu poslovne sisteme i izvrše
kupoprodajne procese na siguran način (IBM, 2001). Elektronsko poslovanje se često
poistovećuje sa elektronskom trgovinom, odnosno kupovinom i prodajom putem
interneta, ali kao što se zaključuje iz prethodno navedene definicije, ovaj koncept
obuhvata sprovođenje svih vrsta poslovnih procesa uz pomoć internet tehnologija.
Iako projekti elektronskog poslovanja dele veliki broj zajedničkih atributa sa klasičnim
projektima, Brooks identifikuje sledeće razlike (Brooks, 1987):
Nevidljivost - Ne postoji fizički objekat sa kojime se radi. Ulaz u projekat
predstavlja zamisao, tj opis funkcionalnosti koje se očekuju kao izlaz iz projekta.
Zbog navedenog, kao i zbog visokog nivoa dinamičnosti sredine u kojoj se
sprovode projekti elektronskog poslovanja, rezultat projekta je često teško
predvidiv.
Kompleksnost - Softverski projekti često mogu biti kompleksniiji od različitih
razvojnih projekata imajući u vidu veliki broj veza u samom predmetu projekta.
Fleksibilnost - Imajući u vidu dinamičnost sredine u kojoj se projekti elektronskog
poslovanja realizuju, oni se moraju realizovati na veoma fleksibilan način, kako bi
bilo moguće izvršiti adaptaciju u svakom trenutku realizacije projekta.
Projekti elektronskog poslovanja predstavljaju podvrstu softverskih projekata, te se na
projekte elektronskog poslovanja odnose mnoge teorije i prakse upravljanja softverskim
projektima. Razlikuje se više tipova razvoja projekata elektronskog poslovanja, koji su
21
analogni razvoju softverskih proizvoda, detaljnije objašnjeno u celini 2.3.1. Većina
procesa u upravljanju projektima elektronskog poslovanja po svojim osobinama i
principima odgovara procesima upravljanja klasičnim softverskim projektima. Procesi
koji se bitno razlikuju, i na koje je potrebno obratiti posebnu pažnju u kontekstu
elektronskog poslovanja, jesu procesi inicijacije projekata elektronskog poslovanja, te će
grupa procesa inicijacije biti detaljno obrađena u celini 2.3.2. Ostale faze (prema PMI),
planiranje, izvršenje, kontrola i zatvaranje, biće detaljnije obrađene u celinama 2.3.3,
2.3.4, 2.3.5 i 2.3.6, respektivno.
2.3.1 Tipovi razvoja softverskih proizvoda
“Svež razvoj” - Svež razvoj softvera, ili razvoj softvera od nule, predstavlja razvoj
softvera koji obuhvata sve faze životnog ciklusa projekta. Projekat počinje analizom
zahteva klijenta, ili identifikacijom potrebe za rešenjem, a završava se testiranjem
gotovog proizvoda.
COTS (commercial off-the-shelf) prilagođavanja softvera - Veliki broj popularnih
COTS proizvoda je dostupno na tržištu. To su softveri koji su namenjeni za opštu
upotrebu i mogu se kupiti na tržištu, a prilagoditi po potrebi. Neki od primera su softveri
za planiranje resursa kompanije (SAP, PeopleSoft), softveri za upravljanje odnosima sa
korisnicima, softveri za upravljanje lancem snabdevanja. Tipične faze COTS
prilagođavanja softvera obuhvataju (Murali & Cagley, 2010):
1. Proučavanje postojećeg sistema
2. Analiza jaza između trenutnog sistema i COTS proizvoda (gap analysis)
3. Izveštaj o prilagođavanju, odnosno definisanje željenog nivoa kastomizacije
sistema
4. Definisanje željenog nivoa kastomizacije COTS proizvoda
5. Dizajniranje softvera
6. Izrada softvera
7. Testiranje
8. Prilagođavanje koda
9. Implementacija
10. Obuka korisnika
11. Migracija
22
Prenošenje softvera - Projekti prenošenja softvera podrazumevaju prenošenje softvera
sa jedne hardverske platforme na drugu hardversku platformu. Projekti prenošenja
softvera mogu da obuhvataju (Murali & Cagley, 2010):
Prevođenje softvera na drugi programski jezik
Implementacija softvera na drugu hardversku infrastrukturu
Intervenisanje na softveru koje će obezbediti da softver radi na novom hardveru
bez problema
Migracija - U današnjem, veoma dinamičnom okruženju, često se objavljuju nove
verzije programskih jezika, nove verzije serverskog softvera i sl. Kada se pojavi upgrade
neke od komponenti od koje zavisi funkcionisanje softvera, nadogradnja softvera može
postati neophodna. Ova nadogradnja je neophodna iz nekoliko razloga (Murali &
Cagley, 2010):
Iskorišćenje novih pogodnosti koje pruža nova verzija u odnosu na prethodnu
Rešavanje problema u radu novih softvera/hardvera u radu sa starim verzijama
softvera/hardvera
Ispravka svih ograničenja i propusti u prethodnoj verziji
Nadogradnja softvera je posledica dinamičkog okruženja i zahtevnih potreba korisnika.
Naravno, ukoliko ne postoji potreba za nadogradnjom softvera, ona se ne radi. Međutim,
potrebno je kontinualno unapređivati softver, kako bi se minimizovala pretnja koju stvara
konkurencija. Obzirom da je softverska industrija jedna od najdinamičnijih industrija,
upravljanje projektima u softverskoj industriji zahteva proaktivnost.
Svaki projekat migracije softvera je jedinstven. Iz tog razloga aktivnosti na svakom
projektu mogu da se razlikuju.
Konverzija - Projekti konverzije predstavljaju projekte koji nastaju iz potrebe da se izvrši
konverzija jednog ili više ključnih parametara softvera. Dobri primeri ovih projekata su
projekat konverzije „Godina 2000 (Y2K)“ i „Evro konverzija“. Projekat „Godina 2000
(Y2K)“ je nestao iz potrebe za promenom načine obeležavanja datuma. Računari su
inicijalno projektovani imajući u vidu veoma ograničen prostor na hard disku. Kako bi
optimalno iskoristili memorijski prostor, godine su označavane samo sa dve poslednje
cifre. Tako bi na primer 1971. godina bila označena kao 71. Problem je nastao krajem
20. veka, zbog čega je pokrenut projekat konverzije „Godina 2000 (Y2K)“ , koji je
23
obuhvatao konverziju načina unošenja datuma u računar (International Y2K Cooperation
Center, 2000). Projekat „Evro konverzije“ je pokrenut kao posledica uvođenja valute
Evropske Unije. Ovo je bio veoma obiman i složen projekat koji je zahtevao konverziju
svih evropskih valuta u softverima u Evro. Na ovom projektu konverzije veoma blisko su
sarađivali najbolji stručnjaci softverskog inženjerstva, finansijskog sektora, i projektnog
menadžmenta (Klosch, 1998).
2.3.2 Inicijacija projekata elektronskog poslovanja
U fazi pokretanja (inicijacije) novih projekata elektronskog poslovanja, veoma su
značajna sledeća 4 koraka (Basu & Muylle , 2007):
1. Identifikacija potencijalnih inicijativa elektronskog poslovanja
2. Analiza obuhvata funkcionalnosti identifikovanih inicijativa
3. Analiza održivosti benefita identifikovanih inicijativa
4. Prioritizacija identifikovanih inicijativa
Identifikacija potencijalnih inicijativa elektronskog poslovanja - Potencijalne
inicijative za ostvarenje nekog oblika elektronskog poslovanja u kompanijama najčešće
nastaju kao način za stvaranje nove ili poboljšane vrednosti za kupca, odnosno neku od
zainteresovanih strana (stakeholder) kompanije, ili kao način za minimizaciju troškova u
tekućem poslovanju kompanije. Zadovoljenje potreba zainteresovanih strana često igra
ulogu pokretača novih ideja u kompanijama, te se iz ove pobude često identifikuju i
inicijative elektronskog poslovanja. Drugi način za identifikaciju inicijativa elektronskog
poslovanja predstavlja prepoznavanje mogućnosti za ostvarenje uštede u tekućim
troškovima poslovanja, i to najčešće kroz optimizaciju jednog ili grupe poslovnih procesa
uvođenjem nekog oblika elektronskog poslovanja. Treći način za identifikovanje
inicijative elektronskog poslovanja jeste zahtev dobijen od eksternog klijenta. Ukoliko je
potreba za projektnom definisana od strane eksternog klijenta, onda ova faza sadrži
sledeće korake (Murali & Cagley, 2010):
1. Zahtev za ponudu od strane klijenta (RfP - Request for proposal)
2. Ponuda
a. Procena traženog softvera
b. Definisanje očekivanih karakteristika
c. Definisanje cene projekta
24
d. Priprema ponude
e. Pregovaranje
3. Potpisivanje ugovora
Analiza obuhvata funkcionalnosti (scope analysis) identifikovanih inicijativa -
Predstavlja proces analize čiji rezultat je definicija svih predloženih funkcionalnosti i
predlog svih aktivnosti koje ulaze u obuhvat inicijative. Ova analiza služi kao polazna
tačka za dalju razradu inicijative u fazi planiranja, ali i kao referentni okvir za kontrolu
obuhvata u toku dalje razrade projekta. Basu&Muylle definišu tipologiju koja se može
koristiti u analizi obuhvata funkcionalnosti, i izdvajaju sledeće celine procesa koje mogu
biti deo obuhvata projekta (prikazano na Slici 7):
Procesi mrežnog nivoa - Predstavljaju komunikacione servise koji čine osnovu za
ostvarenje inicijative elektronskog poslovanja. Mogućnosti za unapređenje
poslovanja na mrežnom nivou u kontekstu elektronskog poslovanja odnose se
pre svega na poboljšanje efikasnosti i pouzdanosti drugih funkcionalnosti
elektronskog poslovanja.
Trgovinski procesi - Predstavljaju procese vezane za prodaju i kupovinu
proizvoda i usluga. Primeri ovih procesa su: pretraživanje proizvoda i usluga za
kupovinu/prodaju, pretraživanje kupaca/prodavaca, autentikacija
kupaca/prodavaca u procesu kupovine, plaćanje i odobrenje plaćanja, dostava,
instalacija itd. Unapređenje ovih procesa može rezultovati kako uštedom u
troškovima, tako i stvaranjem dodatne vrednosti za zainteresovane strane.
Procesi podrške odlučivanju - Predstavljaju procese koje kompaniji daju
mogućnost primene naprednih informacionih modela, kako bi na kvalitetniji način
iskoristila informacije na raspolaganju. Primeri ovih procesa su: kolaboracija
putem konferencijskih poziva, elektronskih white-board poziva, korišćenje deljenih
repozitorijuma, obrada informacija alatima poslovne inteligencije itd.
Procesi integracije - Predstavljaju procese koji kompanijama omogućavaju
integraciju različitih delova informacionog sistema u cilju omogućavanja
automatizacije dela poslovnih procesa. Procesi integracije mogu biti vertikalni
(integracija sa IS dobavljača, distributera i kupaca) i horizontalni (integracija sa IS
horizontalnih poslovnih partnera). Predmet procesa integracije mogu biti podaci
25
(interoperabilnost različitih struktura podataka) i aplikacije (interoperabilnost
aplikacija - u savremenom poslovanju najčešće ostvarena putem veb servisa).
Slika 7 - Analiza obuhvata funkcionalnosti inicijativa elektronskog poslovanja
Analiza održivosti benefita identifikovanih inicijativa - U praksi se sprovodi u skladu
sa utvrđenom procedurom kompanije u kojoj je inicijativa predložena. Za kreiranje
sveobuhvatne analize održivosti inicijative, potrebno je uzeti u obzir veliki broj internih i
eksternih faktora, te na osnovu sprovedene analize napraviti projekciju benefita
predložene inicijative. Najčešći faktori koji utiču na analizu su (Besanko, Dranove, &
Shanley, 1999):
Barijere za ulazak na tržište - prisutnost imitacija, regulativa, veličina tržišta,
osetljivost na cenu, kulturološke okolnosti.
Prednosti prvog igrača na tržištu - reputacija kompanija koje su prve na tržištu,
nepoverljivost potrošača prema novom ponuđaču, potrošačke navike, switching
cost promene dobavljača/partnera.
Prioritizacija identifikovanih inicijativa - Obzirom da će u kompaniji često biti
predloženo više inicijativa, potrebno je izvršiti prioritizaciju identifikovanih inicijativa kako
bi se donela odluka koje od inicijativa je potrebno realizovati u okviru budžeta na
raspolaganju, u cilju maksimizacije benefita, a minimizacije rizika i troškova. Za
donošenje ovakve odluke, vrlo često se koriste principi i alati business case analize.
Business case analiza predstavlja skup argumenata formiranih kako bi se donela odluka
o pokretanju određenog projekta, i najčešće se sastoji od sledećih celina:
26
Rezime (Executive Summary) - Predstavlja pregled celokupne business case
analize. Bitno je da rezime sadrži sve ključne argumente business case-a, kako bi
čitaoci već na osnovu rezime-a zaključili osnovne činjenice o predloženoj
inicijativi.
Definicija problema - Predstavlja definiciju svih problema zbog kojih se inicijativa
predlaže, odnosno opisuje motivaciju da se inicijativa započne. Često sadrži i
kvanitativne pokazatelje koji oslikavaju trenutnu situaciju.
Opis inicijative (predlog projekta) - Predstavlja opis obuhvata projekta, i najčešće
sadrži i definiciju pretpostavki sa kojima se ulazi u analizu (project assumptions),
opis zavisnosti projekta od drugih internih i eksternih uticaja (project
dependencies), najznačajnije rizike na projektu i opis mera koje se preuzimaju u
cilju preventive i korekcije rizika, kao i opis očekivanih izlaznih rezultata projekta
(project deliverables).
Analiza troškova i benefita (Cost-benefit analysis) - Predstavlja analizu koja
poredi odnos troškova i benefita trenutnog stanja u oblasti u kojoj se inicijativa
predlaže i projekcije troškova i benefita ukoliko bi se inicijativa implementirala.
Ova analiza troškove posmatra sa aspekta trenutka nastajanja troška, i razlikuje
fiksne i varijabilne troškove. Benefiti koji figuriraju u ovoj analizi mogu nastati
zbog uštede u operativnim troškovima, uštede u investicijama, porasta prihoda ili
smanjenja određenih rizika. Rezultat analize troškova i benefita uglavnom čini
skup finansijskih i nefinansijskih pokazatelja koji oslikavaju projektovanu
uspešnost predložene inicijative u slučaju prihvatanja iste i pokretanja projekta.
2.3.2.1 Pokazatelji kao rezultat analize troškova i benefita u fazi inicijacije projekta
Pokazatelji koji se javljaju kao rezultat analize troškova i benefita mogu se na visokom
nivou podeliti na kvantitativne, odnosno one koji se mogu izraziti merljivom veličinom, i
kvalitativne, odnosno one koji se najčešće izražavaju opisno. Osim ove podele značajna
je još i podela na finansijske i nefinasijske pokazatelje kao rezultat analize troškova i
benefita. Pokazatelji koji se koriste za projekte elektronskog poslovanja u analizi
troškova i benefita, uglavnom se ne razlikuju u velikoj meri od standardno prihvaćenih
pokazatelja za projekte iz drugih oblasti, koji su dati u nastavku (Brealey & Myers ,
1996).
ROI (Return on investment) - finansijski kvantitativni pokazatelj
27
ROI ili procenat povraćaja investicije, predstavlja pokazatelj koji meri odnos neto izlaza
projekta - benefita (ušteda u troškovima ili porast prihoda umanjeni za ukupne troškove
projekta) i neto ulaza projekta - troškova (ukupni troškovi projekta), izražen u procentnim
poenima.
ROI je jedan on najčešće korišćenih projektnih finansijskih pokazatelja. Jeffery and
Leliveld su u istraživanju 2002. godine, sprovedenom nad 130 predstavnika visokog
menadžementa kompanija koji se nalaze na Forbsovoj listi 1000 najuspešnijih
kompanija, došli do zaključka da čak 59% kompanija redovno koriste ROI prilikom
donošenja odluke o investiranju u IT projekat. Zanimljiv zaključak je takođe da samo
25% kompanija meri ROI projekta nakon samog sprovođenja projekta (Jeffery &
Leliveld, Best Practices in IT Portfolio Management, 2004).
ROI izračunat na gore navedeni način smatra se jednostavnim pokazateljem, koji
pokazuje procentualni finansijski benefit u odnosu na uložena sredstva, ali ne daje
dovoljno informacija za donošenje odluke o inicijativi (Jeffery , Return on Investment
Analysis for E-business Projects, 2004). Kako bi se nešto više dimenzija uzelo u obzir
prilikom računanja procenta povraćaja investicije, koristi se princip diskontovanja tokova
novca, te je osnovni pokazatelj koji se koristi u daljoj analizi benefita i troškova NPV.
NPV (Net present value) - finansijski kvantitativni pokazatelj
NPV ili neto sadašnja vrednost predstavlja sumu sadašnjih vrednosti svih pojedinačnih
tokova novca (priliva i odliva). Drugim rečima NPV uzima u obzir trenutak nastanka
priliva ili odliva novca.
Pri čemu je:
i Stopa diskontovanja novca t Vreme nastanka priliva/odliva novca (uglavnom broj godine) N Ukupni broj vremenskih perioda (uglavnom ukupan broj godina) Rt Budući priliv u vremenu t
28
Na primer, 1000RSD priliva koje projektujemo da će se desiti za godinu dana, danas
zapravo vredi 1000/(1+i), pri čemu je r stopa diskontovanja i predstavlja stopu koju
zarade koju bi kompanija mogla ostvariti ulaganjem u neko od standardnih tržišta na
kojima kompanija posluje. Minimalnom diskontnom stopom se smatra stopa kamate koju
bi kompanija mogla zaraditi stavljajući novac u banku na štednju. Za potrebe ovog
primera recimo da je r=10%, te možemo zaključiti da priliv od 1000RSD za godinu dana,
danas vredi 909RSD. Uopšteno gledajući, kompanije se ne odlučuju za investiranje u
projekat ukoliko je indeks profitabilnosti manji od 1, odnosno češće se odlučuju za
projekte sa većim indeksom profitabilnosti, pri čemu se indeks profitabilnosti računa na
sledeći način:
Zbog nedostataka ROI pokazatelja po pitanju vremenske dimenzije u kojoj tok novca
nastaje, pokazatelj koji se najčešće koristi da pokaže očekivani ishod investicije jeste
IRR.
IRR (Internal rate of return) - finansijski kvantitativni pokazatelj
IRR ili interna stopa prinosa predstavlja složenu godišnju stopu prinosa koja se očekuje
od projekta. IRR se izračunava direktno iz NPV, tj IRR je diskontna stopa pri kojoj je
NPV jednak nuli. Jednostavnije rečeno, interna stopa prinosa predstavlja kvalitet ili
efikasnost projekta, te se projekti sa većom internom stopom prinosa smatraju sigurnijim
za investiranje. Interna stopa prinosa se često koristi i za poređenje investicionih opcija
u više projekata.
Na Slici 8 prikazan je grafikon na kome se može videti veza između neto sadašnje
vrednosti i interne stope prinosa za dve investicije, A i B. Tačka u kojoj je NPV=0
predstavlja internu stopu prinosa za navedeni projekat. Na Slici 8 se može videti da je
projekat A isplativiji za investiranje sve dok je diskontna stopa i manja od one za koju su
neto sadašnje vrednosti projekta A i B jednake. Nakon ove tačke, sa porastom
diskontne stope, isplativije je investiranje u projekat B.
29
Slika 8 - Analiza investiranja u projekte u odnosu na NPV i diskontnu stopu
Generalno je prihvaćeno stanovište da za ključni kriterijum u odlučivanju, kompanije koje
teže efikasnosti u iskorišćenju investicije više koriste IRR, dok kompanije koje teže
maksimizaciji prinosa od investicije više koriste NPV. Danas NPV ima dominatno mesto
kao glavni pokazatelj koji se koristi u odlučivanju prilikom investiranja.
2.3.2.2 Problemi koji mogu da nastanu u fazi iniciranja projekta
Najčešći problemi koji nastaju u ovoj fazi projekta su (Murali & Cagley, 2010):
imenovanje pogrešnog projektnog menadžera, pogrešno definisanje resursa, kašnjenje
u fazi iniciranja projekta.
Imenovanje pogrešnog projektnog menadžera - Na svakom projektu je veoma bitno
da projektni menadžer bude kompetentan i da na najbolji mogući način vodi tim.
Međutim, dešava se da se pogrešna osoba postavi na tu funkciju. Razlozi za to mogu
biti:
Osoba koja bi bila najbolji projektni menadžer je trenutno zauzeta
Loša procena osobe
Postavljanje osobe na tu funkciju iz ličnih razloga i td.
Pogrešno alociranje resursa - Ljudski resursi na projektu moraju da budu
profesionalci, koji dobro poznaju svoj posao i koji imaju iskustva u njemu. Organizacije u
kojima se trenutno sprovodi veći broj projekata moraju voditi računa da racionalno
30
alociraju resurse koji rade na svakom od projekata, kako bi se izbegla situacija u kojoj su
na jednom projektu angažovani svi najbolji stručnjaci, pa su zbog toga drugi projekti u
manjku stručnjaka.
Kašnjenje u fazi iniciranja projekta - Ponekad se u ovoj fazi dese neočekivana
kašnjenja. Njihov uzrok mogu biti različite stvari, kao što su: identifikacija i alokacija
resursa je trajala duže od planiranog, definisanje planova projekta je trajalo duže od
planiranog itd. Ukoliko dođe do ovakvih kašnjenja, ona se moraju nadoknaditi u
sledećim fazama, kako bi projekat bio završen na vreme i kako bi se ispoštovali rokovi.
2.3.3 Planiranje projekata elektronskog poslovanja
Projektni planovi su jedan od glavnih faktora koji utiču na uspeh ili neuspeh projekta. U
zavisnosti od veličine i složenosti projekta, pripremaju se sledeći planovi (Murali &
Cagley, 2010):
Planovi projektnog menadžmenta - Sadrže detalje o obuhvatu projekta, kritičnim
tačkama projekta, alatima i tehnikama koje će se koristiti na projektu, kao i
mehanizmima komunikacije i rešavanja problema na projektu
Planovi upravljanja promenama - Sadrže detalje o procedurama uvođenja
promena, kao i eventualnih alata koji bi se u tom slučaju koristili
Planovi zadovoljavanja kvaliteta - Sadrže aktivnosti koje treba da se ispune, kako
bi finalni proizvod zadovoljio zahtevani kvalitet.
Planovi rasporeda aktivnosti na projektu - Sadrže detaljno rasčlanjene poslove na
projektu, prikaz liste i rasporeda aktivnosti sa dodeljenim resursima, vremenskim
rokovima, trajanjem aktivnosti itd.
Planovi integracije projekta - Sadrže detalje integracije sastavnih delova projekta.
Uključuju između ostalog i uloge i odgovornosti vezane za integraciju proizvoda.
Planovi vezani za razvoj softvera - Sadrže tehničke detalje vezane za razvoj
softvera.
Planovi obuke članova tima - Sadrže teme koje moraju biti pokrivene prilikom
obuke novih članova tima.
Planovi vezani za isporuku softvera - Sadrže detalje vezane za isporuku finalnog
proizvoda klijentu. Ovi planovi uključuju i detalje o tome kako će se meriti da li je
proizvod zadovoljio zahteve klijenta.
31
Planovi vezani za rešavanje problema - Sadrže detalje vezane za prijavu
problema, definisanje rešenja i uloge osoba odgovornih za rešavanje problema.
Saradnja različitih grupa na projektu je od velikog značaja za uspešnost projektnog
planiranja. Najmanje dva entiteta u organizaciji utiču na projektno planiranje:
organizacija koja pruža infrastrukturu za projekat i pojedinac koji predvodi projektno
planiranje, odnosno projektni menadžer.
Organizacija - Kako bi se obezbedila budućnost projekta, organizacija mora da
obezbedi projektno planiranje. Shodno tome, kako bi se omogućilo projektno planiranje,
organizacija mora da obezbedi sve neophodno kako bi se uspešno isplanirao projekat, i
to (Murali & Cagley, 2010):
Razvoj, uspostavljanje, implementaciju i stalno unapređenje procesa planiranja
projekta u organizaciji (obuhvata procedure, obrasce, formulare, plan za
obezbeđenje kvaliteta itd)
Standarde i uputstva za implementaciju (uputstvo za izradu dokumentacije, check
listu za pripremu i proveru planova itd)
Definisano odeljenje ili osobu koja je odgovorna za upravljanje projektnim
planiranjem u okviru organizacije
Uspostavljeno praćenje planova (obuhvata proveru planova prilikom njihove
izrade, praćenje projekta i analiziranje odstupanja od plana)
Evaluaciju planova nakon završetka projekta
Kreiranje znanja i iskustva u planiranju, na bazi iskustva sa prethodnih projekata,
na koji način se izbegava ponavljanje istih grešaka
Treninge sa temom planiranja
Nagrađivanje pojedinaca koji su zabeležili uspeh u planiranju projekata
Projektni menadžer na projektima - Osoba zadužena za projektno planiranje bi trebalo
da bude softverski projektni menadžer. Projektni menadžer mora da bude osoba koja
ima iskustva i uspeha u projektnom planiranju. Ukoliko mu organizacija obezbedi
neophodnu infrastrukturu, ovakav pojedinac može značajno da doprinese projektu tako
što će napraviti kvalitetan i detaljan plan. Da bi projektni menadžer bio uspešan u
planiranju on mora da:
32
Planira projekat tako da se isti uklapa u standarde i procese planiranja u
organizaciji
Prepozna značaj projektnog planiranja
Asistira u organizaciji prilikom razvoja, uspostavljanja, implementirana i stalnog
poboljšanja procesa planiranja
Se strogo pridržava organizacionih procesa, pravila, standarda i uputstva
Redovno daje feedback svim zainteresovanim grupama
Vodi proces planiranja najbolje što može. (Kerzner, 2009)
2.3.4 Izvršenje projekata elektronskog poslovanja
Sprovođenje projekta je srž projektnog menadžmenta u svim vrstama softverskih
projekata, pa tako i u projektima elektronskog poslovanja. Tokom sprovođenja projekata
primenjuju se različiti naučni aspekti menadžmenta, prate se planovi i ocenjuje se
njihova preciznost, pravi se finalni proizvod, testira se i isporučuje se klijentu.
Sprovođenje projekta u softverskoj industriji se sastoji od nekoliko menadžment
aktivnosti (Murali & Cagley, 2010):
upravljanje poslom
upravljanje konfiguracijom
upravljanje kvalitetom
upravljanje motivacijom tima
upravljanje očekivanjima zainteresovanih strana (klijenta, organizacije i
menadžmenta, projektnih timova itd)
integracija proizvoda
kontrola
2.3.4.1 Upravljanje poslom
Na softverskim projektima komponente proizvoda se grade, menjaju ili popravljaju, pa
imajući to u vidu, funkcionalnosti moraju biti grupisane u logične module. Navedeni
moduli se dele na podmodule, do nivoa dok se ne dođe do momenata kada podela više
nema smisla i ne donosi korist projektu. Na osnovu ovakve podele proizvoda moguće je
napraviti paket poslova koji će se alocirati pojedincu. Međutim, postavlja se pitanje koliki
treba da bude paket poslova koji će se dodeliti jednom pojedincu, odnosno koja je
33
optimalna veličina paketa poslova za pojedinca. Kod donošenja ovakve odluke treba
imati na umu sledeće:
Paket poslova treba da se sastoji od pojedinačnih komponenti
Komponente moraju biti pogodne za nezavisno testiranje
Alokacija treba da ima nezavisne funkcionalnosti (Ako se funkcionalnost podeli
na više od jedne komponente, onda sve komponente treba alocirati jednom
pojedincu ili jednom timu)
Prilikom alociranja posla treba voditi računa da je dovoljno posla alocirano na
svakog pojedinca
Za alokaciju resursa postoje dva pristupa: ad hoc pristup i procesni pristup. U ad hoc
pristupu posao se alocira:
tokom sastanka sa članovima tima
tokom objašnjenja funkcionalnosti
tokom postavljanja konačnog cilja
tako što se pojedinci prijavljuju za poslove.
Prema procesnom pristupu posao se alocira tako što se u registar poslova unosi
alokacija poslova, shodno procesima na procesu. Ovo se najčešće radi uz pomoć Excel-
a, MS Project-a i sličnih softvera. Početkom svakog dana član tima proverava registar
poslova i vidi koji poslovi su mu dodeljeni.
2.3.4.2 Upravljanje konfiguracijom
Upravljanje konfiguracijom na softverskim projektima podrazumeva održavanje
integriteta svih projektnih međuproizvoda i kontrolisanje svih promena koje utiču na
međuproizvode. Upravljanje konfiguracijom pokriva konfiguraciju dva tipa: konfiguraciju
produkcije i konfiguraciju razvoja softvera.
Konfiguracija produkcije se odvija u stvarnom okruženju u kom će i softver raditi.
Upravljanje konfiguracijom u produkcijskoj konfiguraciji se bavi proverom svih
međuproizvoda i finalnog proizvoda, kako bi se obezbedilo da krajnji korisnik dobije u
potpunosti funkcionalan softver.
Upravljanje konfiguracijom razvoja softvera se primenjuje na dva međuproizvoda:
informacije i kod. Informacije na softverskom projektu se ogledaju u posebnim
34
projektnim dokumentima, kao što su funkcionalna specifikacija proizvoda, specifikacija
potrebne infrastrukture, plan testiranja, plan integracije itd. Upravljanje konfiguracijom
koda obuhvata kontrolisanje kretanja koda, a sve kako bi se obezbedilo da je koretan i
kvalitetan kod isporučen inicijatoru projekta. Kretanje koda obično prati sledeći proces
koji je prikazan na Slici 9 (Murali & Cagley, 2010):
1. Razvoj koda
2. Testiranje koda
3. Povratak koda u fazu razvoja, ukoliko se u testiranju uoči neki nedostatak
4. Prelazak u fazu testiranja, nakon otklanjanja svi identifikovanih nedostataka
Faze 3. i 4. se ponavljaju sve dok se svi nedostaci ne otklone.
5. Prelazak u fazu integracije, nakon finalne potvrde sa testa
6. Testiranje integrisanog proizvoda
7. Povratak u fazu integracije, ukoliko se u testiranju integralnog proizvoda uoči neki
nedostatak
8. Prelazak u fazu testiranja integrisanog proizvoda, nakon otklanjanja svi
identifikovanih nedostataka
Koraci 7. i 8. se ponavljaju sve dok se ne dobije integrisani proizvod bez greške
9. Sistemsko testiranje, nakon finalne potvrde sa testa integrisanog proizvoda
10. Povratak u fazu integracije ili razvoja, ukoliko se u sistemskom testiranju
proizvoda uoči neki nedostatak (u zavisnosti od mesta greške)
Koraci 9. i 10. se ponavljaju sve dok se ne dobije proizvod bez greške.
11. Faza isporuke, nakon potvrde da je finalni proizvod bez greške
35
Slika 9 - Proces kreiranja koda (Murali & Cagley, 2010)
Ovo je uopšteni proces koji koristi većina organizacija, ali su, naravno, moguća
određena odstupanja.
2.3.4.3 Upravljanje kvalitetom
Upravljanje kvalitetom na softverskom projektu podrazumeva sve aktivnosti koje se
sprovede kako bi se obezbedio kvalitet projekta, razvoja softvera, kao i samog softvera.
Upravljanje kvalitetom na sofverskim projektima, obuhvata tri ključne aktivnosti
(Schwalbe, 2010):
36
1. Planiranje kvaliteta (planning quality) - Uključuje identifikaciju relevantih
standarda kvaliteta za predmetni projekat, kao i način za zadovoljenje tih
standarda. Glavni rezultati aktivnosti planiranja kvaliteta su plan upravljanja
kvalitetom projekta, način merenja (metrike) kvaliteta, ček liste kvaliteta
(checklists), plan za unapređenje procesa i ažurirana projektna dokumentacija.
2. Utvrđivanje kvaliteta (quality assurance) - Uključuje periodičnu evaluaciju ukupnih
performansi projekta, sa ciljem da se potvrdi da projekat i elementi projekta
zadovoljavaju relevantne standarde. Glavni rezultati aktivnosti utvrđivanja
kvaliteta su zahtevi za izmenama (change requests), ažurirani projektni planovi i
ažurirana druga projektna dokumentacija.
3. Kontrola kvaliteta (quality control) - Uključuje monitoring specifičnih rezultata
projekta, kako bi se utvrdilo da rezultati odgovaraju relevantnim standardima, i
kako bi se identifikovali načini za unapređenje ukupnog nivoa kvaliteta projekta.
Alati koji se koriste u toku kontrole kvaliteta uključuju Pareto grafikon, grafikon
kontrole kvaliteta i statističko uzorkovanje. Glavni rezultati aktivnosti kontrole
kvaliteta su zapisi merenja rezultata, potvrđene izmene, potvrđeni rezultati,
zahtevi za izmenama, ažurirani projektni planovi i ažurirana druga projektna
dokumentacija.
Kontrola kvaliteta u softverskim projektima često obuhvata monitoring sprovođenjem
testiranja softverskog proizvoda/usluge. Testiranje u različitim fazama softverskog
projekta obuhvata različite dimenzije, prikazano na Slici 10. Vrste testiranja koje se
javljaju u različitim fazama softverskog projekta su:
Unit testiranje - Sprovodi se kako bi se testirala svaka pojedinačna logička
jedinica (modul) proizvoda. Cilj je da se svi moduli istestiraju i validiraju pre nego
što se pristupi integraciji različitih modula, kako bi se proces integracije
pojednostavio, te kako bi se smanjio rizik prilikom integracije.
Integracijsko testiranje - Sprovodi se kako bi se testiralo sinergijsko
funkcionisanje različitih modula.
Sistemsko testiranje - Sprovodi se kako bi se testiralo kompletno funkcionisanje
sistema, uključujući integrisanost svih predviđenih modula, kao i interakciju
sistema sa svim predviđenim okruženjima. Postoji više vrsta sistemskog testiranja
koje će biti objašnjenje dalje u tekstu.
37
Korisničko testiranje (user acceptance test - UAT) - Sprovode ga krajnji korisnici
sistema. Korisničko testiranje ima za cilj da potvrdi da sistem funkcioniše na način
koji je inicijalno definisan funkcionalnom specifikacijom, bez razmatranja tehničkih
specifičnosti sistema.
Slika 10 - Tipovi testiranja prema fazama sprovođenja softverskog projekta
Prema načinu na koji izvršilac testa pristupa procesu testiranja, razlikuju se dve ključne
vrste testiranja (Murali & Cagley, 2010):
Testiranje bela kutija - Predstavlja interno testiranje u kome izvršilac testa
prilikom testiranja uzima u obzir tehničke specifičnosti sistema. Ovo testiranje
podrazumeva da se osoba koji vrši testiranje dobro razume u osnove kodiranja.
Testiranje crna kutija - Predstavlja testiranje kod koga osoba koja vrši testiranje
ima malo znanja o internoj strukturi softvera. Kroz softver se pusti niz inputa i
dobijaju se autputi. Ti autputi se kasnije porede sa očekivanim autputom. Ova
tehnika podrazumeva da je tester upoznat sa zahtevanim funkcionalnostima
sistema.
38
Sistemsko testiranje, koje podrazumeva testiranje kompletnog funkcionisanja sistema,
sprovodi se na više načina, u zavisnosti od specifičnosti samog sistema i predviđene
produkcijske konfiguracije sistema (Murali & Cagley, 2010):
Testiranje opterećenja - Cilj testiranja opterećenja je da se proveri da li softver
može da podnese višestruke zahteve i da verodostojno prikaže podatke pod
velikim opterećenjem. Testiranje opterećenja se može izvršiti putem web
aplikacija ili putem multikorisničkih aplikacija tako što se veliki broj korisnika
uloguje na aplikaciju i koristi softver na slučajan način ili po definisanim pravilima.
Testiranje opterećenja otkriva probleme povezane sa bazom podataka, veličinom
RAM memorije ili skladišta.
Testiranje obima podataka - Ovim testiranjem softver se opterećuje sa velikom
količinom podataka, kako bi se utvrdilo da li performanse softvera sa povećanjem
podataka i dalje zadovoljavaju postavljenje standarde.
Testiranje funkcionalnosti - Ova testiranja proveravaju da sve funkcionalnosti
softvera rade kako je i predviđeno.
End-to-end testiranje - Ovo testiranje prati entitet od početka do kraja aplikacije.
Cilj ovog testiranja je da se proveri da li su promene koje nastaju na entitetima
sprovedene kroz softver kao što je planirano.
Paralelno testiranje - Paralelno testiranje se sprovodi na softveru koji je dizajniran
tako da može da podnese nekoliko korisnika koji rade na istoj funkciji u isto
vreme. Ovo testiranje proverava sposobnost sistema da podnese višestruke
zahteve u isto vreme, a da se sačuva integritet podataka.
Istovremeno testiranje - Istovremeno testiranje je veoma slično paralelnom
testiranju, ali se ono koristi kako bi se otkrili problemi koji nastaju kada dva ili više
korisnika koriste istu funkciju, u isto vreme kako bi ažurirali ili promenili isti
podatak, ali sa različitim vrednostima.
Testiranje rada u problematičnim situacijama - Ovo testiranje podrazumeva
testiranje rada softvera u problematičnim situacijama, kao što su restartovanje
računara, diskonektovanje sa interneta, isticanje vremena rada servera itd.
Pozitivno testiranje - Pozitivno testiranje podrazumeva korišćenje softvera onako
kako je predviđeno da se on koristi, kako bi se utvrdilo da li sve funkcionalnosti
rade onako kako je planirano da rade kada se softver koristi kako je predviđeno.
39
Ovo testiranje se obično sprovodi kad se softver testira prilikom primopredaje
softvera.
Negativno testiranje - Negativno testiranje podrazumeva korišćenje softvera na
način na koji nije predviđeno da se koristi ili korišćenje na neočekivani način,
kako bi se mogli otkriti skriveni defekti. Ova testiranja se sprovode kako bi se
utvrdilo da nepravilno korišćenje softvera neće uticati na sam softver ili na
integritet podataka.
Testiranje uputstva za korišćenje - Testiranje uputstva za korišćenje
podrazumeva korišćenje softvera po uputstvima za upotrebu. Na ovaj način se
proverava da li je uputstvo za korišćenje pravilno napisano.
Regresiono testiranje - Ovo testiranje podrazumeva testiranje delova softvera na
kojima je ranije otkrivena i otklonjena greška. Cilj ovog testiranja je da se proveri
da li je greška koja je uočena zaista u potpunosti otklonjena i da li softver sada
radi kako treba.
Testiranje sigurnosti - Testiranje sigurnosti se sprovodi kako bi se utvrdilo da je
softver dobro zaštićen od hakera, virusa i drugih štetnih uticaja.
Testiranje performansi - Testiranje performansi treba da proveri da li aplikacija
funkcioniše u okviru prihvatljivog opsega. Rezultati ovog testiranja se porede sa
standardima predviđenim za taj softver.
Testiranje upotrebljivosti - Testiranje upotrebljivosti treba da utvrdi da li je softver
pogodan za korišćenje. Ovim testiranjem treba da se utvrdi da li softver odgovara
planiranoj nameni.
Testiranje instaliranja/uninstaliranja - Ovo testiranje se sprovodi da bi se utvrdilo
da li instaliranje, odnosno uninstaliranje softvera funkcioniše kako treba na svim
platformama.
Uporedno testiranje - Uporedno testiranje podrazumeva upoređivanje softvera sa
konkurentnim softverom i pronalaženje razlika.
Intuitivno testiranje - Intuitivno testiranje se koristi kako bi se utvrdilo da li softver
može da se koristi bez prethodnog upoznavanja sa uputstvom za upotrebu.
Testiranje paketa za isporuku - Ovim testiranjem se proverava da li paket za
isporuku sadrži sve neophodne komponente.
40
2.3.4.4 Upravljanje motivacijom tima
Prema rezultatima istraživanja, motivacija tima ima najveći uticaj na produktivnost,
kvalitet softvera i sveukupni uspeh projekta (Beecham, Baddoo, Hall, Robinson, & Sharp
, 2008). Razumevanje motivacije članova softverskih timova igra ključnu ulogu u
upravljanju izvršenjem softverskih projekata. Projektni menadžer je zadužen da upravlja
motivacijom članova tima, obraćajući pažnju na svakog pojedinca u okviru tima i
uvažavajući njegove specifičnosti. Neki od elemenata koji igraju bitnu ulogu u
motivisanju člana tima su:
Posao - Posao sam po sebi može biti značajan motivator za rad. Ukoliko je posao
zanimljiv, izazovan i poseban, sama sadržina posla motiviše članove tima da daju
sve od sebe kako bi uspešno završili projekat.
Međuljudski odnosi - Međuljudski odnosi na radnom mestu su veoma bitni za
motivaciju zaposlenih. Međusobno poštovanje i razumevanje su neophodni da bi
članovi tima mogli efiksno zajedno raditi.
Očekivanja na radnom mestu - Zaposleni imaju očekivanja vezana za radno
mesto i posao koji obavljaju. Neka od očekivanja vezana su ostvarenje zarade za
obavljeni posao, nagrađivanje za posebno zalaganje, fer odnose nadređenih
prema zaposlenima itd.
Konflikti - Konflikti u timu mogu biti konstruktivni, ukoliko članovi tima dođu do
dobrog rešenja, ali se konflikti moraju održavati na prihvatljivom nivou. Projektni
menadžer zadužen je da upravlja konfliktima u timu, i da pravovremeno reši sve
konfliktne situacije koje mogu nastati u radu.
2.3.4.5 Upravljanje očekivanjima zainteresovanih strana (klijenta, organizacije i
menadžmenta, projektnih timova itd)
Prilikom inicijacije projekta potrebno je identifikovati sve zainteresovane strane na
projektu i definisati na koji način se planira zadovoljenje potreba i želja zainteresovanih
strana. Komunikacija igra najveću ulogu u upravljanju očekivanjima stejkholdera. Dalje
su navedena očekivanja nekih od ključnih stejkholdera na projektima razvoja softvera
(Murali & Cagley, 2010).
41
Očekivanja klijenta/podnosioca zahteva - Na svakom projektu treba imati u vidu da je
klijent taj koji plaća projekat i koji očekuje kvalitetan proizvod za uloženi novac. Neka od
očekivanja koje imaju klijenti su:
Profesionalizam
Dobra komunikacija sa projektnim menadžerom
Softver koji ispunjava sve tražene funkcionalnosti
Isporuka softvera bez defekata
Isporuka na vreme
Servis za klijenta.
Očekivanja menadžmenta - Menadžment je veoma bitan stejkholder na projektu, stoga
je važno da menadžment bude zadovoljan softverskim projektom koji se radi.
Menadžment od projektnog menadžera i projektnog tima očekuje da:
Se projekat izvrši uspešno
Da se projekat izvrši u planiranom vremenskom okviru
Da se sve promene kontrolišu
Da se obezbedi isporuka softvera bez defekata
Da se obezbedi zdrava atmosfera u okviru tima
Da projektni menadžer bude lider i komunikator u timu
Da se od klijenta naplati projekat.
Očekivanja projektnog tima - Veoma je bitno upravljati motivacijom i očekivanjima
projektnog tima. To je zadatak projektnog menadžera. Neka od očekivanja koje ima
projektni tim su:
Poštena alokacija posla
Prepoznavanje uspešno obavljenih zadataka
Pošteno nagrađivanje članova tima
Korektan odnos sa svim članovima tima
2.3.4.6 Integracija proizvoda
Upravljanje konfiguracijom igra značajnu ulogu u integraciji softvera i isporuci proizvoda
bez defekta. Obzirom da je potrebno posvetiti dosta pažnje integraciji softvera, projektni
menadžer bi trebalo da nadgleda integraciju. Kako bi projektni menadžer mogao da prati
42
i kontroliše integraciju, neophodno je da se vodi registar integracije koji će sadržati
detalje o integraciji svakog modula.
2.3.5 Kontrola projekata elektronskog poslovanja
U softverskom projektnom menadžmentu kontrola se definiše kao set korektivnih mera
koje se preduzimaju periodično tokom sprovođenja projekta, a koje proizilaze iz potrebe
za praćenjem aktivnosti na projektu i poređenjem sa planiranih, odnosno željenih
dostignuća. Procesi kontrole obuhvataju (Project Management Institute, 2013):
Kontrolu izmena i formiraranje poreporuka za korektivne i preventivne aktivnosti
Monitoring tekućih projektnih aktivnosti u kontekstu plana upravljanja projektom i
merenje performansi na projektu
Uticanje na na faktore koji ugrožavaju integrisani plan upravljanja promenama i
upravljanja konfiguracijom, kako bi se osiguralo da se implementiraju samo
odobrene promene.
Ključni benefit procesa kontrole jeste da omogućava zainteresovanim stranama da
razumeju trenutno stanje projekta, korake koji se preduzimaju, stanje budžeta i
predviđanja budućeg stanja. Na Slici 11 prikazan je opšti model procesa kontrole, koji
na osnovu ulaznih parametara u proces kontrole, a uz pomoć tehnika i alata, daje
rezultate procesa kontrole.
Ulazi u proces kontrole su najčešće dokumenti i analize koji se formiraju u fazi inicijacije
i planiranja projekta. Tehnike i alati koji se najčešće koriste u procesima kontrole
projekta su sledeći (Project Management Institute, 2013):
Ekspertska procena - Odnosi se na mišljenje domenskih ekperata koje projektni
tim koristi da bi doneo relevantne zaključke.
Analitičke tehnike - Koriste se kako bi se predvideli budući rezultati projekta na
osnovu do sada dostupnih podataka sa projekta i iz spoljnog okruženja. Neke od
tehnika koje se koriste su: regresiona analiza, metode grupisanja, analiza
uzročnosti, metode predviđanja (vremenske serije, simulacije, analiza scenarija),
analiza trenda, analiza varijanse itd.
43
Informacioni sistem za upravljanje projektima - Odnosi se na informacioni sistem
koji pruža alate za podršku upravljanju projektima, i najčešče uključuje i alate za
planiranje rasporeda, resursa, troškova, praćenje performansi itd.
Sastanci - Sastanci mogu biti lice-u-lice, virtuelni, formalni i neformalni, i mogu
uključivati različite uloge na projektu, kao i eksterne učesnike.
Slika 11 - Proces kontrole projekta
Kod projekata elektronskog poslovanja, izuzetno je važno obratiti pažnju na kontrolu
projekta, pre svega kontrolu obuhvata projekta. Obzirom da je tržište veoma dinamično, i
da tehnologije koje se koriste u toku realizacije projekta veoma brzo napreduju, često
dolazi do inicijativa za izmenama na projektu u toku same realilzacije projekta. Uloga
projektnog menadžera jeste da sa projektnim timom sagleda ovakve inicijative i da izvrši
analizu inicijalno planiranog u odnosu na zahtevano, kao i da uz pomoć tehnika i alata
za kontrolu utvrdi dalje korake. Na osnovu ove analize, može doći do zahteva za
izmenama na projektu i/ili ažuriranja projektnog plana i projektne dokumentacije.
2.3.5.1 Metod ostvarene vrednosti
Metod ostvarene vrednosti (Earned Value Method) predstavlja jednu od najznačajnijih
metoda koje se koriste u procesu praćenja i kontrole ostvarenja napretka na projektu.
Osnovna prednost metode ostvarene vrednosti u odnosu na druge metode za praćenje i
kontrolu projekta je u objedinjavanju planiranih i ostvarenih veličina, što predstavlja
osnovu za realno sagledavanje stanja na projektu. Suština ove metode je u utvrđivanju
stepena izvršenja projekta i mogućnosti predviđanja njegovog ishoda. Analiza ostvarene
vrednosti podrazumeva poređenje trenutnog izvršenja projekta u odnosu na očekivano
44
izvršenje iskazano u baseline-u projekta i predviđanje budućeg izvršenja na osnovu
dobijenih parametara.
Osnovni parametar za analizu ostvarenog napretka na projektu je varijansa, koja se
iskazuje kroz dve forme: vremenska i troškovna varijansa. Proračun varijanse se vrši na
osnovu sledećih pokazatelja:
BCWS - planirani troškovi planiranog rada (Budgeted cost of work scheduled) –
ovo je vrednost planiranih troškova projekata ili aktivnosti koje su planirane da se
završe do statusnog datuma
BCWP – planirani troškovi izvršenog rada (budgeted cost of work performed) –
ovo je ostvarena vrednost, odnosno vrednost planiranih troškova projekata ili
aktivnosti koje su izvršene do statusnog datuma
ACWP – stvarni troškovi izvršenog rada (actual cost of work performed) – ovo je
vrednost stvarnih troškova aktivnosti koje su izvršene do statusnog datuma.
Vremenska varijansa, koja se skraćeno označava SV, predstavlja razliku između
planiranih troškova izvršenog rada i planiranih troškova planiranog rada:
SV=BCWP-BCWS
Vremenska varijansa treba da pokaže da li se radovi na programu odvijaju po
postavljenom planu, da li kasne ili se čak odvijaju ranije nego što je to predviđeno:
ako je SV=0, onda se radovi odvijaju prema planu
ako je SV<0, onda radovi kasne
ako je SV>0, onda se radovi odvijaju pre predviđenog roka.
Troškovna varijansa, koja se označava CV, predstavlja razliku između planiranih
troškova izvršenog rada i stvarnih troškova izvršenog rada:
CV=BCWP-ACWP
Varijansa troškova treba da pokaže da li su troškovi u okviru planiranog budžeta, da li su
veći ili su manji nego što planirani:
ako je CV=0, onda su ostvare troškovi prema predviđenom planu
ako je CV<0, onda je došlo do prekoračenja troškova
ako je CV>0, onda su troškovi manji od planiranih.
45
Analiza varijanse (vremenske i troškovne) treba da pomogne u pravovremenom
otkrivanju mogućih problema i njihovom rešavanju. Ukoliko se želi utvrditi efikasnost
izvršenog rada, potrebno je proračunati vrednost troškovne i vremenske varijanse u
odgovarajućim novčanim ili procentualnim veličinama. CPI je troškovni indeks
efikasnosti i izračunava se pomoću formule:
CPI=BCWP/ACWP
SPI je Vremenski indeks efikasnosti i izračunava se pomoću formule:
SPI=BCWP/BCWS
U gore navedenim jednakostima važe sledeće relacije:
CPI>=1 – odlične performanse projekta
CPI<=1 – loše performanse, troškovi prekraćeni
SPI>=1 – odlične performanse projekta
SPI<=1 – loše performanse, projekat kasni.
Za kompletiranje analize o stanju na programu potrebno je proračunati vrednosti
pokazatelja ETC (estimate to complete) i EAC (estimate at completion). Pokazatelj ETC
predstavlja procenu troškova od statusnog datuma do kraja programa i izračunava se na
sledeći način:
ETC=(BAC-BCWP)/CPI
Pokazatelj EAC predstavlja realnu procenu radova koji treba da se izvrše na projektu:
EAC=ACWP+ETC, EAC=BAC/CPI.
Na osnovu prethodno izračunatih veličina može se proceniti varijansa (VAC) za ceo
projekat:
VAC=BAC-EAC (Jovanović, Petrović, Obradović, & Mihić, 2007)
2.3.6 Zatvaranje projekata elektronskog poslovanja
Procesi zatvaranja projekta obično uključuju formalno prihvatanje projekta ili projektne
faze, kao i veći broj administrativnih aktivnosti poput zatvaranja ugovorne
dokumentacije, arhiviranja projektne dokumentacije, dokumentovanja "naučenih lekcija"
(lessons learned) i priprema formalnih izveštaja za zatvaranje projekta. Procesi vezani
46
za zatvaranje projekata elektronskog poslovanje mogu se podeliti u dve grupe i to
(Centers for Disease Control and Prevention, 2006):
Procesi administrativnog zatvaranja projekta, koji uključuju:
o Potvrđivanje da je projekat ispunio sve zahteve spozora, kupca i svih
drugih zainteresovanih strana
o Verifikaciju da su svi izlazi projekta (deliverable) isporučeni i prihvaćeni
o Validaciju da su izlazni kriterijumi ispunjeni
Procesi zatvaranja ugovora, koji uključuju:
o Potvrđivanje da je projekat sproveden u skladu sa uslovima definisanim u
ugovoru
o Potvrđivanje kompletiranja izlaznih kriterijuma za zatvaranje ugovora
o Formalno zatvaranje svih ugovora vezanih za završeni projekat
47
3 Preporuke za upravljanje projektima u elektronskom
poslovanju
Na osnovu prethodno izvršene analize i pregleda literature, u ovom poglavlju će biti date
preporuke za upravljanje projektima u elektronskom poslovanju. Svrha ovih preporuka
jeste umanjenje rizika na projektu, povećanje kontrolabilnosti procesa upravljanja
projektom i osiguranje kontinualnog učenja na osnovu svakog projektnog iskustva.
3.1 Preporuke za iniciranje projekata elektronskog poslovanja
Prva faza svakog projekta započinje identifikacijom inicijative i njenom inicijalnom
analizom. Osoba ili organizacioni deo koji identifikuje inicijativu i predloži je za
sprovođenje smatra se zahtevaocem inicijative. Nakon identifikacije inicijative,
zahtevalac inicijative je dužan da funkcionalno detaljno definiše zahtev, kao i da
sprovede sve potrebne analize koje će utvrditi u kojoj meri je predložena incijativa
pogodna za implementaciju u organizaciji, i da rezultate ovih analiza prezentuje
relevantnim organizacionim delovima. Na osnovu rezultata analize inicijatve, biće
doneta odluka da li će se pristupiti implementaciji inicijative ili ne. Jedna od analiza koja
se najčešće sprovodi u cilju donošenja odluke o implementaciji inicijative jeste business
case analiza.
3.1.1 Kreiranje business case-a za iniciranje projekta elektronskog poslovanja
Business case predstavlja tip analize koja se sprovodi prilikom analiziranja isplativosti i
kvaliteta poslovne inicijative. Svrha business case-a jeste da na logički struktuiran i
precizan način prikaže sve benefite poslovne inicijative, uglavnom u odnosu na trenutno
stanje. U savremenom projektnom poslovanju business case predstavlja jednu od
osnovnih i najbitnijih analiza koja se sprovodi za konkretnu inicijativu. U velikom broju
organizacija ova analiza je ključni instrument na osnovu koga se zaključuje da li će se
pristupiti realizaciji određenog projekta. U praksi se pokazalo da sam kvalitet business
case analize u značajnoj meri utiče na stvaranje vrednosti na osnovu implementirane
inicijative (IT Governance Institute, 2006).
Ovu analizu najčešće sprovodi projektni sponzor, odnosno zahtevalac inicijative, uz
pomoć svih relevantnih zainteresovanih strana. Svaka business case analiza bi trebalo
da obuhvati i opiše sve rezultate koji se očekuju zbog sprovođenja predmetnog projekta,
48
uključujući sve pozitivne i negativne, kvantitativne i kvalitative rezultate. Prema
rezultatima Gartnerovog istraživanja na temu IT troškova i investicija, ističe se pet
osnovnih argumenata koji čine srž business case-a za inicijative u oblasti IT-a (Gartner,
2003). Na Slici 12 prikazane su osnovne grupe argumenata na kojima se može zasnivati
business case, u odnosu na nivo percipirane vrednosti za kompaniju i lakoće
dokazivanja benefita inicijative. Pored grafikona na slici, za svaki od argumenata
navedeni su alati koji se najčešće koriste za dokazivanje benefita inicijative.
Slika 12 - Grupe argumenata na kojima se može zasnivati business case inicijative
Prilikom kreiranja business case analize, minimalno sledeći uticaji na sistem moraju biti
identifikovani i predstavljeni:
1. Potreba za investicijama (fiksni troškovi)
2. Amortizacija investicije
3. Potreba za jednokratnim i/ili višekratnim operativnim troškovima
4. Projektovani porast prihoda
5. Projektovana ušteda u budućim investicijama
6. Projektovana ušteda u operativnim troškovima
49
7. Projektovani porast/smanjenje finansijskog rizika
8. Projektovani porast/smanjenje operativnog rizika
9. Projektovani porast/smanjenje reputacionog rizika
U Tabeli 1 je data preporuka šablona za identifikaciju svih bitnih osobina postojećeg i
predloženog sistema za potrebe formulisanja business case analize, u kontekstu
inicijativa elektronskog poslovanja. U šablonu su prema poslovnim aspektima navedena
pitanja na koja je potrebno dati odgovor kako bi se sagledali rezultati predložene
inicijative u odnosu na trenutno stanje.
Aspekt Ključna pitanja
CAPEX (Capital
Expenses)
Da li predloženo rešenje zahteva investiciju?
o Kupovina softvera/licenci
o Kupovina sistemske infrastrukture (serveri, ruteri ...)
o Kupovina ili lizing nekretnine
Da li predloženo rešenje uzrokuje uštedu u postojećim
kapitalnim troškovima?
o Ušteda u kupovini softvera/licenci koji bi se morao
kupiti ukoliko se ne implementira predloženo
rešenje
o Ušteda u kupovini sistemske infrastrukture koja bi
se morala kupiti ukoliko se ne implementira
predloženo rešenje
o Ušteda u kupovini ili lizingu nekretnine koja bi se
morala kupiti ukoliko se ne implementira predloženo
rešenje
OPEX (Operational
Expenses)
Da li predloženo rešenje zahteva ulaganje u operativne
troškove?
o Softver kao usluga (Software as a service)
o Sistemska infrastruktura kao usluga (Infrastructure
as a service)
o Troškovi instalacije i održavanja softvera
o Troškovi obuke za korišćenje novog rešenjenja
50
o Troškovi ljudskih resursa koji će biti potrebni ukoliko
se rešenje implementira
Da li predloženo rešenje uzrokuje uštedu u postojećim
operativnim troškovima?
Promena prihoda Da li predloženo rešenje uzrokuje promenu u prihodima
(porast ili pad)? Promena u prihodima je najčešće
uzrokovana:
o Promenom broja kupovina proizvoda/usluge po
jednom kupcu/korisniku
o Promenom ukupnog broja kupaca/korisnika
o Promenom frekvencije kupovine proizvoda/usluge
po jednom kupcu/korisniku
Promena nivoa rizika Da li predloženo rešenje uzrokuje promenu u nivou rizika
(u odnosu na postojeći sistem)?
o Promena nivoa finansijskog rizika
o Promena nivoa operativnog rizika
o Promena nivoa reputacionog rizika
Tabela 1 - Šablon za identifikaciju bitnih elemenata business case analize
3.1.2 Preporuke za formiranje cost benefit analize kao deo business case-a
Na osnovu identifikovanih relevantnih elemenata business case-a predloženog rešenja,
potrebno je formirati cost-benefit analizu, kao deo business case-a. Cost benfit analiza
predstavlja sistematičan prikaz benefita i troškova predloženog rešenja čiji rezultati
mogu biti predstavljeni različitim pokazateljima. Pokazatelji koji se najčešće koriste su:
neto sadašnja vrednost, interna stopa prinosa i cost-benefit racio. Ukoliko su neki od
relevantnih benefita predloženog rešenja kvalitativni, ovi benefiti se moraju posebno
istaći, obzirom da se njihov uticaj neće videti u krajnjim rezultatima cost-benefit računice.
Suština business case-a inicijativa elektronskog poslovanja najčešće se ogleda u jednoj
od dve opcije:
Mogućnost za uštedu u troškovima
Mogućnost za rast prihoda
51
Ukoliko inicijativna proističe iz mogućnosti za uštedu u troškovima, cost-benefit će se
zasnivati na razlici trenutno postojećih troškova i troškova predložene inicijative. Ukoliko
inicijativa proističe iz mogućnosti za rast prihoda, cost-benefit će se zasnivati na
povećanju bruto prihoda.
3.2 Preporuke za planiranje projekata elektronskog poslovanja
Faza inicijacije projekta se završava formalnim usvajanjem projekta i projektne
dokumentacije, nakon čega započinje faza planiranja projekta. Ključnu ulogu u fazi
planiranja projekta ima projektni menadžer, čiji je zadatak da kreira sve potrebne
planove za određeni projekat.
Opšte preporuke za sprovođenje planiranja su sledeće:
Za uspešno sprovođenje projekata neophodno je kreirati procese planiranja. Ovi
procesi mogu da pomognu projektnom menadžeru da pokrije sve aspekte u
planu. Procesi u fazi planiranja obezbeđuju sveobuhvatno planiranje. Takođe,
procesi planiranja treba stalno da se unapređuju, jer se iz svakog projekta izvuče
neka nova pouka.
Projektnim planerima je veoma bitno obezbediti sve alate neophodne za
planiranje. Ti alati mogu da obuhvate softversku i hardversku podršku, feedback
sa prethodnih projekata, pravila i norme kompanije i td.
Nakon završetka projekta neophodno je napraviti analizu varijanse. Varijansa
treba da pokaže odstupanja od plana. Potrebno je predvideti i prag tolerancije,
nakon čega bi trealo analizirati sva veća odstupanja i pronaći uzrok tim
odstupanjima. Na ovaj način projektni tim dobija dodatno znanje i iskustvo, koje
može da se doda u skladište znanja. Na ovaj način će se izbeći ponavljanje
grešaka u budućnosti. Takođe, to će obezbediti projektnom timu da u narednim
projektima preciznije planiraju.
Jednu od najsveobuhvatnijih preporuka za planiranje softverskih projekata daju Cardozo
i de Villiers, prateći životni ciklus projekta po IBM-ovo metodologiji Rational Unified
Process® - RUP® (Cardozo & de Villiers, 2003).
52
3.2.1 Vremenski plan
Kreiranje vremenskog plana predstavlja jednu od najzahtevnijih aktivnosti za projektnog
menadžera na projektu elektronskog poslovanja. Formiranje vremenskog plana se
značajno razlikuje u zavisnosti od aktera koji sprovodi realizaciju projekta elektronskog
poslovanja. U ovom poglavlju biće detaljnije razrađeno kreiranje vremenskog plana za
projekte koji su većinski in house.
Kako bi se izvršilo planiranje aktivnosti na projektu, minimalno su neophodni sledeći
ulazi:
Funkcionalna specifikacija projekta (sa precizno definisanim obuhvatom)
WBS (Work Breakdown Structure) - dekompozicija projektnih aktivnosti
Plan upravljanja projektom
Prihvaćeni zahtevi za izmenama
Dokumentacija o raspoloživosti resursa
Procena trajanja realizacije aktivnosti
Alati koji se koriste u toku planiranja vremena na projektu su (Project Management
Institute, 2013):
CPM (Critical Path Method) - Metoda kritičnog puta - Koristi se kako bi se
identifikovao niz kritičnih aktivnosti na projektu. Kod projekata elektronskog
poslovanja, aktivnosti su najčešće kritične zbog ograničene raspoloživosti resursa
koji imaju dovoljne kompetencije da realizuju određene aktivnosti. Ukoliko dođe
do kašnjenja u realizaciji aktivnosti na kritičnom putu, doćiće i do kašnjenja
celokupnog projekta.
What-if analiza - Koristi se kako bi se identifikovale rizične tačke na projektu.
Balansiranje resursa - Koristi se kako bi se izjednačilo angažovanje resursa,
odnosno kako bi se izbeglo preveliko opterećivanje jednog ili grupe resursa.
3.2.2 Plan troškova
Plan troškova predstavlja dokument koji se kreira u fazi planiranja projekta kako bi se
sagledali svi troškovi koji se vezuju za projekat. Sva kasnija realizacija projektnih
troškova se evaluira u odnosu na inicijalno kreirani plan troškova.
53
3.2.3 Plan upravljanja rizicima
Rizik se definiše kao događaj za koji postoji verovatnoća ostvarenja, a koji bi mogao
imati pozitivan ili negativan uticaj na projekat ukoliko se desi. Rizik može imati jedan ili
više uzroka, a ukoliko se ostvari, jedan ili više uticaja. Upravljanje rizicima predstavlja
kontinualan proces koji se sprovodi tokom čitavog životnog ciklusa projekta. Osnovni
elekmenti upravljanja rizicima su:
Identifikacija rizika
Procena rizika
Definisanje preventivnih i korektivnih mera
Praćenje i izveštavanje
U fazi planiranja upravljanja rizicima, preporuka jeste kreirati registar rizika koji bi se
koristio kao osnovni dokument u procesu upravljanja rizicima. U Tabeli 2 dat je predlog
registra rizika sa opisom svih kolona koje bi trebalo popuniti za svaki identifikovani rizik.
Naziv kolone u registru rizika Opis kolone
Šifra rizika Jedinstveni identifikator rizika u registru rizika
Opis rizika Detaljniji opis identifikovanog rizika
Verovatnoća ostvarenja rizika Vrednost od 0 do 1 koja označava koja je
verovatnoća da se identifikovani rizik ostvari.
Uticaj rizika na projekat Vrednost od 0 do 1 koja označava koliki je uticaj
ostvarenja rizika na projekat. 1 označava da bi samo
postojanje projekta bilo ugroženo ukoliko bi se rizik
ostvario.
Ukupna vrednost rizika Računa se kao verovatnoća ostvarenja rizika x uticaj
rizika na projekat. Označava ukupan značaj rizika za
projekat.
Kategorija rizika Moguće vrednosti:
H (high)
M (medium)
54
L (low)
Kategorija se određuje na osnovu definisanih
opsega vrednosti u koloni "ukupna vrednost rizika".
Preventivne mere Preventivne mere predstavljaju aktivnosti koje je
potrebno sprovesti kako bi se smanjila verovatnoća
da će se rizik ostvariti. Preventivne mere često
uključuju aktivnosti monitoringa, praćenja KPI,
obuke korisnika itd.
Korektivne mere Korektivne mere predstavljaju aktivnosti koje je
potrebno sprovesti ukoliko se rizik ostvari.
Korektivne mere često uključuju manuelnu ispravku
problema, replaniranje drugih projektnih aktivnosti
itd.
Vlasnik rizika Vlasnik rizika je najčešće organizacioni deo u čijoj
nadležnosti je deo projekta na kome se rizik može
ostvariti. Vlasnik rizika je zadužen da sprovede
preventivne i korektivne mere.
Tabela 2 - Šablon registra rizika
U prelodloženom registru rizika kolona "ukupna vrednost rizika" predstavlja atribut rizika
na osnovu koga će se zaključiti da li se rizik kategoriše kao H (high), M (medium), L
(low). Preporuka projektnom menadžeru jeste da pre pristupanja realizaciji projekta
pokuša da umanji rizike koji su kategorisani kao H rizici. Prema istraživanju
konsultantske kuće Ernst&Young, kod IT projekata, kompleksnost je dimenzija koja
najviše doprinosi rizičnosti projekta (Ernst&Young, 2011). Na Slici 13 prikazan je uticaj
kompleksnosti projekta na nivo rizika, i istaknuti su ključni faktori koji doprinose
kompleksnosti projekta. Neki od bitnijih faktora koji utiču na povećanje kompleknosti (a
samim time i rizika) na projektu su: dugo vreme realizacije projekta, veliki broj članova
projektnog tima, visok nivo inovacija, visok stepen učenja na projektu i visoki sigurnosni
zahtevi.
55
Slika 13 - Uticaj kompleksnosti projekta na rizičnost projekta (Ernst&Young, 2011)
3.2.4 Plan upravljanja zainteresovanim stranama
U fazi planiranja projekta, projektni menadžer bi trebalo da definiše i plan upravljanja
zainteresovanim stranama na projektu. Kako bi se ovaj plan definisao na kvalitetan
način, potrebno je pre svega izvršiti identifikaciju svih zainteresovanih strana za
projekat. Svaku od identifikovanih zainteresovanih strana je zatim potrebno klasifikovati
u određenu klasu, a za svaku klasu definisati i način i dinamiku komunikacije. Na Slici 14
prikazana je matrica uticaja i zainteresovanosti, po osnovu koje se zainteresovane
grupe mogu klasifikovati.
56
Slika 14 - Matrica strategija za upravljanje zainteresovanim stranama na projektu
U Tabeli 3 su date preporuke za upravljanje različitim grupama zainteresovanih strana,
na osnovu nivoa zainteresovanosti i uticaja svake od grupa. Na različitim projektima,
različite organizacione celine i pojedinci će pripadati svakoj od grupa.
Grupa zainteresovanih
strana
Opis grupe i preporuke za upravljanje svakom od grupa
Nizak uticaj - Niska
zainteresovanost
(Nadgledati)
Ovu grupu često čini šira javnost, zaposleni u drugim
organizacionim celinama i ostali pojedinci koji nemaju
direktnog interesa na projektu, ali ni veliki uticaj na isti.
Projektni tim bi trebalo da bude informisan o stavovima
ove grupe - Poželjno je vršiti povremeno nadgledanje i
"plitko" istraživanje stavova, kao i informisanje ove grupe
putem newsletter-a, web sajta itd.
Cilj - Migrirati ovu grupu u grupu sa visokim nivoom
zainteresovanosti.
Nizak uticaj - Visoka Ovu grupu često čine vendori, kupci, korisnici, tim za
podršku rešenju i druge grupe i pojedinci koji su
57
zainteresovanost
(Informisati)
zainteresovani za projekat, ali nemaju direktnog uticaja na
isti.
Poželjno je detaljno istraživati stavove ove grupe (sastanci
i intervjui sa relevantnim predstavnicima) i često informisati
putem standardnih kanala. Takođe je potrebno povremeno
uključivati predstavnike ove grupe na manje kritičnim
projektnim aktivnostima.
Cilj - Održati nivo zainteresovanosti.
Visok uticaj - Niska
zainteresovanost
(Zadovoljiti potrebe)
Ovu grupu često čine predstavnici visokog menadžmenta,
regulatorna tela i finansijske institucije.
Poželjno je voditi računa o svim potrebama i stavovima
ove grupe, kao i sprovoditi aktivnosti koje mogu povećati
nivo zainteresovanosti za projekat - prezentacije,
radionice, debate.
Cilj - Migrirati ovu grupu u grupu sa visokim nivoom
zainteresovanosti.
Visok uticaj - Visoka
zainteresovanost
(Uključiti u poslovni
proces)
Ovu grupu često čini sponzor projekta, članovi projektnog
tima
Poželjno je ovu grupu uključiti u poslovni proces i procese
donošenja projektnih odluka.
Cilj - Održati nivo zainteresovanosti.
Tabela 3 - Preporuke za upravljanje različitim grupama zainteresovanih strana
Članove tima je veoma bitno upoznati sa planovima projekta, kako bi oni mogli da
razumeju organizaciju na projektu, uloge i odgovornosti i načine na koje će se raditi na
projektu.
Organizovanje prvog sastanka je od velikog značaja. Na prvom sastanku bi trebalo da
budu prisutni svi članovi tima, kao i predstavnici drugih odeljenja u organizaciji. Ovaj
sastanak vodi projektni menadžer na projektu razvoja softvera. Tokom sastanka
projektni menadžer prezentuje detalje projekta, uključujući ključne događaje, kao i
podršku koja je neophodna da bi se projekat uspešno realizovao. Jedan od ciljeva
sastanka je da se obezbedi dokumentovanje učešća svih neophodnih strana na
58
projektu. Na ovaj način postoji pismena saglasnost svih učesnika da će, kada bude bilo
potrebno, učestvovati na projektu i pomoći njegovu realizaciju.
3.3 Preporuke za izvršavanje projekata elektronskog poslovanja
Procesima izvršavanja projekta smatraju se procesi koji se odnose na konkretnu
realizaciju projektnih aktivnosti, a na osnovu kreiranih planova.
Sve aktivnosti koje je potrebno sprovesti na projektu je potrebno delegirati za realizaciju
članovima projektnog tima. Neke od ključnih preporuka za delegiranje aktivnosti na
projektima elektronskog poslovanja su sledeće:
Aktivnosti bi trebalo delegirati članovima tima koji imaju kompetencije potrebne za
realizaciju određene aktivnosti
Pojedinačna aktivnost ne bi trebalo da bude duža od 3 programer dana, kako bi
se progres razvoja svake pojedinačne aktivnosti lakše pratio. Ukoliko je aktivnost
duža od 3 programer dana, potrebno je dalje dekomponovati aktivnost.
3.3.1 Testiranje softvera
Testiranje softvera prestavlja proces pomoću koga se validira ispravnost softvera.
Izvdajaju se dva oblika testiranja i to (Boehm, 1989):
Validacija - proces provere softvera koji utvrđuje da li softver zadovoljava potrebe
korisnika (da li pravimo pravi proizvod?)
Verifikacija - proces provere softvera koji utvrđuje da li softver zadovoljava
postavljenu specifikaciju (da li na pravi način pravimo proizvod)
Kako bi se na najbolji način realizovao proces testiranja, potrebno je definisati testne
scenarije već u momentu definisanja zahteva, odnosno funkcionalne specifikacije. Ovo
je pre svega preporuka za velike i kompleksne projekte elektronskog poslovanja,
obzirom da na ovakvim projektima postoji rizik od izostavljanja jednog ili više testnih
scenarija, ukoliko se definisanje istih ne radi paralelno sa procesom definisanja zahteva.
Automatizovano testiranje softvera ubrzava proces testiranja, i često smanjuje celokupni
trud koji je potrebno uložiti u proces testiranja, ali ipak ne zamenjuje u potpunosti
manualno (ljudsko) testiranje. Određeno vreme manuelnog testiranja je uvek
neophodno, pre svega kod testiranja funkcionalnosti koje nije lako formalizovati za
59
potrebe automatskog testa. Efektivno testiranje se najčešće postiže kombinacijom
manuelnih i automatskih testova. Pre pristupanja automatizaciji testiranja, potrebno je
uraditi analizu isplativnosti automatizacije testa, obzirom da se automatizacija u
najvećem broju slučajeva isplati samo ukoliko postoji potreba za više od 4-6 krugova
testiranja (Deloitte, 2010). Na Slici 15 prikazan je grafikon na kome se vidi kalkulacija
prema kojoj se može zaključiti da li je automatizacija testa isplativa. Sam proces
automatizacije sa sobom nosi jednokratan trošak, dok nakon automatizacije, svaki ciklus
testiranja zahteva minimalan dodatni rad. Sa druge strane, trošak manuelnog testiranja
linearno raste sa brojem ciklusa testiranja. Na osnovu ovoga, možemo zaključiti da se
automatizacija testiranja isplati samo ukoliko se predvidi potreba za većim brojem
ciklusa testiranja.
Slika 15 - Opravdanost automatizovanog testiranja (Deloitte, 2010)
3.4 Preporuke za kontrolu projekata elektronskog poslovanja
Kontrola projekata elektronskog poslovanja predstavlja grupu procesa koja se sprovodi
kontinualno u toku celokupnog trajanja projekta. Svrha sprovođenja procesa kontrole
jeste validacija da li sve se aktivnosti predviđene projektnim planom sprovode na
očekivani način. Procese kontrole bi trebalo sprovoditi za svaku od bitnih celina projekta,
pa se tako izvdajaju:
Kontrola obuhvata
60
Kontrola realizacije
Kontrola troškova
Kontrola kvaliteta
Kontrola rizika
Kako bi bilo moguće sprovesti kontrolu svake grupe aktivnosti na projektu, potrebno je
obezbediti postojanje referentnih vrednosti u odnosu na koje će se raditi provera.
Navedene referentne vrednosti često se nazivaju baseline-om projekta. Baseline
projekta predstavljaju svi planovi kreirani na početku projekta. Na osnovu analize
odstupanja svake pojedinačne aktivnosti od baseline-a, potrebno je pronaći uzrok
odstupanja i zabeležiti varijansu odstupanja. Na velikim projektima praćenje rezultata
svake pojedinačne aktivnosti može biti vrlo zahtevan posao, koji je skoro nemoguće
izvršiti bez pomoći informacionog sistema za pomoć u upravljanju projektima. Za
potrebe praćenja rezultata aktivnosti koriste se KPI sistemi, koji će biti detaljnije
obrađeni.
Imajući u vidu da su projekti elektronskog poslovanja specifični zbog izuzetno visokog
nivoa dinamičnosti, posebna pažnja će biti posvećena kontroli obuhvata projekata
elektronskog poslovanja.
3.4.1 Formiranje KPI sistema za praćenje performansi na projektu
KPI (Key Performance Indicators) ili indikatori ključnih performansi predstavljaju jedan
od najbitnijih alata koji se u praksi koriste kako bi se projekti na efikasan način pratili i
kontrolisali. KPI su zapravo metrike koje projektni menadžeri mogu koristiti za merenje i
analizu ključnih performansi koje prate na projektu. Može se tvrditi da postoji sedam
ključnih oblasti informacija koje su bitne za projekne menadžere i to (Ishigaki & Jones,
2003):
Progres i raspored aktivnosti
Resursi i troškovi
Veličina i stabilnost proizvoda
Kvalitet proizvoda
Performanse proizvoda
Efikasnost tehnologije
Zadovoljstvo kupca/korisnika
61
U Tabeli 4 je dat pregled KPI koji se najčešće koriste na projektima elektronskog
poslovanja.
Grupa KPI Opis KPI
Progres i raspored
aktivnosti
Broj utrošenih radnih sati u odnosu na broj planiranih
radnih sati
Procenat dostignutih milestone-ova projekta
Procenat milestone-ova projekta dostignutih u planiranom
roku
Procenat milestone-ova projekta dostignutih nakon
planiranog roka
Resursi i troškovi Broj radnih sati po svakom angažovanom resursu (ukazuje
na preveliku i premalu opterećenost resursa)
Odnos planiranog i utrošenog broja sati po svakom
resursu (ukazuje na kvalitet procena koje resurs daje)
Odnos utrošenih i planiranih sredstava
Broj radnih sati utrošenih na rešavanje problema u toku
internog testa
Broj radnih sati utrošenih na rešavanje primedbi sa
korisničkog testa
Veličina i stabilnost
proizvoda
Broj padova sistema u fazi stabilizacije rešenja i nakon
puštanja rešenja u produkciju
Konkretan kvar koji uzrokuje najveći broj padova sistema
(konkretan upit koji lokuje bazu, konkretna situacija u kojoj
dolazi do pada sistema itd)
Kvalitet proizvoda
Broj primedbi korisnika nakon puštanja rešenja u
produkciju
Performanse proizvoda Brzina izvršavanja najbitnijih operacija u rešenju
Maksimalno opterećenje rešenja - maksimalni broj
korisnika koji mogu simultano raditi na rešenju, maksimalni
broj operacija koje se mogu dešavati istovremeno
62
Najzahtevnija operacija - Konkretna operacija koja zahteva
najduže vreme izvršavanja u rešenju ili u najvećem
procentu koristi procesorsku moć
Efikasnost tehnologije Broj problema uzrokovovanih tehničkim ograničenjima
Procenat iskorišćenosti sistemske infrastrukture (baze
podataka, aplikativnog servera, fajl servera itd)
Zadovoljstvo
kupca/korisnika
Broj primedbi u toku rada rešenja
Broj dodatnih zahteva za izmenom/unapređenjem rešenja
Tabela 4 - KPI koji se najčešće koriste na projektima elektronskog poslovanja
Svrha praćenja KPI na projektu jeste pre svega monitoring različitih oblasti projekta, kao
i delovanje na osnovu rezultata KPI. Za svaki KPI preporuka jeste da se definišu zone
prihvatljivosti i to kao:
Zelena zona - vrednost KPI je prihvatljiva i poželjna
Žuta zona - vrednost KPI teži rizičnoj vrednosti
Crvena zona - vrednost KPI je rizična
Ukoliko je KPI u žutoj ili crvenoj zoni potrebno je obratiti pažnju na predmet merenja i
preduzeti mere kako bi se rizik umanjio ili korigovao. Na Slici 16 je prikazana šema koja
ukazuje na dokumente na osnovu kojih se definišu KPI, kao i mere koje se preduzimaju
ukoliko se KPI nađe u žutoj ili crvenoj zoni.
63
Slika 16 - Proces praćenja i kontrole uz pomoć KPI
Osnovne preporuke za kreiranje KPI su sledeće:
KPI-evi moraju biti smisleni korisnicima kojima su namenjeni
Postizanje konsenzusa oko odabira KPI-eva i njihovog korišćenja predstavlja ključni deo
aktivnosti planiranja projekta. Veliki projekti sa velikim brojem internih i eksternih
zainteresovanih strana imaće veliki broj potreba, pa je neophodno selektivno
obaveštavati svaku od zainteresovanih strana samo o onim KPI-evima koji su za nju
relevantni. Takođe, veliki uticaj na izbor KPI-eva vrši i delatnost kojom se kompanija
bavi. Neophodno je unapred planirati i obezbediti kapacitete za izveštavanje svih
zainteresovanih strana o definisanim KPI-evima.
64
KPI-evi moraju biti merljivi
KPI-evi mogu biti značajna alatka za izricanje nagrada i penala kod projekata koji
uključuju formalne ugovore. Potrebno je podeliti KPI-eve na kvantitativno merljive i
kvalitativno merljive.
KPI-eve bi trebalo formirati tako da prate očekivane benefite projekta
Svrha postojanja projekta je benefit koji se ostvaruje ostvarivanjem njegovih ciljeva.
Benefiti koje projekat donosi bi trebalo da budu definisani u odobrenoj business case
analizi. Ako se za merenje uspešnosti nekog projekta koriste KPI-evi, oni bi trebalo da
budu pokretačke akcije koje se fokusiraju na dugovečnost finalnog proizvoda koji je
rezultat projekta.
KPI-evi bi trebalo da budu miks između indikatora ostvarenog i prediktivnih
indikatora
Indikatori ostvarenog daju informacije o stvarima koje su se već desile, odnosno o
prošlim aktivnostima. Prediktivni indikatori daju podatke koji nagoveštavaju kako će se
stvari odvijati u budućnosti, odnosno nivo rizika koji postoji na osnovu trenutnog znanja.
Previše indikatora ostvarenog mogu dovesti do reaktivnog ponašanja, umesto
proaktivnog. Previše prediktivnih indikatora mogu razblažiti uticaj ključnih rizika.
KPI-evi se moraju slagati sa ciljevima programa i/ili strategije kompanije
Veliki broj projekata su samo komponente nekog većeg programa ili čak portfolia.
Korisno je razmotriti definisanje KPI-eva koji se mogu preneti "na više".
KPI-evi se moraju redovno meriti
Neophodno je redovno redovno meriti i izveštavati o statusu KPI-eva. Postoji veliki broj
načina za to, a najčešće se koriste crvena, žuta i zelena boja kao indikatori statusa KPI-
a u odnosu na već dogovoreni kriterijum.
Merenje KPI-eva treba nastaviti nakon puštanja projekta u produkciju
KPI-evi koji su korišćeni za merenje u fazi egzekucije projekta mogu se razlikovati od
KPI-eva koji se definišu nakon puštanja projekta u produkciju. Moguće je definisati KPI-
eve koji se fokusiraju na benefite krajnjeg proizvoda/usluge, pa mogu preći u sledeću
fazu nakon završetka projekta.
65
3.4.2 Kontrola obuhvata projekta elektronskog poslovanja
Projekti elektronskog poslovanja su specifični zbog veoma dinamičnog okruženja u
kome se obično sprovode. Obzirom da se u implementaciji projekata elektronskog
poslovanja koriste savremene informacione tehnologije koje se izuzetno brzo menjaju, a
rešenja se prave za vrlo zahtevne korisnike, neretko dolazi do potrebe za izmenom
obuhvata projekta. Do izmene obuhvata projekta može doći podnošenjem zahteva za
izmenom na projektu, podnošenjem zahteva za dopunom, ili spontanim proširenjem
zahteva. Poslednje navedeni razlog predstavlja jedan od rizika koji u praksi često
dovode do kašnjenja u planiranoj realizaciji. Preporuka je postaviti sledeća pitanja
prilikom analize zahteva za promenom obuhvata na projektu:
Koja je priroda zahteva za promenom i koliko on odstupa od planiranog?
Preporuka je raditi ovo korišćenjem gep analize.
Koliko dodatnog vremena je potrebno za realizaciju zahteva za promenom?
Da li ovaj zahtev utiče na aktivnosti na kritičnom putu projekta i da li je potrebno
da na njemu rade kritični resursi?
Koja je prioritizacija ovog zahteva u odnosu na ostale projektne aktivnosti?
Da li se ovaj zahtev uklapa u strateški okvir planiranog rešenja?
Da li i u kojoj meri ovaj zahtev utiče na business case projekta?
Ukoliko se prihvati implementacija zahteva za izmenom koji će uticati na obuhvat
projekta, potrebno je revidirati projektnu dokumentaciju u skladu sa prihvaćenom
izmenom. Minimalno, potrebno je uraditi reviziju:
Business case-a inicijative
Vremenskog plana projekta
Plana troškova projekta
Plana upravljanja rizicima
3.4.3 Osiguranje kvaliteta softvera
Osiguranje kvaliteta softvera (Software quality assesment) predstavlja planirani,
sistematični patern svih potrebnih aktivnosti koje se sprovode kako bi se obezbedio
adekvatan nivo pouzdanosti da je proizvod u skladu sa tehničkim zahtevima. Osnovne
66
provere koje se vrše u okviru osiguranja kvaliteta proizvoda su (ESA Board for Software
Standardisation and Control (BSSC), 1995):
Provera da li su planovi definisani u skladu sa relevantnim standardima
Provera da li se procedure izvršavaju u skladu sa planovima
Provera da li se proizvodi implementiraju u skladu sa standardima
Osoba koja se bavi osiguranjem kvaliteta na softverskom projektu mora u ranoj fazi
projekta definisati koje sve provere će se vršiti na projektu. Vrsta provera koja će se
vršiti zavisi od vrste i prirode projekta. Jedna od najbitnijih provera koja se sprovodi na
projektu jeste provera rizičnih oblasti. Neke od rizičnih oblasti koje se najčešće javljaju
na softverskim projektima su nove oblasti u kojima razvojni timovi nemaju iskustva,
oblasti koje zahtevaju ručne intervencije i oblasti vezane za aktivnosti koje se izvršavaju
u organizacionim celinama niskog nivoa organizacione zrelosti. Dobra praska
predstavlja formiranje registra rizika, na osnovu koga bi se vršila identifikacija, praćenje i
upravljanje rizicima koji se javljaju na softverskim projektima. Registar rizika predstavlja
alat za upravljanje rizicima koji pomažu pojedincima i grupama da na jasan način
sagledaju i upravljaju rizicima.
3.5 Preporuke za zatvaranje projekata elektronskog poslovanja
Procesi zatvaranja projekta sprovode se kada se projekat nađe u jednoj od sledeće tri
situacije:
Sve projektne aktivnosti su uspešno realizovane, i zahtevalac projekta je potvrdio
sve rezultate projekta
Realizacija projekta je otkazana
Projekat je pripojen nekom drugom projektu
U slučaju da je projekat uspešno realizovan, potrebno je da zahtevalac projekta potvrdi
sve rezultate projekta. Kako bi se potvrđivanje sprovelo na najbolji način, preporuka
jeste da se već u fazi iniciranja projekta definišu izlazni rezultati projekta (deliverable),
koje zahtevalac na kraju projekta očekuje. U Tabeli 5 dat je predlog šablona za
dokumentovanje izlaznih rezultata projekta elektronskog poslovanja sa primerima.
67
Naziv i opis izlaznog rezultata
(deliverable)
Tip izlaznog rezultata Datum prijema i
organizaciona celina
odgovorna za prijem
Detaljan opis šta se očekuje
kao rezultat projekta.
Npr. Modul za automatsko
slanje mailova; Izveštaj svih
notifikacija poslatih korisnicima;
Korisničko uputstvo za
korišćenje rešenja; Uputstvo za
arhiviranje
Neki od čestih tipova
izlaznih rezultata su:
Aplikativna funkcionalnost
Pozadinski džob
Migrirani podaci
Sistemska dokumentacija
Korisnička dokumentacija
Izveštaji
Koja organizaciona
celina je odgovorna
da izvrši korisnički
test i da potvrdi da je
izlazni rezultat u
skladu sa očekivanim
Tabela 5 - Šablon za specifikaciju očekivanih izlaznih rezultata projekta
Faza zatvaranja projekta predstavlja finalnu fazu u kojoj se finalizuju sve projektne
aktivnosti i zatvaraju sve otvorene projektne teme. Osim formalno - administrativnih
poslova koji se odvijaju u fazi zatvaranja projekta, u ovoj fazi sprovode se i finalni
procesi analize/kontrole, kao i procesi sistematizacije naučenog na osnovu projekta.
Sistematizacija načenog se najčešće radi kroz kreiranje dokuementa lessons-learned
(naučene lekcije). Kreiranje ovog dokumenta predstavlja dobru praksu upravljanja
projektima. Lessons-learned dokument je dokument u kome bi trebalo navesti sva
iskustva (pozitivna i negativna) koja bi mogla koristiti kolegama ili samom projektnom
menadžeru na narednim projektima. Za svako od iskustava, trebalo bi navesti kratku
situacionu analizu i sve faktore koji su doveli do dobrog ili lošeg rezultata.
U fazi zatvaranja projekta, vrlo su bitna sledeće dve grupe upravljanja projektom:
Upravljanje ugovorima (ukoliko je projekat uključivao vendora sa kojim je bio
sklapan ugovor)
Upravljanje integracijom projekta - podrazumeva integraciju rezultata projekta sa
postojećim sistemom u tehničkom, pravnom, organizacionom i administrativnom
smislu.
68
3.5.1 Validacija i analiza postavljenih projektnih ciljeva
U slučaju da je projekat uspešno realizovan (zahtevalac je potvrdio sve rezultate
projekta), preporuka jeste da se izvrši evaluacija postavljenih projektnih ciljeva i to tako
što će se:
Inicijalno planirani ciljevi uporediti sa ostvarenim rezultatima
Izvršiti analiza KPI za svaki cilj koji nije u potpunosti ostvaren, kako bi se utvrdilo
šta je doprinelo slabom rezultatu
Preporuka je uraditi analizu ostvarenja ciljeva za svaku pojedinačnu fazu i deo projekta.
Na osnovu ovako urađene analize, može se steći slika gde su postojali propusti u
projektu. Ovakva analiza predstavlja osnov za učenje na osnovu realizovanog projekta.
Primer sprovedene analize ostvarenja ciljeva za pojedinačne delove više projekata iz
projektnog protfolija dat je na Slici 17.
Slika 17 - Analiza ostvarenja ciljeva za pojedinačne delove projekta iz projektnog portfolija
69
4 Studijski primer - upravljanje projektom u oblasti
kartičarskog poslovanja
4.1 Uvod u kartičarsko poslovanje
Kartičarskim poslovanjem se smatra svaki oblik poslovanja, kupovine i prodaje pomoću
platnih kartica. Plaćanje platnim karticama je danas dominantan oblik bezgotovinskog
plaćanja, i svakako predstavlja jednu od oblasti bankarstva sa velikim potencijalom. Na
Slici 18 grafički je prikazan opšti način rada kartičarskog poslovanja. Kao što se vidi na
prikazu, kartičarsko poslovanje čine tri osnove grupe procesa i to:
Procesi autorizacije platnih kartica
Kliring procesi
Setlment procesi
U navedenim procesima učestvuju sledeći akteri:
Korisnik platne kartice (cardholder) - Osoba koja koristi platnu karticu kako bi
napravila transakciju;
POS uređaj - Uređaj na kome se koristi platna kartica;
PGW aplikacija (payment gateway) - Aplikacija za e-commerce;
Trgovac (merchant) - Prodavac koji po ugovoru sa bankom prihvata transakcije
platnim karticama;
Prodajno mesto (point of sale) - Odnosi se na konkretno prodajno mesto trgovca
na kome se nalazi POS uređaj;
Banka trgovca (merchant's bank) - Banka koja sa trgovcem sklapa ugovor o
prihvatanju transakcija platnim karticama;
Banka korisnika platne kartice (cardholder's bank) - Banka koja sa korisnikom
platne kartice sklapa ugovor o korišćenju platne kartice;
Kartičarska organizacija/ Platni sistem (payment system) - Mreža organizacije
koja omgućava bezgotovinsko plaćanje - najpoznatiji su Master Card, Visa,
Diners, American Express;
Proces autorizacije platnih kartica, prikazan na prvoj celini Slike 18, odnosi se na
aktivnosti koje se sprovode u cilju autorizacije transakcije napravljene platnom karticom.
70
Pojam autorizacije platne kartice podrazumeva odobrenje potrošnje platnom karticom.
Proces autorizacije počinje tako što korisnik platne kartice koristi karticu za plaćanje na
prodajnom mestu (POS terminal, PGW), nakon čega uređaj na kome je kartica
korišćena šalje upit banci trgovca, koja upit prosleđuje kartičarskoj organizaciji.
Kartičarska organizacija utvđuje banku korisnika kartice, kojoj zatim šalje podatke o
transakciji. Na osnovu podataka o transakciji, banka korisnika odobrava ili odbija
predmetnu transakciju. Ovaj odgovor banka korisnika šalje kartičarskoj organizaciji, koja
dalje odgovor prosleđuje banci trgovca, da bi finalno odgovor bio primljen na uređaj na
kome je transakcija inicirana. Na uređaju će biti vidljiva informacija o rezultatu
autorizacije (odobrena/odbijena) i na osnovu nje će korisniku biti odštampan slip. Na
Slici je prikazan pojednostavljen proces autorizacije, koji je u praksi dodatno
zakomplikovan izmenama u rutiranju. Izmene u rutiranju se vrše kako bi se uštedelo na
protoku saobraćaja i ubrzalo vreme za koje transakcija bude odobrena/odbijena.
Na osnovu uloga koje se javljaju u procesu autorizacije transakcija platnim karticama,
značajna je podela svih kartičarskih poslova na:
Izdavanje (Issuing) - svi poslovi banke koji se odnose na izdavanje platnih kartica
i ostvarenje prihoda po osnovu izdavanja platnih kartica korisnicima kartica
Prihvatanje (Acquiring) - svi poslovi banke koji se odnose na prihvatanje platnih
kartica na prodajnim mestima trgovaca sa kojima banka ima ugovor
Banka korisnika platne kartice se zove još i banka izdavalac (issuer bank), dok se banka
trgovca naziva još i banka prihvatilac (acquirer bank).
Kako bi se obračunali troškovi i prihodi svim učesnicima u procesu autorizacije
transakcija, sprovode se procesi kliringa (clearing) i setlmenta (settlement). Kliring se
odnosi na proces razmene informacija o svim transakcijama koje su se desile na strani
prihvatilaca platnih kartica. Jednostavnije rečeno, sve banke šalju informacije o
transakcijama koje su se desile na njihovim prodajnim mestima, na osnovu čega
kartičarske organizacije pripremaju podatke o svim transakcijama izvršenim karticama
banke izdavaoca, i svakoj pojedinačnoj banci izdavaocu dostavljaju ovaj izveštaj. Prema
njemu, banke izdavaoci mogu zadužiti korisnike platnih kartica. Osim toga, kartičarske
organizacije prave i izveštaj o "prebijanju", na kome se vide međusobna potraživanja
banke i kartičarske organizacije. Setlment proces se odnosi na drugu stranu ovog
71
procesa. Setlment počinje tako što banka izdavalac plaća potreban iznos kartičarskoj
organizaciji, a kartičarska organizacija grupiše sve uplate namenjene jednoj banci
prihvatiocu.
Dodanu kompleksnost u ovaj proces unosi pojam storno transakcije, koja funkcioniše
kao negativna tranakcija, tako da se u svakom koraku procesa mora raditi i dodatno
prebijanje koje reguliše storno transakcije.
Imajući u vidu da su procesi kartičarskog poslovanja procesi koji barataju velikom
količinom podataka, skoro svi koraci u procesima se dešavaju asinhrono, što stvara
dodatan rizik i zahteva visok nivo logičkog projektovanja.
Obzirom da se sva komunikacija i prenos informacija (od POSa do banke, od banke do
kartičarske organizacije itd) radi elektronskim kanalima, i to u najvećem broju slučajeva
preko interneta, može se smatrati da je kartičarsko poslovanje uopšteno gledano vrsta
elektronskog poslovanja.
Projekti u kartičarskom poslovanju odnose se najčešće na
Aktivnosti uvođenja novih kartičarskih proizvoda
Uvođenje novih modula za operativno upravljanje kartičarskim poslovanjem
Izmenu postećih sistema za podršku kartičarstvu
73
4.2 Studijski primer - implementacija novog proizvoda - Gift kartica
Gift kartica predstavlja vrstu nepersonalizovane platne kartice za koju je vezan inicijalni
depozit, a koji se naknadno može uvećavati uplatom na šalteru banke. Na tržištu postoje
dva tipa gift kartica, i to:
Otvorena petlja (open loop)
Zatvorena petlja (closed loop)
Gift kartice otvorene petlje su kartice banke koje se mogu koristiti na bilo kom prodajnom
mestu, dok su gift kartice zatvorene petlje kartice banke koje se mogu koristiti samo kod
jednog ili specifične grupe trgovaca. Gift kartice zatvorene petlje najčešće nastaju iz
partnerstva banke i trgovca ili udruženja trgovaca.
Na razvijenijim stranim tržištima gift kartice imaju izuzetan potencijal. Prema podacima
najvećeg kartičarskog procesora FirstData, potencijal gift kartica na tržištu Sjedinjenih
Američkih Država, ogleda se u sledećem (First Data, 2012):
U sezoni praznika 2012, putem gift kartica je potrošeno oko 43 milijarde dolara
21% potrošača je kupilo barem jednu gift karticu
73 dolara se u proseku trošilo po gift kartici otvorene petlje
93% potrošača bi više volelo da dobije gift karticu sa 25 dolara, nego poklon
vredan 25 dolara
Studijski primer koji će biti izložen u ovom radu predstavlja projekat implementacije
proizvoda gift kartice otvorene petlje, kao standardnog proizvoda banke. U pitanju je
fiktivni primer projekta, predložen za realizaciju u fiktivnoj banci na srpskom tržištu.
4.2.1 Inicijacija projekta
Poslovna ideja iza identifikovane inicijative jeste uvođenje novog proizvoda u ponudu
banke i to gift kartice otvorene petlje.
Funkcionalni zahtev u okviru koga je definisano šta je potrebno uraditi da bi se proizvod
uveo u ponudu banke je sledeći:
Potrebno je izvršiti koordinaciju sa odabranom kartičarskom organizacijom.
Potrebno je da se kod kartičarske organizacije otvori proizvod, pri čemu će
kartičarska organizacija obezbediti IIN (Issuer Identification Number). IIN je
74
šestocifreni broj koji jedinstveno identifikuje banku i proizvod banke. (Broj kartice
počinje IIN brojem)
Potrebno je formirati proizvod u ponudi banke i to tako da proizvod čini kartica
koja nije personalizovana, sa definisanim tarifnim uslovima.
Potrebno je kreirati dizajn plastike
Business case ovog projekta se zasniva na projektovanom porastu prihoda, te je stoga
ključni argument ovog business case-a prostor za inovacije i rast prihoda. U Tabeli 6,
prikazani su elementi koji ulaze u ovu business case analizu. Business case analiza,
kao i cost benefit analiza koja je prati rađene su na 5 godina, pri čemu je računata stopa
poreza na dobit aktuelna u Republici Srbiji (10%), kao i linearna stopa amortizacije
softvera od 20% godišnje.
Aspekt Elementi koji ulaze u business case
CAPEX (Capital
Expenses)
Da li predloženo rešenje zahteva investiciju?
o Investicija u razvoj proizvoda će se sprovesti kroz
angažovanje interno dostupnih razvojnih resursa.
Procenjeni trošak angažovanja internih resursa je
1.150.000 RSD
o Biće neophodna investicija za razvoj dizajna
plastika
OPEX (Operational
Expenses)
Da li predloženo rešenje zahteva ulaganje u operativne
troškove?
o Rešenje neće inicirati značajne dodatne redovne
operativne troškove
o Izrada kartice košta 100 RSD po kartici
Promena prihoda Da li predloženo rešenje uzrokuje promenu u prihodima
(porast ili pad)?
o Očekuje se prodaja 5000 gift kartica u prvoj godini, i
porast broja kartica od 10% svake naredne godine
o Očekivani prihod po kartici jeste 200 RSD za
aktivaciju i 100 RSD za korišćenje kartice
75
Promena nivoa rizika Da li predloženo rešenje uzrokuje promenu u nivou rizika
(u odnosu na postojeći sistem)?
o Rešenje neće uticati na nivo rizika
Tabela 6 - Elementi koji su deo business case analize
u Tabeli 7 je prikazana cost benefit analiza urađena u okviru business case-a. Rezultati
na osnovu projektovanih izmena koje će uzrokovati implementacija projekta se ogledaju
u finansijskim pokazateljima od kojih su najznačajniji:
NPV - Iznosi 3.051.460 RSD, što govori da će projekat vredeti 3.051.460 RSD za
pet godina
IRR - Iznosi 84.65%, što znači da bi diskontna stopa morala biti 84.65% da bi se
neto sadašnja vrednost projekta smanjila na 0 RSD. Imajući u vidu da se
diskontne stope najčepće uzimaju iz opsega (5%-20%), možemo smatrati da je
ovo je prilično dobar rezultat.
PBP - Iznosi 1,36 godina, što ukazuje na činjenicu da novac neće biti "zarobljen"
u investiciji duži vremenski period.
2014 2015 2016 2017 2018
Softver (5 years) cap.ex.
1.150.000 0,0 0,0 0,0 0,0
Ukupni Capex
1.150.000,0 0,0 0,0 0,0 0,0
Ukupna amortizacija
230.000,0 230.000,0 230.000,0 230.000,0 230.000,0
Ukupni Opex
500.000 550.000 605.000 665.500 732.050
Povećanje prihoda
1.500.000,0 1.650.000,0 1.815.000,0 1.996.500,0 2.196.150,0
Bruto margina
1.500.000,0 1.650.000,0 1.815.000,0 1.996.500,0 2.196.150,0
Ukupni Opex
500.000,0 550.000,0 605.000,0 665.500,0 732.050,0
EBIT
770.000,0 870.000,0 980.000,0 1.101.000,0 1.234.100,0
Porez
69.942,8 79.026,3 89.018,1 100.009,1 112.099,2
Neto Profit
700.057,2 790.973,7 890.981,9 1.000.990,9 1.122.000,8
Neto Profit + Amortizacija
930.057,2 1.020.973,7 1.120.981,9 1.230.990,9 1.352.000,8
Ukupni Capex
1.150.000,0 0,0 0,0 0,0 0,0
Neto Cash flow
-219.942,8 1.020.973,7 1.120.981,9 1.230.990,9 1.352.000,8
Kumulativni Cash flow
-219.942,8 801.031,0 1.922.012,9 3.153.003,8 4.505.004,6
NPV [RSD]
3.051.460,3 IRR [%] 84,65% PBP
[years] 1,36
Tabela 7 - Cost benefit analiza
76
4.2.2 Planiranje projekta
Vremensko planiranje projekta izvršeno je uz pomoć softverskog alata Microsoft Project.
Projektni tim je izvršio detaljniju dekompoziciju aktivnosti koje je potrebno sprovesti u
toku implementacije projekta, na osnovu čega su eksperti iz domenskih oblasti dali
procene trajanja vremena za svaku od aktivnosti. U trajanje svake od aktivnosti
uračunata je rezerva za upravljanje aktivnostima od 10%. Na Slici 19 prikazan je
vremenski plan sa specifikacijom resursa kreiran u Microsoft Project alatu.
Slika 19 - Vremenski plan projekta u MS Project-u
Na Slici 20 se detaljnije vidi koje aktivnosti su planirane kojim resursima, koje aktivnosti
su međusobno zavisne i koje aktivnosti se nalaze na kritičnom putu projekta. Obzirom
da je u pitanju projekat sa malim brojem aktivnosti, ovo je lako uočljivo, ali bi za svaki
kompleksniji projekat bilo neophodno uraditi detaljniju analizu koje aktivnosti su kritične.
77
Slika 20 - Specifikacija projektnih aktivnosti iz MS Project-a
Plan troškova projekta se inicijalno formira na osnovu urađenog business case-a odakle
se mogu videti planirani Capex i Opex na projektu. Ukoliko je u pitanju višegodišnji
projekat, ili projekt koji će se sprovoditi u više planskih perioda, potrebno je pre svakog
planskog perioda dostaviti projekciju trošenja planiranog budžeta. Ukoliko je utrošak u
tekućem planskom periodu manji od namenjenog, u nekim organizacijama se praktikuje
"carry over", odnosno prenošenje dela nepotrošenog budžeta u sledeći planski period.
U nastavku je definisan registar rizika koji obuhvata osnovni skup rizika i aktivnosti za
upravljanje njima. Za potrebe ovog projekta kategorije rizika definisane su kao:
L (low) - nizak rizik, za vrednosti ukupne vrednosti rizika manje od 0,21
M (medium) - srednji rizik, za vrednosti ukupne vrednosti rizika od 0,21 do 0,51
H (high) - visok rizik, za vrednosti ukupne vrednosti rizika od 0,51
78
Šifra rizika GIFT001
Opis rizika Rizik da će biti neophodno dodatno vreme za razvoj. Obzirom da
nikada nije sprovođen sličan projekat, kvalititet inicijalne procene je
neizvesan.
Verovatnoća
ostvarenja rizika
0.4
Uticaj rizika na
projekat
0.5 Ukupna vrednost
rizika
0.2
Kategorija rizika L
Preventivne mere Uspostavljanje KPI-eva koji će da prate validnost procena (inicijalna
procena/utrošeno vreme). Ukoliko se primeti nevalidnost inicijalnih
procena, biće inicirana revizija potrebnog vremena.
Korektivne mere Ukoliko dođe do ostvarenja rizika, potrebno je komunicirati sa svim
relevantnim zainteresovanim stranama. Dalje, potrebno je izvršiti
replaniranje i eventualno dodavanje resursa potrebnih za realizaciju
projekta.
Vlasnik rizika Odeljenje za razvoj
Šifra rizika GIFT002
Opis rizika Rizik od odlaganja definisanih projektnih rokova zbog potrebe da se
razvojni resursi angažuju na drugim projektima visokog prioriteta.
Verovatnoća
ostvarenja rizika
0.5
Uticaj rizika na
projekat
0.5 Ukupna vrednost
rizika
0.25
Kategorija rizika M
Preventivne mere Održavanje informativnih sastanaka u okviru kancelarije za projekte
kako bi se visoko prioritetni projekti pravovremeno identifikovali.
Korektivne mere Ukoliko dođe do ostvarenja rizika, potrebno je komunicirati sa svim
relevantnim zainteresovanim stranama. Dalje, potrebno je izvršiti
replaniranje i eventualno dodavanje resursa potrebnih za realizaciju
projekta.
79
Vlasnik rizika Odeljenje za razvoj
Šifra rizika GIFT003
Opis rizika Rizik od produžetka vremena potrebnog za korisnički test zbog
velikog broja primedbi
Verovatnoća
ostvarenja rizika
0.3
Uticaj rizika na
projekat
0.5 Ukupna vrednost
rizika
0.15
Kategorija rizika L
Preventivne mere Koristiti unit testove tokom razvoja i detaljno validirati funkcionalnu
specifikaciju pre početka, sa zahtevaocem projekta. Uspostavljanje
KPI-a koji prati broj korisničkih primedbi.
Korektivne mere Angažovanje resursa na ispravkama primedbi sa korisničkog testa.
Vlasnik rizika Projekt menadžer
Šifra rizika GIFT004
Opis rizika Rizik da kartičarska organizacija neće biti u stanju da ispuni zahteve
za otvaranje proizvoda
Verovatnoća
ostvarenja rizika
0.4
Uticaj rizika na
projekat
0.9 Ukupna vrednost
rizika
0.36
Kategorija rizika M
Preventivne mere Pre početka projekta poslati RFI kartičarskoj organizaciji.
Korektivne mere Izmeniti funkcionalnu specifikaciju ili podneti isti zahtev drugoj
kartičarskoj organizaciji
Vlasnik rizika Zahtevalac projekta
Tabela 8 - Registar rizika za projekat implementacije gift kartica
U okviru planiranja projekta, izvršeno je i planiranje upravanja zainteresovanim
stranama. U Tabeli 9 navedene su identifikovane zainteresovane strane na projektu.
Grupa zainteresovanih Opis grupe i preporuke za upravljanje svakom od grupa
80
strana
Nizak uticaj - Niska
zainteresovanost
(Nadgledati)
Zaposleni u banci, partneri banke, vendori
Nizak uticaj - Visoka
zainteresovanost
(Informisati)
Trgovci koji će prihvatati gift kartice, služba za
marketing i komunikacije
Visok uticaj - Niska
zainteresovanost
(Zadovoljiti potrebe)
Kartičarska organizacija, Narodna banka Srbije, pravna
služba, compliance, odeljenje za sigurnost
Visok uticaj - Visoka
zainteresovanost
(Uključiti u poslovni proces)
Zahtevalac projekta, članovi projektnog tima,
menadžment banke
Tabela 9 - Identifikacija zainteresovanih strana za projekat implementacije gift kartica
4.2.3 Izvršavanje projekta
Izvršavanje ovog projekta podrazumeva angažovanje 3 različite radne jedinice:
Odeljenja razvoja, interno u Banci
Koordinatora komunikacije sa kartičarskom organizacijom
Dizajn agencije
Obzirom da je dizajn agencija eksterni partner, potrebno je obratiti posebnu pažnju na
koordinaciju aktivnosti eksternog partnera i internih izvršilaca. Kao mera predostrožnosti,
eksterni partner na ovom projektu je angažovan značajno ranije, kako bi se ostavilo
rezervno vreme za eventualne ispravke, korekcije ili kašnjenja.
U ovom projektu sprovodiće se tri zasebna procesa testiranja i to:
Interno testiranje (interno razvijenog softvera)
Korisničko testiranje (interno razvijenog softvera)
Korisničko testiranje eksterno razvijene funkcionalnosti
81
Korisničko testiranje eksterno razvijene funkcionalnosti se odnosi na testiranje dizajna
plastike koje predlaže dizajn agencija. Za softverski deo testa, biće kreiran testni plan
koji treba da obuhvati:
Opis testnog procesa - Potrebno je popuniti šifru i naziv projekta koji je predmet
testiranja, navesti imena programera koji su učestvovali u razvoju funkcionalnosti,
navesti imena učesnika u testiranju, definisati cilj testiranja, a po završenom
testiranju upisati finalni rezultat testiranja. Zadatak učesnika u testiranju je da
popune plan testiranja, izvrše testiranje na osnovu definisanog plana i zapišu
rezultate testiranja na odgovarajuća mesta u planu testiranja.
Test interfejsa i komponenti - Potrebno je napraviti plan testiranja popunjen
stavkama koje se odnose na testiranje interfejsa koji je razvijen, komponenata
koje su korišćene, pojedinačnih funkcija i procedura koje mogu da se testiraju kao
samostalni entiteti. Potrebno je razraditi raznovrsne scenarije interakcije korisnika
sa interfejsom, očekivane i neočekivane unose na korisničkom interfejsu ili ulaze
u procedure i funkcije. U rezultatu je potrebno navesti da li je aplikacija/servis
produkovala korektan rezultat i da li je sistem za obradu grešaka dao adekvatan
odgovor korisniku, odnosno sistemu.
Test baze podataka - Potrebno je napraviti plan testiranja popunjen stavkama
koje se odnose na testiranje objekata baze podataka koji su nastali ili menjani u
procesu razvoja (uskladištene procedure, trigeri, constrainti, defaulti, izračunate
vrednosti, ..). Potrebno je razraditi raznovrsne scenarije interakcije klijentske
aplikacije sa objektima baze podataka. Potrebno je kontrolisati očuvanje
referencijalnog integriteta podataka. Potrebno je izvršiti proveru konzistentnosti
podataka nakon svake akcije testiranja. U rezultatu je potrebno navesti da li je
aplikacija/servis produkovala korektan rezultat u bazi podataka i da li je sistem za
obradu grešaka dao adekvatan odgovor korisniku, odnosno sistemu.
Integracijski test - Potrebno je definisati mesta na kojima razvijene funkcionalnosti
utiču na neke druge postojeće procese. Potrebno je radni list popuniti stavkama u
kojima se opisuje testiranje veze između novorazvijenih i postojećih
funkcionalnosti.
Test sigurnosti - Potrebno je navesti stavke koje se odnose na testiranja kontrola
pristupa razvijenoj funkcionalnosti i njenih delova. Potrebno je testirati
82
bezbednost povezivanja između delova softverske infrastrukture koja je razvijena
ili menjana (način povezivanja klijenta, međuslojeva i servera). Potrebno je
testirati zaštitu poverljivih podataka.
Strest test i test performansi - Potrebno je izložiti funkcionalnost testu u
neočekivanim uslovima: prekid konekcije između delova infrastrukture, obrada
neočekivano velike količine podataka, izlaganje konkurentnoj obradi sa drugim
funkcionalnostima na istim infrastrukturnim resursima.
4.2.4 Kontrola projekta
U odnosu na specifičnosti projekta, identifikovani su KPI-evi koji obavezno moraju biti
deo sistema za praćenje i monitoring projekta, i to:
KPI koji prati procenat utrošenog vremena u odnosu na planirano
KPI koji prati validnosti procena (utrošeno vreme / inicijalna procena). Ukoliko se
primeti nevalidnost inicijalnih procena, biće inicirana revizija potrebnog vremena
KPI-a koji prati broj korisničkih primedbi
KPI koji prati vreme utrošeno na ispravku korisničkih primedbi
U Tabeli XX nalazi se specifikacija identifikovanih KPI za projekat sa definisanim
zonama rizičnosti.
Naziv KPI Zelena zona Žuta zona Crvena zona
KPI koji prati
procenat utrošenog
vremena u odnosu
na planirano po
aktivnosti
KPI <1 1 ≥ KPI ≤ 1,1 KPI > 1,1
KPI koji prati
validnosti procena
(utrošeno vreme /
inicijalna procena)
KPI <1,1 1,1 ≥ KPI ≤ 1,3 KPI > 1,3
KPI-a koji prati broj
korisničkih primedbi
KPI < 3 3 ≥ KPI ≤ 7 KPI > 7
83
KPI koji prati vreme
utrošeno na
ispravku
pojedinačnih
korisničkih primedbi
KPI < 3h 3h ≥ KPI ≤ 5h KPI > 5h
Tabela 10 - Specifikacija KPI sa definisanim zonama rizičnosti
4.2.5 Zatvaranje projekta
Za projekat implementacije gift kartica definisani su rezulati projekta koje će zahtevalac
projekta primiti nakon završetka realizacije projekta. U Tabeli 11 dat je pregled
očekivanih rezulata projekta.
Naziv i opis izlaznog rezultata
(deliverable)
Tip izlaznog rezultata Datum prijema i
organizaciona celina
odgovorna za prijem
Novi proizvod (gift kartica) sa
definisanom tarifom
Aplikativna funkcionalnost Zahtevalac projekta
Funkcionalnost za uručenje gift
kartica
Aplikativna funkcionalnost Zahtevalac projekta
Korisničko upustvo za uručenje
gift kartica
Korisnička dokumentacija Zahtevalac projekta
Validiran dizajn plastike Grafičko rešenje Zahtevalac projekta
Tabela 11 - Očekivani izlazi iz projekta implementacije gift kartice
Na osnovu izlaza specificiranih u tabeli, zahtevalac projekta će biti u stanju da proceni
koji delovi projekta mogu u potpunosti biti primljeni, odnosno zatvoreni. Nakon
zatvaranja svih celina projekta, i prijema svih celina projekta od strane zahtevaoca,
može se pristupiti formalnom zatvaranju projekta.
84
5 Zaključak
Osnove upravljanja projektima se primenjuju na projektima iz različitih oblasti, ali
konkretne aktivnosti upravljanja bi trebalo prilagodili za svaku industriju, prema
specifičnostima iste. Elektronsko poslovanje predstavlja jednu od najdinamičnijih oblasti
poslovanja danas, te je potrebno da i se organizacija projekata u oblasti elektronskog
poslovanja prilagodi ovoj dinamici, kako bi se projekti sprovodili na uspešan način. U
projektima elektronskog poslovanja, promene su skoro neizostavne na svakom projektu.
Iz ovog razloga, neophodno je upravljati promenama i planirati promene, kako bi se
projekat realizovao i ispunio postavljene ciljeve.
Pored upravljanja projektom u svim fazama upravljanja projektima u elektronskom
poslovanju, veoma je bitno da projektni menadžer poseduje i znanje iz oblasti ljudskih
resursa. Kvalitetni ljudski resursi su neprocenjivo važni za organizaciju projekta. Iz tog
razloga je veoma bitno održavati motivisanost tima i podsticati ga da svoj maksimum.
Upravljanje projektima predstavlja budućnost elektronskog poslovanja, što je ujedno i
razlog zašto se sve veći broj kompanija projektno orijentiše kada su u pitanju aktivnosti
vezane za savremene tehnologije. Imajući ovo u vidu, reklo bi se da je projektna
orijentacija u elektronskom poslovanju najbolji izbor, i izbor za koji već posedujemo
potrebne metodologije i znanja, ali na žalost brojevi govore drugačije. Prema istraživanju
konsultantske kuće McKinsey iz 2012. godine, veliki IT projekti u 45% slučajeva ne budu
realizovani u okviru planiranog budžeta, a u 7% slučajeva ne budu realizovani na vreme
(McKinsey&Company, 2012). Ovo i slična istraživanja govore o potrebi za dodatnim
struktuiranjem i razradom metodologija i preporuka za upravljanje projektima, pre svega
u tehnološki intenzivnim oblastima.
85
6 Literatura
Jovanović, P., Petrović, D., Obradović, V., & Mihić, M. (2007). Metode i tehnike
projektnog menadžmenta. Beograd: Fakultet organizacionih nauka.
Basu, A., & Muylle , S. (2007). How to Plan E-Business Initiatives in Established
Companies. In MIT, MIT Sloan Management Review (Vol. 49).
Beecham, S., Baddoo, N., Hall, T., Robinson, H., & Sharp , H. (2008). Motivation in
software engineering: a systematic literature review. Information and Software
Technology , 50 (9-10), 860.
Besanko, D., Dranove, D., & Shanley, M. (1999). Economics of Strategy. New York:
John Wiley & Sons.
Boehm, B. W. (1989). Software Risk Management. IEEE Computer Society Press .
Brealey, R., & Myers , S. (1996). Principles of corporate finance. New York: McGraw-
Hill.
Brooks, F. P. (1987). No silver bullet essence and accidents of software engineering.
IEEE Computer , 20 (4).
Cardozo, E. L., & de Villiers, D. J. (2003). Project planning best practices. The Rational
Edge .
Centers for Disease Control and Prevention. (2006). CDC Unified Process Practices
Guide - Project Close Out. Centers for Disease Control and Prevention.
ESA Board for Software Standardisation and Control (BSSC). (1995). Guide to software
quality assurance. European Space Agency. Noordwijk, The Netherlands: ESA
Publications Division.
Ernst&Young. (2011). Insights on governance, risk and compliance. Ernst&Young.
Deloitte. (2010). Quality Assurance: Software testing is easy ...and other myths. Deloitte
& Touche .
Diallo, A., & Thuillier, D. (2003). The success dimensions of international development
projects: the perceptions of African project coordinators. International Journal of Project
Management .
86
First Data. (2012). Consumer Insights into the U.S. Gift Card Market: 2012. First Data.
Gartner. (2003). IT Spending: How Do You Stack Up? Gartner.
IBM. (2001). IBM @server iSeries e-business Handbook. Retrieved September 7, 2013,
from http://www.redbooks.ibm.com/redbooks/pdfs/sg246711.pdf
International Y2K Cooperation Center. (2000). International Y2K Cooperation Center
Records. Retrieved 2013 йил 11-October from
http://discover.lib.umn.edu/cgi/f/findaid/findaid-
idx?c=umfa;cc=umfa;rgn=main;view=text;didno=cbi00153
Ishigaki, D., & Jones, C. (2003). Practical Measurement in the Rational Unified Process.
Rational Software .
IT Governance Institute. (2006). Enterprise Value: Governance of IT Investments, The
Business Case. IT Governance Institute .
Jeffery , M. (2004). Return on Investment Analysis for E-business Projects. In The
Internet Encyclopedia. Northwestern University.
Jeffery, M., & Leliveld, I. (2004). Best Practices in IT Portfolio Management. MIT Sloan
Management Review , 45 (3), 41-49.
Kerzner, H. (2009). Project Management, A Systems Approach to Planning, Scheduling,
and Controlling. New Jersey: John Wiley & Sons.
Klosch, R. R. (1998). Euro-conversion and Year 2000: a review of the project situation.
Computer Software and Applications Conference, 1998. COMPSAC '98. Proceedings,
(pp. 525 - 526). Vienna.
KLR. (n.d.). Selecting the Right Project Management Methodology. Retrieved 09 22,
2013, from
http://www.klr.com/articles/Articles_Methodology_selecting_right_pm_methodology.pdf
Kruchten, P. (2001). From Waterfall to Iterative Development - A Challenging Transition
for Project Managers. The rational edge .
Murali, C., & Cagley, T. M. (2010). Mastering Software Project Management: Best
Practices, Tools and Techniques. Ross Publishing.
Murray, A. (2011). PRINCE2® in one thousand words. The Stationery Office.
87
Master Card. (2007). The Anatomy of a transaction - Master Card . Retrieved 11 1,
2013, from
http://www.mastercard.com/us/company/en/docs/TheAnatomyOfATransaction.2007.pdf
McKinsey&Company. (2010). Building organizational capabilities: McKinsey Global
Survey results.
McKinsey&Company. (2012). Delivering large-scale IT projects on time, on budget, and
on value.
Project Management Institute. (2013). A Guide to the Project Management Body of
Knowledge (PMBOK® Guide). Newtown Square: Project Management Institute.
Project Management Institute. (2013). PMI’s Pulse of the Profession™ . Newtown
Square, PA: PMI.
Schwalbe, K. (2010). Information Techoology Project Management. Cengage Learning.
Tuman, G. J. (1983). Development and implementation of effective project management
information and control systems. In D. I. Cleland, & W. R. King (Eds.), Project
management handbook (pp. 495-532). New York: Van Nostrand Reinhold Co.
Turner, J. R. (1999). The handbook of project-based management: improving the
processes for achieving strategic objectives. (2nd ed.). London: McGraw-Hill.