Custom software for your HACCP plan and control points
At most companies the HACCP plan is a Word file that was written properly once. Then a new product was added, a processing step moved and a supplier changed. The plan did not change with them. What is measured daily then comes from an analysis of a different process than the one that actually runs.
Where the plan drifts from the process
HACCP rests on seven principles from the Codex Alimentarius: conduct a hazard analysis, determine critical control points, establish critical limits, establish monitoring, establish corrective actions, establish verification, and establish record-keeping. The first three are design work and happen once. The last four are daily work. Software almost always focuses on those last four.
That is understandable, but it leaves the greatest risk unmanaged. If a control point sits at the wrong process step, or if a critical limit is not justified, then you faithfully and daily measure the wrong thing. In an audit that is a more serious finding than a missed measurement, because it goes to the foundation of your system rather than its execution.
The trigger for review is also more concrete than people think. Every change in product, process, supplier or packaging is reason to revisit the hazard analysis. In practice those changes happen weekly, while the plan is reviewed once a year. That difference in pace is exactly where the gap arises.
How we build this
The process flow diagram is the foundation. Hazards, control points and limits attach to a step, not to a chapter in a document.
Every step with its inputs and outputs. As long as the process flow diagram is a drawing in an appendix, nothing can hang off it and everything drifts apart.
Biological, chemical and physical, per step, with an assessment of likelihood and severity. This makes visible which steps have been left empty.
Not just the outcome but the route to it. In an audit the question is about the justification, and that lies in the answers, not in the conclusion.
A new product, a different supplier or a shifted step triggers a review of the relevant analysis. Without that link, the plan goes out of date unnoticed.
What the software actually does
The process flow diagram with the hazard analysis carries everything. What else you need depends on how many products and lines you have and how often something changes.
Hazard analysis per process step
Hazards per step with likelihood, severity and the control measure. A step without an assessment stands out, and that is the finding you would want to discover yourself.
Decision tree with its answers retained
The route to the conclusion, not just the conclusion. Why something is or is not a control point is the first question an audit will raise.
Limits with their justification
Each critical limit with the source it rests on: a legal standard, literature or your own validation. A limit without justification is an assumption.
From plan to daily monitoring
What needs to be measured, at what frequency and by whom follows from the plan and is passed on from there to the registration on the floor.
Review on change and over time
A new product or a different supplier reopens the relevant analysis, and the periodic review runs alongside it. Two triggers, one stream.
Versions you can compare side by side
When a complaint concerns a batch from last year, the question is which plan applied then. That is a different question from what applies now, and most systems can only answer the second.
Who we build for
How often the plan falls behind depends on how often your process changes. Four situations.
Production with varying recipes
Every new product affects the analysis. The gain is greatest here, because the triggers for review occur most often.
Storage, repackaging and distribution
Fewer process steps but more products from third parties. The hazard analysis then leans more heavily on what your supplier controls, and that changes with every change of supplier. For tracing this, there is BRCGS software.
Primary production and fresh products
Short chains subject to seasonal influences. Control more often lies in conditions set in advance than in measurements during the process, which calls for a different setup.
Businesses with multiple lines or sites
The same product on two lines may have different control points. One plan for everything is then incorrect, while a separate document per site is unmanageable.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Technology and integrations
Standards and insights change, and so does your process. Everything relating to hazards, decision rules and limit values should be adjustable and kept with a version history.
Why Appfront
The plan is the source of all measurements
We build the analysis as a given, so that what is measured daily actually follows from the analysis and not from habit.
The justification is the audit
We store the answers in the decision tree and not just the outcome. The conclusion is rarely asked about; the route to it always is.
A change must affect the plan
We link product changes and supplier changes to the relevant analyses. Otherwise the plan falls a year behind the process.
The question concerns then, not now
We build versions that can be compared side by side, because when a complaint concerns an old batch, the plan that applied at the time is what counts.
Security and privacy
A hazard analysis records your recipe and process steps, including where things can go wrong. That is commercially sensitive, and it is not something you want to show an customer unfiltered. We set access by role and by product, and log every view.
For this topic, the version history is itself a requirement. You need to be able to show which plan applied at the moment a batch was produced, and that only works if earlier versions have not been overwritten. We keep every change to a hazard, a limit or a control point with the time and the person responsible, and show an amendment alongside the old value instead of over it. How we handle security ourselves is set out in our information security policy; reports from outside go through our CVD policy.
Frequently asked questions about the HACCP plan
A logging app records the daily measurements. This software is about the plan those measurements come from: which hazards exist, which steps are critical control points and why, and which limits apply. If that is wrong, you faithfully measure the wrong thing.
The CCP app covers what happens once a measurement falls outside its limit: holding, correcting and releasing. That is the implementation of principle five. This page is about principles one to three, where that limit and that corrective action are determined.
No. Determining critical control points is the job of your HACCP team, who know your product and process. We build the place where that reasoning is recorded, with the answers from the decision tree and the justification for each limit, and where it is revisited as soon as something changes.
Alongside a periodic review, any change in product, process, supplier or packaging is a reason to look at the hazard analysis again. In practice that happens more often than the annual round many companies keep. That difference in pace is where the plan drifts away from the process.
Validation answers the question of whether the chosen control actually controls the hazard; you do this before putting the plan into use, using literature, a standard or your own research. Verification answers the question of whether it also happens in practice, through internal audits and checks afterwards. Both should be recorded.
Yes, and usually you need to. The same product on two lines can have different critical control points, for example because one line has a metal detector and the other does not. One plan for everything is then incorrect, and separate documents per location are unmanageable. We build variants on a single analysis.
Yes. The food safety plan is a fundamental part of both standards, and the evidence you record here ends up in your certification file. We link the two rather than mixing them; see also IFS and BRCGS software.
That depends on the number of products and process steps, whether there are several lines, and how much has already been recorded. The process flow diagram with the hazard analysis is usually quick to put to use and immediately shows where the gaps are; review workflows and variants grow after that. We give a reasoned estimate after the exploration phase.
Checking whether your plan still matches your process?
Take the latest product you have added and look up where it appears in the hazard analysis. If it isn't there, you have been measuring ever since on the basis of an analysis that doesn't know about it. We build this as a standalone application and as part of a broader custom software project.