Kako pripraviti razpisno dokumentacijo za informacijski sistem

Zakaj je razpisna dokumentacija temelj uspešnega projekta#

Razpisna dokumentacija za informacijski sistem je dokument, ki določa, kaj bo naročnik dobil, kdo bo to izvedel in po kakšnih merilih se bo presojala kakovost izvedbe. Kadar je dokumentacija nejasna ali pomanjkljiva, se to pozna skozi celoten projekt: ponudniki različno razumejo obseg, primerjava ponudb je težka, po podpisu pogodbe pa prihaja do sporov o tem, kaj je bilo dogovorjeno. Dobro pripravljena dokumentacija te težave prepreči že na začetku.

Priprava dokumentacije zahteva sodelovanje več vlog: naročnik pozna poslovne procese in zakonske obveznosti, izvajalec pa pozna tehnične možnosti in omejitve. Kadar se ti dve strani ne uskladita pred objavo razpisa, se zahteve med izvedbo spreminjajo, kar podaljšuje projekt in povečuje tveganje za neuspeh. Zato je smiselno, da naročnik pri pripravi dokumentacije povabi k sodelovanju tehnično svetovanje, še preden razpis objavi.

Ta članek povzema, katera vsebinska področja mora razpisna dokumentacija za informacijski sistem obvezno pokriti: od opredelitve obsega, tehničnih zahtev in podatkov do varnosti, meril za izbor, podpore po uvedbi in dokumentacije ob zaključku. Namen ni predpisati enotne oblike dokumenta, temveč opozoriti na vsebino, ki v praksi najpogosteje manjka in zato povzroča težave pri izvedbi.

Opredelitev obsega in funkcionalnih zahtev#

Prvi in najpomembnejši del dokumentacije je natančen opis obsega: kateri procesi bodo digitalizirani, katere uporabniške vloge sistem potrebuje in katere funkcionalnosti so obvezne v primerjavi s tistimi, ki so zaželene, a niso ključne. Brez tega razločevanja ponudniki obseg dela ocenjujejo na podlagi različnih predpostavk, kar naredi ponudbe med seboj neprimerljive.

Funkcionalne zahteve je smiselno zapisati po uporabniških vlogah in poslovnih scenarijih, ne le kot seznam tehničnih lastnosti. Tak pristop pomaga izvajalcu razumeti, zakaj je posamezna funkcionalnost potrebna, in omogoča lažje načrtovanje arhitekture ter uporabniške izkušnje. Naročniku pa omogoča, da med izvedbo preverja, ali je sistem res naslovil realne potrebe uporabnikov, ne le formalnih zahtev iz dokumenta.

Pri opredelitvi obsega je koristno ločiti med novim sistemom in prevzemom ali nadgradnjo obstoječega. Pri prevzemu je treba v dokumentaciji predvideti pregled obstoječe izvorne kode, arhitekture, infrastrukture in podatkov, saj ta pregled vpliva na to, kako realno je mogoče oceniti nadaljnji obseg dela. Naročnik naj v razpisu jasno navede, ali gre za gradnjo od začetka ali za nadaljevanje obstoječega sistema.

• Opis poslovnih procesov, ki jih sistem podpira
• Seznam uporabniških vlog in njihovih pravic
• Ločitev obveznih in zaželenih funkcionalnosti
• Podatek, ali gre za nov sistem ali prevzem obstoječega
• Pričakovan način dela (celoten projekt ali posamezen sklop)

Tehnične zahteve, integracije in arhitektura#

Informacijski sistem redko deluje samostojno. V razpisni dokumentaciji je treba navesti, s katerimi obstoječimi sistemi se mora nov sistem povezati, na primer z ERP, CRM, DMS ali ECM sistemi, in kakšne vrste API-jev ti sistemi že ponujajo. Kadar ta podatek manjka, izvajalec ne more oceniti, koliko dela bo integracija zahtevala, kar poveča tveganje za zamude pri izvedbi.

Poleg integracij je treba opredeliti tudi zahteve glede infrastrukture: ali bo sistem deloval v oblaku, na lokalni infrastrukturi ali v kombinaciji obeh, in kakšne zahteve veljajo glede razpoložljivosti sistema. Za javni sektor in regulirane panoge so te zahteve pogosto strožje, zato jih velja opredeliti čim prej, saj vplivajo na arhitekturo sistema in na to, kateri del dela je mogoče izvesti ločeno.

Kadar sistem vključuje mobilni del, naj dokumentacija navede, za katere platforme je aplikacija namenjena in ali mora delovati brez povezave. Kadar gre za AI funkcionalnosti, kot so obdelava dokumentov, semantično iskanje ali avtomatizacija poslovnih procesov, je treba opredeliti, kje se nahajajo podatki, kakšna natančnost se pričakuje in katera opravila lahko sistem izvaja samostojno, brez potrditve uporabnika.

• Obstoječi sistemi, s katerimi je treba integrirati nov sistem
• Vrsta in dostopnost API-jev obstoječih sistemov
• Zahteve glede infrastrukture (oblak, lokalna infrastruktura, kombinacija)
• Zahteve glede razpoložljivosti in odzivnosti sistema
• Platforme za mobilni del, če je potreben
• Obseg in namen AI funkcionalnosti, če jih sistem vključuje

Podatki in migracija#

Kadar projekt vključuje prevzem ali nadgradnjo obstoječega sistema, mora dokumentacija opredeliti tudi stanje in količino podatkov, ki jih je treba prenesti v nov sistem. Kakovost obstoječih podatkov neposredno vpliva na obseg dela pri migraciji, saj neurejeni, podvojeni ali nepopolni podatki zahtevajo dodatno čiščenje pred prenosom. Naročnik naj v dokumentaciji navede, kje se podatki trenutno nahajajo in v kakšni obliki so dostopni, saj to izvajalcu pomaga oceniti zahtevnost prenosa.

Pomembno je tudi vprašanje lastništva podatkov in izvorne kode. Naročnik naj v dokumentaciji jasno zapiše, da so izvorna koda in podatki njegova last, ne last izvajalca, ter da so dokumentacija, dostopi in gesla del primopredaje ob zaključku projekta. To preprečuje situacije, ko je naročnik po zaključku sodelovanja odvisen od enega izvajalca za vsako nadaljnjo spremembo sistema.

Za razvojno delo je treba določiti tudi, kako se ločujejo razvojno, testno in produkcijsko okolje. V testnem okolju se ne sme uporabljati pravih osebnih podatkov, kar je še posebej pomembno pri sistemih, ki obravnavajo občutljive ali osebne podatke uporabnikov. Ta zahteva naj bo del dokumentacije, saj vpliva na to, kako izvajalec zasnuje testiranje in kako pripravi testne podatke.

Varnostne in skladnostne zahteve#

Informacijski sistemi v javnem sektorju in reguliranih panogah morajo izpolnjevati posebne varnostne in skladnostne zahteve. Razpisna dokumentacija naj opredeli, katere zahteve veljajo za konkreten sistem, na primer glede varstva osebnih podatkov, revizijske sledi, nadzora dostopa in beleženja sprememb. Kadar te zahteve niso zapisane vnaprej, jih je treba dodajati med izvedbo, kar podaljšuje projekt in povečuje stroške usklajevanja.

Naročnik lahko v dokumentaciji tudi preveri, ali ima izvajalec dostop do ustreznega kadra in znanja za varnostno arhitekturo, penetracijsko testiranje in upravljanje identitet. Epix pri tem sodeluje s specialistično partnersko mrežo, znotraj katere so na voljo profili s certifikati s področja varnosti, oblačnih storitev in upravljanja infrastrukture, ter standardi, ki so del delivery strukture. Teh kompetenc ne pripisujemo Epix Group d.o.o. neposredno, temveč mreži kot celoti.

Za javni sektor je značilno, da poleg tehničnih zahtev dokumentacija zahteva tudi dokumentacijo za uporabnike, izobraževanje osebja in podporo po uvedbi. Primer takega projekta je rešitev za Občino Sevnica, kjer je bilo poleg programske rešitve in interaktivnih vsebin za javni prostor treba pripraviti tudi dokumentacijo, namestitev na lokaciji in podporo po zagonu sistema. Tovrstne zahteve naj bodo v dokumentaciji izrecno navedene, ne le predpostavljene.

• Zahteve glede varstva osebnih podatkov
• Zahteve glede revizijske sledi in beleženja sprememb
• Nadzor dostopa in upravljanje identitet
• Zahteve glede infrastrukture za regulirane panoge
• Dokumentacija in izobraževanje uporabnikov po uvedbi

Merila za izbor izvajalca in način dela#

Poleg tehničnih zahtev razpisna dokumentacija določa tudi merila, po katerih bo naročnik presojal ponudbe. Merila naj bodo usklajena s tem, kar je naročniku dejansko pomembno: izkušnje s podobnimi projekti, sposobnost sestaviti ustrezno projektno ekipo, način zagotavljanja kakovosti in jasnost predlaganega načina dela. Kadar so merila preveč splošna, se lahko zgodi, da je izbran ponudnik, ki ne razume dejanske zahtevnosti projekta.

Naročnik naj v dokumentaciji tudi zahteva, da ponudnik opredeli način dela: ali bo projekt prevzel v celoti ali po posameznih sklopih, kako bo pri večjih projektih določil projektnega vodjo, odgovornosti ekip in način poročanja. Ta podatek naročniku pomaga presoditi, kako bo potekalo sodelovanje med izvedbo in kdo bo odgovoren za posamezne odločitve.

Kadar gre za prevzem obstoječega ali nedokončanega sistema, je smiselno v dokumentaciji zahtevati, da ponudnik pred oddajo ponudbe opravi pregled izvorne kode, arhitekture, infrastrukture in podatkov. Tak pregled naročniku omogoča bolj realno primerjavo ponudb, saj ponudniki ocenjujejo na podlagi dejanskega stanja sistema, ne le na podlagi opisa v dokumentaciji.

• Izkušnje s podobnimi projekti in panogami
• Predlagan način dela (celoten projekt ali sklopi)
• Opredelitev projektnega vodenja in poročanja pri večjih projektih
• Pristop k pregledu obstoječega sistema, kadar gre za prevzem
• Pristop h kakovosti in testiranju

SLA in podpora po uvedbi#

Razpisna dokumentacija naj opredeli tudi, kakšna podpora je pričakovana po uvedbi sistema. Brez tega naročnik po zaključku projekta pogosto ostane brez jasnega dogovora o tem, kdo odpravlja napake, kako hitro in po kakšnih pravilih. Podpora po uvedbi naj vključuje nadzor delovanja, odpravo napak, tehnične in varnostne posodobitve ter, kadar je potrebno, nadaljnji razvoj sistema.

Smiselno je, da dokumentacija predvidi razvrščanje napak v razrede glede na njihovo resnost, na primer izpad sistema, motnjo pri delovanju posamezne funkcije, manjšo napako brez vpliva na poslovanje in zahtevo za spremembo ali nadgradnjo. Vsak razred ima svojo prednost obravnave, ki jo naročnik in izvajalec uskladita v pogodbi o podpori, ne v splošnih univerzalnih odzivnih časih.

Ker se odzivni časi razlikujejo glede na kritičnost sistema in dogovor med strankama, jih razpisna dokumentacija ne sme predpisati kot enotno pravilo za vse primere. Namesto tega naj dokumentacija zahteva, da ponudnik predlaga razvrstitev napak v razrede in način dogovarjanja o prednosti obravnave, kar naročniku omogoča presojo, kako resno ponudnik pristopa k podpori po uvedbi.

• Izpad - sistem ali ključni del ne deluje, najvišja prednost obravnave
• Motnja - sistem deluje, posamezna funkcija ne
• Napaka - manjša napaka brez vpliva na poslovanje, uvrsti se v naslednjo objavo
• Zahteva - sprememba ali nadgradnja, obseg in termin se uskladita naknadno

Testiranje, prevzem in QA#

Razpisna dokumentacija naj opredeli tudi, kako bo potekalo testiranje pred prevzemom sistema. Naročnik naj zahteva, da ponudnik pripravi testne scenarije, izvede ročno in avtomatizirano testiranje ter testiranje v okviru razvojnega procesa, preden je sprememba objavljena v produkcijskem okolju. Brez jasno opredeljenega testiranja se lahko zgodi, da naročnik prevzame sistem, ki v resnici ni bil ustrezno preverjen.

Za zahtevnejše projekte je smiselno v dokumentaciji predvideti neodvisen QA, ločen od razvojne ekipe, ki testira sistem iz perspektive uporabnika in ne le iz perspektive razvijalca. To je še posebej pomembno pri sistemih, ki obravnavajo plačila, osebne podatke ali kritične poslovne procese, kjer je napaka po uvedbi lahko težje odpravljiva.

Prevzemno testiranje naj bo v dokumentaciji opredeljeno z vnaprej dogovorjenimi merili, po katerih naročnik presoja, ali je sistem pripravljen za produkcijo. Taka merila naročniku omogočajo, da prevzem sistema ni le formalnost, temveč dejansko preverjanje, ali sistem izpolnjuje zahteve, opredeljene v razpisni dokumentaciji na začetku projekta.

Dokumentacija in primopredaja#

Ob zaključku projekta je treba naročniku predati vso dokumentacijo, ki mu omogoča samostojno upravljanje sistema ali nadaljevanje sodelovanja z drugim izvajalcem. Razpisna dokumentacija naj zato vnaprej opredeli, katera dokumentacija je del primopredaje: tehnična dokumentacija sistema, uporabniška navodila, dostopi in gesla ter podatki o infrastrukturi, na kateri sistem deluje.

Kadar sistem vključuje javni prostor ali interaktivne vsebine za uporabnike, kot je bilo to primer pri rešitvi za Občino Sevnica, je smiselno v dokumentacijo vključiti tudi izobraževanje osebja, ki bo sistem upravljalo po zagonu, ter navodila za vsakodnevno delo z opremo in vsebinami. Izobraževanje in dokumentacija skupaj naročniku zmanjšata odvisnost od izvajalca pri vsakodnevnem delovanju sistema in mu omogočita, da posamezne naloge opravlja samostojno.

Dokumentacija naj bo pripravljena tako, da jo lahko uporabi tudi drug izvajalec, če se naročnik kasneje odloči zamenjati podporo. To pomeni, da izvorna koda, arhitektura, konfiguracija infrastrukture in podatkovni model niso opisani le na splošno, temveč dovolj podrobno, da omogočajo prevzem sistema brez dolgotrajnega ponovnega spoznavanja z rešitvijo. Tak pristop naročniku daje dejansko svobodo pri izbiri izvajalca za nadaljnje delo.

Priprava razpisa skupaj z izvajalcem#

Priprava razpisne dokumentacije za informacijski sistem je lažja, kadar naročnik pred objavo razpisa vključi tehnično svetovanje. Epix in njegova specialistična partnerska mreža lahko sodelujeta pri razčlembi zahtev na posamezne sklope, tako da je vsak sklop ocenljiv in izvedljiv ločeno, kar naročniku pomaga pripraviti dokumentacijo, ki jo ponudniki razumejo enako.

Tak pristop je smiseln tudi zato, ker projektne ekipe, ki jih je mogoče sestaviti znotraj delivery mreže, pokrivajo celoten obseg dela: od analize in arhitekture prek razvoja, mobilnega dela in AI funkcionalnosti do cloud infrastrukture, varnosti, QA, uvedbe, dokumentacije in podpore po zagonu. Naročnik lahko torej v dokumentaciji predvidi, da bo en izvajalec pokril več področij, namesto da usklajuje več ločenih pogodb.

Kadar naročnik cene ne more oceniti vnaprej, je smiselno v dokumentacijo vključiti zahtevo po krajši analizi, ki obseg razčleni na sklope, preden se izdela končna ponudba. Taka analiza naročniku pomaga razumeti, od česa je obseg dela odvisen - od funkcionalnosti, integracij, stanja podatkov, varnostnih zahtev in ravni podpore po uvedbi - še preden se zaveže h končni pogodbi.

Razpisna dokumentacija za informacijski sistem torej ni le administrativni dokument, temveč orodje, s katerim naročnik zmanjša tveganje za nejasnosti, spore in podaljšane roke med izvedbo. Kadar so obseg, tehnične zahteve, podatki, varnost, merila za izbor, podpora po uvedbi in dokumentacija ob primopredaji opredeljeni vnaprej, je primerjava ponudb lažja, izvedba pa bolj predvidljiva za obe strani.