SAP ROI — Enterprise Architecture & Business Solutions

Strategic SAP & IT Program Development for Measurable Business Value

ERP Education: Losing Our Religion

January 17th, 2011
Planning, coordinating, training

synchronizing success

Most ERP software packages are designed around industry accepted business practices, operating philosophies and techniques that have evolved over many years. Today the issue is not whether there is a body of knowledge with supporting software tools, the question is… are clients educated enough to see the value or understand the proper use of the tools. The short answer is no.


Education versus ERP software training

First, many have lost site of the fact there is a difference between education and software training. End user software training is very important but it is mainly about how to do transactions in the software and how these transactions related to your business processes. However, this can be very different from understanding the original design intent and industry application of the tools.

For example, the issue of education vs. software training is analogous to training someone to fly a 767 but not educating them on the concepts of jet propulsion or flight; or how to start-up a chainsaw but not the best way to cut down the big tree. Both of these are scary propositions, but in terms of ERP projects it is about failure to achieve the business benefits. At the root of the problem is senior managers and end-users never changed their behaviors to take advantage of the tools; and a big part of this is lack of education.

Independent Sources of ERP education

Keep in mind, education is more than just a seminar of “best practices” put on by a software vendor (with a hidden agenda) in room full of 300 other clients. It is about getting some real independent education, not focused on any specific package. In addition to understanding key concepts, one must also delve into the mechanics in order to implement.

Baked into the ERP implementation methodology

There once was a time when management and user education were part of the standard implementation methodologies. Interesting enough the project success rates was much higher.

For example, it is worth noting the great Joseph Orlicky wrote the first groundbreaking book on the topic of MRP (forerunner to ERP) back in 1975 (updated and still a good read). It focused on concepts and techniques on how to plan and control materials in a manufacturing plant. However, the most interesting thing is Mr. Orlicky (an employee of IBM) never glorified the role of the computer. He believed if one did not understand the underlying principles of MRP, the computer was not much help anyway.

However, the late Ollie Wight (the godfather of MRPII) said it best “MRPII is not a computer system, it is a people system made possible by the computer”. Orlickly and Wight went on to build and grow the “religion” called APICS (The American Production and Inventory Control Society). The best thing that ever happened to manufacturing practitioners.

Back to ERP Basics

Today there is a disconnect between industry best practices and what clients attempt to do with their systems. It might be time to get back to the basics of blocking and tackling or at least try to understand the intent of the package you just purchased.

Instead, we focus on the gee-whiz aspects of software, technology, implementation tools, and turnkey solutions (which usually exist only in the marketing literature). Cheaper, faster and the slam-dunk mentality is the name of the game, even when we do not accomplish anything worth the effort. We naively assume the mere existence of better tools automatically results in a change in employee behavior (if we build it, they will come). We fail to educate senior management and then wonder why they are not committed to the project. We set higher expectations of our employees, yet as leaders, we fail to provide them with the knowledge they need to succeed. When our projects go down the tube, we blame software vendors, consultants, the entire senior management staff, all employees, our spouse, and everyone else except ourselves.

No, education is not glamorous so proposing it will not make you a hero. Nevertheless, it is the stuff successful IT projects are made of. If Ollie knew what was going on today he would roll over in his grave.

=====================

Contributed by Steve Phillips of the Street Smart ERP Blog – Visit his site for more great project insight.

Related Posts:

Software Consulting Firms and Clients Myths and Half Truths

December 6th, 2010

DirectionA recent post from my friend Steve Phillips who runs a great site entitled “Street Smart ERP Blog“.  This is a nice complement to the series I just finished on SAP and ERP critical success factors.

=================

Steve Phillips writes:

Having spent the majority of my career in the shoes of a software consultant or client, I have often wondered why many find it necessary to perpetuate the old myths and half-truths regarding the consultant / client relationship. My feeling is given the track record of ERP we are not doing anyone any favors. In fact, we are causing more harm than good by setting false expectations regarding what consultants are, what they are not, and what the client should be doing.

One answer is …the myths are self-perpetuating. That is, consultants want clients to believe them (more billable hours) and clients desperately hope they are true (even though deep down they know better).

The other answer could be consultants actually believe they are super-human and clients play into this by getting the consultants to assume all the project risks. The real answer is …we are all a lot smarter than that.

In this and the next series of blog entries, I explore this topic by addressing each of the fifteen myths. No doubt, some will not like what I have to say. But if we cannot acknowledge the problems, we certainly cannot address them (and for the sake of everyone involved, let’s face it, they really do need to be addressed). Here is the first one.

MYTH #1: “THE SOFTWARE CONSULTANTS WILL MAKE US SUCCESSFUL”

TRUTH: Consultants can educate, suggest and coach but cannot make the client do much of anything. In fact, for most ERP “critical success factors” consultants have no direct authority or control over the outcomes.

There might be a few superhuman consultants out there, but 99.9% of them are not.

Only the client can:

  • Own and communicate the business case and drivers for the change.
  • Clearly define and communicate their project objectives.
  • Implement measurements to support the desired behavior and process changes.
  • Approve and contain the project scope.
  • Require (not just sell) the cooperation of employees at all levels of the organization.
  • Assign the right internal employees to the project team.
  • Free-up the required time for those assigned to participate.
  • Expect (not hope) the internal team eventually becomes software experts.
  • Hire employees with the right skills and knowledge when necessary.
  • Manage and utilize outside consultants correctly.
  • Hold functional managers and the team accountable for fulfilling their roles
  • Make necessary changes in operating paradigms and business processes.
  • Limit software mods through justification or changing business processes.
  • Remove the people barriers and naysayers that get in the way.
  • Tackle project issues and decisions in a timely fashion.
  • Take end-user training seriously and require employees to attend.

Again, no matter how great your ERP software or consultants, these are things only the organization can do.

So can your software consultants make you successful?

Related Posts:

ERP Software Selection: Do you want to be a Guinea Pig?

August 9th, 2010

Hit the target

 

“If the software functionality does not do what we need it to do, nothing else really matters.”

Back in the 1980’s, IT department preferences or mandates to use specific proprietary mainframe technologies drove many ERP software decisions. This was about the technologies the IT department could (or would) support not the mainframe software that best satisfied business needs.

Later in the 1990’s the mainframe vs. “open system” (client/server) wars caused many to take a blind leap of faith into open systems only to find out later the ERP software functionality in this arena was not as mature as their mainframe counterparts. Though open systems eventually won, many jumped head first into this brave new world simply at the wrong time.

Today “open source ERP”, upstart internet based application services (SaaS), “cloud computing” and other paradigms represent the same fork in the road. It is guaranteed tomorrow there will be a new one. The point is not to generalize regarding any particular direction; but the lessons of the past must not be ignored…. If the software functionality does not do what we need it to do, nothing else really matters.

When this occurs everyone will forget all the seemingly valid reasons a package was selected in the first place (cheaper, newer technology or everyone else is starting to do it). They will focus on the lousy functionality and lack of project benefits.

In the real world budgets are not unlimited, technology can be a strategic enabler, and there are other important trade-offs. However, nine times out of ten if the software functionality is a bad fit, eventually the project is deemed a failure. This means software decisions that do not weigh functionality the most can defeat the purpose of a new ERP system.

The Future of ERP?

The message above seems simple enough (and almost elementary), but many smart people allow themselves to get caught up in the industry hype.  Let the academics and consultants who really care debate the future of ERP because in the meantime you have a business to run. Unless you are interested in becoming a guinea pig. Believe me, a lot of software vendors are looking for them.

The Right Side of ERP History

Selecting software is not just a quantitative process. It ultimately boils down to a business decision and you want to be on the right side of history. As long as the cost of ownership is affordable, the technology stable, the package is supported, and many other companies are using it; go with the software that best meets business needs. 

If the organization cannot find a package that satisfies at least 85% of the overall software requirements (and almost all of the important ones), it is time to either look at higher-end packages or redesign your business processes.

=========================

Editor’s commentary - Steve Phillips runs a great blog which is linked here:

http://it.toolbox.com/blogs/street-smart-erp

Be sure to visit his site and support his efforts!

Related Posts: