Like any knowledge intensive organization, ACME is aware of the risks of not managing the “knowledge production factor”. Today, and in the past, a large part of ‘ACME knowledge’ lives in the heads of its employees, notably a number of champions. This makes the knowledge very agile, and up to date as the individuals continue to learn and educate their colleagues. However, this puts the organization at risk, because champions in the organization are vulnerable and offer limited availability. It is good to have knowledgeable employees, but it is necessary to have a framework of formalized knowledge, independent from these employees, to protect and leverage the knowledge assets at ACME. While containing the risk, this framework (KMF) will also improve the organizational capabilities in terms of stability of operations and faster response to business needs. To enable successful transition to co-sourcing, packaged applications, and running business as a service, a thorough understanding of the current environment, architecture and applications is necessary.

The KMF is not only about a platform, but it is about processes, people, organization, technology and governance. A culture of reward for sharing must be instilled, in which each individual see the value for his or her own contribution. Moreover, a system of “stars”, in which consumer of knowledge reward the contributors of knowledge is necessary. This is a learning from social content. Let the crowd reward the individual. The KMF should be created in an agile way, learning on the way, what are the real needs of the organization. A waterfall model would not fit, as ACME is learning itself what it needs to manage as ‘knowledge’. Classically, knowledge is defined as “actionable information”.  ACME employees need to find the information they need to take actions (solve a bug, resolve a production problem, extend a service, develop a module, test a use case, etc). To make this process efficient:

-          Information needs to be store in a common framework that is explicit and uniform such that we store information with the purpose of it being found later on (by us or others)

-          Information must be treated at a low granular level (document “an IT service”, and don’t create a document of 400 pages with all kinds of services, scenario’s, …)

-          Where possible, standards and standard terms should be used and introduced so you can standardize content

-          Information must be enriched with context information (example: this chunk of information describes the” analysis of the interest calculation module XY”)

-          Information must be interlinked & integrated with other information (bugs linked to the module in which they occur, to operational problems they provoke, to expert advice on how to resolve them, ..) such that we support people in the full flow of analysis. If the train of analysis is broken, the path is useless.

The architecture we propose makes a choice to accommodate diverse formats of information: in the form of documents (collected in a SharePoint site, a shared drive , ..), but also structured data in software engineering tools, wiki pages, emails, and we may expect other forms like instant messages. Although one would prefer to have one format (and as structured as possible, like in a powerdesigner model), we think reality of the next year will not allow such a simplification. Different formats are actually different levels of formalizations. To still have a consistent system, we propose an architecture with a documentation meta-model and with a strong governance model. It’s ok to have different formats of knowledge, as long as you know where to put what. This also factors in the reality of the ACME organization, that has different maturity levels over its diverse departments, value chains and applications. A powerful search engine is the crown piece of the architecture.

We aim to support ACME via knowledge management in two main business activities: creating and modifiying IT applications and running them in the most stable and cost-effective manner. This is obviously a very broad scope: however, that is the nature of knowledge. Limiting our scope to critical applications on the UNISYS platform is perfectly possible and reasonable: however, our concepts and architecture must be global (a bug will not confine itself to a program on UNISYS, it can be a complex interaction between a front-end and a back-end system).

In large parts of ACME activities, KMF will just align with existing activities and provide the “knowledge utility stream” to support higher level initiatives. Notably this is the case in the ITIL and XYZ initiatives around HP service center. They are also about knowledge management, and we need to ensure that the activities are compliant and driven by a common vision. The CMMI initiatives (or whatever frameworks will be around in 10 years time).

Knowledge management initiatives tend to surface every 5 to 8 years at ACME (and not only at ACME). Unfortunately, there is limited information available on previous attempts (no framework of documentation, and not enough discipline ?) so we can analyze on the basis of human memory the reasons of their failure. Have they failed? Or maybe the conclusion is that the organization runs at maximum efficiency, and it accepts the risk that goes with it? My recommendations:

-          Focus more on efficiency than on risk. Today, people spend a lot of time documenting applications and writing down their knowledge. Give them a better system to put more quality in with less effort. The risk will automatically decrease. The business case for risk containment is often made when the risk materializes (i.e. too late).

-          Create a culture of knowledge appreciation and sharing. Sends top level signals that the very top of the organization stands behind this. Make it part of your employee assessment process.

-          Create a position of Chief Knowledge Officer (even when you are a 3 person company). This must not be a full-time assignment. It’s a top level sponsor of continuous care for the knowledge at ACME. Assign knowledge management responsibility in the organization.

-          Standardize a documentation meta-model. It’s an abstraction that creates order in the chaotic universe of content. Transfer ownership to your architects for this model, don’t keep it as a KMF “juwel”. Give the juwel away and show your willingness to share.

-          Increase the coherence between disciplines at ACME by setting up cross-disciplinary work groups. This should enable better flow of knowledge from architecture all the way to operations.

-          The KMF should gain shared ownership by the organization.

-          KMF is not a project, it should be treated as a program and subject of continuous improvement. Of course, it can be boosted by projects improving certain aspects.

Give people a system that can evolve and that supports and automates as much as possible the governance around documentation and knowledge you want to apply.