Interesting Discussion Using a Wiki to implement a Quality Management System (QMS)

[Tagin]

I looked into various wiki software and was rather disappointed in all of them. Most were projects which have been since been abandoned, and while Mediawiki may be the largest, it is probably the clunkiest thing around, and support is next-to-nil. BlueSpice makes Mediawiki more of a robust QMS wiki turnkey solution, and offers support, but comes at a cost.

I've since looked into the possibility of using WordPress as the foundation, because of its ecosystem: it has a very, very large install base, is well-supported, kept up-to-date, and there are many 3rd-party addons for it. I found a plugin, BWL Knowledge Base Manager, which provides a nice wiki-like functionality, with dynamic table-of-contents generation, hierarchical categories, tags, upvote/downvote options, date/time/author stamp, comments, etc. It also offers a form for asking new questions not already in the wiki.

I like the idea of the feedback/user engagement possibilities of the votes, comments, and forms to prompt new or updated articles. Using tags to identify clauses that apply to each article, one can then auto-generate a table of contents of tags which link to the tagged content. This could help identify gaps and/or make audits smoother. WordPress is also very friendly toward embedding multimedia, so including images, videos, etc. in articles is straightforward. I'm still testing the waters, but so far WP + BWL KBM seems like the direction I'll go.

 

[QATN11]

Since my original post 8 or 9 years ago on using a wiki to house documented information supporting a QMS, two significant things have happened. The first is ISO 9001:2015 was finally realized adding some additional flexibility to how much DI is required and in what format and secondly, Microsoft has made vast improvements in SharePoint 365. In 2011, SharePoint was mostly useless IMO. Had these two conditions been viable then, I wold not have considered documenting a QMS using Wiki, ColdFusion, or WordPress. I suggest looking at SharePoint. The are some interesting demos on Youtube specific to SharePoint for documenting a QMS

 

[John Broomfield]

And here is a briefing on the newly developed SharePoint:

Introduction to SharePoint Online - 06/07/2019

 

[Tagin]

Since my original post 8 or 9 years ago on using a wiki to house documented information supporting a QMS, two significant things have happened. The first is ISO 9001:2015 was finally realized adding some additional flexibility to how much DI is required and in what format and secondly, Microsoft has made vast improvements in SharePoint 365. In 2011, SharePoint was mostly useless IMO. Had these two conditions been viable then, I wold not have considered documenting a QMS using Wiki, ColdFusion, or WordPress. I suggest looking at SharePoint. The are some interesting demos on Youtube specific to SharePoint for documenting a QMS

SharePoint's wiki functionality is still pretty weak. It still can't even auto-generate a table of contents for a page.

 

[rogerpenna]

Sharepoint has a monthly cost PER user. I hate systems liket these. You may have people that barely use Sharepoint but once in a while might need to, and still you will pay the same fee every month for them.

If you need to make some documentation accessible to all employees, it's even worse. I like systems which work on Concurrent Users method of billing.

 

[rogerpenna]

I see that most of the time here, when people talk about a Wiki to implement a QMS, they are considering the KNOWLEDGE BASE of the organization... Procedures, Processes, Policies, etc.

A Document Management System required by ISO however goes far beyond, doesn´t it? It is about controlling all documents in the company.
Meaning... controlling contracts, projects many records, etc, etc.

What is the solution? A Wiki style for knowledge base and the other documents controlled in a standard style DMS?

 

[Kronos147]

Roger, your point about SharePoint is well taken.

I have been using lots of spreadsheets at our shop. Examples include the master document list, the NCR log, and the standard and specification index.

If someone is looking for a document, the may open the master document list. Every document title is a link to the live document.

If someone is reviewing the NCR log and chooses to review the detailed record, the NCR log number is a link to the Corrective Action form (where applicable, and OFI may exist only in the log, but I digress).

If someone is looking at a specification on a drawing, example, MIL-C-5541, the can look in the specs and standards index, see that it has been superseded by MIL-DTL-5541, and there are links to current and past revisions.

Maybe saying it's a Wiki is the incorrect description. Make it effective, and make things link when it makes sense, even if just with specific verbiage (quote book on top bookshelf accounting, for example).

 

[rogerpenna]

Ok. Thanks Kronos. But I don´t know how we would be able to adapt it to our document system, where there are too many new documents all the time.

We have like 5-10 new contracts per month, and most contracts result in at least 100 different documents, many of them coming from the client.

A single multi street contract for a neighboring city, for 30 streets, had a total of over 150 DWG files for projects...

Or maybe I am not understanding how the system works. I would throw all those 150 DWG files there and it would automatically create links for them, names, would create the codes, etc?

 

[Kronos147]

Ok. Thanks Kronos. But I don´t know how we would be able to adapt it to our document system, where there are too many new documents all the time.

How about this?
Each project gets a folder. Keep a log that links to the project folder.

Potentially, you could also set up a default folder structure. You could copy empty folders into each project such as "Drawings" and 'Correspondence' and 'Deviations'... and reference this practice in the work instruction or procedure.

 

[Pancho]

Ok. Thanks Kronos. But I don´t know how we would be able to adapt it to our document system, where there are too many new documents all the time.

We have like 5-10 new contracts per month, and most contracts result in at least 100 different documents, many of them coming from the client.

A single multi street contract for a neighboring city, for 30 streets, had a total of over 150 DWG files for projects...

Or maybe I am not understanding how the system works. I would throw all those 150 DWG files there and it would automatically create links for them, names, would create the codes, etc?

hi Roger,

A wiki can be organized as a connected network of pages. In such a network you need only a few clicks to get to any document even if you have hundreds of thousands of documents. It can grow to accommodate new contracts, projects, products or offices, and the thousands of new documents each of those new logical entities would create.

Wiki pages can be linked in the most useful ways. For example, if you have a directory of contracts, each contract can become a link that takes you to a sub wiki with the documents for that contract. Within that you can have links to the agreement itself, to the project’s contacts, a list of your deliverables, a list of the client’s deliverables, etc. Each list, in turn, takes you to pages with relevant documents. If you include navigation menus or panels in your documents, you can jump from any document to any related document. Drawings can be stored in the wiki as easily as other documents.

The wiki does not build itself. No organized collection of documents does. You will need procedures that specify how to add pages, including adding them to the appropriate indices. You will need to train folks on such procedures. Once you have that basic infrastructure, though, a wiki growth becomes second nature, and documents are always reachable.

We have an article that explains to our clients how the wiki helps my company deliver their project. It might be useful to help understand how a wiki may be used to organize a contract-oriented service. You can find it here Project Execution Overview. As far as the organization of the QMS within the wiki, you can find it in this other article: Sample QMS Wiki Organization.

I hope this is useful!