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

Crazy Busy Week

I've been rather overwhelmed this week with some issues that have come up at work - particularly as relate to the Infor Visual ERP (Visual Manufacturing). I'll do my best to post again this weekend if the kids let me.

Rob

Why did you buy it ?

Last post I mentioned that I had thought about writing a "ERP Implementation" book. This is my first official post to this blog regarding the process of ERP implementation.

I'm going to refer to Microsoft Dynamics GP and/or Infor Visual ERP during different parts of the book. This is because these two ERP systems are those that I know best and are also pretty good SME (Small or Medium Enterprise) ERP systems. You can find out more about either of them at creative or sabre if you're interested.

* * *

A critical question to ask yourself if you are in the process or about to implement an ERP is "Why did I buy this?." It's curious how quickly the primary project goals get set aside during the implementation process. We often think that we know why we chose to purchase the ERP - but in fact the decision makers involved in the purchase are rarely involved in the actual implementation.

The answer you find should identify the underlying need that drove the decision. Dig deep enough to find the original "pain" that the purchase was trying to address. Identify the decisions that your organization needed to make (at the time the buying process was initiated) but which were not satisfied by the information at hand. This will point the way to why the ERP was purchased in the first place.

Reminding management of the original reason they purchased the ERP will help you out later on in this process, because a number of sacred cows may need to be shot in order to really implement your ERP effectively.

The book on tape (or CD) "Beyond the Goal" by Eli Goldratt has a great section on how messed up ERP implementations can become because the company refuses to change internal processes which are in fact, completely useless (ie - replaced by other processes) after the ERP is put in place.

Be sure to get “buy in” from the management team that the reason for the purchase remains unchanged. It can change sometimes, as the capabilities of the ERP become more obvious. Usually the delivery of this information was the original goal. Whether that be in the format of a report or in some kind of process that was missing (for instance, a purchasing process). Often you come up with a list of reports they were missing but felt would be essential for running the business more efficiently. There are other possible requirements - but you might be surprised, you can almost always track them back to some kind of missing information and a report or view of that information is the real driving factor.

In Visual Manufacturing most reports are driven from Crystal reports or the built in "QRP" reports. In Dynamics GP the SmartList is a fantastic and easy to use alternative to a report.

If you're in the process of a phase 2, phase 3 etc... re-implementation, then be cautious of a report request without a careful analysis of the data required for the report. This is a danger which can lead to trying to cover up the symptoms of a problem with more and more elaborate reports and information. This is best explained in the chapter on root cause analysis, but I’ll give a quick example:

Acme Inc. implements their ERP system and wants to manage their customer supplied materials with a report. Over time the report begins to become very complicated, accounting for scrap produced, quantities shipped, quantities on machines, user defined fields etc… to arrive at a total on hand.


After digging into it we find that Acme is not receiving and relieving the customer supplied material in their database accurately, and many of the complexities of the report are to cover for this fact. Fixing the data at the source makes the report unnecessary, since all Acme needs to do is look at the quantity on hand in their database to manage this material.

So we've determined the purpose which management had in mind before we started the project. Now what do we do with this information.

First we create a "Mission Statement" for the project.
Then we create a "Project Scope."

I'll cover these in future posts.

The ERP Book

I was just about ready to go when my customer turned to me and asked a question that in my 9 years of consulting I had never heard. She said, “Where can I get a book on using our ERP?” I looked at the shelf above her head and I could see the user manuals sitting right there. I pointed and said, “There they are.”

“No, I mean a book that talks about best practices – something that tells me how to use it correctly, not just how the screens work.”

For a brief moment I was speechless. An image of searching Amazon.com for their ERP came into my head, and I immediately knew the answer.

“There is no such book. That’s why customers need companies like ours to help them.” I pointed to a copy of “The Goal” that was sitting on her desk. “Books like that are really your best resources to implement an ERP.”

This really bothered me. I don’t know exactly why but her words kept turning over and over in my head. While I drove away I began to think of what such a book might need to contain. The information a business would need to implement ERP. I set the idea aside...


... Now I'm here, in the blogosphere and although I've taken a shot at writing this "book" a few times in the past, I don't generally manage to get very far. I've been blogging at my web sites www.sabreit.ca and www.creativemfg.ca for a couple of years and I enjoy doing that. I finally came to the conclusion that this way of recording my thoughts (rather than trying to write a manuscript all at once) might be more successful.


This is the first of many Blog entries intended for SME businesses who intend to implement an ERP. What is an SME? It's a small and medium enterprise - certainly fewer than 500 employees, and often fewer than 100. What's an ERP? It's short for Enterprise Resource Planning, the "mother" of accounting, supply chain and manufacturing software systems.


The vast majority of books on ERP are intended for the very large business. This blog is the beginning of my attempt to create something that's more or less a collection of the information a small customer should understand. Particularly if you are a manufacturing company or industrial supplier looking for input on implementing ERP - this will hopefully be useful to you.