An APS proof of concept is a short, focused pilot, typically four to six weeks, in which you test an advanced planning and scheduling solution against your own data, constraints, and planning scenarios before committing to a full implementation. The goal is not to build a finished model but to verify that the software fits your real operating environment and to create a clear decision basis for what comes next. The sections below walk through exactly what happens, what you need, and how to judge the results.
What happens during an APS proof of concept?
During an APS proof of concept, a limited but representative portion of your production environment is modelled in the APS software so that a small set of agreed planning scenarios can be tested using real data. The pilot is deliberately scoped to avoid the trap of trying to document every exception before anything is proven. The aim is a decision, not a perfect model.
In practice, the PoC moves through a few connected stages. First, the scope is defined: which work centres, product families, or planning horizons will be included, and which will be left out. Second, a handful of scenarios are selected that mirror real planning events, such as inserting a rush order, responding to a capacity change at a bottleneck, or recovering a schedule after an unplanned disruption. Third, the model is built quickly using available ERP or MES data, and planners work through the scenarios with the solution team.
What makes a PoC genuinely useful is that it shifts the conversation from a generic system demonstration to a practical test of your critical situations. Planners can see whether the software handles their actual constraints, and management gets a concrete view of implementation risk before any large commitment is made.
What data do you need to run an APS PoC?
To run an APS PoC, you need a working extract of your master data and recent transactional data: work centres and their capacities, routings and operation times, open production orders, and current or recent demand. The data does not need to be perfect, but it needs to be representative enough that the pilot scenarios reflect real planning conditions.
In our experience, the most commonly required data sets include:
- Work centre definitions, including capacity, shift calendars, and any shared resource rules
- Routing data with operation sequences and standard times
- Open and planned production orders, including due dates and priorities
- Demand data, whether from sales orders, forecasts, or both
- Material availability or known shortage situations relevant to the pilot scenarios
One of the most valuable outcomes of a PoC is that it surfaces data gaps early. It is common to discover that certain routing times are missing, that capacity definitions are incomplete, or that the ERP export does not include a field the planning logic requires. Identifying these issues during the pilot, rather than mid-implementation, significantly reduces the risk of a full rollout. If you would like to discuss your data readiness before starting, you can contact our planning specialists directly.
How long does an APS proof of concept take?
A well-structured APS proof of concept typically takes four to six weeks from data handover to final evaluation. This timeframe is long enough to build a meaningful model, run the agreed scenarios, and draw clear conclusions, but short enough to maintain focus and avoid the scope creep that derails longer planning projects.
The four-to-six-week window assumes that data is available reasonably quickly and that the scope has been agreed before the pilot starts. If data preparation takes longer, or if the scope expands during the pilot, the timeline will stretch accordingly. Keeping the target requirements fixed from the start is the most reliable way to stay on schedule.
It is worth noting that the PoC timeline is not the same as the implementation timeline. The pilot is a design and validation phase. Once requirements and data readiness are confirmed, the move to production deployment follows a separate plan. In that sense, the PoC also functions as a scoping exercise for the full rollout, which makes the subsequent implementation faster and better defined.
What should an APS PoC actually prove?
An APS PoC should prove that the software can handle your real planning constraints, that planners can use it without constant specialist support, and that the results are clear enough to support decisions across production, purchasing, and customer-facing teams. It should not try to prove that every edge case is covered or that the model is complete.
The most practical way to frame what the PoC needs to prove is to agree on a small set of must-pass conditions before the pilot starts. These typically fall into a few categories:
- Planning responsiveness: Can the team create, adjust, and compare schedules significantly faster than with the current approach?
- Constraint handling: Do capacity limits, setup rules, sequencing logic, and material constraints behave as expected in the model?
- Transparency: Are bottlenecks, change impacts, and trade-offs visible enough that planners can explain the plan to supervisors and other departments?
- Usability: Can planners perform key tasks independently after a short familiarisation period?
- Data and integration readiness: Is the data flow from ERP reliable, and are the gaps manageable before a production rollout?
The PoC should also prove something about the working relationship with the solution provider. How quickly does the team respond to issues? How clearly are recommendations explained? The quality of collaboration during the pilot is a strong indicator of what implementation and ongoing support will look like.
How do you evaluate APS PoC results before committing to full rollout?
To evaluate APS PoC results, compare the pilot outcomes against the must-pass conditions defined at the start, then assess what gaps remain and what work would be required to close them before full deployment. A clear summary of met requirements, open gaps, and the effort needed to resolve them gives management a practical basis for a go or no-go decision.
A few evaluation questions tend to produce the most useful signal:
- Did the system handle the agreed scenarios in a way that planners found credible and usable?
- Were the results explainable enough that non-planners, such as production supervisors or customer service teams, could act on them?
- What data or master data issues were discovered, and how significant are they to fix?
- How much effort would be required to extend the model to the full production scope?
- Did the collaboration with the solution provider give confidence in the implementation phase?
It is equally important to evaluate what the PoC did not prove. Gaps are not automatically a reason to stop. They are information. A gap in master data quality is a solvable problem. A gap in the software’s ability to handle a core constraint is a more serious concern. Distinguishing between the two is what makes the evaluation genuinely useful.
With Delfoi Planner, we structure the PoC so that it doubles as a design phase for implementation. By the end of the pilot, the scope, data requirements, and integration approach are already defined, which means the path from proof of concept to production deployment is shorter and better understood. The key outcome is not a finished system. It is confidence: a clear picture of what the solution can do in your environment and what it will take to make it work at scale.
