The New EA Paradigm 5: The Pattern: Assemble-to-Order

My goodness! Cort and I have been teaching non-stop! We have Zachman Certified just over 65 people in the last month!

OK, on with this blog...

Clearly, you have to change the strategy... to an Assemble-to-Order strategy... Mass-Customization, "custom products, mass-produced in quantities of one for immediate delivery"... but this is a completely different kind of a business.

You have to have PARTS in inventory... NOT finished goods... and those parts have to be engineered such that they can be assembled into more than one product. How do you engineer parts that can be assembled into more than one thing? You have to know the total set of things you have to assemble at any given point in time. You do the engineering Enterprise-wide. After you engineer the parts to assemble the Enterprise set of products, you can pre-fabricate the parts and have them in inventory before you get the order. Then when you get the order, the only time it takes to produce the custom product is the time it takes to map the specifications of the product in the order to the inventory of parts, pick the parts and assemble the custom product to order.

So, the pattern is...

"Make-to-Order" ---> "Provide-from Stock" ---> "Assemble-to-Order"

Having engineered parts that can be assembled into the Enterprise set of products at any given point in time provides substantial flexibility to support changes in the Enterprise Product set. However, when products are demanded that are beyond the ability to support with the current inventory of parts, it is a matter of a "delta" to parts... not a major overhaul of the manufacturing process and the product line.

I am sure you have already figured out the Enterprise Engineering and Manufacturing equivalent for the assemble-to-order strategy. If you engineer the Enterprise, Enterprise-wide, creating the set of Primitive models as specified in the Zachman Framework and populate a database (Repository) with the inventory of Primitive Components, you could map the characteristics of the new Enterprise to the Primitive Components, pick the Primitive Components and assemble them (bind them at execute time) into a Composite implementation, dynamically, custom to the specification of the new Enterprise as required. "Custom Enterprises, mass-produced in quantities of one for immediate delivery".

This is a little over-simplification but I think you get the idea. You don't have to populate all of the Cells of the Framework, Enterprise-wide, integrated horizontally and vertically at excruciating level of detail before you produce any implementations. That is a common MIS-conception! You can populate the Framework primitives iteratively and incrementally, implementation by implementation, using the governance system to maintain the continuity and integration over time. You do have to have a Repository metamodel that maintains a separation of the independent variables and allows you to dynamically bind Primitive Components into Composite implementations. I have written another book on Models and Metamodels that elaborates this issue.