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.