Проект как объект учета в 1С: как связать задачи, трудозатраты, оплаты и бюджет

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

Руководитель проекта видит задачи и сроки.
Исполнители фиксируют работу в таблицах или вообще не фиксируют регулярно. Бухгалтерия видит оплаты и документы.
Финансист ведет бюджет отдельно.
- Руководитель получает итоговую картину с задержкой.

В результате проект есть как набор работ, но не всегда есть как полноценный объект учета. А без этого сложно управлять себестоимостью, план-фактом и маржинальностью. Об этом мы подробно будем обсуждать на вебинаре «Простая система управления проектами в 1С: от плана и задач до ресурсов, бюджета и себестоимости».

Проект как объект учета – это подход, при котором все данные, влияющие на экономику проекта, собираются вокруг одной управленческой сущности.

К проекту должны быть привязаны:

• этапы и задачи;

• исполнители и роли;

• плановые трудозатраты;

• фактические трудозатраты;

• бюджет доходов и расходов;

• плановые оплаты;

• фактические оплаты;

• прямые расходы;

• внутренние работы;

• документы;

• план-факт;

• себестоимость;

• маржинальность;

• управленческая отчетность.

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

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

Задачи отвечают на операционные вопросы:

• что нужно сделать;

• кто отвечает;

• какой срок;

• в каком статусе работа;

• что обсуждали в комментариях;

• какой результат нужно получить.

Для организации работы команды этого достаточно. Но для учета проекта нужны другие данные.

Закрытая задача не показывает:

• сколько часов планировали потратить;

• сколько часов потратили фактически;

• какая стоимость ресурса использовалась;

• относится ли работа к оплачиваемой части проекта;

• была ли задача предусмотрена бюджетом;

• связана ли она с этапом договора;

• повлияла ли она на себестоимость;

• стала ли она причиной перерасхода.

Например, задача «доработать отчет» может быть закрыта вовремя. Но если на нее ушло 40 часов вместо 12, а эти работы не были заложены в бюджет, с точки зрения экономики проекта это уже проблема.

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

Чтобы проект стал объектом учета, данные должны проходить понятный путь.

1. Завести проект как отдельный объект учета.
   У проекта должны быть руководитель, сроки, статус, участники, бюджет и связанные показатели.

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

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

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

5. Фиксировать фактические трудозатраты по задачам.
   Факт должен попадать в проектный учет регулярно, а не восстанавливаться в конце месяца или после закрытия проекта.

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

7. Сравнивать план и факт.
   Сравнивать нужно не только деньги, но и сроки, трудозатраты, этапы, оплаты, себестоимость и маржинальность.

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

Такая таблица может быть простым чек-листом: если по проекту не фиксируется хотя бы часть этих данных, управленческая картина будет неполной.

В проектных компаниях труд сотрудников часто является основной частью себестоимости. Это особенно заметно в ИТ, консалтинге, внедрении 1С, инжиниринге, маркетинге, проектировании, сервисных и исследовательских проектах.

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

Для управленческого учета важно фиксировать трудозатраты в разрезах:

• проект;

• этап;

• задача;

• исполнитель;

• роль или подразделение;

• период;

• вид работ;

• оплачиваемые и внутренние работы.

Тогда появляются ответы на вопросы:

• сколько часов ушло на предпроектное обследование;

• сколько времени заняли доработки после приемки;

• какие этапы регулярно превышают план;

• сколько внутренних часов было потрачено без оплаты со стороны клиента;

• какие специалисты были задействованы сверх плана;

• какие проекты потребляют больше ресурсов, чем ожидалось;

• где команда ошибается в оценке трудоемкости.

Без этой связи себестоимость проекта часто считается постфактум и приблизительно. А значит, управлять ею в процессе почти невозможно.

Для учета важны оба показателя.

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

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

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

Сравнение плана и факта помогает выявить:

• недооцененные этапы;

• задачи с перерасходом;

• неучтенные работы;

• слабые места в методике оценки;

• проблемы в управлении ресурсами;

• снижение маржинальности еще до завершения проекта.

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

Трудозатраты показывают факт: сколько времени уже потрачено. Но для управляемости проекта важно видеть и будущую потребность в ресурсах.

Ресурсное планирование помогает ответить на вопросы:

• какие специалисты понадобятся проекту в ближайшие недели;

• хватает ли ресурсов для выполнения запланированных работ;

• где возможен дефицит;

• какие сотрудники перегружены;

• какие проекты конкурируют за одних и тех же людей;

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

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

В проектной деятельности деньги редко существуют отдельно от этапов и результатов.

Оплаты могут быть связаны:

• с авансом;

• с завершением этапа;

• с подписанием акта;

• с достижением вехи;

• с передачей результата;

• с календарным графиком платежей;

• с дополнительными работами.

Если оплаты живут отдельно от проектного плана, возникают разрывы.

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

В едином контуре проектного учета важно связывать:

• этапы проекта;

• договорные обязательства;

• плановые оплаты;

• фактические оплаты;

• расходы;

• трудозатраты;

• документы;

• бюджет;

• план-факт.

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

Бюджет проекта должен отражать не только ожидаемый доход, но и планируемые затраты.

В зависимости от типа компании и проекта в бюджет могут входить:

• плановые доходы;

• трудозатраты сотрудников;

• услуги подрядчиков;

• закупки;

• командировки;

• лицензии;

• оборудование;

• внутренние расходы;

• резерв на риски;

• дополнительные работы;

• платежный календарь.

Важно, чтобы бюджет не был отдельной таблицей, которую обновляют вручную перед совещанием. Он должен быть связан с фактическим исполнением проекта: задачами, этапами, трудозатратами, оплатами и расходами.

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

Одна из частых проблем проектного учета – поздний расчет себестоимости.

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

Поздний расчет себестоимости опасен по нескольким причинам:

• перерасход обнаруживается после завершения работ;

• внутренние часы не попадают в управленческий учет вовремя;

• дополнительные работы выполняются без пересогласования бюджета;

• задержки оплат становятся видны отдельно от статуса проекта;

• руководитель проекта не видит влияния решений на маржу;

• компания повторяет ошибки оценки в следующих проектах.

Себестоимость нужно видеть в динамике.

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

План-факт в проектном учете не должен ограничиваться только деньгами.

Полезно сравнивать несколько измерений.

Например, проект может быть выполнен на 80% по задачам, но при этом уже использовать 95% запланированных трудозатрат. Или наоборот: задач закрыто немного, но основные платежи уже поступили, а впереди трудоемкие этапы.

Без связанного план-факта такие ситуации видны плохо.

Во многих компаниях проектный учет устроен примерно так:

• задачи ведутся в таск-трекере;

• часы собираются в Excel;

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

• оплаты отражаются в другой;

• бюджет ведет финансист в отдельной таблице;

• документы хранятся в папках;

• отчеты собираются вручную;

• руководитель получает сводку к совещанию.

В такой схеме данные постоянно расходятся.

РП может считать проект выполненным на 70%, финансист – видеть превышение бюджета, бухгалтерия – ждать закрывающие документы, руководитель – ориентироваться на отчет недельной давности.

Типовые последствия:

• невозможно быстро посчитать себестоимость;

• РП и финансы спорят о цифрах;

• трудозатраты не попадают в расчет вовремя;

• перерасход становится виден слишком поздно;

• оплаты не связаны с этапами и результатами;

• отчеты собираются вручную и быстро устаревают;

• нет единой базы для анализа будущих проектов;

• руководитель не видит реальную маржинальность в процессе.

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

Чтобы проект стал объектом учета, данные должны проходить понятный маршрут.

Сначала проект появляется в реестре. Затем он раскладывается на этапы, задачи и вехи. По задачам назначаются исполнители и плановые трудозатраты. В ходе выполнения сотрудники фиксируют фактические часы. Эти часы попадают в отчеты по трудозатратам и используются для анализа себестоимости.

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

Упрощенно цепочка выглядит так:

проект → план → задачи → отметки → трудозатраты → ресурсы → бюджет и оплаты → план-факт → себестоимость

Если из этой цепочки выпадает хотя бы одно звено, управленческая картина искажается.

Например:

• нет отметок по задачам – фактические трудозатраты приходится восстанавливать;

• нет связи задач с этапами – сложно понять, где возник перерасход;

• нет плановых часов – нечего сравнивать с фактом;

• нет привязки оплат к этапам – РП и финансы видят разные картины;

• нет план-факта – отклонения становятся заметны слишком поздно.

Единый контур проектного учета не означает, что все сотрудники должны работать в бухгалтерской системе. Смысл в другом: проектные и учетные данные должны быть связаны вокруг одного объекта – проекта.

В таком контуре проект объединяет:

• структуру работ;

• задачи;

• исполнителей;

• роли и подразделения;

• плановые трудозатраты;

• фактические трудозатраты;

• бюджет доходов и расходов;

• оплаты;

• расходы;

• документы;

• этапы и вехи;

• план-факт;

• себестоимость;

• маржинальность;

• отчетность для руководителей.

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

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

Так проект перестает быть набором разрозненных таблиц и становится полноценным объектом управленческого учета.

Проверьте, насколько проектный учет в компании связан уже сейчас.

• Можно ли за 5 минут увидеть себестоимость конкретного проекта?

• Понятно ли, сколько часов уже потрачено по каждому этапу?

• Есть ли плановые трудозатраты, с которыми можно сравнить факт?

• Видит ли руководитель проекта, какие оплаты ожидаются по проекту?

• Связаны ли задачи с этапами, бюджетом и вехами?

• Можно ли увидеть план-факт по трудозатратам?

• Понятно ли, какие проекты прибыльные, а какие только выглядят успешными?

• Есть ли единый отчет, где видны сроки, трудозатраты, оплаты и отклонения?

• Попадают ли внутренние доработки в расчет себестоимости?

• Используются ли данные завершенных проектов для оценки новых?

Если на большинство вопросов ответ «нет» или «только вручную», значит проектный учет пока держится не на системе, а на усилиях отдельных людей.

Компании стоит пересмотреть подход к проектному учету, если регулярно возникают такие ситуации:

• себестоимость проекта становится понятна только после завершения;

• трудозатраты сотрудников фиксируются нерегулярно;

• невозможно быстро понять, какие проекты прибыльные;

• руководитель проекта и финансовая служба используют разные цифры;

• бюджет проекта ведется отдельно от задач и этапов;

• оплаты не связаны с вехами, актами и результатами работ;

• внутренние доработки не попадают в расчет себестоимости;

• отчеты собираются вручную в Excel;

• руководитель видит выручку, но не видит реальную маржу;

• план-факт по проектам готовится только к совещаниям;

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

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

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

Можно видеть:

• какие проекты прибыльные, а какие требуют внимания;

• какие этапы чаще всего дают перерасход;

• где трудозатраты превышают план;

• какие работы выполняются без оплаты;

• какие специалисты или подразделения перегружены;

• какие оплаты задерживаются;

• как меняется себестоимость в процессе проекта;

• где нужно пересогласовать объем работ;

• какие данные использовать для оценки будущих проектов.

Это важно не только для финансовой службы. Такая информация нужна руководителю проекта, проектному офису, руководителю направления и собственнику.

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

Проектный учет начинается не с итогового отчета о прибыли. Он начинается со связки данных.

Задачи, трудозатраты, оплаты, бюджет и расходы должны быть привязаны к одному объекту – проекту. Только тогда можно видеть реальную себестоимость, план-факт и маржинальность.

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

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

Если вам актуальна тема проектного учета, приходите на вебинар «Простая система управления проектами в 1С: от плана и задач до ресурсов, бюджета и себестоимости».

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

Реклама: ООО «Инфостарт-Сервис», ИНН: 7816642037, erid: 2W5zFHbaLcZ