Insights

Do you feel the pain of change? Part II - Solution documentation

13 Dec 2011 Project Management & Methodology, SAP Solution Manager, Consumer Business

In Part 1 of this blog series I discussed how SAP Solution Managers Business Process Change Analzer can be used to reduce the pain of change impact analysis. Here I'll look at how we can maintain our solution documentation during change, and the final blog I'll look at how changes can be tested.

The pain of change

One of the 'simple' aspects of making a system change is the actual execution of the change.  For example how long does it actually take to implement a new Enhancement Package for SAP ECC 6.0? I've  have always seen that the actual time to perform the technical work is a small percentage of the total project duration, and this is because it is often a complicated process to identify the change impact, plan and create solution documents, document and execute our tests.

It's always been a key challenge to understand which business processes are impacted when a support pack or enhancement pack is introduced.  As discussed in the first blog we can use BPCA to identify the business processes that are impacted by change.  But once we know this we then need to understand which documents need to be updated, and where these documents can be located.

For many organisations solution documentation can be located across multiple systems, databases, or even a combination of manual and electronic mediums. A good example of 'documentation pain' can be seen within organisations that insist a new "project team room" is used to store documentation relating to the project.  The result is often that a team room will be used to store documentation relating to the solution, for example a blueprint document, technical documentation and even test documentation.  After some years the organisation can be in a situation where they need to look in multiple team rooms to find the documentation relating to a business process that is going to change.

Solution documentation

Within SAP Solution Manager we have a Solution Directory.  The Solution Directory is often seen as the heart of the application because it is the basis for many SAP ALM processes.

The Solution Directory documents our productive solution landscape.  Within the Solution Directory we can document our business process hierarchy, blueprint information, configuration and development objects and our test documentation to name a few.

During each project we can use SAP Solution Manager as our storage location for all our documents. This would typically include our business requirements, business blueprint, test cases and other project deliverables. This documentation is process orientated, meaning that the documents are assigned to a business process in the business process hierarchy.  At the end of the project we can move our Solution Documentation to the Solution Directory.  This then provides a central location to store our solution documentation that reflects the productive use of the system.

When we identify the business processes that are impacted by the change we can then use a maintenance project in SAP Solution Manager to check-out documentation in our Solution Directory so that it can be updated.  This can be completed on a process by process basis, meaning that one or many processes can be checked out so that they can be updated.

Once the updated documentation has been released, and the change implemented, we can check-in our modified documentation. This ensures that our solution documentation is always current.

So our first pain point was to understand what has been impacted by change, and we have the BPCA that can tell us this.  Next we need to update all our solution documentation, and we can use the Solution Directory to store the documents, and control the on-going maintenance.

So in the final blog in this series I'll look at the process of testing the change that has been identified and now documented.