Comments 80
А если серьёзно — почему SAP?
Видел его в банках, и на вопрос «как вам SAP?» отвечают «нуу… SAP. Работает.»
PS кмк, за 6 лет и 3 вагона денег можно собрать отличную команду, перетряхнуть все процессы, написать ERP под себя и жить счастливо. Не могу понять, зачем в этих условиях SAP? Консультанты излучают пафос вместе с уверенностью и бьют по рукам владельцев бизнеса, чтоб не лезли с дурацкими идеями?
PS кмк, за 6 лет и 3 вагона денег можно собрать отличную команду, перетряхнуть все процессы, написать ERP под себя и жить счастливо
Можно. Кто-то именно так и делает, обычно с простой целью: чтобы через эти 6 лет стать незаменимым техническим директором, которого никогда не уволят с предприятия.
Не могу понять, зачем в этих условиях SAP?
Хорошо выстроенная система продаж во всем мире. Ну и не в последнюю очередь возможность переиспользовать чужой опыт. Например, при автоматизации какого-нибудь нового нефтеперерабатывающего завода в Баликпапане (Индонезия) скорее всего непосредственно у SAP AG или у партнёров найдётся работающее на практике отраслевое решение, которое уже будет покрывать 85% востребованного функционала, ещё скорее всего и локализованное на бахаса. Далеко не все ERP платформы могут таким похвастаться.
В одном разделе для добавления новой записи нужно нажать F4, а в другом — уже F7. На вопросы — а почему так — разводят руками — «Сие есть тайна превеликая». И данная ERP именно в данной отрасли применяется впервые и мы именно первые находим глюки и нестыковки, которые потом исправляются, потом вылазят новые глюки и по новой все.
В SAP не работал, но надеюсь, что там с этим лучше ситуация.
чтобы через эти 6 лет стать незаменимым техническим директором, которого никогда не уволят с предприятия
А чем это отличается от ERP SAP, которая становится незаменимой программой, от которой нельзя отказаться, за поддержку и сопровождение которой необходимо платить суммы, сопоставимые с заработной платой технического директора + бизнес-аналитика + 3 middle-программистов?
А использование чужого опыта в своей работе даёт основание полагать, что ВАШ опыт эти самые консультанты через год-полтора будут применять у ВАШИХ конкурентов.
Кодить на АБАП-е, кстати, одно удовольствие. Во-первых, из-за анально огороженной закрытой системы отпадает куча необходимых действий — не надо заморачиваться о паролях, хэшах и их засолке. Есть у этого и обратная сторона: целый пласт актуальных статей на хабре проходит просто-таки мимо моего понимания. Есть даже поговорка: программист это недоучившийся математик, абапер — недоучившийся программист. Ну и как следствие, абап-разработка переполнена дешевыми индусскими разрабами чуть менее чем полностью, что опосредованно влияет на уровень зарплат (в целом ниже чем в остальных языках)
«Я как технарь вижу, что ваша система более надёжна и вообще лучше продумана чем BrandX. Но если я возьму их и что-то случится, то мне скажут „ну, блин, обидно-то как. Ну ладно, что поделать“, а если возьму вашу и что-то случится, мне скажут „где ты, мудак, их откопал?“. Кроме того, банк готовится на продажу и внедрённый BrandX повышает его стоимость, а ваша система — нет»
его спрашиваю — че ты тащишся?
— ну как же — волна — откат — волна — откат…
с 4х вагонов за сап денежки прилипнет больше чем с полвагона за 1с
С момента написания той самой статьи я успел 3 раза сменить работу, изрядно поднять квалификацию, найти жену, обучить жену основам SQL, пройти курсы, получить дипломы, много раз покраснеть за код, который писал раньше — неужели SAP остался тем же и по техническим вопросам немцы всё так же шлют на неофициальный американский форум, потому что там лучше описано, а в Германии все, кто знал — уже или в маразме, или уволились?
Пользовательский интерфейс который вы видите в SAP Logon, не меняется годами отчасти из-за того, что более менее разумные заказчики заказывают отдельный веб интерфейс для своих нужд или интегрируют функции SAP со своим порталом.
Автор статьи, вероятно, специально поместил скриншоты из устаревшей десктопной версии (хотя она очень удобная, хоть и страшная).
Уже сколько-то лет как сап перешёл на веб интерфейс (и попутно перепилил и упростил модели и переехал на БД HANA), который в целом довольно симпатичный. Плюс отошли от концепции кокпитов (огромный функционал в одном приложении) в пользу маленьких вэб приложений с одной функцией.
Насколько вообще ERP системе нужно быть красивой в ущерб функциональности — время покажет
Ну я не DBA, а разработчик, но если вкратце — хана, это im-memory БД с поколоночным хранением данных (т.е. данные мапятся по ключам и хранятся столбцами, а не кортежами). Кроме того, хана включает в себя множество всяких интересных фич, вроде fuzzy search, каких-то ML штук и вообще очень много всякого полезного, которое, впрочем, мало используется.
Что же касается приложения непосредственно к SAP ERP и подобным системам, то там поверх ханы построена целая надстройка для моделирования данных, используя view, которая называется CDS View. В ней очень много аннотаций и вообще довольно интересная и функциональная штуковина, и на ней построены новые (свежие) продукты от SAP (те, что на ABAP).
Но жрет хана как не в себя, и я сомневаюсь, что ее кто-то вообще покупает отдельно для своих нужд.
покупают, еще как… Только не прям отдельно — т.е. если отдельно нужно инмемори — есть тарантул, aerospike, cassandra (отчасти), ignite и прочая веселуха из мира бигдаты
Да? А можно подробнее — кто и для чего? Мне прям интересно узнать, какие такие кейсы у людей.
На сколько знаю, один крупный банк реализует доступ к архивным данным через Impala для пользователей (а-ля детализация по счёту за 5-10 лет).
Горячие лежат в exadata и выдаются ещё быстрее.
PS кстати, в exadata тоже можно сделать in-memory table/view и колоночное хранение давно реализовано — всё ради скорости.
Статье ОЧЕНЬ не хватает примера какой нибудь таблички. С названиями полей и данными. :)
Это как сыр. Есть такие сыры — в упаковке прикольно выглядят, но когда откроешь — запах "специфический". https://lenta.ru/news/2010/01/26/kaese/amp/
Причем сыр этот не испортился!
Правда, не уверен, что аналогия полная. Сыр то может и не испортился… А вот за миллионы долларов делать самим себе инъекцию очень "ароматного" легаси…
Разумеется, это дело вкуса, но у того же Оракла ERP не такое "пахучее". :)))
Не совсем. Из-за того, что начали раньше заимели большое количество успешных кейсов, которые стали бест практис, которые проще продать.
Да и сейчас, если клиент хочет какое-то уникальное решение, то оно разрабатывается конкретно под заказчика, а дальше допиливается и продается другим клиентам из этой отрасли.
Интересно, 1С:ERP она действительно ЕРП или нет?
Почта, это что-то.
Иконки… надо просто выучить эти пиктограммки, они зачастую не соответствуют общепринятым ассоциациям.
Все модули написаны разными людьми со своим видением мира. Вам надо просто пройти дрессировку для выполнения определённых функций.
Постоянно происходит обслуживание. 3-4 раза в неделю.
Смотришь на тот же МС динамикс и плакать хочеться, почему же в сапе не так…
Роснефть.
По поводу интерфейса.
Всё это не юзабильное UI максимально приближено к стандартным формам документов. То есть экран введения поступления материала похож на форму товарной-накладной и задача кладовщика — верно с бумажки перенести данные в систему. Но технологии на месте не стоят…
Современный SAP выглядит уже не так, как на картинках в статье. В середине прошлого десятилетия SAP начал полностью перерабатывать UI и выкатил Fiori. Это позволило интерфейсу перетечь с SAP Logon на обычный браузер (хотя и раньше была возможность использовать WebGUI).
Сейчас же у компаний есть возможность полностью самостоятельно погрузиться в мир UX/UI и делать интерфейс под себя с минимальными затратами, так как это уже обычный веб и таких специалистов на рынке, как голубей в городских парках. Нужна синяя прозрачная кнопочка в виде котика — нанимай фронтэндера и пусть рисует.
Но если говорить про российские реалии, то тут всё очень сложно. Поменять цвет кнопки и надпись на ней — дело пяти минут и месяца согласований начиная от бухгалтера тёти Тани, заканчивая безопасниками.
Бытует обывательское мнение, что SAP это месть немцев за поражения в мировых войнах.
Динамика изменения рыночной капитализации некоторых компаний иногда удивляет. Как, к примеру, компания со столетней историей и наибольшим патентным портфелем, мать всея машинерия, оказывается аутсайдером рыночной гонки, уступая тридцатилетним выскочкам?
Конечным пользователям дают какой-то недоделанный бэкенд от инженерного интерфейса.
Чем там так особен сап внутри — было бы интересно знать. Там что, не просто реляционная база данных?
Поэтому разработка (и разработчики) уверенно делится на 2 категории — программирование «с белого листа» (по предварительно написанной спецификации) разнообразных форм и отчетов, которую выполняют индусы после 2-недельных курсов (с соответствующей низкой оплатой) — и сложный тюнинг системы, где надо вклинить какой-то кастомный бизнес-процесс в стандартную САПовскую логику, читая простыни комментариев к коду на расовом немецком и пытаясь понять ход мысли сумрачного тевтонского гения. «Хороший САП-разработчик» не означает «хороший программист», а означает «программист, который досконально изучил внутреннее устройство САП-а».
Что еще характерно: фриланс в САП-е не очень распространен. «Выучил АБАП и теперь стригу купоны» — это сложнодостижимый сценарий. Как правило, крупный заказчик не горит запускать в свою инфраструктуру малознакомых контракторов, а заключает подряд с какой-нибудь крупной IT-фирмой (точнее «фермой»), которая за две недели обучает «пушечное мясо» АБАП-у и отправляет кодить для заказчика.
Все, не так плохо. GUI, о котором Вы пишите, давно активно заменяется на нормальный JS фронт — Fiori sapui5
Если интересно узнать про современный SAP почитайте про S/4 и Industry 4.0.
Работаю с SAP последние 10 лет, большой и сложный монолит. Вся его ценность завязана на бухгалтерском фунционале. Интеграция rfc и idoc просто ужасна, немного спасает pi/xi в котором можно выставить ws/rest интерфейсы, пользователи ценят bw как место в котором можно получить рапорты и данные которые из сап нужно вытягивать многими транзакциями и клеить в экселе. Тяжесть сама по-моему следует из оберегаемого и нежно любимого производителем эффекта легаси, монолитичного подхода к базе и корпо подхода sod раздувающего штат на сотни человек в 5 отделах, где нормально справился бы отдел из 10 человек с нормальным софтом. Капитализация и рыночный успех это только следствие правила 95%.
Ну, все правильно — любая технология должна быть достаточно сложной, чтоб откровенные идиоты в нее не залезали. ))
А ещё сап откровенно дорогой. Те задачи, которые им решают, можно решить за сумму в 10 раз меньшую. Неповоротливый? Да, наверное, есть такое, но надо представлять каким реально объемом данных оно ворочает.
Что ещё сказать. Насчёт бизнес процессов все верно написано. Это не ты точишь сап под себя, а свои процессы точишь под сап. В принципе, с 1с та же история. Я помню пример, когда фирма Юлмарт переходила на сап — это было началом конца. С тех пор я шучу, что есть два типа компаний — те, которые не выжили после внедрения сап, и те, которые ещё не внедряли сап ))
Естественно, это все является точкой зрения дилетанта и взглядом со стороны
А насчёт HANA. Если вы ее к себе внедрили, то Вам ханА
Пример
https://x5.ru/ru/Pages/Media/News/310815.aspx
И чем это кончилось https://m.habr.com/ru/company/X5RetailGroup/blog/432412/
Безотносительно качества SAP, в приведённой вами статье автор в основном брызжет слюной, а не аргументирует почему SAP плохой. Получается такая себе анти-антиреклама.
Неповоротливый? Да, наверное, есть такое, но надо представлять каким реально объемом данных оно ворочает.
Вот именно.
Жалкие сотни тысяч — миллионы строк SAP часто считает ЧАСАМИ.
Тем кто хочет увидеть развитие интерфейсов в SAP, рекомендую поискать по запросу "SAP Fiori"
Всем привет из мира SAP! Занимаюсь реализацией и интеграцией проектов на нем уже многие годы.
У SAP есть несколько огромных преимуществ: первое — это отличная интеграция одной прослойки бизнеса в другую. Не надо придумывать новую систему, архитектуру и тд. Достаточно сделать некоторые настройки внутри + небольшая кастомизация кодов для нужд конкретного бизнес процесса. Второе — это отсутствие оверхеда по доп технологиям. Не надо думать о веб-сервере, выборе бд, логированию, придумыванию системы ролей и тд. Для многих вещей разработчики не требуются. Ещё один плюс — это скорость разработки. Нужно сделать новый отчет или поменять логику работы бизнес процесса — как правило на это уходят часы. Ещё один несомненный плюс — это поддержка. Стандартные модули, отчёты, проводки, инструменты и тд. При смене персонала/консалтинговой компании продолжить поддержку системы 10-летней давности не превращается в какой-то неразрешимый ужас.
По-поводу интерфейса. SAP уже несколько лет как активно использует в своих разработках JS-фреймворк SAPUI5, который делает возможность взаимодействия конечных пользователей С с системой простым и понятным. Каждый новый апп делается под конкретную группу пользователей, а бэк остаётся на апп-сервере на ABAP.
Среда разработки встроенная, но несколько лет назад появилась возможность вести разработки через Eclipse, хотя ещё далеко не все компании перешли на нее.
Давненько появилась HANA — calculation in memory BD с поколоночным хранением и разработкой под нее через тот же самый Eclipse.
Кстати, на счёт рисования колонок в GUI — такое ощущение, что автор работал с сап лет 10 назад. Практически никто уже давно таблички не рисует. Есть классы, в которых с помощью кода реализоваешь все отображение данных и ничего не рисуешь руками.
Сейчас SAP активно движется в сторону ABAP in cloud с полноценной поддержкой REST. И полным уходом от GUI.
В общем много всего ещё хорошего и позитивного можно сказать про SAP. А многие его ругают, потому что никогда не пробовали использовать другие продукты. + Есть проблема в разработке для SAP в низкоквалифицированных специалистах. многие из которых никогда не работали на других языках и просто не знают, как должно быть. Из этого часто выливаются проблемы с плохо написанным и плохо протестированных софтом, на который потом и ругаются конечные пользователи.
Есть у SAP и минусы конечно. Но об этом как-нибудь в другой раз (((:
Так что даже наоборот — на протяжении нескольких лет откровенно сам себе завидовал, что не приходится забивать себе голову джава-скриптами за исключением кратковременных запилов в смартформах и PI :)
Взаимно, коллега (: я вот сейчас обучение записываю на абап клауде через эклипс и не могу нарадоваться. И генерация кода адекватная, и хоткеи удобные, и навигацию огонь. До intelijIdea эклипсу конечно далеко. Но мне больше нравится, чем стандартный редактор. И все исходники сразу в виде сорцов, а не эти пресловутые таблички с методами (:
даже Microsoft использует SAP вместо своего собственного ERP-продукта Microsoft Dynamics.
Ссылка на блон, а не официальный ресур плюс аж за 2012 год.
Сейчас на дворе 2020 ;)
Сейчас Х5 управляет более чем 13 000 магазинов. Большинство бизнес-процессов каждого из них проходит через единую ERP-систему. В каждом магазине может быть от 3 000 до 30 000 товаров, это создает проблемы с нагрузкой на систему, т.к. через неё проходят процессы регулярного пересчёта цен в соответствии с промо-акциями и требованиями законодательства и расчёта пополнения товарных запасов. Всё это критично, и если вовремя не будет посчитано, какие товары в каком количестве должны быть завтра доставлены в магазин либо какая цена должна быть на товары, покупатели не найдут на полках то, что искали, либо не смогут приобрести товар по цене действующей промо-акции. В общем, кроме учёта финансовых операций, ERP-система отвечает за многое в повседневной жизни каждого магазина.
Вдумайтесь в эти цифры:
13 000 магазинов. В каждом магазине может быть от 3 000 до 30 000 товаров, это создает проблемы с нагрузкой на систему, т.к. через неё проходят процессы регулярного пересчёта цен в соответствии с промо-акциями и требованиями законодательства и расчёта пополнения товарных запасов.
Берем верхнюю границу — 13000 * 30000 = 390'000'000 SCU
Грубо — всего 400 миллионов позиций, по которым надо рассчитать объем пополнения и цену. И все эти вычисления не обязательно делать «одним куском» — прекрасно можно распараллелить расчет для каждого магазина в отдельности и, возможно, посчитать что то вместе (проверить доступные запасы в распределительных центрах, например).
То есть раз в день надо посчитать 800 миллионов цифр (400 миллионов цен и 400 миллионов пополнений запасов) — и это создает проблемы с нагрузкой на систему.
Я не знаю, может на каких то художников или певцов цифра в 800 миллионов в день и производит впечатление. Но на меня производит впечатление, что в 2018 году это вызывает сложности.
И да, я сам писал и расчет цен с учетом всех акций и скидок, и пополнение складов. Количество SCU было, разумеется, сильно меньше (около 200 тысяч, насколько помню) — но и сервер был всего один и по меркам 2018 года весьма слабый. И никаких проблем с нагрузкой на систему не было. И при росте количества SCU нагрузка вырастает линейно — никаких блокировок там нет — просто берешь набор данных и считаешь.
Берем верхнюю границу — 13000 * 30000 = 390'000'000 SCU
Вы правда думаете, что в КАЖДОМ магазине УНИКАЛЬНЫЙ товар? Чего-то сомневаюсь. Из того, что я вижу — любая Пятерочка обладает в любом регионе плюс-минус одинаковым ассортиментом: молоко "Простоквашино", йогурт "Actimel", бананы весовые и пр.
Да, могут быть региональные отличия. Могут быть в магазинах товары от локального поставщика или под брендом сети (а по факту — опять же от локального поставщика). Но оценка в 390 млн SCU — это перебор.
Но на меня производит впечатление, что в 2018 году это вызывает сложности.
Вызывает сложности. Т.е. задача не выглядит супер-пупер-гипер-ресурсоемкой. Но все равно — это не веб-сайт на единственном сервере крутить. Плюс ERP система это же ведь не только товары. Это еще и график работы сотрудников, расчет зарплаты и прочая дичь.
И SKU (я в предыдущем комментарии ошибся в написании аббревиатуры) — это не уникальный товар. Это комбинация «уникальный товар — уникальный склад».
www.investopedia.com/terms/s/stock-keeping-unit-sku.asp
www.sapdistribution.com/industry-news/step-8-managing-sku-proliferation
В той статье очень много описано именно про эти расчеты. Которые сами по себе относительно простые и не должны вызывать особых сложностей. А если вызывают сложности — это и есть характеристика SAP с технической точки зрения.
То есть ответ на вопрос "Что такое SAP?" звучит так:
SAP — это система, в которой сложно на очень мощном железе раз в день посчитать пополнение для 200 млн SKU. :)))
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
2. Мне очень нравится попытка оценить масштаб задачи по измерениям. Вот только кроме условных «товар» и «магазин» вы забыли измерение «дата». Самый простой пример: чтобы рассчитать потребность магазина в товаре, надо сформировать прогноз продаж. Для прогноза продаж надо заглянуть:
а. В прошлое (посмотреть временной ряд продаж и запасов).
б. В будущее (посмотреть, какие планируются факторы влияния на спрос, например, из-за снижения цены по промо-активности).
В общем, из-за третьего измерения объем задачи недооценен на 2-3 порядка.
LKU, подскажите, а где именно вы встречались с подобной схемой? Все компании, в которых работал и о которых слышал, работали с жестким разделением:
- Расчет “желаемого уровня запасов” на основе анализа продаж за прошлые периоды, акций, рекламных компаний, требований производителей и прочего всегда считался в полуавтоматическом режиме и далеко не каждый день. Максимальная частота пересчетов, о которой знаю — раз в неделю. И система только предлагает свои варианты, но конечное решение всегда за человеком — не взирая ни на какие расчеты менеджер категории может указать — хочу в этом магазине ящик вот такого товара — и именно эта цифра будет зафиксирована.
- Расчет пополнения уровня складских остатков — обычно считается довольно часто и полностью автоматически.
Если не можете назвать компанию — скажите хотя бы область, где так поступают.
Опять же, если мы добавим анализ прошлых продаж и другие факторы — в чем вы видите сложность подобных расчетов? В тех случаях, о которых я знаю, всегда использовали относительно простые формулы, так как с какого то момента при попытке повышении точности прогноза упираешься в “потолок” — на уровне комбинации конкретной торговой точки / товара начинают проявляться случайные факторы (пришел конкретный Петя за покупками сегодня или решил пойти завтра), и никакие расчеты не помогают.
Если вы знаете примеры, когда оправданы сложные расчеты — расскажите, думаю многим будет интересно.
3. Результатом расчета пополнения не является одна цифра на товар/магазин. Никому не интересен черный ящик, без промежуточных показателей расчета, это вам не котиков распознавать нейросеткой :)
Тоже — подскажите, где именно (в каких областях) требуется в качестве результата расчета не одна цифра на товар/магазин, а еще и промежуточные результаты? Я подобными вещами плотно занимался в четырех разных фирмах, общался на эти темы с коллегами и знаю о ситуации еще минимум в паре десятков других фирм — всегда расчет пополнения — это одна цифра. Промежуточные результаты если и интересовали, то только при написании и отладке кода.
Возможно, вы говорите о расчетах требуемого уровня запасов (анализ динамических рядов, прогноз продаж, акции и тп)?
4. До расчета пополнения и после расчета пополнения есть свои критичные бизнес-процессы, которые должны отработать в строгой последовательности.
Например, результатом расчета пополнения является даже не одна строка в таблице в разрезе товар/магазин. Результатом являются документы в ERP, на которые навешена своя существенная бизнес-логика. Скажем, заказы на распределительные центры должны быть переданы на исполнение в РЦ, а заказы внешним поставщикам — отправлены им для исполнения (в основном, по EDI).
5. Все эти ежедневно рассчитываемые цифры являются бизнес-критичными. Это значит две вещи:
— у бизнеса непрерывно есть требования, как улучшить процесс пополнения
— элементарная ошибка в логике расчета даже по одному товару может привести к космическим коммерческим потерям (просто представьте себе что будет, если при заказе кока-колы по ошибке сконвертировать рассчитанную потребность в бутылках в коробки как один к одному).
Надеюсь, я немного расширил представление о задаче пополнения в розничной сети магазинов в плоскости ИТ.
Откровенно говоря, я это знал и раньше. Я ведь писал, что работал с подобными задачами.
Вот здесь
www.sql.ru/forum/1244237-1/algoritm-rezervirovaniya-dlya-neskolkih-skladov
обсуждали вопросы резервирования и там же немного затронули и все эти бизнес процессы, о которых вы говорите.
Ну и, наконец, всё упирается в финансовый результат.
В недавнем отчете о 250 крупнейших ритейлерах мира, Россия представлена четырьмя компаниями. У трех из них в качестве ERP системы используется SAP. А конкретно X5 еще и на 29м месте в мире по скорости роста за пятилетку.
www2.deloitte.com/content/dam/Deloitte/be/Documents/Report_GPR2018.pdf
А это к чему? Мы обсуждаем технические характеристики системы.
Если при обсуждении технических вопросов слишком сильно концентрироваться на финансовых результатах и аргументах в стиле PR менеджеров и маркетологов — получится как с Боингом. ru.wikipedia.org/wiki/Boeing_737_MAX
1. Ссылку на финансовые результаты я дал потому, что качество автоматической системы пополнения магазинов (автозаказа) — это один из нескольких критических бизнес-процессов для розничной сети, который на эти результаты влияет просто напрямую.
2. Про основную идею. При заранее известном графике поставок (характерно для розницы) оптимально при каждом расчете заказа на дату поставки 1 рассчитывать оптимальный размер заказа так, чтобы к поступлению товара по следующему заказу (на дату поставки 2) запас был равен необходимому (регулярная выкладка + дополнительная выкладка + страховой запас).
Фиксированный целевой уровень запаса при поступлении на дату поставки 1 проигрывает этой модели (это мое личное мнение, в холивар тут не хотелось бы впадать).
3. Что касается моего опыта и где эта модель применяется — я был архитектором на проектах создания системы пополнения в 10 федеральных розничных сетях России. Правда, существенная часть из них управляется одной материнской группой компаний и расчет пополнения выполняется в одной информационной системе.
Названия сетей называть не буду, но в любом сколько-нибудь крупном ТЦ в Москве вы их встретите :)
Отрасли разные — продукты, детские товары, одежда и обувь, потребительская электроника.
Я так понимаю, вы описываете
Time-phased planning
help.sap.com/doc/saphelp_470/4.7/en-US/f4/7d255644af11d182b40000e829fbfe/frameset.htm
Я работал в ситуациях с центральным (распределительным) складом, с которого раз в день / раз в два дня выполнялась «подпитка» складов магазинов. И в таком случае лучше работает Reorder Point Planning
То есть пересчет точки дозаказа выполнялся относительно редко — раз в месяц, не чаще, а расчет пополнения — каждый день.
У нас не сап был, но алгоритмы расчетов плюс минус похожие.
3. Результатом расчета пополнения не является одна цифра на товар/магазин. Никому не интересен черный ящик, без промежуточных показателей расчета, это вам не котиков распознавать нейросеткой :)
Кстати, мне все равно не ясно — а какие «промежуточные» параметры вы анализировали и зачем?
Возвращаясь к SAP — вопрос не в качестве алгоритмов расчета пополнения запасов — они у сапа относительно стандартные и описаны в книжках и статьях о логистике и управлении запасами и, насколько знаю, реализованы корректно. Вопрос — почему появляются проблемы с этими относительно несложными расчетами на относительно небольших объемах данных?
Именно это и вызывает недоумение.
Кстати, мне все равно не ясно — а какие «промежуточные» параметры вы анализировали и зачем?
Вам это непонятно ровно потому же, почему непонятно зачем я давал ссылку на финансовые показатели.
В крупной рознице есть постоянный цикл обратной связи по оптимизации существующих процессов.
Упрощенно так:
1. Обнаружили глобальное ухудшение оборачиваемости
2. Нашли, что за существенную часть негативного эффекта ответственны конкретные SKU сковородок, запас которых в торговой сети составляет 5 лет продаж
3. Нашли расчет автозаказа, по которому были заказаны эти сковородки, проанализировали и выяснили что за большой объем заказа отвечает в данном случае тот факт, что в рамках промо-акции ХХХ некий менеджер Иванов заложил дополнительную выкладку по 1000 сковородок в каждый магазин, а его начальник Петров это согласовал.
Дальше движения могут пойти по линии СБ, но нас интересует ИТ составляющая и тут в ИТ может прийти задача контролировать плановый размер доп. выкладки по некому алгоритму до согласования промо-акции, чтобы в будущем избежать таких проблем.
Вывод такой — если хотите увеличивать эффективность системы, нужна отслеживаемость причинно-следственных связей, в том числе какие числа подставились в формулу расчета автозаказа и откуда они взялись.
Возвращаясь к SAP — вопрос не в качестве алгоритмов расчета пополнения запасов — они у сапа относительно стандартные и описаны в книжках и статьях о логистике и управлении запасами и, насколько знаю, реализованы корректно. Вопрос — почему появляются проблемы с этими относительно несложными расчетами на относительно небольших объемах данных?
Именно это и вызывает недоумение.
Я думаю, тут комплекс причин:
1. Масштаб задачи (число обсчитываемых комбинаций товар/магазин/дата).
2. Через несколько лет после начала работы никто не использует базовые простые алгоритмы SAP. Или существенно их дорабатывают, или пишут с нуля свою систему пополнения внутри SAP. Это факт может не очень приятный для SAP как вендора, но такова жизнь (см. выше про цикл улучшений).
3. Базовые алгоритмы SAP действительно не самые оптимальные из тех что можно написать относительно размена (время работы) vs (потребляемая оперативная память).
Местами видим селекты в циклах вместо массовой выборки данных, где-то кеширования не хватает на уровне сервера приложений, где-то наоборот кешируют, но таблицу во всю ширину (select *) вместо выборки нескольких нужных полей и т.п.
Практика показывает, что если с умом писать систему пополнения на встроенном в SAP языке программирования ABAP, то тот же объем данных на тех же мощностях можно обсчитывать примерно в 10 раз быстрее.
Вам это непонятно ровно потому же, почему непонятно зачем я давал ссылку на финансовые показатели.
:)))
Я как то за год скорость оборота в полтора раза увеличил.
А то, что вы описываете — это не «промежуточные показатели расчета», а входные данные. ))
Я думаю, тут комплекс причин:
1. Масштаб задачи (число обсчитываемых комбинаций товар/магазин/дата).
Давайте говорить откровенно — это довольно маленькие объемы данных.
Практика показывает, что если с умом писать систему пополнения на встроенном в SAP языке программирования ABAP, то тот же объем данных на тех же мощностях можно обсчитывать примерно в 10 раз быстрее.
Предполагаете, проблема Х5 — низкая квалификация их разработчиков?
Публичные споры о том «куча бананов — это сколько?» и какая квалификация у сотрудников конкретной компании (разная, конечно!) мне не очень интересны.
Предлагаю на этом остановиться.
Такая система, что в 2000, что в 2010, что в 2020 по-прежнему оценивается по сложности в 1-10М LOC (строчек кода).
1. Неоправданно дорогая система. Её внедрение и поддержка не окупается. Мы с бухгалтерами считали. Ни количество персонала, ни затраты в итоге не снижаются. Где убыл 1 рабочий завода — там прибыл 1 SAP-консультант.
2. Совершенно не user-friendly интерфейс. Вся система состоит из кодов и немецких шифровок. Алан Тьюринг офигел бы от попытки всё расшифровать. Про графические элементы и составляющие интерфейса я вообще молчу.
3. Куча устаревшего функционала, написанного
4. Язык ABAP — это убийство для современного разработчика. Даже C на его фоне кажется прорывом. Куча кода пишется в открытую, когда можно было встроить скрытые реализации. Длинные конструкции, которые возвращают вас в детство и школьный Pascal. Один код включает другой код, а тот — третий и т.д. — ни о каких современных концепциях хранения кода не идёт и речи. Вишенка на торте — неадекватные типы данных и всякие «филдсимволы».
5. Документация и туториалы из серии BC просто бесполезны. Детские примеры и скупые описания. Как итог — опыт разработки передаётся из уст в уста.
Вердикт: если вы уже знаете один из популярных ЯП и не имеете склонностей к БДСМ — не суйтесь в SAP.
А по удобству это как со СФИВТ — колоться, плакать но продолжать есть кактус ибо безальтернативно.
Для работы на территории СНГ, это лично моё мнение, 1С с его модулями выше крыши достаточно, да и затраты на его интеграцию и поддержку в разы меньше. Ну а Европа вся подмята SAP и Siemens(
Что такое SAP?