IN Blind Pursuit of Technology

Today I am reminded of one of the more memorable installations I have done over my career.  As it always seems to turn out, the more difficult jobs bring greater reward for the client and for me as well. 

The company I was working with had purchased a rather good ERP package from a local vendor. I learned, to my dismay, that this was their fourth attempt at installing a system in the last six years.  Each prior installation had failed to bring the results they desired.  In fact, they had gone to litigation with one of the last vendors because they felt they had been misled.  I was beginning to wonder what I doing was there. 

During my initial consult with them I inquired as to their perception of why they had failed in the past.  The answers made it pretty clear that they really didn’t have a good understanding of it.  It was the software, it was the consulting advice they were given, it was them…you could tell they weren’t sure of anything.  

They did feel that their business had some very special needs.  And, interestingly enough, they had very strong opinions on the things the software should deliver.  They felt the issue was that they had failed to find software that could do all the things they needed it to do.  I smiled.  Here’s a little background of their business. 

Half of their product line had a seasonal sales cycle.  The other half was less seasonal, but still had spikes.  During peak months the demand for their product dramatically outstripped their production capacity.  And so we have the typical cycle of a seasonal manufacturer.  These types of companies will employ strategic inventory to draw from when peak output cannot meet demand.  Unfortunately, this didn’t work for them because they allowed attributes, such as color, to be specified by the customer during the ordering process.  This meant that they couldn’t forecast past a certain point.  The typical strategy here is to build popular component part stockpiles and ensure the manufacturing process can meet peak capacity in the required workcenters. Support departments try their best to fill in the gaps in the product mix as they occur.  This way you don’t have to gear up the whole facility, just part of it. 

From a software perspective this simply meant they needed and inventory/MRP based system.  Nothing that you would classify as a “special need” so far.  Here’s the basic layout for any inventory system.  There are three types of orders that drive everything: 

Sales orders, which place demand within the inventory system 

Work orders, that supply component parts and finished goods.  They also consume materials. 

Purchase orders, that supply raw materials. 

Now, creating a sales order at this client was a problem because orders were frequently taken and processed without the customer specifying the variable attributes such as colour.  These were left as “to be determined”.  The perception was that giving manufacturing whatever information was available would allow them to jump-start the process.   Now as far as the customer was concerned, the lead-time clock was ticking even though the details weren’t finalized.  And, as could be expected, sometimes there were delays in getting the missing info to manufacturing in time.   And this frequently made them late. 

This company really had a great line of products.  The design allowed it to be put together in a great number of different configurations.  And, if they didn’t have the required configuration, then they would build it as a “special”.   So, creating a work order was a problem because the number of bills of material required was staggeringly high.  In many cases, you literally had a different BOM for each time the product was built.   I’ll tell you, learning their product was a trial.  Oh, and they didn’t use part numbers for most of their stuff but that is another story. 

Now, most vendors will tell you that you need a tool called a product configurator to meet the demands of these types of businesses.  This sounded logical to my customer so the current package had a great configurator.  And, truthfully, some of the product was ideally suited for use with a configurator.  Trouble was that a significant portion of it wasn’t.  There were simply too many combinations.  Worse, some options mandated that other options had to be changed. In fact, there was a whole hierarchy of decisions that had to be adhered to.  Software that does this is referred to as a “parametric configurator”.   So they bought one. 

Yes, they believed the configurator was indeed the solution to their problem.  Software salesmen had told them so, so it must be true.  (Breaking up laughing now).  Their pursuit of it had seen them buy one, but once they really tried to use it, it proved that it wasn’t functional enough.  The second one was better but the amount of data entry required was high.  While it was, perhaps, worse than normal, they should have got the message at this point.  But, instead they were told that it was a matter of finding one that was flexible enough.  So they decided to buy a software package with a very strong configurator and then paid to have it enhanced to a specification that would be created through analysis.  It was the right approach.  Now, they thought, we will have the tools we need.  So, back to the parametric configurator. 

The first point I want to make about a parametric configurator is this…entering data into one of these babies has a lot in common with General Relativity.  It’s very complicated.  There’s also a lot of data that needs to be entered for each combination.  And they had a huge number of available combinations.   As I looked closer, the bottom line seemed to be that the amount of data entry required to support the configurator for much of their product offering was just staggering.  If they had been a larger company with more manpower then….maybe.  But they weren’t.  So they couldn’t do the required data entry.  

When I got the call they were 12 months into this installation.  The company was angry at the software vendor.  They felt they hadn’t delivered the required configurator specification.  The vendor was also angry with the client.  They felt they had gone over and above the required specification and had gone to great lengths to make the data entry process simple and effective.  The system was partially installed and working well in those areas.  The configurator was working well for the standard segment of their product line.  When I checked the capabilities of the configurator I was surprised to find that it did indeed do what was advertised.  In fact, it may be the strongest configurator I’ve seen.  It would handle virtually anything they could throw at it.  And the data entry task was about as simple as it could be for something that could produce data that complex. 

My investigation concluded that there were two major issues.  First, the configurator was complicated.  They had never used anything like it before.  Kind of like trying to scale Mount Everest the first time you go rock climbing.  Secondly, the amount of data required to cover all of the options they offered was absolutely huge.  And there weren’t enough people to do it that had the required product knowledge.  It was simply a task that was so large they didn’t know where to start.  And even if they had, they wouldn’t have finished it for a very long time.  And then there’s the ongoing data maintenance….it was just too much to bear. 

Solving this problem required making a few rules, and simplifying the product structure.  Because the product was so configurable there was a certain degree of engineering that was going into each product.  So we trapped this process on the system to create the product structure.  It’s manual, but it follows the process well.  It also negates the need to create all the configurations because they simply configure it as they go, manually. 

The biggest overall problem I had was convincing them they didn’t need what they had spent all this money on.  It took them quite a while to let go of the old concept and accept the new one.  But, in the end, the results proved to them that it was the right choice.  There were orders flowing for the first time.  As it turns out, the first system they bought probably would have done the job for them if they had only had the right concept in hand prior to purchasing. 

This just goes to show that pursuit of automation only works in situations where a manual process isn’t the right choice.  Sometimes, doing it manually is the most effective way.  It’s all about having the right concept in hand and good picture of effort vs benefit.   Integration with the business process, and managing the amount of data you need to generate will always be key success factors in business software implementation.