Допустим, бюро подписало договор на проектирование. Менеджер закрывает сделку, а главному инженеру проекта, ГИПу, ещё нужно распределить разделы, проверить загрузку и подготовить выдачу. Если эти сведения живут в разных таблицах, руководитель вручную сопоставляет обещанный срок, готовность работ и оплату.
Мы предлагаем начинать выбор системы с этой передачи в работу. CRM хранит отношения с заказчиком и коммерческие договорённости. Проектный модуль связывает их со стадиями, заданиями и людьми. Среда общих данных, CDE, помогает управлять документами, версиями и доступом. Ниже разберём границы этих частей, дадим карту выбора и покажем, какие результаты должны входить в смету разработки.
Карта выбора · Состав сметы · Проверка проекта
Иллюстрация сценария
Договор, работа, выдача
Какая часть задачи относится к CRM
В CRM удобно вести запрос, контакты, предложение и историю переговоров. После договора появляются другие вопросы: какой раздел готовит подразделение, от кого оно ждёт исходные данные, сколько работы осталось и что именно передано заказчику. Эти записи стоит связать со сделкой, сохранив собственные статусы и ответственных.
Проектный модуль, или PM-модуль, нужен для планирования и контроля работ. Среда общих данных (CDE) задаёт порядок хранения, проверки и обмена проектной информацией. Она может включать несколько инструментов. В руководстве UK BIM Framework, Part C выбор технологии следует за определением процесса. Для бюро это полезный порядок: сначала согласовать путь документа, затем выбирать хранилище и интеграцию.
Например, если команда уже работает в подходящем хранилище, CRM может показывать идентификатор комплекта, его статус и ссылку на конкретную версию. Просмотр моделей, совместная работа с чертежами и инженерные проверки останутся в профильных инструментах. Перенос этих функций в новую систему потребует отдельного обоснования и оценки.
Начните с разрыва в процессе. Если теряются запросы, проверьте CRM. Если трудно планировать специалистов, изучите проектный модуль. Если команда путает версии и состав выдачи, разберите правила документов и возможности хранилища.
Как мы дополняли готовую CRM
В Malling мы разработали отдельный инструмент коммуникаций рядом с Битрикс24 и amoCRM. Он использует данные контактов и сделок из существующей CRM; в своём интерфейсе команда работает с рассылками и клиентскими данными. Такой архитектурный путь стоит проверить и для бюро: оставить подходящую основу и добавить рабочий модуль под конкретную задачу.
Наш проект Malling
Модуль рядом с CRM
Договор, проект и стадия: что хранить отдельно
Одна длинная воронка быстро смешивает переговоры, работу инженера и ожидание оплаты. Мы предлагаем начать модель с отдельных записей и проверить их связи на вашем договоре.
Договор хранит согласованный объём, сроки, результаты и условия расчётов. Проект объединяет работы по объекту или задаче бюро. Стадия задаёт часть результата со своим составом, сроком и ответственным. Названия стадий берём из вида проектирования, договора и требований заказчика. Для одного бюро подходят одни шаблоны, для другого потребуется несколько.
Связь договора и проекта тоже проверяем: рамочный договор может охватывать несколько проектов, а по одному проекту могут действовать разные договоры и дополнительные соглашения. Жёсткое правило «одной сделке соответствует один проект» нужно подтвердить до настройки автоматического создания записей.
Внутри стадии будут задания подразделениям и исполнителям; результатом станут комплекты документов. У комплекта появятся версии; выдача сохранит выбранный состав и адресатов. Такая модель позволяет открыть договор и проследить его до результата, который получил заказчик.
Готовая платформа уже может поддерживать часть этой модели. Например, смарт-процессы Битрикс24 позволяют создавать дополнительные сущности, поля, права и связи. По документации, проверенной 3 октября 2026 года, функция доступна не на всех тарифах. На выбранном тарифе нужно показать именно ваш договор и проект, включая повторные выдачи и изменения.
Загрузка и изменения: какие данные нужны ГИПу
Количество открытых задач мало говорит о доступности инженера. Для планирования нужны оценка трудоёмкости, рабочий календарь и уже согласованные назначения по другим проектам. Руководитель должен видеть, кому можно передать раздел и как новое задание повлияет на действующие сроки.
Например, исполнитель может ждать исходные данные по одному разделу и работать над другим. В системе полезно разделить статус задания, блокирующую причину и плановую занятость. Тогда ожидание не исчезнет в общем статусе «в работе», а перераспределение часов будет видно в плане.
Если бюро пока не оценивает трудозатраты, мы предложим начать с распределения работы по периодам и простого учёта оставшегося объёма. Для более надёжного прогноза сначала согласуем методику, проверим исходные данные и сопоставим план с фактической работой. Автоматический процент готовности по числу закрытых задач может вводить в заблуждение: задачи отличаются по размеру и зависимости от других разделов.
Просьба заказчика меняет план
Допустим, заказчик просит изменить планировку после внутренней проверки комплекта. Мы предложим завести запись изменения: основание, затронутые разделы, ответственный, оценка труда и влияние на сроки. ГИП увидит, какие задания вернутся в работу, а руководитель поймёт, какое договорное решение требуется.
Часть исправлений может входить в согласованный объём. Для дополнительных работ потребуется отдельное согласование по правилам договора. До этого запись изменения хранит предложение и оценку; после решения обновляет план и связывается с нужным соглашением. Платёжные условия меняются только на соответствующем основании.
Выдача должна ссылаться на определённые версии
Ссылка на папку удобна для работы команды, но её содержимое меняется. Чтобы восстановить состав выдачи, нужна запись: какой комплект, какие версии файлов, кому, когда и каким способом передали. Для исправленного комплекта мы предложим сохранять новую выдачу со ссылкой на предыдущую.
Официальная документация Autodesk разделяет историю версий и передачу документов. В истории версий можно выбрать предыдущую и назначить её текущей; в передаче фиксируются состав, версии и получатели. Это объясняет, почему для журнала выдачи важен точный снимок состава на момент отправки. Возможности вашего хранилища и его интерфейса обмена проверим отдельно.
Выдача, подтверждение получения и приёмка работ имеют разные условия. Закрытая задача или скачанный PDF сами по себе не устанавливают договорную приёмку. В системе мы предложим отдельные поля и события для каждого шага, согласованные с договором и порядком работы бюро.
Связь документов с контекстом заявки мы уже делали в CentreVisa: клиент видит статус обращения и обсуждает документы в чате по нему. Для проектного бюро к такому контексту добавим модель комплектов, версий и выдач, которую сначала проверим с ГИПом.
Как выбрать готовую систему, модуль или разработку
Попросите каждого подрядчика пройти один и тот же маршрут: запрос, договор, стадия, назначение специалиста, изменение и выдача. Сравнивать станет проще: вы увидите, какие операции работают штатно, какие требуют настройки и где сотруднику приходится возвращаться в таблицу.
| Вариант | Когда проверять | Что показать на вашем примере |
|---|---|---|
| Настройка готовой платформы | Типовые стадии, задания и права укладываются в её возможности. | Связь договора с проектом, шаблон стадии, загрузку и точную запись выдачи. Отдельно укажите тариф и ограничения. |
| Отдельный проектный модуль | CRM подходит продажам; планирование или выдача требуют особого процесса. | Переход из CRM в проект, владельцев полей, обмен статусами, работу при сбое связи. |
| Собственная система | Особые связи, роли и правила определяют большинство ежедневных операций. | Целый маршрут, миграцию, экспорт данных, поддержку и порядок передачи системы вашей команде. |
Во всех трёх вариантах можно сохранить действующее хранилище, если оно поддерживает нужные версии, права и операции обмена. Создание собственной CDE добавляет отдельную задачу: управление информацией, доступами, состояниями документов и историей. Её полезно оценивать отдельной строкой, когда существующие инструменты не закрывают проверенный сценарий.
Общий выбор CRM для продаж мы подробнее разбираем в статье о внедрении и разработке CRM. В бюро решающий тест состоит в том, чтобы проследить коммерческое обязательство до работы специалистов и выданной версии.
Из чего складывается стоимость CRM для бюро
В оценке нужно разделить два бюджета. Бюджет проектирования описывает труд бюро и стоимость стадий для заказчика. Смета разработки системы описывает обследование, настройку или программирование, обмен данными, перенос и запуск. Ниже перечислены строки второй сметы и результаты, по которым можно сравнивать предложения.
| Работы | Проверяемый результат | Что влияет на объём |
|---|---|---|
| Обследование и модель | Карта процесса, сущности, связи, роли и исключения. | Виды договоров, проектов и стадий; правила изменений. |
| CRM и проектная часть | Карточки, шаблоны заданий, план сроков и загрузки. | Зависимости разделов, трудоёмкость, календари, отчёты. |
| Комплекты и выдача | Связь конкретных версий с передачей и адресатами. | Хранилище, согласование, возвраты и повторные выдачи. |
| Обмен и перенос | Сопоставление записей, журнал ошибок, контрольная сверка. | CRM, 1С, почта, интерфейс обмена хранилища и качество архива. |
| Пилот и передача | Проверенный маршрут, инструкции, обучение и доступы. | Число ролей, объём переноса, сценарии исключений. |
| Эксплуатация | Правила поддержки, резервирования и обновлений. | Лицензии, размещение, хранение файлов, интеграции. |
Попросите выделить лицензии и регулярные расходы, работы первого запуска и дальнейшее развитие. Для бюро из Москвы, Санкт-Петербурга или другого города в оценке также стоит уточнить формат встреч, обучения и поддержки команды. Проверяйте, какие функции и ограничения входят в выбранную поставку, кто оплачивает обновления и кто отвечает за восстановление.
Для интеграции нужны направления и владельцы данных
Например, 1С может передавать в проектный модуль учтённые платежи, а модуль будет показывать их рядом с договором и планом расчётов. Плановый платёж, выставленный счёт и поступившие деньги сохраняем как разные записи. Конкретный обмен зависит от конфигурации, версии, размещения и доступных интерфейсов 1С.
Почту будем связывать с запросом или проектом по согласованным правилам; для хранилища определим идентификатор документа, версию и права. Идентификатор позволит обеим системам узнавать одну и ту же запись. На каждую интеграцию в оценке должны быть сопоставление данных, повтор после сбоя и сверка. Если ответ на передачу потерялся, сотруднику нужен понятный результат проверки и способ продолжить работу без повторного создания той же записи.
Один проект для проверки решения
Для пилота выберем типовой проект с договором, несколькими заданиями и реальной выдачей. Директору, ГИПу, исполнителю и сотруднику учёта нужен свой рабочий маршрут. На обезличенных данных можно заранее пройти следующие действия и записать ожидаемый результат.
- Передать запрос в проект. Сохранить договорные условия и связи; повторное действие не создаёт лишний проект.
- Спланировать стадию. Назначить подразделение, исполнителя, срок и оценку работы; проверить пересечение с другими назначениями.
- Внести изменение. Увидеть затронутые задания, пересмотр срока и основание для договорного решения.
- Выдать комплект. Зафиксировать версии, состав и адресата; затем найти ту же запись после появления новых рабочих файлов.
- Сверить деньги и права. Проверить платёж по договору; убедиться, что исполнитель видит нужные файлы и задания в пределах своей роли.
- Разобрать сбой. Временно прервать обмен в тестовом контуре, проверить сообщение об ошибке, повтор и итоговую сверку.
После пилота останется перечень подтверждённых функций и открытых вопросов: какие шаблоны можно переносить на другие проекты, какие договоры требуют другой модели, сколько истории переносить. Это даёт основу для следующего этапа и для приёмки работы подрядчика.
Что подготовить к разговору. Один обезличенный договор, названия стадий, пример плана загрузки, состав выданного комплекта и список действующих систем. Покажите также один возврат на исправление: он часто проясняет правила лучше, чем обычный маршрут.
Вопросы перед заказом
Можно ли оставить существующую CRM?
Да, если она подходит продажам и позволяет связать договор с проектной частью. Мы предложим проверить её сущности, права и интерфейсы обмена на одном маршруте. Специальное планирование и выдачу можно вынести в отдельный модуль.
Нужна ли бюро отдельная CDE?
Это зависит от требований к документам, версиям, доступам и передаче. Сначала проверим действующее хранилище. Если оно покрывает нужный процесс, новая система может хранить ссылки и идентификаторы конкретных версий.
Можно ли оценить разработку по числу сотрудников?
Число пользователей влияет на лицензии и права. Объём разработки определяют также договоры, стадии, методика загрузки, выдачи, интеграции и перенос данных. Для сравнимой оценки нужен один разобранный проект и перечень результатов первого запуска.
Покажите путь от запроса до выдачи
Оставьте контакт в форме, чтобы обсудить обезличенный договор, стадии, загрузку и одну выдачу. Мы сравним готовую платформу, отдельный модуль и свою систему. Результатом разбора станут карта частей решения и список вводных для оценки первого этапа. Состав предлагаемой работы для бюро описан на странице решения.