От чего зависит стоимость первой версии
Допустим, вы как заказчик собираете бюджет приложения для строительной компании. Прорабу нужен журнал замечаний, снабжению нужны заявки на материалы, директору нужен отчёт по объектам. Если оценивать всё одним пунктом, предложения подрядчиков окажутся несравнимыми: один включит мобильные формы, другой добавит офисную панель, обмен с 1С и работу без интернета.
Мы предлагаем сначала выбрать процесс, в котором понятны потеря, ответственный и проверяемый результат. Затем разложить его на роли, данные, интеграции и проверки. Так вы получите состав первой версии, по которому можно запросить смету и увидеть, какие изменения увеличат бюджет. Ниже: матрица выбора процесса, карта работ и краткий бриф для оценки.
Для оценки нужны границы: один процесс от действия на объекте до решения в офисе, перечень пользователей и устройств, операции без связи, направления обмена и условия приёмки. После проверки этих вводных можно согласовать цену и срок. Лицензии, сервер, хранение файлов и сопровождение учитывают отдельно.
Как выбрать процесс для первого бюджета
Возьмите примеры недавних операций: замечание по работе, заявку на материал, отчёт заказчику. Для каждой запишите, где сотрудник повторно вводит данные, какое решение задерживается и кто может подтвердить результат. Внутренняя система управления стройкой и CRM для продаж имеют разных пользователей и правила. Объединение их в первую версию добавит отдельные процессы в смету.
| Процесс | Проверяемый результат | Что влияет на смету |
|---|---|---|
| Замечания и стройконтроль | Замечание связано с участком; назначенный исполнитель прислал исправление; проверяющий принял его или вернул с причиной | Версии планов, вложения, права подрядчиков, работа без связи, история исправлений |
| Заявки на материалы | Снабженец получил заявку, подтвердил количество и срок; прораб видит решение и отмечает получение | Справочник, единицы измерения, согласование, обмен с 1С, частичная поставка и замены |
| Отчёт заказчику | Заказчик видит разрешённый отчёт по своему объекту после проверки сотрудником компании | Внешние аккаунты, границы доступа, состав публикуемых данных, вопросы и согласования |
| Продажи в строительной CRM | Менеджер ведёт обращение и следующий контакт; руководитель видит движение сделки | Действующая CRM, источники обращений, перенос базы, права, специализированный модуль |
Например, для пилота журнала замечаний руководитель участка уже назначает исполнителя и принимает исправление. Если у заявок на материалы ещё нет общего справочника и согласованного порядка подтверждения, сначала потребуется привести данные и правила в порядок. Мы предложим сравнить оба процесса по ожидаемой пользе и подготовительной работе, затем выбрать тот, который компания готова принять.
У первого процесса должны быть ответственный со стороны бизнеса, доступные исходные данные и участники проверки. В статье о MVP приложения прораба подробно разбираем задания на смену, факт работ, материалы и итог. Здесь выбираем, какой процесс включить в первый бюджет.
Что даёт опыт связи приложения с учётной системой
В продуктовом ритейле «Бакаев» мы связали мобильный магазин, админ-панель и 1С через сервер синхронизации. Помогли перенести локальную 1С в облако и настроили обмен через API: согласованный способ передачи данных между системами.
Сотрудник меняет фотографию товара в админ-панели, и изменение отражается в 1С. Заказ через приложение меняет остатки в админке и учётной системе. Изменения из 1С доходят до приложения. За привычным действием пользователя стоит работа нескольких частей системы; эту связь нужно учитывать в составе разработки.
Реальный проект 13FOX · продуктовый ритейл
Каталог, админ-панель и 1С связаны
В нашей панели сотрудники управляют товарами. Сервер синхронизации передаёт изменения между приложением, панелью и учётной системой.
В Malling мы разработали инструмент CRM-коммуникаций рядом с Битрикс24 и amoCRM. Для компании, у которой уже есть CRM, мы предлагаем сначала проверить возможность отдельного модуля. Это позволяет оценить нужный процесс с учётом существующей системы и сравнить его с вариантом полной замены.
Карта сметы: у каждой строки свой результат
Стоимость разработки приложения для строительной компании складывается из работ над выбранным процессом. Число экранов помогает оценить интерфейс, но одинаковая форма замечания может работать только при связи либо сохранять фото на устройстве, отправлять их позднее и показывать ошибки. Во втором варианте в смете появятся дополнительные правила и проверки.
| Строка сметы | Что получаем | Уточнение до оценки |
|---|---|---|
| Разбор процесса и прототип | Согласованные поля, переходы, роли и пример работы будущих форм | Кто принимает результат; какие исключения обязательны |
| Приложение сотрудника | Ввод факта, просмотр задания, фото и понятное состояние записи | Платформы, модели телефонов, объём файлов, способы установки |
| Офисная часть и сервер | Назначение, проверка, возврат, доступ по объектам и история изменений | Существующая панель или новая; подрядчики и внешние пользователи |
| Работа без связи | Заранее загруженные данные, локальная запись, очередь передачи и обработка ошибок | Какие действия доступны; какие данные должны сохраниться при перезапуске |
| Интеграции и перенос данных | Согласованный обмен, сопоставление записей и контрольная сверка | Конфигурация и версия 1С, объекты, направления, права, качество исходной базы |
| Проверки, запуск и передача | Принятый сценарий на устройствах, инструкция сотрудникам, порядок восстановления | Тестовые данные, участники пилота, резервные копии, сопровождение |
Например, для заявок на материалы попросите подрядчика указать, кто подтверждает количество, какие данные получит снабженец и как проверят частичную поставку. Рядом с каждой строкой укажите объём работы, что входит в неё и как проверить результат. Исследование неизвестного обмена стоит выделить отдельно: его результатом будут проверенные операции и уточнённая оценка реализации. Так финансовый директор увидит, за что платит на каждом этапе и какое решение потребуется от компании.
В отдельном перечне зафиксируйте расходы после запуска: лицензии используемых систем, сервер, хранение фото, резервные копии, обновления приложения и сопровождение обмена. Уточните, какие платежи входят в предложение, на какой период и как меняются при росте числа пользователей или файлов.
Как офлайн и 1С меняют объём разработки
Допустим, на объекте связь есть в бытовке, а на рабочем участке пропадает. Для первого релиза можно загрузить назначенные задания заранее и разрешить создание замечания с фото на телефоне. Подтверждение руководителя придёт после передачи данных в офис. Этот набор отличается от требования редактировать без связи все объекты, справочники и решения других сотрудников.
В руководстве Android по офлайн-архитектуре чтение локальных данных, запись и синхронизация рассматриваются отдельно. Для выбранного процесса мы предложим состояния «сохранено на телефоне», «получено сервером» и «принято проверяющим». Если устройство потеряно до передачи, локальные записи могут быть утрачены; это условие нужно учесть в правилах работы.
В оценку включим проверку повторной отправки, частично загруженного фото и правки задания в офисе, пока телефон без связи. Заранее согласуем, что увидит сотрудник при конфликте и кто его решит. Работа в фоне также требует испытания на выбранных устройствах: появление интернета само по себе не задаёт точный момент передачи.
Для 1С сначала укажите, что именно должно пройти между системами. Загрузка справочника материалов, передача заявки и создание учётного документа имеют разный состав. Например, в пилоте прораб отправляет факт получения, а сотрудник учёта проверяет его перед отражением в базе. Автоматическое списание потребует отдельного правила и проверки.
Документация 1С:Фреш по OData описывает программное чтение и запись данных, доступные объекты и ограничения прав. Для вашей базы мы проверим конфигурацию, размещение и разрешённые операции. В смете нужно закрепить источник справочника, направление каждого изменения, ответственного за исправление ошибки и сверку результата.
Пример границ первой версии стройконтроля
Рассмотрим условный пилот на одном объекте. Цель: провести замечание от записи на участке до подтверждённого исправления. Руководитель назначает исполнителя; исполнитель прикладывает результат; проверяющий принимает работу или возвращает её с причиной. Это предлагаемый состав, который нужно сверить с процессом вашей компании.
- Включаем: объекты и участки, список замечаний, ответственного, срок по заданию, фото, статусы, возврат с причиной и историю изменения.
- Без связи: просмотр заранее загруженных заданий и создание новых записей с вложениями. Решения проверяющего сотрудник получает после обмена.
- В офисе: назначение, фильтры по участку и исполнителю, проверка исправления, список записей с ошибкой передачи.
- Учёт: на этом этапе замечания ведём в приложении; обмен с 1С включаем только при конкретной потребности процесса.
- Следующий этап: версии чертежей, закупки, кадровый учёт и кабинет заказчика оцениваем отдельными задачами.
Если компания ведёт нормативную исполнительную документацию, нужно отдельно определить формы, порядок согласования и требования к подписанию. Внутреннее принятие замечания в приложении само по себе не задаёт юридический статус документа.
Перед собственной разработкой проведите этот же сценарий в готовой системе. Проверьте права подрядчиков, работу без связи и выгрузку данных. Когда процесс проходит штатными настройками, имеет смысл сравнить стоимость настройки и лицензий с разработкой. Если остаётся важный разрыв, мы предложим оценить доработку или отдельный модуль.
Как сравнить предложения по бюджету и сроку
Передайте подрядчикам одинаковый бриф и пример операции. Попросите разделить подготовку, реализацию, проверки и запуск, а также перечислить обязательные действия вашей команды. Срок зависит и от готовности справочников, тестового доступа к 1С, принятия прототипа и участия сотрудников в пилоте.
Например, предложение с офисной проверкой и журналом ошибок можно сравнивать с другим только после уточнения, что входит в каждое из них. В строке «интеграция» должны совпадать объекты и направления. В строке «офлайн»: доступные действия и проверяемые сбои. Указанная дата должна относиться к одному результату: демонстрации, принятой версии или запуску для сотрудников.
- Зафиксируйте состав версии и исключения вместе с оценкой.
- Назовите зависимости: данные, доступы, решения и ответственные.
- Уточните, как оплачивается проверка доступности обмена и когда пересматривается оценка.
- Согласуйте порядок оценки новых пожеланий до включения их в работу.
- Опишите передачу кода, доступов и инструкций, условия поддержки и регулярные расходы.
Уменьшать бюджет удобнее через конкретную границу: например, оставить один тип замечаний или отложить внешние аккаунты. Проверки выбранного процесса останутся в смете: по ним компания примет работу. Полезно заранее назвать также условие расширения: после успешного пилота подключаем новые объекты или следующий процесс.
Краткий бриф для оценки
Начните с обезличенного документа и описания одной операции. Для первого обсуждения не нужны пароли, клиентские данные или доступ к рабочей базе. Названия систем, примеры полей и желаемый результат помогут определить, что потребуется проверить дальше.
- Процесс и цель: что запускает операцию, кто её завершает, какое решение задерживается сейчас.
- Пример: замечание, заявка на материал или отчёт с полями и состояниями.
- Участники: прораб, подрядчик, снабженец, проверяющий, директор; какие объекты и сведения видит каждый.
- Масштаб: объекты и сотрудники пилота, ожидаемое число записей и вложений, дальнейшее расширение.
- Устройства и связь: телефоны, платформы, действия без интернета, требуемое хранение на устройстве.
- Системы: CRM, конфигурация и версия 1С, размещение базы, нужные данные и направления обмена.
- Бюджет и запуск: допустимый бюджет, нужная дата, подготовленные данные, ответственный за пилот и будущую поддержку.
На первом обсуждении мы сравним возможные границы версии, отметим зависимости и составим перечень работ для оценки. Если неизвестна доступность нужной операции в 1С, вынесем её проверку в подготовительный этап с отдельным результатом.
Вопросы перед оценкой
Какой бюджет нужен для приложения прораба с офлайн и 1С?
Бюджет можно оценить после определения действий без связи, ролей, устройств и обмена. Чтение справочника из 1С и создание документов требуют разных работ. Начните с одного процесса, укажите результат в офисе и сбои, которые нужно проверить; по этому составу запросите смету.
Можно ли сразу оценить строительную CRM целиком?
Можно подготовить общую карту процессов, но для согласования разработки потребуется разделить продажи, работу на объекте, снабжение и отчётность. У каждого процесса свои пользователи, данные и приёмка. Сначала проверьте, что уже закрывает действующая CRM и какой модуль нужен отдельно.
Нужно ли готовое техническое задание?
Для первого обсуждения достаточно примера операции, ролей и текущих систем. Мы предлагаем сначала согласовать поля, переходы, исключения и проверки, затем оформить задание на выбранную версию. Для оценки неизвестной интеграции может потребоваться техническая проверка.
Источники технических условий
Документы проверены 7 октября 2026 года: Android Developers: работа без связи; 1С:Фреш: доступ через OData. Для конкретной сметы проверим нужные операции в вашей конфигурации и поведение выбранных устройств.
Получить состав первой версии
Оставьте удобный контакт. На обсуждении покажите обезличенный пример процесса, роли и текущие CRM/1С. Мы разберём границы, обмен и работу без связи. Результат первого обсуждения: состав первой версии и список уточнений для сметы разработки.