MediaWiki case studies/Five Guys

This is a case custody about the experience of Five Guys using MediaWiki as corporate wiki software.

Background
The company is a privately-held, fast-growing restaurant chain with more than 1,000 stores. Each staff accountant is responsible for taxation, rent payments, etc. for all the stores in the states under his purview (e.g. California for one staff accountant; Connecticut, Kentucky, New York, and Ohio for another; etc.). The company has a shared drive containing a variety of files and schedules for the different departments.

Problem
As each new accountant is trained, he maintains his own notes on procedures, etc. and his own cheat sheets (spreadsheets of useful information), either in hard copy or on personal MS Word and MS Excel documents. As the notes become more lengthy, the Word documents become unmanageable, as it becomes harder to find information in them.

A few procedures are on the shared drive, but most are not. Some procedures are also established or described by emails that are sent out, whether to individual accountants (e.g. in response to questions) or to the team; however, new accountants will not have received emails sent before they came on board.

Solution
Therefore, a wiki was created to store information about stores, personnel, state taxation, etc. as a handy reference. For the soft launch, login credentials were given to two staff accountants, the accounting supervisor, and the assistant controller.

Benefits
The wiki is well-suited for storing information about procedures, since it allows for collaboration; categorization; cross-linking of articles; accountability via revision histories; reverting back to previous versions in the revision histories; centralized tracking of changes; and other useful features. Having separate articles for each topic is easier than dealing with a voluminous Word document of procedures.

Limitations
Setting up the wiki has been challenging because there isn't a detailed procedure on MediaWiki.or for setting up a "tricked out" wiki configuration, with the more popular extensions, gadgets, etc. installed and working.

It is desired to make the wiki opaque to the general public, and only reveal its name, etc. to logged-in users. So far, we have not found a way to do this, other than by changing the $wgSitename to something non-descriptive.

The wiki is poorly-suited for maintaining information about stores, because of the duplicative labor informed. E.g., information from, say, the "Store 310" article will need to be separately added to the "List of stores", "List of landlords", "List of district managers," etc. articles. MediaWiki tables are also not as easy to work with as MS Excel spreadsheets. Using Semantic MediaWiki might alleviate these problems somewhat, but it's questionable whether it's in working condition at the moment or if anyone is maintaining it. A system like Wikidata might also work, if the software is ready for being used on non-WMF wikis.

Administering the wiki also present challenges. Ideally, the wiki should be part of the company Intranet, but then the maintenance responsibilities would need to handed over to IT, and the accounting team would need to submit requests to them to get tasks done such as running maintenance scripts, changing configuration settings, etc. It would be if MediaWiki allowed for more of these tasks to be done through a web interface.

MS Word document formatting needs to be converted into MediaWiki markup before the content will look decent. Perhaps there are automated tools for doing this, although wikilinking will still need to be done by hand. Some staff lack experience editing wikis, so a WYSIWYG may be helpful, if there's one out there that's ready for prime time.

__NOINDEX__