The flexibility of Microsoft System Center Service Manager (SCSM) stems from its ability to help you turn any organizational process into a standard, templated workflow. When you really think about it, pretty much every Service Request is typically about a few things:
- Getting an Approval
- Taking Action(s)
In Service Manager speak, you can think of it as:
- Review Activity
- Manual Activity
If you need to get complex, you can also take the above Activities and wrap them inside Parallel Activities or Sequential Activities to control your process flow at more granular levels. Perhaps a series of tasks are not dependent on one another, but another group is. But where Service Manager shines is its ability to hook into virtually any other system through automation. Our conduits to automation vary, but all come in the form of what is essentially a Runbook Automation Activity:
- System Center Orchestrator
- Service Management Automation (SMA)
- Cireson PowerShell Activity
- Cireson Service Manager portal Webhooks
How to Approach Automation with Service Manager
What should you automate first? Where can you even start automating? What are good automation ideas? At the end of the day, every Manual Activity in a Template should be viewed as something that hasn’t been automated yet. This gives you a chance to iron out the process you’re building and/or defining within your organization first. This step is a must! Automating a bad process is still a bad process! So, make sure it’s understood and critically evaluated first!
Once we’ve outlined the process the way we want it, the discussion will inevitably turn to automation… and by automation I really mean integration. Specifically, integrating with other systems outside of the System Center and even outside of the Microsoft eco-system. The example we’ll use may seem farfetched, but at its core I think highlights how to work with disconnected systems and how to Template any process. Let’s build a Service Request that gets a 3D print started!
Apart from the 3D printer that actually creates the thing we want to print, we’ll also use a project that has become terrifically popular on GitHub, and that’s Octoprint. It’s an open-source web portal designed to control 3D printers. We’ll be taking advantage of its APIs, so we can get Service Manager requests to invoke new print jobs once approved.
This entire process will show how you can integrate almost any system with System Center Service Manager identify pain points within your organizational processes and demonstrate just how easy it is to work with APIs through PowerShell.
How to Integrate Systems with SCSM
First, we need a brand new Service Request Template. Let’s call it “Submit a 3D Print Job” and save it in a new “Fabrication Requests” management pack. In the actual Service Request Template, we can title it “New 3D Print,” set Source to “Portal” and set Urgency/Priority/Support Group as you see fit. Second, let’s add an Activity flow.
- Review Activity to Approve the print
- Manual Activity to assign out to an Analyst to start the print.
Finally, let’s build the Request Offering based on this Template that takes a few inputs, such as “What are you printing” and map it over to the Description of the Service Request/Review Activity. Then add a File Attachment input, so people can upload the file they want to print. By default, File Attachments will automatically be added to the Service Request, so there isn’t anything we have to do here.
Next. Next. Publish. Add this to a Service Offering. And Boom, we’re done! We just turned a process into an SCSM Request that our users can submit.
But like I said before, we’re not exactly done, because every Manual Activity is simply a process that hasn’t been automated. As it turns out, the usage of this new request is skyrocketing, but it’s taking a long time to get prints started. How do we know this? Since every Manual Activity that relates to this request is called “Start the Print” we can fetch these numbers through SQL queries or…
PowerShell
Here we’re going to work with the Manual Activity class and get all MAs that have a title of “Start the Print”. Then we’ll see how long each of them take to finish so we can compute the average time. Looking to adapt this solution to other Work Items? Just change the Work Item class you initially retrieve. Need some pointers? Check out our blog over here.
With this data, we now have some supporting evidence to move forward with process automation. Something we can do rather easily with Orchestrator and a little PowerShell.
Now any time a print is approved, our runbook is called, the job is uploaded, and the print begins immediately. With our new automation in place, we could now report on the average time we’re saving in a given week/month compared to how long it was taking, waiting for people to manually start this work.
Thinking Through Transformation with Service Manager
It’s this line of thinking that is the basis for every process you want to transform in your organization through Service Manager. Here’s what you want to do:
- Make an observation
- With data, take a measurement of the current state
- Work towards improving that process
- Measure again
- Repeat
Then consider how you approach integration. If the external system has an API to work with, there is generally no limit to what you can do!
The best part about this process is that the data points used are automatically set within Service Manager, which makes forming observations easy. Why is a particular Manual Activity taking a long period of time? Why does a certain group of Incidents always resolve in under 5 hours? The only mistake you can make is saying “There is nothing to improve.”
