Zadanie = kvalita, kvantita, termíny, rozpočet (KKTR)

Ako správne viesť projekty v bankovníctve

Dob­ré za­da­nie je pr­vý pred­pok­lad ús­pe­chu pro­jek­tu. Kva­lit­né za­da­nie by ma­lo ob­sa­ho­vať sché­my či ob­ráz­ky, z kto­rých bu­de jas­ný biz­ni­so­vý pro­ces a je­ho cie­le, kto­ré má in­for­mač­ný sys­tém pok­rý­vať. Veľ­mi dô­le­ži­tý je aj rám­co­vý vý­pis oča­ká­va­ných fun­kčnos­tí a poh­ľad na ob­jek­ty ale­bo en­ti­ty, s kto­rý­mi sys­tém bu­de pra­co­vať.

Ak te­da bu­dem pra­co­vať s úve­rom, kar­tou, pod­pi­so­vým vzo­rom, so zá­kaz­ní­kom, in­for­má­cia­mi o po­boč­ke, mu­sí byť zo za­da­nia jed­noz­nač­ne mož­né vy­vo­diť, kto­ré dá­ta/ob­jek­ty bu­de in­for­mač­ný sys­tém ob­sa­ho­vať. Ne­za­ned­ba­teľ­ný bod dob­ré­ho za­da­nia je sta­no­ve­nie roz­poč­tu. Klient sí­ce ob­vyk­le ne­má dos­ta­tok zna­los­tí na sta­no­ve­nie ce­ny, ale mu­sí pres­ne poz­nať svo­je in­ves­tič­né mož­nos­ti. Čas­tou chy­bou klien­tov bý­va, že nep­ri­chá­dza­jú so žiad­nou kon­krét­nej­šou fi­nan­čnou pred­sta­vou a sta­no­ve­nie ce­ny ne­chá­va­jú úpl­ne na do­dá­va­te­ľo­vi.

No in­for­mač­ný sys­tém rie­šia­ci ur­či­tú ob­lasť sa dá vy­tvo­riť za 3 ale­bo 5, ale aj za 100 mi­lió­nov ko­rún. A vždy bu­de funkč­ný. Roz­diel však bu­de v kom­for­te pre pou­ží­va­te­ľa, v rých­los­ti za­ško­le­nia ob­slu­hy, v ce­ne pre­vádz­ky a údr­žby, v tom, čo si mô­žem do­vo­liť rie­šiť auto­ma­tic­ky a čo bu­dem mu­sieť rie­šiť ruč­ný­mi servisn­ým­i zá­sah­mi a pod. Fi­nanč­ný roz­sah je te­da dô­le­ži­tá sú­časť za­da­nia pro­jek­tu, rov­na­ko aj rám­co­vé ter­mí­ny a pred­sta­va, akým spô­so­bom sa má sys­tém na­sa­dzo­vať. Naj­hor­šie je pri­jať chyb­né za­da­nie ale­bo sa dos­tať do si­tuácie, v kto­rej sám za­da­niu ne­dô­ve­ru­jem. Ide o to, aby pro­jekt do­pa­dol dob­re, nie aby sme vy­in­ka­so­va­li pe­nia­ze a o rok zá­pa­si­li s nes­po­koj­nos­ťou klien­ta pre zle vy­ko­na­nú prá­cu.

Ria­de­nie KKTR - čo a ako ro­bí­me, aby sme udr­ža­li pa­ra­met­re

Zá­klad­né pa­ra­met­re pro­jek­tu do­dáv­ky in­for­mač­né­ho sys­té­mu sú kva­li­ta, kvan­ti­ta, ter­mín a roz­po­čet (KKTR). Rov­na­ko ako pri stav­be do­mu sa pri návr­hu a do­dáv­ke in­for­mač­né­ho sys­té­mu pos­tu­pu­je v nie­koľ­kých kro­koch: úvod­ná štú­dia, tech­nic­ký pro­jekt s pro­to­ty­pom a až po­tom nas­le­du­je im­ple­men­tá­cia a za­ve­de­nie sys­té­mu do pi­lot­nej a nás­led­ne do ru­tin­nej pre­vádz­ky. 

USY_Clanok_Projektove riadenie - banky.jpg

Obr. 1  Za­da­nie in­for­mač­né­ho sys­té­mu

Zá­klad­né pa­ra­met­re KKTR tre­ba vní­mať ako je­den ce­lok. Vo fá­ze úvod­nej štú­die a nás­led­né­ho tech­nic­ké­ho pro­jek­tu sa de­tail­ne roz­pra­cú­va roz­sah pro­jek­tu (kva­li­ta a kvan­ti­ta) - pre­bie­ha ana­lý­za po­žia­da­viek a di­zajn ce­lé­ho rie­še­nia. Je cel­kom bež­né, že sa dis­ku­tu­je o fun­kčnos­tiach, kto­ré v sys­té­me bu­dú a kto­ré nie. Za­dá­va­te­lia z biz­ni­su a biz­ni­so­ví ar­chi­tek­ti navr­hu­jú čo naj­lep­šie rie­še­nia, čo naj­viac prep­ra­co­va­né a maximál­ne vy­ho­vu­jú­ce pot­re­bám kon­co­vých pou­ží­va­te­ľov.

Ten­to prís­tup má lo­gic­ky pod­stat­ný vplyv na ce­nu a je dô­le­ži­té, aby už v prie­be­hu ana­lý­zy bol návrh no­vé­ho sys­té­mu neus­tá­le kon­fron­to­va­ný s plá­no­va­ným roz­poč­tom. Čas­tá chy­ba je, že roz­po­čet sa ne­po­va­žu­je za vstup­nú po­žia­dav­ku. Na kon­ci ana­ly­tic­kej fá­zy tak dôj­de k „pre­po­čí­ta­niu" ce­ny pro­jek­tu a na prek­va­pe­nie všet­kých zú­čas­tne­ných sa zis­tí, že roz­po­čet je prek­ro­če­ný nap­rík­lad dvoj­ná­sob­ne. Po­tom nas­tá­va zlo­ži­tá fá­za ore­zá­va­nia roz­sa­hu. Pro­jekt sa tak za­čne omeš­ká­vať, zá­kaz­ník, kto­rý si už nas­ta­vil ur­či­té oča­ká­va­nie od no­vé­ho in­for­mač­né­ho sys­té­mu, mu­sí to­to oča­ká­va­nie zme­niť. Tie­to čin­nos­ti na­vy­še sto­ja pro­jek­to­vý čas a pe­nia­ze.

Dob­rý biz­ni­so­vý ar­chi­tekt be­rie neus­tá­le pri ana­lý­ze a syn­té­ze po­žia­da­viek roz­po­čet ako kľú­čo­vú vstup­nú po­žia­dav­ku pre všet­ky svo­je ana­ly­tic­ké úva­hy, kto­ré s tým­to roz­poč­tom kon­fron­tu­je. Je te­da správ­ne, keď na ana­ly­tic­kom wor­ksho­pe za­znie: „Obá­vam sa, že tú­to fun­kčnosť asi ne­bu­de mož­né vy­rie­šiť tak­to kom­for­tne, pre­to­že tým po­ru­ší­me váš roz­po­čet. Váš pán ria­di­teľ po­va­žu­je roz­po­čet za pod­stat­nú sú­časť za­da­nia. Navr­hu­jem, že fun­kčnosť bu­de zjed­no­du­še­ná tak­to…

Pou­ží­va­te­ľom to bu­de pl­ne dos­ta­čo­vať a ne­na­ru­ší­me tým cel­ko­vý roz­po­čet pro­jek­tu." Tú­to vša­dep­rí­tom­nú va­li­dá­ciu navr­ho­va­né­ho rie­še­nia a roz­poč­tu na­zý­va­me ria­de­nie bu­dú­cich roz­poč­tov. Mno­ho „stráž­cov" roz­poč­tu sle­du­je roz­po­čet pre­bie­ha­jú­cej fá­zy (napr. tech­nic­ké­ho pro­jek­tu), ale uni­ká im, že dô­le­ži­té je v tech­nic­kom pro­jek­te us­ta­no­viť prá­ve bu­dú­ci roz­po­čet im­ple­men­tá­cie. Nie je zlo­ži­té ukon­čiť tech­nic­ký pro­jekt v roz­poč­te, kto­rý bol sta­no­ve­ný na sa­mot­nú pro­jek­ciu - to pat­rí k zá­klad­ným schop­nos­tiam pro­jek­to­vých ma­na­žé­rov. Dô­le­ži­té je pred­lo­žiť aj vý­stu­py ana­ly­tic­kých prác - ta­ký tech­nic­ký pro­jekt, kto­rý na­šiel rie­še­nia spĺňa­jú­ce všet­ky šty­ri pa­ra­met­re KKTR.

Chce­me, aby zá­stup­co­via klien­ta ro­zu­me­li vý­stu­pom a „pod­pí­sa­li" ich

Zá­stup­co­via zá­kaz­ní­ka by ma­li nie­len ro­zu­mieť vec­ne rie­še­nej prob­le­ma­ti­ke, ale ma­li by aj ve­dieť čí­tať tech­nic­ký pro­jekt. Je­di­ne tak sa da­jú od­ha­liť a od­strá­niť mož­né ne­dos­tat­ky a roz­diel­ne poh­ľa­dy eš­te v pro­jek­čnej fá­ze. Je naiv­né my­slieť si, že lep­ší zá­kaz­ník je ten, kto­rý všet­ko od­súh­la­sí bez hl­bších zna­los­tí. Pre­to je dô­le­ži­té ško­liť zá­kaz­ní­kov tak, aby ro­zu­me­li jed­not­li­vým mo­de­lom a di­ag­ra­mom.

Chy­bou je vzbu­dzo­vať v zá­kaz­ní­ko­vi po­cit zá­vis­los­ti od do­dá­va­te­ľa. Niek­to­ré fir­my si ne­zas­tu­pi­teľ­nú úlo­hu do­kon­ca bu­du­jú. Tre­ba dbať na to, aby na stra­ne klien­ta bo­la sku­pi­na ľu­dí, kto­rá je do­dá­va­te­ľo­vi par­tne­rom, kto­rá prá­ci ro­zu­mie, kto­rá ju za­dá­va i pre­be­rá, chá­pe pri­da­nú hod­no­tu a roz­ho­du­je nap­rík­lad aj o tom, či si ne­bu­dú niek­to­ré čas­ti pro­jek­tu ro­biť sa­mi.

Prís­tup klien­ta ku všet­kým in­for­má­ciám v pro­jek­te - vec­ným aj ria­dia­cim

V prie­be­hu reali­zá­cie pro­jek­tu sa tre­ba po­de­liť o in­for­má­cie so všet­ký­mi za­in­te­re­so­va­ný­mi stra­na­mi. Sta­rá­me sa o to, aby kaž­dý mal ta­ké in­for­má­cie, kto­ré pri svo­jej prá­ci pot­re­bu­je. Pre ria­de­nie je nee­fek­tív­ne, keď sú in­for­má­cie iba v hla­vách jed­not­liv­cov ale­bo v ich e-mai­lo­vých schrán­kach. Dô­le­ži­té in­for­má­cie je ne­vyh­nut­né zdie­ľať na jed­nom spo­loč­nom mies­te. Ich zhro­maž­ďo­va­nie mu­sí pre­bie­hať cie­le­ne a zá­ro­veň by sme ma­li byť schop­ní od­kiaľ­koľ­vek a ke­dy­koľ­vek náj­sť to, čo pot­re­bu­je­me.

Lu­káš Zr­za­vý, pre­vádz­ko­vý ria­di­teľ Uni­corn Sys­tems a. s.

Zdroj: IW 6-7/2013


Ohodnoťte článok:
   
 

24 hodín

týždeň

mesiac

Najnovšie články

In­for­mač­ná bez­peč­nosť: Geog­ra­fic­ky dis­tri­buo­va­ná ochra­na dát
Ako minimalizovať výpadok IT služieb a stratu dát v dôsledku nepriaznivých udalostí. Zatiaľ čo v predošlej dekáde stačilo chrániť pred výpadkom niektoré aplikácie.  čítať »
 
Pla­te­ná rek­la­ma vs. op­ti­ma­li­zá­cia SEO – vý­ho­dy, ne­ga­tí­va, mož­nos­ti
Špecialisti na SEO tvrdia, že správnou optimalizáciou webu máte šancu získať oveľa viac ako platenou reklamou. Naproti tomu experti na platenú reklamu argumentujú dosahovaním rýchlych a merateľných výsledkov. čítať »
 
Ar­chi­tekt vs Pro­jek­to­vý ma­na­žér - spo­jen­ci, či ne­pria­te­lia?
Tieto roly existujú v každom väčšom projekte, ale napriek tomu ich spolupráca často neprebieha tak hladko ako by sa očakávalo. Je dôvod v samotných rolách, alebo leží úplne inde? čítať »
 
Ap­pli­ca­tion De­li­ve­ry – efek­tív­na ochra­na pro­ti hac­ke­rom a op­ti­ma­li­zá­cia vý­ko­nu slu­žieb
Sú vaše webové služby chránené proti hackerom? Programátori často urobia chyby, ktoré dokážu útočníci zneužiť.   čítať »
 
Cloud com­pu­ting: Oča­ká­va­nia a reali­ta, preh­ľad pos­ky­to­va­te­ľov (Ama­zon, Goog­le, IBM, Mic­ro­soft)
Cloud computing, technológia predstavujúca model zdieľania hardvérových zdrojov pomocou virtualizácie a automatizácie, v súčasnosti naberá rýchlosť pri globálnom rozširovaní sa do celého spektra sektorov poskytujúcich obrovské množstvo služieb. čítať »
 
Dá­ta nie sú len ved­ľaj­ším pro­duk­tom pre­vádz­ky IS
Na otázku, ako stručne hodnotíte informačný systém vašej organizácie, by sme dostali mnoho rôznych odpovedí. čítať »
 
BYOD pod­po­ru­je ino­vač­né ini­cia­tí­vy ta­len­to­va­ných za­mes­tnan­cov
Jeden z charakteristických atribútov trendu BYOD je možnosť vynútenia technologického pokroku v IT podpore biznisu „zdola", najčastejšie zo strany mladších používateľov. čítať »
 
Li­cen­čnú čis­to­tu je ťaž­ké us­trá­žiť
Pre licenčného manažéra je znalosť aktuálnych licenčných podmienok od dvoch až troch výrobcov softvéru na všetok využívaný softvér v spoločnosti nedosiahnuteľná méta. čítať »
 
 
 
  Zdieľaj cez Facebook Zdieľaj cez Google+ Zdieľaj cez Twitter Zdieľaj cez LinkedIn Správy z RSS Správy na smartfóne Správy cez newsletter