Wiki in the Workplace

It has been nearly 10 years since founding an initiative in the company I formerly worked in called “JetWiki”.  JetWiki was a cutting edge idea in it’s time and was a fair decade ahead of it’s time.

The online encyclopedia,, was maturing, even though the occasional radio show host would still refer to it as “the site where you can create a page about yourself”.  But the real innovation of was the engine that the website ran on: MediaWiki.

MediaWiki used PHP to server-side generate dynamic web pages based on user query and database lookups, but extended further to allow the user to interactively edit the very page they were viewing.  Any user could have editorial responsibility over the content to create an organic and varying information source for a larger audience.

I wanted to try an experiment with a small team.  I found an old machine that was being discarded (a Compaq Evo D31VM)  and installed Debian Etch.  I also installed Apache, PHP and MySQL to provide what we today called the ‘LAMP stack’.  I installed MediaWiki above that and it simply worked.

Three users were initially created, but at first I was the only one who used it for the first month.  There was a very good reason for that: I didn’t exactly know the optimal method for using this tool.  I wanted to access and store information where the path to the data was intuitive and required a minimum of mouse clicks.

This wiki was tasked with tracking maintenance items in a 70,000 square foot manufacturing facility that consisted of two lines and two batch-work stations and three additional departments.  I was unsure if I should sort the items by geographic location or by function, much less, how each paradigm can be optimally implemented.

My solution was that I did “All of the above”.   I used both paradigms and decided to see which one I favored after a few weeks of usage.  The geographic paradigm ended up staying, but only in the context of the building as a structure.  The ‘function’ paradigm was a hierarchy of subsystems where encompassing descriptors for page names were given, such as: “Line 1” or “Light Assembly”.  Beneath these descriptors, were entries that could be followed by clicks where “Line 1” follows with “Washer Stage 2” follows with “Exhaust Blower” which loads a page that describes the maintenance history and Minimum Tool List for servicing this subassembly.  A few clicks leads the operator to form a ‘go-kit’ to service the equipment in a single trip across the plant floor.

The beauty of a wiki is also it’s challenge.  It is a clean slate that you can define.  In creating this wiki, you must be prepared to admit that your present method may need to be changed.  The users of the wiki must be permitted to make decisions over how they use it, but it is just to create a template as a starting example.

As I am writing this, I am also writing a book on the topic.  This will be available with my training seminars or from Amazon.  When it is complete, the information will appear in this paragraph.