Сколько стоит одна позиция в прайсе?

Если мы разработали новое изделие, добавили новую позицию в каталог — мы сделали полезное дело или, наоборот, навредили компании? История о неочевидных финансовых вопросах, которые встали перед нами и которые наверняка встают перед другими компаниями.

Мы — приборостроители. Наша компания Uniscan Research больше двадцати лет разрабатывает и производит различные электронные приборы. Медтехника, системы безопасности, станции экомониторинга CityAir, биореактор для выращивания пищевых водорослей и многое другое.

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

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

Компания, само собой, все эти годы растет во всех смыслах. Штат вырос с 20 человек до 200.

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

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

Многие годы мы рассуждали так:

• Если разработчики создали новое изделие, то мы понесли понятные расходы на разработку. Это можно посчитать и списать в инвестиции или CAPEX.
• Далее производство его тиражирует. Тут появляются понятные переменные издержки или OPEX.
  
• Продавцы продают, CAPEX и OPEX постепенно покрываются. Когда покроются окончательно, тогда мы выходим на точку окупаемости.
  
• Надо доработать изделие (новая фича, баг) — добавляем некую сумму в CAPEX. Если же мы не продаем и не дорабатываем изделие, то компания не несет никаких расходов. Вроде бы все логично.
  

Очевидный вывод: мы можем иметь в каталоге сколь угодно много изделий, которые могут не продаваться. Конечно, при условии, что мы не планируем их развивать и дорабатывать. То есть эти изделия могут оставаться «на паузе» сколь угодно долго — и нам это ничего не стоит.

В такой парадигме мы жили 15 лет, и наш каталог потолстел с 20 до 400 изделий. Это радовало продавцов и, напротив, огорчало разработчиков. Но денежный поток позволял закрывать глаза на жалобы разработчиков.

Почему так получается? Очевидно, из-за того, что мы не учитываем какие-то существенные расходы на разработку и доработку изделий. Чтобы разобраться в этом, следует объяснить, откуда вообще берется стоимость владения изделием. Это проще сделать на примере.

Представим, что мы нашли контрактного разработчика и заказали у него разработку крутого нового изделия, которое прекрасно дополняет наш охранный комплекс. Договорились о сроках, деньгах, накидали ИТ. Прошло время, и мы получаем КД и запускаем производство. Все классно, все счастливы.

Наши затраты: расходы на подрядчика и на запуск производства. Понятая сумма. Списываем ее в инвестиции. Производим изделие, продаем его, получаем выручку. До этого момента все окей. Трудности возникают, когда появляются вопросы — у производства, продавцов, клиентов.

• Можно ли заменить «конденсатор А» на «конденсатор Б»? У производителя конденсаторов меняется модельный ряд, и нашим конденсаторам нужна замена на аналоги.
• Клиент хочет один датчик засунуть под воду, а другой повесить на едущий танк. Будет ли устойчивая связь?
  
• На выходном тестировании приборов пошел массовый брак. В чем причина?
  

Все вопросы понятные, и очевидно, что нужно найти на них ответы. Беда в том, что все эти вопросы не к нам, а к нашему контрактному разработчику.

• Подойдет ли «конденсатор Б»? Разработчик должен изучить документацию и дать ответ.
• Будет ли связь? Надо знать, как радиоканал устроен изнутри. Это знает тот, кто его разрабатывал. И он же сможет продумать сценарий испытаний и организовать проверку на полигоне.
  
• Откуда брак? Сломался испытательный стенд или что-то не то на производственной линии? Еще один вопрос к подрядчику.
  

На все вопросы подрядчик зачастую отвечает: «Мы сильно заняты. Будет время — изучим вопрос и ответим. Когда-нибудь». Для нас такой вариант неприемлем, и мы готовы заплатить за быстрый ответ. Подрядчика это радует, и он сразу выделяет специалиста для решения вопроса.

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

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

Еще лучше эта тема раскрывается, если мы рассмотрим другой пример:

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

Производим, отгружаем, монтируем — все сами. Баги правим по мере возможностей. Фичи под заказ не добавляем вообще – некогда. Документируем разработку по остаточному признаку, то есть никак. Пользовательская и продажная документация отсутствует, не до этого.

Все происходит быстро, весело и задорно. Хронология событий примерно такая:

1. Делаем MVP, начинаем продажи. Пользователи требуют еще пару датчиков, на других физических принципах. Отказать нельзя — нужна новая разработка. Но мы утонули в багах старых датчиков. Нужны еще инженеры, а вместе с ними начальники разработки и производства, логистика и ее начальник.

2. Люди группируются в две виртуальные команды: «старый продукт» и «новый продукт». Начальник разработки пыхтит над регламентом работы двух команд. Директор пытается организовать взаимодействие разработки, производства, продажников. Сам он больше не разрабатывает – некогда.

Все идет уже не так быстро, но все еще весело и задорно.

3. Пользователи довольны, но для полного счастья хотят видеокамеру, фотоаппарат, тепловизор. Мы же стартап – не можем поворачиваться к пользователю спиной. Нанимаем еще инженеров.

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

5. Компания растет, появляются новые сущности. Много изделий в производстве — нужна инженерная поддержка конвейера. Не успеваем ездить по монтажам и багам — появляется сервисная служба. Обратной связи уже столько, что приходится заводить трекер заявок. Это повод для появления фреймворка разработки. Начинаем придумывать «правила жизни разработчика», по которым он успевает сделать все, что на него валится.

Это переломный момент. Раньше поведение разработчиков и расходы компании укладывались в некую интуитивную картинку: мы что-то разработали, потратили какую-то сумму — значит, эту сумму и надо отбить продажами.

Но с появлением фреймворка к CAPEX добавляется абсолютно неочевидный OPEX, который вообще не зависит от продаж и отгрузок. Изделий в каталоге уже намного больше, чем их авторов — в таких условиях работу компании обеспечивает фреймворк. И за него надо платить.

Продолжаем хронику стартапа:

6. Развитие продукта становится нашей визитной карточкой: мы вносим все доработки по первому запросу. В итоге в разработке еще пяток датчиков. Нанимаем еще инженеров. Начальники уже не вывозят такое количество подчиненных — начинаем дублировать отделы, заводить замов, техлидов.

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

8. Количество изделий растет, растет риск ошибок, внедрение в производство становится заметно сложнее.

Становится так много работы по документированию, внедрению, ответам на вопросы, что мы недоумеваем: почему все работают на максимуме, а разработка ничего не выдает наружу?

9. Проходит 10 лет, и у нас уже 200 изделий в каталоге и 50 разработчиков в штате. Фреймворк, построенный на отделах, терпит фиаско. Переходим к командам. Привет, Agile. Появляются владельцы продуктов, скрам-мастера, техлиды. Начальники больше не могут разрабатывать – они теперь носители экспертизы. Появляются писатели, стендовики. Соотношение количества «пехоты» и «офицеров» чуть ли не 1:1.

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

Очевидно, что пример со стартапом — во многом это история нашей компании. Со временем мы пришли к некоему SLA, которое регламентирует отношения разработчиков с производством и продажами.

Это SLA и выпадает из внимания. Здесь теряется причинно-следственная связь, когда мы обсуждаем стоимость владения позиции в каталоге. На самом деле мы тратим деньги не только в тот момент, когда мы заказываем доработку или разработку нового изделия.

Мы тратим деньги каждый день, пока эта позиция в принципе существует. Мы платим деньги за возможность действия с объектом. Пользуемся мы этой возможностью или нет — неважно. Это все равно стоит денег. Вот в этом месте интуиция и подводит.

У нас было готовое устройство, и за целый год мы не провели ни одного проекта по нему. Но это не значит, что оно нам ничего не стоило. Однажды нам потребовалось срочно перевести это устройство с Bluetooth на LoRaWAN — и мы сделали это, потому что весь год поддерживали весь свой фреймворк.

А вдруг на горизонте замаячит новый продукт? Например, какой-нибудь супердрон. Перспективный, репутационный. Как оценивать его? С учетом, что мы уже обожглись с SLA.

Вот тут и зарыта проблема: обсуждая каждый новый проект, мы обсуждаем только очевидные проектные расходы. А то, что 2–3 таких изделия приведут к появлению новой команды, владельца продукта, скрам-мастера, писателя, а может, и уборщицы, админа, бухгалтера — все это остается за кадром. Всего этого не будет ни в одном проекте разработки. Это «бесплатная» функция инфраструктуры.

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

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

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

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

Также это все накладывает ограничения на масштабирование компании. Если мы попытаемся сократить расходы с учетом падения продаж, то не можем никого уволить: вся армия разработчиков и производственников поддерживает SLA для текущего каталога. И если мы не сокращаем каталог или не упрощаем SLA, то нельзя уволить ни одного человека.

Мы у себя в компании запустили несколько проектов по улучшениям:

1. Проредить каталог.

a. Убрать все изделия, которые много лет не продаются и для которых в каталоге есть более современные решения.

b. Убрать все изделия, которые разработаны «на всякий случай», но по факту продаются крайне мало.

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

d. Для каждого изделия завести атрибут «время жизни» — дату, после которой изделие убирается из каталога, как устаревшее. Мы до сих пор поддерживаем изделия, разработанные 20 лет назад.

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

3. Описать текущий набор сервисов и SLA. Годами сложившиеся правила работы компании становятся привычными и незаметными. Команда, которая оказывает сервисы остальной компании, не всегда сходу может составить полный список этих сервисов. И еще сложнее описать требования к качеству этих услуг: с какой оперативностью реагировать, как и откуда принимать запросы, как должен выглядеть результат работы команды и далее по списку.

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

5. И напоследок: если сокращение каталога и упрощение SLA не дадут должного эффекта, то остается крайняя мера — надо больше продавать 😊

Вроде бы все очевидно, но для нас это было поворотной точкой в развитии компании.

Спасибо за внимание, буду рад вопросам.