Между «настроить» и «доработать» лежат три уровня, а не два, и стоят они по-разному не столько в момент внедрения, сколько на втором году — когда выходит обновление вендора и выясняется, что часть изменений нужно проверять и чинить после каждого релиза. Решение об уровне принимается на этапе требований, а платится за него в течение всей жизни системы.
Правило, которое закрывает большую часть споров, звучит так: если требование про уникальность вашего бизнеса — это код; если про удобство менеджера — это настройка. Уникальность стоит дорого и оправданно, удобство стоит дёшево и тоже оправданно; беда начинается там, где удобство закрывают кодом, потому что «так просили».
Ниже — три уровня с ценой одного и того же требования на каждом, правило разделения на шести живых примерах, что происходит с изменениями при обновлении вендора, из чего складывается ежемесячная часть и расчёт точки, после которой переезд на другую систему дешевле продолжения доработок. Ставка инженера в расчётах — 3 000 ₽/час.
Три уровня изменений и что каждый стоит
Уровни отличаются не сложностью, а тем, чьими средствами делается изменение: средствами самой системы, средствами её конструктора или собственным кодом поверх неё. Отсюда следует всё остальное — цена, срок, и главное, кто сможет это сопровождать, когда исходный исполнитель уйдёт.
| Уровень | Что это | Кто делает | Срок типового изменения | Кто сопровождает потом |
|---|---|---|---|---|
| 1. Настройка штатными средствами | Поля, воронки, стадии, права и роли, роботы, шаблоны документов, штатные отчёты | Администратор системы на вашей стороне | Часы — дни | Ваш администратор, без подрядчика |
| 2. Кастомизация конструктором | Свои сущности и справочники, низкокодовые правила, свои формы и представления, вычисляемые поля | Внедренец или обученный администратор | Дни — недели | Внедренец; администратор при наличии описания |
| 3. Код и собственные приложения | Обращения к внешним системам в момент действия, своя бизнес-логика, свои экраны и модули | Разработчик | Недели — месяцы | Только разработчик, и желательно тот же |
Разница видна на одном требовании. Возьмём типовое: при переводе сделки на этап «договор» система должна сформировать договор по шаблону, подставив реквизиты из карточки и данные из учётной системы.
Сравнение в три колонки с общим заголовком «Требование: при переводе на этап «договор» сформировать договор по шаблону». Первая «Настройка — 18 000 ₽»: 6 часов, делает администратор, переживает обновление молча. Вторая «Конструктор — 60 000 ₽»: 20 часов, делает внедренец, проверка после релиза по короткому списку. Третья «Код — 210 000 ₽»: 70 часов, делает разработчик, регламентная проверка после каждого релиза, сопровождает только разработчик. Под колонками общая строка «кто сможет это починить через год без исходного исполнителя»: администратор / внедренец при описании / никто без разработчика. Чертёжный стиль, подписи по-русски.
Правило разделения: уникальность или удобство
Требования приходят от людей в виде готовых решений: «сделайте кнопку», «пусть при сохранении открывается окно». Первое действие — перевести решение обратно в задачу: что человек пытается сделать и почему это не получается сейчас. После такого перевода примерно половина требований уходит на первый уровень или исчезает.
| Требование | Уровень | Почему именно этот |
|---|---|---|
| Поле «источник» находится внизу формы, менеджеры до него не долистывают | 1 | Удобство: порядок полей и форма создания меняются штатно за минуты |
| Нужна стадия «ожидание поставки» с автоматической задачей на менеджера | 1 | Процесс описывается штатными стадиями и роботами |
| Согласование договора в три подписи с возвратом на доработку | 2 | Штатный или низкокодовый процесс согласования есть почти во всех системах |
| Нужен отчёт по марже в разрезе менеджеров и категорий | 2 | Конструктор отчётов, если себестоимость уже приезжает в систему |
| Скидка считается по нашей матрице объёма, категории клиента и срока оплаты | 3 | Уникальность бизнеса: правило не описывается штатными условиями |
| В момент разговора менеджер должен видеть свободный остаток на складе | 3 | Обращение во внешнюю систему в момент действия, а не выгрузка по расписанию |
Последняя строка — самая частая причина перехода на третий уровень, и она же самая недооценённая по цене. Выгрузка остатков раз в сутки делается коннектором, а онлайн-запрос в момент разговора требует прямого доступа к учётной системе и обработки её недоступности. Четыре способа обмена с ценой каждого разобраны в материале про интеграцию CRM с 1С, а лимиты, в которые упирается любой из них, — в материале про API CRM и лимиты.
Схема-развилка сверху вниз. Верхний блок «Требование в виде решения — сделайте кнопку» → блок «Перевод в задачу: что человек пытается сделать» с подписью сбоку «около половины требований отсеивается здесь». Далее развилка на три ветви по вопросу «что именно закрывается»: ветвь «удобство работы» → «Уровень 1, настройка, часы-дни»; ветвь «недостающая сущность или отчёт» → «Уровень 2, конструктор, дни-недели»; ветвь «правило, уникальное для вашего бизнеса, или обращение во внешнюю систему в момент действия» → «Уровень 3, код, недели-месяцы» с дополнительной плашкой «регламентная проверка после релизов». Чертёжный стиль, подписи по-русски.
Что происходит при обновлении вендора
Обновления выходят независимо от вас, и главный вопрос не «сломается ли», а «узнаете ли вы об этом до того, как узнает клиент». Разные уровни ведут себя по-разному, и планировать проверку надо ровно по этой таблице.
| Что изменено | Как переживает обновление | Что делать после релиза |
|---|---|---|
| Штатные поля, стадии, права, роботы, шаблоны | Почти всегда молча | Ничего; изредка появляются новые возможности, которыми стоит заменить старые обходы |
| Низкокодовые правила и свои справочники | Обычно переживает, изредка меняется поведение условий | Короткий список проверок: 5–8 сценариев прогоняются вручную за час |
| Обращения к внутренним методам и интерфейсам системы | Гарантий нет: метод может измениться или исчезнуть | Регламентная проверка на тестовом контуре до обновления боевого |
| Правка исходников коробочной версии | Ломается или блокирует само обновление | Так не делают; если сделано — либо откат к штатным средствам, либо отказ от обновлений |
Компания, у которой правка исходников не даёт обновиться, сначала пропускает один релиз, потом год, а потом обнаруживает, что переход на актуальную версию превратился в отдельный проект стоимостью с внедрение. Плюс всё это время не устанавливаются исправления безопасности. Если доработка мешает обновляться, её надо переписать штатными средствами, а не оставлять как есть — и эта работа считается заранее, а не в тот момент, когда обновиться уже нельзя.
Практический вывод: тестовый контур перестаёт быть роскошью на третьем уровне. Он нужен именно для того, чтобы обновление проверялось до боевого, и разворачивается на обезличенной копии данных — как это делается и сколько занимает, разобрано в материале про обезличенные данные для тестового контура.
Цена владения и точка разворота
Коробка с кастомизацией по рынку — от 500 000 ₽ разово плюс 15 000–80 000 ₽ в месяц поддержки. Широкая вилка ежемесячной части объясняется тем, что в неё складываются четыре разные вещи, и в предложениях они обычно не разделены.
Именно последние две строки и создают точку разворота. Эксплуатация — 45 000 ₽ в месяц — платится в любой системе и никуда не денется. А 34 000 ₽ в месяц на доработки и проверки существуют только потому, что требования не закрываются штатно; в системе, где они закрываются, этих денег нет.
Расчёт умышленно грубый, и у него есть важная оговорка. Переезд имеет смысл только если новая система действительно закрывает ваши требования штатно — иначе через 22 месяца вы окажетесь в той же точке, но уже с двумя оплаченными переездами. Проверяется это до решения, на списке требований, а не на демонстрации интерфейса; смету и состав такого переезда мы разбирали в материале про то, чем заменить зарубежную CRM, — цифра 750 000 ₽ взята оттуда.
Двухосевой график на 36 месяцев. По горизонтали — месяцы, по вертикали — рубли до 1 200 000. Восходящая ступенчатая линия «накопленные доработки и регламентные проверки» с шагом 102 000 ₽ каждый квартал. Горизонтальная штриховая линия на отметке 750 000 ₽ с подписью «стоимость переезда на систему, где требования закрываются штатно». Точка пересечения на 22-м месяце выделена и подписана «точка разворота». Область справа от точки залита штриховкой с подписью «здесь платите за тот же результат дважды». Чертёжный стиль, подписи по-русски.
Что спросить у подрядчика до начала работ
Пять вопросов, каждый из которых меняет смету или срок. Задавать их надо до договора: после подписания уровень исполнения уже выбран, а вы про это узнаете на приёмке.
- 1Каким уровнем закрывается каждое требование из списка и почему? Ответ «сделаем как надо» означает, что уровень выберут по удобству исполнителя, а платить за сопровождение будете вы.
- 2Кому принадлежит код доработок и передаётся ли он вместе с исходниками при закрытии проекта? Отсутствие ответа означает, что следующий подрядчик начнёт работу с оценки «проще переписать». Что именно забирается в день подписания акта, перечислено в чек-листе закрытия проекта.
- 3Что нужно проверять после обновления вендора и сколько часов это занимает? Эта строка обязана быть в договоре поддержки отдельно. Если её нет, регламентную проверку никто не делает, и поломка обнаруживается на клиенте.
- 4Есть ли тестовый контур и на чьих данных он работает? Проверять обновление на боевой системе — это не экономия, а перенос риска на вас; обезличенная копия стоит дешевле одного разбора последствий.
- 5Что произойдёт при смене исполнителя: есть ли описание доработок, по которому в них войдёт другой разработчик? Документация третьего уровня — это не пожелание: без неё стоимость смены подрядчика равна стоимости повторной разработки.
Когда дорабатывать не надо
Половина требований третьего уровня отсеивается ещё до сметы, если задать по ним пять вопросов. Ниже — ситуации, в которых правильный ответ «не делаем», и это не отказ, а инженерное решение.
- Требование от одного человека. Если функция нужна одному менеджеру из двадцати, её цена делится на одного. Обычно она закрывается изменением его личного порядка работы или сохранённым фильтром, а не разработкой.
- Процесс менялся дважды за полгода. Цикл изменений короче цикла разработки: доработка устареет до приёмки. Сначала регламент на одну страницу и владелец процесса, потом автоматизация — тот же принцип разобран в материале про то, когда автоматизация не окупится.
- Требование закрывается строкой в регламенте. «Пусть система не даёт закрыть сделку без причины отказа» — это обязательное поле, а не разработка. «Пусть система запретит скидку больше 15 % без руководителя» — это уже правило и второй уровень; разница между ними в том, нужно ли системе что-то вычислять.
- Вендор закроет это в ближайшем релизе. Дорожные карты у российских систем публичные. Заплатить 210 000 ₽ за то, что через квартал появится штатно, — обидная и очень частая история; вопрос «нет ли этого в планах» стоит одного письма.
И честный итог. Третий уровень не плох сам по себе: правило расчёта скидки, которое отличает вашу компанию от конкурентов, стоит того, чтобы жить в коде. Плохо другое — когда в код уезжает удобство, потому что так быстрее договориться, и через два года компания платит 34 000 ₽ в месяц за поддержку решений, каждое из которых по отдельности казалось мелочью.
Цена доработки — это не то, сколько за неё выставили, а то, сколько стоит её сопровождать после каждого обновления в течение всей жизни системы.
