018-066/2026 Javni holding Maribor d.o.o.
Številka: 018-066/2026-8Datum sprejema: 19. 6. 2026
Sklep
Državna revizijska komisija za revizijo postopkov oddaje javnih naročil (v nadaljevanju: Državna revizijska komisija) je na podlagi 39. in 70. člena Zakona o pravnem varstvu v postopkih javnega naročanja (Uradni list RS, št. 43/2011 s sprem.; v nadaljevanju: ZPVPJN) v senatu Sama Červeka kot predsednika senata ter Andraža Žvana kot člana senata in dr. Mateje Škabar kot članice senata, v postopku pravnega varstva pri oddaji javnega naročila »Implementacija in redno vzdrževanje novega poslovno-informacijskega sistema Javnega podjetja Snaga, d.o.o.«, na podlagi zahtevka za revizijo vlagatelja HIPROJECT d.o.o., Mestni trg 7B, Slovenske Konjice, ki ga po pooblastilu zastopa odvetnik Aleksander Petrovič, Ulica XIV. divizije 8, Celje (v nadaljevanju: vlagatelj), zoper ravnanje naročnika in pooblaščenega naročnika Javni holding Maribor d.o.o., Zagrebška cesta 30, Maribor (v nadaljevanju: naročnik) dne 19. 6. 2026
odločila:
1. Zahtevek za revizijo se zavrne kot neutemeljen.
2. Zahteva vlagatelja za povrnitev stroškov postopka pravnega varstva se zavrne.
Obrazložitev:
Obvestilo o predmetnem javnem naročilu, ki ga naročnik izvaja po odprtem postopku skladno s 40. členom Zakona o javnem naročanju (Uradni list RS, št. 91/15, s sprem.; v nadaljevanju: ZJN-3), je bilo 10. 4. 2026 objavljeno na Portalu javnih naročil pod št. objave JN002679/2026-EUe16/01 in istega dne v Uradnem listu Evropske unije pod št. objave 245020-2026, z dvema popravkoma. Naročnik na podlagi pooblastila št. JN-P-06/2026-S izvaja postopek javnega naročanja v imenu in za račun naročnika Javno podjetje Snaga, d.o.o., Nasipna ulica 64, Maribor.
Vlagatelj je (pred potekom roka za predložitev ponudb) z vlogo z dne 24. 4. 2026 vložil zahtevek za revizijo, v katerem primarno predlaga, da se zahtevku za revizijo ugodi in v celoti razveljavi izpodbijana dokumentacija v zvezi z oddajo javnega naročila, podredno pa da se razveljavijo pogoji ali zahteve, ki določajo:
- da mora biti informacijski sistem podjetja Microsoft Dynamics 365 Business Central oz. da so dovoljene tudi drugačne rešitve za ERP sistem;
- da je za uvedbo, prilagoditev in integracije novega krovnega informacijskega sistema ERP, dovoljen le Microsoft Dynamics 365 Business Central;
- da se implementacijo podsistema za programsko rešitev oziroma tehnološko platformo, namenjeno digitalizaciji operativnih procesov v podjetju (v nadaljevanju: operativni podsistem), integrira zgolj z ERP 365 BC;
- odprto kodno rešitev v točki 5.1 REQ-TCH-001 - Odprtokodna rešitev – v dokumentu »Uporabniške zahteve«;
- Kritičnost napak in odzivni časi v dokumentu »Uporabniške zahteve« v točki 2.11.3 ter pogodbene kazni v vzorcu pogodbe, zlasti glede časovnih intervalov na katere se izrekajo pogodbene kazni;
- Preverjanje sposobnosti, podpoglavje pogoji za sodelovanje, točka C. Tehnična in strokovna sposobnost.
V vsakem primeru vlagatelj zahteva povrnitev stroškov pravnega varstva.
Naročnik je z odločitvijo z dne 8. 5. 2026 zavrnil zahtevek za revizijo in vlagateljevo zahtevo za povrnitev stroškov.
Naročnik je dne 13. 5. 2026 in 29. 5. 2026 Državni revizijski komisiji odstopil dokumentacijo v zvezi s predmetnim javnim naročilom in dokumentacijo predrevizijskega postopka.
Vlagatelj v vlogi z dne 13. 5. 2026, s katero se je opredelil do navedb naročnika, vztraja pri navedbah iz zahtevka za revizijo.
Naročnik je dne 18. 6. 2026 posredoval pripravljalno vlogo s katero obvešča, da postopka ni ustavil, dne 4. 6. 2026 pa je sprejel odločitev, da se javno naročilo ne odda.
Državna revizijska komisija je pred meritorno obravnavo zahtevka za revizijo preverila, ali je bil zahtevek za revizijo vložen pravočasno in pri naročniku; ali vsebuje vse obvezne sestavine iz 15. člena ZPVPJN; ali ga je vložila aktivno legitimirana oseba iz 14. člena ZPVPJN; ali obstajajo omejitve iz 16. člena ZPVPJN in ali je dopusten. Ker je Državna revizijska komisija ugotovila, da so vsi pogoji iz prvega odstavka 31. člena ZPVPJN izpolnjeni, je zahtevek za revizijo, na podlagi drugega odstavka 31. člena ZPVPJN, sprejela v obravnavo.
Državna revizijska komisija uvodoma ugotavlja, da vlagatelj zatrjuje, da ni jasno ali ima pooblaščenec naročnika ustrezno pooblastilo. Iz vpogleda v odstopljeno dokumentacijo Državna revizijska komisija izhaja, da pooblaščeni naročnik na podlagi pooblastila št. JN-P-06/2026-S z dne 26. 2. 2026 izvaja postopek javnega naročanja v imenu in za račun naročnika Javno podjetje Snaga, d.o.o., Nasipna ulica 64, Maribor, prav tako iz pooblastila izhaja, da je pooblaščen tudi za zastopanje v postopkih pravnega varstva v postopku javnega naročanja.
Po pregledu dokumentacije o javnem naročilu ter preučitvi navedb vlagatelja in naročnika je Državna revizijska komisija odločila, kot izhaja iz izreka tega sklepa, iz razlogov, navedenih v nadaljevanju.
Predmet javnega naročila, ki ga naročnik oddaja po odprtem postopku, je enotna izvedba projekta, ki zajema uvedbo, prilagoditve in integracije novega krovnega informacijskega sistema ERP Microsoft Dynamics 365 Business Central (v nadaljevanju tudi: ERP 365 BC) za podporne procese naročnika, skladno s strategijo lastniškega Javnega holdinga Maribor, d.o.o., ki predvideva uvajanje Microsoft Dynamics 365 Business Central v povezana podjetja holdinga; implementacijo podsistema za programsko rešitev oziroma tehnološko platformo, namenjeno digitalizaciji operativnih procesov v podjetju, ki je integriran z ERP 365 BC; redno vzdrževanje IS ERP sistema za obdobje 36 mesecev po produkcijskem zagonu, skladno s pogoji SLA in izvedbo dodatnih del po naročilu naročnika.
Državna revizijska komisija je revizijske navedbe presojala po vsebinskih točkah, kot jih je navedel vlagatelj v zahtevku za revizijo, pri čemer je medsebojno povezane očitke obravnavala skupaj.
I. Glede zahtevanega informacijskega sistema Microsoft Dynamics 365 Business Central
Vlagatelj zatrjuje, da naročnik zahteva implementacijo točno določenega produkta – tehnologijo Microsoft Dynamics 365 Business Central in točno določeno rešitev ERP, ki je zgolj ena izmed mnogih na trgu, s takšno zahtevo pa krši določbe ZJN-3 in omejuje številne ponudnike, ki lahko nudijo vsebinsko ustrezen ERP sistem, ki ne temelji na omenjeni platformi. Zatrjuje, da naročnik nima objektivne utemeljitve za zahtevo navedenega produkta, njegova zahteva pa neupravičeno omejuje konkurenco, ki ponuja enakovredne konkurenčne rešitve ERP sistemov. Zatrjuje, da ne more sodelovati pri predmetnem javnem naročilu, čeprav lahko ponudi vsebinsko enakovreden sistem. Navaja tudi slabosti zahtevanega produkta in izpostavlja sporočilo Komisije Evropskemu parlamentu, Svetu, Evropskemu ekonomsko-socialnemu odboru in odboru regiji z dne 1. 4. 2025 o tehnološki suverenosti in tehnološki odvisnosti.
Naročnik na drugi strani pojasnjuje, da je pri določanju svojih potreb samostojen, ZJN-3 pa ga ne omejuje glede izbire predmeta, ki ga bo naročil, pri tem se sklicuje na odločitev Državne revizijske komisije št. 018-172/2025. Prav tako izpostavlja prakso Državne revizijske komisije iz katere izhaja, da načela enakovrednosti ni mogoče razumeti kot absolutne kategorije; da ZJN-3 naročniku ne prepoveduje določitve tehničnih zahtev, s katerimi se omejuje konkurenca, temveč le takšnih s katerimi se neupravičeno omejuje konkurenca. Poudarja, da produkt oziroma licence sploh niso predmet javnega naročila, zato se dejansko stanje bistveno razlikuje od zadeve iz sklepa Državne revizijske komisije št. 018-047/2024. Zatrjuje, da naročnik Javni holding Maribor d.o.o. že razpolaga z licencami in platformo v okviru postopnega strateškega poenotenja uvaja v vse družbe v okviru holdinga. Navaja, da odločitev za uporabo zahtevane platforme izhaja iz strateške usmeritve Skupine Javni holding Maribor, d.o.o., k poenotenju informacijskega okolja, večji povezljivosti sistemov, racionalizaciji stroškov, standardizaciji procesov in dolgoročno učinkovitejšemu upravljanju informacijskih rešitev. Platforma je določena iz objektivnih poslovnih, tehnoloških in organizacijskih razlogov. Navaja, da gre za tehničen standard združljivosti v okviru licenc, ki jih naročnik znotraj holdinga že uporablja, brez poenotenja pa ni mogoče uporabljati rešitev različnih podjetij znotraj holdinga na enotni strojni opremi ter platformi. Uporaba enotne platforme zagotavlja, da se oprema ne podvaja, da se ne kupuje različnih licenc in uporablja različnih rešitev, kar z vidika kadrovskih resursov finančno, tehnično ter organizacijsko ni vzdržno. Enotna platforma omogoča uporabo določenih skupnih modulov, mogoč je enoten pogled na podatke, kar omogoča celovitost pregleda nad delovanjem posamezne gospodarske družbe, pa tudi poenostavljeno združenje v primeru statusnih sprememb. Zatrjuje, da na drugačen način sploh ne more doseči ciljev, ki jih lahko doseže zgolj s poenotenjem na enovito platformo. Izpostavlja še vprašanje ali lahko prosto sprejema poslovne odločitve o uporabi določene platforme s katero že razpolaga, ali mu te poslovne odločitve lahko narekuje katerikoli ponudnik na trgu. Navaja, da je vprašljiva tudi aktivna legitimacija, saj lahko rešitev, ki teče na zahtevani platformi izdela vsak ponudnik na trgu, ki razpolaga z ustreznimi znanji. Navaja, da vlagatelj ne zatrjuje, da ne more izdelati rešitve na podlagi funkcionalnih zahtev, ki bi za platformo uporabljala zahtevano rešitev, niti ne zatrjuje in ne dokaže kako očitane kršitve naročnika posegajo v pravni položaj oz. ekonomski interes vlagatelja.
Vlagatelj v vlogi z dne 13. 5. 2026 s katero se je opredelil do naročnikovih navedb poudarja, da je stanje identično kot v odločitvi Državne revizijske komisije št. 018-047/2024, iz katere izhaja, da avtonomija naročnika pri oblikovanju specifikacij ni neomejena, saj mora imeti za zahteve, ki omejujejo konkurenco opravičljive razloge. Pojasnjuje, da je navedena odločitev uporabljiva, saj predmet javnega naročila niso bile le licence temveč tudi implementacija rešitev HRV in ostalih »add on« rešitev, ki uporabljajo zahtevan Microsoft Dynamics. Vlagatelj zatrjuje, da ni jasno na koga se nanašajo navedbe, ko se navaja »naročnik«. Zatrjuje, da navedbe naročnika iz katerih izhaja, da le-ta ima licence Microsoft Dynamics 365 Business Central, in da jih že uporablja, niso relevantne, sej je v konkretnem primeru naročnik Javno podjetje Snaga d.o.o. Kljub temu iz previdnosti zatrjuje, da se naročnik le splošno sklicuje na strateške usmeritve Skupine Javni holding Maribor, d.o.o., k poenotenju informacijskega okolja, večji povezljivosti sistemov, racionalizaciji stroškov, standardizaciji procesov in dolgoročno učinkovitejšemu upravljanju informacijskih rešitev, saj za te navedbe ne predloži dokazov. Prav tako dodaja, da ni izkazal imetništva licenc, niti zaveze, da bi moral naročnik uporabljati točno določen produkt. Zatrjuje, da skladno z javno objavljenimi pogoji licenciranja, produkta Microsoft Dynamics 365 Business Central ni mogoče kupiti oziroma ga licencirati za trajno uporabo, možno je kupiti licenco za določen čas, dejansko gre tako za najem uporabe, ki jo uporabnik lahko kadarkoli odpove. Dalje zatrjuje, da je licenca vezana na podjetje in zaposlene, tako morebitne licence pooblaščenega naročnika niso uporabljive za naročnika, ki bo implementiral sistem. Dodaja, da veliko ponudnikov lahko ponudi ERP sistem a ne na platformi, ki jo zahteva naročnik. Zatrjuje, da lahko naročnik določi katero strojno opremo mora podpirati rešitev in določi ustrezne tehnične specifikacije, tudi istovrstnosti podatkov se po mnenju vlagatelja lahko zagotavlja s tehnično specifikacijo. Navaja tudi, da je lažja prenosljivost podatkov zgolj zaradi uporabe enake platforme zgolj navidezna.
Naročnik mora skladno s prvim odstavkom 68. člena ZJN-3 v dokumentaciji v zvezi z oddajo javnega naročila navesti tehnične specifikacije, s katerimi opredeli zahtevane značilnosti (lastnosti) predmeta javnega naročila, ki naj bi izražale pričakovanja naročnika glede namena, ki ga želi doseči z izvedbo javnega naročila. Tehnične specifikacije določajo zahtevane značilnosti gradnje, storitve ali blaga. Te značilnosti se lahko nanašajo tudi na točno določen postopek ali način proizvodnje ali zagotavljanja zahtevanih gradenj, blaga ali storitev ali na točno določen postopek za kakšno drugo stopnjo v njihovi življenjski dobi, tudi če takšni dejavniki fizično niso del njih, a pod pogojem, da so značilnosti povezane s predmetom javnega naročila ter sorazmerne z vrednostjo in cilji naročila.
Naročnik tehnične specifikacije določi ob upoštevanju 68. člena ZJN-3, ki v četrtem odstavku določa, da morajo tehnične specifikacije vsem gospodarskim subjektom zagotavljati enak dostop do postopka javnega naročanja in neupravičeno ne smejo ovirati odpiranja javnih naročil konkurenci. Naročnik je pri opisovanju predmeta javnega naročila omejen tudi s temeljnimi načeli javnega naročanja, ki ga zavezujejo, da tehnične zahteve določi na način, ki zagotavlja konkurenco med ponudniki in njihovo enakopravno obravnavo (5. in 7. člen ZJN-3), hkrati pa mora zahteve določiti v obsegu, ki je potreben in sorazmeren z naravo, vsebino, namenom in obsegom predmeta naročila (8. člen ZJN-3).
Vendar gre v zvezi z navedenim izpostaviti, da je Državna revizijska komisija že večkrat pojasnila (npr. odločitve št. 018-111/2021-20, 018-043/2021-10, 018-127/2020-6, 018-020/2019-10), da načela zagotavljanja konkurence med ponudniki ni mogoče interpretirati v smislu zahteve po vzpostavljanju konkurenčnosti tudi na tistih področjih oziroma v tistih primerih, ko te iz upravičenih razlogov ni mogoče doseči. Prav tako tudi načela enakopravnosti v pravu javnih naročil ni mogoče razumeti kot absolutne kategorije. Enakopravnost namreč ne pomeni, da mora naročnik vsem potencialnim ponudnikom omogočiti enak položaj v postopku oddaje javnega naročila. Nasprotno, pravo praviloma ne sme neposredno vplivati na razmerja na trgu z ukrepi, ki bi povzročali ekonomsko ali dejansko enakost. Zaradi različnih ekonomskih, tehničnih, kadrovskih in tudi naravnih danosti je dejanski položaj ponudnikov in njihovih ponudb različen, prednosti, ki jih te dajejo, pa je dovoljeno in pogosto celo gospodarno upoštevati. Zato zgolj dejstvo, da naročnik z določeno zahtevo razlikuje ponudnike, še ne pomeni, da je takšna zahteva že sama po sebi diskriminatorna. V naravi same zahteve je, da ponudnike razvršča na tiste, ki določeno zahtevo izpolnjujejo in je zato njihovo ponudbo mogoče obravnavati kot dopustno (takšno, ki ustreza potrebam in zahtevam naročnika), ter na tiste, ki te zahteve ne izpolnjujejo in posledično ne morejo sodelovati v postopku oddaje javnega naročila. Naročniki so zato v postopkih oddaje javnih naročil upravičeni postavljati zahteve, ki imajo za posledico razlikovanje ponudnikov, vendar le iz razlogov, ki so neposredno povezani s predmetom javnega naročila in so objektivno opravičljivi. Ni pa dopustno razlikovanje ponudnikov glede na kriterije, ki niso objektivno opravičljivi in pomenijo zlasti krajevno, predmetno ali osebno diskriminacijo, s čimer je določen gospodarski subjekt bodisi postavljen v bistveno slabši položaj bodisi je privilegiran, ne da bi za to obstajali utemeljeni razlogi (v tej zvezi smiselno prim. tudi sodbo Sodišča EU v zadevi C-513/99, Concordia Bus Finland Oy Ab).
Vsaka tehnična specifikacija, ki jo določi naročnik, vpliva na krog gospodarskih subjektov, ki lahko pridobijo javno naročilo, saj že po naravi stvari razlikuje med gospodarskimi subjekti, ki jo lahko (s ponujenim predmetom) izpolnijo, in gospodarskimi subjekti, ki je ne morejo. Vendar kot navedeno ni namen ZJN-3, da bi preprečil vsakršno razlikovanje med gospodarskimi subjekti, temveč le tisto, ki ni skladno z njim (npr. arbitrarno razlikovanje). ZJN-3 naročniku tako ne prepoveduje določitve tehničnih zahtev, s katerimi se omejuje konkurenca, temveč mu prepoveduje zgolj določitev takšnih tehničnih zahtev, s katerimi se neupravičeno omejuje konkurenca. Če torej naročnik, ne glede na to, da lahko določeno zahtevo morebiti izpolni le določen krog potencialnih ponudnikov (ali celo en sam ponudnik) oziroma da posamezen ponudnik ne more konkurirati za pridobitev naročila, izkaže, da je takšna zahteva povezana s predmetom naročila in da ima zanjo objektivno utemeljene razloge, mu ni mogoče očitati kršitve določb ZJN-3.
Naročnik je v dokumentaciji v zvezi z oddajo javnega naročila v dokumentu »Uporabniške zahteve« v 1. poglavju »Predmet naročila« določil, da predmet obsega:
»Uvedbo, prilagoditve in integracije novega krovnega informacijskega sistema ERP (Microsoft
Dynamics 365 Business Central – v nadaljevanju: ERP 365 BC) za podporne procese naročnika,
skladno s strategijo lastniškega Javnega holdinga Maribor, ki predvideva uvajanje Microsoft
Dynamics 365 Business Central v povezana podjetja holdinga ter
2. Implementacijo podsistema za programsko rešitev oziroma tehnološko platformo, namenjeno
digitalizaciji operativnih procesov v podjetju (v nadaljevanju: operativni podsistem), ki je
integriran z ERP 365 BC.
Krovni informacijski sistem podjetja mora biti Microsoft Dynamics 365 Business Central, ki zajema vse podporne procese kot je v nadaljevanju dokumenta napisano. Izvajalec jih ne sme nadomestiti s programsko opremo drugega ponudnika (podizvajalca). […]
Potrebne ERP licence (Microsoft Dynamics 365 Business Central) bodo zagotovljene s strani Javnega holdinga Maribor in zato niso predmet tega naročila.«
Med strankama je sporna zakonitost naročnikove zahteve, da morajo ponudniki ponuditi informacijski sistem ERP Microsoft Dynamics 365 Business Central.
Kot že ugotovljeno, je naročnik v danem primeru kot predmet javnega naročila opredelil uvedbo, prilagoditve in integracijo krovnega informacijskega sistema ERP Microsoft Dynamics 365 Business Central, pri čemer je zahtevane funkcionalnosti informacijskega sistema podal v dokumentu »Uporabniške zahteve«. Naročnik je tako določil tehnične specifikacije v smislu delovanja in funkcionalnosti (skladno s točko a) petega odstavka 68. člena ZJN-3), kljub temu pa zahteval rešitev, ki deluje na točno določenem informacijskem sistemu (tj. produktu določene blagovne znamke).
Vlagatelj zatrjuje, da naročnik zahtevane ERP rešitve v času objave predmetnega javnega naročila ne uporablja, zato zahteva rešitve na točno določenem informacijskem sistemu ni objektivno utemeljena in neupravičeno omejuje enakovredne konkurenčne ERP rešitve. Navaja tudi slabosti zahtevane rešitve in opozarja na tehnološko odvisnost od ameriškega ponudnika ter priporočila Evropske komisije glede tehnološke suverenosti.
Naročnik na drugi strani pojasni, da odločitev za uporabo zahtevane platforme izhaja iz strateške usmeritve Skupine Javni holding Maribor, d.o.o., katere del je tudi naročnik, k poenotenju informacijskega okolja, večji povezljivosti sistemov, racionalizaciji stroškov, standardizaciji procesov ter dolgoročno učinkovitejšemu in celovitejšemu upravljanju informacijskih rešitev.
Vlagatelj izpostavlja, da naročnik ne predloži dokazov o obveznosti naročnika izpolnjevati zaveze holdinga, zatrjuje še, da naročnik nima licenc, le teh pa tudi sicer ni mogoče kupiti za trajno uporabo oziroma je mogoče od uporabe odstopiti.
Državna revizijska komisija ugotavlja, da dejstvo, da naročnik ob objavi javnega naročila še ne uporablja zahtevane platforme, samo po sebi ne more pomeniti, da za takšno zahtevo nima objektivno opravičljivih razlogov. Takšno stališče bi namreč neutemeljeno omejevalo pravico naročnika do načrtovanja prihodnjega razvoja svojega informacijskega okolja in izvajanja strateških odločitev, sprejetih na ravni skupine. Potrebe po poenotenju poslovno-informacijskega sistema zato ni mogoče presojati zgolj z vidika trenutnega stanja posamezne družbe, temveč v okviru širšega poslovnega in organizacijskega konteksta, v katerem ta družba deluje.
Državna revizijska komisija dalje ugotavlja, da je naročnik izkazal neposredno povezavo med sporno zahtevo in predmetom javnega naročila ter prepričljivo pojasnil, da je predmetna zahteva posledica poslovnih, tehnoloških in organizacijskih razlogov ter del širše strateške usmeritve holdinga k poenotenju informacijskega okolja vseh družb v skupini, vključno z naročnikom. Pojasni namreč, da predmet javnega naročila ni nakup licenc (kar izhaja že iz dokumentacije v zvezi z oddajo javnega naročila), temveč tehnični standard združljivosti v okviru licenc, ki jih podjetja znotraj holdinga že uporabljajo oziroma jih uvajajo tudi v preostale družbe. Cilj naročnika pa je zagotoviti standardizirane poslovne procese, uporabo skupnih modulov, ki se razvijejo zgolj enkrat in uporabljajo pri več uporabnikih, učinkovitejše upravljanje informacijskih rešitev, lažjo izmenjavo podatkov, uporabo skupne infrastrukture ter racionalnejšo porabo finančnih in kadrovskih virov, brez podvajanja strojne opreme, nakupa različnih licenc in upravljanja različnih rešitev znotraj holdinga. Glede na navedeno ni mogoče spregledati, da je naročnik izkazal neposredno povezavo med sporno zahtevo in predmetom javnega naročila, saj je zahteva po uporabi določene platforme torej namenjena zagotavljanju združljivosti in enotnega delovanja informacijskega okolja na ravni skupine podjetij. Okoliščina, da licence oziroma informacijsko okolje uporablja družba znotraj skupine oziroma holding kot krovna organizacija, še ne pomeni, da teh okoliščin ni dopustno upoštevati pri opredelitvi potreb odvisne družbe oziroma naročnika. Kot že navedeno je naročnik pojasnil, da se zahteva nanaša na vzpostavitev enotnega informacijskega okolja holdinga in ne zgolj na potrebe posamezne družbe, zato vlagateljeve navedbe s katerimi zatrjuje, da naročnik še nima licenc pri presoji objektivno upravičenih razlogov niso utemeljene. Tudi navedbe vlagatelja o načinu in trajanju licenciranja Microsoft Dynamics 365 Business Central same po sebi ne izpodbijajo naročnikovih navedb o organizacijskih, procesnih in tehnoloških koristi standardizacije in poenotenja sistemov na ravni skupine oziroma holdinga.
Naročnik tudi sicer dodaja, da lahko rešitev, ki teče na zahtevani platformi skladno s tehničnimi specifikacijami in funkcionalnimi zahtevami, izdela vsak ponudnik na trgu, ki razpolaga z ustreznimi znanji. Tudi vlagatelj sam zatrjuje, da veliko ponudnikov lahko ponudi ERP rešitve, ki izpolnjujejo potrebe naročnika, vendar zgolj pavšalno navaja, da to ni izvedljivo na zahtevani platformi, pri čemer za takšno trditev ne navede nobenih konkretnih razlogov. Njegove navedbe zato ne morejo omajati naročnikovih pojasnil o obstoju objektivnih razlogov za določitev sporne zahteve. Ker je naročnik v odločitvi o zavrnitvi zahtevka za revizijo po presoji Državne revizijske komisije navedel objektivno utemeljene okoliščine, povezane s predmetom javnega naročila, ki upravičujejo zahtevo, da rešitev informacijskega sistema deluje na zahtevani platformi, je treba navedbe vlagatelja, da zahteva ni objektivno utemeljena zgolj zato, ker obstajajo druge ERP-rešitve, da naročnik ni družba Javni holding Maribor, d.o.o., ter da zahteva po rešitvi na navedeni platformi ni sorazmerna oziroma povezana s predmetom javnega naročila in zato predstavlja kršitev 68. člena ZJN-3 ter načela zagotavljanja konkurence med ponudniki iz 5. člena ZJN-3, zavrniti kot neutemeljene.
Sklicevanje vlagatelja na odločitev Državne revizijske komisije št. 018-047/2024 ni utemeljeno, saj se obravnavana zadeva od navedene razlikuje tako glede predmeta javnega naročila kot tudi glede trditvene podlage, na kateri temelji presoja. V zadevi št. 018-047/2024 v okviru katere je naročnik naročal licence in nato nanje vezal zahtevano rešitev je Državna revizijska komisija ugotovila, da naročnik ni uspel objektivno utemeljiti zahteve po uporabi točno določene platforme in ni izkazal, zakaj njegovih potreb ne bi mogla zadovoljiti tudi druga enakovredna rešitev. V obravnavanem primeru pa predmet javnega naročila ni nabava licenc ali izbira določene programske rešitve na trgu, temveč implementacija ERP rešitve na platformi, ki jo naročnik oziroma skupina že zagotavlja oziroma jo bo zagotovila sama, zaradi česar je zahteva usmerjena v zagotavljanje združljivosti in integracije z enotnim informacijskim okoljem skupine. Poleg tega je naročnik v tem postopku podal konkretne razloge za uporabo zahtevane platforme ter pojasnil njihovo neposredno povezavo s predmetom naročila, medtem ko vlagatelj teh razlogov v predmetni zadevi s pavšalnimi navedbami vsebinsko ni uspel ovreči. Ker je presoja zakonitosti posamezne zahteve vselej odvisna od konkretnega predmeta naročila ter trditev in dokazov, ki jih v postopku zatrjujejo stranke, ugotovitev iz zadeve 018-047/2024 ni mogoče neposredno prenesti na obravnavani primer.
Prav tako na ugotovljeno ne vplivajo priporočila in smernice v zvezi z informacijsko odvisnostjo na katere se sklicuje vlagatelj, saj le te niso zavezujoči pravni akti, posledično za naročnika ne ustvarjajo obveznosti in ne morejo predstavljati podlage za ugotovitev kršitev.
II. Glede splošne tehnične dokumentacije
Vlagatelj zatrjuje, da v okviru uporabniških zahtev manjka specifikacija arhitekture sistema, integracijskih vmesnikov (API, formati), varnostnih zahtev, zmogljivostne zahteve, da ni primerov uporabniških vmesnikov, podatkovnih modulov ter opisov obstoječih sistemov predvidenih za integracijo, brez navedenega pa ni mogoče podati ustrezne ponudbe in zagotavljati integracijo sistema, saj obseg del ni znan.
Naročnik zatrjuje, da vlagatelj zgolj pavšalno navaja kaj naj bi manjkalo v dokumentaciji v zvezi z oddajo javnega naročila. Zatrjuje, da je predmet določil natančno skladno s funkcionalnimi zahtevami, ki jih potrebuje, način na katerega se funkcionalnost implementira pa je prepuščena ponudnikom. Pri izdelavi uporabniškega vmesnika je tako ponudnik avtonomen v okviru funkcionalnih specifikacij. Naročnik meni, da so tehnične specifikacije v dokumentu, ki obsega kar 448 strani dovolj natančne, da je mogoče izračunati obseg potrebnega dela in oblikovati konkurenčno ceno. Pojasnjuje še, da je arhitektura sistema določena v 5.4 identifikator zahteve REQ-TCH-005 oz. celotnem poglavju št. 5, varnostne zahteve v poglavju 6.15 REQ-CMN-015, uporabniški vmesniki v poglavju 5.18 REQ-TCH-020, povezana rešitev z enotnim vmesnikom na strani 115, zahteve po zmogljivosti so navedene na način, da lahko naročnik rešitev skalira kar je navedeno v poglavju 5.5 REQ-TCH-006.
Vlagatelj v vlogi z dne 13. 5. 2026 našteva glavne osnovne elemente arhitekture, programske arhitekture ter mrežne arhitekture in dodaja, da iz dokumentacije v zvezi z javnim naročilom ni razvidna strojna in mrežna arhitektura (izpostavlja tip in št. procesorjev, velikost pomnilnika, ustrezno hitrost trdih diskov, število in propustnost ter hitrost mrežnih povezav). Naročnik se sklicuje na točko 6.15 vendar ta ne določa kako ima sistem zasnovan naročnik, da lahko aplikacija in microservisi komunicirajo med seboj. Glede uporabniških vmesnikov se naročnik sklicuje na točko 5.18, ki ima le osnovna napotila glede delovanja uporabniških vmesnikov, ničesar pa o primerih vsebine ali potreb naročnika. Zahteva rešitev, ki ima že narejene API vmesnike vendar jih tehnična dokumentacija po mnenju vlagatelja ne določa, definirano ni niti kateri podatki bodo posredovani s strani naročnika, kako jih je potrebno konsolidirati oziroma katere podatke bodo pošiljali tretji sistemi. Prav tako ni določeno s katerimi sistemi naročnika in na kakšne načine se bo opravila integracija. Ne pojasni niti podatkovnih modelov, niti glede katerih podatkov, med katerimi sistemi in na kakšen način želi hiter, varen in učinkovit tok podatkov.
Predmet javnega naročila mora naročnik opisati jasno, nedvoumno in tako, da imajo ponudniki za pripravo ponudbe zadostne informacije. Na podlagi opisa predmeta javnega naročila se potencialni ponudniki seznanijo s potrebami naročnika in ocenijo, ali lahko sami ponudijo ustrezen predmet z zahtevanimi tehničnimi lastnostmi. Način in obseg opisa predmeta javnega naročila je odvisen od lastnosti in kompleksnosti samega predmeta.
Pred vsebinsko obravnavo tega dela zahtevka za revizijo gre izpostaviti, da je Državna revizijska komisija že v več svojih odločitvah (npr. št. 018-010/2021, 018-062/2020, 018-212/2019, 018-110/2018) pojasnila, da je zahtevek za revizijo namenjen zatrjevanju kršitev, ki naj bi jih v postopku oddaje javnega naročila domnevno storil naročnik, v ta namen pa ZPVPJN od vlagatelja zahteva aktivno vlogo pri navajanju (pravno relevantnih) dejstev in predlaganju (pravno relevantnih) dokazov. Iz drugega odstavka 15. člena ZPVPJN (obvezne sestavine zahtevka za revizijo) izhaja dolžnost vlagatelja, da v zahtevku za revizijo navede očitane kršitve ter dejstva in dokaze, s katerimi se kršitve dokazujejo. Zahteve v zvezi z zatrjevanjem kršitev in dejstev ter njihovega dokazovanja je treba poiskati v Zakonu o pravdnem postopku (Uradni list RS, št. 26/1999 s sprem.; v nadaljevanju: ZPP), katerega določbe se na podlagi prvega odstavka 13. člena ZPVPJN v predrevizijskem, revizijskem in pritožbenem postopku uporabljajo glede vprašanj, ki jih ZPVPJN ne ureja. Razpravno načelo, določeno v 7. členu ZPP, od strank zahteva, da navedejo vsa dejstva, na katera opirajo svoje zahtevke, in predlagajo dokaze, s katerimi se ta dejstva dokazujejo. Dolžnost navesti dejstva in predlagati dokaze, na katere opirajo svoje zahtevke ali s katerimi izpodbijajo navedbe ter dokaze nasprotnika, je strankam naložena tudi v 212. členu ZPP. Iz navedenih določb ZPP izhaja t.i. trditveno-dokazno breme, ki pomeni prvenstveno dolžnost tožnika, da jasno, določno in konkretno navede dejstva, na katera opira tožbeni zahtevek (trditveno breme) in zanje predlaga dokaze, ki naj resničnost zatrjevanih dejstev potrdijo (dokazno breme).
V izhodišču je torej na vlagatelju trditveno in dokazno breme, ki pa ga lahko vlagatelj prevali na naročnika (še)le, ko in če v zahtevku za revizijo navede (in dokaže) dejstva, ki kažejo na nezakonitost naročnikovega ravnanja. V obravnavanem primeru, ko vlagatelj v zahtevku za revizijo zatrjuje, da naročnik ni določil oziroma podal vseh informacij za pripravo ponudbe, to pomeni, da mora vlagatelj v zahtevku za revizijo navesti in dokazati takšno dejstveno podlago, ki bi omogočala ta (pravni) zaključek. Povedano drugače: vlagatelj mora v zahtevku za revizijo navesti (in dokazati) nekaj, kar bi lahko kazalo na to, da naročnik ni zagotovil vseh potrebnih podatkov. Če in ko vlagatelj zmore svoje trditveno-dokazno breme, je naročnik dolžan utemeljiti (ne)obstoj podatkov.
Iz vpogleda v dokumentacijo v zvezi z oddajo javnega naročila izhaja, da je naročnik kot njen sestavni del pripravil dokument »Uporabniške zahteve«, v katerem je na 448 straneh opisal svoje potrebe in zahteve ter opredelil tehnične specifikacije.
Iz vpogleda v navedeni dokument izhaja, da je naročnik med drugim opredelil predmet, pregled trenutnega stanja, številčenje uporabniških zahtev, vsebinske zahteve za podporne procese, tehnične zahteve za temeljne procese, skupne zahteve, vsebinske zahteve za temeljne procese in prenašanje podatkov ERP 356 BC. V okviru uporabniških zahtev je, kot gre slediti naročniku, opredelil tudi arhitekturo sistema (5.4 točka »Uporabniških zahtev«), vmesnike (5.8 točka »Uporabniških zahtev«), varnostne zahteve (6.15 točka »Uporabniških zahtev«), zahteve po zmogljivosti (5.5 točka »Uporabniških zahtev«), uporabniški vmesniki (5.19 točka »Uporabniških zahtev«).
Vlagatelj trditve o nezadostnih informacijah glede arhitekture sistema, integracijskih vmesnikov (API, formati), varnostnih zahtev, zmogljivostih zahtev, primerov uporabniških vmesnikov, podatkovnih modulov ter opisov obstoječih sistemov predvidenih za integracijo ni konkretiziral do te mere, da bi bilo mogoče ugotoviti kaj v zvezi z izpostavljenimi podatki manjka. Ker vlagatelj ni navedel konkretno katere so tiste informacije oziroma podatki, ki bi jih poleg že obsežno navedenih zahtev potreboval za oddajo prijave, teh navedb Državna revizijska komisija na podlagi drugega odstavka 15. člena ZPVPJN, ki določa, da mora vlagatelj v zahtevku za revizijo navesti očitane kršitve ter dejstva in dokaze, s katerimi se kršitve dokazujejo, v povezavi s pravilom o trditvenem in dokaznem bremenu (7. in 212. člen ZPP), ni vsebinsko obravnavala, saj vlagatelj teh navedb ni konkretiziral do te mere, da bi bila možna njihova vsebinska presoja.
Vlagatelj sicer v opredelitvi z dne 13. 5. 2026 bolj konkretno izpostavi podatke in informacije, za katere meni, da niso jasno opredeljeni, vendar Državna revizijska komisija ugotavlja, da vlagatelj na podlagi šestega odstavka 29. člena ZPVPJN v opredelitvi do navedb naročnika in poznejših vlogah ne sme navajati novih kršitev, dejstev in predlagati novih dokazov, razen če dokaže, da jih brez svoje krivde ni mogel predložiti v predrevizijskem postopku. Ker vlagatelj ni zatrjeval, da navedenih podatkov brez svoje krivde ni mogel navesti in konkretizirati v predrevizijskem postopku, je s tem prekludiran.
III. Glede zahtevane odprtokodnosti
Vlagatelj zatrjuje, da naročnik zahteva odprtokodno rešitev in to s točno določeno licenco GNU Affero General Public License 3. Zatrjuje, da odprtokodna rešitev sama po sebi ni nedovoljena, a pojasnjuje, da naročnik z odprtokodno rešitvijo ne pridobi ničesar, saj je samo jedro zaprtokodno. Zatrjuje, da ne obstaja objektivni razlog, da se izločijo vsi ponudniki, ki ponujajo zaprtokodno rešitev ERP, prav tako ima lahko naročnik dostop do izvirne kode in jo pregleduje v kolikor to določi z razpisom ter nadgrajuje in razvija. Navaja, da naročnik nima objektivno utemeljenih razlogov niti za določitev zgolj ene izmed odprtokodnih licenc. Dalje še dodaja, da zahteva po odprtokodnosti ob hkratni uporabi zahtevane platforme ni izvedljiva oz. je vsaj nejasna do te mere, da ponudnikom ne omogoča priprave primerljivih in skladnih ponudb.
Naročnik zatrjuje, da vlagatelj niti ne navaja v čem naj bi bila kršitev naročnika in dodaja, da je dejstvo, da ponudnik ne želi razkriti izvorne kode stvar poslovne odločitve ponudnika. Pojasnjuje, da z varnostnega vidika odprtost kode naročniku v prvi vrsti omogoča varnostne preglede rešitve, prenos pravice do odprte kode in uporabo iste rešitve v okviru drugih naročnikov. Odprtost kode mu zagotavlja neodvisnost od posameznega proizvajalca, kar zmanjša tveganje za dolgoročno odvisnost in omogoča trajno vzdržnost sistema. Izpostavlja tudi prilagodljivost odprtokodnih rešitev. Pojasnjuje, da bi z zaprtokodno rešitvijo stopil v »vendor-lock-in« situacijo in bil v celoti odvisen od volje druge pogodbene stranke. Odprtokodnost naročniku zagotovi varnost, možnost izbire poljubnega ponudnika ob izteku pogodbe, zagotavlja tudi širok nabor možnih ponudnikov. Navaja tudi priporočila Računskega sodišča Republike Slovenije, Slovenska cesta 50, Ljubljana in ministrstva, pristojnega za digitalno preobrazbo, ki usmerjajo naročnike, da ti rešitve, ki so izdelane po naročilu in prilagojene njim, naročajo na način, da imajo možnost dostopa do izvorne kode oziroma preferirajo odprtokodne rešitve in s tem povečujejo konkurenco.
Vlagatelj v vlogi z dne 13. 5. 2026 zatrjuje, da naročnik sam predvideva »vendor-lock-in« situacijo zaradi zaprtokodne platforme. Naročnik ne pojasni izbiro licence za odprtokodno rešitev.
Naročnik je v dokumentaciji v zvezi z oddajo javnega naročila v dokumentu »Uporabniške zahteve« v točki 5.1 REQ-TCH-001 določil:
»Naslov zahteve: Odprtokodna rešitev z licenco AGPLv3
[…]
Opis: Programska rešitev mora biti odprtokodna, kar pomeni, da je izvorna koda javno dostopna ter jo lahko kdorkoli uporablja, pregleduje, spreminja in deli v skladu s pogoji licence. Takšen pristop zagotavlja transparentnost delovanja sistema in krepi zaupanje uporabnikov, saj omogoča vpogled v notranje procese ter izključuje možnost prikritega zbiranja podatkov ali sledenja uporabnikom. Odprtokodnost omogoča, da neodvisni strokovnjaki pregledajo programsko kodo,
odkrijejo morebitne ranljivosti in prispevajo k njihovemu hitrejšemu odpravljanju, kar povečuje varnost in zanesljivost rešitve. Platforma oziroma tehnologija skupaj z vsemi komponentami, moduli, mikrostoritvami in pripadajočo kodo mora biti izdana pod licenco GNU Affero General Public License različice 3 („AGPLv3“). Kopija licence AGPLv3 (povezava do izvirnega besedila).«
Državna revizijska komisija ugotavlja, da vlagatelj glede zahteve po odprtokodni rešitvi zgolj pavšalno navaja, da ne obstajajo objektivni razlogi za izključitev ponudnikov, ki ponujajo zaprtokodne rešitve. Takšna navedba sama po sebi ne zadostuje za utemeljitev navedenega očitka. Vlagatelj namreč ne pojasni, zakaj naj bi bila zahteva po odprtokodnosti določena v nasprotju z določbami ZJN-3, niti ne navede konkretnih dejstev ali okoliščin, iz katerih bi bilo mogoče sklepati, da naročnik za takšno zahtevo nima utemeljenih razlogov. Namesto tega poda le svoje pravno stališče oziroma zaključek. Glede na navedeno Državna revizijska komisija ugotavlja, da očitka v tem delu, na podlagi drugega odstavka 15. člena ZPVPJN, v povezavi s pravilom o trditvenem in dokaznem bremenu (prvi odstavek 7. člena in 212. člena ZPP, ki se uporabljata v revizijskem postopku na podlagi 13. člena ZPVPJN), ni mogoče vsebinsko obravnavati.
Ne glede na navedeno gre vseeno ugotoviti, da iz naročnikove odločitve, s katero je zavrnil zahtevek za revizijo, izhaja, da naročnik odprtokodno rešitev zahteva, ker odprtost kode zagotavlja neodvisnost od posameznega proizvajalca, kar zmanjša tveganje za dolgoročno odvisnost in omogoča trajno vzdržnost sistema. Vlagatelj tako v zahtevku za revizijo ni podal ustrezne trditvene podlage, naročnik pa je na drugi strani navedel konkretne razloge za določitev sporne zahteve. Zato Državna revizijska komisija ne more zaključiti, da je naročnik z določitvijo obravnavane zahteve kršil določbe ZJN-3.
Vlagatelj sicer še dodaja, da zahteva po odprtokodnosti ob hkratni uporabi zahtevane platforme ni izvedljiva oz. je vsaj nejasna do te mere, da ponudnikom ne omogoča priprave primerljivih in skladnih ponudb. Vendar tudi v navedenem delu vlagatelj ne navede razlogov, zaradi katerih rešitev ne bi bila izvedljiva, niti ne konkretizira pomanjkljivosti oziroma nejasnosti, ki naj bi onemogočale oddajo primerljivih in skladnih ponudb, zaradi česar Državna revizijska komisija tudi v tem delu, na podlagi drugega odstavka 15. člena ZPVPJN, v povezavi s pravilom o trditvenem in dokaznem bremenu (prvi odstavek 7. člena in 212. člena ZPP, ki se uporabljata v revizijskem postopku na podlagi 13. člena ZPVPJN), vlagateljevih navedb ni mogla vsebinsko obravnavati.
IV. Glede kratkih rokov za odzivni čas
Vlagatelj zatrjuje, da naročnik določa izjemno kratke roke odzivnosti in zahteva stalno pripravljenost ponudnika za odpravo vseh napak, kar ni sorazmerno z javnim naročilom. Zatrjuje, da so roki nemogoči, določeni zaradi preferiranja velikih podjetij; razvrstitev napak glede na kritičnost ne pove ničesar o obsegu napake ali vrsti napake, zato ponudnik ne more vedeti ali napako lahko objektivno odpravi v tako kratkem času. Prav tako zatrjuje, da naročnik določa visoke pogodbene kazni, ki so vezane na 2-urni interval, s čimer prav tako preferira samo enega ponudnika, kratki roki in visoke pogodbene kazni po mnenju vlagatelja nimajo nobene objektivne podlage v izvedbi javnega naročila.
Naročnik zatrjuje, da zahteva ne pomeni kršitve predpisov javnega naročanja in navaja, da je kritičnost napak določil oziroma definiral. Zatrjuje, da so pogodbene kazni enake za vse in poudarja, da ne gre za pogoj za sodelovanje ali razlog za izključitev, pač pa pogodbeno določilo, ki bo zavezujoče za izbranega ponudnika, ki bo prejel v izvedbo naročilo visoke vrednosti.
Vlagatelj v vlogi z dne 13. 5. 2026 zatrjuje, da naročnik ni izkazal zakaj so tako stroge kazni v povezavi s predmetnim javnim naročilom, in dodaja da pogodbena določila naročniku omogočajo, da izven javnega naročila zagotavlja preferiranemu ponudniku, da lahko sprejme takšne pogoje, vsi ostali, ki si upajo prijaviti na javno naročilo pa bodo strogo kaznovani.
Naročnik je v dokumentu »Uporabniške zahteve« v točki 2.11.3 »Kritičnost napak in odzivni časi« določil:
- »Kritična napaka: popolna nedosegljivost sistema oz. njegova ključna jedra (npr. sesutje podatkov, nedelovanje strežniške aplikacije). Odzivni čas: do 1 ure, znotraj delovnega časa naročnika.
- Manj kritična napaka: delni izpad, sistem se pogojno uporablja. Odzivni čas: do 3 ure znotraj delovnega časa.
- Nekritična napaka: delovni proces ni neposredno moten, lahko pa dolgoročno vpliva. Odzivni čas: do 8 ur znotraj delovnega časa.
Izvajalec mora ob prijavi napake začeti z njenim odpravljanjem najkasneje ob izteku odzivnega časa in nadaljevati kontinuirano do odprave, ne glede na to ali se rok izteče izven delovnega časa naročnika. O napredku mora redno obveščati naročnika.
Delovni čas naročnika je objavljen na https://snaga-mb.si/kontakti/, upoštevajoč vseh navedenih 14 enot.
Roki za odpravo napake (vzpostavitev delujočega stanja) so:
- kritična napaka: 4 ure od preteka odzivnega časa
- manj kritična napaka: 8 ur od preteka odzivnega časa
- nekritična napaka: 2 dni od preteka odzivnega časa«.
Državna revizijska komisija ugotavlja, da je naročnik določil kritičnost napak s pojasnilom za kakšen obseg napake gre in odzivni čas, ki ga je določil na način, da velja znotraj delovnega časa naročnika. Vlagatelj zgolj pavšalno zatrjuje, da so odzivni roki kratki, nemogoči in neživljenjski, ter da naj bi favorizirali večja podjetja in izključevali manjše ponudnike. Vlagatelj ne navede niti ne pojasni, zakaj naj bi bil posamezen odzivni rok, ki je dejansko določen zgolj znotraj delovnega časa naročnika, objektivno neizvedljiv, ne navede, kakšni odzivni roki so po njegovem mnenju običajni ali sorazmerni za posamezno navedene napake, niti ne konkretizira, zakaj naj bi manjši gospodarski subjekti teh zahtev ne mogli izpolniti. Prav tako ne predloži nobenih dokazov, iz katerih bi bilo mogoče ugotoviti, da zahteve dejansko omejujejo konkurenco ali neupravičeno favorizirajo določeno skupino ponudnikov. Vlagatelj tako ni navedel konkretnih pravno relevantnih dejstev, ki bi omogočala presojo zatrjevanih kršitev, zato Državna revizijska komisija ugotavlja, da njegovim pavšalnim navedbam ni mogoče slediti.
V kolikor gre navedbe vlagatelja s katerimi zatrjuje, da kritičnost napak ničesar ne pove o obsegu in vrsti napake razumeti kot pomanjkljivo ali nejasno opredelitev kritičnosti napak, Državna revizijska komisija ugotavlja, da vlagatelj niti teh navedb ni konkretiziral do te mere, da bi bila možna njihova vsebinska presoja. Kot izhaja iz vpogleda v citirani del dokumenta »Uporabniške zahteve« je naročnik kritičnost napak opredelil v 2.11.3 točki, in sicer glede na obseg napak in delovanje sistema, vlagatelj pa ne konkretizira podatkov, ki bi jih o obsegu in vrsti še potreboval, zato Državna revizijska komisija revizijskih navedb v tem delu, na podlagi drugega odstavka 15. člena ZPVPJN, v povezavi s pravilom o trditvenem in dokaznem bremenu (prvi odstavek 7. člena in 212. člena ZPP, ki se uporabljata v revizijskem postopku na podlagi 13. člena ZPVPJN), ni vsebinsko obravnavala.
V zvezi z revizijskimi navedbami glede pogodbenih kazni, Državna revizijska komisija ugotavlja, da se le-te ne nanašajo na fazo postopka oddaje javnega naročila, temveč na fazo izvajanja predmeta javnega naročila. Pri čemer Državna revizijska komisija ugotavlja, da domnevno sporne določbe v zvezi z s pogodbeno kaznijo vlagatelja ne omejujejo in mu ne preprečujejo sodelovanja v postopku oddaje javnega naročila. Vlagatelj v zvezi z njimi ne bo imel obveznosti, ki bi se nanašale na pripravo ponudbe, saj gre za pogodbena določila, ki se bodo uporabila šele po zaključenem postopku oddaje javnega naročila in po sklenitvi pogodbe, pa še to le v hipotetičnem primeru, in sicer, če vlagatelj (v kolikor bo seveda izbran) ne bo ravnal v skladu s pogodbenimi obveznostmi. Kot je zapisala Državna revizijska komisija že v svojih številnih odločitvah, je odločitev o tem, ali bodo sodelovali v postopku oddaje javnega naročila in v primeru predložitve najugodnejše ponudbe sklenili pogodbeno razmerje v vsebini, kot jo je določil naročnik, lastna odločitev vsakega gospodarskega subjekta, pri čemer je potrebno poudariti, da so vsi gospodarski subjekti v enakem položaju, saj sporna pogodbena določila enako zavezujejo vse ponudnike. Vsi ponudniki so namreč jasno in vnaprej seznanjeni, kako namerava ravnati naročnik v primeru, če bodo kršili pogodbena določila. Ali in kako bodo posamezni gospodarski subjekti takšno tveganje vključil v ponudbeno ceno, pa je lastna odločitev vsakega izmed njih. Poleg tega gre ugotoviti, da vlagatelj ne bo omejen pri morebitnem uveljavljanju pravnega varstva v fazi izvajanja pogodbe. Vlagatelj bo namreč lahko v fazi izvajanja pogodbe, ob nastopu hipotetične situacije, v kateri bo naročnik zahteval plačilo pogodbene kazni, ugovarjal njeni (nesorazmerni) višini, o takem sporu pa bo, če bo do njega prišlo, odločalo sodišče.
V. Glede nesorazmernih pogojev
Vlagatelj zatrjuje, da naročnik zahteva reference informacijskih sistemov, ki pokrivajo proizvodni proces, pri čemer je naročnik javna gospodarska služba, katere dejavnost ne zajema proizvodnje, referenca pa tako ni povezana s predmetnim javnim naročilom. Zatrjuje, da naročnik ni izkazal niti zakaj zahteva reference v višini 400.000,00 EUR ali 500.000,00 EUR in zakaj ni primerna višina 50.000,00 EUR. Sam omogoči, da se lahko nekatere reference seštevajo s čimer izkazuje, da tako visok znesek reference ni potreben in izkazovanje takšne sposobnosti ni v povezavi s predmetnim javnim naročilom. Navaja še, da ni izkazano, zakaj se več referenc pri enem pogoju lahko seštevajo pri drugem pa ne in zakaj ni ustrezen seštevek 10 referenc v referenčnem obdobju, več manjših, vsebinsko enakovrednih projektov izkazuje enako ali celo večjo usposobljenost ponudnikov. Zatrjuje tudi, da naročnik kot ustrezne določa le reference na platformi, ki je predmet implementacije, čeprav so lahko ponudniki, ki ne nudijo točno določenega produkta enakovredno usposobljeni ali celo bolj, omejevalna referenca pa ni v povezavi s predmetnim javnim naročilom in implementacijo ERP sistema.
Naročnik zatrjuje, da vlagatelj v zahtevku za revizijo ni izkazal kršitev naročnika. Navaja, da izvedba več manjših projektov na zagotavlja, da je ponudnik sposoben izvesti en večji projekt, saj večji projekt terja večjo organizacijsko, kadrovsko in finančno sposobnost. Pojasnjuje, da naroča rešitev na platformi Microsoft Business Central, kar pomeni, da je sorazmerna in s predmetnim javnim naročilom povezana ravno referenca, ki izkazuje uspešen projekt s točno določenim predmetom.
Vlagatelj v vlogi z dne 13. 5. 2026 zatrjuje, da če je podjetje izvedlo več manjših projektov ne pomeni, da nima ustreznega števila kadra ali primerne organizacije. Dodaja, da sklicevanje na finančno zavarovanje ni relevantno. Navaja, da naročnik ne pojasni zakaj v višini referenc ne smejo biti zajete licence, čeprav zahteva točno določeno platformo, kjer je implementacija pogosto in logično v projektih izvedena z licencami. Naročnik tudi ne pojasni zakaj zahteva reference, ki pokrivajo proizvodni proces. Prav tako vztraja, da so ponudniki ki so izvedli večje projekte na drugih platformah enako sposobni izvesti projekt na platformi, ki jo zahteva naročnik.
Pogoje za sodelovanje naročnik določi v skladu s 76. členom ZJN-3. Ta v prvem odstavku določa, da lahko naročnik določi objektivna pravila in pogoje za sodelovanje, ki se lahko nanašajo na a) ustreznost za opravljanje poklicne dejavnosti, b) ekonomski in finančni položaj in c) tehnično in strokovno sposobnost.
V skladu z drugim odstavkom 76. člena ZJN-3 lahko naročnik gospodarskim subjektom kot zahtevo za sodelovanje naloži pogoje, ki so določeni v 76. členu. Naročnik v postopek javnega naročanja vključi le tiste zahteve, ki so potrebne za zagotovitev, da ima ponudnik ustrezne pravne in finančne zmogljivosti ter tehnične in strokovne sposobnosti za izvedbo javnega naročila, ki se oddaja. Vse zahteve morajo biti povezane in sorazmerne s predmetom javnega naročila. Glede tehnične in strokovne sposobnosti deseti odstavek 76. člena ZJN-3 določa, da lahko naročnik določi zahteve, s katerimi zagotovi, da imajo gospodarski subjekti potrebne človeške in tehnične vire ter izkušnje za izvajanje javnega naročila v skladu z ustreznim standardom kakovosti. Naročnik lahko zahteva zlasti, da imajo gospodarski subjekti zadostne izkušnje, ki jih izkažejo z ustreznimi referencami iz prejšnjih naročil. Naročnik lahko domneva, da gospodarski subjekt nima zahtevanih strokovnih sposobnosti, če pri gospodarskem subjektu zasledi nasprotje interesov, ki bi lahko negativno vplivalo na izvedbo javnega naročila.
Dokazila za ugotavljanje sposobnosti gospodarskih subjektov za sodelovanje v javnem naročanju ZJN-3 ureja v 77. členu. Skladno z drugim odstavkom tega člena lahko naročnik zahteva le dokazila, določena v tem in v 78. členu ZJN-3. Tehnične sposobnosti lahko gospodarski subjekt glede na vrsto, količino ali pomen ter uporabo gradenj, blaga ali storitev izkaže na enega ali več načinov iz osmega odstavka 77. člena ZJN-3 – npr. s seznamom najpomembnejših dobav blaga ali opravljenih storitev v zadnjih treh letih skupaj z zneski, datumi in navedbo javnih ali zasebnih naročnikov. Zaradi zagotovitve ustrezne ravni konkurence lahko naročnik po potrebi navede, da bo upošteval dokazila o ustreznih dobavah blaga ali opravljenih storitvah izpred več kot treh let; (točka b), z navedbo tehničnega osebja ali tehničnih organov, ki bodo sodelovali pri izvedbi javnega naročila, zlasti tistih, ki so odgovorni za nadzor kakovosti, v primeru javnih naročil gradenj pa tistih, od katerih lahko izvajalec zahteva, da izvedejo gradnjo, in sicer ne glede na to, ali so zaposleni pri gospodarskem subjektu ali ne (točka c), z dokazilom o izobrazbi in strokovni usposobljenosti izvajalca storitev ali gradenj ali vodstvenih delavcev podjetja pod pogojem, da ne štejejo kot merilo za oddajo javnega naročila (točka f) itd.
ZJN-3 opredeljuje le osnovna izhodišča za določanje pogojev za priznanje tehnične in strokovne sposobnosti ter posamezna dokazila, ne določa pa vsebinskih zahtev. Naročnik je tisti, ki mora v vsakem konkretnem postopku oddaje javnega naročila določiti posamezne vsebinske zahteve oziroma referenčne kriterije (vsebinske, vrednostne, časovne, ipd.), ki jih mora izpolnjevati referenčni posel, da lahko ponudnik z izkazovanjem njegove uspešne izvedbe dokaže sposobnost za izvedbo naročila. Pri oblikovanju referenčnih kriterijev mora naročnik upoštevati, da morajo biti posamezni referenčni kriteriji sorazmerni in povezani s predmetom naročila. Z drugimi besedami to pomeni tudi, da mora naročnik zahteve za referenčni posel opisati na način, da bo ta obsegal storitev oziroma gradnjo, primerljivo predmetu javnega naročila. Referenca je namreč po svoji naravi dokazilo, da je ponudnik sposoben izvesti določeno javno naročilo v zahtevanem obsegu in kvaliteti, saj z njo dokazuje, da je istovrstno storitev oziroma gradnjo (ki jo je po obsegu, zahtevnosti in kvaliteti mogoče primerjati s predmetom naročila) v preteklosti že uspešno izvedel. Naročnik lahko le na podlagi dokazila, da je ponudnik (vsaj) enkrat že uspešno izvedel primerljivo naročilo, utemeljeno sklepa, da ima tak ponudnik ustrezno znanje, izkušnje in kapacitete, potrebne za izvedbo javnega naročila, ki ga razpisuje. Vsekakor pa je glede na načelo sorazmernosti treba zavzeti stališče, da morata biti predmet referenčnega posla in predmet javnega naročila enaka oziroma podobna do te mere, da je na podlagi potrdila o uspešni izvedbi referenčnega posla mogoče utemeljeno sklepati, da ima ponudnik ustrezno znanje in izkušnje za izvedbo predmeta naročila. Naročnik torej glede na namen reference referenčne kriterije določi na način, da z njimi omeji izkazovanje reference na primerljive storitve. S tem seveda nujno omeji
konkurenco, vprašanje pa je, ali to stori na sorazmeren in objektivno utemeljen način.
Naročnik je v dokumentaciji v zvezi z oddajo javnega naročila v 7. poglavju »Preverjanje sposobnosti« v okviru pogojev za sodelovanje med drugim v točki C določil:
»Ponudnik v zadnjih petih (5) letih pred rokom za prejem ponudb, uspešno razvil in/ali vzdrževal vsaj en (1) informacijski sistem zasnovan na platformi, ki je predmet implementacije, v skupni realizirani vrednosti najmanj 400.000,00 EUR brez DDV. Referenca se lahko nanaša izključno na storitve izvajalca, ki obsegajo razvoj in/ali vzdrževanje programske opreme na platformi, ki je predmet implementacije (načrtovanje, razvoj, testiranje, postavitev, uvedba v uporabo in podpora) brez vrednosti licenc, strojne ali sistemske programske opreme, najemnin ali drugih podobnih storitev in je bila ali je še v produkcijski uporabi.«
in
»Ponudnik v zadnjih petih (5) letih pred rokom za prejem ponudb, uspešno razvil in/ali vzdrževal enega ali več informacijskih sistemov, ki pokriva/jo proizvodni proces (funkcije poljubnega proizvodnega procesa in skladiščnega poslovanja), v skupni realizirani vrednosti najmanj 500.000,00 EUR brez DDV. Pogoj lahko ponudnik izkazuje s skupaj največ petimi referenčnimi posli (vrednosti referenc se seštevajo, ostale referenčne zahteve mora izpolnjevati vsaka izmed predloženih referenc). Posamezna referenca se lahko nanaša izključno na storitve izvajalca, ki obsegajo razvoj in/ali vzdrževanje programske opreme na zahtevanem področju pokrivanja – proizvodni proces (načrtovanje, razvoj, testiranje, postavitev, uvedba v uporabo in podpora) brez vrednosti licenc, strojne ali sistemske programske opreme, najemnin ali drugih podobnih storitev in je bila ali je še v produkcijski uporabi.«
Vlagatelj kot sporno izpostavlja vrednost referenc, referenco, ki zahteva proizvodni proces ter zahtevo, da so ustrezne le reference na platformi, ki je predmet implementacije.
Kot navedeno je referenca je po svoji naravi dokazilo o tem, da je ponudnik sposoben izvesti javno naročilo v zahtevanem obsegu in kvaliteti, saj z njo dokazuje, da je v preteklosti istovrstna oziroma primerljiva dela že uspešno opravil.
Pri predmetnem javnem naročilu gre za uvedbo, prilagoditve in integracijo krovnega informacijskega sistema ERP Microsoft Dynamics 365 Business Central. Iz spornih referenčnih pogojev iz C) točke 7. poglavja dokumentacije v zvezi z oddajo javnega naročila, izhaja, da je naročnik zahteval, da ponudniki izkažejo referenčni posel, uspešno razvitega in/ali vzdrževanega informacijskega sistema zasnovanega na platformi, ki je predmet implementacije, v skupni realizirani vrednosti najmanj 400.000,00 EUR brez DDV in razvitega in/ali vzdrževanega enega ali več informacijskih sistemov, ki pokriva/jo proizvodni proces (funkcije poljubnega proizvodnega procesa in skladiščnega poslovanja), v skupni realizirani vrednosti najmanj 500.000,00 EUR brez DDV.
Državna revizijska komisija ugotavlja, da vlagatelj zatrjuje nesorazmernost referenčnega pogoja predvsem z navedbami, da naročnik ni pojasnil, zakaj zahteva reference v določeni vrednosti in zakaj ne bi zadostovale reference bistveno nižjih vrednosti ter zakaj pri posameznih referenčnih pogojih dopušča seštevanje referenc, pri drugih pa ne. Iz vlagateljevih navedb izhaja stališče, da več manjših, vsebinsko primerljivih projektov izkazuje enako stopnjo usposobljenosti kot izvedba posameznega projekta zahtevane vrednosti. Vendar navedbam vlagatelja ni mogoče slediti. Iz pojasnil naročnika izhaja, da je sporni referenčni pogoj določil z namenom preverjanja sposobnosti gospodarskega subjekta za izvedbo naročila primerljivega obsega in zahtevnosti, pri čemer je pojasnil, da izvedba projekta določene velikosti terja in izkazuje tudi ustrezne organizacijske, kadrovske in finančne zmogljivosti. Državna revizijska komisija pritrjuje naročniku, da izvedba več manjših projektov sama po sebi še ne omogoča zaključka, da je gospodarski subjekt sposoben izvesti tudi posamezen projekt večjega obsega, prav tako tega ni izkazal niti vlagatelj. Izvedba večjega projekta namreč praviloma zahteva usklajevanje večjega števila aktivnosti, obvladovanje večjih pogodbenih in organizacijskih tveganj, koordinacijo večjega števila sodelujočih itd. Takšnih sposobnosti ni nujno mogoče preveriti zgolj na podlagi več ločenih projektov manjšega obsega, četudi so ti po vsebini primerljivi. Vlagatelj sicer zatrjuje, da bi naročnik lahko določil tudi nižji referenčni prag vendar z navedenim ne izkaže nesorazmernosti spornega pogoja. Dejstvo, da bi bilo mogoče določiti tudi milejši pogoj, samo po sebi še ne pomeni, da sta obravnavana pogoja nesorazmerna oziroma v nasprotju z določili ZJN-3. Naročnik je namreč v konkretnem primeru upoštevaje trditveno podlago vlagatelja uspel izkazati razumno povezavo med zahtevano vrednostjo referenčnih pogojev in predmetom naročila (oziroma ocenjeno vrednostjo predmetnega naročila, ki je celo bistveno višja od zahtevanih vrednosti referenčnih poslov). Državna revizijska komisija ugotavlja, da so neutemeljene tudi navedbe vlagatelja, da naj bi bila zahteva arbitrarna zgolj zato, ker je naročnik pri enem referenčnem pogoju dopustil seštevanje referenc, pri drugem pa ne. Posamezni referenčni pogoji lahko zasledujejo različne cilje preverjanja tehnične in strokovne sposobnosti, zato že sama različna ureditev načina njihovega izkazovanja ne pomeni njihove nesorazmernosti. Državna revizijska komisija dalje ugotavlja, da vlagatelj ne konkretizira razlogov zaradi katerih bi bilo mogoče šteti, da delovanje naročnika ni primerljivo proizvodnemu procesu, zaradi česar ob upoštevanju že navedenega pravila o trditveno dokaznem bremenu tudi ni mogoče ugotoviti, da je zahteva, ki določa, da je ponudnik uspešno razvil in/ali vzdrževal enega ali več informacijskih sistemov, ki pokriva/jo proizvodni proces (funkcije poljubnega proizvodnega procesa in skladiščnega poslovanja) nesorazmerna oziroma da ni povezana s predmetom javnega naročila, posledično tudi ni mogoče ugotoviti kršitev 76. člena ZJN-3.
Iz vlagateljevih navedb prav tako izhaja, da bi morali biti kot ustrezni priznani tudi ponudniki z referencami na drugih ERP platformah, saj naj bi bili lahko enakovredno ali celo bolje usposobljeni za izvedbo naročila, omejevalna referenca, ki kot ustrezne določa le reference na platformi, ki je predmet naročila pa po mnenju vlagatelja ni v povezavi s predmetnim javnim naročilom in implementacijo ERP sistema. Državna revizijska komisija pojasnjuje, da referenčnega pogoja ni mogoče presojati ločeno od predmeta javnega naročila in tehničnih zahtev, ki jih zasleduje, kot navedeno je referenca po svoji naravi dokazilo o tem, da je ponudnik sposoben izvesti javno naročilo v zahtevanem obsegu in kvaliteti. V konkretnem primeru predmet naročila ni implementacija katerega koli ERP sistema, temveč implementacija ERP rešitve na konkretni platformi. Kot je Državna revizijska komisija ugotovila že v I. točki predmetne obrazložitve je naročnik za uporabo navedene platforme navedel objektivno utemeljene razloge, povezane z poenotenjem informacijskega okolja več podjetij znotraj holdinga vključno z naročnikom. Ker je Državna revizijska komisija ugotovila, da je zahteva glede implementacije konkretne platforme objektivno opravičljiva in povezana s predmetom naročila, je dopustno tudi preverjanje izkušenj ponudnikov prav v zvezi s to platformo. Referenčni pogoj namreč služi preverjanju tehnične in strokovne sposobnosti ponudnikov za izvedbo predmeta naročila. Izkušnje z implementacijo drugih ERP rešitev zato niso nujno primerljive z izkušnjami pri implementaciji platforme, ki je predmet tega naročila. Ker se torej zahtevana referenca nanaša na izvedbo projektov na isti platformi, kot je predmet implementacije v okviru tega javnega naročila, Državna revizijska komisija ugotavlja, da je sporni referenčni pogoj neposredno povezan s predmetom javnega naročila, objektivno opravičljiv glede na naročnikove potrebe ter sorazmeren predmetu naročila. Posledično so vlagateljeve navedbe v tem delu neutemeljene, naročniku pa ni mogoče očitati kršitve 76. člena ZJN-3.
Ob upoštevanju navedenega Državna revizijska komisija ugotavlja, da vlagatelj ni uspel izkazati, da sporni referenčni pogoji tako glede zahtevane vrednosti, reference, ki zahteva izkušnje pri projektu proizvodnega procesa kot tudi zahtevo, da so ustrezne le reference na platformi, ki je predmet implementacije torej Microsoft Dynamics 365 Business Central presega to, kar je potrebno za preverjanje usposobljenosti gospodarskih subjektov za izvedbo predmetnega javnega naročila. Posledično naročniku ni mogoče očitati kršitev 76. člena ZJN-3 v povezavi s 5. in 8. členom ZJN-3.
Vlagatelj dalje zatrjuje, da tudi kadrovske zahteve o kar sedmih visoko kvalificiranih kadrih z dolgotrajnimi izkušnjami niso sorazmerne predmetu javnega naročila, naročnik niti nima kompetenčnega kadra, da bi bila smiselna in učinkovita komunikacija z zahtevanimi kadri. V majhnih podjetjih so zahteve naročnika združene v eni ali dveh osebah in po mnenju vlagatelja ni potrebe, da bi bile funkcije razdeljene med sedem oseb. Dalje zatrjuje, da naročnik neutemeljeno izključuje določene licence, ki jih tudi našteje.
Naročnik pojasnjuje, da je predmetno naročilo velikega obsega, zato je jasno da zahteva več visoko usposobljenih strokovnjakov, vlagatelj pa ni izkazal, da navedeni kadri niso potrebni, po mnenju naročnika gre za različne specializirane vloge (vodje projekta, analitike, programerje,…). Pojasnjuje, da so razlike v podjetjih naravna danost, manjša podjetja pa se lahko povezujejo. Ker vlagatelj ni podal konkretnejših argumentov, zakaj kader ni potreben, naročnik zatrjuje, da ne more in ni dolžan podrobneje utemeljevati zahteve o posameznem kadru. Meni tudi, da je jasno da so osnovni certifikati manj kot napredni, vlagatelj pa niti ni izkazal, da so certifikati, ki jih našteva primerni za izkazovanje določene ravni usposobljenosti vodje projekta glede na veliko zahtevnost projekta.
Naročnik je v dokumentaciji v zvezi z oddajo javnega naročila v 7. poglavju »Preverjanje sposobnosti« v okviru pogojev za sodelovanje med drugim v točki C pod zaporedno št. 3 določil:
»Ponudnik mora za izvedbo predmetnega javnega naročila zagotoviti najmanj sedem (7) različnih strokovnjakov, in sicer.
a) enega (1) vodjo projekta, ki izpolnjuje naslednje pogoje:
- dosežena izobrazba na ravni 7 SOK oz. 6 EOK;
- vsaj pet (5) let delovnih izkušenj s področja vodenja projektov;
- znanje slovenskega jezika na ravni najmanj B2 po Skupnem evropskem referenčnem okviru za jezike (SEFR), za namene neposredne komunikacije z naročnikom;
- ima veljaven certifikat s področja vodenja projektov (PMP, IPMA Level B ali C, Prince 2 Practitioner ali po zahtevanih izkušnjah in težavnosti certifikacije primerljiv – npr. IPMA Level A, PRINCE 2 Foundation ali Certified Scrum Master (CSM) niso primerljivi certifikati – dokazno breme dokazovanja primerljivosti je na ponudniku);
- je v vlogi vodje projekta (ali v drugače poimenovani, a vsebinsko enakovredni vlogi) sodeloval pri vsaj enem (1) referenčnem projektu, ki ustreza pogoju pod točko 7.C.1. Tehnična in strokovna sposobnost (Reference ponudnika), ne glede na vrednost reference.
b) enega (1) strokovnjaka s področja razvoja informacijskih sistemov (arhitekt rešitve), ki izpolnjuje naslednje pogoje:
- dosežena izobrazba na ravni 7 SOK oz. 6 EOK;
- vsaj tri (3) leta delovnih izkušenj s področja razvoja informacijskih sistemov;
- je v vlogi arhitekta rešitve (ali v drugače poimenovani, a vsebinsko enakovredni vlogi) sodeloval pri vsaj enem (1) referenčnem projektu, ki ustreza pogoju pod točko 7.C.1. Tehnična in strokovna sposobnost (Reference ponudnika), ne glede na vrednost reference.
c) enega (1) analitika, ki izpolnjuje naslednje pogoje:
- dosežena izobrazba na ravni 7 SOK oz. 6 EOK;
- vsaj tri (3) leta delovnih izkušenj kot analitik informacijskih sistemov;
- znanje slovenskega jezika na ravni najmanj B2 po Skupnem evropskem referenčnem okviru za jezike (SEFR), za namene neposredne komunikacije z naročnikom;
- je v vlogi analitika (ali v drugače poimenovani, a vsebinsko enakovredni vlogi, npr. konzultant na projektu, ki je zadolžen za vsebinsko analizo) sodeloval pri vsaj enem (1) referenčnem projektu, ki ustreza pogoju pod točko 7.C.1. Tehnična in strokovna sposobnost (Reference ponudnika), ne glede na vrednost reference.
d) enega (1) analitika, ki izpolnjuje naslednje pogoje:
- dosežena izobrazba na ravni 7 SOK oz. 6 EOK;
- vsaj tri (3) leta delovnih izkušenj kot analitik informacijskih sistemov;
- znanje slovenskega jezika na ravni najmanj B2 po Skupnem evropskem referenčnem
okviru za jezike (SEFR), za namene neposredne komunikacije z naročnikom;
- je v vlogi analitika (ali v drugače poimenovani, a vsebinsko enakovredni vlogi, npr. konzultant na projektu, ki je zadolžen za vsebinsko analizo) sodeloval pri vsaj enem (1) referenčnem projektu, ki ustreza pogoju pod točko 7.C.2. Tehnična in strokovna sposobnost (Reference ponudnika za fazo 2), ne glede na vrednost reference.
e) tri (3) programerje, ki izpolnjujejo naslednje pogoje:
- vsak vsaj dve (2) leti delovnih izkušenj kot programer;
-vsak od nominiranih strokovnjakov je v vlogi programerja (ali v drugače poimenovani, a vsebinsko enakovredni vlogi) sodeloval pri vsaj enem (1) referenčnem projektu, ki ustreza pogoju pod točko 7.C.1. ali 7.C.2. Tehnična in strokovna sposobnost (Reference ponudnika), ne glede na vrednost reference.«
Vlagatelj torej kot sporno izpostavlja, da naročnik zahteva kar sedem visoko kvalificiranih kadrov, kot sporno izpostavlja tudi zahteve izkušenj s platformo, ki je predmet implementacije in zatrjuje, da naročnik neutemeljeno izloča določene certifikate kadra (IPMA Level A, Prince 2 Fundation ali Certified Scrum Master CSM).
Državna revizijska komisija ugotavlja, da vlagatelj zatrjuje nesorazmernost kadrovskih pogojev predvsem z navedbami, da naročnik zahteva preveliko število strokovnjakov ter da so posamezne funkcije v manjših gospodarskih subjektih pogosto združene v okviru ene ali dveh oseb. Kot izhaja iz citiranega dela dokumentacije v zvezi z oddajo javnega naročila je naročnik za posamezne kadre opredelil konkretne vloge (vodja projekta, strokovnjak za področje razvoja informacijskih sistemov, analitike, programerje) in pojasnil, da gre za medsebojno različna strokovna področja, ki jih je glede na obseg in zahtevnost predmeta javnega naročila potrebno zagotoviti za uspešno izvedbo naročila, pri tem pa ne omejuje ponudnikov, da dodajo tudi dodaten kader. Vlagatelj po drugi strani ni navedel, katere izmed zahtevanih vlog naj bi bile glede na predmet naročila nepotrebne, katerih kompetenc naj naročnik ne bi potreboval oziroma katere funkcije bi bilo mogoče združiti. Prav tako ni pojasnil, zakaj bi bilo mogoče posamezne naloge opravljati z manjšim številom strokovnjakov, niti ni navedel okoliščin, iz katerih bi izhajalo, da naročnik za izvedbo predmeta javnega naročila objektivno ne potrebuje vseh zahtevanih kadrov s tako opredeljenimi znanji in izkušnjami. Zgolj navedba, da manjši gospodarski subjekti določene naloge opravljajo z manjšim številom zaposlenih oziroma da posamezne funkcije združujejo v okviru iste osebe, sama po sebi še ne izkazuje nesorazmernosti spornega pogoja glede na predmet in obseg konkretnega javnega naročila. Razlike v organizaciji poslovanja posameznih gospodarskih subjektov ne vplivajo na upravičenje naročnika, da glede na predmet javnega naročila določi raven tehnične in strokovne sposobnosti, ki jo šteje za potrebno za uspešno izvedbo naročila. Ker vlagatelj svojih očitkov ni konkretiziral na način, da bi izpodbijal posamezne kadrovske zahteve ali pojasnil njihovo domnevno nepovezanost s predmetom naročila oziroma nesorazmernost, Državna revizijska komisija ugotavlja, da mu ni mogoče slediti, da so zahteve določene v nasprotju z določbo 76. člena ZJN-3 v povezavi z 8. členom ZJN-3.
Tudi v zvezi z revizijskimi navedbami, da naročnik neutemeljeno izključuje certifikate: IPMA Level A, Prince 2 Fundation ali Certified Scrum Master CSM, Državna revizijska komisija ugotavlja, da vlagatelj ne pojasni, katere kompetence oziroma raven strokovne usposobljenosti navedeni certifikati izkazujejo in zakaj naj bi bili z vidika predmeta javnega naročila primerljivi zahtevanim certifikatom oziroma ali izkazujejo enako raven strokovnega znanja in izkušenj, kot jo zahteva naročnik. Naročnik je pojasnil, da zahtevani certifikat izkazuje napredno raven usposobljenosti, ki jo glede na zahtevnost predmeta javnega naročila šteje za potrebno. Tem navedbam vlagatelj ni vsebinsko nasprotoval, temveč je zgolj zatrjeval, da bi morali biti priznani tudi drugi certifikati oziroma da so usposobljeni za izvedbo javnega naročila tudi strokovnjaki brez teh certifikatov. Ker vlagatelj ni navedel dejstev in okoliščin, na podlagi katerih bi bilo mogoče ugotoviti primerljivost zatrjevanih certifikatov z zahtevanim certifikatom, Državna revizijska komisija ugotavlja, da ni uspel izkazati, da je naročnik sporni pogoj oblikoval v nasprotju z določbam ZJN-3.
Vlagatelj pavšalno zatrjuje, da zahteva glede izkušenj kadra na sistemih Microsoft Dynamics 365 Business Central ni utemeljena. Kot je Državna revizijska komisija že v okviru presoje referenčnih pogojev gospodarskega subjekta navedla, izkušenj, ki se nanašajo na kader ni mogoče presojati ločeno od predmeta javnega naročila in tehničnih zahtev, ki jih zasleduje, referenca oziroma izkušnje pa so po svoji naravi dokazilo o tem, da je zahtevan kader oziroma strokovnjak sposoben izvesti javno naročilo v zahtevanem obsegu in kvaliteti. Ker je Državna revizijska komisija ugotovila, da je zahteva glede implementacije konkretne platforme objektivno opravičljiva in povezana s predmetom naročila, je dopustno tudi preverjanje izkušenj ponudnikov in kadra prav v zvezi s to platformo. Zahtevane izkušnje namreč služijo preverjanju strokovne sposobnosti kadra za izvedbo nalog predmeta naročila, vlagatelj pa niti ni zatrjeval, da temu ne bi bilo tako oziroma, da je mogoče izkušnje izkazati tudi z izvajanjem poslov na primerljivih platformah. Enako kot je Državna revizijska komisija že ugotovila v okviru presoje referenčnih pogojev za gospodarski subjekt, ugotavlja tudi v zvezi z zahtevanimi izkušnjami kadra, da je zahteva povezana s predmetom javnega naročila, objektivno opravičljiva glede na naročnikove potrebe ter sorazmerna predmetu naročila. Posledično so pavšalne navedbe vlagatelja o kršitvi določb 76. člena ZJN-3 in 8. člena ZJN-3 tudi v tem delu neutemeljene.
Vlagatelj kot sporno izpostavlja tudi zahtevo, da morajo imeti ponudniki certifikat Microsoft Gold Enterprise Resource Planning in zatrjuje, da naročnik z navedeno zahtevo diskriminira ponudnike.
Državna revizijska komisija ugotavlja, da vlagatelj tudi v zvezi z zahtevanim potrdilom oziroma certifikatom Microsoft Gold Enterprise Resource Planning svojih navedb ni ustrezno konkretiziral. Ne pojasni namreč zakaj naj bi bil sporni certifikat nepovezan s predmetom javnega naročila, niti ne navede okoliščin, iz katerih bi bilo mogoče sklepati, da zahtevani certifikat ne izkazuje sposobnosti, relevantnih za izvedbo predmeta javnega naročila. Prav tako ne zatrjuje, da bi bilo mogoče isti namen doseči z drugimi, enakovrednimi dokazili. Zgolj splošna navedba, da sporni pogoj omejuje konkurenco oziroma diskriminira ponudnike, brez navedbe dejstev in okoliščin, ki bi takšen zaključek utemeljevale, ne zadostuje za ugotovitev kršitve določb ZJN-3. Ker vlagatelj ni zadostil trditveno dokaznemu bremenu kot izhaja iz 7. in 212. člena ZPP in ni navedel dejstev, ki bi omogočal presojo zatrjevane diskriminatornosti sporne zahteve, Državna revizijska komisija njegovih navedb ne more vsebinsko obravnavati.
VI. Sklepno
Državna revizijska komisija upoštevaje predhodno navedeno ugotavlja, da ni mogoče slediti očitkom vlagatelja, da je naročnik z določitvijo tehničnih specifikacij (implementacija ERP rešitve na zahtevani platformi, splošnih tehničnih specifikacij, odprtokodnost) in pogojev za sodelovanje (referenčnih zahtev, kadra in zahtev vezanih na določene strokovnjake, zahtevanih certifikatov) kršil določbe ZJN-3 in načela javnega naročanja. Posledično je zahtevek za revizijo vlagatelja, na podlagi prve alineje prvega odstavka 39. člena ZPVPJN, kot neutemeljenega zavrnila.
S tem je utemeljena odločitev Državne revizijske komisije iz 1. točke izreka tega sklepa.
Če je zahtevek za revizijo utemeljen, mora naročnik v skladu s tretjim odstavkom 70. člena ZPVPJN iz lastnih sredstev vlagatelju povrniti potrebne stroške, nastale v predrevizijskem in revizijskem postopku, vključno s takso.
Ker vlagatelj v obravnavanem primeru z zahtevkom za revizijo ni uspel ne v predrevizijskem ne v revizijskem postopku, je Državna revizijska komisija v skladu z določbo tretjega odstavka 70. člena ZPVPJN njegovo zahtevo za povrnitev stroškov postopka pravnega varstva zavrnila.
S tem je odločitev Državne revizijske komisije iz 2. točke izreka tega sklepa utemeljena.
Pravni pouk:
Upravni spor zoper to odločitev ni dovoljen.
Predsednik senata:
Samo Červek, univ. dipl. prav.
predsednik Državne revizijske komisije
Vročiti:
- vlagatelj – po pooblaščencu;
- naročnik,
- ministrstvo, pristojno za javno naročanje.
Vložiti:
- v spis zadeve.