Part of The Beginning and The End of Information Management. Now available for pre-order on Amazon.
We live in the future. But we hold onto past ideas for too long. One of these ideas is that we should think of business processes before we think of technology or data.
This isn’t true. We should think of value, outcomes, markets, and a whole bunch of other important things and all of them are more important than technology by itself, data by itself, or business processes by themselves.
We have built functional organisations and filled them with people. So we’re going to get some perverse outcomes. People are good at that. It’s what makes our organisations interesting.
We spend so much time telling each other how business processes are more important than technology and data that it starts to feel like a discussion about value. But it’s not. Business processes, technology, and data are all equally important or unimportant. Each of them is only the most important thing to the functions and silos who are responsible for them. And there are only functions and silos responsible for them because that’s how we design our organisations.
But in modern organisations there are business processes, and types of business processes, and indeed whole business models, that can’t operate the way they are designed without the associated information technology. Likewise, all business processes depend on, generate, or coordinate with other business processes through data.
This means that at some level the idea that business processes “comes before” or are somehow conceptually “above” concerns about technology land data is no longer valid.
Justify the value of data
Imagine talking to the CEO of a nuclear power plant. You might say:
“Look, uranium is obviously critical to what we do around here.”
The CEO would nod in agreement or at least impatiently stare you into making your point.
“Well we’ve done a bit of a review and we’ve found some issues with the handling of the uranium. In fact, every time somebody goes near it we find it spreads. The Geiger counters are picking up radiation all over the plant.”
The obvious analogy here is with data: both critical to the operating model of most companies but also potentially risky if handled in the wrong way.
But if this situation played out like most data governance conversions it would continue like this:
“Okay, I know uranium is important. But what is the business value of it?” CEOs ask these sort of open-ended questions to uncover what you know, so this isn’t unusual.
“We it’s fundamental to how we operate. It’s a critical resource. Actually, because it’s a critical resource the way we manage it should be considered an asset. So these machines help us process it and the plant uses it to make power.” You’d feel like you are rambling now – and it’s not a very satisfactory answer but given this is a fundamental part of the operation of a uranium powered plant it’s actually hard to know where to start.
The CEO isn’t uninformed about the operations of the plant so he offers “So we have a cleanup crew for uranium incidents. I spend hundreds of thousands of dollars on this each year so I hope I’m getting something for it!”
This wasn’t where you’d start the conversation but it’s as a good a place as any so you offer “Yes, well that’s once something goes wrong. We need to be more proactive than that.”
“Yes, we need to be proactive. We want to innovate because our strategy is to be a leader in this area.”
“Great – yes – so the cleanup crew can help us once there is an incident but how do we ensure we handle the uranium in a way that reduces incidents?”
“Well we just switched suppliers so we’ll need to give them time to bed down their processes. They have productivity targets built into the contact so we should expect them to be more productive each year. Well they have to or I’ll cut orders from them! We wont tolerate breach of contract.”
You know that the supplier only handles the uranium to the delivery point, and the delivery points seem to be well controlled. Actually, there are a lot of controls in place, but some of them aren’t being followed, and some just don’t seem feasible to follow.
“Our suppliers aren’t the problem, it’s the way we handle the uranium after its delivered. Actually, there is a regulatory element to this too…”
“We want to be compliant!”
“Yes, but the readings we are getting all over the plant indicate that our handling may not be compliant”
“Darn regulators!”
“So let’s try to get compliant but at the same time let’s see if we can get business value from the compliance. There are a lot of sick days maybe they are related to the poor handling of the uranium.”
“I think that’s a cultural problem” the CEO is again attributing common actions across a large group of people to “culture” when you think he might mean “incentives”. But that’s another conversion. Anyway, he’s still talking.
“We need to get business value out of this initiate. I know uranium is important but what is the business value we are going to get form this initiative!?”
“Well at first we just want to contain the issue”
“What’s the ROI?”
“Well it reduces risk”
“Our risk appetite it low at the moment”
“So just to contain it we’ll need to slow down movement of the uranium at critical points and refurbish these damaged containment areas”
“How much will that cost?”
“$2 million”
“Well that’s a lot we don’t have that sort of budget allocated. These things always blow out we started an initiative 3 years ago and it was supposed to be $500k but it blew out to $800k”
“Well, actually this is just the first thing we need to spend, we’ll need to spend a lot more once we have a roadmap”
“I think we should do a roadmap first before we contain the uranium”
At some point in this conversation it’s the CEO that needs to be removed, not the data management consultant (Sorry, the person responsible for the uranium).
An important point: there is somebody in this fictional tale responsible for the uranium and having this discussion with the CEO.
Even if the conversation isn’t getting anywhere there is at least a significant budget allocation, a policy and process library, and a broad understanding across the plant about the dangers and proper handing of the uranium.
So if you’re having bizarre conversations like the one above – and they are about data, and not uranium – you’re at least trying to ensure that the value of data is understood.
But you’ll get into difficulty if you have to answer questions regarding “the business value of data”. The problem is not finding business value of data, the problem is realising that data has business value.
Data has a primary value.
Data isn’t only valuable because you can do specific things with it. Instead it’s valuable because you can’t do certain things without it. If you aren’t valuing the data you aren’t valuing the things you can do with it. If you have a car, and you want to drive it, you need wheels. The tires on the wheels need to be maintained. The business value of the wheels is the same as the business value of the whole car.
It’s hard to make an organisation think this way without sounding like what might be called “a data geek”. But it’s an important part of the transition you need to make into a data-driven organisation.
No organisation attempts to operate without people, but nobody asks “what is the value of people?”. We do have a variety of ways of managing people; including both disconnected performance management systems as well as a general consensus that all interactions people have with the organisation constitute a continuous feedback loop. But we’d never try answer such a general question as “what’s the value of our people?”
I.T. departments are unfortunately stuck in a service posture. They are stuck in the position of having to justify why something is important. You don’t need to do that for data. People know it’s important – when they ask about the value of data they are just messing with you.