EDUCAÇÃO E TECNOLOGIA

Intelligent Alerting: SAP IBP Order Based Planning OBP Enhancement

Hello all, this blog is focused on order based collaboration in SAP IBP combined with intelligent business rules to define the collaboration scope. This is an enhancement delivered by GitaCloud team to augment SAP IBP Order Based Planning OBP standard capabilities. Read content below to understand the business requirement, SAP IBP functionality gap, solution approach, and business value, when it comes to business threshold based intelligent alerts leveraging pegging data generated by SAP IBP Order Based Planning.

Introduction:

  • This enhancement is built on top of the standard SAP IBP Response and Supply application, leveraging Pegging API, and custom Fiori Apps in SAP S/4HANA.
  • As you may know, SAP IBP Response and Supply Application supports an Order Based Data Model tightly integrated with SAP S/4HANA. This enables Order Based Planning OBP capability in SAP IBP, which generates pegging relationships between demand and supply order elements.
  • Planners need to understand which firm supply elements (Production Orders, Purchase Orders, etc.) need to be expedited / delayed / cancelled based on latest firm demands (Sales Orders, Outbound Deliveries, etc.).
  • With this Intelligent Alerting enhancement developed by GitaCloud team, planners can get the order based planning paradigm extended to order and pegging based alerts as well.
  • See overall IBP Solution Architecture view below, before we dee-dive into the Intelligent Alerting solution.

Business Requirement:

  • Procurement Teams (Buyers) need to work with Suppliers to pull-in / push-out or cancel open firm supply (Purchase Orders) in response to volatile demands (Sales Orders, Forecasts). We refer to this as Order Based Supplier Collaboration. This is similar to MRP Exception Message Processing processes in SAP S/4HANA or SAP ECC centric MRP world.
  • Production Planners need to work with Shop Floor to pull-in / push-out Production Orders in response to demands.   We refer to this as Shop Floor Collaboration.
  • Firm Supply Orders (Purchase Orders, Production Orders) have an original Goods Receipt GR date in S/4HANA. It is important for Planners to understand the New Need Date or New Goods Receipt GR Date in-sync with latest demands.
  • Planners need pegging based alerts, e.g., only raise an expedite request (pull-in) for a Purchase Order within the next two weeks, if the pegged demand is a sales order and not a forecast. This makes sense, as asking the supplier to change shipment mode from ground to air to support a shortage related to forecast is not a good way to spend the freight budget.
  • It is not enough to simply raise pegging based alerts for all firm supplies that need to be rescheduled (pull-in or push-out). This could overwhelm Planners with too many alerts and does not take the actionability quotient of the alert into account. For example, if the Original GR Date is within the Transportation Lead Time from Current Date, then it is likely the Supplier has already shipped materials against the Purchase Order. In this case, sending a de-expedite (push-out) request to the Supplier is a waste of time. Similarly, if the Original Goods Receipt Date is way out in the future (e.g., 90 days or more), and if the expedite request (pull-in) is by only 2 days, then it is trivial and likely to change again, hence best ignored for now.
  • Planners need to apply additional thresholds to order based planning / pegging based alerts, in terms of the size of the commercial impact. This commercial impact can be defined by multiplying the Purchase Order Line Item Quantity with Purchase Price on the PO with total number of days the PO line item is being expedited or delayed. For example, Planners may not care about delaying an incoming Purchase Order if the Dollar Days Threshold is less than $5,000. This means the PO line item is relatively insignificant in value to include in the Supplier Collaboration and Firm Order Rescheduling process scope.
  • Planners need to be able to define these time fences, limits, and thresholds as global defaults, or more specifically by Planner Code, by Supplier Code, and so on.

SAP IBP Capability Gap:

  • SAP IBP supports a basic capability to define Custom Alerts based on Key Figure values.
  • SAP has recently also introduced Intelligent Visibility App, which enables planners to see sales order confirmation related alerts in a drill-down manner. See this link to SAP IBP Help for details.
  • However, pegging based alerts are not supported. For example, you cannot raise an alert or a rescheduling action message only if the pegged demand happens to be a sales order, not a forecast.
  • Business threshold and commercial impact based restrictions on pegging based alerts is not supported. Buyers do not have a way to ignore minor exceptions, or segment action messages in critical-high-medium-low priority tiers.

GitaCloud Solution Enhancement: Intelligent Alerting

  • See below the weekly alerting / collaboration process flow.

  • We created a custom Fiori App for Planners to define business threshold conditions. See snapshot below.

  • The first column “Line Index” represents the Business Rule Number.
  • “Action Message” Column: This is a User-Defined title of the Rule. As you can see, various values like Expedite, De-Expedite, Past Due, and Cancel have been maintained to communicate various collaboration scenarios.
  • Supply Element Type: represents the Firm Supply Element that the Intelligent Alert is for. In this snapshot, you can see all the Intelligent Alerting Rules for Purchase Orders (MRP Element: BE).
  • MRP Controller: We have defaulted the value * here, which communicates the default rule applicable across all Buyers. This Fiori application allows definition of the alert rules for a given MRP Controller. For example, if MRP Controller # 11 has different thresholds than the default, then we can define alert rules accordingly with MRP Controller column being value 11.
  • Vendor (Supplier): We have defaulted the value * here, which communicates the default rule applicable across all Vendors (Suppliers). However, we could define a separate set of thresholds for a given Vendor or even a MRP Controller – Vendor combination.
  • Fence:
    • See Rule # 1 (5th row from top in the snapshot above). Fence value is maintained as 4 days. This communicates that any Purchase Order Line Items due to be received within the next 4 days will automatically be excluded from the alerting scope, if the PO line item needs to be expedited (pulled-in). Notice the last column “Need Date Scope”: New Need Date is earlier than the Current GR Date on the PO line item. This makes sense to not ask the vendor to expedite such a PO line item, given the vendor might already have shipped such a line item, or may not be able to change their production schedule last minute.
    • See Rule # 2 (3rd row from top in the snapshot above). Fence value is maintained as 7 days. This communicates that any Purchase Order Line Items due to be received within the next 7 days will automatically be excluded from the alerting scope, if the PO line item needs to be de-expedited (pushed-out). Notice the last column “Need Date Scope”: New Need Date is later than the Current GR Date on the PO line item. This makes sense to not ask the vendor to de-expedite such a PO line item, given the vendor might already have shipped such a line item, or may not be able to change their production schedule last minute, or may not be able to hold the inventory for us in case of storage space challenges.
    • See rule # 8, 10, 12 in the snapshot above. Given the Fence parameter is a negative 90 days, we attach the Action Message as ‘Past Due’ to the PO line item, whether the PO new need date happens to be earlier than (rule #12), later than (rule #10), or the same date (rule # 8, which states the new need date is blank). This enables planners to look for all PO line items with current GR date on the PO line item in the last 90 days and check with the Supplier for the past-due line item. Items longer than 90 days in the past are assumed to be inactive PO line items (waiting for cancellation), and are not included in the supplier collaboration scope.
  • Limit, Low Filter, High Filter: These three parameters operate together to define the business thresholds flexibly. Limit parameter enables Planners to specify a time limit from today’s date and have different thresholds apply to the left or to the right of this time limit. Low Filter parameter applies to the left of the time limit, while High Filter parameter applies to the right of the time limit.
    • See Rule # 1 (5th row from top in the snapshot above). Low Filter is 3 days. This means any PO line items which need to be expedited 3 days or less are excluded from the Supplier Collaboration scope, if the PO line item due date is within the next 90 days. High Filter is 14 days. This means any PO line items which need to be expedited 14 days or less are excluded from the Supplier Collaboration scope, if the PO line item due date is after the next 90 days. The intent here is to make sure that we do not ask the supplier for low impact items in the short term (expedite needed for 3 days or less for PO line item due within 90 days). We also we do not want to ask the supplier for medium impact items in the mid-term (expedite needed for 14 days or less for PO line item due after 90 days).
    • See Rule # 2 (3rd row from top in the snapshot above). Limit is 60 days here. Low Filter is 7 days and High Filter is 45 days. This time we are focused on de-expedites. The ruleset translates to only raising de-expedite alerts if the de-expedite is 7 days or more for PO line items due to be received in the next 60 days. This rule changes to 45 days or more of de-expedite needed for PO line items due to be received after the next 60 days.
  • Dollar Days Threshold: Planners also have the option to also specify this Dollar Days Threshold Parameter in Rules. This is a $$ value and operates as an additional filter to remove PO line items with insignificant $$ value. For example, note the parameter value of $5000 for Rule #2. This means any PO line item for which PO line Item Value * number of days de-expedited do not exceed $5000 should be removed from the Supplier Collaboration scope (alert should not be raised), even if it meets other threshold parameters, such as Limit, Low Filter, High Filter, etc.
  • We extract IBP Order based Planning OBP generated pegging structure and apply the Business Rules listed above to raise Intelligent Alerts: enable to planners to focus on actionable and important problems, not flood their inbox with hundreds of trivial or unactionable alerts. Planners can pull up the Orders to be rescheduled based on various selection criteria. See snapshot below.

  • See snapshot below to see PO line item level alerts raised.

  • Supplier specific excel spreadsheets can be generated from these Intelligent Alerts. These spreadsheets are MRP Controller – Supplier combination specific and enable Suppliers to understand which PO line items need to be expedited, de-expedited, or even cancelled (in case there are no pegged demands for a PO line item). Suppliers can confirm the request by populating the Confirmed Date column same as New Need Date or provide their best-effort date. These spreadsheets can then processed through an inbound interface to automatically populate the new date from the Supplier on the PO line item in S/4HANA to complete the Supplier Collaboration cycle. Buyer or Supplier can also provide comments along with the Date Request / Confirmation. These comments are stored in the S/4HANA PO Line Item to have a full record of the Supplier Collaboration cycle.

Business Value:

  • This enables an order based collaboration cycle with Suppliers and intelligent identification of the critical items needing collaboration through flexibly defined business rules.
  • The solution supports spreadsheets based collaboration, which can be automated in terms of both supplier publish and inbound processing with a full automated update loop in S/4 PO line items.
  • The solution works equally well for Shop Floor Collaboration to identify which Production Orders need to be expedited / de-expedited in sync with fluidly moving sales order backlog.

Conclusion:

  • Hope this gives you a good sense of the solution enhancement and value. It addresses a key usability gap from Response Planning Business Process perspective by giving Planners a fully automated and granular solution in terms of order pegging based alerting and supplier collaboration process.
  • Please provide your thoughts and feedback in the comment section. Do like and share this blog if you liked the content. Also, feel free to submit any questions related to IBP in the respective Q&A area in SAP Community.
  • Feel free to reach out directly to me at ashutosh@gitacloud.com, if you have similar unmet business process requirements with your current SAP IBP Order Based Planning implementation or if you have any questions regarding the technical mechanics of this enhancement.
  • You can also review my other blog posts regarding similar IBP OBP enhancements. See Firm Order Rescheduling Enhancement or Demand Management Enhancement.
  • As always, good luck with your endeavors in delivering exceptional customer success and value through your SAP powered supply chain transformation engagements.