У проектних компаніях під час аналізу операцій часто чути: «Бюджет же був затверджений, чому знову перевищено?» Фінансист каже, що закупівлі не відбулися в рамках бюджету; менеджер проекту — що на місці було надто багато змін; продавець — що контракт підписаний на занижену суму. Кожна сторона веде свою розрахункову книгу,Немає жодного візуалізованого звіту про витрати, що оновлюється в реальному часі за проектами., перевитрати часто виявляються лише під час завершення проекту; у цей момент можна лише написати пояснення, а не виправити помилки.
Невидима причина витрат
- Бюджет має грубу гранульованість: Є лише загальна сума, а розбір на окремі робочі позиції, технологічні операції та кошторисні статті неможливий.
- Затримка робочого часу: Інженер наприкінці місяця заповнює форму, а фактичний обсяг понадурочних робіт на місці відрізняється від системного запису на два тижні.
- Закупівля роздрібних замовлень: У термінових закупівель не прив'язано номер проекту або прив'язано неправильний номер проекту, що призводить до відхилення витрат на матеріали.
- Зміни без оцінки: Клієнт озвучує потреби усно, без актів змін та оцінки витрат; розрахунок здійснюється лише після завершення робіт.
Три системи обліку паралельно проти одного облікового рахунку витрат проекту
| Вимір | Фінансовий головний облік / закупівлі / робочий час – кожен відповідає за свою сферу. | Центр витрат проекту |
|---|---|---|
| Часовість даних | Тільки після закриття місяця стало відомо про прибутковість чи збитковість проекту. | Робочі години, закупівлі та витрати щоденно або щотижнево підсумовуються по мірі надходження. |
| Порівняння бюджетів | Вручну збираємо таблиці в Excel | Бюджетна версія заблокована, фактичні витрати автоматично зменшують залишок бюджету. |
| Попередження про перевищення витрат | Ні, або покладається на свідомість менеджера проекту | Коли показник за предметом або загальний ліміт перевищує порогове значення (наприклад, 80% або 100%), автоматично повідомляються PM та фінансовий відділ. |
| Вплив змін | Післяподійне коригування обліку | Оцінка змін у робочому часі, матеріалах та термінах виконання, після затвердження оновлення базового бюджету |
| Перегляд подій | Суперечка щодо калібру | У рамках одного ідентифікатора проекту можна відстежувати робочий час, PO, відшкодування та субпідряд. |
Бізнес-логіка: бюджет, фактичні дані, прогнози
Рекомендація щодо моделі витрат проекту передбачає три рівні:
- Бюджетний рівень (Budget): Під час введення проекту розбивають кошторис за структурою WBS — праця, матеріали, субпідряди, подорожі, інше. Після затвердження версія блокується, а зміни оформлюються через лист змін.
- Відділ виконання (Фактично): Робочий час × стандартна або фактична ставка, сума отриманих товарів за PO, відшкодовані витрати — у реальному часі збираються на вузлах WBS.
- Прогнозувальний шар (ETC/EAC): Відбулося + оцінка залишкової робочої навантаження, щоб отримати оцінку вартості завершення (EAC), яку порівнюють з доходами за контрактом, щоб визначити тенденцію валового прибутку.
Основні положення правил:Без номера проекту неможливо зробити замовлення, вказати робочий час або оформити відшкодування.. Виняткові випадки проходять через пул «Без проектних витрат», з обмеженням та потребою затвердження керуючим фінансами або PMO, щоб запобігти виникненню «чорних дір».
Логіка дизайну: хто ввів дані, той і затверджує, а інші лише переглядають
- Керівник проекту: підтримка WBS, затвердження робочого часу, ініціація змін, перегляд панелі керування витратами.
- Інженер/на місці: Відмітка робочого часу за день або за завданням, зв’язок із листовими вузлами WBS, підтримка мобільного пристрою.
- Закупівлі: PO — обов’язковий елемент і WBS, відображення суми отримання на рівні запису.
- Фінанси: підтримка таблиці тарифів, блокування завершених проектів, експорт звітів про фінансовий розрахунок.
- Керівництво: рейтинг валового прибутку за кількома проектами, список перерозходів з червоними прапорцями, навантаження ресурсів.
Основні моменти розробки та інтеграції
- Основний ключ: Код проекту є унікальним для всієї системи і збігається з архівом проектів ERP та системою контрактів.
- Система обліку робочого часу: Може інтегруватися з існуючою OA або бути окремим модулем; головне — схвалення потоку та обов’язкові поля WBS.
- Інтеграція закупівель: У полі рядка ERP PO є номер проекту, а під час проведення отримання відбувається збір витрат.
- Сторона доходів: Сума контракту, виставлення рахунків за мілястонами, правила підтвердження доходів повинні бути узгоджені з боком витрат; валовий прибуток = підтвердження доходів − відповідні витрати (обсяг необхідно затвердити фінансовим відділом).
Під час завершення проекту формуються тризбірні таблиці «Бюджет проти фактичних витрат проти змін», які стають частиною організаційного процесу; при запуску наступного проекту враховуються тарифи за аналогічні попередні проекти, що допомагає зменшити розмір бюджету, затверджуваного наосліп.
Пілотний режим та механізм виправлення помилок
Виберіть один3–6-місячний період, персоналНе більше 20 осібПілотний проект на об'єкті, що будується:
- Перший тиждень: створення WBS та введення бюджету, загальне навчання «без номера проекту – безкоштовно».
- 2–4 тижні: запуск збору робочого часу та PO, щоп'ятниці о 15:00 проводиться збір з фінансами щодо звіту за тиждень.
- З другого місяця: увімкнено попередження про перевищення витрат; за червоними проектами необхідно подавати план корекції (вибрати один із трьох варіантів: зменшити обсяг робіт, збільшити бюджет або прискорити терміни виконання).
Ознака успіху — це не те, наскільки гарний система, а те, щоЧас виявлення перевитрати було скорочено з завершення проекту до поточного місяця., кількість актів змін зросла (що свідчить про те, що зміни справді контролюються), а відхилений показник валового прибутку за розрахунками знизився.
Тарифи та робочий час: не треба чекати до завершення проекту, щоб все підрахувати
Найбільш часто виникають суперечки щодо трудових витрат — «який тариф застосувати». Рекомендуємо закріпити це на стадії проектування.Бюджетна таблиця ставок(за рівнем посади або посадою), витрати робочого часу обліковуються на рівні фактичних витрат за бюджетними ставками; при завершенні проекту здійснюється коригування шляхом розподілу за фактичними зарплатами, а різниця записується у окремий аналітичний рахунок «Різниця ставок», замість того щоб занурюватися у валовий прибуток проекту й ставати незрозумілою. Працівник на місці щоденно15 хвилинЯкщо заповнити час роботи не вдається, можна замінити це на «одним натисканням кнопки підтвердити завершення завдання», що набагато надійніше, ніж пам’ятати про додавання записів наприкінці місяця.
Ключовим моментом управління витратами проекту є зв'язування розрізнених записів про робочий час, закупівельних накладних та видаткових квитанцій за допомогою одного й того ж ідентифікатора проекту. Якщо це не вдається, то завжди будуть виникати конфлікти на підсумковій нараді, а не в процесі коригування помилок; коли менеджер проекту у середу на щотижневій нараді може показати на приладову панель і сказати: «На матеріали вже витрачено 78% бюджету, тому на наступні два тижні призупиняємо несуттєві закупівлі», а не виявляти недостачу лише наприкінці місяця.12%, лише тоді ця система вважається налагодженою.
Конфлікт ресурсів при паралельному виконанні кількох проектів
Ті ж самі інженери часто працюють на кількох проектах, які включають…2–3 проектиЗаповніть час роботи. Якщо оцінювати витрати лише за проектом, легко не помітити, чи не «розмитнено» людські ресурси. Можна додати це у вигляді накладки в панелі ресурсів.Коефіцієнт навантаження робочого часу: Якийсь особа за тиждень заповнила понад48 годинУ разі виникнення аномалій при сумуванні по проектам, PMO залучається до перевірки. Рекомендується розбивати субпідрядні договори на два шаблони: «оплата за маркери» та «оплата за робочий час за бажанням»; субпідряди, що оплачуються лише за робочий час, обов’язково повинні прив’язуватися до WBS, щоб уникнути ситуації, коли загальна сума не може бути спрямована на конкретний вид робіт.
Узгодження з доходами від контрактів
З боку витрат, якщо підтвердження доходів затримується, валовий прибуток все одно буде неправдивим. Рекомендуємо визначити у контракті етапи (перша перевірка, остаточна перевірка, закінчення гарантійного терміну), а в системі — позначку «можна підтвердити дохід» при досягненні цих етапів, щоб проводити аналіз у зв’язку з відповідними діапазонами витрат. Таким чином, коли продавці обговорюють зміни та підвищення цін, вони зможуть бачити вже понесені витрати й залишковий бюджет, що надасть більш обґрунтовану основу для пропозиції, замість того, щоб після підписання низькоціновного замовлення змушувати проектну команду самостійно справлятися зі складностями.