|
Introduction "How
does Knowledge Management (KM) improve performance? In particular, how does it
improve financial and operational (process) performance? This is the question that
matters most to many senior managers and executives. They need answers -- and more
than one -- that will justify and reinforce the importance of integrating and
institutionalizing KM in their organizations.
To be of practical value, KM must affect what is done, how it is done, and how well it
is done. Clearly, then, one critical link between KM and business results is through
business processes. The impact of KM on key business results might well be the
greatest through its potential for improving the performance of business processes.
This suggests that the design or redesign of business processes should factor in an
understanding of where and how knowledge plays a role in the performance of the
process. In turn, this is accomplished by identifying the knowledge needed to make
the decisions or take the actions that make up the process, as well as addressing
considerations related to the knowledge generated by those decisions and actions (e.g.,
capture and distribution to name but two).
This paper outlines some of what I see as the basic fit between KM and business
processes. It begins with a framework for thinking about processes and then
considers how KM initiatives might connect with a company's processes. It ends with
a review of some basic implications for action.
A Process Framework
Below is perhaps the most basic view of processes -- the well-known input-process-output
model. Albert Einstein once advised that "things should be made as simple as possible
– but not too simple." This model is too simple. It masks important
details by treating a process as a "black box." Something a little more
elaborate is needed.
Figure 1 - The Basic I-P-O Model
Processes: Some Additional Detail
Figure 2 is only a little more complex than Figure 1 and gives us much more useful
information.
Figure 2 - A Systems Model of A Process
Note in the diagram above that "process" is really a label for the
interactions between the Processor and the Inputs to be processed. More important,
these interactions define the process.
Note also that the processor is controlled by a "Controller." In some cases,
control is effected by way of instructions programmed into a computer or other equipment.
In other cases, the chief means of control is supervision. Often, however, the
"Processor" is a highly skilled person who operates under self-control. This is
especially true of knowledge workers. (See the companion article to this piece
titled "Knowledge Management and Performance in the Age of the Autonomous Performer.)
Inputs come from a "Supplier." This might be an earlier step in the
process, another unit within the company or an outside vendor. Outputs have a destination.
It might be the next step in a larger process, a different unit or an outside
entity such as a customer or client.
Finally, the dotted lines and circles that link the Controller with the Processor and
with the Inputs and Outputs are "feed forward" and "feedback" loops.
Feed-forward loops control process initiation and feedback loops controls process
termination. In effect, the feed-forward loop says to the processor, "It’s
time to start the process" and the feedback loop says, "The process has been
correctly carried out and it’s okay to end the process." The feedback loop
also controls progress toward the end result.
Where is the knowledge in
processes?
The key question is, "Where and how does knowledge come into play in a
company’s processes?" The answer is, "In lots of places and
ways."
- Inputs and Outputs. One place knowledge comes into play
in a process is as a production input, that is, as an input that is to be operated upon
and transformed into an output. Consider, for example, units such as R&D groups or
Marketing departments. Each depends heavily on knowledge input from the outside (i.e.,
scientific data, client feedback, consumer surveys, legislation, changing governmental
policies, etc.). These inputs are then operated upon (e.g, through analysis or
experimentation) to produce the unit's outputs.
- Controllers. Another place where knowledge comes into play in a process is in the
form of controls. Consider, for example, an automatic replenishment system. The system is
programmed to replenish certain products automatically when inventory levels drop to
pre-set point. That point might reflect knowledge about production runs, order processing
times and delivery pipelines. In these kinds of situations, knowledge can be
said to be "embedded" in the process.
- Processors. The "Processor" performs the actions needed to produce a
result from the process. If the Processor is automated, the actions may be prefigured,
that is, designed in advanced. This is especially true of computer programs that
carry out algorithmic processes such as automated insurance claims adjudication or
automated loan application evaluations. This kind of knowledge is also embedded or,
more precisely, "encoded" in the process.
Then again the Processor may be a person. The actions, however, might still be prefigured,
as is the case when a claims examiner, in accordance with clear-cut procedures handed down
from on high, processes a claim that has been suspended from automated processing for
manual resolution. Relevant knowledge is again captured in the procedure. Actions
might also be configured by the performer, that is, tailored to the situation at
hand. For example, a sales representative for a pharmaceutical firm might call on a
several physicians during a day's work. In discussions with the physicians, the
representative will probably present some "canned" information but, in all
likelihood, the representative will also customize his or her presentation to suit the
interests and requirements of a particular physician during a particular call. In
these situations, the knowledge, or capacity for action, clearly resides within the
individual.
- Design. Although some processes may be said to have evolved over time, many
production and business processes are consciously designed. Their form and structure are
not left to chance -- or to evolution. As a consequence, a lot of knowledge is
"embedded" in these processes in the form of specifications for the outputs, the
inputs, the routines and the requirements. Some of this "embedded" knowledge is
obvious, as might be the case with the sequence of operations making up the process.
Some is not so obvious and reflects the tacit knowledge of the designers.
This might be reflected in standards of performance which, although few seem to recognize
this fact, must always be set instead of determined. In any event, the knowledge
embedded in a process makes itself felt through what is done, when, how, by whom and to
what standards.
In case all this is beginning to sound rather mechanistic, let’s introduce one of
the factors that separates individuals and organizations: collective human
endeavor.
One reason organizations exist is because collective human endeavor greatly increases
the scale of operations and the scope of processes that can be carried out by
organizations. In short, organizations can accomplish more than individuals acting alone.
Organization also yields greater complexity. Consider the typical "order
fulfillment" process. This process is often defined as bounded on one end by the
receipt of an order from a customer and, on the other end, by receipt of payment from the
customer. The order fulfillment process can involve dozens or hundreds of people,
large-scale data processing systems, and thousands of processing steps. Many en-route
"products" or outputs are produced. Depending on the design of the
process, several functions are involved: order entry, manufacturing, shipping and
distribution, billing, credit and collections, too.
In these enterprise-wide processes, knowledge in and knowledge of the process is
fragmented; it is distributed across people, equipment, functions and even
organizations. Frequently, no one person – or even small group of people – has a
full understanding of the entire process. As much as anything else, this points to the
potential value of a KM effort that enables efficient access and sharing of high-quality,
relevant, timely knowledge up, down, and across organizational lines, especially those
functional and organizational lines that result in fragmented processes.
Implications for Action
Organizations that are serious about better managing their knowledge work will examine
their processes with an eye toward improving their performance. The situations that follow
illustrate the kinds of thinking that should bear fruit.
- Develop Basic Process Competence. At the risk of stating the obvious, one
of the most important issues to consider is the extent of the company's capability with
respect to process design, management and improvement. If a reasonable capability
does not exist it must be developed. It seems unlikely that an organization lacking
in the basics of process competence will deploy a KM initiative that will have much of an
impact on process performance. The knowledge of interest is knowledge of
processes.
- Look for Missing Metrics. If metrics are missing, no one can know how well a
process performs. An early step might be to establish metrics for process performance and
thus establish a baseline of knowledge about the level of process performance. Here, the
knowledge of interest is knowledge of actual conditions.
- Consider Benchmarking. Consider everyday processes such as recruiting and
hiring, or perhaps the launch of a new product. Sometimes, we know how well our own
processes perform, but we don’t know how that level of performance compares with
others. Here we may pursue knowledge of "best practices." These can be
internal or external best practices. The real point of benchmarking isn't to simply
mimic what others are doing; it is to learn from others are doing. The knowledge of
interest is knowledge of what is possible in the way of improvement.
- Work to Diffuse Internal Knowledge and Practices. On occasion,
particularly in the case of people, teams or units that engage in similar work, best
practices are unevenly distributed. One division is opening new markets at a record clip
and others are stumbling. This can be due to radically different market conditions;
however, it can also be due to very different practices and knowledge among groups.
Sharing these is a way to diffuse high-value knowledge throughout the larger organization.
- Provide A Supportive Learning Environment. The people who know the most about the
work processes in which they engage are those who do them. In many cases, they are also
the ones who define the work. Most important, if what is being learned is to advance or
improve the practice in a given area, the practice members are the ones who must do it. If
their learning is not supported, or if they work in a culture of hoarding instead of
sharing knowledge, best practices are confined to a few individual "stars" and
overall organizational performance suffers.
- Address Known Knowledge Gaps.
In many organizations, there are known
knowledge gaps: process performance suffers, and the reasons are known. What isn’t
known is what to do about them. This can be frustrating when we’re unable to focus
management attention on these gaps. Usually, this is a matter of priorities. In any event,
one quick route to improved process performance is to simply ask people where and how a
lack of knowledge is interfering with process performance or, alternately, where and how
better knowledge could improve performance.
- Check and Recheck Assumptions. One definition of knowledge is as "beliefs
reasonably held." In organizations, these reasonable beliefs often take the form of
assumptions. Nowhere are assumptions more critical than in the design or redesign of a
process. Because a company has successfully introduced product line extensions using the
same process for six years, are the assumptions still valid as they approach the seventh
year? It is not unusual for assumptions to be wrong or to have been correct but to have
become outdated. It is a useful practice, then, to periodically check known assumptions.
- Make the Implicit Explicit. In keeping with the item immediately above, it is
also the case that design parameters and assumptions are sometimes left unstated, let
alone undocumented. It can be a useful exercise to surface the unstated and often implicit
design assumptions that frequently underpin a company's most important processes.
- Learn from Malfunctions. Even the best designed processes sometimes malfunction.
An order doesn’t get filled, a production run has to be scrapped, or a call from an
important client or customer doesn’t get returned. All too often, the response to
these missteps is to punish the guilty and return to business as usual. The failure
to learn from process malfunctions results in lost opportunities to improve process
performance. Problems or malfunctions should be analyzed, their root causes determined,
and process changes made. Post-mortems or what the Army calls "after action
reviews" can be a valuable source of improvements in process performance. These
needn’t be agonizing, exhaustive reviews, but they should focus on finding out what
went wrong and identifying ways to prevent similar mishaps in the future. To the
extent these reviews focus on finding and punishing the guilty, energy will go into cover
ups, not clear ups.
Summary
If Knowledge Management (KM) initiatives are to yield any benefit to the organization,
they must affect its performance. Process performance is a likely beneficiary of KM
initiatives because knowledge affects an organization's processes in several
ways. Systematically examining a process to understand where and how knowledge comes
into play is a good starting point for subsequently improving the performance of that
process through a KM initiative. Depending on the results of that examination,
several options for action are available.
|
