Define the scope of an APS proof of concept by identifying a small set of real planning scenarios that expose your most critical constraints, setting clear success criteria before the pilot begins, and agreeing on a fixed timeframe of four to six weeks. The goal is not to build a complete model but to generate a confident, decision-ready answer to one question: does this solution fit your environment?
In 2026, manufacturing companies are under increasing pressure to validate technology investments quickly and with minimal disruption. A well-scoped APS PoC lets planners, plant management, and leadership reach that confidence together, using real data and real operating rules rather than vendor demonstrations. The sections below walk through the most important questions teams face when designing an APS pilot project.
What should an APS proof of concept actually test?
An APS proof of concept should test whether the solution can handle your specific planning constraints, respond to realistic disruptions, and produce schedules that planners trust and can explain. The focus is not on demonstrating every feature the software offers. It is on proving that the system works in your environment, with your data, under conditions that reflect everyday operations.
The most valuable thing a PoC can reveal is where spreadsheet-based planning breaks down in your context. That typically happens when priorities shift frequently, capacity is shared across multiple products or work centres, and sequencing rules make planning decisions highly interdependent. These are precisely the conditions where advanced planning and scheduling software should deliver a clear advantage, and they are the conditions worth testing directly.
Rather than running a generic system demonstration, build the pilot around a handful of agreed scenarios that mirror real events. For example:
- A rush order needs to be inserted without breaking critical delivery commitments
- Bottleneck capacity changes, and delivery dates must be re-evaluated quickly
- A material shortage forces resequencing across multiple work orders
- The schedule must be recovered after an unplanned disruption
When the PoC is built around scenarios like these, evaluation becomes practical and easy to agree on across planning, operations, and leadership.
Which planning processes should be included in the scope?
Include the planning processes where your current approach creates the most friction: typically capacity scheduling, sequencing, and change management when priorities shift. A PoC scope should cover enough of the planning workflow to test real interdependencies, but it should not attempt to model every exception or edge case your operation has ever encountered.
A common and costly mistake is trying to document all special cases before the pilot begins. This leads to expanding workshops, delayed timelines, and a model that is still incomplete when priorities have already moved on. The right mindset for an APS PoC scope is to model only what is necessary to test the target requirements.
In practice, this usually means selecting one or two product families or production areas where planning complexity is high and the pain of current methods is clear. It means including the constraints, routings, and sequencing rules that directly affect those areas, and deliberately leaving out processes that are either straightforward or not part of the decision being made. A narrower scope completed with confidence is far more valuable than a broad scope that remains unfinished.
How long should an APS proof of concept take in 2026?
An APS proof of concept should take four to six weeks. This timeframe is long enough to build a working model with real data, test it against agreed scenarios, and surface meaningful gaps, but short enough to maintain focus and avoid the model-building drift that undermines longer pilots.
In 2026, the expectation from both planners and leadership is that APS evaluation moves quickly. A pilot that stretches beyond six weeks without clear milestones tends to lose momentum and credibility. The four-to-six-week window works because it forces the team to prioritise what actually matters for the decision rather than pursuing completeness for its own sake.
The timeline also signals something important about the solution itself. If the APS software requires months of configuration before it can be tested with real scenarios, that is itself a finding worth knowing before committing to a full implementation. A solution that supports an iterative way of working should be able to reach a testable state within weeks, not months.
What data is needed before the PoC can begin?
Before an APS PoC can begin, you need access to master data covering resources and their capacities, routing and operation sequences for the selected product families, and a representative set of open production orders or a recent order history. This data does not need to be perfect, but it needs to be available and usable enough to build a working model of the scoped area.
One of the most consistent findings from APS pilot projects is that the PoC itself reveals data gaps that were not visible beforehand. Missing or inconsistent capacity data, incomplete routings, and unreliable planning parameters are common discoveries. This is not a reason to delay starting the pilot. It is one of the most practical reasons to run one.
Identifying data gaps during the PoC rather than during a full rollout reduces implementation risk significantly. When gaps surface early, there is still time to correct master data and planning parameters before production deployment. Preparing the following before kickoff will help the pilot start cleanly:
- A current resource list with capacity definitions and shift calendars
- Routing data for the selected product families or work centres
- Open order data or a recent planning horizon snapshot from your ERP
- A short list of known planning rules, priorities, and sequencing constraints
How do you set success criteria for an APS PoC?
Set success criteria for an APS PoC by defining, before the pilot begins, what must be true at the end for the organisation to move forward with confidence. Criteria should focus on planning capability and readiness rather than long-term operational KPIs, because a short pilot is not a production deployment.
Strong success criteria are specific and observable. Useful indicators include how quickly planners can create and adjust a revised schedule compared to current practice, whether constraints and bottlenecks behave as expected in the model, and whether planners can explain the resulting schedule to production and customer-facing teams without specialist support. These questions get at something more important than feature coverage: they test whether the solution is trustworthy and usable in your hands.
A practical framework for APS PoC success criteria covers four areas:
- Planning responsiveness: Can schedules be created, adjusted, and compared faster than current methods?
- Usability and adoption: Can planners perform key tasks and explain results to stakeholders without constant support?
- Data and integration readiness: What gaps were found, and how quickly could they be corrected?
- Transparency: Are constraints, bottlenecks, and change impacts visible enough to support cross-functional decisions?
By the end of the pilot, you should be able to summarise which requirements are already met, what gaps remain, and what data or process work would be needed to proceed to full deployment.
What are the most common APS PoC scoping mistakes?
The most common APS PoC scoping mistake is pursuing a perfect model before testing anything. Teams try to document every exception and special case upfront, workshops multiply, and the timeline slips. By the time the model feels complete, the business context may already have shifted, and the window for a clear decision has closed.
A second frequent mistake is scoping the PoC around the software’s capabilities rather than around the organisation’s planning problems. This turns the pilot into a demonstration rather than an evaluation. The result is a positive impression that does not translate into confidence when planners face their actual day-to-day scenarios.
Other mistakes worth watching for include:
- Scope that is too broad: Trying to cover too many product families, work centres, or planning processes at once makes it impossible to reach a clean conclusion within the available time
- No agreed success criteria: Without criteria defined upfront, the PoC ends with opinions rather than a decision
- Underestimating data preparation: Assuming that ERP data is ready to use without checking its quality and completeness before kickoff
- Treating the PoC as a one-off test: The most effective APS pilots are designed so that the model and findings feed directly into implementation planning, rather than being discarded after the evaluation is complete
With Delfoi Planner, we structure the PoC as the first phase of implementation rather than a separate exercise. This means the work done during the pilot, including the model, the data corrections, and the scenario findings, carries forward into production deployment. The PoC becomes both a validation and a design phase, which reduces the total time and effort needed to reach a live system. Contact us to discuss your PoC and find out how we can help you move forward with confidence.
