Javno naročilo za informacijski sistem: kaj preveriti pred oddajo

Kdo sploh lahko sodeluje na javnem naročilu za informacijski sistem?#

Na javnem naročilu za informacijski sistem lahko sodeluje vsak gospodarski subjekt, ki izpolnjuje pogoje za sodelovanje, določene v razpisni dokumentaciji – ekonomsko-finančno sposobnost, tehnično in kadrovsko usposobljenost ter zahtevane reference. Kdor teh pogojev ne izpolni ali jih ne dokaže na predpisan način, je iz postopka izločen, še preden pride do vsebinske primerjave ponudb, ne glede na to, kako dobra je sicer njegova tehnična rešitev.

Pogoji se med naročili razlikujejo, ker jih naročnik prilagodi tveganju in obsegu projekta. Pri manjši nadgradnji spletnega portala bodo zahteve praviloma manj stroge kot pri uvedbi celovitega informacijskega sistema, ki povezuje več oddelkov in obstoječih evidenc. Preden podjetje sploh začne pripravljati ponudbo, velja preveriti, ali izpolnjuje formalne pogoje – v nasprotnem primeru je vsak nadaljnji trud v pripravo vsebinske ponudbe zapravljen čas, ki bi ga ekipa lahko namenila projektu, kjer ima realne možnosti za uspeh.

Vprašanje javno naročilo informacijski sistem pogoji se v praksi najpogosteje nanaša prav na ta del razpisne dokumentacije. Gre za razdelek, kjer naročnik navede minimalne zahteve za sodelovanje, ločeno od meril za izbor najugodnejše ponudbe – to sta dva različna sklopa, ki ju je treba brati ločeno. Pogoje za sodelovanje ponudnik izpolni ali ne izpolni, merila pa določajo, katera med ustreznimi ponudbami je za naročnika najugodnejša.

• Ekonomsko-finančna sposobnost (bonitetna ocena, promet, zavarovanje odgovornosti)
• Tehnična sposobnost, izkazana z referencami primerljivih projektov
• Kadrovska sposobnost (izobrazba in izkušnje ključnega kadra)
• Registracija dejavnosti in morebitna dovoljenja
• Izpolnjen ESPD obrazec
• Odsotnost razlogov za izključitev (nekaznovanost, poravnane obveznosti)

Kaj morate preveriti v tehnični specifikaciji, preden oddate ponudbo?#

V tehnični specifikaciji je treba najprej preveriti, ali so zahtevane funkcionalnosti, integracije z obstoječimi sistemi naročnika in merila za prevzem opisani dovolj natančno, da jih je mogoče izvesti in preveriti brez naknadnega spora o obsegu dela. Nejasna ali splošno zapisana specifikacija je eno največjih tveganj pri javnih naročilih informacijskih sistemov, saj se šele med izvedbo pokaže, kaj je naročnik dejansko mislil.

Posebno pozornost velja nameniti zahtevam po povezovanju z obstoječimi sistemi naročnika, na primer ERP, CRM ali dokumentnim sistemom. Specifikacija bi morala navesti, kateri podatki se izmenjujejo, prek katerega vmesnika oziroma API-ja in kdo je odgovoren za dostop do obstoječega sistema med izvedbo. Kadar teh podatkov v razpisni dokumentaciji ni, je smiselno vprašanje nasloviti na naročnika še pred oddajo ponudbe, saj se obseg integracije pogosto izkaže za največji vir dodatnega dela po podpisu pogodbe.

Enako velja za obseg podatkov, ki jih je treba preseliti iz starega sistema v novega. Specifikacija naj opredeli količino in stanje podatkov, format, iz katerega se selijo, ter kdo preveri pravilnost preseljenih zapisov. Kadar je vir star, nedokumentiran ali delno podvojen sistem, se čas, potreben za migracijo, pogosto podcenjuje – to je smiselno upoštevati že pri sami odločitvi, ali ponudbo sploh oddati.

Nazadnje velja preveriti merila za prevzem sistema: kdaj se šteje, da je sistem funkcionalno dokončan in ustreza specifikaciji. Brez jasnih, merljivih meril za prevzem se lahko primopredaja zavleče, plačilo pa zadrži, čeprav je izvajalec svoj del dela že opravil, zato je smiselno, da ponudnik že v fazi priprave ponudbe predlaga, kako naj bo prevzemno testiranje strukturirano.

Reference in dokazila o usposobljenosti#

Reference so tisti del ponudbe, kjer naročnik preverja, ali je ponudnik že izvedel projekte primerljivega obsega in zahtevnosti. Pri informacijskih sistemih to praviloma pomeni izkušnje z večjimi, večoddelčnimi projekti, ne le s posameznimi manjšimi spletnimi rešitvami. Ponudnik mora znati referenco tudi dokazati – s pogodbo, potrdilom naročnika ali drugim dokazilom, ki ga razpisna dokumentacija zahteva, sicer se referenca pri ocenjevanju ne upošteva.

Izkušnje z javnim sektorjem imajo posebno težo, ker gre pogosto za projekte z jasno določenimi postopki naročanja, dokumentacijskimi zahtevami in nadzorom nad porabo javnih sredstev. Epix je tak projekt izvedel za Občino Sevnica, kjer je za javni prostor pripravil programsko rešitev in interaktivne vsebine na 55-palčnem zaslonu na dotik – od konfiguracije kiosk okolja in integracije strojne ter programske opreme do namestitve na lokaciji, dokumentacije in podpore po zagonu.

Tovrstna referenca pokaže, da izvajalec obvlada celoten cikel projekta v javnem prostoru: od tehnične zasnove do namestitve na terenu in dokumentacije, ki jo naročnik potrebuje za lastno evidenco in revizijsko sled. Za podjetje, ki pripravlja ponudbo, je smiselno enako natančno izkazati lastne pretekle projekte – ne le z naštevanjem imen, temveč z opisom obsega, vloge ekipe in doseženega rezultata.

Razpisna dokumentacija: kaj vse je treba prebrati pred odločitvijo o oddaji#

Razpisna dokumentacija pri javnem naročilu za informacijski sistem običajno obsega več ločenih dokumentov, ki jih je treba brati skupaj, ne posamično. Pogoji za sodelovanje, tehnična specifikacija, merila za izbor in vzorec pogodbe se med seboj dopolnjujejo – pogodba na primer pogosto vsebuje obveznosti, ki jih specifikacija sama ne omenja, na primer glede lastništva izvorne kode, dokumentacije ali podatkov po zaključku projekta.

Vzorec pogodbe je smiselno prebrati posebej pozorno, saj določa plačilne pogoje, pogodbene kazni, obveznosti glede vzdrževanja po uvedbi in način reševanja sporov. Podjetje, ki ponudbo pripravlja hitro in se osredotoči le na tehnično specifikacijo, lahko spregleda pogodbeno določilo, ki bistveno poveča tveganje projekta – na primer nesorazmerno visoko pogodbeno kazen za zamudo, ki je odvisna tudi od dejanj naročnika.

Poleg vzorca pogodbe velja preveriti tudi morebitne priloge, kot so zahteve glede varnosti podatkov, obrazec za opis reference ali predloga terminskega načrta. Priloge pogosto vsebujejo podrobnosti, ki jih glavni del razpisne dokumentacije le na kratko omenja, zato jih je treba brati kot enakovreden del zahtev, ne kot dodatek, ki ga je mogoče preleteti na hitro, saj prav v prilogah pogosto tiči zahteva, ki v celoti spremeni oceno tveganja za ponudnika.

• Povabilo k oddaji ponudbe in navodila ponudnikom
• Pogoji za sodelovanje in razlogi za izključitev
• Tehnična specifikacija predmeta naročila
• Merila za izbor najugodnejše ponudbe
• Vzorec pogodbe in morebitne priloge (SLA, varnostne zahteve)
• Obrazec ESPD in druge izjave ponudnika

Varnost podatkov in skladnost s predpisi#

Javna naročila za informacijske sisteme vse pogosteje vključujejo zahteve po varovanju osebnih podatkov in kibernetski varnosti, saj sistem pogosto obdeluje podatke državljanov, zaposlenih ali poslovnih partnerjev naročnika. Zahteve po skladnosti z GDPR, po potrebi pa tudi s pravili, ki izhajajo iz direktive NIS2 za ključne in pomembne subjekte, se v specifikaciji lahko pojavijo kot pogoj za sodelovanje ali kot del tehničnih zahtev za sam sistem.

Ponudnik mora znati pojasniti, kako bo v razvojnem, testnem in produkcijskem okolju ločil prave osebne podatke od testnih – v testnem okolju se pravi podatki naročnika praviloma ne uporabljajo, kar je tudi ustaljena praksa pri Epixu. Enako je smiselno vnaprej opredeliti, kdo ima dostop do produkcijskih podatkov, kako se ta dostop beleži in kako sistem izkazuje revizijsko sled, kar je pri javnih evidencah pogosto zahtevano.

Naročniki pri zahtevnejših projektih vse pogosteje preverjajo tudi, ali ponudnik oziroma njegova mreža izpolnjuje mednarodne standarde s področja kakovosti in informacijske varnosti. Epix in njegova specialistična partnerska mreža imata v svoji delivery strukturi vzpostavljene standarde, kot so ISO 9001, ISO 20000/20001, ISO 27001 in ISO 27701, poleg tega pa dostop do posameznikov s certifikacijskimi profili s področij oblačnih storitev, varnosti in upravljanja projektov. Take reference so pri javnih naročilih pogosto dodatna prednost, ne le formalna zahteva.

Kdaj se splača oddati ponudbo na javno naročilo za informacijski sistem?#

Ponudbo se splača oddati takrat, ko podjetje realno razpolaga s kadrovskimi kapacitetami za izvedbo projekta v obsegu, ki ga zahteva specifikacija, in ko tveganja iz pogodbe – pogodbene kazni, garancije, obveznosti po izvedbi – ne presegajo koristi, ki jih projekt prinaša. Če je odgovor na katero od tega vprašanja negativen, je smiselno ponudbo prej temeljito preračunati ali se odločiti, da se je podjetje ne udeleži.

Pri oceni tveganja je smiselno pogledati tudi, kako natančna je tehnična specifikacija in koliko odprtih vprašanj ostaja nerazjasnjenih. Zelo splošno zapisana specifikacija pomeni, da bo obseg dela med izvedbo verjetno večji, kot je razviden iz razpisne dokumentacije – to tveganje mora ponudnik upoštevati že v svoji interni oceni, ne glede na to, da cene v ponudbi ne sme spreminjati enostransko po oddaji.

Finančna tveganja – zahtevana zavarovanja, garancije za dobro izvedbo in pogodbene kazni – so pri javnih naročilih pogosto strožja kot pri zasebnih naročilih, ker naročnik varuje javna sredstva. Podjetje, ki teh instrumentov še ni uporabljalo, naj presojo prepusti pravni in finančni službi, ne le tehnični ekipi, saj lahko posamezna pogodbena določila ogrozijo poslovanje podjetja tudi, če je sam projekt tehnično uspešno izveden.

SLA in obveznosti po uvedbi sistema#

Javna naročila za informacijske sisteme pogosto ne zajemajo le razvoja, temveč tudi obveznost podpore po uvedbi – odpravljanje napak, tehnične in varnostne posodobitve ter dogovorjene odzivne čase glede na resnost težave. Ponudnik mora že v ponudbi predvideti, kako bo to podporo organiziral, saj gre za obveznost, ki traja dlje od same izvedbe projekta in pogosto pomembno vpliva na oceno tveganja celotnega posla.

Pri Epixu obveznosti po uvedbi razvrščamo v štiri razrede: izpad, ko sistem ali njegov ključni del ne deluje in ima obravnava najvišjo prednost; motnja, ko sistem deluje, a posamezna funkcija ne; napaka, manjša težava brez vpliva na poslovanje, ki se uvrsti v naslednjo redno objavo; in zahteva, torej sprememba ali nadgradnja, za katero se oceni obseg in uskladi termin izvedbe. Tak razrez je uporaben okvir tudi pri pripravi lastne ponudbe za javno naročilo, saj naročniku pokaže, da je podpora sistemsko urejena.

Del primopredaje po uvedbi so tudi dokumentacija, dostopi in gesla, izvorna koda in podatki pa ostanejo last naročnika. Spremembe na produkcijskem sistemu gredo po uvedbi skozi enak pregled in testiranje kot med razvojem, ločeno razvojno, testno in produkcijsko okolje pa ostane vzpostavljeno tudi po zaključku projekta, če se naročnik odloči za nadaljnje vzdrževanje pri istem izvajalcu, kar naročniku olajša tudi morebiten kasnejši prehod na drugega izvajalca, saj ostane vsa dokumentacija in koda dostopna.

Podizvajalci in konzorciji: kdaj sodelovati s partnerji#

Kadar razpisana specifikacija zahteva širši nabor kompetenc, kot jih ima podjetje samo – na primer hkrati razvoj, mobilne aplikacije, podatkovno analitiko in kibernetsko varnost – je smiselno razmisliti o nastopu s podizvajalcem ali v konzorciju. Razpisna dokumentacija običajno določa, kako je treba tak nastop prijaviti in kakšne pogoje mora izpolnjevati vsak član skupine posebej, zato je to vprašanje treba razjasniti še pred oddajo, ne med izvedbo.

Projekt je mogoče prevzeti v celoti ali kot posamezen projektni sklop, kar velja tudi za sodelovanje v vlogi podizvajalca pri večjem javnem naročilu. Znotraj širše delivery mreže je mogoče sestaviti projektno ekipo, ki združuje senior inženirje, arhitekte rešitev, specialiste za oblačno infrastrukturo, kibernetsko varnost in AI, ne da bi moralo eno samo podjetje same zaposlovati ves ta kader stalno.

Pri konzorciju je smiselno vnaprej dogovoriti odgovornosti posameznih partnerjev, projektno vodenje, način poročanja naročniku in delitev pogodbene odgovornosti, če pride do zamude ali napake enega od partnerjev. Nejasna delitev vlog je pogost vzrok sporov med partnerji med izvedbo, čeprav do njih navzven, proti naročniku, praviloma sploh ne bi smelo priti, zato velja to urediti s pisnim dogovorom še pred oddajo skupne ponudbe.

Kako izbrati tehničnega partnerja za pripravo in izvedbo ponudbe?#

Tehničnega partnerja za javno naročilo informacijskega sistema izberete tako, da preverite, ali zna prevzeti odgovornost za konkreten sklop projekta, izkazati primerljive reference in se vključiti v projekt po pravilih, ki jih postavlja razpisna dokumentacija – vključno z roki za oddajo dokazil, ki jih zahteva naročnik. Partner, ki teh formalnosti ne pozna, lahko upočasni pripravo celotne ponudbe, ne glede na to, kako dobra je njegova tehnična rešitev.

Pri izbiri je smiselno preveriti tudi, kako partner pristopa k prevzemu obstoječega ali nedokončanega sistema, če naročnik razpisuje nadgradnjo, ne novega sistema. Epix take projekte prevzame po pregledu izvorne kode, arhitekture, infrastrukture in podatkov, kar je pri javnih naročilih pogosto potrebno, saj naročnik redko razpisuje sistem, ki nastaja povsem na zeleni njivi, temveč gradi na obstoječih evidencah in sistemih, ki jih je treba najprej razumeti.

Zadnje, a ne najmanj pomembno merilo je, kako partner komunicira med izvedbo – kdo je projektni vodja, kako pogosto poroča in kako se rešujejo spremembe obsega, do katerih pri večjih javnih naročilih skoraj vedno pride. Pri večjih projektih Epix določi projektnega vodjo, odgovornosti posameznih ekip, roke ter način komunikacije in poročanja že na začetku, kar naročniku olajša nadzor nad izvedbo skozi celoten projekt.

• Dokazljive reference iz primerljivih projektov, po možnosti iz javnega sektorja
• Jasna delitev odgovornosti med naročnikom, izvajalcem in morebitnimi podizvajalci
• Poznavanje zahtev razpisne dokumentacije, ne le tehnične specifikacije
• Sposobnost prevzema obstoječega sistema po pregledu kode in podatkov
• Opredeljen model podpore in SLA po uvedbi
• Ločena razvojna, testna in produkcijska okolja ter varovanje podatkov v testnem okolju