Archive for the ‘Information Value’ Category
Information overload is as much an overwhelming feeling as it is a measurable reality. We often feel an impossible obligation to be across everything, which leaves us wanting to give up and absorb nothing that hits our various screens. Despite all this, the good news is that the majority of the information we need seems to appear just in time.
Where does that leave those of us who are control freaks? I am not comfortable to know that the right information will find me the majority of the time. I want to know that the information I need is guaranteed to find me every time!
The trouble is, guarantees are expensive. This is related to the debate between search based big data solutions and enterprise data warehouses. Google provides a “near enough” search solution that, given the massive amount of data it trawls through, usually seems to find what we need. Knowledge and business intelligence solutions provide the predictable information flows but come at a huge cost.
Of course, the real sense of serendipity comes when information arrives unsought just when we need it. It can come through the right article being highlighted in a social media feed, a corporate policy being forwarded or the right coffee conversation with a colleague. Of course, serendipity isn’t random coincidence and there is much we can do to improve the odds of it happening when we need it most.
Before doing so, it is important to know what things have to be predictable and reliable. A list is likely to include financial reports, approvals and other controls. What’s more, a scan of any email inbox is likely to show a significant number of messages that need to be read and often actioned. Despite its tyranny on our working lives, email works too well!
Serendipity depends on the quality of our networks, both in terms of who we know and the amount of activity the passes between the nodes. A good way to understand the power of relationships in an information or social network is through the theory of “small worlds” (see chapter 5 of my book Information-Driven Business).
Ironically, in an era when people talk about electronic isolation, social networks, that is who we know, are more important than ever. Serendipity relies on people who we know, at least vaguely, promoting content in a way that we are likely to see.
Just as control freaks worry about relying on serendipity, those that are more relaxed run the risk of relying too much on information finding its way mysteriously to them at the right time. Those that don’t understand why it works, won’t understand when it won’t work.
Far from making experts and consultants redundant, this increasing trend towards having the right information available when it’s needed is making them more necessary than ever before. The skill experts bring is more than information synthesis, something that artificial intelligence is increasingly good at doing and will become even better at in the near future. The job of experts is to find connections that don’t exist on paper, the cognitive leaps that artificial intelligence can’t achieve (see Your insight might just save your job).
The first thing is to be active posting updates. Networks operate through quid quo pro, in the long-term we get back as much as we give. In the office, we call this gossip. Too much gossip and it just becomes noise but the right amount and you have an effective social network. Those people who only ever silently absorb information from their colleagues quickly become irrelevant to their social circle and gradually get excluded.
The second is to be constantly curious, like a bowerbird searching and collecting shiny pieces of information, without necessarily knowing how they will all fit together. The great thing about our modern systems is that massive amounts of tagged content is easy to search in weeks, months and years to come.
Finally, have some sort of framework or process for handling information exchange and picking a channel based on: criticality (in which case email is still likely to be the best medium), urgency (which favours various forms of messaging for brief exchanges), targeted broadcast (which favours posts explicitly highlighted/copied to individuals) or general information exchange (which favours general posts with curated social networks). Today, this is very much up to each individual to develop for themselves, but we can expect it to be part of the curriculum of future generations of children.
No matter how often it seems to happen, almost by magic, information serendipity is no accident and shouldn’t be left to chance.
All over the web, authors are ranting about the misuse of the English language in business. It’s an easy article to write, picking out examples of jargon and the general torturing of sentences in the name of explaining apparently simple concepts while making the writer seem more impressive.
Some great examples from business can be found in this Forbes article: The Most Annoying, Pretentious and Useless Business Jargon. Examples that I like (or hate) include terms like “swim lanes”, “best practice” and “core competence”.
There are good reasons for using jargon Rather than take cheap shots, let’s start by asking why people use jargon in the first place. There are often good reasons for using most of the terms, even the ones that we all hate. Every discipline has its own special language, whether it is science, architecture, law or business across every industry. This use of language isn’t restricted to technical terminology, it also includes the way that concepts are expressed which can seem obscure or even absurd to an outsider.
While often justified, the use of jargon acts as a tool to exclude these outsiders from participating in the conversation. This is a problem because there is good evidence that some of the most exciting solutions to problems are multi-disciplinary.
Experts seldom realise that they might be missing out on a breakthrough which comes from another field. Business, for instance, is borrowing from ideas in physics (such as thermodynamics) in understanding the dynamics of markets as well as biology to understand how organisations evolve.
Just as fields of science, medicine and law have their own language, so does every aspect of business such as human resources, finance, sales et cetera. Even in general business, diversity of thought comes up with a better answer almost every time. Getting to those ideas is only possible if the discussion is intelligible to all.
Jargon to avoid debate
While many discussions use jargon and acronyms as a legitimate shortcut, some use of jargon reflects a lack of understanding by the participants or even an attempt to avoid debate in the first place. Take the example of “metadata”, a term which has appeared in many countries as governments struggle with appropriate security, privacy and retention regimes.
A plain English approach would be to describe the definition of metadata in full in every discussion rather take the shortcut of using the term on its own. The reality is that even landing on a definition can lead to an uncomfortable debate, but definitely one worth having as the Australian Attorney General learned to his determent in this interview where the purpose of a very important debate was lost in a confusing discussion on what metadata actually is.
The Attorney General isn’t on his own, many executives have been challenged in private and public forums to explain the detail behind terms they’ve commonly used only to come unstuck.
Sometimes people use jargon, like metadata, swim lanes and best practice because they are avoiding admitting they don’t know the detail. Other times, they are legitimately using the terms to avoid having to repeat whole paragraphs of explanation. Of course, this is where acronyms come into their own.
Balancing the needs of the reader and author
Given that it takes at least five times as long to write something as it does to read it (and a factor of ten is more realistic for anything complex) the authors of documents and emails can be forgiven for taking a shortcut or two.
The problem is when they forget that every communication is an exchange of information and while information has value, the value is not necessarily the same for both the writer and reader.
For example, there is little that is more annoying that receiving an email which requires extensive research to work out what the TLAs contained within it actually stand for. Of course, a TLA is a “three letter acronym” (the most popular length of acronym with examples including everything from “BTW” for “by the way” through to LGD for “loss given default”).
Our propensity for short messages has only increased due to our rapid adoption of texts, instant messaging and Twitter. I’ve written before about the role of email in business (see Reclaim email as a business tool). Clarity of meaning is fundamental to all communication regardless of the medium.
Given that it does take so much longer to write than to read, it makes sense for the writer to take short-cuts. However, if the information is of the same value to both the writer and reader, then the shortcut needs to offer a tenfold benefit to the writer to make-up for the additional cost in time to the reader who has to decode what the shortcut means.
This equation gets worse if there are multiple readers, if the benefit is greater to the writer than the reader or when the writer has the advantage of context (that is, they are already thinking about the topic so the jargon and acronyms are already on their mind).
In short, there is seldom a benefit to using jargon or acronyms in an email without taking a moment to either spell them out or provide a link to definitions that are easily accessed.
Is this the best you can do?
Perhaps the need to make sure that a reader’s time is spent wisely is best summed up in this anecdote told by Ambassador Winston Lord about Henry Kissinger (former US Secretary of State).
After giving Henry Kissinger a report that Ambassador Winston Lord had worked diligently on, Kissinger famously asked him if this “Is this the best you can do?” This question was repeated on each draft until Lord reached the end of his tolerance, saying “Damn it, yes, it’s the best I can do.” To which Kissinger replied: “Fine, then I guess I’ll read it this time.” (sourced from Walter Isaacson, “Kissinger: A Biography”, Simon & Schuster 1992).
Anthropologist Robin Dunbar has used his research in primates over recent decades to argue that there is a cognitive limit to the number of social relationships that an individual can maintain and hence a natural limit to the breadth of their social group. In humans, he has proposed that this number is 150, the so-called “Dunbar’s number”.
In the modern organisation, relationships are maintained using data. It doesn’t matter whether it is the relationship between staff and their customers, tracking vendor contracts, the allocation of products to sales teams or any other of the literally thousands of relationships that exist, they are all recorded centrally and tracked through the data that they throw off.
Social structures have evolved over thousands of years using data to deal with the inability of groups of more than 150 to effectively align. One of the best examples of this is the 11th century Doomsday Book ordered by William the Conqueror. Fast forward to the 21st century and technology has allowed the alignment of businesses and even whole societies in ways that were unimaginable 50 years ago.
Just as a leadership team needs to have a group of people that they relate to that falls within the 150 of Dunbar’s number, they also need to rely on information which allows the management system to extend that span of control. For the average executive, and ultimately for the average executive leadership team, this means that they can really only keep a handle on 150 “aspects” of their business, reflected in 150 “key data elements”. These elements anchor data sets that define the organisation.
Key Data Elements
To overcome the constraints of Dunbar’s number, mid-twentieth century conglomerates relied on a hierarchy with delegated management decisions whereas most companies today have heavily centralised decision making which (mostly) delivers a substantial gain in productivity and more efficient allocation of capital. They can only do this because of the ability to share information efficiently through the introduction of information technology across all layers of the enterprise.
This sharing, though, is dependent on the ability of an executive to remember what data is important. The same constraint of the human brain to know more than 150 people also applies to the use of that information. It is reasonable to argue that the information flows have the same constraint as social relationships.
Observing hundreds of organisations over many years, the variety of key data elements is wide but their number is consistently in the range of one to a few hundred. Perhaps topping out at 500, the majority of well-run organisations have nearer to 150 elements dimensioning their most important data sets.
While decisions are made through metrics, it is the most important key data elements that make up the measures and allow them to be dimensioned.
Although organisations have literally hundreds of thousands of different data elements they record, only a very small number are central to the running of the enterprise. Arguably, the centre can only keep track of about 150 and use them as a core of managing the business.
Another way of looking at this is that the leadership team (or even the CEO) can really only have 150 close relationships. If each relationship has one assigned data set or key data element they are responsible for then the overall organisation will have 150.
Choosing the right 150
While most organisations have around 150 key data elements that anchor their most important information, few actually know what they are. That’s a pity because the choice of 150 tells you a lot about the organisation. If the 150 don’t encompass the breadth of the enterprise then you can gain insight into what’s really important to the management team. If there is little to differentiate the key data elements from those that a competitor might choose then the company may lack a clear point of difference and be overly dependent on operational excellence or cost to gain an advantage.
Any information management initiative should start by identifying the 150 most important elements. If they can’t narrow the set down below a few hundred, they should be suspicious they haven’t gotten to the core of what’s really important to their sponsors. They should then look to ask the question of whether these key data elements span the enterprise or pick organisational favourites; whether they offer differentiation or are “me too” and whether they are easy or hard for a competitor to emulate.
The identification of the 150 key data elements provides a powerful foundation for any information and business strategy. Enabling a discussion on how the organisation is led and managed. While processes evolve quickly, the information flows persist. Understanding the 150 allows a strategist to determine whether the business is living up to its strategy or if its strategy needs to be adjusted to reflect the business’s strengths.
Data profiling is an excellent diagnostic method for gaining additional understanding of the data. Profiling the source data helps inform both business requirements definition and detailed solution designs for data-related project, as well as enabling data issues to be managed ahead of project implementation.
Profiling of a data set will be measured with reference to and agreed Data Quality Dimensions (e.g. per those proposed in the recent DAMA white paper).
Profiling may be required at several levels:
• Simple profiling with a single table (e.g. Primary Key constraint violations)
• Medium complexity profiling across two or more interdependent tables (e.g. Foreign Key violations)
• Complex profiling across two or more data sets, with applied business logic (e.g. reconciliation checks)
Note that field-by-field analysis is required to truly understand the data gaps.
Any data profiling analysis must not only identify the issues and underlying root causes, but must also identify the business impact of the data quality problem (measured by effectiveness, efficiency, risk inhibitors). This will help identify any value in remediating the data – great for your data quality Business Case. Root cause analysis also helps identify any process outliers and and drives out requirements for remedial action on managing any identified exceptions.
Be sure to profile your data and take baseline measures before applying any remedial actions – this will enable you to measure the impact of any changes.
I strongly recommend Data Quality Profiling and root-cause analysis to be undertaken as an initiation activity as part of all data warehouse, master data and application migration project phases.
Over the years, I’ve tended to find that asking any individual or group the question “What data/information do you want?” gets one of two responses:
“I don’t know.” Or;
“I don’t know what you mean by that.”
End of discussion, meeting over, pack up go home, nobody is any the wiser. Result? IT makes up the requirements based on what they think the business should want, the business gets all huffy because IT doesn’t understand what they need, and general disappointment and resentment ensues.
Clearly for Information Management & Business Intelligence solutions, this is not a good thing.
So I’ve stopped asking the question. Instead, when doing requirements gathering for an information project, I go through a workshop process that follows the following outline agenda:
Context setting: Why information management / Business Intelligence / Analytics / Data Governance* is generally perceived to be a “good thing”. This is essentially a very quick précis of the BI project mandate, and should aim at putting people at ease by answering the question “What exactly are we all doing here?”
(*Delete as appropriate).
Business Function & Process discovery: What do people do in their jobs – functions & tasks? If you can get them to explain why they do those things – i.e. to what end purpose or outcome – so much the better (though this can be a stretch for many.)
Challenges: what problems or issues do they currently face in their endeavours? What prevents them from succeeding in their jobs? What would they do differently if they had the opportunity to do so?
Opportunities: What is currently good? Existing capabilities (systems, processes, resources) are in place that could be developed further or re-used/re-purposed to help achieve the desired outcomes?
Desired Actions: What should happen next?
As a consultant, I see it as part of my role to inject ideas into the workshop dialogue too, using a couple of question forms specifically designed to provoke a response:
“What would happen if…X”
“Have you thought about…Y”
“Why do you do/want…Z”.
Notice that as the workshop discussion proceeds, the participants will naturally start to explore aspects that relate to later parts of the agenda – this is entirely ok. The agenda is there to provide a framework for the discussion, not a constraint. We want people to open up and spill their guts, not clam up. (Although beware of the “rambler” who just won’t shut up but never gets to the point…)
Notice also that not once have we actively explored the “D” or “I” words. That’s because as you explore the agenda, any information requirements will either naturally fall out of the discussion as it proceed, or else you can infer the information requirements arising based on the other aspects of the discussion.
As the workshop attendees explore the different aspects of the session, you will find that the discussion will touch upon a number of different themes, which you can categorise and capture on-the-fly (I tend to do this on sheets of butchers paper tacked to the walls, so that the findings are shared and visible to all participants.). Comments will typically fall into the following broad categories:
* Functions: Things that people do as part of doing business.
* Stakeholders: people who are involved (including helpful people elsewhere in the organisation – follow up with them!)
* Inhibitors: Things that currently prevent progress (these either become immediate scope-change items if they are show-stoppers for the current initiative, or else they form additional future project opportunities to raise with management)
* Enablers: Resources to make use of (e.g. data sets that another team hold, which aren’t currently shared)
* Constraints: “non-negotiable” aspects that must be taken into account. (Note: I tend to find that all constraints are actually negotiable and can be overcome if there is enough desire, money and political will.)
* Considerations: Things to be aware of that may have an influence somewhere along the line.
* Source systems: places where data comes from
* Information requirements: Outputs that people want
Here’s a (semi) fictitious example:
e.g. ADD: “What does your team do?”
Workshop Victim Participant #1: “Well, we’re trying to reconcile the customer account balances with the individual transactions.”
ADD: And why do you wan to do that?
Workshop Victim Participant #2: “We think there’s a discrepancy in the warehouse stock balances, compared with what’s been shipped to customers. The sales guys keep their own database of customer contracts and orders and Jim’s already given us dump of the data, while finance run the accounts receivables process. But Sally the Accounts Clerk doesn’t let the numbers out under any circumstances, so basically we’re screwed.”
Functions: Sales Processing, Contract Mangement, Order Fulfilment, Stock Management, Accounts Receivable.
Stakeholders: Warehouse team, Sales team (Jim), Finance team.
Inhibitors: Finance don’t collaborate.
Enablers: Jim is helpful.
Source Systems: Stock System, Customer Database, Order Management, Finance System.
Information Requirements: Orders (Quantity & Price by Customer, by Salesman, by Stock Item), Dispatches (Quantity & Price by Customer, by Salesman, by Warehouse Clerk, by Stock Item), Financial Transactions (Value by Customer, by Order Ref)
You will also probably end up with the attendees identifying a number of immediate self-assigned actions arising from the discussion – good ideas that either haven’t occurred to them before or have sat on the “To-Do” list. That’s your workshop “value add” right there….
Workshop Victim Participant #1: “I could go and speak to the Financial Controller about getting access to the finance data. He’s more amenable to working together than Sally, who just does what she’s told.”
Happy information requirements gathering!
Why estimating Data Quality profiling doesn’t have to be guess-work
Data Management lore would have us believe that estimating the amount of work involved in Data Quality analysis is a bit of a “Dark Art,” and to get a close enough approximation for quoting purposes requires much scrying, haruspicy and wet-finger-waving, as well as plenty of general wailing and gnashing of teeth. (Those of you with a background in Project Management could probably argue that any type of work estimation is just as problematic, and that in any event work will expand to more than fill the time available…).
However, you may no longer need to call on the services of Severus Snape or Mystic Meg to get a workable estimate for data quality profiling. My colleague from QFire Software, Neil Currie, recently put me onto a post by David Loshin on SearchDataManagement.com, which proposes a more structured and rational approach to estimating data quality work effort.
At first glance, the overall methodology that David proposes is reasonable in terms of estimating effort for a pure profiling exercise – at least in principle. (It’s analogous to similar “bottom/up” calculations that I’ve used in the past to estimate ETL development on a job-by-job basis, or creation of standards Business Intelligence reports on a report-by-report basis).
I would observe that David’s approach is predicated on the (big and probably optimistic) assumption that we’re only doing the profiling step. The follow-on stages of analysis, remediation and prevention are excluded – and in my experience, that’s where the real work most often lies! There is also the assumption that a pre-existing checklist of assessment criteria exists – and developing the library of quality check criteria can be a significant exercise in its own right.
However, even accepting the “profiling only” principle, I’d also offer a couple of additional enhancements to the overall approach.
Firstly, even with profiling tools, the inspection and analysis process for any “wrong” elements can go a lot further than just a 10-minute-per-item-compare-with-the-checklist, particularly in data sets with a large number of records. Also, there’s the question of root-cause diagnosis (And good DQ methods WILL go into inspecting the actual member records themselves). So for contra-indicated attributes, I’d suggest a slightly extended estimation model:
* 10mins: for each “Simple” item (standard format, no applied business rules, fewer that 100 member records)
* 30 mins: for each “Medium” complexity item (unusual formats, some embedded business logic, data sets up to 1000 member records)
* 60 mins: for any “Hard” high-complexity items (significant, complex business logic, data sets over 1000 member records)
Secondly, and more importantly – David doesn’t really allow for the human factor. It’s always people that are bloody hard work! While it’s all very well to do a profiling exercise in-and-of-itself, the result need to be shared with human beings – presented, scrutinised, questioned, validated, evaluated, verified, justified. (Then acted upon, hopefully!) And even allowing for the set-aside of the “Analysis” stages onwards, then there will need to be some form of socialisation within the “Profiling” phase.
That’s not a technical exercise – it’s about communication, collaboration and co-operation. Which means it may take an awful lot longer than just doing the tool-based profiling process!
How much socialisation? That depends on the number of stakeholders, and their nature. As a rule-of-thumb, I’d suggest the following:
* Two hours of preparation per workshop ((If the stakeholder group is “tame”. Double it if there are participants who are negatively inclined).
* One hour face-time per workshop (Double it for “negatives”)
* One hour post-workshop write-up time per workshop
* One workshop per 10 stakeholders.
* Two days to prepare any final papers and recommendations, and present to the Steering Group/Project Board.
That’s in addition to David’s formula for estimating the pure data profiling tasks.
Detailed root-cause analysis (Validate), remediation (Protect) and ongoing evaluation (Monitor) stages are a whole other ball-game.
Alternatively, just stick with the crystal balls and goats – you might not even need to kill the goat anymore…
A “foreign” colleague of mine once told me a trick his English language teacher taught him to help him remember the “questioning words” in English. (To the British, anyone who is a non-native speaker of English is “foreign.” I should also add that as a Scotsman, English is effectively my second language…).
“Five Whiskies in a Hotel” is the clue – i.e. five questioning words begin with “W” (Who, What, When, Why, Where), with one beginning with “H” (How).
These simple question words give us a great entry point when we are trying to capture the initial set of issues and concerns around data governance – what questions are important/need to be asked.
* What data/information do you want? (What inputs? What outputs? What tests/measures/criteria will be applied to confirm whether the data is fit for purpose or not?)
* Why do you want it? (What outcomes do you hope to achieve? Does the data being requested actually support those questions & outcome? Consider Efficiency/Effectiveness/Risk Mitigation drivers for benefit.)
* When is the information required? (When is it first required? How frequently? Particular events?)
* Who is involved? (Who is the information for? Who has rights to see the data? Who is it being provided by? Who is ultimately accountable for the data – both contents and definitions? Consider multiple stakeholder groups in both recipients and providers)
* Where is the data to reside? (Where is it originating form? Where is it going to?)
* How will it be shared? (How will the mechanisms/methods work to collect/collate/integrate/store/disseminate/access/archive the data? How should it be structured & formatted? Consider Systems, Processes and Human methods.)
Clearly, each question can generate multiple answers!
Aside: in the Doric dialect of North-East of Scotland where I originally hail from, all the “question” words begin with “F”:
Fit…? (What?) e.g. “Fit dis yon feel loon wint?” (What does that silly chap want?)
Fit wye…? (Why?) e.g. “Fit wye div ye wint a’thin’?” (Why do you want everything?)
Fan…? (When?) e.g. “Fan div ye wint it?” (When you you want it?)
Fa…? (Who?) e.g. “Fa div I gie ‘is tae?” (Who do I give this to?)
Far…? (Where?) e.g. “Far aboots dis yon thingumyjig ging?” (Where exactly does that item go?)
Foo…? (How?) e.g. “Foo div ye expect me tae dae it by ‘e morn?” (How do you expect me to do it by tomorrow?)
Whatever your native language, these key questions should get the conversation started…
Remember too, the homily by Rudyard Kipling:
Is this the kind of response you get when you mention to people that you work in Data Quality?!
Let’s be honest here. Data Quality is good and worthy, but it can be a pretty dull affair at times. Information Management is something that “just happens”, and folks would rather not know the ins-and-outs of how the monthly Management Pack gets created.
Yet I’ll bet that they’ll be right on your case when the numbers are “wrong”.
So here’s an idea. The next time you want to engage someone in a discussion about data quality, don’t start by discussing data quality. Don’t mention the processes of profiling, validating or cleansing data. Don’t talk about integration, storage or reporting. And don’t even think about metadata, lineage or auditability. Yaaaaaaaaawn!!!!
Instead of concentrating on telling people about the practitioner processes (which of course are vital, and fascinating no doubt if you happen to be a practitioner), think about engaging in a manner that is relevant to the business community, using language and examples that are business-oriented. Make it fun!
Once you’ve got the discussion flowing in terms of the impacts, challenges and inhibitors that get in the way of successful business operations, then you can start to drill into the underlying data issues and their root causes. More often than not, a data quality issue is symptomatic of a business process failure rather than being an end in itself. By fixing the process problem, the business user gains a benefit, and the data in enhanced as a by-product. Everyone wins (and you didn’t even have to mention the dreaded DQ phrase!)
Data Quality is a human thing – that’s why its hard. As practitioners, we need to be communicators. Lead the thinking, identify the impact and deliver the value.
Now, that’s interesting!
Just recently, Gary Allemann posted a guest article on Nicola Askham’s Blog, which made an analogy between Data Governance and the London Tube map. (Nicola also on Twitter. See also Gary Allemann’s blog, Data Quality Matters.)
Up until now, I’ve always struggled to think of a way to represent all of the different aspects of Information Management/Data Governance; the environment is multi-faceted, with the interconnections between the component capabilities being complex and not hierarchical. I’ve sometimes alluded to there being a network of relationship between elements, but this has been a fairly abstract concept that I’ve never been able to adequately illustrate.
And in a moment of perspiration, I came up with this…
I’ll be developing this further as I go but in the meantime, please let me know what you think.
(NOTE: following on from Seth Godin’ plea for more sharing of ideas, I am publishing the Information Management Tube Map under Creative Commons License Attribution Share-Alike V4.0 International. Please credit me where you use the concept, and I would appreciate it if you could reference back to me with any changes, suggestions or feedback. Thanks in advance.)
Just how productive are Chief Information Officers or the technology that they manage? With technology portfolios becoming increasingly complex it is harder than ever to measure productivity. Yet boards and investors want to know that the capital they have tied-up in the information technology of the enterprise is achieving the best possible return.
For CIOs, talking about value improves the conversation with executive colleagues. Taking them aside to talk about the success of a project is, even for the most strategic initiatives, usually seen as a tactical discussion. Changing the topic to increasing customer value or staff productivity through a return on technology capital is a much more strategic contribution.
What is the return on an IT system?
There are all sorts of productivity measures that can be applied to individual systems, but they are usually based on the efficiency of existing processes which leads to behaviours which reduce flexibility. The future of business and government depends on speed of response to change, not how efficiently they deal with a static present.
Businesses invest in information systems to have the right information at the right time to support decisions or processes. Information that is used is productive while information that is collected, but poorly applied, is wasted or unproductive.
However, to work out what proportion of information is being used there needs to be a way to quantify it.
How much information is contained in the systems?
There is a formal way to measure the quantity of information. I introduce this extensively in chapter 6 of Information-Driven Business.
The best way to understand “quantity” in terms of information is to count the number of artefacts rather than the number of bits or bytes required to store them. The best accepted approach to describing this quantity is called “information entropy” which, confusingly, uses a “bit” as its unit of measure which is a count of the potential permutations that the system can represent.
A system that holds 65,536 names has just 16 “bits” of unique information (log265536). That might sound strange given that the data storage of 65,536 names might use of the order of 6MB.
To understand why there only 16 bits of unique information in a list of 65,536 names consider whether the business uses the spelling of the names of if there is any additional insight being gained from the data that is stored.
How much of that information is actually used?
Knowing how much information there is in a system opens up the opportunity to find how much information is being productively used. The amount of information being used to drive customer or management choices is perhaps best described as “decision entropy”. The decision entropy is either equal or less than the total information entropy.
An organisation using 100% of their available information is incredibly lean and nimble. They have removed much of the complexity that stymies their competitors (see Value of decommissioning legacy systems).
Of course, no organisation productively uses all of the information that they hold. Knowing that holding unproductive information comes at a cost to the organisation, the CIO can have an engaging conversation with fellow executives about extracting more value from existing systems without changing business processes.
When looking at how business reports are really used, and how many reports lie unread on management desks, there is a lot of low hanging fruit to be picked just by improving the way existing business intelligence is used.
Similarly, customer systems seldom maximise their use of hints based on existing information to guide buyers to close the best available offer. A few digital enhancements at the front line can bring to the surface a vast array of otherwise unused information.
Changing the conversation
Globally, CIOs are finding themselves pushed down a rung in the organisational ladder. This is happening at the very same time that technology is moving from the back office to become a central part of the revenue story through digital disruption.
CIOs are not automatically entitled to be at the executive table. They have to earn the right by contributing to earnings and business outcomes. One of the best discussions for a CIO to focus on is increasing productivity of the capital tied-up in the investments that have already been made in the systems that support staff and customers.
TODAY: Mon, March 27, 2017March2017