I started experimenting with wikis at TradingPartners a little over a year ago. A wiki could help us, we figured, with sharing up to date category information across a team that is spread all over the globe. (How to best make sure when Joe in the USA ran a sourcing project for castings that he would know that Jane had recently been working on something similar in China, and would be able to benefit from her experience?)
A wiki seemed like a good fit as:
-
it would be editable by anyone in the business
-
it would be accessible to everyone in the business over the web
-
it would be fun for people to use
-
the necessary investment would be negligible
So we tried out various wikis and settled on mediawiki. Launched it to the business early 2007 in workshops at which staff excitedly brainstormed ideas of what kinds of information they’d like to see on there…
Then we left it to see how it evolved. Fast forward 9 months and this is what we had:
-
Lots of marketing material – case studies, brochures etc.
-
Some customised user pages with pictures of people, their backgrounds and interests.
-
Standard templates, training materials etc.
-
Some category information. But, interestingly, this had not been put on by auction managers themselves, but by self-appointed editors who were collecting the information and uploading it.
In reality, despite the initial enthusiasm for a site that “anyone could edit” was replaced with the more realistic understanding that in order for it to be of any value, “someone” would have to do the actual editing!
It brings home the fact that in wiki- or forum- style communities, the number of people who contribute information is a fraction of those who consume information. The templates and marketing information all went on because they only relied on a small number of interested editors to make the wiki site definitive. Some people – either those who find this sort of thing interesting, or those whose managers find this stuff interesting, were prepared to update their own user pages. But changing the process of running a sourcing event so that all the relevant information is entered into the wiki repository after the event for the benefit of others in the business? Now that’s a whole different proposition. And it begs a number of questions like: how do you make sure all the relevant information is loaded onto the wiki (and you don’t miss out a crucial piece of information which is blindingly obvious to you but which might not be obvious for other people)? How do you ensure that people who are consuming the information are looking at the right page (paper bought for resale might not be the same as paper bought as an indirect, for example)? Etc, etc.
Extrapolating from this experience has taught me something important about any attempts to build a procurement community online: The procurement world is sufficiently small that you can’t expect a critical mass of people simply to contribute useful information to any one central repository. Iasta’s e-sourcing wiki is an example: 7,500 odd hits so far but check the recent changes page and only a small number of names appear as contributors. Perhaps there’s a generational element, with newer buyers more open and older buyers more reticent. That would be the thrust of articles like this one at Tech Crunch, but I suspect the generational piece will turn out to be just a small element in the overall equation, especially when applied to business information. Seems to me that the best way to share useful information in the procurement space is by inferring it from what people are actually doing, rather than treating it as an activity in its own right. Of course, exactly how to infer auction best practice (for example) from successful auctions people have run rather than via a self-contained documentation exercise is another question in its own right which, I guess, nods towards the Semantic Web – if that ever gets off the ground. More questions than answers, in other words.
A coda: what did we do with our wiki in the end?
Well, we kept it for two things:
-
Community building by people building their own pages and telling a bit about where they come from and what their experiences are. This is becoming part of the process for all new starters and is quite a neat way to quickly get a feel for who you should be talking to about what.
-
An intranet-style piece holding standard templates and marketing materials.
Regarding category information: We could have gone down the traditional Enterprise Software Change Management route. This would have gone something like “come on, the eAuction managers aren’t updating their category information. We need to mandate it as part of the process and keep beating them over the head until they accept it”. Or we could have gone down the Enterprise Software Budget Busting route. This would have been something like “the central repository won’t work without an editor. So let’s hire someone to maintain the wiki and have that person interview, or otherwise, extract information from the eAuction managers as they go about their daily jobs”.
We took a different approach, which I call the Going Back To The Objective approach. We asked “what are we trying to achieve here?”. The answer was: “help eAuction managers keep up to speed with what their colleagues are doing”. Next question: “Is there an easier way to do this that doesn’t make them do extra typing?”. Answer: “How about just letting everyone have query access over our history of sourcing events with some pre-defined reports so people can easily look up who has the most experience in category X and which eAuction managers have auctioned category Y most recently. That way they can just pick up the phone and easily get hold of all the relevant information, plus all that intangible, invaluable stuff you only get through talking to people”. The tool then becomes something to encourage, and facilitate, people to talk to each other. Not an end in itself. Boom. Sometimes the simplest solutions are the best.
?
