Что на самом деле разрушает проекты Salesforce с юридической точки зрения
Практически любой конфликт в проекте Salesforce начинается не с вопроса "сколько это стоит", а с вопроса "завершено ли это". Поставщик считает, что результат передан, а организация полагает, что он непригоден для использования. Обе стороны правы в своем понимании, поскольку никто заранее не определил, что будет считаться завершенным.
Из этого вытекает один принцип, которым руководствуются все пункты данной статьи: хороший контракт не защищает вашу сторону в конфликте, он предотвращает конфликт.
Двенадцать ключевых пунктов
1. Определение приемки для каждого результата
Это самый важный пункт. Для каждого результата необходимы наблюдаемые критерии: не "экран управления клиентами", а "пользователь с профилем X может выполнить сценарий Y и получить результат Z, как определено в утвержденных критериях приемки".
Рекомендуемая формулировка: Определенный период тестирования, начинающийся с момента поставки, по истечении которого клиент либо утверждает результат, либо письменно указывает на выявленные недостатки. Молчание по истечении этого периода считается утверждением — это пункт, который защищает поставщика и дисциплинирует клиента.
2. Механизм запросов на изменение
Определяет, кто имеет право запрашивать изменения, кто их оценивает, в какие сроки и по какому тарифу. Тариф должен быть установлен при подписании контракта, а не в момент возникновения необходимости.
3. Двусторонняя зависимость
Большинство контрактов определяют, что происходит, когда поставщик задерживается, но не определяют, что происходит, когда задерживается клиент. В результате, когда организация опаздывает с утверждением, поставщик несет издержки, а затем перекладывает их через запросы на изменение.
Сбалансированная формулировка: График проекта зависит от определенной реакции клиента (время на утверждение, доступность владельца процесса, предоставление данных) и превышение сроков сдвигает веху после письменного уведомления.
4. Право собственности на код, конфигурацию и документацию
Разделение между специализированным продуктом и общими компонентами поставщика, с бессрочной лицензией на использование общих компонентов, не зависящей от продолжения сотрудничества.
5. Документация как обязательный результат
Документация, которая не определена как результат с критериями приемки, либо не будет написана, либо будет написана в последнюю неделю. Определите минимум: архитектурные решения, модель данных, сопоставление интеграций, операционные процедуры.
6. Гарантия и исправление дефектов
Определенный период и четкое разграничение дефекта и изменения. Рабочее определение: расхождение между фактическим поведением и утвержденными критериями приемки является дефектом.
7. Ключевые специалисты
Имена, процент выделения ресурсов, предварительное уведомление о замене и эквивалентный профессиональный уровень с одобрения клиента.
8. Доступы, среды и информационная безопасность
Кто получает доступ к каким средам, на какой срок, что происходит с доступами по завершении, и как обрабатываются реальные данные в непроизводственных средах.
9. Соответствие нормативным требованиям и конфиденциальность
Место хранения, обработка персональных данных, право на проверку и отчетность об инцидентах безопасности. В регулируемых организациях этот пункт требует индивидуальной формулировки, а не шаблона.
10. Точки принятия решений и точки выхода
Право остановить проект по завершении определенного этапа с заранее оговоренным порядком оплаты. Такой пункт снижает риски обеих сторон, поэтому хороший поставщик не будет возражать против него.
11. Передача знаний
Не "обучение", а: количество часов, для кого, о чем и каков результат. Желательно, чтобы передача знаний распределялась на протяжении всего проекта, а не концентрировалась в его конце.
12. Завершение и выход
Список передаваемых элементов, формат, период дублирования функций, тариф за часы поддержки при передаче. Это пункт, который никто не хочет обсуждать при подписании, и именно поэтому стоит настаивать на нем тогда.
Карта рисков: что предотвращает каждый пункт
| Пункт | Предотвращаемый отказ | Цена отсутствия |
|---|---|---|
| Определение приемки | Спор о "завершении" | Задержка оплаты и ввода в эксплуатацию |
| Запросы на изменение | Ценообразование в условиях острого дефицита | Неконтролируемое увеличение затрат |
| Двусторонняя зависимость | Взаимные обвинения в задержке | Непрозрачное смещение сроков |
| Право собственности и документация | Зависимость от поставщика | Высокие затраты при смене поставщика |
| Ключевые специалисты | Тихая смена команды | Потеря контактов и знаний |
| Гарантия | Спор о дефекте против изменения | Двойная оплата за исправление |
| Выход | Переговоры с невыгодной позиции | Непредвиденные затраты на передачу |
Формулировки, которых следует избегать
- "Поставщик выполнит работу с обычным профессионализмом" — невозможно обеспечить соблюдение без критериев.
- "Стороны согласуют позднее..." — каждый такой пункт является потенциальным конфликтом.
- "При условии полного сотрудничества клиента" — без определения этого, это односторонняя защита.
- "Результат будет поставлен по завершении проекта" — без определения, что такое завершение.
- График платежей по календарным датам вместо привязки к приемке.
Пример для иллюстрации: розничная сеть
Гипотетический сценарий предназначен для иллюстрации. Сеть подписала соглашение (SOW), которое включало "миграцию данных клиентов из существующей системы". Организация предполагала, что миграция включает удаление дубликатов; поставщик предполагал, что он передает то, что ему было предоставлено.
В результате были перенесены сотни тысяч записей с дубликатами. Обе стороны прочитали одно и то же предложение и поняли его по-разному. В контракте не было пункта, который бы определял, что считается корректной записью.
Коррекция, сделанная в последующих соглашениях той же сети, была краткой: приложение, определяющее измеримый порог качества для загрузки — долю записей, проходящих валидацию, правила выявления дубликатов и кто утверждает. Это приложение заменило десятки часов споров.
Что проверять перед подписанием
- Каждый результат в предложении есть в SOW с критериями приемки.
- Каждое предположение, представленное в предложении, отображено как явное предположение в контракте.
- График платежей привязан к приемке.
- Есть пункт о выходе и пункт о передаче знаний.
- Определение дефекта достаточно четкое для разрешения пограничных случаев.
То, что было согласовано при сравнении предложений, но не включено в контракт, просто не существует. Сам процесс сравнения подробно описан в руководстве по сравнению предложений Salesforce, а основа для формулирования требований закладывается уже в документе запроса (RFP), как указано в руководстве по RFP.
Связь с выбором поставщика
Некоторые из этих пунктов также служат инструментом оценки: поставщик, который противится пункту о праве собственности на документацию или пункту о выходе, говорит вам кое-что о своей бизнес-модели. Сочетание профессиональной оценки и договорной добросовестности оценивается в руководстве по оценке поставщиков Salesforce, а общие критерии для проверки компании собраны в руководстве по выбору компании-интегратора. Соответствие типа взаимодействия типу приобретаемой услуги подробно описано в руководстве по услугам Salesforce.
Следующий шаг
Возьмите SOW, которое у вас есть, и отметьте каждое место, где написано "будет поставлено" или "будет выполнено" без указания того, как будет определено, что это произошло. Каждая такая отметка — потенциальный конфликт, и каждую из них можно исправить сейчас, потратив всего пять минут.