Building on the theme from my last entry, I wanted to share some insights from Andrew McAfee and JP Rangaswami on when you might use a wiki or a blog in an internal knowledge management system at a large organization. The insights come from an excellent article in Optimize Magazine entitled, "Enterprise 2.0 Evangelists." Rangaswami implemented wikis and blogs a Dresdner Kleinwort, a large London-based investment bank. McAfee, a Harvard Business School professor, has written extensively about this implementation effort and its implications for other organizations.
Rangaswami had some excellent insights into when to use a wiki and when to use a blog to capture knowledge. He identifies three broad business processes--idea-to-market, lead-to-cash, and problem-to-repair. Here are some of his key insights:
It turns out the idea-to-market element has very much to do with multipart conversations—putting things forward without having to be rock-solid right. And these things were much more effective if you used a tool like a blog.
The lead-to-cash approach seemed to require more structure than the cloud of blogging. And it came much closer to a wiki, where there were how-tos and definitions and whys and work flows. And the wiki gave them that because things were ordered, things were listed, you could nest them, you could add to them. Even though they were creating the structure themselves, they needed that structure to be able to work. A lot of the things that would have been lead-to-cash directions migrated onto the wiki, including manuals, guidelines, policy documents, how-tos, definitions, and glossaries.
The blogs were for the creators and the thinkers; [they were] the conversations in the marketplaces for people who really were talking about ideas. The wikis were about doing things rather than thinking about things.
And those who concentrated on some form of customer service—for example, a system that fails, or an application that has to be brought back up within the next 40 minutes—found it much more comfortable to use IM.
In all three cases, we found that as we expanded more, and connected the more radical, open-source community types within the IT department, the technology actually formed a bridge because it resonated with both the producer and consumer of technology. What they both got—which they only realized over time—was a persistence of context that just didn't exist in the past with conferencing or E-mail.
With slight variation, Rangaswami's insights ring true based on my own experience. Wikis can provide a very accessible repository of structured information to support the sales process and the customer service process. For our Mekko Graphics product, I can see using wikis to provide our customers with information on when different types of charts might be useful for specific business problems. This would support both sales and customer service. Wikis are also a great repository for detailed information about how are software works. They can be a supplement to our help file, providing more detailed information on how we determine the font size of labels or how to customize a color palette.
At KMA, we have embraced blogging as a sales tool. It is a great way to share our insights with customers and prospects. Blogs can play a similar role in a large organization. In a consulting firm, practice area leaders can use blogs to share their insights, making others aware of opportunities to sell additional services. In an engineering firm, technical experts can describe how they solved a specific customer problem.
The jury is still out as to how widely these new tools will spread within organizations. I hope these ideas help you get started in your journey toward improved knowledge management.
Comments