The business blueprint is arguably the most important – and most complex – document that is delivered during an implementation. But how much time should be allotted to this phase?
When the blueprinting phase of a project begins, the project team already knows several things about the project. For example:
- We know that the project will be initiated as an answer to a specific business problem
- In most cases, we know the primary technology to be leveraged
- We understand most or all of the high-level requirements for the project
- We have a general idea of how the software should function compared to any legacy systems
One of the most surprising things to come out of the blueprinting phase is that early on you start to understand the things that you don’t know. For example, we may know that Account A should be reported in the final budget submission of our new planning tool. An experienced consultant should be able to identify several unknowns from that one statement, such as:
Where do the values for this account come from? Does it have historical data? Have we identified drivers for this account that should be part of a driver-based business calculation? How are these drivers identified or maintained? Are the drivers themselves a part of a business calculation?
When we begin answering questions like these, account-by-account and line-by-line, we can begin to translate the results into a holistic design that provides a systematic solution from both a high-level as well as an extremely granular basis.
It gets better from there! Sometimes the answers to the questions that you just answered have a caveat to them – it may be true for 85% of your business, but for specific cost centers or profit centers another rule applies. Or perhaps it’s activity-driven where one rule applies for certain business activities but another rule applies for others. Sometimes subject matter experts can disagree on what the rule should be and more meetings need to be held in order to come up with a resolution on how to move forward both functionally and technically.
A business blueprint should serve several purposes in any successful implementation. It should serve as:
- Complete documentation for the client to fully-understand and sign off on the solution before the build/realization phase begins
- The to-be definition used to build a project plan and provide estimates for each task
- A reference throughout the project that serves to answer any question of how a deliverable should function
In addition to the above, the blueprint should be used to hold the project team accountable for every facet of the implementation during the build and testing phases.
A document of this importance and complexity takes time to create, and it should go through at least a couple of iterations before sign-off. While the time to create this document will vary from solution to solution, a typical timeline is illustrated below.
This timeline is representative of a robust, driver-based planning solution built on SAP BPC which incorporates best practices and as much out of the box functionality as possible, but still has plenty of custom business intelligence. Depending on the complexity of the solution, the right amount of design can vary. For example, if a large data integration exercise is necessary in addition to the above, the design timeline could easily be extended. On the other end, if the requirements dictate a relatively simple solution, the design time could safely be shortened to 8 weeks or fewer. In practice, it is always wiser to allow for more time for design rather than taking a “pencils down” approach to the start of the build/realization phase.
When the entire project team acknowledges how important it is to agree on a fully-documented design before the build phase can begin, they’ve made the first step towards a successful implementation. The unfortunate reality is that many projects have only a 1 to 3 week blueprinting/design phase. When this happens, requirements can keep creeping up throughout the build and test phases. Rework occurs because certain processes weren’t completely fleshed out before the realization phase began. Key members of the project team end up working nights and weekends in order to meet the criteria for a successful go-live, and compromises of the quality of the system must be made even then.
Incorporating too short of a blueprinting phase is the single most risky thing project teams routinely do on projects. It introduces risk in every phase of the project, and usually ends with burned out consultants, a sub-par or lower quality implementation, budget woes and a less than happy client.Interested in learning more about best-practices for SAP BPC implementations? Sign up for one of our webcasts!