Бюро выбирает систему, смотрит популярные CRM — и через месяц настройки понимает, что складывает свою работу в чужую форму. Разбираем, где именно расходятся универсальная CRM и работа проектной организации, и что стоит проверить до того, как платить за год вперёд.
Обычно так: бюро выросло, таблицы перестали держать нагрузку, руководитель идёт искать систему. Находит популярные CRM, заводит пробный период — и упирается в слово «сделка». Сделку нужно двигать по воронке: «первый контакт», «отправлено предложение», «согласование», «оплата». Для продажи товара это верно. Для проекта дома — нет: проект живёт месяцами, внутри него десяток параллельных работ, несколько платежей и куча документов, а «воронка» описывает только то, как заказчик к вам пришёл.
Дальше начинается настройка под себя. Переименовать сущности, добавить поля, нарисовать своё подобие стадий. Через месяц получается конструкция, которую держит один человек в компании — тот, кто её собирал. А когда доходит до документов и расчётов с исполнителями, оказывается, что часть вещей в этой конструкции вообще не делается.
Коротко: универсальная CRM отвечает на вопрос «как продать». Проектной организации нужен ответ на вопрос «как сделать и сдать то, что уже продано».
Будем честными, иначе разговор бессмысленный. Универсальные системы сильны там, где у них родная задача:
Если у бюро основная боль — «заявки теряются, забываем перезвонить», универсальная CRM закроет её и будет полезна. Вопрос начинается там, где заказчик подписал договор и работа поехала в производство.
Дальше самое важное. Проект — не одна строка со статусом, а набор работ, которые идут параллельно, у каждой свой срок и свой исполнитель.
Работа делится по разделам проектной документации: архитектурные решения, конструктивные, инженерные сети. Разделы ведут разные люди, часть — сторонние специалисты. Внутри проекта они идут не в очередь, а одновременно и с разной скоростью. Воронка это не описывает: у сделки один статус, а у проекта в один и тот же день один раздел на согласовании, второй в работе, третий ещё не начат.
У сделки в CRM есть «дата закрытия». У проекта — срок по каждому разделу, срок стадии и общий срок сдачи, и они связаны: сдвинулось утверждение планировок — поехало всё, что дальше. Система, которая показывает один общий срок, не поможет заметить, что проблема возникла три недели назад на конкретном разделе.
Отдельная вещь, которой в продажной логике просто нет. Проект стоит, потому что заказчик не утверждает планировку или не вносит доплату после перерасчёта площадей. Это не просрочка бюро — это пауза, и её нужно видеть отдельно, чтобы потом не оправдываться за чужое время.
Замечания к варианту — обычная работа, их может быть сколько угодно. Другое дело, когда заказчику не подошёл вариант целиком и решение ищется заново. Это отдельный заход, на него тратятся недели, и в договоре у нормального бюро записано, сколько таких заходов включено в стоимость. Универсальная CRM про это ничего не знает: для неё сделка просто «в работе» третий месяц. А потом разговор с заказчиком, который ходит по кругу, ведётся на память и на эмоциях — вместо того, чтобы открыть список и показать даты.
В универсальной CRM документы обычно устроены так: есть шаблон, в него подставляются поля карточки. Для счёта этого хватает. Для проектной работы — нет, потому что документы связаны между собой и должны сходиться:
Ручной набор здесь опасен не тем, что долго, а тем, что ошибка всплывает в конце. Акт печатают по старой площади, заказчик подписывает, а через полгода при сверке выясняется, что бюро недополучило за увеличенную площадь. Спорить поздно: документ подписан обеими сторонами.
Проверка на демонстрации: попросите показать, что будет, если площадь в утверждении изменилась после того, как договор подписан. Если ответ «поправьте руками в шаблоне» — документами эта система не занимается.
Отчёт «выручка за месяц» в бюро мало что объясняет. Деньги приходят частями — предоплата, доплата после перерасчёта, завершающий платёж, — а расходы по проекту растут всё время, пока он идёт. Ответ на вопрос «заработали мы на этом проекте или нет» складывается из трёх вещей: сколько получено от заказчика, сколько выплачено исполнителям, сколько ещё осталось получить.
При сдельной оплате исполнителям есть ещё одна деталь, которую универсальная система не видит в принципе. Переработка варианта оплачивается людям заново, а заказчику она по договору идёт бесплатно, если бесплатные заходы ещё не кончились. Каждый такой круг уменьшает прибыль по проекту, и заметить это нужно на втором заходе, а не при годовом подведении итогов.
Половина звонков заказчика — «как там мои планировки». В универсальной CRM выбор обычно между «не пускать вообще» и «завести его пользователем», то есть открыть внутреннюю кухню. Проектному бюро нужен третий вариант: отдельный доступ, где заказчик видит стадии своего проекта, сроки и подписанные документы — и не видит ни загрузку сотрудников, ни расчёты с исполнителями, ни другие проекты.
Эти вопросы стоит задать любой системе, включая нашу. Ответ «это настраивается» без показа на экране считается ответом «нет».
Не всякому бюро нужна отраслевая система. Если проектов немного и они короткие, работа не делится между несколькими исполнителями, документы типовые и печатаются раз в месяц, а расчётов со сторонними специалистами нет — универсальная CRM или даже аккуратная таблица закроют задачу. Переходить стоит тогда, когда появляются одновременные проекты, несколько исполнителей и документы, которые обязаны сходиться между собой.
Подробнее про то, как раскладывается работа внутри проекта, — в статье «Управление проектами в проектной организации».
Мы делаем систему для архитектурных бюро и проектных организаций и сами в ней работаем каждый день. Коротко по пунктам из этой статьи:
Посмотреть можно на своём проекте: мы переносим один ваш текущий проект со стадиями, сроками и суммами, чтобы вы сравнивали не с витриной, а со своей работой. Оставьте заявку или напишите на manager@workab.ru. Цены — на странице тарифов.