A lot of what I’m working on lately involves the best process to accomplish something, which can mean a lot of step by step logic. Often when working on such docs I end up having to repeatedly reorganize them as I realize during the writing that I hadn’t entirely thought out what came before what (the structure of this sentence is a living example of my not having an entirely linear mind).

I’m not a strict outliner for shorter-than-book documents, but I found a kind of middle ground that helps me organize my thoughts without feeling bound into a rigid outline format: rough flowcharting. Somehow it feels more fluid to me than outlining even though I suspect most outlining tools have most of the same features as the charting tools I use. Maybe it’s a visual thinker thing.

In the world of Macs, Omnigraffle is a great tool to just rapidly throw together a step by step chart. I probably underutilize it and there are some features I haven’t figured out–for someone who writes I am ironically also someone who fiddles first and looks at docs when I give up, most of the time–but the ability to just make a series of linked boxes with step explanations, move them around and relink if I need to, etc., seriously comes in handy. Even better, when I’m done, I can clean up the chart and make a more official-looking flowchart out of it to include with the document.

In my wanderings about the Web, I encountered Luis Suarez’s thoughts on an article discussing IBM’s rethinking of knowledge management. In part, the Knowledge Sharing issue makes me think of internal corporate wikis, where people tend to put things up according to the mythical beast named, “When I have the time,” and whose pages can often become out of date, forgotten, and not maintained. However, at times I have thought that part of this problem is the nature of the wiki itself.

As someone who’s spent a good portion of her life mastering word processors and being able to use them to get things to look exactly as she wants them, I tend to find wikis to be a rather cumbersome and frustrating experience. I’m a technical person by nature, so it’s not that I don’t understand how to use them, but by definition wikis seem to be very bare bones and don’t even have some of the useful formatting features that even most blog-posting software has. Trying to get a non-technical person to utilize a wiki can be a frustrating experience, which tends to in a lot of ways sabotage the wiki’s usefulness if you want everyone to add to it.

Part of my focus as Knowledge Manager at Splunk is capturing best practices, particularly the best practices around using Splunk. Gathering this information is a lot like researching a story, getting me to draw on:

• My own knowledge of how to use Splunk (hey, I’m not a guru but I have been using it for over a year now)
• Our sales engineers who encounter what customers want to do in the field
• Folks in support who hear a lot about what aspects of Splunk might be confusing, along with what folks are trying to do with it
• Our developers, who can give me those sweet little tips and tricks that I can share to help people do things more efficiently
• The folks in professional services, who definitely encounter what customers are doing in the field.
• Doc writers, who spend a lot of time explaining the nitty gritty of things and can often have some pretty interesting tips.
• And really anyone else in the company who might have something interesting to share.

Knowledge management is one of those strange terms that sounds like it was made up to make someone’s job sound more important than it is. However, the task of the knowledge manager is no small one: “capture” the knowledge within a company, whether across the board or in a vertical section such as human resources or technology usage. This process is multi-step, as you have to get a feeling for what there is to learn, who to go to in order to learn it, and then get it all down in ways that people can find and make use of.

In my case, I capture best practices in using the Splunk product to accomplish key tasks. Since I’m surrounded by experts in various aspects of using Splunk at work, this task involves a bit of mind-melding so I can learn and understand cool things that other Splunkers have discovered and then put them down in a way our users can follow. I’m sure that many users out there who have come up with some pretty interesting ways to efficiently utilize Splunk for their own purposes. If you’re one of them, I’d love to hear what you’re up to!