denotes premium content | May 26 2012 
Feature
posted 31 Aug 2004 in Volume 1 Issue 3
Navigating the triangle of lost knowledge
Jointly owned by the biggest banks and building societies in the UK, automated clearing house BACS has never lost a single payment in 36 years of business, despite processing more than four billion of them per year. But prestigious ownership and impressive records aside, could they handle implementing a knowledge-management programme to help employees find critical information? Gareth Lodge, the company’s knowledge manager, describes the often challenging process.
BACS is probably the largest automated clearing house in the world and is the mechanism that processes electronic funds transfers. Critical to the UK economy, we’re used by 50,000 UK businesses to pay 95 per cent of the country’s workforce.
Over the last few years competition reviews of the banking industry, such as the Cruickshank Report, have radically changed our marketplace. One important change for BACS was the Office of Fair Trading’s decision to increase transparency in the payments arena. That resolution prompted BACS to split into two entities in December 2003. BACS remains the organisation that physically processes payments and maintains the payment network, while BACS Payment Schemes governs the rules and legal structures under which payments are made. Because of this division, the processing arm of BACS now has significantly greater commercial freedom.
To take advantage of these opportunities two new departments, sales and ventures, were created. With the influx of new staff, people were no longer necessarily aware of what their colleagues knew or did, what documents had been previously created or where they might reside. This problem wasn’t insurmountable but the methods being used to solve it were often time consuming, incomplete and/or unfulfilling. BACS tried to help staff in the new departments optimise their search results by implementing a knowledge-management (KM) programme, without dictating how they worked.
The need
As knowledge manager at BACS, I needed to understand how big the problem was before building a business case for a KM programme. To do this, I carried out a brief survey around key employees. The results were not too surprising. A key point was that between ten per cent and 30 per cent of employee time could be spent on acquiring information and duplicating existing work. This isn’t unusual, as research from Delphi Group estimates 60 per cent of workers have difficulty in finding information, wasting 25 per cent of their day searching for it.
Several people who were considered important experts and thus key to the knowledge-sharing process were identified. These people were effectively viewed as the corporate memory, knowing who did or wrote what, when and why. Unfortunately, these experts were also caught in a virtuous circle: by asking them a question, their knowledge increased and made them an even more useful resource. Given this, there was obviously a risk of knowledge loss if any of these key figures left.
Explicit knowledge
Explicit knowledge exists in many forms, such as documents, reports or statistics. The type of data often determines where and how it is stored and which tools are used to access it. As a broad rule of thumb, the worth of the data is generally linked to its type, making value the driver behind how much investment is made in managing it.
Let’s look at unstructured data such as documents. At one end of the spectrum, file stores are low-level investments, but don’t usually have any level structure. For example, data is grouped together at file level, but with no additional metadata. At the other end of the scale, something like a document manager or customer-relationship-management database has a very rigid structure, with many mandatory fields. This is probably because high level can mean completely different things to different people. Typically, logical structure exists only in the first two tiers (usually department, then team), but then the individual takes over, using what seems to make sense to them. What that leaves you with is duplication of folders and files, folders that are empty or stuffed to the gills, or folders with meaningless names.
The file stores rely on software to find the documents, while document managers rely on people to correctly file and tag the same items. Different types of tools are often used for each approach. For example, search engines are used in document management solutions because an investment has already been made in correctly labelling and making sure that data is in the right place, while semantic search engines tend to be used for large amounts of unstructured data. However, there are trade-offs. Somewhere in the middle the best of both worlds must exist – where there is just enough structure and where human expertise and knowledge can be harnessed with a clever search engine. Yet this middle ground is difficult to find because people search in very different ways.
How people search
A person once told me: “I don’t want a search engine, I want a find engine. I’m only interested in results, not how you get them.”
Most users aren’t interested in learning how to use a search engine or how a document is stored. They just want the right information in the correct format as soon as possible.
To work properly, most tools in the marketplace force people to work in a specific, structured way. The reality is that how people search rarely matches how the software works, because the process varies from person to person.
- Focus – some want just a handful of key documents while others want everything;
- Vision – some have a clear idea of what they’re looking for while others have no idea, hoping they’ll know it when they see it;
- Knowledge – some are experts in the field while others aren’t even aware of the correct terms to search on;q Serendipity – some are very structured in how they search while others want to browse and almost stumble across the results.
Professional searchers are able to adopt the best search strategy for the particular situation, but the average user won’t. The old adage that if they don’t find what they want in three clicks they give up is true in many cases. Some users will ask a professional searcher, but many will assume the information simply doesn’t exist.
Software also tends to fail a group I classify as social researchers. This group tends to pick up the phone and use their social networks to speak to an expert rather than read reams of documents. This method relies on the person they’re asking having sufficient knowledge and no bias in their answer.
This mismatch of tools and preferred ways of working is clearly reflected in published research. Delphi asked employees of an information management software provider1 what the biggest challenge to finding business-critical information was. The lowest scoring answer was ‘skills’ with three per cent, while the second highest answer was ‘bad tools’ with 28 per cent. Unless technology can adapt to meet the varying information-gathering processes used, software adoption will continue to be lower than it should.
The solution
To fix the problem I describe as the Bermuda Triangle of lost knowledge, we decided we needed a tool that linked and brought together the triangle of users, experts and documents. We looked at a number of potential solutions, such as portal software, document-management solutions and search-and-retrieval software, and eventually decided on two products that would tackle different parts of the problem. Both were from the same vendor, but one was a document manager and the other a semantic search engine.
Semantic search engines analyse the concepts within the document based on things such as frequency and positioning and what other documents are stored in the same folder. The advantage of the product we chose is that on top of the usual semantic profiling it used the interactions people had with the system and the documents. This is based on a number of factors, such as who has written, read, searched or commented on documents, their teams, and the type of documents they look at. This gives them the additional ability to suggest experts on topics, but also allows continual refining of the concept mapping. Each interaction with the system improves the results for all because a new user suddenly has everyone’s expertise to help them. The products also have the capability to produce concept maps based on search results or on a document set. Many find that having a pictorial view helps speed up their searches.
Another important consideration was that the semantic search engine also had the ability to explore a wide variety of data sources, such as file stores, customer-relationship-management packages, internet sites and databases such as Factiva, Dialog, Sharepoint and Oracle. For the first time, we had a one-stop-shop that would search all the data sources we had access to and allowed new sources to be added in the future.
Lessons learnt
Our chosen solution hasn’t completely solved the problem but, in the face of three main challenges, I think we’ve made greater progress than I expected.
Our first problem was in designing the taxonomy for the document manager. It was the one thing everyone could relate to because they had all experienced the current filing structure. Not surprisingly, that became the focus of much debate. Convincing users that we would never get it right for everyone the first time and that the point of having the software was to find things was difficult.
The second problem was changing how people label documents, which continues to be an uphill struggle. While users complain that other people have given documents meaningless titles, it always seems to be someone else who does it.
Lastly, we thought we had managed the migration of documents into the manager by closing off the file store. But despite moving the folder structures into the system, without any adaptation, users claimed they couldn’t work with the new folder structure and tried to remain on the old file share.
I also encountered a tricky problem I didn’t expect and that we still haven’t solved – some people did not want to be identified as experts. This was because some people just want to get on with their work and are too self-effacing or feel they are too junior to qualify as such. Sometimes they want to put that title and experience behind them, because they’ve moved on to another role.
Cultural change and operation
There was some debate as to who could best run the project. Because we were taking our first steps towards knowledge management, the level of investment was accordingly small. We set up a user group of champions for key departments (sales, ventures, planning, human resources and the executive) to foster ownership of the products. These groups were also involved in the initial selection of the solution.
These champions were selected as influencers and/or probable heavy users within their respective teams. They helped select the product to ensure we got buy-in from everyone when we rolled out the system. This means they couldn’t say it didn’t suit their way of working, or meet their needs or leave them feeling like it was imposed on them. We also used these people as champions for their areas, almost like super-users.
While getting resources from IT for a smaller project was a challenge, deciding who owned the project was even harder.
We ended up compromising with a project board representing management and users.
Like any new IT program, there are still some bugs to work out and some things that, despite user acceptance testing, we hadn’t picked up. Culturally, some people love the new system and are actively selling it to their colleagues, while others are being dragged along.
Reference
1. Taxonomy& Content Classification Market Milestone Report http://www.stratify.com/infocenter/download/DelphiResearchReport.pdf
