My previous blog entry was a follow up on flexible tools not being immune to being used the wrong way. My example was the danger of using a blog as a solution centre due to its news type nature, and rather using a wiki for an official solution centre.
In that example, wikis were described as a place to house explicit information, whereas the blog was more explanatory tacit based information, perhaps containing the know-how behind the solution.
Why is the blog entry important?
We may not be aware that the wiki solution page that we are reading, with a little altering, can also fix our current error we are troubleshooting.
The wiki solution page may not have much context, it’s just, “when you see this error, use this solution”.
The good thing about this is the page is succinct, we don’t want to be reading forever when we are researching for a solution.
But if that wiki solution page points to a blog entry about the experience of coming up with that solution, we may find we can apply these same techniques to our current troubleshooting.
This is the difference between explicit and tacit, with tacit know-how we learn, rather than just being informed.
It can be done without a blog
You don’t have to have a blog to share the anecdote about your troubleshooting experience, you could have a link on your wiki solution page to another wikpage that is a space for anecdotes about the solution. I just like the idea of a blog format listing a diary of experiences in time, like reading the daily news (again, this is learning by building anticipatory awareness).
Wikis vs Documents
So at the moment a wiki is preferable as a solution centre over a folder with a bunch of documents, as the website format is more usable, and one-click edit is very easy compared to having to launch a Word document in a Document Management System (DMS).
I guess a website feels like a sense of place, more a one stop shop compared to a document in a folder, a website just has more character, a front door, etc…
Know-how expressed as both explicit and tacit
Using the example above, the fact that people are taking the time to add a solution to a wiki is an act of sharing their know-how. Even though I have called it “explicit”, it blurs the line as know-how is usually synonomous with “tacit”. Perhaps it’s better to say that they share their know-how in the wikipage in a more explicit and summarized way, and they share this same know-how in a more tacit and personal way in the blog entry.
In fact I described the different ways to express information in an entry called the KM Core Sample.
Whether explicit (more formal) or tacit (more informal) we are happy that people are sharing at all, and as facilitators we are to concentrate on creating conditions for it to happen more often.
Wikis reach what procedures cannot forsee
Wikis are really valuable for people to pool their know-how for incidences where there are process failures and exceptions to the rule.
Some members of a Document Control team at my work use an Excel document (stored in the DMS) to list exceptions to procedures or just little steps that are not able to be known upfront in a procedure…we hope wikis will cover this space.
A procedure or a best practice cannot cover every context, and some clients and situations have different needs, which means we need to be able to make our workflow flexible and also keep everyone in the loop of what’s going on and how to do things that procedure’s simply cannot cover (they are thick enough already, and are not clairvoyant anyway).
Actually I mentioned this point in my KM Review article:
“These types of interactions enable learning to occur in a more informal and social way; a way we cannot cater for upfront; and a way that brings to light answers and workarounds for contexts and situations that arise, as well as those that already exist.”
There’s always a documented formal way in how to do things, and then there’s the way things are really done. I think a wiki is sharing and documenting how things are really done, they reflect the reality of where a manual cannot reach.
In a learning perspective this is the difference between formal learning (training) and informal learning (social on the job). I heard the other day that 80% of what we learn to do our job, is contextual on the job learning by experience, and 20% is from formal training. Put another way why do we spend 80% on training, when it effectively relates to only 20% of learning…this is based on the Pareto Principle of 80% of the effects come from 20% of the causes.
See more on a comparison of Learning 1.0 vs Learning 2.0.
BRP - Barely Repeatable Process
Ross Dawson explains the need to complement an ERP - Easily Repeatable Process, with a BRP - Barely Repeatable Process:
“Typically exceptions to the ERPs, anything that involves people in non-rigid flows through education, health, support, government, consulting or the daily unplanned issues that happens in every organisation. The activities that employees spend most of their time on every day.
Processes that often starts with an e-mail or a call. A process volume, measured by time and resource spent at organisations, probably larger than for the Easily Repeatable Processes.
These are mostly handled and organised - frameworked - by systems like paper based rules and policies, e-mail, meetings, calls and now in more modern organisations by wikis and other collaboration systems and methods.
Known by extensive loss of information (e-mails residing on HDDs), little knowledge acquired and reused (typical research says 70% of problems solved before without being known) and most of all, untrustworthy processes (oops, forgot to send that mail). In other words not an iota (well almost) of business process thinking or methodology applied to this huge untapped area of business processes.”
Not only do wikis offer a communal space to list these exceptions to procedures and workflows that occur due to unplanned events or just the plain reality of situational contexts, so we can do our work, but it can be seen as a knowledge re-use perspective. Once what was just “known” but not written down, is now flowing out of people’s heads onto the communal canvas.
When I’m in a urgent siutation I may not need to wait for a couple of people to get back to me with an answer, as they may have already shared a little scribble about an exception to a process in the wiki.
Ross Mayfield on the same meme:
“The way organizations adapt, survive and be productive is through the social interaction that happens outside the lines that we draw by hierarchy, process and organizational structure. The first form of social software to really take off to facilitate these discussions was email.”
“Most employees don’t spend their time executing business process. That’s a myth. They spend most of their time handling exceptions to business process. That’s what they’re doing in their [e-mail] inbox for four hours a day. Email has become the great exception handler.”
And again, there’s no knowledge re-use when we use a closed system like email to handle exceptions that procedures cannot cover.
Just say some of your work tools or applications don’t work on certain laptops
- you are never going to get a laptop that works seamlessly with everything, that’s life
- IT could create a wikipage listing tools that don’t work on a particular laptop model, or what you have to do in order to make them work
- I bet a communal effort could whip up a list in no time at all
These little things we take for granted usually come up when we are training someone new.
Like all of us, every job I’ve had I’ve been taught processes, but also been overwhelmed with things like “but on this day, or in this situation, you have to deviate from the norm and do this instead”. You usually hear about 10 of these exceptions and think, how will I ever remember what to do when I need to do it.
Part of my role is in Document Management support. When a project coordinator creates a project there are various post-duties we have to do for projects created with different templates. This is because the templates are being revamped, and procedures don’t cover these in-between stages. Once the new templates come in then everything will be more generic, but for now we need to know what to do different for which template.
There are even local differences, and these differences can’t be part of a procedure, so again this is where a wiki can be used to help you do your job.
The world is complex and contextual, and wikis help ease this situation by pooling the efforts of all the players. Wikis can also display patterns that emerge. If a manager reviews all the exceptions and workarounds in a wiki, it could reveal a usage issue, a bottleneck problem, a safety issue, etc…
Every plant site has procedures, but like everything else these procedures cannot be aware of every situation that can occur, or meet every need, so a site wiki for these heuristics, anomalies, band-aids, exceptions can be communally created by the people who actually work at the site.
A wiki would be doing a site manager a favour in the ways of safety, and possible new inclusion into the procedures…when exceptions become the rule. Now that I think of it, it’s kind of a distant cousin to an online suggestion box.
What I like about this is no-one is in charge or responsible to write such a document, it’s just stuff everyone knows or doesn’t know, so by everyone pitching in we help each other out, there is no effort on just one person, therefore it’s more prone to exist…plus none of us are smarter than the sum of us.
I’m sure everyone has seen a sign when they have travelled and stayed in hostels, that says “if toilet doesn’t flush, keep button pressed till it passes” or “first set shower hot water tap, then turn on the cold water tap”.
But we can’t have signs or post it notes everywhere, and you can’t easily put a sign on intangible things like a process step in using an online application.
Please leave a comment of an example of exceptions and workarounds in your job, that people know (or don’t know), but isn’t written down because it’s not someone’s job duty.
I expect some comments as I think this happens everywhere
In this post I describe using wikis for a solution centre and for an exceptions list, but there are endless ways to use wikis, go check it out.