Data – Information – Knowledge

30 January, 2009

I often work in situations where people struggle with some fairly basic definitions for what knowledge is. You can “Google” the term or look at any number of white papers and articles on knowledge management, but I prefer to use a real-world example which seems to help get the point across (well it works for me anyway!).

Now this is a very simple example and is intended to try an make the point about when data becomes information becomes knowledge. Consider the following example and ask yourself what’s more useful to you as a business traveller, then decide what a computerised travel booking system might be able to use:

Data

  • 26Oct08 28Mar09 123456 – LHR 14:20 5 SEA 16:01 BA49 747 0
  • 26Oct08 28Mar09 - - - - - -7 LHR 14:20 5 SEA 16:15 BA49 777 0
  • 26Oct08 28Mar09 1- - -56 - LHR 17:10 5 SEA 19:05 BA53 777 0

 

Information

  • Effective from 26th October 2008 until 28thMarch 2009 there is one daily British Airways flight that departs from Heathrow to Seattle, this flight departs in the afternoon at 2:20PM.  On Mondays, Fridays and Saturdays there is an additional flight that leaves at 5:10PM.

 

Knowledge

  • The BA49 is usually a Boeing 747. If you are travelling alone and want to get the best premium economy seat on the plane, use the on-line checking system 24 hours before to request row 28, this is usually an aisle which only has one seat in the entire aisle, so there is plenty of leg room to stretch out and room for hand-luggage.
  • If you can’t book it on-line, get to the check-in early, the crew refer to this internally as the “Captain Kirk” seat so if you ask for it using this nick-name you stand a much better chance of getting it.

What this does not answer is how you transform data into information into knowledge? how do you enable the capturing and sharing of knowledge? and how do you keep all of this current and in a usable form? 


Top Tips for Knowledge Flow Initiatives

5 November, 2008
  1. Keep any systems simple, easy and most of all convenient to use, build knowledge flow tools into systems that people use every day (like e/mail and file servers)
  2. Carefully design a taxonomy or ontology to help store and organise content, get it right and it will provide a useful structure and context, get it wrong and you will end up with another un-manageable (and not very useful) collection of unstructured and disconnected data.
  3. To change people behaviour and attitude to sharing knowledge, work on their beliefs, make them want to do it, make it a challenges, make it status or career enhancing and if possible make it worth their while financially.
  4. Devise a simple way of ranking the usefulness of contributions, consider feedback or rating systems. Allow people or groups to make a reputation from what they contribute.
  5. If possible, link knowledge to where it is used and link it to people, make it easy to find examples of where and how using information was used, was created and who the experts are

Architecting Knowledge Flow Systems

27 October, 2008

In order for any system that stores or manipulates large amounts of unstructured data and concepts you need to have some for of structure, framework or meta-data in place. For information flow systems, you need to consider a Taxonomy or Ontology, for those not familiar with these terms, below is the definition from Wikipedia, the free encyclopaedia – Taxonomy “is the practice and science of classification”, Ontology “is the study of being or existence. It seeks to describe or posit the basic categories and relationships of being or existence to define entities and types of entities within its framework.” Without some consistency, structure or framework organising, storing and searching knowledge in simple systems (I am a great fan of keeping things as simple as possible) becomes very difficult and may result in inconsistent or unexpected results search results. Tools that help people collaborate are very powerful agents of change, this change can however be negative making these tools quite disruptive to an organisation.

It is absolutely critical to take an architectural approach to knowledge flow systems, by doing so you will go through certain thought and planning processes that will ensure that the systems that get created actually deliver value and minimise the risk of simply “shifting the problem” from individual based knowledge silos to network based knowledge silos.

Very often when I see how people are using collaboration technology, I come across organisations that have allowed this kind of technology to proliferate in an ad-hoc and un-managed way. This proliferation is often fuelled by the easy way in which these systems can be deployed and the low cost availability of servers and network bandwidth. What I often see is dozens of systems deployed that have little or no architecture; they are very often isolated from each other even though they are based on the same server platform. The value of these systems is questionable and very often I see a peak of use at the beginning when these systems are launched, then people revert back to their old ways of working because these systems while functionally rich are poorly architected and don’t actually fit into people ways of working.


Unified Communications or Unified Confusion?

12 October, 2008

I am currently working on a project to define a strategy and road map for collaboration and knowledge sharing. Part of this involves creating a set of guidelines for Unified Communications (UC) initiatives so that definitions, blueprints and an architecture can be developed.

As I start this piece of work with my client, it is soon clear to me that there is a lot of confusion and inconsistency as to what UC actually is. Sitting in a room with suppliers and IT Architects it soon strikes me that everyone has morphed UC into something that they want it to be given their own preferences and agendas. Now I don’t have a problem with this, as such, but when trying to define a set of consistent standards and guidelines, the start point has to be a clear and shared understanding of the UC domain. What it is, and as important what it is not.

I have asked the team I am working with to spend some up-front time creating a vision (in business terms) of what UC is and more importantly what UC will enable.

If you Google UC you get “about” 8,840,000 hits, so not much point in me defining or re-defining it here. What I will share here is my “starter-for-ten” vision for UC and what this might actually mean for a user (remember them!!)

Unified Communications provides me with a set of capabilities that enable me to communicate in a secure and trusted way with the people I want to in a way that I want to when I want to. It provides me with a number of choices that make communications convenient and usefully given my role and the responsibilities and obligations I have.

Unified Communications enables me to be more responsive and engaged with my colleagues improving my effectiveness and my contribution to my organisation.

Now that we have this out of the way, the techies can start arguing about products, technologies, SaaS, presence, identity management, transport protocols, VoIP, integration, universal inbox, web conferencing etc….


Knowledge Management or Knowledge Flow?

7 October, 2008

Can an organisation really manage knowledge? should it even try to? Putting a strong emphasis on the “management” of knowledge can lead to very well managed “silos” of knowledge which I think misses the fundamental point.

I prefer to use the term “knowledge flow” when describing a core capability that organisations should try to enable.

Consider the Wikipedia definition of knowledge management:

Knowledge Management refers to a range of practices used by organisations to identify, create, represent, and distribute knowledge for reuse, awareness, and learning across the organisations”

The main reason I prefer to use the term knowledge flow instead of knowledge management is that I feel that the emphasis should be on recognising the importance of enabling the movement, flow, transference, accessibility and “absorption” of knowledge rather then emphasising the need to “control” or “manage” knowledge like many more traditional fixed assets. Often I have come across what I refer to as “knowledge stealth” situations, by this I mean situations where knowledge or expertise is hidden – not deliberately – but by the virtue of it being fixed in one place and not visible on the corporate or social radar. It’s only when knowledge flow is enable that you can actually begin to detect it’s existence and then find ways to tap into it.

This flow of knowledge has been an area of interest to me since the early nineties when the emergence of “Groupware” products signalled a change in the way people viewed collaboration and started the think about the less obvious and deeper value that this kind of technology could bring to an organisation. In order to understand what the potential benefits from knowledge enabling technologies might be, one needs to consider how knowledge changes state and flows in and around an organisation, the paths it takes, the impact it has on individuals and how knowledge and information increases in “potential” value.