Чек-лист RFP для B2B-вендоров: выбор софта

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

Что должен содержать RFP на разработку ПО?

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

Есть также пункт последовательности, экономящий месяцы: RFP — не место, где вы узнаете, что вам нужно. Требования выходят из внутренней работы: владельцы процессов описывают, как бизнес на самом деле работает, финансы говорят, что должно сходиться, а люди, которые будут ежедневно пользоваться системой, называют, где сейчас боль. Эта работа медленная и политическая, и она происходит до того, как вовлекается любой вендор. Команды, отдающие ее первому пришедшему вендору, получают требования, написанные на языке продукта этого вендора, и после этого любое другое предложение выглядит неудачным, — не потому что оно неудачное, потому что бенчмарк написан вокруг одного из претендентов.

Еще одно различие, которое стоит держать, между тремя документами, которые часто путают. RFI спрашивает рынок, что существует; он короткий, предшествует требованиям и никого не обязывает. RFP просит представить предложения против зафиксированных требований и заявленного метода оценки. RFQ просит цену против зафиксированного круга вопросов. Ранний RFP вместо круга вопросов RFI — это то, что превращает последующие требования из вашей задачи в задачу каждой отдельной заявки, на их словах, с их приоритетами.

Еще пять вещей, которые делают RFP выполнимым, а не декларацией:

• Описывает проблему, а не решение. «Сократить время закрытия месячного отчета с дней до согласованных часов» — это формулировка проблемы; «нам нужен склад данных» — предположенное решение, которое невозможно оценить.


• Разделяет требования и приоритеты. Блокирующее (должно быть), необходимое (приоритизировано) и приятное (не решает сделку). Приоритет — это разница между предложением, которое можно оценить, и списком, который все оценят по-своему.


• Называет ограничения. Системы, которые нужно интегрировать, данные, которые нужно перенести, обязательства по хранению, что уже установлено, кто подписывает. Этих ограничений нет в списке — и вендор отвечает в вакууме.


• Заявляет метод оценки заранее. Критерии, веса, кто оценивает, какие доказательства требуются и когда вы запустите стартовый список падения от поставщиков, не набравших порог. Это то, что отличает оценку от дискуссии после факта.


• Ставит даты процесса. Дедлайн вопросов, дедлайн подачи, окно оценки, дата решения. Процесс без дат приглашает искренних поставщиков позже, чем худшие претенденты.

Структура RFP

Рабочая структура и типичные ошибки по разделам:

Функциональные требования к ERP и функционально-нестандартные

Функциональные требования описывают, что система делает: какие процессы, для каких ролей, с каким исходом. Функционально-нестандартные описывают, насколько хорошо она это делает, и именно они чаще всего недописаны, потому что их дорого добавлять позже и их просто нелегко формулировать.

Что обычно имеет значение в большинстве B2B-проектов:

• Скорость. Время ответа на ключевых операциях — оформление заказа, отчет, закрытие месяца — под согласованным объемом; это согласованный диапазон, а не обещание.


• Доступность. Какой аптайм нужен бизнесу, окно обслуживания и что происходит, когда система недоступна; формулировка «целевой аптайм» без окна и порядка — не требование, а пожелание.


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


• Аудиторский след. Кто что и когда менял, как долго хранится, кто может найти; особенно там, где движутся деньги, запасы или персональные данные.


• Доступность и удобство. Кто, на каких устройствах и на каких языках работает системой; система, которой невозможно пользоваться на телефоне со склада, не внедрена, как бы хорошо она ни баллировалась.


• Интеграция и данные. Какие системы соединяются, в каком направлении идет данные и кто единственный владелец источника по каждой сущности.

Безопасность и вопросы комплаенса

Безопасность формулируется вопросами, требующими доказательств, а не строкой «обязан соответствовать»:

• ISO/IEC 27001 — есть ли у вендора и какую область покрывает сертификат? Сертификат, покрывающий офис продаж, а не команду поставки, — конкретный ответ, и его стоит спросить именно в таком виде.


• Защищенный жизненный цикл разработки — где безопасность стоит в дизайне, ревью кода и тестировании; как обрабатываются зависимости и уязвимости.


• OWASP Top 10 — входит ли это в их проверку веб-компонентов; конкретный вопрос с ответом вместо расплывчатого «безопасно ли это?».


• Контроль доступа — кто может добраться до ваших репозиториев, окружений и данных; как доступ выдается, журналируется и отзывается при уходе человека.


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

Коммерческие условия и SLA

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

SLA требуют такой же точности, как и требования: процент аптайма важен вместе с определением, исключениями и тем, что происходит при нарушении; время ответа важно вместе с определением срочности и рабочими часами. Когда вендор называет цифры, попросите определения прямо в SLA — именно там они и должны жить.

Балльная матрица оценки

Рабочий шаблон. Веса ниже — иллюстрация; поставьте свои, исходя из своих приоритетов, и удерживайте сумму 100. Определите, что означают 1, 3 и 5 баллов, до того, как кто-либо баллирует, а не после начала споров:

Три дисциплины делают матрицу рабочей. Баллируйте до обсуждения, чтобы первый уверенный голос в комнате не решил; записывайте одно обоснование на каждый балл, чтобы победитель мог объяснить свой результат, а ваша команда — защитить его через шесть месяцев; и не заполняйте матрицу в одиночку, потому что матрица, которую заполняли торопясь, становится боем мнений, а матрица с обоснованиями становится дорожной картой, по которой идут.

Есть и третья дисциплина — кто баллирует. В команде должны быть люди, которые будут жить с результатом, — владелец процесса, человек, ответственный за данные, представитель безопасности или финансов, — а не только отдел закупок. Когда баллируют те, кто не живет с результатом, оценка отмечает убедительность презентации, а не работу, и это проявляется спустя квартал. Баллирующий, у которого есть право говорить «нет» до встречи, баллирует иначе, чем тот, кому это право не дано. И полезно помнить, что та же матрица баллирует и вещи, которые вы не просили: сильный тон презентации, размер логотипа, знакомство с вашей отраслью — все это попадает в подсознательные баллы, если явных нет.

Показать балльную матрицу вендорам до подачи — нормальная практика; показать ее после — это спор без основания. Публиковать веса тоже: если безопасность взвешена на 5%, а цена на 30%, это заметят и серьезные вендоры, для которых безопасность важна, и те, кто ее игнорирует. Более широкая рамка оценки вендоров и страница ИТ-аутсорсинга из Турции показывают, как эти баллы соединяются с выбором модели и пилота.

Референсы и пилот

Кейс-статьи — это маркетинг; проверка референсов — это доказательство. В звонке больше всего говорят не предложенные вопросы, а то, что вы заметите сами: отвечает ли бывший клиент вовремя, говорит ли он о проекте так, как вы бы хотели, чтобы говорили о вашем.

Задайте:

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


• Что вы бы сделали иначе. Этот вопрос почти всегда выдает реальное отношение к работе.


• Кто на самом деле делал работу. Та же команда, что была в презентации, или подрядчики; об этом редко врут, но редко и спрашивают.


• Как обходятся изменения в объеме. Кто инициирует, как оценивается, сколько это стоит на практике.


• Что происходит, когда что-то ломается. Скорость реакции, кто поднимается по эскалации, что чувствуется на своей стороне.


• Продлили бы вы. И если нет, почему.

И затем пилот. Короткая платная работа на реальных требованиях — ровно тот инструмент, который отличает выбор по наблюдению от выбора по презентации. Ограничьте его, определите, что такое «готово», заранее, и договоритесь о правиле решения до начала: что означает продолжение, что — пересмотр, что — стоп. Вендор, отказывающийся от пилота по принципиальным соображениям, дает вам информацию о том, каким будет сотрудничество.

Пункты договора, которые стоит проверить

Большинство из них согласуются в обычной форме; важнее то, чтобы они были:

• Уступка IP. Код, документация и производные переходят вам с момента создания, а не при финальном платеже.


• Право на данные. Данные остаются вашими; права вендора ограничены тем, что нужно для поставки.


• Приемка. Что означает «принято», кто объявляет и что происходит, когда что-то не проходит.


• Процедура изменений. Как изменения инициируются, оцениваются и утверждаются; без нее любое изменение — это разговор.


• Выход и передача. Исходный код, доступ, документация и знания в конце; спрашивайте формат, а не обещание.


• Ответственность и гарантии. Что покрыто, какие ограничения и какие гарантии реально есть.


• Сроки и расторжение. Как долго действует договор и как его можно завершить, включая содействие при переходе.

Часто задаваемые вопросы

С чего начать: RFI, RFP или RFQ?

RFI, когда круг вопросов не определен, — чтобы узнать, что существует и сколько это примерно стоит. RFP, когда требования и метод оценки зафиксированы. RFQ, когда круг зафиксирован и нужна цена. Ранний RFP без определенного круга вопросов превращает последующие требования в задачу каждой заявки.

Какие критерии использовать?

Те, которые отвечают на вашу проблему: понимание проблемы, функциональное соответствие, функционально-нестандартные требования, безопасность, интеграция, команда, референсы, коммерческие условия, поддержка. Веса — ваши, поставлены до встречи и держат сумму 100; таблица выше — отправная точка, а не догма.

Что делать, если вендор отказывается от пилота?

Спросить почему, и если отказ принципиален, сравнить его с тем, что предлагает рынок в целом: платный пилот — обычная практика, и отказ дает вам информацию о сотрудничестве. Есть случаи, где пилот объективно неприменим, — тогда замените его глубокой проверкой референсов и явной формой ограниченного первого этапа в договоре.

Как баллировать безопасность?

Тремя уровнями по каждому пункту: позиция отсутствует (1), политики описаны (3), проверена область сертификата и описан защищенный жизненный цикл разработки с доказательствами (5). Сертификаты — с вопросом об области, а не как строку; там, где сертификата нет, спрашивайте письменно, какие эквивалентные контроли есть. Безопасность баллируется не по наличию логотипа, а по доказательствам, которые можно перепроверить.

Нужно ли показывать матрицу вендорам?

До подачи — да, это нормально и честно; после — нет, это превращает оценку в спор. Опубликованные критерии, веса и формат подачи делают процесс предсказуемым и повышают качество ответов, потому что вендоры пишут то, что вы собираетесь измерять.

Какие ограничения обязательно назвать?

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

Источники и стандарты

• ISO — издатель ISO/IEC 27001 (управление информационной безопасностью); подтвердите актуальную редакцию и область сертификации, прежде чем полагаться на сертификат.
• OWASP — издатель чек-листа рисков веб-приложений Top 10, на который ссылается эта страница.
• Структура RFP, таблица баллирования, вопросы референсов и дизайн пилота следуют общей практике закупки программных услуг; на этой странице нет ни сроков, ни стоимости, ни процентов успеха и не заявляется никакой сертификат, аудит или квалификация для WorldwideTradeX; обязательства по защите данных названы, но не интерпретированы, — подтвердите применимый режим у квалифицированного консультанта.

Связанные страницы

Разработка ПО · ИТ-аутсорсинг из Турции · Модели стоимости и ценообразования · Кастомный против коробочного ERP · ИТ-аудит и консалтинг · Запросить КП