Site icon AppTractor

Смета как данные: как выбрать ПО для строительной компании

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

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

Начать с задач компании

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

В каталоге УЦС Информпроект представлены программы для сметы строительства, включая «Адепт:Смета», «ГРАНД-Смета» и Smeta.RU. Чтобы составить список подходящих решений, полезно заранее ответить на несколько вопросов:

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

Проверить расчёты и обмен файлами

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

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

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

Обмен файлами желательно проверить вместе с реальным контрагентом. Выгрузите документ и попросите заказчика или подрядчика открыть его в своей программе. Это даст предметный ответ о совместимости именно вашего рабочего процесса.

Посмотреть за пределы сметы

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

Например, экосистема АДЕПТ включает отдельные решения для смет, BIM, календарного планирования и документооборота. Поэтому при подборе стоит уточнять не только название системы, но и конкретный набор модулей, условия их совместной работы и состав поставки.

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

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

Проверить BIM на изменениях

Если компания работает с информационными моделями зданий, добавьте в пилот путь от элемента модели до сметной позиции. Для линейки АДЕПТ работа со сметой на основе модели заявлена с использованием BIM-модуля. Нужную конфигурацию и ограничения конкретной поставки следует согласовать до покупки.

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

Для условного примера можно изменить перегородки в модели. Задача проверки — проследить, какие объёмы обновились, какие позиции требуют пересмотра и как пользователь подтверждает результат. Такой сценарий помогает оценить управляемость изменений, а не только наглядность 3D-визуализации.

Учесть условия эксплуатации

Функциональный тест стоит дополнить проверкой технических и организационных условий. Желательно подключить к ней ИТ-службу до согласования покупки, а не после установки программы.

Техническую поддержку и консультации по расчётам лучше не смешивать. Восстановление доступа к программе и разбор обоснованности расценки стоит сформулировать как разные задачи и заранее определить ответственных.

Отделить ПО от экспертной проверки

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

В УЦС Информпроект можно заказать экспертное сопровождение смет: составление и проверку документации, а также помощь в работе с замечаниями государственной экспертизы. Это отдельная услуга — её объём и условия нужно согласовать независимо от покупки программы.

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

Завершить выбор коротким пилотом

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

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

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

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

Exit mobile version