Ошибка 1. Сначала выбирают программу, а потом пытаются понять, зачем она нужна

CRM, учёт времени, бухгалтерия, управление задачами, сервисы аналитики - агентство может использовать сразу несколько систем.

Само их наличие ещё ничего не решает.

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

Автоматизацию лучше начинать с вопросов бизнеса:

• какой проект вышел за плановые затраты;
• сколько времени команда потратила на клиента;
• какие прямые расходы относятся к проекту;
• насколько фактическая маржинальность отличается от плановой;
• какие данные нужны для расчёта и где они возникают.

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

Ошибка 2. Доход по проекту известен, а прямые затраты собираются отдельно

Стоимость проекта для клиента обычно известна сразу.

С затратами сложнее.

Часть находится в бухгалтерском контуре, часть - в документах по подрядчикам, часть - в системе учёта времени. Некоторые расходы вообще могут остаться без проектной аналитики.

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

Чтобы оценивать экономику проектов одинаково, агентству нужна единая методика.

Например:

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

Задача автоматизации - не придумать формулу, а собрать необходимые данные по одинаковым правилам.

Ошибка 3. Трудозатраты фиксируются приблизительно

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

Допустим, на этап запланировали 100 часов, а фактически сотрудники потратили 140.

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

Но если время вообще не фиксируется либо сотрудники восстанавливают его по памяти в конце недели, увидеть реальное отклонение сложно.

Для финансового анализа одних часов тоже недостаточно.

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

Без фиксации времени этот перерасход может раствориться в общей загрузке команды.

Ошибка 4. Прямые расходы не связаны с конкретными проектами

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

Тогда результат по проектам искажается.

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

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

При этом признание расхода и фактическая выплата денег - разные события.

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

Ошибка 5. Факт собирают, но сравнивать его не с чем

Можно аккуратно собрать расходы и трудозатраты и всё равно поздно заметить проблему.

Если до начала проекта не зафиксированы плановые показатели, фактические 230 часов сами по себе мало о чём говорят.

Много это или мало?

Для одного проекта план мог быть 180 часов, для другого - 250.

Поэтому план-факт начинается с плана:

• ожидаемого дохода;
• плановых трудозатрат;
• внутренней стоимости ресурсов;
• расходов на подрядчиков;
• других прямых затрат по принятой модели.

После этого фактические показатели можно сравнивать с исходными.

Дополнительные 30 часов могут означать расширение объёма работ, а могут - ошибку первоначальной оценки. Для бизнеса это разные ситуации и разные решения.

Ошибка 6. Премии рассчитывают отдельно от экономики проекта

Ещё одна зона риска появляется, когда финансовый результат проекта и система мотивации сотрудников существуют независимо друг от друга.

Например, премия зависит только от суммы проданных или закрытых проектов. При этом не учитывается, сколько ресурсов потребовалось для их выполнения.

Но и обратная крайность опасна: нельзя просто взять маржинальность и сделать её единственным критерием премирования.

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

Если компания использует проектные показатели в мотивации, правила должны быть определены заранее, показатели - измеримы, а условия выплаты - соответствовать действующей системе оплаты труда.

Отдельно нужно проверить, не включена ли премия уже во внутреннюю стоимость ресурса. Иначе один расход может попасть в расчёт проекта дважды.

Ошибка 7. Отчёты есть, но никто не отвечает за отклонения

Самая дорогая автоматизация бесполезна, если данные только собираются.

Допустим, отчёт показывает:

• трудозатраты выше плана на 18%;
• расходы подрядчиков выше бюджета на 70 000 рублей;
• проектная маржинальность снизилась с 32% до 21%.

Это ещё не управленческое решение.

Нужно проверить исходные данные, понять причины отклонений и определить дальнейшие действия.

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

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

Полезен не просто отчёт, а регулярный процесс:

Как связать данные в единую картину

В агентстве обычно используются несколько учётных контуров, но их границы зависят от конкретной архитектуры.

CRM может использоваться для работы с клиентами, сделками и коммуникациями.

Проектный контур - для этапов, задач и трудозатрат.

Бухгалтерский контур - для отражения хозяйственных операций и регламентированного учёта.

Зарплатный - для начислений сотрудникам.

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

Решения на базе 1С тоже могут участвовать в нескольких контурах одновременно. Это не означает, что все данные обязательно должны физически находиться в одной базе.

Что проверить в агентстве

Для начала достаточно шести вопросов.

1. Есть ли единое правило расчёта проектной маржи и маржинальности?
2. Привязываются ли прямые расходы к конкретным проектам?
3. Фиксируются ли фактические трудозатраты?
4. Есть ли план по часам и прямым затратам до начала проекта?
5. Можно ли сопоставить план и факт по одинаковой методике?
6. Кто отвечает за проверку отклонений и принятие решений?

Если на часть вопросов нет ответа, проблема обычно не решается добавлением ещё одного отчёта.

Сначала нужна понятная модель учёта и ответственность за данные. Затем под неё настраиваются системы.

Итог

Высокая загрузка команды ещё не показывает, насколько выгодны отдельные проекты.

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

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