Материал будет полезен компаниям, которые занимаются или планируют заниматься заказной разработкой программного обеспечения.
Привет! Меня зовут Дарья Ребковец, я практикующий эксперт в области управления корпоративными финансами с опытом работы более 10 лет в разных направлениях бизнеса и клиентами из SMB сектора.
Проводя финансовые аудиты IT - компаний, которые делают программное обеспечение на заказ, я заметила очень схожие проблемы. Когда компания молодая, такие проблемы мешают ей расти и зарабатывать деньги. Обычно это проходит, когда компания переходит на этап устойчивого роста и имеет стабильную клиентскую базу, но до этой стадии жизненного цикла бизнеса нужно еще дорасти и не всегда это получается. Я выделила такие проблемы в список:
Утилизация персонала: неэффективная загрузка сотрудников
Утилизация персонала – это отношение коммерческого времени к общему расписанию сотрудника. Этот показатель важно отслеживать при большом количестве проектов.
Есть средние нормы по отрасли – показатель должен быть на уровне 75%.
Если он выше, это может говорить о большой загруженности и в последующем выгорании сотрудников и их увольнении.Если он ниже 75%, то или сотрудники не загружены и компания платит из своего кармана зарплату, или бизнес-процессы в компании выстроены так, что на внутренние процессы (звонки, встречи и т.д.) занимают больше времени, чем в других компаниях и это снижает серьезно рентабельность бизнеса.
Довольно часто происходит следующая ситуация: как только сотрудник становится лидом или менеджером, его утилизация резко падает, так как если ты лид или менеджер, то должен только управлять командой, а тратить время на проекты и на код не нужно. При норме утилизации для лида 50-60% в таких случаях она превращается в 35-45%.
Расчет коммерческой ставки сотрудников
Вроде бы все знают, чтобы справедливо оценить стоимость сотрудника нужно взять все прямые и косвенные расходы и разделить на время работы. Но многие забывают из рабочего фонда времени вычесть отпускные и средние больничные по году и тем самым занижают себестоимость 1 часа работы сотрудника и впоследствии рейта. Также нужно помнить про утилизацию персонала - для каждого грейда она разная.
Немаловажно заложить резерв на риски в 10-15%, так как бывают форс-мажорные обстоятельства и сотрудники увольняются, а текучесть персонала несет для компании дополнительные расходы.
Расчет окупаемости технической поддержки
Важно считать ROI для направления технической поддержки. Отдел саппорта клиентов – очень важная составляющая в бизнесе, так как этот отдел стимулирует продажи, увеличивает LTV и влияет на отток.
Самый простой способ и наиболее практичная формула расчета окупаемости это: (доходы-расходы)/расходы *100%
Целевой ориентир ROI – 10-20%
Для того чтобы это направление было прибыльно, нужно верно рассчитать:
стоимость технической поддержки = предварительная оценка по трудозатратам на месяц * на стоимость рейта сотрудника саппорта
Встречала на практике, когда в договоре прописано, например, 50 часов на саппорт в месяц, а фактически тратится около 70 часов. Важно отcлеживать сколько часов технической поддержки указано в договоре и сколько по факту потрачено.
Многие заказчики пользуются этим и заказывают доработки ПО через техническую поддержку, поэтому кроме ежемесячного сравнения плана с фактом по нормо-часам, у компании должно быть четкое разграничение какие работы относятся к технической поддержке, а какие к разработке.
Когда компании нужно к договору разработки рассчитать стоимость годовой технической поддержки после релиза, стоимость в год должна составлять 15-20% от стоимости его разработки и этот показатель довольно часто используется как отраслевой бенчмаркинг при заключении договора технической поддержки.
Гарантийная поддержка
После того как разработку сдали, всегда есть гарантийный период, обычно он длится до года. Это период, когда разработчик должен исправлять баги, которые возникают у заказчика с продуктом. Часы на эти исправления изначально должны быть заложены в разработку проекта: кто-то считает просто как 10% от стоимости разработки, кто-то высчитывает планируемые часы. В данном случае очень важно, чтобы команда четко отделяла это время, а то получится как в одной из аудируемых мною компаний, когда разработчикам ставили общее время на выполнение проекта одной цифрой и все это отведенное время они утилизировали на разработку, просто не зная, что в этих часах сидит еще и гарантия.
Модель ценообразования
Глобально есть 2 модели ценообразования: fixed price и time and material.
T&M – очень удобная модель, гибкая и с прозрачным ценообразованием. Все риски, если вдруг будут вноситься изменения в ТЗ, ложатся на заказчика, а все дополнительные часы оплачивает заказчик.
Чего не скажешь о модели fixed price. Все доработки по fixed price необходимо дополнительно фиксировать и рассчитывать отдельно от основного договора разработки и в этом основной конфликт между заказчиком и исполнителем, так как дополнительно никто не хочет платить. А если это крупный заказчик с громким именем на рынке, то лишний раз не хочется вступать с ним в конфликт и компании заказной разработки соглашаются нести эти дополнительные расходы, чтобы не потерять возможности добавить именитый бренд в свое портфолио.
Проблемных точек, из-за которых бизнес заказной разработки теряет деньги, гораздо больше, чем эти 5 пунктов, я лишь перечислила самые основные. Но если их выявлять на ранней стадии зарождения и лечить своевременно, то бизнесу будет расти намного проще.
А если вы хотите проконсультироваться по поводу бизнеса или узнать:
Какое самое большое заблуждение в финансах?
- Что такое бенчмаркинг и как он помогает сравнить ваш бизнес с конкурентами?
Где брать информацию для планирования доходов на стадии разработки и внедрения идеи на рынок?
- Что лучше для бизнеса: традиционный подход к финансовому планирование или beyond budgeting?
То самым правильным решением будет:
- Подписаться на мой LinkedIn или канал в Telegram — Где деньги? с Ребковец.
#разработкаПО #аутстафинг #заказнаяразработка #аутсорс #IT #утилизацияперсонала #рейт #финансовыйучет #малыйбизнес #среднийбизнес