How "KM technology Push" failed at Engico

Implementing technology alone is often a reason for KM failure, and here’s a prime example.

Grochim [CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0)],  from Wikimedia Commons

One of the early successes of Knowledge Management was the Ford “best practice replication” system, known as BPR – a system for identifying, sharing and re-using process enhancements in manufacturing plants, driven by relentless cost cutting and supported by roles, processes, technology and governance.

BPR was such a simple idea, and Ford licences the software to other companies, so why should it not work everywhere?  And yet it didn’t work everywhere.

To balance the success story, here is an interesting case study by Andreas Diedrich of how BPR completely failed at a large Scandinavian engineering company, and how that failure persevered for 4 years. For me the most interesting sentences in the whole article are as follows:

“Under certain circumstances, failure can reinforce belief; one merely needs a good reason to explain the failure”, and 

“The (ideological) belief in the goodness of automation and technology is one of the main reasons why permanently failing projects are nevertheless allowed to continue”.

Here’s what happened.

• In 1999, Engico read about BPR and said “we want that.” BPR was seen as addressing varius problems related to silo working and resolution of common problems

• They attempted to licence the Ford BPR system. 

• Negotiations failed and they decided to build their own system

• The new system was launched, on a new platform rather than the existing Lotus Note platform, and supported by plans for communities of practice.

• For the innovators, the launch was almost ideological. “For them the “idea of BPT as such” was so powerful, so positive and so strong, that they fully believed “soon, everybody will be using the BPT process because it is so clearly the right thing to do”. Now, all that needed to be done was to launch the process”.

• The engineers in the factories were not interested in voluntarily submitting best practices. “Their focus  lies firmly with their own organization…their own work with improvement. And they have their network, and they have their meetings via telephone…and they meet once or twice a year in this network. And they are probably satisfied”

• A German factory submitted several best practices, and then waited to see if others joined in. When they didn’t, the German factory refused to submit any more. “Why should I waste my time on distributing my stuff, if I don’t get anything in return? Show me first of all that the others are submitting something.”

• The users blamed several things – they lack of involvement in the design process, the difficulty of assigning value to practice improvements, and problems with the IT (which was unfamiliar, hard to use, and ran into connectivity and network problems).

• So the innovators decided to fix the technology, and in 2001 removed the IT tool for rework. At the same time the underlying IT platform was being revised.

• By 2002 there was a new version, but this had become more complex, and still did not work.

• Work continued. Deadlines slipped.

• “After struggling for nearly three years to get the BPT process underway by attempting to convince the process development managers out in the divisions to establish new communities, by obtaining a commitment from managers who had already established communities, by solving the technical difficulties, and by persuading the members of the existing communities to describe and submit their best practices through the system, to no avail, the innovators acknowledged … that the BPT project was a failure”.

• The dream of building the perfect machine remained just that: a dream. After almost four years the project was eventually “put on ice” for good in September 2003.