2.0 Business Process

Capture the business process that the application supports . This can be describe through a process diagram or a business capability modelThe order confirmation process in SAP typically involves confirming the details of a sales order, including product availability, delivery dates, and other relevant information. The process begins with the creation of a sales order in SAP. This involves entering details such as customer information, product quantities, delivery dates, and any other relevant specifications. SAP performs an ATP check to determine the availability of the products requested in the sales order. This check considers factors such as current stock levels, incoming goods, and production schedules. Based on the ATP check, SAP provides an initial confirmation to the customer. This confirmation includes details such as the confirmed delivery date and any other relevant information. If there are changes to the order, such as customer requests or adjustments to production schedules, the order confirmation may need to be revised. SAP facilitates the process of making these revisions while ensuring the impact on product availability and delivery commitments is considered. Order changes reports in BW provides reporting and analytics capabilities to track key performance indicators (KPIs) related to the order confirmation process. This allows Solvay to monitor the order fulfillment efficiency.

3.0 Application Feature Overview

Information about the existent Workbooks and the respective BW queries.

4.0 Functional Specification

4.1 General Data/Calculations 

This section will approach the concepts/definitions that will be used in all the reports and required to understand the data from the reports.

There are indicators in the report that explores the time taken to confirm an order in SAP by comparing the order line creation date and the confirmation date. The target is to be less than 48 hrs (=< 2 business days).

Furthermore, the report assesses the 'Stability' factor, determining whether the first confirmation date has been altered subsequently. If so, the report provides insights into the frequency and extent of these changes, shedding light on the order's stability over timeCould be specific fields, closing activities, additional information to work and understand the reports.

4.2 Process Detail 

Scope :  

• The scope has been aligned with the OTIF scope. See scope HERE

• Exclusion of material types services and packaging (i.e. units in KWH): PF1/Z703  WP1/ZDIE WP1/ZVER WP1/ZUNB

• Consolidation Method ≠ Sold (entities)

• Deleted order lines are excluded

• Order lines with a “Reason for rejection” have been excluded, except for the WP1 reason "98 - Incompleted delivery, tb closed-not OTIF" .

Reference Date : for the KPI % Order Promising and the Cycle Time the  reference date is Order Line Creation date . Order lines are taken into consideration as soon as they are entered in the system. (data load delay of 1 day, night batch)

Cycle Time :

• Order line creation date - > 1st ATP confirmation date (ATP stands for Available to Promise)

ATP in SAP helps businesses determine the quantity of a product that can be promised to a customer at a specific point in time. It takes into account the current stock levels, incoming goods, and existing customer orders to calculate the available quantity that can be promised for future delivery.

• In case of credit block the KPI measures: Cycle Time between FIRST credit release > 1st ATP confirmation date

  In SAP a "Credit Block" on a sales order refers to a restriction or hold that is placed on the order due to credit-related concerns. This mechanism is part of SAP's credit management functionality, which helps organizations control and monitor credit limits for their customers. When a sales order is subject to a Credit Block, it means that the system has identified a potential credit risk associated with the customer placing the order. This risk could be due to factors such as the customer exceeding their credit limit or having overdue payments. 

   

• If the order hasn’t been confirmed yet we calculate the cycle time with Today’s date

• Measured in business days (of server location: Belgian holidays excluded) 

Scenarios/ Rules  

Image Added

1st ATP confirmation date :

• First Confirmed quantity date from Change Log in PF1

• If there is no quantity change in the change log and the order line has been delivered, BW takes the order line creation date assuming that the order was confirmed immediately
• in case the order line was created, deleted, recreated, we consider the last order line creation date
• If a schedule line comes from a value to zero, we assume the order line was confirmed immediately (1st conf. date = order line creation date)
• If a 1st confirmation date is inferior to the order line creation date then we read the change log and take the next quantity confirmed date as the 1st confirmation date.
• For WP1 BW uses a dedicated field ZZERDAT "1st committed delivery date" (Order line - Additional Data B)

4.2.1.  Report/Process Definition 

Promising Split : Each order line is categorized in 5 possible Confirmation Status

Details of Confirmation Status:

• GOOD : confirmed  =< 2 business days
• FAILED 3-9 business days
• FAILED 10-30 business days
• FAILED > 30 business days
• FAILED with ALLOCATION : 
• For WP1: if order line has failed to be confirmed within 2 business days and has ever had ZPEN flag on order line level
• For PF1: there is no common process, therefore this category is not defined for PF1 GBUs

KPI Order Promising percentage :   # of GOOD confirmed < 2 business days /  # total orders lines

Confirmed in 2 business days : KPI is based on 1st ATP confirmation (whether the order line has been updated or not)

# of Confirmations :  

• Count the # of distinct dates* the order line has been confirmed in the change log (after confirmed quantity or schedule line date change) 

*even if the change log shows several changes per day, we can count only 1 confirmation per day

• A change that goes from value to zero is considered as an instability, not a cancellation (+1)
• If there is no change in the confirmed quantity or schedule line date in the change log and the order line has been delivered, BW counts as 1 confirmation and assuming that the order line was confirmed immediately. (WP1) BW uses order line creation date in cycle time.

Stability (Stable confirmation) : 

Calculation: Based on KPI “# of Confirmations”, Stable Y = 1 confirmation and Stable N > 1 confirmation

If the order has no GI date, it is considered as not possible to calculate the KPI. 

5.0 Non-functional Descriptions 

5.1 Usability

5.2 Regulatory Compliance

5.3 Security

5.5 Reliability

5.6 Scalability

5.7 Compatibility

5.8 Availability

5.9 Refresh of the Data

4.2.1.  Report/Process Definition 

<insert link>

This section represents the process with detail information for the application. Can include specific or special cases, complex logics , calculations, flows, among others.

5.0 Non-functional Descriptions 

5.1 Usability

Usability is about the ease with which a User can learn to start using the solution and the ease with which they can use the system.  In addition to ease of learning and ease of use, usability also includes areas such as ease of recall, error avoidance and handling, accessibility among others e.g., 99% of metadata entry Users who have use the Maintenance Dashboard should be able to change filters, extract etc., when required.  Maintenance data will be centrally stored in the Google Cloud platform, which will be available to other applications e.g., and Dashboards if needed.

5.2 Regulatory Compliance

Software systems must comply with legal and regulatory e.g., GDPR requirements, this can change depending on country, organisation industry and / or region.  The software systems must be secure from unauthorized access.  The Maintenance Dashboard will comply with Solvay’s regulations and compliance e.g., access only granted to authorized Users.

5.3 Security

Security refers to essential aspects that assure a solution and its components will be protected against unauthorized access or malware attacks.  Important considerations related to security aspects of a system are User authentication, User authorization or User access privileges, data theft, malware attacks, data encryption, and maintaining audit trails, e.g., only Users with administrator access shall be able to create new accounts and assign data access privileges to the new accounts e.g.,

• All data will be encrypted in the dashboard
• Only authorised Users / Administrative Users will be able to access data.
• Maintenance data will be split between either SCO or ECO, and Users will only have authority to one Entity data.

5.4 Performance

Performance defines how fast a software system or a particular section of it responds to certain User actions under a certain workload.  In most cases, this metric explains how long a User must wait before the target operation happens e.g., the page renders, a transaction is processed, etc., given the overall number of Users now.  Performance requirements may describe background processes invisible to Users, e.g., backup and speed of data transfers. 

5.5 Reliability

Reliability is the ability of a solution or its component to perform its required functions without failure under predefined conditions for a specified time / period.  Reliability can possibly be specified in terms of average time system runs before failure occurs, percentage of operations completed successfully within a time / period, maximum acceptable failure probability, or number of failures within a period.  Reliability aspects are in reference to (but not limited to) evaluation of the system to be considered as reliable, classification of reliability defining failures vs. regular failures, and the impact of failure on business operations.  The Maintenance Dashboard will display data from the previous refresh of data.   

5.6 Scalability

Scalability refers to the degree to which a solution can evolve to handle increased amounts of work.  The increased amount of work could be in terms of the user base, transactions, data, network traffic, or other factors e.g., the system should be able to handle an additional load of a maximum of 5,000 Users every month for the next 6 months without any noticeable performance impacts.  

5.7 Compatibility

Interoperability is the degree to which the solution is compatible with other components.  It is a measure of how effectively the system interoperates with other software systems and how easily it integrates with external hardware devices.

Interoperability aspects to be discussed during elicitation are in reference to (but not limited to) software systems to be interfaced with along with data / messages to be exchanged and any standard data formats, hardware components to be integrated with, and any standard communication protocols to be followed e.g., Order Management system will push the order file into a secured file transfer protocol server from where it will be loaded into the system through a daily job.  To guarantee between Google Cloud platform and SAP BW Queries e.g., BW_QRY_MVPMOR01_0002, Solvay has introduced a new tool called Xtract (Xtract).

5.8 Availability

Availability is the degree to which the solution is operable and accessible when required. It is a measure of time during which the system is fully operational e.g., available for use and sometimes included as a Service Level Agreement (SLA) considering its criticality to the business, e.g., the system shall be at least 99% available on weekdays between 09:00 to 18:30 Central European Time (CET).

5.9 Refresh of the Data