Technology as what we all know is broad, and it has been very helpful to the world today in terms of speeding up work in order to increase productivity. Technology has become a need to every human being today. In school, in work and in everything we do. Simple machines are considered technology as well, since it speeds up work and reduces human efforts.
Why use technology?
The very first thing that comes to my mind is to ease the way of living.
Before: People used to walk to their destinations no matter how far the distance is, this is because they've got no choice.
Today: People can easily go to places they wanted to be in. Through technology, they were able to get to their destination in no time. Thus, they save time and energy.
Communication
Before: The only way to communicate with friends, family and to other people is through letters. These letters are mailed and will take few days in order for it to get to the receiver.
Today: Telephones, mobile phones, fax machines, e-mailing etc. simplifies the way communication goes. Through the said technology, you would be able to communicate with love ones in an instant. Thus, information is easily passed through.
Technology Change
Technology changes because of the needs of the society. It is dependent on the demand that the world demands. Technologies are developed because it is needed. Another thing that changes technology is how the people adopts it. Will they be able to use a said technology easily? It should also be safe to use regarding the catastrophes that are happening to the world. And the last thing is the cost of its production. It should be feasible and cost effective.
December 27, 2010
January 04, 2010
Life Cycle of a School
Life Cycle can be defined in many ways and forms, and as for this topic, we would only tackle the three views life cycle.
Systems Development Life Cycle
The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. The concept generally refers to computer or information systems.
In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system: the software development process.
A Systems Development Life Cycle (SDLC) is any logical process used by a systems analyst to develop an information system, including requirements, validation, training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance.
Computer systems have become more complex and often (especially with the advent of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of systems development life cycle (SDLC) models have been created: "waterfall"; "fountain"; "spiral"; "build and fix"; "rapid prototyping"; "incremental"; and "synchronize and stabilize".[citation needed]
SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid changes along the development cycle. Iterative methodologies, such as Rational Unified Process and Dynamic Systems Development Method, focus on limited project scopes and expanding or improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results.[citation needed]
Some agile and iterative proponents confuse the term SDLC with sequential or "more traditional" processes; however, SDLC is an umbrella term for all methodologies for the design, implementation, and release of software.
In project management a project can be defined both with a project life cycle (PLC) and an SDLC, during which slightly different activities occur. According to Taylor (2004) "the project life cycle encompasses all the activities of the project, while the systems development life cycle focuses on realizing the product requirements".
Systems development phases
Systems Development Life Cycle (SDLC) adheres to important phases that are essential for developers, such as planning, analysis, design, and implementation, and are explained in the section below. There are several Systems Development Life Cycle Models in existence. The oldest model, that was originally regarded as "the Systems Development Life Cycle" is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages generally follow the same basic steps but many different waterfall methodologies give the steps different names and the number of steps seem to vary between 4 and 7. There is no definitively correct Systems Development Life Cycle model, but the steps can be characterized and divided in several steps.
Initiation/planning
To generate a high-level view of the intended project and determine the goals of the project. The feasibility study is sometimes used to present the project to upper management in an attempt to gain funding. Projects are typically evaluated in three areas of feasibility: economical, operational or organizational, and technical. Furthermore, it is also used as a reference to keep the project on track and to evaluate the progress of the MIS team.[8] The MIS is also a complement of those phases. This phase is also called the analysis phase.
[edit] Requirements gathering and analysis
The goal of systems analysis is to determine where the problem is in an attempt to fix the system. This step involves breaking down the system in different pieces and drawing diagrams to analyze the situation, analyzing project goals, breaking need to be created and attempting to engage users so that definite requirements can be defined. Requirement Gathering sometimes require individual/team from client as well as service provider side to get a detailed and accurate requirements.
(http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle)
Enterprise life cycle
Enterprise Life Cycle (ELC) in enterprise architecture is the dynamic, iterative process of changing the enterprise over time by incorporating new business processes, new technology, and new capabilities, as well as maintenance and disposition of existing elements of the enterprise.
The enterprise life cycle is a concept in Enterprise Architecture (EA). The Enterprise Architecture process is closely related to other processes, such enterprise engineering and program management cycle, more commonly known as the Systems Development Life Cycle. This concept aids in the implementation of an Enterprise Architecture, and the Capital Planning and Investment Control (CPIC) process that selects, controls, and evaluates investments. Overlying these processes are human capital management and information security management. When these processes work together effectively, the enterprise can effectively manage information technology as a strategic resource and business process enabler. When these processes are properly synchronized, systems migrate efficiently from legacy technology environments through evolutionary and incremental developments, and the Agency is able to demonstrate its return on investment. The figure on top illustrates the interaction of the dynamic and interactive cycles as they would occur over time.
Enterprise Architecture Process
As a prerequisite to the development of every enterprise architecture, each Agency should establish the need to develop an EA and formulate a strategy that includes the definition of a vision, objectives, and principles. Executive buy-in and support should be established and an architectural team created within the organization. The team defines an approach and process tailored to Agency needs. The architecture team implements the process to build both the baseline and target EAs. The architecture team also generates a sequencing plan for the transition of systems, applications, and associated business practices predicated upon a detailed gap analysis. The architecture is employed in the CPIC and the enterprise engineering and program management processes via prioritized, incremental projects and the insertion of emerging new technologies. Lastly, the architectures are maintained through a continuous modification to reflect the Agency's current baseline and target business practices, organizational goals, visions, technology, and infrastructure.
Architecture Life Cycle
The architecture is re-analyzed, and the process continues until the operational deficiencies are minimized. The final sets of viable candidates are assessed for operational viability. Based on the results of the assessments, design changes are made and submitted for inclusion into the budgeting process. This process of developing, analyzing, and modifying continues throughout the architecture’s life cycle.
Enterprise Life Cycle activities
An Enterprise Life Cycle integrates the management, business, and engineering life cycle processes that span the enterprise to align its business and IT activities. Enterprise Life Cycle refers generally to an organization’s approach for managing activities and making decisions during ongoing refreshment of business and technical practices to support its enterprise mission. These activities include investment management, project definition, configuration management, accountability, and guidance for systems development according to a System Development Life Cycle (SDLC). The Enterprise Life Cycle applies to enterprise-wide planning activities and decision making. By contrast, a System Development Life Cycle generally refers to practices for building individual systems. Determining what systems to build is an enterprise-level decision.
The figure on the right depicts notional activities of an Enterprise Life Cycle methodology. Within the context of this document, Enterprise Life Cycle does not refer to a specific methodology or a specific bureau’s approach. Each organization needs to follow a documented Enterprise Life Cycle methodology appropriate to its size, the complexity of its enterprise, and the scope of its needs.
(http://en.wikipedia.org/wiki/Enterprise_Life_Cycle)
Here is an example of school life cycle:
Future School: Product life cycle
The Future School product life cycle guidelines provide advance notification in relation to individual product licenses and their life cycles. These guidelines apply to all Future School products, and provide information about the period of time licenses are available for purchase (mainstream phase) and the associated support Future School distributors provide during the entire life cycle of Future School products. These guidelines are intended to assist customers with their product planning and future information technology decisions.
Future School's policy is that its product licenses can only be purchased for a maximum of three (3) years from the date each product license is first released for sale, and that varying levels of support for a product will only be available for a period of five (5) years from the date that product licence is first released for sale. The different phases of a product are illustrated in the life cycle graph shown above, and are explained below.
Product life cycle phases products and services
Mainstream phase: 3 years
1. Each Future School product license is available for purchase through all standard product distribution channels;
2. Distributor assisted support is available from the distributor from whom the product license is purchased;
3. Website support is available from national distributors, and registered license users are also able to upgrade their version of a product to include any modifications to the version during this phase.
Extended phase: 1 year (4th year after release for sale)
1. Future School product licenses are not available for purchase;
2. Distributor assisted support is available from the distributor from whom the product license is purchased;
3. Website support is available from national distributors and all registered license users, except educational volume licensing agreement customers, are able to upgrade their version of a product to include any modifications to the version during this phase.
Final life cycle phase: 1 year (5th year after release for sale)
1. Future School product licenses are not available for purchase;
2. Distributor assisted support is no longer available, unless specifically agreed to in writing by the distributor from whom the product licence is purchased;
3. Website support is available from national distributors, and provides for registered licence users to request limited electronic assistance. Upgrades or modifications to a version are not available during or after this phase.
(http://www.futureschool.com/prodlifecycle.html)
Systems Development Life Cycle
The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. The concept generally refers to computer or information systems.
In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system: the software development process.
A Systems Development Life Cycle (SDLC) is any logical process used by a systems analyst to develop an information system, including requirements, validation, training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance.
Computer systems have become more complex and often (especially with the advent of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of systems development life cycle (SDLC) models have been created: "waterfall"; "fountain"; "spiral"; "build and fix"; "rapid prototyping"; "incremental"; and "synchronize and stabilize".[citation needed]
SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid changes along the development cycle. Iterative methodologies, such as Rational Unified Process and Dynamic Systems Development Method, focus on limited project scopes and expanding or improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results.[citation needed]
Some agile and iterative proponents confuse the term SDLC with sequential or "more traditional" processes; however, SDLC is an umbrella term for all methodologies for the design, implementation, and release of software.
In project management a project can be defined both with a project life cycle (PLC) and an SDLC, during which slightly different activities occur. According to Taylor (2004) "the project life cycle encompasses all the activities of the project, while the systems development life cycle focuses on realizing the product requirements".
Systems development phases
Systems Development Life Cycle (SDLC) adheres to important phases that are essential for developers, such as planning, analysis, design, and implementation, and are explained in the section below. There are several Systems Development Life Cycle Models in existence. The oldest model, that was originally regarded as "the Systems Development Life Cycle" is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages generally follow the same basic steps but many different waterfall methodologies give the steps different names and the number of steps seem to vary between 4 and 7. There is no definitively correct Systems Development Life Cycle model, but the steps can be characterized and divided in several steps.
Initiation/planning
To generate a high-level view of the intended project and determine the goals of the project. The feasibility study is sometimes used to present the project to upper management in an attempt to gain funding. Projects are typically evaluated in three areas of feasibility: economical, operational or organizational, and technical. Furthermore, it is also used as a reference to keep the project on track and to evaluate the progress of the MIS team.[8] The MIS is also a complement of those phases. This phase is also called the analysis phase.
[edit] Requirements gathering and analysis
The goal of systems analysis is to determine where the problem is in an attempt to fix the system. This step involves breaking down the system in different pieces and drawing diagrams to analyze the situation, analyzing project goals, breaking need to be created and attempting to engage users so that definite requirements can be defined. Requirement Gathering sometimes require individual/team from client as well as service provider side to get a detailed and accurate requirements.
(http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle)
Enterprise life cycle
Enterprise Life Cycle (ELC) in enterprise architecture is the dynamic, iterative process of changing the enterprise over time by incorporating new business processes, new technology, and new capabilities, as well as maintenance and disposition of existing elements of the enterprise.
The enterprise life cycle is a concept in Enterprise Architecture (EA). The Enterprise Architecture process is closely related to other processes, such enterprise engineering and program management cycle, more commonly known as the Systems Development Life Cycle. This concept aids in the implementation of an Enterprise Architecture, and the Capital Planning and Investment Control (CPIC) process that selects, controls, and evaluates investments. Overlying these processes are human capital management and information security management. When these processes work together effectively, the enterprise can effectively manage information technology as a strategic resource and business process enabler. When these processes are properly synchronized, systems migrate efficiently from legacy technology environments through evolutionary and incremental developments, and the Agency is able to demonstrate its return on investment. The figure on top illustrates the interaction of the dynamic and interactive cycles as they would occur over time.
Enterprise Architecture Process
As a prerequisite to the development of every enterprise architecture, each Agency should establish the need to develop an EA and formulate a strategy that includes the definition of a vision, objectives, and principles. Executive buy-in and support should be established and an architectural team created within the organization. The team defines an approach and process tailored to Agency needs. The architecture team implements the process to build both the baseline and target EAs. The architecture team also generates a sequencing plan for the transition of systems, applications, and associated business practices predicated upon a detailed gap analysis. The architecture is employed in the CPIC and the enterprise engineering and program management processes via prioritized, incremental projects and the insertion of emerging new technologies. Lastly, the architectures are maintained through a continuous modification to reflect the Agency's current baseline and target business practices, organizational goals, visions, technology, and infrastructure.
Architecture Life Cycle
The architecture is re-analyzed, and the process continues until the operational deficiencies are minimized. The final sets of viable candidates are assessed for operational viability. Based on the results of the assessments, design changes are made and submitted for inclusion into the budgeting process. This process of developing, analyzing, and modifying continues throughout the architecture’s life cycle.
Enterprise Life Cycle activities
An Enterprise Life Cycle integrates the management, business, and engineering life cycle processes that span the enterprise to align its business and IT activities. Enterprise Life Cycle refers generally to an organization’s approach for managing activities and making decisions during ongoing refreshment of business and technical practices to support its enterprise mission. These activities include investment management, project definition, configuration management, accountability, and guidance for systems development according to a System Development Life Cycle (SDLC). The Enterprise Life Cycle applies to enterprise-wide planning activities and decision making. By contrast, a System Development Life Cycle generally refers to practices for building individual systems. Determining what systems to build is an enterprise-level decision.
The figure on the right depicts notional activities of an Enterprise Life Cycle methodology. Within the context of this document, Enterprise Life Cycle does not refer to a specific methodology or a specific bureau’s approach. Each organization needs to follow a documented Enterprise Life Cycle methodology appropriate to its size, the complexity of its enterprise, and the scope of its needs.
(http://en.wikipedia.org/wiki/Enterprise_Life_Cycle)
Here is an example of school life cycle:
Future School: Product life cycle
The Future School product life cycle guidelines provide advance notification in relation to individual product licenses and their life cycles. These guidelines apply to all Future School products, and provide information about the period of time licenses are available for purchase (mainstream phase) and the associated support Future School distributors provide during the entire life cycle of Future School products. These guidelines are intended to assist customers with their product planning and future information technology decisions.
Future School's policy is that its product licenses can only be purchased for a maximum of three (3) years from the date each product license is first released for sale, and that varying levels of support for a product will only be available for a period of five (5) years from the date that product licence is first released for sale. The different phases of a product are illustrated in the life cycle graph shown above, and are explained below.
Product life cycle phases products and services
Mainstream phase: 3 years
1. Each Future School product license is available for purchase through all standard product distribution channels;
2. Distributor assisted support is available from the distributor from whom the product license is purchased;
3. Website support is available from national distributors, and registered license users are also able to upgrade their version of a product to include any modifications to the version during this phase.
Extended phase: 1 year (4th year after release for sale)
1. Future School product licenses are not available for purchase;
2. Distributor assisted support is available from the distributor from whom the product license is purchased;
3. Website support is available from national distributors and all registered license users, except educational volume licensing agreement customers, are able to upgrade their version of a product to include any modifications to the version during this phase.
Final life cycle phase: 1 year (5th year after release for sale)
1. Future School product licenses are not available for purchase;
2. Distributor assisted support is no longer available, unless specifically agreed to in writing by the distributor from whom the product licence is purchased;
3. Website support is available from national distributors, and provides for registered licence users to request limited electronic assistance. Upgrades or modifications to a version are not available during or after this phase.
(http://www.futureschool.com/prodlifecycle.html)
December 28, 2009
Critical Success Factor
Critical Success Factor (CSF) is the term for an element that is necessary for an organization or project to achieve its mission. It is a critical factor or activity required for ensuring the success of your business. The term was initially used in the world of data analysis, and business analysis. For example, a CSF for a successful Information Technology (IT) project is user involvement.
A plan should be implemented that considers a platform for growth and profits as well as takes into consideration the following critical success factors:
* Money: positive cash flow, revenue growth, and profit margins.
* Your future: Acquiring new customers and/or distributors.
* Customer satisfaction: How happy they are.
* Quality: How good is your product and service?
* Product or service development: What's new that will increase business with existing customers and attract new ones?
* Intellectual capital: Increasing what you know is profitable.
* Strategic relationships: New sources of business, products and outside revenue.
* Employee attraction and retention: Your ability to extend your reach.
* Sustainability: Your personal ability to keep it all going.
Key success factors generally include exceptional management of several of the following:
* Product design
* Market segmentation
* Distribution and promotion
* Pricing
* Financing
* Securing of key personnel
* Research and development
* Production
* Servicing
* Maintenance of quality/value
* Securing key suppliers
* New product development
* Good distribution
* Effective advertising
* Innovative response to customer needs
* Consumer loyalty
* Linkage of technology to market demand
* Link marketing to production
* Investment in growth markets
* Unique positioning advantage
* Strong brand image and awareness
* Prevention of price wars
* High product quality
* Patent protection
* Low product cost
* Large marketing resource budget
* Marketing research quality
* Information system power
* Analytic support capability
* Develop human resources
* Attract the best personnel
* Managerial ability and experience
* Quick decision and action capability
* Organizational effectiveness
* Learning systematically from past strategies
(http://en.wikipedia.org/wiki/Critical_success_factor)
The success of a Knowledge Management initiative depends on many factors, some within our control, some not. Typically, critical success factors can be categorized into five primary categories:
1. leadership;
2. culture;
3. structure, roles, and responsibilities;
4. information technology infrastructure; and
5. measurement.
Leadership
Leadership plays a key role in ensuring success in almost any initiative within an organization. Its impact on KM is even more pronounced because this is a relatively new discipline. Nothing makes greater impact on an organization than when leaders model the behavior they are trying to promote among employees. The CEO at Buckman Laboratories, a chemicals company, champions the cause for KM within the organization and personally reviews submissions to its knowledge bank. When he notices that a particular employee has not had been active within the system, he sends a message that reads: "Dear associate, you haven't been sharing knowledge. How can we help you? All the best, Bob."
Several other best-practice organizations have demonstrated this commitment to KM. At the World Bank, the president's support led to the creation of an infrastructure that promoted and supported the growth of communities of practice (CoPs) not only throughout the organization, but also around the globe. Today, the World Bank has sustained its KM initiative through its CoPs. Its knowledge managers constantly search for new approaches to knowledge sharing.
Although leadership plays a critical role in the success of the KM initiative, the "culture" factor can be even more important to the success of Knowledge Managment.
Culture
Culture is the combination of shared history, expectations, unwritten rules, and social customs that compel behaviors. It is the set of underlying beliefs that, while rarely exactly articulated, are always there to influence the perception of actions and communications of all employees.
Cultural issues concerning KM initiatives usually arise due to the following factors:
• Lack of time - The goal is not to encourage the employees to work more, but to work more effectively. The processes, technologies, and roles designed during a KM initiative must save employees' time, not burden them with more work. This can only be accomplished if the employees' work patterns are accounted for during the initial design and planning phase of the initiative.
• Unconnected reward systems - Organizations have to maintain a balance between intrinsic and explicit rewards in order to encourage employee behavior. The most effective use of explicit rewards has been to encourage sharing at the onset of a KM initiative. If the attendees don't find value in either the meetings or the information on the system, providing incentives will not sustain their participation. People share because they want to, they like to see their expertise being used, and they like being respected by their peers.
• Lack of common perspectives - Sharing must be inspired by a common vision. The people affected by the new process or technology must all buy in to this vision and believe it will work.
• No formal communication - When designing and implementing KM initiatives, ensure that employees and customers know about the changes occurring in your organization. It has been hypothesized that a person needs to hear the same message at least three times before it registers in the brain. Hence, communication should be pervasive. While implementing KM within your organization, market yourself. Make sure everyone knows what you are attempting to do, and build anticipation for the launch.
If your organization naturally has a tendency to share knowledge, enabling knowledge sharing becomes a little easier. If your organization harbors a knowledge-hoarding culture, don't give in to it. Remove negative consequences to sharing. People want to share their knowledge. They want others to know they are knowledgeable. Break down some of the existing barriers to knowledge sharing, and give people the tools and environment they need. By designing KM initiatives around your culture, you will be initiating a cultural change.
Structure, Roles, and Responsibilities
Although there are many ways that organizations structure the governance of their KM initiatives, APQC has found common elements among best-practice partner organizations: a steering committee, a central KM support group, and stewards/owners throughout the organization who are responsible for KM. It is a combination of a centralized and decentralized approach.
The steering committee usually consists of executives at the top level. They promote the concept and provide guidance, direction, and support. The central KM group is typically made up of three to four people who provide the initial support for projects or initiatives, which are usually handed over to the business owners once they are implemented. The central group usually consists of people with advanced project management, facilitation, and communication skills. The stewards, or owners, are responsible for knowledge sharing and acquisition within the business units. Like the core KM group, the stewards are change agents for the organization. They model and teach employees the principles of knowledge sharing using a common vocabulary. All of these participants work as a team to prevent a silo mentality and incorporate resistant employees in the process.
Although the structure is put in place to establish ownership and accountability, if there is no overall ownership of knowledge and learning within the organization and the leadership does not "walk the talk," it will be difficult to sustain any sharing behavior.
sharing using a common vocabulary. All of these participants work as a team to prevent a silo mentality and incorporate resistant employees in the process.
Although the structure is put in place to establish ownership and accountability, if there is no overall ownership of knowledge and learning within the organization and the leadership does not "walk the talk," it will be difficult to sustain any sharing behavior.
Measurement
Most people fear measurement because they see it as synonymous with ROI, and they are not sure how to link KM efforts to ROI. Although the ultimate goal of measuring the effectiveness of a KM initiative is to determine some type of ROI, there are many intervening variables that also affect the outcomes.
Because many variables may affect an outcome, it is important to correlate KM activities with business outcomes, while not claiming a pure cause-and-effect relationship. Increased sales may be a result not only of the sales representatives having more information, but also of the market turning, a competitor closing down, or prices dropping 10 percent. Due to the inability to completely isolate knowledge-sharing results, tracking the correlations over time is important There is a final imperative concerning critical success factors, which transcends KM and applies to all interactions: Listen! Listen to your users, customers, and managers-whichever audience for which you are designing. They will tell you how you can meet their needs and have a successful KM initiative.
(http://www.providersedge.com/docs/km_articles/Critical_Success_Factors_of_KM.pdf)
Critical Success Factor (CSF) is the term for an element that is necessary for an organization or project to achieve its mission. It is a critical factor or activity required for ensuring the success of your business. The term was initially used in the world of data analysis, and business analysis. For example, a CSF for a successful Information Technology (IT) project is user involvement.
A plan should be implemented that considers a platform for growth and profits as well as takes into consideration the following critical success factors:
* Money: positive cash flow, revenue growth, and profit margins.
* Your future: Acquiring new customers and/or distributors.
* Customer satisfaction: How happy they are.
* Quality: How good is your product and service?
* Product or service development: What's new that will increase business with existing customers and attract new ones?
* Intellectual capital: Increasing what you know is profitable.
* Strategic relationships: New sources of business, products and outside revenue.
* Employee attraction and retention: Your ability to extend your reach.
* Sustainability: Your personal ability to keep it all going.
Key success factors generally include exceptional management of several of the following:
* Product design
* Market segmentation
* Distribution and promotion
* Pricing
* Financing
* Securing of key personnel
* Research and development
* Production
* Servicing
* Maintenance of quality/value
* Securing key suppliers
* New product development
* Good distribution
* Effective advertising
* Innovative response to customer needs
* Consumer loyalty
* Linkage of technology to market demand
* Link marketing to production
* Investment in growth markets
* Unique positioning advantage
* Strong brand image and awareness
* Prevention of price wars
* High product quality
* Patent protection
* Low product cost
* Large marketing resource budget
* Marketing research quality
* Information system power
* Analytic support capability
* Develop human resources
* Attract the best personnel
* Managerial ability and experience
* Quick decision and action capability
* Organizational effectiveness
* Learning systematically from past strategies
(http://en.wikipedia.org/wiki/Critical_success_factor)
The success of a Knowledge Management initiative depends on many factors, some within our control, some not. Typically, critical success factors can be categorized into five primary categories:
1. leadership;
2. culture;
3. structure, roles, and responsibilities;
4. information technology infrastructure; and
5. measurement.
Leadership
Leadership plays a key role in ensuring success in almost any initiative within an organization. Its impact on KM is even more pronounced because this is a relatively new discipline. Nothing makes greater impact on an organization than when leaders model the behavior they are trying to promote among employees. The CEO at Buckman Laboratories, a chemicals company, champions the cause for KM within the organization and personally reviews submissions to its knowledge bank. When he notices that a particular employee has not had been active within the system, he sends a message that reads: "Dear associate, you haven't been sharing knowledge. How can we help you? All the best, Bob."
Several other best-practice organizations have demonstrated this commitment to KM. At the World Bank, the president's support led to the creation of an infrastructure that promoted and supported the growth of communities of practice (CoPs) not only throughout the organization, but also around the globe. Today, the World Bank has sustained its KM initiative through its CoPs. Its knowledge managers constantly search for new approaches to knowledge sharing.
Although leadership plays a critical role in the success of the KM initiative, the "culture" factor can be even more important to the success of Knowledge Managment.
Culture
Culture is the combination of shared history, expectations, unwritten rules, and social customs that compel behaviors. It is the set of underlying beliefs that, while rarely exactly articulated, are always there to influence the perception of actions and communications of all employees.
Cultural issues concerning KM initiatives usually arise due to the following factors:
• Lack of time - The goal is not to encourage the employees to work more, but to work more effectively. The processes, technologies, and roles designed during a KM initiative must save employees' time, not burden them with more work. This can only be accomplished if the employees' work patterns are accounted for during the initial design and planning phase of the initiative.
• Unconnected reward systems - Organizations have to maintain a balance between intrinsic and explicit rewards in order to encourage employee behavior. The most effective use of explicit rewards has been to encourage sharing at the onset of a KM initiative. If the attendees don't find value in either the meetings or the information on the system, providing incentives will not sustain their participation. People share because they want to, they like to see their expertise being used, and they like being respected by their peers.
• Lack of common perspectives - Sharing must be inspired by a common vision. The people affected by the new process or technology must all buy in to this vision and believe it will work.
• No formal communication - When designing and implementing KM initiatives, ensure that employees and customers know about the changes occurring in your organization. It has been hypothesized that a person needs to hear the same message at least three times before it registers in the brain. Hence, communication should be pervasive. While implementing KM within your organization, market yourself. Make sure everyone knows what you are attempting to do, and build anticipation for the launch.
If your organization naturally has a tendency to share knowledge, enabling knowledge sharing becomes a little easier. If your organization harbors a knowledge-hoarding culture, don't give in to it. Remove negative consequences to sharing. People want to share their knowledge. They want others to know they are knowledgeable. Break down some of the existing barriers to knowledge sharing, and give people the tools and environment they need. By designing KM initiatives around your culture, you will be initiating a cultural change.
Structure, Roles, and Responsibilities
Although there are many ways that organizations structure the governance of their KM initiatives, APQC has found common elements among best-practice partner organizations: a steering committee, a central KM support group, and stewards/owners throughout the organization who are responsible for KM. It is a combination of a centralized and decentralized approach.
The steering committee usually consists of executives at the top level. They promote the concept and provide guidance, direction, and support. The central KM group is typically made up of three to four people who provide the initial support for projects or initiatives, which are usually handed over to the business owners once they are implemented. The central group usually consists of people with advanced project management, facilitation, and communication skills. The stewards, or owners, are responsible for knowledge sharing and acquisition within the business units. Like the core KM group, the stewards are change agents for the organization. They model and teach employees the principles of knowledge sharing using a common vocabulary. All of these participants work as a team to prevent a silo mentality and incorporate resistant employees in the process.
Although the structure is put in place to establish ownership and accountability, if there is no overall ownership of knowledge and learning within the organization and the leadership does not "walk the talk," it will be difficult to sustain any sharing behavior.
sharing using a common vocabulary. All of these participants work as a team to prevent a silo mentality and incorporate resistant employees in the process.
Although the structure is put in place to establish ownership and accountability, if there is no overall ownership of knowledge and learning within the organization and the leadership does not "walk the talk," it will be difficult to sustain any sharing behavior.
Measurement
Most people fear measurement because they see it as synonymous with ROI, and they are not sure how to link KM efforts to ROI. Although the ultimate goal of measuring the effectiveness of a KM initiative is to determine some type of ROI, there are many intervening variables that also affect the outcomes.
Because many variables may affect an outcome, it is important to correlate KM activities with business outcomes, while not claiming a pure cause-and-effect relationship. Increased sales may be a result not only of the sales representatives having more information, but also of the market turning, a competitor closing down, or prices dropping 10 percent. Due to the inability to completely isolate knowledge-sharing results, tracking the correlations over time is important There is a final imperative concerning critical success factors, which transcends KM and applies to all interactions: Listen! Listen to your users, customers, and managers-whichever audience for which you are designing. They will tell you how you can meet their needs and have a successful KM initiative.
(http://www.providersedge.com/docs/km_articles/Critical_Success_Factors_of_KM.pdf)
Subscribe to:
Posts (Atom)
