[an error occurred while processing this directive]

About BRINT | News About BRINT | Help & FAQs | Users Guide | Advertise Here |
Welcome to the World's No. 1 Resource for Business Technology Management and Knowledge Management

Services: Knowledge Portals · Knowledge Map · Knowledge Network · Book of Knowledge · NEWS· INFORMATION Channels: General Business · Business Technology · E-Business · Knowledge Management Community: Join the Network! · Global Network · Events Calendar · Executive Jobs	SEARCH [HELP]

• FEATURE • Order Out of Chaos: A Practitioner's Guide to Knowledge Management

---

by Joe Helfer,
Founder, Knowledge Management Readiness Systems (KMRS)

---

Consider this summary paragraph on Knowledge Management found on the Northern Light Web search engine.

"General Motors Corp., Fidelity Inc., Hewlett-Packard Co., and a growing number of other leading firms are taking the infant discipline of knowledge management very seriously. Each is working to improve how they acquire, share, and use knowledge in their organizations. In each case, IS plays a key leadership or support role. IS' systemic thinking, technology know-how, and experience working with many departments can be the perfect background for knowledge management. Visions vary, but duties include: 1). Mapping knowledge and information resources both online and off-line; 2). training, guiding, and equipping users with knowledge access tools; and 3). monitoring outside news and information. The current corporate interest in knowledge management is no passing fad. It is part of the quickening switch from an industrial-based economy to an information-based economy."

This sounds terrific, however, the fly in the ointment is that there are so many ways of dealing with the question, "How do we manage knowledge?" One can easily become overwhelmed by either philosophical debate or arguments over appropriate software products. The core challenge of knowledge management lies in navigating through all the technology suppliers that claim to have KM products and all the employees that claim KM is central to the effective execution of their jobs. This article provides a framework to help you figure out who is lying, or, to put it more diplomatically, what the varied viewpoints of a KM system entail. In addition, this article will provide a framework for the economic valuation of KM projects. Social organizations make implicit or explicit economic valuations when they make go/no go funding decisions for KM projects.

Since corporations tend to form task forces or committees to oversee KM projects, a wide range of viewpoints can emerge. MIS, product management, librarians, customer support, and manufacturing professionals typically do not share a common framework or language for working together on a KM project. In this article we will try to help cross-functional teams answer the following questions that should surface during KM meetings and planning sessions. In our experience at KMRS, we have found that without shared answers or approaches to these questions, the task force or committee will find it very difficult to create a project plan or agreed-upon course of action.

Core Knowledge Management Questions and Tasks

Questions KMRS has found that project teams and team leaders who know how to ask the right questions tend to have higher success rates than those who don't. A representative set of such questions, such as those below, should occur during the formative stages of a KM project: How can I tell the difference between data, information, knowledge, and wisdom (DIKW)? How can I determine how much information (DIKW) is missing from a process? How can I calculate or get a handle on the value of missing information (DIKW)? How do you handle management resistance when improving the process impinges upon privileged information? (Also known as the "knowledge is power and I ain't gonna give it up" issue) What do you do when the CEO says that he attended a management seminar or talked to his cousin Shirley and now wants a KM system? What are the unstated assumptions and hidden agendas of the varied evangelists of KM systems? Why should you care? Do KM products really have anything to do with the management of knowledge? What is the relationship between entropy, missing information, and corporate downsizing?

In addition, KMRS has found that following a specific sequence of tasks greatly increases the probability of success and decreases the number of false starts in a KM project.

Tasks Following this sequence of tasks, in our experience, greatly increases the probability of success and decreases the number of false starts in a KM project: Choose or identify a diseased or flawed business process. Build a rough model of the business process that makes the "as-is" environment explicit (a first-cut business process audit). Identify the Data, Information, Knowledge, or Wisdom processes (a first-cut KM audit) embedded in step 2. Perform an economic valuation of the benefits you hope to derive by creating a KM system to improve the process. Identify the linkages between the outputs of the re-designed process/KM system and other systems and processes within the enterprise. Architect a strawman solution, an advanced rapid prototype, as a focal point for generating consensus among team members.

Case Study: Knowledge Management at LOTUS Notes

The case study underpinning this KMRS diagram comes courtesy of Bill Zoellick of CAP Ventures who presented it at a session on "The Practice of Knowledge Management" at AIIM '98. Bill's framework is very different from the KMRS model, and this analysis of the case does not carry his imprimatur. I chose it because it helps make tangible an otherwise rather abstract framework.

Around 1990 LOTUS Notes went through an explosive growth in its user base and product complexity. Not surprisingly, the help desk became overwhelmed. The process for answering telephone queries to the help desk relied on a cadre of gurus with large notebooks and yellow post-it tags: the sum of the individual technician's DIKW (Data, Information, Knowledge, Wisdom). An effort was undertaken — surprise, surprise — to use LOTUS Notes as an enabling technology to better deal with the disconnect between the distressed LOTUS customer base and the capabilities of the help-desk process.

Since LOTUS NOTES had just incorporated full-text searching as a product feature in 1990, top management decided that a vast process of transcription should take place to convert the notebook data into digital form. Unfortunately, the help desk technicians weren't overly enthused when the newly digitized LOTUS Notes KM system yielded 50 possible full-text answers to every customer query.

The imposition of help-desk technician productivity quotas didn't help. We all know the routine — blame the individual rather than the process. To meet the quotas for information sharing and collaboration, the help desk technicians flooded the system with e-mails. Another impediment to progress involved a misalignment between the KM system and the question/process it was supposed to address. Rather than being driven by the logic of customer problem characteristics, product component and technology typing within the LOTUS infrastructure drove the process.

The solution emerged when the focus shifted to organization by problem types from the customer's viewpoint — making the reduction of the customer's missing information as the starting point. Using a Yahoo-like structure for the help desk's KM system became a critical success factor for the KM team, a team in which librarians, experienced in aligning user question types with facts and information resources, organized the hierarchy. This development enabled them to build the shareable, collaborative endeavor that is core to the KM mantra. This solution to the issue generated the capability and awareness within LOTUS to develop competitive advantage and raise the bar for competitors. Help desk linkages to the consulting services group and the product development group provided great corporate advantage.

The solution to reducing the entropy of the help desk process allowed LOTUS to reduce the entropy of more strategic processes — it allowed multiple strategic question frameworks to participate in the DIKW flow. "Hold on there!" you may say. "What does this entropy stuff have to do with intranets, data mining, and knowledge management?" Keep reading.

Methods and Tools for Core Knowledge Management Tasks

What do we mean by DIKW? Let's start by distinguishing between wisdom, knowledge, information, and data. Although there are more rigorous approaches to categorizing such matters, KMRS has found that a common-sense approach such as the following works just fine for a KM framework.

Data:	6. blue, Australia, (818) 340-7895
Information:	Adam is six feet tall, has blue eyes, lives in Australia and has a telephone number
Knowledge:	Adam is easier to reach by telephone than by e-mail
Wisdom:	It's best not to communicate with Adam by email

If we look at steps 2 and 3 of the Core Knowledge Management Tasks — modeling of a current business process and identifying the DIKW components in the processes — those steps really answer two different questions: What are we doing? What do we know? DIKW analysis targets step 3, asking more questions: Does the process create, use, or destroy DIKW? How does the process do whatever it does to the DIKW?

In contrast, consider this marketing pitch culled from the Web site of a KM consulting firm.

"Knowledge Management. Is your firm capitalizing on its most important asset — the knowledge of the workers? Are you making best practices available so your firm can continually improve? Are you making important documents easily available to key personnel, on demand? If not, give your firm a Knowledge Management Audit (KMA), and learn about the processes and technologies that can make your firm work smarter."

I really like this pitch by virtue of the way in which it denudes the KM process so that it can mean almost anything to anybody. How does making important documents available to key personnel increase the knowledge of the company? Why is the provision of best practices guidelines a guarantor or even a rational method for improving how your company manages its knowledge? Best practices sounds great, but it avoids the question of best practices in doing what. If the things the company does don't make any corporate sense, how does doing them better help matters? In terms of the KMRS Core Knowledge Management Tasks, the first task — identifying the diseased process — requires checking whether it makes sense to improve something before starting. Sounds obvious, but — trust me — many KM projects start failing right here.

What exactly are you going to audit: the data itself, the process flow in the company, the policy documents for processing a purchase order, the frequency of e-mail messages from one department to another? How does getting the right information to the right person address the issue of corporate knowledge vs. individual knowledge? How come companies with lots of really smart people persist in doing really dumb things? And how come companies with lots of dumb people sometimes do truly brilliant things?

KMRS Axiom #1 If you can't tell me what isn't a Knowledge Management System and who isn't a Knowledge Worker, you really don't know how to create the former and empower the latter.

ENTROPY: "How Do We Know That?"

There is a scientific measure for the state of disorder of an information system. It is known as information theory entropy and can prove extremely useful, if not critical, when analyzing DIKW issues. If the team does not know how much data, information, knowledge, or wisdom is missing from a process, it will probably not succeed in building a new system that supplies the omissions!

The notion of entropy comes from the scientific discipline of thermodynamics, which creates a framework for understanding the behavior of matter in terms of heat, energy, work, temperature, etc. Entropy is a measure for the physical disorder of a system. We know where the atoms of water are located in an ice cube with more certainty than their location in a cloud of steam, produced by heating the ice cube in a microwave oven. Therefore, we can claim that entropy increases throughout the melting and boiling process. A pound of steam has twice as many atoms as a half pound of steam and twice the entropy. Conversely, freezing an ice tray of liquid water reduces its physical entropy.

Translating the concept to information, two times as many things to worry about implies twice as much uncertainty. This inverse relationship between knowing about a system and its state of disorder prompted much intellectual activity in the early 20th century. For example, the thermodynamical law that all systems increase in entropy unless work is performed on them is analogous to the managerial concept that it takes work to prevent an enterprise from falling apart. In the middle of the 20th century, the rigorous proof that the physical concept of entropy could indeed extend to the abstract world of data constitutes the core contribution of Claude Shannon, who developed it into a full-blown model in 1948 while working in Bell Labs. Shannon used the model to solve the fundamental telecommunications problem of how much information could be sent over a phone line. His work represents the analytic underpinning of much of the communications technologies, from modem protocols to routing table algorithms, that underpin the networking revolution we are still experiencing.

In any case, when your boss or a KM team leader says that the entropy is too high or when you encounter the phrase "information theory entropy" in the KM literature, rest assured that the concept is not just a metaphor, but a hard-nosed business term.

KMRS Axiom #2 You can measure how much information (DIKW) you are missing and the value of perfect information.

As a concrete example of this axiom, let's consider how to determine the value of perfect information in a real-world situation. A real estate company is considering a "buy/no-buy decision" in which the findings of the local zoning board can radically change the expected economic value of the targeted property.

In this hypothetical situation, a real estate team or agent assesses the business situation. In making the assessment, they could use experience, historical data, input from informal meetings with the zoning board, whatever. The key point is that the real estate office formulates a model for the process of purchasing the property. That model typically involves a combination of answers to "What if?" and "How much?" questions. Tree diagrams can effectively represent the model by showing the various possibilities, their likelihoods of occurrence, and their payoffs.

The decision tree diagrams for this situation were taken from Vanguard Software Corporation's Web site [http://www.vanguardsw.com] in a walkthrough of its DECISIONPRO analysis tool. One reads the tree from right to left in order to calculate the expected value of the project: adding up the probability of an event multiplied by its value (positive or negative).



Compare the first decision tree diagram (top) with the second (above).

The value of perfect information (knowing whether the permit will be approved or denied) is the difference between the two expected values ($27,000-$14,200 =$12,800). If we had perfect information, we could remove the expected downside loss of rezone denial from the scenario. The difference in value is the mathematical product of the downside loss ($32,000) multiplied by its probability of occurrence when we had imperfect information (40 percent probability of being denied).

The Strange Case of Entropy at IBM

IBM senior management's method of handling the PC revolution supplies a classic example of the reduction of entropy by decreasing the size of the system, rather than supplying missing knowledge. Their managerial acumen and method of dealing with entropy created about $250 billion in market value — for their competitors.

At the time, IBM believed in an economic model known as Grosch's law, which delineated the economies of scale and business model of the classical mainframe computing mantra. The cost-center and product managers at IBM had a reward system and process structure that disallowed the posing of certain questions regarding the IT industry.

The missing information entropy fell along the lines of "How can I come up with a business model for products in this space without destroying or impinging upon the turf of the existing product management culture within IBM?" This is clearly a wisdom or knowledge question, not an informational or data one. I am sure that IBM's competitive intelligence group flooded the system with data and information about PC purchases, technology trends, competitors' product plans, etc. However, the more data and information collected, the more entropy it created. Why? It made more uncertain the answer to the core business question: How do we arrange ourselves to deal with a commodity business with low margins? How can I get into this line of business without damaging my existing product strategy?

The longer IBM waited, the more business decision tree possibilities that emerged and the higher the entropy. "Hey, if the research generates more questions than answers, what good is it?" Also they had the real issue of meaningless market research. Mana-gers sent forth their legions on data and information-gathering missions with questions formulated to help them solve managerial questions in ways solvable by established patterns conforming to institutional dicta. The fundamental clash between Moore's law for the decreasing price of computer technology per se and Grosch's law began to destroy the empire. A scarcity of process and political answers, not a lack of market intelligence, formed the core of the failure. IBM's solution was to lower the entropy by shrinking the system and removing the immediate threat of the uncertain answers to these questions: Give the operating system to Bill Gates!

New question:

How can IBM become the leading manufacturer of PC hardware devices?

Questions removed from the system:

How will the operating systems and applications market for PCs impact our existing business?

How do I produce products that capture market share without cannibalizing from the existing product management revenue stream?

How should I position IBM's PC strategy with our key customers and installed base?

Typical Corporate responses to high levels of entropy:

Denial

Downsizing

Business process re-engineering

Acquisition

Pep talks and arm waving

Establish a quality team

Fire the CEO

KMRS Axiom #3 Organizations not only act to maximize present value or optimize short-term profits, they also minimize entropy.

Ironically, this approach to the measuring the value of perfect information and calculating missing information is typically ignored by top managers and KM teams aspiring to take advantage of the very technologies that make KM systems possible — modern communications hardware and protocols. The approach is fairly straightforward to use and doesn't take that much effort, once you have decided what system you want to examine. If the KM team does not define the problem or describe the process/system in an intelligent manner, then the team will probably not succeed in analyzing alternatives or even talking about them in a meaningful way.

Entropy or missing information can occur at any stage of the KM process: Data Entropy, Information Entropy, Knowledge Entropy, and Wisdom Entropy. If an enterprise has a misaligned DIKW situation, reducing entropy in one area may not reduce the entropy in any of the others. The misalignment results in a KM system in which the DIKW of an enterprise work more like stand-alone systems. The data, information, knowledge, and wisdom questions are not logically linked: The answer to one does not provide more certainty for the others.

BUSINESS PROCESS MODELING: "How Do We Do That?"

The entropy approach described above only yields meaningful insights about real-world business issues if the KM team has a good handle on the business itself. I like to call it the wildlife photographer's dilemma: If you take a photograph from too far away, you may not see that the dark spot is a grizzly bear, but if you zoom in too close, you may miss the grizzly bear just outside the picture frame — the one coming to rescue the first grizzly by attacking you! How do we capture the essential elements of the process? Too little and we can miss critical activities (the LOTUS Notes technicians didn't share information). Too much and detail we neither understand nor need will overwhelm us. (Personally, I use small Post-Its rather than the medium-sized ones as my "insight capture mechanisms")

In the case of our previous real-estate model, it isn't too hard to build a crude model of the business process and discern the key pieces of DIKW involved. Most business activities are much more ambiguous, such as new product development, with complex activity paths that can appear almost chaotic at first glance. If I find that manufacturing can't supply a component effectively, I will start an outsourcing process. If my online searchers detect that my competitors have released a product that contains most of this feature set, I will delay our product release and redesign.

Several computer-based tools exist that can help deal with this dilemma. Most require about a week to learn how to use and all require high intelligence and some degree of business intuition in order to provide useful results. IDEF is a good example of such a tool for visualizing and analyzing business processes. IDEF originated in the U.S. Air Force's efforts to improve the manufacturing processes of its prime contractors. It provides a pictorial framework representing and illustrating complex manufacturing flows in a simple manner that works for all the different disciplines involved in designing a computerized manufacturing system. The beauty of the approach lies in the fact that it can simultaneously provide a top-down management view while allowing for extremely detailed views for the implementor. Used first as the front end of a team effort prior to developing a Computer Integrated Manufacturing System, IDEF was later adopted as a standard methodology by the business process re-engineering folks and database designers.

One can use IDEF for any of the questions posed in the earlier "Knowledge Management Alignment Framework" diagram. It can create an explicit representation of business processes and provide an underpinning for activity-based accounting at the "guerilla project" level. The latter functionality can prove invaluable as a reporting mechanism to capture process improvement data that can sell the project to top management. "We found that having the product managers do market research themselves will cut 20 days off the product development cycle and save $3 million in indirect costs per year. So what do you think? Should we go ahead?"

The diagram at left is read as follows:

When we perform an activity (develop a new product) we take inputs (from central engineering, the president of the company, market research, competitors' Web sites) under the control of a system (financial constraints, product life cycle policies, patent law), and, using a set of mechanisms (manufacturing's design center, the R&D department, computer simulation tools), produce outputs (product plan, marketing literature, advanced rapid prototype)

In addition, these IDEF tools allow the team to zoom in on the model and examine the details:

Many business process re-engineering practitioners and MIS people who participate in KM projects are familiar with the IDEF approach to business modeling. IDEF is as good as any, and better than most, for building a model. It certainly beats trying to deal with hand-drawn flow charts and grease boards with "DO NOT ERASE" emblazoned in the lower corners. In addition, a few IDEF software products actually have links to KM enabling technologies. For example one can use Metasystems' IDEF products in conjunction with FILENET's workflow products, as well as Oracle's database products, to build the information technology components in a KM environment.

The clincher is that these products contain Activity Based Costing modules that allow the team to uncover potential cost savings: ABC data are quite acceptable to the finance people. This helps to keep the project alive in terms of demonstrable short-term gains for top management and to provide the credibility for the KM team to deal with higher level questions in the KM alignment framework.

For the truly innovative online searcher or other member of the KM team, this modeling activity can represent the foundation for knowledge-based products for resale. By examining the DIKW inputs and comparing them with DIKW outputs, the team can make a first-cut determination as to whether or not they have identified enough value added (value of perfect information) for potential productization. Consumer goods corporations have a long-standing tradition in this regard. They have found it quite profitable to package and sell such information to other consumer goods corporations: Mined information for customer preferences and buying patterns for brandy might very well have market value to a cigar distributor as the basis for a target marketing campaign. A cognac with your Cuban?

KMRS Axiom #4 The DIKW outputs of business process models are the raw components of knowledge and information products for the knowledge-based economy

Selected Insights About Technologies Used in KM Systems

Intranets/Extranets

The challenge here is that Web-based data are difficult to validate or interpret. Whether you use pull or push technologies, the question of "How do you know that?" is not immediately obvious in the land of HTML. The WWW Consortium is attempting to address the chaos and entropy of the Web itself through the use of metadata. Metadata are data about data, such as provided (hypothetically) by XML tags that augment HTML. Metadata within this framework serve the function of reducing the entropy of the information derived from the data, by providing an audit trail in effect and reducing the uncertainty as to the data's origin and hence validity. In principle this increases the confidence one has in the information. XML should address questions such as, "OK, so you got it off the Web. How do we associate a confidence level with this great factoid that you found us? How do we know that it isn't a random number generated by a drug-crazed 18-year old Webmaster doing corporate outsourcing work in his attic while attending bartending school during the day?"

Workflow Products

The well-known LOTUS Notes, MS Exchange, and a myriad of other collaborative software products typify this group of tools. The challenge here is two-fold: These enabling technologies must be designed, built, and managed, and they can easily increase rather than decrease entropy in a corporation. By flooding recipients with pieces of information or knowledge that they don't need (not an atypical situation in corporations seeking collaboration for its own sake), a corporation can consume inordinate resources, sending and receiving information of no marginal utility to the enterprise as a whole. One can also easily find oneself embarked upon a project of remarkable complexity, since these products require rather elaborate interfaces to interact with legacy systems and other information assets within the enterprise.

Data Mining

Corporations often try to create useful information out of the historical data they collect in the course of doing business. When you see special coupons in the supermarket offering you a bag of potato chips free when you buy a bottle of beer, you can rest assured that this is the result of a $20 million data warehousing effort at the parent supermarket's headquarters.

You basically have two choices: Build a data warehouse or build a data mart. Implementing the former is a Herculean task requiring extremely sophisticated database machines and product sets, as well as a large and masochistic MIS departments. The latter is a simpler version of a data warehouse that answers pre-selected queries on the data, a model extremely prone to developer bias. Do you really want your IS team choosing the query types that your product managers can ask? Both are really information management tools rather than knowledge management systems components. The key challenge in these efforts usually involves transforming the underpinning data sets designed for transaction processing into useful information tools.

You could end up learning the answer to external customer questions, such as the likelihood that a Chicano female living in Cleveland will buy gefilte fish on the evening before Good Friday. These technologies are totally inappropriate for KM projects since they take so long to implement. KM projects need results in short time frames, not years. A KM project that depends upon the design and implementation of a data warehouse for its success had better be the favorite child of the CEO.

The Telephone

This remains both one of the most effective KM enabling technologies available and one of the most overused and underutilized assets. For some reason people seem reluctant to call someone up and ask "Hey, do you know how to…?" when it comes to higher level knowledge issues. Our advice? Call.

Conclusion

We hope that this framework will help you deal more effectively with the notion of Knowledge Management from a practitioner's point of view. If KM is to become more than a traditional MIS project and truly assist in the success of a knowledge-based enterprise, then it involves gathering new skills and understanding. The core competencies of the KM team members clearly should include an understanding of business process modeling, activity-based accounting, economic valuation of Data, Information, Knowledge, and Wisdom assets, missing information entropy as well as the business acumen to align a business process to its embedded DIKW. There are half a dozen axioms that a participant in a KM project team should understand. KM product suppliers and systems integrators often promulgate many misleading and trivializing notions that can destroy a KM project's value if adopted.

One final note, readers seeking further background on KM matters should visit the award-winning Web site developed by Yogesh Malhotra from Knowledge Management Think Tank [http://www.brint.com].

Knowledge Management Readiness Systems has been involved for some time in helping its clients manage knowledge for the attainment of corporate goals. KMRS provides Economic Valuation of KM Projects, KM Training, KM Audits, and KM Architecture Services. This article makes use of KMRS internal models and research as well as focused interviews and case studies. Joe Helfer, the co-founder of KMRS can be reached at (818) 340-6324 or helferjoe@ilan.com.

---

Originally published in Searcher: The Magazine for Database Professionals, Jul-Aug, 1998.
Reprinted with permission of the author.