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 S4 HANA.  

The key drivers to centralize the Delegation of Authority (DOA) in S4 HANA 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 S4 HANA 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 S4 HANA reduces the need for extensive customizations across multiple platforms.

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

Overall, centralizing DOA in S4 HANA 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

 N/A

Impacts

Describe the impact of the decision on other aspects such as other processes, infrastructure, other SAP modules or systems, data cleansing and migration, developments, automations, interfaces, in-flight projects, etc.

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 S4 Hana, 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 S4 HANA

To be created in S/4HANA as table and custom interfaces. Org hierarchy and user details are available (via HR master data sync from SF to S/4HANA).

Reference Technical Architecture would following. 

Option B: DOA matrix and Framework in BTP

To be created in BTP BPA as business rule and CAP services to interface. Employee Data and Organization hierarchy data need to retrieved from Success factors. 

Reference Technical Architecture would following. 

Option C: DOA matrix and Framework in respective cloud applications 

DOA Table and Framework to be created in each system. Employee and Organisation need to be interfaced to all the relevant cloud application. 

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