The difference between Opalis and Service Manager
One of the most common questions I get is to help people understand the difference between Opalis and Service Manager. There is a misconception that they do the same thing. They don’t.
Whilst there are some things that you could do in both solutions, the reality is that they are complimentary.
Here’s how I define the differences. In a given IT process:
Opalis knows what was done and how it was done. Service Manager knows why it was done and who wanted it done.
There is no human element to the execution of an Opalis IT Process workflow. It is instructed to do something, and it does it when the appropriate time comes.
If you follow ITIL or MOF or any other process orientated methodology, there should always be (for lack of better terms) a requestor of something, and approver for that something, and one or more executors to deliver that something.
Typically, Service Manager would log that someone requested something, track the approval and associated change requests and then hand off to Opalis to execute the delivery of that something.
This is true also when Opalis is used to replace scripts and do heavy system level automation – you are still doing this for a reason (i.e. the ‘why’) on behalf of someone (the ‘who’). So a step towards IT Process maturity would be to lodge this automation in Service Manager as part of the documentation process.
I am building up a slide that will help with this, of which my current draft is below. This is a work-in-progress but I wanted to include it anyway – I welcome any thoughts, questions and feedback!
As you can see, we start with very system level automation, taking away custom scripts (which are typically written by someone who then leaves without documenting what it does), progressing into more business level automation and then onto what I would term service level automation.
Going back to the original question, differentiating between Opalis and Service Manager, I hope this helps you understand the differences!