Abstraction

I've probably had this conversation with dozens of customers over the time I've been providing ERP consulting for Infor Visual Manufacturing, but in my opinion this is the most critical and subtle part of implementing an ERP. It's also the one part of the implementation that is ignored by too many customers and is what usually results in the failure of the system.

This post all centers around the following term:

Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically to retain only information which is relevant for a particular purpose (I borrowed this from Wikipedia).

In simpler terms what Abstraction means is leaving out the detail you don't need. There is a fine line between over-abstracting a process and over-detailing it. Let me give you some examples from real-world situations I've found myself in.

Over-Detailing:

This happens less often, but my favorite example was a customer who was creating routings and bills of material for an assembly process. The routing had about 15 steps on it, and each step had the individual items required at that step. The reason this was over-detailed however, is because the entire process of assembly took about 15 minutes and was done at one bench by two employees. Collecting labor cards for the time invested to assembling the parts took longer than actually putting it together. It took the material handler fifteen minutes to add up all the items required since they were broken out into different routing steps.

Had this been an assembly line process where hundreds were produced and each step was done by a different indivudual and needed to be stocked separately, then this level of detail would have been fine. The fact was that these asseblies were done in small quantities (less than 10) and all together. The extra detail in the bills of material and routings made the system much harder to use.

I made my best effort to explain to the customer that this was not an appropriate level of abstraction, but unfortunately engineers had designed the process and from their point of view "it was right." The most dangerous mistake when over-detailing is customers want to use the ERP the "right" way, meaning use all the features and make the data as accurate as they can. What they often do not understand is that doubling the detail in the system can be substantially more than double the work.

Over-Abstration:

There are more examples of over-abstraction than there are of over-detailing. Some customers try and abstract their processes as much as they can in order to cut corners in collecting data. One example of this was a customer who decided to only collect information regarding production at the beginning of their process. They analyzed the time required to produce the part and decided that since it was less than a day to finish a part that was started, they would report the part completed after the first production step. They rationalized that if they abstracted the process they would reduce the data entry time required to use their ERP.

The problem with this approach was that in reality the parts could take as long as 2 weeks to complete. So the system would show some number of parts (10,000 or 20,000 would be normal) in stock and available to be used when they were really in work in process (WIP). Since the parts could be used in several finished goods, employees were constantly consuming too many of them when building stock of finished items. The customer eventually chose to implement a six figure barcoded data collection system to track the location of the work in process. I still believe that they would have dramatically improved their inventory accuracy just by adding another "stock point" where the collected information about the items that come out of WIP.

"So what do we do?"

I've given some examples of what NOT to do, but how do you take this and turn it into what you should do? I'll give a number of suggestions. There's no magic bullet and there's no substitution for experience, but this list will assist most people in getting started.

1. "Understand what you need the information for!" It's surprising how often people do not sit down and look at the reports, lists and other information staff will require to do their jobs. If people need the information, then you should make sure you collect enough detail to drive the reports they require.
2. "Be aware of who is collecting the information" One of the big problems with adding detail is whether staff can actually manage to collect the information accurately. You need to abstract the information you collect enough that it's not going to overwhelm the abilities of your staff to keep up with it.
3. "When do you need the information" You can abstract both the information itself but also when you collect or know it. The example of over-abstraction I gave above takes this too far, but it's definitely an area where the implementation team should establish what is "real-enough time" for data collection.
4. "What is and is not MATERIAL" I am using the term Material here to mean that it actually impacts the bottom line or represents a cost that is important. You should be aware of how much data you need to ensure that financial information is accurate. Sometimes leaving unimportant information in the system (very low cost parts on Bills of Material for instance) costs more to manage than the parts themselves could ever cost.
5. "Broaden your Analysis" Before you choose to exclude or abstract something (particularly to save data-entry time) be sure to look outside the apparent "department" where this information might be used to see if it's needed elsewhere. It's frequent that information in an ERP is used in several places. Bill of Material information is used in the planning process for instance as well as just in engineering or purchasing.

Once again, I hope that this Blog is helpful and that you found it interesting.

Rob Jolliffe
President creativemfg and sabre
Infor Visual Manufacturing / Microsoft Dynamics GP Experts