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 the same question: can we manage NPI inside this thing? The honest answer is no, and the reason isn't that the ERP is bad. The reason is that ERPs, PLMs, and MES platforms were each designed for a fundamentally different job, and New Product Introduction doesn't fit any of them. ERP is a system of record for transactions. PLM is a system of record for the design. MES runs the shop floor. NPI is something else entirely: a cross-functional, time-bounded, gate-driven program that runs across all three layers and lives largely in email, spreadsheets, and PDFs while it's active. This is why mid-market suppliers in aerospace, defense, electronics, and advanced manufacturing keep finding themselves running multimillion-dollar customer programs out of Smartsheet and Outlook, even when their IT stack costs them $400K a year in license fees. It's not a discipline failure. It's an architecture mismatch — and once you see it that way, the path forward gets clear. This is the structural why, and the shape of what fits in the gap.

What ERP was designed for

ERP — SAP, Epicor, Oracle, Microsoft Dynamics, Plex, Infor, IFS — was built for a specific job, and it does that job well: running steady-state production. 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 upstream system enters a transaction, ERP records it, ERP enforces 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 — not actively being defined.

This is a big and important job. Modern ERPs are decades-mature engineering achievements with deep integration into how mid-market and enterprise manufacturers run finance, procurement, inventory, and steady-state production. Nobody who's worked with a properly-deployed ERP would call it bad software.

The trouble starts when teams try to use ERP for a job it wasn't designed for: managing a cross-functional, gate-driven, customer-facing program that exists specifically because the parts, BOMs, and processes are still being defined.

The 5 reasons NPI breaks inside an ERP

Five structural reasons NPI doesn't fit the ERP model. None of these are bugs in any particular ERP — they're consequences of the architecture choice that makes ERP great 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 using project codes, custom tables, or a separate "project" module — but the underlying data model still wants transactions, not programs. Every report, every roll-up, every dashboard is built around transactional aggregates. A program that doesn't have transactions yet (because the part isn't qualified yet) is mostly invisible to ERP.

2. No native stage-gate model

Stage gates — AS9102, PPAP, APQP, customer-specific reviews — are the structural backbone of NPI. ERPs don't model them natively. Teams approximate gates with custom workflow states, document approval tables, or status flags. The approximation works for simple cases and breaks for the customer-format-specific gates that real NPI requires. AS9102 Forms 1, 2, and 3 don't fit cleanly into a generic ERP approval workflow, and a Level 3 PPAP submission with 18 elements isn't a workflow item — it's 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, not for cross-company program coordination. There's 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: somewhere else.

4. Cross-functional comms aren't ingested

Every supplier email lives in Outlook. Every customer engineering response lives in Outlook. Every internal escalation lives in Outlook. ERPs don't ingest comms. Teams hand-copy the relevant facts into ERP fields, or more commonly, into Smartsheet — and 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 are slow and expensive — a typical customization cycle is weeks or months, not days. The mismatch between ERP's change cadence and NPI's change cadence means teams stop trying to model NPI in ERP and revert to spreadsheets. The ERP becomes a passive recipient of finalized data after the program closes, rather than an active management tool 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.

But PLM has a similar gap to ERP: it's a human-driven workflow engine optimized for engineering, not for cross-functional program management. Engineers act on design data; PLM records and routes. The cross-functional NPI program — process engineering, quality, supplier quality, production, program management — isn't PLM's domain.

PLM stops where NPI begins, at design release. Once the design package is released to manufacturing, PLM's job is mostly done. What happens next (tooling, validation, supplier qualification, pilot, ramp) is NPI's job, and it doesn't fit PLM's data model. Like ERP, PLM is good at what it was built for. Asking it to run NPI is asking it to do a different job — and the result is the same: customizations that approximate NPI without actually 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 systems to NPI in spirit because it's operationally fast-moving, sensor-aware, and continuously updated.

But 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 doesn't manage that journey; it runs the destination.

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 systems are mature, well-supported, and good at their job. The fourth — NPI — has historically had no system. Spreadsheets and email have filled the gap. That's the gap the coordination layer fills.

The coordination layer that actually fits NPI

The coordination layer is a separate category of software, not a feature inside an existing one. 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 the systems of record stay in place.

What defines the category:

• Domain object: the program. Not the transaction (ERP), not the design (PLM), not the work order (MES). 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. The human confirms, corrects, or overrides. The engine learns from every confirmation.
• Deployment: 1 day, not 12–24 months. 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, not replace them.
• Security: ITAR / CUI-grade for aerospace and defense. Built in from day one, not retrofitted as an enterprise feature.

This is what we built BlackOrbit to be — and the architectural difference between BlackOrbit and the alternatives isn't features, it's the operating model. Traditional PM tools and ERP modules are request/response: 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

The fear teams have when they hear "another system" is rip-and-replace. ERP migrations are 12-to-24-month projects. PLM migrations are similar. MES rollouts can be longer. Nobody wants another one of those — and they shouldn't have to commit to one to fix NPI coordination.

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 provenance — every field is 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. Customer-facing PMs land on their own customer-program views. The Advisor agent starts running, 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). Connect shared folders. Connect ERP for parts and orders (read-only). Connect 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 layer reads, the human team confirms.

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

Once trust is established, write-back to ERP for status milestones, 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 earn trust, leave the others read-only.

The pattern is read first, write later. The coordination layer earns the right to write back to your systems of record by demonstrating that its proposals are accurate. Your existing ERP, PLM, and MES stack stays exactly where it is throughout — same vendors, same contracts, same workflows. The coordination layer adds a missing layer; it doesn't replace anything.

The decision your team has to make

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

• The coordination tax. 50%+ of team time on collaboration and search per Cross/HBR — the upper end in cross-functional NPI. (See: How NPI Programs Slip for the full math and the five failure modes it produces.)
• Program slips that compound. A four-day delay on a DFM question becomes a one-week tooling slip becomes a missed FAI date becomes a customer escalation. Each step compounds.
• 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, not from your team. 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're actually good at. The cost is a 1-day deployment and a software line item — typically less than a tenth of the cost of an ERP customization, with zero rip-and-replace risk.

The decision isn't between two equivalent options. It's between continuing to pay the coordination tax silently or paying explicitly for a system designed to recover it. The coordination tax is being paid either way — the only question is whether you're getting anything back for it.