Гарантии при разработке ERP: что требовать и как оформить

📅 21 июля 2025 г.⏱ 8 мин чтения

Какие гарантии должен давать разработчик ERP и CRM. Гарантийная поддержка, SLA, ответственность, что зафиксировать в договоре.

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

Что такое гарантийная поддержка в разработке ПО

Гарантийная поддержка — обязательство разработчика бесплатно исправлять ошибки (баги) в течение определённого периода после сдачи системы. Это не «добавить новый функционал» — это «починить то что не работает как должно».

Стандартный срок гарантии в профессиональной разработке — 12 месяцев. Минимально допустимый — 6 месяцев. Меньше 6 месяцев — тревожный сигнал.

Что входит в гарантийное обслуживание

Исправление ошибок (баги) — функционал работает не так как описано в ТЗ.
Критические уязвимости безопасности — если обнаружена дыра в безопасности.
Проблемы с производительностью при штатной нагрузке — если система тормозит при обычном использовании.

Что НЕ входит в гарантию:

Новый функционал которого не было в ТЗ
Изменения требований заказчика
Проблемы вызванные изменениями инфраструктуры на стороне заказчика
Ошибки возникшие из-за неправильного использования системы

SLA: время реакции на проблемы

Service Level Agreement (SLA) — соглашение об уровне сервиса. В контексте гарантийной поддержки это время реакции и время решения при разных типах проблем:

Приоритет	Описание	Время реакции	Время решения
Критический	Система не работает, бизнес остановлен	2 часа	8 часов
Высокий	Ключевой функционал недоступен	4 часа	24 часа
Средний	Отдельная функция работает некорректно	8 часов	3 рабочих дня
Низкий	Незначительные неудобства, есть обходной путь	1 день	7 дней

Что зафиксировать в договоре

Срок гарантии (минимум 12 месяцев)
Определение что считается «ошибкой» (соответствие ТЗ)
Сроки реакции и устранения по уровням критичности
Канал обращения (тикет-система, почта, мессенджер)
Порядок эскалации при нарушении SLA
Ответственность разработчика при нарушении SLA (штрафные санкции)

Поддержка после гарантии: что дальше

После гарантийного периода переходите на пакет платной поддержки или работайте по запросам. Варианты:

Пакет часов — покупаете X часов в месяц, расходуете на поддержку и небольшие доработки. Предсказуемый бюджет.
По запросу (T&M) — платите за фактические часы. Гибко, но сложнее планировать бюджет.
Собственная команда разработки — нанимаете внутреннего разработчика. Имеет смысл при большом объёме постоянных доработок.

ℹ️

Мы даём 12 месяцев гарантийной поддержки на все проекты. После гарантии — пакеты поддержки от 80 тыс. рублей в квартал.

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

Что если разработчик говорит что гарантийный случай «не в нашей зоне»?+

Обратитесь к ТЗ: если функция описана и работает не так — это гарантийный случай. Если в ТЗ не было — это не гарантия, это изменение. Детальное ТЗ защищает обе стороны.

Можно ли требовать компенсацию за простой из-за бага?+

Только если это прямо прописано в договоре. Стандартный договор не предусматривает компенсацию прямых убытков. Для критически важных систем стоит включить штрафные санкции за нарушение SLA.

Что происходит с гарантией если мы сами внесём изменения в код?+

Зависит от договора. Обычно гарантия аннулируется на изменённые части. Поэтому важно любые изменения делать через разработчика или согласовывать формально.

Насколько реально взыскать штраф с разработчика за нарушение SLA?+

Реально если штрафные санкции прописаны в договоре с конкретными суммами. Без этого — только моральное давление и расторжение договора.

Нужна ли страховка разработчика?+

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

Как выбрать между собственной командой поддержки и аутсорсом?+

Собственная команда выгодна при объёме постоянных доработок от 100–150 часов в месяц. При меньшем объёме аутсорс дешевле — вы платите за фактические часы, а не за простой.