uncover hidden qm problems using health checks.pdf

SAP supply chain concepts, technology, and best practices

Account | Log Out | Help

Search the knowledgebase | Advanced Search

Home • Article Index • Sample Articles • Advisors • Pricing • Contact Us Subscribe/RenewPricing

Share |

Best Practices, Implementations, Upgrades, and Migrations, Quality management, Reporting, SAP SCM

Uncover Hidden QM Problems Using Health Checks

by Doug TenBrock, Sr., Consultant, Enowa Consulting • January 19, 2011

Save time and money by knowing the health of your Quality Management (QM) module with SAP QM

module health checks. By running health check reports, you are able to avoid a costly rework of

processes because the close observation of the health of a go-live allows for quick adjustments if

needed; roll off consultants, if you are using them, sooner because you have the tools to support a

go-live; know the actual health of the modules; and solve issues without outside help.

Key Concept

Quality management (QM) module health checks involve running a set of standard SAP reports that identify if your QM module is operating smoothly. These reports show how well the users understand the processes, how well the master data is set up, if data is being closed out without problems, if processes are falling into the cracks, and if there are trends that should signal warnings.

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.

Note

Although this article focuses on QM module health checks reports, all SAP SCM modules should run health checks and all power users should be familiar with the inner workings of their modules.

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.

Note

QM module health checks apply to all SAP versions.

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.

Share Resources by Consolidating Warehouse Operations in a 3PL Model (Part 2)

•

Share Resources by Consolidating Warehouse Operations in a 3PL Model (Part 1)

•

Improve Runs for Products with Recurring Time Constraints Using SAP APO SNP

•

Simplify Shop Floor Sequence Optimization with a PP/DS Exception-Based Setup Matrix

•

Capture the Variable Scheduling Time of Operations in Process Order Scheduling

•

Better Inspect and Maintain Your Critical Equipment with SAP PM and SAP QM

•

Quick Tip: Use SAP APO SNP to Improve Runs for Products with Recurring Time Constraints

•

Uncover Hidden QM Problems Using Health Checks•

Making the Grade: How Bayer MaterialScience Boosted Supply Chain Performance with a User Certification Program

•

How to Protect SD ALV Reports from Unwanted Changes

•

BI Expert Financials Expert HR Expert CRM Expert Solution Manager Expert GRC Expert Project Expert SAP Professional JournalSCM Expert

of 7SCM Expert - Uncover Hidden QM Problems Using Health Checks

01/03/2011http://www.scmexpertonline.com/article.cfm?id=5642

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.

20 Carematrix Drive, Dedham, MA 02026, USA. Sales and Customer Service: 1.781.751.8799

Copyright © 2011 Wellesley Information Services. All rights reserved.

SAP and the SAP logo are trademarks or registered trademarks of SAP AG in Germany and several other countries.

Insider Learning Network Resource Centers Conferences and Seminars SAP PRESS

Publications and Knowledgebases Multimedia Training About WIS Press Release

Contact Us Help Sitemap



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 missing inspection plans report



Figure 5 Example of a new inspection lots 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.

Note

It is important to assign someone responsibility to run the daily QM module health checks and to report back if there are any issues. This person is normally a quality department QM power user.

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 is a senior QM/MM consultant 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 him via email at [email protected].



uncover hidden qm problems using health checks.pdf

Documents