Daugiau konkurencijos IT paslaugų viešuosiuose pirkimuose

Lietuvos Aukščiausiasis Teismas šių metų vasario 2 d. išnagrinėjo bylą dėl Bendrojo pagalbos centro (BPC) informacinės sistemos viešojo pirkimo sąlygų teisėtumo. Šiuo atveju turime unikalią situaciją bei itin svarbius teismo išaiškinimus, kurie aktualūs informacinių technologijų (IT) paslaugų viešuosius pirkimus vykdančioms perkančiosioms organizacijoms.

Kur problema?

Viena iš byloje kilusių problemų – reikalavimas, pagal kurį tiekėjai yra įpareigojami pasirūpinti reikalingomis perkančiosios organizacijos (šiuo atveju – BPC) jau turimos programinės įrangos aplikacijų programavimo sąsajomis (angl. Application Programming Interface, API) ir dokumentacija bei atlikti reikalingas integracijas su nauja sistema.

Paprastai tariant, API yra tam tikros techninės „instrukcijos“ apie perkančiosios organizacijos jau naudojamas IT sistemas, t. y. jų sąveikavimą su kitomis IT sistemomis. API esmė dažnai atskleidžiama per įprastą visuomenei praktinį pavyzdį – vakarieniaujant restorane vyksta duomenų mainai tarp restorano klientų, restorano padavėjo bei restorano virtuvės. Padavėjas šiuo atveju atspindi programinės įrangos API, kitaip tariant – yra sąsaja, kuri komunikuoja tarp dviejų sistemų – restorano klientų (arba programuotojo, integruojančio sistemas) ir restorano virtuvės (t. y. programinės įrangos, su kuria atliekama integracija).  Tiekėjams faktinis API turėjimas yra reikalingas tam, kad jie galėtų sukurti informacinę sistemą, tinkamai sąveikaujančią su perkančiosios organizacijos ir trečiųjų asmenų naudojamomis programomis.

Tačiau šiuo atveju perkančioji organizacija nustatė pareigą būtent patiems tiekėjams užsitikrinti šiuo metu BPC naudojamos ir į pirkimo objektą net nepatenkančios programinės įrangos API. Grįžtant prie aukščiau esančio pavyzdžio – eliminavo padavėją, taigi neteko duomenų šaltinio.

Ir čia turime problemą, kadangi įtvirtinus tokį reikalavimą, šiuos API užsitikrinti iš esmės gali tik atitinkamą programinę įrangą jau anksčiau sukūrę / įdiegę tiekėjai, t. y. įtvirtinamas konkurencijos ribojimas.

Tokia situacija platesniame kontekste gali turėti dar didesnę neigiamą įtaką, kadangi pačioms perkančiosioms organizacijoms neužsitikrinus reikalingų API, sukuriama uždara sistema (angl. „vendor lock-in“), kuomet perkančiajai organizacijai įvykdžius vieną pirkimą, visi kiti pirkimai (dėl papildomos informacinės sistemos, dėl integracijos, sistemos / įrangos priežiūros, aptarnavimo ir kt. paslaugų) vykdomi įsigyjant šias paslaugas tik iš vieno tiekėjo, t. y. tiekėjo, kuris jau anksčiau teikė paslaugas perkančiajai organizacijai. Tai, be kita ko, kelia didelę riziką ir korupciniu požiūriu.

LAT: pasiūlymo atitiktį turi vertinti perkančioji organizacija, o ne trečiasis asmuo

Vienas aspektų, kuriuos identifikavo LAT, yra tai, jog pirkimo sąlygos sudarė galimybę pirkimo laimėtoją pasirinkti ne perkančiajai organizacijai, o privačiam subjektui (t. y. programinės įrangos gamintojui, kuris turi reikalingas API).

Kaip nustatyta byloje, programinės įrangos, kurią API tiekėjai turėjo užsitikrinti, gamintojas iš tiesų sudarė galimybę pirkimo dalyviams šias API sąsajas gauti. Tačiau šis privatus subjektas iš esmės galėjo atsisakyti suteikti reikiamų API prieigą potencialiems tiekėjams remdamasis ne kokiais nors kvalifikaciniais, objektyviais reikalavimais, o išimtinai savo subjektyviu vertinimu (pavyzdžiui, verslo intereso nebuvimu).

Taigi, šiuo atveju BPC informacinės sistemos (t. y. visuomenei svarbaus ir reikšmingo objekto) įsigijimo pirkime reikalavimus de facto kėlė ne pats BPC / PAGD, o privatus subjektas – šiuo metu BPC jau turimos ir naudojamos įrangos gamintojas. O tokia situacija, kaip konstatavo LAT, pažeidžia viešųjų pirkimų principus ir nepagrįstai riboja tiekėjų konkurenciją.

LAT: dėl perkančiųjų organizacijų neapdairumo kylančios neigiamos pasekmės negali būti perkeliamos tiekėjams

LAT taip pat priėmė svarbius išaiškinimus, patvirtinančius, kad perkančiosios organizacijos negali tiekėjams perkelti pareigos užsitikrinti jų jau turimos ir naudojamos programinės įrangos API.

Kaip nurodė teismas, net jeigu dėl kokių nors priežasčių (savo neapdairumo, siekio išvengti administracinės naštos ar dar kitų priežasčių) valstybės institucija šia galimybe (t. y. užsitikrinti reikalingas API sąsajas ir jų dokumentaciją) nepasinaudojo, neigiami padariniai (papildomos išlaidos API prieigoms gauti (taigi ir išaugusi Pirkimo kaina), konkurencijos ribojimas) tokias prieigas suteikiant tik programinės įrangos gamintojo pasirinktiems subjektams, šiems neturint jokios atsakomybės dėl atsisakymo suteikti prieigas, negali būti perkeliami potencialiems naujo viešojo pirkimo dalyviams. Priešingas aiškinimas reikštų neteisėtą pusiausvyrą tarp perkančiajai organizacijai ir viešojo pirkimo dalyviams tenkančios rizikos siekiant pirkimo rezultato, o tai vertintina kaip lygiateisiškumo principo pažeidimas.

Kas toliau?

Aptariama LAT nutartis neabejotinai itin reikšmingai prisidės prie konkurencijos IT viešuosiuose pirkimuose didinimo. Turime aiškią žinutę – perkančiosios organizacijos negali neigiamų pasekmių, kilusių dėl savo neapdairumo ar ankstesniuose pirkimuose padarytų klaidų, perkelti tiekėjams.

Tai reiškia, kad įsigydamos IT paslaugas perkančiosios organizacijos turi iš anksto įvertinti ateityje planuojamus daryti programinės įrangos / sistemos atnaujinimo, papildymo, integracijos ir kitus darbus. Ir, atitinkamai, jau pirminiame įrangos įsigijimo etape nustatyti tokias pirkimo dokumentų / pirkimo sutarties sąlygas, kurios perkančiosioms organizacijoms suteiktų visas reikalingas sąsajas, dokumentaciją, įskaitant ir teisės šiuos duomenis atskleisti tretiesiems asmenims užtikrinimą.

Tinkamai neatlikus šių darbų pirminiame etape, vėliau gali tekti patirti papildomas išlaidas – pačiai perkančiajai organizacijai kreiptis į įrangos gamintoją, prašant reikiamos dokumentacijos, arba, nepavykus jos gauti, netgi svarstyti apie atitinkamos programinės įrangos pakeitimą (ypatingai, jei jos vertė yra ženkliai mažesnė už planuojamą įsigyti naują sistemą, kaip atsitiko ir šiuo atveju aptariamoje byloje).