Dosje javnega naročila 006203/2020
Naročnik: POŠTA SLOVENIJE d.o.o., Slomškov trg 10, 2000 Maribor
Blago: Informacijska podpora logističnim procesom (IPLP)
ZJN-3: Postopek s pogajanji s predhodnim javnim razpisom

JN006203/2020-E01 - Obvestilo o naročilu - gospodarske javne službe (EU 5 - SL), objavljeno dne 08.10.2020
JN006203/2020-ODL01 - Odločitev o oddaji oz. neoddaji naročila, objavljeno dne 22.12.2020
Zahtevek za revizijo

    JN006203/2020-E01 Obvestilo o naročilu - gospodarske javne službe (EU 5 - SL) 2020/S 197-477977
   Dodatna pojasnila

Oddelek I: Naročnik

Direktiva 2014/25/EU
I.1 Ime in naslovi
POŠTA SLOVENIJE d.o.o.
Slomškov trg 10
2000
SI
Maribor
Slovenija
Sektor za investicije in nabavo, Irena Klis Presker
irena.klispresker@posta.si
+386 24492308
+386 24492379

Internetni naslovi
http://www.posta.si

I.2 Skupno javno naročanje
I.3 Sporočanje
Razpisna dokumentacija je na voljo brezplačno za neomejen in celovit neposredni dostop na:
URL: http://www.posta.si

Dodatne informacije lahko dobite na zgoraj navedenem naslovu.
Ponudbe ali prijave za sodelovanje je treba poslati elektronsko na URL: https://ejn.gov.si/ponudba/pages/aktualno/aktualno_javno_narocilo_podrobno.xhtml?zadevaId=21256
I.6 Glavna področja dejavnosti
Poštne storitve


Oddelek II: Predmet

II.1 Obseg naročila
II.1.1 Naslov
Naslov: Informacijska podpora logističnim procesom (IPLP)
Referenčna številka dokumenta: 0025/2020/0025/JNS/6
II.1.2 Glavna koda CPV
Glavni besednjak Dopolnilni besednjak
48900000
II.1.3 Vrsta naročila
Blago
II.1.4 Kratek opis
Predmet javnega naročila je implementacija rešitve za informacijskio podporo logističnim procesom in vzdrževanje rešitve.
II.1.6 Informacije o sklopih
Naročilo je razdeljeno na sklope: Ne
II.2 Opis
II.2.1 Naslov
II.2.2 Dodatna(-e) koda(-e) CPV
Glavni besednjak Dopolnilni besednjak
48900000
II.2.3 Kraj izvedbe
SI - SLOVENIJA
Glavna lokacija ali kraj izvedbe:
II.2.4 Opis javnega naročila
Informacijska podpora logističnim procesom (IPLP) družbe Pošta Slovenije.


II.2.5 Merila za izbiro ponudbe
Cena ni edino merilo za oddajo naročila in vsa merila so navedena le v razpisni dokumentaciji
II.2.6 Ocenjena vrednost
II.2.7 Trajanje naročila, okvirnega sporazuma ali dinamičnega nabavnega sistema
Trajanje v mesecih: 60
To naročilo je mogoče podaljšati: Ne
II.2.9 Informacije o omejitvah števila kandidatov, ki bodo povabljeni k sodelovanju
II.2.10 Informacije o variantah
Variante so dopustne: Ne
II.2.11 Informacije o variantah
Variante: Ne
II.2.12 Informacije o elektronskih katalogih
II.2.13 Informacije o sredstvih EU
Naročilo se nanaša na projekt in/ali program, ki se financira s sredstvi EU: Ne
II.2.14 Dodatne informacije


Oddelek III: Pravne, ekonomske, finančne in tehnične informacije

III.1 Pogoji za udeležbo
III.1.1 Ustreznost za opravljanje poklicne dejavnosti, vključno z zahtevami v zvezi z vpisom v register poklicev ali trgovski register
Razvidni iz razpisne dokumentacije
III.1.2 Poslovno in finančno stanje
Merila za izbor, kot so navedena v razpisni dokumentaciji
III.1.3 Tehnična in strokovna sposobnost
Merila za izbor, kot so navedena v razpisni dokumentaciji
III.1.4 Objektivna pravila in merila za sodelovanje


III.1.5 Informacije o pridržanih naročilih
III.1.6 Finančna zavarovanja
Garancija za dobro izvedbo pogodbenih obveznosti

III.1.7 Glavni pogoji financiranja in plačilna ureditev ter sklic na ustrezne določbe, ki jih urejajo
30 dni po prejemu računa

III.1.8 Pravna oblika, ki jo mora prevzeti skupina gospodarskih subjektov, ki ji bo naročilo oddano


III.2 Pogoji, ki se nanašajo na javno naročilo
III.2.1 Informacije o določeni stroki
III.2.2 Pogoji za izvedbo javnega naročila


III.2.3 Informacije o osebju, odgovornem za izvedbo naročila


Oddelek IV: Postopek

IV.1 Opis
IV.1.1 Vrsta postopka
Postopek s pogajanji s predhodnim javnim razpisom
IV.1.3 Informacije o okvirnem sporazumu ali dinamičnem nabavnem sistemu
Obvestilo vključuje sklenitev okvirnega sporazuma.
Okvirni sporazum z enim gospodarskim subjektom.
IV.1.4 Informacije o zmanjšanju števila rešitev ali ponudb med pogajanji ali dialogom
IV.1.6 Informacije o elektronski dražbi
IV.1.8 Informacije o Sporazumu o vladnih naročilih
Naročilo ureja Sporazum o vladnih naročilih: Ne
IV.2 Upravne informacije
IV.2.1 Prejšnja objava v zvezi s tem postopkom
IV.2.2 Rok za prejem ponudb ali prijav za sodelovanje
27.11.2020   12:00
IV.2.3 Predvideni datum pošiljanja povabil k oddaji ponudbe ali sodelovanju izbranim kandidatom
IV.2.4 Jeziki, v katerih se predložijo ponudbe ali prijave za sodelovanje
Slovenščina (SL)
IV.2.6 Minimalni časovni okvir, v katerem mora ponudnik zagotavljati veljavnost ponudbe
Ponudba mora biti veljavna do 30.06.2021
IV.2.7 Način odpiranja ponudb
Datum in ura:


Oddelek VI: Dopolnilne informacije

VI.1 Informacije o ponovitvah naročila
Ponovitev naročila: Da


VI.2 Informacije o elektronskem poteku dela
Sprejeto bo elektronsko izdajanje računov.
Uporabljeno bo elektronsko plačilo.
VI.3 Dodatne informacije
Rok za sprejemanje ponudnikovih vprašanj: 13.11.2020   12:00
VI.4 Postopki za revizijo
VI.4.1 Organ, pristojen za revizijo
DRŽAVNA REVIZIJSKA KOMISIJA ZA REVIZIJO POSTOPKOV ODDDAJE JAVNIH NAROČIL
Slovenska cesta 54
1000
Ljubljana
Slovenija

VI.4.2 Organ, pristojen za postopek mediacije
VI.4.3 Postopek revizije
VI.4.4 Služba, pri kateri lahko dobite informacije o postopku revizije
POŠTA SLOVENIJE d.o.o.
Slomškov trg 10
2000
Maribor
Slovenija

VI.5 Datum pošiljanja tega obvestila
06.10.2020

O odločitvi o javnem naročilu boste obveščeni, če odločitev ni bila objavljena pred vašo prijavo.


   Dodatna pojasnila
Datum objave: 14.10.2020   09:52
Celotna razpisna dokumentacija je ponudnikom na voljo nanaročnikovi spletni strani:

<https://www.posta.si/o-nas/javna-narocila-top/javna-narocila>



Datum objave: 12.11.2020   08:38

ODGOVORI NA VPRAŠANJA

Vprašanje 1: Datum prejema: 04.11.2020
Kateri sistem uporabljate za integracijo računov in financ? Je to S / 4 HANA ali kateri koli drug sistem?
Odgovor 1: Da, Pošta trenutno implementira SAP S/HANA ERP, za zaračunavanje bo uporabljen SAP Billing, sistem bo v produkciji v letu 2021.


Vprašanje 2.1: Datum prejema: 04.11.2020
Prosimo za dodatno pojasnitev tehnične funkcionalnosti pod številko 237: Kalkulacija lastnih stroškov / poizvedbenih dejanskih stroškov: Lastni stroški za prenos pošiljke morajo biti kalkulirani v IPLP za namene priprave ponudbe, preko uporabe distribucijskih scenarijev IN poizvedbeni dejanski stroški morajo biti kalkulirani glede na dejansko izvedene stroške (transporta, pretovora, skladiščenja, prevzema, transferjev...) Cena posamezne aktivnosti / procesa bo definirana v sistemu.
Odgovor 2.1: Naročnik predvideva, da bo imel s tem možnost izvajanja dveh analiz, na podlagi dejstva, da bo sistem za izvajanje optimizacij operiral tudi z atributi, kot so stroški transporta med točko A in B, kje so vozlišča, strošek aktivnosti na vozlišču (usmerjanje, crossdock):
Pričakujemo, da bomo imeli možnost simulirati naročilo, ki bo imelo X pošiljk (lahko s storitvami) in Y dostavnih točk, in da bo sistem zmožen predvideti, preko katerih vozlišč in s katerimi vozili bo naročilo izvedel ter katere operacije bodo morala vozlišča in terenski delavci izvesti, da bodo pošiljke dostavili. Ker bo sistem za posamezno aktivnost poznal lastni strošek, poznal pa bo tudi (načrtovano) pot, ki jo bo posamezna pošiljka izvedla pričakujemo, da bo sistem sposoben podati 'lastni strošek naročnika' za izvedbo tega naročila.
Drugo pričakovanje naročnika je, da ko se bo določeno naročilo dejansko izvedlo, bo sistem poznal celotno zgodovino dejansko izvedenih aktivnosti. Ker bo sistem za posamezno aktivnost poznal lastni strošek pričakujemo, da bo sistem sposoben izračunati 'dejanski lastni strošek naročnika' za izvedbo tega naročila.


Vprašanje 2.2: Ali imate dolgoročne tovorne sporazume z zunanjimi prevozniki za rezervacije pošiljk? Ali imate kakšno zahtevo za oddajo naročil za tovor z zunanjimi prevozniki?
Odgovor 2.2: Naročnik za izvajanje transporta uporablja tudi pogodbene prevoznike (podizvajalce). Ti nam vsak dan dajejo na voljo (pogodbeno) določeno število vozil, ki jih nato obremenimo v skladu z našimi trenutnimi potrebami. Ti vozniki izvajajo svoje delo z isto mobilno rešitvijo, kot vsi ostali terenski uslužbenci PS. Specifične zahteve, ki se nanašajo na delovanje pogodbenih prevoznikov, so predvsem 42, 43, 44 in 240. Predvidevamo pa, da bo potekala izmenjava podatkov o tvarini med sistemi PS (IPLP) in sistemi odvisnih družb (v obe smeri), ki predvideva predajo pošiljk (pod določenimi pravili) v izvajanje distribucije, in sicer preko primopredaje/prevzema v IPLP sistem. Distribucija se bo v tem primeru izvajala z uporabo IT podpore odvisnih družb, pri čemer bo potrebno zagotoviti prejetje povratne informacije v IPLP sistem. Povratne informacije se bodo morale zagotavljati v obe smeri med IPLP sistemom in sistemi odvisnih družb.


Vprašanje 2.3: Kako uporabljate IPLP za izračun stroškov prevoza? Ali ima IPLP shranjene zapise o stroških ali deluje le kot medij za oddajo stroškov s strani zunanjih prevoznikov?
Odgovor 2.3: Iz vprašanja ni razvidno, na katere funkcionalnosti se to nanaša, zato ne moremo podati dokončnega odgovora. Kljub navedenemu pa pojasnjujemo, da se morajo za aktivnost oz. procese v IPLPju, kjer se upoštevajo različni stroški, ti podatki zagotoviti v IPLP sistemu (primeri: izračun stroškov pogodbenega prevoznika v izbranem obdobju, priprava ponudbe za prevoz za prodajnike, optimizacija v primerih, kjer se upošteva kriterij stroškovne učinkovitosti, itd.).
Predvidevamo, da smo na to vprašanje delno odgovorili v odgovoru 2.1.


Vprašanje 3: Datum prejema: 04.11.2020
Prosimo za dodatno pojasnitev tehnične funkcionalnosti pod številko 237: Kalkulacija lastnih stroškov / poizvedbenih dejanskih stroškov: Lastni stroški za prenos pošiljke morajo biti kalkulirani v IPLP za namene priprave ponudbe, preko uporabe distribucijskih scenarijev IN poizvedbeni dejanski stroški morajo biti kalkulirani glede na dejansko izvedene stroške
Odgovor 3: Na identično vprašanje smo odgovorili v odgovoru 2.1


Vprašanje 4: Datum prejema: 04.11.2020
Za poročanje o pošiljkah in nove posodobitve ETA morata storitev za zemljevide in mobilna aplikacija imeti možnosti za redno pošiljanje vidnosti pošiljke. Ali imajo to možnost? Ali pa v svojem vozilu za sledenje uporabljajo telematske naprave?
Odgovor 4: Storitev za zemljevide mora zagotoviti ponudnik IPLP rešitve (torej tudi možnosti za redno pošiljanje vidnosti pošiljke). Naša last mile mobilna aplikacija (UPO Mobile) bo z IPLP jem tesno povezana in bo v sistem pošiljala vse statuse o pošiljkah. Vsa vozila na PS, ki jih uporabljamo za transport in dostavo pošiljk, so opremljena s sledilnimi napravami. Tudi ti podatki bodo dostopni IPLP sistemu.


Vprašanje 5: Datum prejema: 04.11.2020
Ali se štejejo za veljavne reference ponujene rešitve, ki so od podizvajalca glavnega ponudnika?
Odgovor 5: Kot veljavne, štejejo reference vsakega od članov konzorcija, ki sodelujejo v ponudbi, kakor tudi reference podizvajalcev glavnega ponudnika (v kolikor ponudbo odda ponudnik s podizvajalci). Kot partner pri konzorciju za izvedbo javnega naročila lahko sodeluje tudi eden ali več certificiranih partnerjev principala. Kot veljavne bomo šteli tudi tiste reference, katerih funkcionalnosti je zagotovil principal ali izvajalec, ki sodeluje v konzorciju ponudnika.


Vprašanje 6: Datum prejema: 04.11.2020
Ali že uporabljate kakšno rešitev za vodenje skladiščnega poslovanja za razvrščanje, izbiranje, pakiranje, natovarjanje, razkladanje in vse druge skladiščne operacije?
Odgovor 6: Takšne rešitve naročnik že uporablja za skladiščni del poslovanja in ne predvideva, da se bodo ti sistemi razširili na del, ki ga bo pokrivala IPLP rešitev. Torej mora ponudnik vse morebitne sisteme »za vodenje skladiščnega poslovanja za razvrščanje, izbiranje, pakiranje, natovarjanje, razkladanje in vse druge skladiščne operacije« v IPLP rešitvi zagotoviti sam v kolikor je zaznal, da so te funkcionalnosti zahtevane v naročnikovih tehničnih zahtevah.




Vprašanje 7: Datum prejema: 04.11.2020
Aplikacija Last mile bi rešila škodo pri pošiljanju in vračanju embalaže. Ali želite, da se te podrobnosti posodobijo tudi v pošiljki v zalednem sistemu v realnem času ali da se obravnavajo samo v aplikaciji last mile?
Odgovor 7:
Iz vprašanja ni razvidno na katero funkcionalnost se nanaša zato ne moremo podatki končnega odgovora. Pojasnjujemo pa, da pričakujemo, da se bo celoten sistem evidentiranja lokacij in primopredaje embalaže, logističnih sredstev (ne glede ali so v lasti naročnika ali pogodbene stranke) ter vodenje stanja zagotovil v IPLP sistemu.


Vprašanje 8: Datum prejema: 04.11.2020
Prosimo za dodatno pojasnitev tehnične funkcionalnosti pod številko 184: Zmožnost vodenje podatkov, vezanih na pavšal za dvokolesa. Ali lahko to bolj podrobno opišete?
Odgovor 8: V aplikaciji za skrbnike voznega parka bo potrebno voditi tudi podatke za dvokolesa. Eden izmed teh podatkov je npr. koliko kilometrov je opravilo dvokolo. Ob vsakodnevni potrditvi brezhibnosti vozila s strani uporabnika, bo sistem moral na podlagi ID uporabnika iz KIS-a pridobiti podatek, koliko kilometrov je uporabnik izvedel (fiksni podatek, vezan na okraj). Te kilometre bo moral sistem hraniti za namene evidence skupnih prevoženih kilometrov vozila.


Vprašanje 9: Datum prejema: 04.11.2020
Katere vrste obrazcev / papirjev in dokumentov so potrebne za tiskanje?
Odgovor 9: Predvidevamo, da se vprašanje nanaša na zahtevo št. 22 v dokumentu Tehnične zahteve. V tem primeru sporočamo, da bo deloma tudi od ponudnikovega sistema odvisno, katere podatke in dokumente bo treba zagotoviti za potrebe evidentiranja podatkov, ki bodo ob ponovni vzpostavitvi sistema vnesli. Navedeno se določi v fazi BluePrinta.


Vprašanje 10: Datum prejema: 04.11.202
Kje se kreira in nahaja transportni nalog kot osrednji objekt? Ali je UPO vir podatkov?
Odgovor 10: Po našem mnenju se transportni nalog nahaja v IPLP sistemu. UPO ni namenjen vodenju transportnih nalogov.


Vprašanje 11: Datum prejema: 04.11.2020
Ali ima Pošta Slovenije danes svoj portal T&T? Ali pa želijo razviti novega?
Odgovor 11: Pošta Slovenije ima svoj T&T portal, kamor bo tudi IPLP sistem zagotavljal določene statuse. Točno katere, je stvar faze Blueprinta.


Vprašanje 12: Datum prejema: 04.11.2020
Prosimo za dodatno pojasnitev tehnične funkcionalnosti pod številko 154: Rešitev mora omogočati re-planiranje celotnega plana med samim izvajanjem (ko so npr. vozila že zapustila depo) z namenom re-optimizacije obstoječega plana (sprememba ETA-jev zaradi upoštevanja vseh trenutnih informacij) ali vključevanja novih naročil v obstoječi plan.
Kakšen je obseg ponovne optimizacije tukaj? Ali to pomeni preusmeritev pošiljke ali spremembo rezultatov načrtovanja, na primer dodelitev dostave na stpos ali zamenjava gonilnika ... itd?
Odgovor 12: Naročnik pričakuje, da bo obseg ponovne optimizacije v tem primeru omejen le na izračunano pot tega specifičnega terenskega delavca. V kolikor bo nov vhodni podatek za neko pošiljko predvideval dostavo npr. v drugi coni ali v drugem časovnem terminu (ki sta izven prostorskih in časovnih okvirjev tega delavca), se bo takšno pošiljko vrnilo na izhodiščno poštno poslovalnico.


Vprašanje 13: Datum prejema: 04.11.2020
Ali Pošta Slovenije želi tudi vnaprej uporabljati obstoječi sistem za tiskanje nalepk?
Odgovor 13: Da.


Vprašanje 14: Datum prejema: 04.11.2020
S koliko zunanjimi prevozniki danes sodelujete? Ali že imate obstoječi portal za operaterje ali razmišljate o uporabi SAP LBN ali katerega koli drugega portala?
Odgovor 14: Trenutno sodelujemo z 12 različnimi zunanjimi prevozniki (pogodbeni podizvajalci). Naročnik še ne uporablja portala za operaterje. Zagotovitev teh funkcionalnosti je del IPLP naročila, predvsem v tehničnih zahtevah 43 in 44.


Vprašanje 15: Datum prejema: 04.11.2020
Prosimo za dodatna pojasnila tehnične funkcijske specifikacije št. 147:
Optimizer mora podpirati opcijo nalaganja in razlaganja na različnih poštah / terminalih
Izvajanje paketne dostave znotraj območja več dostavnih pošt hkrati
Izvajanje delnega obračuna v primeru paketnih pošiljk na izročilnih poštah in v primeru logističnih pošiljk na logističnih poštah.
Prosimo, navedite nekaj podrobnosti za to zahtevo. Ali želite, da rešitev načrtuje izdelavo paketov za eno stranko ali mešane?
Odgovor 15: Dodatna pojasnila na to temo so del razpisne dokumentacije. Predlagamo, da preučite dokument »Priloga 08 - Mobilna hibridna first-last mile aplikacija«. V kolikor pojasnila v prilogi niso zadostna, nato postavite dodatna vprašanja.


Vprašanje 16: Datum prejema: 04.11.2020
Kakšen je postopek prejema naročila kupca? Ali prek telefonskega klica, e-pošte ali katerega koli portala za stranke? Ali za rezervacijo naročil uporabljate tudi ERP sistem?
Odgovor 16: Naročnik trenutno naročila za prevzem pošiljk na terenu (naročilo za prevoz) pridobiva preko telefona in e-pošte (kraj in čas pobiranja) oz. je naročilo za prevzem določeno v pogodbi. Pri čemer pa podatke o teh pošiljkah, ki so predmet teh prevzemov, v večini primerov dobi v elektronski obliki (ID pošiljke, masa, storitve, naslovnik). V ta namen ima naročnik razvitih več rešitev, ki omogočajo pripravo in oddajo podatkov v različnih strukturah (CSV, XML, Json). Za rezervacijo naročil ne uporabljamo ERP sistema.


Vprašanje 17: Datum prejema: 04.11.2020
V katerem sistemu se vodijo zaloge? Ali rešitev IPLP mora voditi upravljanje zalog in skladiščnih operacij?
Odgovor 17: V kontekstu blaga, ki ga imamo na poštnih poslovalnicah ter obrazcev, ki se uporabljajo pri delu, se zaloge vodijo v UPO sistemu, ki je povezan z obstoječim skladiščnim sistemom. V smislu vodenja zalog povratne logistike in osnovnih logističnih sredstev (npr. pismarnic, zabojnikov, palet, ročnih viličarjev, pošiljateljeve embalaže) pa mora ponudnik to zagotoviti v sklopu IPLP rešitve. Tehnične zahteve za ta segment so predvsem 62, 64.


Vprašanje 18: Datum prejema: 04.11.2020
Prosimo za dodatna pojasnila tehnične funkcijske specifikacije št. 67:
Zmožnost uporabe (vklop/izklop) sekundarnih cross-dock lokacij pri planiranju transporta.
Naročnik pričakuje, da bo pri planiranju dispečer imel možnost odobritve uporabe sekundarne lokacije za izvajanje cross-docka.
Odgovor 18: Naročnik pričakuje, da bodo (določena) vozlišča imela definirano maksimalno kapaciteto in v kolikor bo ta presežena, bi moral IPLP sistem dispečerja na to opozoriti. Naročnik že sedaj določen del cross-docka izvaja na ločenih lokacijah in v kolikor bo kapaciteta na primarni lokaciji presežena, mora sistem tvarino preusmeriti na sekundarno lokacijo.


Vprašanje 19: Datum prejema: 04.11.2020
Prosimo za dodatna pojasnila tehnične funkcijske specifikacije št. 66:
Zmožnost določitve kratkoročnih skladiščnih kapacitet na posameznih cross-dock lokacijah in logističnih poštah. Ali se želijo in če je to možnost, da se kapacitete definirajo znotraj cross-dockinga lokacij?
Odgovor 19: V tem primeru govorimo predvsem o paletah in večjih tovorkih ter o cross-dock lokacijah in logističnih poštah. Ne govorimo o tem, da se na teh lokacijah »rezervira« prostor, kamor se lahko palete skladiščijo temveč o tem, da če se npr. naslovnik odloči, da se »njegova« paleta dostavi jutri (namesto danes), da ima delavec na tej lokaciji zmožnost tej paleti določiti status »kratkoročnega skladiščenja«. To se v sistemu nato odrazi v dejstvu, da se dostava pošiljke planira za naslednji dan ter da se izvedba storitve »kratkoročno skladiščenje« odrazi v evidentiranju storitve, ki je vezana na to pošiljko oz. na naročilo. Navedena storitev je nato tudi predmet izmenjave podatkov za potrebe billinga.


Vprašanje 20: Datum prejema: 04.11.2020
Prosimo za dodatna pojasnila tehnične funkcijske specifikacije št. 61:
Zmožnost pregleda (trenutnega - v realnem času) pošiljk na cross dock lokaciji
Popis pošiljk, ki so trenutno na cross-dock lokaciji, v kateri fazi procesa so in kje točno se nahajajo (cona, transportna enota)?
Odgovor 20: Ena od funkcionalnosti, ki jih bo prinesla IPLP rešitev je tudi gnezdenje pošiljk v logistične enote in gnezdenje le-teh v vozila. To pomeni, da bomo pridobili pregled nad pošiljkami, ki so prišle na lokacijo in tiste, ki so odšle iz lokacije. Ta pregled 'trenutno prisotnih pošiljk na lokaciji' je ključnega pomena za naročnika. V primeru velikih Cross-dock lokacij se predvideva tudi vpeljava con (npr. cona ob vratih 1, 2 in 3, cona za predelavo pisemskih pošiljk, cona za kratkoročno skladiščenje, cona za ekspress pošiljke). Prehod med temi conami bo potrebno sistemsko slediti preko (v nekaterih primerih) primopredaj ali le potrditve operaterja, da je paleto ali zabojnik odložil v določeni coni. Na ta način bomo vzpostavili pregled nad tem, katere pošiljke so na lokaciji in kje se nahajajo. Omenjene funcionalnosti se nanašajo predvsem na tehnične zahteve 61, 72 in 212.


Vprašanje 21: Datum prejema: 04.11.2020
Prosimo za dodatna pojasnila tehnične specifikacije št. 63: Zmožnost, da se dinamično zajamejo nove informacije vezane na naročilo, med izvajanjem operacije in glede na njih planirati pot, ki je že v izvajanju.
Odgovor 21:
Med izvajanjem dela na terenu se lahko naslovniki oddajo nova navodila glede dostave pošiljke (npr. dostava na nov naslov, dostava ob drugi uri, dostava v PS Paketomat, itd.). Sistem mora takšno informacijo upoštevati v skladu z naprej določenimi pravili (npr. za »dostavo v PS Paketomat« se postavi pravilo, da se pošiljka zmeraj vrne na dostavno pošto).


Vprašanje 22: Datum prejema: 04.11.2020
Kaj mislite s pregledom resursov v realnem času? Katerih resursov? Kje želite izvajati ta pregled? Kaj pomeni za vas v realnem času?
Odgovor 22: Govorimo o tem, da lahko npr. dispečer v sistemu vsak trenutek vidi, kje se nahajajo terenski delavci, kakšne aktivnosti izvajajo, in kaj imajo naloženo v vozilu, da imamo v sistemu »ad-hoc« vpogled nad pošiljkami in logističnimi sredstvi, ki se nahajajo na določeni lokaciji (npr. cross-dock lokaciji), itd. Naveden vpogled se določi na osnovi evidentiranja različnih statusov pošiljk, gnezdenja v PLCjih, primopredaj, podatkov iz sistema za sledenje vozil, itd. Za vsakega od navedenih se določijo pravila intervalov osveževanja (npr. osveževanje na 10 minut).


Vprašanje 23: Datum prejema: 04.11.2020
Ali lahko pojasnite bolj detajlno, kaj ste mislili s tehnično funkcijsko specifikacijo št.48: Pregled vseh resursov, ki jih dispečer koristi pri planiranju dostavnih poti oz. naknadnemu dodeljevanju naročil, v realnem času.
Odgovor 23: Prosim preberite odgovor 22.


Vprašanje 24: Datum prejema: 04.11.2020
Ali lahko pojasnite, kaj ste mislili s tehnično funkcijsko specifikacijo št.26: Zmožnost dodajanja informacij pošiljkam v vseh fazah, brez reklamacije (izločitve pošiljke iz procesa). Prosimo za specifikacijo tipa in oblike informacij, ki jih boste dodeljevali pošiljkam?
Odgovor 24:
Naročnik pričakuje, da se bodo lahko naročilom oz. pošiljkam dodajale opombe in informacije, ki bodo pomembne za delavce, ki bodo v kasnejših fazah prenosa rokovali s pošiljko oz. bodo pomembne v fazi reševanja morebitnih reklamacij. V nadaljevanju podajamo dva primera:
1.Operater med gnezdenjem opazi, da je ovojnina pošiljke poškodovana in pri tem oceni, da jo je potrebo prepakirati (dodatno zaščititi), takšni pošiljki dodeli status reklamacije. Če pa oceni, da je poškodba minimalna in ne vpliva na zaščito vsebine, pa mora imeti možnost dodati podatkom o pošiljki zaznamek o poškodovani ovojnini.
2.Če voznik med prevzemom palete ugotovi, da tvarina glede čez robove palete (kar ni v skladu s pravili oddajanja pošiljk), lahko ta zaznamek doda med podatke o pošiljki, vendar kljub temu izvede prevzem.


Vprašanje 25: Datum prejema: 04.11.2020
Ali lahko pojasnite bolj detajlno, kaj ste mislili s tehnično funkcijsko specifikacijo št.22:
Zmožnost, da v primeru padca sistema (padec strežnika, interneta) v vseh fazah (prevzem/dostava, notranji prevozi) delovanja sistema z natisnjenimi dokumenti, obrazci, ki se jih nato naknadno vnese v sistem. Navedeni obrazci oz. dokumenti se kreirajo in natisnejo v zalednih sistemih oz. na UPO DM na poštah.
Zagotoviti backup način dela in način, da se izpolnjeni dokumenti nato naknadno vnesejo v sistem.
Kako lahko sistem tiska, če sistem dol pade?
Ali lahko posredujete scenarije neprekinjenega poslovanja?
Odgovor 25: Scenariji za neprekinjeno poslovanje se bodo določili v fazi Blueprinta. Bistveno za naročnika je, da se v primeru padca ali delnega padca sistema ohrani določena sledljivost tvarine in da ima zmožnost predaje navodil terenskim delavcem. Seveda je aktivnost bistveno odvisna od tipa oz. dela sistema, ki je padel. Eden od scenarijev je na primer ta, da dispečer pripravi route, vendar jih dostavni delavci ne prejmejo na IPLP napravo. V tem primeru mora dispečer imeti možnost celoten seznam izvoziti v (npr.) PDF in nalogo poslati po e-mailu na dostavno pošto. Ko se sistem naknadno vzpostavi, moramo imeti tudi možnost naknadnega vnosa izvedenega dela v sistem (npr. da smo pri pošiljatelju X prevzeli 5 pismarnic).


Vprašanje 26: Datum prejema: 04.11.202
Ali lahko pojasnite, kaj ste mislili s tehnično funkcijsko specifikacijo št.12: Zmožnost podpore različnih logističnih scenarijev za pošiljke, LTL, FTL in zabojnike in druge transportne enote znotraj enega programskega okolja. Iz navedena ni jasno, katere logistične scenarij eje potrebno podpreti in na kakšen način?
Odgovor 26: Naročnik svoje delo opravlja v več logističnih mrežah, npr. mreža hitre pošte in telegramov, paketna mreža, logistična mreža, direktni prevozi FTL ali LTL in pričakuje se, da se vse to organizira znotraj ene dispečerske rešitve. Pri tem mora rešitev podpirati možnost, da se določeni resursi (vozila, delavci, logistična sredstva, itd.) dodelijo določeni mreži.


Vprašanja 27: Datum prejema: 04.11.2020
Lepo prosimo za pojasnilo opombe "* S podpisom tega obrazca vam ni potrebno prilagati pri pogojih navedene izjave" pri obrazcu "IZJAVE O SPREJEMU IN IZPOLNJEVANJU POGOJEV IZ RAZPISNE DOKUMENTACIJE". Kaj se navaja pod številke 1.2,3,4, 5 in ali se ta izjava prilaga k ponudbi?
Odgovor 27: Obrazec »Izjava o sprejemu in izpolnjevanju pogojev iz razpisne dokumentacije« je standarden obrazec v razpisnih dokumentacijah naročnika. V kolikor so v razpisni dokumentaciji zahtevane izjave o izpolnjevanju pogojev, lahko ponudnik namesto, da predloži posebne izjave, sam vpiše zahtevane izjave v obrazec in ga podpisanega priloži svoji prijavi. V kolikor posebne izjave niso zahtevane, zadošča, da ponudnik zgolj izpolni podatke na začetku obrazca in ga podpisanega priloži prijavi.



Datum objave: 12.11.2020   08:42
VPRAŠANJE

Naročnika prosimo za pojasnitev obrazca Izjava o sprejemanju in izpolnjevanju pogojev iz razpisne dokumentacije, in sicer:

1. Kaj naj bi ponudnik navedel pod »Št. Izjavljamo:
1.
2.
3.
4.
5. » in

2. Kaj je Naročnik mislil z opombo »S podpisom tega obrazca vam ni potrebno prilagati pri pogojih navedene izjave.«
Naročnika prosimo za pojasnilo ter ga hkrati prosimo, da obrazec smiselno korigira.

Odgovor: Naročnik je na smiselno enako vprašanje odgovoril v objavljenem sklopu vprašanj dne 12.11.2020.

Datum objave: 19.11.2020   07:59

ODGOVORI NA VPRAŠANJA

Vprašanje 1: Datum prejema: 05.11.2020
Kakšen % bančne garancije pričakuje stranka, da je relevanten za licence programske opreme ? (Običajno v takšnih primerih je nekje okoli 5% ).
Odgovor 1: Višina garancije za dobro izvedbo pogodbenih obveznosti je opredeljena v zadnjem odstavku 17. člena vzorca okvirnega sporazuma.

Vprašanje 1: Datum prejema: 09.11.2020
Ali nam lahko pojasnite, kaj razumete pod ''tretje osebe'' (OS, 3. člen, tretja alineja)?
Odgovor 1: Naročnik se bo v času izvajanja projekta posluževal storitev svetovanja s strani strokovnih svetovalcev ter strokovnjakov iz odvisnih družb za pomoč izvajanja projekta.

Vprašanje 2: Datum prejema: 09.11.2020
Ali lahko pričakujemo, da bo za potrebe testiranja naročnik zagotovil ustrezne sistemske licence (OS, MS SQL) (OS, 3. člen, zadnji odstavek)?
Odgovor 2: Da, v kolikor gre za Microsoft programsko opremo.

Vprašanje 3: Datum prejema: 09.11.2020
Predvidevamo, da bo potrebno število testnih licenc dogovorjeno v Blueprint fazi projekta. Drži?
Število testnih licenc je odvisno od ponujene rešitve in metodologije implementacije izvajalca.
Odgovor 3: Da

Vprašanje 4: Datum prejema: 09.11.2020
Ali bo lahko ponudnik ponudil tudi ustrezne novejše modele terenskih naprav? Ali bo naročnik omogočil nakup novih modelov in morebitne drugačne nakupne cene od tistih v ponudbi? (OS, 4. člen, zadnji odstavek, 8. Člen, zadnji odstavek)
Glede na trajanje projekta in zgolj okvirno število naprav lahko pričakujemo v obdobju veljavnosti OS zamenjavo ponujenih modelov z novejšimi, s tem pa tudi spremenjene cene.
Odgovor 4: Naročnik bo tekom implementacije projekta kupoval terenske naprave, ki jih bo ponudnik podal v ponudbeni dokumentaciji, za katere je cena v ponudbi znana. Te terenske naprave morajo zadostiti naročnikovim tehničnim zahtevam na tem segmentu. V primeru spremembe tehnologije (novejši modeli, obstoječi niso več dobavljivi ipd.), se lahko naročnik v smislu 6. odstavka 48. člena ZJN-3 pisno posvetuje z gospodarskim subjektom, podpisnikom okvirnega sporazuma, in zahteva, da po potrebi v tem delu dopolni svojo ponudbo, oziroma naročnik ravna skladno z možnostmi, ki mu jih v takšnem primeru nudi veljavna zakonodaja.

Vprašanje 5: Datum prejema: 09.11.2020
Zakaj je naročnik izrazil potrebo reprodukciji licenčne programske opreme? (OS, 5. člen, prvi odstavek, prva alineja)
Naročnik dobi z nakupom/najemom licenčne programske opreme pravico do uporabe le-te, ne pa tudi do njene reprodukcije. Pravice uporabnika so omejena na pravice, zapisane v dokumentu Software License Agreement, ki ga bo ponudnik priložil k ponudbeni dokumentacije.
Odgovor 5: V zvezi s tem naročnik opozarja na določilo drugega odstavka 114. člena ZASP. Naročnik bo zakoniti uporabnik programske opreme, posledično mu gre tudi pravica reproduciranja v navedenem obsegu. Gre za varnostno kopijo in ne reprodukcijo za potrebe česarkoli drugega.

Vprašanje 6: Datum prejema: 09.11.2020
Kašne uporabniške pravice je naročnik predvidel za javnost? (OS, 5. člen, prvi odstavek, druga alineja).
Od podeljenih uporabniških pravic je odvisen tudi število in tip potrebne licence (plačljiva ali ne).
Odgovor 6: V tem primeru ima naročnik v mislih npr. portal za pogodbene prevoznike, do katerega bodo morali dostopati tudi naši pogodbeni podizvajalci. V kolikor se bo dostop urejal preko licenc, mora naročnik imeti pravico, da te licence za dostop dodeli svojim pogodbenim prevoznikom. Prav tako predvidevamo, da bo na področju najav (funkcionalnost mapinga) treba zagotoviti dostop za pogodbene uporabnike.

Vprašanje 7: Datum prejema: 09.11.2020
Glede na to, da je naročnik predvidel okvirno število uporabnikov ponujene programske opreme in se ne obvezuje nakupiti/najeti ponujenega števila licenc, ali lahko ponudnik razume, da je tudi cena ponujene programske opreme okvirna? (OS, 5. člen, tretji odstavek).
Odgovor 7: Naročnik je število uporabnikov predvidel z namenom, da lahko ponudniki ocenijo število potrebnih licenc in ceno podajo v ponudbi. Izraz 'okvirno' število uporabnikov izhaja iz dejstva, da naročnik ne pozna ponudnikovih rešitev in zato ne zna povedati natančno koliko uporabnikov bo dostopalo do katerih delov rešitve. Prva realna ocena potrebnih uporabnikov bo znana po zaključeni fazi Blueprinta pri čemer pričakujemo, da se bo 'končno' število ugotovilo šele v fazi 'roll out' rešitve.

Fiksne in zavezujoče morajo biti cene po kosu posamezne licence.

Vprašanje 8: Datum prejema: 09.11.2020
Ponudnik bo izvedel le tiste nadgradnje ponujene rešitve, ki ne bodo v njegovo in naročnikovo škodo. Vse morebitne škodljive zahteve naročnika po nadgradnjah bo argumentirano zavrnil. Naročnik v primeru argumentirane zavrnitve nima pravice zahtevati škodljive nadgradnje in ob tem še ponudnika sankcionirati. Prosimo za mnenje. (OS, 6. člen, prvi odstavek)
Odgovor 8: S predlogom se naročnik strinja, vendar zahteva, da bo v primeru ponudnikove zavrnitve izvedbe nadgradnje, moral ponudnik to škodljivo nadgradnjo detaljno in ustrezno argumentirati.

Predlog 9: Datum prejema: 09.11.2020
Predlagamo črtanje zadnjega odstavka. (OS, 6. člen)
Ponudba bo v celoti sledila zahtevam iz razpisne dokumentacije, podroben izvedbeni načrt projekta pa bo izdelan v Blueprint fazi projekta, zato smatramo, da je ta stavek nepotreben.
Odgovor 9: Naročnik se ne strinja s predlogom. Zapis izhaja iz tveganja nastanka okoliščine, kjer ponudnik v ponudbi kakšnih stroškov (npr. določen sklop licenc) ne upošteva, kasneje pa od naročnika zahteva, da jih kljub temu plača, saj drugače rešitev kot celota ne bo delovala.

Predlog 10: Datum prejema: 09.11.2020
Predlagamo, da se izvedba Blueprint faze projekta ne šteje v rok za izvedbo implementacije rešitve. Prosimo za mnenje. (OS, 7. člen, drugi odstavek)
Odgovor 10: Naročnik se ne strinja s predlogom.

Predlog 11: Datum prejema: 09.11.2020
Prosimo naročnika, da se podrobneje opredeli do tega »ključnega vprašanja, v ozadju katerega so številna finančna zavarovanja naročnika za zamude pri delih projekta in celoti.
Glede na predvideno trajanje testiranja rezultatov posameznega mejnika projekta (30 dni) in trajanje zaključnega testiranja (90 dni) s strani naročnika, smatramo, da je to skupni čas(skupaj to znese 13 mesecev), ki ga naročnik rezerviral za lastne potrebe, zato se teh 13 mesecev ne more šteti v čas implementacije in omejevati izvajalca.
Odgovor 11: Naročnik predvideva, da se bo testiranje rezultatov posameznega mejnika (30 dni) odvijalo neodvisno in vzporedno z naslednjim mejnikom, zato to ni razlog za podaljševanje časovnice. Zaključno testiranje (90 dni) po končani implementaciji pa podaljšuje projekt za dodatnih 90 dni, kar mora ponudnik vključiti v svoj terminski plan, katerega skupno trajanje ne sme presegati 30 mesecev od podpisa pogodbe.

Predlog 12: Datum prejema: 09.11.2020
Pričakujemo, da bodo lahko mejniki potekali vzporedno, skladno z ponujenim časovnim planom izvedbe). Prosimo za potrditev.
Po tej matematiki bo imel izvajalec na voljo zgolj 17 mesecev za izvedbo projekta (čas pod nadzorom izvajalca), kar za izvajalca, glede na zahtevnost in kompleksnost naročila, ni sprejemljivo.
Odgovor 12: Ponudnik naj aktivnosti razporedi na način, da bo naročnik skozi terminski plan enakomerno obremenjen. Glede na odgovor 11, se naročnik ne strinja, da bo imel izvajalec na voljo zgolj 17 mesecev (brez obdobja testiranja), temveč 27 mesecev+3 mesečno zaključno testiranje, odvisno od podane ponudbe (rok, ki izhaja iz razpisne dokumentacije, je 18 do 30 mesecev).

Vprašanje 13: Datum prejema: 09.11.2020
Kaj v primeru, če naročnik in izvajalec ne potrdita dokumenta za izvedbo projekta (Blueprint), čeprav slednji v celoti ustreza zahtevam razpisne dokumentacije? (OS, 7. člen)
Odgovor 13: Neposrednega odgovora na vprašanje, to je za hipotetično situacijo, kjer je možno izjemno veliko število dejanskih stanj in razlogov za njih, ni mogoče podati; če bi blueprint vseboval vse zahteve naročnika iz razpisne dokumentacije ter bil skladen z dodatnimi ugotovitvami iz faze implementacije, gre težko pričakovati takšno situacijo. V vsakem primeru pride do uporabe določil Obligacijskega zakonika veljavnega v Republiki Sloveniji.

Predlog 14: Datum prejema: 09.11.2020
Predlagamo popravek predzadnjega stavka na način, da naročnik ne bo omejeval ponudnika glede načina projekta. (OS, 7. člen) Pričakujemo, da bo izvedba implementacije ponujene rešitve potekala po načrtu, ki ga bo predstavil izvajalec v Blueprint fazi. Vsakršno omejevanje načina in dinamike izvajanja projekta lahko po nepotrebnem podaljša rok izvedbe, s tem pa izpostavi izvajalca zagroženim sankcijam naročnika in mu s tem povzroči poslovno škodo.
Odgovor 14: Naročnik se s predlogom ne strinja, vendar hkrati zagotavlja, da si bo prizadeval v največji možni meri ponudniku aktivnosti izvajati na način, kot ga ponudnik predvideva (na daljavo).

Predlog 15: Datum prejema: 09.11.2020
Naročniku predlagamo, da iz OS umakne vse omejitve ponudnika pri izvedbi projekta in v celoti sledi dogovorjenemu Blueprint dokumentu.
Izvajalec bo pri angažiranju kapacitet naročnika deloval razumno in prilagodljivo, če bo to le mogoče brez ogrožanja učinkovitosti in rokovnika izvedbe projekta.
Odgovor 15: Naročnik se ne strinja s predlogom.

Predlog 16: Datum prejema: 09.11.2020
Naročniku predlagamo, da ne omejuje števila in trajanja delavnic na največ dva dni/teden. S tem se izvajalec ne strinja, saj metodologija implementacije, obvezujoč rok izvedbe in vse nevedne pogodbene kazni za morebitne zamude ne dopuščajo takšnih omejitev.
Odgovor 16: Naročnik je omejitev določil zato, ker je iz izkušenj na podobnih projektih spoznal, da so celodnevne delavnice izredno naporne in iz njih za naročnika tipično izhaja veliko zadolžitev, ki jih je potrebno izvesti do naslednjih delavnic. Ker ima naročnik za izvedbo projekta na voljo predvidoma manj kadrovskih resursov kot konzorcij več podjetij na strani ponudnika, je za pričakovati, da bo lahko sledil aktivnostim na BluePrintih le ob upoštevanju zgoraj navedene omejitve.

Predlog 17: Datum prejema: 09.11.2020
Naročniku predlagamo, da glede morebitne zamude s strani naročnika oblikuje bilateralni odnos.
Naročnik ne navaja nikakršne odgovornosti za povzročeno zamudo na svoji strani. Morebitna zamuda na strani naročnika bi povzročila odstopanje od dogovorjenega rokovnika izvedbe, kar bi lahko ponudniku povzročilo razmeroma veliko poslovno škodo (penali, bančna garancija). Naročnik mora razumeti, da je tudi izvajalec poslovni subjekt in da bi zanj morali veljati enaki pogoji kot za naročnika. Gre za sorazmernost odgovornosti obeh strani.
Odgovor 17: Izvajalec odgovarja za zamudo le, če vzrok zanjo izvira iz njegove pogodbene sfere, to je če za zamudo ne odgovarja, kot to izhaja iz določila 250. člena Obligacijskega zakonika. Za vse kar z okvirnim sporazumom ni izrecno določeno se uporabljajo določila Obligacijskega zakonika.

Predlog 18: Datum prejema: 09.11.2020
Predlagamo, da naročnik črta besedo ''programiranje'', saj ne ustreza vsebini predvidenih storitev. (OS, 8. člen, prvi odstavek)
Odgovor 18: Naročnik skozi JN sicer kupuje obstoječo, delujočo rešitev, kjer se pričakuje, da dodatnega programiranja ne bo. Pri tem pa vseeno pričakuje, da bodo v fazi BluerPrinta identificirane zahteve, ki bodo zahtevale nadgradnjo programske opreme izključno na podlagi naročnikove zahteve in izven siceršnjega predmeta naročila. Zato so ponudniki dolžni tudi za ta segment podati ceno. Zaradi navedenega vztrajamo da ta beseda ostane v zapisu.

Predlog 19: Datum prejema: 09.11.2020
Ali lahko ponudnik za v Blueprint fazi dogovorjeno število testnih licenc ponujene programske opreme zaračuna stroške letnega vzdrževanja (maintenance) le-te, saj tudi v primeru uporabe testnih licenc prevzema odgovornost za nemoteno delovanje ponujene programske rešitve? (OS, 9. člen, peti odstavek)
Odgovor 19: Vsi stroški, povezani s testnimi licencami, morajo biti zajeti v implementacijskih stroških (1. skupina ponudbenega predračuna), ne glede na to, ali gre za uporabo določenega števila licenc, ali za izvajanje podpore.

Vprašanje 20: Datum prejema: 09.11.2020
Ali je naročnik pripravljen plačevati stroške nakupa/najema naročenih licence v naprej za 12 mesecev? ( OS, 9. člen, Licence/vzdrževanje in podpora)
Z naročilom prve licence prične veljati tudi pogodba za vzdrževanje in podporo, ki pa se na osnovi uveljavljene prakse in SLA pogojev sklepa za obdobje enega leta v naprej.
Odgovor 20: Naročnik naroča vzdrževanje za 5 let od go-live za posamezni modul, za kar se ne bo sklepalo dodatne pogodbe za vzdrževanje, saj je le-to že zajeto v tem OS. Naročnik in izvajalec se bosta morala le strinjati, kdaj se to posamezno 5 letno obdobje prične izvajati. To pomeni, da se vzdrževanje do izteka tega obdobja ne bo leto obnavljalo. V razpisni dokumentaciji je predvideno kvartalno plačevanje stroškov v naprej, vendar naročnik dovoljuje tudi morebitno spremembo tega kvartalnega plačevanja stroškov v naprej v 2. fazi javnega naročila.

Vprašanje 21: Datum prejema: 09.11.2020
Kdaj in zakaj lahko naročnik zavrne izdani račun? Prosimo za pojasnilo. (OS, 10. člen, tretji odstavek).
Račun bo izdan na osnovi potrjenega primopredajnega zapisnika, kar pomeni da bi lahko bil edini razlog zavrnitve računa , da slednji ne ustreza vsebini primopredajnega zapisnika, ki bo obvezna priloga k računu.
Odgovor 21: Naročnik lahko račun zavrne, v kolikor obstajajo utemeljeni argumenti, da pogoji za izstavitev računa še niso doseženi (npr. v fazi implementacije, da primopredajni zapisnik še ni potrjen s strani naročnika)

Vprašanje 22: Datum prejema: 09.11.2020
Ali bo naročnik sprejel pogoje ponudnika za izvedbo pogodbenih obveznosti v dogovorjenih rokih, vsebini in načinu, kot bo to dogovorjeno z Blueprint dokumentom? (OS, 11. člen, Drugi odstavek, druga alineja). Ponudnik ne more prevzeti odgovornosti za izvedbo pogodbenih obveznosti, v kolikor mu naročnik postavlja omejitve in vsiljuje način in pogoje izvedbe.
Odgovor 22: Naročnik ne more podati splošnega odgovora, ker ni izpostavljeno, na katero pogodbeno obveznost se ta nanaša.

Predlog 23: Datum prejema: 09.11.2020
Predlagamo, da naročnik črta zadnji stavek tretjega odstavka ter četrti odstavek v celoti. (OS, 11. člen).
Ponudnik ne more zahtevati nadgradnje ponujene rešitve, kljub temu, da jo je ponudnik argumentirano zavrnil. In ob tem še groziti s sankcijami.
Odgovor 23: S predlogom se naročnik ne strinja. V tem odstavku je s sankcijami opredeljena samo neutemeljena zavrnitev. V primeru ponudnikove utemeljene zavrnitve izvedbe naročila, bo moral ponudnik to zavrnitev deteljno in ustrezno argumentirati.

Predlog 24: Datum prejema: 09.11.2020
Predlagamo, da pri zagotavljanju dostopa ponudnika do naročnikovega informacijskega okolja naročnik upošteva omejitve, ki jih prinaša pandemija Covid-19. (OS, 13. člen, tretja alineja).
V Blueprint dokumentu bo ponudnik natančno opredelil potrebe po dostopu do informacijskega okolja naročnika, ki mu omogočajo nemoteno izvedbo pogodbenih obveznosti v dogovorjenih rokih.
Odgovor 24: Kot izhaja iz tretje alineje 13. člena OS, bo dostop omogočen ob odobritvi naročnika v primeru 'potrebe'. V kolikor se bo naročnik strinjal, da dane okoliščine (npr. zaradi pandemije) izražajo potrebo po dostopu, bo to izvajalcu tudi odobril.

Predlog 25: Datum prejema: 09.11.2020
Avtorske pravice in pravice intelektualne lastnine na programski opremi, ki je predmet ponudbe, so in ostanejo v izključni domeni ponudnika in njegovih podizvajalcev. Navedene pravice v nobenem primeru ne bodo prenesene na naročnika, ampak bo slednjemu na osnovi nakupa licenc ponujene programske opreme podeljena le pravica uporabe le-te.
PREDLOG: Predlagamo, da temu ustrezno prilagodite vsebino 14. člena. (OS).
Odgovor 25: Navedeni člen je že zapisan v smeri, kot navajate v predlogu, zato sprememba po naročnikovem mnenju ni potrebna.






Vprašanje 26: Datum prejema: 09.11.2020
Ali se naročnik strinja, da bo ponudnik programske opreme lahko zagotovil nemoteno delovanje le-te šele ob pogoju plačila licenčne programske opreme (v naprej)? Z nakupom/najemom prve licence bo aktivirana vzdrževalna pogodba, ki bo veljala naslednjih 12 mesecev. (OS, 15. člen, prvi odstavek)
Odgovor 26: Naročnik se zaveda, da je narava tega projekta takšna, da se napake v sistemu odpravljajo postopoma. V ta namen naročnik tudi zahteva fazo 30 dnevnega testiranja v posameznem modulu in tudi kasneje predvideva, da se bodo napake odpravljale v sklopu rednega vzdrževanja. Naročnik predvideva, da bo skoraj vse napake odpravil že v fazi testiranja na mejniku oz. najkasneje v fazi 90 dnevnega zaključnega testiranja.
Vzdrževalna pogodba se aktivira z nakupom prvih produkcijskih licenc na posameznem modulu, in velja naslednjih 5 let. Naročnik zahteva, da se nemoteno delovanje zagotovi že v fazi izvajanja testiranja. Vsi stroški, povezani s to zahtevo, morajo biti zajeti v implementacijskih stroških (1. skupina ponudbenega predračuna), ne glede na to, ali gre za uporabo določenega števila licenc, ali za izvajanje podpore.

Vprašanje 27: Datum prejema: 09.11.2020
Kako si naročnik predstavlja zaračunavanje skupne zamude, če bo slednjo zaračunal sproti (mejniki)? Ali to pomeni, da bo pogodbene kazni za isti ''prekršek'' zaračunal večkrat?(OS, 16. člen, prvi in drugi odstavek)
Odgovor 27: Če bo programska oprema implementirana po posameznih modulih, se bo pogodbena kazen izračunavala za zamudo pri implementaciji vsakega posameznega modula posebej. Če datum začetka uporabe posameznih modulov za potrebe poslovanja naročnika ne bo isti, ne pride do večkratnega zaračunavanja »istih« prekrškov, temveč kot že pojasnjeno, ločeno po posameznem modulu programske opreme (in glede na predviden terminski načrt implementacije posameznega modula programske opreme).

Vprašanje 28: Datum prejema: 09.11.2020
Zakaj naročnik omenja sankcijo ''popolno oškodovanje'', brez da pojasni metodologija vrednotenja le-te, poleg že zagroženega unovčenja bančne garancije za dobro izvedbo posla?
Pri vseh oblikah pogodbenih kazni je običajna praksa, da naročnik pojasni metodologijo vrednotenja kazni in natančno pojasni vzroke zanje. Tukaj še posebej izpostavljamo odškodninsko odgovornost.
Prosimo za opredelitev zakonodaje, ki naročniku omogoča tovrstne sankcije.
Odgovor 28: Pojasnjevanje zakonodaje ni predmet obveznosti naročnika, gre za pravice v primeru kršitve pogodbenih obveznosti, kot jih predvideva Obligacijski zakonik veljaven v Republiki Sloveniji (prim. 253. člen OZ).

Predlog 29: Datum prejema: 09.11.2020
Prosimo naročnika da pojasni stališča, ki jih zagovarja v OS.
Naročnik navaja skupno zamudo in uveljavitev popolnega oškodovanja v primeru zamud pri izvajanju projektnih aktivnosti po krivdi ponudnika. Opozoriti želimo, da tovrstnih pogodbenih kazni ZJN-3 ne predvideva. Pri skupni višini pogodbenih kazni je potrebno upoštevati tudi omejitve pogodbenih kazni, ki jih prinaša Uredba o finančnih zavarovanjih.
VPRAŠANJE: Kako lahko ponudnik uveljavi pogodbeno kazen (stroške) v primeru zamude na strani naročnika? Je pogodbena kazen enako penali (zamude)? (OS, Pogodbena kazen)
PREDLOG: Predlagamo sorazmerno odgovornost naročnika in ponudnika.
Smatramo, da vse zagrožene sankcije spadajo med pogodbene kazni, ne zgolj penali.
Omejevanje ponudnika po potrjenem Blueprint dokumentu s strani naročnika lahko privede do zamud, za katere pa odgovarja zgolj ponudnik.
Odgovor 29: Na tem mestu naročnik odgovarja, da je pogodbena kazen instrument za utrditev pogodbenih obveznosti, predvidena je za zamudo pri izvedbi implementacije programske opreme. Ponudnik ne more uveljavljati pogodbene kazni zaradi zamude naročnika. V preostalih primerih kršitve pogodbenih obveznosti s strani izvajalca ima naročnik na voljo z zakonodajo predvidene pravice, nenazadnje pa tudi bančno garancijo za dobro izvedbo pogodbenih obveznosti, kot instrument zavarovanja pogodbenih obveznosti izvajalca. Naročnikova (glavna) pogodbena obveznost je plačilo za kar ni mogoče dogovoriti pogodbene kazni. Izraz »penali« v okvirnem sporazumu ni uporabljen, posledično na vprašanje ni mogoče odgovoriti. Naročnik ponavlja, da izvajalec odgovarja za zamudo skladno z določilom 250. člena Obligacijskega zakonika, če za zamudo ne odgovarja, ga naročnik seveda s plačilom pogodbene kazni za takšno obdobje ne more obremeniti. Mnenje izraženo v vprašanju, da so vse zagrožene sankcije zaobjete s pogodbeno kaznijo naročnik ne potrjuje, je zgolj mnenje, ki mu naročnik ne more pritrditi.

Predlog 30: Datum prejema: 09.11.2020
Predlagamo črtanje zadnjega stavka in črtanje vseh sankcij v obliki odškodnin (OS, 16. člen)
Če so zamudni penali še nekako logični, v kolikor naročnik zagotovi zahtevane pogoje za nemoteno izvajanje projektnih aktivnosti ponudniku, pa vse druge pogodbene kazni in odškodnine od ponudnika zahtevajo previsoka tveganja, ki so izključno na njegovi strani.
Odgovor 30: Naročnik ne spreminja okvirnega sporazuma v tem delu. Gre za povsem običajna določila. Naročnik, kot to tudi sicer velja v obligacijskem pravu, ima pravico do zadoščenja (povrnitve škode), če pri do kršitve pogodbenih obveznosti.

Vprašanje 31: Datum prejema: 09.11.2020
Ali bo naročnik uveljavil finančno zavarovanje za dobro izvedbo posla kljub temu, da ni potrdil Blueprint dokumenta, oziroma omogočil dogovorjenih pogojev v Blueprint dokumentu? (OS, 17. člen, prvi odstavek, tretja alineja)
Izvedbeni dokument projekta (Blueprint) bo poleg načina in dinamike izvedbe projektnih aktivnosti vseboval tudi pogoje ponudnika, NUJNE za nemoteno izvajanje projektnih aktivnosti v dogovorjenih rokih.
Odgovor 31: Če izvajalec ne krši pogodbene obveznosti, naročnik ne more unovčiti finančnega zavarovanja oziroma bi bila taka unovčitev neupravičena.

Predlog 32: Datum prejema: 09.11.2020
Predlagamo, da naročnik v celoti črta 18. člen OS, saj zanj nima osnove v ZJN-3.
Z unovčenjem bančne garancije nastanejo pogoji za takojšnjo ustavitev projekta, saj bi s tem ponudnik utrpel nepopravljivo škodo, po možnosti tudi ne zgolj zaradi razlogov na njegovi strani. V tem primeru naročnik ne more zahtevati še dodatnih odškodnin, zato je le-te potrebno črtati iz OS.
Namreč, če se pogodbene kazni in odškodnine lahko seštevajo, dobimo znesek, ki je večji kot 110% vrednosti javnega naročila z DDV (penali + bančna garancija v višini 10% + odškodninska odgovornost 100% +DDV, ki sploh ni bil obračunan in plačan).
Odgovor 32: Naročnik ne bo sledil predlogu. Pojasnilo izhaja iz že podanih odgovorov.


Vprašanje 33: Datum prejema: 09.11.2020
Kako bo ravnal naročnik v primeru, da ne pride do obojestranske potrditve Blueprint dokumenta, ki je bistveni izvedbeni dokument projekta? (OS, 28. Člen).
Smatramo, da v tem primeru naročnik nima pravice do nobenih zagroženih sankcij, hkrati pa mora ponudniku v celoti plačati vse že izvedene projektne aktivnosti (postavitev testne platforme, izvedba delavnic, svetovalne storitve, ipd.)
Odgovor 33: Na vsebinsko enako vprašanje je naročnik že predhodno podal odgovor.

Vprašanje 34: Datum prejema: 09.11.2020
Ali bo ponudnik prost vseh zagroženih sankcij v primeru, da ne pride do obojestranske potrditve Blueprinta dokumenta? (OS, 28. člen, 5 odstavek)
Ponudnik ne more prevzeti odgovornosti za realizacijo naknadno izraženih zahtev in pričakovanj naročnika, ki znatno odstopajo od zahtev, podanih v razpisni dokumentaciji. Morebitne zahteve naročnika, ki bi škodljivo posegale v standardne ponujene rešitve in s tem ogrozile njeno zanesljivost in funkcionalnost, niso sprejemljive. Naročnik se mora zavedati, da naroča v realnem okolju že delujočo programsko rešitev, ki ustreza razpisanim zahtevam.
Odgovor 34: Ponudnik je na smiselno enako vprašanje že odgovoril v predhodnih vprašanjih.

Predlog 35: Datum prejema: 09.11.2020
V kolikor se naročnik želi zavarovati za resnost ponudbe, predlagamo, da namesto zagroženih sankcij uporabi 6. člen Uredbe o finančnih zavarovanjih v primeru neutemeljenega odstopa ponudnika od OS v fazi Blueprinta.
V OS zagrožene sankcije v obliki neopredeljene in ne ovrednotene višine škode, pomenijo za ponudnika (pre)veliko poslovno tveganje. Prosimo, da naročnik natančno opredeli zakonske okvirje, ki tovrstne sankcije omogočajo.
Odgovor 35: Gre za pogodbeno razmerje, kot del avtonomije volje strank. Določila okvirnega sporazuma v ničemer ne odstopajo od siceršnjih pravic, ki jih ima pogodbi zvesta stranka, naročnik je celo sprejel poslovno odločitev, s katero je višino odškodnine, če je to skladno z zakonodajo, omejil. Vpraševalcu naročnik pojasni, da naročnik v tem postopku z ničemer ne ravna v nasprotju z uredbo na katero se le-ta sklicuje.

Predlog 36: Datum prejema: 09.11.2020
Predlagamo, da naročnik sprejme pogoje morebitne odškodninske odgovornosti ponudnika, navedene v dokumentu Software License Agreement, saj slednji v celoti opredeljuje morebitno odškodninsko odgovornost ponudnika do naročnika. Ta dokument bo obvezna priloga k ponudbi.
Omenjeni dokument velja za vse uporabnike ponujene programske opreme, je univerzalen in velja na globalnem tržišču. OS je potrebno uskladiti z vsebino tega dokumenta, oziroma namesto sankcij v ustreznih členih OS navesti dokumente, ki opredeljujejo odškodninsko odgovornost lastnika ponujene programske opreme.
Svoj SLA imajo in uveljavljajo vsi svetovni proizvajalci programske opreme. Smatramo, da je naročnik kot dolgoletni uporabnik tovrstnih rešitev seznanjen z vlogo in vsebino takšnih pogodb, ki so za končnega uporabnika zavezujoče.
Odgovor 36: Naročnik se do SLA pogojev ponudnikov ne more opredeljevati, dokler jih dejansko v ponudbi ne prejme, lahko pa je to predmet obravnave v 2. fazi javnega naročila.

Predlog 37: Datum prejema: 09.11.2020
Predlagamo, da se v 29. členu OS dopiše, da je slovensko materialno in procesno pravo v celoti usklajeno s pravom, ki velja v državah, članicah EU.
Odgovor 37: Obligacijsko pravo je (pretežno) avtonomna pristojnost posamezne države članice EU, in kot tako med državami, če posameznega področja ne ureja pravo sprejeto na ravni EU, ni v celoti usklajeno.

Predlog 38: Datum prejema: 09.11.2020
Predlagamo črtanje zadnjega stavka (OS, 31. člen, 5 odstavek), saj je naročnik na svoji spletni strani objavil OS v slovenskem in angleškem jeziku.
Za popolno ujemanje obeh dokumentov je odgovoren naročnik, saj so pravne službe ponudnika preučili zgolj angleško verzijo OS, kar lahko povzroči nepotrebni pravni spor.
Odgovor 38: Naročnik se ne strinja s predlogom. Besedilo člena ostaja, kot objavljeno.

Vprašanje 39: Datum prejema: 09.11.2020
Kako namerava naročnik zagotoviti varovanje poslovnih skrivnosti, saj namerava omogočiti dostop do vsebin ponudbe tretjim osebam? (RD, 1.1, zadnji odstavek)
Takšna namera ni skladna z vsebino tega dokumenta (poglavje 1.14, prvi odstavek)?
Odgovor 38: Naročnik se bo v času izvajanja projekta posluževal storitev svetovanja s strani strokovnih svetovalcev ter strokovnjakov iz odvisnih družb za pomoč izvajanja projekta. Z vsemi strokovnimi svetovalci bomo imeli oz. imamo sklenjene NDA-je oz. je varovanje poslovne skrivnosti zajeto v njihovi pogodbi.

Vprašanje 40: Datum prejema: 09.11.2020
Zakaj je naročnik predvidel pogajanja s ponudniki po oddaji ponudbe, če spremembe razpisne in ponudbene dokumentacije niso dopustne po oddaji ponudbe? (RD, 1.7)
Odgovor 40: Stavek razpisne dokumentacije se nanaša na obdobje po oddaji končnih ponudb. V času postopka (tako v oddaji začetnih ponudb kot tudi tekom postopka pogajanj, vključno z oddajo končnih ponudb) se razpisna, pa tudi ponudbena dokumentacija lahko spreminjata skladno s pravili, ki jih določi naročnik, ter v okviru veljavne zakonodaje.

Vprašanje 41: Datum prejema: 09.11.2020
Ali namerava naročnik zahtevati še kakšna dodatna dokazila o skladnosti ponujene rešitve s tehničnimi zahtevami (skupini 10 in 20)? (RD, 1.12)
Odgovor 41: Ponudnik mora predložiti dokazila, kot so zahtevana v razpisni dokumentaciji, da bo naročnik lahko ugotovil izpolnjevanje tehničnih zahtev in pogojev naročnika. Morebitno dopolnjevanje ponudb je dovoljeno v skladu z določbami Zakona o javnem naročanju (ZJN-3). V skladu z določili zakonodaje o javnem naročanju in prakse DKOM ponudbe v delu, ki se nanaša na izpolnjevanje meril ni dovoljeno dopolnjevati ali spreminjati. Dopolnjuje se sicer lahko del, ki se nanaša na izpolnjevanje pogojev za sodelovanje (vendar v tem primeru ni dovoljeno spreminjanje predmeta ponudbe v tehničnem delu).

Vprašanje 42: Datum prejema: 09.11.2020
Kakšno metodologijo za ocenjevanje škode namerava uporabiti naročnik? (RD, 1.13)
Višina morebitne škode mora biti omejena in ponudniku znana še pred oddajo ponudbe, da lahko razume tveganje, ki ga prevzema z oddajo ponudbe.
Predlagamo črtanje zadnjega stavka v drugem odstavku poglavja 1.13.
Odgovor 42: Naročnik se ne omejuje glede vrste in višine škode v primeru, da izbrani ponudnik ne želi skleniti okvirnega sporazuma. Uveljavljal bo vso povzročeno in pravno priznano škodo, v primeru spora bo o tem odločalo sodišče.

Predlog 43: Datum prejema: 09.11.2020
Naročniku predlagamo, da zagotovi vzajemno odgovornost naročnika in ponudnika na osnovi enakih kriterijev za ocenjevanje obsega nastale škode in njeno poplačilo. (RD, 1.13, drugi odstavek, zadnji stavek, 1.15, zadnji odstavek).
Odgovor 43: Naročnik ne pristaja na predlog.

Vprašanje 44: Datum prejema: 09.11.2020
Kako bo ravnal naročnik, če v fazi Blueprinta pride do različnega razumevanje posameznih zahtev iz razpisne dokumentacije in razlik ni mogoče odpraviti? (RD, 1.15, 1.16)
Ponudba bo vsekakor skladna z vsemi navedenimi tehničnimi zahtevami v razpisni dokumentaciji.
Če ne pride do dogovora glede Blueprint dokumenta, ali to pomeni zaključek projekta?
Ali v tem primeru ponudniku grozijo kakršnekoli sankcije (bančna garancija, odškodnina,)?
Kako je v tem primeru s plačilom že opravljenih storitev ponudnika (npr. vzpostavitev platforme, delavnice, )?
Odgovor 44: Zahteve iz razpisne dokumentacije morajo biti napisane dovolj razumljivo, da pri njih ne bo prišlo do različnih razumevanj. V ta namen imajo ponudniki možnost (ki jo glede na število vprašanj dobro izkoriščajo), da zastavijo vprašanja, tako da je vsebina razpisne dokumentacije dovolj jasna tudi njim.
Dolžnost ponudnika je torej, da zahteva ustrezna pojasnila. Na drugi strani lahko pri pripravi Blueprintov kljub temu pride do dvoumnosti glede izpolnjevanja zahtev v tem primeru se razlaga po splošnih obilgacijskopravnih načelih vrši v korist šibkejše stranke, kar pomeni, da bi naročnik za uveljavitev njegove (sicer nejasne) razlage moral zahtevati spremembo osnovne zahteve, ki se ustrezno vrednoti po pogodbi.
Razen če bi prišlo do fundamenntalnih razhajanj v razumevanju (do česar pa glede na prvi odstavek v resnici ne bi smelo priti), skuša pravo pogodbena razmerja ohraniti v veljavi, kar pomeni da pogodba ne preneha, niti se zaradi tega ne morejo uveljavljati zavarovanja izvajalec bo moral vseeno izvesti naloge vsaj v obsegu, ki je zahtevan po zanj ugodnejši interpretaciji zahteve iz razpisne dokumentacije (sicer so vse naštete sankcije mogoče), ob upoštevanju tega pa se potem uporabijo pravila, kot je navedeno v drugem odstavku tega pojasnila.
Navedeno pojasnilo sicer po mnenju naročnika ne vpliva na ponudnikovo možnost priprave ponudbe, naročnik pa ga je dal z namenom, da ponudnike seznani, da je v njegovem interesu izvedba projekta in ne prekinitev pogodbe tekom izvajanja. Konkretnejših pojasnil naročnik v zvezi s tem ne more dati, saj razpon »razhajanj« v interpretaciji sega od nebistvenih razlik v konceptu, pa do popolnoma drugačnih predstav o zahtevah naročnika, slednjih pa praviloma ne bi smelo biti.

Vprašanje 45: Datum prejema: 09.11.2020
Kako naročnik komentira ta del zakonodaje? (RD, 1.18)
Uredba o finančnih zavarovanjih, 7. Člen: (1) Višina finančnega zavarovanja za dobro izvedbo pogodbenih obveznosti znaša največ 10 % pogodbene vrednosti (z DDV). Kadar naročnik pri plačilu zadrži del zaračunane vrednosti, zadržana sredstva in finančno zavarovanje za dobro izvedbo pogodbenih obveznosti skupaj ne smejo presegati 10 % pogodbene vrednosti (z DDV).
V primeru, da naročnik uveljavi finančno zavarovanje za dobro izvedbo pogodbenih obveznosti, bo verjetno prišlo za ustavitve projekta. Kako si je naročnik zamislil posledice uveljavitve finančnega zavarovanja?
Odgovor 45: Naročnik bo ravnal v skladu s predpisi in okvirnim sporazumom.

Vprašanje 46: Datum prejema: 09.11.2020
Ali je naročnik pripravljen izločiti čas testiranja, ki si ga je rezerviral v fazi implementacije projekta (mejniki, zaključno testiranje, skupaj 13 mesecev) iz rokovnika izvedbe projekta?(RD, 3, 1. Faza)
Ob tem naročnik še omejuje število delavnic/teden (največ dva dni).
Ali lahko ponudnik načrtuje vzporedno izvajanje mejnikov projekta?
Ali bo rok izvedbe projekta sorazmerno podaljšan, če pride do podaljšanja posameznih mejnikov projekta, tudi Blueprint faze, po krivdi naročnika?
Odgovor 46: Naročnik predvideva, da se bo testiranje rezultatov posameznega mejnika (30 dni) odvijalo neodvisno in vzporedno z naslednjim mejnikom, zato to ni razlog za podaljševanje časovnice. Zaključno testiranje (90 dni) po končani implementaciji pa podaljšuje projekt za dodatnih 90 dni, kar mora ponudnik vključiti v svoj terminski plan, katerega skupno trajanje ne sme presegati 30 mesecev od podpisa pogodbe. Naročnik ne predvideva izvajanja več mejnikov hkrati, razen v primeru da se izkaže, da bodo resursi na strani naročnika to dopuščali. V kolikor pride do podaljšanja posameznih mejnikov (tudi Blueprint faze) po krivdi naročnika, se časovnica projekta sorazmerno podaljša.

Vprašanje 47: Datum prejema: 09.11.2020
Ali lahko člani konzorcija ponudnikov k ponudbi priložijo vsak svoj SLA (Service Level Agreement) dokument? (RD, 3, 1. Faza)
Odgovor 47: Da, ponudniki lahko ponudijo vsak svoj SLA, vendar morajo vsi ponujeni SLA zajemati najmanj zahteve, ki izhajajo iz naročnikovih SLA zahtev.

Vprašanje 48: Datum prejema: 09.11.2020
Ali je naročnik pripravljen spoštovati pravila uporabe in ravnanja z naročeno programsko rešitvijo, ki ji bo postavil ponudnik? (RD, 2. Faza, 3. skupina)
Ponudnik bo ponudbi priložil dokument (SLA- Software License Agreement), ki bo v celoti opredelil pravice uporabnika (naročnika programske rešitve) glede načina uporabe in ravnanja s ponujeno rešitvijo. Tovrstni dokumenti so standardni in veljavni na globalnem tržišču.
Odgovor 48: Naročnik se do SLA pogojev ponudnikov ne more opredeljevati, dokler jih dejansko v ponudbi ne prejme. SLA bo naročnik pregledal ob prejemu ponudbe, vsebina SLA je lahko predmet 2. faze javnega naročila.

Predlog 49: Datum prejema: 09.11.2020
Predlagamo, da naročnik črta tretji odstavek. (RD, 2. Faza, 4. skupina).
Ponudnik bo oddal ponudba, ki bo v celoti sledila tehničnim zahtevam, ne more pa prevzeti odgovornosti za neznane zahteve.
Odgovor 49: Naročnik se ne strinja s predlogom. Zapis izhaja iz tveganja nastanka okoliščine, kjer ponudnik v ponudbi kakšnih stroškov (npr. določen sklop licenc) ne upošteva, kasneje pa od naročnika zahteva, da jih kljub temu plača, saj drugače rešitev kot celota ne bo delovala.

Vprašanje 50: Datum prejema: 09.11.2020
Kako naj ponudnik naročniku v naprej zagotavlja možnost dodajanja programskih modulov na osnovi zgolj informativnega zapisa? (RD, 2. Faza, 4. Skupina, zadnji odstavek)
Vsaka potreba po širitvi funkcionalnosti, oziroma dodajanju modulov, je predmet dodatne presoje ponudnika (in dodatnega naročila).
Odgovor 50: Menimo, da smo na vprašanje odgovorili pri odgovoru na 49. vprašanje

Vprašanje 51: Datum prejema: 09.11.2020
Ali je naročnik pripravljen izločiti predvideni lastni čas testiranja rezultatov posameznih mejnikov (skupaj 10 mesecev) iz ponujenega rokovnika izvedbe? (RD, 4.3, 1.)
Ponudnik mora imeti proste roke tako pri načinu, kot tudi rokovniku izvedbe implementacije projekta. V praksi to pomeni, da lahko ponudnik zaključi projekt v dogovorjenem roku, četudi se dela na posameznih mejniku podaljšajo. Prav zaradi tega ponudnik načrtuje vzporedno izvajanje mejnikov projekta.
Vsakršno omejevanje ponudnika s strani naročnika, pa naj gre za trajanje delavnic, dostop do informacijskega okolja naročnika, predvideno časovnico testiranja, lahko ponudniku povzroči dodatno tveganje.
Odgovor 51: Naročnik predvideva, da se bo testiranje rezultatov posameznega mejnika (30 dni) odvijalo neodvisno in vzporedno z naslednjim mejnikom, zato to ne bo podaljševalo časovnice. Zaključno testiranje (90 dni) po končani implementaciji pa podaljšuje projekt za dodatnih 90 dni, kar mora ponudnik vključiti v svoj terminski plan, katerega skupno trajanje ne sme presegati 30 mesecev od podpisa pogodbe. Naročnik ne predvideva izvajanja več mejnikov hkrati, razen v primeru da se izkaže, da bodo resursi na strani naročnika to dopuščali. Naročnik je omejitve navedel ravno z namenom, da ponudniki razumejo naročnikova pričakovanja in zmožnosti in si na ta način pri pripravi terminskega plana zmanjšajo tveganje nastanka zamud na projektu.

Predlog 52: Datum prejema: 09.11.2020
Predlagamo, da v Blueprint dokumentu poleg podrobnega opisa izvedbe projektnih aktivnosti po posameznih mejnikih projekta natančno dogovorimo tudi pogoje, ki jih mora zagotovi naročnik in ki ponudniku omogočajo nemoteno izvedbo projektnih aktivnosti v dogovorjenem roku.
Odgovor 52: Naročnik se z navedenim strinja. Vendar pa mora ponudnik v tej fazi ob oddaji terminskega plana upoštevati vse omejitve, ki so zahtevane v razpisni dokumentaciji.

Vprašanje 53: Datum prejema: 09.11.2020
Ali je naročnik pripravljen črtati drugi stavek prvega odstavka? (FZ, 1.4)
Ponudnik lahko prevzame odgovornost le za storitve, ki so predmet ponudbe in bodo podrobneje opredeljene v Blueprint dokumentu. Vse drugo je predmet dodatnih naročil in plačil.
Odgovor 53: Naročnik se ne strinja s predlogom. Zapis izhaja iz tveganja nastanka okoliščine, kjer ponudnik v ponudbi kakšnih stroškov (npr. določen sklop licenc) ne upošteva, kasneje pa od naročnika zahteva, da jih kljub temu plača, saj drugače rešitev kot celota ne bo delovala.

Predlog 54: Datum prejema: 09.11.2020
Predlagamo, da naročnik besedo ''programiranje'' izpusti in zapiše človek/dan. (FZ, 1.4, 5. odstavek)
Odgovor 54: Naročnik skozi JN sicer kupuje obstoječo, delujočo rešitev, kjer se pričakuje, da dodatnega programiranja ne bo. Pri tem pa vseeno pričakuje, da bodo v fazi BluerPrinta identificirane zahteve, ki bodo zahtevale nadgradnjo programske opreme izključno na podlagi naročnikove zahteve in izven siceršnjega predmeta naročila. Zato so ponudniki dolžni tudi za ta segment podati ceno. Zaradi navedenega vztrajamo da ta beseda ostane v zapisu.

Vprašanje 55: Datum prejema: 09.11.2020
Kako bo ravnal naročnik, če ne pride do potrditve Blueprint dokumenta, ker se ponudnik ne strinja z zahtevanimi dopolnitvami naročnika in jih tudi utemeljeno zavrne? (FZ, 1.4)
Odgovor 55: Na vsebinsko enako vprašanje je naročnik že predhodno podal odgovor.

Vprašanje 56: Datum prejema: 09.11.2020
Ali je naročnik pripravljen umakniti omejitve glede izvajanja delavnic, saj slednje lahko po nepotrebnem podaljša tako rok izvedbe Blueprint faze, kot tudi posameznih mejnikov?
Odgovor 56: Naročnik je na vsebinsko enako vprašanje odgovoril v odgovoru 16.

Vprašanje 57: Datum prejema: 09.11.2020
Ali se naročnik strinja, da lokalizacija ponujene programske rešitve in uporabniške dokumentacije ni predmet posameznega mejnika, ampak mora biti zaključena v dogovorjenem roku izvedbe projekta? (FZ, 1.6)
Odgovor 57: Naročnik se s predlogom ne strinja. Lokalizacija ponujene rešitve mora biti izvedena ob začetku 'go-live' posameznega modula (torej ob zaključenem posameznem mejniku). Prav tako mora naročnik in njegovi inštruktorji imeti dostop do uporabniške dokumentacije, da se izobraževanje uporabnikov in uvajanje funkcionalnosti v uporabo (roll-out) sploh lahko prične izvajati.

Vprašanje 58: Datum prejema: 09.11.2020
Ali se naročnik strinja, da bodo pravice naročnika glede načina in upravljanja ponujene programske rešitve dogovorjena z Blueprint dokumentom in da morajo le-te ustrezati standardnim pravilom in omejitvam, ki jih bo ponudnik navedel v dokumentaciji, ki bo obvezna priloga ponudbe? (FZ, 1.6, dolžnosti ponudnika)
Odgovor 58: Naročnik se do pogojev ponudnikov ne more opredeljevati, dokler jih dejansko v ponudbi ne prejme, lahko pa je to predmet obravnave v 2. fazi javnega naročila.

Vprašanje 59: Datum prejema: 09.11.2020
Ali bo naročnik opredelil in pojasnil vse zahteve, ki se tičejo slovenske zakonodaje, kateri bi naj ustrezala ponujena programska rešitev, v Blueprint fazi? (FZ, 1.8).
Problem je v tem, da se izvajalec obveže zagotoviti rešitev za neznano vsebino in količino. Ker je cena fiksna, bi morale te informacije biti na voljo pred oddajo ponudbe.
Odgovor 59: Da, naročnik bo opredelil vse zahteve v Blueprint fazi.

Vprašanje 60: Datum prejema: 09.11.2020
Kako si naročnik predstavlja realizacijo zahteve, navedeno v četrti alineji? (FZ, 1.11).
Ponudnik se zavezuje zagotoviti le tiste funkcionalnosti, ki so navedene v tehničnih zahtevah in tiste, ki bodo dogovorjene v Blueprint fazi.
Odgovor 60: Zapis izhaja iz tveganja nastanka okoliščine, kjer ponudnik v ponudbi kakšnih funkcionalnosti ne bi predvideval (ker niso eksplicitna zahteva naročnika), kasneje pa bi se izkazalo, da brez manjkajoče funkcionalnosti rešitev ne bi delovala. Ponudnik bi tako od naročnika zahteval, da manjkajočo funkcionalnost doplača, saj drugače rešitev kot celota ne bi delovala.

Vprašanje 61: Datum prejema: 09.11.2020
Ali se naročnik strinja, da bo ponudnik realiziral le tiste zahteve, ki so zapisane v tehničnih zahtevah in tudi dogovorjene v Blueprint dokumentu, torej tudi omejeno število poročil? (FZ, 1.11)
Odgovor 61: Naročnik se strinja, da bo ponudnik realiziral le v Blueprint fazi dogovorjeno število poročil. Priprava dodatnih poročil, na podlagi potreb, ki bodo nastale v času roll-out posameznih modulov, bodo predmet Change request-ov.

Predlog 62: Datum prejema: 09.11.2020
Ponudnik se je seznanil z vsebino poglavja 1.12, a za njeno realizacijo ne more prevzeti vnaprejšnje odgovornosti.
Odgovor 62: Naročnik je z zapisom želel ponudnike seznaniti s potrebo po širitvi IPLP rešitve (ločeno od okvirjev/obsega tega razpisa) na odvisne družbe in od ponudnikov pričakuje, da bodo njihovi sistemi dovolj fleksibilni in odprti, da bodo v tem smislu lahko sledili potrebam naročnikovih odvisnih družb.

Vprašanje 63: Datum prejema: 09.11.2020
Ali se naročnik strinja, da bodo pravice IT strokovnjakov naročnika, ki se nanašajo na upravljanje ponujene programske rešitve, dogovorjene v Blueprint fazi? (FZ, 2.7)
Odgovor 63: Da, ponudnik se strinja da bodo pravice IT strokovnjakov naročnika, ki se nanašajo na upravljanje ponujene programske rešitve, dogovorjene v Blueprint fazi.

Vprašanje 64: Datum prejema: 09.11.2020
Ali se naročnik strinja, da lahko izvajanje mejnikov projekta poteka vzporedno, s tem pa ima ponudnik pravico, da sicer dogovorjene rokovnike posameznih mejnikov dinamično spreminja (skrajša ali podaljša) na način, da bo lahko zagotovil izvedbo projekta v dogovorjenem roku? (FZ, 3., 3.1).
Edini pravi kriterij za pravočasno dokončanje projekta je njegov pravočasni zaključek. Posamezni mejniki so/morajo biti fleksibilni, saj je to delovni dokument izvajalca, načrt izvedbe. Postavil ga je izvajalec kot oceno, ne obveznost, zato morebitni penali vezani na mejnik nimajo nobenega smisla.
Odgovor 64: Naročnik se lahko strinja s ponudnikovim predlogom, da se prehodne mejnike dinamično spreminja, vendar se morajo skladno s tem zamakniti tudi plačila, ki so vezana na realizacijo na posameznem mejniku. Takšno zamikanje, s katerim se mora naročnik eksplicitno strinjati, ne sme vplivati na končni rok zaključka projekta. Naročnik se nikakor ne strinja, da se zaradi zamikov lahko več mejnikov izvaja vzporedno, razen če se bo izkazalo (glede na resurse, ki jih bo imel naročnik takrat na voljo), da je (začasno) vzporedno izvajanje dveh mejnikov izvedljivo. Vsak dinamični premik enega mejnika bo tako imel vpliv na začetek izvajanja nadaljnjih mejnikov.

Vprašanje 65: Datum prejema: 09.11.2020
Ali bo naročnik za potrebe vzpostavitve testnega okolja zagotovil potrebne testne licence sistemske programske opreme (OS, DB)? (FZ, 3., 3.3)
Odgovor 65: Da, v kolikor gre za Microsoft programsko opremo.

Vprašanje 66: Datum prejema: 09.11.2020
Ali se naročnik strinja, da mora naročnik podati vse pripombe na delovanje ponujene programske rešitve v pisni obliki (ali e-pošti) najpozneje 1 mesec pred zaključkom finalnega testiranje (naročnik predvidel 3 mesece)? (FZ, 3., 3.5)
Odgovor 66: Naročnik se s predlogom ne more strinjati. Naročnik bo v času 3-mesečnega testiranja in tudi po tem obdobju prijavljal napake, ki se morajo odpraviti. Naročnik in izvajalec se bosta v tem 3-mesečnem obdobju uskladila, katere napake se morajo odpraviti pred zaključkom projekta in katere se odpravijo v času rednega vzdrževanja. Del končnega primopredajnega zapisnika bo tako tudi predvidoma t.i. »open points list«, kjer bodo navedene napake, ki so bile identificirane v testnem obdobju, vendar se bodo odpravile v času poimplementacijskega vzdrževanja.
Naročnik zahteva, da bo skozi celotno obdobje projekta vzpostavljen sistem komunikacije na način, da se bodo vse napake pisno evidentirale v sistemu prijave in odpravljanja napak, ki ga zagotovi ponudnik.

Vprašanje 67: Datum prejema: 09.11.2020
Ali je naročnik pripravljen sprejeti, da bo stroške kupljene ali najete programske opreme plačeval v naprej, za vsako leto produkcijske uporabe rešitve? (FZ, 3., 3.7)
Odgovor 66: V razpisni dokumentaciji je predvideno kvartalno plačevanje stroškov v naprej, vendar naročnik dovoljuje tudi morebitno spremembo tega določila v 2. fazi javnega naročila.

Vprašanje 68: Datum prejema: 09.11.2020
Ali lahko ponudnik ob aktivaciji testnih licenc aktivira vzdrževalno pogodbo, po kateri bo naročnik plačeval stroške letnega vzdrževanja in podpore za količino nameščenih testnih licenc? (FZ, 5., 5.1)
Le v tem primeru lahko ponudnik zagotavlja nemoteno delovanje ponujene programske rešitve.
Odgovor 68: Vsi stroški, povezani s testnimi licencami, morajo biti zajeti v implementacijskih stroških (1. skupina ponudbenega predračuna), ne glede na to, ali gre za uporabo določenega števila licenc, ali za izvajanje vzdrževanja in podpore.

Vprašanje 1: Datum prejema: 10.11.2020
V prilogi 11 so tehnične zahteve za ročne terenske naprave, kjer je med drugim zapisana tudi zahtevana teža ter zmogljivost baterije. Med priznanimi proizvajalci ni takšnega modela, ki bi ustrezal glede teže kot tudi glede zmogljivosti baterije. Naj kot primer navedem po karakteristikah najbližji terminal priznanega proizvajalca, ki je s standardno baterijo lažji od zahtevanih 250g, ampak ne zadostuje zahtevam glede zmogljivosti baterije, obstaja pa možnost z boljšo baterijo, ki ima 5400mAh, je pa zato težja, saj tehta 269g.
Glede na zgornje zapisano bi dodali še, da znotraj teh dimenzij, ki bi hkrati ustrezali še drugim kriterijem, ni možno dobaviti naprave priznanega proizvajalca, zato nas zanima, če lahko naročnik morda nekoliko omili sistemske zahteve za ročne terminale pri teži (recimo do 280g), odstopanju v dimenziji (npr. tako, da bi bila ustrezna tudi odstopanja manjša od 2mm).
Odgovor 1: Naročnik želi v tehničnih zahtevah za terenske naprave ponudnikom prikazati le cenovni in kakovostni rang naprav, ki jih pričakuje za izvajanje terenskih aktivnosti. Vsekakor je želja, da ponudnik zagotovi napravo, ki je standardna na trgu in v tem rangu. Zato se strinjamo s ponudnikovimi predlogi, da se tehnične zahteve omili na način, da se omogoča standardno baterijo (malo manj mAh), da se omili sistemske zahteve za ročne terminale pri teži (do 280g) in da so ustrezna tudi odstopanja manjša od 2mm.

Vprašanje 2: Datum prejema: 10.11.2020
Imamo še dodatno vprašanje glede Bluetooth zahtev. Se bodo tu uporabljale kakšne specifične zadeve, ki bodo uporabljale najnovejši Bluetooth, ali bi bil s sprejemljiv tudi lahko Bluetooth v4.1 LE?
Odgovor 2: Naročnik v naslednjih letih vidi potrebe po uporabi najnovejše Bluetooth tehnologije, zato Bluetooth v4.1 LE za nas ni sprejemljiv.

Vprašanje 1: Datum prejema: 11.11.2020
Na kašen način bo naročnik zavaroval vsebino ponudbeno dokumentacijo ponudnika, označeno kot poslovna skrivnost in prevzel odgovornost za morebitno zlorabo le-te s strani tretjih oseb (npr. s strani naročnika izbrani zunanji svetovalec)? (RD, Priloga: Izjava ponudnika glede razkritja vsebine ponudb).
Odgovor 1: Morebitni zunanji svetovalci bodo zavezani z izjavo oziroma dogovorom o poslovni skrivnosti, ki bo imel običajno vsebino, med drugim, prepoved razkritja tretjim osebam, uporabo zgolj v okviru svetovanja naročniku, ter uničenje po zaključku svetovanja. S svetovalci ne bomo delili cenovne politike ponudnikov.