The Knowledge Economy: Fiction or Reality?


Reason for republishing

I wrote this article in May 2014. The recent problems at the UWV (Employee Insurance Agency) with the WIA (Work and Income Act) made me decide to look up the text again after ten years. After rereading, there seems to be sufficient reason to republish the article, although some examples may be somewhat dated. But: Has much changed in reality?

 

Introduction

We live in a knowledge economy—or so it is widely claimed. But why don’t we notice it? Old economy habits still dominate our actions. Power positions based on information—or more precisely, the concealment of information from end users—are desperately maintained, even when it leads to disasters like the recent credit crisis.

Disturbing symptoms

Some time ago, I heard a radio interview with an entrepreneur who mentioned that his local government believed he needed 24 permits for a new project. It turned out that more than 100 were required. I don’t even want to think about how many forms this entrepreneur ultimately had to fill out, or how often he had to submit the same data. It was probably a lot.

Suppose this entrepreneur encounters a problem while searching online for the necessary permits and decides to call an internet helpdesk. In the best case, after repeatedly calling and hours of waiting, he might be lucky enough to get transferred to the right department and eventually receive the correct answer. Why can’t that happen the first time? Apparently, the required knowledge existed within the provider, just not in the right place.

Or try booking a trip online, looking for a holiday destination that accommodates both a disabled child and a pet. Chances are that the necessary information is somewhere within the travel company’s systems or staff, but they fail to offer it in a user-friendly manner. The same can be said for insurance providers and many other service companies.

Effects on businesses If we, as customers, are served so poorly, it’s almost certain that the employees of these businesses face similar challenges. There are countless examples of people leaving their jobs because they were stuck with routine tasks below their capabilities, as well as examples of employees being given tasks that exceeded their skills, with little support but full responsibility. And what about companies where the marketing department or product manager wants to quickly launch a new product but has to wait for the next release of the IT system?

Is this really an economy where knowledge is the driving factor? It certainly doesn’t seem like it.

What is the Knowledge Economy?

In a knowledge economy, knowledge is the driving factor. But purists might argue that the knowledge economy is limited to the domain of research and development, where innovation takes place, benefiting the whole country. Is that really the case? What about the application of knowledge? Isn’t there knowledge application in nearly all interactions between service providers and consumers? And wouldn’t there be significant improvements in almost every situation where services currently fail? Not just in customer and employee satisfaction but also in productivity and product innovation. Wouldn’t our country benefit from that? Shouldn't we be investing in these areas, especially during this economic crisis?

Everyone Is expected to apply the law

And what about the government? Isn’t its domain also highly knowledge-intensive? The legal principle that "everyone is expected to know the law" doesn’t just apply to citizens like you and me but also to civil servants. Given the continuous changes in laws and regulations, it would be better to adjust this rule to "everyone is expected to be able to apply the law, and every legislator must make this possible." That would be a real challenge for the knowledge economy! If the government could take on this challenge, it would not only give the economy a significant boost but also greatly improve its relationship with the public.

The same applies to companies that deal with many regulations and often add their own rules on top of that.

This brings us to the inevitable question: Why do we make so little use of knowledge and its application?

Is IT to blame?

It’s tempting to blame IT, and partly, that’s justified. IT professionals initially automated routine tasks and activities, which worked well with the available technology. Almost all valuable information has been digitized. Now, we’re automating more knowledge-intensive tasks and activities, and that’s where things go wrong.

Knowledge-intensive tasks are often complex, involving many variations, combinations, and decision points, and are subject to frequent changes. Take the automation at the tax authorities, for instance. New tasks lead to new processes, system adjustments, and new systems. Known rules, such as the definition of "liable employer" suddenly mean something else in a different domain. And to make matters worse, the rules these systems must follow can be changed at any moment by the legislature. Traditional IT approaches simply can’t keep up with this.

Causes of IT project failures

We argue that many large IT project failures, especially in government, are partly due to attempts to automate knowledge-intensive processes. The approaches and solutions used in the early days of our information society are simply inadequate for these more complex processes. Strikingly, this aspect is almost always overlooked in discussions on the topic.

For example, in the recent problems with the WIA (Work and Income Act) at the UWV (Employee Insurance Agency), the following was reported in Computable:

According to the UWV, legislative changes are the cause of the WIA debacle. "To handle these changes properly, we need very complex IT systems that must also be adapted quickly," said the organization in a written statement. "Everything that The Hague decides, we have to translate into IT changes," says the UWV spokesperson. One example mentioned is the political decision to increase the WIA benefit from 70% to 75%. "This leads to enormous changes in the system. As a result, many people may no longer qualify for various allowances."

This is a classic example of attempting to encode knowledge into software. When the rules suddenly changed, the UWV was in trouble.

For automating tasks in a complex and dynamic environment that is knowledge-intensive and subject to frequent changes, we need different solutions and approaches. IT will still play a role, but more as a tool to facilitate change, rather than a way to freeze the status quo in systems.

Do we realize that we’re living in a knowledge economy? If so, we clearly haven’t fully grasped its impact.

The battle for attention

From personal experience, we know that we have become increasingly critical of the quality of services provided to us. We’ve grown alongside the information society, becoming more vocal and demanding. We expect personalized information and services, at the moment we need them, in the format that suits us. We make providers compete for our time and attention. If we don’t quickly find the right product or answer, we simply move on to the next provider. The era of the empowered user has arrived, and the provider must follow suit.

Loss of control

This situation puts the provider in a tough spot. They need to retain their employees, as knowledge has become "mobile," walking out the door with the knowledge worker. Managers can no longer rely on the old command-and-control structures. Knowledge workers have become assertive and mobile, collaborating in teams with changing compositions. Naturally, they want to be well-supported in their work.

At the same time, providers must comply with more rules and conditions and be accountable for them, leading to the introduction of numerous internal procedures and agreements that, in turn, often demotivate employees. The same applies to their partners and customers.

The world around us is becoming more complex and changing faster. Providers increasingly feel like victims of these changes. They are losing control. Maintaining insight and oversight has become nearly a full-time job. Adapting to change has become reactive, rather than a deliberate proactive effort. This is disastrous for long-term competitiveness and innovation.

Are there solutions?

Yes, there certainly are solutions. However, they require us to look at our environment through a different lens—through the lens of knowledge. By doing so, we can identify those tasks, activities, and processes that are knowledge-intensive and where the knowledge itself often changes. These are where we should focus our attention and actions.

What should we aim to achieve?

Learning from Others

Let’s take a look at the automotive industry as an example. Initially, the production process was a series of sequential steps with many specialized functions. Everything was rigidly coded into rules, sometimes physically represented by molds or standard options, such as the available colors ("we offer all colors as long as they’re black").

The introduction of robots brought a fundamental change. A robot can be used at multiple points in the process and can perform several functions (e.g., assembly, painting, etc.). The rules can be adjusted relatively easily. Variants, such as different wheels, upholstery, and even different car brands and types, can be handled simultaneously according to the planning and customer preferences. The customer has increasingly become part of the process, able to configure their own model and have it custom-made.

Rule management

What we see in this example is a balance between standardization and customization and the decoupling of processes, functions, and content (rules). Now, let’s translate this to knowledge-intensive applications. What happens when we extract the key rules governing a process? Take the process of issuing permits, for example. Everything in that process revolves around rules: what requires a permit, how the application should be made, how it’s assessed, how decisions are communicated, and how control is exercised.

If we manage these rules separately, what remains is a simple process consisting of a few steps: receive → gather information → assess → decide → announce → issue. This process is unlikely to change often. What does change frequently are the rules. Therefore, we need an environment where these rules can be managed and controlled, where we can adjust them and know the impact of those changes. These changes should be made by the knowledge owners themselves.

You might say, "That’s fine, but how do I know when a rule needs to change, and how do I apply it to my service?" The answer to the first question is obvious: a rule changes when the law changes or when the organization decides to alter it. It’s wise to establish a link between the source of the change and the implemented changes, so you can always trace which decision led to a particular adjustment and know what will be affected if another change occurs. However, applying rules in processes is a more complicated matter.

Context of the user

Earlier, we complained about poor service delivery. There is a gap between what the provider delivers and what we, as customers, expect. It boils down to the fact that we expect a provider to offer services in terms we understand, and tailored to our specific situation and needs.

For example, we don’t want to be bombarded with difficult legal or business jargon. It’s fine if the provider uses that jargon within their domain, but in their communication with us, it should be translated into understandable terms. If we’re proud new parents, we expect to receive insurance products suitable for a family with a baby and not be bothered with irrelevant offers. The same applies to the permit example: based on our postal code, the municipality should be able to tell us which regulations apply to our building if we want to renovate. We don't need to see the rules that don’t apply to us.

The conclusion is clear: providers must expand their rule domain with the context of the user. They need to be able to bridge the gap between the rules governing their services and the rules that describe the customer’s situation.

How do you achieve this in a way that is practical, without creating unnecessary overhead or adding dependency on the IT organization? This can be done by using what is called ‘semantic technology’. Due to the focus on Web 2.0 in the literature, many people are unaware of the possibilities that already exist thanks to semantic technology. Beneath the surface, this Web 3.0 wave is growing in power and volume. The Semantic Wave report by Mills Davis (http://www.project10x.com/) provides striking examples of this.

Standardization of functions

It sounds tempting, right? Simple processes that change little and control over the rules that make things difficult for us, as well as control over the customer's context. But how do you apply those rules in a process? After all, that’s what it’s all about in the end, isn’t it?

Indeed, and that brings us to the second gap in companies’ and organizations’ knowledge infrastructure. It’s not enough to just describe the customer’s situation and your own rules.

Let’s return to our automotive industry example, where functions were also separated. But what are the functions in a process where knowledge is applied? Essentially, these are the activities you perform to make a choice or decision. So, comparing two products, choosing between different options, calculating something, checking whether all necessary steps have been completed, determining to which category something belongs, filling out a form, scheduling an activity, etc.

Does it strike you that these are all standard functions that can be applied to many different processes? Whether it’s about applying for and granting a permit in government or offering and buying insurance, these activities are universal.

Instrumentalizing knowledge

The last link we need is the development of standard tools for these functions. For example, a decision tree tool for choosing between options, or a dynamic form that only asks for what is necessary based on rules and pre-fills information already known. Naturally, this should be connected to administrative systems, so we’re no longer burdened with providing data the provider already has.

Advantages

Both you and I, as customers, can use these tools to decide whether to submit an application or order a product. Employees of the provider can also use the tools to perform their tasks. This means that new employees can be deployed more quickly, and existing employees can handle a wider variety of tasks. Since we, as customers, have already made many decisions ourselves, the entire process will proceed more quickly. Everyone benefits from this. Moreover, the choices we all make are based on the same rules, giving the provider the opportunity to demonstrate afterward which rule was used to make a decision. This allows for accountability.

A toolkit for applying knowledge

Given all these advantages, doesn’t this mean that, in a knowledge economy, we should not only divide and manage our rules into components but also the functions, supporting tools, and processes? This would give us a kind of toolkit, enabling us to create new combinations at any time. That offers interesting possibilities for managing and applying knowledge.

Technically, all of this is already possible. There is even a Dutch company called ‘Be Informed’ (www.beinformed.nl) that successfully offers such a toolkit. Major IT service providers, such as Ordina and Accenture, are already using it in their projects.

Do we really want it?

The crucial question is whether we’re ready to accept that we live in a knowledge economy and that we must start looking at our environment through the knowledge lens. Only when I no longer have to be frustrated when selecting a product, calling a helpdesk, or applying for a permit will I know that we’re truly on the right path.

 

Thei Geurts

This article was written in a personal capacity

Systems of denial in policy making

The concept of systems of denial was introduced in a paper by Andrew Hill and Stephen Gerras about strategic resistance to military innovation. They explored how successful organizations focus organizational energy and attention on refining their dominant theories of competition, often resulting in dysfunctional organizational responses, or systems of denial, to strategic anomalies - inconvenient information - that contradict assumptions.

The behavior patterns of these systems apply not only to successful armies, but also to e.g. IT-departments, businesses and the public sector.

Managing Model-Driven Applications

When implementing a new business application, most organizations feel they need to choose between “build” versus “buy”. Building your own application means everything is possible, but building complex applications is a risky venture. Buying a standard application provides all the advantages of pre-configuration, but has limited flexibility. Although most organizations prefer standard applications, they end up adapting them, leading to high cost of ownership, and long change cycles.

However, a third approach has emerged, reconciling the differences between build and buy. Model-driven applications come with an out-of-the-box configuration, as would be expected of a packaged business application, yet it can be adapted without development effort.

Moving from the vicious to the virtuous spiral

Many commercial and public organizations are caught in a negative bureaucracy spiral. They have numerous points of interpretation, decision making, transfer, translation and evaluation in which the meaning of regulatory and business requirements is lost or becomes eroded. Dependencies are overlooked and anomalies surfaced only after high-risk decisions have been taken. The result is a vicious spiral of frustration and demotivation, stakeholder irritation and considerable financial loss.

Documentation 3.0

Instruction manuals, users guides, and other types of documentation have always been the way manufacturers distributed the how-to information about their products to customers, as well as sales and support staff and other employees.  This kind of catch-all, one-size document forces every user to sift through irrelevant information, applying their own context to find solutions to their problems. Even when they are successful, users remember the experience as painful and tedious.