TL;DR
- Collection, post-processing and optimisation are three distinct stages with different tool requirements; conflating them is the usual source of rework.
- Fix the KPI definitions before the first test day, not after the data is in.
- Acceptance reporting should be a by-product of the workflow, not a separate manual exercise.
What should be decided before any data is collected?
Three things: the KPI definition set, the route plan and the pass/fail thresholds. If these are decided after collection, the data will almost always turn out to be missing something — a route that did not cover the target cluster, a KPI that cannot be computed from the logs captured, a threshold nobody agreed on.
The KPI definitions matter most because they are the hardest to change later. Event detection parameters — what counts as a dropped call, a handover failure, a throughput degradation — determine every number downstream. Locking them before testing is what makes results comparable across clusters, quarters and vendors.
| Stage | Question it answers | Typical tool |
|---|---|---|
| Planning | Where should the network be and how should it be configured? | ATOLL |
| Collection | What is the network actually doing on the ground? | TEMS Investigation, TEMS Pocket, Nemo Handy |
| Post-processing | Why is it doing that, and where is the worst of it? | ACTIX Analyzer, TEMS Discovery |
| Acceptance reporting | Does it meet the contractual thresholds? | ACTIX Analyzer reporting |
Where does post-processing fit?
Post-processing turns logs into comparable measurements. It is where multi-vendor normalisation happens, where KPIs are computed against the locked definitions, and where the difference between a network fault and a device fault becomes visible.
The common mistake is treating post-processing as reporting. It is not: reporting is the output of post-processing, and if the two are the same step, the analysis is usually too shallow to explain anything. The useful post-processing output is a ranked list of problems with evidence, not a KPI table.
How does optimisation connect back to planning?
Optimisation findings should feed the planning model, not just the parameter database. If measurements consistently show weaker coverage than predicted in a particular clutter type, the propagation model is wrong and the next cluster will inherit the same error.
This feedback loop is what separates teams that improve over a rollout from teams that fight the same problems in every cluster. It requires the measurement and planning tools to share a data format, which in practice means choosing tools that can exchange data rather than assuming someone will reconcile spreadsheets afterwards.
Where does acceptance reporting belong in the workflow?
At the end, and automated. If acceptance reports are assembled manually from exported data, the effort scales with the number of clusters and the consistency degrades as the programme grows. If they are generated from the same locked KPI definitions used in analysis, they cost almost nothing to produce and they are comparable by construction.
This is the practical argument for a post-processing tool with a configurable KPI engine rather than one with fixed reports: the report format changes between contracts far more often than the analysis does.