BBP phase – Can it be Avoided or Compressed?
In this blog I am specifically going to talk about a variety SAP project in which I feel that the necessity of BBP phase can be called into question.
Recently I was part of a project that can be described partially as SAP instance consolidation and partially a greenfield implementation as it had both. Like a typical SAP project we went the through all the phases starting from Business Blue-printing, Design, Realization etc. But hind-sight tells me that the BBP phase has not been of any great value as the goal of the project was to move from SAP 4.7 instance to ECC 6.0 which is already existing with minimal business process change. While the greenfield part of the project does require BBP, but it was a small portion and I feel it could have been handled as part of Design phase itself.
I see the following are some of the important outcomes of a BBP phase
- Clients business processes are throughly reviewed, analysed and documented?
- As-Is and To-be business processes are documented and proposed/reviewed and frozen.
- In-efficiencies in the existing business processes are identified and acted upon for removal in the To-Be process
- Obsolete requirements are identified and the relevant aspects are eliminated in the To-Be process
- Identify and ensure that all stake-holders are part of BBP and their views are discussed, reviewed and appropriate action is taken on special requirements
- Prepare a platform for successful business stake-holder participation right through the project
So if BBP is not there, the major issue will be missing of points 5 & 6. Can these two be achieved in the design phase itself. My experience says that it can be achieved by having appropriate planning of the design phase involving a sort of business process review as a first activity.
Since the goal of the project is to keep the As-Is & To-Be process same with zero to minimum change, elaborate BBP phase running into 8 to 10 weeks to cover all the areas of project was not at all required. A compressed BBP phase spanning to say 2 weeks would have been ideal as there is a bit of greenfield implementation is there in the project scope.
What are the risks of such compressed BBP?
- Not enough time for detailed study of the the As-Is process
- Increases the probability of surprises later in the project which can turn out to be a drag on timely completion of project
- Existing in-efficiencies may continue in the new system too
While these risks are valid, but I think these can be mitigated in the design phase by focussing & achieving enhanced business key-user participation in the project. My experience has always been that the more the key user participation is achieved in the solutionizing phase, easier becomes UAT and sign-off