Maturity Model 

Installing SAP Solution Manager with a purely technical view of the product may not result in the full benefits being realized. To a degree, configuring the various capabilities whether aiming at cleaning up the custom ABAP repository, or attempting business process monitoring will yield results. 

However, experience has taught us that in order to truly position SAP Solution Manager as value adding component in the IT strategy, there needs to be a defined path with some sort of feedback loop to ensure that steady and constant progress is being made as the various capabilities of SAP Solution Manager are deployed, adapted and finally adopted. Having a roadmap is only one part of the process. Tracking and maturing that roadmap is often overlooked. Hence the Maturity Model. 

A typical Maturity Model is based on the concept of a growth or improvement path that relies on grouping activities or statuses into levels that are traversed as the path is followed. For example, in a pyramid set-up, each higher level builds on the strength of the lower levels. 

Assuming you start at the lowest level, certain qualifying criteria are identified together with activities that need to be performed and evaluated before progressing to the next level. Typically, before applying a Maturity model to a real life context, some sort of assessment is carried out with the prescribed context to identity whether or not the satisfying criteria for the lower levels have already been met. This sets the starting level or, identifies the gaps that are needed to satisfy a particular level in order to progress to the next. 

SAP Solution Manager’s Maturity model is no different. It does however have an additional dimension and, depending on the scope of the implementation, there can be multiple instances of the Model being applied at any one time all traveling at their own pace. 

Maturity Model Layers 

In the case of this Maturity Model, the layers are as follows: (Starting from the lowest) 

Layer 1 – Platform Readiness 

The first layer being the technical foundation is probably the most important. If the system is not setup correctly, or is missing key configuration steps or notes, there is a strong possibility that the addition of later functionality will either be flawed or not operate as designed. 

Trying to build the required capabilities on a shaky foundation only leads to frustration with the product, and often, with the engaged partner. 

There is no need to configure for every capability in order to start the build for any one required capability, however, the fundamentals do need to be put in place, as the integrated nature of the product requires that some overlap configuration must be completed properly. 

Generally, the technical readiness level is reached once the system is able to provide the ‘First Output’ for the required capability. Once this output is created/generated/visible, we can move to the next level for these specific capabilities. 

This first level will be re-visited when the next set of capabilities are identified and their specific journey through the Maturity Model is started. 

Layer 2 – Visibility 

The objective of the second layer is to consume and examine the outputs from the system. The idea here is to gain insight as to what the system is doing in its current state. Depending on the capabilities being deployed, this information ranges from the Early Watch Alert Reports to Business Process Analytics exposing a view of the technical landscape to the process behavior respectively. 

Gaining access to all this output empowers the respective teams to interpret the information and get a better understanding of what is ‘normal’ for the systems. Whether it’s acceptable or not is another question. However, with the new knowledge gained, action plans and activities can be planned to hopefully improve the status quo. 

Layer 3 – Stability 

Once visibility has been gained, we now move to driving for the stability of the SAP landscape. Depending on the outputs generated and consumed during the visibility phase, some sort of direction should be chosen to focus on the items that need to be attended to in order to enhance the landscape stability. 

Sometimes the work effort to solve a larger problem that has been exposed is too great to be accommodated in the current time frame or budget. This is acceptable, at least the awareness is there, and proper planning can be done to address this issue in the near future. (Assuming it’s not too critical). 

Generally, the trend here is to aim for the ‘low hanging fruit’. Aim for the adjustments that require very little effort or create minimal disruption, but make a significant step towards stabilizing the landscape. These adjustments can range from system parameter changes to creating a more structured change and patching cycle. 

We have often seen that making these, sometimes, minor changes, have had a significant knock-on effect and eliminated other performance issues that have plagued the landscape. 

Layer 4 – Performance 

Performance. All operational manages want their SAP systems to run as fast as possible and give the user a very responsive experience. Maybe one day we will all experience instantaneous and possibly predictive computing. But until then, we do what we can to make SAP as pleasant as possible. 

The line between stability and performance is very blurred, as changing parameters for stability can influence the performance in a positive way. Making changes to enhance performance also contributes to the SAP system’s stability. 

Depending on the capability being deployed, adjusting the system and re-analyzing the outputs, takes us all the way back to the ‘Visibility’ layer and could even force a re­alignment of the chosen capability roadmap. 

Generally, when speaking about performance, we can group it into two main areas: Technical Performance and Transaction or Business Process Performance. 

There is a dimension to Business Process performance that is sometimes overlooked. Typically everyone looks at what the current real-time performance is. This is typically the response time and it is most visible from a user perspective. Striving for good response times will always be a priority and the technical monitoring capabilities of SAP Solution Manager offers significant insight. 

The other dimension is the efficiency of the Business Process. Here, the backlog and throughput statistics of the generated business documents can be analyzed and monitored. The identification of incomplete end-to-end (E2E) processes, stale documents and unacceptably long E2E lifecycles. 

The identification of these items can lead to a more focused attempt at improving the process at an operational level to prevent stale or incomplete processes etc. and possibly even leading to adjusting the process to be more efficient and thus improve the overall process performance. 

Layer 5 – Governance and Control 

The final layer in the Maturity Model is reached when, depending on the capability that has been matured, the chosen method of visibility has been identified from Layer 2 and the actions to ensure long term stability and ongoing performance from layers 3 & 4 have been identified. 

These key items are used to form the feedback loop to ensure constant monitoring and adjusting of the SAP Landscape. In order to assist with the adoption, these key items should be integrated into the policies and procedures of the respective users and capability owners. 

Although this layer is focused within the context of SAP Solution Manager and applying governance to its usage and adoption in the SAP Landscape, the visibility and subsequent actions can add substantial value to the overall governance of the business from the various risk and compliance frameworks. The various reporting and monitoring capabilities can be aligned to these frameworks and be used as supporting content to assist with the necessary compliance monitoring. 

Share This