1. KNOWLEDGE CREATION AND KNOWLEDGE MANAGEMENT ARCHITECTURE
Lecture Three
(Chapter 3, Notes;
Chapter 4, Textbook)

2. Review of Lecture 2 Challenges in building KM Systems
Compare KMSLC and CSLC
Knowledge Management System Life Cycle (8 Stages)
Before doing that, let’s review the main topics that were covered last week to refresh our memory.
In last lecture, we talked about:
What is KM and what are the driving forces behind its development.
Then, we discussed the organizational issues that one need to consider when initiating KM projects.
Third, I briefly explained what is KMS and its role in an organization.
Fourth, we looked at the relevance of KM in today’s dynamic business environments that are fueled by the advancement of technologies.
Finally, I presented both benefits and concerns when developing KM projects from an IT perspective.
Ask the students some questions.

3. This Week’s Topics Knowledge Creation and Sharing
Knowledge Infrastructure
Knowledge Management Architecture
Build versus Buy Decision

4. KNOWLEDGE CREATION
Dynamic activity that can enhance organization success and economic well-being
Driver of innovation
Involves knowledge acquisition, selection, generation and sharing
Maturation - translates experience into knowledge

5. Knowledge Creation and Transfer via Teams
Initial knowledge
Outcome is realized
Team performs
a job
Outcome compared to action
New knowledge reusable by same team on next job
New experience/ knowledge gained
Knowledge captured and codified in a form usable by others

6. Impediments to Knowledge Sharing
Compensation
Recognition
Ability utilization
Creativity
Good work environment
Autonomy
Job security
Moral values
Advancement
Variety
Achievement
Independence
Social status
Personality
Organizational culture
Lack of Vocational reinforcers
Knowledge sharing
Attitude
Company strategies and policies
Work Norms

7. Nonaka’s Model of Knowledge Creation and Transformation
TACIT TO TACIT
(SOCIALIZATION)
e.g., Individual and/or Team Discussions 
TACIT TO EXPLICIT
(EXTERNALIZATION)
e.g., Documenting a Team Meeting
EXPLICIT TO TACIT
(INTERNALIZATION)
e.g., Learn from a report and Deduce new ideas
EXPLICIT TO EXPLICIT
(COMBINATION)
e.g., Create a Website from some form of explicit knowledge; a Report

8. Key to Knowledge Creation
The model focuses on tacit knowledge and use of technology to generate or transmit such knowledge to others
The key to knowledge creation lies in the way knowledge is being mobilized and converted through technology

9. KNOWLEDGE INFRASTRUCTURE
Content
Content core: Identify knowledge centres
People core: Evaluate employee profiles
Technical core: The totality of technology (S/W and H/W) required to operate the knowledge environment
People
Technology

10. Identifying Knowledge Centers
Competition data, Sales volume, Leader sales data
Job skills,
Training
HUMAN RESOURCES
SALES
CUSTOMER SERVICES
MARKETING
Strategies
Tools
R & D
Advertising
Complaint rate, Satisfaction survey

11. Stages of KMSLC ← KM Architecture Iterative Rapid Prototyping
Evaluate Existing Infrastructure
Knowledge Capture
Design KM Blueprint
Verify and validate the KM System
Implement the KM System
Manage Change and Rewards Structure
Form the KM Team
Post-system evaluation ←
KM Architecture
Iterative Rapid Prototyping
KM system development life cycle is largely composed of 8 stages, which we will briefly discuss in the remaining slides. You should obtain description of their details in both the lecture notes and the prescribed text.

12. … User1 User2 Usern Layer User Interface 1 2 Authorized access control
User1
User2 …
Usern
Layer
User Interface
(Web browser software installed on each user’s PC) 1 2 3 4 5 6 7
Authorized access control
(e.g., security, passwords, firewalls, authentication)
Collaborative intelligence and filtering
(intelligent agents, network mining, customization, personalization)
Knowledge-enabling applications
(customized applications, skills directories, videoconferencing, decision support systems,
group decision support systems tools)
Transport
( , Internet/Web site, TCP/IP protocol to manage traffic flow)
Middleware
(specialized software for network management, security, etc.)
Then, the blueprint should consider how the functions of the KMS can be placed into a KM architecture, consisting of 7 important layers as shown here.
Details of these layers in the KM architecture will be explained in the next lecture.
The Physical Layer
(repositories, cables)
Legacy applications
(e.g., payroll)
Groupware
(document exchange,
collaboration)
Data warehousing
(data cleansing,
data mining)
Databases

13. KM Architecture
Visualize the building blocks of a KM system in the form of layers
User Interface being the least technical, and data repository the most technical
These layers represent internal technologies of the company

14. The User Interface (Layer 1)
Interface between users and the KM system
Usually as a web browser
The goal is to remove barriers to information and tacit (made explicit) knowledge represented in the data repositories

15. The User Interface (Layer 1)
User interface should be consistent, relevant, visually clear, easy to navigate, and easy to use
Usability testing by the actual users is the final test of acceptability

16. Authorized Access Control (Layer 2)
Maintains security and ensures authorized access to the knowledge stored in company’s repositories
Access points can be intranet, Internet, and extranet

17. Authorized Access Control (Layer 2)
Extranet
Internet
Intranet
Clients
Suppliers
Vendors
Partners
Customers
Public
Company
Human resource information
Production information
Sales information
Strategic plans
News/events
Marketing
E-commerce
Careers
Product information
Sales information
Collaboration/cooperation

18. Collaborative Intelligence and Filtering (Layer 3)
Personalized views based on roles and stored knowledge
Intelligent agents to reduce search time for needed information

19. Knowledge-Enabling Application (Layer 4)
Referred to as value-added layer
Provides knowledge bases, discussion databases, automation tools, etc.
Ultimate goal: demonstrate by knowledge sharing how employees’ performances are improved

20. Transport Layer (Layer 5)
Most technical layer to implement
Includes LANs, WANs, intranets, extranets, and the Internet
Ensures that the company will become a network of relationships
Considers multimedia, URLs, graphics, connectivity speeds, and bandwidths

21. Middleware (Layer 6)
Focus on interfacing with legacy systems and programs residing on other platforms
Designer should address databases and applications with which KM system interfaces
Makes it possible to connect between old and new data formats

22. Physical Repositories (Layer 7)
Bottom layer in the KM architecture
Represents the physical layer where repositories are installed
Includes data warehouses, legacy applications, operational databases, and special applications for security and traffic management

23. Build In-House, Buy, or Outsource?
Trend is toward ready-to-use, generalized software packages
Outsourcing is also a trend, releasing technological design to outsiders
Regardless of choice, it is important to set criteria for the selection
Question of who owns the KM system should be seriously considered

24. End of Lecture Three This end the Lecture 2.
The next lecture, we will cover Knowledge Creation and Knowledge Architecture.

25. In Class Discussion Exercise
Assume you are the person responsible for making decision on a KM project
How would you decide to build or buy?
Based on the key elements compared, and
The current state of your organization preparedness (thinking in terms of maturity in layers of KM architecture)

26. CHALLENGES IN BUILDING KM SYSTEMS
Culture
— getting people to share knowledge
Knowledge evaluation
— assessing the worth of knowledge across the firm
Knowledge processing
— documenting how decisions are reached
Knowledge implementation
— organizing knowledge and integrating it with the processing strategy for final deployment
Needless to say, there are numerous challenges that one will expect to face when building KM systems.
Here, I have listed four which are considered as universal.
The first challenge is culture. Here, we are not simply referring to culture as in your place of birth, your nationality, etc.
The challenge is more than that. It involves the challenge of getting people to share knowledge, getting people to the point of willing to share what they know. This challenge is more of an art of doing it, rather than technical. For a knowledge developer, one of the primary skills or qualifications is the ability to get the experts share both explicit and tacit knowledge related to the domain of the KMS that is to build.
The next challenge is knowledge evaluation. This involves the assessment of the worth of knowledge (people, files, documents, databases, etc) that exist across the entire organization, in order to determine both domain and scope of KM projects that should be initiated.
The third challenge is knowledge processing. By knowledge processing, it is the task of finding out how experts make decision on their tasks based on the knowledge they possess. This is an important challenge that will eventually influence the quality of the KM system that is to build.
Finally, there is the challenge of knowledge implementation. This is most technical among the four challenges, and are related to the activity of organizing knowledge that has been identified and integrating it to the processing strategy being adopted by the organization. Being able to successfully overcome this challenge is like overcoming the last hurdle before final deployment of the KM system.

27. Conventional System Life Cycle
Iterative
KM System Life Cycle
Evaluate Existing Infrastructure
Knowledge Capture
Design KMS Blueprint
Verify and validate the KM System
Implement the KM System
Manage Change and Rewards Structure
Form the KM Team
Post-system evaluation
versus
Recognition of Need and Feasibility Study
Logical Design (master design plan)
Physical Design (coding)
Testing
Implementation (file conversion, user training)
Operations and Maintenance
Functional Requirements Specifications
Here, I make a comparison between the system life cycle that is often adopted in conventional system development and the version of KMSLC that are proposed by Awad and Ghaziri in their textbook.
Let’s look at the stages that are involved in a typical conventional system life cycle.
In almost all conventional system development project, one will start out with a “Recognition of Need and a Feasibility Study”. Sometimes, this stage is simply abbreviated as Feasibility Study. In this stage, normally a system analyst will have already identified an existing problem in an organization (may be in a department) that can be solved by an application of Information technology. Of course, recognizing the existence of a problem doesn’t necessarily say a solution is possible, within the current resources constraint in the organization. These constraints could be time, money, people, and expertise.
Assuming that the answer is positive after the feasibility study, the next stage would be to come up with software specifications for the system that is to be constructed. This is a sample of elements that will be included in a software requirements specifications document.
When the software requirements specifications have received an “ok” sign from users and from management, the later stage will be straightforward. Logical design (or the master design plan) of the system will commence, usually performed by a group including systems analyst and programmers and users.
Once the master design plan is ready, physical design (or coding) will follow. This is again straightforward in an IT point of view.
Once a version of the system is ready, then testing will begin, followed by implementation, and finally when the system is ready, issues on operations and maintenance will be documented and followed.
The conventional system life cycle is largely sequential, that is one stage following on from the previous one.
However, at the point of testing, when the system to be implemented is found out to not perform according to the initial software requirements specifications or contains logical errors or programming errors, the development team will have to refer back to the logical design to make necessary changes or amendments. However, the software requirements specification remains unmodified.
Compared to this, in the KM system life cycle,
One will start with evaluating the existing infrastructure (knowledge assessment), including both knowledge and system and people, that constitute the essential resources in the company.
If a KM initiative were decided, then the next step will be the formation of a KM team to take on this KM project initiative.
Normally, there will one knowledge developer in the KM team, who will be playing the important role of identifying knowledge sources, capturing the necessary knowledge from experts, and then design the blueprint for the KMS to be constructed. The first 3 stages pretty much resemble the first 2 stages in the conventional system life cycle, while the “design the KM blueprint” corresponds to the logical design.
However, instead of having a sequential stage of physical design, then followed by testing, in KMSLC, the stage of verify and validate the KM system proceeds in an iterative manner, until a satisfactory prototype of the KMS is arrived. By satisfactory, this will involve not just the users as in conventional system life cycle, but the experts who are the sources of the knowledge embedded in the KMS.
Implementation will be the next step, followed by the important yet less noticeable step of manage change and rewards structure. This is a delicate stage as very often users, experts could become anti-support to the KMS and implementation if they feel that their importance is being undermined, or that the existence of the KMS jeopardize their necessity in the company.
Post-system evaluation is to consider all the benefits of the KMS as weighted against its foresee benefits at the time of conception.
Iterative

28. Users Versus Experts Attribute User Expert
Dependence on system High Low to nil
Cooperation Usually cooperative Cooperation not
required
Tolerance for ambiguity Low High
Knowledge of problem High Average/low
Contribution to system Information Knowledge/expertise
System user Yes No
Availability for system
builder Readily available Not readily available
In earlier slides, we talked about the differences between conventional system life cycle and KMSLC.
We emphasized the importance of the role of users in conventional life cycle as compared to that of experts in KMSLC. Here, we compare them based on their major attributes.

29. KM System Development Life Cycle (8 Stages)
Evaluate existing infrastructure
Form the KM team
Knowledge capture
Design KM blueprint (master plan)
Test the KM system
Implement the KM system
Manage change and reward structure
Post-system evaluation
KM system development life cycle is largely composed of 8 stages, which we will briefly discuss in the remaining slides. You should obtain description of their details in both the lecture notes and the prescribed text.

30. Build vs. Buying Option Cost Time Factor Customization
In-house Usually high Much shorter than High, depending
development development by on quality of
user staff
Development Usually low Depends on skills High to the user
by end users set, system priority, specifications
and so forth
Outsourcing Medium to high Shorter than High
in-house
Off-the-shelf Low to medium Nil Usually up to
Solution % usable
In earlier slides, we talked about the differences between conventional system life cycle and KMSLC.
We emphasized the importance of the role of users in conventional life cycle as compared to that of experts in KMSLC. Here, we compare them based on their major attributes.

31. Knowledge Sharing Via Teamwork
Initial knowledge
Outcome is realized
Team performs
a job
Outcome compared to action
New knowledge reusable by same team on next job
New experience/ knowledge gained
Knowledge captured and codified in a form usable by others