Evaluate mining fleet management by asking why a particular unit received a particular assignment and what evidence supports that decision. Separate operating constraints from dispatch objectives, then replay a difficult exception. A production dashboard is useful, but the selection decision also needs an understandable path from input data to assignment and outcome.
Begin with the people who own dispatch, planning, maintenance information and operational review. Ask each to identify the data they provide and the decision they expect the system to support. Preserve the mine’s existing authorised procedures while designing the evaluation; a software demonstration should use a non-live replay environment.
Wenco’s publisher pages provide examples of mining-specific dispatch, fleet-management and reporting functions. The original decision packet below turns those examples into questions for a shortlist. Its purpose is to make the demonstrated configuration legible, including the conditions under which an assignment should remain unresolved.
Which dispatch decisions are you actually comparing?
Wenco describes dynamic dispatching as assigning trucks to load and dump points. Wenco’s dispatching page describes configurable preferences for operational objectives. In its dispatching description, the important selection question is how the proposed objective is represented alongside the conditions that determine an eligible assignment.
Write the objective in plain language before viewing an optimiser. For example, the business may want to compare a chosen production objective with waiting time or equipment use. Ask what the proposed configuration is trying to improve, which inputs it needs and which constraints it must respect. A preference for an outcome should remain distinguishable from a rule that makes a destination unavailable.
Wenco’s ore-quality dispatch description uses mine-planning data for load and dump assignments. Ask the demonstrator to identify the actual planning input, its owner and its effective version. The useful evidence is a traceable relationship between the input used and the decision shown, rather than a general statement that planning and dispatch are integrated.
Wenco describes activity dispatching around shift changes, meal breaks and other production pauses. Wenco’s fuel-dispatch description includes staggered assignments. Keep these decisions visible in the proposed scope. Ask how an activity assignment relates to a production assignment and which record explains a change from one to the other.
What do assignment controls and operational indicators establish?
Wenco describes a drag-and-drop interface for trucks, excavators and auxiliary units. Wenco’s fleet-management page lists assignment changes, locks and bars. Ask the demonstrator to show the meaning and scope of each relevant control in the proposed fleet-management product, including who can apply it and how another user recognises its effect.
Treat the labels carefully. A control called a lock or bar needs an explanation of what it prevents, when it takes effect and how it is removed. Define any required operational restriction separately through the mine’s established process. The demonstration should show the actual software behaviour without turning an interface label into an assumed safety mechanism.
Wenco’s fleet-management page includes responding to OEM alerts. Ask which alerts the proposed configuration receives and how their state reaches the people making assignments. A useful test identifies the source event, receipt time, displayed information and subsequent decision. It also asks what the user sees if the expected update has not arrived.
Wenco lists availability, cycle times and payload compliance among tracked production indicators. Agree the meaning of every indicator used in the evaluation. Request the underlying events, units and inclusion rules. A number labelled availability should have an explanation that the dispatch and maintenance reviewers can both follow.
Original dispatch decision packet
This hypothetical packet uses unit U-A, load point L-A and destination D-A. These are fictional identifiers. It is a proposed record for a non-live replay, with all operating constraints supplied by the site’s authorised owners. It contains no recommended route, payload, grade or operating threshold.
| Packet section | Information to capture | Question for the demonstration |
|---|---|---|
| Decision context | Unit, proposed origin, destination and decision time | Can another reviewer identify the exact assignment? |
| Eligibility inputs | Applicable site-provided constraints and their versions | Why was this destination eligible at that moment? |
| Dispatch objective | Selected preference and configuration owner | What was the assignment intended to improve? |
| Data freshness | Source event time, receipt time and known gaps | Which information was current when the decision was made? |
| Manual intervention | Actor, stated reason and resulting assignment | Can an override be distinguished from an automatic decision? |
| Outcome evidence | Relevant cycle or activity events and exceptions | Can the result be traced back to this assignment? |
Complete the packet for a straightforward example first. Ask the demonstrator to explain the assignment using the captured information alone. If the explanation relies on an undocumented assumption, add the assumption to the evaluation questions and identify who is qualified to resolve it.
Next, remove the attractive dashboard view and ask another reviewer to reconstruct the decision from the retained record. This tests the handover between operation and analysis. It can reveal a missing reason, an unclear time reference or an event that cannot be associated confidently with the assignment being discussed.
How should a closed-destination exception be replayed?
In the fictional scenario, D-A initially appears in the candidate set. The authorised destination owner then supplies an updated state marking it unavailable for the replay. Record the effective time of that state and the time the dispatch system receives it. These are different facts and both matter to the explanation.
Ask the demonstrator to process the replay under the proposed configuration. Record which candidate is shown, whether an existing assignment changes and what the operator sees. Keep the observed result separate from the requirement. If the required restriction is not demonstrated, retain it as unresolved rather than explaining it away through a favourable production total.
Repeat with the update deliberately withheld in the test environment. Ask how stale information is indicated and who owns the next decision. The exercise is about exposing the data dependency; it is not an instruction to continue real operations without current information. Any operational response belongs to the site’s authorised procedures.
Then introduce a manual assignment change. Ask the reviewer to distinguish that intervention from the earlier automatic suggestion. Capture the actor, reason, information available at the time and resulting event trail. This gives the shortlist a concrete question about decision accountability without assuming a particular audit feature exists.
What operating evidence should support the comparison?
Wenco’s data-and-reporting page describes real-time dashboards for operational performance. Wenco’s reporting page describes combining data from FMS, mine planning, ERP and CMMS sources. Use its reporting description to identify the proposed inputs, then request evidence for the integration actually offered to your operation.
For each selected indicator, retain a definition card: event source, reporting window, unit, excluded records and correction process. Ask how a delayed event or a changed status affects the displayed result. This turns a reporting discussion into an investigation of how the measure is produced, rather than a comparison of impressive-looking totals.
If the evaluation includes an improvement claim, require a defined baseline and a comparable observation method before discussing an outcome. Keep changes in fleet composition, operating conditions and data completeness visible in that comparison. The original packet provides a place to organise evidence; it does not supply measured results for your mine.
What should the selection record contain?
Retain the replay inputs, completed packet, observed exceptions and unresolved configuration questions. Identify which requirements were demonstrated and which need further technical or operational review. Include the product version and proposed integration scope so a later reviewer can assess the same configuration.
Use business systems for wider integration planning and web development for a defined software scope. To discuss the software requirements, get started with the decision packet and the data relationships the demonstration still needs to prove.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.