Kako definirati zahtjeve za ERP

Svi znaju da ma koliko ERP (Navision, SAP ili neki treći) bio sveobuhvatan, budući ili postojeći klijent uvijek traži nešto novo. To se zove zahtjev. Zahtjevi se, generalno, dijele na 3 kategorije: zahtjev za funkcionalnošću koja ne postoji u ERP-u (npr. specifične bonus kartice ili specifičan rabatni sustav), zahtjevi koji postoje u ERP-u, ali ih treba generalno promijeniti (npr. način obračuna poreza za neku državu) i zahtjevi tzv. „kozmetičke“ prirode (npr. raspored postojećih polja na robnoj kartici).

Bez obzira u koju kategoriju zahtjev spadao potrebno ga je pravilno i detaljno definirati. Istraživanja su pokazala da najveći broj nezadovoljstva kod korisnika dolazi iz razloga što isporučena funkcionalnost ne odgovara onome što je traženo. Ovo se može i prevesti da isporučena funkcionalnost ne odgovara onome što je mišljeno da je traženo (sa strane isporučitelja) ili onome što je mišljeno da će se dobiti (sa strane naručitelja). Zašto je tome tako? Vjerovali ili ne, zbog jezičnih barijera. Zamislite da ste voditelj projekta kod implementacije ERP-a. I da vam korisnik objašnjava svoj zahtjev na kineskom jeziku, od kojeg vi razumijete 10%. I onda taj, vama NEDOVOLJNO nerazumljiv zahtjev, morate prenijeti developerima koji govore japanski, ali vi opet znate samo 10% tog jezika. A nemate prevoditelja.

Prevedeno na IT struku postoje role i jezici koje moraju te role poznavati. Naručitelj govori poslovnim jezikom. On će vam, na primjer, reći: „Želim uvesti svoju loyality karticu!“. On ne zna i ne mora znati što je to SQL, dll, klasa, kontrola i slično. Niti možete od njega očekivati da će svoj zahtjev proširiti rečenicom, kao što je to: „A za to vas molim da formirate posebnu tablicu u bazi kupaca sa dva numerička i jedim alfanumeričkim poljem, koji će sadržavati……“. Ovdje najčešće nastaje problem što onaj tko skuplja zahtjeve (a to je najčešće voditelj projekta koji je istovremeno i Business Analyst), ne postavlja dovoljno dodatnih pitanja. Na primjer: Da li se kartica veze za fizičku ili pravnu osobu?

Da li jedna osoba može imati više kartica? Da li kartica ima neko ograničenje (datum važenja, maksimalni broj bodova i slično)? Da li je kartica prenosiva? Mogu li se bodovi spajati na više kartica? Koliko EUR-a je jedan bod? Kako kartica izgleda? Kako se verificira? I tako unedogled. Ako se ovo ne napravi, garantirano će kupac (naravno kada sve napravite), reći nešto tipa: „A gdje na blagajni mogu očitati bodove? Zašto ne mogu i platiti tom karticom (HOP! Cijela struktura mora biti promijenjena)?“ i slično.

Kada se skupe svi takvi zahtjevi obavezno se moraju dokumentirati do zadnjeg detalja. Ali baš zadnjeg! Na primjer, ako je naručitelj rekao da je maksimalni broj bodova 1234 po jednoj kartici i da se ne mogu pri jednoj kupovini koristi bodovi s više od jedne kartice onda to točno tako treba i napisati. Sada slijedi jedan korak koji, vrlo često, voditelji projekta preskaču i rade krucijalnu grešku. Najčešće kada je sve zapisano traže potpis od naručitelja. I tu je greška! Zašto? Zbog toga što kada naručitelj to potpiše on smatra da je to izvedivo! Što znači da ćete kasnije imati velikih problema ako nešto jednostavno ne možete izvesti. Stara je i lažna izreka: „Sve se može napraviti!“ NE MOŽE! Nešto zato jer jednostavno nije tehnološki podržano, a nešto zbog toga što bi implementacijom takvog rješenja postojao veliki rizik da cjelokupni sistem urušite!

Zbog toga je potreban međukorak, koji treba napraviti prije nego se traži naručiteljev potpis, a to je – verifikacija zahtjeva s developerima. Oni su ti koji će odraditi posao i oni su ti koji će vam dati informaciju o tome: da li je to uopće izvedivo, koji su rizici na postojeći sustav i (vrlo grubo), koliko vremena im treba da bi to napravili. Sada, voditelj projekta, imajući te informacije, može otići do naručitelja i reći mu da je to neizvedivo (pa da ili preformulira zahtjev ili od njega odustane) ili da je to izvedivo ali je rok za izvedbu npr. 6 mjeseci i trošak oko 500.000€. Kada konačno imate potpisane zahtjeve kreće finalni razgovor s developerima.

Moji kolege često zbijaju šale i govore kako je voditelj projekta – propali developer. Šalu na stranu, vrlo velik broj voditelja projekata u ERP industriji jesu bivši developeri (ne nužno loši). I tu leži velika, dapače ogromna, opasnost. Voditelj projekta mora moći objasniti developerima što treba napraviti, ali ne i kako. Na primjer, ispravno je reći: Potrebno je za dobivanje kartice na nekom jedinstvenom mjestu ubaciti podatke o imenu i prezimenu (samo alfanumerički podaci), adresi (samo iz Hrvatske i Srbije) i slično. Ali nikako ne smije postaviti zahtjev tipa: Potrebno je u bazi x otvoriti 3 nove tablice s ovim indeksima i u tablicu a dodati polje x, y i z i slično). To je isključiv posao developera.

Dakle, voditelj projekta mora definirati i to vrlo precizno što developer treba napraviti, a on će sam odlučiti kako će to napraviti. Također voditelj projekta mora znati developeru objasniti i kako se radi grubi test. Dakle, ako se zahtjev za izdavanje kartice mora odobriti pod određenim uvjetima, tada se mora jasno to developeru i reći: „Da bi karticu mogli odobriti potrebno je da je kupac u zadnjih 3 mjeseca kupio robe u vrijednosti 3.500 EUR ili više!“. Sada, kada developer zna što treba napraviti i odluči kako će to napraviti, on pristupa radu i voditelj projekta mu je tu ključna osoba koja mora moći odgovoriti na sva nejasna pitanja. Ako npr. tijekom razvoja developer ne zna, da li je postoji ograničenje na valjanost kartice (npr, rečeno ja da kartica može trajati samo jednu godinu, a developera zanima može li neka kartica trajati i duže), tada odgovor mora dobiti od voditelja projekta. Ako ni on ne zna odgovor, mora ga dobiti od naručitelja i to zapisati u specifikaciju zahtjeva.

Dakle, tijekom razvoja funkcionalnosti, voditelj projekta je veza između njega i naručitelja. Nikad, ali nikad developer ne treba zvati naručitelja za pojašnjenje. Ima pregršt razloga zašto, ali najčešća dva su: vrijeme i novac. Naime, developer može (u najboljoj namjeri, da odmah bude jasno), dogovoriti neko proširenje funkcionalnosti (npr. naručitelj će mu u svoj odgovor na pitanje navesti i: „Pa kad već radiš ovo, što ne bi odmah ubacio i nešto treće“), za koje će mu biti potrebno dodatno vrijeme. Kako to vrijeme nije u projektnom planu, projekt će automatski (u najvećem broju slučajeva) kasniti i koštati će više, a to nije unaprijed dogovoreno pa se neće ni moći opravdati niti naplatiti.

Drugi razlog je što kada naručitelj jednom krene komunicirati s developerom, stalno će ga zvati i samim time dekoncentrirati i ometati i time mu smanjiti produktivnost. Zato svaka promjena ili nejasnoća mora ići putem: developer – voditelj projekta – naručitelj. Ako se na tom putu od strane naručitelja javi potreba za proširenjem, voditelj projekta će standardnom procedurom zahtjeva za izmjenu jasno dokumentirati to proširenje, staviti ga u projekti plan i korigirati vrijeme izvedbe kao i budžet (naravno, ako je voditelj projekt profesionalac, a ne šarlatan).

Kada je razvoj funkcionalnosti završen i testiran od strane developera, na scenu stupa – tester. Vrlo često se smatra da tester može biti bilo tko, jer on „samo klikće po dugmadi u aplikaciji i traži način da je sruši“. To je potpuno pogrešna percepcija. Tester je vrlo važna rola. Naime svaka se funkcionalnost testira na tri razine: bugovi, funkcionalno i integralno. Što to znači? Bugovi su svima jasni. Tester npr. pritisne tipku F6 i aplikacija se sruši ili javlja neku čudnu poruku. To je najlakše. Međutim funkcionalni test pokazuje da li funkcinalnost koja se testira radi ispravno. Npr. ako postoji polje limit  i u njega se smije unijeti maksimalan broj 10.000 onda tester mora to znati i probati unijeti i broj veći od 10.000, ali i nulu i broj manji od nule i mora znati kako se funkcionalnost u tom slučaju mora ponašati (npr. dati poruku; „Morate unijeti broj veći od nule, a manji od 10.000“).

Integralni test podrazumijeva da tester mora provjeriti da li sve vezane funkcionalnost koju testira rade jednako. Npr. ako na fakturi prilikom ispisa mora biti broj stečenih bodova po kartici tada tester mora provjeriti i rad modula za fakturiranje.

pm1.PNG

I na kraju se radi UAT (User Acceptance Testing), odnosno testiranje od samog korisnika. Da bi to prošlo što bezbolnije, potrebno je napisati detaljne upute, po mogućnosti sa slikama ekrana i to korak po korak, a prilikom prvog testa netko od isporučitelja mora biti na samoj lokaciji naručitelja. Nemojte pasti u zamku i samo naručitelju reći: „Vaš zahtjev je stavljen na test, pa vi probajte“, što se često radi. Naručitelj se puno lagodnije osjeća kad ste uz njega i kada ima upute.

I na kraju, ovo je put kojim treba ići, ali ovo nije recept za uspjeh. Definirajte jasne korake, upoznajte sve s njima i držite ih se uvijek bez iznimke. Ovim koracima ćete samo uvelike smanjiti mogućnost nezadovoljstva i kod naručitelja, ali i u vlastitom timu. Međutim štogod radili i kolikogod se trudili nikad ne zaboravite da vam je s druge strane – čovjek.

by Nenad Trajkovski

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s