New product introduction is the work of bringing a new product, or a new variant of an existing one, into the point where it can be quoted, planned, produced and delivered. The difficulty can extend beyond any single system. It is that a customer requirement, a configuration, a product definition, a work definition and a launch commitment have different owners, change at different speeds and live in different applications. This guide explains how those records relate, where they must be kept distinct, and what to decide before connecting them.
The approach below uses documented vendor mechanics as concrete illustrations. They show what one platform's records look like; they are not evidence of how typical manufacturers operate, and your architecture may divide these responsibilities differently.
What a launch record is, and what it is not
A launch needs its own controlled record, separate from the product definition itself. Oracle's business-object documentation describes a new product launch definition as a request that generates new product combinations based on combinations from a specified source product, and optionally copies data for specified measures. The same object carries identifiers for the new product, the source product and the associated plan, plus a status of In-Progress, Active or Completed.
The design lesson is modest and useful. In that model the launch request is a distinct object with its own identity and status, linked to a plan and to a source product. It is not the bill of material, the quote or the routing. When you design your own flow, decide what plays that role for you: one record that says a launch exists, who requested it, which existing product it borrows from, and whether it is still in progress or complete.
The documentation describes an indicator for whether the Copy Measure Data step is enabled for a launch definition. That is a reminder that even a mechanical launch request involves choices about which history carries forward and which parties the new product applies to. Those choices need an accountable decision-maker rather than a default.
How product definition, work definition and effectivity relate
Customer need, quote, configuration, product definition, bill of material, routing and quality plan are separate artifacts. Collapsing them into one record hides who may change what.
Oracle's 25D release note on process manufacturing illustrates one such relationship. A work definition can now reference a formula from product management, and one formula can be used by one or more work definitions based on varying batch sizes, production resources, process parameters and work instructions. By referencing a formula, manufacturing engineers can assign input and output items to operations without manually recalculating quantities for batch sizes. Formula ingredients and products also have effective start and end dates for controlling changes, so planned requirements can be viewed as of a specific date.
This is a documented example of effectivity: the same product structure can mean different things on different dates, and the work definition consumes it. Whatever platform you use, you should be able to answer for each record who authored it, who approves it, what date range it governs, and which downstream records read it.
The same note records that the formula-based work definition supports approvals using electronic records and electronic signatures, and audit trails. Approval and audit are properties of the record, which matters when a launch must show who released what and when.
Where late change breaks the flow
The release note is equally useful for what it says does not happen automatically. Oracle states that you can't automatically synchronize formula changes to process manufacturing work definitions using the scheduled process at this time. Instead, a user can search work definitions by item revision and formula and make the changes manually. The note also says you can't add a formula to an existing process manufacturing work definition, and that formula quantities default to the work definition and can't be overridden, so batch quantity has to be considered when the formula is defined.
These are limits of one product at one release, and the note should not be read as describing every platform. But they illustrate a general planning question that you can test in your own environment: when engineering changes a product definition late, which open quotes, orders, planned supply, work orders, inventory, documentation and service records are affected, and does anything detect that, or does a person have to search for it? If the answer is a person, then the owner of that search and the cadence of the review belong in the launch plan.
Where each system fits
Treat the following as an architecture question, not a prescription. A manufacturer may keep the customer need and quote in a CRM or quoting tool, the product definition and engineering release in a product information or lifecycle system, sourcing and supply commitments in ERP and planning, work and inspection records in execution and quality systems, and fulfillment and order status in warehouse and portal systems. Other manufacturers will place product structure, planning data or quality plans elsewhere, and some will use fewer applications.
The point of naming them is the boundaries. Each boundary is where a record is handed from one owner to another, and each handoff needs a defined identifier, a trigger, a direction and a way to detect failure.
When this approach fits, and when it does not
This kind of explicit launch record and gated hand-off fits when products are configured or derived from existing ones, when several functions must commit before an order promise is credible, or when changes after release are expensive. It adds less when a manufacturer introduces few products and a single team owns every step. In that case, weigh whether heavy gating is worth its overhead.
Two distinctions prevent common confusion. First, a launch record is not the product definition; one tracks the introduction, the other describes the product. Second, a system feature that supports approval or effectivity does not decide your gates. The documentation describes what a platform records, not how your organization should divide authority.
Applying this before your next launch
We recommend working through these questions with the functions involved, before choosing tools:
- What single record says a launch exists, and who may open, close and change its status?
- For each artifact (requirement, quote, configuration, product definition, bill of material, routing, sourcing, quality plan), who owns it and who approves release?
- Which dates govern each artifact, and which downstream records read those dates?
- When a released definition changes, which open quotes, orders, supply, work, inventory and documents are affected, and how will you find them without relying on memory?
- Which hand-offs are automated, which are manual, and who is accountable for each manual one?
- What launch evidence, such as first-run quality results, delivery performance and service issues, returns to product and planning owners, and on what cadence?
Answer these first. The answers tell you whether an existing system can carry the flow, whether an integration is needed, or whether the gap is an ownership decision rather than a technology one.
