Сколько стоит внутренняя система: смета по модулям

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

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

Смета — это база плюс модули

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

Что собираем	Нижняя граница	Срок до рабочей версии
Интеграция систем	от 130 000 ₽	2–4 недели
MVP продукта	от 190 000 ₽	3–5 недель
Личный кабинет клиента	от 230 000 ₽	4–7 недель
Своя CRM	от 250 000 ₽	5–8 недель
B2B-портал оптовых продаж	от 300 000 ₽	6–9 недель
Личный кабинет дилера	от 320 000 ₽	6–9 недель
ERP-модуль и бэк-офис	от 380 000 ₽	6–9 недель
SaaS-платформа	от 450 000 ₽	8–14 недель

Отдельная AI-функция внутри продукта считается своим блоком — от 65 000 ₽. Срок везде указан до первой рабочей версии в проде, а не до «всё готово навсегда»: это разные вещи, и подмена одного другим — самый частый способ сделать смету красивее, чем она есть.

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

Что уже входит в нижнюю границу

Цифра «от» имеет смысл только вместе с тем, что за ней стоит. У меня в нижнюю границу входит не демо, а работающая вещь. Для своей CRM это модель данных под твои сущности, а не под чужой шаблон, права, проверяемые на уровне данных, воронки и статусы под твой процесс, импорт клиентов и истории из текущей системы и одна интеграция. Для ERP-модуля — модель предметной области, снятая с процессов, документы и движения со сторнированием вместо удаления, права «кто проводит, кто отменяет», обмен с бухгалтерией и складом и журнал операций, по которому можно разобраться постфактум.

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

Что двигает цифру вверх

Порядок здесь примерно по силе влияния.

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

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

3. Интеграции. Обмен с 1С, банком, складом или CRM почти всегда недооценивают. Сложность не в передаче данных, а в расхождениях: что делать, когда внешняя система недоступна, ответила ошибкой или прислала то, чего быть не должно.

4. Роли и права. «Админ и все остальные» стоит дёшево. Право на конкретное действие — кто проводит, кто отменяет, кто видит суммы — стоит заметно дороже, зато без него журнал действий не имеет смысла.

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

Про страшные средние: почему им не стоит верить

Здесь стоит остановиться, потому что рынок сметы обсуждает в терминах чужих катастроф.

Самая цитируемая цифра в индустрии — 189% среднего перерасхода из отчёта Standish Group CHAOS 1994 года. Исследователи Simula Research Laboratory (Магне Йоргенсен и Хьетиль Молёккен) разобрали её и показали неприятное: пересчёт по собственному распределению Standish даёт около 89%, то есть внутри одного отчёта две цифры не сходятся между собой. Британское исследование, которое они приводят, даёт средний перерасход 18%.

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

Более взвешенная оценка — из обзора исследований точности оценок (диссертация Хьетиля Молёккена-Эствольда, Университет Осло, 2004): проекты в среднем перерасходуют 30–40% усилий. Это и есть реалистичная поправка, которую стоит держать в голове, а не 189%.

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

Почему дробление дешевле

Это не стилистическое предпочтение, а следствие данных. В исследовании McKinsey совместно с Оксфордским университетом (более 5 400 IT-проектов) есть цифра: каждый дополнительный год проекта увеличивает перерасход в среднем на 15%. Риск растёт от длительности, а не только от сложности.

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

Как выбрать, с какого модуля начинать, если система большая, — разобрано отдельно для ERP и для автоматизации процессов.

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

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

Что сравнивать по пунктам:

• Что входит в нижнюю границу. Деплой, мониторинг, перенос данных, обучение — внутри или «отдельно обсудим»?
• До какого состояния доводится. До рабочей версии в проде или до демо?
• Фиксируются ли цена и срок до начала работ — или это «оценка», которая поплывёт.
• Что с поддержкой после запуска. У меня 2 месяца входят в цену: баги и мелкие правки без доплат.
• Кому принадлежат код и доступы. Репозиторий и сервер должны быть оформлены на твою компанию.
• Кто пишет код. Тот, с кем ты говоришь, или команда, которую ты не увидишь.

Когда смету считать рано

• Не сформулирована задача. Не «нужна CRM», а какую именно ручную работу система забирает.
• Нет владельца правил. Некому ответить «а как правильно» — разработка встанет на первом вопросе.
• Процесс меняется каждый месяц. Сначала он должен устояться.
• Экономия не считается. Если непонятно, что система возвращает, цифра в смете не с чем сравнивать. Как считать — в разборе окупаемости автоматизации.

Опиши задачу — назову вилку и срок до того, как что-то начнётся, и скажу прямо, если своя разработка тебе не нужна. Что я делаю и на каких условиях — услуги.

Источники

Проверено 17.08.2026.

• M. Jørgensen, K. Moløkken, Simula Research Laboratory, «How Large Are Software Cost Overruns? A Review of the 1994 CHAOS Report»: отчёт Standish Group 1994 года заявляет 189% среднего перерасхода; пересчёт по собственному распределению Standish даёт около 89%; приводимое британское исследование — 18%; пример проекта с перерасходом 146%, признанного приемлемым на фоне завышенного ориентира. simula.no
• K. J. Moløkken-Østvold, «Effort and Schedule Estimation of Software Development Projects», диссертация, Университет Осло, август 2004: проекты в среднем перерасходуют 30–40% усилий; гибкие и инкрементальные методы уменьшают величину перерасхода; цена не должна быть единственным критерием выбора подрядчика. simula.no
• McKinsey & Company совместно с BT Centre for Major Programme Management, University of Oxford (2012), более 5 400 IT-проектов: каждый дополнительный год проекта добавляет к перерасходу в среднем 15%. Страница McKinsey не открывается автоматически, цифра сверена по разбору neocode.com.
• Вилки, сроки и список того, что двигает смету, — мои собственные, из src/lib/cost/data.ts; в текст они не вписаны руками, а рендерятся из датасета, поэтому не могут разойтись с разделом цен.