Сколько стоит разработка корпоративного приложения

Вопрос о цене корпоративного приложения решается не сметой, а расчётом владения. Разбираем, как посчитать три года вперёд и в каком виде это защищать.

Коротко

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

Почему на этот вопрос нет короткого ответа

Формулировка «сколько стоит корпоративное приложение» устроена так же, как вопрос о стоимости строительства без описания дома. Кабинет, в котором контрагент смотрит три документа, и кабинет с заказами, лимитами, отсрочками и обменом с учётной системой называются одинаково, а трудозатраты между ними различаются в разы.

Поэтому диапазона в этой статье нет. Цифра, приведённая без описания задачи, создаёт ложную уверенность и мешает сравнивать предложения — по ней невозможно понять, что именно вошло в объём.

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

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

Четыре способа получить систему и что вы покупаете

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

Способ

Что покупаете

Форма расхода

Что остаётся при остановке

Доработка учётной системы

Часы подрядчика по 1С

Разовый, повторяется при каждой доработке

Функция внутри ядра, усложнённого обновления

Готовый продукт

Лицензию и настройку

Регулярный платёж плюс внедрение

Ничего: работа прекращается вместе с подпиской

Заказная разработка

Систему в собственность

Крупный разовый, потом поддержка

Код, данные и необходимость их сопровождать

Сборка на платформе

Лицензию платформы и работу по сборке

Умеренный разовый плюс регулярная лицензия

Приложение в платформе и выгружаемые данные


Из последней колонки следует практический вопрос, который стоит задать до выбора. Что происходит с системой, если вы перестанете платить или прекратите проект. У готового продукта ответ обычно самый жёсткий, у заказной разработки самый мягкий, и это тоже часть цены.

Три бюджета, в которые попадает корпоративное приложение

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

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

Операционные затраты. Подписки, поддержка, хостинг, доработки по мере необходимости. Ложатся на бюджет подразделения, согласуются проще, но заметны каждый месяц и суммируются незаметно.

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

Отсюда нередкий сюжет. Решение, которое дешевле по сумме, оказывается неприемлемым, потому что попадает не в тот бюджет — например, требует капитальных затрат в год, когда их не согласуют. И наоборот, дороже по трём годам, но в операционных расходах, проходит легче. Спросить об этом стоит до того, как выбирать способ.
ЧТО ВЫ ПОКУПАЕТЕ

Лицензия платформы и работа по сборке

NolanИИ-ассистент, который собирает приложение на low-code платформе. Он не заменяет платформу, а работает поверх неё.

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

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

  • личные кабинеты, заявки, согласования, реестры и внутренние порталы
  • заявленный эффект — в 10–50 раз меньше трудозатрат на типовое решение

Что оплачивается один раз, а что каждый месяц

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

Разово

Регулярно

Разбор задачи и описание процесса

Лицензия платформы или подписка на продукт

Сборка или разработка

Поддержка и обновления

Настройка интеграций

Плата за пользователей, если она есть

Миграция и чистка данных

Хостинг, если приложение в вашем контуре

Обучение сотрудников на старте

Изменения вслед за регламентом

Приёмка и пилот

Обучение новых сотрудников


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

Лицензии «за пользователя»: как считать при росте штата

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

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

Что проверить по каждой схеме, прежде чем сравнивать.

  • Кто считается пользователем. Только те, кто заходит регулярно, или все заведённые учётные записи. Разница на большой компании кратная.
  • Считаются ли внешние. Контрагенты в кабинете, подрядчики, соискатели. В некоторых моделях они стоят как сотрудники, и кабинет для дилеров становится самой дорогой частью.
  • Что происходит при сезонном росте. Если летом штат удваивается, платите вы за пик или за среднее.
  • Как считается снижение. Уменьшить число лицензий обычно сложнее, чем увеличить, и условия отличаются.

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

Что спросить про лицензии до подписания

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

  1. Что входит в базовую лицензию, а что продаётся отдельно. Интеграции, отчётность, мобильный доступ и электронная подпись нередко оказываются дополнительными модулями.
  2. Как меняется цена при продлении. Условия первого года и второго часто различаются, и это стоит увидеть в договоре, а не в обещании.
  3. Есть ли минимальный пакет. Ситуация, когда вам нужно двадцать лицензий, а минимум пятьдесят, встречается регулярно.
  4. Что происходит с приложением при паузе в оплате. Останавливается работа, закрывается доступ или приложение переходит в режим только для чтения.
  5. Входят ли обновления платформы. И обязательны ли они — иногда обновление, которое вы не заказывали, требует доработки вашего приложения.
  6. Как считается тестовая среда. Отдельная копия для проверки изменений — нормальная практика, и она может тарифицироваться как рабочая.
  7. Что с данными после расторжения. Срок, в течение которого их можно забрать, и форма выгрузки.

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

Стоимость владения за три года

Расчёт, к которому сводится вопрос из заголовка. Он не требует точных цифр от вендора — достаточно структуры и собственных данных.

Составляющая

Как оценить

Что её двигает

Создание

Смета исполнителя или стоимость сборки

Число сущностей, ролей и интеграций

Лицензии за три года

Модель лицензирования × прогноз пользователей

Рост штата и внешние пользователи

Поддержка и инфраструктура

Годовая сумма × три

Требования к контуру и доступности

Изменения

Число изменений в год × стоимость правки × три

Как часто меняется регламент

Время сотрудников

Часы на приёмку, обучение, сопровождение

Число пользователей и текучесть

Выход из решения

Что придётся сделать, если решите уйти

Форма, в которой отдаются данные


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

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

Для внешнего веб-продукта смета раскладывается по другим строкам: разбор сметы на веб-приложение.

Как расход растёт вместе с компанией

Расчёт, сделанный на сегодняшнем состоянии, описывает первый год. Дальше меняется компания, и вместе с ней растут разные части расхода — у каждого способа по-своему.

Что происходит

Что дорожает при лицензии за пользователя

Что дорожает при своей разработке

Штат вырос на треть

Лицензии — сразу и пропорционально

Ничего, кроме поддержки

Открылось второе подразделение

Лицензии плюс, возможно, новые роли

Настройка ролей и данных

Подключили внешних контрагентов

Лицензии, если они считаются пользователями

Разработка кабинета

Регламент изменился

Только работа по правке

Работа по правке плюс релиз

Появилась вторая похожая задача

Обычно в рамках той же платформы

Новый проект почти с нуля


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

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

Скрытые статьи, которые не попадают в расчёт

Четыре расхода, которые оплачиваются рабочим временем сотрудников и поэтому не видны в смете.

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

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

Обучение и сопровождение внутри отдела. Первые недели кто-то отвечает на вопросы коллег. Если этого человека не назвать, им станет самый отзывчивый сотрудник, и это скажется на его основной работе.

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

Все четыре стоит назвать в расчёте отдельной строкой, даже если они не превращаются в платёж. Так решение выглядит честнее, а на защите бюджета исчезает вопрос «а что ещё понадобится».

Стоимость оставить всё как есть

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

Что складывается в текущую стоимость процесса.

  • Ручной труд. Часы на перенос данных, сверку, сбор статусов, подготовку отчётов по запросу. Считается по числу случаев в год и времени участников.
  • Ошибки и переделки. Доля случаев, которые проходят дважды, и стоимость каждого повторного прохода.
  • Срок. Задержка процесса, если она имеет цену — упущенная скидка, просроченный договор, простой оборудования.
  • Риск. Ситуации, которые пока не наступили, но стоят денег при наступлении. Проверка, утечка, потеря истории решений.
  • Стоимость непрозрачности. Время руководителей на выяснение, где стоит работа.

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

Одна оговорка про честность расчёта. Освободившиеся часы редко превращаются в сокращение расходов на самом деле — люди остаются и занимаются другим. Поэтому в защите бюджета корректнее говорить о том, что эти часы перестанут уходить на перенос данных и сверку, и называть, куда они денутся. Расчёт, обещающий прямую экономию фонда оплаты труда, на защите обычно разбирают первым и не в вашу пользу.
СТОИМОСТЬ ИЗМЕНЕНИЙ

Правка процесса без релиза и без сметы

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

У Nolan изменение идёт тем же путём, что первая сборка. Вы описываете правку в чате, ассистент вносит её в описание приложения и проверяет сборку, а разворачивает результат платформа. Форма, поле, роль, маршрут — без нового релиза и без отдельной сметы на доработку.

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

  • изменение не ждёт очереди в ИТ-отделе и не оформляется допником
  • итоговое ТЗ и документация на собранное приложение

Что делать, если сумма не проходит

Отказ по бюджету редко означает «никогда» — чаще он означает «не в этом виде». Четыре хода, которые работают, и все они меняют не сумму, а её форму.

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

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

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

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

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

Как защитить бюджет: язык финансового директора

Расчёт, сделанный в терминах ИТ, на защите работает плохо. Перевод на финансовый язык занимает полчаса и меняет исход разговора.

Что заменить в презентации.

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

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

Кто подписывает и что для него важно

Решение по внутренней системе редко принимает один человек. Аргументы приходится готовить под каждого, и они разные.

Кто

Что для него главное

Чем убеждать

Владелец процесса

Чтобы стало работать быстрее и без ручного труда

Сокращение цикла, освобождённые часы

Финансовый директор

Форма расхода и предсказуемость

Три года владения, раскладка по бюджетам

ИТ-директор

Кто это поддерживает и как встаёт в контур

Размещение, доступы, кто вносит изменения

Безопасность

Данные, доступы, соответствие требованиям

Место хранения, роли, журнал действий

Собственник

Отдача и риск

Стоимость оставить как есть, срок до результата


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

Когда дешевле купить готовое

Разработка и сборка не всегда правильный ответ, и проверка занимает полчаса.

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

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

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

Как понять, что расчёт неполный

Три признака, по которым видно, что оценку придётся переделывать. Проверять стоит свой расчёт, а не только присланный исполнителем.

  1. В графе «ничего не делать» стоит ноль. Значит, текущая стоимость процесса не посчитана, и сравнивать варианты не с чем.
  2. Нет строки на изменения. Регламенты меняются у всех, и расчёт без этой строки описывает первый год, а не три.
  3. Не указано число пользователей на конец периода. Без него любая модель лицензирования считается по сегодняшнему дню и занижает результат.

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

Типичные ошибки в расчёте

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

Покажем Nolan на вашем процессе

Свяжемся в течение одного рабочего дня. Без спама.

Опишите задачу — мы разберём ваш процесс и подготовим демо-приложение на его основе

1
Вы оставляете заявку и кратко описываете задачу
2
Мы разбираем процесс или ЧТЗ
3
Показываем демо работающего приложения
Наши продукты:
Программа для ЭВМ «Nolan»
Программа для ЭВМ «CDP.Light»
Программа для ЭВМ «Корпоративный портал»

Компания «Технологии возврата»

3 года занимается разработкой и развитием ИИ