Guide · fleet management
Road-rail equipment fleet management software
To choose road-rail equipment fleet management software, first list the decisions you make every week (which machine to assign, which configuration, which documents, which flagged issue to handle), then check six points: the machine record, scheduling, offline field work, history, access security and a pilot run by future users.
Criteria for choosing road-rail equipment fleet management software: data, scheduling, offline field work, history, security and a pilot deployment.
Starting point
Describe the decisions to make before comparing software
The search often starts with "manage the equipment" or "replace the spreadsheets". These goals are too broad to tell two solutions apart. You first need to list the recurring decisions: which machine to assign, which configuration to prepare, which documents to find, which flagged issue to handle and who can update a status.
A short workshop with the fleet manager, a field user and the workshop lets you reconstruct three or four real workflows. You follow a request from its origin to its closure, noting re-entered data, attached files and the moments when the team waits for information. This work provides verifiable criteria and avoids buying an appealing application that does not reflect the organisation.
Working checklist
- ✓ Choose a frequent mission and a mission involving a deviation or unavailability.
- ✓ Identify the machine, its equipment and the configuration actually used.
- ✓ Name the person who prepares, the one who records and the one who decides.
- ✓ List the documents read, produced or updated at each step.
- ✓ Identify periods without network coverage and the devices used in the field.
- ✓ Define the expected outcome: report, action, history or availability change.
The real process is the requirements specification
A demo becomes useful once it reuses the company's data, exceptions and roles. A long list of features does not prove that a complete scenario can actually be run.
Business architecture
Check that the machine record links the right information
In a road-rail fleet, a single number is not always enough. The base machine, its railway components, its attachments, its configurations and the associated parts must be distinguishable without multiplying contradictory records. The model must also keep track of changes: replacing a document or closing a flagged issue must not erase what led to the decision.
Trackary centralises one record per machine, configurable categories, scheduling, inspections and the report history. Scoping defines the level of detail each customer needs: too little structure turns the application into a PDF store; too many fields slows down data entry and encourages workarounds.
| Item | Demo question | Warning sign |
|---|---|---|
| Identity and configuration | Can you distinguish the machine, its equipment and their condition at a given date? | A free-text field has to explain every variant |
| Documents | Is a document linked to the right machine, a scope and a version? | Files are only sorted into folders |
| Deadlines and actions | Does an alert lead to the report and then to resolving an observation? | The date turns green with no evidence or decision |
| Missions and reports | Does the field finding join the history without re-entering data? | The final PDF stays separate from the equipment record |
Evaluation
Have future users run the scenarios
A proof of concept should not be a second sales pitch. The manager prepares a work order, the technician opens their day, records an entry with a deviation, then the office finds the report and assigns the follow-up. If field coverage can be patchy, the scenario is repeated with the network deliberately switched off.
Watch the number of steps, how well statuses are understood and where a user hesitates. The quality of support matters as much as the interface: data migration, template configuration, access management, training and support should each have an owner and a deliverable.
- Prepare a representative data set Import a few realistic machines, configurations, documents and deadlines, without using sensitive data you do not need.
- Run a normal departure Schedule, view the record, complete the planned inspection and produce a report without constant assistance.
- Introduce a deviation Add an observation, a useful photo and an action, then check who is notified and who can close it.
- Test prepared offline work Load the mission, switch off the network, enter data, restart the app then check synchronisation on return.
- Review the history Ask someone who did not take part in the test to explain the timeline and the decisions.
Offline does not mean unlimited functionality
The scope available locally, the volume of attachments, recovery after an interruption and conflict handling must be tested on the devices and scenarios of the real deployment.
Decision and deployment
Score the coverage, then secure adoption
The scoring grid should separate three levels: covered natively, covered after configuration, or requiring customisation. This distinction makes cost and timeline clear. It also avoids treating a feature merely mentioned during a demo as available.
After the choice, a pilot scope lets you clean up data and adjust templates before rolling out more broadly. Useful indicators relate to the work done: completed reports, assigned actions, time spent finding a part, entries awaiting synchronisation and deviations still without a decision. The number of logins alone does not tell you whether the fleet is better managed.
- Assign an owner to each imported reference data set and define the authoritative source.
- Document the roles: view, prepare, record, review, decide and administer.
- Limit the first deployment to one complete workflow and a group able to give precise feedback.
- Set a data correction rule rather than hiding duplicates during migration.
- Review templates after the first missions and keep a record of why changes were made.
What Trackary can demonstrate
Trackary centralises machine records, scheduling, configurable inspections and the report history. When an offline workflow is included and configured, its scope must be confirmed during scoping and tested under the real conditions of the deployment. Any specific integration or customisation must also be confirmed.
Going further
The same criteria apply to general-purpose equipment fleet management software or a CMMS. To compare budgets, read our page on the cost of a CMMS; for inspections, our VGP inspection tracking software; for maintenance, the free preventive maintenance plan. A mixed fleet (construction, handling, lifting, road-rail) can be tracked with a single equipment management software.
Frequently asked questions
Sources and limits of this guide
- SNCF Réseau — Checking the compliance of your works equipment ↗ Official background on checking the compliance of works equipment; it shows why a software status does not replace a process carried out by the competent party.
- INRS — Initial or periodic inspections ↗ Reference points for distinguishing upkeep, inspections and responsibilities; useful for separating the items tracked in the software.
- SNCF Réseau — RFN-IG-SE 09 B-00 n°001, version 7 ↗ SNCF Réseau specific operating rule, available on the EPSF portal, to be consulted within its scope; it reminds us that categories and conditions of use cannot be reduced to a generic field.
- Software centralises information and formalises a process defined by the organisation. It does not replace regulatory analysis, physical inspection or the decision of a competent person.
- Features, integrations, migration timelines and support arrangements must be verified in a demo and a proposal matching the real scope.