Прикольная история

[tessob]

Там все алгоритмы придуманы десятки лет назад. Если кто не заметил, то весь текущий хайп преимущественно вокруг работы с изображениями. Что касается использования, DS в банках, страховании и медицине, то там все эти алгоритмы являлись основой бизнесов с самого начала. Страхование, как бизнес, невозможно без понимания статистики, так как риск — это просто мат ожидание.

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

Посмотрите на ту же Yandex Data Factory — количество нанимаемых математиков не приводит к появлению новых решений. А в тех случаях когда приводит, например в задачах прогнозирования оттока клиентов, то выясняется, что в результате получено полностью бесполезное знание за достаточно большие деньги. Просто математика, как правило, не способна ответить на вопрос какие выводы нужно извлечь и как их удержать.

[Chessplayer]

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

Я бы всё-таки ещё добавил NLP в этот список. В этой области очень большой прогресс в последние пару лет в связи с появлением трансформеров.

[Sergunka]

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

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

Формулировка вполне так старозаветная и решается вполне так кондовым методом временных рядов по каждой позиции на складе + видимо еще что-то дополнительное, но пока не об этом. Собственно вот это решение

https://c3.ai/products/c3-predictive-maintenance/

Сейчас нашей конторе используют решение на базе SAP, но вроде как оно не оптимальное если вообще это можно назвать решением в контексте дискуссии.

Занятно наблюдать чем дело кончится

[tessob]

Занятно наблюдать чем дело кончится

Sergunka, это наверное один из тех немногих случаев когда я могу предсказывать Вам будущее. Я просто работаю с SAP со времен мезозоя. И все то, о чем Вы написали, я уже когда-то делал. ))

Видимо, Вы не в курсе, но временные ряды в SAP есть уже лет 30 как. Модели вроде ARiMA/SARiMA там уже давно реализованы в компоненте MRP. Когда стало понятно, что это провал, SAP запилил отдельный продукт – APO-DP, где модель была расширена возможностью корректировать временной ряд в Excel и сбоку был прикручен IBM ILOG CPLEX. Когда стало понятно, что и это не полетит, то SAP запилил очередной продукт – IBP, который тоже, как выяснилось, летать не умеет.

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

Мне кажется, что ваши дата-сатанисты прикладывают математику не той стороной и не к тому месту. Просто, для рассчета safety-stock, ваша модель должна учитывать волатильность (дисперсию случайной величины), так как это именно то от чего сток и зависит. Соответственно тогда, при нулевой дисперсии, ваш сток будет равен мат ожиданию. При ненулевой садятся и пилят модель случайного процесса, дифференцируемого по времени, и формулируют задачу как “вероятность получить OOS (out of stock) для заданных параметров”. Просто воспроизвести временной ряд через вероятностную модель возможно, а наоборот не очень. Ну и вместо временного ряда гораздо веселее иметь какую-то функцию плотности, являющуюся частным случаем гамма-распределения.

Вопрос к Вам, раз уж Вы упомянули SAP – каким образом вы интегрируетесь и каков у вас RPM (requests per minute)?

[Sergunka]

Занятно наблюдать чем дело кончится

Sergunka, это наверное один из тех немногих случаев когда я могу предсказывать Вам будущее. Я просто работаю с SAP со времен мезозоя. И все то, о чем Вы написали, я уже когда-то делал. ))

Видимо, Вы не в курсе, но временные ряды в SAP есть уже лет 30 как. Модели вроде ARiMA/SARiMA там уже давно реализованы в компоненте MRP. Когда стало понятно, что это провал, SAP запилил отдельный продукт – APO-DP, где модель была расширена возможностью корректировать временной ряд в Excel и сбоку был прикручен IBM ILOG CPLEX. Когда стало понятно, что и это не полетит, то SAP запилил очередной продукт – IBP, который тоже, как выяснилось, летать не умеет.

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

Мне кажется, что ваши дата-сатанисты прикладывают математику не той стороной и не к тому месту. Просто, для рассчета safety-stock, ваша модель должна учитывать волатильность (дисперсию случайной величины), так как это именно то от чего сток и зависит. Соответственно тогда, при нулевой дисперсии, ваш сток будет равен мат ожиданию. При ненулевой садятся и пилят модель случайного процесса, дифференцируемого по времени, и формулируют задачу как “вероятность получить OOS (out of stock) для заданных параметров”. Просто воспроизвести временной ряд через вероятностную модель возможно, а наоборот не очень. Ну и вместо временного ряда гораздо веселее иметь какую-то функцию плотности, являющуюся частным случаем гамма-распределения.

Вопрос к Вам, раз уж Вы упомянули SAP – каким образом вы интегрируетесь и каков у вас RPM (requests per minute)?

Спасибо, за очень качественное заяснение в постановке задачи. Я что-то собственно такое и подразумевал в особенности в этой части "Просто воспроизвести временной ряд через вероятностную модель возможно, а наоборот не очень."

Моя задача в этом проекте была очень скромная приехать посмотреть на вменяемость команды так как наши менеджеры стали сильно подозревать, что там явно рак головы Я сложных вопросов не задавал там даже еще POC (Proof of Concept) за три месяца не появилась даже на коленке. Я описал в чем там проблема в коммуникациях между группами почему начальники потеряли управление... в общем диагностировал рак и предложил эсколацию процесса. Пожал руки и уехал восвояси Боже мой как я люблю свою работу

Задача вцелом мне понравилась так как для крупных компаний навроде нашей она действительно должна давать экономию по safety-stock... очевидно, что перфоманс сильно просядет когда попытаются сопряч с САП-ом, но это задачи будущих лет типо корп мыслит на пятилетку минимум (привет СССР )

[tessob]

очевидно, что перфоманс сильно просядет когда попытаются сопряч с САП-ом, но это задачи будущих лет типо корп мыслит на пятилетку минимум (привет СССР )

Походу, все самое интересное у вас еще впереди... внизу. Я не просто так спросил. ))

Дело в том, что SAP был написан в доинтернетную эпоху и интеграция – это просто писец какая проблема. Без шуток! Вот например партнерское решение Amazon, которое в хорошую погоду даст вам… возможность интеграции как таковую, но с RPM меньше единицы. Я не шучу. Посмотрите видео по моей ссылке, корзины S3 используются как продолжение идеи FTP серверов… чтоб было куда выгрузить CSV файлики.

Есть еще решение вендора – SAP Cloud Platform Integration, которое дает 5-6 RPM, стоит 1’100 баксов в месяц за каждый API-endpoint, и работает только в одну сторону (uni-directional). Документации на это нет в принципе, даже жаба доков нет и дешевых разработчиков на рынке тоже нет. Прикрутить это можно только к продуктивным серверам, так что про тестирование придется забыть – сразу в продакшен. И про VPN/HTTPS придется тоже забыть - криптография для лохов. В техническом плане там просто Apache Camel под капотом, но TCO (total cost of ownership)... в общем вы поймете, что FTP сервера с CSV файликами и 0.001 RPM – это не так уж и плохо.

Нормальная интеграция возможна тоже. У меня, например, свой собственный велосипед который дает по 8’000-10’000 RPM в каждую сторону на одном application server и я без проблем могу даже Kafka Streams поставить в середине. Только, чтобы это получить мне пришлось реверс-инженерить проприетарный TCP протокол и отлавливать баги на протяжении 15 лет. Зато сейчас для меня вопрос интеграции вообще не стоит и я могу развернуть обычный REST/RPC ко всем данным логистики в реальном времени дня за 3-4.

Короче, на каждое успешное скрещивание DS & SAP на сегодня приходится, пожалуй, несколько сотен историй, когда просто не удалось найти приемлемого способа интеграции и проекты банально рассыпались. То есть, даже если у вас и получится выдающаяся математическая модель, очень высока вероятность того, что проект в итоге провалится по технической причине.

[Sergunka]

очевидно, что перфоманс сильно просядет когда попытаются сопряч с САП-ом, но это задачи будущих лет типо корп мыслит на пятилетку минимум (привет СССР )

Походу, все самое интересное у вас еще впереди... внизу. Я не просто так спросил. ))

Дело в том, что SAP был написан в доинтернетную эпоху и интеграция – это просто писец какая проблема. Без шуток! Вот например партнерское решение Amazon, которое в хорошую погоду даст вам… возможность интеграции как таковую, но с RPM меньше единицы. Я не шучу. Посмотрите видео по моей ссылке, корзины S3 используются как продолжение идеи FTP серверов… чтоб было куда выгрузить CSV файлики.

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

Есть еще решение вендора – SAP Cloud Platform Integration, которое дает 5-6 RPM, стоит 1’100 баксов в месяц за каждый API-endpoint, и работает только в одну сторону (uni-directional). Документации на это нет в принципе, даже жаба доков нет и дешевых разработчиков на рынке тоже нет. Прикрутить это можно только к продуктивным серверам, так что про тестирование придется забыть – сразу в продакшен. И про VPN/HTTPS придется тоже забыть - криптография для лохов. В техническом плане там просто Apache Camel под капотом, но TCO (total cost of ownership)... в общем вы поймете, что FTP сервера с CSV файликами и 0.001 RPM – это не так уж и плохо.

Нормальная интеграция возможна тоже. У меня, например, свой собственный велосипед который дает по 8’000-10’000 RPM в каждую сторону на одном application server и я без проблем могу даже Kafka Streams поставить в середине. Только, чтобы это получить мне пришлось реверс-инженерить проприетарный TCP протокол и отлавливать баги на протяжении 15 лет. Зато сейчас для меня вопрос интеграции вообще не стоит и я могу развернуть обычный REST/RPC ко всем данным логистики в реальном времени дня за 3-4.

Короче, на каждое успешное скрещивание DS & SAP на сегодня приходится, пожалуй, несколько сотен историй, когда просто не удалось найти приемлемого способа интеграции и проекты банально рассыпались. То есть, даже если у вас и получится выдающаяся математическая модель, очень высока вероятность того, что проект в итоге провалится по технической причине.

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

[tessob]

Я постучался в линкедине.