This post focuses on the pre-implementation planning work that should be conducted to ensure a successful SAP Profitability and Performance Management (PaPM) project.
The topics discussed here are not limited to just SAP PaPM, but can be applied to any digital finance transformation initiative. The planning phase is important because it can serve as the basis of managing the project execution in terms of the budget and measuring how the delivered solution satisfies the original project requirements. The information we talk about here stems from our real-life experience running SAP PaPM.
Keys to Successful Financial Digital Transformation
The key to a successful financial digital transformation project is to navigate within the corporate governance framework. This is not always a straightforward exercise because it involves many different organizations: finance performance management, financial reporting, IT, capital projects, information security, and digital finance. The magic happens when disparate priorities align. The path to doing this is to let solution speak for itself. For an SAP PaPM project, the decommissioning of SAP Profitability and Cost Management (PCM) necessitated a search for an alternative cost allocation engine that would deliver performance management, management accounting, segment reporting, and financial accounting at the required level of granularity.
The criteria for the search and selection of such a solution would be in the following areas:
- Reporting functionality
- IT landscape fit
- Proof of value
- Purpose and scope
- Alignment with priorities and other strategic outcomes
We documented the current reporting functionality we were using, as well as how the various user groups were being supported. We identified a selection criteria list and prepared the scope to be used to evaluate the list of alternative applications from various vendors. One of the criteria involved was how the solution would fit within the current IT landscape; it was important to partner with potential vendors to help them deliver a solution proposal and be able to show how their product and services integrated with our current landscape. In our case, a pilot project provided a mechanism to bridge the use case requirements and features provided by SAP PaPM.
The scope of work documented the requirements and helped lay the groundwork for the pilot project, which needed to replicate the key calculations we used and emulate the results of the current SAP PCM system. The final vendor selection would then be based on a directive from IT, i.e. whether a sole-source or multi-source delivery was required. From there, we needed to work with the contracting department to approve the vendor and generate a purchase order for both software and hardware. It is at this point where finance management was needed to prioritize the project in case additional justification was necessary for a timely implementation.
The alignment of the various priorities of our organization would be accomplished through the identification of reporting functionality made possible by the new application. It was critical for the organization and all affected parties to rally around the delivery of the proposed PaPM solution.
Challenges of Financial Digital Transformation Projects
Even with the support of senior management, IT, and the SAP PCM end user community, the next significant challenge we faced was navigating through the IT roadmap, capital budgeting approval, and financial digital transformation approval process. These all depended on providing stakeholders with the proper justification for the project. Based on the success of our pilot project, we were able to identify criteria such as visualization and analytics with predictive capabilities; these enhanced our case.
Benefits of SAP PaPM Over SAP PCM
It helped our case that installing the solution close to the data source gave us better transparency, traceability, and auditability of our data. There were no limitations on cost centers as there were with SAP PCM. SAP PaPM gave us an appropriate level of calculation granularity and provided a single source of truth. Let’s look at a couple of examples.
Firstly, due to hardware and software application limitations in SAP PCM (even the 64-bit version, multi-threading on key dimensions was limited to a fixed set of input dimensions and only five output dimensions) values from the source system required a certain level of aggregation to simplify the calculations. Cost centers from the source system were aggregated to cost center groups or a responsibility center. This translated to a disconnect between the lower-level detail with the higher-level aggregation in SAP PCM and gave some inconsistent results. This was because the floating point calculation was limited by a fixed set of significant figures which could not keep the same accuracy on both levels of aggregation.
With SAP PaPM, a lower level of detail will allow for the correct allocation percentage or driver allocation at the cost center level to be applied with the availability of traceability and no loss of detail. This can be done because of SAP S/4HANA and in-memory computing, from which the accuracy is scalable on each level of aggregation so there are no floating-point calculation issues. There are also robust parallelization and partition features in SAP PaPM which allow for two billion records per partition and parallel processing for independent calculations.
Secondly, in SAP PCM, the allocation driver was applied equally regardless of cost elements or general ledger accounts, which introduced inaccuracy because certain cost elements like depreciation require a different driver. With SAP PaPM, we were able to include the asset location in our allocation logic through the derivation function for laser-focused assignment of depreciation costs at the cost center level. This was not possible prior to PaPM.
Just as in the solution selection process, the project justification and approval was based on the merits of improved reporting accuracy offered by SAP PaPM.
Getting Started with an SAP PaPM Project
At the time of writing this post, we had started stepping through our SAP PaPM project implementation. We met with the selected vendor to finalize the statement of work, project scope, deliverables, qualifications of technical consultants, and project timeline. We also made arrangements for both physical office space as well as remote connectivity to our network with user accounts and developer level access. We are in the process of installing the software and executing the post-installation steps as documented in the administration guide. We conducted meetings with all the stakeholders and subject matter experts to go over the implementation timeline and to manage expectations. We identified the implementation team including a project manager and subject matter experts. These are all steps you should follow when implementing SAP PaPM yourself.
Because SAP PaPM is a new application, it is important to organize training for the implementation team, schedule regular update meetings to address issues, and assign team roles and responsibilities. Conducting hardware sizing exercises with static/dynamic memory and processing requirements should not be ignored in order to anticipate the application's behavior once it goes live.
One thing we’ve learned so far is that we can leverage SAP PCM as a function unit dictionary; this was a pleasant surprise because we will not have to create SAP PaPM functions from scratch. We also plan to secure data sources from our existing IT landscape. Cost center, cost element, hierarchy, and activity driver information were identified as SAP Business Warehouse (SAP BW) info source objects. Some configuration will be required to enable either the SAP BW query or the SAP HANA view for the data to be consumed within SAP PaPM.
Information security is also a key feature in SAP PaPM that we were impressed with. Very early on, we identified the required roles and authorization for administrators, users with process roles, and users with view-only access. We required specific roles to be established for the administrator, edit user, and display user. SAP PaPM includes predefined roles that can be modified to accommodate these roles (and any other role) and authorization scenarios that our implementation may require. Each role will be set up by working with the information security group to create roles and access with variants to allow an appropriate level of data restrictions, then subsequently test the roles in the development environment.
Once the data sources have been secured, user roles and access established, the SAP Fiori launchpad tested, and functions developed, the next step will be to run the SAP PaPM model/environment in parallel for a pre-determined period of time to evaluate and validate the results against the SAP PCM ones. We then plan to unleash the full power of SAP PaPM, taking us above and beyond our current analytical horizon.
Conclusion
In summary, planning is critical for the success of any project, especially financial digital transformation ones like SAP PaPM. Interaction and coordination with other organizations and stakeholders need to be a continuous dialog. Getting ahead of potentially contentious issues will make the project execution straightforward and smooth. Everybody's concerns should be heard and addressed so that project success is assured. Having a solid implementation plan promotes a shared goal of delivering a solution that will take full advantage of the features offered by SAP PaPM. We’ll check back in later with another post on how the rest of the implementation went.
Comments