Почему проваливаются цифровые трансформации цепочки поставок (Эрик Кимберлинг) - Ep 181

00:00:00 Эрик Кимберлинг и вступление Third Stage
00:04:31 Сосредоточенность на людях, а не на технологиях в проектах
00:06:14 Правильное определение рамок цифровых трансформаций
00:08:08 Преодоление инкрементализма в трансформациях
00:10:53 Предвзятость поставщиков может сбить с толку усилия
00:12:40 Проблемы принудительных переходов в облако
00:14:46 Низкая ценность обновления систем или записей
00:19:26 Чувствительность систем и влияние трансформаций
00:21:38 Уязвимости крупных компаний при трансформациях
00:23:39 Проблемы руководства увеличивают склонность к избеганию рисков
00:26:22 Отсутствие стратегической перспективы в трансформациях
00:29:42 Важность понимания механизмов работы систем в руководстве
00:32:42 Задержки в данных затрудняют распределенные вычисления
00:35:42 Высокая стоимость обработки терабайт данных
00:38:38 Анализ рисков технологических трансформаций
00:41:43 Футуристические стратегии цифровых трансформаций
00:44:25 Сбалансированность бюджетов проектов и возврата инвестиций
00:47:42 Реалистичные ожидания затрат при трансформациях
00:50:58 Избыточное количество функций программного обеспечения мешает продуктивности
00:53:29 Сосредоточение на бизнес-процессах, а не на технологиях
00:56:39 Внутреннее управление технологическими трансформациями
00:59:45 Бюрократия при реализации стратегического планирования
01:02:48 Управление предотвращает хаос в цепочках поставок
01:06:27 Комплексная перестройка для амбициозных трансформаций
01:09:34 Оптимизация капитальных затрат для создания ценности в цепочке поставок
01:12:20 Неэффективность нынешних трансформаций
01:15:28 Использование данных поставщиков для конкурентного преимущества
01:18:11 Финансовые стимулы, влияющие на продуктивность
01:21:13 Преследование перспективных разработок в области программного обеспечения
01:23:19 Избегайте дорогостоящих неудач, признавая безвозвратные затраты

Резюме

В обсуждении цифровых трансформаций цепочки поставок Эрик Кимберлинг и Жоанн Верморель подчеркивают частые неудачи, вызванные давлением со стороны поставщиков и несоответствием приоритетов. Кимберлинг, руководитель Third Stage Consulting Group, выступает за стратегии, независимые от технологий, делая акцент на потребностях бизнеса, а не на простом обновлении программного обеспечения. Он предупреждает о поспешных решениях, продиктованных поставщиками, которые часто не приводят к трансформационным результатам. Верморель акцентирует внимание на важности использования существующих систем с инновационными дополнениями вместо радикальных замен. Оба лидера подчеркивают необходимость согласования усилий по трансформации с конкретными бизнес-целями и выделяют управление изменениями как ключ к успеху. Они выступают за постепенное, осознанное внедрение технологий, обеспечивая четкое определение целей и контроль рисков.

Расширенное резюме

При анализе причин неудач цифровых трансформаций цепочки поставок крайне важно учитывать мнения, высказанные ведущими отраслевыми специалистами, такими как Эрик Кимберлинг и Жоанн Верморель, в их недавнем диалоге, проведенном Конором Дохерти. Оба, Кимберлинг и Верморель, обладают огромным опытом в проведении компаний через тернии технологических перемен, и их взгляды раскрывают важные истины, зачастую упускаемые организациями, начинающими подобные преобразования.

Эрик Кимберлинг, выдающийся мыслитель в области технологий, возглавляет Third Stage Consulting Group — компанию, специализирующуюся на предоставлении независимых и нейтральных с точки зрения технологий консультаций для организаций, стремящихся к успешным цифровым трансформациям. Его фирма действует с ясной целью: предоставлять клиентам объективные рекомендации, в которых потребности бизнеса ставятся выше пустых технологических обновлений. Подход Эрика подчеркивает необходимость того, чтобы трансформации фокусировались не только на технологических решениях, но и на всесторонних организационных изменениях, охватывающих процессы и людей, а не только технологии.

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

Жоанн Верморель, основатель enterprise software, делит программное обеспечение на «системы учета», «системы отчетности» и «системы аналитики», утверждая, что трансформации не должны узко фокусироваться на системах учета, приносящих минимальную дополнительную ценность. И Верморель, и Кимберлинг признают альтернативные стратегии компаний, таких как Palantir и Snowflake, которые совершенствуют существующие системы без радикальной замены, подчеркивая стратегическое преимущество адаптации текущей инфраструктуры с помощью инновационных дополнений.

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

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

При определении успешных случаев Кимберлинг и Верморель подчеркивают важность ясности и краткости в плановых документах. Вместо громоздких презентаций PowerPoint, сжатые текстовые планы способствуют более глубокому пониманию и облегчают ясное общение между заинтересованными сторонами. Они восхваляют достоинства подхода к инвестициям в технологии как к капитальным затратам — оценивая их как долговременные активы, а не как простые операционные расходы.

По мере завершения диалога оба участника вновь подчеркивают, что, хотя трансформации, основанные на технологиях, могут служить сильным катализатором развития бизнеса, их успех зависит от тщательного баланса между внедрением программных инноваций и поддержкой организационных изменений. Кимберлинг советует начинать эти трансформации с постепенного и осознанного подхода, обеспечивая строгое определение целей перед ускорением реализации. Верморель соглашается, продвигая постепенные внедрения и подход «fail fast», который смягчает риски и оставляет пространство для адаптации.

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

Полная расшифровка

Conor Doherty: С возвращением на Lokad. Сегодня я рад провести беседу между Эриком Кимберлингом и Жоанном Верморелем. Эрик – генеральный директор и основатель Third Stage Consulting Group, и сегодня он присоединяется к нам, чтобы поделиться своим уникальным взглядом на то, почему так много цифровых трансформаций терпят неудачу в цепочках поставок. Пока вы здесь, если вам нравится наша работа на Lokad, обязательно подпишитесь на Lokad TV на YouTube. Подожду.

Conor Doherty: Хорошо, спасибо. А также следите за нами в LinkedIn, и на этом я представляю вам сегодняшнюю беседу с Эриком Кимберлингом. Прежде всего, Эрик, большое спасибо, что присоединились к нам, и добро пожаловать на Lokad.

Eric Kimberling: Спасибо, что пригласили. Приятно быть здесь.

Conor Doherty: Итак, Эрик, прежде чем мы перейдем к сути нашей беседы, должен отметить, что вы очень популярны в интернете. На самом деле, я впервые наткнулся на вас в LinkedIn. У вас достаточно большая аудитория, и вы также активны на YouTube. Однако наша аудитория в основном европейская, поэтому, возможно, они не так хорошо знакомы с вами. Не могли бы вы вкратце рассказать для тех из наших зрителей, кто не из Северной Америки: чем занимается Third Stage Consulting Group, как вы оказались здесь и так далее?

Eric Kimberling: Да, Third Stage Consulting Group — это консалтинговая фирма из США, специализирующаяся на цифровых трансформациях. Ключевым аспектом нашей бизнес-модели является наша независимость и технологическая нейтральность. Мы помогаем клиентам на всех этапах: от разработки цифровой стратегии и оценки и выбора программного обеспечения до планирования внедрения, а также управления программой реализации и управления изменениями.

У нас около 100 консультантов. У нас даже есть небольшой офис в Европе, базирующийся в Великобритании, который обслуживает регион EMEA. Таким образом, вы правы, что мы пока не так широко представлены в Европе, но наша цель — иметь там такое же присутствие, как и в Северной Америке. На самом деле, я основал компанию в 2018 году, потому что почувствовал, что на рынке недостаточно консультантов, действительно нейтральных в отношении технологий, объективных и представляющих интересы клиентов.

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

Conor Doherty: Когда вы упоминаете традиционную модель консалтинга, полагаю, что технологическая нейтральность играет в этом ключевую роль, но не могли бы вы подробнее объяснить, что вы имеете в виду? Это красивое выражение, но что вы подразумеваете под технологической нейтральностью?

Eric Kimberling: Конечно, технологический атеизм — мне тоже нравится этот термин, он даже лучше. Но, собственно, технологическая нейтральность означает, что мы не получаем комиссионных от поставщиков программного обеспечения. Другими словами, мы зарабатываем деньги непосредственно от наших клиентов, а не от производителей ПО. И это очень важное отличие, поскольку большинство консалтинговых фирм либо получают прямые стимулы от поставщиков для расширения их присутствия на рынке или в регионе.

У них есть резерв ресурсов, сфокусированных на одной технологии, и их цель — задействовать этих консультантов в проектах, связанных с этой технологией. Такая предвзятость формирует подход «технология прежде всего» при трансформациях, в то время как, по моему мнению, самые успешные трансформации, будь то в цепочках поставок или при внедрении ERP, управляются потребностями бизнеса и определением стратегии и дорожной карты, соответствующих этим потребностям, а не исходным выбором технологии с последующим поиском способов её интеграции в бизнес. Это может показаться незначительной деталью, но на самом деле это имеет большое значение и является важным фактором, определяющим успех или неудачу на рынке.

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

Eric Kimberling: По сути, мы определяем это как технологическое обеспечение всего предприятия. Это не только про технологии; возможно, даже важнее является операционная и организационная сторона, процессы и работа с людьми.

Когда мы рассматриваем определенные технологии, большинство людей начинают с решения, что им необходимо заменить свою технологию. Обычно проблема формулируется так: “Нам нужно заменить какую-либо технологию”. Эта технология может быть системой управления цепочкой поставок, ERP-системой, CRM или системой управления взаимоотношениями с клиентами; это может быть HR-система, финансовая система, а теперь, когда ИИ становится настолько важным, и ИИ, или бизнес-аналитика.

Таким образом, существует множество различных технологий на выбор. На наш взгляд, когда речь заходит о цифровой трансформации, это довольно широкое и расплывчатое понятие. Оно охватывает множество различных аспектов и технологий, и, что более важно, слово “цифровая трансформация” может вводить в заблуждение, заставляя думать, что речь идет исключительно о технологиях. На самом деле такие проекты обычно касаются значительно больше работы с людьми, а не технологий.

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

Joannes Vermorel: Я полностью согласен, прежде всего, с важностью технологической нейтральности, если вы хотите давать качественные советы. Это абсолютно фундаментально; в противном случае проблема будет сформулирована таким образом, что будет способствовать расширению присутствия того, кто уже вошел в рынок как поставщик. Это означает, что проект сводится к вопросу: как обновить ERP этой компании с версии N до N+1. В итоге это выглядит как рецепт для огромных инвестиций с минимальными результатами.

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

В отличие от линейного прогресса, перехода от версии N к версии N+1, что обычно является очень сложным вопросом, потому что, например, вы можете подумать: “Ладно, у нас так много людей, которые занимаются этим, этим и этим,” но оказывается, что, возможно, если бы мы были лучше организованы, нам вообще не пришлось бы выполнять эти задачи с самого начала. Поэтому нет смысла пытаться оптимизировать то, что они делают, ведь лучшая организация вообще не нуждалась бы в этом. Так что я вижу в этом вызов, чтобы действительно обдумать бизнес. Что вы на самом деле достигаете?

А затем вам необходимо хорошо разбираться в технологиях, в том, на что они способны, а что нет. Но я бы сказал, что это отдалённое второе место по сравнению с очень ясным пониманием бизнеса и того, чего вы стремитесь добиться. Мне очень нравится этот подход, и я считаю, что для меня самая большая проблема большинства компаний, думаю, в Европе, но, возможно, и в США до некоторой степени, в этой цифровой трансформации заключается в проклятии поэтапности. Они действительно думают о том же самом с несколькими дополнительными функциями, или хотят тот же ERP, но с веб-интерфейсом вместо десктопного, или что-то в этом роде.

И для меня, да, это было бы неплохо, но в основе своей ROI таких дорогостоящих проектов не оправдывает затраты. Вы не обновляете ERP только потому, что устали от его некрасивого интерфейса. Если он работает, значит, он работает, даже если он не выглядит красиво. Если вы хотите обновляться и тратить на это годы, вам нужно иметь нечто такое, что значительно улучшит вашу компанию после этого, а не просто сделать инструмент более привлекательным, а саму компанию изменить. Это было бы моим пониманием того, что на самом деле означает подлинная и правильно выполненная цифровая трансформация.

Эрик Кимбелинг: Да, это отличная точка зрения, потому что вы затронули несколько действительно важных моментов. Один из них заключается в том, что вы говорили о планировании и ранних решениях, которые принимаются, и о том, как они задают траекторию проекта. Это совершенно верно, и многие организации, как мне кажется, думают: “Давайте просто поспешим с этими решениями, начнём проект, а затем разберёмся со всем по ходу дела.” И именно здесь всё становится запутанным, и отсутствует ясность направления.

Но ещё один момент, на который вы намекаете, заключается в том, что иногда нормально сказать: “Мы не будем обновлять нашу технологию.” Что если вы не перейдёте на самую новую и модную систему? А что, если вы вместо этого оптимизируете то, что у вас уже есть? А что, если вы сосредоточитесь на модификации ваших бизнес-процессов для их оптимизации? А что, если вы обучите людей лучше пользоваться программным обеспечением? А что, если вы реализуете все эти малозатратные меры, которые приносят чрезвычайно высокую ценность с низким риском для организации? Почему бы не рассмотреть это как вариант?

Теперь поставщики программного обеспечения категорически не согласятся со мной. Если бы я был поставщиком программного обеспечения, я бы сказал, что это ужасная идея; вам нужно обновить все технологии, вам нужно перейти в облако, вам нужен ИИ, вам нужно всё это, потому что я пытаюсь продать вам технологию. Но если отступить на шаг и убрать эмоции, и исключить пристрастие поставщиков, многие организации придут к выводу: “Знаете что? Нам не нужно спешить с переходом в облако только потому, что наш поставщик говорит, что у нас установлен жесткий срок.”

И я считаю, что очень важно взять трансформацию в свои руки и строить её на основе потребностей вашего бизнеса, ваших приоритетов, ваших стратегий, а не на основе интересов поставщиков программного обеспечения.

Конор Дохерти: Эрик, если я могу добавить, и я не хочу подставлять слова тебе в рот, но подразумевается ли, что людей, возможно, несколько вводят в заблуждение консультанты или поставщики, и это приводит к провалам цифровой трансформации? Если нет, то каковы, по твоему мнению, наиболее распространённые причины неудач цифровых трансформаций?

Эрик Кимбелинг: Да, это отличный вопрос. Мы могли бы провести всё интервью, обсуждая только этот вопрос. Но если резюмировать, я бы сказал, что да, предвзятость, безусловно, является значимым фактором провала. Если я консультант по программному обеспечению и подхожу с узким взглядом на то, что именно эта технология нужна для интеграции в вашу организацию, вы уже создали несоответствие, потому что я не начинаю с вашего бизнеса, а начинаю с моей технологии.

Моя технология имеет лучшие практики; у неё есть встроенные рабочие процессы; вам нужно подстроиться под моё программное обеспечение, потому что моё программное обеспечение замечательное. Это просто вызывает крайне разрушительные процессы из-за такого подхода. Так что я считаю, что предвзятость является частью проблемы; это значительный фактор. Но, по моему мнению, ещё большим фактором, который многие не осознают, является то, что многие из этих крупных поставщиков программного обеспечения, как SAP или Microsoft, по сути, принуждают своих клиентов к обновлению до новой технологии, говоря: “Мы прекратим обслуживание и поддержку вашей старой системы; мы прекратим её поддержку в эту дату, и у вас есть время до этой даты, чтобы перейти на новую систему, иначе мы отрубим поддержку.”

И я считаю, что это чрезвычайно безрассудно; это не проблема, ориентированная на клиента. По сути, здесь проблема поставщика превращается в проблему клиента. Проблема поставщика заключается в том, что нам нужно перейти в облако, потому что это более прибыльно для нас; наши инвесторы требуют этого. И поэтому эта проблема становится проблемой клиента, потому что теперь они говорят: “Эй, я знаю, возможно, вы только что внедрили решение для локального использования два года назад, но угадайте что? Мы прекращаем поддержку этой системы, которую вы только что внедрили; мы прекратим поддержку через два или три года, и у вас есть время до этого момента, чтобы перейти на новую систему.”

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

Конор Дохерти: Йоаннес, я знаю, что ты огромный поклонник поставщиков и защищаешь их до конца, но можно ли попросить тебя прокомментировать это?

Йоаннес Вермо렐: Да, мой взгляд таков: я разделяю мир корпоративного программного обеспечения на три различные царства. У нас есть системы учёта, системы отчетности и системы интеллекта. Системы учёта касаются, в первую очередь, ввода данных и рабочих процессов. Это всё, что связано с управлением в системе учёта, которая может быть CRM, ERP (которую следовало бы назвать ERM, управление корпоративными ресурсами, потому что планирование — это второстепенная задача), TMS, системами управления перевозками и так далее. Все эти управленческие системы являются системами учёта.

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

Системы учёта, и я замечаю, что в этих цифровых трансформациях многие обсуждения касаются обновления систем учёта, которые уже в определённой мере фиксируют всё необходимое. Так что для меня добавленная ценность такого рода трансформации, которая обычно поглощает свыше 80% бюджета, почти равна нулю, потому что ваши рабочие процессы уже налажены. Они уже работают. Ваше программное обеспечение, то есть, следующий интерфейс, не изменит ничего, поскольку речь идёт лишь о вводе данных и подобном.

И если у вас это есть, и оно работает, и функционально охватывает всё необходимое, то вы вроде как закончили. И я считаю, что проклятие этих корпоративных поставщиков заключается в том, что они понимают, особенно такие компании, как SAP, что работа уже выполнена. Задача для системы учёта была завершена два десятилетия назад.

А теперь, кстати, вы можете объяснить весь переход SAP HANA в направлении “О, давайте трансформируем это”, что из системы учёта превратить её в систему отчетности с всевозможными аналитическими слоями. Но мой анализ таков: вы должны просто оставаться при своём выборе. Вы — система учёта. И затем, когда бизнес смотрит на это в таком ключе, они говорят: “Нам не следует инвестировать в это, потому что следующая версия принесёт только баги, регрессии, новое обучение, если только старые системы не были невыносимыми из-за чрезмерной медлительности, множества ошибок или неспособности зафиксировать необходимые записи. Тогда добавленной ценности нет.”

И для нас в цепочках поставок это действительно важно, потому что я встречал много клиентов, у которых системы управления запасами существуют уже 30 лет. Это черно-белые текстовые консольные экраны, но функционально они выполняют 100% того, что требуется этим компаниям. А управление запасами, знаете, не ракетостроение. Я беру что-то, плюс-минус одна единица на полке. Я ставлю что-то на полку, плюс один.

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

Эрик Кимбелинг: Согласен. И я думаю, что поэтому такие компании, как Palantir и Snowflake, — некоторые из этих систем, я не хочу говорить, что это системы, которые присоединяются к чему-то, но это системы, созданные для взаимодействия с другими системами учёта. Таким образом, можно сказать: “Ну, моя система учёта, возможно, устарела, но она работает, и я не хочу проходить через весь риск, затраты и усилия по замене этой системы учёта. Но я хочу лучшей отчетности. Я хочу лучшего интеллекта. Возможно, я хочу некоторые возможности ИИ. Но я хочу это без необходимости… Мне не нужно выдирать систему учёта с корнями.”

Таким образом, компании, такие как Palantir, Snowflake и другие, создают решение, которое говорит: “Оставьте вашу старую систему. Нам всё равно. Мы предоставим вам решение, которое не вмешивается в неё. Вместо этого оно просто строится на её основе и дает вам лучшие рабочие процессы, лучший ИИ, лучшую отчетность, лучший интеллект — всё это.”

Так что, я думаю, вы правы. Это те варианты, о которых часто не знают организации и команды. У них есть варианты, потому что другие поставщики говорят: “Нет, нет, нет, вам нужно заменить вашу систему учёта, потому что она работает на устаревшей технологии. У вас есть технический долг. Вы отстанете.” Знаете, это продажа на основе страха. И это работает.

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

Йоаннес Вермо렐: Беззастенчивая реклама, это именно бизнес-модель Lokad. Она построена точно так же, как у Palantir или Snowflake. Мы делаем именно это по этим причинам. Но, конечно, я не хотел заставлять тебя говорить это. Но да, это моя точка зрения. Проблема этих систем учёта в том, что когда вы их трогаете, уровень срыва в организации становится огромным.

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

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

Недавно во Франции крупная компания просто обанкротилась, GiFi, просто из-за, у меня, на самом деле, это отображается перед глазами, плохого управления цифровой трансформацией. Мульти-миллиардная компания, которая просто обанкротилась из-за неправильно проведённой цифровой трансформации.

Эрик Кимбелинг: Допустим, это также крупная известная компания во Франции, верно?

Йоаннес Вермо렐: Да, это была, скажем, одна из топ-10 розничных сетей по всей стране.

Конор Дохерти: Это на самом деле идеальный переход, потому что я действительно хотел перейти к тому, что ты часто комментируешь, Эрик, а именно — приведению примеров крупных компаний, о которых все знают. На самом деле, у меня перед глазами открыт список. Ты, например, писал и записывал про Lidl. Он у меня перед глазами: провал в 600 миллионов при попытке трансформировать их ERP-систему. Извините. Но также есть примеры по всему миру, не только в Европе.

У вас есть DHL, теряющая сотни миллионов, Lidl в Германии, теряющий полмиллиарда. Asda, GE, Spar. На самом деле, я помню, что видел и твое видео о Spar. Так что, снова, это огромные компании, поэтому это не локализовано только в Европе или только во Франции, например, или только в Вашингтоне или где-то ещё. Это почти как системное явление.

Слушайте, я не хочу вставлять слова в ваш рот, но если это действительно систематично для огромных компаний, то вопрос становится следующим: есть ли что-то уникально уязвимое в крупных компаниях, что приводит к этому? Им не хватает гибкости или что? Почему эти большие компании теряют так много денег?

Эрик Кимберлинг: Это отличный вопрос. Прежде всего, я не знаю. Я не смог бы вам ответить ни утвердительно, ни отрицательно. Да, я подозреваю, что у больших компаний, возможно, чуть выше уровень неудач, хотя скажу, что множество малых и средних компаний также терпят неудачу. Единственное различие в том, что о них не слышно, потому что никому нет дела до них.

Никто раньше не слышал об этих компаниях, а вот о Lidl, Spar Group, Asda — о любом известном имени — слышали. Но, чтобы ответить на ваш вопрос о том, почему большие компании более подвержены этим неудачам, я бы сказал, что динамика, которая свойственна крупной компании, действительно способствует неудаче, отчасти из-за организационного поведения. Отчасти это происходит потому, что большая компания, например, скорее всего внедрит большое, сложное решение, потому что она сама большая и сложная, и ей кажется, что нужно еще более большое и сложное решение.

Таким образом, они с большей вероятностью купят SAP или Oracle или какую-то другую крупную систему. И это уже становится фактором риска. Это сразу увеличивает ваш риск, потому что теперь вы пытаетесь внедрить большую, сложную систему.

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

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

Под этим я подразумеваю, что они говорят: “Если я внедрю SAP, то SAP — известный продукт. Если я найму Accenture, Deloitte или KPMG, это очень известные фирмы. Так что я покрою все базы и удостоверюсь, что нанимаю проверенные компании, чтобы чувствовать себя уверенно, ведь они — эксперты, они справятся с этим.”

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

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

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

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

Конор Дохерти: Спасибо, Эрик. Йоаннес, вы пару раз упоминали бюрократию в крупных компаниях. Не могли бы вы повторить эти мысли?

Йоаннес Верморель: Да, я имею в виду, что по моему мнению, малые компании могут потерпеть неудачу, потому что им не хватает ресурсов, чтобы иметь экспертов и тому подобное. Я считаю, что в больших компаниях, где неудачи происходят часто, есть все эксперты, но проблема в том, что они приходят с определенной программой. Все эти эксперты нанимаются, и у них есть свои собственные планы.

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

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

Что я имею в виду под механической симпатией? У них абсолютно нет интереса к тому, что происходит под капотом, как все это подключено, о чем вообще идет речь. Я не говорю о том, чтобы быть экспертом-программистом, но речь идет о том, является ли это чем-то вроде примитивного приложения — знаете, создание, чтение, обновление, удаление в базе данных, которая состоит из множества таблиц.

Или нам нужно реальное время? Что мы подразумеваем под реальным временем? Нам нужны микросекунды, миллисекунды, секунды или часы? Нам это нужно и так далее? То есть, существует множество относительно базовых вопросов, но если у вас вообще отсутствует то, что я называю механической симпатией, тогда объекты или программные объекты, с которыми вы работаете, становятся совершенно абстрактными.

И для вас это набор кодовых имен, которые вообще не имеют смысла. «О, нам нужен виджет ABC20, но чтобы запустить ABC20, нам также нужно обновить Contoso12». А Contoso12, о, ему ещё нужна штука номер семь и так далее.

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

Извините, это длинный ответ, но этот компонент механической симпатии отсутствует во многих компаниях. И для этого не требуется большого уровня экспертизы. Знаете, как человек, который любит автомобили, он просто уделит немного времени, чтобы узнать, что происходит под капотом, чтобы то, что машина едет вперед, не казалось волшебством. Есть определенное понимание основных строительных блоков, которые заставляют все работать.

Эрик Кимберлинг: Да, абсолютно. Это интересный термин. Я не слышал о механическом любопытстве, и, думаю, это возвращается к тому, что я часто упоминаю. Я думаю, они тесно взаимосвязаны, и это общее владение и любопытство к продукту в целом.

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

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

Меня поражает, сколько крупных организаций говорят: “Я не технолог. Я не несу ответственность, я позволю экспертам этим заниматься.” Но это бизнес-трансформация, и если вы делаете её правильно, это действительно бизнес-трансформация, и вам нужно быть вовлечённым, весьма вовлечённым.

Даже если вы не участвуете в техническом механическом любопытстве, вы, по крайней мере, должны участвовать в операционном любопытстве. Что это будет означать для моей организации? Как будут выглядеть мои операции? Как это повлияет на рабочие места людей? Мне это подходит, нормально, или я хочу чего-то другого?

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

Конор Дохерти: Если можно добавить, просто потому что я согласен с вами обоими, но хочу внести небольшое замечание, так как слышал, как вы несколько раз упоминали механическую симпатию. Недавно, в другом подкасте с Supply Chain Connect, привет, я говорил именно об этой концепции.

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

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

Йоаннес Верморель: Да, приведу, например, случай с LLM. Ладно, искусственный интеллект — это здорово, фантастика, значит, у нас есть эти большие языковые модели. Какова приблизительная стоимость загрузки одного мегабайта данных в LLM?

Прикинув, за один мегабайт, даже если взять дешевую модель, мы говорим примерно о $1, и это дешевая модель нижнего уровня. Каждый раз, когда вы хотите получить ответ, если вам нужно обработать один мегабайт данных на входе в вашу LLM, это будет стоить вам $1, даже с самой дешевой моделью.

Если вы будете помнить эту цифру, то поймете, что существует множество вещей, которые просто не выйдут из строя и останутся незамеченными, вероятно, более чем на десятилетие. Потому что если подумать: “Ладно, у меня терабайты данных, я не стану сразу обрабатывать их через LLM.”

А затем, если при каждом клике кому-то придется платить $1… То есть, вы проводите простейшие математические вычисления, которые показывают: ну это просто не сработает. Это экономически нецелесообразно.

Даже если цена упадет в 100 раз, мы все равно отстаем от чего-либо разумного на четыре нуля. Просто пример, и я видел много ситуаций, когда, обсуждая с потенциальными клиентами, я говорил: возьмите несколько базовых порядков величины, чтобы понять, о чем идет речь.

То же самое, например, и для распределенных вычислений. Распределенные вычисления сильно ограничены скоростью света. Люди спрашивают: “Зачем мне знать скорость света?” Но ответ таков: если у вас есть система, где ваш склад общается с центральной системой, и информация передается туда-обратно, у вас задержка в 200 миллисекунд.

Вы просто понимаете, что для выполнения задачи вам нужно тысяча циклов обмена данными. Тогда мы уже говорим о 200 секундах только на циклы обмена. Опять же, это не суперсложная математика, но именно такие вещи указывают на наличие проблемы в проектировании.

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

В таком случае люди поняли бы, что с учетом бизнес-целей это просто не сработает. Потому что технолог может сказать: “Ну, это займёт 200 секунд. Много вычислений требует времени, так почему бы не 200 секунд?”

Но тот инженер скажет: “Нет, это то, чего оператор ждет, так что это вообще невозможно.” Или LLM скажет: “О, это стоит $1 за мегабайт.” А инженер ответит: “Да, почему бы и нет? Это всего лишь ценовой ориентир, мне всё равно.”

Им всё равно, а затем бизнес говорит: “Но вы понимаете, что человек, за который платят примерно $20 в час, будет кликать это 60 раз в час?” Таким образом, стоимость вашего LLM будет примерно в четыре раза превышать зарплату того, кто им управляет.

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

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

Йоаннес Верморель: Да, и опять же, не стоит недооценивать то, что, по моему опыту работы с инженерами, они могут дать вам пять знаков точности, но запятая окажется чуть не там в расчётах.

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

Конор Дохерти: Чтобы убедиться, что я правильно понял, то, что вы упомянули ранее: терабайт — это миллион мегабайт, верно? Так что обработка по доллару за мегабайт будет просто…

Йоаннес Верморель: Терабайт — это тысяча гигабайт. Так что да, это миллион мегабайт. Таким образом, терабайт по тому ценовому уровню, о котором я говорил, будет стоить миллион долларов за терабайт для обработки.

Конор Дохерти: Просто хочу удостовериться, что я правильно понял.

Joannes Vermorel: Так что да, я имею в виду, если вы хотите это сделать, то, вероятно, вам изначально не хочется этого делать. А если уж вам абсолютно необходимо это сделать, то стоит удостовериться, что вам не придётся делать это чаще, чем раз в год, ведь, очевидно, даже для большой компании речь идёт о довольно экстравагантных ИТ-расходах.

Conor Doherty: Ну, да. Вообще, Эрик, если можно вернуться к этому, потому что общий посыл и общий контекст заключались в том, что чего-то не хватало. Но мне хочется вернуться к ещё одному моменту, который отсутствовал. Знаете, мы уже обсуждали механическую симпатию, но в этом контексте вы оба упомянули идею ROI, финансовой отдачи.

И ещё кое-что, что вы сказали раньше, Эрик, когда говорили о том, как крупные компании выбирают, какое программное обеспечение им понадобится, — “О, мы просто возьмем, как называется крупное имя? А какую большую консалтинговую компанию — возьмем, потому что, знаете, галочка стоит.” И вы заметили, что в таком контексте ROI зачастую не имеет значения. Теперь я знаю, что Жоаннес раньше говорил о финансовых KPI и ROI в цепочке поставок, но мне интересно: не могли бы вы немного разъяснить, почему, по вашему мнению, финансовая перспектива может быть менее представлена в цепочке поставок, чем, возможно, должна быть?

Eric Kimberling: Да, я думаю, что с тем, как технологии меняются так быстро и экспоненциально, это почти как ядерная гонка вооружений, где люди испытывают FOMO, знаете, страх упустить что-то важное. И они хотят быть уверены, что не страдают от технического долга и всех этих модных терминов, которые придумывают аналитики и поставщики программного обеспечения.

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

Мы утратили понимание всего этого. Мы просто не задумываемся, зачем нам вообще нужна эта технология. Зачем нам, например, переходить в облако? Иногда я спрашиваю об этом клиентов, и вижу недоумённые взгляды, типа: “Мы ведь сейчас работаем на своих серверах.” И я говорю: “Ладно, вы на собственном оборудовании. Так что может случиться худшего, если вы останетесь на нем еще на пять лет?”

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

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

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

Joannes Vermorel: Я считаю, что, во-первых, финансовые KPI вводят в заблуждение, потому что это не тот правильный подход. Ваш цифровой путь, так сказать, рассчитан на 10 лет. Вам нужно мыслить на 10 лет вперед — куда вы хотите прийти? Такие планы долговременны. Это, буквально, те компании, которые вы проектируете.

Таким образом, на мой взгляд, ориентация на краткосрочные KPI — не то, что действительно имеет значение для понимания, правильное ли это решение или нет. Если бы вы опирались на такие KPI, то это именно тот случай, когда Walmart в 2002 году сказал бы: “О, нет, электронная коммерция нам не нужна.”

Это тот тип мышления, который приводит к заключению: “Ладно, электронная коммерция актуальна; но она настолько мала, что нам не важна.” Нет, на самом деле она очень важна, и через несколько лет появится гигант, который окажется больше вас, если вы ничего не предпримете. Это был упущенный шанс цифровой трансформации. То есть, большая розничная сеть могла бы стать гигантом электронной коммерции; но этого не произошло, потому что они, в некотором роде, упустили цифровую трансформацию.

Но, возвращаясь к теме, я бы сказал, что я склоняюсь к мышлению с долгосрочной бизнес-перспективы. Есть ли у нас быстрый расчет, который доказывает, что это правильное решение? С учётом риска: каков, по вашему мнению, риск — 90%, 50% или 10% — и использование простых допущений для обоснования этого решения и движения в этом направлении.

А сейчас, как мне кажется, обычно не хватает следующего: я упоминал об инкрементализме. Люди воспринимают свою цифровую трансформацию как то же самое, только немного лучшее. Но если вернуться к примеру Walmart 2002, будущее — это электронная коммерция, так что это определённо не то же самое, что просто Walmart с чуть улучшенной точкой продаж с ЖК-экраном.

Видите ли, не так. Будущее принципиально отличается, и я думаю, что именно здесь компании обычно не делают достаточно, чтобы бросить вызов тому, каким будет их облик через 10 лет. Какие будут роли? Кажется, недавно по LinkedIn циркулировала очень интересная записка от CEO Shopify.

Он буквально говорил всем: “Мы приостанавливаем все наймы на данный момент, и каждое подразделение должно будет обосновать, что та работа, на которую они хотят нанять сотрудников, уже не может быть выполнена с помощью технологий ИИ, LLM и тому подобного, которые мы уже приобрели, внедрили и интегрировали в нашу систему.” Shopify — довольно технологичная компания, так что у них уже есть несколько лет опыта в этом.

И он говорил: “Ладно, у нас проблема с трансформацией. Суть записки заключалась в том, что высшее руководство не придерживается исключительно инкрементальных взглядов, а должно быть гораздо амбициознее в отношении конечной цели.” И я думаю, что посыл был очень интересным. Они не говорили: “Мы не инвестируем, не нанимаем.” Они говорили: “Вам нужна конечная цель, которая признает существование этих технологий, и вы не должны пытаться следовать траектории, которая делает вид, что их не существует.”

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

Думайте на 10 лет вперед: вам нужно представить себе такое будущее, в котором половина рабочих мест, особенно офисных, существующих сегодня, исчезнут. Это не означает, что вы просто увольняете людей; их можно переподготовить, перевести на другие задачи и так далее. Но сами рабочие места — как минимум половина из них через 10 лет просто исчезнут, и так будет.

Eric Kimberling: Да, и я думаю, что вы затрагиваете действительно важный момент для тех, кто возглавляет технологические или трансформационные инициативы в своих цепочках поставок или где бы они ни работали. Для них важно спросить себя: каким мы хотим видеть эту инициативу? Является ли эта инициатива заменой старых технологий для поддержания актуальности, что, возможно, является инкрементальным, с более низкими затратами, но потенциально с низким ROI? Или мы стремимся трансформировать наш бизнес, действительно его трансформировать, рассматривая новые бизнес-модели и инновации? Это два совершенно разных пути, и ни один из них не является однозначно правильным или неправильным. Просто нужно удостовериться, что вы согласованы и принимаете решения, соответствующие выбранному пути. Это не должно быть универсальным решением для всех; оно должно основываться на том, кто вы есть. Цифровая стратегия Shopify должна выглядеть совершенно иначе, чем ваша, моя или кого-либо ещё.

Joannes Vermorel: Я полностью согласен, но проблема, которую я вижу, заключается в том, что путь номер один — просто инкрементальное обновление с низким ROI — получает огромные бюджеты.

Eric Kimberling: Да.

Joannes Vermorel: Да, и для меня это выглядит так: как можно реализовывать проект, если при любом разумном приблизительном расчёте ваш ROI будет очень скромным? Зачем тратить деньги? Я видел компании — имена не буду называть — у которых на ERP-обновления свыше 100 миллионов долларов уходили проекты длительностью более пяти лет. Когда я обсуждаю это с топ-менеджментом, становится очень трудно понять, будет ли вообще какой-либо возврат — не только ROI, но и просто возврат. После обновления станет ли бизнес действительно лучше? Это даже неясно, особенно если вам приходится переходить на такие аппаратные требования, как у SAP HANA — я имею в виду, я просто упоминаю SAP; они не единственные.

Conor Doherty: Поднажми, всё в порядке.

Joannes Vermorel: Да, но если вы заморозите свою ИТ-систему на пять лет, упущенная выгода будет просто огромной. Это не может быть чем-то инкрементальным; должно быть нечто гораздо большее.

Conor Doherty: Так, Эрик, если я могу на этом остановиться, потому что, буквально, Жоаннес, что я только что написал — затраты первого порядка, затраты второго порядка, упущенная выгода — я буквально только что использовал те же слова, чтобы вернуться к вам. Эрик, как консультант, я вот-вот собирался спросить: как именно вы объясняете понятие затрат первого и второго порядка? Потому что, очевидно, затраты первого порядка: вы покупаете это программное обеспечение, это будет стоить вам 50, 100, 150 миллионов; вам придётся нанимать людей для контроля, что обойдётся в ещё какое-то количество миллионов. Это затраты первого порядка.

Затраты второго порядка — это, как только что сказал Жоаннес, упущенная выгода. Деньги, которые вы только что потратили, теперь нельзя потратить где-то ещё, ведь доллар, потраченный здесь, не может быть одновременно потрачен там.

Joannes Vermorel: Ваша ИТ-команда будет перегружена и застрянет на этом проекте на определённое время.

Conor Doherty: Это, опять же, относится к финансовой перспективе, о которой я говорил ранее. Как вы лично, находясь в комнате в роли технически агностика, помогаете людям понять — и я не хочу звучать снисходительно, я говорю буквально — возьмём доллар: если один батончик стоит доллар, а другой тоже за доллар, вы не можете купить оба за один доллар. Так что затраты первого и второго порядка, упущенная выгода — как вы объясняете эти понятия таким образом, чтобы они находили отклик у людей, у которых, как вы сказали, FOMO — они не хотят упустить возможность, хотят поймать волну и так далее?

Eric Kimberling: Вы намекаете на то, о чём мы ещё не говорили подробно — на реалистичные ожидания и наличие реалистичных ожиданий в отношении затрат первого и второго порядка. Я думаю, что коренная причина, или одна из коренных причин проблемы в том, что организации не понимают, каковы реальные затраты, и поэтому не могут оценить упущенную выгоду, потому что думают, что это обойдётся в 100 миллионов, когда на самом деле это никогда не стоило 100 миллионов; всегда стоило 300 миллионов. Но кто-то убедил вас, что это можно сделать за 100 миллионов, и этот кто-то завышал свои ожидания, занижал трудозатраты, зная, что есть сложности и риски, которые, вероятно, увеличат стоимость. Если подумать, когда поставщик ПО или решений продаёт вам продукт, ему невыгодно, с точки зрения собственной выгоды, переоценивать затраты. Им выгодно занижать их и говорить: “Нет, нет, это низкий риск, низкая стоимость.” Так что проблема начинается именно здесь.

Итак, если я говорю, что собираюсь оценить упущенную выгоду, затраты второго порядка, я делаю это на основе ошибочной информации. Даже если я это сделаю, это не имеет значения, потому что у меня нет точных данных для принятия решения. Но я думаю, что если бы больше компаний знали, каковы будут реальные затраты, они бы сказали: “Ого, подождите, это огромные суммы. Это деньги, которые мы могли бы потратить на строительство ещё одного завода. За эти же средства мы могли бы открыть 10 новых магазинов. Разве это то, что мы хотим?” Большинство организаций не доходят до этой точки, потому что основываются на заниженной оценке затрат, которая никогда не была реалистичной.

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

Так какова же стоимость этих сбоев и что, например, произойдёт, если вы не сможете отгружать продукцию в течение двух недель, четырёх недель, трёх месяцев? Такое случается с организациями: они проходят через эти проекты, что-то идёт не так, они запускаются в эксплуатацию, а потом не могут отгружать продукцию. Клиенты расстраиваются, заказы отменяются. Это реальные затраты. Именно эти затраты вы должны учитывать в расчёте ROI, чтобы оптимизировать внедрение, убедиться в правильном управлении проектом и понимать, каков реальный риск.

Conor Doherty: Вы подняли действительно важный вопрос, Эрик, и Жоаннес, я хочу вновь обратиться к вам, используя пример, который только что привёл Эрик. Если взять кого-нибудь — я никого не выделяю, — но если взять среднее значение, скажем, для автомобильной промышленности, аэрокосмической отрасли или нефтегазового сектора, и спросить: “Сколько стоит простой в час в виде потери производительности?” — они смогут дать приблизительную оценку, но те виды простоев, о которых только что говорил Эрик, им, возможно, не удастся точно количественно оценить.

Joannes Vermorel: Да, и я также считаю, что с операционными расходами всё полностью верно. Одна вещь, которую люди не осознают, заключается в том, что производительность снижается, когда растёт сложность вашей среды. Видите, у вас есть программное обеспечение; оно устаревшее, выполняет очень немногие функции, но выполняет те, которые вам действительно нужны. Это означает, что в моей IT-среде у моего пользовательского интерфейса не так много кнопок, не так много опций, не так много лишних деталей и возможностей, которыми я могу пользоваться. А теперь я обновляюсь до чего-то куда более мощного. Почему? Потому что у поставщика было столько пунктов, которые нужно было отметить в AFP. Мы спросили поставщика: “Должно уметь делать это, то, то, то, то, и то же самое”, хорошо, 100 пунктов спустя. Теперь у нас обновлённая система, которая дополнительно может выполнять кучу функций.

Но это означает, что для человека, управляющего программным обеспечением, появляется намного больше меню. И я видел это снова и снова в корпоративном ПО, когда люди показывали мне свою систему, а я говорил: “Это ужасно.” Ситуация выглядит так: у вас 30 меню, и когда вы нажимаете на любое из них, каждое меню содержит около 30 подменю, а, возможно, каждое подменю — ещё пять подподменю. А потом вы видите экран-стену с 20 различными опциями.

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

Каждая отдельная функция в системе, которую вы не используете, — это просто лишний груз. Это значит, что она будет сбивать с толку каждого нового сотрудника, который придёт и начнёт с ней работать. Они спросят: “Почему это не работает?” А ответ: потому что, например, для оформления заказов поставок существует пять разных экранов, а мы используем только один из них. Остальные четыре — просто тупики. Если вы вводите там свои данные, они не будут обработаны, а просто потеряются и будут игнорированы. Вот с чем можно столкнуться.

Eric Kimberling: Да, абсолютно. То, что вы говорите, действительно имеет смысл, и оно возвращает нас к вопросу: что вам вообще нужно? То есть, действительно ли вам нужна вся эта технология? Часто компании берут на себя больше, чем способны осилить, и переоценивают расходы на технологии. В результате возникает столько технической сложности, что у вас просто не остаётся ни времени, ни ресурсов.

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

Именно эти вещи решают, будет ли система или трансформация успешной или провальной. Но, тем не менее, компании чрезмерно вкладываются в технологии. Я предпочёл бы видеть компанию, которая закупает немного технологий, но внедряет их действительно качественно, потому что такая компания будет успешнее. Она снизит риск и, вероятно, получит лучший ROI.

И затем, когда вы это сделаете — кстати, как только вы осуществите эту небольшую технологическую инвестицию и внедрите её действительно хорошо — вы создадите уверенность, возможности и зрелость в организации, что позволит вам сказать: “Хорошо, теперь я возьмусь за более масштабный проект. Теперь я уверен, что мы достаточно научились и можем инвестировать в ещё немного технологий.”

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

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

Так что, Эрик, сначала к вам: скажу на более позитивной ноте, есть ли что-то, что вы заметили в успешных цифровых трансформациях, особенно в контексте управления изменениями, культуры, ожиданий и тому подобного? Что действительно помогает в этом?

Eric Kimberling: Да, я имею в виду, я вернусь к тому термину, который вы употребили — честность… вы сказали, что это была механическая симпатия или симпатия? В моей голове это была механическая любознательность. Оба термина работают, если честно. По сути, это почти одно и то же. Механическая симпатия — я понял, что перепутал ранее. Но механическая симпатия действительно имеет большое значение.

Потому что самые успешные проекты, которые мы видели, — это те, в которых бизнес-лидеры организации активно участвуют. Они понимают технологии; они могут и не быть экспертами в настройке и программировании (и им это не нужно), но они понимают, как работает технология. И они определённо понимают, как работает их бизнес и как они хотят, чтобы он работал.

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

Другое, что, пожалуй, связано с этим, заключается в том, что они не передают трансформацию на аутсорсинг. Они не просто говорят: “Мы привлечём крупных поставщиков и дадим им всё делать.” Они говорят: “Мы привлекаем экспертов, но будем ими управлять.” Так же, как вы бы управляли субподрядчиком или генеральным подрядчиком, если нанимаете кого-то для строительства нового завода.

Они, скорее всего, не скажут: “Нам всё равно, просто стройте завод, используйте лучшие практики, делайте всё, что нужно для строительства завода.” Нет, они будут активно участвовать, чтобы убедиться, что завод соответствует спецификациям и требованиям. Но в технологических проектах многие компании так не поступают. Так что успешные компании рассматривают технологические инвестиции и трансформации как обычные капитальные вложения.

Они не относятся к этому иначе; они ожидают ROI, ограничивают бюджет, активно участвуют и имеют значительное влияние на процесс. Всё это происходит заранее, и это важный фактор успеха.

Еще один момент — вернёмся к тому, что один из вас упомянул ранее, — о решениях, принимаемых на ранних этапах. Я не хочу сказать, что исполнение не имеет значения, потому что оно имеет, но ещё важнее то, что предшествует фактическому выполнению — решения, которые принимаются, приоритеты, устанавливаемые цели и согласованность.

Налаживание согласованности в команде, потому что часто, когда мы входим в зал с, скажем, семью руководителями и присутствует наше руководящее коммитет, и если я спрошу их: “Что означает эта трансформация для организации?” — обычно получаешь семь разных ответов. И ни один из них не является абсолютно правильным или неправильным, но все они различны, и так добиться успеха не получится.

Вы просто не достигнете успеха, независимо от того, кого вы наймёте, или какие технологии внедряете, если не будете едины. Это запутанный процесс, и теоретически он может замедлить проект в краткосрочной перспективе, потому что вы говорите: “Подождите, давайте остановимся с технологией, не будем это пока делать, сначала придём к согласию.”

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

Итак, эта согласованность и выделение времени на установление стратегических целей, параметров, приоритетов, бизнес-кейса, ожиданий, управления, определение будущих бизнес-процессов — какими мы хотим видеть наши процессы в будущем? Какой мы хотим видеть организацию? Всё это должно быть определено заранее, прежде чем вы начнёте внедрять технологии, и это действительно важный фактор успеха.

И последнее, что я упомяну, — это инвестиции в управление изменениями. Компании, которые вкладываются серьёзно, и когда я говорю “вкладываются”, я не обязательно имею в виду большие денежные суммы, я говорю о том, что они инвестируют своё время и внимание в организационные изменения, коммуникации, внедрение и ясность для всей организации. Всё это значительно повышает процент успеха.

Joannes Vermorel: Согласен с вашей историей. Фактически, в программном обеспечении, знаете, я тоже являюсь инженером-программистом. Существует поговорка: “О, я провёл три часа, размышляя о проблеме, которую хотел реализовать. Я потратил три часа, и это стоило мне трёх недель дополнительной реализации.”

Но возвращаясь к первоначальному случаю, я вижу, что многие крупные компании принимают идею: “О, да, нам нужно тщательно планировать.” Они слышали этот совет; мы не первые, кто это говорит. Так что они делают это, но я наблюдаю извращение этого подхода в их организациях, превращающееся в простое выполнение бюрократических процедур или заполнение чек-листов, типа: “О, мы на стадии планирования, значит, мне нужен этот отчёт, тот отчёт, эта валидация, этот аудит, эта диагностическая проверка и так далее.” И в итоге вы получаете не ясность; получается документ, который может состоять из тысяч страниц и не давать никакой ясности. Вот что я называю технократией.

Это фаза планирования, когда вы просто начинаете собирать материалы по всей организации, и каждый буквально переполняется выполнением запроса. Представьте себе: вы — совет директоров, и за месяц ваши команды собрали несколько тысяч страниц оценок, диагностики и т.п. И никто не понимает, о чём речь. Это немного похоже на пакетный закон о тратах в Конгрессе США — гигантский документ, состоящий из тысяч страниц, и никто не имеет понятия, что в нём написано.

Я считаю, что в этой фазе планирования следует осознать, что это не должно быть технократическим упражнением. Необходимо уметь сохранять ясность в документе, который, я бы сказал, не должен превышать от пяти до двадцати страниц. Если вы не можете изложить что-то ясно максимум на 20 страницах, а лучше — ещё короче, значит, вы просто заблудились в технократическом лабиринте.

Ваш дальнейший путь будет совершенно неверным. И я говорю о страницах, написанных текстом, а не слайдах PowerPoint, потому что в PowerPoint можно обмануть, используя лишь маркированные пункты — там отсутствует логическая связь, поэтому итог может получиться крайне неоднозначным. Если же вы пишете по-английски с правильными связками и переходами, обойти это невозможно; вам нужно, чтобы документ имел смысл и был таким, который можно зачитать вслух. Это примерно моё мнение по этому вопросу.

Eric Kimberling: Это отличный аргумент. И команда, которая осуществляет проект, тоже должна иметь эту ясность. Знаете, если подумать, например, о трансформации цепочки поставок — пусть ваша организация решит внедрить полную систему управления цепочками поставок. Легко потеряться в множестве сложностей и деталей.

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

Потому что, угадайте, что? Правительство США вводит все эти тарифы или существуют многочисленные геополитические обстоятельства, которые нам нужно учитывать, поэтому нам нужно лучше управлять поставщиками, и это наш фокус. Вам нужно установить приоритеты и сказать: “Мы это делаем, потому что хотим реформировать наши процессы управления поставщиками”, и действовать соответственно.

Если у вас нет этой ясности в документе от 5 до 20 страниц и вы не сможете добиться согласованности среди всех участников, то всё превратится в хаос, где каждый просто требует то, что, по его мнению, ему необходимо.

Joannes Vermorel: Кстати, для протокола, я видел множество компаний, и никогда не встречал качественных документов, кроме утёкших материалов от американских технологических компаний, таких как Amazon, Shopify, Apple — утёкших меморандумов, которые супер ясны, написаны на пяти страницах, прекрасно составлены. Видно, что руководство действительно отлично понимает, где оно находится, куда стремится и т.д., и пишет очень чётко и кратко.

Когда речь заходит о не-технологических компаниях, это чрезвычайно редко. Крайне редко. Мне, наверное, приходит в голову не более дюжины таких компаний. Например, меморандумы Berkshire Hathaway просто великолепны; всё предельно ясно: что они делают, зачем и как. Но обычно, в тех компаниях, о которых мы говорим, таких как Lidl и прочих, я абсолютно уверен, что никто не располагает простым меморандумом с изложением того, чего мы вообще пытаемся достичь, почему мы убеждены, что у этой инициативы есть хоть какой-то разумный шанс на успех.

Большинство крупных проектов, которые я наблюдаю — Lokad иногда участвует в них, знаете, они обновляют свою ERP-систему, обновляют аналитику цепочки поставок с нами. Это настолько редкое явление; именно поэтому я это упоминаю. Я почти никогда не вижу какой-либо степени ясности, когда речь идёт о цифровой трансформации. Всё сводится к слоям технократии.

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

Eric Kimberling: Интересно, действительно ли то, что вы говорите о технологических компаниях, заслуживает внимания. Я раньше об этом не задумывался или не проводил такой параллели. Знаете, возможно, технологические компании действительно способны и обладают большей зрелостью в предоставлении такой ясности.

Но иногда мне интересно, иногда я задумываюсь, знаете ли, что нынешние руководители — вы думаете о руководителях, которые выросли в технологическом пространстве, начиная, может быть, с 90-х, хорошо, может быть, они моего возраста или немного старше. Я помню, как появился Windows 98, и это было таким событием, когда Windows 98 вышел.

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

Интересно, думают ли руководители, которые выросли в IT-среде в то время, что технологические проекты похожи на обновление до Windows 98, и не осознают, что это не обновление до Windows 98. Это масштабный пересмотр не только ваших внутренних систем и баз данных, но и ваших процессов, вашего способа организации, и всего прочего.

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

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

Когда я думаю о цифровой трансформации для собственной компании, поскольку эти технологии, как вы упомянули, развиваются и многое меняется для Lokad, я вижу будущее через 10 лет, когда, возможно, более половины рабочих мест, которые у нас есть, будут заменены на уровне задач. Сотрудники останутся, без проблем, но они будут заниматься другими вещами.

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

Почти ни одна должность не исчезает, ни одна задача не устраняется сразу. Если подумать о том, что могут делать такие инструменты, как, например, ChatGPT, становится очевидно, что есть целые классы задач, которые, очевидно, можно автоматизировать.

Так или иначе, мое мнение таково, что цифровые трансформации очень часто не хватает амбиций; они чрезвычайно скромны. Единственное, что не скромно, — это бюджет, который у них есть на обновления.

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

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

Joannes Vermorel: Да, это мое личное мнение. Когда я смотрю на офисные профессии, если только в них нет чего-то по-настоящему особенного, я думаю, что это просто то, за что компания вынуждена платить, чтобы получить определенный результат в плане обработки информации. Офисный работник по сути принимает информацию и генерирует информацию, которая может принимать множество форм. Но многие люди, особенно в бэк-офисе — именно это они делают в крупных компаниях. Например, в цепочке поставок у вас есть люди, которые получают данные об уровнях запасов из их ERP и множество индикаторов недавних продаж и тому подобное, и что они решают? Они принимают решение для каждого отдельного SKU, единицы складского учета: “Нужно ли мне заказывать снова, да или нет?” У меня есть тысяча SKU, которые нужно контролировать. Организация устроена так, что один demand planner работает с, скажем, 1000 SKU. Всего у нас 80 000 SKU, так что это 80 специалистов по планированию спроса и предложения, и каждый из них ежедневно просматривает 1000 SKU и формирует заказ на replenishment на день. Многие компании организованы именно так.

Таким образом, мое мнение таково, что когда вы рассматриваете свою практику цепочки поставок в таком ключе, люди, которых вы нанимаете, являются чистым opex. Вам необходимо ежедневно выплачивать заработную плату, чтобы ваша компания продолжала функционировать. Если перестать платить этим людям, они перестанут работать, компания остановится, поток товаров прекратится. Если взглянуть на подход Lokad, он заключается в том, чтобы сказать: “Нет, мы должны рассматривать практику цепочки поставок как нечто, что является capex. У нас есть люди, которые разрабатывают программное обеспечение, так или иначе. Существует множество способов; низкий код, необязательно писать код, но вы разрабатываете программное обеспечение, которое автоматически генерирует решения о пополнении запасов.”

И затем, если вам нужно платить одному человеку больше, это делается для улучшения системы. В этом случае ваши инвестиции рассматриваются как capex. У вас есть этот программный продукт, который работает автоматически, и у вас есть opex, но он используется исключительно для программного обеспечения, так что затраты очень невелики. А когда вы тратите деньги на сотрудников, это направлено на улучшение системы, и таким образом это становится очень капиталовложенческим. Это накапливающееся, как и должен быть актив. Да, это превращается в актив. Таким образом, ваши инвестиции в людей становятся активом; их результаты труда становятся ощутимым активом для вашей компании, которым в данном случае является система принятия решений.

То, что я наблюдаю в отношении этих современных цифровых трансформаций, заключается в том, что они кажутся чрезвычайно скромными в том смысле, что существует множество рабочих мест, которые являются чистым opex офисными позициями и которые должны становиться capex. Когда люди работают даже один час, они создают что-то накапливающееся, что-то, что строит актив в той или иной форме, вероятно, программное обеспечение, но это могут быть и другие ценные вещи для компании, независимо от постоянной работы людей. Возможно, это звучит немного странно, но это как будто эти люди конструируют механизм, а потом вы можете поддерживать этот механизм в работе на неопределенный срок. Я, конечно, упрощаю; этим механизмам требуется обслуживание и тому подобное, но большинство цифровых трансформаций, которые я вижу, чрезвычайно скромны, потому что они рассматривают людей как opex — как нечто чисто расходное. Мне приходится снова и снова привлекать время этих людей.

Я говорю исключительно о задачах, связанных с информацией, а не о приготовлении бургеров в ресторане. Для этого нужны руки. Пока у нас нет роботов, способных переворачивать бургеры. Но я говорю о чем-то, что похоже на офисную работу в бэк-офисе. Для меня большинство цифровых трансформаций едва ли затрагивают тот факт, что почти все эти процессы должны быть полностью роботизированы, опять же, в бэк-офисе, где мы даже не встречаемся с клиентами. Это чисто внутренняя занятость, и все же для многих крупных компаний это может составлять до двух третей белых воротничков, занятых в бэк-офисе. Очень часто я вижу, что цифровые трансформации даже не царапают поверхность проблемы, когда речь идет о преобразовании этого огромного объема opex в capex, но это мое личное мнение.

Eric Kimberling: Вы поднимаете действительно интересный момент и более масштабную проблему, я думаю, в технологической индустрии, в области корпоративных технологий в целом. Вы говорили много о capex и opex и о том, что IT следует рассматривать как актив, но если посмотреть, куда движутся поставщики технологий, они идут в направлении модели, в которой IT не является активом для их клиентов; актив принадлежит поставщику. И всегда было так, очевидно; это их продукт, их интеллектуальная собственность. Но сейчас происходит переход от локальных решений, где вы инвестируете, делаете капитальные вложения, адаптируете программное обеспечение под свои процессы и так далее, и это становится активом, который амортизируется, к тому, что сейчас мы перемещаем все в облако. Все наши данные оказываются в облаке. Теперь это переходит из capex в opex, и это не просто бухгалтерское решение, является ли это capex или opex.

Это изменение мышления, потому что теперь происходит следующее, как еще один пример — ИИ. Если мы посмотрим на ИИ, то увидим, что эти крупные технологические поставщики говорят: “Эй, у нас есть эта технология ИИ, которая может принести огромную пользу вашей организации.” И это может быть правдой, но одновременно с этим в процессе мы берем наши данные, нашу интеллектуальную собственность внутри компании, и используем их для обучения этих моделей ИИ, которые затем используются конкурентами и другими фирмами. Теперь центр силы смещается от клиентов к поставщикам, поскольку поставщики не владеют данными, но они владеют ИИ и технологией, которая использует ваши данные для обучения, чтобы сделать ИИ инструмент еще лучше для продажи другим компаниям.

Таким образом, это важно. Это действительно важный момент для размышления, поднимающий больший вопрос: что такое IT для нас? Является ли это товаром, который мы просто хотим убрать с баланса, вывести из своих операций, потому что не хотим с этим возиться? Возможно. То есть, для некоторых организаций это может быть приемлемо. Но, как вы упомянули, Amazon и Spotify. Я уверен, что Amazon и Spotify не рассматривают IT просто как товар, который может управляться кем-то другим. Это значительное конкурентное преимущество, и не все мы должны стремиться быть как Amazon или Spotify, но мы можем стремиться сказать: “Например, если наше конкурентное преимущество заключается в том, что у нас действительно эффективная цепочка поставок, мы можем доставлять товары клиентам быстрее, чем кто-либо другой, и можем быстрее настраивать наши продукты и доставлять их клиентам. Хорошо, это ваше конкурентное преимущество. Теперь давайте создадим технологию, уникальную для вас, чтобы сделать это конкурентное преимущество действительно трудно воспроизводимым. Если я просто куплю облачное решение, которое может приобрести любой, то я потеряю свое преимущество.”

Таким образом, вся эта тенденция к стандартизации облачных процессов, использование данных для обучения моделей ИИ в интересах других, меняется. Я считаю, что это очень опасная тенденция, которая заставит организации сожалеть об этом на долгие годы. Поэтому, я думаю, важно остановиться и задуматься. Если мы хотим, чтобы IT было стратегическим активом, отличительной чертой, то давайте будем рассматривать проект именно так. Это, вероятно, означает, что мы не выбираем стандартную готовую технологию, которая находится в облаке. Возможно, мы выбираем более индивидуальное, кастомное решение, даже если это слово “кастомизация” считается плохим и о нем не говорят, не обсуждают индивидуальную разработку. Это может быть правильным решением для вас, если вы рассматриваете IT как стратегическое преимущество.

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

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

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

И внезапно ситуация становится очень сложной. Вы действительно хотите бросить вызов себе как поставщик программного обеспечения, если вы берете плату за пользователя в такой области, где ваше следующее обновление, возможно, устранит 90% ваших пользователей? Это — очень, очень сложный вопрос. Это действительно сложная задача. Кстати, исторически это уже случалось с IBM. IBM брала плату за MIPS, миллионы инструкций в секунду — вот что они делали в 80-х и 90-х. И угадайте, что произошло? Когда IBM брала плату за MIPS, их программное обеспечение с каждым поколением становилось всё медленнее.

Eric Kimberling: Да, я имею в виду, вы поднимаете действительно — еще одну тему, о которой мы могли бы говорить целый эпизод, а именно несогласованность ожиданий или несовпадение стимулов. Знаете, если у вашего поставщика ПО, вашего системного интегратора и, знаете, если взять три основные стороны, у всех троих очень разные и противоречивые стимулы, то преодолеть это будет сложно.

Conor Doherty: Извините за перебивание, но я думаю о времени Эрика. Вы были очень любезны, оставаясь с нами, поэтому я — по крайней мере, мы можем вернуться к этому и поговорить об этике действий всех участников. Но на сегодня я перейду к заключительной мысли. Начну с вас, Йоаннес, на позитивной ноте. Какой совет вы бы дали организациям, несмотря на всё, что мы обсудили, или с учетом всего сказанного? Какой совет вы бы дали организациям, которые собираются начать свою цифровую трансформацию?

Joannes Vermorel: Как сторонник программного обеспечения с четырьмя десятилетиями опыта — я был энтузиастом программного обеспечения ещё в молодости, когда увлекался, скажем, видеоиграми, — я бы сказал, что, думаю, никогда не было лучшего времени, когда технологии программного обеспечения обещали так много. Для меня это просто удивительно — революция deep learning, её производное с LLM и так далее. Это почти магия, знаете, идея о том, что у вас может быть нечто, способное обрабатывать естественный язык для выполнения множества задач.

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

Так что я бы сказал: мечтайте масштабно, а затем расходуйте средства осторожно и постепенно на проекты, которые не являются мега-проектами, потому что риск — вот моё послание по цифровой трансформации. Вам нужно создать условия для быстрого провала, потому что, будучи поставщиком программного обеспечения, я могу сказать вам, что если спросить у клиента: “Можете дать мне действительно плохую оценку того, что произойдёт в течение следующих шести месяцев?” Шесть месяцев — возможно, я смогу это сделать. Да, год уже начинает быть сложным; два года — это уже сложно, потому что люди могут приходить и уходить. Двухлетний проект может оказаться настолько же дестабилизирующим, что это крайне сложно.

Пять лет — о, боже, это как будто мы пытаемся сконструировать Звезду Смерти. Так что, по-моему, цифровая трансформация имеет огромный потенциал. Это великолепно, это не так дорого, поэтому вам стоит попробовать, а не думать, что нужно сначала убедиться, что всё работает. Я бы сказал — делайте наоборот: начинайте с малого, действуйте быстро и проваливайтесь быстро, чтобы если что-то не получится, вы сразу признали, что это утопленные издержки, и пошли дальше, вместо того чтобы продолжать и продолжать, что является точным рецептом для поставщиков корпоративного программного обеспечения, которые в итоге заставляют своих клиентов тратить в 10 раз больше того, что было запланировано.

Вы должны быть способны сказать, “Нет, мы останавливаемся. Мы попробовали, мы увидели, мы закончили. Мы попробуем что-то другое, потому что мир огромен. У нас так много потенциала; нам вовсе не обязательно придерживаться первоначального плана. Нормально потерпеть неудачу с инициативой через три месяца. Но совершенно недопустимо потерпеть неудачу через три года.”

Eric Kimberling: После того, как вы уже потратили миллиарды или сотни миллионов долларов.

Joannes Vermorel: Да, да.

Conor Doherty: Ну, Эрик, здесь принято предоставлять последнее слово гостям, так что, повторюсь, тот же вопрос: есть ли какие-нибудь советы для людей или компаний, которые собираются начать свой путь?

Eric Kimberling: Ну, я имею в виду, это был отличный совет, который вы только что дали. И я, возможно, добавлю к этому, что, знаете, инвестируйте в — инвестируйте в управление изменениями. Убедитесь, что вы вкладываете своё время в управление изменениями, чтобы уменьшить вероятность того, что вам придётся быстро провалиться. Но я согласен, вы хотите проваливаться быстро, и именно поэтому я считаю, что начинать с малого, начинать медленно, а затем ускоряться гораздо эффективнее, чем начинать слишком быстро и слишком масштабно, а потом вынуждены замедляться. Это просто создаёт много моральных проблем, много неопределенности и сомнений в организации.

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

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

Conor Doherty: У меня больше нет вопросов. Большое спасибо за ваше время, Эрик, я очень признателен.

Eric Kimberling: Отличная беседа, было очень весело, мне понравилось.

Conor Doherty: Итак, Йоаннес, мне больше нечего сказать, кроме как ещё раз поблагодарить за ваше время, Эрик. Большое вам спасибо, и всем спасибо за просмотр. До встречи в следующий раз.