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

[Pancho]

I am late to joining this Wiki QMS party, but I wanted to chime in on our success with using a WIKI to manage our QMS. We implemented TWIKI as our platform in 2008 and have been rolling with it ever since. Originally we were registered to ISO - our current registration is AS9100 C. There was lots learned along the way but for the most part it was relatively easy to feel our way along. Our registrars and auditors have all bought in and support the platform.

If I had to do it today I might not use TWIKI- the system has become somewhat stagnant the last few years - but without a doubt I believe a WIKI implementation of Quality documentation is the way to go.

I am happy to answer specific questions if you would like some feedback. Good luck!

Thanks, Skreis!

ProjectForum, the engine that we are on, has also stagnated over the last few years. Coincidentally, today we received a notice from the developer that he's discontinuing the product shortly, so we will be looking to port our content to another wiki. We started running ProjectForum almost exactly 10 years ago, in April of 2007. It was a good run. I'm definitely not looking forward to the move.

 

[kdjohannes]

I'm not sure I understand. If the engineers don't know what they will need, wouldn't offline browsing require downloading the whole wiki? Wikis might not offer this feature directly, but it seems an easy, if a bit impractical, requirement. Copy the whole terabyte of a database? Small portable disks can easily hold that several times over.

Any time you copy from the wiki (or any other repository of your system's documents, such as G Suite), be it the whole thing or only a document, you've created either an uncontrolled copy or a record. Make sure your personnel know how to handle to avoid misuse.

We often work at remote construction sites without internet. With or without internet, though, as part of our deliverables to the client, we prepare an "installation manual" that contains all procedures that are anticipated to be required at the site. But the procedures are copies or even adaptations of the live ones in our QMS. Once delivered, such manual is a record of the project. The live procedure may continue to improve in the wiki, but the record stays as it was delivered or approved, except when specifically revised through an agreed upon change. And despite it perhaps being not the most current info, the record is what we use at the subject site.

I guess offline browsing would require a download of the entire thing! Not ideal I know...I was wondering if there was a wiki software that worked in a browser or maybe was an installable software on a PC where it downloads content (similar to how a dropbox or google drive desktop app works). I think my question may be null and void if we use G Suite since it is capable of being accessed offline.

Good thought on creating a procedure on how to handle downloadable content - an issue we have now is not having the most current doc because it was whatever pdf was downloaded last time.

That manual idea is also cool. I'm not sure if we do that now (I don't deal with customers often), but it would be a good thing to start because of the benefits you stated.

 

[jam325]

I am interested in using a wiki for our QMS after reading through this thread. However, I wonder if Gsuite would not work even better than a wiki. It would allow for all the tracking and edits of a wiki with the user friendliness of your favorite word processor.

Does anyone know if Gsuite allows you to create workflows and things to make a CAPA system, and other tracking features that you get in the big paid systems? That is the only thing I am not sure of, and have not been able to find a great answer on.

 

[Jeffbbt]

Hi,
I am hoping to implement Confluence as a ISO 9001/13485 compliant QMS, starting, relatively from scratch. There are many different software options out there now, including Greenlight Guru, qmsWrapper, and one I am particularly interested, M-Files (with Compliance Kit). Surprisingly, I have not found any reference to M-Files on this website, and I find its document management system quite amazing. Unfortunately the price tag for the compliance kit is very daunting.

I think this thread will be understandably biased toward the wiki approach. I have already started to setup a Confluence/JIRA solution, but other members of the team have concerns about validating the system for ISO. Mostly around this requirement:

11.10 (a)
Compliant Electronic Document Management Systems must be validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.


Questions:
1) Has anyone recently set up a QMS, and tried some of the new software packages and Wiki's and chosen one over the other?
2) Has anyone been audited while using Confluence for 13485? What was done to validate the 'accuracy/reliability'? (Similar to previous posts, i have not seen a post explicitly stating validation of Confl. for 13485).
3) Has anyone tried M-Files for QMS purposes?

ps - Thanks for the looong thread with lots of great info

 

[steveha]

Thanks, Skreis!

ProjectForum, the engine that we are on, has also stagnated over the last few years. Coincidentally, today we received a notice from the developer that he's discontinuing the product shortly, so we will be looking to port our content to another wiki. We started running ProjectForum almost exactly 10 years ago, in April of 2007. It was a good run. I'm definitely not looking forward to the move.

hi Pancho, 4 years since I last posted (and now with a re-built Elsmar identity ), and at least 5 years since first stumbling across this thread which started me on my wiki journey!! Much to say about the experience, but for now I am keen to know what platform you guys chose, and how that switch-over went?? I am now having to face the same issue, due to an IT decision to get rid of inhouse SharePoint...

 

[Pancho]

hi Pancho, 4 years since I last posted (and now with a re-built Elsmar identity ), and at least 5 years since first stumbling across this thread which started me on my wiki journey!! Much to say about the experience, but for now I am keen to know what platform you guys chose, and how that switch-over went?? I am now having to face the same issue, due to an IT decision to get rid of inhouse SharePoint...

Hi Steve. We haven't moved away from ProjectForum. The software is running well and does everything we need. In 2 years we have not once needed tech support from the developer.

We did plan for the contingency. Our own developers wrote a set of "wiki-tools" in anticipation of porting to Confluence. But then decided against the port as long as ProjectForum keeps working for us. Saves on license fees and retraining of all users.

 

[steveha]

Hi Steve. We haven't moved away from ProjectForum… We did plan for the contingency. Our own developers wrote a set of "wiki-tools" in anticipation of porting to Confluence...

Thanks Pancho, interesting you were thinking of Confluence; how much work was done to look at replacement options? Did you have other systems you were looking at positively? What drew you guys to Confluence? In my case it is a done-deal, we are going away from in-house SharePoint, and that is that. Because we are an MS-aligned company, there will still be an IT-led preference for the replacement to be MS SharePoint in the cloud (O365). To be fair, once we had an external developer at a healthy hourly rate configure the blank-canvas OOTB SharePoint to have some wiki-type functions, over about 2 years of development (I explain my mental picture to someone, they go away and a month later come back with something approximating what I had in mind, etc) at twice the cost we could have paid for an immediately usable subscription platform like Confluence, the system is working reasonably well.

Another issue I will need to ponder, of no interest to an IT team, will be the taxonomy and "access structure" of the information itself, from the point-of-view of the staff using/consuming the information. At present the info has a "flat" structure, with each topic/web page in one large "bin" in alphabetical order - think like Wikipedia; what is the common name of the thing we do, piece of equipment we use, etc, then search either for a word in title of the topic/web page, or use a second search field which looks for words within content in the page itself. Where different aspects of a topic are performed by more than one Organisational team (eg, say, Medical Incidents, which our paramedics attend, and which our Operations Control Centre, a different team, does the callouts for), all information is in the one topic/web page. One source of the truth about "how we do Medicals". I hear some anecdotal feedback that staff are in some cases not interested in having "other teams'" processes in the same topic as their own. There is also a preference from trainers not to have a topic with information irrelevant to the trainee, where that trainee is a total noobie, and needs to just focus on one thing. This switch over to a new system may be an opportunity to consider providing the same information to users but in a different structure, which is why I was interested to see amongst this thread a copy of the Geometrica home or landing page, which provides a differently-structured initial interface to my own system. I am also keen to see any other examples other folk have implemented, it would be highly interesting!!. cheers!

 

[Pancho]

Thanks Pancho, interesting you were thinking of Confluence; how much work was done to look at replacement options? Did you have other systems you were looking at positively? What drew you guys to Confluence?

Our IT guys already use Jira, so Confluence seemed natural.

Another issue I will need to ponder, of no interest to an IT team, will be the taxonomy and "access structure" of the information itself, from the point-of-view of the staff using/consuming the information. At present the info has a "flat" structure, with each topic/web page in one large "bin" in alphabetical order - think like Wikipedia; what is the common name of the thing we do, piece of equipment we use, etc, then search either for a word in title of the topic/web page, or use a second search field which looks for words within content in the page itself. Where different aspects of a topic are performed by more than one Organisational team (eg, say, Medical Incidents, which our paramedics attend, and which our Operations Control Centre, a different team, does the callouts for), all information is in the one topic/web page. One source of the truth about "how we do Medicals". I hear some anecdotal feedback that staff are in some cases not interested in having "other teams'" processes in the same topic as their own. There is also a preference from trainers not to have a topic with information irrelevant to the trainee, where that trainee is a total noobie, and needs to just focus on one thing. This switch over to a new system may be an opportunity to consider providing the same information to users but in a different structure, which is why I was interested to see amongst this thread a copy of the Geometrica home or landing page, which provides a differently-structured initial interface to my own system. I am also keen to see any other examples other folk have implemented, it would be highly interesting!!. cheers!

Yes, we rely on and encourage a network of indices, menus and contextual links to get quickly from one page to any related page. Here’s the description. A process menu atop each page links to all process description documents. Then a “process navigation” panel to the right of each page immediately provides links to all other documents in the same process. These two lists of links in every page, by themselves, create an efficient Mandala network of knowledge. But that’s not all: Using the bracket-linking feature of wikis, links are also added within the content itself. And search is still there and available (though the links are usually quicker).

The result is that all the organization’s knowledge is really available at points of use.

 

[steveha]

... a network of indices, menus and contextual links to get quickly from one page to any related page... A process menu atop each page links to all process description documents. Then a “process navigation” panel to the right of each page immediately provides links to all other documents in the same process...

Yes, your Sample QMS Wiki Organization was the landing page I was referring to. Several routes to accessing the more detailed information. If you start with the old-school 200 page Operations Manual for all the things team X does (which I created probably 15 years ago at least - design a structure with several broad headings; the Chapters, then the subsets within those broad categories; the subheadings, then populate the actual content, then slap a T of C at the front, etc), then transfer all that good information into a flat structure of 500 topics/web pages with hyperlinking connections, people seem to suffer from a vague sense of unease, that they do not "know where they are" in the wider scheme of things, or that they are possibly missing something vital that may be on another page that they do not know about. A "way in" like yours, giving them a structure and hierarchy of information, will give more peace of mind, I now think.

I must admit to a bit of confusion when comparing the right-hand pane with the main larger left hand pane of your QMS home page; the entire right-hand pane is entitled "Management System", but its contents did not seem to match the 9 sub-sub-heads under the "Management System" sub-head in the main larger left hand pane?

If you, say, add a new sub-category of information, would your system functionality enable the various navigation menus to auto-update?

 

[Pancho]

I must admit to a bit of confusion when comparing the right-hand pane with the main larger left hand pane of your QMS home page; the entire right-hand pane is entitled "Management System", but its contents did not seem to match the 9 sub-sub-heads under the "Management System" sub-head in the main larger left hand pane?

Referring to the first illustration in the article, the “larger left hand pane” is the content of the home page of our system. When you go to any other page in the system, be it of the same or a different process, the content will be different.

The “right hand pane” we call the process navigation menu, or “nav”. It lists all documents that belong to the process that this document belongs to. In this case Quality Management. When you go to any other page listed in this pane, this pane will be unchanged. This is accomplished by “including” the QM nav in every page that belongs to the QM process. When you go to any page that belongs to a different process, the contents of this right hand pane will not be the same as in the homepage anymore, as it will list then the docs from that other process. For example, the third illustration in the article shows a Project Management document, and the nav is for the PM process.

There is another important “pane”: the main menu. It is the long string of two and three letter codes near the top-right of the page that starts with “QMS | SM | 5s | ...”. This pane doesn’t change throughout the whole document system. Clicking on one of these codes takes you to the home page of a process, where that process’s description is.

So, in summary, the content “pane” varies with every page. The nav “pane” varies by process. The main menu at the top of every page doesn’t vary.

The subheads under Management System on the left, well those from 3 to 8, are “Description” documents. Their contents describe how each section of the standard is implemented in our QMS. The illustration is from the 2008 version of the standard, the current one is a little different. These description docs are useful to auditors (internal and external), but not so useful for day to day work, so they were omitted from the navigation panel. This is why the right and left panes don’t match. (But i should mention that omitting docs from nav panels in our wiki is rather exceptional.)

Yes, your Sample QMS Wiki Organization was the landing page I was referring to. Several routes to accessing the more detailed information. If you start with the old-school 200 page Operations Manual for all the things team X does (which I created probably 15 years ago at least - design a structure with several broad headings; the Chapters, then the subsets within those broad categories; the subheadings, then populate the actual content, then slap a T of C at the front, etc), then transfer all that good information into a flat structure of 500 topics/web pages with hyperlinking connections, people seem to suffer from a vague sense of unease, that they do not "know where they are" in the wider scheme of things, or that they are possibly missing something vital that may be on another page that they do not know about. A "way in" like yours, giving them a structure and hierarchy of information, will give more peace of mind, I now think.

Indeed. Users do not feel lost in our wiki thanks to the two menus in each page: the main menu on top of the page and the nav pane on the right.

Also, the wiki’s “easy linking” by adding brackets to any word or phrase encourages links within the content. We train folks to spot potential useful links and create them.

If you, say, add a new sub-category of information, would your system functionality enable the various navigation menus to auto-update?

Yes. The navs are “included” content. This means that these panels live on their own wiki page, but are included into other pages through the wikis “include” command. When you update a nav page, all the pages that included it are automatically updated.

Furthermore, when you change the title of a page, all the links that point to that page in other pages are updated with the new name of the page. These auto-updates include nav pages. It is really easy to keep the whole system consistent and in-synch.