What To Expect

Our consultancy teams will work closely with you, sharing their knowledge and expertise. They’re highly experienced and have done this many times, for businesses of all sizes working across various sectors. They’ll be involved at every step, from start to finish:


Installation and initial hardware set up


Data gathering and analysis to support installation


Application design and development


Performance tuning


Data migration and testing your system

The Process



The project starts with the Initiation phase. During this…

The project starts with the Initiation phase. During this phase, the following elements are discussed, clarified and documented in the Project Initiation Document (PID): project strategic objectives and benefits; functional, geographical and technical scope; project roles and responsibilities; deliverables; high level project plan; effort and cost estimates; resource plan including Copperman and client resources; and identified assumptions, dependencies, risks and issues.

During this phase, the project lifecycle approach options - whether Agile or Waterfall - are discussed and the best option is defined considering the project and client profiles.


Functional Requirements

During Functional Requirements, a series of investigatory…

During Functional Requirements, a series of investigatory activities - such as meetings, interviews, conference calls or video conferences, workshops, documentation reading, and existing technology investigation - take place. This work gives us a detailed understanding of the business, functional and technical requirements of the future solution.

Our structured approach to requirements, which includes a set of predefined areas for investigation based on a questionnaire that is specific to Financial Consolidation or Business Planning, brings agility to the investigation and guarantees no important requirement is missed.


Solution Design

During Solution Design, the solution is documented in the…

During Solution Design, the solution is documented in the Solution Design Document (or Solution Blueprint), presented to you and validated.

Within this document, we provide a detailed description of the future processes supported by SAP BPC. This document also contains the solution architecture diagram, the list of components (commonly referred as RICEFW) and functional and technical specifications for each component including dimensions, input forms, reports, security, script logics, ABAP codes, interfaces, work status, business process flows and validations.

The documentation supporting each component is tailored by component type so that the best balance between project efficiency and scope management can be achieved. For example, it is common to develop demo applications with mock ups of input forms and reports using the Excel front-end to provide you with a better understanding of these component types. Normally these mock ups are sufficient for development; however, it is not possible to mock up an interface in Excel and for this component type a detailed technical specification is more appropriate.

The development of a robust Solution Design Document is key as it provides the best baseline for scope management during the project lifecycle.


Build and Unit Testing

During the Build and Unit Test, our team of experienced technicians…

During the Build and Unit Test, our team of experienced technicians with specific knowledge of SAP BPC will develop the solution.

Performing unit tests on the solution is part of this phase. Unit testing involves simple tests on each component to check their mechanical operation and alignment to design. Unit testing is performed by the development team alongside build, following our structured unit testing methodology.

Given SAP BPC’s high flexibility, we recommend that the build is completed alongside you, as the client, and where possible close to end users. When this is not possible, establishing a formal mechanism for presenting the system to end user representatives during build is critical, so that feedback is received and adjustments to the solution can be incorporated in a timely manner.

We also recommend involving your technical resources team in the build phase to enable us to easily share our knowledge with you and decrease your long-term dependency on external support for SAP BPC.



Once the solution is built and unit tested, the project progresses…

Once the solution is built and unit tested, the project progresses with other formal testing activities. The quantity and type of testing activities depend on the solution’s complexity,  lifecycle approach and client availability, all to be discussed and agreed with you and documented in a Testing Strategy document. Testing may include some or all of the activities below:

a) System or Component Testing - where the application is typically jointly tested by our experts and members of your team, involving a restricted number of business representatives, to check the mechanical operation and adequacy of each component individually.

b) Integration Testing - focused on testing the interfaces between SAP BPC and other systems, whether inbound or outbound.

c) UAT (User Acceptance Testing) - when end users are invited to test SAP BPC following structured test scripts, to confirm the new system is functionally fit-for-purpose.

d) Performance Testing or Non Functional Testing - this aims to guarantee the system will perform at the right speed and deliver adequate response times.

e) Data Migration Reconciliation - to allow the business to verify and reconcile the data that has been loaded into SAP BPC.



We believe successful training is critical for any SAP BPC…

We believe successful training is critical for any SAP BPC implementation. Training begins with a Training Strategy and Approach document that defines the quantity and type of training activities within the project. The most adequate format(s) for training depend on a number of factors such as solution complexity, user type (end user, system administrator, report builder, etc.), lifecycle approach, project plan, costs, and user availability. Based on our extensive experience in delivering specific training for SAP BPC systems, we can provide pragmatic advice on the best Training Strategy.

Training is then delivered as per the Training Strategy and can involve the following formats:
- Classroom sessions
- One-to-one sessions
- Executive training
- Computer-based training
- Self training/reading training materials.

Typically SAP BPC solutions have the following user types, each type requiring specific training:
- End users, who need to understand how to navigate through SAP BPC, input data, run reports and run calculations.
- Super users, who are normally business users capable of creating and maintaining input forms and reports with little support from IT or support providers.
- System administrators, who require a deep understanding of SAP BPC. We recommend all system administrators are involved in development so that they can naturally gain in-depth knowledge of the solution.


Data Migration

The process of migrating data can vary in difficulty depending…

The process of migrating data can vary in difficulty depending on the complexity of the BPC solution in comparison with the incumbent system.

When BPC is implemented for Consolidation, organisations are typically trying to take advantage of the additional automated system functionality and improved data separation.  This usually means that additional effort is required to prepare source data in the necessary detail.

We are experienced at guiding organisations through this detailed process, from planning to the final reconciliation.



This is the process of “go-live”, including managing…

This is the process of “go-live”, including managing any parallel run processes. The decision to “go-live” will be based on predefined criteria.


Support & Maintenance

This covers post-implementation support, which could be a…

This covers post-implementation support, which could be a help desk solution or outsourced service, as well as ensuring change control processes are in place and maintenance processes have been defined.


Change Management

Change management is often overlooked, but is necessary to…

Change management is often overlooked, but is necessary to ensure that stakeholders are aware of timelines and can participate in and prepare for key activities.

Change Management is typically led by organisations themselves. However, the implementation partner always has a role within the process, whether it be performing regular system demonstrations or creating content for communications. We will always seek to inform where and when users can appropriately engage in the process, including explaining the steps user-groups can take independently to prepare for system delivery.