Almost every company that runs SAP has an IT organization which is aiming to maximize the effectiveness of employed SAP software and technology for the best business outcome. We currently observe that in many organizations SAP landscapes are either already in a process of significant changes or those changes are planned soon. With the implementation of new or additional SAP software customers need always to decide how to manage the SAP landscape after the implementation is done.
While some IT organizations just slightly adjust or scale up the existing organizational setup, most of our SAP customers want to leverage the momentum of a larger implementation project to redefine their setup fundamentally such as organizational structure, ways of working, ways of sourcing etc. They understand that a later or standalone performed reorganization measure is costly and sometimes traumatic and not easy to carry out. Therefore, such a project phase would be a welcome opportunity for a change.
Unfortunately, there is no such thing as a “one size fits all” or “best practice” organizational setup and org chart for the IT department or an "Customer COE for SAP" (Customer COE for SAP stands for a Center of Expertise for SAP. It is an officially approved name and a SAP brand and it is supported and managed by the Customer COE program by SAP. Further information about the Customer COE Program by SAP: http://support.sap.com/ccoe). It depends on many factors like the company structure, -size, and market presence, the current business practices as well as the set strategic direction and the corresponding C-Level experiences and expectations.
Based on our many-years experiences working with many CIOs, IT directors and SAP IT leads, we identify three basic concepts for SAP IT organizations for which SAP technology is part of their strategic choice (see Figure 1):
For the sake of simplicity, we elaborate on the three concepts by referring to the Plan/Build/Run Distinction to allocate all various SAP capabilities that are required to develop, maintain and operate the SAP landscape holistically. The organizational effectiveness depends on how SAP capabilities are assigned and organized.
SAP-related capabilities in the Plan space are e.g. SAP architecture, innovation management, demand management, SAP license (cost) management. The Build part represents all SAP project and program management as well as PMO (project management office) capabilities. The Run part contains for example SAP application management incl. user support, incident and problem management, SAP basis, operations control, and all other rather technical capabilities incl. day to day third party, managed service or cloud service consumption and management.
SAP as a Shared Service Center (SSC) or as a centralized team means to put all your experts with SAP-specific capabilities under one lead. This concept is beneficial due to the economies of scale and scope e.g. for SAP resources efficiency, SAP innovation and technology adoption, SAP budget allocation, SAP sourcing readiness.
There are some areas that are usually not assigned to the "Customer COE for SAP". These are e.g. the 1st level SAP support (service desk) or the data center, and infrastructure team. Many companies have already chosen a centralized or outsourced approach accordingly.
To centralize SAP capabilities in a Shared Service Center often requires organizing non-SAP capabilities in the same logic. This results in further centralized SSC's such as for non-SAP technologies or for Integration. The integration SSC, for example, would hold all the interface and integration experts to connect the different key technologies for a seamless processing and data flow across.
In a life-cycle based structure, the "Customer COE for SAP" functions are split up across the cycles Plan, Build and Run. The planning unit in a Plan-Build-Run model consists of IT strategy planning, IT governance and architecture as well as business services portfolio management and financial management. The Change Unit comprises of program and project management and requirements management. Run provides the operational support to keep the technology environment operating, including components such as an end-user service desk, a field service organization and level-one and -two support operations.
In the third option, a business domain-oriented structure, the IT department mirrors the various business domains such as the Accounting unit or Purchasing unit. Like the life-cycle-based structure, the "Customer COE for SAP" functions are split across several domains instead of being implemented as a centralized unit.
The SAP capabilities are spread all over the organizational setup. Especially SAP application management is spread across several teams and heads. Below the application layer further capabilities are needed such as SAP Basis. Those teams are usually centralized under one head supporting the various application teams.
Many companies have established or are in the process of up-scaling agile teams. In the three basic concepts, we call them feature teams. Feature teams are small and temporary teams, equipped with cross knowledge from business and IT. Each team has a product owner and the team works on a defined product or subject that needs to be improved or launched very quickly due to a high prioritized business rationale. A feature team may also be called agile team, squad, chapter, tribe or pizza team. There are many terms in the market, but the purpose is always similar: faster time to market through incremental results. As business and IT must send their experts into those feature teams as needed, it works with any organizational setup. More important than the organizational setup is the mindset of the business and IT individuals at all levels and the appetite to innovate and to improve faster. This transformation towards an agile organization (not only performing projects in an agile mode) is immense as it impacts bold traditional structures within the company: ways of working and how the best people wants to work, changing leadership behavior and political power, resources and budget allocation etc. For example, in an agile approach you would no longer fund any projects. Instead, you would fund products. Business outcome counts that means “Don’t think organizational!”; “Think processes, products and Eco-systems! Think adaptive & outcome focused”. And DevOps by the way is the IT part of agile working. It is more beneficial to approach Business IT integration from the very beginning and to execute e.g. “BizDevOps” (Business/Development/Operation).
Choosing the right organizational structure for an "Customer COE for SAP" is critical to its success. However, there is no “one size fits all” for every organization. Each company must identify its best way, and just as mentioned, an individual solution will bring the desired success.
As our consulting experts from “Digital IT Transformation” get deeper insights year after year into 20-30 various "Customer COEs for SAP", we can clearly state that the best running SAP IT organizations have centralized their SAP resources and capabilities into one entity often referred to an "Customer COE for SAP" or SAP team.
In order to compare the pros and cons of the centralized or divided approach you should first consider your company and/ or IT goals and directives, such as time to market, process standardization, digitization, technology value. On the other hand, we have identified long-lasting operational challenges such as resource -, IT process -, and governance efficiency and effectiveness. In Figure 2, we have lined up some of the recurring pros and cons that can be considered.
Our experiences show that this setup requires a very strong governance and design authority for the SAP Landscape to meet companies’ goals. Otherwise there is a risk that the various application or platform teams running SAP and Non-SAP develop an “independent existence” over time (silos). As a result, neither an SAP manager nor an "Customer COE for SAP" lead and a corresponding SAP team with focus and accountability for the entire SAP life-cycle are foreseen in this setup. Figure 3 shows a typical situation.
Several key business solutions are defined. The IT organization mirrors the business structure. Each business domain has a solution team within the IT organization that supports the domain specific business processing by applying one or two key solutions.
SAP is used by all business domains. By consequence the SAP landscape with its broad process integration is managed, governed and owned by several solution heads. Usually this result into a very challenging SAP governance. The alignment effort for SAP improvements and innovations might be high and decision making is slow. It needs to be emphasized that in this example, approximately 60% of all business processes run on SAP business software and technology.
Other key solutions (non-SAP) are characterized by a rather 1:1 relationship between the domain/solution team and the key solution. The ownership for each key solution is clearly assigned. That enables a relatively simple governance from an organizational point of view.
If the organization does not pursue the centralized SAP approach, some solid governance measures are recommended to safeguard your SAP investment in a distributed setup. Referring to the Plan/Build/Run Distinction, for each step a gate should be established to protect the SAP landscape and the SAP investment across the various IT teams for the best business outcome.
Is it a welcome time to change current organizational setup? Does the organization have enough governance pain and willingness to change? Can it add enough value to the company? Can it be performed without high risks or negative side effects? One yes only is enough to trigger on a debate in this highly politicized space. Even the exchange of pros and cons between supporter and opponents of centralization and decentralization helps your organization to develop successfully.
Useful links:
1. To Centralize or Not to Centralize the SAP IT Organization - The Eternal Question
While some IT organizations just slightly adjust or scale up the existing organizational setup, most of our SAP customers want to leverage the momentum of a larger implementation project to redefine their setup fundamentally such as organizational structure, ways of working, ways of sourcing etc. They understand that a later or standalone performed reorganization measure is costly and sometimes traumatic and not easy to carry out. Therefore, such a project phase would be a welcome opportunity for a change.
Unfortunately, there is no such thing as a “one size fits all” or “best practice” organizational setup and org chart for the IT department or an "Customer COE for SAP" (Customer COE for SAP stands for a Center of Expertise for SAP. It is an officially approved name and a SAP brand and it is supported and managed by the Customer COE program by SAP. Further information about the Customer COE Program by SAP: http://support.sap.com/ccoe). It depends on many factors like the company structure, -size, and market presence, the current business practices as well as the set strategic direction and the corresponding C-Level experiences and expectations.
Based on our many-years experiences working with many CIOs, IT directors and SAP IT leads, we identify three basic concepts for SAP IT organizations for which SAP technology is part of their strategic choice (see Figure 1):
(1) Shared Service / Technology based structure
(2) Life-cycle (plan, build, run) based structure
(3) Business domain-oriented structure
Figure 1: Basic Concepts of IT Organizations with SAP allocation
For the sake of simplicity, we elaborate on the three concepts by referring to the Plan/Build/Run Distinction to allocate all various SAP capabilities that are required to develop, maintain and operate the SAP landscape holistically. The organizational effectiveness depends on how SAP capabilities are assigned and organized.
SAP-related capabilities in the Plan space are e.g. SAP architecture, innovation management, demand management, SAP license (cost) management. The Build part represents all SAP project and program management as well as PMO (project management office) capabilities. The Run part contains for example SAP application management incl. user support, incident and problem management, SAP basis, operations control, and all other rather technical capabilities incl. day to day third party, managed service or cloud service consumption and management.
(1) Shared Service / Technology based structure
SAP as a Shared Service Center (SSC) or as a centralized team means to put all your experts with SAP-specific capabilities under one lead. This concept is beneficial due to the economies of scale and scope e.g. for SAP resources efficiency, SAP innovation and technology adoption, SAP budget allocation, SAP sourcing readiness.
There are some areas that are usually not assigned to the "Customer COE for SAP". These are e.g. the 1st level SAP support (service desk) or the data center, and infrastructure team. Many companies have already chosen a centralized or outsourced approach accordingly.
To centralize SAP capabilities in a Shared Service Center often requires organizing non-SAP capabilities in the same logic. This results in further centralized SSC's such as for non-SAP technologies or for Integration. The integration SSC, for example, would hold all the interface and integration experts to connect the different key technologies for a seamless processing and data flow across.
(2) Life-cycle (plan build, run) based structure
In a life-cycle based structure, the "Customer COE for SAP" functions are split up across the cycles Plan, Build and Run. The planning unit in a Plan-Build-Run model consists of IT strategy planning, IT governance and architecture as well as business services portfolio management and financial management. The Change Unit comprises of program and project management and requirements management. Run provides the operational support to keep the technology environment operating, including components such as an end-user service desk, a field service organization and level-one and -two support operations.
(3) Business domain-oriented structure
In the third option, a business domain-oriented structure, the IT department mirrors the various business domains such as the Accounting unit or Purchasing unit. Like the life-cycle-based structure, the "Customer COE for SAP" functions are split across several domains instead of being implemented as a centralized unit.
The SAP capabilities are spread all over the organizational setup. Especially SAP application management is spread across several teams and heads. Below the application layer further capabilities are needed such as SAP Basis. Those teams are usually centralized under one head supporting the various application teams.
2. The Agile Journey
Many companies have established or are in the process of up-scaling agile teams. In the three basic concepts, we call them feature teams. Feature teams are small and temporary teams, equipped with cross knowledge from business and IT. Each team has a product owner and the team works on a defined product or subject that needs to be improved or launched very quickly due to a high prioritized business rationale. A feature team may also be called agile team, squad, chapter, tribe or pizza team. There are many terms in the market, but the purpose is always similar: faster time to market through incremental results. As business and IT must send their experts into those feature teams as needed, it works with any organizational setup. More important than the organizational setup is the mindset of the business and IT individuals at all levels and the appetite to innovate and to improve faster. This transformation towards an agile organization (not only performing projects in an agile mode) is immense as it impacts bold traditional structures within the company: ways of working and how the best people wants to work, changing leadership behavior and political power, resources and budget allocation etc. For example, in an agile approach you would no longer fund any projects. Instead, you would fund products. Business outcome counts that means “Don’t think organizational!”; “Think processes, products and Eco-systems! Think adaptive & outcome focused”. And DevOps by the way is the IT part of agile working. It is more beneficial to approach Business IT integration from the very beginning and to execute e.g. “BizDevOps” (Business/Development/Operation).
3. Comparison of Central versus Distributed SAP IT organization
Choosing the right organizational structure for an "Customer COE for SAP" is critical to its success. However, there is no “one size fits all” for every organization. Each company must identify its best way, and just as mentioned, an individual solution will bring the desired success.
As our consulting experts from “Digital IT Transformation” get deeper insights year after year into 20-30 various "Customer COEs for SAP", we can clearly state that the best running SAP IT organizations have centralized their SAP resources and capabilities into one entity often referred to an "Customer COE for SAP" or SAP team.
| Criteria | "Customer COE for SAP" as Distributed (Virtual) Approach | "Customer COE for SAP" as Centralized Approach |
| SAP People | Multiple resources with the same skill set across solution teams e.g. S4 development skills | Optimal resource allocation and utilization |
| Hard to get all needed skills and resources per solution team | Strategic skill management (economies of scale) | |
| More difficult to have substitutes for all experts per solution team and to manage work life balance | Easier to have a consistent people development and career paths the SAP world | |
| Higher usage of external resources per solution team, key resources and loss of knowledge as a risk | Easier to manage and leverage external resources, easier to avoid bottlenecks and loss of knowledge | |
| SAP IT Processing | Heterogeneous processes, procedures per solution team “independent existence” over time (“Silos“) | Homogeneous processes and procedures through central, top down governance |
| Higher hurdles to automate processes and procedures per solution team | Easier to invest in automation through central, top down governance | |
| SAP Governance | Higher hurdles to adjust existing or to introduce new governance rules, organizational changes or innovations across all solution teams | Easy to introduce or change rules, org. changes, innovations |
| High effort for communication, alignment and decision making across the solution teams to adjust or introduce SAP-based business capabilities | Enables a real and fair IT solution/technology competition between the key solutions to get the best business outcome |
Figure 2: Comparison of Central versus De-central SAP IT organization
In order to compare the pros and cons of the centralized or divided approach you should first consider your company and/ or IT goals and directives, such as time to market, process standardization, digitization, technology value. On the other hand, we have identified long-lasting operational challenges such as resource -, IT process -, and governance efficiency and effectiveness. In Figure 2, we have lined up some of the recurring pros and cons that can be considered.
4. The Challenge with the Distributed Setup
Our experiences show that this setup requires a very strong governance and design authority for the SAP Landscape to meet companies’ goals. Otherwise there is a risk that the various application or platform teams running SAP and Non-SAP develop an “independent existence” over time (silos). As a result, neither an SAP manager nor an "Customer COE for SAP" lead and a corresponding SAP team with focus and accountability for the entire SAP life-cycle are foreseen in this setup. Figure 3 shows a typical situation.
Figure 3: Key solution usage by business domains
Several key business solutions are defined. The IT organization mirrors the business structure. Each business domain has a solution team within the IT organization that supports the domain specific business processing by applying one or two key solutions.
SAP is used by all business domains. By consequence the SAP landscape with its broad process integration is managed, governed and owned by several solution heads. Usually this result into a very challenging SAP governance. The alignment effort for SAP improvements and innovations might be high and decision making is slow. It needs to be emphasized that in this example, approximately 60% of all business processes run on SAP business software and technology.
Other key solutions (non-SAP) are characterized by a rather 1:1 relationship between the domain/solution team and the key solution. The ownership for each key solution is clearly assigned. That enables a relatively simple governance from an organizational point of view.
5. Key Recommendations for the Distributed Setup
If the organization does not pursue the centralized SAP approach, some solid governance measures are recommended to safeguard your SAP investment in a distributed setup. Referring to the Plan/Build/Run Distinction, for each step a gate should be established to protect the SAP landscape and the SAP investment across the various IT teams for the best business outcome.
- Plan Gate: Establish SAP Design Authority
- Build Gate: Establish a central Release Command and Control (RCC)
- Run Gate: Establish an Operations Control Center (OCC)
- Across: Establish SAP Steering Committee
Figure 4: Cross Concepts to ensure E2E SAP Governance
- Plan Gate: Establish “SAP Design Authority”
- Keep SAP Standard (incl. agreed custom development, business partner) protected as hard as really needed
- As IT, do not block but do challenge and avoid development of “Golden Balconies”
- Perform “Fit to SAP Standard” as a mandatory step within the “from demand to solution” process
- Build Gate: “Establish a central Release Command and Control (RCC)”
- Ensure smooth operations through standardized procedures, guidelines and processes for Change-, Test-, Release-, and Deployment Management for the SAP world
- Protect the productive SAP environment
- Keep away insufficient tested changes and releases
- Manage business and technical releases as well as internal and vendor releases
- Run Gate: “Establish an Operations Control Center (OCC)”
- See all aspects of the health of your IT landscape at one glance
- See hiccups in critical business processes before the business notices
- Perform business process improvement
- Improve business continuity and reduce total cost of operations
- Across: “Establish SAP Steering Committee”
- Provide SAP strategy, direction and road-map, allocate SAP budget
- Provide a management audience to make SAP decisions about the various IT teams and along the entire SAP life cycle (360° view)
- Support the implementation of OCC, RCC and Design Authority
- Observe synergies and technology competition across the various IT teams
...
Is it a welcome time to change current organizational setup? Does the organization have enough governance pain and willingness to change? Can it add enough value to the company? Can it be performed without high risks or negative side effects? One yes only is enough to trigger on a debate in this highly politicized space. Even the exchange of pros and cons between supporter and opponents of centralization and decentralization helps your organization to develop successfully.
...
Torsten Scheffler is Principle Business Consultant at SAP
Useful links:
- For more information explore SAP Advisory Services:
https://www.sap.com/services/advisory-development/business-transformation.html - Further information about the Customer COE Program by SAP:
http://support.sap.com/ccoe
- SAP Managed Tags:
2 Comments
