Great job guys! This is a super helpful video and helps to clarify the use of these 'people' attributes. This is one of my 'go-to' videos for sorting out different opinions on what goes where.
I have always delineated Assignment Group and Support Group in the same way as Assigned To and Supported By. It's about who is USING the CI vs who is SUPPORTING the CI. Making a delineation between Incident and Change seems arbitrary here, and seems to just add confusion from an operational perspective. If I am on the Server team, I am going to submit a change to the Server when patch the OS. If I am an application owner, I am going to submit a change to the Server when I update the Application. This allows a level of "shared ownership" that reflects the actual reality of how the CI is managed. While I do like the future direction of defining stakeholders on a related list, I'm not sure if the change in direction to re-label Assignment Group as Change Group really provides any benefit, and it seems a bit hasty.
It was a change we made years in the making. We needed to better support the legacy siloed way of managing things and this sublet change to reliable helps to understand the intent. As we move toward a team model, it will become more straightforward to define and manage. I would refer to this as more a RACI model that follows the hierarchy. The jobs and responsibilities will be predicated on the products you have installed for those roles, all tracing to the single team.
Very helpful. Thanks! Once this related list of contacts (team of owners, or groups) is in place, I'd like to see a method to more easily drive the incident assignment from the Alert. For example, an alert for a user (or application) file system nearly out of space will go to a different group than the same alert for a system related file system on the same server. Consider a Windows C:\ drive vs. a G:\ drive, for example.
Very neat and clear video with good use-cases. One use-case that i often come across with customers is "How can we have 1st level and 2nd level" support groups identified for our ITSM processes on the CI level. Will you recommend to use Technical Service Offering - Dynamic CI approach for it ? But then i guess it will contradict with having no clear responsible group for the CI. Thank you !
I think the Assignment Group would create / manage the change, and the Appoval group would be included in the workflow as one of the approvers for that change.
Referring at 12:18, when CI de-associated from Dynamic CI Group then it default to the CI Class 'Managed By Group' but if MBG itself is NULL at CI class level then it shouldn't set CI MBG to . In my case all Dynamic CI Group CIs MBG set to empty after de-association, my intention here is just to update the Support Group. System shouldn't overwrite CI MBG if it is null at CI class level. Any thoughts @ServiceNow - Now Community @Mark Bodman @Scott Lemm
Awesome video at right time, as most of clients are breaking their heads to adopt to CSDM and there are so many attributes that needs to be populated and synchronized. I would like to see more of these videos. I have question: Is the role "Managed by group" is to manage actually CI such as window L3 team who manages specific group of window machine ? or group is only responsible managing all the aspect the CI data ? such as making sure the all the recommended and mandatory data are populated with appropriate data like data certification.
The managed by group is more to support the team and product-centricity that most organizations are moving towards. More on that direction is coming in Rome+, so watch for additional incremental changes there.
Would you suggest the incident form show support group instead of assignment group? I see OOB SanDiego shows assignment group and assigned to on the inc form.
Yes, what happens when a CI is part of different Dynamic CI Groups connected to different Technical Service Offerings with different Managed By groups?
@@kodax71 if this happens, the last one wins. The main issue you have when a CI has many offering / service relationships, you indicate parallel support groups for those CIs. Therefore, who is truly responsible can not be determined and this is not manageable.
