Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
philip_kisloff
Active Participant
0 Kudos

I’ve decided to create a series of blogs based on the RunSAP training course I attended in Walldorf over the four weeks before TechEd08. They won’t pretend to be a complete overview or even a partial look at some areas. They are the result of my personal attempt to make sense of what was very intensive course. While they focus on some core learning points, I’ll feel free to drift off into other areas I found interesting. Hopefully, they will help orientate anyone wishing to learn more about this extensive subject, at least as a place to start.

 

What did I know about RunSAP before the course? That it is a methodology, the operational version of ASAP implementation methodology; that it is built around Solution Manager, and some other tools; that it covers software logistics, the monitoring of business processes and “Root Cause Analysis”; and that it’s SAP’s answer to supporting complex landscapes.

 

That final point is worth elaborating. While SAP knows business processes very well, it cannot be expected to support what ever solution a customer designs using all the available components at the customers disposal. The complexity is too great for SAP to resource for their entire client base. SAP can, however, provide the tools, procedures and skills for customers to take on some of this work themselves. If the customer does this, they will be happier for being able to manage their own issues much more quickly. The methodology to allow customers to reach this place is called RunSAP, and the focus is not the “implementation” of SAP software to ensure Go-Live turns out right, but on the day-to-day “operations” necessary to ensure reliability every day afterwards. The term I learnt that is used to describe RunSAP’s focus is “End-to-End Solution Operations”.

 

Before I talk about the tools, there must first come an explanation of the key processes that must be adopted, called E2E Solution Standards. This is of capital importance because the danger of ignoring the process is the same reason why some ERP implementations failed in 1990’s to deliver on their business case (and, I presume, since then as well). These failed implementations generally had one thing in common: they considered themselves as delivering only a technology change, instead of realising that organisational processes had to be adapted too. It’s a mute point, so I’ll simply assert that technology in itself does not bring benefits, only process change enabled by technology.

 

The E2E solution standards have been grouped around core capabilities: eSOA readiness, change management, root cause analysis and business process integration & automation. These divisions are useful for planning a RunSAP implementation, as not all capabilities can be realised at once, but some are required to exist together. The E2E solution standards consist, amongst other things, of key processes assigned to organisational stakeholders. The parts I want to talk about in this blog are the key processes and how the ownership is assigned between different parts of the business and IT function.

 

Let’s start with the stakeholders, as shown in the organisational model below (Figure 1). The first thing to say is that a company will almost certainly have essentially the same roles in place already, albeit with different names or merged boundaries. This is OK, so long as the individual responsibilities are clear: the organisational model for RunSAP enables assignment of responsibilities for using the standards and tools, more of which later.

 

Figure 1.

 

The Organisation Model is split between the business and IT, naturally enough, but also goes further in flagging those roles that can be “out-tasked” (ownership retained) and “out-sourced” (ownership transferred). The owners are the business process owners (champions) and the project oversight committee (PMO). Within IT, the business process operations are staffed with business process experts, with accountability for operations lying with application management. To fully understand the responsibilities and standards, we need to look at it working in a practical example for Business Process Monitoring (Figure 2).

   "

Figure 2

 

In this work process, a problem is reported either by an end user to a key-user, or by the Solution Manager monitoring tools to the IT department. In either case, the business process champion is informed, and if the problem cannot be handled within normal procedures an incident is created and then, after diagnosis following the Root Cause Analysis (RCA) standard, any required changes to the system is handled by the Change Control standard.

 

So you can see a day to day operational procedure have been described in this End-to-End Solution Standard. The standards also describe parts of bigger standards, and the interaction between the various stakeholders. The standards are stored in the SAP Service Marketplace, at http://service.sap.com/supportstandards. Pleasingly, these are not like ordinary standards, but really are very readable and give a good overview of the RunSAP methodology. If there is one problem, it is that and that is some single documents describe different standards assigned to each stakeholder involved. At the time of writing, the standards are undergoing revision, but Figure 3 should make clear which standard is owned by which stakeholder.

 

 

Figure 3

   

Some points to note:

Since writting this blog, Testing Management and System Monitoring now have their own standards.
4 Comments