U prethodnom članku predstavili smo sve važne faze digitalng projekta. One glase:

Projektne faze digitalnog projekta

U ovom članku ponovo se osvrćemo na faze digitalnog projekta, kako bismo pokazali koliko su specifične pri uvođenju novog sistema za do sada nekorišćene procese. Ovde treba naglasiti da nije reč o zameni postojećeg rešenja novim.

Osobenosti novih sistema mogu biti predstvaljene kao prednosti i mane.

Prednosti

• Kod novih sistema uvek se polazi od nule, a to znači: niti je potrebno uzimati u obzir stare nerešene probleme, niti je prisutna migracija podataka.
• Sistem je moguće prilagoditi i podesiti zahtevima, baš onako kako je potrebno da bude.
• Operativni biznis kod novih sistema još uvek nije u tolikoj meri involviran, obzirom da nije neohodno stalno ažuriranje sistema.
• Obzirom da se procesi sporo menjaju, opšti uslovi sistema ostaju stabilni.

Mane

• Najveća mana je činjenica, da je sistem nov i da nimalo iskustva nije stečeno u radu sa njim.
• Upravo nedostatak iskustva u radu sa novim sistemima otvara brojna pitanja:
  • Koje su važne tačke koje je potrebno definisati?
  • Koje funkcije su bitne, koje nisu?
  • Kakvo je iskustvo korisnika?
  • Koje je sve sisteme potrebno involvirati?
  • Šta čini sistem komplikovanim, a šta ne?
  • Kako se povezuje sa drugim sistemima?
  • Ko je vlasnik?
  • Kako na kraju da povežem novi sistem sa procesima?
  • Kako korisnici da primenjuju sistem i kako ih pridobiti da ga zaista koriste?

1. Inicijalizacija projekta

Pretpostavimo da je reč o projektu preko 50.000 evra koji treba da prođe postupke odobrenja preduzeća.

• Sužavanje obima (scope)

U fazi inicijalizacije projekta nastaje ideja. Stoga ova faza odmah mora istaknuti šta sistem treba da postigne i koje procese da pokrije.

Ako je obim (zbir svih zahteva koje sistem treba da pokrije) uzak, tada je i sistem mali i pregledan, ali je korist eventualno suviše mala da bi stigao na dnevni red.

Ako je obim suviše širok, moguće je da su troškovi previsoki pa projekat postaje preobiman.

• Način postupanja

Naručiocu je neophodno dostaviti izveštaj o strategijskom značaju, budžetu, rešenju problema i korisnicima. Potrebno je stvoriti jasnu sliku o tome koju pažnju menadžment poklanja tom sistemu (pre svega koje ciljeve i zaradu odnosno koju dobrobit projekat treba da donese čitavom poduhvatu).

Ali ovde se ne radi o tačnoj definiciji postupka, jer ona naručiocu neće biti ni od kakve koristi. Iz njegovog ugla posmatrano, jednostavno je potrebno razraditi ga.

Važno je steći predstavu o tome i nadalje u krugu glasati o svemu. Pri tome je pre preporučljivo zalaženje u detalje, čak i ako tokom radionicam dođe do izmena, nego rad sa nejasnim idejama koje bude različita očekivanja na različitim odeljenjima i različitim nivoima. Naime, preciznost detalja je više prednost nego mana.

Odobravaju se prvi resursi za grube koncepte i postalvja se grubi koncept. Definišu se grubi zahtevi, prednosti i troškovi. Ako su obim projekta i grubo razumevanje iznad business case-a, mogu se uočiti strateške i finansijske prednosti.

Sledi procena troškova kroz razgovore sa sopstvenim IT odeljenjem, eventualno i prve procene firmi i eksternih konsultanata. Poslednji korak ove faze pre odluke menadžmenta jeste postavljanje business case-a, koji će sve da obuhvati, uključujući i projaktni tim, koji realizuje projekat, i projektni plan.

Sada predstoji odluka menadžmenta o daljem vođenju projekta. Ovo podrazumeva razvijanje obrasca za odluke za naredne korake, procenjivanje troškova za fazu detaljnog koncepta, definisanje projektnog tima i eksternih konsultanata i eventualno raspisivanje tendera.

Ako ništa ne sprečava dalje vođenje projekta, odobravaju se sredstva za detaljan koncept.

2. Detaljan koncept  (setup projekta)

• Izrada detaljnog koncepta

Najpre se pokušava grubi koncept razložiti u detalje, kako bi se procenili troškovi. Već u ovoj fazi moraju se definisati mnogi aspekti. Ali upravo to često predstavlja teškoću stručnim odeljenjima, jer imaju pune ruke posla.
Često se ova tačka ne razmatra dovoljno precizno, jer je već na ovom stepenu detaljisanja potrebno doneti odluku za rešenje. Tako, na primer, klijent može jednu ili deset slika da posatvi pomoću altke, kao zip folder ili svaku pojedinačno. Zbog straha od opredeljenja ovakve odluke se ne donose, koncept i dalje ostaje neodređen, a procena troškova nedovoljno pouzdana.
U ovom trenutku važno je skicirati rešenje, čak i ako će ono kasnije biti izmenjeno. Na taj način sve izmene troškova ostaju transparentne. Preporučljivije je da se put za rešenje menja naknadno, ali preciznije, nego da ostaje nedefinisan.

Ne sme se zaboraviti da detaljan koncept i dalje predstavlja samo specifikaciju posla, a ne tehničko rešenje. Detaljan koncept uključuje korisnike, uloge, veze, procese, neophodna polja podataka, MockUp-ove i scenarije grešaka.

• Procena pomoću IT odeljenja

Čim je detaljan koncept do pojedinosti opisan, IT kreira rešenje zasnovano na postojećim resursima i znanjima. To rešenje sadrži predloge o tome, koji deo rešenja se interno, a koji eksterno odvoja. Pošto je ova tema nova za IT odeljenje, teško je dati neku procenu. Mnogo toga ovde zavisi od ličnosti zaposlenih, od toga da li procenjuju previsokim trud koji je potrebno uložiti, da li IT vodi previše ili premalo računa o bezbednosti i da li se upušta u rizike. Pri preuzimanju u business case ovo obavezno treba uzeti u obzir.

• Odluke make-or-buy

Čim se da predlog da se jedan deo rešenja eksterno obavi, menadžment mora doneti odluku make-or-buy. Obzirom da je reč o novom rešenju, moguća su tri puta:

• Rešenje se kupuje kompletno novo.
• Rešenje se programira u sopstevnom preduzeću, jer je prisutno znanje i stručnost.
• Radi se na proširenju znanja, pa se rešenje programira u sopstevnom preduzeću.

Koji će od ova tri načina biti odabran, zavisi od strateškog značaja teme.

• Procena troškova i raspisivanje tendera (takođe uz sopstveno IT odeljenje)

Ukoliko je sve definisano, stvarni troškovi se mogu detaljno proceniti. Za eksterne usluge sledi raspisivanje tendera odnosno potrebno je pribaviti procene troškova od dvojice dobavljača.
Loše posledice moglo  bi da ima, ukoliko detaljan koncept nije dovoljno precizan. IT odeljenje to neće moći proceniti, već će kod nesigurnosti obezbeđivati doplate za bezbedno postizanje rešenja. To bi moglo biti veoma skupo, pa bi troškovi neproporcionalno rasli. Zbog toga je važno izbeći ovo.

• Odluka oko realizacije i DL (download?)

Ako su poznati svi troškovi, može se početi sa kreiranjem finalnog obrasca za odluke, kako bi menadžmentu bili prikazani tačni troškovi.

3. Realizacija

Čim je odluka pala, može se započeti sa stvarnom realizacijom.

Od ovog trenutka dolaze do izražaja prednosti stvaranja novog softvera za novu temu. Sistem se stvara od samog početka i prilagođava se postojećim zahtevima. Kako će se dalje odvijati programiranje, uvođenje (kod postojećih rešenja) ili prilagođavanje sistema zavisi od IT odljenja i DL-a, ali spada takođe pod odgovornost tehničkog vođe projekta.

Šta je važno za digitalnog vođu projekta  pri realizaciji novog sistema (interfejs između stručnih odeljenja i IT odeljenja)

• Planiranje novih projekata Planiranje treba da usledi preko više distribucija i u vidu manjih paketa. Stalno će se pojavljivati zamke, koje će prouzrokovati pomeranja i kašnjenja. Za svako distriburanje potrebno je odvojiti i dovljno vremena za testove. U to se ubrajaju kako funkcionalni testovi tako i nadgledanja realizacije zahteva.
• Zamke Pošto je realizacija projekta najvažniji deo, posebno je važno imati u vidu faktore budžet, vreme i kvalitet. Kod novih rešenja mogu se javiti zamke tj. zahtevi mogu dovesti do tehničkih problema koji će postati uočljivi tek pri programiranju. Važno je izolovati ovakve zamke i definisati moguće alternative. Pritom bi trebalo iz ugla poslovanja odlučiti, šta je važnije. Takođe može biti od značaja pridržavati se zahteva, čak i ako programiranje zahteva više rada i napora, ili zahteve prilagoditi tako da programiranje brže napreduje.
• Paralelno stvaranje više sistema
  
  Kada se paralelno programira, treba voditi računa o usklađivanju dokumenata. Naime, u toku realizacije svugde je potrebno izvoditi mala odstupanja od sistema. Njih je potrebno zabeležiti i komutirati za ostale sisteme. Često se javljaju greške, pa se tako razilaze dve linije stvaranja i ne dolazi do komutiranja.
• Uključivanje naručioca Kod novog sistema i nove usluge može uprkos temeljnoj specifikaciji da se desi da se zamisao i realizacija ne poklope. Ukoliko pre naručioci mogu da vide, testiraju ili ispitaju određene stvari, utoliko su pre u stanju da definišu izmene. Treba strogo izbegavati programiranje sistema u trajanju od dva do tri meseca, a tek potom prezentovanje rezultata. Posle toga je sa sigurnošću potrebno uraditi velike izmene. Zbog toga bi trebalo, na koji god način, sprovoditi usklađivanje između rešenja i očekivanja naručioca na svake dve nedelje.
• Funkcionalno testiranje
  
  Nakon programiranja odnosno pre spajanja (Merger) i pre integracijskog testiranja trebalo bi testirati i proveriti funkcije. Često se ovaj korak ne odvija dovoljno temeljno, pa potom integracijski testovi i testovi prihvatljivosti bivaju blokirani i kasne. Osim toga, novi softver poprima loš imidž ako osnovni dugmići ne funkcionišu ili ako na testovima isplivaju suviše očigledne greške (npr. ne funkcioniše download). Osim toga trebalo bi odlučiti da li previše grešaka u kategoriji blokera eventualno znači da se sa distribuiranjem ide na zajedničko okruženje za testiranje.

4. Testiranje

• Integracijski testovi

Ako je izveden i poslednji korak realizacije, svi pojedinačni softverski paketi mogu se svesti, povezati i testirati na zajedničko okruženje. Sada je moguće ispitati i testirati sve definisane integracijske testove i slučajeve interfejsa. Podaci i slučajevi interfejsa već su definisani u realizaciji i potrebno ih je samo još realizovati.
I ovde je bitno da su interfejs i protoci podataka testirani u svim varijantama. To se ne odnosi samo na utvrđivanje ispravnosti (ono što treba da funkcioniše), već i na utvrđivanje neispravnosti (ono što ne treba da funkcioniše).
Od ovog momenta može se dati odobrenje čitavog okruženja za testove prihvatljivosti. U tom potezu trebalo bi stvoriti naloge, pristupe i podatke, kako bi stajali na raspolaganju za testove prihvatljivosti.

• Testovi prihvatljivosti

Mogu se proveriti e2e-testovi sa podacima. Pritom u najboljem slučaju ne bi trebalo više da se utvrde odstupanja od zahteva. Ako bi se to ipak desilo, imalo bi ogromne posledice po čitavo rešenje. Na primer, ako se utvrdi da je zavisnost od dva podešavanja neispravna, potrebno je vratiti se u osnovno projektovanje rešenja i time ponoviti ukupan postupak funkcionalnih i integracijskih testova. Na testu prihvatljivosti trebalo bi u najboljem slučaju da se pojave sadržajne greške, eventualno da su vrednosti pogrešno interpretirane ili određeni podaci da nisu prikazani. Na kraju se vide sve utvrđene i prema posledicama pozicionirane greške. Na taj način menadžment može da odluči, da li bi u datim uslovima lansiranje bilo pametno.

Pogotovo kada je reč o novim rešenjima, spisak može biti poprilično dug. Ipak ne treba biti suviše restriktivan u tim slučajevima. Ako se ne radi o stvarnim blokerima u glavnim procesima, preporučljivo je pokrenuti rešenje, a ostale greške popravljati u radnom režimu. Često se neiznuđene greške ispostavljaju kao ne toliko važne, pa je pažnja na važne greške u radnom režimu znatno veća nego u fazi programiranja.
5. Prelaz u radni režim

Faza prelaza u radni režim novog sistema započinje već sa testiranjem odnosno pre njega, ako je potrebna za testiranje.
Ove se prikupljaju sve potrebne informacije o sistemu za sve stakeholdere. Počev od čistih informacija, kao na primer kao novost da se alatka pušta u rad pa sve do detaljnog materijala za obuku svih korisničkih grupa.
Pogotovo novi sistemi moraju biti detaljni i sadržati opise grešaka, kako funkcije, koje su namerno postavljene, ne bi bile prepoznate kao greške.

Osim objašnjenih funkcija dodeljuju se i vremena.

• Tehnički prelaz na radni režim: ovde se vode razgovori sa odeljenjem za tehniku o tome koje podatke, kada i u koji sistem treba ubaciti, da bi u trenutku lansiranja sve besprekorno funkcionisalo. Kod novih sistema ovo nije toliko važno.
• Stručni prelaz u radni režim: kod novih sistema potrebno je odrediti tačno vreme za sve stakeholdere, kojim se određuje koje komponente će kojim korisnicima kada biti dostupne.
• Takođe se određuje da li će postojati interna test faza za zaposlene i potom soft launch, kada počinje marketing i kada se može računati na veći porast.

6. Završetak projekta Faza stabilizacije

Završetak projekta kod novih rešenja ne bi trebalo da se poklapa sa puštanjem u rad, već bi ga trebalo planirati za oko tri meseca nakon puštanja u rad. Tako se obezbeđuje da zaposleni na projektu, koji do tog momenta već velikim znanjem raspolažu, stoje na raspolaganju onim zaposlenima za rešenje problema, koji su zaduženi za sistem od momenta puštanja u rad, ali koji su za to kratko vreme svega malo iskustva stekli u vezi sa njim. To se često previđa. Projekat se završava nakon puštanja u rad, zaposleni na projektu napuštaju projekat, a zaposleni na projektu u radnom režimu suočeni su sa pitanjima, na koja ne mogu da odgovore. Kao posledica toga vreme za pronalaženje odgovora traje predugo ili se u najgorem slučaju  problemi uopšte ne rešavaju.

Ako je sve ovo obavljeno, završen je novi digitalni projekat i lansiran novi softver sa novim procesima i novim znanjem. Na taj način postavljeni ciljevi će biti ispunjeni.