I agree that's a good way to track update sets and we do it similarly (userid-RITM-description) although I'm not sure why we need the userid (in our case) since it is captured as created by or updated by.
I want to track the scripts. If I'm correct, this method would require the update set and the script to have the same name to know that it goes together. Once you've identified the script in question, to find out why it was created this way you then have to search for that same name in the update sets; then you'll be able to find the task of the request.
update set: rc1234-RITM000012312 Parse key value app for shared resources
BR: Parse key value app for shared resources
We get a new request to populate cmdb_env field.
update set: rc1234-RITM000012401 Populate cmdb_env field
BR: Parse key value app for shared resources
We would add the functionality into the existing BR bc it's easier to add functionality to that than creating a new rule that looks at the same table and does a similar function. I would be more generic with the name like Parsing key values table and any parse-like functionality would go into that script.
In the end, the script, updateset and task should be easily tied together and if it were me, I would make all of it referenced in each other. From any one of the 3 you should be able to identify the others although I think being able to identify them all from the script is most important. Identifying from the task would be next in the line of importance to me.
