Data without Outcomes ≠ Transformation

In his 1989 paper entitled, “From Data to Wisdom”, Russell Ackoff said:

In Knowledge Management (KM) circles, the DIKW pyramid or paradigm has been a point of discussion possibly before the term was even coined. But irrespective of their point of view most, if not all, KM Thought Leaders agree. It isn’t all about the data.

Data needs structure, relationships or context to qualify as information. A simple example might be the definition of “person” could include “title”, “first name”, “last name”, “email address”. Each piece of data can be current and correct but without structure to relate the data effectively, it’s not very useful.

In the real world, we may be faced with situations where data is incomplete or incorrect – in some cultures, it is normal to state your name in what Western cultures might consider reverse order. If we applied our “first name” “last name” structure to all data, we may well synthesize incorrect information. It is through experience, broader cultural understanding or just plain old trial and error over time, that we build our knowledge of how to correctly identify, save, display and communicate “first name”, “last name” pairs as well as date formats. And we can use that knowledge to help correct and/or flesh out the underlying data elements so that the information we hold is more complete and correct.

But even with that knowledge in place or even by using that knowledge to establish better data and information, we still need to understand the relevance of that knowledge and whether it is appropriate to use. It may be deeply insulting to get the “first name” “last name” sequence wrong – wisdom helps us to navigate the issue successfully.

A trivial example perhaps but when considered in terms of the breadth and depth of data out there and the sheer speed at which it is being generated, it becomes a lot more interesting. And in public sector agencies where core data elements are often managed and controlled by 3rd parties or sister agencies, the issue of how to convert data to wisdom is possibly as complex as it can be.

It is improbable (perhaps impossible) that every piece of data will be in one place and totally correct. However, it IS possible to capture the rules around how it should be structured and applied. It IS possible to improve those rules over time as we build knowledge and learn when and how to apply that knowledge to deliver outcomes for customers that an organisation is responsible for.

So how do we do it? There are 3 simple steps:

1.     Focus on OUTCOMES;

2.     Focus on DIKW in reverse;

• Use the WISDOM of business users to define desired future outcomes
• Capture KNOWLEDGE in the form of business rules, polices and past results
• Define INFORMATION required to achieve outcomes
• Map and collate the DATA sources required – manage what is yours, agree access methods with what is not

3.     ITERATE

• Fail fast! is the agile rallying cry which is great so long as we learn from that failure. Failing fast on the same problem more than once is the antithesis of Agile.

 Let’s look at an example.

A case worker undertakes a home visit. They read the paper file given to them and, after the visit, add an entry which reads “situation unchanged since last visit”. Their team leader, with no additional information will probably still be able to advise a course of action. With years of experience, the team leader would know that “situation unchanged” is most likely not as positive as “situation remains stable” so can pick up the phone and call the case worker to verify. Even without any cause for alarm, the team leader can counsel the case worker to choose a different phrase to signify everything is OK – or, not OK if the situation is bad and hasn’t changed. In other words, the data may be accurate but not helpful in improving the home environment for the person in care.

We can see that the supervisor knows the outcome they are looking for – a safe environment for a child, a parolee successfully reintegrated into society etc – and can use their past experience to apply wisdom to improve that future outcome without having to have all data elements in place. They may find that the timing between visits or the duration may also be material and may choose to add that to the suggested schedule of the case worker. In other words, the team leader would inject their knowledge into attaining and/or improving the desired outcome in the form or business rules or polices. To do that, the system (manual or automated) would need to have a way of capturing that information – timing, duration etc and only then would there be a real need to focus in on data quality and availability.

And herein lies the reason that so many digital or service transformations stall or don’t seem to deliver: They focus almost relentlessly on data quality or data availability only. By making accurate and up-to-date (even real-time) data a pre-requisite to progress, we immediately buy in to the theory that the DIKW pyramid IS strictly hierarchical and, more importantly, that we can only proceed to the higher levels when the foundation is complete.

If we are going to succeed in delivering on the promise of true digital transformation, we need to accept we will NEVER be ahead of the growth in available data. Instead, we need to follow the three step process I have suggested above.

Check out this great video to help you understand where to get started:

 https://www.pega.com/insights/resources/build-change-journey-centric-rapid-delivery

If you’re planning on going to Gartner Symposium 2019 on the Gold Coast, be sure to attend my speaking session to get some more great insights.