SAP Quality Management (QM) module health checks act as an important part of successfully running SAP QM. Those of you who are in the middle of QM implementations may start to feel like you finally have what you need to ensure your go-live will be successful, because you are relying on facts, not hope. Those of you who are already live can tell how well your QM module actually runs. In many cases, you can obtain the information you need for the system to start running correctly. 

Several years back a client called me in to fix a few problems in QM. The client felt these problems were the only issues at hand and believed the rest of the module was running well. The first thing I did was run the QM daily health check. What I found was that the module was not only running poorly, but was one of the worst QM systems I had seen to date. On top everything looked fine, but underneath they had a mess that could only be seen by the QM module health check reports.

Later I found that the additional troubles that the reports had identified were legitimate. This client needed to fix many more things than what I was called in to handle. It was painful, but if the client had run QM module health check reports during its initial go-live — or at least started the reports after the go-live —the client could have fixed the problems years earlier. Then the client would have obtained true benefits and accurate reporting from the QM over the years.    

I discuss the three main types of health checks: 

• QM go-live health checks
• QM daily health checks
• QM monthly health checks

I cover the majority of the information and concepts in the QM go-live health checks section because they are applicable to all three sections. I only point out the differences in sections about daily and monthly health checks.

Go-Live QM Health Checks

Many projects head towards go-live with testing, training, conversions, and authorizations, but conversely have no plan in place to ensure everything runs properly during and after the go-live. Project planners base the success of the go-live on the number of issues reported, but this does not always mean the system runs or reports everything properly. Major issues may surface long after the project team is gone. 

Typical Go-Live Support Scenario

In a typical scenario, most projects go live by focusing on an “issues list” (Figure 1), which can differ drastically from what is really happening. The go-live can be a few days into progression with no or few issues being reported. However, if planners run proactive reports, the reports might indicate problems that aren’t evident. These reports might also show who uses the new functionality or who is still holding back and may need more training. Early into the go-live, transactions may fall behind and bad habits might take hold. 

Figure 1

Typical go-live support scenario

Preferred Go-Live Support Scenario

Planners need to work on the go-live health check reports and related checklist during the project realization phase and fully check the reports in the final integration test. Because the final integration test cycle is a rehearsal for the go-live, you should include all the real steps in the test. 

The reports and checklist are different for each project because new functionality differs per project. Also, how to run each report differs, so it is important to use various settings until you find the correct settings to fit your needs. You may need to set up report variants (i.e., saved settings) so the users know exactly how to run each report to ensure consistent runs.

By testing this preferred approach (Figure 2) in the realization phase, the team is ready to run the proactive reports from the first hour of go-live through the first couple of weeks. The number of reports to run tends to be from eight to 15, depending on the functionality being implemented. By running these reports, you know the hour-by-hour heartbeat of QM. 

Projects that use go-live checklists have fewer reported issues because reports run during testing pick up problems sooner.

Figure 2

Preferred go-live support scenario

Example of a Go-Live Checklist

Set up a health check checklist template that organizers can use to check and sign each time they run a report. This template helps confirm everyone involved is following the process. For the first month of a go-live, file the templates in a booklet for easy reference. Figure 3 is an example of a go-live QM module health check template. It includes the transaction, description, comments, what to measure, and a place to enter initials. You can use any format for your template, but it is important to make the template clear so people can easily and consistently follow it. 

Figure 3

Example of a go-live QM module health check checklist

Table 1 shows examples of reports on the go-live QM module health check template from Figure 3. There are many more reports depending on the functionality you implement. Be sure to understand the reports available so you can choose the best ones to add to your checklist.

Table 1

Partial list of QM module health check reports

Figure 4

Example of a go-live QM module health check checklist

Figure 5

Example of a missing inspection plans report

Daily QM Health Checks

The normal transition time from go-live QM module health checks to daily QM module health checks is two weeks or less, depending on when the system is fully stable.

The main differences between the two health checks include:

• You run the reports on the checklist once a day for daily checks instead of several times a day for go-live checks
• You run several reports with dates to look at aging for daily checks instead of just looking at the current date for go-live checks. Running the reports with back dates to investigate aging may show inspection lots that fall behind or are missed altogether.

Also, with daily health checks, you don’t monitor as closely the goods movements and production order releases because basic integration triggers are likely working fine by now (this is one of the milestones for switching from go-live to daily checks). Such close monitoring is important during go-live because it is the only way to know when a QM process should have triggered. However, after a successful go-live, those processes are proven, so you can remove those transactions from the health check checklist. 

Once you start running daily health checks, you will always perform them from that point on. This ensures you remain proactive and aware of how well QM runs. The daily health checks reports only take five to 10 minutes a day to run.

Many of the reports on the daily health check template are the same as the go-live health check template. Some reports run twice — for example, a report runs just for that day’s activity and the same report runs again with aging dates to see if items are falling behind. By running reports as aging in all key functionality areas, you can confirm whether people are following processes or steps. 

To run the reports as aging, clear the from date and use a date in the past as the to date (Figure 6). Use transaction QA33 or follow menu path Quality Management > Quality Inspection > Worklist > Inspection > Display Data. The Lot created on field in the first column is blank and the to date is 30 days back, which in my example is 11/03/2010. That shows you everything that was created 30 days ago or before, and any open inspection lots on the list are suspect and need to be checked.

The date in the past differs per company. The length of time for an inspection or defect resolution differs per company.

Figure 6

Inspection lot selection aging report

Monthly QM Health Checks

The monthly QM module health checks template uses some of the daily health checks’ reports along with several new ones. The reports brought over from the daily health check template change because instead of running them as aging, you now run them with a date range to see how the month went. This step gives a sense of good and bad trends and how they compare to business initiatives or process improvements.

The new reports come from the QM Info System (i.e., the summary-only report system). These are the reports that only show monthly totals. You can slice and dice the data in many ways, such as creating graphs or sending it to spreadsheets. You can get to the QM Info System in a couple of ways. One option is to go to the bottom of each of the submodules under QM. For example, you could follow the menu path Quality Management > Inspection Processing > Info System. You can also reach it through a common area for information systems such as the menu path Logistic Controlling > QM Information System.

Table 2 shows examples of some reports on the monthly QM module health checks checklist.

Table 2

Partial list of monthly health checks reports

The transactions within the QM Info System reports run much the same way, as the transactions feature many similar settings and options for running. They use different tables but the initial screens are the same and the way you manipulate data is the same. Once you learn one transaction well, you can run them all. Figure 7 shows an example of QM Info System Report MCXX, which addresses defects by material.

Figure 7

Defects by material report

Doug TenBrock Sr.

Doug TenBrock is a senior QM/MM consultant with Enowa with 15-plus years of SAP project experience. His experience includes 17 full life cycle projects, project management, and the integration of all SAP modules. Doug’s industry exposure includes chemicals, pharmaceuticals, food, bio tech, health care, and high tech. The knowledge that he has gained from the diversity of the projects worked on has helped him create tools for streamlining system development, effective training of users, and assistance to colleagues in system problem solving. Doug is a team player who ensures that all modules successfully cross the finish line together.

You may contact the author at tenbrockd@msn.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.