Modular Function Deployment (MFD)

1. What Is Modular Function Deployment (MFD)?

Modular Function Deployment (MFD) is a product-engineering framework for deciding which technical solutions should become modules, how those modules should interact, and what business purpose each boundary serves. It connects customer requirements, engineering choices, and company priorities to a modular product architecture—not simply a collection of reusable parts. Product-architecture consultants use it to structure cross-functional design decisions.

For producers of industrial machinery, the central question is where to preserve commonality and where to allow variation. MFD helps teams evaluate whether different capacities, tooling options, controls, or service requirements justify separate modules rather than repeated redesign of entire machines.

2. Origin and Background

Gunnar Erixon developed MFD through research at KTH Royal Institute of Technology during the 1990s. His 1998 doctoral thesis, Modular Function Deployment: A Method for Product Modularisation, formalized the method. Anna Ericsson and Erixon subsequently presented it in the 1999 book Controlling Design Variants: Modular Product Platforms, published by the Society of Manufacturing Engineers.

The method addressed product modularization according to company-specific needs across the product life cycle, rather than technical decomposition alone. Industrial applications were already documented in Erixon’s 1997 paper, including mobile winches, truck couplings, and servo drives. Manufacturing applications therefore belong to its original context, not a later industry adaptation.

3. How Modular Function Deployment (MFD) Works

The name reflects three connected ideas:

• Modular: Define building blocks with controlled interfaces.
• Function: Start with what the equipment must do, rather than existing part numbers.
• Deployment: Carry requirements and business priorities into architecture decisions and module specifications.

The original method contains five iterative stages. These connect customer requirements to technical solutions, module concepts, concept evaluation, and detailed improvement.

Module drivers: the distinguishing mechanism

MFD’s traditional twelve module drivers express reasons for creating modules. They span six areas, rather than treating modularity solely as an engineering concern:

• Design and development: Carry-over, technological evolution, and planned design changes.
• Variation: Different specification and styling.
• Manufacturing: Common unit and process or organization.
• Quality: Separate testability.
• Purchasing: Supplier availability.
• After-sales: Service and maintenance, upgrading, and recycling.

The Module Indication Matrix (MIM) relates technical solutions to these drivers. Strong relationships identify potential module candidates; driver profiles help explain boundaries. For example, a stable frame may warrant common-unit treatment, while electronics may warrant separation because technology changes faster. Scores support judgment—they do not establish an optimal architecture automatically.

Current training also explicitly addresses module interfaces, variants, configurations, and architecture feasibility. These are useful extensions when the intended output is a configurable equipment family rather than one modular machine.

4. When to Use Modular Function Deployment (MFD)

MFD is especially useful when an equipment producer must support recurring customer differences without recreating engineering work for every order. Consider it during platform renewal, consolidation of overlapping machine families, transition toward configure-to-order selling, or redesign intended to make maintenance and upgrades more localized.

A useful analysis needs customer requirements, order histories, bills of materials, engineering-change records, production routings, supplier constraints, and service experience. Involve mechanical, electrical, and controls engineering alongside manufacturing, purchasing, sales, service, and finance. Modular design requires cross-functional participation and upfront investment; it should not be assigned to engineering alone.

Use MFD when requirements can be represented meaningfully and interfaces can be controlled. Be cautious with genuinely one-off installations or designs where tight integration dominates performance. An analysis of one representative machine can also mislead when extrapolated to an entire family: research comparing modularization methods found that family-level results required particular care.

5. How to Apply Modular Function Deployment (MFD): Step-by-Step

The following workflow expands the framework into practical tasks for an equipment-platform project.

1. Clarify the decision and scope.

   Define the machine family, customer applications, performance range, geographic markets, and platform life. Agree whether the decision concerns a new architecture or restructuring existing products. Specify which legacy orders and installed machines must remain supported.

2. Gather requirements and establish the baseline.

   Interview buyers, operators, and maintenance teams. Translate needs into measurable design requirements using Quality Function Deployment. Assemble order-level configurations, component costs, engineering hours, assembly effort, commissioning issues, and service records. Separate recurring costs from transition investment.

3. Define functions and select technical solutions.

   Describe functions such as transfer material, position workpiece, deliver force, or control motion. Compare alternative solutions before accepting today’s assemblies as tomorrow’s modules. Use technical solutions—not departments, suppliers, or sales model names—as the initial analysis units.

4. Construct the module matrices and architecture map.

   Assess each solution against the relevant module drivers in the MIM. Agree a scoring convention and document evidence. Sketch alternative groupings, then map mechanical, electrical, fluid, data, and control interfaces. Record which requirements each proposed module must satisfy.

5. Evaluate complete concepts.

   Compare architectures against performance requirements and business objectives. Include interface hardware, tolerances, assembly sequences, test equipment, spare-parts implications, and engineering reuse. Examine representative configurations across the family, including demanding combinations—not only the easiest machine to modularize.

6. Test sensitivities and competing assumptions.

   Change assumptions about order mix, production volume, supplier availability, technology replacement, and maintenance frequency. Identify boundaries that remain attractive across scenarios. Challenge disputed driver scores separately from financial estimates so stakeholder preferences do not disappear inside a weighted total.

7. Improve modules and plan industrialization.

   Convert the preferred concept into module specifications, interface definitions, detailed designs, and permitted configuration rules. Assign development budgets and owners. Prototype critical connections, establish module tests, and plan tooling, supplier qualification, pilot builds, and legacy-product transition.

8. Align stakeholders and iterate.

   Have engineering, operations, commercial, and service leaders approve the trade-offs. Establish ownership of interfaces and authority to approve exceptions. Revisit the matrices when testing or customer evidence changes assumptions, rather than protecting the first workshop’s answer.

For implementation, use program management support to synchronize interface approvals, supplier readiness, pilot builds, configuration-data release, and legacy support. The architecture decision is only the starting point for those dependencies.

6. Example: Modular Function Deployment (MFD) in Action

Consider Northline Packaging Systems, a fictional producer of packaging machinery. Its case packers share similar functions, but successive customer projects have generated incompatible frames, handling mechanisms, and controls. The engineering director selects MFD to determine which differences deserve deliberate variants and which reflect avoidable historical divergence.

The team analyzes machine bases, product-handling mechanisms, sealing solutions, and servo-control assemblies. Inputs include customer throughput and changeover requirements, order configurations, assembly records, commissioning defects, and service calls. The MIM indicates strong carry-over and common-unit drivers for the base, different-specification and service drivers for handling equipment, and technological-evolution and separate-testability drivers for controls.

The team proposes a shared base within a defined load envelope, interchangeable handling variants within approved interfaces, and independently testable controls. It rejects a universal base covering every application because the largest load case would impose unnecessary cost on smaller machines. Two bounded platform sizes provide a better compromise.

The subsequent product design work turns these choices into drawings, interface specifications, validated module variants, and assembly fixtures. Northline pilots contrasting configurations and tracks engineering reuse, assembly effort, and commissioning defects. Benefits remain hypotheses until the pilot and subsequent orders demonstrate them; this example supplies no industry benchmark.

7. Strengths and Limitations

Strengths

• Connects architecture to business intent. Module boundaries can reflect customer variation, supplier capability, testing, and service—not only physical convenience.
• Creates a common decision language. Commercial, engineering, and operations teams can explain why a boundary exists and what it must protect.
• Makes trade-offs traceable. Requirements, technical solutions, and modular concepts remain connected, supporting review of alternatives rather than undocumented design preferences.

Limitations

MFD does not guarantee unique or optimal module boundaries. Assessments depend on judgment, and different modularization methods can produce different architectures. Nor does a coherent module map automatically solve assembly: research has identified weaknesses in bringing assembly-sequence and joining considerations into early MFD decisions. Supplement the method before interfaces become expensive to change.

Treat machinery safety as a whole-system verification issue, not something established by a favorable modularity score. Machinery risk assessment addresses hazards across relevant life-cycle phases; module-level testing should inform, not substitute for, that assessment.

Reject proposals whose extra connections, structural compromises, or transition costs outweigh their benefits. Also test whether commonality concentrates dependence on a single supplier or component.

8. Common Pitfalls and How to Avoid Them

• Renaming existing assemblies. Historical assembly boundaries may encode yesterday’s compromises. Begin with functions and requirements, then justify which boundaries should survive.
• Scoring without evidence. Workshops can amplify departmental preferences. Record the customer, technical, or operational evidence behind each important driver relationship.
• Maximizing commonality. A universal module can impose excess capability and cost on simpler machines. Evaluate bounded platform sizes and purposeful variants.
• Ignoring controls dependencies. Physical compatibility is insufficient. Specify communication behavior, firmware compatibility, timing, and fault responses alongside mechanical connections.
• Counting savings too early. Fewer designs do not automatically mean lower total cost. Include interface hardware, qualification, inventory transition, and installed-base support.
• Allowing uncontrolled exceptions. Customer-specific departures can undermine the architecture. Require explicit approval, documented economics, and an owner for each exception.

9. How Modular Function Deployment (MFD) Relates to Other Frameworks

Quality Function Deployment: establish what matters

Quality Function Deployment (QFD) translates customer expectations into technical requirements. It normally comes first and is already embedded in traditional MFD. Use QFD alone when the immediate problem is requirement prioritization; use MFD when the team must also determine product boundaries.

Design Structure Matrix: reveal technical coupling

A Design Structure Matrix (DSM) maps interactions among system elements. Use it alongside MFD to expose dependencies that complicate proposed boundaries. DSM emphasizes coupling; MFD adds business reasons for separation or grouping. For tightly integrated machinery, understanding interactions may be the necessary first diagnostic.

Design for Manufacture and Assembly: make the architecture producible

Design for Manufacture and Assembly (DFMA) examines how parts are made and assembled. Bring its considerations into concept evaluation, then apply it more deeply as module designs mature. A commercially attractive architecture should not reach tooling approval with unnecessarily difficult fabrication, handling, or joining operations.

10. Key Takeaways

• MFD connects customer requirements and business priorities to defensible product-module boundaries.
• Module drivers explain why a technical solution should be separate, shared, or deliberately variable.
• Analyze an equipment family and its configurations, not just one convenient machine.
• Controlled interfaces, manufacturability, testing, and service requirements determine practical value.
• A module map is not implementation: validate the economics and govern exceptions.

11. FAQs About Modular Function Deployment (MFD)

What is the difference between MFD and QFD?

QFD establishes which customer needs should become technical requirements. MFD uses that foundation to develop and evaluate modular architecture choices, incorporating company priorities through module drivers.

Does MFD make every module interchangeable?

No. Define interchangeability within an explicit platform, interface specification, and approved configuration set. Do not assume that physical fit proves equivalent performance, compatible controls, or acceptable system behavior.

Can smaller equipment manufacturers use MFD?

Start with one recurring machine family, a manageable function map, and a spreadsheet-based MIM. Keep the analysis proportionate, but retain customer evidence, cross-functional review, and interface ownership.

How long does an MFD project take?

Separate initial architecture exploration from validated industrialization. Timing depends on product-family breadth, data quality, technical coupling, prototype needs, and supplier qualification. Define milestones around decisions and evidence rather than promising a universal project duration.