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.
I think we can see several reasons for failure here. 
  • The BPR approach did not help the workers by providing them with solutions, but added more burden. 
  • There was not urgent driver for KM as there was in Ford
  • The tool was rolled out as “the right thing to do” rather than a work aid. 
  • The tool was seen as the solution
  • The tool was too new – new platform, new technology, new processes. 
  • When the tool was not met with the correct behaviours, the solution was “change the tool” rather than change the behaviours (probably because changing the tool was seen as the easier thing to do, and because of the ideological belief described above).
  • Engico persevered with the tool for 4 years before giving up. The author describes this as “A Surviving Failure” (ie a failure that continues to survive) and sees the cause for this as the innovators’ strong belief in “the technologies inherent goodness”. He says

“The innovators were disappointed, but they did not give up. As is often the case in KM projects and innovation projects in general, they put the blame on the intended users and others who did not understand the tremendous benefits of using the new technology and/or technical problems. And when the technology resisted, when they encountered technical problems with the IT infrastructure – especially with the CoolSnake Intranet platform – the innovators argued that once the problems were solved, the BPT process would work, because the “idea of BPT as such was good” and in any case “had nothing to do with the IT system”. The BPT innovators were certain that once their machine worked, everybody would be convinced of its goodness. But, the machine did not work and therefore could not “convince anyone because of its good working order”.

This was a failure of change management, driven by the belief that the value of the technology was so evident, everyone would use it.  A case study of Technology Push.

View Original Source (nickmilton.com) Here.

Leave a Reply

Your email address will not be published. Required fields are marked *

Shared by: Nick Milton