Facilitating knowledge flow through the enterprise

Facilitating KnowledgeFlow through theEnterpriseJeanette Bruno*General Electric Global Research Center, Schenectady, New York

ABSTRACT This paper is concerned with the issues we encountered when attempting toachieve enterprise level knowledge reuse. We present three pilot studies where newvisualization techniques were used to allow manufacturing and service operationstake advantage of engineering knowledge embodied in 3D models. Though allthese studies showed dramatic productivity increases, only one business unitfrom the studies is currently working to achieve the reuse. There are a numberof reasons why this is so, but the key underlying theme is a lack of enterpriselevel commitment to knowledge sharing and a lack of an adequate knowledgearchitecture for sharing knowledge across organizational boundaries. We concludewith an approach for facilitating knowledge flow across functional units. Copyright 2002 John Wiley & Sons, Ltd.

OVERVIEW

Our motivation is to promote efficiencies inan enterprise through knowledge reuse. Sinceknowledge (hopefully) is the crux for mostdecision-making processes within an enterprise,we assume that increasing the reuse of existingknowledge will:

• Help to make business operations across anenterprise more consistent and better alignedwith each other and

• Increase opportunities for optimizing the oper-ations across the enterprise.

The following pages present three case studiesinvolving proposals for knowledge reuse. Foreach case we discuss how organizational bound-aries played a major factor in inhibiting the reuse.We conclude with a proposal on how to overcomethe organizational boundaries.

* Correspondence to: Jeanette Bruno, GE Global Re-search Center, Building K1/5C17, P.O. Box 8, Schenec-tady, NY 12301.

THE KNOWLEDGE DOMAIN

Three-dimensional modeling is common in prod-uct design operations. These models also pro-vide a wealth of knowledge that need to flowout of design engineering and into the man-ufacturing, service and sales arena (and backto design engineering). This paper describesthree instances of where the 3D model visu-alizations were taken beyond the engineeringdesign organization; into manufacturing and ser-vice settings. It describes how the extended usesof the 3D models were unanimously acclaimed,but basic shortcomings in the implementationof the 3D model knowledge prohibited real-izing these extended uses in the day-to-dayoperations.

THE CASE STUDIES

Visual Assembly Instructions in Test BuildArea

This case study involved the reuse of assem-bly sequence information generated by design

Copyright 2002 John Wiley & Sons, Ltd.

International Journal of Intelligent Systems in Accounting, Finance & Management

Published online in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/isaf.210

Int. J. Intell. Sys. Acc. Fin. Mgmt. 11, 1–8 (2002)

engineers. During the design cycle, the designengineers would develop assembly sequences,describing how to put together major assembliesof the product. These sequences were used togenerate animations that the design engineersused to verify that the components in the designcould be assembled and to optimize the assemblyoperations.

Historically the assembly knowledge waspassed along as follows: a summary of theassembly sequence would have been sent todrafting and the drafting organization wouldhave produced detailed drawings indicating howto assemble the components. These instructionswould then be passed on to the developmentassembly area where the test versions wouldbe built and the assembly instructions verified.Business pressures to reduce design cycle timeshad changed the operations so that the develop-ment assembly area no longer waited for draftingto produce the assembly instructions. Instead,design engineers were sent directly to the devel-opment assembly floor to oversee the assemblyoperations for the test versions of the prod-uct (while drafting was producing the assemblyinstructions).

In our case study, we replaced the designengineers on the assembly floor with printedsnapshots of the assembly animation from a 3Dvisualization tool. The design engineers wereavailable if the assemblers had questions, butthey did not stay on the assembly floor. (Sincethe development assembly floor did not havePC’s, they could not use the 3D visualizationtool directly.) The assembly operation was ableto proceed smoothly with the printouts and thedesign engineers estimated that this reuse of theassembly visualization eliminated the need forthem to spend a week on the assembly floor

for each test product (out of a 2-month designcycle).

Visual Assembly Instructions for OverhaulOperations

In 1999, a GE overhaul shop ran a pilot studysimilar to the first one. We augmented text-basedrepair instructions with visualizations generatedfrom 3D models. This study primarily focused onthe cost–benefit of using visual-based assemblyinstructions over text-based instructions. For thestudy we chose two assembly jobs on alikeproduct assemblies. With the first assemblyoperation the shop provided a mechanic who wasalready familiar with the re-assembly proceduresfor the chosen component and we tracked thetime/effort it took to put the assembly together.For the second operation the shop provided aseasoned mechanic (one who had been workingin the overhaul shop for three years), but whohad never done a reassembly on the chosencomponent. This mechanic was given the usualpaper-based instructions, but was also providedwith a PC on the shopfloor and software thatdisplayed animations of each assembly step, pluslinks to the text description of each step. Weallowed the mechanic to use the PC for the firsttwo thirds of the assembly operation, then tookthe PC away, forcing him to use the paper basedinstructions. Again we tracked the time/effort ittook to assemble the second assembly. The resultsare shown in Table 1.

It should be noted that for the pilot, thevisual assembly instructions were generatedfrom a semi-automated process that derived theassembly sequence from the existing text-basedrepair instructions. The process to extract thesequence from the text instructions took 1 weekto develop and could be immediately applied to

Table 1.

Time for firsttwo thirds ofthe assembly

Time for lastthirds of theassembly

Cycle

1st job: Seasoned mechanic 44.4 (h) 12.4 (h) 7 days2nd job: New mechanic 32.3 31.1 5 days

27% improvement 150% loss

Copyright 2002 John Wiley & Sons, Ltd. Int. J. Intell. Sys. Acc. Fin. Mgmt. 11, 1–8 (2002)

2 J. BRUNO

the business’s other overhaul repair instructions(tight regulations on the documentation formatshave resulted in a repetitive format for theoverhaul instructions). ‘Hand tweaking’ wasrequired to do a final clean-up of the extractedsequence, but this effort was comparable to the‘hand tweaking’ that was regularly applied to thetext-based repair instructions for each assemblyjob (less than 2 days’ effort).

Visual Assembly Instructions forManufacturing

In this study we compared the cost of producingtraditional assembly instructions in a 2D draft-ing operation with producing visual assemblyinstructions via a 3D model-based animation.Some of the details of the assembly are listedbelow:

• The assembly operation for the pilot involvedaround 360 steps.

• The assembly of multiple alike parts wereconsidered one step unless special instructionswere needed for particular instances (such asa torquing sequence for four bolts—then thiswould be visualized as four steps).

• The visual assembly instruction displayedsummary text at each step highlighting tooling,safety issues, torques, lubricants, or miscella-neous comments for the step.

• The assembly floor where the new instructionswere being used was already fitted with a PCcapable of displaying the visual instructions.

The drafting operation took a little over 30person days (with a seasoned draftsman) toproduct the 2D-based instructions. (After thesequence had already been fixed.) The visualinstructions took 8 hours to produce includingtranscription of the summary instructions.

The Non-quantified Benefits

Besides the labor savings described above allthree organizations agreed that this new use ofthe knowledge should also yield the followingnon-quantified benefits:

• Improved service/manufacturing quality—thereadily available visual instructions with keysummary information would be looked at more

often. This would result in the instructionsbeing followed more accurately and produce ahigher-quality product.

• Training—In the second pilot it was evidentthat the mechanic that was new to the assemblyarea received on-the-job training via the visualinstructions. Though we did not specificallygo after benchmarking training operations, wefeel that this also would be a natural use of thisknowledge.

• Improved design opportunities—In each casethe operations groups ‘tweaked’ the sequencesthat had been generated by the design groups.The visualization presentation mechanismallowed the design engineers to understandthe requirements, limitations, and optimalworking conditions for the downstream man-ufacturing and servicing organizations morequickly and effectively. This better under-standing (knowledge) should help the designengineers generate better designs.

PILOT RESULTS

So all three pilots were a resounding success. Thenumbers showed that impressive productivitygains could be made with the use of thevisualization tools. Also the personnel whoparticipated in the pilots all clamored to havethe tools rolled out into day-to-day operation.Yet 2 years later, only one of these businessgroups is still actively pursuing putting 3Dvisualization-based instructions on their shopfloor. The following paragraphs describe why.

A common theme across the pilots was thereuse of the 3D models and assembly informationbeyond the originators of this knowledge. Inall three cases we were attempting to pushthis knowledge, which had been created withindesign engineering organizations, out into themanufacturing, and service organizations. Ourgoal was to quantify the productivity gains thatcould be achieved with the extended use of the3D model knowledge, and help the businessesdeploy the use of this knowledge in the newarenas. We were successful in demonstrating theproductivity gains, but not in extending the useof the 3D model knowledge outside of designengineering. The major factor in our lack of


FACILITATING KNOWLEDGE FLOW THROUGH THE ENTERPRISE 3

success was our inability to broach organizationalboundaries.

In order to realize the reuse of the knowledgewe were targeting, the new user organizationsneeded two new features in this knowledge:

(1) Assembly representations of the products—containing not only the geometry of theindividual parts, but also information on howthey fit together and

(2) The ability to track product configurations atthe unit level—keep track of each product,the manufactured and service configurationas well as the designed configuration (inthis paper, referred to a product unit levelconfigurations).

In order to meet this pair of needs, the businesseshad to modify their operations in the followingmanner:

(1) Extend their repositories to be able to main-tain product unit level configurations

(2) Modify business practices to ensure thatassembly representations were built and

(3) Modify their product unit level tracking tofeed maintenance and service changes backinto the repository.

No Repository Extensions for Product UnitLevel Configurations

At the very beginning of the project we knew thatthis requirement would bubble to the top, but wedecided to continue on with the project becausewe considered this to be a significant but notinsurmountable technical challenge. We thoughtthat the key issues were primarily in the area ofdisk space usage, and the completeness of thedata structures. We were not overly concernedabout these issues, since our experts in this areaassured us that a great deal of prior work has beendone in this area and many data models existedto support the configuration management data.With the data models and APIs well defined, wethought that extending the existing repositories tosupport this information would be a manageableeffort.

What we didn’t foresee were the business pro-cess problems we would face when attempting toget the newer repository designs implemented.

The engineering operations were extremely reluc-tant to entertain any thought of ‘extensions’ orother modifications to the repositories. The IToperations were such that the knowledge creators(the design engineers) were supported by an engi-neering IT organization while the proposed newdownstream users were supported by differentIT organizations (manufacturing and service ITorganizations). The existing repository was underthe auspices of the IT engineering organization.These organizations were already stretched thinand did not have the resources to implementthe changes, especially since it involved addingfunctionality their users didn’t need. The alterna-tive would have been to have the downstream ITorganizations implement the modifications, butsince they had no expertise in the existing repos-itory structure, this would greatly increase thecost and risk of making the modifications.

No Guarantee of Assembly Information

The missing assembly information also provedto be a larger problem than anticipated for theservice operation. The service operation wasprimarily focused on older product models thatdid not have the assembly geometry alreadycaptured. Design engineering had just startedgenerating the assembly information a few yearsearlier, but this information was only availablefor the newer models. Again this was a casewhere it appeared it would be cost effective togenerate this information, yet it was not done.The experts who would be most effective in fillingthe knowledge gap (the design engineers) werealready stretched thin, and there was no incentiveto put another organization’s needs above theirown operation’s needs. Again the group thathad the motivation to use the knowledge, didnot have the expertise to generate it. It wasdecided that the service operations could use theircurrent instructional material until the newerproducts reached their servicing age. At thatpoint the business would revisit using assemblyinstructions based on the 3D models.

No Tie between Product Lifecycle Trackingand Visual Knowledge

Given the lack of a repository to support productunit level information, we did not even approach


4 J. BRUNO

the subject of associating the lifecycle knowl-edge of each product to the corresponding 3Dmodeling knowledge. Going into the project wedid verify that the lifecycle information is beingmaintained by each of the businesses. Typically,the businesses were using relational databasesto maintain the product unit level configurationsinformation, but this information had not beenintegrated with the model repositories. (Whichmade sense since the repositories didn’t supportthis information.) Given the fact that the reposito-ries were not going to be able to maintain productunit level configurations, this issue became a mutepoint.

CROSS-ENTERPRISE KNOWLEDGE REUSE

True proliferation of knowledge throughout anenterprise requires a commitment to enterprisecoordination. Metrics are needed to promote thiscoordination. Current practices are to engineerknowledge repositories for the initial consumer.The typical thought is, that if the extended useof a piece of knowledge is worthy enough, thenew consumer of this knowledge will cover thecost of extending the engineering. The problemwith this reasoning is that the engineering of theinitial implementation will greatly affect the costof extending it.

Nowadays, every knowledge engineeringeffort should be adopting modular design prac-tices and using design concepts that are standardto their industry. This is easily said and sel-dom seen. For example, global product, part andcustomer numbering schemes should be usedthroughout an organization. Different depart-ments should not have their own customer num-bers or part numbering schemes. This has beenunderstood for a long time now, yet we still seemarketing, sales service, design, manufacturing,and sourcing departments using their own partand customer numbering schemes.

Before a business can start to benefit from theproliferation of the use of its knowledge it mustassess the current state of its knowledge, iden-tify opportunities for reuse and develop a planto achieve the reuse. Today we are only see-ing the tip of the iceberg. Businesses need to

establish development practices (both IT devel-opment and business process development) thatfoster knowledge proliferation. The followingparagraphs outline four steps that can be usedto adopt these practices.

Step 1. Enterprise Knowledge Council

The first step is to form an enterprise knowl-edge engineering council. This council would beresponsible for directing how the enterprise man-ages its shared knowledge. Individual members ofthe council would represent different functionalorganizations across the enterprise. Each mem-ber would be responsible for understanding itsorganization’s knowledge needs and the overlapswith the other organizations. The council mem-bers must have a thorough understanding of thebusiness and IT processes that support their orga-nizations, and must understand (or be able to findout quickly) about the limitations inherent in theexisting processes.

In the cases where a functional organization issupported by very complex IT systems, it may beadvisable to have both an IT and business processcouncil member representing the organization.

The objective of the enterprise knowledgecouncil is to maintain a roadmap for optimizingthe reuse of the enterprise’s knowledge and helpthe enterprise stay on the roadmap.

Step 2. Knowledge Needs Inventory

The next step is to recognize what knowledgeis needed for each functional organization andassess how well these needs are being met andthe cost/benefit impact of meeting/not meetingeach need. These needs should be characterizedin terms of the following:

• The business process it supports,• the cost/benefit of meeting or not meeting the

need and• the information (data) and processing that is

currently in place to support the need and thesource of this information and/or processing.

A good starting point for organizing the inven-tory is the American Productivity and QualityCenter (APQC) Process Classification Framework



(PCF). The PCF provides a good checklist of busi-ness processes. It would be natural to organize theknowledge needs inventory based on the businessprocesses with the need.

Up to this point we have been purposefullyvague on the definition of knowledge. In orderto take the inventory, we will have to think ofknowledge as units of something that can betallied, tracked, etc. Our objective is to help peopledo their jobs better by optimizing the use/reuseof the enterprise’s ‘decision making processes’.As such we need to know what ‘in the decisionmaking processes’ is available for use/reuse.Given this viewpoint, we consider a ‘piece’ ofknowledge to be a group of information (data)and related processes that deliver a message thathelps the recipient of the message take action(make a decision). Note, the inventory is notan inventory of existing digitized knowledgeprocesses, instead it is an inventory of the needfor knowledge. This inventory should includea characterization of what is needed, and howthat need is being met today. As each entryis being added to the inventory, we need tocharacterize it in terms of who/what is usingthe knowledge, who/what is producing the rawinformation (data) that goes into generating theknowledge, and what processing is involved.

It is very important to keep in mind the bigpicture: ‘maintaining a roadmap for optimizingthe reuse of the enterprise’s knowledge and helpthe enterprise stay on the roadmap’. Each coun-cil member will be responsible for deciding onthe granularity of the ‘pieces of knowledge’ theyrepresent. We want to maximize the granularityof the knowledge to prevent becoming over-whelmed by the amount of knowledge beingmanaged. On the other hand, if the granules aretoo large we will miss opportunities for reuseby hiding reusable ‘pieces of knowledge’ in largebundles.

Step 3. Developing the Roadmap

Once they are armed with their respectiveknowledge needs inventory, the council mem-bers can convene working sessions to build aplan/roadmap for optimizing the use/reuse ofthe enterprises’ knowledge. In these working ses-sions the council members need only concentrate

on those needs that represent a large cost/benefitand cross multiple council member domains (typ-ically those needs who’s source of informationand/or processing occur outside the functionalorganization owning the need).

For each such need, the council membersinvolved need to identify inefficiencies or missedprofit opportunities in regards to the existing pro-cess and determine (via a cost/benefit analysis)how to address the inefficiencies or missed profitopportunities and in what order. This analysismust factor in what is to be gained by addressingthe need, the cost of addressing the need, thetimeliness of the payoff and the availability ofresources to address the need.

The knowledge processes that are chosen forcross enterprise deployment will have resourcesassigned to it that are specifically tasked withenabling the cross enterprise deployment. In themeantime, it is important that each council mem-ber also encourage the organization it representsto actively embrace modular design techniquesas they move forward on knowledge processeswithin their organization. This will reduce thecost of realizing the next round of cross enter-prise knowledge deployment. Toward this endwe have developed a model for describing thematurity of a knowledge process from a reusabil-ity point of view. Bruno describes this maturitymodel and how to apply it.

Step 4. Staying on the Roadmap

Staying on the roadmap may be the hardest partof all. We particularly want to stress that this willbe a moving roadmap. The council cannot expectto develop a complete and comprehensive planand then spend a couple of years implementingit. This is not feasible, especially in todays’s e-speed world. Instead the council must make aplan for addressing the most immediate needsand regularly re-evaluate the roadmap in terms ofthe outstanding or new needs.

Case Studies Revisited

So now we revisit our case studies and projecthow the four-step process described above shouldhave been applied to these cases. Note, sincethe first two pilots both occurred in the same


6 J. BRUNO

business, a single projection of how that businesscould have followed the four-step process willcover both pilots.

Test Build and Overhaul OperationsStep 1—form the Enterprise Knowledge Engi-neering Council.

• Many of the engineering design IT staff wereonce design engineers. Since these peopletended to have an in depth understanding ofboth the design engineers requirements andthe system implementation details the councilrepresentative for design engineering wouldhave come from the engineering design IT staff.

• In development engineering there was moredistance between the users and the IT staff.There was not a dedicated IT staff for thedevelopment engineers, their IT staff also sup-ported other organizations. As a result, thecouncil would need two members to representthis functional organization: a developmentengineer to cover the users needs and an ITrepresentative to understand the IT opportuni-ties/limitations.

• The service operations were in the samesituation as development engineering. One rep-resentative would be needed for their under-standing of the service needs and a secondrepresentative for the IT side. IT turned out thatin this situation, the development engineeringand the service operations could probably berepresented by the same IT representative.

Step 2—build the knowledge needs inventoryIn this case the service and development engi-neering council representatives would each havehad ‘maintaining and presenting 3D model baseassembly sequence instructions’ as one of theiruser needs. They would have had projected costreduction figures from the pilot study and basedon our discussions with these organizations, webelieve that these needs would have been rankedhigh within each organization.

Step 3—develop the roadmapIn the council working sessions involving mem-bers from the design engineering, developmentengineering and services, these members wouldhave seen the overlap in 3D modeling needs. Anenterprise oriented cost benefit analysis would

have allowed the council to determine the truevalue of making this knowledge available outsidethe design engineering community. As a result, amore informed decision would have been maderegarding the need to modify the data structureto support the additional users.

Step 4—maintain the roadmapAssuming the decision was to extend thedata structure to support the additional users,this activity would have been scheduled andacted upon.(Note: This business did have something akin tothe Enterprise Knowledge Engineering Councilbut it missed this opportunity because they werelimiting their focus to legacy mainframe systemsand they did not include the needs of the overhauloperations.)

Manufacturing InstructionsThis business also came close to having some-thing like the Enterprise Knowledge EngineeringCouncil in place. It did have a technology offi-cer who recognized the benefits to be gained bysharing the knowledge, and sharing of the knowl-edge was attempted, but some of the key CTQ’sof the downstream users were not captured thusmaking the ‘enterprise’ solution unusable for thedownstream users.

This underscores the importance of having acouncil rather than a single person. One personcan have a global view of the enterprise’s needs,but cannot be expected to be familiar with thedetailed requirements for all the opportunities.With a council, however, the details are sharedand maintained by those who are most familiarwith them.

A technology officer would be useful asa facilitator/spokesperson for the council, butshould not be responsible for understandingall the detailed requirements of the enterprise.For each reuse opportunity, the key piecesof information this facilitator would need totrack are:

• What is the projected additional profits/costsavings/benefits from the reuse (after factoringin the cost of achieving it).

• What functional groups would benefit fromreusing the knowledge (at the design level thatwas used to compute the cost).



• Is the reuse in place, scheduled, or still on thetable.

CONCLUSIONS

Cross-enterprise knowledge reuse is a communi-cation and business process optimization prob-lem. Realizing the reuse can yield very largepayoffs, but require a level of coordination andfocus that most businesses have not yet attained.There needs to be two environmental factors inexistence to achieve these payoffs:

• A cross-enterprise organizational structure (theknowledge engineering council) tasked withinvestigating and quantifying the opportuni-ties for reuse, and

• A high-level focus on achieving the payoffs.This translates into upper level managementspecifically tracking how the enterprise is doingin terms of reusing its knowledge:– tracking where the large payoff reuse

opportunities are and– tracking how well the enterprise is taking

advantage of these opportunities.

It is important to remember that the focus ofthe knowledge engineering council should be

on the knowledge interchange points betweenfunctional organizations (how and when knowl-edge/information needs to flow from one func-tional organization to another). The individualfunctional organizations should be responsiblefor maintaining their knowledge, but need tofactor the requirements of the other user organi-zations into their solutions.

ACKNOWLEDGMENTS

I would like to acknowledge the other teammembers who contributed to the pilot efforts.Russell Blue, Charles Law, Ann Kelly, SteveLinthicum, Peter Meenan and George Ryon allworked tirelessly to get the hardware and 3Dvisualization tools up and running at the sites.

References

APQC Process Classification Framework. http://www.apqc.org/free/framework.cfm (pdf version: http://www.apqc.org/free/Framewrk.pdf).

Bruno, J. A Knowledge Management Maturity Model,Corporate Research and Development. GECRDInternal Report.


8 J. BRUNO

Facilitating knowledge flow through the enterprise

Documents

Transcript of Facilitating knowledge flow through the enterprise