Коли виникає потреба в діалозі
Замовник може розуміти бажаний результат, але ще не мати достатньої основи для остаточного опису технічного або іншого рішення. Конкурентний діалог є спеціальним механізмом, у якому передбачена взаємодія з кандидатами для опрацювання визначених питань і наступного відбору. Можливість його застосування, умови та етапи встановлюються законом. Самої складності предмета недостатньо, щоб довільно обрати назву процедури.
Перед початком перевірте застосовні норми, категорію замовника й перехідні правила. Ця сторінка пояснює логіку роботи з потребою, а конкретну послідовність процесуальних дій потрібно визначати за належною редакцією акта.
Чим це відрізняється від консультації
Попередня ринкова консультація допомагає зібрати відомості до закупівлі. Конкурентний діалог є визначеним закупівельним процесом із правилами участі, документування та переходу між етапами. Приватна розмова з одним продавцем не перетворюється на конкурентний діалог лише тому, що обговорюється складний товар. Важлива не назва зустрічі, а правова основа і встановлений порядок.
Розмежуйте інформацію для розуміння ринку та інформацію, що впливає на допуск або оцінювання в процедурі. Для кожної дії має бути зрозуміло, хто бере участь, які питання дозволені та як її результат буде використано далі.
Як описати бажаний результат
Почніть із проблеми користувача, масштабу, умов експлуатації та критеріїв успішного результату. Не підміняйте опис потреби назвою продукту, який випадково відомий команді. Водночас не залишайте завдання настільки загальним, що неможливо порівняти різні підходи. Укажіть наявні системи, межі бюджету, вимоги до сумісності й обмеження, якщо їх можна та потрібно розкрити.
Корисно поділити відомості на підтверджені умови та відкриті питання. До першої групи належить, наприклад, кількість користувачів; до другої — спосіб організації переходу між системами, якщо він ще потребує опрацювання.
Як готувати питання кандидатам
Сформулюйте однакову основу питань про функції, впровадження, ризики, витрати та підтримку. Попросіть пояснювати припущення, від яких залежить рішення. Коли кандидат пропонує інший підхід, з’ясуйте, яку потребу він покриває та які нові зобов’язання виникають у замовника. Не оцінюйте складність лише за кількістю функцій у презентації.
Для організації команди визначте фахівців із предмета, фінансів, права та експлуатації. Їхня участь має допомагати розуміти відповіді, а не створювати суперечливі неофіційні обіцянки різним кандидатам щодо майбутнього результату відбору.
Приклад інформаційної системи
У навчальній ситуації установа хоче об’єднати звернення з кількох каналів і контролювати строки їх обробки. Один підхід передбачає розширення наявної системи, інший — нову платформу з перенесенням даних. Для порівняння команда досліджує повноту міграції, права доступу, навчання працівників, роботу під час переходу та витрати на підтримку після запуску.
Виявляється, що дешевша початкова ліцензія не охоплює перенесення архіву. Цей факт не визначає переможця, але показує, яке питання потрібно належно врахувати в майбутніх умовах. Приклад вигаданий і не є підтвердженням допустимості певної процедури для конкретного замовника.
Як берегти рівність інформації
Записуйте поставлені питання та отримані відповіді у спосіб, передбачений правилами. Перевіряйте, яка інформація може бути доведена до інших кандидатів, а яка потребує захисту. Не використовуйте конфіденційну розробку одного учасника як безумовно доступне всім технічне рішення. Порядок обміну й допустиме використання матеріалів потрібно встановлювати до того, як вони вплинуть на документацію.
Якщо загальна умова змінюється після опрацювання питання, забезпечте належне доведення цієї зміни до відповідного кола осіб. Інакше учасники можуть готувати пропозиції на різних вихідних припущеннях, що робить порівняння ненадійним.
Перехід до остаточної пропозиції
Перед наступним етапом перевірте, які параметри вже визначені та які документи повинен подати учасник. Зведіть результати діалогу у погоджену основу вимог, дотримуючись застосовної процедури. Усі суттєві питання, що впливають на ціну та обсяг, мають бути зрозумілими у належних документах. Усне розуміння окремої робочої групи не забезпечує однакового трактування сторонами.
Постачальнику варто повторно оцінити свої витрати після остаточного уточнення умов. Комерційна оцінка, зроблена до діалогу, може стосуватися іншої комплектації, іншого графіка або іншого розподілу відповідальності за впровадження.
Робочий журнал рішень
Для кожного відкритого питання заведіть запис із проблемою, розглянутими підходами, доказами та погодженим результатом. Додайте посилання на матеріал, відповідального й дату. У журналі пояснюйте, чому певний параметр з’явився в остаточних вимогах. Це дає команді можливість відтворити логіку рішення без припущення, що всі пам’ятають зміст попередніх зустрічей.
Після завершення перевірте, чи співвідноситься результат закупівлі з початковою потребою. Велика кількість обговорень не є показником якості сама по собі. Важливо, чи усунуто невизначеність, чи можна об’єктивно перевірити виконання та чи зрозумілі майбутні витрати замовника.
Перевірка готовності вимог
Попросіть команду відповісти, як вона перевірятиме результат на прийманні. Якщо опис обмежується словами про зручність або високу якість, додайте вимірювані характеристики та сценарії роботи. Наприклад, для системи звернень важливо відтворити рух конкретного звернення від надходження до закриття, а також перевірити права різних користувачів. Таке завдання має бути узгоджене з потребою і допустимими умовами закупівлі. Перевірний результат допомагає завершити діалог із придатною основою для наступного етапу та не переносити ключову невизначеність у договір.
Джерела для подальшої перевірки
- Закон № 922-VIII: нормативне джерело для перевірки застосовної редакції
- Закон № 4888-IX: перевірте чинність і введення в дію конкретних положень
- Prozorro Infobox: навчання та практичні пояснення
Практичні рекомендації потрібно зіставляти з умовами конкретної закупівлі. Перед застосуванням правових вимог перевіряйте чинну редакцію першоджерела.
