ŠOPING-LISTA NIJE PROJEKAT

Nabavka kompleksnog IT rešenja nije posao koji se radi preko noći. Treba mu se ozbiljno posvetiti i obaviti niz predradnji, pre nego što se pomisli na to koja oprema i softver su potrebni za izvođenje projekta.

Kaluđerica je veliko naselje nadomak Beograda koje je godinama građeno bez plana i projekata za puteve, kanalizaciju, struju… Rezultat takve gradnje mogli ste da vidite i sami, i to ne samo u Kaluđerici. Kaluđerica je ovde samo slikovit prikaz rezultata koji se dobijaju kada se gradi bez plana, bez projektnog zadatka i pojektne dokumentacije. Da se ne radi o hipotetičkom poređenju već o uvreženoj praksi svedoči veliki broj neuspešnih IT projekata, čija se šteta na godišnjem nivou u Srbiji meri pre stotinama nego desetinama miliona evra.

Bez preskakanja koraka

Jedan od čestih slučajeva je da se IT projekti realizuju bez projektnog zadatka, koji bi trebalo da proizađe iz potreba poslovanja, a taj zadatak pred IT treba da postavi menadžment kompanije, javne ili državne institucije. Međutim, često se dešava da menadžment kompanije ne poklanja dovoljno pažnje artikulaciji potreba biznisa i postavljanju jasnog zadatka pred IT. S druge strane, IT stručnjaci ne poznaju dovoljno primarnu prirodu poslovanja kompanije za koju rade, pa i ne osećaju potrebu da posao urade na sistematizovan način, kako se to inače radi u tehničkim strukama.

Najčešći primeri govore da se ovaj posao, umesto detaljne izrade projektne dokumentacije, svodi na šoping‑listu opreme i softvera, bez dublje analize šta će se time postići i kako edukovati korisnike da korišćenjem ove tehnologije daju poslovanju opipljivu korist. Kao krajnji rezultat imamo uzaludno potrošen novac, bez vidljivog pozitivnog uticaja na biznis.

Poređenja radi, investiranje u IT bez projektne dokumentacije bilo bi slično kao kada biste kupili materijal za izgradnju kuće, a da prethodno i ne znate koliko će osoba živeti u toj kući, koliko soba želite, koliko kupatila itd. U tom slučaju ćete od materijala koji ste kupili možda i moći da izgradite nekakvu kuću, ali ona sigurno neće odgovarati nameni.

Nažalost, i u IT‑ju ima dosta sličnih primera, gde se bez plana i projekta prvo nabave „crep i cigla“, pa se naknadno pokušava konstruisati rešenje. Najčešći primeri ovakvog pristupa sreću se u javnom sektoru, a nije mali ni njihov broj u ostalim segmentima poslovanja.

Zašto se radi na ovakav način?

Razlozi su brojni. Jedan od osnovnih je to što je IT struka relativno mlada i još uvek nema strukturiranog obrazovanja u ovoj oblasti. Uz to, i tehnologija se menja veoma brzo, pa ne postoji ni jedinstvena metodologija za projektovanje, za razliku od stotinama godina starih inženjerskih struka, kao što su građevina ili mašinstvo, gde je nezamisliva mogućnost da se bilo kakav projekat sprovede bez preciznog projektnog zadatka i detaljne projektne dokumentacije.

Navedenim razlozima valja dodati i to da se od ovakvih investicija često ne zahteva opravdanost, uz odsustvo prakse da se nakon nekog perioda (bar 12 meseci) sagledaju efekti investicije u IT, kako bi se potvrdilo da su dobiti u poslovanju kompanije ili u efikasnosti državne/javne uprave finansijski veći od ulaganja u IT. Kako se to ne radi, nema ni odgovornosti za utrošena sredstva, niti beneficija za dobro izveden projekat.

Ovakva situacija pogoduje razvoju drugih anomalija, pa se često obavljaju nabavke za koje se unapred zna da ne mogu imati pozitivan efekat na poslovanje. Primarna svrha ovakvih nabavki jeste da neko od ponuđača dobije posao – ovde često srećemo na delu i korupciju – pa aktivnosti traju dok se ne isporuči oprema, a oprema i licence onda ostaju u kutijama ili se oprema eventualno uključi „da zasvetle lampice“, kako bi se stvorio utisak da je posao dobro urađen.

Usled nedovoljnog ulaganja u edukaciju kadrova za ovladavanje najnovijim tehnologijama, IT se često oslanja na vendorske prodavce, verujući im da su oni u stanju da „iz rukava“ isporuče gotovo rešenje. Po pravilu, prodavci imaju za cilj da vam prodaju što više opreme i softvera, a ako vi nemate projektno rešenje – oni će to i uraditi, bez imalo odgovornosti za rezultat. Poređenja radi, ovakav pristup bio bi isti kao kada biste otišli kod lekara, a on vas i ne pita za simptome vaše bolesni, niti uradi bilo kakve analize, već vam samo propiše najnoviji lek i kaže da će vas on odmah izlečiti. Samo precizan projektni zadatak i detaljna projektna dokumentacija garantuju uspeh.

Dakle, projektni zadatak je osnovni, početni dokument koji definiše zahteve. Ovaj dokument ishodi iz poslovnih potreba privatnog ili javnog preduzeća, odnosno državnog organa. Projektni zadatak treba detaljno da opiše šta se želi postići u poslovanju, bilo kroz povećanje efikasnosti ili ubrzavanje procesa, do povećanja produktivnosti, postizanja uštede ili drugih koristi za preduzeće. Projektni zadatak ne mora da zalazi u tehničke detalje, niti da daje izričite instrukcije takve vrste.

Tehnički uslovi su važan deo svakog projekta i njima se definiše postojeće okruženje u kome se realizuje projekat. Oni podrazumevaju opis postojeće infrastrukture na kojoj će se sprovesti projekat ili će se postojeća infrastruktura nadograditi, bez obzira na to da li se radi o hardverskoj ili aplikativnoj infrastrukturi.

Pri pisanju projektnog zadatka i opisu tehničkih uslova ne treba robovati formi, već valja precizno opisati zahteve i uslove koji su relevantni za izradu projektne dokumentacije, tako da projektant ima pred sobom jasan zadatak i opis okruženja za koje se izrađuje projektna dokumentacija.

Studija izvodljivosti

Ukoliko se radi o zahtevima koji do tada nisu široko primenjivani i za koje treba koristiti najnovije tehnologije, za koje se ne zna kakve rezultate mogu postići, bilo bi korisno da se pre izrade projektne dokumentacija uradi studija izvodljivosti, koja bi pokazala da li bi takav projekat bio tehnički, vremenski i kadrovski izvodljiv i da li bi bio ekonomski opravdan.

Tek nakon ovih priprema treba pristupiti izradi tehničke dokumentacije. Ukoliko u kompaniji nema kadrova koji su u stanju da izrade tehničku dokumentaciju, treba angažovati kompetentnu firmu, koja iza sebe ima dobre reference i koja će izraditi projektnu dokumentaciju ili biti konsultant na njenoj izradi.

Za proceduru projektovanja postoje razne metodologije, od projektovanja ERP rešenja pa sve do projekata za IT infrastrukturu. Svaka metodologija projektovanja usmerava projektanta da se projekat uradi na strukturiran način, uz obradu svih potrebnih segmenata, kako bi izvođač projekta mogao da na pouzdan način i u potpunosti izvede projekat. Međutim, svaki projektant u skladu sa projektnim zadatkom može koristiti i svoju metodologiju.

Projektna dokumentacija mora nedvosmisleno da odgovori na sva pitanja postavljena u projektnom zadatku. Dakle, rešenje mora biti precizno opisano, uz svu potrebnu dopunsku dokumentaciju, šematske prikaze, tabele i tehničke opise koji u dovoljnoj meri opisuju rešenje, da bi izvođač na osnovu toga mogao da izvede projekat.

Provera rezultata

Za razliku od brojnih primera u Srbiji, gde se prvo kupuju opema i licence pa se onda pokušava da se iznađe neko projektno rešenje, u valjanoj projektnoj dokumentaciji tek na kraju dolazi specifikacija opreme, licenci i potrebnih usluga za realizaciju projekta. Da bi projekat u potpunosti odgovorio svojoj nameni, uz specifikacije moraju stajati i budžetske cene, odnosno ukupna cena izvođenja projekta.

Važan deo pri izradi projektne dokumentacije predstavlja i analiza ekonomske isplativosti i analiza povratka investicije (ROI). Iako cena projektovanja može činiti i 10% od ukupne investicije, to sigurno nije uludo bačen novac; naprotiv, adekvatno projektovanje štiti investitora od mogućnosti da projekat bude neuspešan i garantuje da implementacija projekta može ostvariti projektovane dobiti.

Da bi se potvrdilo da je projekat dobro isplaniran i izveden, potrebno je nakon određenog perioda od puštanja projekta u produkciju analizirati da li su projektom postignuti tehnički i ekonomski ciljevi postavljeni u projektnom zadatku. U suprotnom, odgovornost za neuspeh projekta mogu snositi investitor, projektant, izvođač ili korisnik.

12 pravila za uspeh IT projekata

  • Šoping‑lista nije projekat!
  • Bez preciznog projektnog zadatka ne ulaziti u proces projektovanja
  • Projektni zadatak mora biti baziran na jasnim poslovnim ciljevima
  • Za projektanta izaberite kompetentnu firmu, koja ima uspešno izvedene referentne projekte
  • Ukoliko se radi o kompleksnom projektu i primeni novih tehnologija, pre projektovanja uradite studijo izvodljivosti
  • Dobro proučite tehničke uslove i okruženje pre nego što otpočnete projektovanje
  • Pored tehničkog rešenja, projektna dokumentacija mora sadržati ekonomske pokazatelje isplativosti projekta
  • Ne raspisujte tender za nabavku opreme i licenci na početku, već na kraju projekta
  • Izaberite isporučioca i implementatora projektnog rešenja na osnovu znanja i pozitivnih referenci
  • Nakon najmanje 12 meseci životnog veka izvedenog projekta izvršiti analizu efekata i poređenje sa zacrtanim ciljevima iz projektnog zadatka
  • Svaki dobro izveden projekat mora imati kontinualnu, pouzdanu, plansku i incidentnu stručnu podršku
  • Samo dobro urađena projektna dokumentacija garantuje uspešno sprovedenu tendersku proceduru

Proof of Concept i pilot‑projekat

Ukoliko se radi o složenijem projektu koji treba da se uklopi u postojeće okruženje, možda će biti neophodno da se uradi potvrda koncepta (Proof of Concept), a ukoliko ima ikakvih nedoumica oko funkcionisanja projekta, tada bi trebalo uraditi pilot‑projekat koji će pokazati sve funkcionalnosti u manjem okruženju. Ovakvi postupci mogu biti od koristi da se projekat uspešnije isplanira i izvede, ali i da se izbegnu mogući rizici.


S.D.

0 %s Comments

Prosledi komentar

Vaša adresa e-pošte neće biti objavljena.

Najnoviji

Novi-NetApp-proizvodi

Novi NetApp proizvodi

Da li su vam već poznati novi NetApp sistemi C-serije, sa QLC Flash tipom ...
Veštačka-inteligencija-u-našim-rukama

Veštačka inteligencija u

Broj oblasti u kojima se eksperimentiše sa različitim dostignućima veštačke ...
Azure-Active-Directory--postaje-Entra-ID

Azure Active Directory

Azure Active Directory je sada Entra ID. I premda većina korisnika ovu promenu ...
Transformacija-tehničkog-duga--pomoću-DevOps-tehnologija

Transformacija tehničkog duga

Najveću opasnost za organizacije ne predstavlja samo postojanje tehničkog duga, ...