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

Розробка тендерного майданчика: де ламається логіка торгів

Розробка тендерного майданчика — це насамперед робота з конкурентним станом, а не з формами та особистими кабінетами.

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

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

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

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

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

Третя зона — обхід правил допуску. Учасник без акредитації, з простроченою кваліфікацією або в конфлікті інтересів не повинен фізично дійти до кроку подання пропозиції.

Перевірки, розмазані по інтерфейсу, обходяться прямим викликом методу; перевірки, зібрані в одному шарі правил перед записом ставки, — ні. Окремо проєктуємо аудит: хто, коли і на якій підставі був допущений або відхилений.

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

Що дає керована торгова платформа

Швидкість торгів і закриття лоту

Площадка утримує лот в одному стані: ставка, підтвердження, протокол — без ручного перенесення між таблицями та поштою. Крок ставки та правило продовження задаються політикою, тому торги відбуваються передбачувано, а не залежать від того, хто з операторів чергує.

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

Стійкість і частка успішних угод

Відмовостійкість будується навколо ідемпотентності операцій: повторна ставка не створює дубль, обрив зв'язку не втрачає поданої пропозиції. Реплікація бази та черга подій дають відновлення без втрати протоколів — клас відмов «заявка пішла, але не збереглася» зникає повністю.

Частка угод, що доходять до підписання, зростає, бо учасник бачить статус і історію своїх дій, а організатор — повну картину по лоту.

Прозорість і розбір спірних ситуацій

Кожна дія фіксується незмінним журналом: хто, коли, з якої адреси та що змінив. Це знімає більшість спорів після торгів — історію можна підняти за конкретним лотом, а не відновлювати за листуванням.

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

Що це дає напряму

Тендерна площадка розробка під ключ окупається не «гарним кабінетом», а керованістю: менше ручних операцій, передбачувані строки раунду, відновлюваний аудит.

Ми проєктуємо так, щоб навантаження зростало без переписування ядра, а нові типи процедур додавалися налаштуванням, а не доопрацюванням під кожного замовника.

Способи реалізації тендерного ядра

Ядро торгів — це правила допуску, крок ставки, антиснайпер, протоколи та зв'язка з ЕТП-шлюзами. Саме тут підхід до реалізації визначає, що можна доопрацювати, а що доведеться обходити. Нижче — три реальні варіанти, між якими обирають на старті.

Де ламається готове рішення

Типова платформа закриває стандартний аукціон, але щойно з'являється пониження з кроком від стартової, кваліфікаційний відбір або двоетапний допуск — починаються обхідні сценарії. Частина логіки переїжджає в ручні операції, і протокол перестає бути відтворюваним.

Що дає замовне ядро

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

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

Як ми ведемо проєкт: від аудиту до передачі

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

Поки ці правила не формалізовані, будь-яка схема даних вийде довільною і її доведеться переробляти. Тому перший етап — розбір документів замовника і чинних процедур разом із вашою командою.

1. Аудит регламенту. Розбираємо процедури, ролі учасників, строки та підстави для відмови. На виході — узгоджена модель процесів, від якої далі рахуються всі правила.
2. Схема даних. Проєктуємо лоти, заявки, ставки, документи та історію змін. Закладаємо незмінний журнал дій: по будь-якому лоту видно, хто і коли що змінив.
3. Налаштування правил. Реалізуємо допуск учасників, кроки процедури, автоматичне визначення переможця та повідомлення. Правила виносяться в конфігурацію — зміна регламенту не потребує переписування логіки.
4. Навантажувальна перевірка. Відтворюємо пік подання заявок в останні хвилини: перевіряємо, що майданчик тримає одночасний наплив і не втрачає заявки. Окремо дивимося сценарій, коли кілька учасників подають ставку в одну секунду.
5. Перевірка відмовостійкості. Відпрацьовуємо перезапуск вузлів і відновлення з резервних копій, заміряємо час повернення в роботу.
6. Передача системи. Розгортаємо на вашій інфраструктурі, віддаємо документацію, регламент супроводу та доступи. Навчаємо адміністраторів майданчика.
7. Супровід. Після запуску ведемо моніторинг, розбираємо інциденти та доопрацьовуємо процедури під зміни регламенту.

Кожен етап закінчується артефактом, який можна перевірити: узгоджена схема, налаштовані правила, протокол навантажувальної перевірки, інструкції для адміністраторів. Ви бачите стан проєкту на будь-якій стадії, а не лише на прийманні.

Правила допуску, ролі та журнал дій

Ролі та допуск описуються декларативно: замовник веде довідник організацій, для кожної задає статус (замовник, постачальник, організатор процедури), набір дозволених дій та область видимості — які закупівлі та документи учасник бачить.

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

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

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

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

Журнал дій — append-only: кожен запис містить автора, час, об'єкт і результат, попередні записи не редагуються і не видаляються. Хешування ланцюжка записів показує, якщо дані намагалися змінити в обхід системи, — це і є основа аудиту торгів. Вивантаження журналу за процедурою займає секунди і приймається контролюючими органами як доказ.

Такий контур закриває типові вимоги Федерального закону № 223-ФЗ і внутрішніх регламентів замовника: розмежування доступу, простежуваність рішень і захист від підміни даних після завершення торгів.

Що замовник отримує після запуску

Запуск — це не «сайт віддали й попрощалися».

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

• Конфігурації середовищ — описи стендів, параметрів підключення до реєстрів і зовнішніх сервісів, налаштувань ролей і прав. Розгортання нового середовища перестає бути ручною роботою «за пам'яттю».
• Схеми системи — архітектурна карта: компоненти, потоки даних між особистим кабінетом, заявковою частиною та сховищем документів, точки інтеграцій. За нею видно, що впаде при відмові вузла і що потрібно підняти першим.
• Регламенти супроводу — порядок оновлень, вікна робіт, правила резервного копіювання та відновлення, дії при інциденті. Черговий розуміє, що робити, до того як щось зламалося.
• Інструкції для учасників — покрокові керівництва з реєстрації, акредитації, подання та відкликання заявки, роботи з електронним підписом. Знижують потік звернень до підтримки на старті торгів.
• Інструкції для служби підтримки — сценарії розбору типових ситуацій: не проходить заявка, не підвантажується документ, завис статус процедури. З готовими відповідями та межею, де підключається інженер.
• Модель ролей і матриця доступів — хто зі співробітників що бачить і змінює: організатор, оператор, модератор, спостерігач. Доступ відкликається при виході людини, а не залишається «про всяк випадок».
• Перелік інтеграцій і зовнішніх залежностей — з якими системами пов'язаний майданчик, хто відповідає за кожну сторону, що робити при недоступності суміжного сервісу.
• Журнал передачі та план розвитку — що увійшло в поточну версію, які доопрацювання узгоджені наступними, які обмеження відомі. Замовник бачить межу зробленого і не чекає чудес від того, що не замовляв.

Такий комплект знімає головний ризик супроводу — залежність від однієї людини, яка «все пам'ятає». Опишіть задачу — повернемося з оцінкою та планом, включно зі складом документації на передачі.

Чим відрізняється закритий тендер від відкритого?

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

Закритий тендер, навпаки, передбачає попередній відбір: організатор формує пул допущених постачальників, і тільки вони бачать умови та можуть подати пропозицію. З точки зору платформи це два різних контури доступу, а не одна форма з галочкою «приватність».

Різниця проявляється в моделі даних. У відкритому режимі картка лота публічна, ставки видно в реальному часі, а навантаження на читання кратно вище за запис — сюди приходять пошукові роботи, аналітика та зовнішні агрегатори.

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

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

Режими доступу визначають і життєвий цикл торгів. Відкрита процедура допускає продовження, роз'яснення та публічні уточнення — усе це фіксується в незмінному журналі.

Закрита вимагає окремого контуру запрошень, підтвердження участі та часто — угоди про конфіденційність до розкриття документації.

Звідси різні вимоги до аудиту: у закритому режимі важливо довести, хто і коли отримав доступ, у відкритому — що опубліковані умови не змінювалися заднім числом.

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

Кейс: площадка для закупівель з 40 000 лотів на рік

Замовник прийшов з працюючою тендерною площадкою на Сбербанк-АСТ-сумісному форматі обміну: лоти публікувалися, але в дні великих закупівель система не витримувала одночасної подачі заявок.

Пікове навантаження припадало на останні 30 хвилин перед закриттям прийому — учасники масово надсилали документи, черга зростала, частина заявок відхилялася за таймаутом, а спірні ситуації розбиралися вручну за логами кілька днів.

Що змінили

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

Винесли перевірку підписів і валідацію пакетів документів в окремий контур, щоб важкі операції не блокували прийом. Налаштували автомасштабування під профіль навантаження: за 10 хвилин до закриття лота піднімаються додаткові обробники заявок, після — згортаються.

Метрики до і після

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

Швидкість розбору спірних ситуацій зросла не за рахунок людей, а за рахунок того, що дані перестали збирати по частинах з різних логів.

Через півроку після запуску площадка стабільно приймає 40 000 лотів на рік, а пікові дні перестали бути аварійними — команда замовника чергує за графіком, а не за фактом падіння.

Обговоримо ваше завдання і повернемося з планом

Щоб повернутися з оцінкою та планом робіт, а не із загальними словами, нам потрібен від вас мінімум контексту: які процедури проводить майданчик (конкурс, аукціон, запит пропозицій), хто учасники та замовники, як зараз приймаються заявки і де зберігаються документи.

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

Далі ми фіксуємо межі першої версії та ризики: інтеграції із зовнішніми системами, вимоги до підпису та юридичної значущості, навантаження в пікові вікна подання заявок.

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

• Розбір ваших процедур і ролей: хто подає заявки, хто допускає, хто підбиває підсумки.
• Схему даних: лоти, заявки, документи, протоколи, історія змін.
• План робіт за етапами з порядком і залежностями.
• Оцінку строків і складу команди під кожен етап.
• Перелік інтеграцій і зовнішніх сервісів, які знадобляться.
• Варіанти запуску: повний обсяг або поетапне введення модулів.
• Список ризиків і рішень, які їх закривають.
• Формат підтримки після запуску і регламент доопрацювань.

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