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

Based on the thorough analysis conducted, it is recommended to proceed with Option B: Standardize and simplify the existing Delegation of Authority (DOA) by aligning it with job positions and bands. This approach will lead to a significant simplification and standardization of the DOA framework across all Global Business Units (GBUs) within Syensqo, ensuring consistency and clarity in decision-making processes throughout the organization.

By aligning the DOA with specific job positions and bands, the organization will establish a clear and consistent framework where financial and operational authority is systematically granted based on an individual's role and level within the company. Furthermore, standardizing the DOA will enhance governance over both the DOA policy and the financial matrix. With a consistent and well-defined structure in place, the organization will be better equipped to monitor, manage, and audit financial and operational decisions, thereby reducing the risk of errors and unauthorized actions.

In addition to improving governance, the standardization of the DOA will also facilitate the systematization of workflows within the new SAP systems. By integrating the standardized DOA into the S/4 and other operational systems, Syensqo can automate approval processes, reduce manual intervention, and improve overall efficiency.

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 positions and bands in Sucess Factors as part of the project

Constraints

None identified at the time of writing

Impacts

Change Impact: Delegation of Authority matrix once standardised needs to be 

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
• Job Bands and positions will be directly referenced from HR
• The approver determination will be based on the 

Options considered

Following are the options considered for DOA

Option A: Keep the existing DOA framework

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 and simplify the existing DOA aligning with the job positions and bands

As a part of this option, the DOA policy and financial matrix is standardised according to the harmonized 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.

The table below is an example on how the financial amounts will be mapped to a band into the standardized DOA

Evaluation

	Option A: Keep the existing DOA	Rating	Option B: Standardise the existing DOA	Rating
Consistency Across Functions	Pro: Can be tailored to fit the unique requirements of each department, allowing flexibility. Con: Inconsistencies can arise across departments, leading to potential confusion and inefficiencies.	Medium	Pro: Ensures uniformity across all departments, reducing confusion and enhancing coherence. Con: May not account for specific needs of each department, leading to overgeneralization. This is however overcome by adding the exceptions to the DOA process where applicable	High
Efficiency	Con: May lead to delays as approval processes vary by department, causing bottlenecks. Offline approvals will still have to continue for some of the processes and some of the existing applications / excels will still have to stay as it is very complex to systemize the requirements	Low	Pro: Streamlines approval processes with clear guidelines, reducing delays. The workflows can be systemised and therefore the approvals can happen in the system	High
Clear Accountability	Con: Accountability may be inconsistent, with varying standards across departments. Proof of approval is stored in multiple places	Medium	Pro: Establishes uniform accountability standards, making it easier to manage and audit. Proof of approval is stored in the system as part of the workflow process	High
Risk Management	Pro: Allows departments to implement risk management practices that are best suited to their specific needs. Con: Different approaches in different departments can increase the risk of errors or compliance issues.	Medium	Pro: Reduces risks by applying uniform controls and procedures across the organization. Con: May not be flexible enough to address unique risks in specific areas. Exceptions in the DOA will have to cover these unique risks and might need exceptions in the DOA process	High
Training and Compliance	Con: Training and compliance efforts are more complex, as different policies may apply in different areas and training needs to be conducted multiple times	Medium	Pro: Simplifies training and compliance by having a single, clear policy to follow.	High
Scalability and Adaptability	Pro: Easier to implement changes in specific departments without disrupting the entire organization. Con As the organization grows or restructures, the policy needs to be revalidated / rewritten with the list of new DOA approvers	Medium	Pro As the organization grows or restructures, a standardized approach to DOA and financial authority can be easily adapted to new positions or job bands. This scalability ensures that the policy remains relevant and effective as the company evolves, without requiring significant overhauls each time the organizational structure changes Con: Can be difficult to manage and scale, particularly in larger organizations with diverse operations.	High
Change Management	Pro: Minimal effort for change management as the current process	High	Con: Requires extensive change management	Medium

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