QM/Characteristics/Specifications/Classification – Blog 1

QM/Characteristics/Specifications/Classification – Blog 1.

This is the first blog of a series of blogs and documents I intend to write and post.  The series of postings will attempt to explain the relationships and issues with how specifications are kept in SAP and in particular how batch management is impacted.  Or probably more accurately how batch management affects QM.

I’ll not only include the technical process around this subject, but I’ll try to provide some functional information around these processes.  The how’s, the why’s, the pitfalls, the benefits, the pros, the cons, etc…  I’ll also try to provide some real world examples of how certain techniques can be used.

I also hope that other QM experts here will chime in with their own comments.  I will take all comments constructively and will make every attempt to correct or update the blog/document where necessary.  For those experienced QM folks, please have patience with these blogs.  A lot of these blogs and documents will be old stuff to you.

But hopefully you can comment and add to what is presented. 

So, to begin this series, I think some background knowledge should be covered.  One of the first things that I think is crucial to understanding these QM processes is understanding the relationship between Master Inspection Characteristics (MIC’s) and General Characteristics, (GC’s), You may find SAP documentation as well as consultants or clients referring to general characteristics as batch characteristics, or class characteristics.  In this series of blogs and documents I will use the term general characteristics.

The first key concept to understand is that MIC’s are only known to the QM module in SAP.  General characteristics are used by all other areas of SAP.  With only a handful of exceptions, QM does not really know about GC’s. Why is this?  To be honest, I don’t know 100% for sure but I’ll give you my thoughts on this.  Maybe a true SAP historian can comment and let me know if I’m right or not.

In any case, the QM module pre-dated the classification system. I believe classification was introduced back in 3.1, I think with the 3.1F version.   I’m going to guess that classification was developed by an SAP customer/third party firm and then bought out by SAP and added to SAP. That’s a total guess however.  In any case, you have to remember that SAP was at the time, a business system.  It wasn’t designed as a full blown LIMS.   It was to provide the basic laboratory functions to support the business.  The QM module wasn’t really meant to do much outside of collect final product test results, provide a certain amount of in-process testing and control, and allow a formal way to release product and print test results on a certificate to support the required SD documents.  It’s grown a lot since then!  There was no batch management and quality and testing was mostly plant centric.  So MIC’s were plant centric data.

With the release of batch management and classification, there came a need to get QM test data into the batch record.  Batches were designed to use general characteristics, and since by definition, batches can only have one current test value for any given test, they had to figure a way to get QM and Classification to integrate somehow.

I am sure there were a ton of design meetings and I’m sure many things were considered.  But for better or worse, the infamous linkage between MIC’s and GC’s was created.  A field (ATINN) was appended to the QPMK table and the marriage was made.

Now since GC’s are really client level data, and MIC’s are plant level data, this now impacts the QM design.  Since only one MIC can be assigned to one GC this can cause some problems.  If you have a MIC, say VIS003 in plant 1000 and VIS003 in plant 1001, you cannot assign them to the same general characteristic VISCOSITY. 

Typically, (BTW: for future reference that’s my way of saying that nothing is absolute, and somewhere, there is probably a valid exception but you really, really want to avoid the exception), you do not want to create multiple general characteristics to match up with multiple MIC’s across multiple plants.  If you think you have this need, go back and think it through carefully.  Think about how batches work, the batch level you use, the transfer of material between plants, to distribution centers, to consignment stock, how the production chain works, producing certificates, using batch determination, batch derivation, copy inspection results, etc…  You’ll hopefully see that it would be a bad idea.

Fortunately, SAP allows us to share MIC’s across our inspection plans and tasks lists.  Doing this does allow us to  minimize the number of MIC’s required.

So, define a master data plant.  Even if you’re on a small project and only have one plant, make sure you design from the start as if you have more than one plant.  Define the one plant as your master data plant up front.  Have it recognized as part of your design documents as the master data plant right from the start.  You might even suggest creating a virtual plant just for master data. Other modules often can find a master data plant valuable. 

If you are in what I call a silo’ed business, whether for practical reasons, (GMP reason),  or political reasons, (I don’t want people seeing my data), a virtual plant allows you to provide appropriate users access to the virtual plant, without giving them access to another plants data.  If you have two or more very disparate businesses working in the same SAP client, you might need to have two or more master data plants.

In lieu of having a specific virtual master data plant you might consider using a “plant” that was only set up to be used as a corporate location or sales location.

In any case, hopefully now, your design has all the MIC’s created in one master data plant, and each MIC will be linked to one and only one general characteristic.  This is important as I will be basing the remaining blogs on this concept.  At appropriate places I will try to point out what issues would happen if you used a multiple mic’s across multiple plants design.

Ok… this is probably a good stopping place.  The next blog of the series will discuss the impact of linking MIC’s with general characteristics and some of the more technical issues associated with the linkage. It will serve as a basis of how specifications are maintained.

Next Blog:  http://scn.sap.com/community/erp/operations-qm/blog/2013/10/03/qmcharacteristicsspecificationsclassification-blog-2