Skip to Content

Hope you all aware some time before I dumped few discussions about Business process blue print implementation and maintenance in solution manager (http://scn.sap.com/thread/3149836, http://scn.sap.com/thread/2153935) , there are some good responses I received from the experts, but I was not satisfied, seeking the real purpose of this functionality. The queries raised from my current client make me to go deep on this blue print area. Since from the time when I got the SM100 training, I just thought Business blue print is about the Tcode Solar01, Solar02, where we store the details of business processes. I also aware it is the basic pre request for other solution manager functionalities like BPMon, BPCA. But in real world needs more from solar01.

We had a requirement for implementing critical business process monitoring and BPCA. The story begins on when I introduced Business process blueprint as a documentation tool to my immediate boss. Subsequently we planned to sell the business process blue print functionality to our customer.

With the same perception, I had given a presentation to my clients, alas!! They were not satisfied. Business blue print has the other meaning in the real world especially for the customers who already implemented SAP, Just looking for a way to document their entire business process. They want to maintain complete bible for their business processes. Their concern is not only getting transparency and the long time maintenance of the business process.

How and who will maintain this business process blue print. I showed the use of Solution manager document assistant and Latest 7.1 Reverse business process engineering. But the Unanswered question is how I can maintain the documentation of business processes after the implementation.

If we look into the business process lifecycle in solution manager, from initial template project to solution it gets reused by upgrade/maintenance project or other solution manager capabilities. How can I maintain the transparency and integrity of the business process, which is changeable in quite often by the ongoing maintenance project? They afraid about what if the people not maintained blue print properly? Still there are lots of customers afraid on this, and not ready implement Business processes blue print.

Motive of this blog to reveal the implementation and maintenance part of business process blue print.

The plan we had taken is very simple, I referred the below guide which gives the view of business process long term maintenance for Global template scenario

https://websmp109.sap-ag.de/~form/sapnet?_OBJECT=011000358700000910652011E&_SCENARIO=011000358700…

But we dont have global and local rollout template scenarios, our case quite tricky where each locations are interconnected, Plant in India connected to the Plant in German or plant in other production unit. Finally I plan in this way,

  1. Start one fresh implementation project as business process bible which documents all the business process. Once all Business process gets captured, I lock the blue print and configuration, so that my initial project is no longer editable even by mistake.
  2. I imported the project to my solution, considered this as Productive or going to act as bible for my entire business process in future. Later I activated check in Check out. Hence my solution is no longer editable without prior approval.
  3. Now in future for maintenance, we plan to create a new maintenance project with reference to your productive solution, but we end up with other challenge is what about multiple maintenance projects run at a same time. Create multiple maintenance project with/without reference to the solution based on requirement, Do the changes in the business process structure, or create new business process.
  4. Once all the maintenance projects rolled out, the so called governance team collect the changes from all the projects. They will governance our productive solution where all necessary document (eg. Business blueprint which inclusive functional and technical information) are updated to the latest.
  5. Governance team creates one long term maintenance project and assign to our productive solution.
  6. Later they check out the respective business process nodes from the productive solution for maintenance. Do the changes in the business process structure, or create new business process based the multiple maintenance projects done before.
  7. Once all the changes are updated into our long term maintenance project, request for Check in, which finally copy the changes back to the solution. Later you can use our productive solution as the basis in Business process Change Analyzer, BPMon or other solution manager functionality.

bpb.JPG

Through this blog I shared some possibilities of how we can implement business process blue print and maintain its integrity in long-term.

I have still some doubts on solar01 organizational units and master data with regards to the testing. This is still open query here http://scn.sap.com/thread/3169612

I would like to hear more real time ideas and experience from you all, how you are maintaining business process blue print in your places in the effective way.

Please share your views.

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Raquel Pereira da Cunha

    Hi Jansi,

      I faced the same situations as you in many customers. In most of the cases they already have SAP in place but missed the documentation of their business processes and want to have a better control of it, especially when it comes to use the other ALM processes such as Business Process Monitoring, BPCA, SDA or when they will start an upgrade and want to use the productive business processes as the source of a new upgrade project.

      None of my customers for whom I worked with documentation of business processes was using the Solution Directory when I started there. In most of the cases they already have a initial implementation project which they want to use as the main repository, or in some cases a template project. In both cases I instructed them to first structure all the business processes in SOLAR01 and detail in SOLAR02 with all the scenarios, processes and processes steps, with the corresponding documents, transactions, IMG activities, Configurations, Developments, Interfaces, document as much as they can in such a way that anyone later will be able to easily find a process node or a document or an object such as a transaction code in a search. This is a hard work for customers with SAP Solutions already in place when no standard SAP business processes were used as the source (and this is the case in almost all the customers where I worked) and when nothing was documented during the implementation projects. But after it’s done, it’s much easier to maintain.

    Once they have a complete business process structure I use to instruct them to do just as you did: lock the structure and hand over to a Solution, and use check-out/check-in to one maintenance project when the structure has to be changed. In some cases I suggested to have one maintenance project only to control changes in the business processes structure separated from the daily basis maintenance project(s) used for urgent and normal (and other customized corrections) because some customers create different maintenance projects for each different SAP Solution, such as one only for ERP, another one only for CRM and so on, and  when using normal corrections they may need to have different development, test and go-live phases for each SAP Solution, or have some improvements or implementation of new business processes considered as a maintenance project and not implementation project and want to control it with normal corrections.

    Keep the Solution and the new projects created using the Solution as source synchronized is not so easy, but you can use the Compare and Adjust functionality to help you find out what was changed in the successor and predecessor (not the content of documents of course).

    Maybe there is a better way to do it, but my experience it’s very similar to yours.

    Best regards,

    Raquel

    (0) 
  2. Ganesh Janakiraman

    Hi Jansi,

    As always, this was a very interesting article.

    I’ve got a question about point #4 mentioned above.

    Where you say the governance team collected data from other projects. How did you manage to transfer the content from these separate (not linked to solution I’m assuming) into the Solution. Was it a manual process? Compare and Adjust?

    Furthermore what I’m proposing is that all projects that need to edit any structure in the solution work off a single maintenance project. They will follow the check-out\check-in process. This is the only elegant\ non tedious solution that I could come up with. 🙂

    Looking forward to your response.

    Cheers

    Ganesh

    (0) 
    1. Jansi Rani Murugesan Post author

      Hi Ganesh,

      It is okie, that we can edit the structure with single Long term maintenance project…

      in real world like, people are maintaining separate maintenance project scenario.. the idea behind is, just dont want to mess up with lots check in check out cycle.. furhter in this case we need train every one to use check in checkout.. we just tried to avoid this by clearly defined the central control in long term maintenance project to the limited ppl.

      this is also posible and the suggestion..

      Regards,

      Jansi

      (0) 

Leave a Reply