5 проблем финансового учета: что мешает компаниям по разработке ПО зарабатывать

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

Привет! Меня зовут Дарья Ребковец, я практикующий эксперт в области управления корпоративными финансами с опытом работы более 10 лет в разных направлениях бизнеса и клиентами из SMB сектора.

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

Утилизация персонала – это отношение коммерческого времени к общему расписанию сотрудника. Этот показатель важно отслеживать при большом количестве проектов.

Довольно часто происходит следующая ситуация: как только сотрудник становится лидом или менеджером, его утилизация резко падает, так как если ты лид или менеджер, то должен только управлять командой, а тратить время на проекты и на код не нужно. При норме утилизации для лида 50-60% в таких случаях она превращается в 35-45%.

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

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

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

Для того чтобы это направление было прибыльно, нужно верно рассчитать:

Встречала на практике, когда в договоре прописано, например, 50 часов на саппорт в месяц, а фактически тратится около 70 часов. Важно отcлеживать сколько часов технической поддержки указано в договоре и сколько по факту потрачено.

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

Когда компании нужно к договору разработки рассчитать стоимость годовой технической поддержки после релиза, стоимость в год должна составлять 15-20% от стоимости его разработки и этот показатель довольно часто используется как отраслевой бенчмаркинг при заключении договора технической поддержки.

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

T&M – очень удобная модель, гибкая и с прозрачным ценообразованием. Все риски, если вдруг будут вноситься изменения в ТЗ, ложатся на заказчика, а все дополнительные часы оплачивает заказчик.

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

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

То самым правильным решением будет:

#разработкаПО #аутстафинг #заказнаяразработка #аутсорс #IT #утилизацияперсонала #рейт #финансовыйучет #малыйбизнес #среднийбизнес