Что такое SAP?

Original author: Abdul Nimeri
  • Translation


Что такое SAP? И с какого лешего она стоит $163 миллиарда?

Каждый год компании тратят $41 млрд на софт для планирования корпоративных ресурсов, известный под аббревиатурой ERP. Сегодня практически в каждом крупном бизнесе внедрена та или иная ERP-система. Но большинство маленьких компаний обычно не покупают ERP-системы, а большинство разработчиков, вероятно, и не видели их в деле. Так что у тех из нас, кто не использовал ERP, возникает вопрос… в чём прикол? Как компания вроде SAP умудряется продавать ERP на $25 млрд в год?

И как получилось, что 77% мировой торговли, в том числе 78% поставок продуктов питания, проходит через программы SAP?

ERP — то место, где компании хранят основные операционные данные. Мы говорим о прогнозах продаж, заказах на покупку, складских запасах, а также о процессах, которые срабатывают на основе этих данных (например, выплаты поставщикам при оформлении заказов). В некотором смысле ERP является «мозгом» компании — она хранит все важные данные и все действия, которые инициируются этими данными в рабочих процессах.

Но прежде чем полностью захватить современный мир бизнеса, как вообще появилось это программное обеспечение? История ERP начинается с серьёзной работы по автоматизации офисной деятельности в 1960-е годы. Ранее, в 40-е и 50-е годы происходила главным образом автоматизация механической работы «синих воротничков» — вспомните General Motors, создавшую свой отдел автоматизации в 1947 году. А вот автоматизация работы «белых воротничков» (часто с помощью компьютеров!) началась в 60-е.

Автоматизация 60-х: появление компьютеров


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

К 60-м годам многие компании для автоматизации расчёта зарплаты и выставления счетов использовали компьютеры IBM. Процессинг данных —устаревший термин, от которого осталась только компания Automatic Data Processing, Inc. Вместо него сегодня мы говорим «ИТ». Тогда ещё не сформировалась отрасль разработки программного обеспечения, поэтому в отделы ИТ часто брали аналитиков и учили их программировать на месте. Первый в США факультет Computer Science открыл университет Пердью в 1962 году, а первый выпуск по специальности состоялся спустя несколько лет.



Написание программ для автоматизации/обработки данных в 60-е годы было сложной задачей из-за ограничений памяти. Не было ни языков высокого уровня, ни стандартизированных операционных систем, ни персональных компьютеров — только большие дорогие мейнфреймы с небольшим объёмом памяти, где программы запускались на катушках магнитной ленты! Программисты часто работали с компьютером по ночам, когда он был свободен. Для компаний вроде General Motors обычным делом было писать собственные операционные системы, чтобы получить максимальную отдачу от своих мейнфреймов.

Cегодня мы запускаем прикладное программное обеспечение в нескольких стандартных операционных системах, но такого не было до 1990-х гг. В средневековую эпоху мейнфреймов 90% всего программного обеспечения писалось на заказ, и только 10% продавалось в готовом виде.

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

Рождение стандартного программного обеспечения: расширяемая программа SAP


В 1972 году пять инженеров уволились из IBM, чтобы заключить контракт на поставку программного обеспечения с крупной химической фирмой под названием ICI. Они основали новую компанию под названием SAP (Systemanalyse und Programmentwicklung или «системный анализ и разработка программ»). Как и большинство разработчиков программного обеспечения в то время, они в основном занимались консалтингом. Сотрудники SAP приходили в офисы клиентов и разрабатывали софт на их компьютерах, в основном, для управления логистикой.



Бизнес шёл хорошо: SAP закончила первый год с выручкой в 620 тыс. марок, что чуть больше $1 млн в сегодняшних долларах. Вскоре они начали продавать своё программное обеспечение другим клиентам, портируя его на различные операционные системы, когда это было необходимо. За следующие четыре года у них появилось более 40 клиентов, доход вырос в шесть раз, а число сотрудников увеличилось с 9 до 25. Может, это далековато от кривой роста T2D3, но будущее SAP выглядело оптимистично.

Программное обеспечение SAP было особенным по нескольким причинам. В то время большинство программ работало по ночам и печатало результат на бумажных лентах, которые вы проверяли на следующее утро. Вместо этого программы SAP работали в режиме реального времени, причём результат выводился не на бумагу, а на мониторы (которые в то время стоили около $30 тыс.).

Но самое главное, программное обеспечение SAP изначально создавалось расширяемым. В первоначальном контракте с ICI компания SAP не создавала программное обеспечение с нуля, как было принято в то время, а писала код поверх предыдущего проекта. Когда SAP выпустила своё программное обеспечение для финансового учёта в 1974 году, то изначально планировала в будущем писать поверх него дополнительные программные модули и продавать их. Такая расширяемость стала определяющей особенностью SAP. В то время взаимодействие между клиентскими контекстами считалось радикальной инновацией. Программы писались с нуля для каждого клиента.

Важность интеграции


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

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

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

Скорость доступа к информации в интегрированном ПО позволяет компаниям полностью изменить свои бизнес-модели. Компания Compaq с помощью ERP внедрила новую модель «производство по заказу» (то есть сборка компьютера только после явного получения заказа). Эта модель экономит деньги, уменьшая складские запасы, полагаясь на быстрый оборот — именно то, в чём помогает грамотная ERP. Когда IBM последовала тому же примеру, то сократила время доставки комплектующих с 22-х до трёх дней.

Как на самом деле выглядит ERP


Слова «корпоративное программное обеспечение» никак не ассоциируется с модным и удобным интерфейсом, и SAP не исключение. Базовая установка SAP содержит 20 000 таблиц БД, 3000 из которых являются таблицами конфигурации. В этих таблицах около 8000 конфигурационных решений, которые нужно принять ещё до начала работы программы. Вот почему SAP Configuration Specialist — это реальная профессия!

Несмотря на сложность настройки, программное обеспечение SAP ERP обеспечивает ключевую ценность — широкую интеграцию между собой нескольких бизнес-процессов. Эта интеграция приводит к тысячам вариантов использования в организации. SAP организует эти варианты использования в «транзакциях», которые представляют собой бизнес-действия. Некоторые примеры транзакций включают «создание заказа» и «отображение клиента». Эти транзакции организованы в формате вложенного каталога. Таким образом, чтобы найти транзакцию «Создать заказ на продажу», вы идёте в каталог «Логистика», затем «Продажи», затем «Заказ», и там найдёте фактическую транзакцию.



Если назвать ERP «браузером транзакций», то это будет удивительно точным описанием. Он очень похож на браузере, тут есть кнопка «Назад», кнопки зуммирования и текстовое поле для кодов “TCodes”, эквивалент адресной строки в браузере. SAP поддерживает более 16 000 типов транзакций, поэтому навигация по дереву транзакций может быть сложной без этих кодов.

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

Данные


В интерфейсе SAP разработчики могут создавать собственные таблицы БД. Это реляционные таблицы как обычные базы SQL: столбцы различных типов, внешние ключи, ограничения значений, а также разрешения на чтение/запись.

Логика


SAP разработала язык под названием ABAP (Advanced Business Application Programming, первоначально Allgemeiner Berichts-Aufbereitungs-Prozessor, по-немецки «общий процессор создания отчётов»). Он позволяет разработчикам запускать индивидуальную бизнес-логику в ответ на определённые события или по расписанию. ABAP — это язык с богатым синтаксисом, здесь примерно втрое больше ключевых слов, чем в JavaScript (см. реализацию игры 2048 на языке ABAP). Когда вы написали свою программу (в SAP есть встроенный редактор для программирования), то публикуете её как собственную транзакцию, вместе с индивидуальным кодом TCode. Можете настроить существующее поведение с помощью обширной системы хуков, которые называются «бизнес-надстройками» (add-ins), где программа настраивается для запуска при выполнении определённой транзакции — аналогично триггерам SQL.

UI


SAP также поставляется с конструктором для создания UI. Он поддерживает драг-н-дроп и поставляется с удобными функциями, такими как сгенерированные формы на основе таблицы БД. Несмотря на это, его довольно трудно использовать. Моя любимая часть конструктора — рисование столбцов таблицы:



Трудности внедрения ERP


ERP стоит недёшево. Крупная транснациональная корпорация может потратить на внедрение от $100 млн до $500 млн, включая $30 млн лицензионных платежей, $200 млн за консалтинговые услуги, остальное на аппаратное обеспечение, обучение менеджеров и сотрудников. Полное внедрение занимает от четырёх до шести лет. Генеральный директор крупной химической компании сказал: «Конкурентное преимущество в отрасли получит фирма, которая сможет лучше и дешевле провести работы по внедрению SAP».

И дело не только в деньгах. Внедрение ERP — рискованное предприятие, и результаты сильно отличаются. Одним из успешных кейсов считается внедрение ERP в Cisco, которое заняло 9 месяцев и $15 млн. Для сравнения, внедрение в корпорации Dow Chemical стоило $1 млрд и заняло 8 лет. ВМФ США потратил $1 млрд на четыре различных проекта ERP, но все потерпели неудачу. Аж 65% руководителей считают, что внедрение ERP-систем несёт «умеренный шанс повредить бизнесу». Такое нечасто услышишь при оценке программного обеспечения!

Интегрированная природа ERP означает, что для её внедрения требуются усилия компании целиком. А поскольку компании получают выгоду только после повсеместного внедрения, это особенно рискованно! Внедрение ERP — не просто решение о покупке: это обязательство изменить свои методы управления операциями. Установка программного обеспечения — это легко, перенастройка рабочего процесса всей компании — вот где основная работа.

Для внедрения у себя ERP-системы клиенты часто нанимает консалтинговую фирму, такую как Accenture, и платят ей миллионы долларов за работу с отдельными бизнес-подразделениями. Аналитики определяют, как интегрировать ERP в процессы компании. И как только интеграция начинается, компания должна начать обучение всех сотрудников, как использовать систему. Gartner рекомендует резервировать 17% бюджета только на обучение!

Несмотря на все трудности, большинство компаний из списка Fortune 500 внедрили ERP-системы к 1998 году: процесс ускорился страхом Y2K. Рынок ERP продолжает расти и сегодня превышает $40 млрд. Это один из крупнейших сегментов в мировой индустрии программного обеспечения.

Современная индустрия ERP


Крупнейшими игроками являются Oracle и SAP. Хотя обе являются лидерами рынка, их ERP-продукты удивительно отличаются. Продукт SAP был в основном построен внутри компании, в то время как Oracle агрессивно скупила конкурентов, таких как PeopleSoft и NetSuite.

Oracle и SAP настолько доминируют, что даже Microsoft использует SAP вместо своего собственного ERP-продукта Microsoft Dynamics.

Поскольку в большинстве отраслей довольно специфические потребности в ERP, у Oracle и SAP есть готовые конфигурации для многих отраслей, таких как пищевая, автомобильная и химическая, а также вертикальные конфигурации, такие как процессы организации продаж. Тем не менее, всегда остаётся место для нишевых игроков, которые, как правило, ориентируются на конкретную вертикаль:

  • Ellucian Banner для университетов
  • Infor и McKesson предлагают ERP для организаций здравоохранения
  • QAD для производства и логистики

Вертикальные ERP специализируются на интеграциях и рабочих процессах, специфичных для целевого рынка: например, в ERP для здравоохранения могут поддерживать протоколы HIPAA.

Однако специализация — не единственная возможность найти свою нишу на рынке. Некоторые стартапы пытаются вывести на рынок более современные программные платформы. Примером может служить Zuora: она предлагает возможность интеграции (с разными ERP!) по подписке. Стартапы вроде Anaplan и Zoho предлагают то же самое.

ERP на подъёме?


В 2019 году SAP чувствует себя прекрасно: в прошлом году выручка составила €24,7 млрд, а рыночная капитализация сейчас превысила €150 млрд. Но мир программного обеспечения уже не тот, что раньше. Когда SAP впервые появилась, данные были изолированы и трудно интегрировались, так что хранение всего этого в SAP казалось очевидным ответом.

Но теперь ситуация быстро меняется. У большинства современных корпоративных программ (например, Salesforce, Jira и т. д.) есть бэкенд с хорошими API для экспорта данных. Формируются озёра данных: например, Presto облегчает соединение между собой баз данных, невозможное всего несколько лет назад.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 80

    +31
    Интерфейс из 2000х, 3000 словарей из 70х, нужен консультант-настройщик, консультант-консультант, консультант-тренер, перестройка бизнеса, 9 лет времени и 4 вагона денег: привет, SAP, ERP мечты! /sarcasm
    • UFO just landed and posted this here
        +8
        Практически безграничные возможности — это у С/С++, и то иногда нужны ассемблерные вставки.
        А если серьёзно — почему SAP?
        Видел его в банках, и на вопрос «как вам SAP?» отвечают «нуу… SAP. Работает.»
        PS кмк, за 6 лет и 3 вагона денег можно собрать отличную команду, перетряхнуть все процессы, написать ERP под себя и жить счастливо. Не могу понять, зачем в этих условиях SAP? Консультанты излучают пафос вместе с уверенностью и бьют по рукам владельцев бизнеса, чтоб не лезли с дурацкими идеями?
          +4
          PS кмк, за 6 лет и 3 вагона денег можно собрать отличную команду, перетряхнуть все процессы, написать ERP под себя и жить счастливо

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

          Не могу понять, зачем в этих условиях SAP?

          Хорошо выстроенная система продаж во всем мире. Ну и не в последнюю очередь возможность переиспользовать чужой опыт. Например, при автоматизации какого-нибудь нового нефтеперерабатывающего завода в Баликпапане (Индонезия) скорее всего непосредственно у SAP AG или у партнёров найдётся работающее на практике отраслевое решение, которое уже будет покрывать 85% востребованного функционала, ещё скорее всего и локализованное на бахаса. Далеко не все ERP платформы могут таким похвастаться.
            +1
            Спасибо, теперь наконец-то понятен профит SAP: «у нас есть большой опыт в автоматизации, управлении и учете <название_отрасли>, купите наш продукт — и опыт станет работать на вас. (Если хватит денег и вы сможете перестроить бизнес под лучшие практики)».
              +2
              Работаю сейчас с ERP-системой одной маленькой немецкой фирмы, системе всего лет 10-12. Дизайн из 90-х, куча ошибок, которые нужно исправлять. Куча открывающихся окон для того, чтобы посмотреть разную информацию. Спасает только два-три монитора с несколькими запущенными приложениями.
              В одном разделе для добавления новой записи нужно нажать F4, а в другом — уже F7. На вопросы — а почему так — разводят руками — «Сие есть тайна превеликая». И данная ERP именно в данной отрасли применяется впервые и мы именно первые находим глюки и нестыковки, которые потом исправляются, потом вылазят новые глюки и по новой все.
              В SAP не работал, но надеюсь, что там с этим лучше ситуация.
                +1
                Могу сказать что не лучше. Редактор кода там досихпор имеет ограничение в 80 символов на строку…
                +5
                чтобы через эти 6 лет стать незаменимым техническим директором, которого никогда не уволят с предприятия

                А чем это отличается от ERP SAP, которая становится незаменимой программой, от которой нельзя отказаться, за поддержку и сопровождение которой необходимо платить суммы, сопоставимые с заработной платой технического директора + бизнес-аналитика + 3 middle-программистов?
                А использование чужого опыта в своей работе даёт основание полагать, что ВАШ опыт эти самые консультанты через год-полтора будут применять у ВАШИХ конкурентов.
                  –1

                  А ещё sap наверняка кушает аппаратные ресурсы не в себя. И ещё наверняка простые диалоговые окна в нем могут открываться по 5 минут

                    +3
                    на удивление нет. Реакция интерфейса зависит только от загрузки сети и резвости сервера приложений, который легко масштабируется.
                    +1
                    Bus factor?
                    • UFO just landed and posted this here
                        +1
                        будут, но им это не поможет. Всеравно много чего придется переделать.
                    • UFO just landed and posted this here
                        +1
                        Каждый раз, когда я сталкивался с SAP'ом и спрашивал о причинах выбора, мне неизменно отвечали, что никакая другая ERP не способна прожевать их объёмы данных. Кроме того, озвучивалось мнение, что SAP существенно стабильнее той же 1С, даже если во внедрение последней грохнуть столько же денег.
                          +1
                          Рискну предположить, что для: а) аудита б) стандартизации. Аудитору проще проверифицировать бизнес-процесс, который ведется в САП-е, нежели в решении от «рога и копыта». Во-вторых, если компанию продают, покупающим гораздо меньше времени требуется на реорганизацию, так как используются более-менее стандартные тулзы.

                          Кодить на АБАП-е, кстати, одно удовольствие. Во-первых, из-за анально огороженной закрытой системы отпадает куча необходимых действий — не надо заморачиваться о паролях, хэшах и их засолке. Есть у этого и обратная сторона: целый пласт актуальных статей на хабре проходит просто-таки мимо моего понимания. Есть даже поговорка: программист это недоучившийся математик, абапер — недоучившийся программист. Ну и как следствие, абап-разработка переполнена дешевыми индусскими разрабами чуть менее чем полностью, что опосредованно влияет на уровень зарплат (в целом ниже чем в остальных языках)
                            +4
                            Почему покупают BrandX, а не пишут своё или не заказывают разработку на стороне, мне лет 10 назад на пальцах объяснил один IT-директор одного известного тогда банка.
                            «Я как технарь вижу, что ваша система более надёжна и вообще лучше продумана чем BrandX. Но если я возьму их и что-то случится, то мне скажут „ну, блин, обидно-то как. Ну ладно, что поделать“, а если возьму вашу и что-то случится, мне скажут „где ты, мудак, их откопал?“. Кроме того, банк готовится на продажу и внедрённый BrandX повышает его стоимость, а ваша система — нет»
                              +1
                              Все просто по настоящему. Есть правило — хочешь выйти на IPO нужен SAP. Он сейчас стандарт де факто для определенных отраслей.
                                +2
                                сидит чиновник на берегу моря и пялится в прибой.
                                его спрашиваю — че ты тащишся?
                                — ну как же — волна — откат — волна — откат…
                                с 4х вагонов за сап денежки прилипнет больше чем с полвагона за 1с
                                  0
                                  Потому что внедрённые решения от Oracle и SAP увеличивают рыночную стоимость публичной компании в глазах аналитиков. А что то другое внедренное — нет. Не важно насколько это справедливо, это просто факт, который приходится учитывать.
                                  +3
                                  Возможности безганичные, но огромное количество внедрений закнчивается провалом))))
                                • UFO just landed and posted this here
                                    0
                                    Эту статью на лурке я помню, и даже помню статью на хабре с комментами (ныне недоступную), на которую ссылается лурк, но неужели за это время в SAP ничего не изменилось?
                                    С момента написания той самой статьи я успел 3 раза сменить работу, изрядно поднять квалификацию, найти жену, обучить жену основам SQL, пройти курсы, получить дипломы, много раз покраснеть за код, который писал раньше — неужели SAP остался тем же и по техническим вопросам немцы всё так же шлют на неофициальный американский форум, потому что там лучше описано, а в Германии все, кто знал — уже или в маразме, или уволились?
                                      +2
                                      Нууууу… Почему же прям тем же. Недавно на работе зашёл в SAP — а там иконки на новые плоские перерисовали, улучшения явно на лицо! :)))
                                      +7
                                      Я просто оставлю это здесь :)

                                      А я — это ;) Сэкономлю людям время.

                                      image
                                      0
                                      Но имя, репутация… да и кормушка для огромного штата… В общем своего рода секта.
                                      0
                                      Я думал наша Галактика по интерфейсу осталась в прошлом веке, а оказывается и лидер индустрии, м-да…
                                        +1

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

                                          +1

                                          Автор статьи, вероятно, специально поместил скриншоты из устаревшей десктопной версии (хотя она очень удобная, хоть и страшная).
                                          Уже сколько-то лет как сап перешёл на веб интерфейс (и попутно перепилил и упростил модели и переехал на БД HANA), который в целом довольно симпатичный. Плюс отошли от концепции кокпитов (огромный функционал в одном приложении) в пользу маленьких вэб приложений с одной функцией.


                                          Насколько вообще ERP системе нужно быть красивой в ущерб функциональности — время покажет

                                            +1
                                            О, расскажите про Hana — на сколько понимаю, это ещё одна реализация Big Data + in-memory MPP, только от SAP?
                                              +1

                                              Ну я не DBA, а разработчик, но если вкратце — хана, это im-memory БД с поколоночным хранением данных (т.е. данные мапятся по ключам и хранятся столбцами, а не кортежами). Кроме того, хана включает в себя множество всяких интересных фич, вроде fuzzy search, каких-то ML штук и вообще очень много всякого полезного, которое, впрочем, мало используется.


                                              Что же касается приложения непосредственно к SAP ERP и подобным системам, то там поверх ханы построена целая надстройка для моделирования данных, используя view, которая называется CDS View. В ней очень много аннотаций и вообще довольно интересная и функциональная штуковина, и на ней построены новые (свежие) продукты от SAP (те, что на ABAP).


                                              Но жрет хана как не в себя, и я сомневаюсь, что ее кто-то вообще покупает отдельно для своих нужд.

                                                0

                                                покупают, еще как… Только не прям отдельно — т.е. если отдельно нужно инмемори — есть тарантул, aerospike, cassandra (отчасти), ignite и прочая веселуха из мира бигдаты

                                                  0

                                                  Да? А можно подробнее — кто и для чего? Мне прям интересно узнать, какие такие кейсы у людей.

                                                    +1
                                                    Туда же Apache Impala: in-memory MPP, с фильтрацией запросов и быстрыми селектами.
                                                    На сколько знаю, один крупный банк реализует доступ к архивным данным через Impala для пользователей (а-ля детализация по счёту за 5-10 лет).
                                                    Горячие лежат в exadata и выдаются ещё быстрее.
                                                    PS кстати, в exadata тоже можно сделать in-memory table/view и колоночное хранение давно реализовано — всё ради скорости.
                                          +3

                                          Статье ОЧЕНЬ не хватает примера какой нибудь таблички. С названиями полей и данными. :)


                                          Это как сыр. Есть такие сыры — в упаковке прикольно выглядят, но когда откроешь — запах "специфический". https://lenta.ru/news/2010/01/26/kaese/amp/
                                          Причем сыр этот не испортился!


                                          Правда, не уверен, что аналогия полная. Сыр то может и не испортился… А вот за миллионы долларов делать самим себе инъекцию очень "ароматного" легаси…
                                          Разумеется, это дело вкуса, но у того же Оракла ERP не такое "пахучее". :)))

                                            0
                                            получается SAP такая прибыльная и популярная, птотому что начали раньше?
                                              0

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

                                              0

                                              Интересно, 1С:ERP она действительно ЕРП или нет?

                                                +1

                                                Ну нет.

                                                  0
                                                  Если совсем коротко, то да. Что нельзя было сказать про УПП.
                                                  0
                                                  SAP может и очень мощный инструмент, но пользовательский интерфейс убивает всё!
                                                  Почта, это что-то.
                                                  Иконки… надо просто выучить эти пиктограммки, они зачастую не соответствуют общепринятым ассоциациям.
                                                  Все модули написаны разными людьми со своим видением мира. Вам надо просто пройти дрессировку для выполнения определённых функций.
                                                  Постоянно происходит обслуживание. 3-4 раза в неделю.
                                                  Смотришь на тот же МС динамикс и плакать хочеться, почему же в сапе не так…
                                                  Роснефть.
                                                    +1

                                                    По поводу интерфейса.
                                                    Всё это не юзабильное UI максимально приближено к стандартным формам документов. То есть экран введения поступления материала похож на форму товарной-накладной и задача кладовщика — верно с бумажки перенести данные в систему. Но технологии на месте не стоят…
                                                    Современный SAP выглядит уже не так, как на картинках в статье. В середине прошлого десятилетия SAP начал полностью перерабатывать UI и выкатил Fiori. Это позволило интерфейсу перетечь с SAP Logon на обычный браузер (хотя и раньше была возможность использовать WebGUI).
                                                    Сейчас же у компаний есть возможность полностью самостоятельно погрузиться в мир UX/UI и делать интерфейс под себя с минимальными затратами, так как это уже обычный веб и таких специалистов на рынке, как голубей в городских парках. Нужна синяя прозрачная кнопочка в виде котика — нанимай фронтэндера и пусть рисует.
                                                    Но если говорить про российские реалии, то тут всё очень сложно. Поменять цвет кнопки и надпись на ней — дело пяти минут и месяца согласований начиная от бухгалтера тёти Тани, заканчивая безопасниками.

                                                    +6

                                                    Бытует обывательское мнение, что SAP это месть немцев за поражения в мировых войнах.

                                                      0
                                                      В 2002 году стоимость продукта составляла $1M. И $10M внедрение и сопровождение в течение года. Как и Navis SPARCS.
                                                      Динамика изменения рыночной капитализации некоторых компаний иногда удивляет. Как, к примеру, компания со столетней историей и наибольшим патентным портфелем, мать всея машинерия, оказывается аутсайдером рыночной гонки, уступая тридцатилетним выскочкам?
                                                        +2
                                                        Я бы просто написал, что САП это худшая из когда либо мной виденных программ для конечного пользователя. Как там поживают разработчики\внедрители — не могу сказать.
                                                        Конечным пользователям дают какой-то недоделанный бэкенд от инженерного интерфейса.
                                                        Чем там так особен сап внутри — было бы интересно знать. Там что, не просто реляционная база данных?
                                                          +2
                                                          Разработчики поживают очень даже неплохо: язык АБАП и практики его использования крайне недалеко ушли от школьного курса процедурного программирования на Паскале. Порог вхождения очень низкий. При этом основная загвоздка в написании действительно сложных программ — это понимание не сложных концептов программирования как таковых, а внутренней архитектуры САПа (служебные переменные итд итп), которое приходит исключительно с годами.

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

                                                          Что еще характерно: фриланс в САП-е не очень распространен. «Выучил АБАП и теперь стригу купоны» — это сложнодостижимый сценарий. Как правило, крупный заказчик не горит запускать в свою инфраструктуру малознакомых контракторов, а заключает подряд с какой-нибудь крупной IT-фирмой (точнее «фермой»), которая за две недели обучает «пушечное мясо» АБАП-у и отправляет кодить для заказчика.
                                                            0

                                                            Все, не так плохо. GUI, о котором Вы пишите, давно активно заменяется на нормальный JS фронт — Fiori sapui5

                                                              0
                                                              Видимо, он ещё не доехал до нас)
                                                            0
                                                            Непонятно, почему в разделе UI описан редактор печатных форм, да еще устаревший, который появился в 1998 году? Для разработки форм в SAP уже более 10 лет используется новая технология, возможность использовать старые оставлена в целях совместимости. Статья выглядит так, будто автор что то где то слышал краем уха и решил этим поделиться.
                                                              +1

                                                              Если интересно узнать про современный SAP почитайте про S/4 и Industry 4.0.

                                                                +1

                                                                Работаю с SAP последние 10 лет, большой и сложный монолит. Вся его ценность завязана на бухгалтерском фунционале. Интеграция rfc и idoc просто ужасна, немного спасает pi/xi в котором можно выставить ws/rest интерфейсы, пользователи ценят bw как место в котором можно получить рапорты и данные которые из сап нужно вытягивать многими транзакциями и клеить в экселе. Тяжесть сама по-моему следует из оберегаемого и нежно любимого производителем эффекта легаси, монолитичного подхода к базе и корпо подхода sod раздувающего штат на сотни человек в 5 отделах, где нормально справился бы отдел из 10 человек с нормальным софтом. Капитализация и рыночный успех это только следствие правила 95%.

                                                                  +1

                                                                  Ну, все правильно — любая технология должна быть достаточно сложной, чтоб откровенные идиоты в нее не залезали. ))
                                                                  А ещё сап откровенно дорогой. Те задачи, которые им решают, можно решить за сумму в 10 раз меньшую. Неповоротливый? Да, наверное, есть такое, но надо представлять каким реально объемом данных оно ворочает.
                                                                  Что ещё сказать. Насчёт бизнес процессов все верно написано. Это не ты точишь сап под себя, а свои процессы точишь под сап. В принципе, с 1с та же история. Я помню пример, когда фирма Юлмарт переходила на сап — это было началом конца. С тех пор я шучу, что есть два типа компаний — те, которые не выжили после внедрения сап, и те, которые ещё не внедряли сап ))


                                                                  Естественно, это все является точкой зрения дилетанта и взглядом со стороны

                                                                    +1

                                                                    А насчёт HANA. Если вы ее к себе внедрили, то Вам ханА


                                                                    Пример
                                                                    https://x5.ru/ru/Pages/Media/News/310815.aspx
                                                                    И чем это кончилось https://m.habr.com/ru/company/X5RetailGroup/blog/432412/

                                                                        –1

                                                                        Безотносительно качества SAP, в приведённой вами статье автор в основном брызжет слюной, а не аргументирует почему SAP плохой. Получается такая себе анти-антиреклама.

                                                                          +1
                                                                          Это автор системы dia$par, так что его ироничный взгляд оправдан. Антиреклама — да (этому гамну ещё не хватало рекламу создавать!). И пишет он не только про ERP, но и вообще комментирует различные бизнес-кейсы.
                                                                      +1
                                                                      Неповоротливый? Да, наверное, есть такое, но надо представлять каким реально объемом данных оно ворочает.

                                                                      Вот именно.
                                                                      Жалкие сотни тысяч — миллионы строк SAP часто считает ЧАСАМИ.
                                                                        0

                                                                        Ну, если там распределенные транзакции
                                                                        абстракция над абстракцией и еще одной абстракцией
                                                                        если в SAP'е ABAP код интерпретируется
                                                                        — то я ничему не буду удивлен

                                                                    0

                                                                    Тем кто хочет увидеть развитие интерфейсов в SAP, рекомендую поискать по запросу "SAP Fiori"

                                                                      +3

                                                                      Всем привет из мира 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 и минусы конечно. Но об этом как-нибудь в другой раз (((:

                                                                        0
                                                                        Всегда интересно увидеть коллегу по цеху. Насчет «наконец-то Эклипс» вы конечно погорячились. Я пришел в АБАП после Си-шарпа, какое-то время потом работал с CDS в Эклипсе и, к счастью, потом опять ушел в АБАП. Тот самый «встроенный эдитор», на мой взгляд, самая приятная и легковесная среда разработки, в которой когда-либо приходилось кодить.

                                                                        Так что даже наоборот — на протяжении нескольких лет откровенно сам себе завидовал, что не приходится забивать себе голову джава-скриптами за исключением кратковременных запилов в смартформах и PI :)
                                                                          0

                                                                          Взаимно, коллега (: я вот сейчас обучение записываю на абап клауде через эклипс и не могу нарадоваться. И генерация кода адекватная, и хоткеи удобные, и навигацию огонь. До intelijIdea эклипсу конечно далеко. Но мне больше нравится, чем стандартный редактор. И все исходники сразу в виде сорцов, а не эти пресловутые таблички с методами (:

                                                                          0
                                                                          Преимущество, только если бизнес типовой. Когда у нас внедряли — конкретно надо было всё переделывать, погуляли по граблям вволю. Зарплатный модуль в итоге так и не внедрили. Но, пользователи очень полюбили SAPQuery, и без него уже не могут. Практически перестали пользоваться отчетами — многие цифры получают прямо из сапквери.
                                                                          +3
                                                                          даже Microsoft использует SAP вместо своего собственного ERP-продукта Microsoft Dynamics.

                                                                          Ссылка на блон, а не официальный ресур плюс аж за 2012 год.
                                                                          Сейчас на дворе 2020 ;)
                                                                            +1
                                                                            Сейчас Х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 нагрузка вырастает линейно — никаких блокировок там нет — просто берешь набор данных и считаешь.
                                                                              0
                                                                              Берем верхнюю границу — 13000 * 30000 = 390'000'000 SCU

                                                                              Вы правда думаете, что в КАЖДОМ магазине УНИКАЛЬНЫЙ товар? Чего-то сомневаюсь. Из того, что я вижу — любая Пятерочка обладает в любом регионе плюс-минус одинаковым ассортиментом: молоко "Простоквашино", йогурт "Actimel", бананы весовые и пр.
                                                                              Да, могут быть региональные отличия. Могут быть в магазинах товары от локального поставщика или под брендом сети (а по факту — опять же от локального поставщика). Но оценка в 390 млн SCU — это перебор.


                                                                              Но на меня производит впечатление, что в 2018 году это вызывает сложности.

                                                                              Вызывает сложности. Т.е. задача не выглядит супер-пупер-гипер-ресурсоемкой. Но все равно — это не веб-сайт на единственном сервере крутить. Плюс ERP система это же ведь не только товары. Это еще и график работы сотрудников, расчет зарплаты и прочая дичь.

                                                                                +1
                                                                                Я сознательно взял верхнюю границу. На практике там, вероятнее всего, не 390 млн SKU, а максимум миллионов 200.
                                                                                И 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
                                                                                  Ради такого дела решил написать свой первый комментарий на Хабре :)
                                                                                  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
                                                                                    +1
                                                                                    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
                                                                                      SergeyUstinov, постараюсь в ответе не растекаться мыслью по древу.

                                                                                      1. Ссылку на финансовые результаты я дал потому, что качество автоматической системы пополнения магазинов (автозаказа) — это один из нескольких критических бизнес-процессов для розничной сети, который на эти результаты влияет просто напрямую.

                                                                                      2. Про основную идею. При заранее известном графике поставок (характерно для розницы) оптимально при каждом расчете заказа на дату поставки 1 рассчитывать оптимальный размер заказа так, чтобы к поступлению товара по следующему заказу (на дату поставки 2) запас был равен необходимому (регулярная выкладка + дополнительная выкладка + страховой запас).
                                                                                      Фиксированный целевой уровень запаса при поступлении на дату поставки 1 проигрывает этой модели (это мое личное мнение, в холивар тут не хотелось бы впадать).

                                                                                      3. Что касается моего опыта и где эта модель применяется — я был архитектором на проектах создания системы пополнения в 10 федеральных розничных сетях России. Правда, существенная часть из них управляется одной материнской группой компаний и расчет пополнения выполняется в одной информационной системе.
                                                                                      Названия сетей называть не буду, но в любом сколько-нибудь крупном ТЦ в Москве вы их встретите :)
                                                                                      Отрасли разные — продукты, детские товары, одежда и обувь, потребительская электроника.
                                                                                        +1
                                                                                        Ясно.
                                                                                        Я так понимаю, вы описываете
                                                                                        Time-phased planning
                                                                                        help.sap.com/doc/saphelp_470/4.7/en-US/f4/7d255644af11d182b40000e829fbfe/frameset.htm

                                                                                        Я работал в ситуациях с центральным (распределительным) складом, с которого раз в день / раз в два дня выполнялась «подпитка» складов магазинов. И в таком случае лучше работает Reorder Point Planning
                                                                                        То есть пересчет точки дозаказа выполнялся относительно редко — раз в месяц, не чаще, а расчет пополнения — каждый день.
                                                                                        У нас не сап был, но алгоритмы расчетов плюс минус похожие.

                                                                                        3. Результатом расчета пополнения не является одна цифра на товар/магазин. Никому не интересен черный ящик, без промежуточных показателей расчета, это вам не котиков распознавать нейросеткой :)

                                                                                        Кстати, мне все равно не ясно — а какие «промежуточные» параметры вы анализировали и зачем?

                                                                                        Возвращаясь к SAP — вопрос не в качестве алгоритмов расчета пополнения запасов — они у сапа относительно стандартные и описаны в книжках и статьях о логистике и управлении запасами и, насколько знаю, реализованы корректно. Вопрос — почему появляются проблемы с этими относительно несложными расчетами на относительно небольших объемах данных?
                                                                                        Именно это и вызывает недоумение.
                                                                                          +1
                                                                                          Кстати, мне все равно не ясно — а какие «промежуточные» параметры вы анализировали и зачем?

                                                                                          Вам это непонятно ровно потому же, почему непонятно зачем я давал ссылку на финансовые показатели.

                                                                                          В крупной рознице есть постоянный цикл обратной связи по оптимизации существующих процессов.
                                                                                          Упрощенно так:
                                                                                          1. Обнаружили глобальное ухудшение оборачиваемости
                                                                                          2. Нашли, что за существенную часть негативного эффекта ответственны конкретные SKU сковородок, запас которых в торговой сети составляет 5 лет продаж
                                                                                          3. Нашли расчет автозаказа, по которому были заказаны эти сковородки, проанализировали и выяснили что за большой объем заказа отвечает в данном случае тот факт, что в рамках промо-акции ХХХ некий менеджер Иванов заложил дополнительную выкладку по 1000 сковородок в каждый магазин, а его начальник Петров это согласовал.
                                                                                          Дальше движения могут пойти по линии СБ, но нас интересует ИТ составляющая и тут в ИТ может прийти задача контролировать плановый размер доп. выкладки по некому алгоритму до согласования промо-акции, чтобы в будущем избежать таких проблем.
                                                                                          Вывод такой — если хотите увеличивать эффективность системы, нужна отслеживаемость причинно-следственных связей, в том числе какие числа подставились в формулу расчета автозаказа и откуда они взялись.

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

                                                                                          Я думаю, тут комплекс причин:
                                                                                          1. Масштаб задачи (число обсчитываемых комбинаций товар/магазин/дата).

                                                                                          2. Через несколько лет после начала работы никто не использует базовые простые алгоритмы SAP. Или существенно их дорабатывают, или пишут с нуля свою систему пополнения внутри SAP. Это факт может не очень приятный для SAP как вендора, но такова жизнь (см. выше про цикл улучшений).

                                                                                          3. Базовые алгоритмы SAP действительно не самые оптимальные из тех что можно написать относительно размена (время работы) vs (потребляемая оперативная память).
                                                                                          Местами видим селекты в циклах вместо массовой выборки данных, где-то кеширования не хватает на уровне сервера приложений, где-то наоборот кешируют, но таблицу во всю ширину (select *) вместо выборки нескольких нужных полей и т.п.

                                                                                          Практика показывает, что если с умом писать систему пополнения на встроенном в SAP языке программирования ABAP, то тот же объем данных на тех же мощностях можно обсчитывать примерно в 10 раз быстрее.
                                                                                            +1
                                                                                            Вам это непонятно ровно потому же, почему непонятно зачем я давал ссылку на финансовые показатели.

                                                                                            :)))
                                                                                            Я как то за год скорость оборота в полтора раза увеличил.

                                                                                            А то, что вы описываете — это не «промежуточные показатели расчета», а входные данные. ))

                                                                                            Я думаю, тут комплекс причин:
                                                                                            1. Масштаб задачи (число обсчитываемых комбинаций товар/магазин/дата).

                                                                                            Давайте говорить откровенно — это довольно маленькие объемы данных.

                                                                                            Практика показывает, что если с умом писать систему пополнения на встроенном в SAP языке программирования ABAP, то тот же объем данных на тех же мощностях можно обсчитывать примерно в 10 раз быстрее.

                                                                                            Предполагаете, проблема Х5 — низкая квалификация их разработчиков?
                                                                                              +1
                                                                                              SergeyUstinov, мне кажется, мы уже приблизились к максимуму взаимного понимания, который можно достичь обменом письменными комментариями без устного обсуждения.

                                                                                              Публичные споры о том «куча бананов — это сколько?» и какая квалификация у сотрудников конкретной компании (разная, конечно!) мне не очень интересны.

                                                                                              Предлагаю на этом остановиться.
                                                                                +1
                                                                                Почему 400 М цифр? Товары могут быть в разном состоянии: на складе, в пути, еще где-то. Грамотнее говорить о том, сколько обновляется записей в БД каждый день. Обновление 1ММ записей в день это очень много! Берите запросов на чтение, отчеты как 1 к 100 + добавьте еще спец требования по согласованности данных, если они не влазят в одну физическую БД или отчеты должны быть согласованными.

                                                                                Такая система, что в 2000, что в 2010, что в 2020 по-прежнему оценивается по сложности в 1-10М LOC (строчек кода).

                                                                                0
                                                                                Ну поднимем же бокалы «за САП за бап, и за АБАП»
                                                                                  0
                                                                                  Воистину)
                                                                                  +1
                                                                                  Когда-то стажировался на SAP SD и доработку на ABAP под S4/Hana. Это было одно из худших решений в моей карьере. Могу подчеркнуть основные тезисы о SAP ERP на собственном опыте:
                                                                                  1. Неоправданно дорогая система. Её внедрение и поддержка не окупается. Мы с бухгалтерами считали. Ни количество персонала, ни затраты в итоге не снижаются. Где убыл 1 рабочий завода — там прибыл 1 SAP-консультант.
                                                                                  2. Совершенно не user-friendly интерфейс. Вся система состоит из кодов и немецких шифровок. Алан Тьюринг офигел бы от попытки всё расшифровать. Про графические элементы и составляющие интерфейса я вообще молчу.
                                                                                  3. Куча устаревшего функционала, написанного индусами аутсорсерами. Многие функции и модули прямо просят обновить их.
                                                                                  4. Язык ABAP — это убийство для современного разработчика. Даже C на его фоне кажется прорывом. Куча кода пишется в открытую, когда можно было встроить скрытые реализации. Длинные конструкции, которые возвращают вас в детство и школьный Pascal. Один код включает другой код, а тот — третий и т.д. — ни о каких современных концепциях хранения кода не идёт и речи. Вишенка на торте — неадекватные типы данных и всякие «филдсимволы».
                                                                                  5. Документация и туториалы из серии BC просто бесполезны. Детские примеры и скупые описания. Как итог — опыт разработки передаётся из уст в уста.
                                                                                  Вердикт: если вы уже знаете один из популярных ЯП и не имеете склонностей к БДСМ — не суйтесь в SAP.
                                                                                    0
                                                                                    Это все абсолютная правда. И как всегда есть большое НО. На определенном уровне — обычно международном — без внедренного САП — ты никто и с тобой работать не будут (верно не для всех отраслей). И выход на IPO с САПом более легок.
                                                                                    А по удобству это как со СФИВТ — колоться, плакать но продолжать есть кактус ибо безальтернативно.
                                                                                      0
                                                                                      Согласен. Как раз работал на компанию из лёгкой промышленности. Им по сути этот SAP и нафиг не сдался, но хотели открыть завод в Испании — пришлось переходить полностью на SAP ERP.
                                                                                      Для работы на территории СНГ, это лично моё мнение, 1С с его модулями выше крыши достаточно, да и затраты на его интеграцию и поддержку в разы меньше. Ну а Европа вся подмята SAP и Siemens(

                                                                                  Only users with full accounts can post comments. Log in, please.