Вот интересно: статья написана из базовой инженерной логики, что если мы в рамках одной БД перекидывает сумму с одного счета на другой, то делать это надо в рамках одной транзакции БД, т.е. консистентно.
На практике в банковских приложениях разных банков РФ последние годы при переводе денег между собственными счетами внутри банка регулярно наблюдаю дикую дичь:
Деньги задваиваются (на исходящем счёте ещё не списались, а на новом уже отражаются)
Деньги испаряются (на исходящем счёте уже списались, а на целевом все ещё показывает ноль
Это временные проблемы, обычно в течение 10 секунд, реже минуты все устаканивается. Но, судя по пользовательскому интерфейсу, нынче элементарные переводы внутри счетов одного пользователя в одном банке стало принято реализовывать с помощью асинхронных обновлений каждого счета по отдельности, т.е под капотом микросервисы, eventual consistency и вот это всё.
Как пользователя, меня такое поведение банковских приложений расстраивает неимоверно и думаю я не один такой.
Вопрос знатокам - почему всё же банки на практике ушли от нормальных транзакций в рамках одной БД к распределенной асинхронщине?
Согласен, SQL применительно к исходным данным в ERP системе - это реалистичный альтернативный инструмент решения поставленной задачи.
В моём вариант с SQL я оценил как менее оптимальный по сравнению с выгрузкой подготовленных и отфильтрованных данных из аналитической системы с последующей обработкой на локальном компьютере при помощи Python.
Сыграли такие факторы:
Задача была существенно сложнее, чем просто найти дни с нулевыми остатками товара. Задача состояла в том, чтобы проверить связи между разными потенциальными причинами по графу причинности и итоговым фактом нулевого остатка товара для конкретной комбинации товар/магазин/день
Объем данных и структура хранения. Сырых данных в моем случае было не миллионы строк, а сотни миллионов. Кроме того, я как раз хорошо знаю структуру хранения данных в SAP ERP и, поверьте, она не простая. Можно сэкономить много сил и избежать целого класса ошибок интерпретации, если брать данные из аналитической системы, где данные уже разложены по кубам с продуманными бизнес-аналитиками и показателями.
Мда.. Я бы поостерегся взять на работу автора статьи после её прочтения по следующим причинам:
Автор уверен, что его вопрос "В каком порядке обрабатываются SQL-запросы" может быть понят единственным образом: "в каком порядке БД (какая?) обычно обрабатывает данные для формирования ответа на одиночный SQL запрос к одной таблице без джойнов, функций и подзапросов". При этом выше в комментариях написали уже минимум два других способа интерпретировать вопрос и это не предел.
В статье полностью проигнорирован тот факт, что SQL - декларативный язык. По определению, текст запроса с select содержит требования ЧТО достать из БД, а вот КАК это делать - это работа движка БД (по крайней мере, пока в тексте запроса нет хинтов).
Всё, чему посвящена статья - разбор очень примитивного частного случая, причем наверняка даже для него будет куча исключений у разных движков БД (совсем не уверен что какая-нибудь поколоночная inmemory БД будет обрабатывать запрос по описанному автором плану)
Павел, прочитал ваше резюме и не нашел ни одного упоминания, какой результат ваша работа на предыдущих местах принесла во внешний физический мир. Все сконцентрировано на очевидно липовых цифрах про улучшение внутреннего производственного процесса и героический рефакторинг.
Есть ли на свете мобильное приложение или сайт или конкретная страница сайта, которую вы разработали в части фротн-энда?
Может стоит их как-то в резюме описать, сообщить что именно эти страницы делали и как зарабатывали деньги для компании, на которую выработали?
Не пробовал и не был в курсе существования, как и коллеги из разных компаний, с которыми взаимодействовал. При попытке запустить установщик, на него ругается win defender.
Мое утверждение простое: перечисленные плюсы UUID начинают работать на больших объемах и высоких нагрузках, до которых 99.9 таблиц в БД обычно никогда не дотягивают.
А вот крайне существенный недостаток начинает портить жизнь немедленно и заключается он в том что UUID обычный человек не может в своей голове запомнить и сравнить с другим. Помогает только копипаст и формулы в excel.
Просто представьте, что вы работаете в поддержке и вам пользователь выставляет тикет со скриншотом проблемного документа. Сравните затраты на перебивание числового 10 или даже 8 значного номера по сравнению с 16 или 32 шестнадцатеричнвми числами.
Что важно, эта проблема с UUID проявляется уже при первых сотнях записей в таблице, а не когда у вас там 10млрд строк.
"Программисты - это люди, которые решают непонятные вам проблемы непонятными вам способами"
Предлагаю различать типовую роль "системный архитектор" и должностные обязанности сотрудника с должностью "системный архитектор" в одной конкретной компании.
Системный архитектор, как роль, означает человека, который в первую очередь отвечает за архитектуру создаваемой системы, то есть за все важные (дорогим в изменении) решения, которые повлияют на процесс создания системы и ее итоговую функциональность. Например, архитектор часто выполняет функциональный анализ и модульный синтез, то есть разбивает требуемые функции на разумные куски и придумывает из каких конструктивных частей их собрать.
Также системному архитектору хорошо быть системным инженером и понимать во всех практиках, применяемых в жизненном цикле создания системы. Особенно важно понимать что идёт до архитектуры (концепция использования, потребности, требования).
Остальное (вроде подбора персонала) может быть в должностных обязанностях конкретного инженера, но не описывает типовую роль.
Постараюсь высказаться яснее.
Логику приложения отделяют от логики пользовательского интерфейса не просто потому что кто-то сказал, что «это делать хорошо», а для достижения каких-то задач.
Например, это может быть задача упростить дальнейшую поддержку и модернизацию, особенно если этим будет заниматься не тот разработчик, который изначально писал программу.
Я утверждаю, что при таком мотиве гораздо лучше использовать общепринятый подход, т.е. просто выделить в отдельные perform код для выборки данных, вывода ALV и реакции на user-command. Ваша же схема потребует от нового разработчика долго разбираться, какой же там мега-шаблон вы использовали и не дает никаких преимуществ для целей поддержки.
Может быть другая задача — сделать больше одного пользовательского интерфейса для одной и той же функциональности. Например, обычный SAP GIU под Windows и какое-нибудь мобильное приложение. Вот в этом случае усилия по полной изоляции логики интерфейса от логики работы с данными оправданы. Но часто ли у вас встречается такая задача?
Уважаемый автор, а зачем нужны все эти дополнительные сущности, по сравнению с базовым вариантом написать напрямую весь код в тексте report в se38?
Вроде никакого повторного использования кода ваш вариант не предполагает..
Интересно, директор точно счастлив, что офис-менеджер каждый рабочий день тратит пару часов рабочего времени на поездку в Ашан и затрачиваемое на это рабочее время уже стоит дороже закупаемого кофе? При экстремальном уменьшении закупаемой партии растет доля транзакционных издержек.
SergeyUstinov, мне кажется, мы уже приблизились к максимуму взаимного понимания, который можно достичь обменом письменными комментариями без устного обсуждения.
Публичные споры о том «куча бананов — это сколько?» и какая квалификация у сотрудников конкретной компании (разная, конечно!) мне не очень интересны.
Кстати, мне все равно не ясно — а какие «промежуточные» параметры вы анализировали и зачем?
Вам это непонятно ровно потому же, почему непонятно зачем я давал ссылку на финансовые показатели.
В крупной рознице есть постоянный цикл обратной связи по оптимизации существующих процессов.
Упрощенно так:
1. Обнаружили глобальное ухудшение оборачиваемости
2. Нашли, что за существенную часть негативного эффекта ответственны конкретные SKU сковородок, запас которых в торговой сети составляет 5 лет продаж
3. Нашли расчет автозаказа, по которому были заказаны эти сковородки, проанализировали и выяснили что за большой объем заказа отвечает в данном случае тот факт, что в рамках промо-акции ХХХ некий менеджер Иванов заложил дополнительную выкладку по 1000 сковородок в каждый магазин, а его начальник Петров это согласовал.
Дальше движения могут пойти по линии СБ, но нас интересует ИТ составляющая и тут в ИТ может прийти задача контролировать плановый размер доп. выкладки по некому алгоритму до согласования промо-акции, чтобы в будущем избежать таких проблем.
Вывод такой — если хотите увеличивать эффективность системы, нужна отслеживаемость причинно-следственных связей, в том числе какие числа подставились в формулу расчета автозаказа и откуда они взялись.
Возвращаясь к SAP — вопрос не в качестве алгоритмов расчета пополнения запасов — они у сапа относительно стандартные и описаны в книжках и статьях о логистике и управлении запасами и, насколько знаю, реализованы корректно. Вопрос — почему появляются проблемы с этими относительно несложными расчетами на относительно небольших объемах данных?
Именно это и вызывает недоумение.
Я думаю, тут комплекс причин:
1. Масштаб задачи (число обсчитываемых комбинаций товар/магазин/дата).
2. Через несколько лет после начала работы никто не использует базовые простые алгоритмы SAP. Или существенно их дорабатывают, или пишут с нуля свою систему пополнения внутри SAP. Это факт может не очень приятный для SAP как вендора, но такова жизнь (см. выше про цикл улучшений).
3. Базовые алгоритмы SAP действительно не самые оптимальные из тех что можно написать относительно размена (время работы) vs (потребляемая оперативная память).
Местами видим селекты в циклах вместо массовой выборки данных, где-то кеширования не хватает на уровне сервера приложений, где-то наоборот кешируют, но таблицу во всю ширину (select *) вместо выборки нескольких нужных полей и т.п.
Практика показывает, что если с умом писать систему пополнения на встроенном в SAP языке программирования ABAP, то тот же объем данных на тех же мощностях можно обсчитывать примерно в 10 раз быстрее.
SergeyUstinov, постараюсь в ответе не растекаться мыслью по древу.
1. Ссылку на финансовые результаты я дал потому, что качество автоматической системы пополнения магазинов (автозаказа) — это один из нескольких критических бизнес-процессов для розничной сети, который на эти результаты влияет просто напрямую.
2. Про основную идею. При заранее известном графике поставок (характерно для розницы) оптимально при каждом расчете заказа на дату поставки 1 рассчитывать оптимальный размер заказа так, чтобы к поступлению товара по следующему заказу (на дату поставки 2) запас был равен необходимому (регулярная выкладка + дополнительная выкладка + страховой запас).
Фиксированный целевой уровень запаса при поступлении на дату поставки 1 проигрывает этой модели (это мое личное мнение, в холивар тут не хотелось бы впадать).
3. Что касается моего опыта и где эта модель применяется — я был архитектором на проектах создания системы пополнения в 10 федеральных розничных сетях России. Правда, существенная часть из них управляется одной материнской группой компаний и расчет пополнения выполняется в одной информационной системе.
Названия сетей называть не буду, но в любом сколько-нибудь крупном ТЦ в Москве вы их встретите :)
Отрасли разные — продукты, детские товары, одежда и обувь, потребительская электроника.
Ради такого дела решил написать свой первый комментарий на Хабре :)
1. SKU в общепринятом понимании — это именно уникальный код товара, а не код товара/места хранения. Но это не так уж важно.
2. Мне очень нравится попытка оценить масштаб задачи по измерениям. Вот только кроме условных «товар» и «магазин» вы забыли измерение «дата». Самый простой пример: чтобы рассчитать потребность магазина в товаре, надо сформировать прогноз продаж. Для прогноза продаж надо заглянуть:
а. В прошлое (посмотреть временной ряд продаж и запасов).
б. В будущее (посмотреть, какие планируются факторы влияния на спрос, например, из-за снижения цены по промо-активности).
В общем, из-за третьего измерения объем задачи недооценен на 2-3 порядка.
3. Результатом расчета пополнения не является одна цифра на товар/магазин. Никому не интересен черный ящик, без промежуточных показателей расчета, это вам не котиков распознавать нейросеткой :)
4. До расчета пополнения и после расчета пополнения есть свои критичные бизнес-процессы, которые должны отработать в строгой последовательности.
Например, результатом расчета пополнения является даже не одна строка в таблице в разрезе товар/магазин. Результатом являются документы в ERP, на которые навешена своя существенная бизнес-логика. Скажем, заказы на распределительные центры должны быть переданы на исполнение в РЦ, а заказы внешним поставщикам — отправлены им для исполнения (в основном, по EDI).
5. Все эти ежедневно рассчитываемые цифры являются бизнес-критичными. Это значит две вещи:
— у бизнеса непрерывно есть требования, как улучшить процесс пополнения
— элементарная ошибка в логике расчета даже по одному товару может привести к космическим коммерческим потерям (просто представьте себе что будет, если при заказе кока-колы по ошибке сконвертировать рассчитанную потребность в бутылках в коробки как один к одному).
Надеюсь, я немного расширил представление о задаче пополнения в розничной сети магазинов в плоскости ИТ.
Ну и, наконец, всё упирается в финансовый результат.
В недавнем отчете о 250 крупнейших ритейлерах мира, Россия представлена четырьмя компаниями. У трех из них в качестве ERP системы используется SAP. А конкретно X5 еще и на 29м месте в мире по скорости роста за пятилетку. www2.deloitte.com/content/dam/Deloitte/be/Documents/Report_GPR2018.pdf
То есть вы полагаете, что разработчики интернет-банковский приложений массово забывают принудительно обновить кеш по счетам, затронутым переводом?
Может и так конечно, но тогда это уж совсем масштабная глупость..
Вот интересно: статья написана из базовой инженерной логики, что если мы в рамках одной БД перекидывает сумму с одного счета на другой, то делать это надо в рамках одной транзакции БД, т.е. консистентно.
На практике в банковских приложениях разных банков РФ последние годы при переводе денег между собственными счетами внутри банка регулярно наблюдаю дикую дичь:
Деньги задваиваются (на исходящем счёте ещё не списались, а на новом уже отражаются)
Деньги испаряются (на исходящем счёте уже списались, а на целевом все ещё показывает ноль
Это временные проблемы, обычно в течение 10 секунд, реже минуты все устаканивается. Но, судя по пользовательскому интерфейсу, нынче элементарные переводы внутри счетов одного пользователя в одном банке стало принято реализовывать с помощью асинхронных обновлений каждого счета по отдельности, т.е под капотом микросервисы, eventual consistency и вот это всё.
Как пользователя, меня такое поведение банковских приложений расстраивает неимоверно и думаю я не один такой.
Вопрос знатокам - почему всё же банки на практике ушли от нормальных транзакций в рамках одной БД к распределенной асинхронщине?
Согласен, SQL применительно к исходным данным в ERP системе - это реалистичный альтернативный инструмент решения поставленной задачи.
В моём вариант с SQL я оценил как менее оптимальный по сравнению с выгрузкой подготовленных и отфильтрованных данных из аналитической системы с последующей обработкой на локальном компьютере при помощи Python.
Сыграли такие факторы:
Задача была существенно сложнее, чем просто найти дни с нулевыми остатками товара. Задача состояла в том, чтобы проверить связи между разными потенциальными причинами по графу причинности и итоговым фактом нулевого остатка товара для конкретной комбинации товар/магазин/день
Объем данных и структура хранения. Сырых данных в моем случае было не миллионы строк, а сотни миллионов. Кроме того, я как раз хорошо знаю структуру хранения данных в SAP ERP и, поверьте, она не простая. Можно сэкономить много сил и избежать целого класса ошибок интерпретации, если брать данные из аналитической системы, где данные уже разложены по кубам с продуманными бизнес-аналитиками и показателями.
Мда.. Я бы поостерегся взять на работу автора статьи после её прочтения по следующим причинам:
Автор уверен, что его вопрос "В каком порядке обрабатываются SQL-запросы" может быть понят единственным образом: "в каком порядке БД (какая?) обычно обрабатывает данные для формирования ответа на одиночный SQL запрос к одной таблице без джойнов, функций и подзапросов". При этом выше в комментариях написали уже минимум два других способа интерпретировать вопрос и это не предел.
В статье полностью проигнорирован тот факт, что SQL - декларативный язык. По определению, текст запроса с select содержит требования ЧТО достать из БД, а вот КАК это делать - это работа движка БД (по крайней мере, пока в тексте запроса нет хинтов).
Всё, чему посвящена статья - разбор очень примитивного частного случая, причем наверняка даже для него будет куча исключений у разных движков БД (совсем не уверен что какая-нибудь поколоночная inmemory БД будет обрабатывать запрос по описанному автором плану)
Павел, прочитал ваше резюме и не нашел ни одного упоминания, какой результат ваша работа на предыдущих местах принесла во внешний физический мир. Все сконцентрировано на очевидно липовых цифрах про улучшение внутреннего производственного процесса и героический рефакторинг.
Есть ли на свете мобильное приложение или сайт или конкретная страница сайта, которую вы разработали в части фротн-энда?
Может стоит их как-то в резюме описать, сообщить что именно эти страницы делали и как зарабатывали деньги для компании, на которую выработали?
Вот, рад что в главном мы сходимся!
Не надо безоглядно делать UUID во всех таблицах только потому что "у них есть 7 преимуществ".
Это нишевое решение под нишевые задачи.
Не пробовал и не был в курсе существования, как и коллеги из разных компаний, с которыми взаимодействовал. При попытке запустить установщик, на него ругается win defender.
Мое утверждение простое: перечисленные плюсы UUID начинают работать на больших объемах и высоких нагрузках, до которых 99.9 таблиц в БД обычно никогда не дотягивают.
А вот крайне существенный недостаток начинает портить жизнь немедленно и заключается он в том что UUID обычный человек не может в своей голове запомнить и сравнить с другим. Помогает только копипаст и формулы в excel.
Просто представьте, что вы работаете в поддержке и вам пользователь выставляет тикет со скриншотом проблемного документа. Сравните затраты на перебивание числового 10 или даже 8 значного номера по сравнению с 16 или 32 шестнадцатеричнвми числами.
Что важно, эта проблема с UUID проявляется уже при первых сотнях записей в таблице, а не когда у вас там 10млрд строк.
"Программисты - это люди, которые решают непонятные вам проблемы непонятными вам способами"
Мда, всё смешалось.
Предлагаю различать типовую роль "системный архитектор" и должностные обязанности сотрудника с должностью "системный архитектор" в одной конкретной компании.
Системный архитектор, как роль, означает человека, который в первую очередь отвечает за архитектуру создаваемой системы, то есть за все важные (дорогим в изменении) решения, которые повлияют на процесс создания системы и ее итоговую функциональность. Например, архитектор часто выполняет функциональный анализ и модульный синтез, то есть разбивает требуемые функции на разумные куски и придумывает из каких конструктивных частей их собрать.
Также системному архитектору хорошо быть системным инженером и понимать во всех практиках, применяемых в жизненном цикле создания системы. Особенно важно понимать что идёт до архитектуры (концепция использования, потребности, требования).
Остальное (вроде подбора персонала) может быть в должностных обязанностях конкретного инженера, но не описывает типовую роль.
Логику приложения отделяют от логики пользовательского интерфейса не просто потому что кто-то сказал, что «это делать хорошо», а для достижения каких-то задач.
Например, это может быть задача упростить дальнейшую поддержку и модернизацию, особенно если этим будет заниматься не тот разработчик, который изначально писал программу.
Я утверждаю, что при таком мотиве гораздо лучше использовать общепринятый подход, т.е. просто выделить в отдельные perform код для выборки данных, вывода ALV и реакции на user-command. Ваша же схема потребует от нового разработчика долго разбираться, какой же там мега-шаблон вы использовали и не дает никаких преимуществ для целей поддержки.
Может быть другая задача — сделать больше одного пользовательского интерфейса для одной и той же функциональности. Например, обычный SAP GIU под Windows и какое-нибудь мобильное приложение. Вот в этом случае усилия по полной изоляции логики интерфейса от логики работы с данными оправданы. Но часто ли у вас встречается такая задача?
Уважаемый автор, а зачем нужны все эти дополнительные сущности, по сравнению с базовым вариантом написать напрямую весь код в тексте report в se38?
Вроде никакого повторного использования кода ваш вариант не предполагает..
Публичные споры о том «куча бананов — это сколько?» и какая квалификация у сотрудников конкретной компании (разная, конечно!) мне не очень интересны.
Предлагаю на этом остановиться.
Вам это непонятно ровно потому же, почему непонятно зачем я давал ссылку на финансовые показатели.
В крупной рознице есть постоянный цикл обратной связи по оптимизации существующих процессов.
Упрощенно так:
1. Обнаружили глобальное ухудшение оборачиваемости
2. Нашли, что за существенную часть негативного эффекта ответственны конкретные SKU сковородок, запас которых в торговой сети составляет 5 лет продаж
3. Нашли расчет автозаказа, по которому были заказаны эти сковородки, проанализировали и выяснили что за большой объем заказа отвечает в данном случае тот факт, что в рамках промо-акции ХХХ некий менеджер Иванов заложил дополнительную выкладку по 1000 сковородок в каждый магазин, а его начальник Петров это согласовал.
Дальше движения могут пойти по линии СБ, но нас интересует ИТ составляющая и тут в ИТ может прийти задача контролировать плановый размер доп. выкладки по некому алгоритму до согласования промо-акции, чтобы в будущем избежать таких проблем.
Вывод такой — если хотите увеличивать эффективность системы, нужна отслеживаемость причинно-следственных связей, в том числе какие числа подставились в формулу расчета автозаказа и откуда они взялись.
Я думаю, тут комплекс причин:
1. Масштаб задачи (число обсчитываемых комбинаций товар/магазин/дата).
2. Через несколько лет после начала работы никто не использует базовые простые алгоритмы SAP. Или существенно их дорабатывают, или пишут с нуля свою систему пополнения внутри SAP. Это факт может не очень приятный для SAP как вендора, но такова жизнь (см. выше про цикл улучшений).
3. Базовые алгоритмы SAP действительно не самые оптимальные из тех что можно написать относительно размена (время работы) vs (потребляемая оперативная память).
Местами видим селекты в циклах вместо массовой выборки данных, где-то кеширования не хватает на уровне сервера приложений, где-то наоборот кешируют, но таблицу во всю ширину (select *) вместо выборки нескольких нужных полей и т.п.
Практика показывает, что если с умом писать систему пополнения на встроенном в SAP языке программирования ABAP, то тот же объем данных на тех же мощностях можно обсчитывать примерно в 10 раз быстрее.
1. Ссылку на финансовые результаты я дал потому, что качество автоматической системы пополнения магазинов (автозаказа) — это один из нескольких критических бизнес-процессов для розничной сети, который на эти результаты влияет просто напрямую.
2. Про основную идею. При заранее известном графике поставок (характерно для розницы) оптимально при каждом расчете заказа на дату поставки 1 рассчитывать оптимальный размер заказа так, чтобы к поступлению товара по следующему заказу (на дату поставки 2) запас был равен необходимому (регулярная выкладка + дополнительная выкладка + страховой запас).
Фиксированный целевой уровень запаса при поступлении на дату поставки 1 проигрывает этой модели (это мое личное мнение, в холивар тут не хотелось бы впадать).
3. Что касается моего опыта и где эта модель применяется — я был архитектором на проектах создания системы пополнения в 10 федеральных розничных сетях России. Правда, существенная часть из них управляется одной материнской группой компаний и расчет пополнения выполняется в одной информационной системе.
Названия сетей называть не буду, но в любом сколько-нибудь крупном ТЦ в Москве вы их встретите :)
Отрасли разные — продукты, детские товары, одежда и обувь, потребительская электроника.
1. SKU в общепринятом понимании — это именно уникальный код товара, а не код товара/места хранения. Но это не так уж важно.
2. Мне очень нравится попытка оценить масштаб задачи по измерениям. Вот только кроме условных «товар» и «магазин» вы забыли измерение «дата». Самый простой пример: чтобы рассчитать потребность магазина в товаре, надо сформировать прогноз продаж. Для прогноза продаж надо заглянуть:
а. В прошлое (посмотреть временной ряд продаж и запасов).
б. В будущее (посмотреть, какие планируются факторы влияния на спрос, например, из-за снижения цены по промо-активности).
В общем, из-за третьего измерения объем задачи недооценен на 2-3 порядка.
3. Результатом расчета пополнения не является одна цифра на товар/магазин. Никому не интересен черный ящик, без промежуточных показателей расчета, это вам не котиков распознавать нейросеткой :)
4. До расчета пополнения и после расчета пополнения есть свои критичные бизнес-процессы, которые должны отработать в строгой последовательности.
Например, результатом расчета пополнения является даже не одна строка в таблице в разрезе товар/магазин. Результатом являются документы в ERP, на которые навешена своя существенная бизнес-логика. Скажем, заказы на распределительные центры должны быть переданы на исполнение в РЦ, а заказы внешним поставщикам — отправлены им для исполнения (в основном, по EDI).
5. Все эти ежедневно рассчитываемые цифры являются бизнес-критичными. Это значит две вещи:
— у бизнеса непрерывно есть требования, как улучшить процесс пополнения
— элементарная ошибка в логике расчета даже по одному товару может привести к космическим коммерческим потерям (просто представьте себе что будет, если при заказе кока-колы по ошибке сконвертировать рассчитанную потребность в бутылках в коробки как один к одному).
Надеюсь, я немного расширил представление о задаче пополнения в розничной сети магазинов в плоскости ИТ.
Ну и, наконец, всё упирается в финансовый результат.
В недавнем отчете о 250 крупнейших ритейлерах мира, Россия представлена четырьмя компаниями. У трех из них в качестве ERP системы используется SAP. А конкретно X5 еще и на 29м месте в мире по скорости роста за пятилетку.
www2.deloitte.com/content/dam/Deloitte/be/Documents/Report_GPR2018.pdf