Accurate delivery promises depend on more than knowing when an order was placed or when production is scheduled to finish. Manufacturers must account for material availability, machine capacity, operator skills, and changing shop floor conditions. At INFOCUS 2026, Penn Engineering shared how it is combining JD Edwards, Claude AI, and a governed data pipeline to make those calculations more reliable and actionable.

In the session “From Past-Due to Plain English: A Governed JDE Data Spine You Can Chat With,” Melody Bivona and Felipe Lopez explored how Penn Engineering is transforming complex manufacturing data into practical insights that improve capacity planning, reduce inefficiencies, and support more realistic customer delivery commitments.

Why Traditional Capacity Planning Wasn’t Enough

Penn Engineering manufactures fasteners for industries including automotive, aerospace, medical, and technology. Its operations span multiple manufacturing locations, with intercompany orders adding complexity to production planning and customer service.

When a customer requests an order update, the answer may depend on components manufactured at another facility, work orders progressing through different operations, and materials still in transit. Complicating matters, many work orders carry past-due dates that no longer reflect actual production conditions.

Historically, delivery commitments sometimes relied on standardized lead times, such as eight weeks, regardless of the actual routing requirements or existing backlog. Lopez explained that certain manufacturing processes could exceed those estimates before accounting for hundreds of outstanding work orders.

Penn Engineering needed a more dynamic approach that could evaluate real manufacturing constraints rather than relying on static dates and assumptions.

Building a Governed JD Edwards Data Pipeline

Bivona emphasized that AI alone cannot solve inconsistent data problems. When employees initially began creating applications with Claude, different teams developed similar on-time delivery metrics that produced conflicting results.

The solution was a standardized, governed data pipeline published as a connector in Claude.

The pipeline establishes consistent rules for extracting, cleaning, validating, and processing JD Edwards data. Each execution follows the same logic, identifies anomalies, and alerts users when expected records disappear. Its outputs include a structured dataset, an Excel workbook, and an interactive HTML dashboard or plain-English report.

JD Edwards Orchestrator provides the foundation for accessing operational data. During development, the team can prototype applications using Excel exports from Data Browser, validate the results, and then create orchestrations for automated refreshes.

Governance also extends to GitHub, approval workflows, and deployment into AWS. Rather than allowing individual AI experiments to become disconnected enterprise applications, Penn Engineering established a repeatable development process.

Bivona described another important lesson: browser-based automation can be fragile. After a Microsoft Edge update disrupted automated data extraction, the team moved toward orchestrations for more dependable enterprise operations.

Modeling Capacity Down to Machines and Operators

Lopez demonstrated how Penn Engineering moved beyond conventional capacity calculations to model actual shop floor conditions.

The company’s manufacturing processes involve equipment that can technically produce different parts but may require significant setup time between jobs. Consequently, machine assignments depend not only on available hours but also on product characteristics, changeover requirements, and operational efficiency.

The team’s advanced capacity planning model incorporates material availability, work order routing, machine capacity, employee attendance, and operator qualifications. Using historical production records, it estimates how work orders will progress and identifies potential delivery risks.

A Sankey-style visualization represents individual work orders moving through manufacturing operations. Color-coded indicators distinguish orders expected to finish on time, those at risk, and those projected to be late.

Importantly, the model does more than display problems. It simulates alternative operating scenarios and recommends adjustments, such as adding a shift, changing machine assignments, or temporarily idling equipment to improve overall production flow.

Because moving an operator between machines affects multiple work orders, the simulation evaluates consequences across the shop floor rather than optimizing one machine in isolation.

Turning Historical Data Into Better Decisions

Historical production data plays a central role in the model’s accuracy.

Lopez incorporated approximately 18 years of manufacturing history to understand operator experience, work order performance, and production patterns. The model compares projected completion times against actual results and updates its assumptions as new work orders finish.

It also accounts for different capacity constraints. For example, certain heat-treatment operations are measured by weight rather than machine hours, requiring specialized calculations that standard capacity models cannot easily accommodate.

Another application analyzes manufacturing drawings to identify similarities between parts and optimize production sequencing. Instead of treating every product change as a full nine-hour setup, the model estimates changeover requirements based on component similarities.

In one demonstrated scenario, optimized scheduling reduced projected setup time by 25 hours.

Planners initially followed approximately 90% of the model’s suggested sequencing. Within two weeks, that alignment increased to 99%, demonstrating both adoption and the value of combining algorithmic recommendations with experienced planners’ judgment.

Measurable Improvements in Just Five Weeks

Although the advanced capacity planning application was only five weeks old at the time of the presentation, Penn Engineering reported encouraging results.

On-time delivery improved from approximately 50% to 65% during the initial implementation period. A later KPI summary cited improvement from 63% to 75%, reflecting another reported measurement of delivery performance.

The team also reported:

• Approximately €230,000 in projected first-year return for one manufacturing site.
• Visibility into 68,000 hours of work in progress previously difficult to locate precisely.
• An estimated €100,000–€120,000 in potential tooling-related benefits.
• Improved planning accuracy through more realistic setup-time calculations.

These figures represent early results and projections rather than established long-term outcomes. Nevertheless, they demonstrate how improved visibility and operational decisions can translate into measurable business value.

Making JD Edwards Data Accessible Through Plain English

The team’s longer-term vision extends beyond dashboards and simulations.

Using Claude and exploring Model Context Protocol (MCP) connectivity, Penn Engineering is working toward an interface where employees can ask questions about open work orders, projected delays, and corrective actions in natural language.

For example, a customer service representative could enter a part number and receive an estimated completion date based on material availability, routing requirements, production capacity, and current work order status.

The team also envisions processing multiple orders simultaneously, automatically assigning realistic promise dates to incoming EDI orders, and eventually offering customer-facing functionality.

Other applications already provide managers with daily executive summaries, identify purchasing and planning bottlenecks, and generate notifications when intercompany orders threaten downstream deliveries.

At the time of the session, these applications retrieved and analyzed JD Edwards data but did not write changes back into the system. Secure write-back through orchestrations remained a future objective.

Practical Lessons for JD Edwards Teams

Penn Engineering’s experience reinforces several principles for organizations exploring AI-powered manufacturing analytics.

First, begin with a clearly defined operational problem rather than implementing AI simply because the technology is available. Second, establish consistent data definitions and governance before scaling applications. Third, involve the people who understand the manufacturing process, including planners, operators, engineering, purchasing, and HR.

Data quality remains essential. Lopez identified inaccurate routings as a major challenge and explained that the model can refuse to predict completion dates when insufficient historical information exists.

Finally, validate predictions against actual performance and continuously incorporate user feedback. AI can accelerate development, calculations, and visualization, but manufacturing expertise determines which constraints matter and which recommendations are practical.

Penn Engineering’s approach demonstrates how JD Edwards organizations can use governed data and AI to move beyond reporting what is late toward understanding why—and identifying what to do next.

Want more?

Explore more content and resources to help you get the most from your JD Edwards investment:

• Visit the Quest Learn Library for blogs, how-to demos, and on-demand sessions.
• Connect with peers in one of our Quest JD Edwards Community User Groups to swap stories, ask questions, and share tips with other users facing the same challenges.
• Bookmark LearnJDE.com for updates from JD Edwards development.

Not a Quest member yet? Join today and tap into the ultimate Oracle customer network.