73 KAKOVOSTNO VODENJE IN NADZOR NALOŽB QUALITY MANAGEMENT AND CONTROL OF INVESTMENT Strokovni članek Professional article Janez Hafner Povzetek Ključne besede Abstract Key words V projektu smo poskusili odgovoriti na vprašanja, povezana s problematiko kakovosti pri večjih in zahtevnejših naložbah. Rešitev smo gradili na področju nakupov infor- macijskih sistemov, pri katerih na novo vpeljani sistem poleg tehnoloških rešitev navadno poseže v procesna in organizacijska vprašanja. V informacijski rešitvi se prepletajo elementi projektnega vodenja, informacijskega inženiringa in zagotavlja- nja kakovosti. Izdelati je bilo treba hibrid, ki se napaja na najboljših praksah, a hkrati vanje ne posega pregloboko. Odločitev za splet omejenega nabora funkcionalno- sti in njihovo posplošeno obravnavanje je pripeljala do vsestranske rešitve, ki jo je mogoče uporabiti za spremljanje kakršnih koli naložbenih projektov. Zagotavljanje kakovosti, projektno vodenje, nabava, informacijski sistem. The aim of the IPPVIS project was to resolve some key dilemmas related to procu- rement of complex systems. The development of information systems was chosen to be used as a raw model. The nature of IS development shows that such systems prove to be the most complicated since they actively interfere with the processes and the organisational structure. The product of the project can be regarded as a generali- sed hybrid of project management, quality assurance and management methodology requirements. The decision for this set of functionalities and their management has yielded a universal solution applicable to general procurement process as a control- ling-communication tool between the procurement authority and the user/operator. Quality assurance, project management, procurement, information systems. DOI:10.33179/BSV.99.SVI.11.CMC.13.1.5 Sodobni vojaški izzivi, junij 2011 – 13/št. 1 Contemporary Military Challenges, April 2011 – 13/No. 1 74 Sodobni vojaški izzivi/Contemporary Military Challenges Janez Hafner Finančna kriza, ki je v zadnjem letu dni zajela svet, močno vpliva na prihodke držav, ti pa močno vplivajo na odhodke, ki si jih posamezna država lahko privošči. Na odhodkovni strani je obrambni proračun eno izmed glavnih področij zmanjševanja stroškov, znotraj njega pa so najbolj na udaru naložbe v novo opremo in sredstva. Zmanjšan obseg naložb še bolj kot kadar koli prej postavlja zahteve po racionalni porabi sredstev. Odgovoriti je treba na vprašanje, kako z manjšimi sredstvi doseči večje rezultate oziroma kako zagotoviti, da so vložena sredstva sorazmerna s prido- bljenim rezultatom (angl. value for money). V obrambnih sistemih so nakupi zelo različni, od preprostih, pri katerih so vsi parametri nakupa vnaprej znani, do zahtevnejših nakupov, pri katerih prihaja do spleta različnih tehnologij in jih lahko v razpisnem procesu le grobo opredelimo. Obvladovanje nabavnega procesa, sodelovanje vsebinskih in tehnoloških nosilcev, zlasti pa nadzor nad zunanjimi dobavitelji oziroma izvajalci so bistveni elementi uspešnega nakupa. Pojavlja se večna dilema o tem, ali je bolje dobro nadzorovati nabavni proces ali pa bi bilo bolje več poudarka nameniti strokovnim oziroma tehno- loškim vsebinam. Skladno s tem lahko opažamo odmike enkrat v smeri, v kateri teh- nološko ocenjevanje postane neobvladljivo, drugič v smeri, v kateri je edini dejavnik izbora ekonomska vrednost ponudbe. Ne ena ne druga skrajnost ne moreta obroditi sadov. Predvsem v primeru zahtevnejših nakupov je nujno vključevanje tehnološke ocene, razpis pa mora vedno ostati transparenten in mora ugoditi vsem pogojem javnega naročanja. Vprašanje, na katerega moramo odgovoriti, je, kako zagotoviti ustrezno raven sode- lovanja notranjih nosilcev na področjih nabave, vsebine, stroke in uvajanja ter kako v fazi nakupa oziroma projekta sodelovanje razširiti na zunanjega izvajalca oziroma dobavitelja. 1 PROJEKT IPPVIS V projektu smo poskusili odgovoriti na vprašanja, povezana s problematiko nakupov, s poudarkom na zahtevnejših nakupih, in sicer nakupih informacijskih sistemov. Nakupi informacijskih sistemov spadajo med najzahtevnejše nakupe (Eveleens, 2010). Tako imenovani nakupi s police (COTS – commercial of the shelf) so izve- dljivi le v primeru nakupa vnaprej znane strojne in programske opreme. V primeru le malo bolj zahtevnih sistemov, pri katerih je predvideno sodelovanje različnih tipov uporabnikov, pa se izkažejo za neizvedljive. Pojavi se več področij, na katerih končna rešitev vnaprej ni znana in se razvija v sodelovanju med izvajalcem in naročnikom v okviru izvedbe projekta. Najmanj, kar tak projekt navadno vsebuje, sta prenova procesov in povezovanje v trenutne informacijske sisteme. Prenova procesov ne vpliva le na način dela, temveč lahko posledično uvede spremembe v organiziranost. Spremembe prinašajo negotovost, negotovost pa v ljudeh vzbudi odpor, ki lahko povzroči neuspeh projekta. Ugotovimo lahko, da tudi, kadar projekt uspešno reši vsa tehnološka vprašanja, to še ni zagotovilo, da bo sistem preživel uvajanje v uporabo. Uvod 75 Sodobni vojaški izzivi/Contemporary Military Challenges KAKOVOSTNO VODENJE IN NADZOR NALOŽB Na strani naročnika je največja težava torej negotovost, ki jo povzročita strah pred novostjo in pomanjkanje samozaupanja. Tudi na drugi strani, torej na strani izvajalca, ugotavljamo podobno mero negoto- vosti, ki jo največkrat povzroča strah pred neuspehom projekta. Če privzamemo, da bi moral izvajalec obvladovati tehnologijo, ugotovimo, da je ta strah povezan predvsem s sodelovanjem naročnika pri izvedbi projekta. Vsak izvajalec si prizadeva, da naročnika čim prej pripelje do tega, da se v projektu natančno določijo meje, da se te meje med izvedbo ne spreminjajo in da so načini določanja uspešnosti projekta vnaprej znani. Projekt IPPVIS poskuša odgovoriti na izzive, ki jih prinašajo projekti oziroma nakupi informacijskih sistemov s postavitvijo hipoteze: »Visoka stopnja izmenjave informacij poveča znanje/poznavanje udeležencev in zmanjšuje njihovo negotovost. Nižja negotovost zmanjšuje odpor in povečuje možnosti za uspeh projekta.« Čeprav problematika projekta izvira iz problematike nakupa informacijskih sistemov, lahko ugotovimo, da so vzvodi uspešnosti (glej poglavje 3) enaki za katere koli nakupe. S tega vidika je projektna rešitev univerzalna in jo je mogoče uporabiti za nadzor katerega koli zahtevnejšega nakupa. 2 ANALIZA PROBLEMA Povod za zagon nabavnega procesa je vsebinska zahteva, ki jo izrazi uporabnik, pri čemer njena izpolnitev presega sposobnosti organizacije. Za njeno realizacijo zato nujno potrebuje zunanjo pomoč. Vzroki za to so lahko različni: na voljo ni potrebnih materialnih sredstev, organizacija nima ustreznega znanja ali pa kljub ustrezni ravni znanja človeški viri ne zadoščajo za samostojno reševanje težave. Zaradi velikega števila zahtevnih nakupov zelo različnih vsebin je strokovno ob- vladovanje področja nakupa pogosto omejeno. Prevelik razkorak v poznavanju tematike med naročnikom in izvajalcem je lahko velika ovira, saj lahko izvajalec svojo premoč nad naročnikom izkorišča za doseganje komercialnih ciljev. V primeru nakupa informacijskih sistemov lahko ugotovimo, da je stanje na področju znanja za MO RS precej dobro, saj strokovne službe s področja informacijskih sistemov zagotavljajo zadostno bazo znanja za nadzor izvajalcev. Na koncu velja omeniti še eno pomembno lastnost »nakupnih« projektov. Z vklju- čitvijo zunanjega izvajalca naročnik nanj prenese večinski del izvedbenih tveganj. Izvajalec je s tem prevzel odgovornost za razporejanje svojih virov (čas, kadri, finance) in tako razbremenil naročnika, tako da se ta lahko posveti le še nadzorni funkciji projekta. Poseganje v interno razporejanje virov izvajalca ni zaželeno, saj bi s tem naročnik prevzel del odgovornosti za uspešno izvedbo. 76 Sodobni vojaški izzivi/Contemporary Military Challenges 2.1 Kazalniki uspešnega nakupa Da bi lahko nakup razglasili za uspešnega, mora zadostiti naslednjim osnovnim zahtevam: – nakup mora biti opravljen pravočasno in v okviru sredstev, ki so mu bila na voljo; – izdelek/predmet nakupa mora ustrezati kakovostnim zahtevam; – uporabnik mora biti z izdelkom/predmetom nakupa zadovoljen, kar pomeni tudi, da je sredstvo uvedeno v uporabo; – vzpostavljena mora biti podpora delovanja. Zagotovljena mora biti ustrezna raven vzdrževalnih storitev. 2.2 Kje se lahko zatakne Čeprav so kazalniki, opisani v prejšnjem poglavju, videti samoumevni, pot do njih ni preprosta. To je večplasten proces, v katerem lahko en sam šibek člen v verigi zamaje uspešnost celotnega nakupa oziroma projekta. V nadaljevanju si oglejmo nekaj značilnih napak, ki lahko povzročijo, da projekt ne uspe. Slabo določena merila – uporabniške zahteve so eden najpogostejših vzrokov za propadle projekte. Prve težave nam »šibka« merila povzročijo že v fazi razpisa. Slabo določena merila odpirajo vrata različnim interpretacijam in lahko se zgodi, da zaradi tega ne moremo razločiti dobrih ponudb od slabih. Tudi po uspešno izvedenem razpisu se nam lahko v okviru izvedbe zgodijo neprijetnosti, do katerih pride zaradi različnega razumevanja. Če izvajalec in naročnik v fazi izvedbe nista sposobna poenotiti svojega pogleda na vsako izmed uporabniških zahtev, lahko vnaprej pred- vidimo velike težave pri zagotavljanju kakovosti. Neustrezen ocenjevalni sistem v fazi razpisa: v zadnjem času je v celotni državni upravi opaziti usmerjenost v poenostavljanje razpisov z namenom zagotavljanja čim bolj transparentne porabe javnih financ. Jasno je izražena usmerjenost v izključi- tev strokovnih ocenjevalnih meril, kot edino odločilno merilo pa se upošteva cena ponudnika. Utemeljitev je, da je treba vsa tehnološka merila podati kot izločilna in tako zagotoviti tehnološko ustreznost vseh ponudb, ki jih izpolnjujejo. To je veliko poenostavljanje in podcenjevanje tehnološke zahtevnosti. Dejstvo je, da v okviru priprave razpisa ni mogoče povsem vključiti zahtev, saj v primeru zahtevnih nakupov znanje o sistemih na začetku projekta tega ne omogoča. Za tovrstne projekte je značilno, da si tako naročnik kot tudi izvajalec znanje pridobita šele skozi izvedbo projekta. Ob začetku projekta, še manj pa v fazi razpisa, ni mogoče predvideti vseh težav, s katerimi se bo projekt srečal. Posledica dejstva, da uporabniških zahtev oziroma razpisnih meril v fazi priprave razpisne dokumentacije ni mogoče popolno opisati, je, da še toliko težje predvidimo vse mogoče rešitve, kako neko zahtevo zadovoljiti. Naloga strokovnih nosilcev mora biti, da lahko izmed ponudb, ki izpolnjujejo izločilna merila, izberejo boljše oziroma dodajo svoj prispevek v oceno ponudbe. Celo v primeru dobro določenih razpisnih Janez Hafner 77 Sodobni vojaški izzivi/Contemporary Military Challenges meril se namreč lahko zgodi, da se ponudbe med seboj po kakovosti zelo razlikujejo in je odločitev za najcenejšo različico lahko za naročnika še vedno najdražja rešitev. Neustrezna projektna organizacija naročnika: če naročnik že v začetku ni sposoben na svoji strani zagotoviti ustreznih sogovornikov za vse faze izvedbe projekta (priprava in izvedba razpisa, sodelovanje z izvajalcem, nadzor izvajalca, prevzemi sredstev, uvajanje v uporabo), se lahko v vsaki izmed njih zgodi, da projekt obstane. Tudi v primeru naknadnega »krpanja« projektne skupine naročnika to lahko vpliva na časovne zamude ali značilnosti kakovosti. Šibko sodelovanje izvajalca in naročnika v fazi izvedbe lahko onemogoči pra- vočasno usmerjanje projekta. Dolžnost izvajalca je, da naročniku redno poroča o napredku projekta, pravočasno identificira in z njim usklajuje vsa odprta vprašanja. Dolžnost naročnika je, da bdi nad izvajalcem in ga pravočasno opomni, kadar spozna, da projekt zavija vstran od svojih ciljev. Zavedati se je treba, da lahko izvajalec cilje projekta razume po svoje in lahko zato povsem nenamerno in v dobri veri »zgreši« naročnikova pričakovanja. Neupoštevanje pravil projektnega vodenja lahko povzroči, da projekt »zbezlja«. Zgodi se, da projekt zaide v stihijsko stanje, v katerem se izgubi nadzor nad projek- tnimi izdelki, odgovornost razpade in postane nedoločljiva, roki se pogosto in ne- nadzorovano premikajo. Več o tem, kako zagotoviti korektno projektno vodenje, si lahko preberete v poglavju 3.1. Pomanjkanje strokovnega znanja: naročnik in izvajalec morata vsak na svoji strani zagotoviti osebje z zadostnim strokovnim znanjem za uspešno izvedbo projekta. Če naročnik nima osebja, ki bi lahko sodelovalo pri natančnejši določitvi uporabniških zahtev in preverjanju njihovega izpolnjevanja, bo projekt gotovo propadel. Edina rešitev, ki jo v takem primeru lahko uporabi, je vključitev zunanjih svetovalcev, ki zastopajo njegove interese. Še težje stanje je, kadar izvajalec nima potrebnega znanja, kar se nam lahko zgodi v primeru slabo določenih razpisnih meril ali v primeru razpisa z neustreznim ocenje- valnim sistemom. Preostane edino zamenjava izvajalca (vključitev podizvajalca) ali prekinitev pogodbe. Neustrezni kvalitativni prevzemi: najpogostejše napake, do katerih prihaja pri kva- litativnih prevzemih, so, da zaključna testiranja ne izhajajo iz uporabniških zahtev, da testiranja nimajo vnaprej definirane in dogovorjene metrike ter da je uspešnost testiranja prepuščena subjektivni oceni. Končnega uporabnika v projekt vključimo šele v zadnjih fazah projekta ali celo šele po njegovem zaključku. Sredstva in opremo smo kupili, nakup je zaključen, kaj zdaj? Ena izmed najpogostejših napak je, da končnega uporabnika prepozno vključimo v projekt ali pa se končni uporabnik sodelovanju v projektu celo izogiba. KAKOVOSTNO VODENJE IN NADZOR NALOŽB 78 Sodobni vojaški izzivi/Contemporary Military Challenges Nakup opreme, ki je končni uporabnik ne potrebuje, ni smiseln, zato ga je treba vključiti že v zelo zgodnji fazi, v kateri mora imeti vlogo vsebinskega nosilca. Zadolžen je za določitev ključnih vsebinskih lastnosti in izvedbo priprav v enoti – prejemniku sredstev. Šele z njegovo vključitvijo lahko nakup doseže svoj končni cilj – uvedbo sredstev v operativno uporabo. Kadar v okviru nakupa primanjkuje sredstev, lahko pride do zniževanja cene na račun vzdrževanja in podpore v dobi uporabe. Za zahtevne sisteme je značilno, da za svoje delovanje potrebujejo zadostno raven strokovne podpore. Razpad sistema zaradi nezadostne podpore lahko pod vprašaj postavi vse dotedanje vložke, saj navadno sproži zavračanje uporabnikov. 3 VZVODI USPEŠNOSTI V analizi problema so bili prikazani glavni izzivi, ki smo jih želeli razrešiti s projektom IPPVIS. Izkazalo se je, da rešitev problema lahko zagotovimo skozi izbor in integraci- jo projektnih in inženirskih metodologij. Ob tem je bilo nujno upoštevati želje končnih uporabnikov. V zvezi s tem se je izkazalo, da predvsem ne želimo še ene rešitve za projektno vodenje, temveč je treba oblikovati rešitev, ki bo spremljanje naložb poeno- stavila. Eden izmed glavnih vzrokov najemanja zunanjih izvajalcev je namreč tudi v razbremenitvi lastnega kadra, ki se mu ni več treba ukvarjati s projektnim vodenjem, temveč se lahko usmeri v nadzor izvajalca in reševanje vsebinskih problemov. Skozi načrtovanje rešitve smo tako najprej določili vzvode uspešnosti in jih nato im- plementirali v okviru portalne rešitve. 3.1 Projektno vodenje Projektno vodenje je disciplina, v okviru katere poskušamo vzpostaviti nadzorovano okolje za izvedbo neponavljajočih se aktivnosti. Po definiciji je vsak projekt zgodba zase in ga ne moremo ukalupiti enako, kot lahko to naredimo za ponavljajoče se delovne procese organizacije. Težave, povezane z enkratnim izvajanjem, rešujemo z metodološkimi pristopi, ki so se razvili na podlagi najboljših praks. V svetu obstaja vrsta metodologij projektnega vodenja. Med njimi smo za namen projekta IPPVIS izbrali metodologijo, ki jo kot uradno priznava tudi Nato: PRINCE II (PRoject IN Controlled Environment). Zaradi usmeritve v nadzorno funkcijo smo se pri tem usmerili predvsem v dele, uporabne za nadzor zunanjih izvajalcev in zagotavljanje kakovosti končnih izdelkov. 3.1.1 Organizacijski vzvodi Organizacija projekta določa vzpostavitev projektnih skupin in podskupin, opisuje njihovo odgovornost in področje dela ter načine komunikacije med njimi. V fazi vzpostavitve projekta je priporočljivo vsa pravila zapisati in jih formalno sprejeti v obliki Poslovnika projekta. V njem se opredelijo načini in pogostnost poročanj, glavna pooblastila ter sestava in relacije projektnih skupin. Janez Hafner Slika 1: 79 Sodobni vojaški izzivi/Contemporary Military Challenges Narava projektov, v katerih je izvajanje porazdeljeno med naročnika in izvajalca, na izvajalca prelaga odgovornost za organiziranost in upravljanje večine izvajalskih skupin. Tako je naročnik razbremenjen skrbi za razporejanje virov in zadostuje, da izvajalca redno nadzoruje. V ta namen je treba ustanoviti mešani nadzorni (projektni) svet, z izključno nadzorno funkcijo, katerega naloge so, da: – v naprej določenih časovnih presekih (mejnikih) pregleduje dosežke projekta, jih potrjuje in odobrava nadaljnjo izvedbo del (glej poglavje 3.1.3); – določi pooblastila projektnega vodje izvajalca; – odobrava predloge sprememb, ki so zunaj pooblastil projektnega vodje; – odloča o zaključku ali ukinitvi projekta. Projektni vodja izvajalca prevzema celotno odgovornost za vsakodnevno izvedbo projekta. 3.1.2 Načrtovanje na podlagi izdelkov Načrtovanje na podlagi izdelkov je posebna tehnika PRINCE II (OGC, 2005), s katero vse izdelke projekta hierarhično delimo v njihove podrejene izdelke (glej sliko 1), s čimer poskušamo projekt razbiti na manjše zaključene celote, katerih izvedbo je lažje nadzirati. Vztrajanje v izdelavi tako imenovane strukture dela (Work Breakdown Structure) je podlaga za lažje nadzorovanje poteka (glej poglavje 3.1.3) in kakovosti projekta (glej poglavje 3.3). 3.1.3 Upravljanje faznih mej Redno spremljanje napredka v izvajanju projekta je ključ do zgodnjega odkrivanja težav in izvajanja korekcijskih akcij. Interesi naročnika in izvajalca si glede tega včasih nasprotujejo, saj si izvajalci zlasti, kadar so v projektu predvidena redna KAKOVOSTNO VODENJE IN NADZOR NALOŽB Slika 1: 80 Sodobni vojaški izzivi/Contemporary Military Challenges izplačila ob dokončanju posameznih faz, prizadevajo prikriti napake. Zlasti v časovno daljših projektih je zelo pomembno, da projekt razdelimo na več ločenih faz, v katere razporedimo izdelke in podizdelke iz strukture dela (glej poglavje 3.1.2). Naročnik mora od izvajalca pri tem zahtevati porazdelitev izdelkov po vseh fazah projekta. Zaključek posamezne faze se veže na naročnikovo potrditev izdelkov te faze. Izvajalec pri tem ni prepuščen na milost in nemilost naročnika. Lastnosti izdelkov ter načini njihovega potrjevanja so vnaprej določeni skozi uporabniške zahteve (glej poglavje 3.2) in procese zagotavljanja kakovosti (glej poglavje 3.3). 3.1.4 Upravljanje sprememb Vsak projekt je živa tvorba. Ne glede na kakovost začetnega projektnega načrta ni mogoče predvideti vseh dejavnikov, ki lahko vplivajo na njegov potek. Spremembe so stalnica vsakega projekta in jih, če potekajo nadzorovano, lahko štejemo za normalno stanje. Nadzorovano uvajanje sprememb je proces (glej sliko 2), s katerim zagotovimo sledljivost projekta in tako preprečimo, da bi ušel nadzoru. Bistveno je, da ob vzpostavitvi projekta natančno določimo začetno stanje (projektni načrt, terminski načrt, strukturirana delitev dela, merila kakovosti) in vnaprej določimo dopustna odstopanja (časovna, finančna in odstopanja v kakovosti) projekta in vsake posamezne faze. Tako je določeno izhodiščno stanje, vsako nadaljnje odstopanje pa je kredibilno le pod pogojem, da je uvedeno skladno s projektnimi pooblastili in zapisano v delovodniku sprememb. Spremembe v mejah dopustnih odstopanj lahko uvaja projektni vodja samostojno in zadostuje, da jih v delovodnik vpiše. Vsa večja odstopanja mora odobriti nadzorni svet. 3.1.5 Upravljanje konfiguracije Upravljanje konfiguracije razumemo kot proces opredeljevanja predmetov kon- figuracije, obvladovanja različic in sprememb, zapisovanja ter poročanja o stanju predmetov in zahtevah po spremembah v življenjskem ciklu projektnih izdelkov. Poenostavljeno povedano gre za obvladovanje vseh projektnih dokumentov in izdelkov z vidika njihovih časovnih sprememb. Za vsak izdelek in dokument moramo vedno vedeti, katera je njegova veljavna različica, na vpogled morajo biti dostopne vse starejše inačice, vse spremembe morajo biti zapisane in opremljene s podatki o predlagateljih ter postopkih odobritve. 3.2 Uporabniške zahteve Upravljanje uporabniških zahtev je bistvenega pomena za končni videz in kakovost projektnih izdelkov (Bikha, 2008), pa tudi eden izmed ključnih vzvodov pri neuspešno izvedenih projektih. Bistvenega pomena pri obravnavanju uporabniških zahtev je razumevanje, da se uporabniške zahteve skozi projekt razvijajo in jih zato ne moremo obravnavati kot nespremenljivo sestavino nakupa. Za razvoj informa- cijskih sistemov je značilno, da se razumevanje problema sčasoma poglablja, skozi izvedbo se povečujeta znanje tako naročnika kot tudi znanje izvajalca. Posledica tega je, da se v fazi izvedbe pojavijo dileme, ki jih v fazi razpisa ni bilo mogoče predvideti in na katere je treba poiskati odgovor. Pojavi se potreba po spremembi Janez Hafner 81 Sodobni vojaški izzivi/Contemporary Military Challenges uporabniških zahtev ali celo po vpeljavi novih. Sporazumni dogovor naročnika in izvajalca o vsaki izmed uporabniških zahtev je ključnega pomena za uspeh projekta. Način doseganja tega dogovora je določen s pravili upravljanja uporabniških zahtev (Taylor, 2010). KAKOVOSTNO VODENJE IN NADZOR NALOŽB Slika 2: Slika 3: 82 Sodobni vojaški izzivi/Contemporary Military Challenges 3.2.1 Nastanek in razvoj uporabniških zahtev Nastanek in razvoj uporabniških zahtev opisuje piramida uporabniških zahtev (slika 3), skozi katero lahko določimo dve glavni fazi. Definicija uporabniških zahtev (določitev razpisnih pogojev). Ta faza je namenjena določitvi poslovnih potreb in projektnih ciljev. Projektna zamisel že vsebuje grobe opise uporabniških zahtev, ki jih nato naprej razgradimo skozi nastanek investicij- skih dokumentov, vse do faze objave razpisa. Razpis mora vsebovati opise vseh bistvenih uporabniških zahtev. Pri tem se je treba usmeriti predvsem na vprašanje, kakšne morajo biti temeljne značilnosti predmeta nakupa. Odgovoriti je torej treba na vprašanje, kaj je predmet razpisa, izogniti pa se je treba predpisovanju, kako. Razvoj uporabniških zahtev se začne z izdelavo ponudbe ponudnika – morebitne- ga izvajalca. V njej ponudnik poda svoje videnje uporabniških zahtev in opiše način njihovega izpolnjevanja. Stopnja razumevanja problematike in predlagana rešitev bi morali biti najpomembnejši vodili pri določanju tehnološke ocene ponudnika. Razvoj uporabniških zahtev se nadaljuje skozi fazo pogajanj in se nato nadaljuje v izvedbi projekta. Navadno so razvojno aktivne predvsem prve izvedbene faze, nadaljnji razvoj uporabniških zahtev pa se nato skozi izvedbo projekta počasi umirja. V prvi fazi razvoja uporabniških zahtev se zahteve povežejo z izdelki (slika 4). Pri tem ločimo dva tipa zahtev: funkcionalne (FZ na sliki 4), ki opisujejo procesne lastnosti izdelkov, ter nefunkcionalne (NZ na sliki 4), ki po navadi določajo merljive lastnosti izdelkov. Janez Hafner Slika 4: 83 Sodobni vojaški izzivi/Contemporary Military Challenges Razvoj uporabniških zahtev je večplastno analitsko vprašanje, skozi katero uporab- niške zahteve pripeljemo od prvotnega preprostega opisa v enem stavku prek več- plastnih standardiziranih opisov (na primer z uporabo UML-diagramov primerov uporabe) in procesnih diagramov vse do testnih protokolov. Vloga testnih proto- kolov torej ni le, da določajo način testiranja posamezne lastnosti, temveč testni protokoli predstavljajo najvišjo stopnjo dogovora naročnika in izvajalca o ra- zumevanju uporabniške zahteve. 3.2.2 Upravljanje uporabniških zahtev Uporabniške zahteve so tako kot vsi drugi projektni elementi podvržene spremem- bam. Ker z izvedbo projekta narašča naše razumevanje problematike, se s tem spreminja tudi naš pogled na njeno reševanje. Upravljanje uporabniških zahtev s procesnega pogleda usmerja postopek nadzorova- nega uvajanja sprememb (glej poglavje 3.1.4), ažurnost dokumentacije pa določajo pravila upravljanja konfiguracije (glej poglavje 3.1.5). Uvajanje nadzorovanih sprememb na področju uporabniških zahtev je tudi zahteven strokovni izziv. Uporabniške zahteve (lastnosti) so namreč le redkokdaj neodvisne. Zelo pogosto se dogaja, da so med seboj povezane, zato lahko sprememba ene zahteve povzroči spremembe v več soodvisnih zahtevah. Podobno lahko ugotovimo, da hierarhična povezava med izdelki in zahtevami predstavlja le najbolj očitno po- vezanost. Lastnosti enega izdelka lahko vplivajo na lastnosti drugih izdelkov (na primer pospešek vozila je odvisen od moči motorja in teže vozila). Kot orodje za razumevanje sorodstvenih povezav in razumevanje medsebojnih vplivov sprememb uporabljamo povezovalno matriko med izdelki in uporabniškimi zahtevami. 3.3 Zagotavljanje kakovosti Zagotavljanje kakovosti je proces, namenjen ugotavljanju izpolnjevanja zahtev (glej sliko 5). Osnovne vhodne podatke, ki jih za to potrebujemo, določa struktura izdelkov s pripadajočimi uporabniškimi zahtevami. Tako ima vsak izdelek za vsako izmed svojih lastnosti (uporabniška zahteva) določena način potrjevanja (merjenja) in merilo uspešnosti, ki ga mora doseči. Izdelek lahko potrdimo kot uspešno dokončan, ko vse njegove lastnosti uspešno prestanejo testiranje (NSA, 2007). KAKOVOSTNO VODENJE IN NADZOR NALOŽB 84 Sodobni vojaški izzivi/Contemporary Military Challenges Zagotavljanje kakovosti kot bistven proces projekta oziroma nakupa povezuje vse vzvode uspešnosti. Če manjka le eden izmed njih, uspešnega zagotavljanja kakovosti ni mogoče izvajati. 4 REZULTAT PROJEKTA IPPVIS Rezultat projekta IPPVIS predstavlja portalna rešitev na podlagi Ms SharePoint, v kateri smo združili elemente projektnega vodenja, upravljanja uporabniških zahtev in zagotavljanja kakovosti. Najvišja vrednost rešitve ne leži v njeni tehnološki izvedbi, temveč predvsem v vgrajenem znanju. Dokumentacija je standardizirana. Vsi deli procesa, vse od razpisne dokumentacije do zaključnih projektnih poročil, so opremljeni z ustreznimi dokumentnimi predlogami. Življenje portala se začne s projektno zamislijo, najvišjo dodano vrednost pa pridobi z vključitvijo zunanjih iz- vajalcev (glej sliko 6, rdeči del). Slika 6: Janez Hafner Slika 5: 85 Sodobni vojaški izzivi/Contemporary Military Challenges V portalu je predvidenih več vrst uporabniških vlog (slika 7), od katerih ima vsaka točno določene dostope in pravice. Primarni ustvarjalec vsebin na portalu je izvajalec. Vse vsebine imajo status predloga, dokler jih ne potrdi projektni vodja naročnika. Po njegovi potrditvi vsebine postanejo veljavne in zavezujoče. S tem nastopijo stanje, ko jih ni več mogoče spreminjati brez odobrenega predloga nadzorovane spremembe. Odobrena sprememba proži odklepanje tistih delov, na katere se nanaša. Rešitev ima vgrajeno strukturirano delitev dela, upravljanje uporabniških zahtev in spremljanje njihovega statusa. Na tej podlagi so izdelane nadzorne plošče, ki sledijo konceptom metrike »scorecard« (Gupta, 2004) in uporabniku omogočajo preprost ter pregleden vpogled v zdravje projekta (slika 8). Slika 7: Slika 8: KAKOVOSTNO VODENJE IN NADZOR NALOŽB 86 Sodobni vojaški izzivi/Contemporary Military Challenges Sklep Literatura Veliki kupci so postavljeni pred izziv, kako zagotoviti ustrezno stopnjo kakovosti za svoje naložbe. V primeru zahtevnih projektov, kakor lahko opredelimo večino projektov s področja informacijske tehnologije, spremljanje in nadzor izvajalcev zahtevata polno vključenost naročnikov. S projektom IPPVIS smo poskušali odgovoriti na vprašanje, kako s standardizaci- jo nadzornih postopkov ter uvedbo portalne komunikacije olajšati delo naročnikov in izvajalcev. Naročnik tako dobi orodje za nadzor izvajalca, izvajalec pa orodje za oblikovanje dogovora o razumevanju uporabniških zahtev. Primarno vodilo je bilo izdelati preprost in pregleden sistem, ki uporabnikov ne bo obremenjeval, temveč jim bo v pomoč. Polna projektna rešitev bi bila preobsežna in prezahtevna. Podobno velja tako za razvojne inženirske sisteme kot za testne pakete. Izdelati je bilo treba hibrid, ki se napaja na najboljših praksah, a hkrati v njih ne posega pregloboko. Tako smo pripravili preprosto in univerzalno rešitev. Za njeno uporabo zadostuje kratko uvajalno šolanje, namenjeno pridobitvi teoretičnih in prak- tičnih osnov. 1. Bikha, A., 2008. Requrements management – defining the project scope and developing Use Cases. Working papers of the Global Centre for ICT, str. 1–69. 2. Gupta, P., 2004. The Six Sigma Business Scorecard, New York: MsGraw-Hill. 3. NSA, 2007. STANAG 4107 (Edition 8) – Mutual acceptance of Government Quality Asuusrance and Usage of the Allied Quality Assurance Publications (AQAP). Bruselj: NATO Standardisation Agency. 4. OGC, 2005. Managing Successful Projects with PRINCE2. London: Office of Government Commerce. 5. Taylor, R. N., 2010. Software Arhitecture, Foundations, Theory, and Practice, New York: John Wiley & Sons. Janez Hafner