Заказная разработка или готовое ПО: что выбрать

Коротко: Выбор между заказной разработкой или готовым программным обеспечением зависит от уникальности бизнес-процессов и бюджета. Готовые системы (SaaS или коробочные версии) дешевле и быстрее внедряются, но ограничивают функционал. Собственное ПО дает полный контроль и масштабируемость, но требует огромных капитальных вложений и учета новых налоговых правил 2026 года, включая ставку НДС 22%.

Кстати, в AmSales мы делаем разработку программного обеспечения на заказ и внедрение и настройку Битрикс24 под ключ. Если нужна помощь - напишите нам.

Готовое решение или разработка с нуля: основные отличия

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

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

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

Главный минус здесь - время и неопределенность. Стоимость разработки собственного ПО часто растет в процессе реализации, когда выясняется, что требования были описаны недостаточно детально. Вы не просто покупаете инструмент, вы создаете актив, который требует постоянного внимания команды разработчиков, тестировщиков и системных аналитиков. Это не разовое мероприятие, а непрерывный процесс развития.

Сравнительный анализ подходов

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

Экономика выбора: скрытые расходы и налоги 2026 года

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

При использовании готового ПО основная статья расходов - это ежегодная индексация стоимости подписки. Вендоры имеют право повышать цены, и вы оказываетесь в заложниках у их политики. Кроме того, не забывайте про стоимость интеграций. Если вам нужно связать CRM с вашей учетной системой или сервисом рассылок, за каждый такой "мостик" придется платить отдельно - либо разработчикам, либо самому сервису через API-лимиты.

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

В 2026 году на финансовую модель серьезно влияет налоговая нагрузка. Любое решение должно проходить через фильтр налогового планирования, так как изменения в законодательстве напрямую влияют на то, сколько денег останется в компании после внедрения системы. Ошибки в расчетах на этапе планирования бюджета могут привести к тому, что проект, казавшийся выгодным, станет убыточным из-за не учтенных налоговых обязательств.

НДС 22% и новые правила расчета по длящимся договорам

С 1 января 2026 года налоговый ландшафт для бизнеса существенно изменился. Основное изменение - повышение основной ставки НДС с 20% до 22%. Это напрямую влияет на стоимость любого ИТ-внедрения. Если вы планируете заказную разработку или покупку лицензий, закладывайте эти дополнительные 2% в бюджет сразу. Для крупных компаний это превращается в серьезные суммы, которые могут существенно сместить баланс между CAPEX (капитальными вложениями) и OPEX (операционными расходами).

Но еще более критичным стало изменение порядка исчисления НДС по длящимся договорам, вступившее в силу 1 октября 2026 года согласно закону № 293-ФЗ. Если раньше в долгосрочных контрактах на разработку ПО часто возникали сложности с тем, как и когда признавать налог, то теперь правила стали жестче и прозрачнее. Согласно изменениям в статьях 166 и 168 НК РФ, при возникновении обязанности по уплате НДС налог по длящимся договорам рассчитывается исходя из цены договора, а не предъявляется сверх неё.

Это означает, что при составлении договора на разработку программного обеспечения вам нужно быть предельно внимательным к тому, как прописана цена. Если в договоре указана общая сумма, то НДС теперь "сидит" внутри этой суммы. Для покупателя, имеющего право на вычет, налог будет исчисляться дополнительно к цене с оформлением счета-фактуры, но общая механика расчета изменилась. Это требует от бухгалтерии и юридического отдела пересмотра всех типовых форм контрактов на ИТ-услуги.

Для бизнеса это несет два риска. Первый - риск неверного планирования денежного потока (cash flow). Если вы не учли, как новая ставка и правила расчета повлияют на итоговую стоимость контракта, вы можете столкнуться с кассовым разрывом. Второй риск - риск некорректного оформления документов. Ошибки в счетах-фактурах при работе с длящимися договорами в новых реалиях 2026 года могут привести к отказам в вычетах со стороны ФНС.

Риски использования ПО без статуса доверенного в закупках

Если ваша компания работает с государственным сектором или крупными корпорациями, имеющими жесткие требования к безопасности, вопрос выбора софта переходит из плоскости "удобно/неудобно" в плоскость "можно/нельзя". С 1 марта 2026 года правила игры в закупках окончательно закрепились: приоритет отдается только "доверенному ПО". Это понятие не равно просто "российскому софту". Чтобы продукт считался доверенным, он должен соответствовать ряду строгих критериев.

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

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

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

Как оценить TCO при покупке и создании системы

TCO (Total Cost of Ownership) или совокупная стоимость владения - это главный показатель, на который должен смотреть собственник. В контексте ИТ это сумма всех затрат на систему за весь жизненный цикл: от идеи и закупки до вывода из эксплуатации. Оценка TCO позволяет сравнить несравнимое: дешевую подписку на готовый сервис и дорогую разработку своего продукта.

При расчете TCO для готового решения учитывайте следующие компоненты:

1. Стоимость лицензий или подписок на начальный период (обычно 3-5 лет).
2. Затраты на внедрение: настройка, импорт данных, обучение персонала.
3. Стоимость интеграций с уже существующим стеком технологий.
4. Расходы на расширение лимитов (пользователи, объем данных, API-запросы).
5. Стоимость поддержки и обновления (если они не включены в подписку).

Для заказной разработки формула TCO выглядит иначе. Здесь на первый план выходят капитальные вложения (CAPEX) и операционные расходы на содержание команды (OPEX). Вам нужно заложить стоимость проектирования архитектуры, разработки MVP, полноценного релиза и последующей эксплуатации. Важно понимать, что стоимость разработки собственного ПО не заканчивается на релизе. Каждый новый функционал, который потребует рынок, будет стоить вам денег в виде часов работы разработчиков.

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

Масштабируемость продукта и зависимость от вендора

Масштабируемость - это способность системы справляться с ростом нагрузки без потери производительности и без кратного увеличения затрат. В готовых решениях масштабируемость обычно "горизонтальная" и автоматическая. Если вам нужно добавить 100 новых менеджеров, вы просто покупаете еще 100 лицензий. Это удобно, но это и есть главная ловушка - зависимость от вендора (Vendor Lock-in).

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

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

Однако здесь кроется обратная зависимость - от ключевых сотрудников. Если архитектуру системы построили два талантливых разработчика, которые затем уволились, оставив после себя "спагетти-код", вы становитесь зависимы от их замены. Стоимость поиска и адаптации новых специалистов, которые разберутся в чужом сложном коде, может быть сопоставима со стоимостью разработки системы с нуля.

Чек-лист для выбора ИТ-решения под задачи бизнеса

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

• Насколько уникальны наши бизнес-процессы? (Если процессы стандартные - берите готовое; если есть "секретный соус" - пишите свое).
• Какой у нас горизонт планирования? (Если нужно "вчера" - готовое решение; если строим фундамент на 5-10 лет - разработка).
• Есть ли у нас ресурсы на поддержку? (Собственный штат или бюджет на аутсорс).
• Соответствует ли решение статусу "доверенного ПО"? (Критично для работы с госсектором).
• Как изменится бюджет с учетом НДС 22% и новых правил по длящимся договорам?
• Какова стоимость владения (TCO) на горизонте 3 лет?
• Насколько сложно будет мигрировать данные, если мы решим сменить решение через 2 года?

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

Типичные ошибки при внедрении автоматизации продаж

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

Вторая ошибка - недооценка человеческого фактора. Менеджеры часто сопротивляются новым системам, потому что они кажутся им инструментом контроля, а не помощи. Если внедрение проходит "сверху вниз" без обучения и объяснения выгод для самих сотрудников, вы получите саботаж. Данные в системе будут заполняться небрежно, и в итоге вы получите "мусор на входе - мусор на выходе", на основе которого невозможно строить аналитику.

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

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

Что запомнить

• В 2026 году учитывайте НДС 22% и новые правила расчета по длящимся договорам при планировании бюджета.
• Выбирайте "доверенное ПО" (реестр + совместимость с отечественным железом), если работаете с госсектором.
• Сравнивайте не цену покупки, а TCO (совокупную стоимость владения) на 3-5 лет.
• Автоматизируйте только отлаженные процессы, иначе вы просто автоматизируете хаос.