Plug-n-Play Knowledge Management


Published on

KM Chicago (July, 2005)

Published in: Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • This presentation will raise more questions than answers. Think about ERP systems that are supposed to help in knowledge and information flows within the organizations, they make work static and rigid, rather than enabling for flexibility and agility.
  • Plug-n-Play Knowledge Management

    1. 1. Plug-n-Play Knowledge Management Designing for Flexibility and Agility Kevin C. Desouza Director, Institute for Engaged Business Research The Engaged Enterprise E-mail: Presentation to: KM Chicago July 12, 2005
    2. 2. Knowledge Management Systems <ul><li>Knowledge management systems can be defined as the inter-connected interaction of information, knowledge, people, process, technology, and environments. </li></ul><ul><li>All organizations are knowledge management systems (KMSs) </li></ul><ul><li>Most organizations have poorly designed KMSs. </li></ul><ul><ul><li>Having studied KMSs in over 50 organizations, KMSs are usually described as: static, inflexible, removed from work processes, unused, outdated, costly, complex, etc. </li></ul></ul><ul><li>The question of this talk is how can we design better KMSs </li></ul>
    3. 3. Poorly designed KMSs? <ul><li>KMSs implemented in organizations suffer from several shortcomings: </li></ul><ul><ul><li>They do not appreciate the dynamic and emergent nature of work processes </li></ul></ul><ul><ul><li>They are not integrated with other technical and human systems </li></ul></ul><ul><ul><li>They are not embedded into the fabric of the organization </li></ul></ul><ul><ul><li>They are not tied to organizational objectives </li></ul></ul><ul><li>The result – KMSs fail to deliver on their intended value. </li></ul>
    4. 4. Designing KMSs <ul><li>I will provide some ideas on how we might go about designing better KMSs – Design Guidelines </li></ul><ul><li>My basic tenet is the following: </li></ul><ul><ul><li>“ Current KM programs in most organizations are analogous to the days when computers took up entire office rooms and buildings. Today, computers are become smaller, leaner, faster, better, and far more superior. We must look to the evolution of computing for lessons on how we might redesign KM programs. In particular, I believe that the future of KM programs should resemble the current paradigm of plug-n-play computing.” </li></ul></ul><ul><li>Plug-n-play applies at the hardware (processes and technologies) and the software (knowledge and people) layers of computing. </li></ul>
    5. 5. Balancing Design Agenda <ul><li>Designer </li></ul><ul><ul><li>Efficiency </li></ul></ul><ul><ul><li>Simplicity in design </li></ul></ul><ul><ul><li>Fanciness in appearance </li></ul></ul><ul><ul><li>Necessary functionality </li></ul></ul><ul><ul><li>Component View or Isolated View </li></ul></ul><ul><ul><li>Focus on Internal Workings </li></ul></ul><ul><li>User </li></ul><ul><ul><li>Ease of use </li></ul></ul><ul><ul><li>Simplicity in use </li></ul></ul><ul><ul><li>Fanciness in appeal </li></ul></ul><ul><ul><li>Unlimited functionality </li></ul></ul><ul><ul><li>Systemic View or Integrated View </li></ul></ul><ul><ul><li>Focus on External Appeal </li></ul></ul>Designer User KMS
    6. 6. DP 1: Breaking-Up of KM <ul><li>Understand the components of a KMSs </li></ul><ul><ul><li>People </li></ul></ul><ul><ul><li>Processes </li></ul></ul><ul><ul><li>Technology </li></ul></ul><ul><ul><li>Knowledge </li></ul></ul><ul><li>What does it mean to understand them? </li></ul><ul><ul><li>Characteristics, types, and behavior of each component – defining the components. </li></ul></ul><ul><ul><li>We must be able to specify the type of components of KMSs. </li></ul></ul>Technologies Process Knowledge People
    7. 7. DP 2: Segmenting of KM Components <ul><li>How can we classify KM Components? </li></ul><ul><ul><li>By what they do </li></ul></ul><ul><ul><ul><li>Sources of Information and Knowledge </li></ul></ul></ul><ul><ul><ul><li>Analytics on Information and Knowledge </li></ul></ul></ul><ul><ul><ul><li>Interpretation of Information and Knowledge </li></ul></ul></ul><ul><ul><ul><li>Acting on Information and Knowledge </li></ul></ul></ul><ul><ul><li>By how valuable they are: </li></ul></ul><ul><ul><ul><li>Rare </li></ul></ul></ul><ul><ul><ul><li>Valuable </li></ul></ul></ul><ul><ul><ul><li>Non-Imitable </li></ul></ul></ul><ul><ul><ul><li>Non-Substitutable </li></ul></ul></ul><ul><ul><li>By how mature they are: </li></ul></ul><ul><ul><ul><li>Immature to Mature </li></ul></ul></ul><ul><ul><ul><li>Unstructured to Structured </li></ul></ul></ul><ul><ul><ul><li>Intuitive and Tacit to Visible and Explicit </li></ul></ul></ul>
    8. 8. DP 3: Workflow Models <ul><li>We must integrate the collection of components into how work is conducted in the organizations. </li></ul><ul><li>Work-flow models: </li></ul><ul><ul><li>Connecting inputs to outputs - processing models </li></ul></ul><ul><ul><li>Moving from a current location to a desired location - path models </li></ul></ul><ul><ul><li>Time-based sequencing of activities - temporal models </li></ul></ul>
    9. 9. DP 3: Workflow Models [contd.] Information or Knowledge from Sources Processing of Information and Knowledge Using Analytics Interpreting Information and Knowledge Acting on Interpretations Hunches or Insights Potential Knowledge Working Knowledge Refined Knowledge Best Practices Ad-Hoc Processes Localized Processes Inter-Connected Processes Organized Process Arch. Optimizing Process Arch.
    10. 10. DP 3: Work-Flow Models [contd.] Static versus Dynamic Workflow Models Generates or Identifies Knowledge Documents the Knowledge Puts Knowledge into Practice for Testing Communicates Knowledge Refines Knowledge Enriches Knowledge Applies Knowledge
    11. 11. DP 4: Map KM Components to Workflow <ul><li>Some considerations: </li></ul><ul><ul><li>Issues of redundancy (criticality of the work) </li></ul></ul><ul><ul><li>Issues of speed (time-sensitivity) </li></ul></ul><ul><ul><li>Issues of control (audit) </li></ul></ul><ul><ul><li>Issues of effectiveness (accuracy) </li></ul></ul><ul><ul><li>Etc. </li></ul></ul><ul><li>Important Considerations: </li></ul><ul><ul><li>Do not “Hard-Code” components (such as Jack or John) but use categories of KM components (Software Engineers or Project Manager) </li></ul></ul><ul><ul><li>Plan for dynamism by noting what components need to be switched, replaced, re-aligned, etc. </li></ul></ul>
    12. 12. DP 5: Plug-n-Play for Agility and Flexibility <ul><li>Mapping KM components to the Work-Flow will provide us with an architecture for the KMS </li></ul><ul><li>We must now mobilize the architecture to meet the needs of the organization by plug-n-play </li></ul><ul><ul><li>Using the collection of KM components, we must: </li></ul></ul><ul><ul><ul><li>Switch components as needed for temporary work settings </li></ul></ul></ul><ul><ul><ul><li>Switch components as needed to engage in distributed work </li></ul></ul></ul><ul><ul><ul><li>Switch components to address the different work-flows </li></ul></ul></ul><ul><ul><ul><li>Switch components to address the different types of knowledge </li></ul></ul></ul><ul><ul><ul><li>… </li></ul></ul></ul><ul><li>We must appreciate issues of: </li></ul><ul><ul><li>Architecture openness </li></ul></ul><ul><ul><li>Access controls and modifications rights </li></ul></ul><ul><ul><li>Standard in terms of communication between components </li></ul></ul><ul><ul><li>Standards in terms of component design for inter-operability </li></ul></ul><ul><ul><li>… </li></ul></ul>
    13. 13. The End-Game: Flexible & Agile KMS <ul><li>Ideally, a KMS should be able to change itself proactively, or reactively, with minimal penalties in time, effort, cost, and performance </li></ul><ul><ul><li>by being able to update outdated and obsolete components </li></ul></ul><ul><ul><li>by being able to replace steps within a given process </li></ul></ul><ul><ul><li>by being able to switch over between producing one kind of output to another </li></ul></ul><ul><ul><li>by being able to route outputs to different communication channels </li></ul></ul><ul><ul><li>by being able to deal with varying types of inputs and different volumes of a given output </li></ul></ul><ul><ul><li>by being able to add new functionalities and components as needed </li></ul></ul>
    14. 14. Keep Thinking! Be Bold! Be Imaginative! Questions or Comments Kevin C. Desouza [email_address]