Change ticket scope and change tasks

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-07-2024 09:27 AM
Hello,
We have certain teams in my organization submitting a change like "Weekly SAP Update" where they bundle a series of changes as Change Tasks, each Change Task matched to a development ticket (Story).
I suspect this isn't the proper use of the system. We seem to be missing out on in-depth evaluation and data of those changes and change tasks by going this route. I think the change tasks purpose is assigning tasks to others/other groups beyond the 'Assigned to' to complete a change.
Are there best practices for this? I'm really looking to implement Change as ServiceNow intended.
Thanks, Russ

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-07-2024 09:48 AM
Hey Russ,
This sounds more like release management where development tasks are rolled up into a pipeline of work and then finally deployed into production.
Release management would allow you to track the deployments across environments, not just a prod deployment, and track the necessary work via a change request where the business policy/process dictates as such.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-07-2024 10:11 AM
Kieran,
We are basically taking a release (with all the stories attached to it) and creating a change from it, each story in the release being a change task.
This doesn't seem like the way it's supposed to work to me.
Thanks

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-11-2024 09:54 AM
Kieran,
I've been reading through the Release Management - Process Workshop Presentation from NowCreate. It's been helpful. We have a lot to change to better use the process and tools of Release and Change management.
Regarding my more specific question at this time - I'm still seeking clarity on how changes are created from releases. I diagramed it out to help with simplify the discussion.
I believe scenario 2 provides the best results.
Does anyone else use something like scenario 1. Seems like scenario 1 makes what should be CHGs into CHG tasks and really complicates reporting, tracking INCs resulting from CHGs, and makes tracking CHGs by CIs difficult.
Looking for the best practice.
Thanks, Russ