Почему трассируемость подбора важнее удобных кнопок

Проект склада-холодильника. Система на чиллерах. Заказчик хочет три варианта компоновки под разные сценарии загрузки. Проектная организация рассылает запросы нескольким производителям.

Первый ответ приходит через два дня — габариты есть, но только в PDF, Revit-модели нет. Второй ответ через четыре дня — модель есть, но расчёт под старые параметры: данные уточнили, а в расчёте не обновили. Третий ответ ещё через день — полный комплект, но заказчик уже скорректировал требования по мощности.

Через неделю на руках: три версии подбора, четыре письма с уточнениями, два Excel-файла с характеристиками. Какой вариант актуальный, под какие исходные данные, что изменилось между версиями?

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

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

Цепочка заказчик — проектировщик — менеджер — техотдел не ломается, она становится прозрачной.

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

Если посчитать потери времени на типовом проекте, согласование оборудования растягивается на недели не потому, что задача сложная, а потому что процесс последовательный: запрос, ответ, уточнение, новый запрос. Сам технический расчёт каждого варианта занимает 20-30 минут, остальное — логистика писем.