018-215/2018 Splošna bolnišnica Izola
Številka: 018-215/2018-26Datum sprejema: 10. 6. 2019
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 spremembami; v nadaljevanju: ZPVPJN) v senatu mag. Gregorja Šebenika, kot predsednika senata, ter Tadeje Pušnar in Nine Velkavrh, kot članic senata, v postopku pravnega varstva pri oddaji javnega naročila »Nakup, implementacija in vzdrževanje novega informacijskega sistema« in na podlagi zahtevka za revizijo, ki ga je vložila družba IN2 d.o.o., Marohnićeva 1/1, Zagreb, ki ga zastopa Odvetniška družba Godec Černeka Nemec o.p., d.o.o., Železna cesta 14, Ljubljana (v nadaljevanju: vlagatelj), zoper ravnanje naročnika Splošna bolnišnica Izola, Polje 40, Izola (v nadaljevanju: naročnik), dne 10. 5. 2019
odločila:
1. Vlagateljev predlog za izločitev strokovnjaka se zavrne.
2. Zahtevek za revizijo se zavrne kot neutemeljen.
3. Zahteva vlagatelja za povrnitev stroškov, nastalih z revizijo, se zavrne.
Obrazložitev:
Naročnik je obvestilo o predmetnem naročilu dne 13. 8. 2018 objavil na Portalu javnih naročil, pod številko objave JN 005609/2018-B0.
Naročnik je dne 8. 11. 2018 sprejel Odločitev o izidu javnega naročila št. JN 067/RN-18, s katero je predmetno javno naročilo oddal v izvedbo skupnim ponudnikom - družbam Telekom Slovenija d.d., Cigaletova ulica 15, Ljubljana, Itelis družba za svetovanje in informacijski inženiring d.o.o., Cesta v Gorice 1, Ljubljana ter Common Management Solutions, S.L., Calle Chile 4, Las Rozas De Madrid, Španija (v nadaljevanju: izbrani ponudnik). Iz obrazložitve je razvidno, da je naročnik prejel dve ponudbi in da je ponudba izbranega ponudnika dopustna. Vlagateljeva ponudba, ki se je uvrstila na prvo mesto, je bila izločena kot nedopustna, ker ni izpolnila naslednjih zahtev: 1). zahteve iz točke 3.1.6 tehničnih specifikacij, v delu, ki določa: »Tehnološko okolje SBI-PIS, strežniška in komunikacijska infrastruktura bo v celoti nameščena na centralno infrastrukturo znotraj DC SBI na način, da bo zagotovljeno popolno upravljanje s strani osebja IT bolnišnice. Ponujen sistem mora ponudnik povezati z obstoječim sistemom za varovanje podatkov naročnika (Veeam backup - stroški licenc so na strani naročnika).«, 2). zahteve iz točke 1 tehničnih specifikacij, v delu, ki določa: »V sklopu uvedbe je potrebno vzpostaviti enovit sistem, ki bo deloval na enotni podatkovni bazi, brez podvajanja podatkov, omogočal enotno vstopno točko za uporabnike z uporabo enega/enotnega uporabniškega vmesnika, to pomeni, da so vsi poslovni procesi med seboj povezani v enovit informacijski sistem.«, 3). zahteve iz točke 1 tehničnih specifikacij, v delu, ki določa: »SBI-PIS mora biti v vsakem trenutku skladen z veljavno zakonsko regulativo brez dodatnih stroškov za naročnika ne glede na to, ali je potreben razvoj ali zadošča nastavljanje parametrov.«, 4). zahteve iz točke 2.1 tehničnih specifikacij, v delu, ki določa: »Naročnik zahteva informacijsko rešitev, ki mu bo omogočala čim več samostojnosti in prožnosti pri definiranju in spreminjanju informatiziranih poslovnih procesov.«, 5). zahteve iz točke 3.1.3 tehničnih specifikacij, v delu, ki določa: »Skrbniški modul, ki bo del SBI-PIS, bo vsebinskim administratorjem oziroma skrbnikom sistema dosegljiv preko uporabniškega vmesnika in bo omogočal nastavljati in konfigurirati sistem. Predvsem bo namenjen upravljanju z uporabniki in pravicami dostopa ter upravljanju šifrantov ter tudi nastavitvam vnaprej pripravljenih poročil in analiz.« in 6). zahteve iz 4. točke Navodila ponudnikom, v skladu s katero je moral biti v partnerski pogodbi naveden delež storitev, ki jih prevzame posamezni partner.
Zoper navedeno odločitev je vlagatelj dne 19. 11. 2018 pravočasno vložil zahtevek za revizijo. Predlaga, da se izpodbijana odločitev razveljavi, zahteva pa tudi povrnitev stroškov pravnega varstva skupaj z zakonitimi zamudnimi obrestmi. Zatrjuje, da je njegova ponudba dopustna in skladna z vsemi tehničnimi zahtevami ter da je naročnik prišel do nasprotnih zaključkov na podlagi napačnega razumevanja vsebine posameznih dokumentov. Ob tem opozarja, da naročnik v razpisni dokumentaciji ni zahteval, da mora biti v ponudbi predložena dokumentacija, ki dokazuje izpolnjevanje vsake posamezne tehnične zahteve (ki so podane na 62. straneh). Vlagatelj se v nadaljevanju opredeljuje do vsakega izmed razlogov, zaradi katerih je bila njegova ponudba izločena. 1). Zatrjuje, da je v ponudbi (v dokumentu PS Arhitektura SBI_PIS.pdf, v točki 1) navedel, da ponuja »on premise« rešitev, navedeno pa velja tudi za varovanje podatkov (backup), v zvezi s katerim je ponudil navezavo na obstoječi sistem, kakor je to zahteval naročnik. Navedeno je razvidno iz slike 5 in iz slike 2 dokumenta PS Arhitektura SBI_PIS.pdf. Poleg navedenega sistema za varovanje podatkov s povezavo z obstoječim Veeam sistemom pa je (kot dodatno funkcionalnost) ponudil še sistem za okrevanje po katastrofi oziroma t.i. Disaster Recovery, ki je prav tako prikazan na obeh navedenih slikah, naročnik pa je celovit prikaz na slikah 2 in 5 spregledal in napačno interpretiral sliki 1 in 6. Dejstvo, da ponuja sistem za varovanje podatkov na lokaciji naročnika ter da za varovanje podatkov ponuja sistem Veeam backup, ki se poveže z obstoječim sistemom naročnika, je jasno razvidno iz točke 5 dokumenta PS_Arhitektura SBI-PIS.docx z naslovom Varovanje okolja in podatkov (backup, DR), ki se podrobneje ukvarja prav z varovanjem podatkov, zlasti iz slike 5. Navedena shema/slika ponazarja rešitve in dokazuje, da je ponujena t.i. »on premise« rešitev, kakor tudi sistem za varovanje podatkov v skladu z zahtevami naročnika. Vse funkcionalnosti in lastnosti sheme se nanašajo na postavitev pri naročniku, vključno z varovanjem podatkov, kar ponazarja uporabniški oblak, navedeno pa pomeni, da z njim upravlja uporabnik. Slika 5 tako dokazuje, da se varovanje podatkov primarno izvaja pri uporabniku in vključuje Fault Tolerance (FT), High Availability (HA) Replication/Snapshot in Backup. Navaja še, da naročnik sistema za okrevanje po katastrofi ni prepovedal. Disaster Recovery na oddaljeni lokaciji predstavlja dodatno vrednost za naročnika, ki je tudi nujna za vsak sodoben sistem in je bila ponujenega poleg tistega, kar je zahteval naročnik. Poleg tega je to dodatno funkcionalnost mogoče tudi izklopiti in zato ni v nasprotju z nobeno tehnično zahtevo naročnika. Naročnik, ki je sicer zahteval »on premise« rešitev, pa je tudi sam zapisal, da se poleg namestitve na primarni lokaciji lahko odloči tudi za namestitev celotnega sistema ali njegovega dela na lokaciji nadomestnega centra. Vlagatelj še navaja, da je sistem za okrevanje po katastrofi v sodobni informacijski opremi nujen in ker po naravi stvari tak sistem ne more shranjevati podatkov na isti lokaciji, na kateri je nameščen tudi sistem, je prepričan, da ga je predvidel tudi izbrani ponudnik. Zato je njegova izključitev tudi v nasprotju z načelom enakopravne obravnave ponudnikov. 2). Vlagatelj se strinja z naročnikom, da ponuja štiri informacijske sisteme, ki jih bo integriral. Navaja, da ni ponudil 4 različnih sistemov, temveč bo po izvedeni integraciji sistem enovit, sestavljen iz 4 komponent oziroma modulov. Vsi 4 moduli bodo delovali na enotni bazi podatkov (Microsoft SQ Server) iste različice, na enotnem strežniku. Poleg tega naročnik ni zahteval, da morajo biti vsi sestavni deli enovitega sistema po zasnovi in strukturi enaki. Predvsem pa obstoj ločenih modulov ne pomeni, da se bodo kakršnikoli podatki podvajali, saj je predvidena takšna integracija, pri kateri podvajanja ne bo. Ravno tako je nerazumljiva naročnikova ugotovitev o tem, da je vlagateljeva ponudba neustrezna tudi zato, ker ne navaja arhitekture ostalih dveh rešitev (obračunski in dokumentarni sistem). Ker naročnik tega ni zahteval, je z navedeno ugotovitvijo nezakonito razširil zahteve iz razpisne dokumentacije. Ob navedenem, še navaja vlagatelj, je v ponudbi podal prikaz arhitekture in delovanja za temeljna modula - to sta Green Cube in MS Dynamics. V zvezi z naročnikovo ugotovitvijo, da iz ponudbe ni razvidno, da bo zagotovljena enotna vstopna točka za vse uporabnike z uporabo enega/enotnega uporabniškega vmesnika, vlagatelj ponovno opozarja, da naročnik ni zahteval, da morajo biti vse tehnične zahteve razvidne in dokazljive iz ponudbe. Zgolj v zvezi z idejnim načrtom je naročnik zahteval, da mora biti predložen takšen idejni načrt, ki zajema vse točke iz razpisne dokumentacije, sicer bo ponudba izločena kot nedopustna. Vlagatelj še poudarja, da bodo vsi moduli ponujenega sistema dostopni z vstopom skozi skupno/enotno vstopno točko oziroma meni modula Green Cube, vse poslovne funkcije Microsoft Dynamics NAV se namreč odprejo preko te vstopne točke brez posebne avtentifikacije/prijave (kar je vidno v opisu funkcije Green Cube). Vlagatelj še poudarja, da je tudi izbrani ponudnik ponudil enovit sistem, sestavljen iz več sistemov/modulov, in sicer ponuja najmanj kombinacijo SAP Core, SAP Health Industry specific, Cerner Medical module, Common MS medical User Interface. Vlagatelj je prepričan, da tudi iz ponudbe izbranega ponudnika ni razvidno izpolnjevanje prav vsake tehnične zahteve. 3). Vlagatelj zatrjuje, da v ponudbi (v dokumentu PS_Arhitektura SBI_PIS.pdf) ni navedel, da za verzijo Microsoft Dynamics NAV 2016 lokalizacija s slovensko zakonodajo ni na voljo. Že iz izrecne izjave, dane v okviru opisa posamezne zagotovljene funkcionalnosti v dokumentu ePRO_Specifikacije N, na mestih, kjer je omenjena verzija NAV 2016, izhaja, da zagotavlja podporo vsem funkcionalnostim sistema oziroma da je zagotovljena tudi lokalizacija za to verzijo sistema. Vlagatelj (zgolj iz previdnost) prilaga še podpisano izjavo podjetja Adacta d.o.o. (ki je dobavitelj lokalizacije za rešitev Microsoft Dynamics NAV za Slovenijo), da zagotavlja lokalizacijo tako za MS Dynamics NAV 2016, kot za ostale višje verzije. Poleg tega prilaga še enako izjavo podjetja Microsoft d.o.o., Ljubljana. Opozarja še, da je v ponudbi navedel orodje za izvedbo posameznega posla/zahtevane funkcionalnosti, pri tem pa verzija tega orodja ni bistvena. Tekom izvedbe lahko nenazadnje izide tudi nova, izboljšana verzija orodja Microsoft Dynamics NAV, ki jo bo vlagatelj implementiral namesto prejšnje. 4). Vlagatelj navaja, da naročnik o prožnosti in samostojnosti sodi na podlagi napačne predpostavke, in sicer, da vlagatelj ponuja štiri različne informacijske sisteme. Zatrjuje, da to ne drži, saj ponuja enovit integriran sistem, sestavljen iz štirih modulov. Poleg tega naročnik sploh ni ugotovil, da prožnost in samostojnost nista podani, pač pa je navedel, da ni mogoče ugotoviti, ali sta podani. Poleg tega je nepreverljiva tudi sama zahteva, saj naročnik nikjer ni navedel, kako bo presojal zahtevi po čim večji samostojnosti in prožnosti. 5). Tudi v zvezi z domnevnim neizpolnjevanjem zahteve iz točke 3.1.3 vlagatelj opozarja, da naročnik ni zahteval, da mora ponudnik s ponudbeno dokumentacijo izkazati izpolnjevanje vsake posamezne tehnične zahteve. Zatrjuje, da ponuja enoten skrbniški modul in opozarja, da naročnik ni izrecno navedel, da zahteva enoten skrbniški modul, pač pa je zahteval le skrbniški modul. Vlagatelj še navaja, da naročnik z uporabo besede »podsistem« sam priznava, da njegov sistem ni sestavljen iz štirih samostojnih sistemov, pač pa da ponuja enoten sistem, sestavljen iz podsistemov. 6). Vlagatelj se strinja z naročnikom, da je v partnerski pogodbi izostala navedba deleža storitev posameznega partnerja, a poudarja, da je iz določb partnerske pogodbe o vrsti del, ki jih bo izvedel posamezen partner, ter ob upoštevanju Ponudbenega predračuna mogoče natančno ugotoviti, kakšen delež storitev prevzema vsak izmed sodelujočih partnerjev. Vlagatelj tako prevzema 26 % celotnega posla, Tich 41 % celotnega posla, Sicom d.o.o. 14,9 % celotnega posla in Pošta Slovenije 18,1 % celotnega posla.
Izbrani ponudnik se je z vlogo, z dne 26. 11. 2018, vloženo na podlagi drugega odstavka 27. člena ZPVPJN, izjasnil o revizijskih navedbah vlagatelja. Zatrjuje, da razpisna dokumentacija zahteva nakup izdelanega produkta kot celote ter da so dopustne tudi integracije, vendar le na zunanje specialistične sisteme in torej ne tudi v okviru ponujene rešitve za povezavo več rešitev v celoto. V primeru vlagateljeve ponudbe gre za kombinacijo 4 produktov, ki jih je potrebno še integrirati. Vlagatelj v zahtevku za revizijo sam priznava, da ponuja 4 rešitve, med katerimi bo integracijo šele potrebno izvesti. Ker te rešitve lahko delujejo tudi neodvisno, to pomeni, da ne morejo delovati brez podvajanja podatkov. Navedeno pa pomeni, da jih je potrebno reprogramirati, saj v nasprotnem primeru ne morejo delovati brez ustrezne osnove. Če je temu tako, gre za reprogramiranje obstoječe funkcionalnosti z namenom izdelave enovitega sistema, ki še ne obstaja. Izbrani ponudnik še ugotavlja, da so vlagateljeve navedbe nasprotujoče, saj najprej priznava, da ponuja 4 različne sisteme, ki jih je potrebno še integrirati, v nadaljevanju pa to zanika. Očitno je torej, da so vlagateljeve navedbe nasprotujoče in neutemeljene in da še nima ustrezne rešitve, temveč izvedbo načrtuje šele v okviru projekta. Vlagatelj navaja integracijo med Green Cubom in Microsoft Dynamics NAV ter drugimi funkcijskimi moduli, pri čemer ne pojasni, kateri so ti funkcijski moduli. Ključna je integracija s SICOM rešitvijo za obračun, kjer gre za ločen sistem. Zato gre razumeti, da dostop do SICOM sistema v trenutku oddaje ponudbe še ne obstaja. Za enotno avtentizacijo uporabnikov vlagatelj ponuja integracijo z MS AD Direktorijem, s čimer je mogoče zagotoviti enotno prijavo v sistem, ni pa mogoče upravljati funkcionalnih avtorizacij sistemov, ki so vezane na konkretne štiri ponujene aplikacije in morajo nuditi omejitve znotraj samih aplikacij. Izbrani ponudnik še zatrjuje, da vlagatelj pri njegovi ponudbi napačno ugotavlja, da je potrebno t.i. module še integrirati v enovit sistem. Navedbe o tem, da ponuja kombinacijo modulov, ki jih je potrebno integrirati, kažejo na nepoznavanje SAP rešitve. V primeru slednjih gre za različne poslovne funkcije znotraj enovitega sistema, ki se aktivirajo glede na potrebe posameznega uporabnika, pri čemer se na enak način aktivira tudi mobilna aplikacija.
Naročnik je z dokumentom, z dne 4. 12. 2018, zahtevek za revizijo zavrnil in posledično zavrnil tudi zahtevo za povrnitev stroškov. Ugotavlja, da vlagatelj ne izpodbija dopustnosti ponudbe izbranega ponudnika, saj to (glede na dejstvo, da je bila njegova ponudba ugodnejša in ob predpostavki dopustnosti njegove ponudbe) niti ni potrebno. 1). Naročnik očitke iz te točke zavrača. Navaja, da je vsebina vlagateljeve ponudbe takšna, da je mogoče nedvoumno razumeti, da se del podatkov nahaja na lokacijah ponudnika, kar je v izrecnem nasprotju z zahtevami iz tehničnih specifikacij. Glavna argumentacija vlagatelja v zvezi s tem je, da hrambo na lokaciji ponudnika ponuja zgolj dodatno, kar je nenavadno, saj najem lokacije-kolokacije izrecno ni predmet javnega naročila, prav tako med strankama ni sporno, da je naročnik izrecno prepovedal tako hrambo podatkov izven sfere naročnika, hkrati pa je izrecno navedel, da komunikacijska oprema ni predmet javnega naročila. Če mora biti vsa oprema pri naročniku, ni možnosti, da se podatki nahajajo kjerkoli drugje. Četudi ni eksplicitno navedeno, da se podatki ne bodo nahajali pri naročniku, pa iz zapisa »zagotovljenega popolnega upravljanja s strani osebja IT bolnišnice« in dejstva, da mora biti »tehnološko okolje v celoti nameščeno na centralni infrastrukturi znotraj DC SBI«, to po naravi stvari ne more biti drugače - takoj ko so podatki kje drugje, je del tehnološkega okolja SBI-PIS, strežniška in komunikacijska infrastruktura nameščena drugje, kar pa je bilo prepovedano. Poleg tega tudi ni utemeljena vlagateljeva navedba, da je bil sistem za okrevanje po katastrofi ponujen zgolj dodatno, saj variantna ponudba ni bila dovoljena. Iz vsebine pogodbe pa je tudi razvidno, da je eden izmed partnerjev (Pošta Slovenije d.o.o.) zadolžen za komunikacijsko infrastrukturo (aktivna oprema LAN), ta pa sploh ni bila zahtevana. Tudi mobilna aplikacija je ponujena v kombinaciji privatnega in javnega oblaka, kar je izrecno zapisano v vlagateljevi ponudbi. Navedeno pomeni, da sistem, ki je ponujen, komunicira z lokacijo izven lokacij naročnika, posledično pa se del tehnološke rešitve (s tem pa tudi operativni podatki) nahaja izven zahtevane infrastrukture. 2). Naročnik navaja, da je potrebno glede očitkov, ki se nanašajo na enotnost informacijskega sistema, sprejeti tudi izjasnitev izbranega ponudnika. Naročnik v tem delu v celoti sledi navedbam izbranega ponudnika in opozarja, da se je beseda integracija (tudi v vprašanjih in odgovorih) uporabila izključno za povezovanje z zunanjimi informacijskimi sistemi, pri čemer integracija notranjega informacijskega sistema ni bila dovoljena, nasprotno, ponujen je moral biti enovit sistem, ki je v večini funkcionalnosti že tudi izdelan. Dikcija vlagatelja, da šele namerava izvesti integracijo kaže na to, da rešitev ni enovita in izdelana, naročnik pa je eksplicitno zahteval, da mora biti produkt v enovitem delu že izdelan. Tudi vlagateljeva uporaba besede modul ni na mestu, saj je ponudil (niti še ne izdelano) integracijo štirih različnih proizvajalcev - v zahtevku navaja, da je bila ponujena enotna podatkovna baza verzija 2017, v ponudbi je navedel, da ponuja bazo verzijo 2016 (Navision), v drugem delu opisa pa še verzijo 2018 (Navision enterprise). Na ta način so očitno ponujene tri različne podatkovne baze. Enotna baza za vlagatelja tako pomeni tri različne baze, fizično nameščene na istem strežniku. V ponudbi so sicer ponujeni štirje različni strežniki za štiri različne baze, v zahtevku pa je vlagatelj vsebino svoje ponudbe spremenil na tri podatkovne baze. Vlagatelj sicer zatrjuje, da bo združevanje različnih baz dosegel z referenčnimi povezavami med bazami, vendar referenčna integriteta med različnimi bazami, ne glede na to, da so na istem strežniku in tudi ne glede na verzijo, ni možna. Glede rešitve za obračun pa vlagatelj sploh ni navedel ničesar, saj mora na novo napisati celotno aplikacijo, ponujena rešitev Sicom pa obstaja zgolj na podatkovni bazi Oracle, ki je zopet podatkovna baza drugega proizvajalca. Sicer vlagatelj lahko programira povezave različnih baz in jih delno podvaja, toda rešitev ta trenutek ne obstaja, zahtevana pa je bila že obstoječa rešitev. Namen zahteve po enovitosti je v tem, da deluje integrirano. Vsako stvar se posledično popravi/dopolni le enkrat, v konkretnem primeru pa bo šel razvoj rešitve Navision po svoje, Greencube po svoje itd., kar pomeni, da bo moral vsak od proizvajalcev štirih rešitev vsakokrat prilagoditi svoj del rešitve, kar pa ni smiselno. Da ne gre za enotno rešitev pa je mogoče ugotoviti tudi ob upoštevanju zahteve po enotnem uporabniškem vmesniku - že samo ekranske slike modulov Navision in Greencube so različne. Četudi bi sprejeli »teorijo modulov«, bi moral vlagatelj tudi enoten vmesnik šele izdelati, saj primeri izdelkov ne predstavljajo enotnega uporabniškega vmesnika (naročnik navedeno ponazarja s sliko 1 - vmesnik Navision 2018, sliko 2 - vmesnik Navision 2016, sliko 3 - vmesnik Greencube in sliko 4 - vmesnik BIS Obračun podjetja Sicom). Vlagatelj sicer trdi, da bo imel enotno vstopno točko (npr. v Greencube-u), vendar to še ni enoten uporabniški vmesnik. Uporabniki bi se tako morali učiti uporabe štirih različnih vmesnikov, kar je nesprejemljivo, zato je naročnik navedeno tudi prepovedal. Naročnik še navaja, da je vedel, česa na želi (različnih vmesnikov), saj ima trenutno informacijski sistem, ki je sestavljen iz več različnih rešitev, zato je vztrajal pri enotnem vmesniku. 3). Naročnik nadalje navaja, da je vlagatelj v predračunu ponudil izdelek Navision verzija 2016, v tehnični dokumentaciji ponudbe sicer navaja, da bo verzija 2018 lokalizirana, ne navaja pa tega tudi za verzijo 2016. Navedeno pomeni, da je izvajanje lokalizacije pridobil šele po oddaji ponudb, s čimer je naknadno spremenil vsebino ponudbe v delu, ki se nanaša na tehnične specifikacije). 4). Naročnik navaja, da že iz 2. točke izhaja, da rešitev ni prožna, kar je posledica neenovite rešitve oziroma štirih različnih rešitev, ki jih je potrebno v primeru sprememb spreminjati s strani štirih proizvajalcev. Navedeno pa ne ustreza definiciji prožnosti. 5). Naročnik ponovno opozarja na 2. točko in navaja, da ne obstaja enoten skrbniški modul, saj gre za štiri različne produkte, ki nimajo enotnega skrbniškega vmesnika (ga že po naravi stvari ne morejo imeti). 6). Naročnik vztraja tudi pri navedbah, ki se nanašajo na deleže. Navaja, da deleži v pogodbi o skupnem nastopanju niso razvidni. Drži sicer, da je razvidna vrsta del, vendar je bila izrecno zahtevana tudi navedba deležev. Vlagatelj bi moral pri pripravi ponudbe ravnati s potrebno skrbnostjo in upoštevati izrecne zahteve (naročnik se v zvezi s tem sklicuje na odločitev Državne revizijske komisije št. 018-144/2018).
Vlagatelj se je z vlogo, z dne 10. 12. 2018, izjasnil o navedbah naročnika o odločitvi o zahtevku za revizijo. 1). Navaja, da se naročnik ni opredelil do njegovih navedb o tem, da je ponudil sistem za varovanje podatkov s povezavo z obstoječim sistemom za varovanje podatkov naročnika (Veeam backup). Razlaga predmetne tehnične specifikacije je enoznačna in zahteva, da mora biti na lokaciji naročnika celotno tehnološko okolje sistema ter celotna strežniška in komunikacijska infrastruktura sistema. Navedeno pa je izpolnil, saj je ponudil sistem, ki bo z vsemi funkcionalnostmi, zahtevanimi v tehničnih specifikacijah, v celoti nameščen na strežnikih na lokaciji naročnika. Sporne tehnične zahteve ni mogoče razlagati tako, da bi prepovedovala, da bi se kopije teh podatkov nahajale na drugi lokaciji. Na zunanji lokaciji bo le Disaster Recovery (v nadaljevanju: DR) oziroma se bodo na zunanji lokaciji (če bo naročnik dodatno ponujeni DR želel vklopiti) nahajale le kopije podatkov sistema, pri čemer naročnik z nobeno tehnično zahtevo ni prepovedal kopiranja podatkov na drugo lokacijo. Vlagatelj ob tem poudarja, da noben podatek, ki bo zaradi zagotavljanja DR kopiran na oddaljeni lokaciji, ni potreben ponujenemu sistemu za njegovo delovanje, zato kopij teh podatkov ni mogoče razumeti kot tehnološko okolje SBI-PIS, strežniško in komunikacijsko strukturo. Opozarja še, da je potrebno tehnično specifikacijo razlagati skladno z njenim namenom. Naročnik vso infrastrukturo na njegovi lokaciji zahteva zato, da bo imel možnost popolnega upravljanja s strani svojega osebja. Glede na to, da so vsi podatki, ki so potrebni za delovanje sistema z vsemi funkcionalnostmi, ki jih zahteva naročnik (vključno z backupom), zagotovljeni pri naročniku, je namen zadevne specifikacije izpolnjen. Vlagatelj še navaja, da v tem delu ni ponudil variantne ponudbe, saj je poleg zahtevanega sistema za varovanje podatkov s povezavo na obstoječi sistem pri naročniku, ponudil še dodatno varovanje podatkov za primer katastrofe. Navaja še, da je naročnik dodal nov razlog za izločitev njegove ponudbe, in sicer je pavšalno navedel, da točka 3.1.6 ni izpolnjena tudi zato, ker je ponudil mobilno aplikacijo, za katero je zapisano, da je ponujena v kombinaciji privatnega in javnega oblaka, kar naj bi pomenilo, da se operativni podatki nahajajo na zunanji lokaciji. Vlagatelj zgolj iz previdnosti opozarja, da se v javnem oblaku ne bodo nahajali operativni podatki, temveč le podatki za potrebe statistik in licenčnega preverjanja. 2). Vlagatelj vztraja tudi pri očitkih, ki se nanašajo na enovit sistem. Navaja, da naročnik svojim prvotnim ugotovitvam nedopustno dodaja še nove, ki so povzete iz izjasnitve izbranega ponudnika (da integracija štirih sistemov sama po sebi ne ustreza zahtevi po enovitem sistemu ter da vlagateljev sistem še ni izdelan, kakor je bilo zahtevano, temveč bo integracijo moral šele izvesti). Poudarja, da z navedenima očitkoma naročnik ravna v nasprotju z načelom enakopravne obravnave ponudnikov, saj je pri izbranem ponudniku uporabil drugačne kriterije. Tudi sistem izbranega ponudnika bo namreč integriran iz več samostojnih sistemov različnih proizvajalcev, ki jih je potrebno integrirati v informacijski sistem. Izbrani ponudnik ponuja celo produkte, ki so infrastrukturno različni, kar pomeni, da jih bodo morali integrirati v enovit produkt. Trditve o tem, da so pri izbranem ponudniku posamezne funkcionalnosti del istega sistema, ne morejo biti resnične, saj gre prav tako za sisteme različnih proizvajalcev. Poleg tega tudi sistem izbranega ponudnika še ni izdelan, saj bo moral izbrani ponudnik izdelati najmanj še obračunski sistem. Naročnik je zahteval sistem, ki bo deloval na enotni podatkovni bazi, pri delovanju katerega ne bo podvajanja podatkov in ki bo omogočal enotno vstopno točko za uporabnike z uporabo enega/enotnega uporabniškega vmesnika. Naročnik v razpisni dokumentaciji ni navedel, da iz več modulov integriran sistem ni enovit sistem, četudi bi deloval na enotni podatkovni bazi in brez podvajanja podatkov ter omogočal enotno vstopno točko z uporabo enotnega vmesnika. Vlagatelj navaja, da je naročnik od ponudnikov zahteval najmanj 3 primerljive enovite informacijske sisteme, pri čemer je navedel tudi, da bo kot enovit informacijski sistem štel projekt, ki ima za osnovo isto programsko platformo (ter podatkovno bazo istega proizvajalca). Ponujen sistem izpolnjuje vse zahteve, tudi predpostavke iz referenčne zahteve, saj je v celoti izdelan na isti programski platformi - Microsoft SQL Server. Moduli izbranega ponudnika pa niso izdelani na isti programski platformi. Po vlagateljevem prepričanju je uporaba pojma integracija v razpisni dokumentaciji irelevantna za ugotovitev, ali s strani vlagatelja ponujeni integriran sistem ustreza vsem tehničnim zahtevam iz naročnikovih specifikacij, vključno z vsemi parametri, s katerimi naročnik pojasnjuje, kaj je enovit sistem. Dejstvo, da so ponujeni sistemi zaradi različnih funkcionalnosti različni, ne pomeni, da po integraciji ne bodo delovali enovito. Naročnik v 1. točki tehničnih specifikacij sam definira enovit sistem tako, da so v njem vsi poslovni procesi povezani, kar pa ni nič drugega kot s strani vlagatelja ponujena integracija modulov v enovit sistem. Vlagatelj pojasnjuje, da ima s pojmom integracija v mislih storitev, s katero zagotovi poenotenje sistemov v enovit sistem, ki bo deloval na enotni podatkovni bazi, in v katerem se ne bo niti en podatek podvajal/nahajal na dveh mestih. Z integracijo bodo vsi štirje prvotno samostojni sistemi vgrajeni kot moduli v enovit sistem. Namen zahteve po enovitosti je v tem, da deluje integrirano - vsako stvar se posledično popravi/dopolni samo enkrat. Tudi naročnik priznava, da enovitost pomeni integrirano delovanje. Ne glede na referiranje na različne verzije Navisiona na posameznih mestih v ponudbi, gre vselej za isto podatkovno bazo enega proizvajalca Microsoft. Naročnik napačno sklepa, da gre za tri različne verzije ERP-ja, ki naj bi tekle na treh različnih bazah. Da je ponujena ena verzija, je razvidno že iz ponudbenega predračuna. Vlagatelj še zatrjuje, da ne ponuja združene uporabe različnih baz, pač pa bo sistem deloval v eni podatkovni bazi, kar je navedeno tudi v ponudbi. Referenčno integriteto podatkov med različnimi bazami pa je možno zagotoviti na dva načina: z uporabo tujih ključev - foreign keys (ta rešitev se uporablja znotraj ene podatkovne baze, ponuja in zagotavlja pa jo tudi vlagatelj) ter s programiranjem. Paradoksalnost naročnikovih navedb se kaže v dejstvu, da vsi očitki, ki jih naslavlja vlagatelju, za izbranega ponudnika ne veljajo. Izbrani ponudnik namreč v svoji rešitvi ne zagotavlja referenčne integritete na nivoju podatkovne baze, kar je napačno očitano vlagatelju, pač pa na programski način, in še to le delno, ker v uporabniškem vmesniku omogoča nastanitev vklopa ali izklopa referenčne integritete med posameznimi podatkovnimi objekti. Izklop referenčne integritete je v primeru izbranega ponudnika možen in dopusten, vlagatelj pa takšne možnosti niti ne predvideva, kar dejansko pomeni, da se bodo (po dikciji naročnika) podatki vsaj v delu podvajali, česar pa naročnik ni dopustil. Vlagatelj še navaja, da tudi ne drži, da mora za obračunski sistem/billing na novo spisati celotno aplikacijo. Zatrjuje, da naročnik ni dovolj natančno preveril njegovih referenc, sicer tega ne bi trdil. Rešitev Sicom (poleg Oracla) obstaja tudi na podatkovni bazi MS SWQL Server, kar je možno preveriti na vlagateljevi referenci. Prav tako je zmoten očitek, da ne ponuja enotnega uporabniškega vmesnika. Vlagatelj poudarja, da ponuja enoten uporabniški vmesnik, v katerega bo uporabnik vstopal z enotnim logiranjem. Naročnik pa očitno ne loči med enotnostjo uporabniškega vmesnika in vsebino oziroma funkcionalnostmi posameznega modula. Z elektronskimi slikami želi med tehnične specifikacije vključiti neobstoječo zahtevo, in sicer, da je z zahtevo po enovitem informacijskem sistemu zahteval tudi enotno vizualno podobo vseh modulov sistema. Poleg tega z enotnostjo uporabniškega vmesnika naročniku ni zagotovljeno, da bo s tem, ko se bo naučil uporabljati en modul z določenimi vsebinami in funkcijami, poznal funkcije in vsebine tudi drugih modulov (uporabnik, ki se je npr. naučil uporabljati Microsoft Word, ne bo zato znal uporabljati orodja Microsoft Excel, čeprav sta oba programa iz zbirke Microsoft Office). Naročnik je definicijo pojma enoten uporabniški vmesnik opustil, sedaj pa to skuša nadomestiti z naknadno ugotovitvijo, da je imel v mislih enotno vizualno podobo in z nemogočo zahtevo, da se uporabnikom ne bi bilo potrebno učiti uporabe posameznih modulov. Zato je potrebno enoten uporabniški vmesnik razumeti tako, da se uporabnik prijavi enkrat v en sistem in se mu za uporabo različnih modulov ni treba odjavljati in ponovno prijavljati v drug modul. Vlagatelj v nadaljevanju dodaja tri ekranske slike posameznih modulov izbranega ponudnika (za ERP proizvajalca SAP, za BIS I.s.h. med proizvajalca Cerner in za medicinski mobilni uporabniški vmesnik proizvajalca Common Management Solutions). Navaja, da so podobnosti in razlike med slikami posameznih modulov primerljive slikam modulov, ki jih ponuja sam. Tudi iz teh slik pa je nemogoče zaključiti, da bo uporabnik s tem, ko se bo naučil uporabljati npr. mobilni zdravstveni karton iz zadnje slike, obvladal tudi npr. modula ERP iz prve slike. Vlagatelj poudarja, da njegov sistem že obstaja, vsi posamezni moduli z večino funkcionalnosti pa so že izdelani. Dejstvo, da bo sistem potrebno integrirati pa ne pomeni, da je sistem neizdelan. Integracija bo potrebna v vsakem primeru in tudi izbrani ponudnik bo moral to storiti. Navedeno drži že iz razloga, ker je naročnik šele po izbiri ponudnika predvidel GAP analizo, ki jo bo moral opraviti izvajalec, v kateri se bodo šele izkazale detajlne zahteve naročnika. Naročnik je na številnih mestih navedel, da dopušča izdelavo prilagoditev, na vprašanje izbranega ponudnika pa je dopustil celo izdelavo novega obračunskega sistema (datum objave: 23. 8. 2018 ob 10:19). 3). V zvezi z lokalizacijo vlagatelj ponavlja očitke iz zahtevka za revizijo. Navaja še, da s predloženima izjavama ni spreminjal ponudbe, temveč je zgolj pojasnil tehnične lastnosti iz ponudbe. 4). Navaja še, da je naročnik v izpodbijani odločitvi zapisal, da samostojnosti in prožnosti ni mogel oceniti, v odločitvi o zahtevku za revizijo pa je navedel, da samostojnost in prožnost nista zagotovljeni. Nova in zato nedopustna je tudi navedba, da bi bilo potrebno v primeru sprememb sistem spreminjati s strani štirih proizvajalcev. Ta trditev ni pravilna, saj zaradi integriranosti sistema v primeru sprememb enega modula, ni potrebno narediti nobene spremembe na drugih modulih. 5). Vlagatelj še opozarja, da je post festum zatrjevanje, da zahtevani skrbniški modul ni bil ponujen, prepozno. Kljub temu pa ne drži, da ni mogoče ponuditi enotnega skrbniškega modula, če gre za štiri produkte. 6). Vlagatelj še navaja, da naročnik z razlogom, da bi zmanjšal pomen predračuna, le-tega niti ne omeni, pri čemer nerazumljivo zatrjuje, da je pogodba o skupnem nastopu ločena zaključena celota. Opozarja, da je potrebno na ponudbo gledati kot na celoto ter da odločitev Državne revizijske komisije št. 018-144/2018 ni primerljiva obravnavanemu dejanskemu stanju.
Naročnik se je z vlogo, z dne 13. 12. 2018 (Pripravljalna vloga), opredelil do vlagateljevih navedb, vlagatelj pa je na navedeno naročnikovo vlogo odgovoril dne 24. 12. 2018 (Odgovor na pripravljalno vlogo naročnika).
Državna revizijska komisija je v cilju ugotovitve pravilnega dejanskega stanja na podlagi 34. člena in prvega odstavka 36. člena ZPVPJN za strokovno mnenje zaprosila strokovnjaka mag. A.B., sodnega izvedenca s področja računalništva in informatike (v nadaljevanju: strokovnjak). Državna revizijska komisija je strokovnjaka imenovala s sklepom št. 018-215/2018-11, z dne 30. 1. 2019.
Državna revizijska komisija je strokovno mnenje prejela dne 19. 3. 2019 ter ga dne 20. 3. 2019 posredovala obema strankama in izbranemu ponudniku. Naročnik se je z vsemi ugotovitvami strokovnjaka strinjal, izbrani ponudnik in vlagatelj pa sta na strokovnjakove ugotovitve podala pripombe (Državna revizijska komisija je pripombe vlagatelja in izbranega ponudnika prejela dne 27. 3. 2019). Vlagatelj je tudi predlagal, naj se izvede ustna obravnava, na katero naj se povabi tudi strokovnjak. Državna revizijska komisija je pripombe obeh dne 1. 4. 2019 posredovala strokovnjaku in ga pozvala naj se do njih opredeli. Državna revizijska komisija je dne 8. 4. 2019 prejela strokovnjakovo opredelitev do pripomb izbranega ponudnika in vlagatelja (Dopolnitev mnenja) in naveden dokument še istega dne posredovala vlagatelju, naročniku in izbranemu ponudniku. Dne 16. 4. 2019 je Državna revizijska komisija od vlagatelja prejela pripombe, pri čemer je vlagatelj tudi predlagal, da se izvedenec izloči in se imenuje drug strokovnjak oziroma (subsidiarno) da se izvede ustna obravnava ali pa (podrejeno) pozove strokovnjaka, da se opredeli do vseh vlagateljevih pripomb in vprašanj z vloge, z dne 26. 3. 3019, kar naj vključuje tudi celovito primerjavo obeh ponudb z vidika spornih tehničnih zahtev.
Po pregledu dokumentacije o javnem naročilu ter pa preučitvi navedb vlagatelja, naročnika in izbranega ponudnika ter strokovnega mnenja, dopolnitve strokovnega mnenja in pripomb, ki sta jih v zvezi s strokovnim mnenjem in njegovo dopolnitvijo posredovala vlagatelj in izbrani ponudnik, je Državna revizijska komisija odločila, kot izhaja iz izreka tega sklepa, iz razlogov, navedenih v nadaljevanju.
Državna revizijska komisija je najprej presojala formalne pomisleke in ugovore vlagatelja, ki se nanašajo na (ne)strokovnost in (ne)pristranskost strokovnjaka.
Vlagatelj je v vlogi, s katero se je opredelil do izvedenskega mnenja (Pripombe na strokovno mnenje in vprašanja za strokovnjaka, z dne 26. 3. 2019), navedel, da strokovnjak na nekatera vprašanja ni podal eksplicitnih odgovorov, da so njegova stališča pomanjkljiva in napačna ter da je njegova presoja ponudbe izbranega ponudnika subjektivna. V vlogi, s katero se je opredelil do dopolnitve izvedenskega mnenja (Pripombe na dopolnitev strokovnega mnenja, z dne 15. 4. 2019), je vlagatelj navedel podobne razloge, zaradi katerih je predlagal izločitev strokovnjaka in imenovanje drugega strokovnjaka (vlagatelj je predlagal naj se za presojo spornih vprašanj imenuje eno izmed slovenskih fakultet za računalništvo). Navedel je, »da je strokovnjak z vnovičnim zgolj pavšalnim mnenjem, s katerim se je izognil odgovorom na vprašanja, zlasti na vprašanja v zvezi s ponudbo izbranega ponudnika, izrazil očitno pristranskost in vnaprejšnjo odločenost zastopati stališča naročnika v tem postopku«, poleg tega je vlagatelj tudi navedel, »da kljub vprašanjem Državne revizijske komisije, s katerimi je bil pozvan na preučitev ponudbe izbranega ponudnika, strokovnjak ni izvedel celovite primerjave obeh ponudb, ki bi bila nujna za odločitev, ali je naročnik ravnal v nasprotju z načelom enakopravne obravnave ponudnikov, pristranskost pa očitno izhaja tudi iz dejstva, da strokovnjak ni odgovoril na pretežni del vlagateljevih vprašanj, dopolnil pa je svoje mnenje v delu, v katerem je našel nov potencialni argument v prid naročniku, čeprav vprašanja ali pripombe v zvezi s tem ni prejel«.
Kot je Državna revizijska komisija zapisala že v svojih številnih odločitvah, podlago odločitve naročnika o zahtevku za revizijo tvorijo le tista dejstva in kršitve, ki so bili predlagani in le tisti zahtevki, ki so bili postavljeni do konca predrevizijskega postopka pred naročnikom. Poleg tega je Državna revizijska komisija prav tako že večkrat zapisala, da mora naročnik vse morebitne razloge za nedopustnost ponudbe navesti že v odločitvi o oddaji naročila. Učinkovito pravno varstvo (9. člen ZPVPJN) je v postopkih oddaje javnih naročil lahko zagotovljeno le, če ima ponudnik možnost v predrevizijskem postopku izpodbijati vse naročnikove ugotovitve, ki se nanašajo na vprašanje dopustnosti njegove ponudbe. Ker torej vlagatelj v postopku pravnega varstva po tem, ko naročnik odloči o njegovem zahtevku za revizijo, (praviloma) ne sme navajati novih kršitev (šesti odstavek 29. člena ZPVPJN), tudi naročnik v sklepu, s katerim odloči o zahtevku za revizijo, ne sme navajati novih razlogov za nedopustnost vlagateljeve ponudbe, ki jih ni navedel že v odločitvi o oddaji naročila. Ob upoštevanju navedenega in skladno z ustaljeno prakso, je Državna revizijska komisija pripravila tudi vprašanja za strokovnjaka oziroma so se postavljena vprašanja nanašala zgolj in samo na tista dejstva in trditve, ki jih je vlagatelj navedel že v zahtevku za revizijo.
Državna revizijska komisija ugotavlja, da v konkretnem primeru ni izkazano, da bi bile podane okoliščine, ki bi vzbujale dvom v strokovnost in nepristranskost strokovnjaka, ki mu je zaupala izdelavo strokovnega mnenja. Mnenje strokovnjaka je namreč rezultat strokovne proučitve obstoječe razpisne in ponudbene dokumentacije oziroma primerjava vlagateljeve ponudbe in ponudbe izbranega ponudnika z zahtevami iz razpisne dokumentacije ter temelji na strokovnem znanju s področja predmeta javnega naročila. V postopku pridobljeno strokovno mnenje (in njegova dopolnitev) dovolj izčrpno pojasnjuje strokovna vprašanja, ki so se pojavila med presojo utemeljenosti vlagateljevih navedb, zato Državna revizijska komisija tudi po preučitvi vlagateljevih pripomb meni, da le-to predstavlja ustrezno osnovo, ki omogoča sprejem odločitve o zahtevku za revizijo.
Ob navedenem in ob upoštevanju, da je strokovnjak odgovoril na vsa vprašanja Državne revizijske komisije (ki so bila postavljena, kot že izhaja iz te obrazložitve, zgolj v okviru vlagateljevih očitkov iz zahtevka za revizijo) se ni mogoče strinjati z vlagateljevimi ugotovitvami o tem, da njegovi odgovori (kot bo podrobneje razvidno tudi iz nadaljnje obrazložitve tega sklepa) niso eksplicitni, da so njegova stališča pomanjkljiva in napačna ter da je njegova presoja ponudbe izbranega ponudnika subjektivna. Dvoma v objektivnost, nepristranost in strokovnost strokovnega mnenja ne vzbuja niti vlagateljev očitek o tem, da naj bi se strokovnjak s svojimi pavšalnimi odgovori izognil zlasti tistim vprašanjem, ki se nanašajo na ponudbo izbranega ponudnika, kar naj bi kazalo na očitno pristranskost in vnaprejšnjo odločenost zastopati stališča naročnika v tem postopku ter da je strokovnjak (čeprav vprašanja ali pripombe v zvezi s tem ni prejel) v dopolnitvi strokovnega mnenja našel nov potencialni argument, ki govori v prid naročnika. V naravi izdelave vsakega strokovnega mnenja je namreč, da po strokovni preučitvi odstopljene dokumentacije strokovnjak lahko pride do enakih zaključkov, do katerih je prišel kateri izmed udeležencev postopka (v konkretnem primeru naročnik). Zgolj morebitno strinjanje z naročnikom oziroma morebitno povzemanje naročnikovih ugotovitev iz sklepa, s katerim je odločil o zahtevku za revizijo, zato ni zadosten razlog za zaključek, da je strokovno mnenje, kot navaja vlagatelj, zlasti v delu, ki se nanaša na ponudbo izbranega ponudnika, subjektivno oziroma da kaže na strokovnjakovo odločitev o tem, da bo strokovno mnenje pripravil v prid naročniku. Na pristranskost strokovnega mnenja prav tako tudi ne vpliva dejstvo, da je strokovnjak dopolnil svoje mnenje tudi v tistem delu, v katerem pripomb sploh ni prejel. Vlagatelj sicer pravilno opozarja, da je strokovnjak (kot bo podrobneje razvidno tudi iz nadaljnje obrazložitve tega sklepa) v delu, ki se nanaša na »enotno podatkovno bazo«, svoje prvotno mnenje popravil, in sicer je ugotovil, da je vlagatelj ponudil štiri baze na štirih strežnikih (in torej ne tri baze na treh strežnikih, kot je zapisal predhodno), vendar pa je v obeh primerih tudi izrecno in jasno zapisal, da vlagatelj ni ponudil enotne podatkovne baze oziroma da vlagateljeva ponudba v tem delu ni skladna z naročnikovo zahtevo iz razpisne dokumentacije.
Državna revizijska komisija na podlagi navedenega ni sledila predlogu vlagatelja, naj izloči strokovnjaka in imenuje drugega, temveč je ocenila, da pridobljeno strokovno mnenje (po izvedeni dopolnitvi), tudi ob upoštevanju vlagateljevih vsebinskih pripomb, predstavlja ustrezno podlago za sprejem odločitve v predmetnem postopku pravnega varstva.
S tem je utemeljena odločitev Državne revizijske komisije iz 1. točke izreka tega sklepa.
Državna revizijska komisija tudi ni sledila vlagateljevi pobudi, naj se izvede ustna obravnava (vlagatelj je pobudo za izvedbo ustne obravnave podal tako v zahtevku za revizijo, kakor tudi v obeh vlogah, s katerima se je opredelil do strokovnega mnenja oziroma njegove dopolnitve).
Vlagatelj pobudo za izvedbo ustne obravnave utemeljuje z ugotovitvijo, da bi bila (glede na obsežnost potrebnih dopolnitev in kompleksnost vprašanj) zadeva najučinkoviteje rešena na ustni obravnavi, na katero naj se povabi tudi strokovnjak. Vlagatelj tudi navaja, da mu je bila v obravnavanem primeru odvzeta pravica do ugovora na njegove pripombe ter tudi pravica do odgovorov na vprašanja, ki jih je podal na izvedensko mnenje, s tem pa mu je bila odvzeta pravica do predlaganja dokazov v postopku in s tem pravica do izjave oziroma kršena kontradiktornost postopka in ustavna pravica do enakega varstva pravic.
V skladu s prvim odstavkom 35. člena ZPVPJN, lahko Državna revizijska komisija na pobudo vlagatelja ali naročnika ali na lastno pobudo izvede ustno obravnavo z namenom pridobitve natančnejših pojasnil o dejanskih okoliščinah, od katerih je odvisna odločitev v revizijskem postopku. Če Državna revizijska komisija presodi, da je dejansko stanje mogoče pravilno in popolno ugotoviti na podlagi dokumentacije iz postopka javnega naročanja, predrevizijskega postopka ali revizijskega postopka, pobudo vlagatelja ali naročnika zavrne.
Državna revizijska komisija torej ustne obravnave ni dolžna izvesti, saj lahko, če je mogoče dejansko stanje pravilno in popolno ugotoviti že na podlagi dokumentacije (iz postopka javnega naročanja, predrevizijskega postopka ali revizijskega postopka) vlagateljevo pobudo tudi zavrne. Državna revizijska komisija v obravnavanem primeru vlagateljevemu predlogu za izvedbo ustne obravnave ni ugodila, saj se je vlagatelj v postopku pred Državno revizijsko komisijo opredelil tako do vseh naročnikovih vlog, kakor tudi do strokovnega mnenja in njegove dopolnitve. Vlagatelj je tako poznal in komentiral vse predložene dokaze in ugotovitve, ki so bile vložene z namenom vplivanja na odločitev Državne revizijske komisije, kot to zahteva pravica do kontradiktornosti postopka. V okoliščinah danega primera tako ni pričakovati, da bi ustno zaslišanje strank v čimerkoli prispevalo k razjasnitvi dejanskega stanja zadeve, saj je imel vlagatelj tudi v pisno vodenem postopku možnost predstaviti svoja stališča in trditve, vključno s svojimi dokazi na način, ki ga ne postavlja v slabši položaj v primerjavi z naročnikom. Ob navedenem se je Državna revizijska komisija odločila, da v konkretni zadevi ustne obravnave ni potrebno izvesti, pri čemer pa je upoštevala tudi razloge učinkovitosti in gospodarnosti, saj bi izvedba ustne obravnave nepotrebno podaljšala (v obravnavanem primeru že tako dolg) postopek pravnega varstva.
V obravnavanem primeru vlagatelj zatrjuje, da je njegova ponudba skladna z vsemi tehničnimi zahtevami in je bila zato nezakonito izločena iz postopka oddaje predmetnega javnega naročila. Zatrjuje tudi, da je bila njegova ponudba (v delu, ki se nanaša na točki 3.1.6 in 1 dokumenta ePRO Specifikacije) v primerjavi s ponudbo izbranega ponudnika obravnavana neenakopravno. Prav tako tudi navaja, da je iz njegove ponudbe jasno razvidno, kakšen delež storitev bo izvedel vsak izmed partnerjev znotraj konzorcija.
V obravnavanem primeru je naročnik prejel dve ponudbi. Kot že izhaja iz te obrazložitve, je bila vlagateljeva ponudba, ki se je sicer uvrstila na prvo mesto, izločena iz več razlogov. Vlagateljeva ponudba je bila izločena kot nedopustna, ker ni izpolnila tehničnih zahtev iz naslednjih delov razpisne dokumentacije: 1). 3.1.6 tehničnih specifikacij (dokumenta ePRO Specifikacije), v delu, ki določa: »Tehnološko okolje SBI-PIS, strežniška in komunikacijska infrastruktura bo v celoti nameščena na centralno infrastrukturo znotraj DC SBI na način, da bo zagotovljeno popolno upravljanje s strani osebja IT bolnišnice. Ponujen sistem mora ponudnik povezati z obstoječim sistemom za varovanje podatkov naročnika (Veeam backup - stroški licenc so na strani naročnika).«, 2). tehnične zahteve iz točke 1 tehničnih specifikacij (dokumenta ePRO Specifikacije), v delu, ki določa: »V sklopu uvedbe je potrebno vzpostaviti enovit sistem, ki bo deloval na enotni podatkovni bazi, brez podvajanja podatkov, omogočal enotno vstopno točko za uporabnike z uporabo enega/enotnega uporabniškega vmesnika, to pomeni, da so vsi poslovni procesi med seboj povezani v enovit informacijski sistem.«, 3). tehnične zahteve iz točke 1 tehničnih specifikacij (dokumenta ePRO Specifikacije), v delu, ki določa: »SBI-PIS mora biti v vsakem trenutku skladen z veljavno zakonsko regulativo brez dodatnih stroškov za naročnika ne glede na to, ali je potreben razvoj ali zadošča nastavljanje parametrov.«, 4). tehnične zahteve iz točke 2.1 tehničnih specifikacij (dokumenta ePRO Specifikacije), v delu, ki določa: »Naročnik zahteva informacijsko rešitev, ki mu bo omogočala čim več samostojnosti in prožnosti pri definiranju in spreminjanju informatiziranih poslovnih procesov.«, 5). tehnične zahteve iz točke 3.1.3 tehničnih specifikacij (dokumenta ePRO Specifikacije), v delu, ki določa: »Skrbniški modul, ki bo del SBI-PIS, bo vsebinskim administratorjem oziroma skrbnikom sistema dosegljiv preko uporabniškega vmesnika in bo omogočal nastavljati in konfigurirati sistem. Predvsem bo namenjen upravljanju z uporabniki in pravicami dostopa ter upravljanju šifrantov ter tudi nastavitvam vnaprej pripravljenih poročil in analiz.« Vlagateljeva ponudba je bila izločena tudi zato, ker v partnerski pogodbi ni navedel deleža storitev, ki jih prevzame vsak posamezni partner (4. točka Navodila ponudnikom - obrazec ePRO).
Naročnikovo ravnanje z vlagateljevo ponudbo je treba presojati z vidika 29. točke prvega odstavka 2. člena ZJN-3, ki določa, da je ponudba dopustna, kadar so izpolnjeni naslednji pogoji:
- ponudba je predložena pravočasno,
- za ponudnika ne obstajajo razlogi za izključitev (75. člen ZJN-3),
- ponudnik je izpolnil pogoje za sodelovanje (76. člen ZJN-3),
- ponudba ustreza potrebam in zahtevam naročnika, določenim v tehničnih
specifikacijah in v dokumentaciji v zvezi z oddajo javnega naročila,
- v zvezi s ponudbo ni dokazano nedovoljeno dogovarjanje ali korupcija,
- ponudba ni neobičajno nizka,
- ponudba ne presega zagotovljenih sredstev naročnika.
V skladu s prvim odstavkom 89. člena ZJN-3 (pregled in ocenjevanje ponudb ter način oddaje javnega naročila) naročnik odda javno naročilo na podlagi meril, potem ko preveri, da so izpolnjeni naslednji pogoji:
- ponudba je skladna z zahtevami in pogoji, določenimi v obvestilu o javnem naročilu ter v dokumentaciji v zvezi z oddajo javnega naročila, po potrebi ob upoštevanju variant iz 72. člena ZJN-3, in
- ponudbo je oddal ponudnik, pri katerem ne obstajajo razlogi za izključitev iz 75. člena ZJN-3 in izpolnjuje pogoje za sodelovanje ter izpolnjuje pravila in merila iz 82. in 83. člena ZJN-3, če so bila določena.
Iz citiranih določil ZJN-3 izhaja, da mora ponudba ustrezati tudi tistim zahtevam naročnika, ki se nanašajo na predmet naročila in jih naročnik določi s tehničnimi specifikacijami. V skladu s 23. točko prvega odstavka 2. člena ZJN-3 pomenijo tehnične zahteve specifikacijo v dokumentu, ki opredeljuje zahtevane značilnosti proizvoda ali storitve, kot so ravni kakovosti, okoljskih in podnebnih vplivov, zahteve v zvezi z oblikovanjem, prilagojenim vsem uporabnikom, ter ocenjevanje skladnosti, zahteve v zvezi z delovanjem, uporabo proizvoda, varnostjo ali dimenzijami, vključno z zahtevami v zvezi s proizvodom glede imena, pod katerim se prodaja, izrazoslovjem, simboli, preizkušanjem in preizkusnimi metodami, pakiranjem, označevanjem, uporabo znakov, navodili za uporabnike, proizvodnimi postopki in metodami na posamezni stopnji življenjske dobe blaga ali storitve, ter postopki ocenjevanja skladnosti. S tehničnimi specifikacijami naročnik v skladu z 68. členom ZJN-3 opredeli oziroma opiše predmet naročila. Z njimi točno opredeli lastnosti predmeta javnega naročila oziroma specificira zahtevane značilnosti predmeta, kot npr. stopnjo kakovosti, uporabljene materiale, dimenzije, tehnične parametre, proizvodne postopke, okoljske lastnosti, stopnjo varnosti itd. Gre za zahtevane značilnosti 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.
Predmet obravnavanega javnega naročila je nakup, implementacija in vzdrževanje novega informacijskega sistema za upravljanje in razvoj procesov dela Splošne bolnišnice Izola pod akronimom SBI-PIS. Podrobna specifikacija razpisanih storitev je navedena v dokumentu SBI-PIS (Tehnološke in vsebinske zahteve), in sicer na 62 straneh.
Državna revizijska komisija je najprej presojala tiste vlagateljeve očitke, ki se nanašajo na točko 3.1.6 strokovnih zahtev. Kot namreč že izhaja iz te obrazložitve, je bila vlagateljeva ponudba izločena (med drugim tudi) iz razloga, ker ponujena storitev ni skladna z zahtevo iz te točke oziroma iz razloga, ker je (kot je zapisal naročnik v izpodbijani odločitvi) »del rešitve (najmanj sistem za varovanje podatkov naročnika) predviden na lokaciji izvajalca (PS-DC Maribor)«. Naročnik je tudi navedel, da je iz opisa ponujene rešitve (Slika 1 - infrastrukturna topologija končne postavitve hibridne oblačne rešitve za SBI-PIS) nedvoumno razvidno, da ponujena rešitev ni skladna z zahtevami iz točke 3.1.6. Enako je razvidno tudi iz Slike 6, iz katere izhaja, da je ponujena rešitev backup lokacije na infrastrukturi partnerja v konzorciju - družbe Pošta Slovenije d.o.o., Maribor, navedeno pa izhaja tudi iz opisa na 9. strani istega dokumenta, kjer je vlagatelj zapisal, da Veeam Backup&Replication server skrbi za Backup replik virtualnih strežnikov v oddaljeno okolje in varne podatkovne centre družbe Pošta Slovenije d.o.o., Maribor.
Vlagatelj v tem delu zahtevka za revizijo zatrjuje, da je ponudil rešitev, ki v celoti ustreza tehničnim zahtevam oziroma da je ponudil »on-premise« rešitev, vključno z varovanjem podatkov (backup), v zvezi s katerim je ponudil navezavo na obstoječi sistem, kot je to zahteval naročnik. Navedeno naj bi bilo razvidno iz Slike 2 in 5 dokumenta »PS_Arhitektura SBI_PIS.pdf«, dodatno pa je ponudil še sistem za okrevanje po katastrofi t.i. Disaster Recovery, ki pa je predviden na drugi lokaciji, saj že po naravi stvari ne more biti na isti lokaciji kot celoten sistem.
Naročnik je v točki 3.1.6 (Tehnološko okolje SBI-PIS) postavil naslednje zahteve:
»Naročnik v sklopu javnega naročila kupuje vso potrebno strežniško infrastrukturo. Naročnik zagotovi primeren strežniški prostor za namestitev fizične strežniške opreme za SBI-PIS v sklopu obstoječega DC. Naročnik pričakuje razpoložljivost sistema, ki ne sme nikoli biti manjša od 99,9 %.
Tehnološko okolje SBI-PIS, strežniška in komunikacijska infrastruktura bo v celoti nameščena na centralno infrastrukturo znotraj DC SBI na način, da bo zagotovljeno popolno upravljanje s strani osebja IT bolnišnice. Ponujeni sistem mora ponudnik povezati z obstoječim sistemom za varovanje podatkov naročnika (Veeam backup - stroški licenc so na strani naročnika). Ponudnik mora tehnološko okolje načrtovati in dimenzionirati na način, da bo brez kakršnihkoli nadgradenj delovalo v skladu s pričakovanimi performančnimi specifikacijami programske opreme za dobo, ki ne sme biti krajša od 7 let, z možnostjo nadgradnje ter podaljšanja življenjske dobe od 7-10 let.
Naročnik predvideva tudi možnost več strežniških postavitev SBI-PIS. Poleg namestitve na primarni lokaciji se naročnik lahko odloči tudi za namestitev celotnega sistema ali njegovega dela na lokacijo nadomestnega centra (kolokacija - DRC namestitev ni del ponudbe). Ponujena rešitev mora ustrezati merilom tehnološke sodobnosti, kar pomeni uporabo preizkušenih, uporabljenih in sodobnih tehnologij, ki se nadgrajujejo s strani dobaviteljev.
Za potrebe upravljanja z mobilnimi napravami in zagotavljanja potrebnega varnostnega nivoja mora ponudnik ponuditi celovit sistem za upravljanje mobilnih naprav (EMM). Podpora mora biti za mobilne operacijske sisteme (iOS, Windows in Android), ki jih bolnišnica uporablja.«
Tekom pojasnjevanja razpisne dokumentacije so bila v zvezi s citiranimi zahtevami postavljena tudi naslednja vprašanja (vprašanja in naročnikovi odgovori nanje so bili objavljeni na Portalu javnih naročil dne 14. 5. 2018):
»Naročnik predvideva tudi možnost namestitve na nadomestni lokaciji. Ali je ta lokacija mišljena pri naročniku ali je lahko izven naročnikove lokacije? Ali je ta del, torej namestitev na nadomestni lokaciji predmet ponudbe in rešitve ali ne? Ali mora biti postavitev na nadomestni lokacij performančno enako zmogljiva z enakimi odzivnimi časi ali kako drugače?
Kako je s sistemi varovanja podatkov (backup)? Ali se uporabijo obstoječi (in kateri so) ali jih mora ponuditi naročnik (HW in SW)?«
Naročnik je odgovoril z naslednjimi pojasnili:
»Naročnik pričakuje rešitev, ki omogoča tudi celotno namestitev na nadomestni lokaciji, ki je lahko nameščena na njegovi trenutni lokaciji ali izven. Namestitev ni del ponudbe JN.
Uporabi se obstoječi sistem za varovanje podatkov (Veeam backup).«
Nadalje je naročnik v 1. točki strokovnih zahtev (SBI-PIS - Tehnološke in vsebinske zahteve) zapisal, da vzpostavitev SBI-PIS med drugim obsega tudi:
»Nakup izdelanega produkta in potrebne infrastrukture (kar vključuje tudi sistemsko strojno in programsko opremo, kot so strežniki, diskovni podsistemi, brez aktivne opreme za LAN in brez končnih klientov - osebnih/prenosnih računalnikov, tablic in mobilnih naprav, tiskalnikov, skenerjev ipd.), ki je skladen z zahtevami naročnika iz specifikacij javnega naročila. V sklopu vzpostavitve SBI-PIS so zajete tudi storitve nastavljanja izdelanega produkta, integracije z drugimi informacijskimi sistemi ter nameščanje na infrastrukturo.«
Državna revizijska komisija se je pri presoji navedenega očitka oprla zlasti na mnenje strokovnjaka, ki je na postavljeni vprašanji (»Ali vlagateljeva ponudba izpolnjuje zgoraj citirano zahtevo naročnika oziroma ali je vlagatelj (kot navaja) v celoti ponudil »on premise« rešitev, kar velja tudi za varovanje podatkov (back up), v zvezi s katerim je ponudil navezavo na naročnikov obstoječi (Veeam) sistem? Odgovorite nam še na vprašanje o tem, ali je tudi izbrani ponudnik (kot navaja vlagatelj) ponudil sistem za okrevanje po katastrofi, ki se nahaja izven naročnikove lokacije?«) odgovoril, da vlagateljeva ponudba ne ustreza vsem zahtevam iz točke 3.1.6 ter da iz ponudbe izbranega ponudnika ni razvidno, da bi ponudil ločen sistem za okrevanje po katastrofi izven naročnikove lokacije.
Strokovnjak je uvodoma pojasnil, da je vlagatelj ponudil »hibridno« oblačno rešitev, temelječ na Azure Stack platformi, takšna rešitev pa ne zagotavlja popolne neodvisnosti naročnikovega podatkovnega centra od infrastrukture ponudnika oblačnih storitev. Strokovnjak je tudi navedel, da je v ponujeni rešitvi nakazano, da se del podatkov (najmanj varnostne kopije podatkov) prenaša na infrastrukturo podatkovnega centra družbe Pošta Slovenije d.o.o., Maribor. Strokovnjak je ob tem še opozoril, da tudi orodje za upravljanje mobilnih naprav (EMM) v ponudbi nima zagotovljenih potrebnih strojnih zmogljivosti na strani naročnika in je zato mogoče sklepati, da navedeno orodje ravno tako ne bo nameščeno na infrastrukturi naročnika.
Strokovnjak je pojasnil, da je vlagatelj v dokumentu »PS_Arhitektura SBI-PIS.pdf« navedel potrebne strojne računalniške (strežniške) zmogljivosti, na katerih je načrtovano delovanje storitev. Iz dokumenta »Ponudbeni predračun s specifikacijo.pd« ter iz načina opisovanja arhitekture v dokumentu »PS_Arhitektura SBI-PIS.pdf« je razvidno, da zahtevane strojne zmogljivosti (strojno-strežniško opremo) za projekt zagotovi vlagatelj ter da so predvidene zmogljivosti strojne opreme in potrebna licenčna programska oprema navedene za naslednje elemente rešitve: 1. za poslovno informacijski sistem MS Dynamics NAV - Azure Stack oblačna platforma, strežniške zmogljivosti za aplikacijski strežnik NST, strežniške zmogljivosti delovanja baze podatkov - SQL 2018 Ent 64 bit in strežniške ter diskovne zmogljivosti za spletni strežnik, 2. za BIS - Green Cube - strežniške in diskovne zmogljivosti za podatkovne baze, strežniške in diskovne zmogljivosti za spletni strežnik, potrebno licenčno programsko opremo, komunikacijski prehodi - strežniki, strežniki za poročanje, strežniki za zbiranje dnevniških zapisov (dogodkov) in strežnik za storitve oddaljenega dostopa. Strokovnjak je pri pregledu vlagateljeve ponudbe še ugotovil, da za varovanje okolja in podatkov (backup, DR) in za upravljanje mobilnih naprav (EMM) potrebne strojne zmogljivosti niso navedene. Ob upoštevanju navedenega je strokovnjak zaključil, da specificirane zmogljivosti oziroma strojno opremo dobavi vlagatelj ter jo namesti v naročnikovem podatkovnem centru (»on premise«), potrebne zmogljivosti za gostovanje storitev »varovanje okolja in podatkov« ter »upravljanje mobilnih naprav (EMM)« pa naj bi vlagatelj zagotovil na drug način (to je »off premise«). Strokovnjak je ob tem še opozoril, da so morali ponudniki ob upoštevanju zgoraj citiranih zahtev, v ponudbi dimenzionirati zmogljivosti strojne opreme za najmanj 7 let delovanja brez potrebnih nadgradenj, kar se nanaša tudi na pomnilniške zmogljivosti za varovanje podatkov novega sistema SBI-PIS, pri čemer so morale biti vse zmogljivosti nameščene na lokaciji naročnika in integrirane v naročnikov sistem upravljanja varnostnih kopij Veeam ter da sta morali biti ponujena strojna oprema in arhitektura oblikovani modularno oziroma na način, ki bo naročniku omogočil prenos na drugo lokacijo, če bi se za to odločil.
Strokovnjak je v nadaljevanju tudi navedel, da je vlagatelj v svoji ponudbi (v dokumentu »PS_ Arhitektura SBI-PIS.pdf«) opisal različne možne implementacije Microsoft AzureStack platforme, in sicer: v obliki javnega oblaka, ki temelji na infrastrukturi (strežniška in diskovna) ponudnika oblačnih storitev (vsi podatki se nahajajo pri ponudniku), v obliki privatnega oblaka, ki temelji na infrastrukturi naročnika (vsi podatki se nahajajo pri naročniku) in v obliki hibridnega oblaka, ki temelji na kombinaciji infrastrukture naročnika in ponudnika oblačnih storitev (v tem primeru se podatki lahko nahajajo na infrastrukturi naročnika ali ponudnika ali hkrati na obeh infrastrukturah). Strokovnjak je ugotovil, da je vlagatelj v svoji ponudbi predvidel hibridno verzijo oblačne infrastrukture, ki sloni na Azure Stack platformi (pri čemer je opozoril, da se mora navedena platforma, nameščena na privatni oblačni infrastrukturi, zaradi zahtev Microsofta (licenciranje, prijava uporabnikov, telemetrijski podatki …) vsaj občasno povezovati v javni oblak). Pojasnil je, da naj bi bil privatni (zasebni) del oblačnih storitev nameščen na infrastrukturi v podatkovnem centru naročnika (SBI-PIS), drugi del oblačnih storitev pa bi se naj izvajal na infrastrukturi vlagatelja oziroma na infrastrukturi podatkovnega centra družbe Pošta Slovenije d.o.o., Maribor. Poleg tega na hibridni oblačni strukturi sloni tudi »Intune« platforma za upravljanje mobilnih naprav, kar je vlagatelj potrdil tudi v poglavju 4.1 Idejni načrt, postavka 30.EMM (dokumenta »ePRO_specifikacije N.pdf«), kjer je navedel, da celotna sistemska podpora orodjem in posameznim rešitvam temelji na kombinaciji privatnega in javnega Azure oblaka in da je tudi upravljanje mobilnih naprav podprto s storitvijo iz tega okolja, pri čemer se predvideva uporaba orodja Intune.
Ob upoštevanju strokovnega mnenja se je potrebno strinjati z naročnikom v tem, da vlagateljeva ponudba ni dopustna oziroma da iz vlagateljeve ponudbe izhaja, da se del podatkov nahaja na lokaciji enega izmed vlagateljevih soponudnikov, kar ni skladno z zgoraj citiranimi strokovnimi zahtevami iz točke 3.1.6. Vlagatelj v zvezi s tem sicer pravilno opozarja, da je naročnik v točki 3.1.6 tudi zapisal, da se lahko, poleg namestitve na primarni lokaciji, odloči tudi za namestitev celotnega sistema ali njegovega dela na lokaciji nadomestnega centra, vendar pa bi se za takšno možnost lahko odločil le naročnik. Poleg tega je naročnik v zvezi s tem pravilno opozoril, da (v skladu z zgoraj citiranimi Tehnološkimi in vsebinskimi zahtevami, ki se nanašajo na vzpostavitev SBI-PIS) »najem lokacije - kolokacije izrecno ni predmet obravnavanega javnega naročila«, iz navedenih strokovnih zahtev pa je prav tako tudi razvidno, da komunikacijska oprema ni predmet obravnavanega javnega naročila. Četudi naročnik ni izrecno zapisal, da se podatki ne smejo hraniti izven bolnišnice, pa je naročnik v zgoraj citiranih zahtevah iz točke 3.1.6 jasno in izrecno zapisal: »Tehnološko okolje SBI-PIS, strežniška in komunikacijska infrastruktura bo v celoti nameščena na centralno infrastrukturo znotraj DC SBI na način, da bo zagotovljeno popolno upravljanje s strani osebja IT bolnišnice. Ponujeni sistem mora ponudnik povezati z obstoječim sistemom za varovanje podatkov naročnika (Veeam backup - stroški licenc so na strani naročnika).« Naročnik zato pravilno ugotavlja, da če mora biti vsa oprema pri naročniku, ni možnosti, da se podatki nahajajo kjerkoli drugje oziroma da iz zapisa »zagotavljanja popolnega upravljanja s strani osebja IT bolnišnice« in dejstva, da mora biti »tehnološko okolje v celoti nameščeno na centralni infrastrukturi znotraj DC SBI«, to že po naravi stvari ne more biti drugače oziroma da takoj, ko so podatki kje drugje, to pomeni, da je del tehnološkega okolja SBI-PIS, strežniška in komunikacijska infrastruktura nameščena drugje, kar pa je bilo ob upoštevanju citirane zahteve izrecno prepovedano. Naročnik pa je poleg tega (kot že izhaja iz te obrazložitve) tudi pravilno ugotovil, da je eden izmed vlagateljevih partnerjev (družba Pošta Slovenije d.o.o., Maribor) med drugim zadolžen tudi za komunikacijsko infrastrukturo (aktivna oprema za LAN), ki pa skladno z zgoraj citiranimi zahtevami (iz 1. točke strokovnih zahtev - SBI-PIS - Tehnološke in vsebinske zahteve), sploh ni bila predmet ponudbe.
Iz obrazložitve izpodbijane odločitve sicer res ni izrecno razvidno, da je tudi mobilna aplikacija ponujena v kombinaciji privatnega in javnega oblaka oziroma da tudi ta rešitev komunicira z lokacijo izven lokacij naročnika, a je iz nje vendarle razvidno, da je vlagateljeva ponudba nedopustna iz razloga, ker je »… iz končne postavitve hibridne oblačne rešitve za SBI-PIS razvidno, da je del rešitve (najmanj sistem za varovanje podatkov naročnika) predviden na lokaciji izvajalca.«
Ker je vlagatelj v zahtevku za revizijo tudi navedel, da je (glede na to, da je sistem za okrevanje po katastrofi v sodobni informacijski opremi pri tovrstnih sistemih nujen in iz razloga, ker tak sistem že po naravi stvari ne more shranjevati podatkov na isti lokaciji, na kateri je nameščen sistem) prepričan, da je Disaster Recovery s shranjevanjem podatkov na oddaljeni lokaciji predvidel tudi izbrani ponudnik, je Državna revizijska komisija strokovnjaka pozvala, naj odgovori tudi na vprašanje, ali je tudi izbrani ponudnik ponudil sistem za okrevanje po katastrofi, ki se nahaja izven naročnikove lokacije?
Strokovnjak je navedel, da iz prejete dokumentacije ni razvidno, da bi izbrani ponudnik ponudil ločen sistem za okrevanje po katastrofi izven naročnikove lokacije. Strokovnjak je pojasnil, da iz ponudbene dokumentacije izbranega ponudnika niso razvidne ponujene zmogljivosti strojne opreme (strežniške, diskovne), niti logična arhitektura ponujenega sistema (z izjemo opisa produktov Router in SAPWebdispather). Zlasti pa je strokovnjak v dopolnitvi strokovnega mnenja tudi opozoril (o čemer se je z vpogledom v ponudbo izbranega ponudnika prepričala tudi Državna revizijska komisija) na izjavo izbranega ponudnika, ki jo je podal v dokumentu »20180829_SBI_Idejna_Resitev_BV1.pdf (točka 10.4 - Pokritje s tehnološko vsebinskimi zahtevami). Izbrani ponudnik je namreč v tem delu ponudbe izrecno zagotovil, da izpolnjuje vse pogoje iz točke 3.1.6 (Tehnološko okolje SBI-PIS) oziroma je med drugim tudi navedel, da ponujeno tehnološko okolje SBI-PIS sicer omogoča celotno namestitev sistema na lokaciji nadomestnega centra oziroma da je tehnološko okolje 100 % možno povezati z DRC, vendar pa je ob tem izrecno opozoril, da DRC namestitev ni del ponudbe oziroma da DRC funkcionalnost v ponudbi ni predvidena.
Iz obrazložitve izpodbijane odločitve je razvidno, da je bila vlagateljeva ponudba izločena tudi iz razloga, ker ni izpolnil vseh zahtev iz točke 1 dokumenta ePRO Specifikacije.
Naročnik je v točki 1 dokumenta ePRO Specifikacije postavil naslednje zahteve:
»Predmet javnega naročila je vzpostavitev informacijskega sistema za upravljanje in razvoj procesov dela Splošne bolnišnice Izola pod akronimom SBI-PIS. V sklopu uvedbe je potrebno vzpostaviti enovit sistem, ki bo deloval na enotni podatkovni bazo, brez podvajanja podatkov, omogočal enotno vstopno točko za uporabnike z uporabo enega/enotnega uporabniškega vmesnika, to pomeni, da so vsi poslovni procesi med sabo povezani v enovit informacijski sistem.«
Naročnik je v obrazložitvi izpodbijane odločitve navedel, da je vlagatelj ponudil štiri različne informacijske sisteme, ki jih namerava integrirati (1. bolnišnični informacijski sistem Green Cube partnerja Tich, 2. obračunski sistem (Billing) partnerja Sicom, 3. Dokumentarni sistem partnerja IN2 in 4. ERP sistem partnerja IN2). Naročnik je tudi zapisal, da je iz opisa sistema razvidno, da ne bo deloval na enotni podatkovni bazi, sistem pa bo imel za navedene rešitve različne uporabniške vmesnike. Vlagatelj po naročnikovem mnenju ni ponudil enovitega informacijskega sistema, temveč 4 različne (po zasnovi in strukturi popolnoma ločene), vendar med seboj integrirane informacijske sisteme, zaradi česar se bodo določeni podatki podvajali, kar pa v razpisni dokumentaciji ni bilo dovoljeno. Naročnik je tudi navedel, da iz vlagateljeve ponudbe ni razvidno, da zagotavlja enotno vstopno točko za uporabnike z uporabo enega/enotnega uporabniškega vmesnika. Nasprotno, vlagatelj se z naročnikom ne strinja in navaja, da ni ponudil 4 različnih sistemov, temveč bo po izvedeni integraciji sistem enovit, sestavljen iz 4 komponent oziroma modulov. Vsi 4 moduli bodo delovali na enotni bazi podatkov (Microsoft SQ Server) iste različice, na enotnem strežniku. Vlagatelj tudi opozarja, da naročnik ni zahteval, da morajo biti vsi sestavni deli enovitega sistema po zasnovi in strukturi enaki. Predvsem pa obstoj ločenih modulov ne pomeni, da se bodo kakršnikoli podatki podvajali, saj je predvidena takšna integracija, pri kateri podvajanja ne bo. Vlagatelj tudi zatrjuje, da bodo vsi moduli ponujenega sistema dostopni z vstopom skozi skupno/enotno vstopno točko oziroma meni modula Green Cube, saj se vse poslovne funkcije Microsoft Dynamics NAV odprejo preko te vstopne točke brez posebne avtentifikacije/prijave (kar je vidno v opisu funkcije Green Cube). Poleg tega je vlagatelj opozoril, da je izbrani ponudnik prav tako ponudil enovit sistem, sestavljen iz več sistemov/modulov, in sicer ponuja najmanj kombinacijo SAP Core, SAP Health Industry specific, Cerner Medical module in Common MS medical User Interface. Kot ugotavlja vlagatelj, so tudi to moduli, od katerih vsak služi svojemu namenu zadovoljevanju različnih funkcionalnosti in imajo v principu vsak svojo zasnovo in strukturo ter jih je v enovit sistem potrebno integrirati. Vlagatelj zato meni, da je bila (že) ob navedenem oziroma ob upoštevanju načela enakopravnega obravnavanja, njegova ponudba nedopustno izločena.
Državna revizijska komisija se je tudi pri presoji tega očitka oprla na mnenje strokovnjaka. Državna revizijska komisija je strokovnjaka pozvala, naj poda svoje strokovno mnenje o tem, ali vlagateljeva ponudba izpolnjuje zgoraj citirane zahteve iz točke 1 dokumenta ePRO Specifikacije. Hkrati ga je zaprosila, naj v zvezi s tem preveri še ponudbo izbranega ponudnika, vendar ga je pri tem opozorila, naj dosledno upošteva vlagateljeve očitke iz zahtevka za revizijo.
Strokovnjak je navedel, da vlagateljeva ponudba ni izpolnila vseh zahtev iz te točke. Strokovnjak je uvodoma pojasnil, da je možnih več interpretacij besedne zveze »enovit informacijski sistem«, vendar se je za potrebe izdelave mnenja naslonil na usmeritev v vprašanju Državne revizijske komisije, v katerem je besedna zveza »enovit informacijski sistem« definirana z: 1. enotna podatkovna baza, 2. brez podvajanja podatkov, 3. enotna vstopna točka za uporabnike, 4. en/enoten uporabniški vmesnik in 5. povezava vseh poslovnih procesov. Strokovnjak je navedel, da vlagateljeva ponudba ni izpolnila vseh zahtev iz te točke oziroma da ni izpolnila zahteve v delu, ki se nanaša na enotno podatkovno bazo in na en/enoten uporabniški vmesnik. Kot že izhaja iz te obrazložitve, je strokovnjak svoje strokovno mnenje v delu, ki se nanaša na enotno podatkovno bazo z dopolnitvijo strokovnega mnenja popravil, in sicer je ugotovil, da je vlagatelj ponudil štiri baze na štirih strežnikih (in torej ne tri baze na treh strežnikih, kot je zapisal predhodno), vendar pa je v obeh primerih tudi izrecno in jasno zapisal, da vlagatelj ni ponudil enotne podatkovne baze oziroma da vlagateljeva ponudba v tem delu ni skladna z naročnikovo zahtevo iz razpisne dokumentacije (Državna revizijska komisija zato v tem delu povzema ugotovitve strokovnjaka iz dopolnitve strokovnega mnenja). Strokovnjak je pojasnil, da je iz vlagateljeve ponudbe razvidno, da je ponudil štiri baze na štirih strežnikih, in sicer 1. na podvojenih strežnikih za podatkovne baze (pri čemer je opozoril, da se podvojena baza v tem oziru šteje kot ena), 2. na komunikacijskem strežniku, 3. na strežniku za poročanje in 4. na strežniku za zbiranje dogodkov (long server). Navedel je, da je iz opisa komunikacijskega strežnika mogoče sklepati, da predstavlja vmesnik za prevajanje in izmenjavo podatkov iz naročnikovih naprav z drugačnimi komunikacijskimi protokoli (HL7) ter ponujenimi aplikativnimi rešitvami vlagatelja. Ugotovil je, da ima tudi ta strežnik predvideno svojo bazo (MS SQL 2016 std. 64 bit), vendar je ta prehodnega značaja in ni predvidena za daljšo hrambo podatkov. Strokovnjak je tudi pojasnil, da so zapisi revizijskih sledi in seznami registriranih uporabnikov shranjeni v ločeni bazi podatkov (strežnik za zbiranje dogodkov) in da podobno velja tudi za poročila (strežnik za poročanje).
Strokovnjak se je strinjal z naročnikom tudi v delu, ki se nanaša na en/enoten uporabniški vmesnik oziroma je tudi v tem delu pritrdil naročniku v tem, da vlagateljeva ponudba ni dopustna. Kot je pojasnil, »enoten« uporabniški vmesnik definira predvsem enaka uporabniška izkušnja vseh uporabnikov, ne glede na funkcije, ki jih uporabljajo. Navedel je, da se pri grafičnih vmesnikih le te manifestirajo: 1. v enaki vizualni podobi (barva ozadja, robov, gumbov, velikosti in tip napisov, pogovorna okna) in 2. v enakem obnašanju ekranskih elementov (obstoj in obnašanje stranskih drsnikov, orodne vrstice, meniji - enako obnašanje istovrstnih funkcij, npr. tiskanje, vrstni in spustni meniji, učinek spremembe velikosti okna na elemente - npr. »responsive design«) in 3. v enkratni prijavi. Strokovnjak je navedel, da so skladno z opisom ponujene arhitekture in navedbami vlagatelja (iz zahtevka za revizijo) vsi moduli dostopni skozi meni modula Green Cube, preko katerega se odprejo tudi vse poslovne funkcije modula Microsoft Dynamics NAV brez dodatne avtentikacije, na podlagi česar je mogoče ugotoviti, da ponujena rešitev ne ustreza vsem točkam definicije enotnega uporabniškega vmesnika. Kljub zagotovitvi enkratne prijave se grafični uporabniški vmesnik modula Green Cube po naravi razlikuje od predlog vmesnikov, ki jih omogoča platforma Microsoft Dynamics NAV. To vlagateljevo navedbo pa je mogoče razumeti kot potrditev, da ponujena rešitev vsebuje najmanj dva uporabniška vmesnika.
Ni pa strokovnjak zmogel odgovoriti tudi na vprašanje, ali je vlagatelj ravnal v skladu z zahtevo, ki se nanaša na prepoved podvajanja podatkov. Strokovnjak je namreč v tem delu navedel, da enoličen odgovor ni mogoč. Pojasnil je, da sta iz tehničnega vidika mogoči najmanj dve interpretaciji te zahteve - bodisi kot preprečitev zapisa istega podatka na dveh mestih ali pa kot preprečitev uporabnikovega vnosa istega podatka več kot enkrat. Strokovnjak je navedel, da je iz vlagateljeve ponudbe razviden obstoj več kot ene baze, zato ni mogoče izključiti podvajanja oziroma obstoja manjšega nabora podatkov na več kot enem mestu. Ob predpostavki, da se je naročnik s to zahtevo želel izogniti večkratnim vpisom istih podatkov s strani uporabnikov oziroma omogočiti uporabnikom uporabo vseh obstoječih podatkov v SBI-PIS, pa je vlagatelj zagotovil, da uporabniki v ponujeni rešitvi podatke vnašajo samo enkrat in jih hranijo v isti bazi. Ob navedenem, zaključuje strokovnjak, enoličen odgovor (potrditev ali zavrnitev izpolnjevanja te zahteve) ni mogoč.
Strokovnjak je v obravnavanem delu preveril tudi ponudbo izbranega ponudnika, pri čemer je, na kar ga je opozorila Državna revizijska komisija, upošteval (le) tiste vlagateljeve očitke, ki jih je navedel v zahtevku za revizijo. Vlagatelj je v tem delu zahtevka za revizijo navedel, »… da je tudi izbrani ponudnik, ki nastopa v konzorciju treh ponudnikov, ponudil enovit sistem, sestavljen iz več (pred predvideno integracijo samostojnih) sistemov/modulov, in sicer ponuja najmanj kombinacijo SAP Core, SAP Health Industry specific, Cerner Medical module, Common MS medical User Interface. Tudi to so moduli, od katerih vsak služi zadovoljevanju različnih funkcionalnosti in imajo v principu vsak svojo zasnovo in strukturo ter jih je v enovit sistem potrebno integrirati.« Strokovnjak je ugotovil, da ponudba izbranega ponudnika temelji na izbranih gradnikih (namensko razvitih za potrebe bolnišničnih in ne bolnišničnih procesov) v okviru platforme proizvajalca SAP. Poleg okvira SAP in produkta istega proizvajalca SAP IS-H v rešitvi izbranega ponudnika nastopajo tudi produkti drugih proizvajalcev (npr. Cerner i.s.h. med), ki pa so razviti v skladu s »SAP« arhitekturo ter delujejo kot razširitev »SAP« okolja. Ponudba izbranega ponudnika je zato dopustna, saj temelji na eni (podvojeni) visokozmogljivi podatkovni zbirki (bazi) z imenom »SAP HANA«. Arhitektura in delovanje podatkovne zbirke sta posebej prilagojena za povezovanje, črpanje in obdelavo podatkov iz drugih virov (»extract«, »transform«, »load« oziroma »data provisioning«).
Ob vsem navedenem (zlasti ob upoštevanju strokovnega mnenja in njegove dopolnitve) naročniku ni mogoče očitati kršitve pravil ZJN-3 in lastne razpisne dokumentacije, ko je vlagateljevo ponudbo na podlagi ugotovitve, da ni izpolnil vseh zahtev iz točk 3.1.6 in 1 dokumenta ePRO Specifikacije, izločil iz postopka. Prav tako naročniku v obeh spornih delih ni mogoče očitati, da sta bili ponudbi (vlagatelja in izbranega ponudnika) obravnavani neenakopravno. Državna revizijska komisija na podlagi teh ugotovitev ni obravnavala drugih revizijskih navedb, saj njihova vsebinska presoja ne bi več mogla vplivati na dejstvo, da je vlagateljeva ponudba nedopustna. Ker vlagateljeve ponudbe torej že iz navedenega razloga ni mogoče šteti kot dopustne, so vse njegove preostale navedbe (s katerimi očita naročniku, da je bila njegova ponudba nezakonito izločena tudi iz drugih razlogov), brezpredmetne. Presoja teh očitkov ne bi mogla več v ničemer vplivati niti na vlagateljev položaj niti na status njegove ponudbe, prav tako pa tudi ne na (drugačno) odločitev Državne revizijske komisije v obravnavani zadevi. Poleg tega vlagatelj v zvezi s temi očitki oziroma v teh delih zahtevka za revizijo tudi sicer ne zatrjuje, da naj bi imela enake pomanjkljivosti tudi ponudba izbranega ponudnika.
S tem je utemeljena odločitev Državne revizijske komisije iz 2. točke izreka tega sklepa.
Vlagatelj je zahteval povrnitev stroškov, nastalih v predrevizijskem in revizijskem postopku. Ker je zahtevek za revizijo neutemeljen, je Državna revizijska komisija, glede na določbo tretjega odstavka 70. člena ZPVPJN, zavrnila vlagateljevo zahtevo za povračilo stroškov, nastalih v postopku.
S tem je utemeljena odločitev Državne revizijske komisije iz 3. točke izreka tega sklepa.
V Ljubljani, dne 10. 5. 2019
Predsednik senata:
mag. Gregor Šebenik
član Državne revizijske komisije
Vročiti:
- Splošna bolnišnica Izola, Polje 40, Izola,
- Odvetniška družba Godec Černeka Nemec o.p., d.o.o., Železna cesta 14, Ljubljana,
- Telekom Slovenija d.d., Cigaletova ulica 15, Ljubljana,
- Itelis družba za svetovanje in informacijski inženiring d.o.o., Cesta v Gorice 1, Ljubljana,
- Common Management Solutions, S.L., Calle Chile 4, Las Rozas De Madrid, Španija,
- Republika Slovenija, Ministrstvo za javno upravo, Tržaška cesta 21, Ljubljana.
Vložiti:
- v spis zadeve, tu.