A request arrives: ‘Need Siemens drive urgently.’ Search can produce hundreds of results within seconds, but most of them will be answers to questions nobody has asked. Which family? Which power rating? Which input voltage? Which firmware or option card? Is the installed drive actually at fault? Will a repair help, or is an exchange required before the line's next shift? Can engineering approve a later revision? Until those boundaries are known, speed produces noise.
The purpose of a requirement is not to make the buyer complete a perfect form. It is to create a shared object that a maintainer, buyer, supplier and agent can all test against. The requirement should expose what is known, what is inferred, what is still missing and who may decide the trade-offs. That work narrows search, makes supplier replies comparable and prevents a plausible alternative from becoming an accidental engineering decision.
1. Resolve the installed object
Industrial identity lives in exact strings and physical details. A family name can span different voltages, interfaces, revisions and safety functions. One omitted suffix can change the unit. Start with the full nameplate, not a transcription from memory. Photograph the plate square-on and close enough to read; then photograph the full unit, connectors, terminal layout, option cards, keys, labels and its position in the assembly. Keep the original files because crops and messaging apps can remove useful detail.
- Manufacturer and complete catalogue or model number, including every prefix, suffix, space and separator.
- Revision, series, firmware, hardware version and serial number where present.
- Electrical and mechanical ratings: voltage, current, power, frame, shaft, flange, connector or mounting pattern as relevant.
- Installed options, daughter boards, communication modules, software licences or parameter sets.
- Photographs and documents tied to the object, with the date and origin preserved.
Manufacturer tools and migration guides are useful at this stage. Rockwell's lifecycle and migration resources use catalogue-number lookup because the precise identity determines status and possible replacement guidance. That guidance is evidence about a product route, not automatic approval for the installed application.
2. Describe the function before the failure
The same component can carry very different operational risk depending on what it does. Record the machine or line, the component's function, normal duty and the consequence of its loss. Is it a redundant sensor on a slow process, the only safety-rated controller on a packaging cell or a drive that must restart with a preserved parameter set? Function explains why the deadline and acceptable solution take the shape they do.
Keep observation separate from diagnosis. ‘Display is blank and the upstream breaker remains set’ is an observation. ‘Power supply has failed’ is a diagnosis. The distinction gives a repair specialist room to challenge the fault theory and stops the search from being restricted by an unsupported conclusion. Include fault codes, event logs, measurements, recent interventions and the tests already performed.
3. Turn ‘urgent’ into a time and place
Urgent is not a deadline. State the delivery site, receiving constraints, useful-by time and what happens after it. A unit dispatched on Thursday is not useful if it must clear customs, arrive at a remote site and be installed before Friday's production window. If there are several useful outcomes, record them: an exchange unit tomorrow, a repair completed within three days, or a migration kit before the planned outage next month.
Time should be paired with condition. New manufacturer stock, unused surplus, refurbished, repaired, exchange and tested used units can have different lead times and risks. The buyer should state which states are acceptable, which need special approval and which are excluded. A supplier should not infer that boundary from the urgency.
4. Write the substitution boundary
A later revision, successor product or nominally equivalent component may require new wiring, software, parameter conversion, certification, validation or spares. Manufacturer migration documents can identify a route, but only the authorised technical owner can decide whether it is acceptable in the installed context. The requirement should name that person or role and make the boundary explicit.
- Exact only: no different revision, condition or route without returning for approval.
- Revision-flexible: specified later or earlier revisions are acceptable after stated checks.
- Condition-flexible: repair, exchange, refurbished or tested used routes may be compared under separate evidence requirements.
- Functionally flexible: alternatives may be proposed, but differences and implementation work must be documented for technical approval.
- Migration open: the buyer wants both the immediate recovery route and the supported long-term replacement path.
‘Equivalent accepted’ is too broad. A good boundary names the dimensions that cannot change and the tests or authority needed for the dimensions that can. This is where human judgement belongs. Search can find candidates; it cannot silently redefine the plant.
5. Decide what a complete answer looks like
Suppliers answer more consistently when the requested response has a shape. Ask every route for the same commercial and technical fields: exact identity, quantity, condition, serial evidence, test scope, physical location, possession status, dispatch date, delivery estimate, price, currency, Incoterm where relevant, warranty, return terms, quote expiry and legal seller. Ask alternatives to state every known deviation from the requirement.
This is not bureaucracy. It prevents the fastest reply from winning simply because it is easiest to read. An offer with an attractive price but no confirmed possession should remain below a slower, fully evidenced route until the gap is resolved. Unknown should be a valid field, not an invitation to invent certainty.
An illustrative requirement, before and after
Before: ‘Urgent Allen-Bradley SLC processor, Europe. Please quote.’ The request is searchable but not safely answerable. It can attract the wrong memory size, series, firmware, condition, geography and delivery promise.
After: ‘One 1747-L553, Series C preferred, installed as the line controller on a packaging cell in Valencia. Existing unit shows a persistent fault after power and chassis checks; diagnostic file and nameplate photographs attached. Production is stopped. A confirmed unit must arrive at the site by 12:00 Thursday. Tested used or refurbished is acceptable with current serial photographs, test scope and six-month warranty. Series B or a successor may be proposed only as a separate option and requires controls-engineer approval. Also quote an exchange repair if dispatch can occur sooner. State physical location, present possession, dispatch time, legal seller and quote expiry.’
The example does not guarantee the diagnosis or the availability. It does something more useful: it gives each possible route the same question. Exact stock, exchange repair and migration can now be compared without pretending they are the same solution. The controls engineer can see where a decision is required, and the buyer can reject a vague reply without another round of interpretation.
Common ways the packet goes wrong
- The form demands every field before work can start. A requirement should expose gaps, not block triage when the plant is down.
- A guessed diagnosis is stored as fact. Preserve the symptom, the diagnostic hypothesis and who supplied each one.
- The catalogue number is normalised until meaningful punctuation or a suffix disappears. Keep a literal transcription and a search-normalised copy.
- The deadline describes dispatch instead of useful arrival. Include geography, receiving hours and installation window.
- Alternatives are invited without naming approval authority. Route them to the responsible technical person before they become offers.
- Every supplier gets a different version of the request. Freeze a comparison baseline and record later amendments.
The minimum viable requirement
When time is short, capture seven things: literal identity, original evidence, machine function, observed failure, destination and useful-by time, acceptable condition, and substitution authority. Mark every unresolved field. That is enough to begin deliberate branches across authorised supply, specialist stock, repair and migration while better evidence is collected.