Structure for ISO Management System

J.D Concepts 14 Build and learn
1

Hello!

I’ve been tasked with reorganizing our SharePoint site, which we use for our integrated ISO 14001+45001 multi-site management system. I believe that the Johnny.Decimal system would be a great way to manage our documents, but I’m struggling with a few things. I’m not sure if it’s my structure that is confusing me, or if I’m struggling to understand some of the core concepts.

So far, the structure looks like this. I’ve included some examples of specific documents that will need to be included:

Figure 1
Figure 1610×519 58.2 KB

Figure 2
Figure 2963×656 87.6 KB

Figure 3
Figure 3760×785 85.3 KB

Figure 4
Figure 4913×919 123 KB

The overall intent is for our SharePoint structure to follow the ISO standards clauses (4-10).

What I’m struggling with is how to save files within this structure in a way that makes sense to my whole team.

For example, each location will have an annual internal audit activity. This activity will generate at least an audit schedule, audit report, attendance sheet, and finding summary. Using site “A” as an example, my understanding is that we would create subfolders for each year’s audit (Figure 4). How can I identify the individual files so that others can see them and recognize they belong in folder 85.00? With my current structure, I can only think of naming each file something like 2025-01-01 Site “A” Internal Audit Report or 2025-01-01 Site “A” Internal Audit Schedule. While I think this could work, I fear there will be times when it’s unclear to my team where a file should be located without the ID in the file name. In this scenario, would it make more sense to somehow include the ID (e.g., 85.01) in the file names?

Another item is our multiple versions of the same document. For each type of controlled document (e.g., policies, procedures, work instructions, etc.), we typically create a controlled editable Word version and a PDF version for distribution. My initial thought is to maintain both the Word and PDF versions of the documents in the same folder (Figure 5). However, I see the appeal of having a dedicated folder for document templates and drafts. In the context of our system, I’m curious what others think would be the best choice. Should I keep all of the editable Word versions of our documents in a separate folder, or keep both the Word and PDF versions in the same folder?

Figure 5
Figure 5960×394 56.8 KB

Thank you!

Kyle

1 Like
2

Hi @K_D, cool to see you taking on something of this scope! And encouraging to hear that it seems to work out, in general.

Definitely worth trying, I think. Maybe in square brackets, or preceded by a caret, or some otherwise rare symbol, to aid in searching/filtering.

On that note, also, remember that the JDEX can easily refer to other locations - i.e. you could note ‘Internal Audit reports are located in this and this location with date - sitename - [85.01] in the name`.

On the other hand, it looks like you’re trying (and succeeding?) in organising the whole Sharepoint with a JD structure. That would be a massive win! Most people would be satisfied to maintain a personal index so they can find things in the black hole that is Sharepoint – see various threads on the forum.

It makes me wonder – how much are your team on board and involved? Because file structure is hard to enforce, unless everyone has a very clear understanding of why and what it provides. I suppose, if you’re working in the context of ISO standards conformance, you have institutional support for a mandated way of doing it…

I don’t know if it’s entirely applicable (or permissible?) in your case, but I find Karl Voit’s recommendations for naming file versions a very elegant twist from how many people think about it. If your browser doesn’t support text fragment URI’s, search for ‘tags instead of version numbers’. I.e. use the combination of date and status (draft, final) to determine which is the latest version of a document.

3

Hi @hans! Thank you for the feedback! This is definitely a work in progress, so I appreciate the help. I think the location in brackets may be a good solution. I’ll keep your comment regarding the JDEX in mind.

Regarding your comment on the multiple versions, I need to research Karl Voit’s recommendations further. We currently use a lot of versions, such as v1.0, v2.0, etc. But, to his point, we’re not consistent with it, and it doesn’t provide a lot of information on its own.

If I understand Karl’s recommendations correctly, and I incorporate the document location into the file name, the example I shared above with the documented information procedure may look like Figure 1. I also tried to imagine what future updates to this procedure would potentially look like. Let me know what you think.

Figure 1
Figure 11269×284 65.3 KB

To your question regarding team buy-in and involvement, I’ve been tasked with getting the ball rolling. Thankfully, it’s not a very large team, but there will be rounds of workshops to test and change the structure as needed. You’re right, the structure and requirements of the ISO standards give us a good framework to build off of.

Thanks for your help with this!

4

Glad to be of help. Let us know how you progress.

Regarding the version numbering, I think this is promising. Figure 1 looks really noisy at first, but it’s actually really clear, I think. It’s clear that this document has been finalized and submitted twice.

This could even support multi-author collaboration. You can use sub-day timestamps if necessary, and include the author’s name in the filename if necessary. If you then have the convention that no one edits a document with some else’s name in the filename, but instead creates a new version, you have a fairly real-time version control system.

Of course, we cringe to think how much disk space could be saved by using a ‘proper’ version control system – but this is so much simpler to use! And you can always compact this down when you archive it, if you want.

Interesting.

5

Yeah as @hans said, definitely a place for ID-in-filename here. Looks good at the end there in brackets.

Re: versions, my view (with my ex-corporate hat on) is that there are two versions of any document. There’s the current version and then there are all previous versions.

I’d probably lean towards something like:

.
├── Documented Information Procedure [61.01].docx
└── archive/
    ├── 2025-05-10 Documented Information Procedure [61.01].docx
    ├── 2025-06-02 Documented Information Procedure [61.01].docx
    ├── 2025-06-02 Documented Information Procedure [61.01] - submitted.pdf
    └── 2025-08-10 Documented Information Procedure [61.01].docx

So the current version is undated. It just is. And at any point you choose you ‘peel off’ a dated version, either as a point-in-time reference, or because it was published.

Cool undertaking! Keep us informed as you go on.

1 Like
6

I second that versioning scheme (current one plus “previous ones”) although lazy as I am I tend to keep them in the same folder. :wink:

Actually something like this I would expect from a document management system. But the ones I’ve had the “pleasure” with where usually huge dreadnoughts that took way too much effort to maintain.

1 Like
7

I also agree on the versioning, but I date the current version so I know when it was created/released into the wild.

8

For me, a big reason to date the current/final version is that it prevents ambiguity later, and ambiguity is the beginning of disorganization. When a new version comes along, you will have to give a date to the current one as it is no longer the latest. What date will you give it? And will you really take the time to rename the file? Will you? Better to just give it a date when you name the file the first time. Plus then It sorts properly.

Also, a filename without a date invites editing without recording that you’ve done so. This can get confusing! A date in the name nudges one toward making a new copy to edit - at least, I think so. All around, better to be explicit for your future self’s sake.

1 Like
9

I stand convinced.

10

Dunno but access, creation and modification time have been around for decades. Depends on the file system though. The obvious downside is that a wrong copy command can ruin things quite fast. :wink:

11

As I’m populating the folders with our existing files, I think I’m leaning towards a versioning system that relies on the dates in the file name, but with the addition of leveraging choice columns in SharePoint.

Similar to what I had included in my original post, I believe that for documents such as procedures, work instructions, etc., I can implement something like the example in Figure 1, where the document titles include the ID (e.g., 41.01) and the date for versioning. Instead of adding the word “Draft” to the document titles, my thought is to treat the Word versions of the documents as a perpetual working draft.

Figure 1
Figure 11139×270 44.7 KB

Since the date is in the title of the document, the current version would always be the PDF with the latest date. The date on the Word version serves as an indication whether an update is in the works. Using the example below, the current version of the document is the PDF published on February 1, 2025, since it’s the most recent PDF version of the procedure. However, edits have been made since the Word version has a more recent revision date of March 1, 2025. There will only ever be one Word version of the document. If its revision date is more recent than the most recent PDF version, we know a revision is in the works but is not final.

Leveraging this with a choice column I added to our SharePoint site, I can also tag the file as Draft, Ready for Approval, Published, or Obsolete. I put the ID at the beginning of the file name, since the title is referenced at the top of each document. I’m hoping this will make it easier for everyone to reference and navigate.

For documents that only use one version: Word, Excel, etc. We’ll have to either rely on the dates and the SharePoint choice columns to determine the most recent version, or add a tag in the filename as suggested by a few of you (e.g., – Final) (Figure 2).

Figure 2
Figure 21107×363 59.1 KB

I’m also debating removing a layer in my audit report example. My thought is to be more descriptive. For example, instead of 85.01 being the 2025 internal audit report, 85.01 will be the 2025 audit report for Site “A” (Figure 3).

Figure 3
Figure 3880×523 81.7 KB

Using this approach, we still have enough room for over 10 years’ worth of internal audits before we reach 99.

Thanks for the help so far! It’s been great to experiment with different ideas to determine what works, and I’m really excited about the results. I have a workshop scheduled with a few members of my team tomorrow to determine whether this is the structure we want to adopt. As always, I’m open to new ideas and suggestions.

Cheers!

1 Like
12

I love this. If you’re Australian and ever need a job hit up my mate @Alex. :wink: