Стоимость определяет не название продукта и не количество страниц интерфейса. Главные факторы — глубина процесса, количество ролей, правила, интеграции, качество исходных данных и границы первого рабочего релиза.
«Сколько стоит система?» — нормальный вопрос, но данных для ответа часто мало
Когда бизнес впервые рассматривает автоматизацию, хочется получить диапазон до длинных обсуждений. Это разумно: нет смысла тратить недели на проект, который изначально не укладывается в бюджет.
Проблема в другом. Два запроса с одинаковым названием «внутренний портал» могут отличаться по трудоемкости в несколько раз. Один портал — это список проектов, задачи и документы. Другой должен считать маржу, синхронизироваться с 1С, резервировать оборудование по датам, формировать документы и поддерживать сложную модель доступов.
Поэтому оценка только по названию почти всегда либо завышена «с запасом», либо становится привлекательной цифрой, которая позже растет вместе с уточнением требований.
Фактор 1. Граница первого релиза
Это главный способ управлять бюджетом. Если первый релиз должен решить все процессы компании, стоимость быстро растет не только из-за количества функций. Увеличивается число связей между ними и количество сценариев, которые нужно проверить.
Например, модуль проектов сам по себе может быть сравнительно понятным. Но если он одновременно связан со складом, оплатами, документами и загрузкой сотрудников, изменение статуса проекта начинает влиять сразу на несколько областей.
Поэтому полезнее сформулировать первый результат, а не полный список желаний. Например: «после подтверждения заказа команда должна видеть единый проект, срок, задачи, документы и плановую стоимость». Все, что не требуется для прохождения этого сценария, можно оценить отдельно.
Фактор 2. Количество ролей и правил доступа
Пять экранов для одного владельца проще пяти экранов для десяти ролей. Когда менеджер видит только свои проекты, финансист редактирует оплаты, склад подтверждает выдачу, а руководитель подразделения видит только свою команду, появляется отдельная работа по модели доступа.
Это не декоративная функция. Ошибка в правах может раскрыть финансовую информацию или дать сотруднику возможность изменить то, что он не должен менять.
При оценке важно не просто назвать количество пользователей, а перечислить разные типы ответственности.
Фактор 3. Интеграции
Фраза «связать с 1С» сама по себе почти ничего не говорит о трудоемкости. Нужно понимать, какие данные, в какую сторону и в какой момент передаются.
Одно дело — раз в сутки получить справочник товаров. Другое — синхронизировать платежи, контрагентов и документы с обработкой ошибок и повторной отправкой.
На цену влияют качество API внешнего сервиса, ограничения доступа, документация, необходимость тестового контура и ответственность за ситуацию, когда одна из систем временно недоступна.
Иногда интеграцию выгоднее отложить. На первом этапе сотрудники могут делать один контролируемый экспорт, если это позволяет быстрее проверить основную модель процесса.
Фактор 4. Исходные данные
Перенос базы клиентов из аккуратной таблицы и миграция многолетнего массива, где одно поле заполнялось десятью способами, — разные задачи.
Перед автоматическим импортом данные часто приходится очищать, сопоставлять справочники, объединять дубли и определять, что делать с неполными записями.
Поэтому вопрос «нужно ли переносить историю» стоит решить заранее. Иногда полезнее загрузить только активные проекты и основные справочники, а старую систему оставить в режиме архива.
Фактор 5. Исключения
Основной сценарий обычно занимает меньшую часть обсуждения. Бюджет растет там, где появляются альтернативные ветки: частичная оплата, возврат, перенос даты, несколько юридических лиц, пересчет сметы после согласования, резервирование одного ресурса на части дня.
Не все исключения нужно автоматизировать сразу. Если ситуация случается два раза в год, можно предусмотреть ручное действие администратора вместо отдельного сложного механизма.
Хорошая оценка учитывает частоту исключения и стоимость ручного решения.
Почему «цена за экран» плохо работает
Экран может быть простым списком или интерфейсом, который объединяет вычисления, права, фильтры, историю и несколько внешних источников данных. Количество страниц почти не показывает объем серверной логики и тестирования.
Гораздо точнее оценивать функциональные сценарии. Например: «создать проект из выигранной сделки», «зарезервировать оборудование без пересечения», «сформировать договор из данных проекта».
Как получить адекватную предварительную оценку
Для первой оценки необязательно готовить техническое задание. Достаточно описать:
- Что происходит сейчас.
- Где возникает основная проблема.
- Кто участвует в процессе.
- Какие сервисы и файлы используются.
- Что обязательно должно работать после первого релиза.
Полезно приложить настоящую таблицу, смету или шаблон документа. По ним часто быстрее понять объем, чем по длинному описанию.
После этого проект можно разделить на этапы и отдельно оценить основу и развитие.
Что сравнивать кроме стоимости разработки
Автоматизация имеет смысл только в контексте текущей стоимости проблемы. Посчитайте хотя бы приблизительно:
- сколько часов в месяц уходит на ручную операцию;
- сколько стоит час участников процесса;
- сколько ошибок возникает и каковы их последствия;
- сколько времени собственник тратит на контроль;
- мешает ли текущая схема увеличивать количество заказов без найма еще одного координатора.
Это не означает, что любой процесс обязательно нужно автоматизировать. Иногда расчет показывает обратное: ручное действие дешевле разработки и поддержки. Это тоже хороший результат анализа.
На странице автоматизации бизнес-процессов описан наш подход к выбору первого контура. Если пока трудно сформулировать границы, можно пройти Конструктор и получить предварительную структуру задачи.