In aerospace and defense, complexity isn’t the exception — it’s the rule. Every end item, whether a fighter jet, a satellite, or a next-gen defense system, is a product of deep engineering, high variability, and unit-level uniqueness. Long lead times, evolving requirements, and interdependent assemblies make every program a moving target.

Yet too often, the systems that manage these builds still rely on manual project creation, duplicated BOMs, and disconnected workflows — slowing down execution and increasing the risk of error at every turn.

It doesn’t have to be this way.

With SAP’s Production Engineering & Operations (PEO) and Project System (PS) working together, manufacturers can move beyond manual planning and instead automate the creation of end-item projects from reusable templates. The secret to scaling that automation is parameter effectivity — a powerful capability that lets you tailor each project to a specific unit without duplicating data structures.

At a time when the pressure to deliver faster, cheaper, and more precisely is only growing, this approach offers a path to:

  • Repeatable, template-driven execution
  • Unit-specific accuracy without BOM sprawl
  • Real-time responsiveness to engineering change

In this blog, we’ll walk through what that process looks like:

  • What parameter effectivity does
  • Why it’s a game-changer for engineer-to-order production
  • How to apply it step by step in SAP

Backed by SAP Community guidance, SAP Help documentation, and Capgemini implementation experience, this is a practical guide for engineering and operations leaders looking to modernize how they plan, track, and execute unit-specific builds.

Why Traditional Project Creation No Longer Scales

The engineer-to-order model is central to Aerospace and Defense manufacturing, but it places huge demands on project planning. Every end item is slightly different. Assemblies are deeply interdependent. And change is constant.

Yet in many organizations, project structures are still built manually, one unit at a time. The result is inconsistent execution, duplicated effort, and master data that quickly becomes unmanageable.

SAP’s major assembly production model introduces a modular, more scalable approach. However, without automation and effectivity controls, even this model becomes difficult to maintain. To understand why, it’s helpful to look at how the structure is organized and where complexity creeps in:

  • End items ↔ major assemblies ↔ installation kits: In complex assembly, the end item (for example, a helicopter) is decomposed into major assemblies, each built from installation kits that group real, procurable components. Projects (PS) coordinate end items and major assemblies; production orders (PEO) execute installation kits. This division of labor is intentional and standard in PEO’s major assembly scenario.
  • Consistency at scale: Creating each project by hand is slow and error-prone. The Manage Major Assembly Projects app automatically generates one project per end item (often one per model/unit), creates networks for each major assembly, and schedules network activities that carry installation kit demand.
  •  Variability without master data sprawl: With parameter (model/unit) effectivity, you maintain a super BOM and routing structure. Effectivity parameters—such as model, serial range, or customer—filter what’s truly valid for each unit, eliminating the need to clone BOMs for every variant.

The Building Blocks of Unit-Specific Project Automation

Automating unit-specific project creation in SAP isn’t just about activating a feature — it requires the right foundation. That foundation is made up of data structures, configuration logic, and reusable templates that work together to support consistent, scalable execution.

Each of the components below plays a critical role in enabling the Clean Core approach to major assembly production. When designed and aligned correctly, they allow PEO and PS to operate in sync: filtering project content by unit, mapping installation kits automatically, and keeping everything aligned as engineering evolves.

Here’s what needs to be in place:

  • Material semantics
    Define and distinguish End Item, Major Assembly, and Installation Kit using dedicated material types. Assign the model/unit effectivity type so PEO can interpret and treat them differently during BOM explosion and component assignment.
  • Versioned EBOM/MBOM and shop floor routings
    Engineering releases the EBOM; production engineering converts it into an MBOM structured around installation kits. Versioned shop floor routings include detailed, unit-specific instructions and track engineering changes over time.
  • Reference points
    Assign reference points to both BOM items (installation kits) and template activities. These act as “join keys”, enabling the system to automatically link the right kit to the right activity during project generation.
  • Project template
    Build a reusable project template with one network per major assembly and activities sequenced to reflect the build process. Include reference points at the activity level to ensure automatic component-to-activity mapping.
  • Project generation and check
    Use the Manage Major Assembly Projects app to generate the end-item project, apply parameter effectivity, link kits to activities via reference points, and validate the structure using Check Major Assembly Projects.
  • Change synchronization
    As the EBOM or MBOM evolves, use transaction Transfer Bill of Material (CN33_N) to explode and transfer changes into the live project — keeping Project System aligned with the latest engineering state, even mid-build.

Enabling Unit-Specific Project Automation in SAP: A Step-by-Step Guide

Automating engineer-to-order projects in SAP doesn’t require custom development, but it does require a precise foundation. Here’s how to configure and deploy the key components needed to enable unit-specific project automation using parameter effectivity.

1. Configure Effectivity and Material Structure

Start by defining your effectivity parameters (such as model or serial number) and grouping them under an effectivity type. Activate parameter effectivity in your change management settings and link it to unitized products in PEO.

Set up clear material semantics for End Items, Major Assemblies, and Installation Kits. Assign model-unit effectivity types so the system can interpret the role of each during explosion and assignment.

Define reference points and establish a consistent naming convention—these act as “join keys” between installation kits in the BOM and activities in your project template.

Tip: Additional parameters like customer, market, or date intervals can be added, but wildcard-heavy setups may impact performance.

2. Build and Align Product Structures

Engineering releases the EBOM. Production engineering converts it into an MBOM structured around installation kits. Parameter effectivity allows one super BOM to serve multiple variants without cloning.

Versioned shop-floor routings in PEO capture detailed instructions and track engineering change over time. Reference points are applied to both MBOM lines and the corresponding activities to enable automated kit-to-activity mapping.

3. Design the Reusable Project Template

Develop a PS template that mirrors your major assembly production flow. It should include:

  • One network per major assembly
  • Activities that reflect installation sequence, with proper logic (FS/SS/FF)
  • Reference points that match the MBOM
  • A baseline WBS structure (at minimum, one per end item) for cost, schedule, and demand tracking

4. Generate and Customize the Project

Using the Manage Major Assembly Projects app, generate a project for a specific unit or model. The system:

  • Explodes the end-item BOM
  • Identifies major assemblies
  • Builds project networks
  • Assigns installation kits to activities using reference points
  • Applies parameter effectivity to filter for the correct configuration

Run the Check Major Assembly Projects app to validate the result and resolve any issues before releasing demand.

5. Plan, Execute, and Stay in Sync

Once generated, the project is ready for execution. MRP converts network activity demand into installation orders. Operators execute kit assembly using PEO instructions, with backflushing used to reflect completion.

As engineering changes occur—such as replacing a kit for a certain model or serial range—use transaction Transfer Bill of Material (CN33_N) to transfer updated MBOM content into the active project. This keeps PS aligned with engineering without starting over.

What Changes in Your Day-to-Day

Once implemented, this approach shifts project creation from a manual bottleneck to a fast, repeatable, and controlled process.

Instead of building each project by hand, planners launch them from a standard template—preconfigured with reference points, networks, and activities. The system handles kit assignments automatically, and effectivity ensures only the right components and operations apply.

Engineers and operations teams no longer manage a tangle of cloned BOMs. One super BOM and routing serve all configurations, filtered cleanly for each unit. The result is a clear, auditable record of what’s built, why, and for whom.

Most importantly, change becomes manageable. Versioned structures and parameter-driven filtering allow updates to flow into live projects without breaking them. What was once a source of rework becomes part of a resilient, traceable build process—designed for the real-world variability of Aerospace and Defense.

Best Practices for Templates and Effectivity

There’s no shortcut to scalable, effectivity-driven execution, but there are patterns that work. Whether you’re just getting started or refining an existing setup, these best practices reflect what we’ve seen succeed in real-world A&D programs: clear structure, disciplined governance, and smart use of SAP’s standard tool.

Keep effectivity simple and explicit. Start with the minimum parameter set that reflects real decisions (often model + serial interval). Overusing wildcards or multiparameter combinations can degrade performance and complicate troubleshooting.

Formalize material semantics. Define and document your End‑Item, Major‑Assembly, and Installation‑Kit material types and assign the model‑unit effectivity type—it’s the precondition for PEO to differentiate assemblies from kits during generation.

Name and govern reference points. Treat reference points like stable interfaces. Create a naming convention and gate changes through change control; the generator relies on exact matches between MBOM items and template activities.

Design the template for reuse. Model one network per major assembly and keep activity networks clean (FS links where possible). Avoid unit‑specific tweaks in the template—parameter effectivity should do that work.

Validate early with the ‘Check’ app. Make Check Major Assembly Projects part of your release checklist to catch missing kits, unresolved effectivity, or obsolete references before MRP.

Close the loop on changes. Establish a routine to run Transfer Bill of Material (CN33_N) whenever MBOM versions change, and document who reviews and approves the impact on in‑process projects.

Educate planners on parameter variants. Ensure planners know where and when effectivity variants can be entered/adjusted (sales order, BOM explosion dialogs, PS), and how this drives change‑state selection.

Aerospace and Defense programs are under more pressure than ever to deliver faster, adapt to change, and prove traceability at every step. However, the traditional approach to project creation simply wasn’t built for that reality. Manual builds, duplicated BOMs, and disconnected planning layers can’t scale when every unit is different and every change matters. That’s why the ability to automate project generation — while tailoring each build to a specific configuration — isn’t just a process improvement. It’s foundational to operating with speed and precision in a modern, engineer-to-order environment.

FAQ

In the major assembly model, Project System (PS) plans the work; PEO executes it. Each project activity carries demand for a specific installation kit. MRP then converts that demand into installation orders, which are executed on the shop floor using PEO’s work instructions.

You can—but be careful. Copying an old project may carry over outdated structure or effectivity logic. If you go this route, always re-explode the MBOM using CN33_N to align with the latest configuration. We typically recommend template-based generation to ensure consistency and traceability.

You don’t need to rebuild the project. SAP allows you to transfer updated MBOM content into a live project using CN33_N. With the right setup, changes can flow through without disrupting execution—keeping PS and PEO aligned even mid-build.

Reference points are the “glue” between installation kits and activities. If they’re missing or inconsistent between the MBOM and the template, the system can’t make the match—and demand won’t be created. We’ve seen this become a hidden failure mode if governance isn’t in place.

Filtering happens at BOM explosion and order creation. The system uses the assigned parameter variant (e.g., model, serial range) to determine which components and operations apply. This ensures every project reflects exactly what’s needed for that unit—no more, no less.

In our experience, it often comes down to:
Reference point mismatches

MBOMs not structured around installation kits

Templates with unit-specific logic instead of effectivity

Effectivity parameters missing or not activated
 This is where validation tools—and upfront design discipline—make a difference.

Yes. We recommend piloting with a representative unit or configuration. Use the Check Major Assembly Projects app to verify structure, simulate parameter variants, and confirm the generator behaves as expected. A test run can surface gaps before they become production blockers.
These are just a few of the questions that come up when deploying unit-specific automation at scale. The Digital Core for Aerospace and Defense Manufacturing by Capgemini framework helps aerospace and defense manufacturers get these structures right the first time, so change becomes a capability, not a constraint.