Issue

The purpose of this document is to describe the Delegation of Authority (DOA) feature as it exists across the following platforms: SAP SuccessFactors, SAP Ariba, Salesforce, and Icertis. It outlines how each system implements DOA, including its core functionality, configuration options, limitations, and use cases.

Recommendation

Recommended approach is option A, i.e., DOA matrix and Framework in S/4HANA.  

The key drivers to centralize the Delegation of Authority (DOA) in S/4HANA are:

1. Reduced Post-Go-Live Maintenance: Maintaining the DOA matrix and framework directly in each system can lead to high ongoing maintenance efforts after deployment. Centralizing in S/4HANA minimizes this duplication and effort.

2. Availability of Employee Data: Employee information will be maintained in S4 as Mini Master, facilitating a single source of truth. The organization hierarchy within S4 will be used to identify workflow approvers based on document amounts.

3. Development Effort in Other Systems: Developing the DOA framework within iCertis and Salesforce involves significant development effort and complexity. Centralizing in S/4HANA reduces the need for extensive customizations across multiple platforms.

4. Workflow Development in S/4HANA: The majority of workflows required for the project will be developed within S/4HANA, supporting a unified and efficient approval process.

Overall, centralizing DOA in S/4HANA offers benefits in maintenance efficiency, data consistency, and workflow simplicity. 
Copy
Good response
Bad response

Background & Context

Financial delegation of authority (DOA) is the process of assigning specific financial decision-making powers to individuals or groups within an organization. It defines who can approve transactions like expenditures, contracts, and budget allocations, along with their approval limits. DOA helps manage financial risks by controlling the size of commitments lower-level management can make on behalf of the organization.

The following transaction type will be subject to DOA approval.

Assumptions

The DOA matrix will be governed by the executive leadership team and the approved group controller or designate.

Employee Organization data will be used to determine DOA Approval. 

Constraints

 DOA substitutions to cover for approvers on leave is not part of the technical approach.

Impacts

1. As part of the Cutover activities, the Delegation of Authority (DOA) Matrix will need to be maintained and available for reference.
2. The SyWay program will finalize the DOA for each process area during the Detailed Design phase. This will ensure alignment across stakeholders and readiness for testing.
3. Interfaces may have to be developed in order to replicate the DOA matrix data into other applications that also implement approval workflows with DOA logic. 

Business Rules

Approval Process Principles

1. Approval Basis

   • Approval decisions are determined by the Master data object, like cost centre, WBS, and Business Partner, in the document requiring approval.

2. Final Approver

   • Each approval workflow task is routed directly to the Final approver identified in the Delegation of Authority (DOA) matrix.

   • The Final approver must be authorized to approve the entire transactional value within the relevant organizational boundary.

3. Single-Step Approval

   • The process will follow a single-step approval approach.

   • No multi-step approvals will be implemented to minimize potential delays.

4. Vacant Position Escalation

   • If the designated approver position is vacant, the system will automatically escalate the task to the next higher filled position in the organizational hierarchy.

5. Eligible Approvers

   • The approver may be:

     • A permanent Syensqo employee, or

     • A contingent worker, provided they are officially appointed to the relevant position in SAP SuccessFactors.

6. Task Centre

   • BTP Task Centre will be the central Inbox for all approvals from S/4HANA, Ariba, iCertis and Salesforce.

Options considered

List the options (viable options or alternatives) you considered. These often require a longer explanation with diagrams, or references to other documents (links are best, but attachments are also possible). Use enough detail to adequately explain what you considered so that a project or business stakeholder reviewing this decision will not come back and ask "did you think about...?"; this leads to loss of credibility and questioning of other decisions. This section also helps ensure that you considered enough suitable alternatives rather than just copy/pasting SAP's recommendations.

Option A: DOA matrix and Framework in S/4HANA

As part of the overall solution, a custom table will be developed in S/4HANA to store the Delegation of Authority (DOA) Matrix.

Key components of the solution include:

• A custom framework will be built to:

  • Read data from the DOA table and Employee mini master data.

  • Determine the final DOA approval based on above inputs.

  • Handle exceptions in a controlled and consistent manner to ensure the solution remains homogeneous across all process areas.

• Base approval will be determined by individual workflow logic, leveraging master data objects such as:

  • Cost Center

  • WBS (Work Breakdown Structure)

  • Other relevant organisational data

  • Custom Table 

• The final approval will be derived by applying the DOA framework on top of the base approval logic.

• For external systems such as iCertis, Salesforce, and Ariba, the DOA approval data will be interfaced via API or file-based integration

Reference Technical Architecture would following. 

Maintenance of DOA will be centrally governed and access-controlled.

Option B: DOA matrix and Framework in BTP

As part of the this option a custom table will be developed in BTP to store the Delegation of Authority (DOA) Matrix. This will be using BTP BPA as business rule and CAP services to interface.

Key components of the solution include:

• A custom framework will be built in BTP:

  • Read data from the DOA table

  • Employee and organization data need to read from Success factors. We have API to read data but may end up calling same static data for each workflow. 

  • Determine the final DOA approval based on above inputs.

  • Handle exceptions in a controlled and consistent manner to ensure the solution remains homogeneous across all process areas.

• Base approval will be determined by individual workflow logic in S/4HANA, leveraging master data objects such as:

  • Cost Center

  • WBS (Work Breakdown Structure)

  • Other relevant organisational data

  • Custom Table 

• The final approval will be derived by calling BPA on top of the base approval logic.

• For external systems such as iCertis, Salesforce, and Ariba, the DOA approval data will be interfaced via API or file-based integration

Reference Technical Architecture would following. 

Maintenance of DOA will be centrally governed and access-controlled in BTP.

Option C: DOA matrix and Framework in respective cloud applications 

DOA Table and Framework to be maintained in each system. Employee and Organization data need to be interfaced into all the relevant cloud applications. 

Key components of the solution include:

• A custom framework will be built in respective System :

  • Read data from the DOA table. 

  • Employee and organization data need to read from Success factors. Currently as per solution approach we will not need API call from S/4HANA as data will be available as mini master. We will need either Employee replication or API based integration from Success factor to iCertis/Ariba/Salesforce. 

  • Determine the final DOA approval based on above inputs.

  • Handle exceptions in a controlled and consistent manner to ensure the solution remains homogeneous across all process areas.

• Base approval will be determined by individual workflow logic in S/4HANA, iCertis, Salesforce, and Ariba leveraging master data objects and SaaS capability, such as:

  • Cost Center

  • WBS (Work Breakdown Structure)

  • Other relevant organizational data

  • Custom Table 

• The final approval will be derived by on top of the base approval logic.

Maintenance of DOA will be governed and access-controlled in respective system.

Evaluation

Outline why you selected a position. The best format could be a pro/con table (sample below), but is up to you as the author. You must consider complexity, feasibility, cost/effort to implement, but also ongoing operational impact and cost. You must consider the program principles and explain any deviations in detail. This is probably as important as the decision itself.

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log