CSDM bare minimum modeling without a formal approach

[dohsan1]

Hello,

I want to take advantage of CSDM for benefits like reporting on incident, changes, requests, problems, and outages relating to our SaaS / internal built application and pushing change approvals based on this table + app role approvals to the owner of these apps and auto assignment to groups based on app. Our company is a SaaS-first company where our whole infrastructure is built and hosted in the cloud. We don't have any graph discovery and hope to build a minimalistic CSDM to get some wins mentioned earlier. From my research, it looks like a great place to start is to build technical services + offerings + application service using the guided service builder. Should we even start this if we don't have a proper procedure around onboarding / decomissioning apps? Would it make sense to sync the app list into application services table from Okta (80% of our app stack is listed in Okta)? Any help and opinions of expertise is greatly appreciated. 

[Andreas Borell]

CSDM is a framework outlining desired practices to leverage the most out of Servicenow. Just like with higher level frameworks / standards like ITIL, one key thing to remember is that while almost any organisation executes for instance incident management, the maturity and fit for need is what differs.

You mention incident, changes, request, problems and outages (basically the usual wishlist) and then Technical Services (TS) and Application Services (TS). I am not a Servicenow employee but my advice is to take a step back and look at the CSDM model again. The standard documentation (follow this link) is not bad, and is built to work. I would combine it with watching the latest digital product video (follow this link) that gives a good overview on how things tie together.

The one thing I think the above material does not emphasize enough is considering the fact that most incidents and requests are not directly tied to TS, but rather Business Services (BS), while changes and outages are more related to TS and AS. Most mature IT organisations will probably have a lot more end user requests (and maybe incidents) than IT changes or IT outages, so I would start modelling the consumer side a lot earlier than the recommended approach for CSDM says - but I guess the ability to do so depends on the organizational maturity you operate in and your as-is situation.

[Daniel Vinterda]

I second that approach. 

[SteveMacWWT]

While I agree with all of Andreas points from the perspective of 'pure CSDM', those points come from the perspective of a perfect world. It sounds to me as if dohsan1 is working in an organization that's currently focused on the ITIL process from an IT targeted usage of ServiceNow. That is something a mature organization moves beyond, but there is still benefit in starting to focus on CSDM from the TS / AS perspective and maturing from that point. By forcing a focus on BS / BSO before moving to TS / TSO, many broader organizations will not recognize the benefits that CSDM can bring, and end up denying the ability to go down that path. By using TS/TSOs as a starting point you get the CSDM foot in the door while providing benefit to the existing support teams. 

@dohsan1 - I think you're approach is viable if you implement at least an easy way to onboard apps. A simple catalog item can at least get you started in that direction. Stig's suggestion of using the Bus App service request (if you have APM) is a great place to start. Keep in mind though that you do want to be able to iterate and enhance your onboarding process to get further benefit.

I've used an existing system as a starting point for getting the initial set of apps into the system, but once you've got that going, move to a ServiceNow based onboarding process, and then you can work toward getting that to be the starting point before they even get to Okta. 

Good luck, and don't be afraid to come back to this forum for more help if needed!

[Daniel Vinterda]

Valid points and I do not disagree. Howerever, when not introducing the Business Services I find that user reported Incidents are more often than not misplaced on the wrong Tech - or App Service. Better to place the Incident on for instance Bus. Service Communication and let the analysis by Service Agents enrich with the technical service/app service classification- be it Single Sign on, Email or Teams. This ensures that technical teams are not bothered with incorrectly assigned Incidents. But there is an important factor to take into account. If the organisation is not mature in the Service concept it is not wise to get stuck in Business Service modelling. Such organisations in my experience mostly use the ‘System’ in daily conversation. “I have a problem with the email system”. In such a context I start with the App and Tech Services and make sure that there is no auto-assign to the responsible teams. All goes to Service Desk.