msi ukraine eprocurement deliverable 1_final_uk - submit

JANUARY 2015

This publication was produced for review by the United States Agency for International Development.It was

prepared by Bertram I. Spector, Svetlana Winbourne and Phyllis Dininio, Management Systems International.

ТЕХНІЧНА ПІДТРИМКА ІНІЦІАТИВИ ВПРОВАДЖЕННЯ ЕЛЕКТРОННИХ ТЕНДЕРІВ У КИЄВІ, УКРАЇНА

(ПЕРШИЙ ЕТАП) ДОКУМЕНТ 1: ТЕХНІЧНІ ТА БІЗНЕС-ВИМОГИ

29 ТРАВНЯ 2015, ДООПРАЦЬОВАНО 9 ЧЕРВНЯ 2015

Цей документ було підготовлено для розгляду Агентством США з Міжнародного Розвитку. Документ був розроблений Тато Урджумелашвілі, Давидом Марганією та Юрієм Громовим, Management Systems International.

ТЕХНІЧНА ПІДТРИМКА ІНІЦІАТИВИ ВПРОВАДЖЕННЯ ЕЛЕКТРОННИХ ТЕНДЕРІВ У КИЄВІ, УКРАЇНА (ПЕРШИЙ ЕТАП) ДОКУМЕНТ 1: ТЕХНІЧНІ ТА БІЗНЕС-ВИМОГИ

Management Systems International

Corporate Offices

200 12th Street, South

Arlington, VA 22202 USA

Tel: + 1 703 979 7100

Контракт AID-121-O-15-00012

ЗАЯВА ПРО НЕПРИЙНЯТТЯ ВІДПОВІДАЛЬНОСТІ Думки автора, виражені в цій публікації, не обов'язково відображають точку зору Агентства Сполучених Штатів з Міжнародного Розвитку або Уряду Сполучених Штатів.

ЗМІСТ

АБРЕВІАТУРИ ........................................................................................................................ 1

ВСТУП ................................................................................................................................... 2

БІЗНЕС-ЦІЛІ ТА ТЕХНІЧНІ ВИМОГИ ....................................................................................... 4

Процес розвитку ProZorro ....................................................................................................................... 4

ProZorro та євроінтеграція ...................................................................................................................... 6

ProZorro та законодавство України ........................................................................................................ 7

ProZorro та корупція ................................................................................................................................ 8

ProZorro та державно-приватне партнерство ....................................................................................... 9

ProZorro та малий і середній бізнес ..................................................................................................... 10

ProZorro, КМДА та інші державні установи з закупівель ................................................................... 11

PROZORRO: АНАЛІЗ ПРОГАЛИНГ ТА ТЕХНІЧНИЙ АУДИТ .................................................... 12

Технічна архітектура ProZorro ............................................................................................................... 13

Масштабування ProZorro ...................................................................................................................... 16

Безпечність ............................................................................................................................................. 17

Адміністрування сервісних платформ, перевірка даних .................................................................... 17

Електронний цифровий підпис............................................................................................................. 18

Аналітика ЦБД ........................................................................................................................................ 18

Прозорість системи ............................................................................................................................... 19

Реверсивний аукціон ............................................................................................................................. 19

Виконання угод, інтеграція з зовнішніми системами ......................................................................... 20

Функціональний модуль «План закупівель» ....................................................................................... 21

Гарантія (Гарантування вкладів) ........................................................................................................... 21

Функціональний модуль «Оскарження» ............................................................................................. 22

Чорний список ....................................................................................................................................... 23

Функціональний модуль «Пошук» ....................................................................................................... 23

РИЗИКИ У ВПРОВАДЖЕННІ PROZORRO .............................................................................. 23

ВИСНОВКИ ТА НАСТУПНІ КРОКИ ........................................................................................ 25

Список першочергових вимог для подальшого розвитку системи ProZorro .................................... 26

Допомога КМДА..................................................................................................................................... 28

Масштабування ProZorro ...................................................................................................................... 28

ДОДАТОК 1. СПИСОК ПРОВЕДЕНИХ ЗУСТРІЧЕЙ ................................................................. 30

ТЕХНІЧНА ПІДТРИМКА ІНІЦІАТИВИ ВПРОВАДЖЕННЯ ЕЛЕКТРОННИХ ТЕНДЕРІВ У КИЄВІ, УКРАЇНА (ЕТАП ПЕРШИЙ) 1

АБРЕВІАТУРИ

API Інтерфейс прикладного програмування

BI Бізнес-аналітика

ЦБД Центральна база даних

Кабмін Кабінет Міністрів

CPV Загальний словник закупівель

ДКПП Державний класифікатор продукції та послуг

DOS Відмова від обслуговування

ЕЦП Електронно-цифровий підпис

ЄС Європейський союз

JSON Текстовий формат обміну даними, що базується на JavaScript

КМДА Київська міська державна адміністрація

МЕРТ Міністерство економічного розвитку і торгівлі України

MSI Management Systems International

MVP Найменш життєздатний продукт

REST Передача репрезентативного стану

МСП Малі та середні підприємства

SOA Сервіс-орієнтована архітектура

SSL Криптографічний протокол, що забезпечує захищений обмін даними

TI Transparency International

Грн Українська гривня

Дол Долар США


ВСТУП

Цей звіт містить аналіз технічних і професійних вимог зацікавлених сторін щодо

електронних закупівель. Він узгоджує і порівнює ці вимоги з функціоналом і можливостями

системи ProZorro, а також рекомендує доповнення і зміни функціональності системи для

успішного і ефективного впровадження електронних закупівель в Київській міській державній

адміністрації (КМДА) та інших державних установах в Україні.

Метою оцінки було визначення бізнес-потреб та вимог до системи електронних закупівель

КМДА та Національної системи електронних закупівель. Фахівцям, які проводили аналіз,

були поставлені такі завдання:

Визначити ключові бізнес-вимоги та відповідні технічні вимоги пілотного

запровадження Національної системи електронних закупівель.

Провести зустрічі з широким колом зацікавлених сторін, щоб зрозуміти потреби,

пріоритети та обмеження запропонованого рішення.

Провести аналіз прогалин і технічний аудит мінімально життєздатного продукту (MVP),

включаючи код, що в даний час тестується в кількох урядових установах, в тому числі у

КМДА.

На основі оцінки бізнес-потреб та аналіза MVP, розглянути два варіанти системи

закупівель для КМДА: (1) використання КМДА Національної системи електронних

закупівель, яка розробляється і тестується або (2) розробка КМДА власної системи з

урахуванням сумісності з національною системою.

Виявити прогалини та запропонувати технічні рішення пілотування системи

електронніх закупівель у місті Києві.

Була також поставлена задача знайти відповіді та такі питання:

1. Які є можливості для державно-приватного партнерства в підтримку цієї ініціативи?

Як технології та інші витрати мають бути розподілені між всіма зацікавленими

сторонами?

2. Чи всі зацікавлені сторони, задіяні в цій ініціативі, зокрема, малий та середній

бізнес, прагнуть надавати товари і послуги в місті Києві?

3. Які основні законодавчі та політичні обмеження для остаточної автоматизації і

безпаперового рішення для закупівлі в Києві / Україні?

4. Як ця ініціатива бореться з корупцією та зміцнює довіру до діяльності державного

сектора?

5. Як ця ініціатива підтримує цілі європейської інтеграції для України?

6. Як ця ініціатива може бути поширена в інших містах і регіонах України? Які

основні можливості?

7. Чи забезпечує національна система електронних закупівель з центральною базою

даних тендерів прозору та справедливу конкуренцію, зниження ризиків


інформаційної безпеки та конкуренцію серед постачальників, що пропонують

інтерфейси тендерів бази даних ряду клієнтів в державному секторі?

8. Отримати розрахунки, надані третіми сторонами, вартості розробки системи, а

також апаратного та комерційного програмного забезпечення в підтримку пілотної

ініціативи (в першу чергу серверів).

Результатом проведеної роботи мали бути такі документи:

ДОКУМЕНТ #1 Місто Київ

1.1 Бізнес-цілі і технічні вимоги до системи

1.2 Аналіз прогалин: вимоги Києва та запропоноване рішення

Національна система електронних закупівель

1.3 Оцінка бізнес та технічних вимог до національної системи

1.4 Технічний аудит MVP

ДОКУМЕНТ #2 Місто Київ

2.1 Детальний план проекту

2.2 Розробка та оцінка вартості системи і запит на затвердження фінансування у АМР

США

Національна система електронних закупівель

2.3 Рекомендації для технічних модифікацій і реалізації рішення національної системи

електронних закупівель.

Цей звіт є Документом 1. Він структурований відповідно до завдань і питань, перерахованих

вище. Звіт поєднує в собі аналіз запровадження системи в місті Києві та Національної системи

електронних закупівель і містить два основних розділи. Перший надає аналіз і висновки

стосовно бізнес-цілей та технічних вимог, виявлених в ході численних бесід з зацікавленими

сторонами та огляду різних документів. Другий розділ звіту зосереджений на технологічній

частині MVP системи, у тому числі конфігурації, функціональності і т.д. Цей розділ вказує на

прогалини і дає рекомендації щодо вдосконалення системи на основі потреб і пріоритетів

зацікавлених сторін та існуючих правових і технічних обмежень. Звіт закінчується розділом

"Висновки та наступні кроки", який пропонує етапи для подальшого вдосконалення системи

ProZorro і окреслює в загальних рисах підтримку, яку КМДА потребує для впровадження

системи.

Команда експертів, які проводили оцінку, складалася з двох фахівців з електронних

закупівель: Тато Урджмелашвілі (лідер групи) та Давида Марганії, за підтримки Юрія Громова

(IT фахівець). Протягом 15 днів польових робіт у Києві, команда провела близько 25

групових та індивідуальних інтерв'ю з зацікавленими сторонами, в тому числі з

представниками бізнесу, КМДА та іншими державними установами, які проводять закупівлі,

ініціаторами системи електронних закупівель та спонсорами, розробниками систем та

постачальниками інтерфейсів.


БІЗНЕС-ЦІЛІ ТА ТЕХНІЧНІ ВИМОГИ

Процес розвитку ProZorro

Розробка системи електронних закупівель в Україні, що пізніше отримала назву ProZorro,

мала за мету покращення ефективності та прозорості державних закупівель, зниження витрат,

залучення більшої кількості учасників, зменшення можливостей для корупції та забезпечення

дотримання міжнародних стандартів.

За даними Міністерства економічного розвитку і торгівлі (МЕРТ), Україна втратила близько

50 млрд. грн. (2,39 млрд. дол.), що склало 20 відсотків від загальної вартості закупівель в 2014

році через обмежену конкуренцію та корупцію застарілої та неефективної системи закупівель.

В 2014 році працювали 25 000 комісій із закупівель і було підписано більш 1,5 млн. контрактів

в 2014 році.1

Розробку системи ProZorro було розпочато в березні 2014 групою представників неурядового

сектору, яка включала українських та міжнародних експертів та компанії з розробки

програмного забезпечення та інтерфейсів. Систему було запроектовано відповідно до

міжнародних стандартів і кращих міжнародних практик і базуючись, зокрема, на системі, яку

було розроблено і запроваджено в Грузії, і яка визнана однією з найкращих у світі. В даний

час ProZorro включає наступні модулі:

Модуль реєстрації та оголошення електронних закупівель;

Модуль пояснень (питання і відповіді);

Модуль електронного подання тендерної пропозиції;

Модуль реверсивного аукціону;

Модуль визначення переможця та публікації угод;

Модуль аналітики (BI);

Електронні оплати для участі в аукціоні.

Ініціатива з розробки системи отримала підтримку Адміністрації Президента України2 та

МЕРТ. За їх підтримки з січня 2015 року проводиться пілотування системи ProZorro для

допорогових закупівель3 в ряді державних установ та муніципалітетах, та число державних

установ, що беруть участь у пілотуванні, зростає.

Станом на 16 травня 2015 року 21 державна установа, що бере участь в пілотуванні системи,

оголосила 356 закупівель на загальну суму 9 млн. дол. (194 млн. грн.), та підписала 120 угод.

1 Максим Нефьодов, заступник Міністра МЕРТ. Реформа системи державних закупівель в Україні. Виступ на засіданні Національної ради з реформи 15 травня 2015: http://reforms.in.ua/Content/download/Sessions/s6/7.1%2020150514_NRC_Public%20Procurement_Presentation_v9_A4_DR.PDFandhttp://reforms.in.ua/index.php?pageid=zasidannia-nazionalnoi-rady-6

2 http://gordonua.com/news/politics/Poroshenko-Vnedrenie-sistemy-elektronnyh-goszakupok-pozvolit-predotvratit-korrupciyu-73681.html

3 Допорогові закупівлі – це закупки товарів на суму до 100,000 грн. та послуг до 1 млн. грн. Існуюче законодавство обмежує використання електронних систем для закупівель, що не перевищують ці суми.

http://reforms.in.ua/Content/download/Sessions/s6/7.1%2020150514_NRC_Public%20Procurement_Presentation_v9_A4_DR.PDF

http://reforms.in.ua/index.php?pageid=zasidannia-nazionalnoi-rady-6

http://reforms.in.ua/index.php?pageid=zasidannia-nazionalnoi-rady-6

http://gordonua.com/news/politics/Poroshenko-Vnedrenie-sistemy-elektronnyh-goszakupok-pozvolit-predotvratit-korrupciyu-73681.html


Сума економії оцінюється приблизно в 1.8 млн. дол. (36 млн. грн.), або 7-12 відсотків від

запланованої ціни закупівлі.4

Інфографік нижче (розроблений МЕРТ) надає ключову інформацію про реформу:

4 Інтерв’ю з Дмитром Шимків, заступником голови Адміністрації Президента України: http://www.rbc.ua/ukr/news/sisteme-elektronnyh-zakupok-prisoedinilos-1431767748.html

http://www.rbc.ua/ukr/news/sisteme-elektronnyh-zakupok-prisoedinilos-1431767748.html

http://www.rbc.ua/ukr/news/sisteme-elektronnyh-zakupok-prisoedinilos-1431767748.html


Реформа системи закупівель, в якій ProZorro відіграє важливу роль, є головним пріоритетом, і

була включена в Стратегію України 2020. Ця стратегія визначає основні етапи реформи, в

тому числі обов'язкового переходу до ProZorro для всіх державних закупівель в 2016 році для

закупівлі нижче обов'язкових тендерних порогів, встановлених директивами ЄС (€ 134 000 для

закупівель товарів і послуг і € 5 186 000 для закупівель будівельних робіт), що в даний час

охоплює близько 90 відсотків закупівель в Україні. Ця таблиця показує етапи впровадження

системи та терміни і стан відповідно до Стратегії.5

ЕТАПИ РЕАЛІЗАЦІЇ РЕФОРМИ ЕЛЕКТРОННИХ ЗАКУПІВЕЛЬ

Етапи Терміни

1. Розробка загальної концепції реформи зроблено

2. Впровадження пілотного проекту на допорогових торгах (яке не потребує змін законодавства):

a. Розробка технічного завдання зроблено

b. Залучення електронних майданчиків зроблено

c. Розробка мінімально життєздатного продукту (MVP) зроблено

d. Пілотування системи деякими державними установами втілюється

e. Впровадження зручних засобів звітності та аналізу втілюється

f. Доопрацювання, коректування, виправлення системи

3. Масштабування електронної системи на всі порогові тендери в добровільному порядку

1/4/15–31/12/15

a. Рекомендаційний перехід закупівель на електронні закупівлі за простими групами товарів

b. Підготовка інфраструктури всіх державних закупівельників

c. Навчання закупівельників

4. Обов’язковий перехід всіх державних закупівель на електронну систему з 1/1/16

a. Внесення змін до чинного законодавства до 30/6/15

b. Доопрацювання засобів комунікації та захисту інформації до 30/6/15

c. Підготовка відповідної державної інфраструктури до 31/12/15

5. Приведення законодавства та процедур у відповідність до директив ЄС згідно з другим етапом

до 30/6/17

ProZorro та євроінтеграція

Принципи та основний функціонал ProZorro в цілому відповідають новим директивам ЄС

щодо електронних закупівель. Це знайшло своє відображення в проекті стратегії щодо

реформування системи державних закупівель, розробленої МЕРТ в рамках зобов'язань, що

випливають з Угоди про асоціацію між Україною та ЄС6, яка

свідчить, що система електронних закупівель повинна, як

мінімум, мати: електронні модулі річних планів закупівель,

електронні заяви і повідомлення, електронне подання заявок,

електронну оцінку, управління угодами та електронну оплату, електронні скарги, електронний

каталог і модуль рамкових угод. Всі ці модулі або вже є в ProZorro або передбачені і

сплановано, що вони будуть розроблені та реалізовані найближчим часом. Стратегія також

5 Реформа державних закупівель в Україні:http://www.reforms.in.ua/index.php?pageid=public-procurement-reform#plangraph 6 Угода про асоціацію між Україною та ЄС: http://eeas.europa.eu/ukraine/docs/association_agreement_ukraine_2014_en.pdf

Як ця ініціатива підтримує цілі європейської інтеграції для України?

http://www.reforms.in.ua/index.php?pageid=public-procurement-reform#plangraph

http://eeas.europa.eu/ukraine/docs/association_agreement_ukraine_2014_en.pdf

http://eeas.europa.eu/ukraine/docs/association_agreement_ukraine_2014_en.pdf


підкреслює, що електронна система повинна забезпечувати «відкритість, прозорість і

необмежений доступ до відповідних електронних послуг», які повністю відображені в

принципах і функціональності ProZorro. Ці принципи включають наступне:

1. Зниження і запобігання системної корупції шляхом забезпечення прозорості в

системі закупівель і видалення людського фактору в оцінці пропозицій.

2. Прозорість: забезпечення безперешкодного доступу громадськості до інформації

та документів, пов'язаних із здійсненням державних закупівель.

3. Запобігання дискримінації та забезпечення справедливості в оцінці тендерних

пропозицій шляхом видалення можливості суб'єктивного прийняття рішень в ході

процесу закупівель.

4. Простота і легкість у використанні процедур закупівель, які повинні сприяти

розширенню кола учасників закупівель.

5. Перехід до безпаперових закупівель, що дозволить збільшити ефективність і

знизити витрати.

6. Повна звітність і аналіз усіх державних закупівель.

ProZorro та законодавство України

Чинне законодавство накладає деякі обмеження щодо

використання електронних закупівель і, отже, вимагає

реформи, в тому числі наступне:

Закон про державні закупівлі 2014 залишив

відкритим питання електронних закупівель і зворотних реверсивних аукціонів. Чинне

законодавство дозволяє проводити електронні закупівлі лише для допорогових

закупівель. Перехідне положення закону передбачає розробку окремого закону про

електронні закупівлі, який не був створений. Без додаткового законодавства буде

неможливо розширити електронні тендери та реверсивні аукціони за межі допорогових

закупівель.

У професіоналів України є різні думки щодо законодавчої підтримки системи

електронних закупівель. Деякі вважають, що питання, пов'язані з електронними

тендерами, у тому числі питання про реверсивні аукціони, можуть бути врегульовані

постановою Кабінету Міністрів (Кабмін). Якщо реверсивний аукціон вважається

невід'ємною частиною електронних закупівель, а не окремою процедурою (як це

вважають рід фахівців в Україні), наказу Кабміну має бути достатньо; в іншому випадку,

реверсивний аукціон вимагає окремого закону.

Інша група експертів вважає, що проблема може бути вирішена шляхом прийняття

закону, що спеціально регулює електронні закупівлі, як цього вимагає Закон про

державні закупівлі 2014 року.

На підставі сказаного вище, існує два альтернативних варіанти законодавчих змін для

підтримки та розширення електронних закупівель:

Які основні законодавчі та політичні обмеження для остаточної автоматизації і безпаперового рішення для закупівлі в Києві / Україні?


1. Розробити та прийняти резолюцію Кабінету Міністрів, яка буде вирішувати

питання електронних тендерів, у тому числі реверсивного аукціону. У цьому

випадку, необхідно буде виключити перехідне положення із Закону про державні

закупівлі. Такий варіант вирішення проблеми дозволить уникнути надмірну

бюрократію навколо зміни законодавства і може бути реалізований відносно

швидко.

2. Другий варіант є більш складним як з формальної, законодавчої точки зору, так і з

технічної точки зору, так як закон про електронні закупівлі має бути прийнятий, як

це передбачено Законом про державні закупівлі, терміни якого вже пройшли.

Розробка самого закону не займе багато часу, але не ясно, як швидко він буде

розглянутий і прийнятий Радою України.

Чинне законодавство також встановлює обмеження на використання протоколу Secure

Sockets Layer (SSL) та зберігання публічних даних в хмарних системах зберігання даних,

таких як Amazon і Google, які вже давно визнані надійною і менш дорогою

альтернативою традиційним методам зберігання даних на фізичних носіях. Ці

обмеження лімітують здатність використовувати сучасні електронні рішення, які мають

вирішальне значення для функціонування і безпеки системи і підвищення її вартості.

Законодавча вимога обов'язкового використання електронного цифрового підпису

(ЕЦП) також може створювати обмеження для запровадження системи. Проблема

сумісності сертифікатів цифрового підпису, виданих різними постачальниками послуг,

не була вирішена ні на міжнародному, ні на державному рівнях. В результаті,

користувачі різних платформ ProZorro повинні були би використовувати кілька ЕЦП,

залежно від того, яку сервісну платформу вони використовують. Крім того, вимоги для

використання ЕЦП також створюють проблеми для іноземних учасників, для яких

ринок державних закупівель стає практично недоступним.

Таким чином, чинне українське законодавство не сприяє широкому використанню

електронних закупівель. В результаті, ProZorro було запущено тільки для допорогових

закупівель, які не підлягають цим правовим обмеженням, і організації-закупівельники мають

більше гнучкості у виборі підходу для проведення закупівель.

У той час як цей звіт був написаний, розробка проекту закону про електронні закупівлі була

ініційована реформістською командою Департаменту державних закупівель МЕРТ, на чолі з

Олександром Стародубцевим, який нещодавно приєднався до Міністерства.7 Одним з

головних завдань команди є підтримка та подальший розвиток ProZorro.

ProZorro та корупція

Дослідження показують, що державні закупівлі вкрай

корумповані. Більше 99 відсотків українських

7 http://delo.ua/ukraine/departament-goszakupok-vozglavil-sozdatel-sistemy-elektronnyh-t-292474/

Як ця ініціатива бореться з корупцією та зміцнює довіру до діяльності державного сектора?

http://h/


постачальників повідомили про «відкати» і корупцію у сфері закупівель.8

Можливості для маніпуляцій та суб'єктивності і громіздкість паперової системи є

найважливішими чинниками для виникнення корупції. ProZorro має принципово новий

підхід до питань відкритості та прозорості в процедурах та інформації, а також для оцінки

тендерних пропозицій. Фактори, які передбачені в концепції системи, що мають зменшити

можливості для корупції включають:9

Абсолютна прозорість. Будь-який документ та будь-яка інформація, пов'язана із

закупівлями, повинні бути відкриті і доступні онлайн для всіх зацікавлених сторін;

Прості, ясні і легкі у використанні методи закупівель;

Всі тендери без винятку електронні;

Інформація про всі закупівлі введена в єдину електронну систему;

Початкова ціна тендера доступна для всіх учасників, що знижує можливість маніпуляцій

та інфляції цін;

Документи з адміністративних органів (наприклад, свідоцтво про реєстрацію компанії,

сертифікат про відсутність заборгованості, довідка про будь-які процедури банкрутства)

зобов'язані бути надані успішними учасниками тільки перед підписанням контракту. Це

знизить бюрократичне навантаження на учасників торгів;

Використання реверсивного аукціону є обов'язковою частиною тендеру;

Порядок оцінки заявок починається з найнижчої ціни, потім відбувається оцінка

технічних пропозицій і кваліфікації при використанні підходу «так/ні»;

Будь-який зареєстрований користувач може запросити роз'яснення щодо тендерної

документації з використанням спеціального електронного модуля. Усі відповіді повинні

бути доступні для всіх учасників і бути невід'ємною частиною тендерної документації;

Будь-який зареєстрований користувач системи повинен мати можливість подати скаргу

під час або після закупівлі за допомогою спеціального електронного модуля

оскарження. Відповідь на скаргу є обов'язковою і відкритою для громадськості.

ProZorro та державно-приватне партнерство

ProZorro було розроблено групою ентузіастів на добровільній основі, заповнюючи вакуум,

що залишився через відсутність політичної волі уряду, щоб впоратися з проблемою

державних закупівель. Координатори з ініціативи

також залучили представників бізнесу, які на

добровільній основі розробили модулі системи згідно

з відповідними специфікаціями і протестували їх.

Компанії з розробки програмного забезпечення, такі

як ТзОВ «Група Квінта», UsabilityLab, RBCGroup and

SoftServe були залучені до розробки системи. Декілька компаній —Prom.Ua, e-Tender,

SmartTender— створили сервісні платформи у мережі для пілотування системи, та число

компаній, зацікавлених у приєднанні до ініціативи, зростає. З боку уряду, Адміністрація

8 http://biz.liga.net/ekonomika/all/stati/2962204-poborot-korruptsiyu-v-ukraine-legko-retsept-vedushchikh-ekonomistov.htm

9Тато Урджмелашвілі та Давид Марганія. Концепція розвитку та впровадження системи електронних закупівель в Україні, 2014–2015: https://drive.google.com/file/d/0BzAQEyry9Q-2RVRHaWxUdDFwNHB3ZGN6MDhOZVdjNkNNSG04/view?usp=sharing

Які можливості для державно-приватного партнерства в підтримку цієї ініціативи? Як технології та інші витрати мають бути розподілені між всіма зацікавленими сторонами?

http://biz.liga.net/ekonomika/all/stati/2962204-poborot-korruptsiyu-v-ukraine-legko-retsept-vedushchikh-ekonomistov.htm

https://drive.google.com/file/d/0BzAQEyry9Q-2RVRHaWxUdDFwNHB3ZGN6MDhOZVdjNkNNSG04/view?usp=sharing


Президента і МЕРТ підтримали систему, забезпечуючи участь державних установ у

пілотуванні системи. В даний час більше 20 урядових установ беруть участь в пілотіванні

системи, у тому числі Міністерство оборони10, Міністерство юстиції, Енергоатом,

Міністерство інфраструктури, Міністерство фінансів11, а також муніципалітети Києва та

Львова. Таким чином, процес створення системи, ініційований знизу, перетворився на

державно-приватне партнерство.

Концепція системи ProZorro передбачає подальший розвиток такого партнерства. Це

знайшло своє відображення в тому, що уряд підтримуватиме центральну базу даних (ЦБД) і

модуль реверсивного аукціону, в той час як приватний сектор буде розвивати і керувати

інтерфейсними модулями - сервісними платформами - на конкурсній основі та при

самофінансуванні.

ProZorro та малий і середній бізнес

Декілька факторів відлякують потенційних постачальників - саме малі та середні підприємства

(МСП) - від участі у державних та муніципальних

закупівлях. Серед таких факторів високий рівень

корупції традиційної паперової закупівлі, складність

процедур, великий обсяг документів і складна

система реєстрації та сертифікації. ProZorro має

усунути ці та інші проблеми і залучити більшу кількість малих і середніх підприємств до

участі в закупівлях. Серед таких факторів наступні:

Спрощення та скорочення витрат на підготовку конкурсної пропозиції завдяки

впровадженню принципу само-декларації. Відповідно до цього, документи, видані

адміністративними органами не будуть вимагатися від учасників тендерів на етапі подачі

заявки, а лише на етапі вибору переможця. Таким чином, на етапі подачі заявок

учасники повинні будуть тільки засвідчувати свою відповідність кваліфікаційним

вимогам. Це дозволить знизити адміністративне навантаження на бізнес, так як вони

будуть економити на витратах і часі, що в даний час витрачаються на отримання

великої кількості документів з різних державних органів.

Ліквідація географічної нерівності шляхом заміни паперових документів

електронною формою. З паперовою системою, іногородні учасники повинні здійснити

три або чотири поїздки в місце розташування закупівельної організації (одержання

тендерної документації, подання пропозиції, розкриття конвертів заявки і підписання

договору з переможцем). Це накладало серйозні фінансові і часові затрати і, таким

чином, ставило іногородніх учасників торгів у невигідне становище.

Проста реєстрація в системі, наявність тендерних документів в електронному вигляді

та можливість електронного подання заявок значно спростить участь у закупівлях для

всіх учасників.

10http://www.rbc.ua/rus/news/armiyu-budut-obespechivat-pomoshchyu-elektronnyh-1427971819.html

11http://minfin.com.ua/2015/05/08/7050073/

Чи всі зацікавлені сторони, задіяні в цій ініціативі, зокрема, малий та середній бізнес, прагнуть надавати товари і послуги в місті Києві?

http://www.rbc.ua/rus/news/armiyu-budut-obespechivat-pomoshchyu-elektronnyh-1427971819.html

http://minfin.com.ua/2015/05/08/7050073/


Необов’язкове використання цифрових підписів для реєстрації в системі і для

подання пропозиції, що не накладає жодних додаткових тягарів на учасників торгів.

Всього лише кілька місяців пілотування ProZorro показали збільшення конкуренції і

розширення діапазону претендентів, у тому числі малого та середнього бізнесу. Наприклад,

Міністерство оборони повідомило, що 80 відсотків постачальників, що беруть участь в

електронних закупівлях, були новими для Міністерства та 50 відсотків постачальників ніколи

не брали участь у державних закупівлях в минулому.

ProZorro, КМДА та інші державні установи з закупівель

Група по оцінці провела ряд зустрічей з КМДА щоб оцінити вимоги і потреби в

запровадженні системи електронних закупівель. Як уже згадувалося, КМДА була однією з

найбільших користувачів системи ProZorro, і адміністрація міста, в цілому, задоволена

досвідом. В результаті, КМДА планує заохочувати більше число своїх закупівельних

підрозділів використовувати систему з кінцевою метою залучення всіх своїх 1,672

закупівельних організацій до закупівлі через ProZorro. Загальна сума економії по очікуванням

в кінці року становитиме близько 200 млн. грн. (9,6 млн. дол.).

Інтерв'ю з керівництвом та фахівцями із закупівель КМДА і державних підприємств, які

входять до складу КМДА, а також аналіз системи показали, що основні технічні та бізнес-

вимоги КМДА для системи електронних закупівель багато в чому збігаються з існуючим

функціоналом ProZorro. Тим не менш, співробітники КМДА виклали інші вимоги і потреби,

які були або передбачені в системі або мають бути додані. Серед вимог такі:

Розробити BI модуль для управління процесом закупівель у розрізі підпорядкованих

департаментів та окремих закупівельних органзацій за результатами закупівель, а також

визначення середніх цін для певних категорій закупівель і цін за одиницю конкретних

товарів. Це покращить планування та знизить ціну закупівель.

Запровадити мульти-профілі користувачів закупівельних організацій (управління

користувачами). Це створить можливість відслідковування та адміністрування процесом

закупівель організаціями, підзвітними КМДА.

Гарантувати забезпечення тендерних пропозицій та правила для їх утримання у разі

відкликання учасником пропозиції та в інших випадках, передбачених законодавством

України.

Запровадити автоматичне виключення з системи постачальників, що не завантажили

документт при реєстрації заявки.

Забезпечити можливість відстежувати і повідомляти (по СМС або електронною

поштою) всі зацікавлені сторони про статус тендеру і будь-які зміни.

Стандартизувати тендерні документи і технічні описи товарів і послуг масового

споживання.

Розробити модль планування закупівель і бюджетування.

Розробити модуль електронних контрактів, у тому числі цифрового підпису для

укладення договору.


Розробити модуль подачі заявки на придбання в департаменти закупівель. Це, на думку

респондентів, сприятиме агрегації попиту.

Розробити модуль для подання та розгляду скарг в електронному вигляді.

Підвищити потенціал системи (масштабування та інтеграція з іншими системами).

Вимоги до системи, виражені КМДА, схожі на вимоги, запропоновані іншими користувачами

системи, хоча багато з них виходять за рамки системи електронних закупівель. Ці вимоги

включають в себе:

Зв’язати систему електронних закупівель з державними електронними системами для

бюджетного управління, планування і автоматизації бюджетного зобов'язання по оплаті,

і підключити її до реєстру компаній.

Додати класифікатор статей постачання системи каталогізації НАТО для потреб

закупівель товарів Міністерством оборони України.

Доопрацювати фільтри пошуку закупівельних установ, включаючи можливість

вказувати структурну приналежність до закупівельної організації (тобто, ієрархії).

Забезпечити функцію багатолотовості.

Запровадити систему мотивації чиновників, задіяних в проведенні закупівель, та

оптимізувати кількість задіяних чиновників.

Вирішити законодавчі обмеження на використання протоколу безпеки SSL, які

вимагають використання протоколів безпеки українських спецслужб.

Вирішити питання затримок з виплатами постачальникам (деякі з них іноді

перевищують рік).

Забезпечити рівноправність сторін у договорах - правила про відповідальність

постачальників за порушення договору, як правило, значно більш дискримінаційні, ніж

положення щодо закупівельних організацій.

Полегшити строгі формальні вимоги, які обмежують можливість корекції незначних

помилок, що часто використовується корумпованими чиновниками для маніпулювання

результатами тендеру.

Покращити аналітичну інформацію щодо ціни за одиницю.

Зменшити кількість документів, необхідних для участі в торгах (справки і виписки з

адміністративних органів), так як це значні фінансові і часові навантаження на учасників

торгів.

PROZORRO: АНАЛІЗ ПРОГАЛИНГ ТА ТЕХНІЧНИЙ АУДИТ

У цьому розділі наведені результати технічного аналізу MVP в ProZorro на

експериментальній основі в Україні. Рекомендації щодо змін і поліпшень відмічені знаком ☑

для зручності читача. Ці та інші рекомендації підсумовані в розділі "Висновки та наступні

кроки".


Технічна архітектура ProZorro

ProZorro розроблено відповідно до міжнародних стандартів обміну даними Open Contracting

Data Standards,12 які забезпечують можливість її аудиту та контролю. Система розроблена

відповідно до сервіс-орієнтованої архітектури (SOA) на основі методів взаємодії Передача

репрезентативного стану (REST). Це рішення забезпечує мультиплатформенний підхід, який

включає в себе два основні компоненти: ЦБД і кілька

сервісних платформ, які дозволяють користувачеві

взаємодіяти з ЦБД через інтерфейс прикладного

програмування (API). Взаємодія сервісних платформ з

ЦБД виконується з використанням формату обміну

даними, що базується на JavaScript (JSON). Діаграма

нижче (Малюнок 1) показує, що користувачі через

сервісні платформи підключаються до ЦБД, а в разі

проведення аукціону, сервісні платформи забезпечують

прямий доступ до модуля аукціону.

Qlik View використовується для бізнес-аналізу закупівель, або BI. Додаток дозволяє

виконувати аналіз закупівель у всіх доступних розділах: продукти та їх угруповання (групи,

класи і т.д.), тендери (відкриті, закінчені), організатори та учасники.

МАЛЮНОК 1. КОНФІГУРАЦІЯ PROZORRO

12Open Contracting Data Standards (Open Contracting 1.0RC):http://standard.open-contracting.org/

база даних

торги

платформи

Аналітика , моніторинг

Чи забезпечує національна система

електронних закупівель з

центральною базою даних тендерів

прозору та справедливу

конкуренцію, зниження ризиків

інформаційної безпеки та

конкуренцію серед постачальників,

що пропонують інтерфейси тендерів

бази даних ряду клієнтів в

державному секторі?

http://standard.open-contracting.org/


Технічні рішення та компоненти ProZorro зображені на Малюнку 2. Блоки, що виділені

блакитним, є структурними одиницями ProZorro, а саме:

OPAPI: REST сервер, що відповідає на запити HTTP, для роботи з базою даних, який

реалізований на Python.

OPDB: база даних рішення (документно-орієнтована система управління базами даних

CouchDB), містить метадані для доступу до бінарних файлів, інформації щодо тендерів.

DocumentStorageS3: Сервер зберігання для тендерної документації та бінарних файлів

(таких як PDF, XLS, і т.д.). Сервер, запропонований Amazon, який забезпечує високу

масштабованість, надійність, високу швидкість та недорогу інфраструктуру зберігання.

Auction: Модуль реверсивного аукціону, веб-аплікація модуля аукціону, що

централізовано в ЦБД забезпечує частину тендерного процесу – реверсивний аукціон.

BIDB: аналітика QlikView на даних ЦДБ.

МАЛЮНОК 2. АРХІТЕКТУРА PROZORRO

Однією з найважливіших функцій ЦБД є виконання реверсивного аукціону. Дані про

тендери та правила доступу забезпечуються API і логікою реверсивного аукціону. Сервісні

платформи забезпечують сервісом кінцевих споживачів. На додаток до послуг, які вони

зобов'язані надавати, сервісні платформи, на свій розсуд, можуть запропонувати й інші

база даних

Шар API Програмне забезпечення бізнес- логіка

веб -додатки

користувачі


послуги, наприклад, повідомлення про нові закупівлі, пошук закупівель або статистики по

закупівлям. API перевіряє дані, що надходять від сервісних платформ до ЦБД під час

реєстрації у тендері, реєстрації користувачів, тендерної пропозиції і т.д. Таким чином,

наявність декількох сервісних платформ і конкуренція серед них сприятиме розвитку системи

і поліпшить якість і кількість додаткових послуг для учасників торгів. У свою чергу, ЦБД

надає єдину точку доступу до всіх тендерів і консолідовану інформацію про поточні та минулі

закупівлі.

У той час як нинішнє технічне рішення ProZorro є достатнім для пілотного етапу, воно

вимагає подальших удосконалень і модифікацій, щоб бути в змозі вирішувати такі ризики:

Компонент системи

Опис ризику Ступінь ризику

ЦБД Якщо потужність ProZorro не збільшити, вона ризикує бути перевантаженою швидко зростаючим числом нових клієнтів, що використовують систему.

Високий

Цілісність і стійкість ProZorro може бути порушена, якщо сервісні платформи не зможуть запустити кілька версій ЦБД паралельно.

Середній

Архітектура Система може бути порушена, якщо будь-якій сервісній платформі не вдасться виконати належну авторизацію кінцевого користувача. В даний час, тільки справжність сервісних платформ перевіряється (авторизується) на рівні ЦБД, а кінцеві користувачі авторизуються лише платформами. В результаті, ЦБД не має інформації про особу кінцевих користувачів.

Високий

Стабільність системи і технічна стійкість уразливі, якщо заходи для зменшення впливу збою системи і забезпечення відновлення системи не будуть реалізовані. Ці заходи включають зміцнення основного і резервного віртуальних серверів на Amazon AWS, реалізацію розподіленого зберігання файлів у різних українських центрах обробки даних і т.д.

Високий

Зв’язок Система вразлива до помилок через відсутність автоматизованого інструменту тестування для запуску роботизованого комплексного тестування кожного компонента, підключеного до ProZorro.

Високий

ЦДБ/Архітектура Сертифікація системи, що необхідна для передачі ProZorro уряду є занадто зарегульованою, а вимоги до сертифікації є застарілими. Це підриває процесс предачі ProZorro в призначену державну установу.

Середній

ЦБД ProZorro може бути перевантажена, якщо функція архівування для автоматичного видалення документів з головної бази даних (з можливістю доступу до заархівованих даних за допомогою всіх інтерфейсів користувача) не буде розроблена.

Середній


Масштабування ProZorro

Масштабування системи можливе шляхом розширення архітектури, додаючи шар

балансування навантаження і сервера для роботи в паралельній системі в рамках

горизонтального масштабування. На малюнку 3 показана концептуальна архітектурна схема

рішення з цим доповненням.

МАЛЮНОК 3. КОНЦЕПТУАЛЬНА АРХІТЕКТУРА PROZORRO З БЛОКОМ МАСШТАБУВАННЯ

Таким чином, при збільшенні навантаження на API, сервери ЦБД і БД, паралельна

функціональність забезпечить стабільну та безперебійну роботу системи.

☑ ProZorro зараз завантажена на 20 відсотків від максимально допустимого

навантаження з поточним рішенням конфігурації. При підключенні нових

державних закупівельних установ, необхідно враховувати можливе збільшення

навантаження на ЦБД і масштабувати систему.

реплицируемой Бази даних

Шар API Програмне забезпечення бізнес- логіка

балансування навантаження

веб -додатки

користувачі


Безпечність

Безпека забезпечується шифруванням SSL і API сервісами під час доступу до документів та

відомостей через авторизовані сервісні платформи. Всі доступи до інформації та активності

записуються. Бібліотека API та документація знаходяться у вільному доступі за посиланням:

http://openprocurement.org. Дані про тендери для аудиту, аналітики чи інших потреб

доступні будь-кому з відкритих API сервісів. Таким чином, відповідно до концепції розвитку

ProZorro і рішень, що використовуються MVP, в системі забезпечується наступне:

Безпечне збереження даних;

Міри безпеки для забезпечення конфіденційності подачі тендерних пропозицій;

Моніторинг системи;

Повідомлення і політика безпеки у випадку відмови від обслуговування (DOS) атак чи

подібних цілеспрямованих спроб, спрямованих проти цілісності системи, безпеки і т.д.

☑ Повинно бути розроблено така документація і функціональність:

Резервне копіювання системи та керівництва;

План аварійного відновлення;

Правила обслуговування і гранично допустимих періодів бездіяльності;

Угода про рівень обслуговування (SLA).

Адміністрування сервісних платформ, перевірка даних

В даний час, API з ProZorro перевіряє дані, що виходять з авторизованих сервісних

платформ в ЦБД. Це обмежується інформацією, наданою учасниками в ЦБД через сервісні

платформи і вимагає здійснення інтегрованої системи управління даними. Інтегрований

контроль даних може бути реалізований через розвиток автоматизованого інструменту

тестування для тестування сервісних платформ, які будуть стежити за поточним станом

кожної платформи на поточному чи запланованому функціоналі. Автоматизоване тестування

також може бути використане для аудиту існуючих платформ. Аудит повинен передбачати

мінімальну функціональність системи і, наприклад, введення та перевірку інформації та

послуг, що надаються платформами, таких як:

Номенклатурні довідкові дані Загального словника закупівель (CPV) та Українського

державного класифікатору товарів і послуг (ДКПП), які будуть використовуватися в

повідомленні про закупівлі (і класифікатору НАТО для потреб Міністерства оборони);

Надання платформами повної процедури тендерів для закупівельних установ і для

постачальників до підписання контракту, звернення або анулювання закупівель;

Надання платформами прозорості всіх етапів тендеру та конфіденційності під час

реверсивного аукціону;

Інформування зацікавлених постачальників про будь-які зміни в конкурсній

документації, включаючи скасування закупівель;

Інтеграційне тестування всіх сервісних платформ.

http://openprocurement.org/


Окрім контролю послуг, що надаються платформами для учасників торгів, адміністрація

платформ включає в себе набір дій для підключення нових платформ до ЦБД і проведення

інтеграційного тестування в рамках акредитації платформ. Три платформи вже з'єднані з

системою і ще три проходять випробування. Перевірка функціональності нової платформи і

підключення її до системи відбуваються вручну. Це трудомісткий процес, який займає від двох

до трьох місяців на одну платформу.

☑ Розробка стенда для тестування платформ та уніфікація вимог до платформ

дозволять скоротити функціональну перевірку платформ до трьох тижнів.

Електронний цифровий підпис

Використання електронного цифрового підпису (ЕЦП) не потрібно ні для входу в ProZorro,

ні для подання тендерної пропозиції. Проблема сумісності цифрових сертифікатів підпису,

виданих різними сервіс провайдерами, не була вирішена на міжнародному або місцевому

рівні. Отже, користувачі повинні біли би використовувати кілька ЕЦП, залежно від

платформи, з якою вони працюють. Використання ЕЦП в значній мірі створює проблеми

для іноземних учасників, для яких ринок державних закупівель стає практично недоступним.

Ця проблема залишається невирішеною в багатьох країнах, у тому числі в ЄС.13 Таким чином,

використання ЕЦП не є обов'язковим в рамках відповідної директиви ЄС.14

Аналітика ЦБД

QlikView використовується для аналізу даних закупівель. Додаток використовує дані з ЦБД, в

тому числі: закупівельна установа, каталоги, дані про тендери, кількість тендерів, кількість груп

продукції в одиницях, пропозиції учасників торгів, переможці і дані за договорами. Додаток

дозволяє виконувати аналіз за будь-який обраний період часу в будь-якій комбінації (товарів,

тендерів, торгів і т.д.).

Закупівельні агентства мають атрибути юридичної адреси і адреси доставки, які вказують на їх

географічне положення. Постачальники також мають дані про місце розташування, які

можуть бути використані для візуалізації даних звітності.

☑ Необхідно змінити контроль даних з платформ на стороні ЦБД для правильного

надання даних про місце розташування постачальників і клієнтів.

Система забезпечує детальний аналіз і агрегування показників для окремих вимірів.

☑ Варто додати аналітику по середнім показникам закупівель, будь-яке відхилення від

цих цифр може мати корумповану природу або, навпаки, позитивну динаміку,

залежно від умов тендеру конкретного закупівельного агентства, і т.д.

13 Електронний підпис як перешкода на шляху до електронної торгівлі у Європі без кордонів: Уроки, вивчені з проекту PROCURE, Institut für Informationsmanagement Bremen GmbH (ifib), 2009: https://www.eid-stork.eu/dmdocuments/public/ElectronicSignaturesAsObstaclesForCross-BorderEProcurementInEurope_LessonsFromThePROCUREProject.pdf

14 Директива про електронні підписи: 1999/93/ЄC: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:31999L0093

https://www.eid-stork.eu/dmdocuments/public/ElectronicSignaturesAsObstaclesForCross-BorderEProcurementInEurope_LessonsFromThePROCUREProject.pdf

https://www.eid-stork.eu/dmdocuments/public/ElectronicSignaturesAsObstaclesForCross-BorderEProcurementInEurope_LessonsFromThePROCUREProject.pdf

http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:31999L0093

http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:31999L0093


В даний час всі дані ЦБД можуть бути використані для аналітики, хоча зростання числа

тендерів може призвести до перевантаження ЦБД.

☑ Перевантаження можна буде уникнути шляхом впровадження архівного сервера,

який дозволить зменшити навантаження на систему в майбутньому. Збереження

даних лише про поточні і нові тендери на ЦБД вивільнить ресурси для роботи

бази даних. Таким чином, архівні дані будуть розподілені між зовнішніми

організаціями для перевірки або статистики закупівель, і процес не буде

навантажувати ресурси ЦБД.

Прозорість системи

Поряд з ЦБД всім користувачам системи та іншим зацікавленим особам повинен бути

доступний веб-ресурс для розміщення публічної інформації. В даний час це ресурс

http://prozorro.org, який публікує остаточні результати аукціонів, надає посилання до

платформ, розміщує прес-релізи та блоги, що інформують громадськість, і надає інструмент

для дискусії про статус і прогрес системи і закупівлі. Цей ресурс може бути також

використаний для забезпечення прозорості та відкритості системи, зокрема, публікації в

чорний список постачальників, заяв про тендери і рішень по них (дивіться опис далі).

Реверсивний аукціон

ProZorro призначена для забезпечення функціонування централізованого реверсивного

аукціону як для закупівельних установ, так і для постачальників. Реверсивний аукціон ділиться

на етапи:

Ініціація закупівлі;

Реєстрація пропозицій для закупівлі;

Реверсивний аукціон;

Кваліфікація переможця;

Завершення закупівлі.

Програмне забезпечення реалізує розподіл доступу до даних в залежності від ролі

користувача в системі. ЦБД зберігає інформацію про минулі, поточні та відстрочені закупівлі,

а також забезпечує бізнес процес реверсивного аукціону.

☑ Для систематизації та стандартизації інформації треба розробити стандартну форму

для технічних та кваліфікаційних вимог до постачальників при оголошенні

тендера. Ця форма спростить формулювання основних вимог і усуне дублювання,

які часто зустрічаються за відсутності стандартних форм. Стандартні форми будуть

корисними при проведенні аудиту та аналізу інформації про закупівлі. Консолідація

даних технічних та кваліфікаційних вимог також допоможе закупівельним

установам розробити вимоги до тендеру для майбутніх подібних тендерів, що

поліпшить розробку планів закупівель і может вести до зменшення початкової

вартості закупівлі, використовуючи середні ціни завершених закупівель. Крім того,

http://prozorro.org/


стандартні форми можуть бути використані для двоступеневого аукціону і рамкової

закупівлі, описаної нижче.

☑ ProZorro забезпечує реверсивний аукціон лише для допорогових закупівель.

Подальший розвиток сервісу має також включати логічну і технічну реалізацію

двоступеневого аукціону і рамкових закупівель.

Відмінності між двоступеневими і одноступінчатими тендерами в тому, що протягом

двохступеневого тендеру пропозиції постачальників оцінюються не тільки за ціною, але і за

якістю запропонованих послуг. На першому етапі технічна пропозиція постачальника

оцінюється за технічними вимогами, встановленими тендерною документацією, і критеріями

необхідної якості. Другим кроком є реверсивний аукціон, щоб знизити ціни пропозицій.

Переможець визначається системою автоматично, на основі ціни і якості. Таким чином,

двоступеневий тендер дозволяє включити якість в оцінку тендерних пропозицій на товари та

послуги на додаток до вартості.

Рамкова закупівля використовується для визначення базових умов для закупівлі товарів і

послуг масового споживання, таких як офісний папір, канцтовари, комп'ютери та офісне

обладнання, і т.д. В рамках тендерів буде обрано одного або декілька переможців, і

закупівельні організації можуть укладати контракти з ними протягом терміну дії рамкової

угоди.

☑ Двоступеневий тендер та рамкова закупівля значно розширять сферу застосування

системи в галузі державних закупівель.

Виконання угод, інтеграція з зовнішніми системами

Впровадження системи в сервісно-орієнтованій архітектурі (SOA), полегшує його інтеграцію

із зовнішніми системами, завдяки реалізації процесно-орієнтованого підходу, який пов'язаний

з певними процесами і функціями в якості складової частини, а не з об'єктами програмного

забезпечення. Таким чином, правильне застосування процесів і оптимізації можуть значно

спростити процедуру закупівель для всіх зацікавлених сторін з моменту оголошення про

закупівлі до підписання контракту і його здійснення.

Одним з важливих аспектів електронних закупівель є контракт на закупівлю і його виконання.

В даний час система вимагає завантаження відсканованої копії договору, і, отже, не забезпечує

інформацію в доступному форматі для подальшого аналізу, аудиту або використання в інших

системах.

☑ Ця проблема може бути вирішена шляхом розробки електронної форми договору

для заповнення. Інформація про постачальника і закупівельну організацію є в

системі. Об'єкт закупівлі і специфікація також можуть бути представлені в

стандартній формі замовником при реєстрації на участь у тендері. Таким чином,

шляхом визначення шаблону договору і шаблону для специфікації закупівлі, можна

впровадити електронний контракт в цифровій формі. Такий договір може бути

завірений ЕЦП сторін або, на початковому етапі, може бути сформований для

підпису на папері, а потім завантажений у систему. Подальше удосконалення


функції дозволу електронного підпису не є складним. Дані контракту згодом

можуть бути використані для створення функцій оплат у казну.

Подальша інтеграція електронних закупівель для всієї системи електронного уряду включає в

себе щонайменше здатність обміну даними з такими сервісами, як:

Електронна державна скарбниця;

Реєстр компаній;

Реєстр фізичних та юридичних осіб.

Інформація про контракти (зобов'язання, контракти, рахунки, акти приймання, звіт про

виконання договору, рахунки-фактури тощо) повинна бути відкрита для громадськості.

Функціональний модуль «План закупівель»

Модуль плану закупівель передбачений системою, але не розроблений. За наявності цього

модуля закупівельна установа повинна завантажити свій план закупівлі в систему. Модуль

"План закупівель" повинен забезпечити формат для підготовки та публікації плану закупівель,

який буде містити основну інформацію про закупівлю, таку, як: ціна, засоби та CPV або

ДКПП код. Тендер може бути оголошений тільки якщо він включений в план закупівлі і

зареєстрований в системі. Плани закупівлі повинні бути доступні для всіх зацікавлених

користувачів або гостей сервісних платформ для перегляду та скачування в зручних форматах

(наприклад, Excel і CSV).

Гарантія (Гарантування вкладів)

Концепція системи передбачає необхідність гарантійного забезпечення або захисту тендера

для встановлення серйозності намірів постачальника і мінімальний фінансовий захист для

участі в тендері. Гарантія повинна бути надана до подання тендерної пропозиції. Гарантія

повинна бути повернута постачальнику наприкінці торгів у разі скасування тендера або його

завершення з негативними результатами, або підписання контракту. Гарантія може бути не

повернена учаснику тандера, якщо він відмовився від своєї тендерної пропозиції, був

дискваліфікований за підсумками тендеру або відмовився підписати договір.

☑ У разі електронної гарантії, такі процедури і обмеження повинні бути розглянуті:

Система повинна запитати і підтвердити згоду з правилами використання та

повернення гарантії;

Бенефіціаром гарантії, повинні бути уповноважений орган або сервісна

платформа;

Розмір гарантії повинен бути чітко встановлений відповідним нормативним актом і

зазначений в оголошенні тендеру закупівельним агентством;

Правила повинні бути докладно описані для учасників торгів.


Функціональний модуль «Оскарження»

Початкові технічні вимоги для розвитку ProZorro були доповнені розділом про

функціональний модуль «Оскарження». Цей модуль призначений для того, щоб дозволити

учасникам торгів подавати скарги при оголошенні тендера на оскарження тендерних

документів, а також на стадії кваліфікації для оскарження результатів тендеру. На відміну від

модуля запитань та роз'яснень, ця функція повинна дозволити їм впливати на процес

закупівель, а саме, пересувати дати процедури закупівель на час скарги, або навіть скасувати

тендер за результатами оскарження.

☑ Процес оскарження повинен відповідати таким принципам:

Оскарження тендеру може проводитися будь-яким користувачем, зареєстрованим у

системі, до прийняття остаточного рішення про тендер.

Оскарження може бути ініційоване, якщо користувач вважає, що права учасників

торгів були порушені або процедури закупівель не відповідають закону і

встановленим правилам.

Система повинна розмістити скаргу на загальнодоступному веб-сайті.

Якщо скарга подана відповідно до правил, вона вважається прийнятою з моменту

подачі у систему.

У разі активної скарги по тендеру система не повинна дозволяти підписати

контракт з переможцем до вирішення скарги.

Технічні вимоги передбачають необхідність створення Апеляційної ради, яка буде займатися

скаргами учасників торгів. Вони дають опис процесу подачі, реєстрації та обробки скарг в

системі.

☑ Обробка скарг повинна задовольняти ряд принципів, серед яких такі:

Вирішення суперечок та прийняття рішень здійснюється Апеляційною радою у

строки, встановлені законом, і повинно бути зазначено у договорі користувача

системи.

Якщо звернення вимагає уточнення наданої інформації, заявник отримує

повідомлення від Апеляційної ради із зазначенням терміну, відведеного для

уточнення. Якщо необхідна інформація не надається у строк, Апеляційна рада

може визнати скаргу неприйнятною. Якщо інформація надається у відведений

період, період вирішення скарги починається з повідомлення про прийняття

переглянутої скарги.

Апеляційна рада уповноважена задовольнити скаргу повністю або частково, або

відхилити скаргу з обґрунтуванням.

Рішення Апеляційної ради є відкритим та розміщується в системі і на

загальнодоступному веб-сайті.

Цей модуль повинен значно спростити процес вирішення суперечок і скарг, забезпечити

прозорість та збільшити участь у державних закупівлях.


Чорний список

☑ Для контролю за здійсненням угод про використання системи і права на участь у

державних закупівлях, функція повинна бути реалізована на рівні ЦБД, що б

дозволило системі не приймати в процесі тендера учасників, які порушили правила

процесу закупівель. Це так званий "чорний список" недобросовісних

постачальників. Правила і процедури включення постачальників в цей список

мають бути визначені нормативними актами уповноваженого органу або Законом

України і розкриватися в угоді користувача. Цей список повинен бути публічним і

доступним для всіх.

Функціональний модуль «Пошук»

Пошук в системі реалізується сервісними платформами, і ProZorro повинна забезпечувати

мінімальну функціональність пошуку, що має бути виконана при мінімальному наборі

фільтрів:

Номер закупівлі (ID);

Закупівельник (пошук з третього символу назви);

Постачальник (пошук з третього символу назви);

Статус закупівлі;

Коди класифікаторів (пошук з третього символу назви);

Дата статусу (коли була оголошена, коли відбудеться аукціон і т.д.);

Оголошена ціна закупівлі (від/до);

Ціна контракту (від/до);

Географічне положення закупівельних організацій;

Дочірнє підприємство закупівельника.

Сервісні платформи повинні реалізувати можливість збереження результатів пошуку в Excel

або CSV.

Для досягнення прозорості в процесі закупівель і своєчасного інформування всіх зацікавлених

сторін, сервісні платформи повинні інформувати учасників торгів про стадії і зміни тендеру

або тендерної документації. Крім того, щоб підвищити конкуренцію і залучити нових

постачальників, сайти повинні забезпечити підписку на нові тендери для постачальників за

критеріями, які відповідають мінімальному набору для пошуку і відносяться до тендеру або

закупівельної організації.

РИЗИКИ У ВПРОВАДЖЕННІ PROZORRO

Політичні та фінансові:

Невирішені питання фінансування системи. - Орієнтовна вартість підтримки

функціонування системи, відповідно до МЕРТ, становить 10 млн. грн. на рік (478 000


дол).15 Автори цього звіту не знають про параметри цієї оцінки і, отже, не в змозі надати

будь-які коментарі. Тим не менш, у даний час питання фінансування системи не

вирішені.

Не визначено державний орган, який набуде право власності на систему. В даний

час, система юридично належить некомерційній організації Transparency International

(TI), якій розробники перпедали всі свої майнові та авторські права на умовах, що ТІ в

майбутньому передасть систему уряду безкоштовно.

Законодавче регулювання. Чинне законодавство обмежує розширення використання

електронних закупівель, забороняє використання протоколу SSL і зберігання даних в

публічних хмарних сховищах, які використовуються в ProZorro, і вимагає використання

ЕЦП, що не передбачений в системі. В даний час в уряді і серед фахівців немає згоди

по необхідним законодавчим змінам, що перешкоджає прийняттю законодавства,

необхідного для розвитку і розширення електронної системи закупівель.

Технічні:

Швидко зростаючий рівень завантаження системи. В даний час, система

завантажена на 20 відсотків від максимально допустимого навантаження з поточною

конфігурацією системи технічних рішень, а також забезпечує 130 тендерів на день. По

мірі приєднання нових закупівельних установ навантаження на ЦБД буде зростати.

Наприклад, тільки КМДА планує вимагати від усіх своїх 1 642 закупівельних організацій

приєднатися до системи. ProZorro повинна бути готова прийняти велику кількість

нових учасників за рахунок збільшення пропускної спроможності системи. Це вимагає

масштабування системи.

Швидка передача ProZorro уповноваженому державному органу, який не

підготовлений для її прийняття та обслуговування.

Невирішені питання безпеки і стабільності системи, а саме: те, що відбувається з

учасниками торгів, зареєстрованими на сервісній платформі, яка не може бути

доступною протягом деякого часу за певних технічних причин.

Кваліфікаційні:

Недостатня кваліфікація закупівельних організацій. Масова міграція закупівельних

агентств в ProZorro без належної підготовки потребує створення умов для тренування

закупівельних організацій, у тому числі КМДА.

Недостатня кількість навченого персоналу. Нестача кваліфікованих, добре навчених

і добре оплачуваних фахівців із закупівель і на центральному, і на місцевому рівнях

створює вакуум в зростаючій необхідності підготовки для закупівельних і учасників

торгів.

15 Максим Нефьодов, заступник Міністра Міністерства економічного розвитку і торгівлі, та Олександр Стародубцев, Голова департаменту державних закупівель МЕРТ, «Прогрес реформи державних закупівель і долучення інших міністерств до пілотного проекту електронних закупівель», 13 травня 2015: https://youtu.be/FgXBK3eiftw

https://youtu.be/FgXBK3eiftw


Інші:

Створення державної платформи може стоворити ймовірність того, що така

платформа буде працювати проти принципів здорової конкуренції, що викладені в

діючій моделі мульти-платформенної системи.

Затримка оплати або неплатіж за договорами державних закупівель може

дискредитувати систему.

Можливе переміщення корупційних схем з тендерних процедур на реалізацію та

оплату за договорами.

Неправильна інтерпретація цінової інформації правоохоронними та

контролюючими органами. Ціни, встановлені в ході дослідження ринку можуть бути

значно знижені в ході аукціону, і це може викликати підозру правоохоронних органів,

що ціна була навмисно завищена. Таким чином, необхідно поліпшити методологію

дослідження ринку та забезпечити навчання організаторів закупівель, а також

працівників правоохоронних і регулюючих органів.

ВИСНОВКИ ТА НАСТУПНІ КРОКИ

Аналіз ProZorro показав наступне:

Система в цілому відповідає стандартам і вимогам ЄС і враховує передові міжнародні

практики.

Чинне законодавство обмежує можливість широкого використання електронних

закупівель, і, отже, вони доступні тільки для допорогових закупівель. В даний час

відбувається широке обговорення в країні підходів до законодавчих змін, але немає

спільного бачення. Законодавчі обмеження також відносяться до використання

технологій та електронних цифрових підписів.

Система в значній мірі задовольняє потреби користувачів - і закупівельників, і

постачальників. Концептуальна модель і технічне рішення забезпечують необхідний

набір модулів для повної реалізації процесу закупівель. Тим не менш, система повинна

бути доповнена іншими модулями або розширена до кращого задоволення потреб

користувачів, у тому числі модулем планування, модулем аналітики, модулем

оскарження, реалізацією багатолотової закупівлі і т.д. Перелік пріоритетних заходів,

необхідних для розвитку системи, наведений в таблиці нижче.

Досить швидкий перехід значної кількості державних і муніципальних установ на

систему вимагає негайного здійснення можливостей масштабування системи.

Технічне рішення використовує інноваційні підходи, щоб забезпечити оптимальну і

стабільну роботу системи, забезпечуючи необхідний рівень безпеки. Використання

відкритого коду розширює функціональність системи і спрощує контроль та аудит.

Використання мульти-платформного підходу, за яким єдина центральна база даних

адмініструється державним органом, а кілька сервісних платформ надаються


приватними компаніями, забезпечує (1) економічну ефективність, (2) якість послуг через

конкурентоспроможність сервісних платформ і (3) державно-приватне партнерство.

Пілотування системи показало позитивні результати в плані підвищення ефективності

закупівлі, зниження витрат та економії коштів.

Пілотування системи в 14 відділах КМДА проходить успішно і відповідає основним

вимогам і потребам Адміністрації. В даний час, подальше використання і розширення

системи на інші департаменти та установи є кращим рішенням для КМДА в реалізації

електронних закупівель, у тому числі з точки зору економії витрат. Таким чином, немає

необхідності для КМДА створювати свою власну систему або власну сервісну

платформу.

Список першочергових вимог для подальшого розвитку системи ProZorro

ПРІОРИТЕТНІ ВИМОГИ ДЛЯ ПОДАЛЬШОГО РОЗВИТКУ СИСТЕМИ PROZORRO

№ Функція Опис

Пріоритет 1

1. Модуль оскарження

Процес незалежної обробки скарг для підвищення довіри до системи зі сторони учасників торгів

2.

Інструмент автоматизованого тестування

Сервер автоматичного тестування буде керувати роботизованим комплексним тестуванням кожної системи, підключеної до ProZorro, щоб зменшити кількість помилок у системі

3. Вхід у систему

Вхід на сервер для реєстрації змін у процесі закупівель, включаючи розміщення закупівлі і яких-небудь модифікацій, час подачі заявки, будь-яких змін, IP-адреси і т.д. Зберігання такої інформації на окремому сервері істотно знизить ризики маніпуляцій чи шахрайства

4. Стабільність системи

Технічні питання стійкості - реалізація основних і резервних віртуальних серверів на Amazon AWS, реалізації розподіленого зберігання файлів на різних українських центрах обробки даних і т.д. знизять наслідки катастроф і дозволять легше відновити дані у разі їх виникнення

5. Оплата (біллінг)

Звіти оплат покажуть виставлення рахунків-фактур і фінансові операції

6.

Надання змоги платформам запускати декілька версій ЦБД

Паралельні версії - здатність платформ електронних закупівель використовувати різні версії центральної бази даних паралельно. Це полегшить управління версіями програмного забезпечення

7. Бізнес-аналітика (BI)

Модуль дозволить проведення аналізу даних ЦБД про тендери, учасників торгів, торги, переможців і дискваліфікованих учасників; дозволить експорт даних у відкритих форматах; сприятиме створюванню аналітичних звітів за конкретними параметрами тендеру і візуалізуванню деяких аналітичних даних у вигляді діаграм

8.

Масштабування, резервне копіювання, розподіл навантаження

Імплементація основних і резервних віртуальних серверів на Amazon AWS, реалізація розподіленого зберігання файлів у різних українських центрах обробки даних і т.д. знизить наслідки катастроф і дозволить легше відновити дані


ПРІОРИТЕТНІ ВИМОГИ ДЛЯ ПОДАЛЬШОГО РОЗВИТКУ СИСТЕМИ PROZORRO

№ Функція Опис

Пріоритет 2

9. Система архівації

Архівація - автоматичне видалення документів з основної бази даних в архів з можливістю доступу до архівних даних через всі інтерфейси користувачів

10. Модуль планування

Модуль планування дозволяє розмістити річні плани закупівель від кожної закупівельної організації, що дозволить пошук за допомогою різних параметрів. Ця функція допоможе постачальникам зрозуміти місткість ринку і планувати свої операції

11.

Інтерфейси для візуалізації головної кваліфікації та технічних вимог

Можливість встановити кваліфікаційні критерії, як поля в документі, не тільки як частину документа у форматі PDF. Це дозволить сформулювати технічні вимоги до постачальників, такі як досвід, оборот, кваліфікація, освіта, фінансове становище і т.д., використовуючи веб-форму. Ця функція дозволить проводити більш складну аналітику, що сприятиме безперервному поліпшенню бізнес-логіки процесу

12. Багатолотові тендери

Багатолотові закупівлі дозволяють поділ однієї закупки на різні партії, які можуть мати різні характеристики (наприклад, різні точки поставки) і можуть мати різних переможців. Крім того, ця функція повинна мати вбудовані обмеження для покупців, що запобігають або виявляють шахрайство зі штучним і непотрібним розподілом однієї закупки на різні лоти

13.

Модуль для двоступеневих торгів з урахіванням якісних оцінок пропозицій

Двоступеневі тендери представлять якісні показники для оцінки пропозицій і впливатимуть на розрахунок кінцевої ціни торгів. Ця функція необхідна для більш складних закупівель, коли переможець не може бути визначений лише на основі ціни (наприклад, професійні послуги, будівельні роботи і т.д.)

14.

Модуль управління контрактом впродовж всього строку

Відстеження контракту буде реєструвати стан його реалізації, доставки товарів / послуг та платежів постачальникам

15.

Інтегрована система захисту даних (IDPS)

Інформаційна безпека особливо необхідна перед передачею ProZorro до урядової організації

16.

Звітний модуль для реалізованих процедур (прямі контракти)

Завдяки цьому модулю, закупівельні організації будуть завантажувати інформацію в систему за видами закупівлі (наприклад, за прямими контрактами), що раніше не було доступно онлайн. Цей модуль буде забезпечувати цілісність даних державних закупівель.

17.

Модуль для рамкових угод

Модуль для рамкових угод буде використовуватися закупівельними організаціями для виконання рамкових тендерів і підписання угоди з одним або кількома постачальниками за умов, що регулюються контрактами, які можуть бути нагороджені в ході всього терміну дії договору (як правило 2 + 1 + 1 роки). Рамкова угода не є контрактом; договір складається тільки тоді, коли замовлення розміщується окремою закупівельною організацією.

* Система може мати й інші модулі, як описано, наприклад, Пошук, Гарантування вкладів і Чорний список, серед інших. ** Числові значення, призначені для кожної функції, засновані на класифікації, а не за рівнем важливості.


Допомога КМДА

Однією з цілей цього аналізу було визначити, чи слід КМДА використовувати ProZorro, або

у КМДА є необхідність розробити незалежну систему електронних закупівель. Досвід

використання ProZorro з моменту запуску пілотного проекту показав позитивні результати, в

тому числі його використання КМДА. Як результат, на засіданні Ради по боротьбі з

корупцією КМДА 19 травня 2015, мер офіційно оголосив про рішення використовувати

ProZorro у всіх підрозділах закупівлі КМДА для всіх допорогових закупівель. Автори цього

звіту повністю підтримують рішення КМДА використовувати ProZorro та погоджуються, що

Адміністрація не має необхідності створювати окрему систему або власну платформу.

Тим не менш, перехід всіх (більше 1600), підрозділів з закупівель КМДА до ProZorro повинен

бути узгоджений з координаторами пілотного проекту ProZorro, щоб не викликати проблем,

пов'язаних з технічними обмеженнями існуючої інфраструктури системи.

Крім того, для успішного впровадження і використання електронних закупівель в КМДА

необхідно наступне:

Навчання: Фахівці із закупівель КМДА повинні пройти навчання, перш ніж перейти на

ProZorro. Компетентність фахівців із закупівель буде відігравати значну роль в успішній

реалізації реформи; і технічна допомога в розробці та реалізації навчальних програм

стає все більш важливою. Навчальні програми будуть необхідні для існуючого

персоналу і для нових співробітників у майбутньому. Ці програми також будуть корисні

і для інших міст та державних установ, які приєднаються до ProZorro.

Внутрішні правила: Переглянути внутрішню політику та процедури КМДА для їх

кращої адаптації до електронних закупівель та розробити і впровадити відповідні

внутрішні правила і стандартні операційні процедури.

Керівництва та форми: Розробити і впровадити керівництва і форми стандартизації

процесів закупівель.

Бізнес-аналітика: Розробити зміст систематичних звітів для аналізу та моніторингу

закупівель і підготувати відповідний персонал КМДА.

КМДА потребує технічної та консультативної допомоги у виконанні цих завдань.

Масштабування ProZorro

Тільки два муніципалітети - Київ та Львів - разом з

державними установами беруть участь у пілотуванні

ProZorro. Досвід цих двох міст буде мати неоціненне

значення для поширення системи в інших містах

України. Слід враховувати, що рівень готовності у різних містах до використання системи

буде нерівномірним як із технологічної точки зору, так і з точки зору підготовки фахівців із

закупівель, а також в готовності потенційних постачальників. Також можливий опір

адміністративних органів має бути прийнятий до уваги, оскільки це часто відбувається у

відповідь на інновації.

Як ця спроба може бути поширена в інших містах і регіонах України? Які основні можливості?


Для успішного використання ProZorro в інших містах, на основі досвіду Києва, необхідно

буде забезпечити наступне:

Визначити параметри технологічної готовності муніципалітету для переходу в систему.

Зокрема, наявність необхідного комп'ютерного обладнання та програмного

забезпечення, внутрішньої мережі та її технічного обслуговування. Особливе значення

має якість Інтернет-з'єднання.

Розробити програму підготовки кадрів на всіх рівнях, в тому числі управління,

персоналу, який бере участь у процесі закупівель, і технічного персоналу.

Підготувати інструкторів та тренерів для проведення навчання відповідно до

розробленої програми та надавати консультації на робочому місці. Тренери та

інструктори можуть бути як від КМДА, так і незалежними експертами.

Підготувати керівництво та нормативні документи, які будуть використовуватися при

переході на електронну систему закупівель.


ДОДАТОК 1. СПИСОК ПРОВЕДЕНИХ ЗУСТРІЧЕЙ

ЗУСТРІЧІ, ПРОВЕДЕНІ У 2015

# ДАТА ЧАС ІМ’Я ЗВ’ЯЗОК

1 20 квітня 09:00 Тімоті Дубель, Тамара Паливода

АМР США, Радник з електронного управління АМР США, Представник Відповідального за Контракти, Менеджер проектів

2 20 квітня 15:00

Вільям Шрайбер Київське інвестиційне агентство

Юрій Назаров Київське інвестиційне агентство, Заступник директора

Алена Василецька Київське інвестиційне агентство

3 21 квітня 13:00 Алена Василецька Київське інвестиційне агентство

В’ячеслав Новохацький Київське інвестиційне агентство

4 22 квітня 11:00 Олександр Стародубцев МЕРТ, Голова департаменту закупівель

5 22 квітня 15:00 Мирослав Опир ТзОВ «Група Квінта», Генеральний директор

6 23 квітня 9:30 Марія Горностай Адміністрація Президента України, Радник

7 23 квітня 16:30 Віктор Нестиля TI-Ukraine, Старший аналітик

8 24 квітня 9:30 В’ячеслав Биковець Спілка підприємців малих, середніх та приватизованих підприємств України, Генеральний директор

9 27 квітня 15:00 Оксана Продан Бізнес асоціація Фортеця, Голова

10 27 квітня 17:30 Володимир Михайленко ТОВ «Український папір», Директор

11 28 квітня 13:00 Олександр Стародубцев МЕРТ, Голова департаменту закупівель

12 28 квітня 16:00 Олександр Новохацький e-Tender platform, Старший розробник

13 29 квітня 9:30 Ігор Ніконов КМДА, Перший заступник голови

14 29 квітня 11:00 Олег Щербатенко Smart Tender, Генеральний директор

15 30 квітня 10:00 Олександр Махно Енергоатом, Заступник директора

16 30 квітня 12:30 Володимир Гриченко Державна Адміністрація, Старший консультант з державних закупівель

17 30 квітня 14:30 Артур Переверзев Міністерство оборони, Менеджер проектів та координатор закупівель

18 30 квітня 17:00 Самвел Акобян NetCast, Генеральний директор


ЗУСТРІЧІ, ПРОВЕДЕНІ У 2015

# ДАТА ЧАС ІМ’Я ЗВ’ЯЗОК

19 5 травня 11:00 Мирослав Опир, Юрій Громов

20 13 травня 12:00

Микола Палієнко, Андрій Хлякін, основний розробник Prom.Ua, Микола Жандоров, Директор B2B/B2G Procurement

Prom.ua

21 14 травня 15:00 Олена Степанова та інші Американська торгова палата

22 15 травня 11:00 Анна Ястребова та Сергій Савченко

PublicBid, IT- Contract

23 15 травня 15:00 Юрій Назаров та інші Київське інвестиційне агентство, Заступник директора

msi ukraine eprocurement deliverable 1_final_uk - submit

Documents