Как создать калькулятор для расчета стоимости IT проекта
IT-компания отказалась от интуитивного ценообразования, внедрила калькулятор в Google Sheets и начала точно прогнозировать и наращивать прибыль
Разработали калькулятор стоимости проекта с учетом всех затрат и план-факта.
Цель проекта — создать инструмент, который позволит:
- Точно рассчитывать стоимость проекта уже на этапе КП.
- Закладывать реалистичную маржу с учетом всех затрат.
- Видеть отклонения в процессе, а не в конце.
- Обосновывать цену клиенту фактами, а не интуицией
Причина появления проблемы — отсутствие управленческого учета. В компании не было специалиста, который работает с финансовыми потоками и выполняет функции финансового директора. Многие бизнес- процессы работали только на решение текущих оперативных задач.
Исходная ситуация:
«Мы не знали, сколько реально зарабатываем на проекте, пока он не заканчивался — а иногда и тогда не понимали» — так описывал ситуацию собственник IT-компании, разрабатывающей ПО под заказ.
Бизнес работал по проектной модели, но ценообразование и контроль расходов велись «на глаз». Итог — частые кассовые разрывы, непредсказуемая маржа, решения о ценах и премиях на основе интуиции, а не данных.
Компания занималась проектной разработкой: под каждый заказ собиралась команда специалистов разного уровня (Middle, Senior и др.).
Что было до проекта:
Бизнес работал по проектной модели, но ценообразование и контроль расходов велись «на глаз». Итог — частые кассовые разрывы, непредсказуемая маржа, решения о ценах и премиях на основе интуиции, а не данных.
Компания занималась проектной разработкой: под каждый заказ собиралась команда специалистов разного уровня (Middle, Senior и др.).
Что было до проекта:
- Сметы формировались для КП (коммерческого предложения) «для галочки» — без детальной проработки затрат.
- Фиксация расходов была, но хаотичная, без классификации на постоянные и переменные.
- Не учитывались мелкие, но регулярные траты — доступы, лицензии, разовые сервисы, оплата респондентов.
- План-факт анализа не было — собственник узнавал о перерасходе в конце проекта.
- Мотивация сотрудников не зависела от маржинальности — все работали на фиксированных окладах.
Шаг 1. Сбор и подготовка данных
- Проанализировали прошлые проекты: выручка, длительность, состав команды, все виды расходов (включая личные карты сотрудников и собственника).
- Классифицировали затраты:
- Постоянные — аренда, оклады, постоянные лицензии.
- Переменные — разовые доступы, оплата респондентов, дополнительные сервисы.
Шаг 2. Формирование структуры калькулятора
Калькулятор был реализован в Google Sheets и включал:
- Параметры проекта: тип проекта, сложность, предполагаемая длительность.
- Состав команды: роли, количество человек, ставка (почасовая или проектная).
- Загрузка по ролям: % времени, реально отрабатываемого на проекте (billable hours).
- Накладные расходы: аренда, софт, постоянные сервисы, распределенные на проект.
- Переменные расходы: разовые доступы, исследования, командировки.
- Риски: резерв в % на непредвиденные затраты.
- Желаемая маржа: процент сверху после учета всех расходов.
Шаг 3. Логика расчета
- Калькулятор автоматически суммировал прямые и распределенные расходы.
- Добавлял резерв и целевую маржу.
- Формировал финальную цену договора с обоснованием по статьям затрат.
Отдельно остановимся на методах распределения накладных расходов, так как именно они на этапе развития тянули прибыль проекта вниз. В мировой практике применяется :
1. Метод «по видам деятельности» (ABC — Activity-Based Costing)
Смысл в том, чтобы распределять общие расходы не «на глаз» и не поровну, а по принципу: кто использует — тот и оплачивает.
Например:
1. Метод «по видам деятельности» (ABC — Activity-Based Costing)
Смысл в том, чтобы распределять общие расходы не «на глаз» и не поровну, а по принципу: кто использует — тот и оплачивает.
Например:
- Расходы на офис и администрирование распределяются по времени работы команды над проектом.
- Затраты на специализированные программы или сервисы — по числу людей, которые ими пользуются в каждом проекте.
- Стоимость работы менеджеров и координаторов — по количеству часов, которые они реально уделяют проекту.
2. Метод «по времени» (Time-Driven)
Здесь все накладные расходы переводятся в «стоимость одного часа работы команды».
Сначала считают:
Метод проще в расчетах, чем первый, и подходит, если проекты более-менее одинаково нагружают ресурсы компании.
В данном случае мы применили метод «по времени», так как для клиента это было более понятно и прозрачно.
Здесь все накладные расходы переводятся в «стоимость одного часа работы команды».
Сначала считают:
- Сумму всех постоянных расходов компании в месяц (аренда, зарплата админперсонала, интернет, бухгалтерия и т.д.).
- Общее количество часов, которое команда может отработать в месяц.
- Делят одно на другое — получается ставка накладных на час. Потом для каждого проекта считают, сколько часов на него ушло, и умножают на эту ставку.
Метод проще в расчетах, чем первый, и подходит, если проекты более-менее одинаково нагружают ресурсы компании.
В данном случае мы применили метод «по времени», так как для клиента это было более понятно и прозрачно.
Важно: распределение накладных расходов обновлялось ежемесячно. В случае увеличения количества сотрудников / проектов для метода «по времени» логика была следующая :
Плюс клиент, когда начал фиксировать и распределять накладные занялся вопросами их оптимизации. В частности он:
- Приходит новая команда → общее количество рабочих часов (емкость) компании в месяц увеличивается. Формула: OH_rate = Общие накладные / Часы_всех_команд.
- Ставка накладных на час снизится, если постоянные расходы остались прежними.
- Для план-факта пересчет делается на момент изменения — например, можно разбить месяц на «до» и «после» и рассчитать для каждого периода свою ставку.
Плюс клиент, когда начал фиксировать и распределять накладные занялся вопросами их оптимизации. В частности он:
- Проанализировал, какие программы дублируют друг друга, и оставить только одну, которая покрывает все нужды.
- Настроил оплату так, чтобы лицензии покупались только тем, кому они реально нужны для работы.
- Для аренды «облачных ресурсов» настроил автоматическое отключение ресурсов, когда они не используются (например, ночью или в выходные).
- Для тех мощностей, которые нужны постоянно, перешел на долгосрочную аренду с фиксированной ценой — это дешевле, чем платить помесячно.
- Перевел бухгалтерию на аутсор.
Шаг 4. План-факт контроль
- На основе калькулятора внедрили ежемесячный отчет: сравнение плановой и фактической себестоимости.
- Отклонения анализировались сразу, что позволяло корректировать ход проекта.
Результат:
До:
- Отклонения сметы от факта: ±30–50%.
- Маржинальность — на грани безубыточности.
- Постоянные кассовые разрывы.
- Отклонения сметы от факта: не более ±5–7%.
- Маржинальность проектов: +15–20% в среднем.
- Полное отсутствие кассовых разрывов.
- Сроки окупаемости проектов сократились на 15%.
- Убыточные проекты выявлялись еще на этапе КП и пересчитывались.
