Why your ERP can't manage NPI (and what actually works).

Every manufacturer with a serious ERP (SAP, Epicor, Oracle, Microsoft Dynamics, Plex, Infor, IFS) eventually asks whether NPI, new product introduction, or new part introduction as most contract manufacturers call it, can be managed inside it. In our experience the answer is no, and the ERP itself is rarely the problem. ERP, PLM, and MES were each built for a different job, and NPI fits none of them. ERP keeps the record of transactions, PLM keeps the record of the design, and MES runs the shop floor. NPI is a cross-functional, time-bounded, gate-driven program that runs across all three and lives mostly in email, spreadsheets, and PDFs while it is active. That is why mid-market suppliers in aerospace, defense, electronics, and advanced manufacturing end up running multimillion-dollar customer programs out of Smartsheet and Outlook while paying $400K a year in license fees for their IT stack. The architecture is mismatched, and once you see it that way the path forward gets clearer.

What ERP was designed for

ERP (SAP, Epicor, Oracle, Microsoft Dynamics, Plex, Infor, IFS) was built to run steady-state production, and it does that well. The domain object is the transaction: purchase orders, work orders, journal entries, inventory moves, financial postings.

The operating model is request/response. A human or an upstream system enters a transaction, ERP records it and enforces the business rules. Inventory moves trigger cost postings, work-order completions trigger inventory moves, invoices trigger receivables. The architecture assumes the parts, BOMs, routings, and processes are stable rather than still being defined.

This is a big and important job, and modern ERPs do it well. Nobody who has worked with a properly deployed ERP would call it bad software. The trouble starts when teams try to use it to manage a cross-functional, gate-driven, customer-facing program that exists precisely because the parts, BOMs, and processes are still being defined.

If you run a contract manufacturer and want the whole stack laid out, ERP, MES and the NPI layer side by side, start with our contract manufacturing software guide.

The 5 reasons NPI breaks inside an ERP

None of these are bugs in any particular ERP. They follow from the architecture choice that makes ERP good at what it was built for.

1. The unit of work is wrong

ERP's domain object is the transaction (purchase order, work order, journal entry). NPI's domain object is the program, a time-bounded, cross-functional initiative with phases and gates. You can fake a program inside ERP with project codes, custom tables, or a separate "project" module, but every report, roll-up, and dashboard is still built around transactional aggregates. A program with no transactions yet, because the part is not qualified yet, is mostly invisible to ERP.

2. No native stage-gate model

Stage gates (AS9102, PPAP, APQP, customer-specific reviews) are the backbone of NPI, and ERPs do not model them natively. Teams approximate them with custom workflow states, document approval tables, or status flags, which works for simple cases and breaks on the customer-format-specific gates real NPI requires. AS9102 Forms 1, 2, and 3 do not fit cleanly into a generic ERP approval workflow, and a Level 3 PPAP submission with 18 elements is a structured deliverable that needs its own data model.

3. No customer-facing program view

In contract manufacturing, half the program lives outside the building: at the customer's facility, in the customer's quality system, on the customer's PPAP portal. ERPs were built for the supplier's internal operations, so there is no native concept of "the customer's gate review is on Tuesday" or "the customer engineer has been silent for 11 days on this DFM question." Those facts have to live somewhere else, which is exactly where NPI programs end up.

4. Cross-functional comms aren't ingested

Every supplier email, every customer engineering response, and every internal escalation lives in Outlook, and ERPs do not ingest comms. Teams hand-copy the relevant facts into ERP fields, or more commonly into Smartsheet, so ERP becomes one more place to hand-update rather than a source of truth. The signal-to-action chain that defines NPI lives entirely outside the ERP.

5. The cycle of change is too fast for ERP

NPI is unstable by definition: parts, processes, suppliers, customer requirements, and gate criteria all change as the program runs. ERP customizations take weeks or months, so teams stop trying to model NPI in ERP and revert to spreadsheets. The ERP receives the finalized data after the program closes, and plays no part while it runs.

PLM: same problem, different layer

Product Lifecycle Management systems (Teamcenter, Windchill, 3DEXPERIENCE, Arena, Aras) own the design: CAD, BOM, ECOs (engineering change orders), release workflows, configuration management, revision control. PLM is excellent at the engineering data layer, and a properly deployed PLM is non-negotiable for any serious manufacturer.

PLM has a gap similar to ERP's. It is a human-driven workflow engine built for engineering: engineers act on design data, and PLM records and routes. The cross-functional NPI program (process engineering, quality, supplier quality, production, program management) sits outside PLM's domain.

PLM stops where NPI begins, at design release. What happens next (tooling, validation, supplier qualification, pilot, ramp) is NPI's job, and it does not fit PLM's data model. Asking PLM to run NPI gives the same result as with ERP: customizations that approximate NPI without managing it, eventually replaced by Smartsheet and Outlook.

MES: closer, still not it

Manufacturing Execution Systems (Plex, Rockwell FactoryTalk Production Centre, Siemens Opcenter, Aegis FactoryLogix) run the shop floor in real time: work orders, routings, travelers, machine data, SPC, operator execution. MES is the closest of the four to NPI in spirit because it is fast-moving, sensor-aware, and continuously updated.

MES's domain is the execution of qualified production. Once the part is qualified (first article approved, PPAP cleared, capacity validated), MES picks it up and runs it in steady-state production. NPI is what gets the part to the qualified-production line. MES runs the destination and leaves that journey unmanaged.

A useful way to see all four systems together:

• PLM owns the design (before NPI starts)
• NPI owns the manufacturing introduction (the journey)
• MES runs the shop floor (after NPI ends)
• ERP runs financials and inventory (alongside everything)

Three of the four are mature, well-supported, and good at their job. NPI has historically had no system, and spreadsheets and email have filled the gap. That is the gap the coordination platform fills.

The coordination platform that fits NPI

The coordination platform is its own category of software. Its job is to be the system of record for the NPI program itself (phases, gates, work packages, customer relationships, supplier readiness, evidence, comms) and to integrate with ERP, PLM, and MES so those systems of record stay in place.

What defines the category:

• Domain object: the program. Where ERP is built around the transaction, PLM around the design, and MES around the work order, here the cross-functional, time-bounded NPI program is the first-class object the data model is built around.
• Operating model: continuous loop. Signals come in (uploads, emails, replies, ERP/PLM/MES events). The engine ingests them and maintains program state with provenance. The Cockpit surfaces decisions for the human, who confirms, corrects, or overrides, and the engine learns from every confirmation.
• Deployment: 1 day, compared with 12 to 24 months for an ERP or PLM project. A real program lives in the system on day one, imported from existing Excel, SOWs, and PDFs.
• Integrations: ERP, PLM, MES, email, and shared folders. Bidirectional where it makes sense, read-only or event-driven where it doesn't. Designed to run alongside existing systems and leave them in place.
• Security: ITAR / CUI-grade for aerospace and defense. Built in from day one rather than retrofitted later as an enterprise feature.

This is what we built BlackOrbit to be. The architectural difference between BlackOrbit and the alternatives is the operating model. Traditional PM tools and ERP modules are request/response, where humans operate forms. BlackOrbit is AI-native: agents propose, humans confirm, the engine learns. (More on the architecture in the homepage's how-it-works section.)

How to connect it without ripping anything out

When teams hear "another system" they think rip-and-replace. ERP migrations are 12-to-24-month projects, PLM migrations are similar, and MES rollouts can be longer. Fixing NPI coordination should not require one of those.

The deployment pattern that works:

Phase A (first hour): Magic import

Upload your existing program documents: Excel Gantts, action lists, SOWs, customer PPAP submissions, drawing PDFs. The system parses them into a structured program. Owners, dates, gates, and dependencies appear automatically, with every field traceable to the source line in the original document.

Phase B (same day): Team goes live

Invite contributors. They land on their own actions, deadlines, and gate reviews, and customer-facing PMs land on their own customer-program views. The Advisor agent starts running and surfacing risks across the portfolio. Within 24 hours, a real program is being managed in the new system, with no IT project required.

Phase C (next 30 days): Signal integrations, read-only

Connect inboxes (read-only at first), shared folders, ERP for parts and orders (read-only), and PLM for design release events (read-only). The Ingest Agent starts turning inbound supplier and customer comms into proposed program updates that land in the Cockpit for human confirmation. Nothing in your existing ERP, PLM, or MES is touched: the coordination platform reads, and the human team confirms.

Phase D (next 90 days): Bidirectional integrations, opt-in

Once trust is established, write-back to ERP for status milestones and write-back to PLM for program-state events. By this point the team has 90 days of confirmation history that has trained the engine on shop-specific language and judgment. Bidirectional integrations are opt-in by integration target: turn on the ones that have earned trust and leave the others read-only.

The pattern is read first, write later. The coordination platform earns the right to write back to your systems of record by showing that its proposals are accurate. Your ERP, PLM, and MES stay exactly where they are throughout, with the same vendors, contracts, and workflows.

The decision your team has to make

You can keep running NPI on the workarounds (Smartsheet, Outlook, customer portals, status decks). It works until it doesn't, and the cost shows up in five places:

• The coordination tax. 50%+ of team time on collaboration and search per Cross/HBR, and cross-functional NPI sits at the upper end. (See How NPI Programs Slip for the full math and the five issues it produces.)
• Program slips that compound. A four-day delay on a DFM question becomes a one-week tooling slip, which becomes a missed FAI date, which becomes a customer escalation.
• Tribal-knowledge programs. Programs that exist because one specific PM knows where everything is. When the PM leaves, the program restarts at 60% of where it was.
• Customer escalations that hit late. The customer finds out about the slip from their own portal before your team tells them, and the trust hit is permanent.
• The ops manager who quietly knows the team is slipping but can't see exactly where, because the data lives in five inboxes and three spreadsheets.

Or you can put the missing layer in place and let your ERP, PLM, and MES do what they are good at. The cost is a 1-day deployment and a software line item, typically less than a tenth of an ERP customization, with zero rip-and-replace risk. The coordination tax is being paid either way; the decision is whether to keep paying it silently or to pay explicitly for a system designed to recover it.