Features
Procurement
Procurement inside a maintenance system exists for one reason: the part or the service is the thing standing between a broken device and a working one. Every hour spent in an approval queue is downtime, and the only interesting question is where those hours actually go.
- Hospital operations
- Biomedical engineering
- Executive and finance
What is procurement in a maintenance context?
Definition
Maintenance procurement
Maintenance procurement is the path from an identified need, usually a part shortage or a service requirement, through your approval rules, to a quote, an order, a delivery received against what was ordered, and a record of how the vendor actually performed.
The chain matters more than any link in it. A shortage that becomes an order that becomes a delivery that becomes a fitted part is one story about one device, and when it lives in four systems, nobody can tell you why a repair took three weeks. They can tell you the order was placed on time, which is the answer to a question nobody asked.
Approval rules are configuration. Who may approve what, and above which value, is a policy decision belonging to your organisation, and Rydya never invents one. What it does is enforce the rules you set, on the server, and record the decision.
Why the delay is never where people think
Because the visible part of procurement is the ordering, and the expensive part is the waiting that happens before anyone has decided to order.
Ask a department where procurement time goes and you will hear about suppliers. Measure it and you usually find the supplier was the fast part. The time went into the gap between the technician knowing they needed something and a request existing, then into a queue waiting for an approver who was not told they were the blocker, then into a second queue because the first quote arrived and needed a comparison nobody had time to make.
None of that is visible in a purchasing system, because a purchasing system starts counting when the request exists. The hours before that are downtime with no owner, and they are invisible precisely because no record has been created yet. Meanwhile the ward has borrowed a device from another floor, and the incident that produces is a different report entirely.
This is why procurement here starts at the shortage rather than at the request. A part that fell below your reorder point is a fact the system already knows, and turning that into a request should not require a technician to notice it and go somewhere else to say so.
How a shortage becomes a fitted part
Detected, requested, approved on your rules, quoted, ordered, received against the order, and fitted to the job that needed it.
- 1
The shortage is detected
A worker evaluates stock against the thresholds you configured and raises it before the repair that needs the part. The chain starts from a fact rather than from somebody noticing.
- 2
The request carries its reason
Tied to the asset, the work or the shortage that caused it. A request without a reason is a line item; a request with one is a decision somebody can actually make quickly.
- 3
Approval follows your rules
Who approves what, above which value, is your configuration and is enforced on the server. Approvers are notified and chased, because an approval queue that nobody is told about is just a delay with a name.
- 4
Quotes are comparable
Side by side, with the original amount and currency preserved. Conversions live separately with their rate id, source and timestamp, so a comparison is reproducible months later rather than a snapshot of a rate nobody recorded.
- 5
Receipts are checked against the order
What arrived against what was ordered, with the discrepancy visible rather than absorbed. The parts land in the store as ledger movements, available to the job that has been waiting for them.
Vendor performance, measured rather than remembered
From the jobs that actually happened, not from an annual review meeting where everyone recalls the same two incidents.
Delivery against promise
What was promised, what arrived, and when. Recorded per order rather than reconstructed at renewal, which is the point at which everybody's memory has become an argument.
Service response, from real work orders
When a vendor engineer was engaged and when the device came back. This is downtime the vendor owns, and it is the number most contract negotiations are conducted without.
Cost against the original amount
Immutable, with conversions kept separately. A vendor comparison that quietly revalues history is a comparison you cannot take to a negotiation.
External engineers see only their work
The external vendor scope: the work orders they are engaged on and nothing else, enforced on the server. This is the scope most systems forget, which is how vendor access becomes a shared login with far more reach than intended.
We will not set your approval thresholds
Who may approve what, and above which value, is a financial and governance policy belonging to your organisation. Rydya ships no defaults here and never will, because a default approval limit is a piece of software making a policy decision on behalf of a finance director it has never met. Configure it, and the platform will enforce it on the server and record every decision.
Questions
Does Rydya set our approval limits?
No, and it ships no defaults. Who may approve what, and above which value, is a governance and financial policy belonging to your organisation. Rydya enforces the rules you configure, on the server rather than in the interface, and records every approval decision in the audit trail.
Where does procurement time actually go?
Usually not to the supplier, which is the part everybody blames. It goes into the gap before a request exists, and then into approval queues where the approver was never told they were the blocker. Those hours are invisible to a purchasing system, because it only starts counting once the request exists, which is why Rydya starts the chain at the shortage instead.
How is vendor performance measured?
From the orders and work orders that actually happened: what was promised against what arrived, and when a vendor engineer was engaged against when the device came back. Measured continuously rather than reconstructed at renewal, when everybody's memory has already become an argument about the same two incidents.
Can an external service engineer see our whole estate?
No. Vendors have their own scope: the work orders they are engaged on and nothing else, enforced by server-side permission checks and row level security. This is the scope most systems forget entirely, which is how vendor access quietly becomes a shared login with far more reach than anyone intended.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us