Welcome. And, interesting problem!
So yes, you’re definitely larger than one ‘system’ (as we now call them).
The classic thinking behind a system is that they’re isolated units without much in common. But that’s just the usual case; there’s nothing to say that it has to be so in your case.
The problem
Remember that one of the things that makes JD powerful is the fact that it limits you to 10×10: ten areas, each with ten categories. For most systems, that’s not only enough, it’s a powerful restriction that helps you to be organised.
But you couldn’t fit the whole world in to 10×10, so we have the ‘multiple systems’ notation where we prepend a ‘system code’. (Sorry for the confused parlance. We’ll be updating everything asap.)
So AC.ID
becomes PRO.AC.ID
SYS.AC.ID
.
Systems don’t have to be isolated
In your case, you can stop thinking about these as separate projects systems and instead think about this extended numering as just that: an extension. Your use-case requires more, so give yourself more.
The trick here is in identifying patterns across the 3 organisations. If they’re all of a similar nature, they’ll all have similar needs. For example they might all have (suggested JD categories in red
):
Staff
, and hence payroll
- A
physical building
, and hence maintenance
Tax
and other regulatory compliance
.
If you can identify these patterns and build one common area, say, that each org can then get its own copy of, you’ll be in a much nicer place.
Each org will also surely have its own areas that are unique. So you just design those per org/system.
And over the top you might have another system for the governing structure. Because it doesn’t sit within any of the 3 orgs, it encompasses them all. So you might end up with this very simplified idea.
If some of these systems – say the COMMON
one – only have one area, that’s totally fine. That might well be all they need. Don’t be shy of sparsely populated systems.
Use semantic SYS
identifiers
In this case it’s probably worth using three letters, based I guess on the existing name/geography of the place? Because then let’s say you have CHI
, NYC
and LAX
just as geographies that we all understand.
If this works out, you’ll be in the nice situation where CHI.21.03
is the staff plan for Chicago, and we all already know where the staff plan for NYC
is.
Alternatives
I’ve tried alternatives in the past. At a previous job the scope was so large that it really didn’t fit in to 10×10 so I expanded the numbering, using 3 digits for my categories. So 101.11
would have been an ID inside category 101
, inside area 100-199
.
This is an option, but I suggest trying out the first idea first. The extended numbering worked but I don’t recall loving it.
Let us know how you get on!