Резюме
Сессия о том, почему расходы на корпоративные IT часто направляются неэффективно и как это исправить. Мы рассмотрим, почему большая часть бюджетов уходит на программное обеспечение для учета и отчетности, а не на программное обеспечение для принятия решений, может ли ИИ улучшить вашу ERP, и как измерить реальное влияние ваших программных решений.
Полная расшифровка
Конор Дохерти: Это Supply Chain Breakdown, и сегодня мы разберем, где – на самом деле, вопреки вашим ожиданиям – вы переплачиваете за свою ERP. Меня зовут Конор. Я директор по коммуникациям в Lokad, а справа от меня, как всегда, основатель Lokad, Жоанн Верморель.
Теперь, прежде чем мы начнем, оставьте, пожалуйста, комментарий внизу: сколько вы платите за свою ERP? Мы никому не расскажем. Как обычно, наш продюсер Алексей — Алекс, поздоровайся — задавайте вопросы, и он передаст их нам.
А теперь, Жоанн, прежде чем мы перейдем к главному событию, вы сегодня в LinkedIn намекнули на сейсмические новости. Я не собираюсь раскрывать их всему миру, но что вам нужно сказать людям?
Жоанн Верморель: Вышло Введение в цепочки поставок. Это 18 месяцев работы. Когда я не руководил Lokad, я использовал свободное время для написания этой книги, и теперь, безусловно, это 51 страница… не романа. Боюсь, она немного суховата; действительно, несколько суховата. Тем не менее, в письменном виде она является продолжением лекций и гораздо актуальнее них.
Это современное видение того, как Lokad смотрит на цепочки поставок, как их рассматривает и применяет на практике. Да.
Конор Дохерти: Таким образом, книга расширяет то, что вы ранее изложили в книге Количественная цепочка поставок — гораздо более кристально и всеобъемлюще объясняя вашу философию.
Жоанн Верморель: Да. И, кстати, в ней не говорится о Lokad. Она действительно сфокусирована на области, сфере исследований и практики, независимо от мелких деталей того, чем занимается Lokad.
Конор Дохерти: О, для всех, кто хочет узнать больше, мы уже организовали мероприятие для следующего эпизода, который будет полностью посвящен Введению в цепочки поставок — обсуждению теорий и основных практик, которые вы теперь подробнее излагаете. И мы коснемся и более острых моментов, ведь, знаете, я прочитал раздел о консультантах. Это заслуживает внимания.
Но опять же, это на следующую неделю. Алексей, пожалуйста, оставь ссылку в прямом эфире, и вы уже можете зарегистрироваться. Если больше нечего добавить, Жоанн, давайте — без лишних слов — перейдем к главному событию.
В одном из ваших других произведений — это, как мне кажется, примерно 18 месяцев назад — вы написали статью Три основных класса корпоративного программного обеспечения, в которой изложили свое мнение о том, как IT-бюджет должен распределяться между тремя категориями программного обеспечения. Не могли бы вы рассказать об этом подробнее для тех, кто ее не читал?
Жоанн Верморель: Суть такова: есть три категории — корпоративные системы учета, системы отчетности и системы интеллекта.
Система учета: это ваш электронный регистр — возвышенный регистр. Он создает электронный аналог информации, характеризующей ваше предприятие: что у вас на складе, какой перечень ваших товаров, магазинов, оплачивали ли вы поставщикам, получили ли деньги от клиентов — все эти сверхтранзакционные данные. Система учета.
Отчеты: это система, позволяющая конечным пользователям — корпоративным пользователям — в режиме самообслуживания генерировать описательную статистику на основе тех же учетных данных.
А системы интеллекта предназначены для генерации решений. Опять же, архетип системы интеллекта — это антиспам-фильтр, весьма важное решение: почта, которую вы никогда не прочтете, потому что некая система интеллекта решила, что она не заслуживает вашего внимания.
BI инструменты — системы бизнес-аналитики — представляют собой системы отчетности. Системы учета составляют основную массу: все, что связано с управлением — WMS, YMS, CRM и т.д. И ERP — которую, по идее, следует называть ERM — также относятся к этой категории.
Первый момент — это расходы. В настоящее время системы учета — всё, что связано с «управлением» — составляют около трех четвертей расходов. Буквально, почти все деньги, которые тратят крупные (или не настолько крупные) компании, уходят на системы учета. ERP обычно занимает более половины бюджета. Может немного варьироваться, но скажем так, ERP плюс CRM однозначно являются слонами в комнате.
Конор Дохерти: Следующий вопрос: в чем проблема? Что неправильно в распределении 50%, 75%, 95%? В чем дело?
Жоанн Верморель: Проблема в том, что с конца 90-х цены на эти продукты растут, несмотря на то, что технология становится все более стандартизированной — до такой степени, что сейчас она полностью стандартизирована. Ожидалось бы, что то, что по сути не дает больше — технология, не превосходящая ту, что была 30 лет назад — должно стоить копейки.
Технологии для разработки ПО стоят в порядки дешевле, чем 30 лет назад. Компьютерное оборудование стоит в порядки дешевле. Качество инструментов с открытым исходным кодом — баз данных, веб-серверов, фреймворков для быстрой и надежной разработки приложений — взлетело. Открытый исходный код сам по себе полностью стандартизировал массу задач.
Почему же в такой ситуации многие компании — без учета инфляции — до сих пор платят в два или три раза больше, чем 30 лет назад, за то, за что должны платить в десять раз меньше? Учитывая достигнутый прогресс, для меня это невероятно странно. Конечно, есть причины — я их понимаю — но это огромная ошибка в масштабах всей отрасли.
Конор Дохерти: В той же статье вы привели приблизительные цифры: скажем, 75% IT-бюджета уходит на системы учета, 20% — на BI-инструменты, такие как отчеты, и, может быть, 5% — на то, что фактически является программным обеспечением для принятия решений. Как бы то ни было, что же на самом деле влияет на финансовый итог? Проще говоря, вы сказали, что это не учет, не отчеты — а решения, которые вы принимаете. Расскажите, пожалуйста, подробнее: как программное обеспечение для принятия решений влияет на этот итог?
Жоанн Верморель: Давайте рассмотрим запасы. У вас есть система управления запасами. Эта система считает — подсчитывает, сколько единиц поступает, сколько уходит — и выдает разницу, то есть ваш фактический запас в электронном виде. Это работало уже в конце 70-х. Электронное управление запасами — очень древняя технология, и подобное можно наблюдать в производстве и прочем. Это и есть ваши системы учета.
Теперь происходит следующее: все эти системы учета продвигаются и рекламируются с идеей, что у вас будет меньше запасов и меньше дефицита товаров. Для меня именно здесь все становится очень странным. Система управления запасами ведет учет, но в бухгалтерском смысле — как бухгалтер ведет ваши счета. Она не принимает никаких интеллектуальных, прибыльных решений. Это область систем интеллекта.
Тем не менее, поставщики с конца 70-х годов создавали огромную общую путаницу: даже если вы продаете по сути систему ведения учета, вы говорите «меньше запасов, меньше дефицита», что не имеет смысла.
Кстати, эта фарс с системами учета повторилась и с системами отчетности: я даю вам статистику вашего среднего уровня запасов, ваших средних продаж, среднее то, среднее это, а затем говорю, что у вас будет меньше дефицита и запасов. Нет. То, что я даю описательную статистику, не означает, что у вас будут лучшие результаты. В конечном итоге, кто-то должен принять решение, и только тогда это принесет возврат инвестиций.
Вы, по сути, для систем отчетности немного повышаете производительность человека, который подсчитывает цифры. Это полезно, но оправдывает ли это такие затраты?
Моя критика в том, что эти стандартизированные технологии по сути не генерируют существенного возврата инвестиций. Да, они необходимы, как и электричество для вашего бизнеса; нет смысла тратить несколько процентов годового оборота на электричество, если вы не занимаетесь чем-то чрезвычайно энергозатратным.
Конор Дохерти: Если вы говорите, что что-то слишком дорогое для того, что оно делает, это подразумевает, что вы понимаете, для чего это предназначено — какова цель этой вещи. Исходя из этой философии, как вы видите цель ERP — как бы она ни использовалась сейчас? Какова цель этой системы учета?
Жоанн Верморель: Цель должна заключаться в том, чтобы быть цифровым аналогом транзакций — и ничем больше. Очевидно, поставщики будут представлять это как нечто большее. Мой ответ: если вы пытаетесь сделать из этого нечто большее, вы идете к проблемам. Не возводите вашего бухгалтера в ранг стратега компании. Это плохо.
Если вы посмотрите на генеральных директоров крупных компаний, они не бывшие бухгалтеры — и на то есть веские причины. Мышление, присущее бухгалтерскому учету, и стратегическое принятие решений — как вода и масло. Они не смешиваются.
Это различие отражается даже в программном обеспечении. Если вы разрабатываете ПО, которое занимается учетом, вы не занимаетесь принятием решений. Это совершенно другое. Люди, ориентированные на принятие решений, обычно оказываются крайне плохими бухгалтерами, именно потому что воображение не входит в их число качеств. Если бы я, как владелец бизнеса, услышал от бухгалтера: “Я очень творческий человек”, я бы отказался; я выберу того, кто не проявляет креативности.
Суть работы — выполнять рутинные задачи. Вы должны быть точным, исключительно механическим отображением вашего бизнеса. Это ваша миссия: не будьте креативными, не делайте ничего вычурного. Это лишь приведет к обратному эффекту.
Конор Дохерти: В статье вы привели пример, каким, по вашему мнению, должно быть адекватное распределение бюджета — быстрые расчеты на салфетке. По сути, это инверсия: если текущие расходы составляют 75%, вы считаете, что должно уходить примерно 20% на системы учета, 5% на системы отчетности, а основная часть — на принятие решений. Прежде чем мы перейдем к этому, как вы предлагаете измерять ROI для инструмента, подобного системе учета, которую вы описываете как нечто вроде “на столе стоит стакан; если я его уберу, стакана не будет”? Вот что мне нужно: полная точность от системы учета. Как измерить ROI от любой инвестиции в систему учета?
Жоанн Верморель: Это очень сложно. Это входит в категорию расходов на ведение бизнеса — как электричество. Если его нет, это огромная проблема; поэтому оно необходимо. Но затем вы оцениваете: это чистый центр затрат, и их нужно минимизировать.
Почему я говорю, что это должно быть около 20%? Потому что до сих пор эти системы управления в большинстве компаний легко составляли 75% IT-расходов — зачастую и больше. По моему мнению, благодаря стандартизации стоимость разработки ПО снизилась как минимум в 10 раз. Даже при «vibe coding» — программировании с помощью ChatGPT или другой LLM — стоимость может уменьшиться в 100 раз.
Так что, если мы переходим от 75% к 20%, я говорю — сократите в три-четыре раза. Это даже не полная мера стандартизации, но это начало. Если вы не снизите стоимость этого ПО до дробного процента — сократите в три-четыре раза, вы не начнете извлекать выгоды от этой стандартизации. А эта стандартизация реальна и мощна.
Все основные компоненты вашей ERP: база данных — PostgreSQL с открытым исходным кодом, отличная. Вам не нужна дорогая база данных Oracle или IBM Db2. Веб-серверы — то же самое, множество открытых вариантов. Это верно для многих компонентов.
Итак, в итоге: даже если вы захотите разработать это самостоятельно, на самом деле это очень дешево. И, кстати, Lokad — не очень большая компания, примерно 60 человек — недавно мы переосуществили очень сложный B2B CRM с поддержкой ИИ, веб-ориентированный. Общая стоимость составила менее примерно 200 000 €, с множеством функций. Это дёшево.
Я вижу, как клиенты — компании с миллиардными оборотами — тратят десятки миллионов долларов или евро, плюс сроки, которые просто безумны: обновления ERP, занимающие пять лет. Абсолютное безумие, особенно для технологий, которые полностью стандартизированы. Мы не говорим о ракетостроении. Нет. Речь идет о CRUD — создание, чтение, обновление, удаление — что почти является стандартом для систем учета за последние 40 лет. Технология застойна. Да, у вас есть веб и мобильные интерфейсы, но только немного в части интерфейса; остальное остается неизменным.
Конор Дохерти: Многое из того, что мы обсуждаем в Lokad, рассматривается с точки зрения ROI — с ярко выраженной финансовой направленностью. Я хочу сформулировать это очень четко через метафору, которую вы использовали. Ранее вы говорили, что теоретически — и на практике — нет верхнего предела тому, насколько финансово выгодными могут быть решения по мере появления нового объема данных. Финансовая выгода от получения все лучших решений: потолка нет, теоретически есть только ограничения в виде мировых ресурсов.
Считаете ли вы, что это применимо для ROI, который можно извлечь из системы учета по сравнению с системой отчетности и программным обеспечением для принятия решений?
Жоанн Верморель: Системы учета — это электронный аналог возвышенного бухгалтера. От них не ожидать головокружительного возврата инвестиций. Это затраты на ведение бизнеса в цифровом мире. Если этого не делать, вы сталкиваетесь с огромными неэффективностями. Но опять же, это не означает, что вы должны тратить миллионы на «электричество», если не являетесь энергоемким.
Для систем отчетности вы получаете описательную статистику. Это хорошо, но вы платите дважды: сначала за генерацию статистики, затем за то, чтобы кто-то смотрел на цифры. Затраты растут стремительно. В какой-то момент людям следует перестать смотреть на цифры и действительно принимать решения.
Магазины: если менеджер магазина проводит весь день, изучая таблицы, магазин не будет должным образом обслуживаться. Может быть, стоит десять минут в день просматривать данные о продажах, чтобы получить представление; а затем вернуться к выкладке товаров на полки, удостоверившись, что всё аккуратно и опрятно. В крупных корпорациях с инструментами бизнес-аналитики снижение отдачи наступает быстро. Чем больше цифр, чем больше на это тратится — вам следует переходить к действиям: принятию решений.
Conor Doherty: Если бы мне пришлось это суммировать — ранее вы сказали, что панель управления может выглядеть хорошо только до того, как вы начнёте немного оживлять цвета, но по сути информация уже есть.
Joannes Vermorel: Вы можете бесконечно корректировать определение KPI, но в конечном итоге для улучшения бизнеса вы обязаны действовать. Размышления над цифрами сами по себе — это всего лишь средство для достижения цели, и они сопровождаются очень резким снижением отдачи.
Conor Doherty: Вы не раз использовали термин «центр затрат» для описания систем учёта и систем отчётности — как постоянных расходов. Ранее мы говорили о цепочке поставок: это капитальные затраты или операционные? Применили бы вы этот фильтр здесь более детально, сказав, что программное обеспечение для принятия решений относится к капитальным затратам, а две другие категории — к операционным?
Joannes Vermorel: Суть в следующем: сможете ли вы сделать нечто по‑настоящему стратегически ценное с помощью системы учёта, что взорвало бы стоимость вашей компании? Возможно, для некоторых бизнесов, но для подавляющего большинства — нет. Возможностей слишком мало. Известные бренды, продающие спортивную обувь — подумайте о Nike — уже имеют отличный электронный эквивалент своей физической деятельности.
Могли бы они расширить системы учёта, чтобы фиксировать вещи, которые действительно преобразили бы бизнес? Сомневаюсь. В конечном итоге вы хорошо фиксируете происходящее с точки зрения транзакций, и дальнейшее расширение не приносит большой ценности. Вам это нужно, но это становится частью фонового шума. Вы не сможете выделиться.
Центр затрат против стратегического компонента: действительно ли вы можете получить конкурентное преимущество над соперниками? Я имею в виду системы учёта — их отсутствие является огромной проблемой. Но любая компания с годовой выручкой более 10 млн евро имеет их. Как только они у вас есть и они достойны, конкурентное преимущество, которое можно получить, улучшая их, сверхменно мало по сравнению с принятием лучших решений.
История полна успешных предпринимателей, которые всерьёз относились к тонким идеям, активно их продвигали и заработали на этом состояние. Лучшие решения — это очень умное — или настолько умное, насколько это возможно — и прибыльное распределение ограниченных ресурсов: денег, людей, всё ограничено.
Поскольку нет предела тому, что вы хотите распределить, вы можете сузить задачу — распределение запасов по магазинам — или расширить её: открыть новые магазины, сотрудничать с существующими магазинами для размещения ваших товаров и т.д. В принятии решений, когда я говорю, что возможности безграничны, формального предела нет — если вы готовы пересмотреть рамки. Границы и ограничения становятся размытыми в определении приемлемого решения. Это открытая проблема.
Conor Doherty: Слушая, как вы различаете ERP (системы учёта) и системы интеллекта (программное обеспечение для принятия решений), я вспоминаю друга канала, Эрика Кимберлинга. Он рассказывает о множестве катастроф корпоративного программного обеспечения — масса неудач.
Ничего подобного я никогда не видел в его репортажах — и вообще не встречал на LinkedIn; возможно, такое существует, не стесняйтесь присылать мне примеры — но я никогда не видел заголовка: «Много миллиардная компания тратит $500 миллионов на лучшее программное обеспечение для принятия решений». Что я видел много раз: «Много миллиардная компания транжирит огромные суммы на модернизацию своего ERP».
Joannes Vermorel: Абсолютно верно. Существует несколько точек зрения. ERP считаются необходимостью. По сути, нет четкого верхнего предела тому, какую сумму следует на них тратить. Мы говорим, что это необходимо. Если это необходимо, нужно инвестировать всё, что потребуется — да —, но цена должна быть низкой; иначе вы делаете всё неправильно.
Когда вы говорите «стоимость ведения бизнеса», как за электричество, вы готовы тратить всё, что нужно, чтобы обеспечить электричество — верно —, но это имеет смысл только потому, что в большинстве мест электричество стоит копейки. Поставщики используют это, чтобы взимать с клиентов чрезмерные сборы, распределенные на многие годы.
Эрик отметил, что для компаний с ERP, которая работает отлично — стабильно, надежно — не нужно переходить «в облако». Если у вас есть система, которая работает, центр затрат с умеренными расходами, и функционально она делает то, что вам нужно — по принципу бухгалтерии: учёт ведется правильно — то модернизация вашего ERP приносит очень мало преимуществ.
Это как если у вас есть очень старательный бухгалтер — надежный и недорогой — а потом вы хотите бухгалтера, который только что закончил Принстон или Гарвард — звучит здорово —, но который стоит в пять раз дороже того, кто уже был абсолютно надежен. Если ничего не сломано, не чините.
Что касается систем интеллекта, причина, по которой не происходят катастрофы стоимостью полмиллиарда, в том, что с самого начала вы ориентированы на окупаемость. Вы занимаетесь принятием решений; вы думаете о ROI. Если через несколько месяцев становится ясно, что этот поставщик никогда не обеспечит нужные решения, компания говорит: «Ладно, прекращаем», и мы продолжаем, поручая людям принимать решения вручную. BATNA — лучшая альтернатива заключённому соглашению — заключается в том, чтобы продолжать принимать решения вручную.
Очень быстро, если стоимость вашего программного обеспечения для принятия решений начинает приближаться к затратам на выполнение работы вручную, вы оказываетесь в проигрыше. Именно поэтому в системах интеллекта не наблюдаются проекты на пять лет с бюджетами в сотни миллионов. Основная идея такова: мы сделаем вашу компанию более прибыльной за счёт лучших решений и большей автоматизации.
Подумайте об анти-спам фильтре: если его стоимость будет выше, чем затраты на секретаря, который вручную фильтрует вашу почту, вы скажете: «Погоди, я не собираюсь тратить миллионы, когда могу заплатить секретарю». Это устанавливает жесткий предел. Это не то же самое, что с ERP, где вы говорите: «Мне это нужно, иначе я в проломе». Здесь существует реальная возможность, что люди будут работать с таблицами; это как-то работает. Поэтому компании не будут продолжать сжигать деньги годами.
Conor Doherty: Если рассматривать это как мысленный эксперимент — и я не собираюсь критиковать Lidl; я люблю Lidl —, и если бы вы спросили у лиц, принимающих решения в Lidl: «Существует ли верхний предел тому, насколько хорошей может быть ваша ERP? Насколько хорошими могут быть ваши BI‑инструменты? Есть ли финансовый верхний предел того, насколько хорошими могут быть ваши решения?» — я уверен, они бы с вами согласились. Однако принимаемые решения в итоге не соответствуют этой реальности. В чем же асимметрия?
Joannes Vermorel: В случае с Lidl, в их катастрофе, они по сути покупали модуль системы интеллекта от SAP. Проблема в том, что у них был поставщик — чистый поставщик систем учёта — который полностью оформил проблему принятия решений в парадигме системы учёта. Это явное указание. С самого начала проект был плохо структурирован.
Они должны были сказать: покажите, что это можно запустить за три-четыре месяца для 100 магазинов, а затем расширим, если система сработает. Но они выбрали безумный, сложный проект, следуя философии поставщика систем учёта. Масло и вода: не смешиваются. Не пытайтесь найти человека, который был бы одновременно и Стивом Джобсом, и бухгалтером.
Conor Doherty: Поступило несколько вопросов и комментариев от Алексея, поэтому мы переключимся на них через минуту. Один завершающий вопрос: ранее вы описывали восприятие ERP как необходимости. Существует растущее движение «решение прежде всего» — некоторые даже в сегодняшнем чате: Hey, Warren Pal; мы брали интервью у Адама Деджанса‑младшего, Кристины Раду и Оскара Шнайдера. Многие публикуют, что принятие решений — это основной драйвер.
Что, по вашему мнению, должно произойти, чтобы эта перспектива прорвалась сквозь потолок и подняла обсуждение до уровня: «Я должен иметь систему интеллекта — программное обеспечение для принятия решений»?
Joannes Vermorel: Я не думаю, что это «обязательная необходимость». Сначала нужны записи — не в смысле самого важного, а как основа: вам нужны электронные записи, прежде чем на их основе внедрить умную автоматизацию. Да, записи первичны. Важно признать, что это проблема с полностью стандартизированными решениями, и надо воспринимать её именно так.
Если вы подключаетесь к интернету дома и кто-то говорит вам: «Я могу дать вам доступ к интернету за $50,000», вы подумаете: «Это безумие». Вы ожидаете, что должно стоить $50 в месяц. Потому что это стандартизировано. Вы знаете, что эти вещи можно сделать за эту цену, поэтому не станете обсуждать варианты, в разы превышающие эту сумму. Это правильное отношение: полностью стандартизировано; с агрессивным сокращением затрат.
Что касается последующих решений: программное обеспечение дорогое — особенно ПО для принятия решений; оно более тонкое, чем примитивные приложения. Для принятия решений нужна масштабируемость. Если решение принимается раз в неделю, скорее всего, дешевле обойдется человек. Но если решений требуется принимать десятки, сотни, тысячи раз в день — во многих компаниях это имеет место.
Для решений с высокой частотой системы интеллекта очевидны. Для очень редких — не совсем. Имейте в виду стоимость того, чтобы умный человек этим занимался. Если это требует участия очень немногих людей и решение принимается редко, то, вероятно, это не лучший кандидат для системы интеллекта. Если это что-то вроде ремонта самолетов — очень детализированное, где решения принимаются с мельчайшими нюансами, и само внесение решения занимает время — тогда преимущества очевидны.
Conor Doherty: Спасибо. Я переключаюсь на вопросы и комментарии. Этот вопрос от Мела: проблема не в недоступности более экономичных альтернатив ERP, а в привязанности. Йоаннес, как вы оцениваете роль MCP в освобождении компаний от их экстраординарного поставщика ERP? MCP по сути — это «система решений».
Joannes Vermorel: Я думаю, что компании переоценивают степень привязанности. Обычно она больше в их голове, чем в реальности. У них есть доступ к основным базам данных — к исходным материалам. Поставщик не предоставляет вам код, но и не делает ничего невероятно сложного. Базовые принципы.
Если вы хотите частично переосмыслить систему внутри компании с использованием компонентов с открытым исходным кодом, вы разворачиваете собственную базу данных PostgreSQL плюс фреймворк Django на Python, и постепенно внедряете функциональные области вашего ERP для постепенного отказа от системы. Я видел очень немногие компании, которые действительно страдали от привязанности к поставщику. Настоящая привязанность — когда у вас нет доступа к исходной базе данных. Это случается иногда, но это редкость.
Если определить привязанность к поставщику как «поставщик, продавший вам ваш ERP, не идет навстречу», то это происходит практически всегда. Не ожидайте, что поставщик будет сотрудничать при постепенном отказе от его системы. В большинстве случаев у вас есть доступ к исходной базе данных. Возможно, у вас нет документации, но это можно восстановить обратным инжинирингом. Не конец света.
Conor Doherty: Прежде чем я продолжу, напомню, что юридический отдел сказал: будьте осторожны. От Мануэля: «А что насчет так называемых интеллектуальных модулей, продаваемых компаниями ERP, такими как SAP, по высоким ценам? Каково ваше мнение?» Будьте осторожны.
Joannes Vermorel: Начиная с конца 70‑х, поставщики корпоративного ПО не были дураками. Они понимали, что ценность кроется в решениях. Но они также рано осознали, что решения принимать сложно. Гораздо проще перевести записи в цифровой формат — иметь систему управления запасами, которая считает уровни запасов, — чем принимать правильные решения по запасам.
Поставщики сделали ставку на системы учёта и создали ценность, но при продаже систем управления запасами они не говорили: «у вас будет точный учет», а говорили: «меньше нехваток, меньше запасов» — решающий фактор. В 90‑х годах в ERP ввели понятие «планирование» — Enterprise Resource Planning — чтобы переориентировать системы управления как более ориентированные на принятие решений. Поставщики поняли, что простая цифровизация уже не добавляет ценности, и нужно переходить к решениям.
С технологической и культурной точек зрения принятие решений несовместимо с ведением записей. Возможно, чтобы защитить поставщиков того времени: в 90‑х это было не до конца ясно. Доминировали экспертные системы в машинном обучении; люди думали, что правило‑ориентированный подход — суть систем учёта — может масштабироваться до уровня осмысленного интеллекта. Но нет.
Я могу помиловать их за то, что они не поняли этого в 90‑х. После 2000 года всё стало совершенно ясно.
Conor Doherty: Комментарий от Дэвида Роллингсона: вы должны знать, где находитесь, куда хотите идти и работать сообща, чтобы принимать хорошие решения. Это не просто вопрос программного обеспечения. Ваши мысли?
Joannes Vermorel: Согласен. Решение должно быть обоснованным; оно должно соответствовать стратегическому замыслу компании. Конечно, здесь много нюансов. Тонкая дискуссия о точном отражении неуловимого — стратегического замысла, который определяет особый способ оценки качества обслуживания с точки зрения данной компании — именно это и является культурной разницей между системами учёта и системами интеллекта.
Когда вы работаете с системами учёта, вам не приходится иметь дело с крайне тонкими, нюансированными вещами. «Находится ли эта единица на полке? Да или нет.» «Верна ли эта налоговая ставка? Да или нет.» В системах учёта ответы бинарны. Здесь совсем нет места для тонкостей. Это как бухгалтер: книги либо правильны, либо нет; либо вы соответствуете налоговым требованиям, либо нет.
Если ваш бухгалтер говорит вам: «Что касается налогового соответствия, мы в серой зоне», как владелец бизнеса вы подумаете: «Нет, я хочу быть абсолютно соответствующим». Но в контексте стратегического замысла вы имеете дело с оттенками серого — только с оттенками серого. Вам нужны инструменты, способные работать с неопределённостью и неопределённостью. Работа с неопределённостью — это то, что в полной мере реализовано в системах интеллекта.
Подумайте об анти-спам фильтре: если его стоимость будет выше, чем затраты на секретаря, который вручную фильтрует вашу почту, вы скажете: «Подождите, я не собираюсь тратить миллионы, когда могу заплатить секретарю». Это устанавливает жесткий предел. Это не то же самое, что с ERP, где вы говорите: «Мне это нужно, иначе я в проломе». Здесь существует реальная вероятность, что люди будут работать с таблицами; это как-то работает. Поэтому компании не будут продолжать сжигать деньги годами.
Conor Doherty: Вопрос от Оскара Шнайдера: каковы были основные факторы неудачи в проекте Lidl, который мы упоминали ранее? Кратко, в двух словах.
Joannes Vermorel: В конечном итоге, основной момент заключался в нарушении теории цепочек поставок. Основная теория цепочек поставок вытворяет кучу безумных вещей: анализ временных рядов, каким он осуществляется в мейнстриме, совершенно ненадёжен; подход точечного прогнозирования совершенно ненадёжен; отсутствие экономической обоснованности совершенно ненадёжно. Технологический стек, используемый SAP в этом конкретном случае — SAP ERP — оказался совершенно неподходящим для этой цели и т.д.
У них, вероятно, было десятки проблем — каждая из которых гарантировала провал. Вместе они создали столько путаницы, что им понадобилось семь лет, чтобы свести концы с концами после траты полумиллиарда. Говорят «смерть тысячью порезами», подразумевая, что каждая проблема не является фатальной. Здесь же порезы были как от гильотины. Тело было разрезано на тонкие слои; каждый разрез был смертельным, и их было много.
Conor Doherty: Если кто-то из Lidl смотрит, свяжитесь с нами. Мы предоставим бесплатный экземпляр книги Йоаннеса, и вы сможете обойти все эти мины и гильотины. Давайте двигаться дальше.
Вопрос — я немного перефразирую — от Махи: не считаете ли вы, что руководители цепочек поставок недостаточно бросают вызов своим коллегам из ИТ по вопросам распределения и т.д.?
Joannes Vermorel: Я бы не стал винить руководителей цепочек поставок. Обычно решение принимается за них, и у них нет права голоса. Для систем учёта записей сделка, как правило, заключается посредством убеждения генерального директора, финансового директора и совета директоров. Руководитель цепочки поставок во многих компаниях даже не получает права голоса. Вину я не стал бы возлагать на них.
Они могли бы стать лучшими защитниками альтернатив, но троица, несущая ответственность за расточительные траты, — это генеральный директор, финансовый директор и ИТ-директор/технический директор, возможно, с советом директоров, дающим общее одобрение на значительные расходы.
Conor Doherty: Вопрос от Пра Превари — извините, если я произношу неправильно. Для системы интеллекта разве нельзя просто использовать существующую ERP, взять необходимые выгрузки данных для обработки ИИ-решением, а затем вернуть результаты обратно в систему ERP? Вы уже качаете головой.
Joannes Vermorel: Да. Именно этим занимается Lokad. Мы извлекаем все данные из ERP, потому что не хотим работать внутри ERP. Если вы выполняете что-либо вычислительно интенсивное, это замедляет работу ERP, что крайне плохо. ERP должна быть быстрой — запросы уровня запасов должны выполняться за 50 миллисекунд.
Если хотите быть быстрыми, не следует лишать систему вычислительных ресурсов полноценным сетевым анализом. Это должно происходить в полностью изолированной системе.
Также uptime: если ваша ERP останавливается на минуту, транзакции блокируются; это вызывает огромные проблемы. Для системы интеллекта: если вы не можете отдать заказы своим китайским поставщикам в течение дня, это проблема, но не такая серьезная. Показатели uptime различаются.
Таким образом, правильный подход — это чистая, легковесная выгрузка данных — даже не подготовка данных или объединения — просто сырые дампы таблиц, которые требуют очень мало ресурсов. Вы помещаете их в другую систему. Как только вы завершаете обработку готовой продукции — итоговые решения — вы вводите их обратно. Хорошая новость заключается в том, что эти решения очень легкие: если это заказ на покупку, то это продукт плюс количество, небольшой пакет данных для повторного ввода в ERP. По уровню трения ИТ-интерфейсов он минимален.
Conor Doherty: Последний вопрос от Мануэля: по моему опыту, внедрение систем принятия решений в компаниях ограничено используемыми ERP, потому что ИТ всегда вынуждены выполнять часть работы, и их обычно перегружают задачами. Что думаете?
Joannes Vermorel: Я встречал это очень часто, но это глубокая культурная ошибка. Ошибка заключается в том, чтобы относить системы принятия решений — поскольку это программное обеспечение — к обязанностям ИТ. Это не так.
Основная инфраструктура вашей компании — системы учёта записей — действительно принадлежит ИТ. А решения — нет. Решения полностью зависят от конкретной области. Они требуют глубоких знаний в своей предметной области.
Например, траты на Google AdWords — это не проблема ИТ. Нужно знать рентабельность инвестиций (ROI), когда вы делаете такую ставку за этот клик по данному ключевому слову, и насколько он конвертируется. Это очень специфично для области. Не стоит ожидать, что ИТ решит эту задачу.
Системы интеллекта существуют в каждом подразделении: маркетинг, продажи, финансы, цепочки поставок. Они сегментированы, потому что тип принимаемого решения требует специализированных знаний, соответствующих этим подразделениям. Ошибка заключается в том, чтобы передавать то, что требует огромной специфической экспертизы — например, цепочки поставок — в руки ИТ. Это терпит неудачу, поскольку основная компетенция ИТ не в принятии решений.
Нужно вернуть это в соответствующее подразделение, что означает, что люди могут заниматься программными проектами, не относящимися к ИТ, а входящими в их собственные проекты. Угадайте, что? Это случилось в маркетинге более 10 лет назад. Маркетинговые отделы, тратившие средства на Google AdWords, уже более десяти лет используют программные инструменты. Им пришлось освоить эту компетенцию, чтобы добиться успеха в таких операциях, как AdWords, с десятками тысяч комбинаций ключевых слов, сотнями сообщений, постоянным A/B тестированием и мощными инструментами.
Подразделения перешли на программный подход десять лет назад. Вы можете реализовать это самостоятельно или привлечь специалистов — Lokad был бы специалистом по цепочкам поставок — дополняющих ваши команды. Технические аспекты неизбежны. В итоге вы получаете систему принятия решений, которая является сложным, обычно индивидуально разработанным программным проектом для компании. Иногда сложность слишком велика, и это не оправдывается — люди по-прежнему выигрывают в рентабельности, — но когда вам приходится принимать решения в большом масштабе — будь то Google AdWords или распределение физических товаров в цепочке поставок — программное обеспечение становится очень перспективным кандидатом благодаря детальности решений.
Conor Doherty: Йоаннес, у меня больше нет вопросов. Как всегда, большое спасибо за ваше время и ваши идеи. И всем присутствующим спасибо за участие, за ваши комментарии и вопросы. Интерес к книге — он довольно велик. Как я уже говорил, выпуск следующей недели уже в эфире. Ссылка для регистрации находится в чате; мы разместим её снова позже.
Обязательно приходите, чтобы узнать больше о шедевре Йоаннеса и о том, как он может помочь вашей цепочке поставок — и вы сможете избежать того, чтобы стать следующим Lidl. На этом все, больше мне нечего сказать. Увидимся на следующей неделе. Хорошего вечера и возвращайтесь к работе. Всё будет хорошо.
