Wikis, User-Generated Content and Procurement Communities

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:

  1. it would be editable by anyone in the business 
  2. it would be accessible to everyone in the business over the web
  3. it would be fun for people to use
  4. 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:

  1. 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.
  2. 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.


Posted in:

4 responses to “Wikis, User-Generated Content and Procurement Communities”

  1. Alan,

    Nice write up on wikis and I agree with your assessments. When I launched esourcingwiki, I even tried to forecast what I thought would be the eventual reception. You have correctly described this with:

    “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.”

    Ultimately, I thought this would be the result of our public wiki too, even though I kept my presumptions mostly muted:

    That was not our goal though, we simply wanted to embrace a new delivery model because, frankly, most “white papers” suck. The ESW traffic has steadily grown and is still unique, but it will never have the collaborative nature of true social networking. I am glad we tried it out and have what we really wanted, which was a deep repository of free content on best practices, even if it does not become a community driven process.

    Thanks again, the analysis is very accurate and interesting!

    PS- We use a minimum of 15 internal wikis for operational purposes and they are used religiously by our global team.

  2. Thanks for comment David. I really like the way you’ve integrated esourcing forum and esourcing wiki into the new website.

    15 wikis! Wow, that is impressive. How come so many? Presumably these cover stuff like requirements gathering and new product specifications as well as category and process knowledge?

  3. With small teams in a private wiki we have seen everyone contribute, replacing the need to e-mail agendas, meeting minutes, issues lists, etc.. We use them for all of our client projects as well as internal projects and find them very useful. We have about 100 wikis active on Central Desktop to deal with different clients and projects. Since wikis dissolve authorship while blogs and forums preserve it, we have found them most useful for teams that are measured on a common objective or outcome. I would amend your first four rules for what makes a good fit for a wiki as follows:

    A wiki seemed like a good fit as:

    1. it would be editable by anyone on the team
    2. it would be accessible to everyone on the team over the web, with a WYSIWYG editor
    3. it should be a practical alternative to e-mail for the team
    4. people should be able to edit pages immediately

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: