PSI LogoParadigm Shift
International

USA-505-586-1536

OtherWise


A new guest appears monthly, and the prior wisdom is archived in the Library.
Register for free email notice when monthly update occurs.


Featured Guest Speaker
Posted: July, 1999

Jack Ring
Owner, Innovation Management, Scottsdale, AZ

Current Enterprise Models are
In Conflict with Mass Customization
Copyright 1999 Jack Ring


Editor's Note: I met Jack Ring in the mid eighties when he investigated the new modeling tools our company had developed for designing and operating complex manufacturing systems. Over the years our paths have paralleled and even coincided many times. One of his major pursuits is the nature of enterprise, and how you can model and manage this complex adaptive system of people, resources, and opportunities. Ex-GE, Jack spends most of his time mentoring management in new ventures, and is always at the frontier of new enterprise modeling theory, practice, and tools for management. This essay of his raises serious questions about the disconnect between conventional management tools, like ERP, and the strong trend toward mass customized and parameterized product.


Caution Dramatic Changes Ahead

On the road to mass customization successful suppliers will learn to survive three dramatic changes:

  1. no more part numbers or SKUs (stock keeping units),
  2. no more forecast errors, and
  3. committing company resources instead of just inventory items.

Very few companies will survive in the mass customization era because they will not be able to adapt at the speed of opportunity. Those dedicated to Enterprise Resource Planning (ERP), Sales Force Automation (SFA), Customer Resource Management (CRM), Advanced Planning Systems (APS) and other current forms of enterprise information technology applications are likely to struggle harder and longer – then fall louder.

There will be no SKU’s or part numbers because the product function, feature, form, fit and finish will not be decided until order time. Products will not only be produced at time of order but will be designed at order time. Designing in advance whether in response to focus groups or to marketing's demand to generate catalog options will become passe'. The purchase order number becomes an adequate label for the deliverable artifact. Of course a number of commodity-level components may be incorporated into the product, and these may have part number identifiers; but that world of commodity parts will be operated by low margin businesses who are suppliers to the mass customization industry.

Mass customization producers will operate in a KanBan mode and replenish just-in-time; made feasible by lead times that have shrunk to only 5% of current lead times. There will be no sales forecast errors because there will be no forecasts. Instead there will be a new type of forecast: a probabilistic expression of the anticipated loading of both production and engineering resources. This forecast will be continuously and incrementally transformed to actuals as each order occurs at each point of sale, or even at an earlier indication of customer intent. Forecast errors will occur only when the market changes faster than the factory’s set up time, which will be minutes, not months – so forecast errors will be negligible.

But if a company cannot sell product from inventory, then what is the customer buying? The mass customization customer is buying a segment of time of the supplier's know how and resources. The supplier will operate the enterprise during that time segment in conformance with the customer's purchase order. What a different business model – a services business that produces hard goods!

Any enterprise which cannot change its product, process, technology, structure and even culture at the pace of customer orders is doomed to the lower financial rewards of commodity industries. Change proficiency will become a standard metric on the survivor’s scorecards.

When viewed from any one factory or store, this scenario may seem challenging. When mass customization is considered across a five-level supply chain the scenario tends to be incomprehensible. But don’t let skepticism or the unknown overwhelm a willingness to consider possibilities. Chaos theory gives us some clues about "herding these butterflies" toward levels of ROI that would thrill manufacturers, today.

Parameterized Products

Mass customization is giving rise to a new type of product different than current standardized and configurable product approaches. This new type may be called a parameterized product. Parameterized products are not new, but have not been acknowledged in most textbooks and business models, let alone enterprise applications. Let's compare.

Standardized products such as machine screws, lumber, electrical outlets and video tapes are what they are because their function, feature, form, fit and finish are specified by standards bodies, and hardly any customer would want one that was different. High stake battles are fought during the standardization process (VHS vs. BETA for consumer video tapes and more recently the HDTV standard); and the goal is to minimize variety, expecting everyone to use identical products.

Configured products give customers more choice. Henry Ford knew he could not get away with "... any color you want as long as it is black" for very long.. In 1980 the automobile salesman was asking: "Which of these 31 options do you prefer?" And the automobile production manager had to build several thousand different configurations. In the configured product game, engineering is challenged to design not an automobile but an automobile framework that can be manifested in a variety of options. This is called the framework-and-module mode of production engineering.

Giving customers a choice is fundamental. Doing so with configurable products is good; providing that the cost of optioneering does not drive up the cost of any one configuration. Two decades ago Digital Equipment Corporation used an expert system software package to help their salesmen and their customers make option choices. That one computer program is reported to have saved DEC several million dollars. Great news. But think how much DEC had been wasting before then. Also consider that this one computer program probably avoided only a minor percentage of the "overhead" associated with configurable products. Today the leading personal computer suppliers have adopted the framework-module mode of customer choice. They are in an interesting game.

Parameterized products give customers a choice as well, but in a fundamentally different way, with a different profitability opportunity. Parameterized products have a set of attributes, each of which allows customer choice within limits. The allowable limits on one attribute may change as a result of a choice made on another attribute. Consider, for example, a customer ordering a roll of sheet steel. A customer can make choices about the grade of steel and about several other attributes such as gauge, width, length, finish, annealing schedule, Rockwell rating, etc. Now, suppose the customer's own production facility cannot handle a roll larger than 16 feet in diameter, nor one that weighs more than x tons. Accordingly, when the customer makes a choice about gauge and width, the ordering program can calculate the new limit on length and roll diameter.

The "gray goods" industries, such as metal rolling mills, textile mills and paper mills produce parameterized products almost exclusively, and help their customers do attribute-based ordering.

In the early 80's GE's Large Steam Turbine business turned from making new turbines to making replacement parts for turbines that had been in service for 10 to 20 years or more. This is about half way between configurable products and parameterized products. The management solution involved representing the design engineering staff as "resources" in their (heavily modified) MRP II system, so that they could plan and schedule both the factory production machinery and the "blueprint production machinery" before giving a customer a commitment. The switch was made from blueprints to programmable logic controllers at the same time. Engineering only had to transmit the set points for about 23 parameters and the factory to make replacement "buckets" ranging from one you could hold in the palm of your hand to one over ten times that size with a different airfoil shape.

Not as visible are the billion dollar industries such as ASIC (application specific integrated circuit) foundries and cable news networks. Another industry, adult education, is breaking away from the configurable degree program (core and optional courses) typical of universities, and are now patronizing the more parameterized distance learning opportunities springing up on the internet. Even the internet search engines enable attribute-based information selection, though still in the Model T stage.

Impact on Enterprise Applications

What, then, is the fate of pre-configured enterprise applications such as ERP, SFA, CRM, and APS? Enterprise applications which are not inherently agile and easy to evolve freeze their owners in time and (market) space. Information technology, which is supposed to automate and accelerate information and decision, becomes the problem – stifling innovation and competitive pace. Non-malleable enterprise applications were acceptable in the old days when things were done by guess and just-in-case. The enterprise applications of the current era may still be used in the commodities industries. But in the higher value-added mass customization industry a significantly different kind of enterprise software will be needed..

Last year, as the story goes, an unsuspecting U. S. manufacturer in the parameterized products business let a leading ERP vendor talk them into representing the product parameters envelope with a set of SKU numbers. Several million dollars and 23,000 SKU numbers later the ERP project was abandoned.

And this is not unique. In almost all enterprise applications the software designers assumed the software would be reflecting standardized products, or at most, configurable products. Converting this software to attribute-based ordering of parameterized products is next to impossible. Pasting on adjuncts doesn't really meet the need.

A whole new generation of software is needed. Software which allows the customizing salesperson to reach into your company beyond the inventory stockroom, beyond the production line, beyond the upstream process and production planning, all the way to engineering – and get a rolling answer back up the line in order to make a customer commitment in a matter of minutes.

Customer Commitment Management may become the name of the game.


Jack Ring, Innovation Management
Scottsdale, AZ, 480-488-4615
jring@amug.org


Would you like to offer some thoughts or add to the dialog? Responses of general interest may be posted below. Send your comment to . IMPORTANT: Make sure the subject line of your message contains: Comment on Guest Speaker 7/99.
========= Reply =========================
From: gsinc@gen-strategies.com (W.M. Jaworski), Date: Tue, 20 Jul 1999
Re:"Several million dollars and 23,000 SKU numbers later the ERP project was abandoned".
Wrong implementation technology (SKU, ERP) was not responsible for the failure of the project. "New generation" technology|software is needed to allow effective management of knowledge (innovation) intensive projects|domains. The challenge is to create a knowledge communication technology supporting domain|application developers|managers AND software designers. Agility paradigm, system principles, enterprise models, response ability etc. provide bench test for such technology.

========= Reply =========================
From: Jack Ring jring@amug.org Date: Tue, 20 Jul 1999
I agree with Dr. Jaworski's assertion that "New generation" technology/software was needed in the case I mentioned. But I am puzzled about his reasoning because if "new" is needed then it must be true that the "old" (ERP with SKU's) was inappropriate. In fact, the product line was described by about 20 attributes each of which presented 10 to 20 choices and most of the choices were interrelated. In the face of this, the ERP vendor chose to describe this universe of choices with a list of SKU's, apparently oblivious to the mathematics of "the number of combinations and permutations of n things taken m at a time." On the other hand a knowledge communication solution may not be necessary. A "common sense" communication solution often can be quite effective.

========= Reply =========================
From: "W.M. Jaworski" gsinc@gen-strategies.com Date: Wed, 21 Jul 1999
I belive that using an Agility or equivalent "innovation management" technique BEFORE producing thousends of SKUs would save or cancel the project at the specification phase.

>The ERP vendor chose to describe this universe of choices with a list of SKU's, apparently oblivious
>to the mathematics of "the number of combinations and permutations of n things taken m at a time."
This is a "common sense" and true statement. Unfortunately too late for the client. I learned - the hard way - that in the non-repetitive cases my intuitive "common sense" solution is not always appropriate. Using a knowledge representation technology helps me to produce THE solution. To quote Rick Dove (
http://www.parshift.com/Essays/essay055.htm) "In between a solution and THE solution to a problem lie a lot of questions, mostly never asked." I see a clear distinction between knowledge communication technology|methodology (for ex. Agility) and system|software development technology (for ex. ERP, UML, C++). BTW, I did enjoy and learn from your 'Current Enterprise Models are In Conflict with Mass Customization'
(
http://www.parshift.com/Speakers/Speak018.htm). -- Best regards, W.M. Jaworski.

========= Reply =========================
From: Jack Ring jring@amug.org Date: Wed, 21 Jul 1999
>I belive that using Agility or equivalent "innovation management" technique BEFORE producing thousands >of SKU would save or cancel the project at the specification phase.
That was my point. I was giving an example of what happened to a business which needed systems that were better matched to agility but chose ERP which does not recognize such constructs.

>This is a "common sense" and true statement. Unfortunately too late for the client.
Yes, unfortunate. The sad thing is that the ERP vendor continues to hoodwink unsuspecting clients.

>I learned - the hard way - that in the non-repetitive cases my intuitive "common sense" solution is not always >appropriate.
I do not equate intuitive (the irrational plane) with common sense.

>Using a knowledge representation technology is helping me to produce THE solution.
I do not doubt that.

>I see a clear distinction between knowledge communication technology|methodology (for ex. Agility) and >system|software development technology (for ex. ERP, UML, C++).
In fact, UML is the biggest deterrent to knowledge communication I have seen since the Tower of Babel.

>BTW, I did enjoy and learn from your 'Current Enterprise Models are In Conflict with Mass Customization'
Thanks for the kind words. I hope to get the time to study your work soon. Rick has recommended it highly.

========= Reply =========================
From: "W.M. Jaworski" gsinc@gen-strategies.com Date: Thu, 22 Jul 1999
>In fact, UML is the biggest deterrent to knowledge communication I have seen since the Tower of
>Babel.
Rational intensive PR campaign failed to sell UML to me too.

>Thanks for the kind words. I hope to get the time to study your work soon. Rick has recommended it highly.
I highly value RD's opinion, but please wait a couple weeks. RD's and your last submissions convinced me to revisit my draft model of Agility. I should have a better version for your and RD's comments soon. WMJ

Wise man said: "The gap between theory and practice in practice is larger than the gap between theory and practice in theory". Dr. Wojciech M. Jaworski,
http://www.gen-strategies.com/KI_Forum/

========= Reply =========================
From: ong.jc@excite.co.uk (jcong) Date: Tue, 3 Aug 1999
I am doing my research on how current planning systems can/cannot fit into the agile enterprise. In the early stage of my literature review, current planning systems (especially MRP), cannot fit into the agile enterprise due to their definitions (both planning systems and agility). I still cannot find/think of reasons out of this frame.

For your information, I have read a lot of the articles regarding agility (from paradigm shift international). I learnt a lot from these articles. Therefore, I am here to ask your opinion(s) about the problem I mentioned.
Thank you! I hope to hear from you.

========= Reply =========================
From: Jack Ring jring@amug.org Date: Thu, 05 Aug 1999
JC: I'll give you a very short statement and will be willing to expand on those aspects needing more explanation next week.

First, step away from your enterprise-planning systems and consider a petrochemical plant being run by a Honeywell (or other) process control system. The process control system has sensors and effectors, and a central unit that assesses the sensor data and decides whether adjustments to the plant's operating conditions are needed. If so, it translates those needs into settings for the control valves, pressure pumps, heaters, etc., in the plant and sends the settings to the appropriate effectors that, in turn, control the valves, pumps, heaters, etc..

To make its assessment of the sensor signals the process control system uses a model of the petrochemical plant that is embedded in the process control system, usually in the form of software.

Now, from Ross Ashby and other systems thinkers we have the laws that the controller, in order to maintain control of the subject system, must have two capabilities:
1) its embedded model of the plant must have sufficient fidelity with respect to the real plant, and
2) the controller must be fast enough to keep up with the changes exhibited by the plant (The Law of Requisite Variety).

Returning to the enterprise, we see that the enterprise is the plant and the planning system is a partial process control system. Whether the planning system helps the enterprise operate well or not depends on:
1) the fidelity of the model of the enterprise that is embedded in the planning system, and
2) the ability to evolve or morph the model and planning system at the rate and direction that the enterprise must change.

Within 1) we see that the overall content and structure of the model is a fidelity subfactor, as is the sufficiency of sensor input to keep the model updated (or informed) as to the actual conditions and events throughout the enterprise. Within 2) we see that a planning system cannot be useful if it cannot be changed (every day) to keep abreast of the enterprise content, structure, roles, responsibilities, initiatives, orders, shipments, quality indicators, productivity indicators, resource imbalances relative to customer order patterns, regulatory changes, workforce vacations and about 100 other factors. In fact, an out-of-synch planning system can produce commands to the enterprise that are destructive to enterprise customer satisfaction, reward and integrity.

We should note, as well, that the planning system cannot function properly without the rest of the process control – the sensors, the effectors, and the functionality that transforms needed plant conditions into the pattern of effector commands that will maneuver the plant toward the needed conditions.

Note, as well, that if the planning systems and its adjuncts do form an adequate, accurate and timely control system the enterprise can still suffer if the enterprise is not, in itself, sufficiently agile to keep up with its external demands (no race car driver, no matter how good, is going to win LeMans in a Citroen).

Role 1: the enterprise must be able to know what is going on in its context.
Role 2: the enterprise must be sufficiently agile to keep up with change in its context.
Role 3: the enterprise is the context of the enterprise process control system.
Role 4: the enterprise process control system (epcs) must be able to know (via its sensors) what is going on in its context – the enterprise
Role 5: the epcs must be connected to the enterprise (via its effectors).
Role 6: the epcs must contain an adequate, accurate and timely model of the enterprise.
Role 7: the epcs must be able to assess the acceptability of enterprise observed status.
Role 8: if the assessed status is not satisfactory, the epcs must be able to calculate or otherwise project the needed state of the enterprise.
Role 9: the epcs must be able to transform the needed state into a pattern of commands that will drive the effectors in the appropriate sequence and direction.
Role 10: if Roles 1 though 9 are going to keep the enterprise "in control" while it is maneuvering and evolving, then the epcs must be adaptable or changeable such that it can keep Roles 4 through 9 consistent just a little faster than the enterprise is changing per Role 2.

Now, most planning systems, especially the ERP systems. only purport to satisfy Role 8. Furthermore, they are based on technologies and initializations that are far from satisfying Role 10.

========= Reply =========================


Home | Library

Send mail to with questions or comments about this web site.
Paradigm Shift International, 2051 Lama Mtn., Box 289, Questa, NM 87556, 505-586-1536, -2430(fax)
1997/-2004 Paradigm Shift International - Attributed Copies Permitted
Last modified: December 30, 2004