Changing our DMS/ECM to a Wiki. Advice on best practices and changes of paradigm?

[rogerpenna]

I have decided to implement a Wiki in the company. It comes with some difficult decisions to make, because the logic is a little different from standard DMSs / ECMs

For example... we have codes for documents. PQP-ADM-0001 (PQP for Quality Procedures, ADM for Administrative Department, 0001 the number)
Not only it seems these codes are difficult to automatically establish with Wikis (the codes in theory ensure that no two different documents exist with same name, leading to confusion... Document Management Systems won´t let you have TWO PQP-ADM-0001s), as it makes it easier to departments to search documents that belong to them.

Also the concept of pages, subpages, etc, child pages... normal with Wikis, dont fit very well with our current system.
Here is ChatGPT's answer about requirements of a SOP

A Procedure Document, also known as a Standard Operating Procedure (SOP) or Work Instruction, is a detailed, step-by-step guide on how to perform a specific task or process within an organization. While the specific sections required for a Procedure Document can vary depending on the organization and its needs, there are some common sections that are typically included:

1. Title: Clearly state the name of the procedure, making it easy to identify.
2. Document Control Information: This section includes document identification details such as the document number, version, date of creation, date of last revision, and author.
3. Purpose or Objective: Explain the purpose of the procedure, its importance, and what it aims to achieve.
4. Scope: Define the boundaries of the procedure, including the departments or teams involved, the specific tasks or processes covered, and any exclusions.
5. Responsibilities: List the roles and responsibilities of individuals or teams involved in the procedure, specifying who is responsible for each step.
6. Definitions: Define any technical terms, abbreviations, or acronyms used within the document that may be unfamiliar to the reader.
7. Procedure or Process Steps: Provide a detailed, step-by-step description of how to perform the procedure. This can be presented as a numbered or bulleted list, a flowchart, or even a combination of both, depending on the complexity of the process.
8. Tools, Equipment, and Resources: List any tools, equipment, software, or resources needed to perform the procedure.
9. Safety Precautions: Include any safety guidelines, precautions, or Personal Protective Equipment (PPE) requirements that must be observed while performing the procedure.
10. Quality Control and Verification: Explain any quality control measures or checks that should be performed during or after the procedure to ensure the desired outcome is achieved.
11. Records and Documentation: Specify any records, forms, or documentation that must be maintained or completed during the procedure.
12. References: List any relevant documents, policies, standards, or regulations that are related to the procedure.
13. Revision History: Document any changes made to the procedure, including the date, version, and a brief description of the changes.

Remember that the specific sections and their order can vary depending on your organization's requirements and the complexity of the procedure. Always tailor your Procedure Document to best suit the needs of your organization and its intended audience.

1. Title: Clearly state the name of the procedure, making it easy to identify. Ok, this would be the page name. I guess there is no need for anything extra here
2. Document Control Information: This section includes document identification details such as the document number, version, date of creation, date of last revision, and author. So, document number is a problem in Wikis. Unless we manually include them. All the other info listed here is automatically created by most Wiki systems (I am using XWiki). They don´t come in a header however, but in tabs in the browser window. I guess some WIkis may have the option of adding those when printing?
3. Purpose or Objective: Explain the purpose of the procedure, its importance, and what it aims to achieve. That can be created in a Procedure Template at XWiki, as a field.
4. Scope: Define the boundaries of the procedure, including the departments or teams involved, the specific tasks or processes covered, and any exclusions. same as above
5. Responsibilities: List the roles and responsibilities of individuals or teams involved in the procedure, specifying who is responsible for each step. I don´t like listing individuals resonsible for tasks, because maintenance is too big. Better to use roles. One of the purposes of having a Wiki system is exactly because some allow to SELECT a role while writing a text, and then the roles can be listed in the this field, avoiding discrepancy between procedure content and lists.
6. Definitions: Define any technical terms, abbreviations, or acronyms used within the document that may be unfamiliar to the reader.may also be a field.
7. Procedure or Process Steps: Provide a detailed, step-by-step description of how to perform the procedure. This can be presented as a numbered or bulleted list, a flowchart, or even a combination of both, depending on the complexity of the process.
   ok, this is a big part of the struggles in my mind right now.
   
   a) we usually WRITE our procedures as text, because the "step by step" imho usually don´t explain CONCEPTS and other stuff needed when doing a task. Example: in a risk analysis procedure, I have a step that says "Analisys of the risk based on Probablity and Impact". Ok, but HOW do you do such an analysis? That is not a step by step.
   So even when doing a few step by step SOPs I end up adding info, somewhere, about HOW to analize something, you know, stuff that is not "step by step"
   
   b) our SOPs are usually, by name, match our processes. And have several sections. So we have a Process called Maintenance, and have sections on how to create new Maintenance Plans, Registering New Machines, etc.
   This is a discussion I already had on this forum. But imho, Maintenance, or Document Control, are MACRO PROCESSES. And the subtitles in my SOPs are actually Procedures on Processes.
   I say this because according to Processes Disciplines like BPM, even a small company can have over 100 processes, and most big companies with more departments will have probably 200 processes.
   ISO9001 view of what a process is contradicts what Process disciplines say, and the requirements to map ALL processes, do PDCA of all of them, MEASURE all of them is insane according to Process Disciplines like BPM, where you will only register your processes and then you will analyze which are more important, and THOSE are the ones you will measure, model, act upon.
   
   I am digressing a lot I guess, but what I mean is that it makes sense to me, when moving to a Wiki, to have a main page for a procedure that acts like our old procedures, that is, kinda of being equivalent to a macro process. And instead of having chapters inside, creating subpages for each process that was considered a simple subtitle of our "MS Word Procedures".
   I guess that the usual response here at Elsmar Cove would be "what works best for your company, not what ISO says". While I agree, I am thinking of changing a paradigm here and don´t know yet what works best for the company.
   So I am asking opinions about best practices.
   Also, if I have a SOP as a main page and subpages, is it possible to print a SOP with all it's subpages?
   c) I guess you may ask "whats the difference", it works on the computer in that way, just use it. That's a fair remark but we work with civil infrastructure construction (like roads) and often have worksites at remote locations without internet access. While SpaceX Starlink doesnt become cheap enough to buy dozens of antennas for several worksites, we will many times only be able to give access to PRINTED documents.
   That makes things more complicated. Wikis are not typical thought to be printed. I found no Copy Control features in most Wikis, to print controlled copies with Watermarks and expire dates, so people won´t hold their copies long after new versions come out, nor giving me lots of work telling them to discard those copies they have when I update one.
   There is also the problem of each different subsection of old SOPs now becoming their own procedures, with objectives, scope, related documents, etc, multiplying the number of pages of Original SOPs by 2 or 3, just because instead of a single text now there is all that extra info, page breaks, etc.
   
   Any thought on this?
   
   
   
8. Tools, Equipment, and Resources: List any tools, equipment, software, or resources needed to perform the procedure.
   Really? We never did that with SOPs, only with ITPs (Work Instructions)
9. Safety Precautions: Include any safety guidelines, precautions, or Personal Protective Equipment (PPE) requirements that must be observed while performing the procedure.
   We also only do that for work instructions. Our work instructions are often more direct and step by step, and most of them are for production labor, rather than Business Management, Support processes.
10. Quality Control and Verification: Explain any quality control measures or checks that should be performed during or after the procedure to ensure the desired outcome is achieved. errr... like checking if a document is well typed, in a Document Control procedure? Again, seems like a more production process thing.
11. Records and Documentation: Specify any records, forms, or documentation that must be maintained or completed during the procedure.
    Aha, that's seems to me like something great at Wikis. I can easily link documents. I guess I can also link a document IN THE TEXT and list it in the end. And if a link is broken, it shows! (no more non conformity in external audit because a form model was removed from the process by remained in the lists.
12. References: List any relevant documents, policies, standards, or regulations that are related to the procedure.
    Same
13. Revision History: Document any changes made to the procedure, including the date, version, and a brief description of the changes.
    I don´t think we keep these in the documents themselves for over 10 years, since we got a DMS. Before that, we would have a written section at the end of the MS Word document with all listed changes. A pain in the ass that required extra trees torn down to print it when nobody would read.