Mini Case 1 - The evolution of KM at Ford Motor Company

In 1995 Ford initiated a scheme to make it easier for its dipsersed factories and divisions to communicate and replicate best practices. Stan Kwiecien in collaboration with Bob Kramek Steve Aiello Manjula Moola and Sanjay Swarup explains how the project unfolded to eventually present Ford with a ‘best in class’ knowledge management system.

At Ford we have always had a natural tendency to share among our co-workers. This is especially important in the gruelling world of manufacturing where a constant pressure exists to provide the best quality with the most efficiency in the safest manner possible. Talking with like-minded colleagues about common problems uncovers the inevitable realisation that someone somewhere has solved a similar issue or concern. People who perform similar tasks want to share what they know and want to know what others know. This is the premise of a successful knowledge management tool as developed and used by Ford Motor Company; we call it Best Practice Replication.

It began in a formalised manner in 1995 as Ford began to consider itself a truly global corporation. One realisation made by executives who now had responsibility for global rather than regional manufacturing was that cultural and process differences did exist but it was not obvious which cultures or processes were ‘best’. Dale McKeehan who was at the time responsible for manufacturing in North America and Europe challenged his regional and plant managers to “figure out a way to learn from each other without having to travel all over the world”.

Escorts were built in both the US and Europe while the European Mondeo was called the Contour in the US. Initial benchmarking trips made by managers of ‘sister’ plants showed that there were significant design and assembly differences between the two – in fact the plants were more like cousins. It became evident that the benchmarking process should be directed to comparing productivity. The next trips were conducted between plants with high quality and productivity levels: Kansas City MO and Saarlouis Germany. The managers were accompanied by their production engineers and while the managers were establishing relationships to foster greater teamwork the engineers scoured the plant floor with the hope of uncovering the detailed differences between each location. The result of the visits was a list of 14 process improvements that Kansas City had discovered at Saarlouis and would take home to implement and 17 that Saarlouis would benefit from. When the results were presented to McKeehan his response was: “That’s nice but what are you going to do with these best practices? How am I going to know what their value is?”

The participants of the benchmarking trip began to document the findings of the 31 best practices that had been identified including a description of the process improvements key contacts if more information was required costs to implement and the value or benefit that could be expected by replication. These were in the form of Word documents with a photo of the process or tool pasted at the top. This practice description was called a ‘picture sheet’. A simple Excel spreadsheet also listed the 31 best practices with tracking of the projected implementation dates and the value the replicating site expected to achieve.

The picture sheets and matrix were shown at a meeting of the plant managers where many asked for copies of the picture sheets as most of these practices had relevance at their own plants. The managers also asked if they could add what they considered to be best practices as picture sheets. Now the logistical problems began. It fell upon a small group – operations support – to co-ordinate the compilation of the picture sheets. This included gathering the information obtaining photos and having them duplicated preparing the picture sheets pasting on the photos and mailing the sheets to more than 30 locations. In addition the matrix needed to be maintained which meant soliciting responses to the picture sheet mailings gathering the details entering the data and distributing the reports.

Within a few months the number of best practice picture sheets had grown to 133 and the number of locations participating had grown to 35. It became an administrative nightmare for a staff of three people working full time just to handle the information flow. And this was within only the final assembly group. The operations support manager determined that we either had to find another way or simply stop sharing best practices. The latter option was of course unacceptable.

At the time Ford was just beginning to build its intranet. To explore the possibilities this medium offered we visited the Ford web farm with a handcart loaded with five boxes of documents representing a quarter of what had been generated in the past six months. The discussion centred around the process being used to collect and communicate best practices the process used to solicit and capture feedback and the process used to generate meaningful reports. The manager of the Ford web was confident his team could help.

Given that a process had been well defined and that we had a format for the picture sheets and feedback matrices and reports the web developer went to work and within two weeks had developed what came to be the first web-based transactional database within Ford Motor Company. The simplicity of use was outstanding: the picture sheets appeared with the click of a button and the template used to develop the picture sheet was straightforward and easy to use – it took a mere two clicks to attach a picture that had been scanned in. Likewise the feedback form could be summoned with a single click; the user selected responses such as ‘under investigation’ ‘not applicable’ or ‘adopted’ and the projected implementation dates and expected values could be added into the appropriate boxes. And by simply clicking on the button labelled ‘reports’ all the information appeared clearly presented organised by location and grouped by regional manager. The application was called Best Practice Replication.

McKeehan was pleased; he saw a vision become reality. Now there was a process and a tool to quickly provide valuable knowledge of one location’s efficiency improvements to others around the world. This happened by February 1996. At the next plant manager’s meeting the web-based Best Practice Replication process was introduced. Some of the managers asked if they had to take part in the process. McKeehan’s response was: “No but you are fools if you don’t. And let me add some incentive: this year’s target to reduce operating costs will now be 6 per cent rather than 5 per cent.”

The technology now presented a new problem: we had a technical solution but the necessary infrastructure was not in place. The web required the use of higher capacity PCs and connections to the intranet. This lead to the development of a role within the process called ‘focal points’. Each focal point would be the representative of the best practice activity at each location and was scheduled to be one of the initial recipients of the PC upgrades and connection to the Ford intranet. By the end of the year most of the focal points for the Final Area in the manufacturing process had been upgraded and connected. The initial 131 were loaded in February and by year-end the Final Area had 398 best practices. The Body and Paint divisions also began to witness the power of the process and the web application. In the autumn of 1996 the application had been assigned a full-time web developer and the same infrastructure of focal points and administrators for best practices was in place. By the beginning of 1997 Body had collected 201 practices and Paint 50. The automated reports showed that significant value had been achieved through use of the replication process.

Encouraged by this success the remaining manufacturing areas abandoned their paper and PC file methods to collect and distribute best practices. This taxed the web application as seven additional groups were suddenly sharing the space. The web developer was kept busy creating the reporting formats and adding the new locations to the application tables and database. The initial application was designed and built to accommodate best practice replication without differentiating the users. A second web developer was added to support the growth. By late-1997 Final Area had added 260 practices Body had added 320 Paint had added 85 and the seven new members also began to grow. Central Engineering added 50 Stamping 40 and Material Handling a whopping 526. An additional burden was the inclusion of members from other divisions that had unique regional requirements. One of the developers was concentrating on supporting the growth while the other began to restructure the application to make maintenance less of an issue.

By the end of 1997 the ten manufacturing departments were collectively replicating 1 500 best practices. As the users employed the process and the tool they began to realise the potential that had not yet been tapped. They began to ask for enhancements such as more detailed reports and more flexibility in the metrics. These enhancements were subsequently addressed and the plants began to rely on the information collected in their quest to continuously improve quality and efficiency.

1998 saw an explosion of growth. The process was recognised by the product development department as a means to develop and collect best practices related to its remit. A community of ‘process ownership teams’ was formed. There were 15 process ownership teams that were charged with identifying the significant process steps at each phase of product development and each team was responsible for creating a robust process documenting and detailing the required steps and then making it available to the appropriate development engineers at the proper phase of the development cycle. The unique needs of this community required specialised changes to the web application. This created more work for the developers as there was not a great deal of ‘off-the-shelf’ code available that would satisfy the added requirements.

Among the unique features required was the need to identify the authorised users by department code rather than employee code. This was necessary because team members were seldom permanent which meant a great deal of added work for community administrators in granting and removing access rights. At the same time Ford was working towards implementing a single web log-in procedure. This meant that when a person logged in to the browser they no longer had to use remember or maintain user IDs and passwords for multiple applications. Ultimately the work of the process ownership teams resulted in the formation of some 750 robust processes in the development of a new product. As the development engineers used the processes they identified further improvements. The process changes were subsequently documented and the fresh process used for the next programme. These processes have become the foundation of the Ford product development system.

Back in the world of manufacturing the Final Area community that had instigated all this was finding it was beginning to plateau. Most of the assembly processes had some type of best practice associated with them which had in turn been replicated wherever possible. But there was a hunger for more.

A stringent benchmarking process was subsequently developed and piloted at six locations – three in Europe and three in the US. The Final Area build processes were lumped into 150 specific chunks relating to the vehicle components being assembled. For example the brake system was identified as having six specific major components: the brake tubes the front brakes the rear brakes the master cylinder the pedals and the parking brake. A time study methodology was used whereby each operator was observed and the estimated percentage of time spent for each work cycle was coded to fit one of the 150 ‘components’ or non-work time activities such as walking to obtain parts or putting refuse aside. This data was entered into an Excel spreadsheet along with the conveyor speed at the job being observed comments about the type of conveyor the tools used and other observations. The power of Excel pivot tables (once we understood them!) miraculously lumped all the data gathered at random and organised it allowing us to identify which product and which plant was the most efficient; we were thus able to establish benchmarks.

We were also faced with having more data than ever before and the quandary was what to do with it all. Technology was surely the answer. The best practice replication application needed major enhancements and the opportunities to improve upon the existing system were great. The input forms could be easily modified to accept a higher level of detail for example while a great deal of work was required to develop a more dynamic feedback system. There was also a need for detailed reports to track progress and trends. Undaunted the web developers took on the challenge and within a month had met the seemingly impossible requirements. The plants then went to work analysing the information about benchmarks and understanding their own processes and submitted their plans for improvements together with details of target dates savings and who was responsible.

Some of the benchmark processes were difficult to describe or even photograph. Requests were made for benchmark locations to videotape these processes and send a copy to those that asked. This opened a Pandora’s box with regards to the logistics of collecting copying and distributing potentially thousands of copies and was quickly identified as impractical. Again technology came to the rescue. Streaming video was a commercial novelty at the time and we quickly established a relationship with the industry leader in this field and worked out a simple and inexpensive solution whereby we could convert VHS or PAL tapes to the appropriate file type using proprietary software and a video capture card and stream the videos to the users on demand. The license agreement required the registration of each user and PC but this bit of administration was soon automated. Years later when other departments within Ford were exploring the broad use of streaming video many were surprised that our application was so far advanced.

It was now mid-1999 and we had pushed the application to the point where it was a miracle it even worked at all. The value being derived was significant enough that plans for a complete rebuild of the application to strengthen its base and add functionality to increase its simplicity and flexibility were immediately accepted. A team of six web developers worked six months to start again keeping all the functionality that users loved but replacing anything that had been unpopular. It was also an absolute requirement that any data collected over the years would fit seamlessly into the new application.

Safety has always been of utmost importance at Ford. The health protection services staff recognised that the Best Practice Replication process and tool could be used to communicate awareness of safety hazards and of potentially unsafe conditions. Even as the application was being revised a unique derivation was being developed that the prior version would not have been able to effectively support. Previously any significant accidents or near misses were communicated via e-mail and sent to central station to be forwarded to the appropriate health and safety engineers and management personnel. The revised process and application now enabled a safety engineer at a site to compose a preliminary incident report within the application. They are able to click specific data fields regarding the type of incident severity probable causes etc. Upon submission the application immediately transcribes the information into an e-mail note which is immediately sent to all safety engineers and managers around the globe. A permanent record is kept and data about the incident is captured. The safety engineers then monitor the incidents and conduct weekly reviews to determine if any require in-depth action. If so the original record is updated and a note is sent linking back to the original incident report and including the details of what actions are to be taken. When the revised application was launched in February 2000 it had all the desired features as well as the major benefit of adding communication and value to the most important aspect of our business: the safety of our people.

This use of technology enabled an unprecedented growth in the Best Practice Replication process. The number of communities grew rapidly from 15 to 45 (and counting). And by maximising the flexibility of the templates and reports quicker responses to the needs of existing communities that sort to evolve and to new communities that had diverse and specialised needs were possible.

The health and safety derivative was revised to accommodate the needs of the environmental engineers; marketing was able to use the functionality and process to share proven advertising and niche market successes; additional manufacturing communities are capitalising on the business plan format. Some practices are even being tagged as ‘standard’ meaning not if these successful process improvements will be replicated but when.

The potential is clearly endless and much of the process and supporting software code has been filed for patent. The success of well-defined processes enabled by the clever application of existing technology and the drive to develop new technical solutions has provided Ford Motor Company with a ‘best in class’ knowledge management solution. In closing it is clear that you must first have a great process and then support it with great code.

Stan Kwiecien is eBPR deployment manager and epistemologist at Ford Motor Company. He can be contacted at: skwiecie@ford.com