Антон Дегтярёвбитрикс24 для проектной организации: проектировщики и заказчики
Проектная организация — это не «продал и забыл», а долгий цикл: заказ, разработка разделов документации, согласования, экспертиза, доработка по замечаниям. На 7 из 10 внедрений в проектных бюро вижу CRM, настроенную под разовую сделку — а сама разработка разделов ведётся в переписке и таблицах на общем диске. Разбираю, как собрать весь цикл — от заявки заказчика до сданной документации — в одном портале.
чем проектная организация отличается от обычного b2b
У обычной b2b-компании сделка закрывается один раз: договор подписан, оплата пришла, товар отгружен. У проектной организации после подписания договора начинается основная работа — разработка разделов документации (архитектурный, конструктивный, инженерные сети, ОВ, ЭОМ), которая занимает недели или месяцы и проходит через несколько кругов согласования с заказчиком, а часто ещё и через экспертизу.
Если держать весь этот цикл в одной воронке продаж, к середине проекта воронка забита закрытыми сделками вперемешку с активными разделами документации на разных стадиях готовности — понять реальную загрузку проектировщиков по такому отчёту невозможно. Рабочая схема — разделить контур продажи (заявка → тех.задание → коммерческое предложение → договор → аванс) и контур разработки документации, который живёт в Проектах или Смарт-процессе с отдельными стадиями по разделам.
воронка продажи проектных работ
Заявка — от заказчика напрямую, через тендерную площадку или по рекомендации. Уточнение исходных данных — что именно нужно спроектировать, какие есть ограничения по площадке, есть ли уже часть исходной документации. Коммерческое предложение — с разбивкой по разделам и срокам на каждый. Договор и аванс — обычно 30–50% на старте, остальное — по этапам сдачи разделов. Разработка — отдельный контур (следующий раздел). Сдача и оплата остатка — после подписания заказчиком актов приёмки по всем разделам.
Ключевая точка перехода — статус «договор подписан»: именно здесь автоматика должна создать структуру для разработки (проект или смарт-процесс со стадиями по разделам), а не полагаться на то, что менеджер вручную заведёт задачи проектировщикам.
разделы документации как отдельные объекты
Каждый раздел проектной документации — архитектурные решения, конструктивные решения, инженерные сети — по сути отдельный поток работы со своим ответственным специалистом, сроком и статусом готовности. Здесь хорошо ложится смарт-процесс: стадии «в работе» → «на внутренней проверке» → «отправлено заказчику» → «согласовано» → «на экспертизе» → «принято», с полем ответственного проектировщика и сроком по каждому разделу.
Устройство и настройку такого смарт-процесса я подробно разбирал в статье смарт-процессы в Битрикс24: что это и когда они нужны — для проектной организации это ровно тот случай, когда объектов (разделов) много, они однотипны по циклу и нужна отдельная карточка со своими полями, не похожими на карточку сделки.
согласования с заказчиком — контроль версий и замечаний
Самое узкое место в проектных организациях — версии документации, которые заказчик комментирует по почте, в мессенджере, а иногда голосом на созвоне, и разрозненные правки потом теряются между специалистами. Рабочая схема — бизнес-процесс «отправка на согласование»: раздел уходит заказчику с фиксированным сроком ответа, замечания заказчик оставляет в форме или карточке, а не россыпью в переписке, и по каждому замечанию автоматически ставится задача ответственному проектировщику с ссылкой на конкретный пункт.
Про то, как строятся такие цепочки согласования с ветвлениями и сроками, у меня есть отдельный разбор — бизнес-процессы в Битрикс24, включая типовой пример согласования договора, который по логике почти один в один переносится на согласование раздела документации.
прохождение экспертизы — отдельная стадия, а не часть согласования
Государственная или негосударственная экспертиза — это не то же самое, что согласование с заказчиком, и путать эти два процесса в одной стадии воронки — частая ошибка. У экспертизы свой цикл: подача комплекта → рассмотрение → замечания экспертизы → доработка → повторная подача → заключение. Замечания экспертизы обычно приходят одним объёмным документом по всем разделам сразу, и без отдельной стадии «доработка по замечаниям экспертизы» со своим списком задач по разделам эти правки смешиваются с текущей разработкой и теряют приоритет.
На практике по проектам, где я настраивал такую стадию отдельно, срок повторной подачи после замечаний сокращался примерно на треть — просто потому, что задачи по конкретным пунктам замечаний распределялись между проектировщиками сразу, а не после совещания «кто что должен поправить».
работа с субподрядчиками по узким разделам
Проектные организации часто привлекают внешних специалистов на узкие разделы — например, раздел пожарной безопасности или специфические инженерные сети, где нет своего постоянного специалиста в штате. Субподрядчику нужен доступ ровно к своему разделу и переписке по нему, без видимости коммерческих условий договора с заказчиком и без доступа к другим разделам проекта.
Настраивается через права доступа по ролям на уровне карточки раздела — субподрядчик видит стадию и задачи только своего объекта в смарт-процессе, а не всю воронку организации. Отдельно стоит фиксировать срок и стоимость работ субподрядчика в поле карточки, а не только в отдельном договоре, — так руководитель проекта видит реальную маржинальность по разделу, где часть работы отдана на сторону.
учёт времени специалистов по разделам
Если проектировщики работают не только на фиксированную цену раздела, но и почасово (доработки, экспертные консультации, изменения по инициативе заказчика после подписания договора), учёт времени становится обязательной частью контура — иначе изменения «в рамках проекта» незаметно съедают маржу. Три подхода к организации такого учёта я разбирал отдельно — учёт рабочего времени в Битрикс24; для проектной организации обычно подходит таймер по задаче, привязанной к конкретному разделу, а не общий табель по дню.
типичная ошибка — нет фиксации, какая версия документации у заказчика
Частая ситуация на моих аудитах: проектировщик отправил заказчику третью версию раздела с правками, а в CRM или на диске лежит вторая, потому что файл переслали напрямую по почте в обход системы. Когда возникает спор о том, что именно согласовано, найти актуальную версию занимает часы, а иногда становится юридической проблемой при приёмке работ.
Правило простое: любая версия документации, которая уходит заказчику, крепится файлом к карточке раздела с датой отправки — без исключений «просто перешлю по почте, потом занесу». Это не бюрократия ради бюрократии, а единственный способ доказать, какая версия и когда была согласована, если дело дойдёт до спора по приёмке. Если процесс запускается с нуля, разумно сразу закладывать эту дисциплину в структуру проекта — обсудить это можно на консультации по внедрению, до того как накопится архив несогласованных файлов.
аналитика по проектам — что реально смотреть руководителю
Три показателя закрывают большую часть вопросов руководителя проектной организации. Первый — средний срок разработки раздела по типу (архитектурный обычно занимает не столько, сколько инженерные сети, и смешивать их в одном среднем бессмысленно). Второй — доля разделов, вернувшихся на доработку после первого согласования с заказчиком: если она стабильно выше 40–50%, проблема обычно не в проектировщиках, а в неполном техническом задании на старте. Третий — загрузка специалистов по одновременно открытым разделам, чтобы новый проект не брали в работу, когда штат уже занят на 100%.
Эти три цифры собираются автоматически, если стадии смарт-процесса и поля ответственных настроены с самого начала, — считать их вручную по итогам месяца намного дольше и менее точно, чем смотреть готовый отчёт по фильтру.