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

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

Куда могут завести доработки изделий под каждую хотелку клиента. Лухари эдишн охранного датчика.

Мы — приборостроители. Наша компания 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, которое регламентирует отношения разработчиков с производством и продажами.

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

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

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

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

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

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

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

Как теперь жить с этими знаниями?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{ "author_name": "Алексей Стеринович", "author_type": "self", "tags": [], "comments": 22, "likes": 40, "favorites": 71, "is_advertisement": false, "subsite_label": "trade", "id": 181409, "is_wide": false, "is_ugc": true, "date": "Fri, 27 Nov 2020 06:50:26 +0300", "is_special": false }
0
22 комментария
Популярные
По порядку
Написать комментарий...
8

Отличная статья, спасибо. Все именно так

Ответить
1

гм.
даже аккуратно заполняемая ERP система показывает что куда и зачем
система BI уровня - еще и с выводами подробными
Вы в эксельке отчетность ведете, если утрировать?

Ответить
4

Есть несколько систем учета и анализа. Но они показывают куда уходят деньги, но не показывают почему.
Мы видим, что если продажи просядут в 3 раза, то мы не можем уволить две трети сотрудников. А почему? Вот тут ERP не может помочь, она же не знает что конкретный инженер - носитель знаний про 10 изделий. 
Мы сейчас загрузили аналитика перелопатить управленческую отчетность в BI с акцентом на стоимость владения.

Ответить
4

тут такой момент, что правильно поставленный вопрос уже является большей частью ответа
например - постановка "если продажи просядут в три раза, сколько мы человек можем уволить" по сути бессмысленна, потому что не дает ответа на вопрос "кого именно мы можем уволить"
но если ведется сквозная аналитика по затратам и промежуточные вопросы звучат как "сколько мы тратим денег на поддержание позиции номер 6 в каталоге, и кто из инженеров получает деньги за экспертизу по этой позиции", то при просадке спроса на этот продукт выводы будут полезны.
кажется, что я задаюсь этим вопросом только потому, что он уже очевидно поднят в статье. но - нет. этот вопрос является переформулированным результатом ответа на вопрос "почему мы платим вот этому смежнику с разбивкой сколько копеек на что". 
пока контора получает деньги с рынка за продажу каких то единиц товара, особенно при частой смене ассортимента и собственном R&D, вычисление точного разотнесения затрат на единицу товара архиважно
еще и потому, что в статье (может я пролистал невнимательно) не задается другой интересный вопрос, который всегда встает из аналитики - "а какого дьявола у нас не продалось 1000 единиц той штуки, на разработку которой мы потратили два года и N денег?". это сильно упрощенно, но всё же
а еще появляются основания для риск менеджмента. в стиле - "если у нас в третьем цеху приключится пожар, то мы понесем в три раза меньше убытков, чем если уволится Иван Иванович, который единственный знает принцип переизобретения пяти позиций под новые комплектующие", что предполагает затраты на удержание (или передачу информации другим людям) Ивана Ивановича втрое выше чем на противопожарные меры, упрощенно говоря.
я собственно веду к тому, что аналитика становится полезной, когда она сквозная
а десижен мейкинг становится дата драйвен))))
П.С. в идеале, за 3/4 этой инфы платят фин диру...

Ответить
3

Все верно пишете. О таких вещах надо было думать уже давным-давно. Но жизнь такова какова она есть и никакова больше :)
А вот этот вопрос "а какого дьявола у нас не продалось 1000 единиц той штуки, на разработку которой мы потратили два года и N денег?" прекрасен. Мы конечно им задавались неоднократно, но что делать, если продажник говорит "не смогла"?
Это уже другая большая тема "как выстраивать офис продаж". Чтобы продавали самые маржинальные позиции, чтобы не перебарщивали со скидками и кастомизацией, чтобы система мотивации подталкивала к росту продаж, а не росту благосостояния. В этой теме я уже не чувствую себя настолько уверенным, чтобы давать советы.

Ответить
2

Попробуйте прогонять свои продукты/решения/услуги, по модели Нориаки Кано или возможно в QFD анализ поупражняться. Иногда оказывается, что представления/ожидания о продукте/решении/услуге не отражают реальных потребностей потребителей. Еще не плохо было бы оценку потенциала рынка проводить (многие экспертно пытаются выходить на рынки, экстраполируя свое представление о "прекрасном"). Возможно вопрос лежит за пределами, реальной себестоимости. На уровне допущения, эффективность SKU может решаться ценообразованием (не знаю, на сколько сложная у вас система скидок, ретробонусов, декларируемых и реальных цен). 

Ответить
0

Спасибо, про Кано знаю, пробовали, про QFD почитаю.

Ответить
1

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

Ответить
0

и вот тут мне захотелось написать адовых размеров портянку, но воздержусь)))
то что я писал про конкретные вопросы - они же не довлеющие, они контекстные.
логика простая - если пайплайн с логической точки зрения построен правильно, то можно брать разные разрезы и над ними думать. а если аналитика разрозненная, то ответ всегда будет на очень частные вопросы, которые могут не иметь значения в общем смысле.
если отвечать на последние прямые Ваши посылы, то
во 1ых - R&D переносится в цифры с трудом, кладется в P/L вообще ужасно, это прям отдельная сложная история с решением под конкретную ситуацию, но есть мировые наработки принципов аналитики / подсчетов именно внутри этой сферы
во 2ых - офис продаж это сложный механизм получения информации с рынка о том какой товар сегодня рынок готов оплатить, вопросы управления клиентом тут не единственные на первом плане, это же не компания в сфере услуг b2c)

Ответить
2

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

Просто перед тем как внедрить такие штуки, надо подумать кто с ней будет работать и есть ли у этого человека навыки.

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

BI - круто, но ели не приносит пользы - вы купили графики и эстетическое удовольствие. ERP - еще серьезней и аналитику там строить не всегда удобно.

Есть только одна большая проблема - риск. Если вы не знаете почему уходят деньги, вы пытаетесь их сократить, и это с вероятность 50/59 неверно.  Надо знать где искать раздутые платежи, подбирать альтернативу и прочее и до бесконечности. Кроме того, нужно еще и определять ценность расходов и платежей, и что они дают. К примеру "Офис того же ВК один из самых дорогих в СПб - отличная возможность сэкономить верно? Но ведь он там не случайно, да и на стоимость компании несильно влияет. Так почему же он все еще там? Там же не дураки, все знают. Вот именно, знают. Потому что бренд и потому что престиж и возможности для промо в центре города. Потому что сотрудникам удобно и комфортно, а они генерят больше прибыли, к тому же реже опаздывают(условно). И вот тут мы считаем все за и против и принимаем решение о конкретной экономии, что мы потеряем, если переедем, сколько будет стоить переезд по деньгам и времени, и что получится в итоге и сколько мы выиграем на дистанции. Добавим риск(что люди могут подумать, что у компании плохо с деньгами как репутационную потерю и вот и выходит, что переезд даст нам 0,006% прибыли в год. Занесли, сохранили формулы - чтобы через год пересчитать и перешли к другому сомнительному платежу".

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

Ответить
2

Столько информации, спасибо!

Ответить
1

интересный кейс и взгляд на бизнес-проблемы, спасибо;
поделитесь пожалуйста своим опытом - в каких инструментах (эксель?) делали экономические расчеты для обоснования, что делать с конкретным SKU или его "фичами/элементами-SLA-продукта" (как считали стоимость владения своими продуктами), насколько это было понятно и просто/сложно сделать?

Ответить
1

Для начала нам пришлось донести саму концепцию до ключевых стейкхолдеров. В частности, крайне важно было найти общий язык с офисом продаж и развеять миф, что на расходы влияют только явные запросы в разработку. В конце статьи я как раз и пишу, что именно мы сейчас делаем с точки зрения работы с СКЮ.
По паре позиций стоимость владения оценили врукопашную и очень грубо. Чтобы ее посчитать уже точно и автоматически нам надо разметить свои статьи расходов неким новым образом - сейчас просто нет нужных тегов в ERP системе. Так что тут мы еще далеки от финиша.
Ну а про инструменты: совсем базовые вещи считали буквально в экзеле. А дальше планируем все это увести в PowerBI.

Ответить
2

спасибо, в целом ясно; удачи вам в построении своей кастомной и эффективной системы управленческого учета и планирования юнит-экономики по-продуктно - без нее сегодня (и особенно в бизнесе с большой и гибко-меняющейся продуктовой матрицей) никуда, иначе никогда так и не понять почему выручка есть, а прибыли нет (это классическая проблема отсутствия УУ и хорошего BI к нему); вы уже начали этот путь, не останавливайтесь! :)

Ответить
1

Отличная статья :)

Ответить
0

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

Ответить
0

Не пробовали рассмотреть и разложить ситуацию по Голдрату?
Разработки, которые не продаются = складские запасы, что является не очевилными затратыми. И сам процесс "разработал-внедрил-продал достаточно, чтобы окупить разработку и поддержку" должен иметь бутылочное горлышко.

Ответить
0

Мы неоднократно использовали мыслительные процессы Голдрата при анализе ситуации. При этом мы много лет убеждались, что узкое место - разработка :) И продолжали вкладывать силы в ее развитие.
Прийти через этот анализ к цене владения строчкой в каталоге мы не сумели. Инструменты ТОС предполагают объективные рассуждения о целевой системе, но когда ты находишься внутри тебя легко может унести в сторону из-за "замыленного глаза". 

Ответить
0

Другой вопрос. Не думали, что факт наличия в каталоге 200 позиций создает бренд, что позволяет продавать то что продается, и если оптимзировать каталог и оставить там 20-30 ключевых позиций, то их объем продаж сократится?
Самый простой пример. Есть люди, которые заказывают товар на АлиЭкспресс не потому, что там самый хороший и/или дешевый товар, а потому что там очень большой выбор. Причем в реальности заказывают ограниченный набор товаров, а остальное просто смотрят, выбирают и получают от этого удовольствие.

Ответить
0

Думали. И это основной риск, который заметно усложняет принятие решения: часть изделий были изначально разработаны как PR-повод или одолжение для конкретного клиента. Их исчезновение заметно усложнит жизнь продажников. Так что тут надо очень аккуратно подходить к убийству "ненужных" изделий.

Ответить

Комментарии

null