Deck: Effective knowledge management requires a unified, organized approach that traverses the enterprise and transcends departmental boundaries.
By Doug Kalish
Every organization, no matter its size, relies on ready access to information to achieve its goals, serve customers and maximize productivity. But for an organization’s knowledge management efforts to be truly effective in the information age, we must build a single-source knowledge management system that crosses all organizational boundaries and elicits effective knowledge sharing both within and beyond the enterprise.
Consider the situation at most organizations today: The role of individuals in most professional services firms has evolved to include research and knowledge retrieval as a core job duty. Individuals across the enterprise are tasked with the retrieval of information in order to perform their duties successfully.
But rarely can individuals from far-flung reaches of the enterprise search through shared or linked data repositories. Rather, information is more likely to be organized into a closed system where it is accessed by one functional user group for a specific set of tasks. What is available to one workgroup is not available to another. This is the fundamental architecture of knowledge management today.
Knowledge management, as its exists at most organizations, addresses the limited needs of individual departments and workgroups, is duplicative, and distributed. Wouldn't it be more efficient to frame an enterprise-wide knowledge management infrastructure that crosses all functional boundaries within the organization, and creates common data objects and definitions that can be used with equal ease and success by all employees? This is what we call enterprise knowledge management (EKM), and it is an essential aspect of any business plan in the information age.
Researcher and consultant Karl-Erik Sveiby and others have described knowledge management as the management of an organization’s intangible assets.
There are three types of intangible assets:
¨External: relationships, brand names, reputation, and image
¨Internal: patents, concepts, models, and processes
¨Individual: skills, education, experience, and values
The role of knowledge management has usually been seen as the transformation of individual assets – those associated with the employees – into internal assets – those retained by the organization. At Scient, we have noticed recently that knowledge management is playing a larger role in the attraction and retention of staff.
Every one of our employees wants to know how they will grow in their jobs and what they will learn from us. In fact, it is the biggest question on their minds – right after how many stock options they are going to receive.
So Knowledge Management is now playing a dual role:
¨To attract employees to the organization and retain them, if possible
¨To retain their knowledge, if not
Organizations cannot effectively leverage the power of knowledge management until the framers of organizational communication look at the “big picture” of a company’s organizational resources and needs. The careful implementation of an enterprise-wide knowledge management system will give rise to a cross-functional and consolidated corporate data repository based on open data access standards that creates new levels of communications, eliminate inefficiencies, and is transparent to its users.
The State of Knowledge Management Today
Efficiency and cross-functionality across all boundaries—whether internal, external, departmental, task-oriented etc.—is the ultimate goal of an enterprise knowledge management solution. However, most knowledge management solutions are local or departmental solutions that address a single organizational need (for example, project management or sales force automation).
Part of the problem is that vendors of knowledge management applications primarily offer point solutions to particular knowledge management issues. Consider some of the popular knowledge management applications on today’s market:
¨collaborative group support
Such applications evolved from legacy personal productivity applications: databases, word processors, groupware, contact management and project management. Many of the solutions in these areas are very good—within their limited scope. Many of the vendors of these point solutions will extol the virtues of their proprietary Object Oriented Database or their closed architecture environment. And they may be right about the advantages that derive to that single application. But the bottom line is that these solutions create islands of information that are inaccessible to other applications.
Today, organizations want and need to share knowledge across applications and functional boundaries. Any system that draws a ring around information and secludes it for the exclusive use of one workgroup or business function cannot be part of a truly enterprise-wide knowledge management system. Vendors’ misguided concentration on point solutions has hindered the development of truly efficient knowledge management systems. Organizations that are prepared to embrace enterprise knowledge management will quickly cast off their redundant data sharing applications.
It appears we are repeating the disaster of the early days of corporate web sites. Then, each product group or business unit or geography put up its own site. There were no standards, no interoperability, and few links from one product line to another. It was absolute chaos. Most companies today have consolidated their web presence; and while one group may not own all of the content, there is a single information architecture and navigation scheme, and graphic and presentation standards for all pages.
You achieve the same advantages with an enterprise approach to your Web site as you will gain by using an enterprise approach to manage knowledge.
The Paradox of Knowledge Management
Why have organizations not yet built enterprise knowledge management systems? Simply put, there has been a collision between organizations’ desire to build enterprise-spanning knowledge management solutions and the practicalities of knowledge management implementation. There is a fundamental paradox that has led organizations to build the bottom-up point solutions that are at the crux of their current closed and inefficient knowledge management systems.
The paradox can be stated as four points that address issues of knowledge management systems’ usefulness. In order to be useful knowledge management must do the following:
1.Cross all factions of the organization, but to be successful it must also target the needs of departments and individuals. When companies set up functional boundaries to form a logical division of responsibilities and communication within the organization, they create power boundaries that in turn create information boundaries. However, much information is useful across functional groups and therefore should be available to those groups.
2.Engage the largest community, which includes management, employees, suppliers, clients, and investors¾But to be successful the KM solution must also address a targeted audience. The more people you are able to serve, the more efficient the system inherently is. But different individuals use information in unique ways that best serve their specific organizational role. They must not be limited to a single way in which information can be viewed, accessed, searched, or compiled.
3.Capture and link to the broadest possible knowledge base¾But to be successful it must also collect and index only limited assets. When an organization creates a large knowledge base it’s more likely to contain the information the people need in order to productively perform their jobs. But the larger the knowledge base the greater the chances that the system will become unwieldy, difficult to search, and hard to maintain.
4.Improve the organization’s business processes, but to be successful it must also not require behavioral change of its users¾A successful enterprise knowledge management system must not just grease the wheels of inefficient business processes. Too many knowledge management systems are repositories of ineffectual processes that really comprise “worst practices” databases. Business process change demands behavioral change.
To date, the primary challenge in implementing enterprise knowledge management has been technological. However, the means with which to build an integrated knowledge environment across functional boundaries are now at hand.
Building Enterprise Knowledge Management
How do we define enterprise knowledge management? It is a consistent and integrated view of the sources and uses of knowledge across an organization. Enterprise knowledge management takes into account every knowledge source—from what employees know to what clients tell us—and merges it with traditional corporate knowledge such as standard operating procedures. And it considers every possible use of such knowledge—internal use, from human resources to sales; and externally, from clients to potential business partners. No source or use of information is unaccounted for within the system.
How do you implement enterprise knowledge management? Begin by creating a single corporate data model that identifies common data and objects and makes them accessible across the entire enterprise.
The enterprise knowledge management scheme is based on a few simple premises and characteristics:
1.The first premise of enterprise knowledge management is that there is no “natural” view of data. Each and every data object is created in a way that is independent of the ultimate use of that data. To create data objects, standard definitions of them must be created and adhered to. In the same way that relational databases must normalize data—remove redundant data and duplication of objects—in order to be efficient and avoid maintenance confusion and errors, so too does enterprise knowledge management rely on normalized knowledge for smooth operation and ease of management.
2.Enterprise knowledge management requires open architectures and standard protocols. The individual applications that will support enterprise knowledge management throughout the organization must be able to communicate with each other, which is why applications with proprietary data stores have no place in enterprise knowledge management.
3.Enterprise knowledge management must integrate internal and external data. The boundaries of corporate knowledge go beyond internal knowledge. The knowledge shared by suppliers, distributors, and clients in their dealings with us is important company data that must, along with internal data, be managed. In addition, every company needs access to analyst reports, competitive information, macroeconomic information, and much more. While we usually have some control over the format of internal data, we ordinarily have much less control over external data. This is why standards like XML tags will in the future be critical.
4.The enterprise knowledge management effort must embrace all electronic corporate communications; intranets, extranets, and public Web sites must all draw from the same data resources. The traditional view of intranets, extranets, and Web sites is that they represent different repositories or networks. They were thought of as exclusive entities with little in common beyond their shared infrastructure. But this view is incorrect. To create separate repositories of data for each of these entities is redundant and unnecessary. There is plenty of data that can and should be shared across these sites: project data, phone numbers, news, etc. It’s the data that should be tagged as public or private, confidential or non-confidential, not the network.
5.Finally, and most importantly, enterprise knowledge management must cross functional boundaries within the organization. Businesses are organized into functional groups (IT, HR, Sales, Research) to make management easier. Don't make the mistake of trying to make your corporate knowledge fit into the same rigid structure. Corporate organizational structures exist to make it easier to manage people, not knowledge. There is no reason that your corporate knowledge and your people should share the same organization chart. Once you understand the different uses for your corporate data, the structure of the data mapping should fall into place.
The Single Corporate Data Model in Use
Once built, the shared corporate data model will have inherent flexibility, allowing users to extract pieces of data that can be viewed within a context directly applicable to their particular use. Stated simply: The use of the knowledge determines how it is viewed.
Often in life different people assign different values to the same objects based on the perceived or the actual usefulness of those objects. Similarly, with EKM, knowledge objects are presented differently depending on what the user needs.
How do common object definitions create efficiencies? To understand this, think for a moment about how different individuals throughout an organization might need to access related information about a single entity. Let’s consider the example of an employee.
The definition of an employee might be established with the following fields: name, address, health plan selected, title, department, supervisor, job duties, special skills, past experience, clients handled, and past projects completed. Now, imagine how different people within the organization might use some of those individual fields.
¨address and health plan information is useful to Human Resources
¨staffing managers need access to the employee’s skill set, geographic location, and availability
¨the Research Department needs to know which employees have industry or product and vendor knowledge
¨a colleague who identifies an employee with critical project knowledge needs contact information
While the use of the information varies greatly, each use references a single entity represented by an employee object. Establishing a single definition of an employee across the organization makes it easier to perform searches across functional groups¾for example, pinpointing employees with particular industry knowledge in specific geographical areas who have worked as project managers on engineering engagements.
Having a single data model does not mean that all users see all the data in the same way. Obviously, access controls over the data elements must make sure that sensitive data is supplied only to authorized users.
Also, when a user makes a request for knowledge from the data objects stored, the way the data is displayed will be directly dependent on who the user is and what they want to do with the information.
Consider a portion of the enterprise knowledge base made up of news clippings, competitors and client information, and project work products. A project manager wants to view this information organized by client names. The Marketing Department may want to view the same information aggregated by industry sectors. Staffing managers could ask for the data to be organized by who contributed it. All three requests aggregate data from a common repository, but present data items in an order required by the task at hand. In technical terms, the knowledge needs to be classified by multiple taxonomies, defined by the use of the data. As a general principle, the use determines the view.
Data must also be independent of the different corporate networks that it serves. As we discussed earlier, intranets, extranets, and public Web sites must not be viewed as different repositories, but rather as interconnected networks that draw upon the same corporate resources. In the situation of IP networks, the “type” of user determines the extent of their accessibility.
In the same way that a person’s use determines his or her view, access controls allow us to define a user’s right to particular data objects and therefore limit the view. Company press releases are a good example of a data object appropriate for viewing on an intranet (for employees), an extranet (for clients), and a public Web site (for press). The press release should be a single data object, made accessible to all three networks.
In a situation where knowledge assets are appropriate for one person but not another, the user’s login information will determine what can be viewed. This demonstrates how important it is for knowledge management systems to create access controls over the data, not over the network. Today, networks are built to allow access to certain people and to deny access to others. This is the wrong approach. It should be the data that is tagged as being confidential, non-confidential, or public. With the implementation of a shared corporate data model, separate repositories of information for each network will no longer be necessary.
It is also crucial that organizations embrace data metatagging. Metatags are bits of contextual information attached to knowledge that can be used to determine issues of access and taxonomy. In the simplest case, the metadata could be the author and date of a document stored as document properties.
More value comes from tagging knowledge assets with the context in which they were created, and the use or impact of the information. For example, a proposal could be tagged with the name and industry of the target client, the type of work proposed, and whether the work was won or lost. Tagging with context or impact increases the likelihood that the knowledge will be reused appropriately.
Capturing Employee Knowledge
One of the traditional challenges of knowledge management is transmitting the knowledge that employees have inside their heads into the corporate knowledge base. This can be especially difficult in professional services companies, where to distract professional service workers from billable work is at best unpopular and at worst unprofitable.
Implementers of enterprise knowledge management cannot decrease overall billability of other employees. The challenge is to extract the maximum amount of information with the minimum of overhead.
Fortunately, what knowledge workers know is encoded in their work products—product knowledge, management techniques, and industry knowledge—and much can be extracted from that output. Emerging technologies such as text and term extraction, and conceptual mapping (the grouping of documents according to semantic similarity) will be critical. Technology will never be able to extract and summarize all of the key information in a knowledge asset. However, the more technology can extrapolate explicit knowledge, the more time knowledge workers have to focus on tacit knowledge transfer.
Overseeing Enterprise Knowledge Management
Scient has divided its KM group into three knowledge initiatives: Applications, Transfer, and Services.
Knowledge Applications is probably the most familiar. It encompasses the systems and infrastructure needed to support EKM in the enterprise. Our data architect, who is responsible for the enterprise information and systems architecture, resides in this group, as do the other programmers and developers with KM-specific expertise, such as data extraction, expert systems and parsing. For traditional IT skills, we contract with our IT department. There are two advantages of this approach: first, we are not duplicating skills between IT and KM, and second, the approach ensures that the KM solutions are aware of and integrated with the technology standards of our organization.
Knowledge Transfer, the second initiative, is our training and education initiative. Training encompasses new employee orientation, acculturation, and professional development for our Professional and Core Services staff, who provide technology and consulting skills training as well as education on the use of KM systems and the knowledge sharing culture.
The last KM initiative, Knowledge Services, is critical to our organization. Some members of the services staff direct the development of our client-service methodology, document our internal processes like recruiting and sales, and supply research and analyst services to our engagement staff. More are engaged as Knowledge Liaisons: staffed as knowledge management professionals on each engagement and as representatives to each business unit and internal department.
The liaisons are a direct connection to the operation of the business. They guide the rest of the organization to knowledge assets, instruct our colleagues on the use of knowledge management systems, and incorporate new knowledge assets into the repositories. Last, they provide important feedback about the actual field use of knowledge management products and services.
There is a big advantage to staffing Knowledge Liaisons across multiple projects or business units: As they interact with their targets and with each other, they begin to recognize cross-enterprise issues. In some organizations there may be no better way to identify enterprise-wide opportunities than through a KL program.
One last point on the organization of the KM initiative: the KM group is chartered to define the knowledge architecture, implement the knowledge infrastructure, and help the rest of the organization to use the KM systems and services. The KM group does not "own" or control the knowledge assets. These are owned and managed by the creators and contributors and by their various functional organizations. The KM organization does define the standards and procedures for knowledge acquisition and sharing.
Enterprise Knowledge Management requires centralized leadership¾a Chief Knowledge Officer. The case for CKO is premised on the need for a single, executive-level manager to oversee all the knowledge management efforts of the organization. Tackling enterprise resource management is a time- and resource-intensive undertaking that requires vision, the ability to cross the functional boundaries of the organization, elicit the participation of top management, attack and dismantle legacy applications, and create and implement standards and policies. Such coordination is best achieved through integration at the highest level of the management hierarchy. Most importantly, senior leadership is necessary because it is the enterprise as a whole that will succeed or fail.
Ultimately the knowledge management system should disappear as it is integrated into the organizational workflow. We will be satisfied only when it isn’t possible to point to an external system that is managing knowledge. Instead, the storage and retrieval of knowledge assets should simply become part of each employee’s work process.
Copyright 2009-2016, Douglas Kalish. All rights reserved.