Knowledge Management for Enterprise Integration Eric Rebentisch erebenti@mit.edu X8-7773 28 October 2002 An Objective Perspective on Knowledge Management The Typical Starting Point: Explicit vs. Tacit Knowledge ? Explicit Knowledge: ? Can be expressed in words and numbers ? Easily communicated and shared in hard form ? Examples: scientific formulas, market data, codified procedures ? Tacit Knowledge: ? Difficult to formalize ? Examples: scientific expertise, operational know-how, industry insights Three Essential Components of Knowledge Management ? Knowledge discovery and capture ? Knowledge organization ? Knowledge sharing Implementing Knowledge Management ? Business Intelligence – Processes used to enable improved decision making – Data mining and warehousing, advanced technologies that glean valuable insight from stored data ? Knowledge Discovery – Text mining techniques enable knowledge discovery from text sources ? Knowledge Mapping – Knowledge sources (people & information) are represented in a context defined by relationships ? Expertise Location – Finding, cataloging & making available the best expertise in the corporation when needed for business decision making Implementing Knowledge Management (cont.) ? Collaboration – Enables people to share information, expertise & insights – Amplification of tacit knowledge – Enhanced innovation & motivation ? Knowledge Transfer – Extends reach of available knowledge & skill transfer resources to remote locations – Enables virtual teams to perform at high-level organization standards, independently of the geographical location of the team members Blueprinting Knowledge within the Organization Inventory, Personnel, Payroll, Manufacturing, Assembly Inventory, Personnel, Payroll, Manufacturing, Assembly Marketing, Customer Service, Supplier Negotiations Marketing, Customer Service, Supplier Negotiations Research, Product Development, Problem Solving Research, Product Development, Problem Solving Strategic Management, Planning, EIS Strategic Management, Planning, EIS Structured Work ?Day-to-Day Efficiencies ?Lessons Learned ?Process-Specific Dynamic Work ?Information Exchange ?Collaborative Thought ?High Levels of Knowledge Capture & Creation Source: Ernst & Young LLP, Knowledge Based Businesses Typical Knowledge Management Initiatives Investments Organizational Technological Tacit Explicit Knowledge Capabilities Exploration Contactivity Connectivity ?Education & development ?Management process ?Measurement & protection ?Education & development ?Management process ?Measurement & protection ?Meeting spaces ?Events ?Communities ?Videoconferencing ?Intranets Source: Earl, Scott, Sloan Management Review, Winter 1999 A Common Definition of Knowledge ? No clear consensus despite long history of epistemology ? Knowledge comprises individual beliefs that: – Define cause and effect relationships – Enable value judgements – May also include learned or acquired skills Increasing ability to define value or relevance in context Wisdom Knowledge Information Based on common syntactical rules—explicit and accessible to many Based on deep understanding of underlying relationships— individually idiosyncratic and accessible to few A key challenge is characterizing knowledge outside the realm of practice Knowledge is Embedded in All Aspects of Organizational Activities ? Product Technology ? Process Technology ? Organizational structure and reporting relationships ? Group norms and values ? Informal information flows Knowledge is a By-product of Individual and Organizational Activity Enterprise Knowledge Evolves Over Time ? Knowledge in use evolves with changing activities and priorities ? Cyclical process that builds upon past experience, capabilities, and relationships – Enterprise may draw on internal or external sources as needed to satisfy requirements ? Experience, capabilities, and relationships are adapted as new requirements emerge – Dramatic changes (increased novelty) force equally significant changes in knowledge in use and relationships that link that knowledge together The Knowledge Transformation Cycle Transformation Retrieval Storage New circumstances or requirements Source: Carlile,PR, and Rebentisch, ES Management Science, forthcoming Knowledge Management in Complex Settings Forces Focus on Boundary- spanning and Integration ? Demands of system performance require multiple actors with specialized knowledge working in concert – Boundaries differentiate the actors but also potentially inhibit communication and collaboration ? Specialization of tasks means that no single actor has all the answers — forcing integration of activities and creating mutual dependence ? Over multiple cycles, relationships between specialized sources of knowledge are developed to improve process performance – System architectures – Learning curves ? Novelty from cycle to cycle potentially disrupts BOTH competence within areas of specialized knowledge and relationships between or across boundaries Scoping the Complexity of Knowledge Transfer #1 Transferring from expert to novice #2 Learning or Adaptation #3 Negotiating and transforming #4 Market Processes High Collaboration Low Low High Specialization From Presentation at CMU Knowledge Management Symposium by Carlile, and Rebentisch, Sept 2001 Characteristics of Boundary Objects and Boundary Infrastructures 1. Establishes some shared language/syntax of representing each other’s knowledge. 2. Provides individuals a concrete means of specifying their differences and dependencies. 3. Allows individuals to negotiate and transform their knowledge to collectively create new knowledge. 4. Supports an iterative approach where individuals get better at representing, specifying and transforming knowledge. Source: Carlile,PR, Organization Science 2001 Emerging Findings Around Adaptability in the Design Phase ? Effective System Representations (SR) enable adaptability by facilitating knowledge transfer between stakeholders – SR’s portray the evolving design and facilitate “what if” analyses – Stakeholders used SR’s to identify and evaluate adaptations ? SR effectiveness depends on fidelity, timing and usage – Fidelity: show system level detail & high interest aspects of design – Timing: provide insight while trade space is still open – Usage: in-depth SR interaction by knowledgeable stakeholders ? The user makes a valuable contribution to design by sharing operational considerations – often underutilized! – Timely feedback promotes improvements by helping designers understand how operators foresee using the system – Prioritizing needs allows bounding of overall scope to manage risk Source: Rob Dare forthcoming dissertation Concurrent Technology Transfer Another Strategy for Managing Knowledge Across Boundaries 0 10 20 30 40 50 Percent Reduction Eng. Hours Develop. Cost Lead Time No. of Prototypes Cusumano and Nobeoka, “Thinking Beyond Lean,” 1998 Evidence of Savings From Using Product Line Strategies Organizational Data A B C D Time Implementing PLE (years) 10+ 4 2 a 10 Market Share (%) 75 b 94 c 60 b 55 Overall Size (no. of people) d 5500 2000 1300 5000 Number of Platforms 5618 Number of Derivatives 12 9 e 024 PLE Ratio (Derivatives/Platforms) 2.4 1.5 0 3 PLE Cycle Time Ratio (Derivative Cycle Time/Platform Cycle Time) 0.25 0.5 0.35 f 0.24 ? Derivatives require between 1/2 and 1/4 the time to develop than the original platform ? Evidence that some firms were able to develop derivatives more successfully than others From Beckert, June 2000 Building PLE Capability Strategic Characteristics Political Characteristics Cultural Characteristics Political characteristics provide “traction” for the strategic direction within the organization Cultural characteristics inform and guide the behaviors that fulfill the strategic direction Strategic characteristics provide the foundation and operating context for successful PLE efforts Strategic Characteristics ? Goals and metrics: – Strategic plans clearly defined goals relating to the development of platforms and/or product lines – Metrics used that apply specifically to product line engineering ? Amount of technology sharing ? Extent to which a product meets established coherence requirements ? Number of derivative products a platform can generate ? Amount of unique part numbers – Organization-wide coherence requirements reinforce platform and product line strategy Strategic Characteristics, cont. ? Strategies: – Product line engineering strategies implemented uniformly across organization (e.g., “zero tolerance policy”) – Smallest percentage of projects use new design strategy – Over half of projects leveraged product development through concurrent technology transfer (a defined strategy for knowledge transfer from one project to another overlapping project) ? Resource and technology sharing: – Resources organized around platforms to dictate resource and technology sharing – Individuals designated to recognize and act upon opportunities for organizational sharing – Modular system architectures to facilitate sharing – Initiatives to standardize components and parts to increase technology sharing Political Characteristics ? Management and Stakeholders: – Senior management defines and enforces product line strategies (not a “grass roots” movement) – Supplier stakeholders have “buy-in” to platform strategy through risk-sharing partnerships – P&L responsibility at a level where decisions can be made at the portfolio level ? Responsibility and accountability: – Responsibility for maintaining platform and derivative alignment held at a high level in the organization – Change control boards comprising platform team members control platform architectures Cultural Characteristics ? Communication and training: – Communication modes defined specifically to convey product line engineering strategies – Communication modes designed to facilitate resource and technology sharing – New employee orientation covers general product standards and specific product lines of the organization Product Family Management Process Observations ? Senior management buy-in to phase gate process ? Continuous review of how projects line up against strategy ? Ensure new products fit within strategic plan ? Formal product development process defined ? Formal portfolio management processes in place Observations consistent with previous LAI research on managing the front end of product development Taking a Lifecycle View Requires Perspective Across Multiple Enterprises and Stakeholders Source: Murman et al., Lean Enterprise Value, Palgrave, 2002 Examples of Commonality in Lifecycle Operations ? Commercial Airline: – Main engine starter is common across 747-400, 767, and 767-300ER – 26 airports service these aircraft (11 common) – Airline only has to stock 14 spares, as opposed to 25 if they were not common ? PMA-276 – UH-1Y and AH-1Z deploy together on the same MEU, relying on the same mobility, maintenance, training, and sustainment infrastructure – 85% commonality between UH-1Y (utility) and AH-1Z (attack) reduces the detachment maintenance personnel requirement from between 4 and 14 people (3 to 12%) – Nearly $1.5 billion in savings from commonality over 20 year lifecycle of program Timeline of Commonality Benefits Illustrates Linkage to Multi-Stakeholder Enterprises 0I II III Reduced time for source selection Reduce training time Reduced support equipment Reduced training equipment Higher spares availability Reduced complexity in supply Reduced downtime Greater interoperability Faster solutions to problems Reduced rework Reduced testing Increased operator competency Design reuse Shared development costs Fewer maintenance hours Reduced DMS Reduced spares inventory Reduced tooling Process reuse Reduced documentation Lower risk Economies of scale Reduced inventory Higher reliability Reduced cycle time Higher productivity Research Finds Limited Evidence That Knowledge Sharing Infrastructure Exists in “Downstream” Product Lifecycle ? 5 Fleets of aircraft with ~decades legacy between EOM and user communities ? Operating data painstakingly collected by maintainers – Paper-bound but willingly shared ? OEM has little/no insight into data sources or lessons to be learned ? Operating metrics and data proved useful in a sample of subsystems to guide a redesign of the product architecture ? Spurs new models for customer/OEM relationships and enterprise interfaces Intellectual Capital Defined ? IC is intellectual material -- knowledge, information, intellectual property (IP), and experience -- that can be put to use to create wealth and value ? Includes: ? employees’ skills ? patents & trade secrets ? an organization’s technologies, processes, and experience ? info about customers and suppliers Assertion: IC, like other forms of capital, can be made more productive through proper management From presentation by Rebentisch at LAI Plenary conference, March 2002 Investigating “Design Team Capability” ? Recent LAI study on role of IC in aircraft design: ? Setting: new commercial aircraft designs over a generation of change in the industry – Same target markets – Company-funded development – Same FARs, certification requirements – Mature multi-product firms (with significant military business) ? Data based on interviews and extensive archival document search Year 70s Era 90s Era Case Studies “A70” “B70” “A90” “C90” From presentation by Rebentisch at LAI Plenary conference, March 2002 Comparing 4 Commercial Aircraft Programs in a Study ? Ranked performance across all 4 programs: – Design effectiveness (i.e., weight, range, etc.) – Design quality (i.e., ECPs, etc.) – Program performance (i.e., milestones) – Intellectual capital (e.g., # new designs in prior 10, 20 years, management depth, skills) ? Sum scores and check for correlation Depth of IC is positively correlated with design and program performance From presentation by Rebentisch at LAI Plenary conference, March 2002 Study Observations ? Strong Linkage between IC metrics and Program Performance Metrics ? 70s-era design efforts outperformed the 90s-era efforts in meeting program/ performance objectives – Better weight, payload margins; closer to delivery milestones ? Performance extremes were in the same company—allowing convenient comparison – Can address evolution of in-depth through interviews with “graybeards” and documents ? Test phase an important downstream indicator of design performance and IC – Test personnel positioned to understand design system weaknesses through exposure to recurring problems From presentation by Rebentisch at LAI Plenary conference, March 2002 A Story About the Shelf Life of Explicit Knowledge Weight Plan Profile (WPP) Illustration -8% -4% 0% 4% 8% 12% TIME BASIC DATA DETAIL DESIGN FABRICATION TEST & EVAL. TARGET SPECIFICATION WEIGHT Typical Development Weight Growth / Strong Weight Control Typical Development Weight Growth / Weak Weight Control WPP-Delivers AC on target DELIVERY TO CUSTOMER WPP resulted from attempt to codify lessons learned from a close military competition From presentation by Rebentisch at LAI Plenary conference, March 2002 70s Era Aircraft (A70) Design Experience A70 Weight Empty History / Design through Certification -10% -8% -6% -4% -2% 0% 2% 4% 6% 8% 10% 0 4 8 12 162024283236404448 Months After Program Launch Weight Empty Max. Takeoff Weight Useful Load Aggressive use of WPP (and other lessons learned) by those who helped create it kept program on track From presentation by Rebentisch at LAI Plenary conference, March 2002 Footnote to A70 Design Experience ? Evolutionary derivative program 7 years later experienced greater difficulties – Delayed type certification – Reduced performance (poor weight control) ? WPP tool still existed, but originating team had moved on to new assignments – Discipline to use WPP methodology was not as strong as in original A70 program – Other codified lessons learned were circumvented Perceived relevance of captured knowledge (WPP and others) was apparently affected by passage of time and turnover in workforce From presentation by Rebentisch at LAI Plenary conference, March 2002 90s Era Aircraft (A90) Design Experience -8% -4% 0% 4% 8% 12% 16% 0 6 12 18 24 30 36 42 48 54 60 66 72 78 84 90 96 Months from Program Launch WPP indexed to initial We spec Official Program Status Status based on initial spec value We spec value “Evolutionary” design strategy de-emphasized role of experienced air vehicle team members, with problems appearing in and corrected during developmental test From presentation by Rebentisch at LAI Plenary conference, March 2002 Contrasting the A70 and A90 Design Experiences ? A70: – Management team built on senior engineering leadership emerging from a key military program competition victory – Hand-picked team of senior engineers with experience on multiple programs—”fully staffed” program – Aggressive use of lessons-learned and risk reduction strategies (employing familiar, common tools and concepts) ? A90: – 1 prior major program from which to draw experiences (but housed in a separate facility – Program leadership experience primarily with legacy/derivative program; few key players (1-deep at times) from flight sciences – Manufacturing quality higher as a result of advanced design tools – Simulation tools graphically compelling, but underlying data deficiencies (in part due to reduced reliance on wind tunnel testing) lead to late design changes From presentation by Rebentisch at LAI Plenary conference, March 2002 Summary Observations From Intellectual Capital Research ? Knowledge capture and/or knowledge codification methods may be only partially effective if not backed up with experience in practice ? Prototype and experimental aircraft experience alone is inadequate to bring a new aircraft design through certification and rate production ? There must be adequate "critical mass" of intellectual capital—a few stars can’t carry the entire team ? Use of modern design tools: – Modern computational tools did not fully offset impact of intellectual capital declines on program performance – Failure to refresh/support knowledge systems resulted in mis- prediction/rework that caused major delays – Modern computational tools can inhibit development of user tacit knowledge compared with predecessor analysis methods. From presentation by Rebentisch at LAI Plenary conference, March 2002 Implications: Thinking About Investment in IC/KM Tools NPVIC= discounted value of future net IC contributions to enterprise performance Investment in people and tools may increase net IC productivity and yield a return to the enterprise, but: – Organizational return from knowledge creation decays with time ? Employee turnover, new requirements, forgetfulness, etc. – Current productivity metrics make economic justification of IC/KM investment difficult Σ Productivity gains resulting from IC/KM projects (1 + r) i I=1 N = From presentation by Rebentisch at LAI Plenary conference, March 2002 Implications: Thinking About Investment in Knowledge Creation Learning Curves C n = K N s Unit cost (C) declines with each additional unit produced by a rate (S) Illustration from DoD 4245.7-M, 1985 ? “Production breaks” make the next unit more expensive because of “lost learning” ? IC analogy: years between exercise of design skills results in higher costs due to relearning or mistakes not avoided – Case studies showed that programs with broken or disrupted IC continuity with prior programs suffered in performance and programmatics From presentation by Rebentisch at LAI Plenary conference, March 2002 Strategic Choices Around Knowledge Creation Illustrative knowledge creation and capture investment strategies: ? Short-term (periodic and predictable customer pull for new products): – Firm bridges gaps in knowledge creation activities through own investments in development of derivatives, IRAD, productivity enhancements ? Long-term (many years until next new design): – Externalize cost of knowledge creation by allowing customer to fund technology demonstrations, concept studies, and prototypes – Customer or firm adopts “spiral” or adaptive development process to “load level” design experience over several years – BUT–customer acknowledges and accepts potentially significant relearning penalties to develop follow-on new products if the break in knowledge creation activity stretches on too long From presentation by Rebentisch at LAI Plenary conference, March 2002