Iniciranje Razvoja Sistema

Univerzitet Megatrend Beograd Fakultet za Menadžment Zaječar

SEMINARSKI RAD Menadžment informacioni sistemi Tema: Prevod glave 8: INICIRANJE RAZVOJA SISTEMA

Mentor Prof. dr Branimir Đorđević

Student Ljiljana Tatić F 841/07

92

GLAVA 8. INICIRANJE RAZVOJA SISTEMA PREGLED POGLAVLJA FOKUSIRANJE NA…

GLAVNE TEME • • • •

• Tehnike poređenja sistema

Razlozi za iniciranje projekta Različiti aspekti studije izvodljivosti Upravljanje rizikom Metode i izbori akvizicije

STUDIJA PRIMERA 8.1 Projekat Ureda za pasoše – šta je trebalo drugačije uraditi?

STEČENA SAZNANJA

MENADŽERSKE ODLUKE Viši menadžerski tim koji podržava novi PIS mora da obezbedi da je projekat (a) neophodan, tj. da će doprineti efikasnosti poslovanja i (b) da će efektivno biti vođen. Faza iniciranja projekta i ocene njegove izvodljivosti su usmerene na postizanje ovih ciljeva. Iz menadžerske perspektive ovo poglavlje dotiče sledeća pitanja: • Kako treba proceniti izvodljivost projekta? • Koje su etape i tehnike koje se mogu primeniti u proceni izvodljivosti • Kako se može proceniti povraćaj investicije u PIS projekat • Kako možemo kontrolisati rizike povezane sa IS projektom

Posle čitanja ovog poglavlja moći će te da: • Objasnite važnost strukturnog izvođenja faze iniciranja PIS projekta • Identifikujete direktne i indirektne troškove i koristi vezane za uvođenje informacionog sistema •

Primenite različite tehnike za izbor najpo-voljnije opcije različitih programa, uređaja i ponuđača Opišete važnost ugovora za uspešan završe- tak projekta informacionog sistema

. VEZE SA OSTALIM POGLAVLJIMA Ovo poglavlje se fokusira na početnu fazu razvoja projekta. Glava 7 Glava 9 Glava 13

opisuje različite načine akvizicije kao što su gotovi i sistemi po meri opisuje kako voditi projekat da bi se obezbedio konstantan nivo kvaliteta tokom projekta pored ostalog razmatra analizu troškova i dobiti u odnosu na ukupnu investiciju koju firma ulaže u IS radije nego u pojedinačne sisteme. Detaljnije su izneti kritični fatori uspeha novog sistema. Opisano je i angažovanje spoljnih saradnika u procesu razvoja informacioniih sistema i menadžmenta.

93

UVOD Uspešna primena informacionog sistema je izazov, mnogi projekti informacionih sistema propadaju. Često ti projekti probijaju vremenske rokove ili budžet ili ne donose očekivane dobiti. Skorašnja studija 134 velikih organizacija iz UK, USA i drugih država pokazuje oboje, i važnost vodjenja projektata kao i njihove izazove (KPMG, 2002). Ovo istraživanje je pokazalo da je 56% organizacija u poslednjih 12 meseci iskusilo propast IT projekata. Prosečan poslovni gubitak je bio 8 miliona funti po projektu dok je najveći gubitak iznosio 133 miliona funti. Jedan primer neuspešnog projekta uzrokovanog problemima u inicijalnoj fazi prikazan je u Studiji primera 8.1 koji se odnosi na UK projekat ureda za pasoše. U ovom slučaju kašnjenje do 50 dana za izdavanje pasoša je rezultiralo u dodatnih 12 miliona funti utrošenih za rešavanje nedostataka sistema.

Faza inicijacije Prva faza u procesu razvoja informacionog sistema. Ciljevi su da se ustanovi da li je projekat izvodljiv i da se obezbedi da projekat bude uspesan

Studija izvodljivosti Aktivnost na početku projekta koje treba da uveri da je projekat zdrav poslovni predlog. Izveštaj studije izvodljivosti analizira neophodnost kao i uticaj sistema i razmatra alternative za nabavku programa.

Ovi neuspesi su često rezultat grešaka napravljenih u planiranju sistema dok su drugi sistemi osuđeni na propast od samog početka zbog toga što nisu bili neophodni ili su nesposobni da pruže ono što se od njih očekivalo. KPMG istraživanje iz 2002-ge pokazuje da je najvažnije napraviti sistem koji zadovoljava potrebe naručioca. Sledeći kriterijumi su bili najčešće korišćeni da se oceni uspeh završenog projekta: • • • •

Zadovoljavanje potreba naručioca (46%) Pravovremena isporuka (21%) Neprekoračivanje budžeta (9%) Podjednak značaj sva tri prethodna kriterijuma (24%)

Neuspeh u realizaciji projekta je često je uzrokovan lošim vodjenjem inicijacije ili početne faze projekta. Ovo poglavlje opisuje sve aktivnosti koje su neophodne na početku projekta da bi se smanjio rizik neuspeha u kasnijim fazama projekta. Inicijacija je prva faza u razvoju nekog informacionog sistema. Njeni ciljevi su da ustanovi da li je projekat izvodljiv i da obezbedi uspešnost projekta. Studija izvodljivosti je aktivnost na početku projekta koje treba da uveri da je projekat zdrav poslovni predlog. Izveštaj studije izvodljivosti analizira neophodnost kao i uticaj sistema i razmatra alternative za nabavku programa i obično se smatra delom faze inicijacije projekta. Studija izvodljivosti je obično deo inicijalne faze projekta (ponekad je i zasebna faza posle inicijacijalne) kao preliminarno istraživanje čija je svrha da ustanovi da li se poslovna ideja ili problem mogu rešiti uvođenjem novog informacionog sistema. Često se koristi i kao definicija “zadataka“ projekta.

Aktivnosti uključene u inicijaciju procesa Svrha početne faze projekta je da donese sud o tome da li će projekat informativnog sistema imati uspean završetak. Razmotrimo banku koja po prvi put uvodi sistem online pružanja usluga ili unapređuje svoj već postojeći elektronskih usluga. Ovde, kao i u svakom projektu informacionog sistema, glavna aktivnost studije izvodljivosti bi bila analiza troškova i koristi koja treba da proveri da li koristi koje sistem sobom donosi prevazilaze troškove. Ostali faktori kao što je uticaj na osoblje će isto tako biti uzeti u obzir i definisati obim projekta. Aktivnosti koje se dešavaju u okviru početne faze projekta su iznete u tabeli 8.1.

94

Tabela 8.1 Glavne aktivnosti tokom inicijalne faze projekta Informacionog Sistema Aktivnost Svrha 1

2

3

4

5

6

7

Procena izvodljivosti

Ovo je najvažniji aspekt početne faze projekta. U sebi uključuje analizu troškova i koristi kao i uzimanje u obzir i nekih nematerijalnih beneficija kao što je uticaj novog sistema na osoblje. Može se uraditi jedna sveobuhvatna studija izvodljivosti koja će ustanoviti poslovne razloge za postupak praćena poređenjem alternativnih tehničkih rešenja različitih dobavljača. Definisanje poslovnih Provera da li je sistem usklađen sa poslovnim ciljeva i skiciranje zahteva potrebama kroz definisanje kritičnih faktora uspešnosti sistema (KFU) koji se moraju ostvariti primenom određenih karakteristika sistema. Evaluacija alternativnih Ova evaluacija treba da pokrije različite aspekte kao što rešenja su cena, podesnost i performanse sistema različitih dobavljača koji mogu biti već gotovi (of-the-shelf) ili pravljeni po meri. Definisanje obima Ovo uključuje specificiranje granica sistema opisujući projekta na koje delove organizacije će sistem uticati; da li će biti ograničen na samo jedan deo, celu organizaciju ili će prevazići okvire organizacije i uključiti i dobavljače? Definisanje odgovornosti Pošto veliki uticaj na projekat posebno u oblastima definisanja zahteva i procedure testiranja potiče od menadžera i krajnjih korisnika sistema, mora se predvideti i vreme za njihovu participaciju. Procena rizika Identifikacija potencijalnih problema koji mogu prouzrokovati neuspeh projekta, kao što su nedostatak stručnosti ili promene na relevantnom tržištu. Koje mere predostrožnosti se mogu preduzeti da projekat ne bi bio neuspešan? Identifikacija ograničenja Uz pomoć procene i planiranja izrađuje se inicijalni i razvoj plana projekta plan projekta koji prikazuje obim i kompleksnost projekta i uspostavlja preliminarni budžet i rokove. Kada se projekat odobri ovi parametri će se uskladiti sa finalnom verzijom projekta. Primećujemo da u inicijalnoj fazi pr Primećujemo da u inicijalnoj fazi projekta analiza izvodljivosti može imati dve zasebne faze. U prvoj opšta izvodljivost može biti ustanovljena utvrđivanjem potreba i ciljeva sistema. Ako se donese odluka da je projekat vredan pažnje, biće urađena detaljnija procena dostupnih rešenja različitih dobavljača. Skica 8.1 prikazuje tipičan redosled aktivnosti u toku inicijalne faze projekta. Za veće projekte kao što je sistem elektronske trgovine u banci, studija izvodljivosti će biti razmatrana od strane grupe višeg rukovodstva kao što su tehnički direktor, finansijski direktor, direktor ili menadžer informacionog sistema i predstavnici odeljenja ili procesa koji će koristiti sistem. Za manje projekte mendžer odeljenja može biti jedina osoba koja će biti uključena ako ona ili on samostalno odlučuje o budžetu. Ovo treba izbegavati jer se može desiti da već postoje sistemi u okviru organizacije koji zadovoljavaju potrebe ili su u konfliktu sa predloženim sistemom.

95

Identifikacija problema ili mogućnosti ↓ Izrada studije izvodljivosti ↓ Definisanje ciljeva i obima ↓ Procena alternativa (izrada ili kupovina) ↓ Preporuka nastavka? ↓ Detaljni plan projekta i plan kvaliteta

Skica 8.1 Redosled glavnih aktivnosti u inicijalnoj fazi projekta Nezavisna procena nekog ko ima pregled celine kao što je menadžer informacionog sistema može pomoći u izbegavanju takvih problema.

RAZLOZI ZA INICIRANJE PROJEKTA Kompanija obično inicira projekat kao odgovor na neki poslovni problem ili priliku da bi obezbedila dobit u odnosu na konkurenciju. Neki primeri takvih dobiti su navedeni u Glavi 2. Kada kompanija razmatra koristi koje se mogu javiti primenom informacionog sistema korisni okvir daje „5C“ koje je Senn definisao 1995 a kojima je ovde dodato još jedno C kako bi se uključio i korisnički servis kao jedan važan faktor. Ovaj okvir pokriva sledeće koristi koje su sažete u tabeli 8.2: 1. Cost reduction / Smanjenje troškova Smanjenje troškova je često ključni razlog za uvođenje novog sistema. Ovaj faktor je relativno lako preračunati i lako je razumljiv i tehničkom kao i finansijskom direktoru. Različiti aspekti preračunavanja troškova su dati u delu koji razmatra analizu troškova i koristi. Za novi bankarski sistem smanjenje troškova se može meriti metodom smanjenja troškova po transakciji – transakcija između korisnika i osoblja telefonskim putem ili u filijali lično može da košta nekoliko Evra dok jedan on-line sistem ne uzrokuje nikakve troškove direktno vezane za osoblje.

96

2. Capability / Sposobnost Novi informacioni system može obezbediti novu sposobnost da se postigne nešto što do tada nije bilo moguće. Na primer, stvaranje on-line bankarstva preko internet stranice pruža mogućnost nove prodajne sposobnosti. Informacioni sistem se isto tako može unaprediti da poboljša već postojeću sposobnost ukoliko je kapacitet bio ograničavajući faktor. Na primer, širenje poslovanja može proizvesti opterećenost koju postojeći sistem ne može da podnese - kompanija u ekspanziji može otkriti da njen postojeći sistem ne može da izađe na kraj sa brojem primljenih narudžbina. Poboljšanje sposobnosti sistema se može ostvariti povećanjem memorijskog kapaciteta ili unapređivanjem programa verzijom sa novim mogućnostima. Holandska banka ING Direct (www.ingdirect.com) je pridobila milione novih korisnika u raličitim zemljama uključujuću Veliku Britaniju, Australiju i Novi Zeland bez potrebe za mrežom filijala uvodeći online štedni račun za koji nije bilo neophodno imati mrežu filijala. 3. Communication / Komunikacija Jedan od ciljeva elektronskog poslovanja je poboljšanje interne, bazirane na unutrašnjoj intranet mreži i spoljašnje komunikacije sa korisnicima, dobavljačima i ostalim partnerima. Banke kao što su First Direct (www.firstdirect.com) nude sistem upozoravanja putem SMS poruke na mobilni telefon korisnika kada je stanje na računu blizu nule. 4. Customer Service / Korisnički servis Korisnički servis se može direktno unaprediti uvođenjem sistema koji je „okrenut okrisniku“ bilo da ga on sam koristi ili da se koristi u njegovom prisustvu. On-line bankarska usluga dozvoljava „non-stop“ korisnički servis. Korisnički servis se može i indirektno unaprediti: kompanija može da kupi poboljšani sistem za obradu narudžbina koji skraćuje vreme potrebno za naručivanje i isporuku robe kupcima i na taj način „oslobodi“ oosoblje i omogući im da više vremena posvećuju težim problemima korisničkog servisa. 5. Control / Kontrola Kontrola se može unaprediti kroz bolji protok informacija menadžerima. Menadžer prodaje koji dobija nedeljne izveštaje o rezultatima njenih ili njegovih prodavaca je u boljoj poziciji da utiče ili kontroliše nego menadžer koji dobija mesečne izveštaje. On-line bankarski sistem obezbeđuje menadžerima u banci izveštaje o najaktivnijim korisnicima kao i o neaktivnim korisnicima koji sistem više uopste ne koriste. Raznim akcijama se onda mogu ohrabriti neaktivni korisnici da počnu više da koriste sistem. 6. Competitive advantage / Konkurentnost Ako informacijski sistem može da pruži prednost nad konkurencijom kroz gore navedene koristi, onda se postiže bolja konkurentnost u odnosu na ostale kompanije. Na primer, supermarket Tesco (www.tesco.com) je bio jedan od prvih iz svog sektora koji je uveo kupovinu iz fotelje, sada ima mnogo veći udeo u on-line kupovini nego u svojim prodavnicama. Slično tome, Dell je uveo Dell Premier (http://premier.dell.com) kao on-line nabavni servis za svoje poslovne korisnike. Prednost začetnika nekog novog vida usluge se ogleda u tome da njegovi rivali imaju poteškoće da za sebe pridobiju mušterije koje su već naviknute na onog koji je prvi došao i taj proces može da traje godinama. Neki teoretičari kao Nicholas Carr sa Harvardske škole biznisa smatraju da je ovako stečena konkurentnost prolazna jer konkurenti kopiraju inovacije (Carr, 2003). Alternativna indikacija potrebe za novim sistemom je pitanje: Kakve bi bile posledice neposedovanja predloženog sistema?

97

Tabela 8.2 Koristi za banku i njene komitente koje donosi uvođenje on-line bankarskog informacionog sistema Korist

Ostvarena kroz

1 .

Smanjenje troškova

2 . 3 .

Sposobnost

4 .

Korisnički servis

5 .

Kontrola

6 .

Konkurentnost

Smanjenje potrebe za osobljem pošto on-line korisnici koriste sistem elektronskog poslovanja kao vid „samouslužnog servisa“. Smanjenje troškova se može izračunati za svaku on-line transakciju. Nova sposobnost da se omogući bankarska usluga 24 sata dnevno, 7 dana nedelno, 365 dana godišnje. Internet omogućava novi vid komunikacije sa komintentima. SMS tekstovna upozorenja donose alternativni vid komunikacije. Komintenti imaju mogućnost izbora korišćenja novog vida komunikacije ili tradicionalnih načina poslovanja. Banka ima uvid u aktivne i pasivne on-line korisnike i može da ohrabri ove potonje na značajnije korišćenje sistema Nove usluge mogu privući nove komintente ili pomoći da se zadrže postojeći.

Komunikacija

AKTIVNOST 8.1 KORISTI KOJE DONOSI PIS Izaberi kompaniju ili organizaciju koja Vam je poznata. Navedite po redosledu važnosti koristi koje razvoj novog Poslovno-informacionog sistema kao što je sistem on-line prodaje može doneti poslovanju određenog odeljenja. Treba da objasnite razloge redosleda za svaku navedenu prednost novog sistema. Ukoliko ovo radite u okviru časa, možete napraviti svojevrsno poređenje različitih sistema i njihovih uporednih prednosti ispisivanjem jednog pored drugog na tabli.

RAZLIČITI ASPEKTI STUDIJE IZVODLJIVOSTI 98

Različiti delovi studije izvodljivosti su obično podeljeni u sledeće kategorije: organizaciona izvodljivost, ekonomska izvodljivost, tehnička izvodljivost i operativna izvodljivost. Ovi faktori se obično analiziraju za svako moguće rešenje koje je predloženo. Alternativna rešenja mogu poticati od raličite opreme ili različitih ponuđača programa ili mofu biti raličita tehnička rešenja predložena od strane ponuđača sistema ili internog razvojnog tima. U ovom odeljku ćemo razmatrati svaki vid izvodljivosti pojedinačno. Oni su sumirani u Tabeli 8.3. Pažnju ćemo najviše obratiti na organizacionalnu i ekonomsku ivodljivost jer su one i najvažnije za odluku za projekat Informacionog sistema. Tehnička i operativna izvodljivost uglavnom se dotiču rizika projekta koji se mogu kontrolisati i koji ne utiču na odluku da li će se projekat izvoditi ili ne.

Tabela 8.3 Pregled različitih aspekata studije izvodljivosti Kategorija izvodljivosti Organizaciona

Ekonomska Tehnička Operaciona

Oblast

Odgovor na pitanje

Usklađivanje sistema sa organizacionim potrebama. Uticaj sistema na organizacionu praksu. Procena troškova koštanja i koristi koje pruža novi sistem. Procena mogućih tehničkih problema i njihovih rešenja. Procena verovatnog reagovanja na sistem od strane njegovih korisnika i menadžmenta.

Da li će sistem zadovoljiti poslovne potrebe i pomoći da se unaprede njegove performanse? Da li će troškovi prevagnuti nad očekivanim koristima? Da li će sistem efikasno raditi? Da li će krajnji korisnici sistem prihvatiti u njihovom svakodnevnom poslu?

Organizaciona izvodljivost Organizaciona izvodljivost Razmatra koliko se dobro rešenje poklapa sa poslovnim potrebama i predviđa probleme kao što su odbojnost prema sistemu ako se osoblje nedovoljno obuči za korišćenje. (Uzima u obzir uticaj promene obzirom na firminu politiku i kulturu.)

Organizaciona izvodljivost razmatra u kojoj meri se rešenje poklapa sa potrebama organizacije i identifikuje probleme koji se mogu pojaviti u toj oblasti. Najvažniji aspekt organizacione izvodljivosti je procena koliko se predloženo rešenje uklapa u postojeću poslovnu i IT strategiju. Često će poželjnost nekog sistema biti poređena sa drugim konkurentskim sistemima.

Usklađivanje informacionog sistema sa poslovnom strategijom Kao deo procene koristi u okviru ekonomske izvodljivosti, veoma je važno ustanoviti da li postoji čvrsta korelacija između dobiti koje novi informacioni sistem donosi i opšte poslovne strategije. To je „odozgonadole“ pristup strategiji informacionog sistema kao što je opisano u glavi 13, gde su zadatak i ciljevi preduzeća prenešeni u mapu zahtevanog informacionog sistema.

IT Upravljanje 99

Upravljanje procesima u cilju usmeravanja i kontrole korišćenja informacoinih tehnologija da bi se ostvarili ciljevi preduzeća povećavajući vrednost uz balansiranje rizika i dobiti koje IT i njeni procesi nose

Model upravljanja IT za usklađivanje njenih dobiti sa poslovnim potrebama Primer inicijative IT industrije koji treba da doprinese boljem usklađivanju informacionih sistema i poslovnih potreba je COBIT. COBIT je model upravljanja IT za Control Objectives for Information and related Technology (u prevodu: Ciljevi kontrole informacionih i srodnih tehnologija) (COBIT,2000). COBIT (2000) objašnjava potrebu za kontrolom IS/IT počevši od inicijalne faze na sledeći način: „poslovni cilj povećanja vrednosti uz balansiranje rizika i dobiti obezbeđuje protok informacija u poslovanju... je omogućen kreiranjem i održavanjem sistema procesa i osobine kontrole svojstvene biznisu koja usmerava i nadzire unapređenje poslovanja pomoću IT.“ Uobičajen način za obezbeđivanje unapređivanja poslovanja je korišćenje kritičnih faktora uspeha što je detaljnije opisano u glavi 13.

Kritični faktori uspeha (KFU) Nivo performanse koji se mora dostići da bi se poslovni ciljevi postigli

Kritični faktori uspeha Korišćenje kritičnih faktora uspeha (KFU) je dragoceno kao pomoć za usklađivanje novog sistema sa poslovnim ciljevima. Kritični faktori uspeha su oni faktori koji određuju da li će poslovni ciljevi biti postignuti. Ključni indikatori performansi (KIP) se koriste za postavljanje ciljeva KFU i procenu da li su oni ostvareni. COBIT definiše KIP kao „glavne indikatore koji definišu meru u kojoj IT proces funkcioniše u omogućavanju postizanja ciljeva.“ COBIT koristi metod sa tri nivoa integrisanja KFU i KIP. Više o tome možete pročitati na www.isaca.org/cobit. Jedan primer takvog pristupa je prikazan od strane Reicheld-a i Schefter-a (2000). Oni su objavili da je Dell Computer osnovao savet za iskustva korisnika koji je istraživao glavne faktore lojalnosti ili KFU koji određuju da li će korisnici biti zadržani kao Dell-ovi ponovni kupci. Poslovni ciljevi i odgovarajući KFU i KIP su prikazani u tabeli 8.4.

Tabela 8.4 Odnos između faktora lojalnosti i mera za procenu uspešnosti u Dell Computer 1 2 3

Poslovni cilj Unapređenje ispunjenja porudžbina

Kritični Faktor Uspeha Isporuka na cilj

Unapređenje performansi proizvoda Unapređenje usluge posle prodaje

Broj inicijalnih problema kod korisnika Pravovremeni i popravak u prvom pokušaju

KPI Procenat sistema koji su isporučeni na vreme i tačno kao što je korisnik specificirao Učestalost problema koji se dešavaju kod korisnika Procenat problema koji su korigovani za vreme prve posete predstavnika servisa koji je došao kada je obećano

PIS igra značajnu ulogu u ostvarenju KFU jer: 1.

PIS je neophodan za prikupljanje KIP podataka i izveštavanje o njima širom organizacije kako bi mogle da se preduzimaju neophodne mere kada ciljevi nisu postignuti

100

2.

PIS se može direktno koristiti za ostvarivanje KFU

AKTIVNOST 8.2 KRITIČNI FAKTORI USPEHA Predloži kako Dell Computer može koristiti PIS da (a) prikupi i izveštava o KFU i KIP iz tabele 8.4 (b) ostvari poslovne ciljeve i KIP u tabeli 8.4 Posle identifikovanja KFU tokom inicijalne faze, projektovanje sistema se treba usmeriti ka ostvarivanju KFU tokom svih faza razvoja sistema. Na primer, u fazi analize će se ispitivati koje funkcije, ulazni i izlazni podaci će biti potrebni radi ostvarivanja zadatih ciljeva. Faza testiranja će uključiti testiranje na bazi rednosti da proveri da li sistem sadrži karakteristike potrebne za ostvarivanje željenih dobiti.

Uticaj sistema na organizaciju Organizaciona izvodljivost uključuje razmatranje uticaja vičnosti i stava potencijalnih korisnika na sistem. Problemi mogu uključiti otpor prema promenama krajnjih korisnika, posebno onih koji nemaju nikakva iskustva u korišćenju kompjutera. Ukoliko se predviđa otpor osoblja prema promenama, moraju se preduzeti koraci koji će obezbediti da do toga ne dođe. Takve mere uključuju obuku i obrazovanje osoblja kroz objašnjenja razloga uvođenja sistema (Glava 12). Ako potencijalni korisnici nisu upoznati sa korišćenjem računara mora se organizovati obuka iz te oblasti. Organizaciona izvodljivost je posebno važna za velike sisteme koji će biti raspoređeni u velikim organizacijama. Primeri su elektronsko poslovanje i sistem planiranja resursa koji iz korena menjaju radne navike kroz redefinisanje poslovnih procesa. U takvim slučajevima novi sistem može uticati na raspored uticaja pojedinih delova organizacije. Ove implikacije morale bi biti uključene kao deo procene organizacione izvodljivosti. Novi sistem može isto tako uticati na načine komuniciranja i kontrolne mehanizme u okviru organizacije i bilo koji štetan aspekt treba biti obuhvaćen analizom. Pristup upravljanju promenama koje su vezane za velike sisteme će biti razmatran kasnije u toku poglavlja.

Ekonomska izvodljivost

Ekonomska izvodljivost

Procena troškova i dobiti različitih rešenja da bi se izabrao sistem koji daje najpovoljnije rešenje (Da li će novi sistem više koštati nego očekivane dobiti?)

Ekonomska izvodljivost je analiza različitih troškova i dobiti implementacije novog sistema. Ona isto tako procenjuje relevantnu važnost novog sistema u poređenju sa ostalim ponuđenim sistemima (vidi pregled analize mape sistema u glavi 13. za više detalja). Počećemo sa pregledom različitih metoda za procenu troškova i dobiti a zatim ćemo preći na osmišljavanje kritičnih faktora uspeha i KIP kao dela identifikacije dobiti koji treba da pomognu da se rezultati projekta usklade sa poslovnim potrebama.

Materijalni troškovi Za svaki materijalni trošak može se izračunati njegova vrednost.

Nematerialni troškovi Novčana vrednost se ne može odrediti za nematerialne

Procena troškova i dobiti Procena troškova i dobiti nekog IS nije precizna nauka. Osnovni problem je da nije tako lako precizno izmeriti svaku dobit ili trošak. Čak i tamo gde su dobiti i troškovi merljivi, cifre koje se navode su bazirane samo na osnovu procene za nekoliko godina unapred. Ovaj odeljak opisuje kako se analiza troskova i dobiti odvija na početku razrade projekta za primenu novog PIS.

101

troškove.

Sve studije izvodljivosti za razvoj informacionog sistema treba da uključe analizu troškova i koristi. Iako se ovo može činiti očiglednim, neke kompanije to ispuštaju iz vida zato što ih neki drugi faktori primoravaju da uvedu sistem kao što je možda odgovor na konkurentsku ponudu ili ispunjavanje zahteva kupca. Razvijanje sistema elektronskog bankarstva je jedan takav primer, ovde su troškovi postavljanja sistema i njegovo održavanje možda veći nego prihodi ostvareni kroz povećani obim poslovanja. Menadžer za marketing će možda ipak želeti da se krene sa tom strateškom inicijativom da bi prednjačio u nečemu, kao što je već ranije objašnjeno. Ili da bi stekao iskustvo usmereno na obezbeđivanje uspešnosti u budućnosti kada se takav način prodaje rasprostrani. Poslovni analitičar koji izrađuje analizu troškova i dobiti će identifikovati obe vrste troškova i dobiti: i materijalne i nematerijalne. Kada je trošak ili dobit materialna, onda je moguće postaviti određenu brojčanu vrednost za neku stavku kao što su troškovi postavljanja nove mreže. Nemoguće je staviti brojčanu vrednost za nematerijalne troškove ili dobiti. Valja primetiti da je za neke faktore teško odrediti da li se radi o materijalnim ili nematerialnim dobitima.

Materialne dobiti Određena mera poboljšanja se može izračunati za svaku materialnu dobit.

Nematerialne dobiti Nemoguće je izmeriti nematerialne dobiti.

Na primer, iako je teško izmeriti dobiti generalnog poboljšanja kvaliteta podataka, bilo bi moguće izmeriti pojedine aspekte kvaliteta kao što je vreme potrebno da se podaci dostave korisnicima. Materialni troškovi su oni koji se mogu izračunati za svaku stavku novog PIS. Na primer, nabavna cena nove opreme potrebne za korišćenje novih programa je materialni trošak. Novčana vrednost se ne može izračunati za nematerialne troškove: prekidi i mogući otpor korisnika koji će se desiti zbog uvođenja novog sistema će imati uticaja na opšte poslovanje kompanije ali je veoma teško izračunati njihovu vrednost. Definitivna mera poboljšanja se može izračunati za svaku materialnu dobit. Smanjenje troškova po transakciji je primer materialnih dobiti za jednu online banku. Nemoguće je izmeriti nematerialnu dobit. Na primer, poboljšanje u sposobnosti donošenja odluka koju donosi sistem za podršku donošenja odluke bi bilo teško izmeriti.

Procena troškova Studija izvodljivosti mora da uključi čitav opseg troškova koji uključuju:

• • • • •

•

•

Nabavnu cenu opreme i programa; Troškove osoblja za razvoj sistema ako je izabran sistem „po meri“; Troškove instalacije uključujući postavljanje kablova, fizičko pomeranje opreme i nameštaja za novu kompjutersku opremu; Troškovi migracije kao što su troškovi prebacivanja podataka sa postojećeg sistema na novi i paralelni rad novog i originalnog sistema dok se stabilnost novog sistema ne uspostavi; Operativni troškovi uključujući troškove održavanja nove opreme kao što su zamena delova ili unapređenje na novu verziju programa. Troškovi osoblja za održavanje opreme i programa kao i za rešavanje sa tim povezanih problemima mora se takođe uračunati. Operativni troškovi mogu i da uključe ekološku proveru količine utrošene energije i potrošnog materijala; Troškove obuke; Šire organizacione trškove, na primer otpremnine za eventualni tehnološki višak radne snage zbog kompjuterizacije.

102

Valja primetiti da ovi troškovi uključuju ne samo inicijalne troškove kupovine već i troškove tekućeg održavanja sistema. Oni su veoma značajni kada je informacoini sistem u pitanju i često premašuju inicijalne troškove kupovine. Vredno je pomena da se sve više shvata da su troškovi posedovanja opreme ili programa potencijalno mnogo viši mego što je nabavna cena istih. Ovo se dešava najviše zbog cene rešavanja programskih problema ili problema sa opremom, telefonske podrške, instaliranja poboljšanja i plaćanja za podršku i/ili poboljšanja od strane isporučioca. Sredinom 1990-tih Gartner Group je prikazala da su ukupni trškovi posedovanja (TCO, vidi poglavlje 16) PC-ja mogu biti do 8.000 $ godišnje sa mogućnošću redukovanja do 2.000 $ godišnje za kompjuter sa manjim brojem opcija u konfiguraciji. Troškovi posedovanja izabrane kombinacije opreme i programa moraju čigledno biti uključeni u vašu analizu troškova i dobiti. Troškovi obuke, edukacije i dokumentacije osoblja treba isto tako uključiti kao i troškovi plaćanja analitičara i programera. Radošević (1999) je sažela troškove kao eksternu i internu radnu snagu, opremu, programe, putovanja i obuka, podrška i testiranje. Ona primećuje da većina kompanija procenjuju ove troškove nakon određivanja poslovnih zahteva i ciljeva pošto su trokovi povezani sa zadacima u strukturi raspodele posla kao što je već objašnjeno u poglavlju 9.

AKTIVNOST 8.3 TIPIČNI TROŠKOVI I DOBITI PIS-A Primeri troškova i dobiti su sledeći: • • • • • • • •

Troškovi nabavke programa Otpor korisnika Smanjenje radnih sati Poboljšano donošenje odluka Troškovi nabavke opreme Nove radne procedure Povećanje prodaje Širi horizonti planiranja

•

Troškovi implementacije Prekidi tokom implementacije

•

• • • • • •

Troškovi obuke Smanjenje pritužbi kupaca Bolja integracija podataka Troškovi održavanja opreme, programa i potrošnog materijala Smanjenje zaliha Bolji protok novca

Proceni gde koji pripada u tabeli ispod:

Troškovi Materijalni Nematerijalni

103

Dobiti Materijalne Nematerijalne

Procena dobiti Dok je troškove informacionog sistema relativno lako identifikovati, dobiti je mnogo teže kvantifikovati pošto su često nematerijalne i pojavljuju se u budućnosti. Dobiti novog sistema mogu se smatrati unapređenjima poslovnog procesa i kvaliteta informacija potrebnih za podržavanje tog procesa. Uobičajene dobiti uključuju smanjene troškove operativnih procesa i veću efikasnost koja vodi do izvršavanja zadataka kao što je uslužuvanje kupaca. Parker i Benson (1988) preporučuji strukturisani pristup identifikaciji materijalnih dobiti. Ovo uključuje razmatranje troškova izvođenja poslovnih operacija pre uvođenja novog sistema i poređenje sa troškovima posle uvođenja novog sistema. Troškovi mogu da uključuju vreme osoblja, materijale i opremu. Ovaj rezultat će pokazati ili materijalnu dobit kroz smanjenje troškova ili dodatne troškove uzrokovane korišćenjem novog sistema. Nematerijalne dobiti uključuju unapređenje kvaliteta informacija, kao što je opisano u poglavlju 1. Novi informacioni sistem treba da omogući poboljšanje kvaliteta informacija na neki od sledećih načina:

• • • • •

Poboljšana preciznost; Poboljana dostupnost i pravovremenost; Poboljšana upotrebljivost (lakše za razumevanje i akciju prema informaciji) Poboljšano korišćenje Poboljšana sigurnost informacija

Korišćenje finansijskih merila za procenu vitalnosti novog sistema Balans između troškova i dobiti može se proceniti korišćenjem različitih finansijskih merila. Ova tehnika vam je možda poznata iz knjigovodstva jer se ova merila mogu primeniti na procenu povraćaja sredstava za bilo koju kapitalnu investiciju. Nakon što su troškovi i dobiti identifikovane i kvantifikovane, uobičajeno je da se izračunaju njihove vrednosti u trenutnim novčanim iznosima mada će troškovi i dobiti da se dese u budućnosti. Novčane dobiti ostvarene u budućnosti će vredeti manje nego kada je projekat započet zbog uticaja inflacije. Da bi se to uzelo u obzir, koristi se korigovana kalkulacija protoka novca kao što su neto sadašnja vrednost ili interna stopa prihoda. U njima se buduća dobit koriguje pretpostavljajući fiksnu ili varijabilnu kamatnu stopu. Ove tehnike je opisao Robson (1997) a procenu troškova i dobiti je detaljnije opisao Remenyi (1995).

Prihod od investicije (POI) Prihod od investicije (POI) Indikacija prihoda koji donosi IS. Izračunava se deljenjem dobiti sa iznosom investicije. Izražava se u procentima.

Ovo je najjednostavnije merilo i široko je rasprostranjeno procenama opravdanosti IS. POI se izračunava tako što se dobit podeli sa iznosom investicije i izražava se u procentima: Vrednost dobiti POI=100 x ──────────── Vrednost investicije gde je: Vrednost dobiti = prihod – trošak. Tako na primer, za jednu investiciju u IS koja iznosi 25.000 € koja donosi dobiti kao što su smanjenje troškova od 100.000 €, POI iznosi 400%.

104

Garner Group sugeriše da POI koji je duplo veći od troškova pozajmljivanja je isplativ. Iako se ovo čini jednostavnim merilom koje se lako izračunava, ne postoji standard na koji se način primenjuje u odnosu na trajanje investicije. Robson (1997) predlaže da se POI izračunava uzimajući u obzir godišnju vrednost dobiti. Analitičari kao Gartner Group koriste za izračunavanje POI period od 4 godine dok drugi radije uzimaju u obzir predviđeni zivotni vek investicije.

Neto sadašnja vrednost (NSV) Problem sa POI je da se često (mada ne uvek) izračunava ne uzimajući u obzir kako će buduća vrednost varirati tokom vremena. Da bi ovo izračunavanje imalo smisla, buduća vrednost treba da se koriguje da bi reprezentovala njenu sadašnju vredmost. Ovo je poznato kao korigovani protok novca (KPN) koji se izračunava prema matematičkoj formuli:

Neto sadašnja vrednost (NSV) Merilo prihoda od sistema koje uzima u obzir varijaciju vrednosti novca tokom vremena.

Vrednost KPN= ∑ ─────── i=1,n (1+ stopa)ⁿ gde je: Vrednost = protok novca, počinjući sa investiciom kao negativnim protokom novca, n = broj perioda (obično godina), Stopa = cena kapitala (stopa korekcije).

Ako je NSV vrednost pozitivna, procena sugeriše da će kompanija imati prihod i da može da se odluči da investira. Negativni NSV sugeriše da neće biti prihoda od investicije i najverovatnije da se projekat neće realizovati. Jedan primer koji sugeriše stepen smanjenja budućih prihoda ie dat u tabeli 8.5. Ovde se pretpostavlja investicija u jedan informacioni sistema koji donosi uštedu od 20.000 € svake godine i korekcionu stopu od 15% (različiti korekcioni faktori bi trebali da se uzmu u obzir svake godine). Tabela prikazuje totalni prihod od 67.041 € umesto 100.000 € za period od 5 godina! Dakle, za isti primer investicije od 25.000 € u IS, dobit u trenutnoj vrednosti je oko 67.000 € i POI je sada 268% umesto 400%. Tabela 8.5 Primer prihoda za period od 5 godina uz stopu korekcije od 15%

Interna stopa prihoda (ISP) Tehnika korigovanog protoka novca koja se koristi za procenu prihoda od projekta uzimajući u obzir kamatnu stopu koju bi proizveo NSV čija je vrednost nula.

Prihod Stopa korekcije Sadašnja vrednost

1. godina 20.000 € 0.86957 17.391 €

2. godina 20.000 € 0.75614 15.122 €

3. godina 20.000 € 0.65752 13.150 €

4. godina 20.000 € 0.57175 11.435 €

5. godina 20.000 € 0.49718 9.943 €

Interna stopa prihoda (ISP) ISP je isto tako tehnika korigovanog protoka novca koja posmatra NSV iz drge perspektive. ISP izračunavanje daje kamatnu stopu koju bi proizveo NSV čija je vrednost nula. Robson sugeriše da se ovaj metod može koristiti za poređenje raznih potencijalnih projekata. Projekat A sa ISP od 15% je poželjniji od projekta B koji ima ISP od 5%. U ovom primeru 19% bi se moglo postaviti za granicu prihvatljivosti projekta.

Period otplate Period otplate Period posle inicijalne investicije pre nego što

Ovo merilo se obično koristi zajedno sa POI, NSV i ISP jer prikazuje dodatnu informaciju koju ova ostala merila ne pokazuju. Period otplate je period u kome, posle početne investicije, kompanija nije ostvarila neto dobit. Ovo se očigledno vidi iz skice 8.2 koja pokazuje da će se tek nakon što dobit počne da se nagomilava sistem otplatiti. PIS često

105

kompanija ostvari neto dobitak.

imaju period otplate reda nekoliko godina dok razvoj projekta i sama investicija mogu da traju preko godinu dana.

Skica 8.2 Grafikon prikazuje odnos između troškova razvoja sistema i vrednosti dobiti tokom vremena i njihov uticaj na kumulativnu neto dobit

Dve alternative mogu imati sličan POI ili NSV ali jedan projekat može imati mnogo kraći period otplate pa je važno koristiti kombinaciju svih metoda ovde izloženih. Pre nego što napustimo ovu temu, treba primetti da su merila koja smo analizirali čisto ekonomska i da ih ne treba razmatrati izdvojeno od ostalih. Važno je razmatrati i druge faktore kao što su nematerijalne dobiti i rizici očekivani od različitih alternativa. Parker i Benson (1988) skovali su termin „informativna ekonomika“ koji obezbeđuje metodologiju za procenu ovih drugih faktora.

AKTIVNOST 8.4

IZRAČUNAVANJE KORIGOVANOG PROTOKA NOVCA ZA RAZVOJ SISTEMA ELEKTRONSKE TRGOVINE Ova aktivnost ilustruje tipove materijalnih troškova i dobiti koje treba uzeti u obzir kada se sastavlja jedan informacioni sistem i pokazuje kako se dobit i troškovi menjaju tokom vremena. Merila koja treba da koristite prilikom procene investicije su: • • •

Period otplate Prihod od investicije Neto sadašnja vrednost

Kompletirajte sledeće faze da bi izvršili kalkulaciju: Faza 1: Troškovi Koristeći troškove iz tabele 8.6 popunite model pregleda troškova u tabeli 8.7 popunjavajući mesta na kojima se nalazi znak pitanja. Faza 2: Dobit

106

Koristeći tabelu 8.8 popunite model pregleda dbiti u tabeli 8.9 popunjavajući mesta na kojima se nalazi znak pitanja.

Tabela 8.6 Tabela ulaznih troškova Projekt menadžer Analitičar Razvojni stručnjak Drugi troškovi osoblja Oprema Programi Instalacija Obuka Održavanje, godišnje

Časovi 300 400 800

Iznos 50 ₤ 40 ₤ 30 ₤ 15 ₤ 10.000 ₤ 20.000 ₤ 5.000 ₤ 15.000 ₤ 12.000 ₤

Tabela 8.7 Model pregleda troškova Trošak Projekt menadžer Analitičar Razvojni stručnjak Oprema Programi Instalacija Obuka (ostalo osoblje) Održavanje Ukupno

0. godina ? ? ? ? ? ? ? ?

1. godina

2. godina

3. godina

? ?

? ?

? ?

Tabela 8.8 Tabela za unos dobiti Smanjeni troškovi obrade (godišnji) Smanjeni troškovi zaliha (godišnji) Prodaja (godine 1 do 3) Manje povraćaja (godišnje) Korekcioni faktor Tabela 8.9

Model pregleda dobiti

107

500 ₤ 10.000 ₤ 50.000 ₤ 10.000 ₤ 15%

100.000 ₤

150.000 ₤

0. godina Smanjeni troškovi Smanjene zalihe Prodaja Manje povraćaja Ukupno

1. godina ? ? ? ? ?

2. godina ? ? ? ? ?

3. godina ? ? ? ? ?

Faza 3: Izračunavanje korigovanog protoka novca Konačno, popunite tabelu KPN (tabela 8.10) koristeći modele pregleda troškova i dobiti (tabela 8.7 i tabela 8.9)

Tabela 8.10

Izračunavanje korigovanog protoka novca

0. godina 1. godina 2. godina 3. godina Dobiti-troškovi ? ? ? ? Korigovani dobiti-troškovi ? ? ? Kumulativni dobiti-troškovi ? ? ? Kumulativni (NSV)-početni ? ? ? Period otplate (meseci) ? = Inicijalni troškovi / (uštede-operativni troškovi) POI (u trećoj godini) ? = Uštede (dobit) / Troškovi NSV (u trećoj godini) ? = Ukupni neto prihod – Inicijalni troškovi

Tehnička izvodljivost Tehnička izvodljivost Procenjuje u kojoj meri će predloženo rešenje funkcionisati kao što se zahteva i da li su odgoarajući ljudi i oruđa na raspolaganju da se rešenje primeni. (Da li će funkcionisati?)

Tehnička izvodljivost se odnosi na analizu mogućih tehničkih problema u raznim rešenjima i ko je podesan za njihovo razrešenje. Tehnička izvodljivost može obuhvatiti razna pitanja koja treba da daju odgovor da li je kompjuterski sistem pravo oruđe za rešenje problema. Neki zadaci se mogu rešiti samo uz pomoć ljudske intervencije. Tipovi pitanja su: • Da li sistem može da pruži očekivane performanse? Na primer, sistem online bankarstva treba da obavi na hiljade transakcija u sekundi. • Da li sistem zadovoljava uslove dostupnosti i pouzdanosti? Jedan sistem on-line bankarstva bi trebalo u idealnom slučaju da bude na raspolaganju 100% vremena, koji su rizici u pogledu grešaka u opremi, programima ili mreži koji bi to mogli da spreče? Ugovor o nivou usluge sa internet provajderom se obično koristi za kontrolu toga. • Da li sistem obezbeđuje potreban nivo bezbednosti?

•

Da li će biti problema sa integracijom ili kvalitetom podataka? Kompleksni sistemi mogu biti neuspešni zbog problema u prenosu podataka između različitih sistema. Kvalitet podataka se mora održavati da bi sistem mogao da isporuči zadovoljavajuće podatke do krajnjih korisnika. Ovaj problem

108

•

najbolje ilustruje često korišćen izraz u IT industriji: „đubre ulazi, đubre izlazi“. Da li sistem podržava tip donošenja odluke koji se traži (posebno podršku za polustrukturirane ili nestrukturirane odluke)?

Cilj procene terhničke izvodljivosti je da odredi da li ponuđeno rešenje uopšte može da funkcioniše. U nekim slučajevima, kao što je za knjigovodstveni sistem, naći će se očigledan proizvod koji zadovoljava zacrtane zahteve. U drugim slučajevima kao što je specijalizovani proizvodni pogon, prilično detaljna analiza zahteva i visoko specijalizovan dizajn sistema može biti neophodan da bi se procenile alternative pre nego bued moguće odlučiti o izvodljivosti. U tom slučaju inicijalna faza će biti produžena i skupa. Za jednostavne aplikacije većina problema će biti tehnički izvodljivo, i glavno pitanje će biti: „Koliko će rešenje da košta?“ Neka rešenja mogu biti tehnički izvodljiva ali zahtevaju skupu opremu, programe ili razvojni tim. Dakle, tehnička izvodljivost se mora uraditi pre ekonomske izvodljivosti kako bi se procenili ti troškovi. Dalje, ostvarenje tehničke izvodlljivosti zavisi od zdravog pristupa kontroli rizika koja će kasnije biti opisana.

Operativna izvodljivost Operativna izvodljivost Procena kako novi sistem utiče na svakodnevno poslovanje u okviru organizacije. (Da li je sistem upotrebljiv u svakodnevnoj praksi?)

Operativna izvodljivost će razmatrati kako uvođenje novog sistema utiče na svakodnevno poslovanje.Na primer, napraviće se detaljna procena da li su upotrebljivost sistema i vreme odziva dovoljni za očekivani obim korisničkih transakcija. Sa sistemom koji je okrenut korisniku kao što je on-line bankarsko rešenje, operaciona izvodljivost je veoma važna jer će sistem koji je komplikovan za upotrebu obijati korisnike posle prve upotrebe i oni će ga manje koristiti. Zbog tog razloga banke angažuju stručnjake za upotrebljivost kao što je Usability Company (www.theusabilitycompany.com) da smanje rizikda će sistem biti komplikovan za korišćenjeili da neće zadovoljiti preporuke dostupnosti. Postoji veoma tesna veza između operativne i organizacione izvodljivosti i one se ponekad zajedno razmatraju.

UPRAVLJANJE RIZICIMA Procena rizika se može koristiti na početku projekta da odredi nivo rizika i razvije planove za smanjenje tog rizika – posebno je važno kao deo procene operativne i organizacione izvodljivosti. Upravljanje rizicima uključuje sledeće faze.

Upravljanje rizicima Ima za cilj da predvidi buduće rizike jednog projekta informacionog sistema i da postavi mere za suzbijanje ili eliminisanje tih rizika.

Rizici mogu da se podele na šest širokih kategorija prema Ward i Peppard (2002). Ove se mogu koristiti kao okvir za identifikovanje rizika u okviru projekta. Svaka od njih ima različit uticaj zavisno od prirode sistema koji se projektuje.

1. Veličina projekta. Veliki i kompleksni projekti će biti teži za upravljanje i

2.

pravovremeno završavanje nego mali; Ovo zbog toga što imaju veliki broj individualnih zadataka i međuzavisnosti u okviru projekta i potreban je veći broj osoba da rade na njemu (povećavajući potreban nivo koordinacije). Dodatno, kod velikih projekata može se mnogo više izgubiti ako projekat propadne jer se od njega očekuje da donese značajan deo poslovne dobiti (ili se ne bi ni započinjao, pre svega!); Kompleksnost projekta. Kompleksnost može biti uzrok za prekoračenje projekta. Valja primetiti da, iako projekat može biti velik, poslovni

109

3.

4.

problem i/ili tehnologija koja se koristi mogu biti prilično jednostavni. Kompleksnost će zavisiti od: • Raznovrsnosti poslovnih funkcija na koje će se uticati (sa implikacijama na organizacione promene procesa upravljanja); • Integracijom sa ostalim informacionim sistemima (sa implikacijama na tehničke promene procesa upravljanja); • Tehničke kompleksnosti u okviru samog sistema (možda zbog potrebe da se koriste nove tehnologije koje još nisu bile korišćene u okviru organizacije); Ljudski resursi. Ovo se odnosi na stepen do kog je viši menadžment posvećen i uključen u projekat. Mora se naći prava mešavina poslovnih i tehničkih veština i efektivna komunikacija između poslovnih korisnika i isporučioca sistema. Jedan primer rizika u ovoj kategoriji je mogućnost nedostatka odgovarajućih stručnjaka – programera sa odgovarajućim znanjima i onda izostaje povratna informacija od krajnjih korisnika. Kontrola projekta. Ovo se odnosi na rigoroznost sa kojom se kontrolišu vreme, troškovi i kvalitet projekta koji se izvodi. Elementi kontrole uključuju postavljanje referentnih tačaka projekta, IS/IT standardi, metodologije razvoja sistema i upravljanja projektom, kontrola budžeta i upravljanje promenama.

Suviše kruto isplaniran projekat može da ne uspe da se prilagodi neočekivanim izmenama tako da je fleksibilnost važna. Rizik leži u preciznosti procesa planiranja i mere do koje se izmene mogu prihvatiti. Rizici u ovoj kategoriji su ako su uzorkovani podaci nedostupni ili se oprema kasno naruči. To može biti i greška drugih ali je još uvek do projekt menadžera da omogući da se nešto desi.

5. Novitet. Ako je potrebno u velikoj meri promeniti poslovanje da bi se omogućila implementacija projekta ili tehničko rešenje sadrži u velikoj meri inovativnu tehnologiju, rizici mogu da postanu vrlo veliki. Sledeći potencijalni rizik koga bi trebalo biti svestan je „sindrom pokretnih stativa“ – kada se poslovni zahtevi ili tehnologije koje će se koristiti menjaju tako brzo da sistem možda neće moći da isporuči ono što se zahteva. U vakom slučaju, ako je projekat koji se razmatra predviđen da donese značajnu konkurentsku prednost, može biti neophodno da se prihvati takav rizik. To je uobičajen problem balansa između rizika i nagrade.

6. Stabilnost zahteva. Što je veći stepen izvesnosti (poslovno i tehnički) to je manji stepen rizika vezan za projekat. Situacija u kojoj su zahtevi nestabilni ili ih je teško definisati znači da će projekat biti skuplji i da će predviđene dobiti teže odgovarati tim troškovima. Dodatno, dinamično poslovno okruženje može takođe da znači da poslovanje zahteva promene relativno brzo i da će se to odraziti i na promene sistemskih zahteva. Alternativni metod gledanja na investixione rizike daju Lyytinen i Hirschei (1987) koji su identifikovali četiri oblasti: tehničke probleme (performanse i pouzdanost sistema nezadovoljavajući); problemi sa podacima (upravljanje kvalitetom podataka neadekvatno da bi zadovoljilo potrebe korisnika); problemi sa korisnicima (neprihvatanje sistema uzrokovano lošom obukom i edukacijom kao deo upravljanja promenom) ili organizacioni problemi (sistem može da zadovoljava potrebe krajnjih korisnika ali ne i one koje ima šira organizacija). Videćete da su ove četiri oblasti tesno povezane sa četiri tipa izvodljivosti tako da strukturirani pristup procenama

110

izvodljivosti može pomoći u smanjenju tih rizika. Da sumiramo, procena rizika uključuje balansiranje rizika i troškova koji će verovatno napravljeni u odnosu na pretpostavljenu poslovnu dobit. Studija slučaja 8.1 daje primer šta može da se desi sa IS projektom kada je upravljanje rizikom neadekvatno.

AKTIVNOST 8.5

ANALIZA IZVODLJIVOSTI ZA LASCELLES FINE FOODS Ova aktivnost se bazira na Studiji slučaja 7.2 gde su alternative nabavke opreme razmatrane za ovu kompaniju. Napravite analizu izvodljivosti za alternativne metode nabavke aplikacijskih programa u odnosu na LFFL. Posebno treba obratiti pažnju na operativnu, organizacionu, ekonomsku i tehničku izvodljivost svakog od njih. Treba da zaključite sa preporukom kako LFFL treba na najbolji način da pređe na sledeću fazu procesa nabavke informacionog sistema. 1. 2. 3.

Identifikuj rizike, uključujući njihove verovatnoće i uticaj. Identifikuj moguća rešenja tih rizika. Primeni rešenja usmerena na najverovatnije rizike sa najvećim uticajem.

IZBOR I METODI NABAVKE Deo faze izvodljivosti je odluka o izboru metode nabavke. To se obično dežava nakon što su potrebe i zahtevi sistema definisani. Napraviti ili kupiti odluka će uslediti i različiti dobavljači gotovih sistema ili sistema po meri će biti procenjeni, kao što je već opisano u poglavlju 7. Ekonomska, tehnička i operativna izvodljivost će biti procenjena za svakog dobavljača nakon što im je tender ili zahtev za ponudom poslat. Ako kompanija odluči da koristi usluge trećeg lica u razvoju svog informacoinog sistema ili da koristi usluge tuđih IS ta pojava se naziva angažovanje spoljnih saradnika (outsourcing) (poglavlje 14.). To je obično strateška inicijativa koja uključuje spoljnu kompaniju za razvoj više od jednog sistema.

111

PRIMER ZAHTEVA ZA PONUDU ZA PIS Akcioni pregled. (dve stranice). Uključuje opis kompanije, ciljeve nabavke, POI zahteve, prioritetnu tehnološku strategiju, termine nabavke. Administrativna informacija (tri stranice). Sadrži redosled i termine nabavke, sažetak zahteva, uputstva za pripremu i podnošenje ponude, listu kriterijuma procene. Poslovni deo (šest stranica). Uključuje poslovnu dobit, opis trenutnog načina poslovanja, očekivanja, kritične faktore uspeha. Tehnički deo (petnaest stranica). Ovaj deo služi kao ček-lista za prijem opreme od strane kupca. Sadrži pregled sadšnjih operacija IS, očekivanja od operacija novog IS, specifikacije funkcija sistema, očekivano vreme reagovanja sistema, zahteve upravljanja dokumenata, zahteve integracije, obradu izuzetaka, zahteve za opremu, programske zahteve, specifikaciju medija za skladištenje podataka.

Zahtev za ponudu (ZZP) Specifikacija sastavljena da pomogne u izboru dobavljača i programa.

Menadžment (tri strane). Može se ostaviti za odabrane dobavljače da popune. Uključuje kriterijume za prijem opreme, plan upravljanja projekta, plan pripreme prostora, plan obuke i raspored, plan i vreme isporuke i instalacije, plan održavanja sistema, dokumentaciju (opis i cene), kvalifikacije i iskustvo (broj instalacija itd.), referentnu listu korisnika, finansijski izveštaj. Sporazum (jedna strana). Traži se cena dobavljača razbijena po stavkama i definicijama kako bi se lakše mogli porediti pojedini dobavljači.

Pregled zahteva sistema Ako odlučimo da nastavimo posle inicijalne studije izvodljivosti, sledeća faza za glavnu primenu u velikoj organizaciji bi bila da pošalje poziv za tender, dokumenat, pismo ili zahtev za ponudu (ZZP). ZZP je specifikacija sastavljena da pomogne u izboru dobavljača i programa. Jedan primer strukture ZZP je prikazan u okviru. Kupac će popuniti prve četiri sekcije a različiti dobavljači će popuniti zadnje dve sekcije. Za manje kompanije ili sisteme, alternativni dobavljači će se takođe procenjivati ali će napor uložen u selekciju biti mnogo manji.

FOKUS NA TEHNIKE POREĐENJA SISTEMA Kada se kupuje sistem, strukturisani način donošenja odluke je neophodan da bi se osiguralo da se najbolja opcija odabere. Tri jednostavna metoda za odabir proizvoda ili dobavljača su prikazana dole.

MINI STUDIJA SLUČAJA

112

ČEKLISTA ZA POREĐENJE KARAKTERISTIKA TRI RAZLIČITA PROGRAMA ZA RADNE TIMOVE Tri proizvoda se porede prema: • • •

Karakteristikama koje obezbeđuju; Operativnim sistemima koje podržavaju za serversku platformu; Operativnim sistemima koje podržavaju za krajnjeg korisnika.

Ovi se sistemi porede koristeći tabelu 8.11. Cene za različite opcije mogu se takođe prikazati u sličnoj tabeli zajedno sa detaljnijim karakteristikama kao što su: da li e-mail ima jedan adresar za celu kompaniju i da li podržava slanje priloga?

Tabela 8.11 Poređenje karakteristika tri programa za timove Kriterijum

Proizvod A

Proizvod B

Proizvod C

Platforme servera Windows XP Professional Novell Netware Linux

Yes Yes Yes

Yes No No

Yes Yes No

Korisničke platforme Windows XP MacOS X

Yes Yes

Yes No

Yes Yes

Karakteristike E-mail Odloženo aktiviranje Upravljanje dokumentima Pristup internetu

Yes Yes Yes Yes

Yes No No No

Yes Yes Yes Yes

Posle pregleda tabele može se videti da Proizvod A i Proizvod C ispunjavaju veći deo kriterijuma. Proizvod B bi bio nepodesan za kompanijukoja ima veliki broj postojećih kompjutera koji rade na različitim operativnim sistemima. Pošto su Proizvodi A i C slični i ne mogu se razlikovati koristeći ovu tabelu, detaljnija evaluacija od ove može da sledi posle isključivanja Proizvoda B. Drugačiji primer malo detaljnije evaluacije poslovnog sistema je opisan niže.

AKTIVNOST 8.6 DETALJNA ANALIZA PROGRAMA ZA UPRAVLJANJE FLOTOM VOZILA SA FAKTORIMA ZNAČAJA

Tabela 8.12 pokazuje pravu analizu tri proizvoda različitih dobavljača koji su poređeni po mnogim faktorima da bi se odredilo koji od njih je najpodesniji. Ovaj tip detaljne analize se obično koristi kada novi sistem košta desetine ili stotine hiljada funti. Veliki total pokazuje da je Dobavljač 3 jasan pobednik i to je bio projekat koji je odabran i uspešno primenjen.

Tabela 8.12 Detaljna analiza programa za upravljanje flotom vozila sa faktorima značaja

113

Faktor značaja

Kriterijum za odluku A Funkcionalnost pojedinačnih modula (pregled) Kontrola održavanja flote Raspored stopa Skladišta/kupovina Subtotal Generalna funkcionalnost Potpuno integrisani glavni moduli Integrisano izdavanje karata i slkadišta On-line održavanje podataka Fleksibilnost za prihvatanje SOR Preuzimanje podataka od postojećeg sistema Jako ad hok izveštavanje Nadgledanje performansi Veza sa sistemom automatizacije u kancelariji Veza sa glavnom finansijskom knjigom Uputstva za obuku i dokumentacija Subtotal B Tehnička razmatranja Efikasne procedure za bezbednost podataka Radi na otvorenom Jednostavnost korišćenja i performanse Subtotal Ostala razmatranja Finansijska razmatranja Podrška održavanja Korisnik lokalne uprave Poverenje u dobavljača Subtotal Grand total

Dobavljač 1

Dobavljač 2

Dobavljač 3

100 100 100 300

80 79 72 231

86 84 71 241

98 85 86 269

100 100 80 80 80 70 60 60 60 60 750

60 30 56 40 64 28 30 42 32 30 412

60 40 56 40 64 56 36 42 40 36 470

60 80 56 68 64 56 42 42 42 36 576

80 80 80 240

56 56 48 160

56 56 48 160

56 56 56 168

60 60 50 50 220 1510

36 36 30 25 127 930

48 30 30 25 133 1004

54 42 30 35 161 1174

PITANJA 1. Razmotri različite kategorije i kriterijuma u okviru njih. Da li misliš da su 2. 3.

faktori značaja u redu? Na primer, razmotri funkcionalnost modula, izveštaje, dokumentaciju, jednostavnost korišćenja i finansijska razmatranja. Pogledaj detaljnije vrednosti za svaki proizvod. Komentariši na bazi odluke o pojedinačnim rezultatima. Uzimajući u obzir moguće nedostatke u tačkama 1. i 2. komentariši podobnost ove tehnike za donošenje odluke. Da li bi je koristoi i zašto? Šta bi uradio drugačije?

Čeklista karakteristika – prvi krug isklučivanja Ovo se koristi na početku da se odmah islkjuče proizvodi koji možda nemaju ključne funkcije ili ne podržavaju operativni sistem koji se koristi. Skromna čeklista karakteristika je alat koji je vrlo koristan i najlakše se primenjuje. Studija slučaja prikazuje tipičnu čeklistu, kakva se može naći u magazinima kao što je PC Magazine (www.zdnet.com) sa poređenjem tri gotova softverska proizvoda.

114

Čeklista karakteristika – detaljno rangiranje Najveći nedostatak jednostavnih čeklista je da ne daju relativnu važnost karakteristikama. Da bi se proširile, daje se svakoj karakteristici značaj od, recimo, između 0 i 100 poena za svaki faktor i onda se saberu poeni za različite proizvode. Aktivnost 8.6 prikazuje detaljnu analizu koristeći mnoštvo faktora za odluku kog dobavljača izabrati.

Konačan izbor korišćenjem uporednih testova Kada kompanija suzi izbor programa koristeći čeklistu karakteristika na dva ili tri kandidata na raspolaganju su brojne mogućnosti za finalnu odluku. One mogu biti prilično skupe i za kupca i za dobavljače. Kao prvo, moguće je poređenje sa drugim organizacijama koje obavljaju slične poslove – kakva su njihova iskustva, kakve performanse program postiže, da li su oni nezavisna referenca? Zatim, ako je u pitanju velika porudžbina, možete tražiti od dobavljača da obezbedi program i testira važne funkcije koristeći simulaciju procesa u kompaniji često koristeći uzorke podataka. Tabela 8.13 daje takav scenario za korišćenje proizvod poslovne inteligencije kao što je Cognos (www.cognos.com) ili Business Objects (www.businessobjects.com) koji su predstavljeni u poglavlju 6. Često poređenje neće imati smisla ako se ne koriste podaci ili procesi iz kompanije kao osnova za takav scenario.

Tabela 8.13 Pet primera scenarija za izbor sistema poslovne inteligencije Funkcija koja se testira

Scenario

1. Administracija. Dodaj novog korisnika

Kako lako se može novi korisnik dodati sistemu ili njegovi lični detalji izmeniti? Koliko je jednostavno podesiti PC kupca (krajnjeg korisnika)? Koliko lako može korisnik da pregleda razliku između stvarne i predviđene prodaje i njihov trend tokom vremena? Ako prodaja opada za jednu proizvodnu liniju, koliko je lako je pronaći uzrok tog problema? Koliko je lako poslati deo podataka za dalju analizu u programsku tabelu? Koliko lako se modifikuje grafikon da prikaže novi KPI?

2. Uporedi stvarnu sa predviđenom prodajom 3. „Rešetanje“ problema 4. Slanje podataka 5. Konfigurisanje pregleda podataka

Koje faktore treba koristiti prilikom izbora sistema? Kada se upoređuju programi, cena je očigledan ograničavajući faktor bilo koje kupovine, obzirom da je to fiksno ograničenje, često je najbolje suziti izbor uzimajući u obzir druge faktore i na kraju doneti konačnu odluku na bazi cene između kandidata koji su slični po ostalim osobinama. Osam važnih faktora za odluku o izboru sistema su prikazani u okviru. Treba primetiti da iz interne perspektive jedna organizacija treba da razmotri da li ima dovoljno stručih ljudi da se izbori sa aplikacijom – ovo može da isključi neka funkcoinalno superiorna rešenja na primer. Popuni Aktivnost 8.7 da bi video kako se ovi faktori mogu primeniti u praksi.

115

Funkcionalnost Termin koji se koristi da opiše da li ima neophodne karakteristike da podrži poslovne zahteve

OSAM KLJUČNIH FAKTORA U IZBORU SISTEMA 1. Funkcionalnost. Da li program ima opisane karakteristike da podrži poslovne zahteve?

2. Lakoća korišćenja. Za oba slučaja, za krajnje korisnike uključujući inicijalna podešavanja iadministraciju.

3. Performanse. Za različite funkcije kao što je izvlačenje podataka i prikazivanje na

Kompatibilnost Kompatibilnost programa definiše jedan tip programa funkcioniše sa drugim. Na primer, da li će program za obradu teksta raditi sa Windows 3.1 ili Windows 95? Kompatibilnost podataka definiše da li se podaci slati iz jednog i koristiti za dalju obradu u drugom. Na primer, da li se tekst pisan u jednom paketu može koristiti u drugom?

4. 5. 6.

7.

8.

Međuoperativnost Opšti izraz koji se koristi za opisivanje koliko se lako različite komponente sistema mogu integrisati.

ekranu. Ako se koristi kao sistem orijentisan ka kupcu, ovo će biti kritičan faktor. Kompatibilnost ili međuoperativnost. Koliko se dobro vaše rešenje integriše sa ostalim proizvodima? Ovo uključuje ono što se sada koristi i šta će se koristiti bazirano na vašom strateškom pravcu. Bezbednost. Ovo uključuje koliko je lako podesiti kontrolu pristupa različitih korisnika i fizičku robusnost metoda za restrikciju pristupa informacijama. Stabilnost ili pouzdanost proizvoda. Ranije verzije proizvoda često imaju „bubice“ pa možete iskusiti popriličnu količinu vremena ispadanja i poziva za podršku pa odatle postoji uzrečica „nikad ne kupuj verziju jedan tačka nula“ (Verzija 1.0). Izgledi za dugotrajnu podršku proizvoda. Ako je dobavljač mala kompanija ili je verovatno da će je progutati konkurencija, da li će proizvod postojati za tri godine? Da li kompanija brzo reaguje i šalje „zakrpe“ i nove funkcije proizvoda? Da li kompanija formira strateške saveze sa drugim važnim dobavljačima koji unapređuju karakteristike proizvoda i međuoperativnost? Mogućnost proširenja. Da li će proizvod rasti? Da li su dostupne karakteristike koje mogu zadovoljiti vaše buduće potrebe? Da li su te karakteristike dostupne u inicijalnoj nabavci ili ćete morati da integrišete program od nekog drugog dobavljača? Kao opšte načelo važi da je najbolje nabaviti sve programe iz istog izvora ili koristiti što je moguće manje dobavljača: sistem će imati veću pouzdanost nego ako moraju različiti moduli da se usklađuju.

AKTIVNOST 8.7

POREĐENJE FAKTORA IZBORA ZA RAZLIČITE SISTEME

Imajući u vidu osam ključnih faktora za izbor programa diskutujte u grupi redosled značaja tih faktora za svaki od sledećih različitih tipova poslovnih informacionih sistema: • • • • •

Knjigovodstveni sistem; Sistem za kontrolu proizvodne linije; Sistem za prodaju autobuskih karata; Sistem za podršku investicija u akcije kompanije Sistem za menadžment kadrovske službe

Kreiraj tabelu za poređenje različitih faktora za svaki sistem. Objasni sličnosti i razlike.

PROCENJIVANJE PROIZVODA RAZLIČITIH DOBAVLJAČA Neka preduzeća čine grešku ograničavajući procenu novih programa na njihove tehničke vrednosti ili karakteristike. To nije mudro, jer je kupovina programa dugoročno vezivanje i kompanija zavisi od podrške koji pruža dobavljač. Mala, „početnička“ kompanija može pružiti dobar izbor karakteristika u svom proizvodu ali je verovatno da ima manje osoblja zaduženog

116

obezbeđivanje kvaliteta programa i pružanje podrške nakon prodaje. U jednom članku u časopisu Computing (8 maj 1988), Simon Rigdel, generalni menadžer ERP specijaliste JD Edwards, tvrdi: „Ljudi treba da prevaziđu čeklistu i da počnu više da obraćaju pažnju na kredibilitet dobavljača.“ Članak takođe sugeriše da mnoge kompanije troše previše vremena za odlučivanje zato što procenjuju previše dobavljača. Neki se moraju rano odbaciti kroz osnovne kriterijume kao što su njihov dosadašnji rad ili finansijska stabilnost. Istraživanje urađeno na 200 UK kompanija od strane konsultanta Tata Bramald pokazuje da su tri četvrtine njih uzimale u obzir do osam dobavljača i polovina njih je trebala više od šest meseci za odluku. Dalji rizik je da dobavljlač može u međuvremenu da propadne ili da ga preuzme neka veća kompanija i da ne bude dostupna nikakva podrška ili verzije za unapređenje sistema.

Pregovori oko ugovora Odgovarajući ugovor je od vitalnog značenja kada se angažuju spoljni saradnici za razvoj sistema ili bilo kakve funkcije informacionog sistema. Ovo može uključiti program pravljen po meri, prepravljanje već gotovog programa i angažovanje spoljnih snaga ili upravljanje kapacitetima (UK). U suštini, ugovor definiše koje aktivnosti treba da se dese, kada i ko je odgovoran za njih. Na primer, dobavljač treba da isporuči Prototip 1 do prvog oktobra, razmatranje treba da se završi do 28. novembra. Oboje, i kupac i dobavljač profitiraju zbog smanjenog rizika neuspeha Vrednost posedovanja dobro definisanog ugovora ilustruju neuspesi koji se dešavaju kada takav ne postoji. Na primer, sredinom 1990-tih engleska policija je prekinula razvoj sistema za otiske prstiju posle dve godine, tražeći odštetu od 10 miliona funti. Dobavljač, IBM, je sa svoje strane podneo protivtužbu tražeći 19 miliona funti odštete zbog nedovoljno jasnih zahteva klijenta. Sledila je dugotrajna pravna bitka dok se dogovor nije postigao. Ugovor treba da definiše sledeće glavne parametre: 1. 2. 3. 4. 5. 6. 7.

Poslovne zahteve i karakteristike sistema; Šta se isporučuje od opreme, programa i dokumentacije; vremenske termine i prekretnice za različite module; Kako se projektom upravlja; Raspodela odgovornosti između različitih dobavljača i kupca; Cenu i način plaćanja; Dugoročnu podršku sistema.

Ugovore je posebno teško postići za projekte informacionih sistema iz sledećih razloga: •

Teško je detaljno specificirati zahteve na početku projekta kada se ugovor potpisuje. Menjanje funkcionalnih zahteva može da dovede do prekoračenja projekta.

•

Ustanovljanje prihvatljivih performansi na početku projekta je teško zato što zavisi od kombinacije opreme i programa. Dosta različitih dobavljača je uključeno i često nije jasno ko je zadužen za otklanjanje problema. Kada se projekat završi može se desiti da nastane kritična greška pa je ugovor o podršci neophodan da osigura brzu korekciju. Ako dobavljačev posao propadne, sistem može biti neodrživ bez programa koji bi se morao poveriti na čuvanje trećoj strani uz ugovor o čuvanju izvornog koda.

• • •

117

Sadržaj tipičnog ugovora za IS proizvod Tipični ugovor će sadržati sledeće sekcije kao i generalne klauzule o poverljivosti, intelektualnom vlasništvu (ko poseduje pravo na program), obeštećenje, primenjiv zakon i jurisdikciju.

Sekcija 1: Specifikacije proizvoda i prijema Ovo je obično najkomplikovanija sekcija pošto detaljno opisuje karakteristike programa i kriterijume prijema. One uključuju kompletiranje svih ključnih karakteristika sa prihvatljivim nivoom grešaka i osigurava da funkcije kao što su izeštaji rade dovoljno brzo.

Sekcija 2: Ulazni podaci za projekat od strane klijenta Ova informacija se ponekad izostavlja jer većinu aktivnosti izvodi dobavljač. Aktivnosti koje su esencijalneza završetak projekta mogu uključiti vreme potrebno za pisanje i razmatranje zahteva i prototipova, vreme za testiranje korisnika pre prijema, vreme za obuku, dostavljanje podataka za testiranje, eventualno snabdevanje opremom i sistemskim programima (ako se nabavlja preko komercijale kompanije), podrška od strane internih funkcija IS i upravljanje projektom.

Sekcija 3: Usluge koje dobavljač treba da pruži Svaki isporučeni deo treba da bude povezan sa referentnim tačkama i određenom isplatom da bi se pomoglo izbegavanje proklizavanja tokom projekta. Referentne tačke treba da uključe isporuku sa obe strane, dobavljača i kupca. Česta referentna tačka je mesec dana.

Sekcija 4: Podrška sistema i garancija Ugovor o servisu treba da formuliše kako problemi „eskaliraju“ kod dobavljača (hijerarhijski put do rešenja), i treba da definišu prihvatljivo vreme reakcije u zavisnosti od težine problema. Sistem za evidenciju grešaka i kontaktni punktovi kao što je prijem poziva mogu takođe biti definisani.

Sekcija 5: Plan projekta Okvirni plan projekta koji pokazuje ključne isporuke i referentne tačke treba da bude deo ugovora. Odgovornost za upravljanje projektom će biti identifikovana na obe strane i definisani redovni sastanci.

Sekcija 6: Metod plaćanja Dva glavna metoda plaćanja su fiksna cena, koji favoriziraju kupci jer ima bolji pregled troškova, i utrošeno vreme i materijal što obično preferiraju dobavljači. Termini plaćanja bi trebali biti povezani sa referentnim tačkama (gde su one poznate pod nazivom „plaćanje po fazama“). Dobavljači mogu preferirati redovne mesečne isplate. Kaznene klauzule ili obeštećenja se mogu ugovoriti gde dobavljač gubi deo njegove isplate ako kasni sa isporukom ili klauzule o riziku i nagradi koje obezbeđuju finansijski stimulans

118

za raniju isporuku.

STUDIJA SLUČAJA 8.1 PROJEKT UREDA ZA PASOŠE – ŠTA JE TREBALO DRUGAČIJE URADITI? Sledeći izvodi su iz izveštaja o vrlo dobro poznatom projektu koji nije dobro zadovoljio svoje potrebe; desio se veliki zaostatak u izdavanju pasoša do 50 dana i dodatni troškovi u vrednosti od 12 miliona funti za otklanjanje nedostataka. Ovaj članak opisuje događaje oko projekta posle ispitivanja od strane Nacionalnog ureda za reviziju. Izvor: http://www.nao.gov.uk/publications/nao_reports/98998 12.pdf. Slučaj ističe mnoge tipične probleme sa projektima informacionih sistema, koji su jednostavni za objašnjavanje u retrospektivi ali mnogo manje jednostavni za identifikaciju unapred. Cilj prokazivanja ovog slučaja je da ispita do kog stepena bi poboljšana inicijalna faza poboljšala rezultat ovog projekta ili da li su neuspesi uglavnom bili posledica lošeg upravljanja projektom kada je projekat započet. 2.24 Agencijin operativni imperativ da započne preseljenje u kancelarije u oktobru 1988 zahtevao je od svih učesnika da isporuče novi sistem na vreme. Radeći po prihvaćenom okvirnom planu projekta, izvođači radova subili pojedinačno odgovorni za dizajniranje i testiranje spostvenih sitema. Osim nekih početnih problema sa printerima lociranim u Liverpulu nije bilo značajnijih poteškoća sa razvojem i implementacijom novog sigurnosnog sistema štampanja; ostatak ove sekcije se stoga fokusirao na novi kompjuterski sistem razvijen od strane Siemensa za podršku početne obrade i ispitivanje aplikacija.

2.27 Prva faza testova u fabrici koja je uključivala testiranje novih programa, izvršena je u Siemens-ovom centru za testiranje u julu 1988. Osoblje iz Agencije je bilo dovedeno da pomogne testiranje raznih elemenata programa. Dalje testiranje uključujući on-site testiranje

119

2.25 Obe faze, dizajn i razvojna faza koje se donekle preklapaju, trajale su duže nego što je očekivano. Faza razvoja je završena nekih četiri meseca kasnije nego što je očekivano i samo šest meseci pre datuma početka rada uživo. Tokom faze dizajna Siemens je trebao da stekne detaljno razumevanje postojećeg procesa Agencije i da postavi rešenje koje će zadovoljiti Agencijine zahteve. Diskusija između Siemens-a i Agencije je duže potrajala nego što je bilo očekivano pošto je svaka strana težila da razjasni namere druge strane i da postigne saglasnost oko specifikacija sistema, na primer da omgući sistemu da zadrži elektronsku sliku aplikacionog formulara i da preuzme dodatne informacije sa formulara kao što su lični podaci supotpisivača koji se pojavljuju na zahtevima za pasoš. Faza dizajna je bila evolucioni proces sa više verzija dokumenata dizajna kako je nov sistem bio definisan i redefinisan od strane Agencije i Siemens-a. Ovaj proces je takođe prolongirao sledeće faze razvoja. 2.26 Kao rezultat kašnjenja u fazi dizajna i razvoja, testiranje je počelo skoro četiri meseca kasnije nego što je planirano. Tokom faze testiranja Agencija je, na savet konsultanata iz Central Computer and Telecommunications Agency, imala uvid u rezultate testova koje je čuvao izvođač i predstavnici Agencije su prisustvovali većini testova.

specifičnom za ulogu koju će preuzeti. Siemens je obučio Agencijine instruktore i pripremio materijale za kurseve vezane za korišćenje kompjuterskog sistema. Siemens je preuzeo odgovornost za obuku osoblja koje je bilo predviđeno za rad sa njim. Procena obuke za

u Liverpulu je bilo urađeno u avgustu i septembru. U vreme kada je sistem pušten u rad uživo u oktobru veći deo funkcija srži sistema je bio isporučen na vreme iako neki delovi sistema, na primer upravljanje izveštajima, nije još bio do kraja razvijen. Uzeto u celini, Central Computer and Telecommunications Agency izveštava da je sistem bio dobro dizajniran. Sa tog sanovišta, ured u Liverpulu je trebao da radi uživo kao „kontrolisana probna lookacija“ iako je možda bilo potrebe za produženjem probe zbog problema sa pouzdanošću tokom testiranja. 2.28 Interna revizijska služba u okviru Agencije koju je obezbedila Home Office Internal Audit je ispitala uvođenje novog sistema tokom septembra i početkom oktobra i zaključila da: „Uzimajući u obzir tesne vremenske rokove u kojima je projekat razvijan bio je dobro upravljan uz čvrstu kontrolu da bi se osigurao kvalitet krajnjeg proizvoda. Međutim, bilo je zgušnjavanja rokova za testiranje. (Mi) razumemo prisilne razloge za željom da se ispoštuje početak probnog rada 5. oktobra 1988 i prihvatamo da je funkcionalnost (novog) sistema uglavnom bila proverena. Ipak, postoji rizik da će probni rad možda trebati da produži svoj rok da bi se osiguralo da robusna operaciona i korisnička procedura i kontrola budu uspostavljene. 2.29 Zbog pritiskanja rokova, program testiranja nije obuhvatio temeljno testiranje uticaja sistema na produktivnost. Tokom prijemnih testova opreme koji su obavljeni u Siemens-ovom test centru u julu 1988, Agencija je postala svesna da faza ispitivanja u toku obrade zahteva za pasoše traje mnogo duže sa novim sistemom. Agencija je nameravala da izvrši dalje testiranje produktivnosti na lokaciji u Liverpuluu septembru pre početka rada uživo ali, iako je terminal bio izdvojen za to, test nije obavljen zbog nedostatka vremena. 2.30 Administrativne procedure koje su trebale da podrže novi sistem nisu bile testirane i nisu bile potpuno dokumentovane u vreme kada su kursevi za obuku osoblja Agencije u Liverpulu počeli u septembru. Svo osoblje Agencije je dobilo osnovnu obuku u Agenciji zajedno sa daljom obukom

120

osoblje Agencije, izvedena od strane Agencije u oktobru i bazirana na povratnoj informaciji od strane osoblja, pronašla je da su kursevi bili dobro prezentovani i da su ispunili njihove ciljeve. Međutim, u proceni je primećeno da su ciljevi obuke bili vezani primarno za korišćenje novih kompjutera a manje za administrativnu proceduru podržavanja novog sitema za izdavanje pasoša. 2.31 Agencijin plan implementacije (skica 8.3) predviđa postepeno uključivanje novog sistema izeđu oktobra 1998 i februara 1999 počevši u Liverpulu a zatim i Newport-u. Agencijincilj je boi da instalira novi sistem pre sezonskog rasta aplikacija početkom Nove Godine. U svakom uredu, postojeći kompjuterski sistem bi se uklonio, građevinski radovi uradili gde je neophodno i izvršila rekonfiguracija ureda, sa prostorom predviđenim za Siemens-ovo osoblje; novi bi se sistem instalirao i testirao i osoblje obučilo. Agencija je očekivala da svaki ured završi sa obradom postojećih zahteva pre datuma zatvaranja i prebaci budući posao drugim uredima koji bi normalno radili. Cilj je bio da se zadrži normalan nivo usluge građanstvu. 2.32 Faza zatvaranja u Liverpulu je počela na vreme 5. oktobra. Agencijin raspored rokova je ostavio malo vremena za konačnu odluku o zavaranju Newport-a koje je trebalo da počne 16. novembra. Pripreme u uredu u Newport-u, uključujući reorganizaciju zgrade, počele su pre nego što je Liverpul počeo sa radom uživo a finalna odluka o Newport-u je trebalo da se donese u okviru pet nedelja posle početka rada uživo u Liverpulu. Ključni datumi i događaji u projektu •

•

Juli 1996 Agencija za pasoše odlučuje da uvede digitalizovan pasoš da bi smanjila rizik postojanja falsifikovanih pasoša, zameni postojeći kompjuterski sistem i poboljša njegovu efikasnost delotvornost. To bi se uradilo kroz privatno finansiranje ili davanje ugovora spoljašnjim snagama koje treba da donesu efikasnu uštedu. April 1997 Primljene ponude izvođača.

Skica 8.3 •

•

•

•

• • •

Gantt grafikon za projekat Ureda za pasoše prikazuje originalni osnovni plan i aktuelno vreme izvođenja Izvor: National Audit Office

Jun 1997 Agencija za pasoše dodeljuje 10godišnji PFI ugovor vrednosti 120 miliona funti za štampanje i distribuciju digitalizovanih pasoša firmi The Stationery Office (sada Security Printing & Systems Limited). Jul 1997 Agencija za pasoše dodeljuje 10godišnji PFI ugovor vrednosti 120 miliona funti firmi Siemens Business Service za prikupljanje, čuvanje i prenos podataka iz aplikacija za pasoše. April 1998 Izdato saopštenje da će od oktobra 1998 deci koja nisu već upisana u pasoš biti potreban sopstveni pasoš za putovanje u inostranstvo. Detalji uslova su uključeni na novim aplikacionim obrascima koji su distibuirani od tog datuma. 5 oktobar 1998 Novi IT sistem i procedure spoljašnjih saradnika uvedene u lokaciju Agencije za pasoše u Liverpulu. 100 zaposlenih poslato u Siemens. Uvođenje uslova da deca imaju sopstveni pasoš ako već nisu uvedena u postoječi. 9 novembar 1998 Upravni odbor Agencije za pasoše odlučuje da uvede novi sistem i procedure na lokaciji Newport. 16 novembar 1998 Novi sistem i procedure uvedene na lokaciji Newport. 96 zaposlenih poslato u Siemens. 18 novembar 1998 Upravni odbor Agencije za pasoše odlučuje da odloži uvođenje novog sistema u preostale četiri lokacije.

121

•

• •

•

22/23 februar 1999 Upravni odbor Agencije za pasoše odlučuje da se usredsredi na davanje prioriteta aplikacijama prema datumu putovanja. Druge mere dogovorene da se poveća izlaz uključujući dodatne isplate osoblju da poveća broj prekovremenih časova (zatim produženo i povećano). Sredina marta 1999 Home Office izrazio ozbiljnu zabrinutost razvojem sitacije. Dogovoren plan oporavka poslovanja. Maj 1999 Besplatno dvogodišnje produženje nedavno isteklih pasoša ponuđeno onima koji su čekali u redovima u Uredu za pasoše. Skoro potpuna obustava davanja telefonskih obaveštenja u Liverpulu. Transfer aplikacija iz Liverpula i Newport-a u druge urede obustavljen. Kasni jun/ rani jul 1999 Skala hitnih mera uvedena, uključujući dodatnih 100 zaposlenih, uvedeno besplatno produžavanje pasoša u poštama, uvedena specijalna telefonska linija za pomoć.

Izvor: UK Nationa Audit Office

PITANJE Proceni do kog stepena bi poboljšana inicijalna faza poboljšala rezultat ovog projekta ili da li su neuspesi uglavnom bili posledica lošeg upravljanja projektom kada je projekat započet.

PREGLED Pregled faze: Inicijacija Svrha: Ključne aktivnosti: Ulaz: Izlaz:

Određuje vitalnost sistema i tehnike koršćene za akviziciju Studija izvodljivosti Ideja za novi sistema ili problem sa već postojećim Studija izvodljivosti, preporuka za nastavak

Glavne karakteristike i faktori uspeha inicijalne razvoja sistema su kao što sledi: 1. 2.

3.

Inicijalna faza je prva faza životnog ciklusa razvoja sistema. Inicijalna faza se generalno smatra da se sastoji iz dve glavne aktivnosti: generisanje ideje za novi sistem i procenu izvodljivosti uvođenja novog sistema. Procena izvodljivosti treba da se uradi za sve projekte, bez obzira na metod akvizicije. Procena izvodljivosti će uključiti poređenje različitih alternativa u pogledu njihove:

• • • •

4.

5.

Ekonomske izvodljivosti – analiza troškova i dobiti; Tehničke izvodljivosti – procena vrednosti različitih akternativa u pogledu njihove praktičnosti; Operativne izvodljivosti – da li će sistem zadovoljiti poslovne potrebe i potrebe krajnjih korisnika; Organizacionu izvodljivost – da li osoblje ima znanje potrebno za korišćenje sistema i kako će njihov stav uticati na prihvatanje sistema?

Postoji opseg finasijskih merila za procenu finansijske vitalnosti novog sistema. Ona treba da uzmu u obzir variranje tokom vremena troškova i dobiti korišćenje korigovanog protoka novca. Nefinansijska merila ne treba zanemariti. O ugovoru za isporuku sistema treba da se pregovara na početku; to minimizira rizik od neuspeha projekta i obezbeđuje adekvatnu podršku kada sistem postane funkcionalan.

VEŽBE Vežbe za sopstvenu proveru 1) Šta je svrha inicijalne faze projekta? 2) Na šta se misli u izrazima „materijalna“ i „ nematerijalna dobit“? 3) Identifikuj svaku od sledećih stavki kao materijalnu ili nematerijalnu dobit ili trošak: (a) kupovina servera za čuvanje podataka sa novim informacionim sistemom; (b) smanjeno verme čekanja kupaca kada se raspituju za napredovanje neke porudžbine;

122

4. 5. 6. 7. 8.

(c) Prekid uzrokovan instalacijom nove mreže u kompaniji; (d) Smanjen period držanja zaliha zahvaljujući novom sistemu za upravljanje zalihama. Ukratko izloži razlike između ekonomske,operativne, tehničke i organizacione izvodljivosti; Šta se podrazumeva pod terminom „procena rizika“ i kako se može primeniti da pomogne u razvoju projekta informacionog sistema? Koja je svrha i kratak pregled sadržaja „zahteva za ponudu“ ili dokumenta „poziv na tender“? Šta su ključni faktori koje će kompanija uzeti u obzir kada izabira programe od različitih dobavljača? Šta su glavne tačke koje treba da budu specificirane u ugovoru za informacioni sistem?

Pitanja za diskusiju 1. Do koje su mere neuspesi mnogih projekata informacionih sistema posledica premalo utrošenog vremena na inicijalnoj fazi? 2. „Tehnike koje su na rspolaganju za poređenje različitih programskih paketa ili sistema od različitih dobavljača se moraju striktno primenjivati“. Diskutuj.

Pitanja za esej

1. Ispitaj glavne posledice za jedan projekat informacionog sistema ako se inicijalna faza izostavi. 2. Kompanija namerava da kupi knjigovodstveni program za 100 zaposlenih i razmatra tri različita paketa. Trenutno koriste aplikaciju baziranu na Microsft Windows 2000 sitemu ali žele da pređu na aplikaciju baziranu na Microsft Windows XP sistemu. Daj kompletan pregled faktora koje treba da uzmu u obzir kada prave poređenja. Koje faktore smatrate najvažnijim? 3. Procena rizika je vredna alatka za projekt menadžera. Šta ta tehnika uključuje i koji budući rizici se mogu identifikovati u raznim fazama razvoja projekta sistema? 4. Napišite kratku studiju izvodljivosti ili početni izveštaj za novu elektronsku trgovinu ili poboljšanje za već postojeću ugrađujući inicijalne faze spomenute u ovom poglavlju. Može da se odnosi na neku fiktivnu kompaniju, malu kompaniju koju poznajete ili veću kompaniju čije stranice na internetu možete da posetite. Vaš odgovor ne treba da bude ograničen na istraživanje ekonomske, operativne, organizacione i tehničke izvodljivosti nego treba da uključi sve aspekte inicijalnog planiranja pređenog u ovom poglavlju.

123

Ispitna pitanja 4) Šta je svrha utvrđivanja sledećih tipova izvodljivosti: (a) (b) (c) (d)

operativne; organizacione; tehničke; ekonomske.

2) Navedi tri razloga kompanije za pokretanje projekta informacionog sistem. Daj kratko objašnjenje za svaki. 3) Definiši angažovanje spoljašnjih saradnika za informacioni sistem. 4) Navedi primere primere dva materijalna troška i dva nematerijalna troška koji koji se mogu napraviti tokom razvoja projekta informacionog sistema. 5) Šta su najvažniji faktori koje treba uzeti u obzir prilikom poređenja alternativnih programskih paketa?

REFERENCE Carr, N. (2003) „IT doesn’t matter”, Harvard Business Review, May, 5-12 COBIT (2000) Executive Summary of COBIT. Izdao COBIT Steering Comitee and the IT Governance Institute. Dostupno on-line na www.isaca.org/cobit KPMG (2002) KPMG Assurance surveys, Program Management Survey, October www.kpmgco.uk/kpmg/uk/services/audit/surveys.cfm Lyytinen, K. and Hirscheim, R. (1987) „Information systems failures: a survey and classification of the empirical literature“, Oxford Surveys in Information Technology, Vol. 4, pp. 257-309 Parker, M. and Benson, R. (1988) Information Economics: Linking Business Performance to Information Technology, Prentice-Hall, Eaglewood Cliffs, NJ Radosevich, L. (1999) “Measuring up – project management successfully”, CIO Magazine, 15 September. Dostupno u arhivi na www.cio.com Reicheld, F. and Schefter, P. (2000) E-loyalty: your secret weapon on the Web”. Harvard Business Review, July-August, 105-13 Remenyi, D. (1995) The Effective Measurement and Management of IT Costs and Benefits, Butterworth-Heinemann, Oxford

Robson, W. (1997) StrategicManagement and Information Systems:An Integrated Approach, Financial Times Pitman Publishing, London Senn, J. (1995) Information Technology in Business: Principles, Practices and Opportunities, Prentice-Hall, Eaglewood Cliffs, NJ Ward, J. And Peppard, J. (2002) Strategic Planning for Information Systems, 3rd edition, John Wiley, Chichester

124

Dodatna literatura Boehm, B. (1991) „Software risk management: principles and practices“, IEEE Software, 8, 1, January, 32-41. Detaljna procena rizika koji se dešavaju na nivou kreiranja programa i poboljšanja. Radosevich, L. (1999) “Measuring up – project management successfully”, CIO Magazine, 15 September. Dostupno u arhivi na www.cio.com Dostupan uvod u faktore koji utiču na merila projekta koje treba uzeti u obzir prilikom inivijacije projekta. Sandison,H. (1992) “Introductpon to software development contracts”, in D. Allen and K. Davis (eds), Allen and Davis on Computer Contracting: A User Guide with Forms and Strategies, Prentice-Hall, London

WEB LINKOVI www.buyitnet,org UK najbolja-praksa organizacija za IS i e-biznis nabavke. Uključujući studije slučaja i direktive. www.coi.com Za CIO (Chief Information Officers) ima dosta članaka koji se odnose na analize i dizajn u raznim istraživačkim centrima kao što su beznednost, CRM i infrastruktura www.cio.com/research/security www.cio.com/research/crm www.cio.com/research/infrastructure www.isacf.org/cobit Slučajevi i specifikacije za COBIT model upravljanja za Control Objectives for Information and related Technology. www.computerweekly.com Computer Weekly nedeljni magazin za IS profesionalce as fokusom na UK/Evropu koji ima mnoge studije slučajeva praktičnih problema iz oblasti analize, dizajna i implementacije. www.research.ibm.com/journal IBM Systems Journal i Journal of Research and Development imaju mnogo primera i članaka o analizi i dizajnu vezanim za koncept e-poslovanja kao što su upravljanje znanjem, bezbednost. www.intranetjournal.com/dev The Intranet Journal ima studije slučajeva analize sistema i dizajna specifičnog za intranet. www.fdic.gov/regulations/examinations FDIC: The Federal Financial Institutions Examination Council (FFIEC) priručnik za provođenje ispitivanja informacionih sistema banak i štednih institucija, zanimljiv zato što preporučuje odgovarajući pristup i aktivnosti u različitim fazama razvoja bankarskog sistema što može da se primeni i na druge sisteme. http://knowledge.wharton.upenn.edu/index.cfm?fa=viewCat&CID=14 Managing Technologies at Wharton članci pokrivaju skalu slučajeva upravljanja tehnologijom uključujući procenu izvodljivosti i prihod od investicije.

125