Hi all. I’ll need to keep this a little bit vague for work confidentiality reasons.
In my role, I deal with both Incidents and CRs. These can be defined as:
Incident: a problem in our production systems has occurred and been logged in the service management tool. This gets a reference in the format INCXXXX.
Change request: this is a formal authorisation to change the scope of a project. Sometimes these are the result of an investigation into an incident. They get a reference number in the format CRXXXX.
I deal with both incidents and CRs:
Sometimes one INC is resolved by one CR
Sometimes one INC is resolved by multiple CRs
Sometimes one CR resolves more than one INC
Sometimes there’s a complex interrelation between multiple incidents and multiple CRs
Sometimes incidents are resolved with no need for a CR
Sometimes CRs are raised that are not triggered by an incident
I’m struggling with how to model this in JD. Both incidents and CRs are relatively transactional in the medium to long term, but they can result in a lot of information needing to be stored.
I initially thought of an ID for incidents, with a transactional pattern of folders named for the INC number inside, and the same for CRs. Where they are interrelated, I could capture this in the JDex notes for each.
But is there a better way? This treats the incident record (and response to it) and the change request (and associated design) as things - but perhaps the thing is the system that has gone wrong? Or the business process that is failing as a result? What if the problem isn’t with one thing, but with how different systems interact with each other?
For this reason, I’ve occasionally thought that the system could best be implemented as tags rather than folders for IDs, which would allow multiple tagging. But personally, I’ve rarely run into this problem.
Another way to implement using folders is via aliases - putting the alias into the other IDs to which it might refer.
This is a spontaneous idea: you could put incidents in one JD folder like AC.ID Incidents, and change requests in another, such as AC.ID Change Requests.
In your note-taking app of choice, create a note for each incident and change request, using their respective ID (e.g., INC1234, CR5678) as the title, and store them in their corresponding JD folders. Then, link the notes accordingly and add any additional metadata as needed.
This seems like the easiest approach to me without resorting to a database.
In this scenario, where cough you’re using ServiceNow or similar, you’ve already got an ID. INC or CR or whatever. I’d caution against creating another ID which usurps that.
There’s also a very clear data model already (ITIL). Again, don’t re-invent that.
I guess the question is, what are you trying to achieve? What’s the purpose of you recording incident & change IDs? (Not saying there isn’t a valid reason. We just need to understand what it is.)
Yep, that makes sense. I was thinking of an ID AC.XX representing “a collection of incidents I’m working / have worked on” with individual INC reference numbers collected under that single ID. - and another AC.YY representing “a collection of CRs I’m working / have worked on” with individual CR reference numbers collected under that single ID.
I see these as broadly transactional, following the creative pattern.
I think maybe I wasn’t clear. My JD system isn’t going to form any sort of official record (my system will only be used by me). The canonical record of the incident will be in the service management tool, with all the structured data you’d expect.
This is about me keeping track of my thoughts, scribbles, ideas relating to each incident and CR. I need somewhere to keep that stuff in JD, and this seems like a reasonable way to do it:
a single ID for incidents straddling a “folder” per incident, named by INC ref
a single ID for CRs straddling a “folder” per CR, named by CR
That way I’m not using a whole ID for what might be quite a small thing.
My question was really around managing the fact that the linkage between incidents and CRs can be complex.
Yeah I reckon just an ID for incidents, one for problems, one for change … and then Markdown links are going to have to be your friend. Finding some consistency there will be key.
I’m struggling with how to model this in JD.
JD isn’t a relational database, so if you keep struggling, it’s not you, it’s me.
But seriously … SharePoint might be a better option? Build yourself a List or something? Or if you can get away with it use something infinitely nicer like Airtable. Because what you need is a relational database.
I suspect you’ll find yourself hacking one together using text links and not having a very nice time. But I’d love to be wrong! Keep us updated please.
(And, I’m not trying to be discouraging. Just realistic.)
create a note somewhere for each ‘nexus’ of Incidents and CRs? i.e. sometimes it’s one-to-one, sometimes it’s many-to-many, sometimes it’s a long ongoing series whose relationships get clearer over time … it might make sense to treat each of those knots as a thing, since that, I presume, is the unit of work that would provide leverage for you (I’m not in this line of work at all). In my very different line of work, it helps me to take a step back and note the bigger units in a sea of seamingly equal tasks and ideas. That helps me to see how to apply my time and effort more strategically. But then I have the luxury of being able to take the time to do that notekeeping work every two weeks. I don’t know if it would work under time pressure, but that’s how I would envision ‘hacking [a relational db] together using text links’. I’d be curious to know if that works for your domain, but don’t experiment just for our sake
Also, as @johnnydecimal points out, I think a JD ID would indeed be at the level of all Incidents and CRs, or maybe one for each, but not an ID per ticket.
Or … and it’s possible I’ve done this at some point in the last decade, I forget … just hijack an entire category and do:
15 Incidents and problems
15.INC789323 That one where the email went away
15.INC789389 The one with the small chicken
15.INC790287 You really screwed up this one
…
So now you’ve got a space for your own thoughts, contained in your system, with permalinks back to the original artefact.
Thanks @hans and @johnnydecimal . I’ve spent some of this morning building out my structure (just on paper, not implementing it yet). Doing that has clarified my thinking some - I’m leaning towards a category called XX - Work Packages which will allow me to have XX.01 Incidents and XX.02 Change requests. With linking between notes in the JDex, that should be enough. This does feel like a slight waste of a whole category, but I think it’s worth it to tame the chaos, and I’ve got categories spare.
If things get complex, I can grant a dedicated ID: XX.03 Really complex thing with multiple CRs and Incidents, but that should be by exception.
might be a better option? Build yourself a List or something? Or if you can get away with it use something infinitely nicer like Airtable. Because what you need is a relational database.