Why Most Organisations Still Cannot Tell You What They Have 

Keyvan: Met the CFO at a financial services firm in London last week. First thing she asked was what her organisation actually had. Technology assets, condition, connectivity, cost. The team spent three weeks building the answer, working across three systems, two spreadsheets, and a discovery tool nobody had reconciled with anything since the spring. The answer came back hedged. She sent it back. 

Ray: She will keep sending it back. 

Keyvan: Because the data is not good enough. 

Ray: Because the data was built to run the tools. She is asking something different. 

A stone bridge crossed over our heads, four hundred years old, carrying a road on the level of the original city, somewhere walking distance above us. The bridge was older than the road. The road was older than the cars on it. 

Ray: Asset management has been a formal discipline since the early nineties. Every major platform supports it. Every framework describes it. Every organisation of any size has spent money on it. And almost none of them can answer the question your CFO is asking. 

Keyvan: So where does it break? The tools exist. The frameworks exist. There is thirty years of practice behind this. 

Ray: Four questions. That is where it begins.  Does it exist in our records?  Do we have records for everything we should?  Do we know how each thing changes over time?  And do we know what each thing supports?  

Those four, in that order. Each one is harder than the last and each one unlocks more value than the last. Most organisations cannot get cleanly past the second. They have some records. They know they are missing others. They have very little confidence in what they do have. 

Keyvan: I know those four questions. I have known them for fifteen years. 

Ray: Most people have. That is not the difficult part. 

We came past an old stone fountain with no water in it. The basin was dry and clean. Moss hung from where the spouts would have been. A small lizard crossed the lip of the basin and disappeared into the cracks. 

I told Ray about a workshop I ran in 2010. A rail infrastructure company. Thirty people in the room, and the head of configuration management had stood up at the start and announced to the whole group that they were doing exceptionally well. All four questions answered. He had total conviction. My colleague and I had been brought in because nothing was working. 

What we found was not what we expected. They did have tight control of their assets. The records were accurate. The discipline was genuine. But maintaining that accuracy had frozen the organisation. Every update needed verifying by hand. By the time we arrived they had a backlog of six hundred outstanding changes sitting unexecuted. The picture was precise. They had built an answer to a question nobody had asked. The organisation was standing still. 

Ray: That is the failure mode. The maintenance becomes the job. The picture is accurate but the organisation has locked up around the process of keeping it accurate. Six hundred changes in a backlog means six hundred things the picture is about to stop reflecting. Accurate today. Wrong by the time anything gets executed. 

Another bridge crossed above us, older than the last one. An old man was sitting on a stone bench in the shade beneath it, doing nothing in particular. He raised a hand without standing up. Ray raised his back, and we kept walking. 

Keyvan: So where does an organisation actually start? 

Ray: From the outcome. What decision depends on this data? A migration. A vulnerability patch. A licence audit. A change process that keeps breaking because nobody knows what it touches. You pick the use case first. Then you build the data quality the use case needs, exactly that, nothing more. Vulnerability remediation needs the first two questions answered cleanly across end-user devices and software, nothing else. The next quarter you take on the licence audit. The licence audit inherits everything that vulnerability work established and only has to add the third question for commercial software titles. The next use case inherits what you have already built and only adds what it needs on top. Each one becomes faster than the last. 

Keyvan: So it compounds. 

Ray: It compounds. The discipline breaks the moment everything has the same priority. You end up trying to maintain everything and you end up maintaining nothing properly. 

He described the structure he uses to make that choice. Business outcomes at the top. The four questions running down. Four families of asset running across: end-user devices, infrastructure, applications and services, software and licences. Each cell representing a specific use case and the quality of data that use case requires. Each family had its own picture. The laptop in the cupboard nobody has logged into for six months. The database server nobody can find an owner for. The customer portal nobody can decompose into the systems it depends on. The SaaS title the auditor is about to ask about. Each one a cell. Each cell with its own quality bar. 

Keyvan: It looks like a honeycomb. 

Ray: It is a honeycomb. Each cell is complete in itself. Each cell shares a wall with the next. The cells you build first carry part of the structure for everything that follows. 

Most asset management programmes are built around completeness, filling every cell at the same time to the same standard. The honeycomb works on a different principle. You build what matters, in the order it matters, and you let the quality accumulate. 

Keyvan: But we still have all the same infrastructure. Same tools, same systems, same repositories. None of that changes.