Skip to Content

The idea for this blog came from a comment thread on one of my other blogs.  Michelle Crapo was kind enought to comment and it led me to a thought I’ve had before.  I’m sure others have discussed this topic probably before at times.  And for some old-timers here this is old news.  But hey… it’s my blog.

It’s amazing the differences between the cultures of countries and companies.  I have done projects with major pharmaceutical firms as well as low cost chemical companies and other general manufacturers.  Several of my projects have also been international in scope working with different cultures.  Italy, Spain, France, UK, Canada, Australia to name a few.  Sorry to say I haven’t had any Asian exposure yet.

Now I’m going to stereotype here.   So don’t beat me up too bad on this.  There are always the exceptions that make the rule and I acknowledge that.

For many of my American brethren, the switch to SAP is somewhat of a culture shock.  I think our European associates “get it” much better.  Every SAP project I’ve been on, we try to hammer into them that bad master data is the number one cause of failures in new SAP projects, (at least from where I sit in QM).  Bad data is where 80% of your go-live headaches and pain will usually be traced back to

We (Americans) have a habit, (I’m not saying its a bad habit or a good habit), of just wanting to resolve the problem.  Let’s just get it done and resolve the problem.  Execute. Execute. Execute.  Go. Go. Go.  I always tell them that SAP is different than any other system.  It expects a huge investment in planning. (no, I’m not talking about MRP) and preparation.  Mainly, I think this is due to the huge amount of built in integration between modules in SAP.  This of course is what drives so many of the major benefits.  You don’t really see that integration when your business runs on 30-50 different applications all from different vendors.  But it is there, it takes the form of emails, phone calls, checking spreadsheets, disbursing reports in snail mail or email, shared files on file servers, master lists, SOP’s, job aids, etc…  After all, you are still doing the work to run your business!

I tell them that most people and companies spend 10% planning and 90% executing.  But SAP expects something like 80% planning and 20% execution.  (Please don’t take those numbers as literal and having any scientific backing. They don’t).  This is not unlike our personal lives where any time management course tells you to plan your day.  And we counter that we don’t have the time to plan.  We say that those 30 minutes a day of planning is wasted time.  Deep down we all know that to be untrue.

SAP is very much like those time management courses.  Fail to plan and you can plan to fail. 

Expecting to use SAP and not planning to commit additional resources to post go-live master data maintenance, upkeep, review and creation is a sure way to make your future in SAP an unhappy experience.  Getting these master data processes correct in the design phases is almost as important, if not more so, than getting the initial master data load correct.  You will get your master data load correct eventually, even if it is 6 months, (maybe 2-3 yrs later!!), after you have loaded it. The system dictates it.  (I know we’ve all been there and done that!)

But bad master data creation processes ensure that the corrections will never end.  The irony is that in reality you are doing these master data creation processes now in whatever combination of those 30-50 systems that are currently being used.  It’s just that you usually have the job of dealing with that data spread out across the 30-50 application specialists that deal with those various apps daily.  And the multiple hand-offs, emails, phone calls and errors are all there.  It’s just that there is no true visibility of those activities and no way to actually quantify them.  Those 30-40 people may only spend 5-10% of their day dealing with those issues.  But 40 people * 10% of their day = 4 FTE’s.

But suddenly with SAP, you have a need to concentrate those responsibilities into one or more specific FTE’s.  You didn’t really see them before… but they were there.  But now, you see them as an FTE’s, (or partial FTE’s), required to support SAP. And that causes management issues to establish these new roles and jobs and often times push back on projects.

But be assured. Eventually you WILL have these people.  Even if you choose to not formally recognize them the system will dictate that someone does the functions required. Make sure you plan these post-go live positions early in your design phase and not as a last minute after-thought a month before go-live when you are doling out the security roles.  I don’t think I have ever seen a task or project item in a project plan or methodology called “Design and map post go-live master data creation/maintenance support”.   Yet every module should have this as a task early in the design.

Unfortunately many consulting companies and consultants do a bad job of pointing this out to clients.  After all, they are out of there once the system is up and running.  Clients too often, (still after all these years!!!) are still identifying and training these people and setting up these processes during the initial couple of weeks of go-live.

FF

To report this post you need to login first.

7 Comments

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

  1. Marssel Vilaça

    SAP is the king of post ‘go-live implementation’! I thought it was stuff of Brazilians, but I can see that is not. Migration data are one of the great villains, but the worst villain of all is undoubtedly the undoubted confidence of clients in Consulting Companies and implementation team. But we have to agree on one thing: Who wouldn’t trust an Auto Mechanic who said your car would blow up? So less than 40% of  implementation are successful. There aren’t 99,99% grade. it’s 100% or nothing.

    (0) 
    1. Craig S Post author

      Thanks for the comment Marssel!  Nice to have a South American perspective.

      Ultimatley I’d still say you have a 100% successful implementation rate.  It’s just that only 40% do it as scheduled. Your other 60% still manage to struggle through and make it work and EVENTUALLY get enough data right to be able to function.  Ask any consulting house and they’ll tell you all projects are “sucessfully in production”.

      FF

      (0) 
  2. Martin Hinderer

    As my major work focus has been on master data and the architecture around it I can definitly confirm this. Most projects tend to underestimate the importance of master data (“customer master data is just an address, so why should we do some strategies for that?”), and I am not only talking about the data migration part. The thing is: if your master data is setup right, you will not notice it. If not, your processes will fail in the end. And this is the only argument which everyone will understand (especially if you give them some nice examples which result in loss of money 😉 ).

    Especially on QM, where inconsistent master data in the SPC part will result in very ugly system behavior (which under normal circumstances the user will not directly see, but an experienced auditor will find it for sure…)

    MH

    (0) 
    1. Craig S Post author

      Thanks Martin!  Thankfully, I have had to do minimal SPC!  You’re my goto guy on that now after seeing and working on other posts with you!  Sampling procedures, sample drawing, and SPC can all be a very uninspiring area for many people and I have only found a handful of SAP consultants that really understand the more esoteric details of them.  (and I don’t include myself among them!).  I’ve known many QM consultants that have never dealt with them even after years in the business.

      Thanks for the confirmation.  SAP is about planning and you would think folks would understand that master data creation processes are crucial to that and need to be addressed as much as say inventory control processes or cash management processes.

      FF

      (0) 
  3. Nitin Jinagal

    Hi Fire

    We did Big bang Go-Live in May’13 and one thing I would like to share as QM guy, we also faced around 90 % issue related to master data. Some occured due to wrong uploading of Material master QM view, others happened due to non verification of legacy data wrt SAP codes. It took us good three weeks to overcome this.

    I like your blog and would like to learn alot from you.

    Kind regards,

    Nitin Jinagal

    (0) 
    1. Craig S Post author

      Thanks Nitin!  Your experience is, unfortunately, the rule it seems in most projects.  QM has a lot of master data so it’s not unusual to see some aspect of it get short changed during the review and load process. Not to mention that last minute process changes sometimes require a wholesale change in some parameter or value across a bunch of data which just adds to the complexity!

      FF

      (0) 
      1. Nitin Jinagal

        True!! I had to amend the whole master for ROH class just after two days of Go-live. I did not know about LSMW so learnt and used QA08 to modify the inspection view for around 1500 materials. Made mistake with other materials with same inspection type and had to re modify. Its a feel good factor now but surely was scary at that moment 🙂

        (0) 

Leave a Reply