Multiple Specifications in QM

[former_member42743]

I've been wondering how the whole multiple spec functionality in QM has been received and how folks like it or don't like it.

I helped implement this at one chemical firm a few years back.  Since then I believe they have had mixed feelings about it.

I've been told that the maintenance of the specs is a real pain and the learning curve difficult for people that have to learn it due to normal employee turnover/promotions etc.

There were also some issues with LIMS integration, in particular getting the qualitative characteristics for customer specs to properly valuate and close when transferred from LIMS.  From what I understand, SAP has been slow to offer any solution.

One of the things it also results in is that all plans have to be managed using the workbench (CWBQM) which in and of itself can have a steep learning curve.

Another issue was that it could only use copied characteristics and no reference characteristics.  This thus forced all material specs to be maintained fully in the plans. Something I've never personally been a real fan of.

But at the time, and given the requirements of the project it seemed like the best solution.

So now that it has been available for awhile, I'd like to hear some other feedback from people and firms who have implemented and used it for awhile. Or from folks that recently decided to implement or not implement it and why they choose the route that they did.

My goal is to write a series of blogs on the multitude of ways that product and customer specifications can be handled in SAP.  There are a number of them and I think few people, (including many consultants), really have a strong grasp of all the various approaches.  Most seem to have a certain way they "like" and it usually relates back to what they were taught or shown first!  But as we all know, one solution never fits everyone.  I have my own thoughts as to what I think is "ideal" but I try to realize not all companies can do it that way.  I try to provide a few viable options  with the given pros/cons of each and let the client choose a particular path. 

So for this discussion.. lets hear your thoughts on multiple specification functionality!!

FF

[Martin_H]

Hi FF,

I have not implemented multiple specifications so far. So i can only tell why I did not consider this, not if the users/I like using it or not 😉

What I see as the biggest issue is the copy thing of characteristics. I am a big fan of centrally maintained (reference) MICs, and SAP is already not good on this with forceing one to use at least a dummy plant for MICs. As you write reference characteristics cannot used with multiple specs, which makes it hard to maintain the MICs then for the multiple specs.

The engineering workbench as a must for maintainence is a greater issue for users that are familiar with the "old" maintenance transactions. From my experience it is similar to the ME21 vs. ME21n switch. It is always difficult to make that transition for users, a good time I found is a release upgrade/system patch, where we just removed the "old" transactions completely from authorization roles.

Generally I feel that multiple specs would be great for usage in a global company environment, where you have the same MICs, but e.g. due to different measurement equipments might have different tolerances. Up to now I have to say that most users already struggle with implementing/understanding/using the basic elements in SAP (MICs, mat specs, inspection plans, sampling strategies), so multiple specs would definitly be too complicated to explain/keep up running at the moment.

Regards

MH

[former_member42743]

Martin,

Do you maintain unique MIC's for each material?  Or do you manage the specs via classes?  Since you are using reference characteristics you don't keep them in the plans.

Thanks!

FF

[Martin_H]

One approach I have promoted during some implementations is to have reference characteristics designed to be used globally (yes, could be grouped in classes), whereas some tolerance values are maintained in the material specifications. So to answer your question, if it is possible for a company I generally advise to have common, material independent MICs, and then to use mat specs to push material specific values into them.

Regards

MH

[former_member42743]

Ok folks.. this is Chemicals... I'm SURE there are more folks out there that have used or considered using multiple specs!!!!

52 views and only one response!?!?

FF

[Former Member]

Hi,

The main challenge in using Multiple Specifications in Pharma is to harmonize the MIC.

For Example an BP specification may have limits as 5 to 10 and USP specification 7.5  to 9.The

method in which they are tested is different. Since the testing method is different they have to test it

twice and a single MIC is of no use.

When I tried to convince a client to use a single MIC for BP,USP the client gave the above

explanation. Only for this reason multiple specifications are not much used.

CSN

[former_member42743]

Actually I tend to agree with the client here.  I usually suggest to the client the if the method differs, it should be a different spec. (except for when the method number is different but the actual laboratory steps are the same, like when two plants run the same test but use a different method numbering scheme in their plants). 

In your example you've indicated the method is different.  So I have to make sure that the proper method is used regardless of the spec.  Hence different MIC's.  Different methods can affect precision of the test and some methods are specific to certain types of compounds.

Now if BP had them run the USP method but only wanted a different spec range, then they could have used the multiple specs because the only thing different is the desired spec.

One of the other big issues with customer specs and using multiple specs is for planning and ATP.  As of right now, ATP has no way to take into account a customer's spec.  So you can't try to "plan" to a customer's spec and unless you use batch determination in the order, you can't determine with any certainty if you have material in inventory that matches THAT customer's spec.  And if you accept the order you must manually communicate to the planner's not to just make the material, but to make it to try to meet the customer's spec.  Which might not be easy in some cases.

Thanks for your reply!  Lets keep the discussion going!!

FF

[MarkoLange]

Congratulations to bringing up that topic which is I know a hot one for companies using SAP´s QM module. Recently we had a discussion within VCI QM working group (VCI is the German Industry asociation of the chemical industry) about how to manage product specifications in general. In that sense our topic was broader than just looking at multiple specifications. The outcome of that discussion was that there is not the one way to manage those. Some were using multiple specifications others were not - we definitely found mixed feelings about it again. But how did companies manage product specifications then? One approach is to have those outside SAP which is not a good one of course. We also discussed to make use of specification data base of EH&S module. Some were skeptic to do that due to organizational restrictions they saw within their company. On the other hand in many companies (mainly mid-sized) EHS and QM are belonging to same department. So why not making use of EHS-QM interface which was improved with EhP 5 of ECC6.0? We decided to have a closer look to this interface in our next working group meeting in fall this year.

How do you think about that interface considering the EhP5 enhancements?

[former_member42743]

Marko,  (warning... rant to follow! )

Thanks for the reply. I'm not a major fan of the EH&S interface so far.  It's very limited right now and doesn't allow taking advantage of many of the inspection plan features.  I don't think it's a bad idea, (yet), but I don't think it's been fully developed.  Plus, I don't think customer related specs should reside in E&HS.  Having the primary material spec is fine.  Along with a sales spec as well, (another huge area that SAP is lacking in).  Sales specs are often different that the manufacturing spec. Yet there really isn't a place for these either.

Since it sounds like you might be involved in these discussions why hasn't SAP championed the use of the condition technique for specifications?  It's already in place for batch determination and if companies have their own required specifications, these are often placed into the SD batch determination to make sure the customer gets the proper material. 

For one client we used these to incorporate customer specs onto the COA.  It simply required a new FM to be written for the "spec origin" selections in the profile.  This FM search the SD batch strategies for any customer specs and used those as the specs in the COA.

Why couldn't SAP use the same concept for inspection plans?  Surely it wouldn't be that difficult for the programers to do something similar where the inspection plan spec can be replaced with customer specs in a MTO scenario.  MTS shouldn't even have customer related specs in reality.

The REALLY big thing that is needed, especially for the chemical industry is to tweak MRP to somehow to take customer specs into consideration.  When looking at orders, it needs to be able to see if existing product inventory is suitable for the customer, and if not, then create a MTO planned order for that material/customer spec.  Then let the planner figure out what he/she wants to do when they convert the order.

Right now, SAP has THREE ways for handling customer specs,

- EHS

- Multiple specs

- independent specs

All have been adapted from customer implementations and third parties.  I really don't think SAP has done a good job at developing a long term strategy around how they think customer specs should be handled.  As a result we have a three approaches that all fall short in one way or another.  And they fail to address the reality that especially in the chemical and pharm industry we have a number of specs.

Material specs:  What we produce the material too.

Sales specs:  Specs that we use in sales and quotes to customers.  Often times these are slightly wider then the material spec we produce to.  These are also often the specs we want want on the COA, not necessarily the specs we manufacture too.

Customer specs: tighter or wider specs than we produce to.

Ancillary specs: These are tests that are never run but guaranteed for industry or governmental requirements.  These sometimes need to be on COA's or other documents.

And finally, SAP has never really come up with a unified approach  to deal with plant monitoring and testing. I.e. waste water testing, emissions testing.

FF

(ok.. I'm done my rant...)

[former_member42743]

************************************************

Right now, SAP has THREE ways for handling customer specs,

- EHS

- Multiple specs

- independent specs

*************************************************

I stated the above incorrectly. 

I don't believe EH&S handles any customer specs.

But my point is, when you look at how to handle any specifications, you have a number of ways to go. I didn't even touch on the all the permutations of batch specs, material specs, inspection plans by customer, by material, unique MIC's, etc, etc, etc...  In one way, this is good as we have a lot of choice now.  But I also think that we have all these choices because SAP never developed a high level, long-term plan as to how they wanted to tackle this messy situation.  As a result, we really have no "Best practice" when it comes to handling all the different specifications that we have to, especially in chemicals and pharma.

FF

[MarkoLange]

Thanks for the warning - not for the rant... As a figher fighter you are familar with heat and apparently we discuss a hot topic here. Not in terms of urgent needs -  I guess that customer have arranged with what they find - but in terms of general product strategy.

And with reagrds to that you describe the dilemma of every integrated system like SAP´s ERP  which is to find the right balance between consolidation of information and data objects and process standardization versus flexibility you have to give. Especially in the case of specifications we face the problem that specifications can stand and are used for many different things that are hard to consolidate. Having said that I do not agree with your remark that SAP has missed to have a good strategy about how to manage all the types of different specifications including customer specs. All the options you discussed came up at different times and had different surrounding conditions and purposes. They provide flexibility where you would love to have more consolidation but I think that consolidation of specification management is very much constrained. Not only in a technical perspective but even more in terms of business and organizational aspects.

However I liked your poste since it is indeed worth to think about where and how specification information can be consolidated and used for different purposes. And my favorite here is the EH&S specifcation data base since it has so many integration points with other ERP modules:

And of course you can think about maintaining customer specifications here as well. Especially given the fact that it integrates with SAP´s Recipe Development application since the typical R&D process in chemicals starts with an customer inqury specifying a certain technical demand. And the EHS-QM interface is another integration point. You and others were criticising that. But I have to state that it was improved with EhP5 and I look now forward to look at it in more detail within VCI working group for QM/LIMS in order to see whether and how it needs to be improved.

Kind rgds

Marko

[former_member42743]

Is the diagram you put up current state or proposed state from the working group your working with?  I can see a few EH&S courses in my future.

When I said they didn't have a strategy I'm referring to the development of QM over time.  Do they now?  Maybe. I'm not privy to the inner workings of SAP.

But EH&S was not developed by SAP originally.  It was a third party bolt on that SAP eventually purchased and took over.

Multiple specs was developed by I believe DOW and their consulting partner.  I'm not 100% sure on that.  But it was developed externally first by a customer. That was bought be SAP and implemented.

And of course they had the original SAP independent specs in the inspection plan.

If you are buying and purchasing external solutions, you are either changing your overall strategy as you see something you like, or you don't really have one.  I'm not opposed to changing strategies.  But in this case it has caused a numerous number of approaches to be available and most of them are lacking in some regard. 

And then we have the whole QIE system for the decentralized warehouse and other uses.  It has many limitations.  I believe that was also a purchased solution.

Will EH&S be the final, recommended solution?  I have my doubts at this time.  The main reason is that SAP is built on MIC's.  And a lot of functionality of the MIC's and inspection plans are required for the chemical and pharma industries.  The general characteristics and used in EH&S jut don't handle that stuff.

Creating and transferring a basic inspection plan to to QM with basic characteristics is just a start.  Will EH&S support LIMS as well or will it have to go through QM first?

I hope you are right and that there really is a plan in place.  Right now I don't see it in what is on the street.  If there is, will the plan stay in place for longer than 5 years?  Or until the next cool externally developed bolt on is developed and SAP likes it and buys that?  Or until management changes and picks a new strategy?

I'm all for more flexibility and options. Hey... it's what keeps me employed.  Right now there is almost no way a new customer, or even an existing customer doing an expansion to a new business, knows all the possibilities for keeping specs and know them well.  Look at me.. I'm going to have to consider some EH&S training in my future.

I might be being a little hard on SAP.  This is a difficult area and I know they look for guidance from the working groups.  It's just that from what I see from the software that is on the street and available, they have so far totally missed the mark when it comes to specs..

FF

[MarkoLange]

The picture is showing existing integration points of EH&S spec DB with other ERP components although your are not happy with at least one of them - the EH&S-QM interface. In VCI working group we plan to have a closer look at it in order to understand whether and which shortcomings might exist here.

When I was saying that we could do some consolidation of spec information within EH&S spec DB I was not expressing a product strategy. It is my personal believe that we can do more with spec DB and all the data that are maintained in it and that was the reason for me to draw that picture. I am not saying that all spec information will find a home there. This is not possible for good reasons I guess.

Marko

[former_member42743]

One correction: in my previous reply I said

"The main reason is that SAP is built on MIC's. "

That should have read:

"The main reason is that SAP QM is built on MIC's. "

Marko: 

You said: I am not saying that all spec information will find a home there.

And that's my point.  I think there should be a spec database where all spec data can reside.  Whether it's a MIC or a general characteristic, a sales spec, material spec or a customer spec.  Or some spec we aren't even aware of yet.

SAP developed the wonderful and amazing condition technique into many areas of their modules.  I can't believe that a flexible, condition based, approach can't be developed.  We already have numerous user exits for changing and updating specs in various objects.  These could be used to grab the data from the spec database utilizing a condition technique approach. 

I don't see it as being that difficult frankly.  hmmmmm.....

FF

[MarkoLange]

We have to distinguish between an ideal and a real world. In the ideal world there might be indeed one place for all specification information although I am even skeptic here due to the fact that the word specification is used for many things. You say that should not be difficult to make. But now we come to the real world. Fact is that specification data today are maintained in different places. So if we would change that now it would cause disruptions since we would touch the ERP system and its data at many places. All the users of SAP´s ERP system will not be happy with that. They will ask what the value behind it is for them who would have to take action to migrate from old to a new structure.

And therefore my idea to make more use of EH&S spec DB for maintenance of specification data since the spec DB has many existing integration points into ERP and is a very flexible tool already.

Here is what I take from our intersting discussion.

First, we have to check EHS-QM interface gathering customer feedback on that.

Second, the specDB is subject of discussions from time to time in terms of modernization. We avoided that for the time being in order to protect customers from disruptive changes. However in IT nothing stays forever and technolgical change will arrive the spec DB as well sooner or later. And in those discussions we should consider a specification management that goes far beyond just Product Safety the spec DB was onces created for.

Marko

[former_member42743]

I agree that real world is different.  I fully understand that their are millions, if not billions of line of code in SAP.  But I have the utmost confidence that SAP programmers could do it if the mandate was there.

One thing that could help would be to do away with MIC's or general characteristics.  I understand why this came about in the first place way back in R2 and 3.0 R3 but having this disconnect between QM MIC's and the rest of the world in SAP that use general characteristics is one of the base causes for many of the spec discussion issues that we have.

And of course everything has to be backward compatible. 

Maybe I should start up a startup company to develop a bolt-on specification solution and then get SAP to buy it. Seems to be the way to go anymore!!! 

FF

[MarkoLange]

Your comment on MICs is an interesting one and we defintitely have to think about ways ho to handle that best.

I like your business plan. However before taking action here I would like to hear from customers what they think about it

Marko

[former_member516092]

We have looked to implement Multiple spec in food manufacturing. Different Customers have different specification and the site is made to stock not made to order so one material. CWBQM is an absolute pain to use for the end users. We also had to put in authorization on plant code so that the end users dont end up mass changing other sites data as this transaction is powerful. The other item is the whole setting up of the Customers for Multiple specification we had to build a custom transaction to allow the end users create the Customers as this is in our config section and could not let them have access. Mainly though I push back on sites that if specification is different to create different material codes and avoid Multiple spec but had lost that debate in this one site. Then while I am on this - I am looking up do i need to implement an OSS note for qualitative auto valuation. So all in all SAP could make this section a lot more user friendly then it currently is.