Strengths and Weaknesses

This particular post isn't exactly in line with the other ones I've been writing, but it's something that I think is important in many elements of business.

Over the years I have come to the conclusion that knowledge of your own strengths and weaknesses, and by extension the knowledge of your own staff of their strengths and weaknesses is essential in successfully executing almost any activity in a small business. There are a lot of reasons for this and a lot of examples I can give, but basically in a nutshell small businesses have many people who wear many hats. If those people try and wear a hat that doesn't fit them, bad things happen.

In larger organizations, employees can find their way into (and are often carefully moved into) very specific roles and silos where they can shine. These kinds of roles can play to their strengths and overcome their weaknesses by providing narrow focus. Human Resources departments have different techniques to identify the strengths of their employees, and therefore are good at putting them into these cozy round holes.

In smaller companies, we (I am lumping myself in with these small businesses) don't have formal HR departments with all the abilities and skills the larger companies have. We also don't have the narrow focus positions and roles where we can snugly fit someone who is really good at one and only one thing. We end up spreading our "hats" out over all of the people in the organization, and when we do this we often end up with less than ideal placement. This is not to say that we should or could afford to hire all those specific skill sets. It is also not to say that people don't "try" and do the best they can. It's just a fact that we can't be sure to put the absolute best person in each role we have. We need to settle.

As a good friend of mine says often, "people work hard and do the best they can - they really want to do a great job - but they simply don't have the skill or education to do any better." I will go one further and say that they have found themselves in a place where their personality is not really suited to the job. There are often jobs that they are really great at, but those are only part of their duties. In other areas, they can sometimes pull down an organization or process because despite their best efforts, it's just not what they are good at.

If we need to settle, then how can we know that we've not just put a person in who is not the best, but we have not in fact selected someone who is BAD at the job. This leads to a second problem we have. We ourselves (as business owners) often uneducated and lack experience in many of the areas if the business. We are literally "making it up as we go" in many, many cases. Particularly things like sales and marketing, accounting, management, project management etc... are not usually an entrepreneurs strong point.

This might even explain why businesses that have lasted 5 years have passed some magic threshold of survival. Could it be that the entrepreneur that started it has to have developed some of those ancillary skills to be able to keep the business running? Could it be that by 5 years, we've learned the bare necessities of marketing, sales, administration, accounting etc. We can get by with what we know and the business can grow?

Once we reach a certain point, we start to delegate some of these skills that we are moderately good at to others. The others that we delegate to are often chosen because they are available - they're the body that can breath that we throw into the job. This can be a terrible mistake, especially in a small business. I have made my share of such mistakes, and I've seen the same mistakes made by those who should know better and have "executive" experience and great pedigree. The mistake these "senior" folks make is that they do not account for their own strengths and weaknesses, and this gets them into serious - and I mean serious - trouble.

I've hired a manager who was really awful at doing paperwork, and he refused (or avoided) preparing sales contracts. He would not delegate to someone who covered his weakness - he was too proud to do that. We were stuck with receivables we couldn't collect because the customer never signed anything that outlined their responsibility in a project. Similarly I've had a manager who really did not know how to deal with conflict but refused to let someone who was good at it intervene. In his case he was so overly concerned with the customer's reaction to an unpleasant conversation that he refused to allow anyone else to even speak to them. In the end they pissed off the customer so badly that we lost all work from them for over 3 years.

The gist of my blog today is to be very, very cautious as a business owner that you are clearly and completely aware of the weaknesses and failings of everyone in your organization. People will do their best to hide what they are not good at. They will hold on as tight as they possibly can to those activities and responsibilities they cannot do. It is up to you to push back against them as much as you possibly can. You also have to watch for the same behavior in yourself and be honest if you really need to step away and delegate.

LEAN ERP

It's been a long time (I was very surprised to see that it's been since December) since I blogged. I'm not usually that bad at keeping up with things. Certainly my goal of having enough posts to publish this as a book is going to fall apart if I don't post more often. Hopefully I can get back on the wagon now that the weather is nicer and I don't have to shovel or struggle through snow (although they say we'll get one more dump this year). The new laptop will help too because I can get 3+ hours of battery from it :-)

Lean ERP?

For a long time now I've been a player in the ERP marketplace in Ontario. Most of my experience is with Visual Manufacturing (also Infor Visual ERP) but as time passes I'm learning more about other ERP systems as well. Some of the knowledge I am gaining is through training and learning other systems, like Dynamics GP - while other information is gained from competitive analysis. What i do know is that the concepts (particularly in Manufacturing) for which ERP was designed have changed in the last 20 years.

Let's take Lean for instance. The developers who released the first version of the Visual ERP would have broken ground somewhere around 1991 or 1992. That was 19 Years ago. The first release that I know of was in someones hands in 1993 when my former employer purchased it. By the Fall of 1994 they were well into their implementation, fully live and I was furiously writing reports to try and help produce information for management and staff.

In 1992 the concept of Lean was new, and no ERP at the time was implementing or even talking about it. Today (notwithstanding the problems with their recalls) basically the entire world has come to realize that Toyota was on to something with their production system. TPS (Toyota Production System) is essentially the perfection of Lean. TPS is the idealized Lean implementation. It is the goal that all other Lean companies strive to achieve. How Toyota has designed their production and manufacturing processes is powerful. They have achieved incredible profitability in an industry that has seen giants brought to their knees.

So back to ERP. In 1992 no ERP vendor was considering Lean in their design. In fact ERP from that period had a decidedly "un-Lean" approach. They required extensive data entry at the front end in order to produce forecasted requirements and demand at the back end. They pushed information INTO the ERP, and it pushed production plans INTO the plant. there was virtually none of what we now understand is the essence of Lean - to PULL materials or information through the facility. PULL - as defined by a customer's requirement to receive a product - is not the primary design consideration of the older ERP technology.

Logically some might argue the best solution is to start over. Create a new ERP system that is fundamentally designed to be Lean. After all, if the old style is no longer of any use, then get rid of it.

In my opinion that would be a terrible mistake. There are a few reasons I say this:

First: ERP is consolidating. The technology is becoming simpler to understand and to implement, and fewer but larger companies are selling these solutions. If you want to be able to pull data through your ERP, you better be able to connect your ERP to your customers and vendors. Choosing a well established product with a large install base would be critical to achieving this.

Second: Just because Lean (TPS) is the ideal goal, doesn't mean you can leapfrog from your current systems to a "Lean" ERP with one Hail Mary. Companies that try and implement Lean without the nearly 60 years of supply chain improvements that Toyota executed can put themselves into a worse position than if they do nothing. Implementing Lean means massive fundamental changes to business. Choosing an ERP that would require those changes to have been made would be suicide if you are not ready.

Third: There is no reason that existing ERP systems can't become Lean. For any technology to be powerful, it needs to be flexible. We have specialized in designing ERP solutions that are Lean and "Bolt On" to the Visual ERP for years now. If we can do it what's to stop Infor, Microsoft or any of dozens of other ERP vendors from doing the same.

So what makes an ERP Lean anyway?

A core concept in Lean is that it's about PULL rather than PUSH. So what about an ERP can switch the model to PULL where in the old days it was PUSH.

In an ERP we believe this is all about the ERP pro-actively pulling information out of the stake holders in the process. EERM (Extended-Enterprise Resource Management) is a new term being coined that in essence is taking an ERP and extended tendrils out into your supplier and customer bases. EERM technology is not about data entry and forecast retrieval. It's about data entry and INFORMATION retrieval. EERM by it's nature reaches out to the different stake holders and pulls information into itself from them. It then allows other key individuals to pull information out of the system if required. However, EERM still supports the older forecasting and MRP models. Why would it do this if it's the new technology?

It does this because we can't throw the baby out with the bathwater (to use a euphemism). Until a business's supply base is as strong as Toyota's, they will still need the ability to forecast. Outsourcing to lower cost regions (which I'll discuss later as well) means that we have 5 to 7 week leadtimes (at best) to get materials if we don't want to give up 100% of our cost advantage to shipping.

Lean is not just Kanban and two-bin and poke-yoke. Lean is about measuring and adjusting. Measuring performance and adjusting processes when they are not generating the performance we expect. Kanban is a tool used to increase performance, but it took Toyota years to identify how to execute Kanban effectively, and trying to implement a cookie cutter approach is bound to fail. It's the measurements that Toyota implemented in their system, to track and understand every nuance of their manufacturing process that allowed them to invent Kanban, and know when and where to use it.

The Lean ERP measures the business in ways that older ERP were not able to. It generates score cards for executives so that they can respond to challenges before they become crisis. Older ERP can only provide you with a static view of what changed over some period. The Lean ERP shows you the RATE OF CHANGE. You can't necessarily see into the future, but if you can watch the TREND you can get ahead of it. That is the critical element in managing information and businesses - not the here and now - but the trend. If you're not ready for where that is taking you, things will fall apart.

So how does Lean ERP manage the Trends? Let's take a look at an example.

You purchase materials from China that go into a major assembly that you sell to your customers. In the traditional ERP world, you would implement a sales forecast which would generate an MPS. Weekly or monthly you might send the Chinese Supplier that MPS. As your sales begin to decline or your sales hopper begins to decline, reports need to be run and managed in order for users to identify that something is happening and to communicate to China to slow down their shipments. You can't do anything about the 5 weeks of goods on the water - but if you can slow down their deliveries...

The fact is many companies don't let the Chinese supplier know in time.

Now you change the model subtlety but critically. The Chinese Supplier has a vendor portal that allows them to see critical information from your Lean ERP that YOU WANT THEM TO SEE. Included in this are the total quoted items that use their products, the total on-order and the total on the water. The trend lines for all are shown to them.

A few weeks before you get back to them that maybe they should slow down their shipments, they're already there. They've looked at your sales and see the movement. Maybe they've picked up a trend that indicates some secondary product is picking up. They are managing themselves because they have the INFORMATION that's been bottled up in your system. You don't have to show them proprietary information. You don't need to show them other vendor information. You can show them product quality trends, rework costs, open quotes that would require their parts (just the quantities, no names or dollars). You can let them pull information out of your system instead of them having to wait to receive this information from you via a push.

To go further, you can pull information from that Chinese supplier so that you can see when they have shipped their parts The Lean ERP lets our customers see that we've got materials en-route from our supplier that are needed for their goods, and that they will be able to get them on-time. It allows us to communicate with each other in a more powerful and dynamic way. It may actually be the beginning of the Lean Enterprise - the interconnected business system in which the entire supply chain can become Lean.

Of course Lean ERP supports concepts such as vendor supplied inventory, kanban component and sub assembly manufacture, reorder point eKanBan and other essential tools required for Lean. The older ERP that needed to have hard core MRP in it to support manufacturing and production processes is dying. ERP needs to turn in a new direction. The extreme levels of sophisticated forecasting, MPS and MRP have been proven to fail when market conditions fail (just look at GM and Chrysler - who bet their companies on these technologies).

The next step beyond the current ERP, and what really constitutes the Lean ERP is EERM - Extended Enterprise Resource Management. I'll touch on that in a future Blog.

For more information on this visit our website at http://www.creativemfg.ca or http://www.sabreit.ca

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.