Ok.. so I've decided to take the plunge and try to make myself blog every once in while here.  I'm not really sure how many people will really care what I have to say but I thought I'd give it a go.  After over 15 years with working with SAP software I feel that I have at least some idea of what is going on.  Of course my wife reminds me, (often), that only applies to the SAP world.

So what do I intend to write about here?  I guess I'll find out as I do this.  But I think I'd like to discuss some of the softer sides of consulting and especially in the QM world as that is pretty much my entire focus.  Now I do think I know my way around some other areas of SAP fairly well, but QM has pretty much been my niche.  Not that some technical issues might not be discussed but I don't want to concentrate on that.  That's what the SDN forums and Wiki are really for.

I like to think I'm fairly good at what I do.  I know I'm not perfect.  I've screwed up a few things here and there in projects along the way. I probably have a few companies and/or employees complaining about the system I left behind.  But that's part of what I think this blog should be about.  Putting in a system or new functionality shouldn't be just be about flipping config switches and creating some user exits. Especially with regard to Quality Management. 

It's not just about making the client happy.  Sometimes you do have to make the client unhappy.  SAP has tried to put in place certain best practices into the system. Now everyone can argue over the details of exactly what is a best practice but we all know there are certain things you should and shouldn't be doing.  I find many of the questions posted in the QM forum relate to how to not do certain things.  How to avoid certain things.

Clients often want the system designed to work a certain way.  Except for when that one particular customer calls up.  Or that one batch is JUST a tad off at 3:00 AM and the truck is waiting to load and they just KNOW the customer won't really care.  That's not the way it works folks if you want to ensure top quality.

So I hope those can be some of the issues I can blog about and we'll see where it goes from here.  Because quality consulting for the QM module shouldn't just be about knowing what switches to flip.

FF

Wow... I didn't think I'd find a topic that would raise my dander so quickly.  Here's a perfect example of what I hope this blog can be about.

A recent posting asked about an early warning system for notifying personnel by email about material about to be expired.  The standard report MB5M was recommended to them. This report can be used to monitor soon to be expired materials.  It was suggested that it should be part of someone's job function to run this report on a regular basis to monitor soon to be expired materials.

Another poster indicated that they had set up MB5M for a client to be run in a background job and the report mailed to the user's.  Now I have no doubt the client asked for this.  And the partner or consultant was doing as asked.  And in the end, there might have been some very valid reasons at the client for doing such a thing.  But my question would be “is this really a good thing to do?”  What are the benefits and risks of undertaking such a development?  It sounds simple enough.  It sounds like a benefit to the company.  And of course if you are a consulting firm doing the work there is always a price involved.  A good thing for the consulting firm but maybe not so good for the client.  But hey...they asked for it.

Just because a client asks for something, I don't necessarily believe we should simply accept it at face value and just give it to them. Now some clients will insist on it and that's fine.  Provided the consultant helped identify all the consequences as well as the benefits.  Do all consultants and consulting partners do this?  Talking a client out of doing a development is well, quite frankly, reducing development revenues.  I think too many consultants are too quick to want to visit their local ABAP'er.

In this case what are the potential benefits and consequences.  A lot depends on the size of the company and the number of materials being monitored.  Also the number of potential email recipients. 

Benefits:

1.  It is run regularly when it is supposed to be run. It's never missed

2.  It is run with a standard variant

3.  Many people can be kept informed

4.  If nothing is expiring people don't waste time going into SAP

5.  No training of users to run the report

Sounds good...  I’m sure I missed some and hopefully folks can add some more via comments.

Ok.. so what are the consequences?  Lets rebuttal each of the benefits first.

1.  Running regularly - This item largely depends on the number of products, the size of the company, the, number of people involved, etc... What if you set the variant up to warn when batches are 30 days from expiring and you run it once a week?  Is that a correct window for all products?  What if some products have a 3yr shelf life and others only 60 days?  Do you set the job up to run multiple variants? What about new products?  If you have products with a 30 day shelf life, do you want them flagged the day they are made?  Maybe this should be run every day for some products.

2. A standard variant - almost impossible for a large company.  You might have many products you really don't care to monitor.  Maybe you have dummy batch managed products for certain processes. Maybe you have bulk intermediates or bulk tank materials that have expiration dates but you don't need to monitor them as the bulk is just blended off into new batches when it expires and the production people monitor that.  In almost any case, you are going to have to somehow specify specific materials in the variant.  Since the selection is only by material in the standard, you have to maintain the material list in the variant.  Either one by one or by using a range of material numbers.  Or you copy the program and add additional selection choices like Material types.. Oh boy... more development!!! 

In the standard you can't limit the selection by material AND plant.  If you specify a material, and you specify a group of plants, it's active for all the plants.  Unless you create multiple variants and use multiple steps for the batch jobs. So now you need a business process to make sure all relevant variants are updated every time you create a new material master or extend a material to a new plant,

3. Many people can be informed. Ok.. yep that's true.  But only a couple of those people will actually ACT on the information.  Maybe only one person!!!  Are those other people REALLY looking at the report?  Is it really worth doing a development to send a report to 20 people when only 1 or 2 people act on the info and maybe only 1 or 2 people are actually monitoring that activity?  And who keeps up the distribution list as people come and go and change job functions?  We’ll need another business process for that!  Oh…and while it’s pretty much peanuts, don’t forget all the email storage space those reports will eat up over time. Not to mention a potential liability issue when a report is available in email showing a batch was once expired that maybe somehow got sold and shouldn’t have?

4. Wasting time to check in SAP?  Let's face it.  The people that actually work with this info are in SAP everyday anyway.  How much time are they really saving?  Let’s see, /nMB5M, pick my favorite variant of the day and click execute.  That's about all of 5 seconds.

5. No training of users to run the report - this is the biggest benefit lie I think there is that is out there.  You never benefit by not training your users.  The key people involved in this activity are going to want to be able to run the report anyway.  Cause here is what happens in real life.  They get the report in the AM when they come into work. The first thing the person that has to act on this information is going to be what?  They are going to go in and run the report anyway!!!! They won't trust the batch job report!  They'll want to see it themselves.  And they'll want the info on their screen in SAP.  So they will learn the transaction with or without your help. And then, if they need to, they can email the report to the appropriate people right from the transaction!

Ok... we all know that every plant has someone responsible for watching expiring material and monitoring blocked stock.  (You do have those people right?).   If it is their job, train them to run the report and explain variant creation, (do it well once and you never have to do it again).  Train their supervisors to run the report and other inventory reports.  They should know how to do that anyway! 

Lastly, set up a business process to perform at least quarterly reviews on every area's blocked and/or restricted stock.  This stock costs you money to keep.  If it's expired, damaged, or soon to be expired get rid of it quickly and efficiently. Don't store it for years on the off chance someone will buy it!  Wake up... it became expired for a reason.

There is a reason SAP never provided a means to set up email notifications for this process.  It's usually does not add much value to your business. 

Actions

Filter Blog

By author: By date:
By tag: