Blog Entry

(View Disclaimer)

Consider this

When accessing the Service Desk, customers can review a list of Services that are available in the Service Catalog. They can request access to these Services, raise questions or issues. What the customer may not know, and does not need to know , is that the Service acts as the presentable face of I.T for all the infrastructure and Processes associated with providing the Service. It effectively masks all the underlying infrastructure and components of the Service, even if some elements have mission critical status.

For example, if a customer logs an issue with the Email Service, Service Desk staff can change the underlying Service CI on the Request to the email server that is hosting the Email Service. The customer however will still see the original Service against which they created the request. In Novell Service Desk this is called CI shadowing. Such capability ensures the details in the Requests and Audit Trail tab for the server are accurate, and records what is actually occurring in the service environment.

This tracking means service management staff know what infrastructure underpins which Services as well as the dependency tree of all those CI’s. This can be used to readily identify the underlying hardware or software that is compromising the stability and reliability of the Services offered.

Escalate between Processes with transparency

Consider the scenario where a customer logs a question against the Email Service because they can no longer send or receive email. Service Desk staff can easily escalate this issue to Incident Management within the Analysis tab of the Service Request. If it is discovered that the customer has exceeded the pre-approved storage quota, an RFC can be logged on their behalf to request an increase in storage capacity. This is easily achieved through the Analysis tab, but this time within the Analysis tab of the related Incident.

Within the relevant CI associated with the Change Request, managers and technicians have the appropriate information at hand to approve and implement a change, while also being able to drill into the related Incident and Service Request. The details of the CI can also be updated through the RFC Summary tab, ensuring the CMDB records are always up to date.

The assigned technician closes the Change Request when the change has been successfully verified, and the related Incident and Service Request status are also automatically updated and the customer notified.

Integrated for efficiency

With the Service Catalog fully integrated with Novell Service Desk’s CMDB, technicians have access to view and update underpinning infrastructure of a Service. Service Requests can be readily escalated to relevant parties within other Service Delivery Processes for action. These escalations include detailed information and links to the originating request, ensuring effectiveness and efficiency of Service Desk procedures.

I.T just wants to feel , well, wanted

Service catalog is the way forward for I.T to further integrate itself with the organisation that it serves. Forget the new shiny toys, the latest silicon, buzz words and those specialist acronyms that we all love when talking to our colleagues. Its not big and its not clever.

ITSM Service Catalog is an area of common ground. Hidden behind it is a whole lot of technology but to the organization all they see is the Service which is being provided.

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.