@ Supply Chain Management

Icon

What should an ERP software possess? Part deux…

In an earlier post: What should an ERP software possess, I was in the process of running up a list of things that an ERP innovator ought to think about. Today, I sat through a presentation of SAP Business One (More information about SAP Business One), an ERP software that SAP targets at Small and Medium sized enterprises (SME) and had the opportunity to brainstorm about critical features that a new ERP system ought to possess. I was expecting a watered down version of mySAP but Business One is a product offering that stands on its own. That particular feature is probably because of the fact that SAP acquired the previous seller of Business One and chose to retain the original offering instead of creating a watered down mySAP. An observation that jumped out at me is the number of forms and drill downs that Business One entailed and it just kept going and going and going and going… There’a lot of information embedded within the system and that’s probably what the system really brings to the table – a data backbone that everyone in the enterprise can use, modify and communicate about.
Meanwhile, I came across the following article: Lies your ERP system tells you. This article deserves a post in its own right but since I want to clarify some of the problems (thus translatable into opportunities) with the current state of ERP software.

“As a result, each year they were overstating the value of their inventory by millions of dollars,” Testa said. “They didn’t know what caused the problem and they didn’t want to find out, so they just wrote off the difference until the parent company called them on it.
“That’s the biggest problem with ERP systems,” Testa said. “People muck with them. They try to make them perform the way they want rather than the way that’s correct.”

What are the sources of the problem here? I can see at least two very readily – one being the lack of discipline when it came to data entry and the second more important one being the lack of understanding of the system. The latter is a point that was raised in the framework for how to think about a new ERP system. The former point about users lacking discipline in entering the data is something that I have frequently encountered while attempting to collect data in the pursuit of some consulting engagement – most of the time, the data sucks big time.

Its power depends on recording and tracking thousands of individual transactions, or events, ranging from sales orders to each component on a bill of materials. It then models how those processes interact with one another. Like dominoes in a row, each new transaction sets off a cascade of new events.

That couldn’t have been put more succintly. In fact, people should not be calling it ERP but information chain with the data layer called the data backbone. That’s what ERP essentially is – setting up a cascade of processes interacting, approving and alerting others is built on top of the information chain and data backbone. The easy way of determining whether a module/factoid/process is critical is to examine what happens to the whole when that little bit is compromised/affected/degraded.

ERP models reflect reality only when each transaction registers true. “Yes, it is costly to enter each transaction,” Testa said. “But as soon as you go around the system, it begins to degrade. Once that happens, people stop trusting it, and then they have another reason not to use it. It’s a death spiral that’s inherent in ERP: If you don’t trust the system, you validate that the system’s data is bad by screwing it up.”

Such remarks remind me about those who repeat – “You can’t manage what you don’t measure.” I’d guess that there is also a propogation of errors (and consequent magnification of errors) as it cascades through the entire set of interacting processes. As incorrect data sloshes throughout the system, it triggers actions and creates beliefs about the current state leading to inefficient decision making – that’s a beast that is difficult to corral.
Here’s a critical observation from the article:

That seems to happen most often when ERP systems reach down to the factory floor. There’s a disconnect.

Why, why, why? I harken back to a book that I am reading right now – Putting Total Quality Management to Work by Marshall Sashkin & Kenneth J Kise, wherein they report on Sam Walton’s (of Walmart fame) observation. The quote from the book reads, “Quality cannot be added on; it must be built in from the start. Mass inspection is completely off the mark. It assumes that quality can be achieved by identifying and then correcting errors. As Walton observes, this means that workers are paid to make errors and then paid again to correct them. This is not to say that workers like this any more than do managers. Deming notes that almost all workers want to do work of high quality, work in which they can feel pride and a sense of accomplishment.”
I am of the conviction that ERP, in its widely found form, is neither about Resource nor about Planning, it is primarily about Enterprise – a whole set of integral and connected processes across the enterprise are brought together under one umbrella (It might be an oddly shaped umbrella but the important thing is that it is one umbrella). The article, sort of, agrees:

Part of the problem is manufacturing complexity. “ERP is great for deploying standardized processes across an enterprise, but it has had a hard time bridging that last mile due to the complexity and disparity of plant operating solutions,” said Russ Fadel, vice president of manufacturing applications at SAP Labs LLC, in Palo Alto, Calif.

Remember, that standardized processes are the route that the current crop of ERP systems have taken – it was a choice in order to get that first “E” of Enterprise. Intuitively, that seems a logical choice but given the observation that there are some practical difficulties, it is wise to return to this original premise. Up to date information exchange is what is desired within an enterprise but it does not logically follow that standardized processes are the only solution. Here’s what really goes on in a wide-swarthe of companies that dot the ERP enabled landscape:

At worst, that means data and process models are scattered everywhere. At best, automated facilities use manufacturing execution systems that harmonize competing models and data, and moderate the flow of manufacturing information to and from the ERP system.

A lot of software providers have sprung up to fill the obvious shortcomings of ERP software. However, that leads to a multiplication and replication of data sources, data models, process models etc. But that’s the real world. Adopters of ERP systems ought to know this even if providers of ERP software do not.
There are three problems described in the article and they are:

“ERP does materials management and resource planning, but if you don’t have accurate shop floor data, ERP forecasts are not much better than putting your finger in the wind,”

and,

“Implementation,” he said, “is the number one, two, and three problem in ERP. It’s not that the systems are inflexible, but that they’re so very flexible.”

and,

“The conflict comes when companies try to reconcile what software says they should be doing with the way they’ve always done things,” Greenbaum said. “Companies that spend millions of dollars on ERP software would like to think that the software works for them and not the other way around.”

The above three reasons and others too are why I think that the business of ERP is in for radical competition. I can imagine that there are many product segments and industries that beg for competition – typically, they’re monopolies/oligopolies of some sort or the other.
But on the flip side, am I barking up the wrong tree? Am I confusing the problem of the technology with the problem of discipline and adaptation? Is the real problem the human element? Here’s why I’m thinking about that:

That sounds daunting. Yet every company operates at least one system where the data is always perfect, Boyer said. It is a system where everyone takes personal responsibility for accuracy. Where they report mistakes immediately. Where no one accepts any lies from their software.
It is, of course, payroll.
When operational personnel take as much responsibility for manufacturing data as they do for their paychecks, they will be able to count on their ERP systems to tell the truth.

Those are observations that are largely true and should give any observer pause. Perhaps the problem lies really at the interface of ERP software and the human being. Consequently perhaps, that’s where the solution must begin.

The expanded list as it stands now:
1. Implementation of the ERP system must be in a timeframe of months (even weeks – am I being rather optimistic) rather than years.
2. IT departments must be minimally involved in the setup and roll out of the ERP system – this is critical because often ERP is an IT project. However, it is an Enterprise project that uses IT as the medium – that’s a big difference.
3. Black boxes must be kept to a minimum if not eliminated entirely
4. Don’t get stuck into thinking that ERP systems should be modular, especially along the lines of defined functional areas. Other forms of organization such as inheritance (OOP) and value chains might offer alternative ways of organizing features/planning philosophy etc.
5. Meta modules and inherited modules must be available. A frequent thought that I have is that when people from different functional areas communicate, they’re abstracting what they think is happening in areas outside their expertise in order to understand those activities. I am thinking out loud here whether that is the nature of communication between functional areas as well.
6. Upgrades to the ERP system should be radically modified. I can’t think of a way to achieve this because the underlying philosophy of the system might change but the architecture initially outlined must consider both ongoing operations as well as future operations along the three broad areas above (Understanding, Adaptation & Implementation and Operation & Continuous Improvement)
7. Dashboards. Dashboards look cool. Other than that, it might very well be an information dissemination service to all members of the firm rather than decision makers.
8. Leverage open cooperation between ERP adopters and implementors across different industries and allow them to collaborate on process development, insights, measurement and continuous improvement ideas. In fact, allow them to exchange and adapt business ideas through the system. This idea is borrowed from the SCOR model implementation which is a formalized system for supply chain development and implementation.
9. The basis, methodology and guiding philosophy of the ERP system must be laid bare for everyone to encounter, experience and understand.
10. Data is the backbone of an ERP system. Therefore data integrity is critical and ways to preserve/enforce/structure data integrity is critical. Current ERP processes such as back flushing should be avoided as much as possible. One way to minimize (not eliminate data errors or significantly minimize data errors) data errors is to minimize direct key board related data entry by using combo boxes and drop downs instead of text fields for data entry.
11. Integrate the most commonly used software mediums into the system. If there is something that I hate about ERP systems is the Form based GUI. I hate it on two accounts (though at this time I cannot think how to replace it effectively) – first that IT has to be intimately involved in creating/modifying/adapting the GUI as it suits a company and second that you can only do what the form allows you to do even if it means cascading through numerous forms in order to ascertain what you want. What is the most commonly used software tools – it has to be MS Office/Internet Explorer or something of the sort. Ergo, the ability of individuals to use MS Office programs is going to have a distinct advantage over any ERP software providers ability to provide templates or customizable forms.
12. Understand why the interaction between ERP software and human actors causes these well documented problems. What is the solution there?

More to come…

Categorized as: Tools_, Supply Chain Management_
Tags: , , , , ,

About me

I am Chris Jacob Abraham and I live, work and blog from Newburgh, New York. I work for IBM as a Senior consultant in the Fab PowerOps group that works around the issue of detailed Fab (semiconductor fab) level scheduling on a continual basis. My erstwhile company ILOG was recently acquired by IBM and I've joined the Industry Solutions Group there.

@ SCM Clustrmap

Locations of visitors to this page

Subscribe by email

Enter email:
Delivered by FeedBurner

Enter email to subscribe
August 2006
S M T W T F S
« Jul   Sep »
 12345
6789101112
13141516171819
20212223242526
2728293031  

Archives