Удобная функция. В российских реалиях может быть применена для копирования номера ГТД партии импортного сырья в признак партии готовой продукции, что часто требуется заказчиком.
Проблема того, что APO до версии 4.1 не видел заказов ТОРО, действительно могла быть актуальной. И описанная функциональность, действительно, будет востребована бизнесом.
Хотелось бы сделать несколько отступлений по возможностям интеграции без APO и потенциальные ситуации, которые предложенная интеграция не решает.
Стандартаня интеграция модулей PP и PM при ведении основных данных так, как это описано в статье, позволяет при балансировке производственных мощностей в CM25 видеть данные о ремонтах согласно РМ-заказам. Поэтому реализация данной функции в АРО является, по сути, дублированием имеющейся в ERP. Хотя, безусловно, данное дублирование требуется, т.к. планирование должно проводиться в одной системе, и APO PP/DS более предпочтительно.
Аналогичная ситуация и с планированием материалов для заказов ТОРО. Стандартный MRP ERP системы видел потребность как ТОРО заказов, так и производственных. Опять-таки, данное дублирование требуется, т.к. планирование должно проводиться в одной системе.
Чего нет в данной интеграции, и что это не позволит сделать: интеграция основана на заказе ТОРО - это означает, что план ТОРО никак не интегрирован в систему планирования АРО.
Де факто, в жизни ремонты не проводятся согласно некому четкому графику, а разрешены различные отклонения, чтобы оптимально подстроить сроки ремонта под производственную программу. И потенциально, от АРО (например оптимизатора) можно было бы ожидать предложения о наиболее эффективном времени проведения ремонта с учетом производственного фактора. К сожалению, этого нет.
Проблема выбора оптимального времени может быть усложнена тем, что потенциально, для более быстрого проведения ремонта, ремонтные службы могут увеличивать свою производительность или за счет сверхурочной работы, или привлечения подрядчика. Понятно, что это потребует дополнительных затрат (с точки зрения АРО - у ресурса создается дополнительные Capacity Variant). И в производстве оптимизатор APO умеет выбирать оптимальный вариант использования мощности. На сколько я понимаю, для ТОРО заказов эта задача пока не решается.
Кроме того, до тех пор, пока по плану ТОРО не будет сделан отзыв, и не будет создан заказ ни ERP ни APO не видят потребности в материалах. С одной стороны это логично. Но с другой стороны, как только заказ создан, ERP перестает перепланировать сроки проведения ремонта на соответствующие новым реалиям (например, если ремонтная стратегия по наработке часов). И АРО не помогает решить этой задачи.
Многое конечно написано по делу. Не понтяно - для кого эта статья. Сложилось впечатление, что тот, кто не понимает/не сталкивался/не знает того, о чем написно в статье реально ничего дополнительного для себя не подчерпнет. Где-то будет просто не понтяно о чем речь, где-то даже не будет видна проблема, которую пытается объяснить автор. В статье не хватает реальных примеров, реальных аппеляций к опыту автора и не растывлены \"акценты\" на важность тех или иных аспектов.
Статья похожа на руководство к действию, много исходного кода, примеры расчетов в модуле Integrated Planning Интегрированного планирования, является демонстрационным примером возможностей системы. Но чувствуется обрезанность статьи, незаконченность. В исходном коде отсутствуют комментарии, усложняет восприятие текста.
Качественно, поскольку от разработчика. Объясняются основы построения, но слишком сложно для понимания людей, не имеющих представления о сабже. Бесполезно, поскольку непонятно как применять в целом.
К счастью, как раз в этой области есть опыт, могу поделиться. Несмотря на сложность настройки, эта штука работает и работает устойчиво. Более того, результаты планирования в некотором смысле оптимальны, поскольку более гибки, чем любая эвристика и объяснимы в отличие от оптимайзера. Поскольку мастер-данные планирования изменяются мало, то грубые отклонения от оптимального решения отлавливаюся и правятся с помощью настройки выбора источника. Для реализации сложных задач возможно сценарное планирование поочередно с различными профилями. Полученные данные реально можно использовать как среднесрочный производственный план.
Недостатки: непростой инструмент, требующий высокой квалификации при настройке.
В принципе действенные способы, но BAdI в новых системах вызываются не только с помощью CL_EXITHANDLER, но и с помощью специального оператора CALL BADI.
По моему мнению легче искать отладчиком. Ставим точку остановки CL_EXITHANDLER=>GET_INSTANCE, так как для старых BAdI вызывается данный метод и также в отладчике ставим точку остановки по оператору CALL BADI.
Очень детальная статья, которая в четко, доступно для понимания, очень детально описывает все шаги процесса разработки веб приложений в среде SAP. Статья очень полезна для создания начального представления о программирование веб интерфейсов для программистов.
Обязательня для прочтения всем кто хочет разрабатывать веб приложения для систем SAP, и в частности для разработчиков в системе Solution Manager, потому что именно в ней очень часто используется веб функциональность.
Полезная статья как для разработчика так и для консультанта, который пишет функциональные спецификации. Раскрывает возможности расширений в системе SAP. На мой взгляд, написана статья не очень понятным языком. Скобки, которые добавляет автор для «(простых) точек расширения» очень визуально дробят текст и делают его очень трудночитаемым. Не понятно как нужно читать предложение со словом в скобках или без слов в скобках. Вторая часть стать, где приводится конкретный пример расширения, конечно же более полезна для разработчиков, чем для консультантов. Считаю статью необходимой для прочтения консультанту, который пишет технические спецификации на модификации системы, чтобы знать все возможности в этом направлении.
Теоретическая статья на тему управления запросами на изменение. Автор в статье, к сожалению, ни как не ссылается на процессы управления изменениями, реализованные в стандартном решении управления изменениями системы Solution Manager. Хотя из того, что написано в статье видно, что процессы управления изменениями, как их видит автор, очень сильно пересекаются с процессами управления изменениями в системе Solution Manager. Последняя часть, в которой описана реализация управления запросами на изменение по средствам собственной базы данных, кажется очень оторванной от реальных продуктивных систем для которых такое решение будет неприемлимо, как с точки зрения ИТ поддержки так и с точки зрения бизнес пользователей.
Ещё одна заноза тем, кто считает инструменты типа Query исключительно консультантскими \"наборами для сверок\".
Не слишком хорошо знаком с процессом, который выполняется, но легкость выполнения (а query это действительно легко и интуитивно понятно) сложной задачи без АБАПа это всегда здорово
Главное преимущество данного подхода - идея документировать всё, но оценивать позже. Действительно, зачастую получается подводить фразы опрашиваемого под известные лекала (настроенный функционал системы, например)
Удивил пункт 5. Взаимное представление (как то больше пресейлу такая информация нужна а не консалтингу) и конечно всяческие оценки наподобие конфидециальности и детализации (не зря пункты выделены как необязательные).
Статья, меня как студента, вывела на новый уровень понимания практического старта проектов. Собрала воедино понятия риска при внедрении и распределение ответственности. очень хорошая компиляция теории и практики.
Комментарий от
Левон Киракосян
| 16 июля 2010, 12:14