Yesterday, I was in Amsterdam, attending KM Europe, which advertises itself as "The World's No.1 Knowledge Management Event". The event consists of an exhibition, keynote addresses and quite a few associated workshops. I attended a workshop organized by KnowledgeBoard, a European KM network of researchers and practitioners. Theme of the workshop was personal KM:
"Much of knowledge management practices are focused on an organisational level; interventions and systems are designed and implemented without much thinking of how they would match the practices and daily routines of individual knowledge workers. While this personal side of knowledge management seems to be neglected in corporate KM initiatives it has increasingly become a topic of discussion by KM practitioners."
I was struck by the difference in atmosphere and attendance between the main conference exhibition and the workshop. The major KM vendors were exhibiting their products, but there seemed to be rather low business and "buzz". Participation in the workshop was high, however, and, especially in the final discussion, many interesting observations were made about how important process is for effective knowledge management. With respect to the vendor solutions, the general opinion seemed to be that many of their sophisticated text analysis and information retrieval applications are more information management than knowledge management tools: necessary, but not sufficient for KM. Of course, many of the knowledge management and community informatics issues are entwined. Even, or especially, personal KM is only useful when starting from the premiss that individual workers are part of a community of practice.
Given that process is so essential to communities and KM, it requires support of some kind. Of course, there are many informal and tacit KM and community aspects that cannot be explicitly supported by applications, since that could easily impose an undesired straightjacket-form of order on the interactions of users (Suchman, 1994). However, it would be naive to assume that no partial process-aspects could benefit from well-defined supporting methods and tools (Winograd, 1994). A simple example is more intelligent forms of notification of significant community events, such as the definition and assignment of action points, which could help trigger members to perform relevant actions.
True KM instead of information management tools would pay much more attention to capturing and supporting essential community process elements, instead of sticking to the current limited array of topics related to information retrieval and analysis. A reason for the lack of such tools could be that community processes are much fuzzier, more complex, and more specific to a particular community than information management issues. In other words, they are much harder to "put in a box". Still, major vendors could play a role here. Perhaps we don't need less tools, but more process-sensitive tools?
To shed more light on this confusing problematic, we need to ask ourselves a host of basic questions. What classes of applications are lacking so far, from a community process perspective? To what extent do they need to be in a package form, which can more easily be sold and generate revenue? What is the role of open source software in this domain? Information systems seem to be constructed ever more according to a market-based IS development paradigm, in which off-the-shelf packages are assembled and integrated, and in which forms of analysis, roles in software development, and the meanings of use and maintenance need to be redefined (Sawyer, 2001). Could this new paradigm be a viable way to integrate business interests with community needs?
References
- S. Sawyer (2001), A Market-Based Perspective on Information Systems Development, Communications of the ACM, 44(11): 97-102.
- L. Suchman (1994), Do Categories Have Politics? The Language/Action Perspective Reconsidered, Computer Supported Cooperative Work, 2:177-190.
- T. Winograd (1994). Categories, Disciplines, and Social Coordination, Computer Supported Cooperative Work, 2:191-197.
Comments