04 Oct What does a BPC project look like?
One of the questions we often receive is how a BPC implementation differs from ‘traditional’ SAP implementations, since BPC is considered a Finance-centric (not IT) solution. The projects we’ve done have been IT led, with moderate to heavy involvement from Finance. That’s the position from which this article is written, although it is possible for Finance to lead an implementation as well.
Even in an IT-led project, it’s true that the Finance/Consolidations business team plays a larger role throughout the entire project life cycle. Certain functions, however, tend to remain IT responsibilities due to the nature of the work.
For example, report building can and generally does become a finance function. The EPM Add-In tool is very user-friendly and can be easily learned. The tool uses drag and drop functionality and is fully integrated with Excel, where finance users are typically experts. Other functions such as Script Logic, BPC’s programming language, require basic programming skills and is often more than a finance user cares to know. These two examples are opposite ends of the spectrum and most tasks fall somewhere in between.
Our BPC projects have followed the typical IT project framework, consisting of phases for Requirements, Design, Build, Test, and Deployment. The requirements phase tends to be somewhat abbreviated compared traditional projects since the BPC tool lends itself well to an agile project methodology. The emphasis for both IT and the business user is to identify the necessary data elements and the source(s) of the data. The business users also gather existing reports and help document the planning or eliminations requirements. During this phase, it should become clear how well the requirements map to BPC-delivered functions and where customization or enhancements are necessary.
In the design phase, the BPC data model is created. Along with the data model, decisions will be made regarding sourcing of data, i.e. from BW, uploads to BPC, manual maintenance in BPC, etc. Data modeling work tends to fall more to the IT team and less on the finance users. Finance users will be involved in decisions related to data sourcing and maintenance.
The build phase is where the project can significantly differ from traditional SAP projects, from a finance user’s perspective. In a traditional SAP projects, users rarely see the configuration settings. In BPC, much of what would be considered ‘config’ is contained in Business Rules in BPC. Business rules can be maintained and understood by finance users, so they can be involved in the development and initial testing of the rules from the ground up. Master data settings control how business rules work, so it is important that finance users who will be responsible for master data maintenance understand how settings affect business rules. Once data is available in BPC, finance users can begin building reports, earlier in the project life cycle than in traditional SAP projects. IT is usually responsible for any custom development that requires programming skills.
The testing phase varies slightly for Consolidations and Planning projects. For consolidations projects, the user-acceptance testing (UAT) consists of running through one or two full month-end cycles (two or more is preferred). Hopefully, by this time, the key finance users helped build the solution and are already comfortable with the solution. In projects where finance users have been less involved, testing can be a larger effort if they are seeing the full solution for the first time.
In planning projects, the testing audience may be bigger and some users may not have seen the solution yet. Scheduling and planning for this type of testing should account for the audience and involvement of the team to date.
Again, in the deployment phase, the phase varies between Consolidations and Planning projects. In Consolidations projects, the user-base tends to be smaller. It is common to do a parallel month-end with the legacy consolidations tool and BPC to compare the results.
For planning projects, the deployment can be a larger effort if there are many users who need to use the solution. In planning projects, there’s is not usually a parallel phase with the legacy tool.
Beyond the initial implementation, decisions must be made regarding roles and responsibilities for maintenance of the solution. For example, which settings will be maintained in production vs what will be transported? Auditors should be consulted while making these decisions. For example, Finance users may be allowed to change/create reports and input templates in production, but business rules may need to be transported. If transports are involved, that may push some responsibility to the IT department, since the transports are created in the BW backend, not in BPC.
Because BPC is so flexible, there’s a wide spectrum of options when defining the project team and responsibilities of team members. Companies should consider the size and skillset of both IT and Finance when looking for the best option for them. There are many viable options and many ways to be successful.