Issue

Syensqo has Delegation of Authority defined across multiple GBU's with different approver roles - Some of these approvals are systemised and some are done offline. With the new ERP rebuild program there will be an opportunity to standardize and define Delegation of Authority process across multiple GBU's.

Recommendation

Summarise the recommendation being made for the reader, leaving the pro/con evaluation and exact decision-making process to the subsequent sections.

Background & Context

Financial delegation of authority refers to the process by which an organization assigns specific financial decision-making powers to individuals or groups within the company. This delegation outlines who has the authority to approve financial transactions, such as expenditures, contracts, budget allocations, and other monetary commitments, and up to what monetary limit they can do so. Following are some of the key criteria for delegation of Authority

• Approval Limits:

  • These are predefined thresholds that specify the maximum amount an individual or role can authorize/approve.

• Roles and Responsibilities:

  • Different roles within the organization have varying levels of financial authority. The delegation matrix often outlines which roles have the authority to make specific types of financial decisions, ensuring that these roles align with the individual's responsibilities and expertise.

• Types of Transactions:

  • Financial delegation authority can vary depending on the type of transaction. For instance, a procurement officer might have authority over purchasing decisions, while a financial controller may have authority over budget adjustments or financial reporting.

• Hierarchy and Escalation:

  • The delegation of authority is typically structured hierarchically, where higher levels of financial commitment require approval from higher management levels. This ensures that more significant financial decisions undergo appropriate scrutiny.

Following are some of the key processes where DOA approval is applicable in Syensqo

• Portfolio and Project Expenditure
• Capital Expenditure
• Sourcing / Procurement Expenditure
• Sales proposals, prices and contracts
• Customer credits and rebates
• Inventory
• Acquisitions and Divestments
• Treasury

Syensqo currently has Delegation of Authority defined across multiple GBUs, each with its own set of approver roles, leading to a mix of systemized approvals and offline processes. This fragmented approach has created inconsistencies and inefficiencies across the organization, complex workflows in the system or non-system manual processes making it challenging to ensure uniformity and accountability in decision-making processes. 

Following are some of the DOA guidelines across GBU's. Some of these DOA's are global and GBU agnostic ex: Procurement and the others are GBU dependent with some have the DOA against the roles and some against named users. Implementing the workflows to support these DOA in the new SAP system is going to be extremely challenging due to the complexity and varied rule set for each of the GBU's

Novecare Commercial:

Procurement: PU-0002-G-WW-EN V.03-2024 Delegation of Authority Guideline (DoAG) (altirnao.com)

Composites: Credit - DOA Authorization File - Google Sheets

Speciality Polymers: https://aodocs.altirnao.com/drive/redirect/solvay.com/Pqleafl75pDtqjRhuN / for capex: Delegation of Authority GBU_Policy_DOA_v3.pdf (altirnao.com)

Technology Solutions: TS DOA September 22nd md (1).xlsx (altirnao.com)

Also, as part of the ERP rebuild, there will be a concerted effort to standardize job bands and positions across the organization. This alignment of bands and positions will further emphasize the need for a consistent approach to Delegation of Authority, ensuring that all employees, regardless of their GBU, operate under the same guidelines and have a clear understanding of their decision-making powers

Assumptions

There will be standardization of jobs and bands as part of the project

Constraints

Capture any constraints or limitations inherent to the recommended option. This could be aspects which, if changed or removed in future, could cause the decision to be revisited or invalidated. For example, a constraint might be that a new product has significant gaps in important functionality, which caused an older alternative to be recommended. If those gaps are closed in future, this might cause the decision to be invalidated.

Impacts

Delegations of Authority

Business Rules

Following are the Business Rules proposed

• Syensqo Group Delegation of Authority Financial Matrix is reference to all the DOA approvals within the organization
• Evidence of approvals will be stored in the respective system - as part of the workflow or as an attachment
• Approval workflow will be sent directly to the relevant position required to approve the full transactional values within the organization boundaries - There will be no step wise approval

Options considered

Following are the options considered for DOA

Option A: Keep the existing DOA

As part of this option, there is no change in the existing DOA and each GBU / process will have its own DOA matrix. 

Option B: Standardise the existing DOA 

As a part of this option, the DOA policy and financial matrix is standardised according to the standard job bands and positions. The standardization process ties the levels of authority—such as approval limits, spending thresholds, and contractual commitments—to specific job bands within the organization. Job bands typically reflect an employee's level of responsibility, expertise, and seniority, ensuring that those in higher bands have greater authority. For example, employees in senior management bands might have authority over large capital expenditures, while those in middle management might be authorized for smaller operational expenses.

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.

	Option A: Keep the existing DOA	Option B: Standardise the existing DOA
Criterion 1	Pro Con	Pro Pro
Criterion 2	Pro Con	Con
Criterion 3	Pro	Con

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

Workflow history