Полная транскрипция
Conor Doherty: Это разбор цепочки поставок, и сегодня мы разберем, почему ваша цепочка поставок является капитальными затратами, а не операционными расходами.
Меня зовут Конор. Я директор по коммуникациям в Lokad, и ко мне в студию слева, как всегда, присоединился безупречно одетый Жуаннес Верморель.
Прежде чем мы начнем, пожалуйста, оставьте комментарий ниже: во-первых, откуда вы смотрите, а во-вторых, согласны ли вы — является ли ваша цепочка поставок капитальными затратами или операционными расходами?
Это очень простой вопрос — или нет? Давайте перейдем сразу к делу.
Итак, Жуаннес, я вернулся из отпуска. Во время отпуска, как и все хорошие сотрудники, я пересмотрел все твои лекции.
Как знают давние последователи Lokad, у Жуаннеса есть давняя серия лекций. Это, конечно, ужасный способ провести отпуск, но я отклоняюсь от темы.
Но я понял, как монетизировать своё время, и, если быть серьезным, я действительно пересмотрел некоторые из них.
И одной из них была «Доставка, ориентированная на продукт, для цепочки поставок», и это было давным-давно.
Думаю, это было где-то в 2017 году, и в ней содержится настоящая жемчужина идей.
Их много, но одна, в частности, поразила меня, где ты утверждал — и именно это вдохновило меня — что следует пересмотреть подход к цепочке поставок: не как к операционным расходам, не как к расходу, не как к обязательству, а скорее как к производительному активу, который снова способен генерировать ценность, как машины, автомобили и тому подобное.
Итак, мой первый вопрос: правильно ли я в общих чертах понял основную идею?
Joannes Vermorel: Да. И когда я говорю «цепочка поставок», я имею в виду именно ту часть процесса, где принимаются решения, а не инфраструктуру цепочки поставок. Да, склад очевидно является активом, но здесь речь идет о системе, или об организации, или о процессе, или о том, что генерирует все рутинные решения в цепочке поставок, которые должны приниматься ежедневно. Что мне закупать? Где производить? Куда размещать запасы? Стоит ли повышать или понижать цены?
Эта система — та организация, которая генерирует все эти решения — рассматривается как актив? И да, моя точка зрения заключается в том, что в современном общем подходе, абсолютно нет. Цепочка поставок — управленческая часть, часть принятия решений — является чистыми операционными расходами. Это центр затрат. Это всё, что необходимо, знаете ли, сколько бы планировщиков ни требовалось, чтобы просто выполнить работу, и вот опять.
Conor Doherty: Итак, давайте будем предельно ясны и максимально конкретны. Какие именно поведенческие особенности отделяют то, что вы сейчас предлагаете, от современного состояния дел? То есть, в конкретных терминах?
Joannes Vermorel: Конкретно, единственная часть, которая воспринимается как капитальные затраты — это лицензии на программное обеспечение от какого-либо поставщика корпоративного ПО, поддерживающего процессы принятия решений. Но это, я бы сказал, в контексте капитальных затрат и производительных активов проявляется очень слабо в мире цепочек поставок, поскольку эти компоненты корпоративного ПО чрезвычайно требовательны к рабочей силе. Фактически, можно даже рассматривать их как вещи, которым нужны человеческие сопроцессоры. То есть у вас есть системы; ваши системы ежедневно требуют огромное количество персонала для принятия решений, касающихся операционной деятельности.
И причина, по которой я говорю, что это не капитальные затраты, заключается в том, что они не являются приростными. Вы инвестируете мандаты сегодня, каждый день, чтобы поддерживать поток, и это нечто, что не является капиталистичным. Вы тратите деньги, и вам приходится тратить их снова и снова, и, спустя двадцать лет, вам всё равно придётся делать то же самое. Таким образом, это бесконечно потребляет рабочую силу. В этом нет ничего по‑настоящему приростного с точки зрения капитализма. Это как если бы вам нужно было заправлять грузовик; вам нужно вкладывать рабочую силу в эти части корпоративного ПО. Вот почему я говорю, что в целом компании рассматривают свою цепочку поставок как чистые операционные расходы — если не учитывать небольшую деталь с лицензией корпоративного ПО, которую, по‑крайней мере, в бухгалтерском учёте можно считать активом — но это всё же очень слабый актив.
Conor Doherty: Распространяется ли эта точка зрения на весь спектр? Ограничивается ли она только специалистами по цепочке поставок, или вы утверждаете, что даже на уровне операционных директоров, финансовых директоров и в бухгалтерии они будут видеть это именно так?
Joannes Vermorel: Множество центров затрат внутри компании придерживаются точно такого же подхода. Они, например, воспринимают бухгалтерию — то же самое. Это просто чистые операционные расходы. Это просто затраты на ведение бизнеса. Вам нужно иметь определённое количество ресурсов в виде бухгалтерского персонала. Возможно, ваше бухгалтерское программное обеспечение является небольшим активом, но это означает, что оно, безусловно, не является по‑настоящему производительным активом. Это не машина для получения дополнительной прибыли или дохода. Это не машина для зарабатывания денег.
Знаете, вот в чём разница между активом и обязательством: будет ли эта приобретённая вами вещь генерировать деньги сама по себе? Если посмотреть на бухгалтерию, то ясно, что нет. Это необходимо, да, но будет ли она генерировать деньги? Нет. Это чистый центр затрат. И вот суть проблемы. Моя точка зрения заключается в том, что классический взгляд на цепочку поставок — то есть на процесс принятия решений — заключается в том, чтобы рассматривать её как чистый центр затрат, где ежедневно расходуются мандаты: компании такого размера нужно столько мандатов, чтобы поддерживать поток, и всё.
Conor Doherty: Мы обсудим последствия этого и, снова, конкретно как будет работать цепочка поставок как актив. Но сразу: вы упомянули, что решения генерируют деньги. Вы сказали, что это противоречит, то есть является противоположностью, — извините — текущему мышлению. Есть ли примеры, прямо с самого начала, решений — вы упоминали решения — примеры ежедневных решений в компании, которые меняются, когда вы начинаете рассматривать цепочку поставок как капитальные затраты, а не как операционные расходы?
Joannes Vermorel: Идея заключается в том, что если вы начнёте думать о капитальных затратах, вам нужно сделать шаг назад. Вместо того чтобы думать: «Я плачу людям за принятие этих решений», вы начинаете думать: «Я плачу этим людям за разработку системы, которая сама генерирует решения». И это совершенно иначе, потому что это означает, что если вы перестанете платить этим людям, система продолжит генерировать прибыльные решения.
И это может быть что-то столь же обыденное, как пополнение запасов. Если оно выполнено правильно, это, очевидно, прибыльная операция: вы превращаете доллары в физические запасы, а эти запасы затем конвертируются обратно в доллары. Если эти решения принимаются автоматически, это как машина по печати денег. Такие решения принимаются с прибылью в интересах компании, независимо от того, вкладывают ли люди дополнительное время или нет. На практике вам приходится платить за электричество и за несколько других вещей, чтобы поддерживать работу программного обеспечения, но в принципе, когда вы механизируете процесс целиком, затраты на его эксплуатацию составляют лишь малую долю по сравнению с тем, чтобы люди выполняли ту же работу.
Если посмотреть на конвейер, перемещение вещей по нему требует затрат — электроэнергии, обслуживания и так далее — но это такая малая доля по сравнению с тем, чтобы люди вручную переносили предметы.
Conor Doherty: Думаю, мы сразу перейдём к обсуждению цепочки поставок как актива, потому что, как мне кажется, для многих, когда речь заходит об активах, они всё ещё застряли на концепции физических активов. И ещё, о чём мы говорили много раз — и это моя формулировка, вы можете её подкорректировать — цепочка поставок представляет собой географически распределённую сеть участников. У вас есть поведение, есть цены. Опять же, это существительные, но абстрактные. Таким образом, цепочка поставок состоит как из физических, так и из абстрактных концепций. Как же объяснить её статус актива, учитывая, что она и физическая, и абстрактная?
Joannes Vermorel: Представьте это как машину для принятия решений. У вас есть эти большие машины, в которых задействованы и компьютеры, и люди, и они генерируют эти решения. Я имею в виду, что если вы воспринимаете это как актив, вы думаете: «Хорошо, я инвестирую время, чтобы сделать машину лучше», и, опять же, поскольку это машина, если вы перестанете инвестировать — то есть тратить время людей — машина останется прежней, хотя должна оставаться неизменной.
Просто сравните эти два подхода: они кардинально различаются с точки зрения капитальных затрат. Когда мы механизируем решения по цепочке поставок — то есть рассматриваем её как капитальные затраты — на самом деле реальность такова: когда специалисты по цепям поставок уходят в отпуск, всё остаётся в порядке. Решения продолжают приниматься. У нас есть люди, контролирующие процесс; есть люди, готовые прийти на помощь в экстренной ситуации, но реальность такова, что если мы перестанем инвестировать на неделю, все решения всё равно будут приниматься, а если мы вернём человека, это делается для дальнейшего улучшения. Именно на это тратится время: оно направлено на непрерывное улучшение, и это улучшение является стабильным. Вот почему я говорю, что это капитальные затраты — потому что они приносят прирост. Вы тратите определённое количество дней, чтобы сделать машину лучше, а затем, если вы позволите машине работать, она будет работать самостоятельно. Немного как конвейер: да, ему требуется обслуживание; да, он не полностью автономен — это правда — но мы говорим о разнице в порядках величин.
Так же, как если вы прекратите обслуживание вашего конвейера на один день, он всё равно будет работать нормально. Вам не нужны люди, постоянно вносящие коррективы. Если для работы вашего конвейера нужно, чтобы кто‑то всегда находился рядом с ним, то это плохой конвейер. Он не выполняет свою роль как производительный актив; он должен работать в основном самостоятельно.
Conor Doherty: Вы затронули вопросы улучшения и ухудшения — ведь можно улучшить или ухудшить работу машины. Вы привели пример с конвейером, который работает функционально; это довольно обыденная функция, и, я полагаю, существует определённый потолок того, насколько можно его улучшить или оценить как актив. Я хочу углубиться в это. Каков предел увеличения или обесценивания этого актива цепочки поставок? Ведь, если это актив, он подвержен как росту, так и падению его стоимости; иначе это не актив.
Joannes Vermorel: Да. И здесь в принципе нет верхнего предела, потому что, когда вы входите в сферу принятия решений, обычно не существует потолка. Если вы определяете проблему как узкое пополнение запасов того, что уже продано, тогда да, существует потолок: оптимальное пополнение повысит прибыльность вашей компании только до определённого уровня. Это может быть значительным, но предел есть.
Но если вы расширите это понятие решений — например, когда решать ввести новый продукт; когда определять, сколько инвестировать в продвижение конкретного продукта и тому подобное — тогда всё становится очень размытым, и я бы сказал, что явного предела нет. Да, могут быть ограничения, но реальность такова, что когда вы находитесь в сфере процессов принятия решений, ограничения практически отсутствуют.
Опять же, если сравнить это с, скажем, бухгалтерией: если у вас отличный бухгалтер, всё будет хорошо; если вы обратитесь к лучшему бухгалтеру в мире, разница с отличным бухгалтером не будет столь существенной, просто потому что речь идёт о соблюдении норм, а не о принятии решений. Так что, если вы произвольно ограничиваете сферу этих решений — скажем, рассматриваете цепочку поставок как способную выполнять только ограниченный перечень задач — тогда да, существует потолок. Но если вы расширяете эту сферу, то явного потолка уже нет, и тот факт, что на рынок продолжают выходить компании, обгоняя своих прежних доминирующих конкурентов, доказывает, что, очевидно, существует способ принимать лучшие решения, чтобы опередить соперников. Каждая компания, которая недавно стала гигантом, доказала, что каким‑то образом существует лучший путь.
Conor Doherty: Проще говоря — и исправьте меня, если я не прав — то, что определяет решения, это доступные данные, какая бы информация ни была. Так что чем больше людей выходит на рынок, чем больше поставщиков появляется, чем активнее ценовые действия ваших конкурентов — всё это меняет границы: что можно сделать завтра по сравнению с тем, что можно было сделать вчера, и что возможно сегодня, поскольку ситуация меняется. С этой точки зрения, если у вас есть инструменты для интеграции всей этой информации в вашу цепочку поставок — в ваш актив — нет верхнего предела того, насколько хорошим, а под «хорошим» я подразумеваю финансово выгодным, может стать решение, потому что сегодня вы заработали один доллар прибыли; завтра, благодаря незначительному изменению в обстоятельствах глобальной цепочки поставок, это может стоить доллар и десять центов; вы можете добиться ещё большего.
Joannes Vermorel: Дело в том, что если взглянуть на другие области — скажем, маркетинг — становится совершенно очевидно, что нет верхнего предела тому, насколько хорошей может быть маркетинговая фраза. «Just Do It» от Nike очень известна; они заработали миллиарды благодаря этой фразе. По сути, нет предела тому, насколько хорошим можно быть в маркетинге. Конечно, на практике очень сложно превзойти конкурентов, и люди, способные быть по‑настоящему гениальными, крайне редки. Но, в сущности, я говорю, что это та проблема, у которой нет никаких очевидных ограничений, и если вы посмотрите на аутсайдеров — и снова, мы в сфере принятия решений, креативности, изобретения — вы можете переосмыслить основу ваших решений. Это даёт вам огромную свободу, и вот почему я говорю, что явного предела нет. Но это не значит, что у вас отсутствуют практические ограничения. Да, у вас есть практические пределы, которые определяются вашей способностью вообще мыслить или разрабатывать систему, которая будет генерировать эти супер-решения.
Conor Doherty: С точки зрения инженерного обеспечения системы существует два подхода к её организации. С одной стороны, есть, скажем, специалисты по данным, специалисты по цепочкам поставок или специалисты по принятию решений, которые непосредственно пишут код. Но существует и инженерное обеспечение условий в компании, которое позволяет этому происходить. Если сосредоточиться на последнем — на действиях операционных директоров (COO) и финансовых директоров (CFO) — то какие шаги они могут предпринять, чтобы создать более благоприятную или продуктивную среду для такого рода мышления?
Joannes Vermorel: Я думаю, что отправной точкой является проведение базовой оценки затрат, которые вы тратите на принятие решений — в широком смысле на цепочку поставок, включающую планирование, прогнозирование, S&OP, все рутинные управленческие задачи, такие как управление производством, управление запасами, управление дистрибуцией и так далее. По сути, это все те люди, которые работают с электронными таблицами.
Вам следует задать себе вопрос: трачу ли я деньги в стиле CapEx? То есть, трачу ли я эти деньги потому, что они действительно необходимы, иначе поток остановится, и завтра ситуация останется точно такой же — мне снова придется платить, потому что по сути ничего не изменилось? Или я трачу деньги на дальнейшую автоматизацию, на улучшение автоматизации или даже на начало автоматизации? Просто начальный пункт, перед тем как задумываться о мельчайших деталях инженерии — о том, как именно это сделать и т.д. — заключается в следующем вопросе: тратятся ли эти деньги на улучшение машины принятия решений, независимо от того, какое соотношение компьютеров и людей у вас в этом процессе? Или я просто трачу деньги, как топливо для грузовика, чтобы он продолжал работать, что, однако, не изменит ничего в грузовике, когда топливо иссякнет?
Моя основная мысль такова: если вы проведете эту базовую оценку, то в большинстве компаний вы обнаружите, что почти все средства расходуются в виде OpEx. Это как 99% трат, буквально направленных только на поддержание работы двигателя. Улучшения двигателя происходят очень, очень редко. Улучшение двигателя случается только раз в пять лет, когда внезапно оплачивается крупный корпоративный софт для обновления или что-то в этом роде. Но это действительно неверный способ мышления, потому что он слишком слаб. Это означает, что вы фактически относитесь к своей цепочке поставок как к чистому OpEx каждый день, за исключением редких случаев, когда поступаете иначе. Я бы отстаивал позицию, что CapEx должен применяться каждый день. Каждый день любые ваши затраты должны быть направлены на улучшение этого актива, а не один раз в голубую луну, вроде как два раза в десятилетие, когда вы решаете выбрать одного поставщика вместо другого.
Conor Doherty: На этой ноте это идеальный переход. Вы описываете «каждый день» — примите менталитет CapEx, а затем каждый день относитесь к своим расходам так, как если бы это был CapEx. Хорошо. В качестве примера актива: если я покупаю дом, то, конечно, невозможно с абсолютной точностью определить его стоимость, но существуют способы оценить его — «Я заплатил полмиллиона год назад; вот за дом аналогичного размера с похожим энергетическим рейтингом в этом районе продан за такую цену; похоже, что мой актив вырос на 10% или уменьшился на 5%» — и так далее. С точки зрения цепочки поставок как CapEx или как актива, как именно вы предлагаете измерять прирост стоимости и/или амортизацию этого класса активов?
Joannes Vermorel: Это чрезвычайно сложно, потому что, по сути, речь идет о контрфактах. «Если бы моя цепочка поставок управлялась другой системой, насколько бы она была прибыльной или убыточной?» Это делает исследование довольно затруднительным. Тем не менее, на практике это не так сложно, поскольку можно взглянуть на все основные показатели эффективности: оборачиваемость запасов, рентабельность, списание запасов, общее качество обслуживания и т.д. Если ваша система хорошо отлажена и совершенствуется, эти показатели должны улучшаться.
Снова, необходимо учитывать контрфакты, поскольку, например, ваше улучшение может нивелироваться тем, что вдруг у ваших поставщиков начнут возникать серьезные проблемы, и ваши сроки поставки значительно увеличатся с момента начала работы. Вам нужно учесть все эти факторы. Создать метрику сложно, но, в основе, хотя это и трудно, это та же проблема, с которой сталкивается каждый поставщик программного обеспечения. Кстати, существует причина этой схожести: если вы рассматриваете свою цепочку поставок как систему, генерирующую решения, то, по сути, вы имеете дело с программным активом.
Просто подумайте, как Microsoft определяет, что, когда они тратят такую сумму на улучшение Microsoft Word, они действительно улучшают его. Проблема становится очень размытой; трудно точно понять, на что именно вы тратите ресурсы для совершенствования инженерии — что конкретно улучшается? Тем не менее, даже если это сложно, прогресс вполне ощутим и реален. Если вернуться к любому программному обеспечению, достаточно попробовать версию, выпущенную два десятилетия назад, и вы поймете: «О, эта версия двадцать лет назад была отвратительной, а нынешняя — значительно лучше». Если только поставщик ПО не замедляет свое развитие, это типичный путь, который можно наблюдать.
То же самое должно происходить и с вашей цепочкой поставок, то есть эта система должна вести вас к состоянию, когда становится все меньше областей, где требуются человеческие сопроцессоры. Это один из параметров, который можно измерить очень просто. Вы также можете оценить, насколько глубокими являются ваши решения. Например, способны ли вы работать с мульти-сорсингом или по-прежнему полагаетесь на очень грубые эвристики выбора поставщиков, при которых мульти-сорсинг невозможен? Действительно ли ваша система перезаказа умна — с полными грузовиками, полными контейнерами — или нет? Можете ли вы действительно воспользоваться скидками, которые предлагают ваши поставщики, и так далее?
Существует множество случаев, когда — даже если у вас никогда не будет реальных контрфактов того, что произошло бы без этого улучшения — вы все равно можете провести простые расчеты: «Хорошо, в прошлом квартале нам удалось действительно улучшить наших эвристик для перевозок полными контейнерами; раньше мы этого не делали; теперь это делается достаточно аккуратно, и я могу оценить, что дополнительная отдача примерно такова». Это приблизительно, но когда улучшение реально, убедиться в получении ощутимых результатов не составляет труда. Если практически невозможно определить какой-либо ощутимый результат, вероятно, ваше улучшение было нереальным; это была просто идея, а не что-то, что действительно принесло пользу вашей компании.
Conor Doherty: Когда мы говорим об эвристиках, одной из вещей, к которой люди часто стремятся при любой цифровой трансформации, является повышение устойчивости, и люди часто рассматривают активы как устойчивые к потрясениям. Например, каждый раз, когда рынок рушится, золото начинает расти. Видите ли вы в перспективе цепочки поставок как CapEx какой-либо конкретный прирост устойчивости перед лицом таких событий, как, скажем, COVID, инциденты в Суэцком канале или что-то подобное? Если можно сравнить, например, подход A/B — перспективу OpEx в таких ситуациях и перспективу CapEx.
Joannes Vermorel: Да. Если вы работаете в режиме OpEx, это означает, что вы фактически пытаетесь оптимизировать использование своих ресурсов. Что это значит? Это означает 100% загрузку ваших ресурсов, то есть людей. Таким образом, ваши сотрудники работают на 100% для поддержания потока. Если же они задействованы только на 70%, то вы теряете 30% их времени, когда они ничем не заняты. Вот в чем заключается проблема подхода с OpEx: вы стремитесь к 100% загрузке.
А как же быть в случае нарушения работы? При возникновении нарушений, ввиду их самой природы, вам, очевидно, придётся сталкиваться с необычными ситуациями, что потребует — поскольку у нас ещё нет общего искусственного интеллекта — участия людей по умолчанию. Вы создали систему, но эта система не обладает сознанием; она не способна самостоятельно справляться с экстраординарными обстоятельствами и будет вынуждена полагаться на людей в таких случаях. Вопрос: будут ли эти люди вообще доступны для решения подобных проблем?
Мой ответ таков: если вы находитесь в режиме OpEx, то на самом деле все работают на пределе своих возможностей. Один из симптомов этого: в компании все заняты тушением пожаров, и директор по цепочке поставок одновременно решает пять чрезвычайных ситуаций в день. Это признак очень высокой загрузки — постоянное тушение пожаров, когда люди несколько перегружены объемом работы, что регулярно доходит до высших уровней управления.
В отличие от этого, если вы находитесь в режиме CapEx, сотрудники тратят время на улучшение системы. При возникновении нарушений они просто приостанавливают свою работу — работу по улучшению — и переключаются на ликвидацию ущерба, поскольку они не задействованы на полную мощность лишь для поддержания рутинной работы. Вот почему, с точки зрения устойчивости, именно CapEx, который я пропагандирую, дает вам большое пространство для действий в чрезвычайных ситуациях, потому что люди не работают на 100% исключительно для выполнения рутинных задач. Буквально, они могут — если вы работаете в режиме CapEx, где у вас есть система, генерирующая решения — все могут уйти в отпуск на неделю, и если только это не критичный момент при изменении тарифной политики, всё будет в порядке. Если вы не находитесь в тот самый момент, когда наступает хаос, всё будет нормально, что означает, что если хаос всё же наступит, эти люди смогут сразу приступить к решению проблемы ликвидации ущерба, а не будут полностью утопать в повседневной рутине.
Conor Doherty: Развивая эту тему, я думаю, что это может быть из той же лекции — или, возможно, это часть 1.4 — где речь идет об оперативности и ответственности системы принятия решений. Когда происходят такие события, вы не хотите собирать сотню людей в одной комнате или на звонке в Teams. Вы хотите, чтобы система — актив — могла быстро адаптироваться к этим шокам.
Joannes Vermorel: Это и есть вторая часть ответа. Если у вас есть эта система, то при масштабном нарушении объем того, что нужно подправить, будет огромен. Если у вас десятки людей, которых нужно перенастроить, адаптировать их политики и так далее, это займет много времени. Даже если вы чрезвычайно старательны, это займёт недели. Если же ваши решения управляются по сути программным обеспечением, вы можете за несколько часов — может, максимум за день или два — импровизировать что-то примитивное, что хотя бы обеспечивает ликвидацию ущерба в масштабах.
Это то, что, посмотрите, мы реализовывали множеством способов за последнее десятилетие. Те сотрудники, у которых есть возможность переключиться на ликвидацию ущерба, когда возникает необходимость действовать, не станут следовать рабочим процессам, которые не соответствуют чрезвычайной ситуации, потому что эти процессы оптимизированы для повышения продуктивности в повседневных задачах, как вы их обычно выполняете. Вы можете напрямую зайти в код и внедрить свои эвристики для решения проблемы в масштабах, и как только вы перезапустите систему, она сгенерирует обновленные решения, учитывающие эту новую реальность.
Чтобы привести пример, они могут сказать: «Что, если, например, компания внезапно потеряла доступ к финансированию, потому что крупный банк, обслуживавший компанию, отменил большую кредитную линию?» Таким образом, за одну ночь объем ликвидности, доступной компании, скажем, сократился в два раза. Внезапно возникает проблема с ликвидностью. У вас появляется проблема: недостаточно денег, чтобы купить всё, что необходимо.
Вопрос: как вы пересматриваете, от начала до конца, все ваши закупочные политики, чтобы они соответствовали этой новой реальности — хотя бы на некоторое время — до тех пор, пока кто-то из финансового отдела не найдет другой источник ликвидности? Если у вас люди, это будет очень сложно; это займёт недели. Если же у вас есть система и числовой алгоритм вместе с экономическими драйверами, вы просто скажете: «Хорошо, стоимость наличности — бац — увеличиваю этот коэффициент, может, в 10 раз, просто потому, что у меня кризис ликвидности», и это автоматически исключит любые решения, которые в краткосрочной перспективе не приведут к положительному денежному потоку для борьбы с этой проблемой нехватки ликвидности.
Conor Doherty: Спасибо. Прежде чем перейти к публичным комментариям и нескольким личным сообщениям, еще одна мысль. Мы говорили об активе; обсуждали перспективу мышления в терминах CapEx, но, как я уже писал, вы не остановились на конкретном упоминании инструментов, техник или методологий, которые определяют этот подход — с технологической точки зрения — что заставляет этот актив расти в цене?
Joannes Vermorel: Мы буквально говорим об улучшении программного обеспечения. На практике, когда я говорил о «системе» — с участием компьютеров и людей — это по сути большой программный проект. Я считаю, что цепочка поставок, если к ней подходить современно — эта игра по принятию решений — по своей сути является игрой, основанной на ПО.
Теперь нужно подумать: как сделать такое программное обеспечение, которое будет полностью специфичным для моей компании? Вот в чем загвоздка: оно не может быть универсальным, потому что должно полностью учитывать конкретные источники данных, которые у вас есть, и конкретную стратегию, которой вы следуете. В масштабах — если рассматривать компании стоимостью, скажем, в сто миллионов долларов и более — нет двух абсолютно одинаковых компаний. Всегда существует различие. Каждая крупная компания занимает свою собственную экономическую нишу.
Таким образом, эта система будет специфичной для вас. Это не означает, что не может быть общих моментов или повторного использования компонентов, но, в основе, поскольку вы объединяете все источники данных и стратегию компании, это программное обеспечение будет, в основном, полностью специфичным для данной компании. В Lokad мы обслуживаем десятки и десятки компаний, и в каждой свои числовые алгоритмы, потому что, даже если компании похожи, мы обнаруживаем, что существуют существенные различия.
Conor Doherty: Когда вы употребляете термин «числовые алгоритмы», вы по сути имеете в виду сам актив — алгоритм, генерирующий решения.
Joannes Vermorel: Именно. Термин «числовой рецепт» является расплывчатым. Он может включать множество алгоритмов, множество эвристических правил, множество компонентов — некоторые очень умные, некоторые не столь. Это буквально все «сантехническое оборудование», которое проходит от всех входных данных до решений, которые вам необходимо сгенерировать, и так можно представить этот актив.
Конор Догерти: Ладно, Йоаннес, продолжу, ведь мы говорим уже около тридцати пяти минут. Это — я просто прочитаю это как комментарий; я не вижу вопросительного знака, так что прочитаю, а ты выскажешь своё мнение. Это от — прости за моё произношение — Гав. Надеюсь, я правильно произнёс: “Насколько я понимаю, позиционирование инвестиций в цепочку поставок как CapEx подчёркивает, что построение устойчивых сетей, автоматизация и цифровые платформы являются долгосрочными активами, которые укрепляют конкурентоспособность, а не просто ежедневными расходами.” Предполагаю, ты с этим согласен.
Йоаннес Верморель: Абсолютно. И ты должен действительно рассматривать это как средство для достижения цели. Не думай: «Я инвестирую в какую-то платформу данных». Ты инвестируешь в машину, которая будет принимать более прибыльные решения. Имей в виду: соответствует ли эта инвестиция видению создания более прибыльных решений?
Потому что у тебя есть еще один момент, когда у тебя много компонентов корпоративного программного обеспечения, которые абсолютно не приносят капиталистической выгоды. Пример: у тебя есть цифровой двойник цепочки поставок — эффектно, но если он не генерирует решения ежедневно, то это всего лишь гаджет, и возможно, дорогой. Единственный способ считать его продуктивным активом — если он генерирует решения ежедневно, в большом объеме, и эти решения приносят прибыль, делающую актив продуктивным и прибыльным.
Конор Догерти: Думаю — и, как всегда, поправь меня, если я ошибаюсь — ключевая деталь здесь, и именно поэтому я всегда вмешиваюсь, когда поднимается эта тема, — это «в большом объеме», потому что масштаб имеет решающее значение.
Один человек может справляться лучше или на уровне алгоритма в одном конкретном решении, но если тебе нужно обрабатывать 50 000 решений каждый день, это уже значительно больше возможностей одного человека.
Йоаннес Верморель: А еще у тебя возникает проблема: это опять же OpEx. Хороший специалист может быть очень хорош, но его возможности для улучшения с течением времени ограничены. Хорошие практики в цепочке поставок известны с 1970-х. APICS, Ассоциация по управлению цепочками поставок в США, преподает эти принципы десятилетиями. Надо быть реалистами в том, какого улучшения можно ожидать. Это не та область, где кто-то станет значительно продуктивнее завтра: по существу, это те же числовые рецепты, та же практика.
Нельзя ожидать, что при ручном выполнении будет достигаться столь значительное улучшение. Так что да, масштаб имеет значение — но это то, что программное обеспечение дает по умолчанию. Если программа разработана правильно, она может обрабатывать решения в любом объеме.
Конор Догерти: Хорошо, спасибо. Продолжаю. Если числовой рецепт — то есть система принятия решений — является активом, кто владеет версионированием, откатами и контрольными механизмами, и как ты управляешь обесцениванием модели, когда меняются рыночные динамики?
Йоаннес Верморель: Да, числовой рецепт — не единственный актив. В Lokad у нас есть еще нечто столь же важное: то, что мы называем совместным руководством процесса, то есть большой свод руководящих принципов для инициативы. Числовой рецепт показывает что — буквально, как я генерирую свои решения ежедневно — и отображает, что происходит на каждом этапе. Это код: код демонстрирует, какие расчеты выполняются. Совместное руководство процесса — предназначенное для людей — объясняет почему: зачем мы выбрали именно такой способ подготовки DR? Почему мы решили использовать эту модель, а не другую? Почему мы выражаем экономический драйвер таким или иным способом?
Сочетание двух элементов — что и почему — именно и составляет активы. Числовой рецепт очень важен, но это лишь половина картины. Документ, объясняющий почему, также критически важен, потому что он является отправной точкой для понимания того, что ты хочешь улучшить. Если видишь: «Почему я так сделал? О, это грубая аппроксимация, потому что не было времени сделать что-то лучше; оставим так», — то в этом и заключается причина — это документация, которая также подскажет специалисту по цепочке поставок, «если и тогда».
Абсолютно, нужна система версионирования кода, аудит; должен быть процесс выпуска. Идеально, если будет множество процессов для проверки того, что поступает корректно, а что выходит правильно, и так далее. Кто должен этим управлять? Ответ: цепочка поставок. Это должно находиться в ведении управления цепочками поставок. В конечном итоге ответственность лежит на директоре по цепочке поставок или главе отдела цепочки поставок, ведь именно он отвечает за принятие решений в этой области. Это не может быть IT, потому что, по сути, они генерируют решения в области цепочки поставок. В конечном итоге ответственность лежит на том, кто за это отвечает, как и ответственность маркетинга за разумное расходование бюджета на Google AdWords.
Да, расходы на Google AdWords могут требовать множество инструментов, но в конечном итоге маркетинг решает, стоит ли делать ставку на определенное ключевое слово и сколько, и так далее. Они должны брать на себя свою ответственность. То же самое применимо и здесь.
Конор Догерти: Это уже немного более технически. С точки зрения финансового директора (CFO), какие конкретные доказательства ты бы показал аудитору, чтобы обосновать капитализацию твоего движка принятия решений вместо учета их как операционных расходов? Или это в первую очередь философская позиция, а не строгий бухгалтерский учет?
Йоаннес Верморель: С бухгалтерской точки зрения, это не обязательно. Некоторые компании так поступают — например, среди софтверных компаний некоторые решают капитализировать средства, когда их инженеры-разработчики тратят время на это. Другие не поступают так. Это больше вопрос бухгалтерской ясности. Что касается финансового директора, я бы сказал: не увлекайтесь тем фактом, что можно сразу капитализировать вложенные средства, потому что если так сделать — кстати, это проблема, с которой сталкиваются софтверные компании — возникает слишком оптимистичная картина расходов на этот проект.
Если, в бухгалтерских терминах, когда вы тратите миллион долларов на программное обеспечение, вы говорите: «Не волнуйтесь, стоимость актива автоматически увеличивается на миллион долларов», то вы столкнетесь с очень странной проблемой, которая не отражает реальную ситуацию. Мое мнение — относитесь к этому с осторожностью. С бухгалтерской точки зрения, посмотрите, как ведется учет в софтверных компаниях, и придерживайтесь этих общих принципов, которые различаются в зависимости от страны.
Это, по сути, философский принцип: инвестирую ли я деньги в то, что даст рычаг для воздействия? Трачу ли я деньги только для того, чтобы выжить сегодня, или я инвестирую, чтобы завтрашний день был лучше? Когда я говорю CapEx, ты должен подумать: я трачу деньги, время и усилия только на те вещи, которые сделают завтрашний, послезавтрашний — и будущее в целом — лучше.
И действительно, это обесценивается — это абсолютно верно. Как правило, в Lokad, по моему опыту, это обесценивается довольно быстро. У нас в Lokad каждые два-три года мы полностью переписываем наши числовые рецепты. Так что это не бесконечно долгоживущий актив, но все же, это имеет огромное значение, когда ты говоришь, что актив будет обесценен в течение трех лет, в отличие от такой ситуации, когда, если перестать тратить, поток решений просто останавливается. Даже если у нас пока нет актива, который прослужил бы десятилетиями, он может просуществовать несколько лет — иногда немного дольше в компаниях, которые не подвергаются чрезмерным изменениям. Очевидно, степень изменений действительно ускоряет обесценивание.
Конор Догерти: У меня больше нет вопросов или комментариев. Но прежде чем закончить, сегодня мы рассмотрели множество тем. Последний призыв к действию для всех, кто нас слушает сейчас и тех, кто послушает это позже.
Йоаннес Верморель: Обязательно убедитесь, что каждая инвестиция в вашу цепочку поставок способствует улучшению этой машины принятия решений. Это ваш главный вывод. Рассматривайте вашу организацию цепочки поставок как машину для принятия решений. Забудьте про корректные прогнозы, корректное планирование, корректные бюрократические задачи. Эти вещи — лишь побочные эффекты; они не приносят прибыль. Единственное, что приносит прибыль — это решения, которые вы принимаете и внедряете.
Вы должны думать о своей организации как о машине для генерации этих решений и задаваться вопросом: идут ли деньги, которые я инвестирую, только на поддержание работы машины — как электричество или топливо — или это инженерные усилия, направленные на ее совершенствование? Мое мнение таково: да, это сочетание того и другого. Для большинства компаний это буквально почти 100% на поддержание работы машины — чистые операционные расходы, — а раз в десятилетие происходит крупная капитальная инвестиция с поставщиком. Я считаю, что это неправильно. Вы должны подходить к этому гораздо более постепенно, потому что, когда речь идет об интеллектуальных начинаниях, эта ежедневная капля инвестиций дает гораздо больший возврат, чем раз в десятилетие вливание миллионов, а затем ничто в течение десятилетия. Такие методы «включи-выключи» работают очень плохо и являются хорошим способом сделать поставщиков корпоративного ПО богатыми, но не вашу компанию прибыльной.
Конор Догерти: Ладно, Йоаннес, вопросов больше нет, и, думаю, время истекло. Как всегда, большое спасибо за твои ответы, и всем остальным — спасибо, что были с нами.
Спасибо за ваши вопросы и за личные сообщения. Знаю, что некоторые из этих тем являются достаточно чувствительными, поэтому иногда люди стесняются публично выражать свои истинные чувства. Но я говорю от нашего имени: мы действительно ценим получение таких сообщений, и те, кто задавал вопросы приватно, поймут, что некоторые из заданных мной вопросов были направлены личным образом.
Иными словами, не бойтесь обращаться к нам. А на этом, возвращайтесь к работе.
