@ 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: , , , , ,

What should an ERP software/tool possess?

The question that I ask myself today is not what particular features/functions an ERP must possess but what kind of experience must users as well as firms experience with an ERP software/tool? So, I decided to draw up a list of things that ERP software/tools must deliver in three broad experiential areas:
1. Understanding – A concept level requirement. Here the idea is that the assumptions, methodology of planning/calculation should be visible and easily understood by a firm’s management and/or users. This would mean that there are no black boxes that accomplish magical things or some dark art embedded within. From the competition aspect (i.e. with other ERP vendors), this throws open the inner workings of the system. Therefore, it will have to be tempered a bit – grey boxes that nevertheless explain in a simple manner what is being accomplished.
2. Adaptation & Implementation – Should a firm adapt its business processes to an ERP software or should an ERP software be adapted to a businesses processes? That is the basic question that underlies this area of Adaptation. Along with that arises the need for an ERP software to model the business process as it is or in a desired reengineered state. A frequent issues that I have observed is absurdly long implementation plans and projects which increases the risk of failures.
3. Operation & Continuous Improvement – An ERP system might be the backbone of an organization but it cannot be the system that only a backbone specialist only can contend with or change at a moments notice. The very notion of continuous improvement implies that any user should be able to change/improve the functioning or scope of an ERP system.
Now, admittedly, this is a rough cut of what I see an ERP must accomplish in order to be successful. From that broad classification of user experience, some ideas fall out as first cut rules that an innovator might follow:
1. Implementation of the ERP system must be in a timeframe of months (even weeks) rather than years.
2. IT departments must be minimally involved in the setup and roll out of the ERP system.
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.
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.

That’s an attempt at a first list. Some of the above might seem outrageous and wishful thinking but if you’re going to set goals, they might as well as be as far out as possible. Next step – features.

Categorized as: ERP_, Tools_
Tags: , , ,

What maketh an ERP software?

What maketh an ERP software system? An innocent question like this could subject you to a lot of harassment (sarcasm overfloweth here) – the magnitude and kind of undue attention would vary depending on the source of the attention. For example, an ERP salesman could subject you to a 3 hour presentation (If you’re like me and lose your mind after the first 15 minutes) and I shudder to think that it might happen not less than a week from today.
This site here lists some of the more common ERP modules that are available from ERP vendors:

  • SALES ORDER PROCESSING (SOP) and DEMAND FORECASTING
  • PRODUCTION PLANNING and MASTER PRODUCTION SCHEDULING (MPS)
  • ROUGH CUT RESOURCE PLANNING (RCRP / RCCP)
  • CUSTOMISATION PLANNING and ENGINEERING CHANGE CONTROL
  • BOM PROCESSING and DATABASE MAINTENANCE
  • PLANNING OF MATERIAL REQUIREMENTS (MRP)
  • PURCHASING (POP / Purchase Order Processing)
  • DETAILED CAPACITY PLANNING and SHOP LOADING and SCHEDULING
  • INVENTORY CONTROL (Stock Management)
  • SHOP FLOOR MONITORING and CONTROL (SFC / SFDC)

So I asked myself that if ERP were to be redone, who might the logical candidate be? I drifted towards an OpenSource implementation of ERP software. That led me straight to Compiere. A brief scanning of Compeire ERP’s architecture, features and processes led me to think that the seed has not fallen too far from the tree. Compiere is directed at SME (Small and Medium Enterprises) and that’s probably a smart move if you wanted to grow big.
The second stop was at OpenMFG which I found to be a lot more upfront about what it is they intend to achieve, what they offer and how they price it – i.e. a fresh breeze flowing from a vendor. OpenMFG has a lot of features as well which they have summarized smartly in their brochure.
The third (and final) stop was at ERP5. It seemed a lot more comprehensive in scale and scope than the previous two open source ERP offerings. The other thing that stood out was the ease with which ERP5 professed to carry out the installation and the availability of source code for the tool as well. I’ve found what I was looking for now. I’ll be exploring more features of the ERP5 tool now in order to study it in a little more depth and detail.

Several more Open source ERP software providers are listed here. I will take a brief jaunt through them as well in order to see what’s happening there.

As I was surfing the field of open source ERP providers, I came up with the idea of drawing up a list of ideas that would form the core of an ERP tool offering. If any of you reading this have any insight into ERP tools, have used them and would suggest your ideas, they would be more than welcome. My ideas in the next post.
Witnessing, a brief spurt in the offerings of entirely new ERP tools in an arena where the elephants of ERP (SAP and Oracle) reside and trample about leads me to think that the time is right to fell the elephants.

Categorized as: ERP_, 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
March 2024
S M T W T F S
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Archives