Чекліст RFP для вибору постачальника ПЗ у B2B

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

Що має містити RFP щодо програмного забезпечення?

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

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

Варто також розрізняти три документи, які часто плутають. RFI запитує ринок, що вже існує; він короткий, передує формуванню вимог і нікого ні до чого не зобов'язує. RFP запитує пропозицію на основі визначених вимог і заявленої методики оцінювання. RFQ запитує ціну за визначений обсяг робіт. Проведення RFQ до визначення обсягу є найпоширенішим способом порівняти три цифри, які насправді означають три різні речі.

П'ять речей, які робить повний RFP, але не робить неповний:

• Визначає проблему, а не рішення. «Скоротити час підготовки щомісячного консолідованого звіту з кількох днів до визначеної кількості годин» — це формулювання проблеми; «побудувати нам сховище даних» — припущення про рішення, яке може її не вирішити.


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


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


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


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

Структура RFP

Функціональні та нефункціональні вимоги

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

У більшості B2B-проєктів варто чітко вказати:

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


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


• Відновлення. RTO і RPO простими словами: як швидко відновлюються операції після інциденту та скільки роботи може бути втрачено. Обидва показники мають входити до оцінювання, а не з'являтися лише в договорі.


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


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


• Інтеграція та дані. Які системи з'єднуються, у якому напрямку рухаються дані та хто відповідає за головний запис кожної сутності.

Питання щодо безпеки та відповідності

Про безпеку краще питати через запитання з обов'язковими доказами, а не через рядок із відповіддю «так/ні». Варто включити такі питання:

• ISO/IEC 27001 — чи має постачальник цей сертифікат і що охоплює сертифікована сфера? Сертифікат, що охоплює відділ продажів, але не команди постачання, повідомляє вам цілком конкретну інформацію.


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


• OWASP Top 10 — чи входить цей перелік до перевірки постачальника для компонентів, доступних через веб; це конкретне запитання, на яке можна відповісти.


• Контроль доступу — хто може отримати доступ до ваших середовищ і даних, як доступ надається та відкликається, яке журналювання ведеться.


• Обов'язки щодо захисту даних — KVKK і GDPR, якщо вони застосовуються; хто є контролером, хто обробником, що угода про обробку даних визначає щодо субобробників і повідомлення про порушення.

Комерційні умови та SLA

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

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

Матриця оцінювання пропозицій

Шаблон, який можна скопіювати. Наведені нижче ваги є прикладом: встановіть власні відповідно до пріоритетів і збережіть загальну суму на рівні 100. Визначте, що означають 1, 3 і 5, до початку оцінювання, а не після перших суперечок.

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

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

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

Перевірка референсів і пілот

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

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

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

Пункти договору для перевірки

• Передача прав ІВ — права на код, документацію та похідні матеріали переходять до вас із моменту створення, а не лише після остаточного платежу.
• Власність на дані — ваші дані залишаються вашими; права постачальника обмежені тим, що необхідно для надання послуг.
• Приймання — що означає приймання, хто його оголошує та якою є процедура, якщо результат йому не відповідає.
• Контроль змін — як зміни обсягу запитуються, оцінюються та затверджуються; без цього кожна зміна стає суперечкою.
• Вихід і перехід — вихідний код, доступ, документація та допомога після завершення; як передається знання, якщо постачальник змінюється.
• Ескроу — якщо безперервність бізнесу залежить від компонентів, які зберігає постачальник, що відбудеться, якщо він не зможе продовжувати роботу.
• Відповідальність — ліміти, винятки та те, що не застраховано; читайте цей пункт із такою самою увагою, як і ціну.
• Розірвання — строки повідомлення, обов'язки після розірвання та процес повернення або видалення даних.

Поширені запитання

Чи слід спочатку надсилати RFI чи RFP?

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

Скількох постачальників слід запросити?

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

Як встановлювати ваги?

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

Чи слід оцінювати ціну?

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

Як оцінювати відповіді щодо безпеки?

За доказами, а не за тоном. Достатньо трьох рівнів: позицію не визначено (1), політики описано (3), сферу сертифіката перевірено, безпечну розробку описано й докази надано (5). Якщо постачальник не має сертифіката, попросіть письмово описати еквівалентні засоби контролю. Чесне «ні» з документованими засобами контролю має отримати вищий бал, ніж «так», яке неможливо перевірити.

Чи можна змінювати вимоги після RFP?

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

Джерела та стандарти

• ISO — видавець ISO/IEC 27001 (управління інформаційною безпекою); перед тим як покладатися на сертифікат, перевірте чинну редакцію та сферу сертифікації.
• OWASP — видавець переліку 10 основних ризиків безпеки вебзастосунків, згаданого на цій сторінці.
• Принципи матриці оцінювання відповідають опублікованій практиці шаблонів RFP; наведені ваги є прикладом для редагування, а не рекомендацією. Ця сторінка містить рекомендації щодо закупівель, а не юридичну консультацію, і для WorldwideTradeX не заявляється жодна сертифікація чи аудит.

Пов'язані сторінки

Розробка програмного забезпечення · ІТ-аутсорсинг із Туреччини · Моделі витрат і ціноутворення · ІТ-аудит і консалтинг · Запросити цінову пропозицію