Characterizing a portal is routine for a significant portion of our readers. However, I'd like to propose a different perspective on the process that typically doesn't receive enough attention: characterization based on processes.
One of the strongest statements in knowledge management is that a portal should be a work tool and, as such, support the business processes we perform. However, in too many cases, we fail to connect this statement to the characterization activity carried out in the field. The initial questions we tend to ask users relate to their subjective perception of information or knowledge they would like to see in the portal. Examples of such questions could be: "What information is important for you to see in the portal?" "What knowledge gaps exist today that you would like to be filled in the portal?" "What are the main content areas you deal with that should be reflected in the portal?" etc.
The main disadvantage of this method is that we can never ensure that the information and knowledge requested by the user will be used in their core work processes. If this is not the case, we risk creating a portal whose entire content is "Nice to have." This doesn't mean these questions should be eliminated from the characterization process, but we suggest enriching them with additional questions exploring the main work processes.
How do we do this? It's a multi-stage process. First, we'll ask the interviewees to define the main role groups the portal is meant to serve. Second, we'll be asked to explain these roles, describing the main work processes. Of course, this doesn't mean defining countless processes; we recommend focusing on five main processes and, if necessary, drilling down to the sub-processes of these primary processes.
From our experience, the easiest way is to define the process using a flowchart or describe the actions involved. For each of the methods or stages in the process we've described, we'll ask the following series of questions:
What data, information, or knowledge do you use today to carry out the process?
Where are the data, information, or knowledge you use currently stored?
What tools/information systems do you use to perform the process?
What is the output of the work process?
What additional information not currently available could facilitate or improve the process?
Who is this information's target audience, and what is its added value for them?
To see the added value of these questions, let's try to demonstrate them on a work process familiar to many companies: responding to a tender. The information we typically use is from past tenders to which we've responded. From these tenders, we copy parts we want to reuse and even use them as a reference when we need to make decisions about costs, the type of solution we want to offer, and more. Usually, we know that responses to these past tenders are filed in users' folders or, in a more optimistic case, in a shared folder titled "Tenders." In our case, we don't use additional systems or databases, and the work product is also a tender response.
Seems simple, right? If we asked our users what they want to see in the portal, we might get the answer "Tender library."ץ However, if we let our imagination run a bit and think about what could facilitate or improve the process, we have many improvement suggestions. We can request a fixed template to assist us in writing tender content. We can imagine a repository of tenders that can be sliced according to predetermined parameters (for example, tender scope, type of activity, target sector). Thus, instead of relying on the last tender we remember writing, we are exposed to the entire list of tenders. We can add a repository of specific expertise holders in the organization so that when we respond to a tender, we ensure we increase its chances of acceptance by presenting the most suitable people; we can create a repository of tender segments (as there are constantly repeating parts) instead of returning to the full tender each time, and more.
We must remember to define the target audience for this process, as the knowledge is intended for them. Finally, we need to ask ourselves what the added value of the information and knowledge we want to introduce to the portal is. Have we duplicated our document folders or created a value-added solution? An additional element that can be considered based on the answers we received is whether the entire process or part of it can be computerized. For example, in our case, is it worthwhile to create a workflow that will assist us in the tender writing process by different people? Finding answers to these questions is not always easy and requires closer user guidance, but the added value is very high if done comprehensively. It should be considered that some of the information will repeat itself when you ask users about processes and when you ask them about content they would like to see in the portal, but this is only natural as these are different perspectives on the same knowledge required by the employee.
In conclusion, the idea underlying this technique is to ensure that central processes performed daily are reflected in the portal, either by making the knowledge or information required for them accessible, by editing and processing this information and knowledge, or by computerizing the process.
Comments