Document Control using Wiki - Cannot Create all Documents as Wiki Pages

C

CATERAF

#1
Hi

I'm calling to attention all those who have know how to achieve ISO 9001 certification using a wiki.. I have a bit of a dilemma.

For the organisation I'm working for we are trying to achieve certification and have a wiki AND a server.

To just use the wiki for document control seems easy (http://articles.geometrica.com/488.html), but our problem is that we're using some documents on the wiki and some not.

To explain further, we cannot create all documents as wiki pages because the format doesn't comply with many requirements for tenders, or because the wiki has restricted formatting capabilities, or the documents are from an extra source, etc etc.
Hence, we've got lots of documents that are not wiki pages.
The problem then comes with how we go about controlling the upload and download of documents to and from the wiki (if we were to drop the server and store everything on the wiki). Ideally we'd love to hit download, it opens a very sophisticated editor and we can then edit the document (including all fancy image-based marketing documents) and then the wiki automatically reuploads the documents to the same location once the user is done without the user having to do any 'save as' things. Sadly, i haven't found a way to manage that as yet.
The other problem is what to do when people are busy working on the document and haven't uploaded the new one yet. Or, the new one is a work in progress and waiting for approval so people are busy using the old one.

Any ideas how to deal with these problems?

I'm stumped.

The closest I've come to is create a wiki page per document and then putting the server location where the downloaded document should be stored and then when the user downloads the document, they have to save it to the specified file. Then, if someone is already using it it'll already be saved there so windows will pop up and ask the user if they want to 'overwrite, append, cancel'.. this would be clue 1 that someone is already using the file. Clue 2 would be if they tried to open the file in the document, it'd say "someone else has this open, would you like to open a read-only copy, or edit and merge changes later" etc.
Then,after editing, you'd upload the file back to the wiki and delete it from the server. This is too messy though and too many instructions for people to follow for every document they download - that's not controlling quality, that's a mess in itself (and i'd have to submit myself a preventive action form!). E.g., what if they forget to delete the file from the server? then it looks like someone is using it when noone is!

If you have ANY advice that'd be extremely helpful!

Thanks
 
Elsmar Forum Sponsor

Wes Bucey

Prophet of Profit
#2
Couldn't you make links to "Associated Documents" in the "cover sheet" which IS a WIKI page? I frequently see links in WIKIPEDIA to websites which contain original documents.
 
C

CATERAF

#3
Couldn't you make links to "Associated Documents" in the "cover sheet" which IS a WIKI page? I frequently see links in WIKIPEDIA to websites which contain original documents.
Yes, there is the option to link to a document external to the wiki. However, we then lose track of versioning and the changes that have been made.

If the document is stored in the wiki, newer versions can be uploaded on top of the older versions and there is room to comment on version changes.

If we were to do something similar on the server, we would then have a million copies of each document (even though only some are released) which can get confusing, and then the link would have to keep being changed on the wiki. Also, there is nowhere that it states what changes were actually made.
 

Pancho

wikineer
Super Moderator
#4
<snip> Any ideas how to deal with these problems?
Yup, when many of your docs are not wiki pages, document control becomes nightmarish, whether you have a wiki for the rest of your docs or not. You also lose another key benefit in the non-wiki docs: easy linking.

But given your constraints, Confluence has an "office connector" that lets you view and edit office docs from within the wiki. Another alternative may be Sharepoint. With it, the sharepoint wiki could be set up as a simple navigator, but most of the document control is done by Sharepoint without help from the wiki.

What wiki engine are you using?
 
C

CATERAF

#5
Yup, when many of your docs are not wiki pages, document control becomes nightmarish, whether you have a wiki for the rest of your docs or not.
Yes, seeming very nightmareish right now.

There doesn't seem to be a way to be able to have a tender or any of our marketing posters or drawings as wiki pages though. How do you deal with your marketing documents etc?
I'm considering just having one wiki page per document. All linking can then be done to this page rather than the document. A little more tedious, but it's a workaround. We'd still have to download, edit and re-upload though which is a messy process.

We're using mindtouch which seems like a good wiki so far except that they're no longer upgrading it which means it could go out of date any second now. Unfortunately we have already created a LOT of pages over the past 4 years so to change to another wiki could be a very tedious process.

Also, while I have you captive -how did you differentiate between reports and documents? It seems like some ISO-certified companies have reports and documents separate. For our wiki though we're trying to make it more staff-friendly and therefore putting everything into 'departments'/'disciplines' rather than 'document' vs 'report'.
Also, do we say we store reports indefinitely? Otherwise how do you go through and get rid of all the reports.. there are so many! Is it sufficient to just say "indefinitely" store reports, but if they're printed they will be shredded after XX time?

Thanks for your help - much appreciated!
 

Pancho

wikineer
Super Moderator
#6
There doesn't seem to be a way to be able to have a tender or any of our marketing posters or drawings as wiki pages though. How do you deal with your marketing documents etc?

I'm considering just having one wiki page per document. All linking can then be done to this page rather than the document. A little more tedious, but it's a workaround. We'd still have to download, edit and re-upload though which is a messy process.
Our marketing glossies are on our wiki as pdfs, but we do prepare and deliver our proposals on wiki. The formatting is not great, but we have a button that runs a script that converts the wiki-format to a pdf.

For many docs we also do the download-edit-upload dance. For example, in each project we have a client-accessible subwiki with a page that contains the list of submittal drawings (index). This list has links to a front-cover wiki page for each submittal, and each of those wiki pages has links to individual pages holding each of the various revisions of drawings, as well as client comments during the approvals. This preserves all versions of shared docs and makes them accessible to our client. The index page at the front helps in keeping straight which are the latest versions of the drawings.

The process of downloading, editing and re-loading is indeed a bit tedious, but we go one extra step: we upload not only the source file, but also a legible screenshot or image of the document. Most folks only need to consult the document without editing, and having a screenshot saves them the trouble of downloading and opening in the source app.


We're using mindtouch which seems like a good wiki so far except that they're no longer upgrading it which means it could go out of date any second now. Unfortunately we have already created a LOT of pages over the past 4 years so to change to another wiki could be a very tedious process.

Also, while I have you captive -how did you differentiate between reports and documents? It seems like some ISO-certified companies have reports and documents separate. For our wiki though we're trying to make it more staff-friendly and therefore putting everything into 'departments'/'disciplines' rather than 'document' vs 'report'.
Also, do we say we store reports indefinitely? Otherwise how do you go through and get rid of all the reports.. there are so many! Is it sufficient to just say "indefinitely" store reports, but if they're printed they will be shredded after XX time?
Not entirely sure of what your "reports" are. If they are records, then consider the following:

One of the records that we maintain that belongs to our Project Management process is a list of all active projects. That list consists of links to the project-specific forums (sub-wikis).

We file all project records in these project-specific wiki spaces, and they are kept subject to our Control of Records procedure, which spells out what to do with them when. These records are produced by the different processes in our organization as they apply to a particular project. They include the submittals list I mentioned above, as well as the project drawings, design reports, quality dossiers, installation manuals, etc., etc. Many of them aren't wiki-format docs.

QMS documents (procedures, work instructions, process descriptions, and only a few non-project records) are kept in the QMS wiki. These documents are added to special navigation pages for each process. You can find how we organized these here: Sample QMS wiki organization.

Hope this helps!
Pancho
 
C

CATERAF

#7
Thanks so much Pancho! You're being very helpful!

Alright, so I think I'm clear on how to deal with the documents that must be attached. It's good to know that you're using a very similar system. This also solves a few other problems that I was having with naming conventions (i.e., we were linking to documents but then, when their name changed we'd lose the link. Now that we link to pages only, there's no naming convention problems).

I've spent an hour or so pouring over your article Sample QMS Wiki Organization, but I'm still not clear on how you are sorting out documents sorry! (It seems clearly written, but I still seem to be missing something!).

It makes sense that you have called each document by the type of document that it is - e.g., IT - instruction, RE - record, etc. (Just out of curiousity, what is the difference between SP,PD,PG and DP please? they all seem to be processes/procedures but I'm not very clear on the difference?)

However, how do you know where to put the documents to make them most easily accessible? For example, you have a 'correspondance' procedure with many instructions. The procedure looks like it applies only to project management, but sales and marketing and engineering may all have correspondance too.
Why did you decide to put it where it is - how do Sales get access to that information? You could link to it on one of their pages, but then it wouldn't show in the document list like it does with the Project Management page?

I guess I'm just really struggling to take our process flow charts (and procedures too i s'pose) and work out how to put it onto the wiki. I've defined the different disciplines (e.g., marketing, sales, project management, engineering/design, production, administration, etc) and then the steps within each discipline but now I have 'inform customer' in multiple places -but where do I describe how to communicate with customers in an instruction? I was going to just do a page with a table a bit like this:http://www.promanade.co.uk/files/Procurement.pdf to detail the steps and then each time it came to 'inform customer' I could link to a page that talks about customer communication.. does this make sense?

Sorry, I'm really struggling to comprehend all this!
 

Pancho

wikineer
Super Moderator
#8
I've spent an hour or so pouring over your article Sample QMS Wiki Organization, but I'm still not clear on how you are sorting out documents sorry! (It seems clearly written, but I still seem to be missing something!).

It makes sense that you have called each document by the type of document that it is - e.g., IT - instruction, RE - record, etc. (Just out of curiousity, what is the difference between SP,PD,PG and DP please? they all seem to be processes/procedures but I'm not very clear on the difference?)
SP, PG - standard procedure
PD, DP - process description

We have two different contractions for some types of document because we have documents in both English and Spanish.

These contractions are used as a prefix to a document name in order to shorten its name. For example, instead of titling a document [Instruction for securing color approval], we call it [IT: Color approval]. The longer name is more descriptive, but harder to remember and harder to type in links. The contraction that describes the type of document allows conveying the same information with a shorter name.

However, how do you know where to put the documents to make them most easily accessible? For example, you have a 'correspondance' procedure with many instructions. The procedure looks like it applies only to project management, but sales and marketing and engineering may all have correspondance too.
Why did you decide to put it where it is - how do Sales get access to that information? You could link to it on one of their pages, but then it wouldn't show in the document list like it does with the Project Management page?
We create navigation pages (contraction: nav) for each process. When a particular instruction is used by more than one process, the instruction is included in the navs for all the processes that use it. A good example is the [IT: Correspondence]. It describes a task that needs to be done while carrying out several processes: Sales, Engineering, Project Management, etc. All those processes reference the same instruction from within their navs and also contextually wherever it makes sense to do so. In the wiki your links do not have to be hierarchical.

A few of our process description pages contain flowcharts, but most do not. Placing links in flowcharts is not so easy, and without the links these graphics are not as useful as other representations that do show links, such as outlines.


I guess I'm just really struggling to take our process flow charts (and procedures too i s'pose) and work out how to put it onto the wiki. I've defined the different disciplines (e.g., marketing, sales, project management, engineering/design, production, administration, etc) and then the steps within each discipline but now I have 'inform customer' in multiple places -but where do I describe how to communicate with customers in an instruction? I was going to just do a page with a table a bit like this:http://www.promanade.co.uk/files/Procurement.pdf to detail the steps and then each time it came to 'inform customer' I could link to a page that talks about customer communication.. does this make sense?

Sorry, I'm really struggling to comprehend all this!
Yes, it makes sense. Do remember that your disciplines are probably well aligned with your processes, but they are not the same. Make sure that all work described in a process is explicitly assigned to someone.
 
C

CATERAF

#9
We create navigation pages (contraction: nav) for each process. When a particular instruction is used by more than one process, the instruction is included in the navs for all the processes that use it. A good example is the [IT: Correspondence]. It describes a task that needs to be done while carrying out several processes: Sales, Engineering, Project Management, etc. All those processes reference the same instruction from within their navs and also contextually wherever it makes sense to do so. In the wiki your links do not have to be hierarchical.
Is each NAV page a new page that you have used an inclusion on (of the page you need) or is it just a single NAV page which contains links to the other pages? :bonk:

A few of our process description pages contain flowcharts, but most do not. Placing links in flowcharts is not so easy, and without the links these graphics are not as useful as other representations that do show links, such as outlines.
Yes, this was something I had been trying to work out how to do. My boss likes (no, loves) flowcharts and was determined to find a way to link it because it's easier to follow the flowchart than read through paragrahs of text. Recently we found a way to do it - we're using a flowchart program (all users have access) that hyperlinks and then we just use that information to insert the flowchart code into the wiki and it keeps the hyperlinks. It can then be edited on the wiki (depends how savvy the users are) or by using the flowchart program.

Yes, it makes sense. Do remember that your disciplines are probably well aligned with your processes, but they are not the same. Make sure that all work described in a process is explicitly assigned to someone.
Well, I thought I had my processes sorted, but that may throw a spanner in the works. Some disciplines are still processes, are they not? But they have subprocesses and sub-sub-processes? Take for example, sales. The sales is a process isn't it? Identify requirements, create a quote/basic plan, receive a contract and do invoicing/payment.
How about marketing though? Marketing is a process.. of creating a plan, creating documents and publishing. There's also a subprocess of market analysis.

Am I on the right track? If so, is there then one process owner who oversees the whole process, but there's also sub-process owners? They report to the main process owner? E.g., marketing analysis may be owned by a researcher who is the process owner, but the main marketing owner could be Head of Marketing. Have I got confused and gone for a functional perspective?

Thanks again for all your help - I am very thankful!
 

Pancho

wikineer
Super Moderator
#10
Is each NAV page a new page that you have used an inclusion on (of the page you need) or is it just a single NAV page which contains links to the other pages? :bonk:
Nav pages are lists of links. In these nav pages we do not include the whole of the listed pages; only the links.

We do include, as a sidebar, a navigation page in each document listed on that nav. This creates a list (menu) of links of closely related documents in every document. If your user is browsing a document in the engineering process, then he will have a sidebar listing all other documents that are part of the engineering process.

Lists in nav pages are indented to show logical dependency, for example, the [IT: Monthly project close] is indented one level below the procedure [PG: Project Monitoring]. The monitoring procedure (or, as you say, subprocess) is a part of the [PD: Project Management]. The three docs mentioned will have the same sidebar -- the nav for the project management process [nav Project management] -- as will other project management documents.

Such sidebar/nav in every document is extremely useful in many ways: a process map (by virtue of the indentations), a one-click directory of related documents, a quick way to integrate new documents deep into your QMS, etc.

Recently we found a way to do it - we're using a flowchart program (all users have access) that hyperlinks and then we just use that information to insert the flowchart code into the wiki and it keeps the hyperlinks. It can then be edited on the wiki (depends how savvy the users are) or by using the flowchart program.
Great! What program are you using?

Well, I thought I had my processes sorted, but that may throw a spanner in the works. Some disciplines are still processes, are they not? But they have subprocesses and sub-sub-processes? Take for example, sales. The sales is a process isn't it? Identify requirements, create a quote/basic plan, receive a contract and do invoicing/payment.
How about marketing though? Marketing is a process.. of creating a plan, creating documents and publishing. There's also a subprocess of market analysis.
You can call them what you like. The process approach aims to prevent folks from saying "that is not my department (discipline)". Introducing the "process" term helps break down ingrained walls.

With the process approach you aim to define clearly who does what when, since likely many tasks your company does involve more than one function. For example, in our project management process we have a procedure for project startup. In this startup procedure, our CFO carries out some steps, our Engineering Director carries out others, the Sales Director others, etc. And all are "supervised" (in this procedure) by the project administrator, who on the org chart may be a level or two below those folks.

Before we had documented our project startup procedure, folks not in the Projects department could have skipped their crucial steps in the thought that what they were being asked to do was unrelated to their departments or their KPIs. The documented procedure prevents such mistakes. Having the "process-approach" allowed us to write the procedure while protecting sensitive toes.


Am I on the right track? If so, is there then one process owner who oversees the whole process, but there's also sub-process owners? They report to the main process owner? E.g., marketing analysis may be owned by a researcher who is the process owner, but the main marketing owner could be Head of Marketing. Have I got confused and gone for a functional perspective?
Yes, you are on the right track.

There are activities, tasks, processes, subprocesses, procedures, instructions, steps. These docs describe how to do the work. Who does what is described there.

Process owners, document owners, etc. are the folks that have ultimate say of how some particular work must be done. They help maintain the docs and do not need to be the same as those that do the actual work. By the way, if you allow your users to edit docs in the system, you are also giving them some ownership of the docs - even if you have a "process owner" review and approve contributions.

You can assign responsibility for whatever level of detail makes sense to your organization -- process, subprocess, procedure, instruction, step, etc., as well as for whatever step in the PDCA cycle. The clearer you document the responsibilities, the better your system will work.

But you don't need to get everything right off the bat. Just do get your Continuous Improvement process working and let your team improve docs and processes in parallel. Soon, your system will shine.
 
Thread starter Similar threads Forum Replies Date
P SharePoint for Document Control - 'Workflows' using SharePoint 2010 Enterprise Document Control Systems, Procedures, Forms and Templates 3
H 4.2.3 Document Control using Microsoft Sharepoint - Visibility of Draft Documents ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
S Using Lotus Notes/Domino for Document Control Document Control Systems, Procedures, Forms and Templates 4
Pancho Using a wiki for Document Control The Reading Room 10
Q Document Control Software Suggestions - Anyone using MIPSIS? Document Control Systems, Procedures, Forms and Templates 7
A What Electronic Document Control Software are you using? 'Canned' or In-House? Document Control Systems, Procedures, Forms and Templates 10
J Training on the importance of Document Control Document Control Systems, Procedures, Forms and Templates 3
M ISO 13485 and document control for programs ISO 13485:2016 - Medical Device Quality Management Systems 6
K ASME, ANSI, ASTM and similar specifications and their requirements for document control. Inspection, Prints (Drawings), Testing, Sampling and Related Topics 8
J Document Control Metrics Document Control Systems, Procedures, Forms and Templates 3
I Document Control Software Document Control Systems, Procedures, Forms and Templates 2
T Controlling Expandable Forms in Paper-Based Document Control System Document Control Systems, Procedures, Forms and Templates 10
shimonv Document Control Procedure Header Content Document Control Systems, Procedures, Forms and Templates 4
L How to add exemption or statement to control of document procedure? ISO 13485:2016 - Medical Device Quality Management Systems 5
I Document Control on Log Files ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 6
Q Tracking Procedure Revisions (Document Control) Document Control Systems, Procedures, Forms and Templates 9
C Document Control Stamps - Does anyone still stamp their documents? Document Control Systems, Procedures, Forms and Templates 24
I Control of Documentation Distribution - Document Control ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 2
T Control of downloaded document copies by employees Document Control Systems, Procedures, Forms and Templates 3
T Document control ISO 13485:2016 ISO 13485:2016 - Medical Device Quality Management Systems 5
O Vendor vs Engineering Document Control ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 1
A ISO9001:2015 Document control and training aids ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
GreatNate Document Control info - What is required on a controlled form/document for ISO 9001: 2015? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
J Document Control Software Needed ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 4
M Document Control - Revision Number in Document Names Document Control Systems, Procedures, Forms and Templates 4
I First Time Implementing Document Control for ISO-9001 - how far back do you go? Document Control Systems, Procedures, Forms and Templates 15
I Document Control Workflow Document Control Systems, Procedures, Forms and Templates 2
D ISO 9001:2015 8.5.6 and 7.5.3 Document Control Questions Document Control Systems, Procedures, Forms and Templates 51
R Changing Document Control software. Must I transfer EVERYTHING? Document Control Systems, Procedures, Forms and Templates 3
B Referencing to Supplier Outputs within our Document Control System 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
Sidney Vianna IAF Mandatory Document #23 - Control of CB Franchisees and Agents Registrars and Notified Bodies 3
C Document Control - old revision vs new revision Document Control Systems, Procedures, Forms and Templates 22
D Software for advancing with Document Control Quality Assurance and Compliance Software Tools and Solutions 4
L IATF 16949 Cl. 7.1 - Lotus Notes for Document Control IATF 16949 - Automotive Quality Systems Standard 0
A Removing purchase order form from document control - should it be done? Document Control Systems, Procedures, Forms and Templates 9
I Video under Document Control SOP ISO 13485:2016 - Medical Device Quality Management Systems 2
S Change Control Form vs. Document Change Notification ISO 13485:2016 - Medical Device Quality Management Systems 3
S Document control for tooling drawings (Document control clause 7.5.3) IATF 16949 - Automotive Quality Systems Standard 5
J Document Control Newbie - Control of Nonconforming / Returns Log AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 8
P Document Control - Do hard copies of documents need to be signed? Document Control Systems, Procedures, Forms and Templates 3
R External Standards List (Document Control) Document Control Systems, Procedures, Forms and Templates 3
M Retiring documents in Document Control Procedures ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
R Managing Level 3 Production Documents - Document Control System Help Document Control Systems, Procedures, Forms and Templates 6
M Cross Function Process Map for Document Control Process Maps, Process Mapping and Turtle Diagrams 3
0 How to deal with resistance to GDP Document Control Discipline Document Control Systems, Procedures, Forms and Templates 7
dubrizo Restructuring Document Control Numbering System Document Control Systems, Procedures, Forms and Templates 3
G Migrating to an ISO 13485:2016 Compliant Document Control System ISO 13485:2016 - Medical Device Quality Management Systems 6
E Document Control MS Access Database Document Control Systems, Procedures, Forms and Templates 46
S Looking for Document Control Templates Document Control Systems, Procedures, Forms and Templates 1
S Document Control Guidelines in Engineering Projects - Excel sheets with VBA coding Document Control Systems, Procedures, Forms and Templates 3

Similar threads

Top Bottom