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

[mmagargee]

The problem with an attachment is that you can't define states for your workflow. You can for a page. Besides, using the attached document makes it more difficult to get the kind of collaborative editing that drove you to a wiki in the first place--you end up downloading, editing, and saving, repeat. You also miss out on other features. For example, we used the page properties macro to define ID numbers, approval groups, and versions on the (wiki page) procedure. That metadata can then be excerpted into tables with all of that information extracted automatically. If any of it updates, the tables also automatically update. By writing our documents as wiki pages, we now avoid the old practice of having a word document and an excel spreadsheet log of a group of documents. In that approach, one has to update the log after editing a word document. I now never update logs again because it is automatic.

Mike

 

[keldez]

Ok that's good to know - especially this early in the game. It's unfortunate I just wrote some SOPs prior to considering how much the wiki will control, but I suppose better now than after writing them all. :mg:
After posting those questions above, I laid out a space with Word uploaded/imported/copy-pasted versions of the same documents to play around with and see the pros and cons of accessing them in Confluence as well as sharing them with my group. It's making your comment above seem to stand out, though I'm just touching the surface at this point.
I'm definitely open to PMing/talking to anyone in this same boat trying to navigate new territory with already difficult objectives.

Thanks

 

[Pancho]

Great thread!
I am in process of starting from scratch with Confluence and Comala Workflows with a half written QMS established in Word Doc form. For those using a wiki, are you finding any hurdles in writing your documents within the wiki versus tying existing document files to the wiki?
For those keeping Word files in your wiki, are you seeing any pros and cons to this?
I'm trying to be as open minded as possible with having everything inside of the wiki. It's just difficult with the ways of old so ingrained, and not taking any baby steps with this project. When in doubt, I look at the requirements and not old practices
Thanks

I agree with Mike. It is best to have the documents on wiki format.

Besides the improved collaboration, one huge advantage of the wiki format is easy linking. You can simply bracket around the title of a document you are referring to, and a link is created. If your users get used to linking contextually, pretty soon you end up with a small world network of documents, where all related information is a click away. This improves tremendously your document's accessibility, your system's usefulness and, ultimately, your company's quality.

 

[prady2581]

Ok that's good to know - especially this early in the game. It's unfortunate I just wrote some SOPs prior to considering how much the wiki will control, but I suppose better now than after writing them all. :mg:
After posting those questions above, I laid out a space with Word uploaded/imported/copy-pasted versions of the same documents to play around with and see the pros and cons of accessing them in Confluence as well as sharing them with my group. It's making your comment above seem to stand out, though I'm just touching the surface at this point.
I'm definitely open to PMing/talking to anyone in this same boat trying to navigate new territory with already difficult objectives.

Thanks

Hi Keldez,
I suggest below some points which you can think of incorporating while designing the Wiki.

1. Have a central Index page with Headings, sub-topic --> links , and back-end configuration in such a way to create workspace basis on the topic / sub-topic (
Eg :
Department wise - Workspace : Restricted access with defined / required staffs (SOP, Work Instruction, How to Articles, etc).
Common - Workspace : Access to larger access - common workspace (Measurement, KPI, Analysis/ CAPA actions, and Continual Improvement, templates )

2.Configuration in back-end to enable settings for Records, compliance, workflow, approval , reminders (requirement documents) and then tag it in that way (Users who will log in will know that these those documents which requires.

My personal experience while system is definitely great to use but over a period of time it grows huge, pages scattered over, same entries found at different pages.
Then it becomes a very hugh effort and time to identify and streamline this and we think " We should have thought and done this at design stage ".
This is my suggestion, there can be better ways of doing this. Please let us know how you do this.

 

[keldez]

So I've set up my "top-level" part of the wiki with SOPs and respective forms, as well as customized Comala's workflow to operate to our needs. All of your input became more and more apparent as the wiki (Confluence) started to make sense and I wasn't so overwhelmed. Now I'm setting up Product areas as well as CAPA, Complaint, etc, and navigation is a breeze.
I think one thing that's been discussed that I'm still having trouble swallowing is full integration of documents, Excel specifically. We have some pretty elaborate templates for FMEA and Risk Analysis to name a couple, with two products in early development. Did those of you that use Confluence ditch spreadsheets and do everything embedded; did you attach them as a file, download to revise and re-attach - leaving you with an exception to the Workflow operation? Maybe I'm over-thinking this. I'm just not entirely impressed with Confluence's level of detail when it comes to writing/formatting, let alone creating complex spreadsheet style documents within.
I'm curious to know how you all have approached items like this and handled revision control, or any other hurdles that appear to be exceptions to the general rule of the wiki's abilities. Thanks as always!
If anyone is in the "deer in headlights" stage of setting up Confluence or workflows feel free to PM me... I think I'm just out of that stage and would be happy to help.

 

[mmagargee]

Hello keldez,
We aren't fancy with workflows because the intention is to capture state changes on pages, approvals, and approval dates. We do make use of metadata within those workflows that later populate reports. The workflow allows the setting of metadata values on a parameter tab which is pretty handy. So for NCMR, we have a drop-down menu for disposition allowing: RTV, repair, scrap, use as is. This value then is placed into a summary table using the Reporting macro. Other metadata examples include: cal interval (in the cal log), type of tool (cal log), lot number (incoming inspection). Believe it or not, there is some limited graphical functionality using the Reporting macro. I have placed a screen shot of the states of all of our open CAPAs.

As for excel integration, we are dealing with the issues you are finding. For example, you have formula inputs that drive either reports or graphs. There really isn't a way to integrate that kind of functionality into Confluence because the excel workbook can't gather that data automatically. You may also have found that cells containing formulas do not display those values when you are viewing the spreadsheet in a Confluence page with the embedded excel content macro. In that case, the page just becomes an accessible storage place that multiple users go to access that spreadsheet.

Mike

 

[keldez]

Thanks Mike,
We found an Excel/spreadsheet plugin that seems to work pretty well. You can embed it within the wiki and it will handle at least the basic functions and formatting that you can do in Excel. It is available for trial, so you might benefit from taking a look at it. I know it's a little beyond the scope of the function of the QMS as you say. We have some existing tables and matrices that are just so "busy" and we want them that way, and we want to bring them into the wiki without being attachments. It seems we've accomplished it this way. I'll post some updates if things change, as we're in our infancy with trying this.

Another question I would like to put out there regards capturing document training via the wiki. Let's say you create a document and have approval captured by your workflow for individuals "A", "B", and "C" - that's pretty straight forward. Now this example of a document needs to be trained to by not only A, B, and C, but individuals D and E as well. Do you handle this by the task system in your wiki or something more formal? Do you define up front training "profiles" based on the document type and note anything like this in the approval stage? I have several ideas for document training, but none of them seem to be home runs. I would appreciate any advice on this subject. I think where I struggle is even though you can assign tasks to review docs to any individual and have proof they've completed the task. I'm trying to picture in my mind how to "corral" this information in a training record with the wiki. If I have to do it manually, then I can live with it. Thanks in advance.

 

[mmagargee]

Keldez,
I'd like to take a look at your excel plugin. Which one are you using?
Thanks,
Mike

 

[keldez]

Mike,
It's called "Spreadsheets for Confluence" and has a green hexagon for a product symbol. I still haven't pushed the limits of this plugin, as I'm more getting content into the QMS at the moment. Only concerns at this moment I've run into, is it's a little slow, and with the specific spreadsheet I embedded, it said it had some script issues, but I saw no lost content.
To use it, you create a blank page, and simply insert it as a macro under "spreadsheet". At that point you can start a spreadsheet from scratch or upload an existing file and it will translate over. You might have better luck starting from scratch where feasible, as I suspect translating may be the source of some of the bugs I'm experiencing.
I'll post any updates if anything really stands out in either positive/negative direction. At $10, you're not losing much to see if it will benefit your application. Good luck!

 

[Pancho]

Another question I would like to put out there regards capturing document training via the wiki. Let's say you create a document and have approval captured by your workflow for individuals "A", "B", and "C" - that's pretty straight forward. Now this example of a document needs to be trained to by not only A, B, and C, but individuals D and E as well. Do you handle this by the task system in your wiki or something more formal? Do you define up front training "profiles" based on the document type and note anything like this in the approval stage? I have several ideas for document training, but none of them seem to be home runs. I would appreciate any advice on this subject. I think where I struggle is even though you can assign tasks to review docs to any individual and have proof they've completed the task. I'm trying to picture in my mind how to "corral" this information in a training record with the wiki. If I have to do it manually, then I can live with it. Thanks in advance.

Keldez,

We don't use wiki logs to record our training. We do our training in four "streams", that we document as explained below:

1. New hires
2. Yearly reviews
3. Outside training
4. Major changes to the system

Every position in the company has a list of documents with which every person in that position must be trained to. Training on general documents and procedures is conducted by a person in HR for new hires. Training on position-specific documents is conducted by process owners for new hires and based on need. Attendance forms or quiz forms are filled out and saved in employees' files (not on the wiki).

At least once every year (after their year of hire) employees document their review of all documents related to their position on a signed "retraining form" that, again, lists the position's documents. This form is filed in the physical employee file. Since most of our employees actively refer to their documents in doing their jobs, this is mostly a formalism.

Occasionally we hold seminars that complement our internal documentation, such as topics in project management, contracts, safety, problem solving, and technical subjects. Such training is planned in the quarterly management reviews, and documented in KPI reports, in subsequent management reviews, and in employee files.

Changes to documents in the wiki are automatically notified to the process owner and those folks that subscribed to that document. This is sufficient "training" for most small changes, and we do not require documentation of those. For larger changes, process owners ask the affected folks to acknowledge the change in the CAPA database through a comment before the action can be marked "resolved".

That's how we handle our compliance with 6.2.2 of the ISO 9001:2008 standard. Not really very automatic, but it has worked for us well for a few years now.