Доработка CRM с ИИ: как сравнить предложения подрядчиков по полной стоимости

Почему первая цена ещё не отвечает на вопрос о стоимости

На столе два предложения на одну доработку CRM. В первом написано: «Используем ИИ, реализуем за 180 тысяч». Во втором — 420 тысяч, зато рядом перечислены проверки, поставка и передача. Разница заметна раньше, чем содержание приложений. Кажется, осталось выяснить, почему второй исполнитель настолько дороже.

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

Для ИТ-директора полезно разделить три величины. Цена предложения — сумма за перечисленные в нём обязательства. Сопоставимая стоимость — расходы на одинаковый результат при одинаковых условиях. Полная стоимость на выбранном горизонте — сопоставимая поставка вместе с оговорёнными повторяющимися и дополнительными расходами. Последняя величина всегда имеет границу: период, состав систем, налоговую базу и правила учёта внутренних ресурсов.

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

Начинать стоит с результата, который компания собирается принять. Если его ещё нет, сначала понадобится обследование. В материале о внедрении CRM разобраны решения владельца процесса до настройки. Здесь считаем, что они уже приняты: новую функцию не выбираем и бизнес-процесс заново не проектируем.

Первый полезный вопрос к смете звучит так: «Что должно работать и что останется у нас после оплаты?» Ответ должен быть одинаковым для обоих исполнителей. Только затем имеет смысл обсуждать способ разработки и цену каждого этапа.

Что именно должно быть одинаковым

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

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

У BPMSoft есть техническое основание для такой точности. В документации начала разработки версии 1.9 рекомендуется использовать сборку, соответствующую продуктивной среде; там же описаны пользовательский пакет и зависимости. Для покупателя это означает практический вопрос: на какой именно исходной конфигурации исполнитель подтверждает результат? Работа на другой сборке не становится эквивалентной только потому, что название платформы совпало.

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

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

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

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

Другой пример — права пользователя. Если форма должна быть доступна только определённой роли, проверка под администратором не закрывает весь согласованный сценарий. Вопрос закупки здесь конкретен: включены ли настройка и проверка прав в предложение, какие исходные роли предоставляет заказчик и кто подтверждает итог? Это помогает выделить работу без перехода к построчному техническому ревью.

Что меняет ИИ в цене доработки

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

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

Официальные ограничения GitHub Copilot Chat прямо предусматривают проверку и тестирование сгенерированного кода. Источник относится к конкретному продукту и не устанавливает норму часов для BPMSoft. Его полезный для нашей задачи вывод ограничен: происхождение кода само по себе не подтверждает соответствие требованиям. Поэтому строка проверки не исчезает из состава работ из-за упоминания ИИ.

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

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

Порядок технического допуска отдельного изменения разобран в статье о проверке кода, предложенного ИИ. Здесь этот порядок не воспроизводится. Нам важно, чтобы работы по проверке имели понятное место в смете, а обещание ускорения не заменяло описание обязательств.

За что платят между кодом и приёмкой

Созданное изменение нужно собрать в поставляемый результат. Рекомендации BPMSoft 1.9 относят пользовательскую реализацию к персональному пакету и отдельно упоминают зависимости и привязки данных. Это не тарифный справочник. Но он помогает назвать предмет разговора с исполнителем: какие объекты он передаёт и что требуется для их работы в целевой конфигурации.

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

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

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

Документация и передача завершают этот набор. Если сопровождение будет выполнять другой специалист, ему нужны сведения о поставленных объектах, конфигурации и наблюдаемых ошибках. Передача не равна многотомному отчёту: достаточно согласованного комплекта, пригодность которого можно проверить. Более подробный инженерный контур рассмотрен в материале о совместной разработке BPMSoft.

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

Как устроена полная стоимость на выбранном горизонте

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

Горизонт выбирают под решение. В нашем примере это шесть месяцев сопровождения после приёмки. Это не рекомендация ограничивать оценку любой CRM полугодием. Если предложения заметно различаются по стоимости дальнейшего обслуживания, имеет смысл повторить сравнение на более длинном периоде. Если сроки запуска различаются, календарный момент начала платежей тоже требуется согласовать.

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

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

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

Из суммы нельзя делать видимость всезнания. Мы не оцениваем потери выручки, вероятность инцидента, инфляцию и стоимость денег. Если эти факторы существенны для конкретного выбора, их добавляют отдельными сценариями с собственными основаниями. Произвольный процент «на риски» не заменяет неизвестные условия договора.

Две сметы на одну поставку

Ниже — полностью синтетические предложения A и B. Это не цены рынка, не реальные подрядчики и не тарифы НТА. Обоим задан один результат: форма, правило маршрутизации и описанный обмен. После выравнивания состава оба включают одинаковую приёмку, поставку, документацию и устранение несоответствий согласованному результату. Способ разработки не используется как показатель качества.

В предложении A первоначально названа только реализация за 180 тысяч рублей. После уточнения к ней добавляются 80 тысяч на проверку, 40 на поставку и 20 на документацию. Разовая база становится равной 320 тысячам. В B сразу названа разовая база 420 тысяч: 200 на реализацию, те же 80, 40 и 20 на остальные работы и ещё 80 за пакет дополнительных часов.

Ежемесячное сопровождение в обоих вариантах имеет один согласованный состав. Цены 20 и 15 условны; из них не следует разница в качестве услуги. Дополнительные работы в этот ежемесячный состав не входят. Новых лицензий и инфраструктуры в примере нет: предполагается, что существующие права и мощность подходят обоим решениям. В реальном сравнении это допущение нужно подтвердить.

×

Собственный сценарный расчёт НТА: A — 180 + 140 + 120 = 440; B — 420 + 90 = 510 тыс. руб. Горизонт — шесть месяцев, дополнительные работы ещё не востребованы. Условные суммы не характеризуют рынок.

Теперь разница составляет 70 тысяч, а не 240. Это не означает, что удалось обнаружить скрытую переплату. Мы просто сравнили одинаковый базовый результат на одном горизонте. У B остаётся дополнительное условие — уже оплаченные 20 часов, и его полезность зависит от того, понадобятся ли они вообще.

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

Сколько дополнительных работ меняет выбор

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

Такое разграничение нужно согласовать до расчёта. Иначе подрядчик сможет назвать дефект «новой задачей», а модель посчитает другое обязательство. Для реального предложения попросите примеры: что входит в исправление, что покрывает сопровождение и какое событие создаёт отдельную оплачиваемую работу. Одно и то же действие нельзя учитывать в двух строках.

В сценарии час стоит 4 тысячи рублей у обоих. У A пакет отсутствует. У B первые 20 часов уже оплачены в разовой базе, доступны в течение выбранных шести месяцев, а неиспользованный остаток не возвращается. Сверх пакета действует та же ставка. Для обоих рассматривается одинаковое r; это проверка условий оплаты, а не предположение о разной дефектности исполнителей.

Формулы на шесть месяцев, в тысячах рублей:

Стоимость A = 440 + 4 × r.

Стоимость B = 510 + 4 × max(0; r − 20).

При нуле дополнительных часов A обходится в 440, B — в 510. При десяти часах получаются 480 и 510. Равенство наступает при 17,5 часа: 440 + 4 × 17,5 = 510. При двадцати часах A стоит 520, B — 510. При сорока — 600 и 590 соответственно.

×

Расчёт НТА по двум открытым формулам. Обе шкалы начинаются с нуля. После исчерпания пакета обе линии растут на 4 тыс. руб. за час: преимущество B больше не увеличивается. График не показывает вероятность дополнительных работ.

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

Для произвольного числа месяцев H база A равна 320 + 20 × H, база B — 420 + 15 × H. Поэтому сравнение меняется и при другом горизонте, даже без изменения функции. Ценность расчёта — в явных условиях, которые можно заменить собственными, а не в универсальности полученного порога.

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

Если у исполнителей разные ставки или разные оценки нужных часов, оставьте две переменные вместо одной. Тогда сравнение уже не сводится к единственной точке 17,5. Потребуется несколько согласованных сценариев и объяснение, почему оценки различаются. Нельзя молча назначить одному подрядчику больше исправлений только из-за использования ИИ: для такого различия нужны относящиеся к проекту основания.

Как сравнить условия после сдачи

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

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

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

Для нашего примера пакет B становится выгоднее при определённом объёме дополнений, но это не повод специально расходовать часы. Сравнивается реальная потребность, а не занятость исполнителя. Покупка ненужной работы не становится экономией из-за низкой эффективной ставки на использованный час.

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

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

Для обращения после сдачи заранее полезно согласовать простую последовательность: зарегистрировать наблюдаемое отклонение, сопоставить его с принятой версией задания, определить категорию работы и только затем подтвердить оплату. Если причина пока неизвестна, отдельно оговаривается диагностика. Это рекомендация по прозрачности сравнения, а не готовая юридическая трактовка гарантии. Её смысл — не заставить исполнителя бесплатно менять любое пожелание, а не оплачивать один и тот же согласованный результат повторно из-за неясной классификации.

Когда расчёт не позволяет выбрать подрядчика

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

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

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

Не сравниваются здесь и последствия задержки запуска. Если сроки принципиальны, зафиксируйте календарные условия отдельно: доступность команды заказчика, готовность внешнего сервиса, окно установки и порядок решения блокирующих вопросов. Затем оцените сценарии с соответствующими специалистами. Добавлять к цене произвольную «стоимость простоя» без основания не полезнее, чем её игнорировать.

Наконец, условный пример ничего не говорит о репутации или добросовестности реального исполнителя. A и B — способы показать состав и правила оплаты, а не портреты «плохого ИИ-подрядчика» и «хорошего классического интегратора». Оба могут применять ИИ; оба должны подтвердить общий результат. Цена, пригодность и исполнение обязательств остаются разными предметами проверки.

Таблица сравнения и вопросы подрядчикам

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

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

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

Тест понедельником

Возьмите две реальные сметы на одну доработку CRM. Попросите коллегу, не участвовавшего в обсуждении, ответить по документам: что компания принимает, какие работы оплачены, кто устанавливает результат, кто устраняет несоответствия и сколько стоит одинаковый период сопровождения. Там, где требуется устное пояснение автора сметы, запишите вопрос для уточнения.

Затем выберите одну неопределённость, которая действительно влияет на сравнение. Это могут быть дополнительные часы, новая лицензия или время внутренней команды. Для часов подставьте свои условия в открытую формулу; для неизвестной лицензии сначала получите условия и цену. Не выбирайте число только ради завершённого расчёта.

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

НТА может обследовать, реализовать и сопровождать изменение CRM. Начать разговор полезно с одинакового задания и двух смет: так обсуждение будет о составе результата, а не о том, насколько убедительно исполнитель произносит слово «ИИ».

Важное уведомление

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