How can you implement a consistent approach to Knowledge Management, in a globally diverse company?
How much of a Knowledge Management framework needs to be consistent around the globe, and how much can you vary on a local, or divisional, basis?
The answer is that you select certain global commonalities, but allow local expression of these. And the local expressions could be localised by geography or by corporate division.
There are several elements which need to be common, and applied globally.
- Knowledge Management needs a common vision and a common definition (see blog post on example visions). That means that KM, across the whole global organisation, is trying to do the same thing.
- Knowledge Management should employ common principles. Principles such as Shell's "Ask, Learn, Share", or the common "Learn Before, During and After" principle, need to be seen across the entire KM deployment.
- Knowledge Management should employ a consistent approach to Communities of Practice. CoPs are likely to be one of the elements that cross the corporate geographical and divisional boundaries, so a common and integrated CoP approach is important.
- Knowledge Management should use a common global technology wherever possible. One set of Community software, one Yellow Pages, one search engine, one Portal, one Lessons Management System, one email system, and so on. However different functions and different divisions may need additional technology that meets their specific needs.
- Knowledge Management should be approached in the same way by Leadership. This will be expressed in a common KM Policy, and reflected in leadership expectations.
- Knowledge management should apply a standard taxonomy and naming convention. Your product components, for example, should be referred to with the same names by product development, manufacturing, sales and service. This will allow KM to cover the whole product lifecycle.
The elements which need to differ from division to division, are as follows.
- Embedding KM processes into business process. Each division will work with a different process. (Ideally processes should be harmonised globally within each division - if not, then this can be one of the early tasks that KM helps with). Therefore KM will need to be embedded differently, in different steps in the process, and sometimes using different processes. The Sales process and the Project Management processes, for example, may be sufficiently different that each uses a partially different set of KM processes, embedding these processes in different places, even when the principles of "Learn before, during and after" should still apply. Projects may "Learn before" by doing KM planning at the project start, while Production may do KM planning on an annual basis. Projects may "Learn After" through holding Retrospects, Sales through using Knowledge Exchange. The principles are the same, the local expressions of those principles are tailored to the business process.
- Embedding roles into the organigram. Each division will have a different organigram, so KM roles (which will be needed in all divisions - roles for knowledge creation and use, roles for knowledge ownership, roles for KM support) will be placed in different spots on the organigram. If the Projects division has a Project Management Office, for example, this could be the ideal home for the KM support roles for projects - the facilitators, the trainers, the lessons management team. If the Marketing division has regional hubs, this could be the ideal place for the KM support roles for marketing. And so on.
- Different specialist technology. Depending on the nature of the knowledge being applied, and the number of knowledge suppliers and users, different functions or divisions may need different KM technologies. Within R&D, for example, knowledge is evolving rapidly, and is held by a small number of people. They may find it useful to set up a wiki where they can collaborate on keeping knowledge constantly updated. on the other hand, the customer service department works with knowledge needed by thousands or millions of customers world-wide, and needs a knowledge base of reliable content where the customer agents (or even the customers themselves) can rapidly find answers to their questions. There are several vendors supplying this sort of technology.
- Different operational contexts. You see this most clearly where a company is providing products to major clients who have differing requirements, or where company lawyers are working in different countries with different regulatory systems. Here the knowledge itself will be local, varying with client or with country, but the KM system should still be global. Lawyers in one country, or engineers working with one client, may still be able to learn from knowledge gained in other contexts, which they can then modify to meet their own needs.
So the implementation of Knowledge Management is set on global principles, and adapted to local settings. Getting this all set up and running comes from defining the Knowledge Management Framework and the Knowledge Management organisation
No comments:
Post a Comment