Как подготовить требования к поставщику корпоративных услуг

Чётко сформулированные требования позволяют избежать недопонимания, снизить риски превышения бюджета и сроков, а также повысить вероятность получения услуги, которая действительно решает бизнес‑задачу. Ниже представлен практический алгоритм, который помогает перейти от общей идеи к готовому документу, пригодному для размещения в запросе предложений (RFP) или техническом задании (ТЗ).

1. Определите бизнес‑цели и задачи

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

• Какую проблему или возможность вы хотите решить?
• Какой результат вы ожидаете получить (например, сокращение времени обработки заявок на 30 %, повышение уровня удовлетворённости сотрудников)?
• Какие ограничения по бюджету, срокам или ресурсам уже известны?

Ответы на эти вопросы запишите в виде короткого утверждения – «бизнес‑цели». Они будут использоваться позже для проверки соответствия каждого пункта требований.

2. Выявите заинтересованные стороны

Услуга обычно затрагивает несколько подразделений или групп пользователей. Чем полнее вы учтете их точки зрения, тем меньше вероятность упустить критически важные аспекты.

1. Составьте список отделов, которые будут взаимодействовать с услугой (ИТ, финансы, HR, операционное подразделение и т.д.).
2. Для каждого определите роль: конечный пользователь, администратор, утверждающий, контролёр качества.
3. Назначьте ответственного за сбор требований от каждой группы (может быть внутренний аналитик или руководитель проекта).

Проведите короткие интервью или workshops с представителями каждой группы. Фиксируйте их пожелания в нейтральной форме, без premature решений о конкретных технологиях.

3. Соберите функциональные требования

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

3.1. Техника формулировки

Используйте структуру «Какрольдействуетчто для достижения цели». Например:

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

3.2. Источники функциональных требований

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

Соберите все пункты в один список, затем выполните приоритизацию: обязательные (must‑have), желательные (should‑have) и необязательные (could‑have). Это упростит последущую оценку предложений.

4. Оформите нефункциональные требования

Нефункциональные требования определяют, как должна работать услуга, а не что она делает. Они часто оказывают решающее значение при выборе поставщика.

4.1. Основные категории

• Уровень обслуживания (SLA) – время отклика, время восстановления, доступность (например, 99,9 % в месяц).
• Безопасность – требования к шифрованию данных, контролю доступа, журналу аудита, соответствию стандартам (ISO 27001, GDPR и т.п.).
• Производительность – максимальная нагрузка, время обработки транзакции, масштабируемость.
• Совместимость и интеграция – необходимость работы с существующими системами (ERP, CRM, документооборот) через API или стандартные протоколы.
• Поддержка и обслуживание – часы работы службы поддержки, каналы связи, порядок эскалации, гарантии времени решения инцидентов.
• Отчётность и мониторинг – какие метры должны быть доступны, частота формирования отчётов, формат экспорта.
• Выход из договора – процедура передачи данных, сроки уведомления, возможные штрафы.

4.2. Как собрать

Для каждой категории задайте конкретные вопросы ответственным из пункта 2. Например, для безопасности спросите: «Какие данные будут обрабатываться услугой и какой уровень конфиденциальности требуется?» Зафиксируйте ответы в измеримой форме, где это возможно («время восстановления не более 4 часов»).

5. Структурируйте документ с требованиями

Хорошо организованный документ облегчает чтение как внутренним заказчикам, так и потенциальным поставщикам.

5.1. Рекомендуемая структура

1. Введение – краткое описание бизнес‑цели и контекста проекта.
2. Глоссарий – определения терминов и аббревиатур, используемых в документе.
3. Функциональные требования – numbered список, каждый пункт с идентификатором (FR‑001, FR‑002 …).
4. Нефункциональные требования – аналогично с идентификаторами (NFR‑001 …).
5. Приложения – текущие схемы процессов, примеры форм данных, ссылки на внутренние регламенты.
6. Критерии оценки предложений – весовые коэффициенты для функциональных и нефункциональных блоков, пороговые значения по SLA.

Каждый требование должно быть:

• Однозначным – нельзя интерпретировать по‑разному.
• Измеримым – есть способ проверить выполнение (тест, демонстрация, метрика).
• Неконтрадиктным – не противоречит другим пунктам.
• Достижимым – реалистично при текущих технологиях и бюджете.

6. Проверка и валидация требований

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

6.1. Внутренний ревью

• Разослать черновик всем заинтересованным сторонам из пункта 2.
• Провести встречу, где каждый участник подтверждает, что его потребности отражены корректно.
• Зафиксировать замечания и внести правки.

6.2. Тестирование на понятность

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

6.3. Соответствие целям

Для каждого требования задайте вопрос: «Как его выполнение поможет достичь бизнес‑цели из пункта 1?» Если связь неочевидна, пересмотрите необходимость этого пункта.

7. Подготовка запроса предложений (RFP) или технического задания

Когда требования окончательны, их можно включить в RFP/ТЗ. Следующие элементы усиливают прозрачность процесса выбора.

• Инструкция для поставщиков – формат ответа, сроки подачи, контактное лицо для вопросов.
• Описание процесса оценки – этапы (предварительная проверка, техническое интервью, пилотный запуск).
• Конфиденциальность и обработка данных – требования к НДА, если необходимо.
• Приложение с полным списком требований (пункты 5).

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

8. Типичные ошибки и как их избежать

Даже опытные команды сталкиваются с повторяющимися недочётами. Знание их помогает предупредить проблемы на ранней стадии.

8.1. Слишком абстрактные формулировки

«Система должна быть удобной» – не измеряемо. Замените на конкретный критерий: «Среднее время выполнения типовой операции не более 15 секунд, измеряемое в тестовой среде с нагрузкой 100 пользователей».

8.2. Пренебрежение нефункциональными аспектами

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

8.3. Отсутствие приоритизации

Если все требования отмечены как «обязательные», поставщики не могут предложить trade‑off. Используйте три уровня приоритета (must/should/could) и отражайте их в весовых коэффициентах при оценке.

8.4. Неучёт изменений в процессе проекта

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

8.5. Недостаточная проверка поставщика

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

9. Следующие шаги после утверждения требований

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

1. Опубликуйте RFP в выбранных каналах (корпоративный портал, торговые площадки, прямые приглашения).
2. Соберите вопросы от поставщиков в течение определённого периода и предоставьте единые ответы (addendum).
3. Примите предложения, проведите первичную проверку на соответствие формальным требованиям (полнота ответа, приложения).
4. Оценивайте техническую часть по заранее определённой шкале, затем финансовую часть.
5. Проведите переговоры с коротким списком финалистов, уточните детали SLA, гарантий и условий выхода.
6. Выберите победителя, уведомите всех участников и подпишите контракт.
7. Запустите пилот или этап внедрения, контролируя выполнение SLA и собирая обратную связь от пользователей.

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