Overview
You can choose to implement any one or a combination of the solutions from the SAP Customer Experience solutions portfolio. Each solution has its own characteristics and specific implementation considerations in which you can find in the execution guidance under each cloud-specific project delivery framework. However, there are fundamental project considerations that are applied across solutions which is described in the over-arching project framework.
Table of Contents
- SAP Customer Experience solutions Project Considerations
- Project Methodology
- Project Key Deliverables
- Project Team
- Governance Structure
- Conclusion
SAP Customer Experience solutions Project Considerations
A SAP Customer Experience solutions project can be an implementation of any or a combination of the five solutions. Our focus in this article is mainly on implementation projects. Regardless of which solution you are engaging with, the following project considerations are applicable.
Time-to-Value and Iterations
The SAP Customer Experience solutions portfolio helps to deliver an excellent customer experience. It establishes and maintains the trusted, personal, relevant, and useful experience with the solutions while quickly responding to the market needs. Implementation projects of any solution within the Customer Experience portfolio should not aim to get every bell and whistle complete at the first launch; it will either take too long or will be too costly. Also, things can change by the time you complete the implementation. To keep up with the disruption, projects should launch quickly and often to allow for the ability to collect and analyze customer feedback. Avoid the temptation of replicating every single feature from the current system into the new solutions. By doing so, it can lose sight of the true strategic goals. Take the time to clearly define the project goals to align with the business strategy and vision.
Unified and Integrated Solution
Your project can start with any one of the solutions in SAP Customer Experience solutions. In most cases, it is rare to implement a standalone solution without any integration with another system. You should identify integration touchpoints with other systems as part of the project planning to highlight the dependencies. In addition to integrations, having a unified approach to customers is also key. You can truly maximize the value of the customer experience by achieving a unified platform, front-office, customer profile and customer data that run across the front and back office.
Enabling and Empowering Clients Throughout the Process
The client team must be empowered to make decisions, and single representatives should be identified to manage this from business, technical, project management, and quality management perspectives. To ensure the representatives fully understand the solution capabilities to administer and iterate the future releases, enablement requirements should be identified early in the project. As much as possible, the customer resources should be embedded and they should actively collaborate with the project team throughout the project.
Quality Baked-in
Fast-paced projects does not mean that you have to cut corners. Quality is important and must be baked in project from day one. All testing activities must be identified from the start; with responsibilities assigned and planned alongside all other critical activities. Testing should never be left to only the customer, nor should it be left solely to the technical teams. Dedicated and professional quality management resources are an essential part of the project team. They ensure quality throughout the user experience and project lifecycle. Investing in quality can minimize a huge source of wasted time and effort when investigating/fixing defects and re-delivering for repeated testing cycles.
Project Methodology
When choosing a project methodology keep in mind that the SAP Customer Experience solutions project frameworks have been aligned with the SAP Activate methodology. By aligning with the same methodology that has been widely adopted for S/4HANA implementations, it simplifies and streamlines the path between the front office and back office.
SAP Activate Methodology
The SAP Activate methodology was developed to take a whole-lifecycle approach. In addition to the initial implementation project, it is also focused on operations and future innovations. A key goal of SAP Activate is to use best practices to reduce customizations on the standard product, which in turn reduces effort and cost, and subsequently allows customers to take advantage of faster deployments of innovations released in new product releases.
SAP Activate is the guiding methodology through Prepare, Explore, Realize, Deploy and Run phases
Prepare
Prepare accelerates the Project Preparation phase and establishes an overall framework for the program including:
- Executive Alignment and Governance
- Vision and Scoping
- Program Readiness
- Data Strategy
- Scope Fit/Gap and Project Plan
Explore
In the Explore phase, industry and solution experts from SAP lead a series of structured show-and-tell and solution design workshops. The goal of these workshops is to create a set of process-oriented, technical documents that illustrate how the customer intends to run their business using SAP solutions.
Realize
During the Realize phase, the project team uses a series of iterations to incrementally configure / develop, test, confirm and document the entire end-to-end solution and to load data. The project team actively works with business representatives to ensure good fit of the built solution. The team releases results of multiple iterations to the business users to accelerate time-to-value and provide early access to finalized functionalities.
Deploy
In the Deploy phase, the project team prepares the system for production release, switches to production environment, and conducts post go-live activities. At the end of this phase, the production system is operational and customer’s business operations are conducted in the new environment.
Run
The Run phase keeps the system available and performing at the high levels required to support business operations. During the system implementation, the project team puts in place an initial set of SAP operation standards. Additionally in the Run phase, the live system is assessed to identify opportunities to further optimize the system by applying additional standards.
Project Key Deliverables
During each phase, the project team produces prescribed set of deliverables that serve as inputs to subsequent phases. Various key deliverables are produced and referenced during projects which are shared with customers and other stakeholder.
Project Team
Having the right skill sets and resource coverage throughout the project can minimize the risks of onboarding a new team member. While each solution has its own specific needs, there are key project roles that need to be filled.
The core team roles and responsibilities are outlined below.
| Role | Responsibilities |
| Executive Sponsor |
|
| Steering Committee |
|
| Program Manager |
|
Project Manager |
|
| Integration Manager |
|
| Business Process Owners |
|
Governance Structure
In a larger organization, projects are usually not stand-alone but embedded in bigger programs. In the context of the SAP Customer Experience solutions project environment, the organization can benefit from program management by: minimizing and managing risks across the projects, managing the dependencies across the projects, ensuring the successful delivery of the projects and ensuring the strategic outcome of the overall program.
A recommended program governance structure consists of five different units. Depending on the needs of the organization, there can be sub-units. The image below shows an example of a program management structure.
The structure can be tailored to the needs of the environment in which the program is operating in. For example, the responsibilities of the Change Advisory Board can be taken over by the Steering Committee if there are not so many change requests expected or a new Dependency Advisory Board can be created if the program deals with many high-risk project dependencies.
Steering Committee
The steering committee is the highest and final decision-making unit of the program. It consists of the program sponsor, all major stakeholders (such as Business and IT), and representatives of involved implementation units or partners. All participants must be empowered to take decisions on behalf of the organization they belong to.
Program Management Office (PMO)
The Program Management Office (PMO) is the central working unit of the program. It maintains the overall program plan including the risk register, dependencies register, cost base line, time base line, and the change request register. It also organizes and facilitates the different committees, boards and meetings, and keeps track of the program status.
Enterprise Architecture Board
The enterprise architecture board is the authority responsible for defining the overall system architecture of the solution on all levels (Solution, Integration, Infrastructure). They ensure that the system architecture works across all involved projects and that it fits into the existing system landscape. They also avoid unnecessary duplication of functionality, code or data and define the master data strategy. The board also must define clear rules and criteria on what requires enterprise architecture board approval and types of decisions can be taken on a project level.
Business Process Board
The business process board is the authority responsible for defining the end-to-end business process across all solutions and projects. They define which business functionality must be implemented to ensure a working end-to-end business process. They also avoid duplication of business functions. The board is also responsible for prioritizing the overall business functionality across all projects to ensure that the outcome of each project fits together and fulfills the requested business needs. The board also keeps in contact with all involved business units and is the first point of contact for newly involved business units. The board must define clear rules and criteria what requires a program level decision and what can be decided on a project level.
Change Advisory Board (CAB)
Change is inevitable during a project and the change can be associated with the project scope, cost, and timeline. The change advisory board (CAB) checks and decides on change requests (CR). Therefore, the CAB checks the impact of a CR from different perspectives. For example, it checks the impact from a system architecture point of view or from the overall business process point of view. They can also check the impact from a cost or timeline perspective on other projects of the program. The CAB provides a recommendation on each CR back to the steering committee. The CAB also must provide rules and criteria on what CR must be approved on program level and what CR can be approved on project level.
Other Program Boards
Depending on the needs of the organization, other program boards, committees or meetings can be required. For example, a deployment approval board can be introduced to manage the deployment dependencies across multiple implementation projects.
Conclusion
Keep in mind that the SAP Customer Experience solutions project framework will continue to evolve. We start with harmonizing the project frameworks across all five solutions to share the same taxonomies which will allow the project teams and customers to easily adapt each step of their journey. The framework is designed to be adaptable and extendable with the consideration of how the front-office and back-office connect and share data. Here are the project frameworks for each specific solution:
- Project Delivery Framework for SAP Marketing Cloud
- Project Delivery Framework for SAP Commerce Cloud
- Project Delivery Framework for SAP Customer Data Cloud
Disclaimer: Original version of this article was written in SAP CX Works.
- SAP Managed Tags:
