Asset data in SAP · Karaoglu Ltd, Paphos
The real asset register is the one the plant uses
After go-live there are two asset registers: the one in SAP, and the one the plant works from.
Register here: functional locations, equipment and the work booked on them, not the asset ledger.
Why your plant keeps a second register
The second register is a spreadsheet, a whiteboard, or one person who knows. Closing the gap between the two is operating work rather than a phase of a project: it opens again every time the plant changes and the record does not.
Start with your identifiers. When a functional location's key encodes its own place in the hierarchy — plant, area, unit, all in one string — that key is an address and not a name. Renaming one level rewrites every identifier beneath it, and everything already booked against the old keys has to be carried across deliberately. The tool will do the cascade; what happens to the history is a decision somebody has to make. That is why a structure gets frozen early in a project and is still wrong years later: the correction was never one field.
Then ask how damage is recorded. A code picked from a catalogue can be counted; the same observation typed into the long text cannot, and nobody misses it until somebody asks which failure is the most common one. A year of free text is a year with no answer to that, and every notification in it looks complete.
Then ask whether the field you want is a field at all. The equipment master has no place to put a pressure rating, a duty or a flow — those are characteristics on a class — so a report built from master-record fields alone comes back empty, and an empty column reads as missing data rather than as a question nobody asked.
A register with nothing booked against it is a drawing, not a register.
Ask about your own register
If this is what you are seeing, write and say which.
Why an empty object is the interesting one
An object with neither a notification nor an order is healthy, or out of service, or was never there — and the register cannot tell you which of the three. That list is where a review starts. The total is where it ends up if nobody asks.
The two records are not interchangeable. The notification says what was seen, and anyone walking past can raise one. The order says what was actually done, it was authorised, and it costs money. A register judged on notifications alone measures attention rather than work.
Read each arrow from the object that carries the reference. An order holds the notification it came from, in AFIH-QMNUM, so the line runs from the order — and the notification carries the link back, in QMEL-AUFNR.
Measuring points and their readings are where the register keeps what moves. A measuring point is master data: it sits on one object — equipment or a functional location, as the object on a notification or an order can be either — and says what is watched there and whether it counts. Each reading is a measurement document against the point, with the date it was taken, so what you hold is a series and not a single number. Put a running-hours counter on the functional location and it counts the position, across every machine that ever stands there; put it on the equipment and the hours leave with the machine.
Now look again at the two arrows leaving the order. It carries its own object and the notification it came from, and nothing makes those two the same object. Raise the order against the skid and the notification against the pump standing in it, and one repair is split across two histories: the pump carries a fault that was never repaired, the skid carries a repair for a fault nobody reported. Take a month of closed orders and compare the two objects before you trust either count.
Working notes
Each note settles one decision. Start with the first.
The register itself
The field you want is not on the record
Where your plant's own fields actually live, which object each one belongs on, and why the columns are empty the first time somebody needs them.
Getting one built
Places before things, things before work
Places before the things installed in them and objects before the work booked on them, so the order of a load is never the thing to argue about.
After go-live
When a correction is slower than the next order
A wrong object stays wrong when the days to correct it outrun the days to the next order booked against it, and both numbers are already recorded.
Three decisions decide whether a register survives
What do I count first?
Count the objects with nothing booked against them before you count the total.
Each one is healthy, or out of service, or was never there, and that list is the shortest honest starting point you have. A planner can sort it in an afternoon. A report cannot sort it at all.
Why is the wrong label still there?
The technician who finds the wrong label is the one who may not change it.
So nobody changes it, the next order is booked to the object next to it, and the history of both is now wrong. Name who may correct a structure, name who signs the correction off, and measure that route in days. An unroutable correction is how a register stops describing the plant.
What has to be decided before go-live?
Keep the structure central and the condition local, and write the split down before go-live.
Who may create a functional location, and who may only report against one, is a decision. Write it down field by field while there is still a project to write it into. Afterwards it gets decided by whoever holds the authorisation, and nobody wrote that down either.
Questions readers ask
How deep should structures go?
As deep as somebody will book work.
Every level you add is a level somebody has to keep, and a level nobody ever books an order against goes wrong quietly. The test is not the drawing: it is whether a planner will ever raise work at that level. If the answer is no, what you are holding is an attribute of the place above it or of the equipment standing in it — a characteristic, not a new functional location. Depth is the cheapest thing to add at design time and the most expensive thing to take back afterwards, because by then the levels carry history.
Functional location or equipment?
Ask whether it stays.
A functional location is a place: it is still there when the machine standing in it is carried out. Equipment is a thing that moves between places, and its history travels with it. Get the split wrong and the history follows the wrong object: either the place keeps the repair record of a pump that is now in another plant, or the pump arrives somewhere new with nothing behind it.
Does the register still match the plant?
Look at what has been booked against it.
Objects carrying notifications and orders are objects somebody is using. Objects carrying none are the interesting list, and the system will not tell you why they are empty — that is a question for the planner and the person who walks the site. A count of objects is not a measure of a register; a count of objects with work against them is.
What does a first conversation cover?
Whichever of these is open where you are.
Bring the structure, or the list of objects with nothing booked against them, or whatever the correction route is today — in whatever state it is in. The time goes on finding the thing nobody has written down yet and saying who should own it.
Why are no clients named?
Because yours would be next.
Nothing you show us turns up here later: not your plant, not your system, not the shape of your structure. What you get instead of a case study is the pattern — the decision that recurs, with everything that would identify anybody taken out. And no example here is a real project with the labels swapped.
Where was this equipment before?
Its installation history, not the master record.
The master record says where a thing is now. Where it has been is the run of installation periods behind it: each functional location it sat at, with the date it arrived and the date it left. A report that reads only the current assignment answers "what is installed here" as of today — and it answers the same way when the question was about last year. If you are comparing cost or failures by location across two years, the key date is part of the question and somebody has to choose it.
Do you keep our data?
No further than the deliverable needs.
No contracts received from a client, no system exports, no meeting recordings. What is not needed to produce the deliverable is not collected, and nothing is kept to train anything on.
Which one is open on your project?
One of the three above, or the one actually blocking you.
What happens when you write or call
You will not find a form here. A mail from your own address arrives as something we can answer, and a number is a number you can dial without asking anybody for it first. Neither can be down, and neither leaves a list of people who once looked.
Nothing here collects anything about you: no form, no tracker, no third-party request of any kind. What we know is what you chose to write, and it goes no further than answering it needs.
A call is the shorter route. Bring whatever state the structure is in — the list of objects with nothing booked against them, or the correction route as it stands today. That is the conversation, not a prepared version of it.