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

[StrangerR]

Та же электронная почта пришла в российский бизнес только через несколько лет после Запада.

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

[Lisa]

Я изучаю Data Science чтобы в дальнейшем зарабатывать на этом. Понятно что если в штатах DS идет хорошо, то в России он тоже нужен. Но будущие клиенты и я не знают точно как:)

Ну вы послушайте как это звучит со стороны. «Я не знаю зачем это вам нужно, опыта у меня никакого нет, успешных внедрений тоже нет, но денег дайте». Смешно же.

[Andrey Strelnikov]

Я изучаю Data Science чтобы в дальнейшем зарабатывать на этом. Понятно что если в штатах DS идет хорошо, то в России он тоже нужен. Но будущие клиенты и я не знают точно как:)

Ну вы послушайте как это звучит со стороны. «Я не знаю зачем это вам нужно, опыта у меня никакого нет, успешных внедрений тоже нет, но денег дайте». Смешно же.

Ну в нашем случае не совсем так. Реально никто никуда не пошел и никаких денег не спрашивает.

Я просто ищу программы развития применительно к реальным будущим потребностям будущих клиентов. Но DS , AI достаточно обширно. Думать надо как развиваться.

Успешные внедрения - скоро будет ровно десят лет как начали на подхвате делать BI. Были только теоретические знания. Успехи есть
Будут и в DS.

[valchkou]

Я просто ищу программы развития применительно к реальным будущим потребностям будущих клиентов. Но DS , AI достаточно обширно. Думать надо как развиваться.

Успешные внедрения - скоро будет ровно десят лет как начали на подхвате делать BI. Были только теоретические знания. Успехи есть
Будут и в DS.

BI втюхнуть легче, это всего лишь визуализация того что было. Все любят графики. Особенно их обожают топ руководители.
c DS сложнее.
Одна из сфер тут это медицина, диагнозы, предсказание болезней, поиск оптимального лечения.
Пока я не вижу чтобы это применялось, но идут активные инвестиции. Тут проблема получить данные, каждый госпиталь сам себе хозяин, гос программы нет.
Есть стартапы которые берут например ученного, доктора, программиста и пытаются запилить модель и затем подписать на нее клиента ввиде доктора/госпиталя.
В россии это бы пошло веселее, так как больницы государственные в большинстве. Всех можно подключить одним махом да еще и под гос финансы.

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

[Lisa]

- логистика: оптимизация и удешевление перевозок, загрузки контейнеров и траков, прокладки маршрутов.

Это вообще не DS. Этим занимаются не один десяток лет и есть куча стандартных решений.

[Lisa]

Ну в нашем случае не совсем так. Реально никто никуда не пошел и никаких денег не спрашивает.

Я просто ищу программы развития применительно к реальным будущим потребностям будущих клиентов. Но DS , AI достаточно обширно. Думать надо как развиваться.

Успешные внедрения - скоро будет ровно десят лет как начали на подхвате делать BI. Были только теоретические знания. Успехи есть
Будут и в DS.

Это разные вещи. Для внедрения BI никаких особых знаний кроме самого BI не нужно. Для успешного применения DS самое критичное это доменные знания и экспертиза в бизнесе. Без этого никакие успешные разработки и тем более внедрение решений невозможны.

[Andrey Strelnikov]

Я просто ищу программы развития применительно к реальным будущим потребностям будущих клиентов. Но DS , AI достаточно обширно. Думать надо как развиваться.

Успешные внедрения - скоро будет ровно десят лет как начали на подхвате делать BI. Были только теоретические знания. Успехи есть
Будут и в DS.

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

Большое спасибо
Самая ценная информация. Конечно общеизвестная, но сам топик сразу стал конструктивным.
Для чего я начал этим заниматься ?
Вот я вижу что половина студентов програмистов и тп вылетает на первом-втором курсе из-за выш математики. Как в наше время так и сейчас.
А из тех кто закончил вуз, пять процентов видят эту математику в дальнейшей карьере.
Вот дочь у меня будет поступать тоже на погроммиста. И я не хочу чтобы она зря потратила силы и время а потом занималась сайтами и тп. Надо готовить бизнес...
Тем более что такое направление пока не освоено здесь. Можно будет брать просто сильных математиков и тд.

[Andrey Strelnikov]

Ну в нашем случае не совсем так. Реально никто никуда не пошел и никаких денег не спрашивает.

Я просто ищу программы развития применительно к реальным будущим потребностям будущих клиентов. Но DS , AI достаточно обширно. Думать надо как развиваться.

Успешные внедрения - скоро будет ровно десят лет как начали на подхвате делать BI. Были только теоретические знания. Успехи есть
Будут и в DS.

Это разные вещи. Для внедрения BI никаких особых знаний кроме самого BI не нужно. Для успешного применения DS самое критичное это доменные знания и экспертиза в бизнесе. Без этого никакие успешные разработки и тем более внедрение решений невозможны.

Согласен. Но это все нарабатывается. И это дело не одного года. Если было бы просто то давно бы уже стартанули.

[valchkou]

- логистика: оптимизация и удешевление перевозок, загрузки контейнеров и траков, прокладки маршрутов.

Это вообще не DS. Этим занимаются не один десяток лет и есть куча стандартных решений.

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

[Lisa]

- логистика: оптимизация и удешевление перевозок, загрузки контейнеров и траков, прокладки маршрутов.

Это вообще не DS. Этим занимаются не один десяток лет и есть куча стандартных решений.

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

Ну если любую математику в индустрии называть DS, тогда да. Но с чего вдруг? Математика для оптимизации перевозок и прокладки маршрутов придумана десятки лет назад.

[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]

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