Skip to Content

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.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Michelle Crapo
    The quick and easy isn’t always the best way to do things.  You can quickly mask a problem with a report like this.  It is a work around instead of use the system as designed type of report.

    And on EXPIRED material?  Really!!!!!?  That’s a big deal.  It creates waste and, if you use the expired material in a batch, the whole batch may have to be thrown away.  You may miss a chance to retest the material.  and… and..

    OK – there are many, many different ways of attacking the issue.  But never looking below the surface, uh, yes, that does happen.  I wish it wouldn’t.

    Internally all of our requests are reviewed by the Business Process Architect.  Those are the people that know their entire process.  If they see request like this pop up, I garentee they are going to start taking a look at them and buzz words like root cause come to my mind.  If the BPA misses the problem, the business analyst will catch the repetation.  And yes, sometimes the developer notices a pattern.

    Yes – it probably was what the business asked for.  And they were probably happy with the solution for a while.  It was of course what they wanted.  But the problem will just come up again later.  And again… Until someone takes the time to figure out why they had that request in the first place.

    Great blog!

    Michelle

    (0) 
    1. Craig S Post author
      Thanks for the encouragement!  Pharma has good things and bad things about it.  I’ve done work for three of the biggest and once worked in a pharm lab in R&D before my SAP life.  Good, because they usually spend a lot of time looking at things and reviewing them and usually do a pretty good anaylsis.  Most actually know what “root cause” means.  The bad side is they usually spend a lot of time looking at things and reviewing them and usually do a pretty good anaylsis.  🙂  That often leads to overkill solutions using a hammer to put a toothpick into a sandwich.  By the time they are done it hardly looks like a sandwich anymore.

      Non-pharma companies usually go the other way.  They want the solution yesterday, don’t really care how it’s done as long as it doesn’t happen again.  Unfortunately many of these companies sacrifice long term quality and consistency by putting in short-term fixes and business processes that address the symptom but not the true root cause of the problem.  An incorrect COA to a customer for instance is fixed by changing the output from autofax to the customer to hardcopy print out and requires a review and  maual fax.  Rather than reviewing and correcting the process of how the master data is set up and corrected to make sure the COA’s are correct the first time out. Once started, these practices are hard to stop and they keep snowballing.

      (0) 

Leave a Reply