Service Desk Practitioners Forum
cancel
Showing results for 
Search instead for 
Did you mean: 

Service Definition in OVSD

SOLVED
Go to solution
Highlighted
Pete_Pearson
Occasional Contributor

Service Definition in OVSD

I'm one of the first Service Level Managers and part of a large ITIL implementation at a top grocery retailer. We are currently implementing two services within the SLM module of OVSD as a proof of concept; however we plan to integrate more services into our OVSD structure within the next year.

First, our team has struggled to identify the "services" we'll be creating within OVSD in addition to the "services" we'll be monitoring in OV Service Navigator. It doesn’t seem logical to create a one-to-one mapping of "services" between these two products.

Second, we haven't received many implementation examples from HP consulting in the area of SLM. Since most large fortune 500 companies probably have a majority of IT service offerings in common, does anyone have examples of services within OVSD & SLM from a production environment? More specifically, IT services defined within a large scale retail (grocery) framework?

Thank you!
20 REPLIES
Michael Lutfi
Frequent Visitor
Solution

Re: Service Definition in OVSD

I work in HP consulting and I can not agree with you more concerning all the examples and ideas people give are very IT related and are not generic enough to extend SD to be used in anything in which you have to manage IT....however I found in the begining the User guide document that you can download as part of the SD documentation really helpful...in your case check out chapter 11

If you really want something to get you sprinting check out the consolidated SD which you can acquire from HP, which is basically a bunch of ready made unpack and deploy kinda of packages that HP can provide and deploy...

Note: somethings in SD are sometimes just not logical and I eventually see the logic to them...basically to make everything granular enough to allow for all the flexiblity that SD can provide without having to write code...
Pete_Pearson
Occasional Contributor

Re: Service Definition in OVSD

So, that has been the typical HP response to any "example" requests. Iâ m very frustrated. I can only assume that most HP OpenView Service Desk implementations are very similar in terms of the Services organizations structure within Service Desk. How many services are typically created within Service Desk? What are the most common examples

In addition, one of the biggest issues right now is usability. How are Service Calls, Incidents, and Problem tickets typically managed or defined by an agent? Iâ d like to see 3-5 real world examples of how a call comes into the Service Desk, logged as a Service Call/Incident/Problem, associated to a location and user, associated to a configuration item, and then associated to a â Serviceâ . I understand the theoretical, but I have no understanding of functional examples.
Sergiy Bilous
Super Collector

Re: Service Definition in OVSD

I agree with you - HP ServiceDesk is very poorly supplied with implementation examples. Chapter 11 of "User's Guide" may be helpfull on start, but it just not enough when you build a large project and try not to make stupid mistakes.
I heard about "HP ITSM Best Practices" (U5490A,U5491A,U5492A) - these are some kind of product documentation which you can buy from HP, right?
Hope that HP would publish some documentation that make HP SD implementation not so hard as it is now.
Carol Hibbard
Honored Contributor

Re: Service Definition in OVSD

Best Practices do exist and are purchaseable from HP or Alignability.
http://openview.hp.com/solutions/itsm/tsm/itsm_tsm_csexpresspack.pdf

For example, the Incident Mgmt process can be viewed here showing process, procedure, and detailed work instructions including pre-defined code fields, forms, templates, db rules, etc. in Service Desk:
http://www.alignability.com/


Robert S. Falko
Honored Contributor

Re: Service Definition in OVSD

Pete,

If someone who knows nothing about IT asks you what your company uses IT for, your non-technical answer will probably be a catalogue of business services. For example, "We use IT for general accounting, for billing, for email, for order processing, for stock management, to manage our fleet of trucks, etc."

Now, if someone in IT asks you what you need to put into place (in a very generic sense) in order to support those business services, you answer might be a list of operations services. For example, "well, we need to manage data storage, and data transport, and authentification, etc."

Finally, if you are asked if your internal IT organization provides all those services itself, your answer might be "No, we outsource the Internet connectivity and the administration of SAP." These are the underpinning services you use.

Although my great uncle was in the produce business, he retired in 1936, so I am not up to date about the services specific to your industry. His computer was a pencil lodged above his left ear. I hope, however, that these examples put you on the right track.

-Josh
Steven De Smet
Frequent Visitor

Re: Service Definition in OVSD

Josiahs definition is the best starting point you can have. The other thing you need is experience, common sense and information from people in all layers of your company.

I don't believe in examples, specific models, ... I do believe in a best practices where you can pick your own flavour and re-use some ideas.

Understand what IT is meaning to your business, define it(IT), and resell it(IT) to your business. I see a lot of companies (IT departments) struggle with Service catalogues, Services, ... because
1. They want to implement everything at once
- Define Service per service and let the business interact
2. If you don't have any control on your incidents, changes and configuration processes, SLM will not work
- Define services and you can negotiate SLA's but don't forget your service support (CMDB!!!)
3. OVSD is so flexible that without any experience, you will drown within the functionalities.
- Again, step by step
Mike Tainter
Acclaimed Contributor

Re: Service Definition in OVSD

Your questions are commonly asked across many industries, for your first question, you are right - on the surface it seems there is little correlation between "services" in Service Navigator and Service Desk. However, both tools can provide you with a lot of value when used in conjunction with each other. One is more business-centric (Service Desk) and the other technology-centric (Service Navigator).

For your second question, and to expand on the value of using a field-proven process model - the Alignability Process Model can provide you with the alignment of ITIL processes with a very robust Service Desk tool. The implementation approach with the APM includes a fully functional Service Desk configuration that includes samples of Services and SLAs that give a clear picture of the value of HP Service Desk's SLM module and can assist you in the process of defining services.

The purpose of SLM is to connect IT with the business and a good way to start is to ask them what they think your services are in business terms...not IT terms. From there you can build the bridge...
Pete_Pearson
Occasional Contributor

Re: Service Definition in OVSD

Thanks everyone for their feedback, and I apologize upfront for the length of this reply. I still have concern in how analysts should relate Services Calls or Incidents to a â Serviceâ in OVSD. Currently, our front line service desk analysts open every ticket they receive as a Service Call within OVSD (I should point out that the Operations is automatically generating Incidents based on events coming from OVO. Incidents, however, are also created by support personal. We have not yet implemented the Problem module within OpenView, so support is using the Incident ticket to relate Service Calls to common or know issues. Regardless, every ticket at the Service Desk starts as a Service Call). Weâ ve had a Service Planning team that has been identifying the â Servicesâ IT delivers to customers for over a year. I have attached a word document that shows a summary of our teamâ s Service framework. Comments are appreciated.

It is only within the last 2 months that we have looked to implement the SLM module within OpenView and change procedures within the Service Desk (adding Service-SLA-Service Level fields). As part of the large scale HP consulting implementation, we identified the Email Service as the first service weâ d prototype in Service Desk. This is the only Service within the SLM module configured. We have simplified the implementation and are not creating any Service Parent-Child relationships and are creating all Services as Business Services so we can relate them freely. The expectation is that Service Desk analysts will relate all Email related Service Calls to the Email Service within the ticket (with configuration items also related). However, what happens when a configuration item or service cannot be initially identified as being impacted at Level 1 support? Does anyone have comments on this implementation strategy or OVSD configuration?

Additionally, if we are truly measuring Services offered to customers within Service Desk, how do we track Services that will never be related to the support organization, such as delivering a new PC to an associate, or On-Boarding a new employee via an On-Boarding Service? OpenView is support (break-fix) focused and seems to lack true Service Delivery capabilities.

Another major question is how should we characterize applications within OVSD? Configuration Management is loading most of our hosted applications into our CMDB (over 500 apps). Yet the SLM team still doesnâ t have a solid understanding as to how we relate these applications in OVSD. How do major applications like PeopleSoft and Oracle Financials get implemented into the â Serviceâ framework? How should all other applications fit into the â Serviceâ framework? It should be noted that we are planning to design application hierarchies within the OV Service Navigator tool and report availability in conjunction with OVO.

It also seems that we are using the Service Call/Incident/Problem ticketing framework incorrectly. Iâ ve spent several years studying the ITIL framework and became ITIL certified two years ago. What is best practice for using Service Calls-Incidents-Problems together in OVSD, and how does the â Serviceâ relationship come into play? Shouldnâ t Service Calls be used differently than Incidents? Donâ t they have a different purpose?

A long thread but comments and feedback are very appreciated!

Pete
Robert S. Falko
Honored Contributor

Re: Service Definition in OVSD

Pete,

Regarding your services:

Operational Services to Load in OVSD

INF- Corporate Office Network Service
INF- Distribution Center Network Service
INF- Extranet Network Service
INF- Datacenter Network Service
INF- Load Balancing Service
INF- Westpark Datacenter Service
INF- Non-Retail Windows Server Service
INF- Non-Retail Linux Server Service
INF- Non-Retail UNIX Server Service
INF- Non-Retail MAC Server Service
INF- Non-Retail Storage Service
INF- Data Transfer Service
INF- Linux Blade Database Hosting Service
INF- General Database Hosting Service

Looks good.

Business Services to Load in OVSD

Good:
BUS- Email Service
BUS- Online Collaboration Service (Interwise)
BUS- Associate Telephone Service

Don't understand what they are
BUS- MDEP Service
BUS- Retail Network Service

For me, all the rest are operations, not business, services. In addition, Gold/silver/bronze are not services, they are service levels. There should be only one service, but with 3 levels.

BUS- Gold Application Hosting Service -
BUS- Silver Application Hosting Service
BUS- Bronze Application Hosting Service
BUS- B2C Web-hosting Service
BUS- B2A Web-hosting Service
BUS- B2B Web-hosting Service

It is hard to suggest what the business services ought to be, because I do not know your business.

Try this as an acid test for the service type: Can the service be outsourced? If it can, it is likely to be an operations service (and if it is already outsourced, then it is an underpinning service). On the other hand, if you cannot outsource a service without radically changing the nature of what your organization does, then it is probably a business service.

-Josh
Robert S. Falko
Honored Contributor

Re: Service Definition in OVSD

Pete,

I break down my responses into bits - I think HPs web server is choking on the length.

>>Currently, our front line service desk
>>analysts open every ticket they receive as
>>a Service Call within OVSD...Incidents, however, are also created by support personal.

Exactly right.

>>We have not yet implemented the Problem
>>module within OpenView, so support is using
>>the Incident ticket to relate Service Calls
>>to common or know issues. Regardless, every
>>ticket at the Service Desk starts as a
>>Service Call).

Still fine.

>>I have attached a word document that shows
>>a summary of our teamâ  s Service framework.
>>Comments are appreciated.

>>As part of the large scale HP consulting
>>implementation, we identified the Email
>>Service as the first service weâ  d prototype
>>in Service Desk. This is the only Service
>>within the SLM module configured. We have
>>simplified the implementation and are not
>>creating any Service Parent-Child
>>relationships and are creating all Services
>>as Business Services so we can relate them
>>freely. The expectation is that Service >>Desk analysts will relate all Email
>>related Service Calls to the Email Service >>within the ticket (with configuration
>>items also related).

Good strategy to use a pilot service, and good choice of service.

-Josh
Robert S. Falko
Honored Contributor

Re: Service Definition in OVSD

Chunk 2

>>However, what happens when a configuration
>>item or service cannot be initially
>>identified as being impacted at Level 1
>>support?

Unless you are using what ITIL calls an "Expert" Service Desk, I do not see that the 1st level should EVER have to identify the impacted CIs (except perhaps the CIs used directly by users).

Otherwise, the value of relating CIs to services includes:
- making it easier to identify the risks and impact of changing CIs
- help in planning maintenance/changes of CIs (with respect to availability requirements defined in SLAs)
- help in diagnosing incidents
- help in making capacity, availability and service continuity plans
- help in identifying and relating costs to services (and hence to customers)

So what happens if the 1st level does not see the linkto a CI?
- you will need to know how to escalate based on something other than impacted CIs. Theoretically, this could be done via the operations services that are supporting the business services.
- your 2nd level of support will probably know exactly which CIs are concerned, so they can update this information.
Does anyone have comments on this implementation strategy or OVSD configuration?
- remember that your infrastructure is probably changing more or less rapidly (and with increasing virtualization of the infrastructure, this is becoming more of an operational feature and something subject to change mgmt.) Should the 1st level always be abreast of exactly which CIs are in use to support a given service, hence which CIs are impacted should that service have an incident?

>>Additionally, if we are truly measuring
>>Services offered to customers within
>>Service Desk, how do we track Services that
>>will never be related to the support
>>organization, such as delivering a new PC
>>to an associate, or On-Boarding a new
>>employee via an On-Boarding Service?
>>OpenView is support (break-fix) focused and
>>seems to lack true Service Delivery >>capabilities.

I do not agree with you. There should be high level categories of Service Calls, amongst which are each of the basic services in your catalogue that are offered to your users (including, but not limited to, your "break/fix" incidents). When service calls involve changes ("install new software", "set up a new workplace", "move a team to a new office" etc.), we use service calls as a front end to change tickets, behind which are all the work orders required to execute the work flow of the change. By the way, we do this because it is via the service call that we can bring the service level management into play in OVSD - it doesn't work with changes.

-Josh
Robert S. Falko
Honored Contributor

Re: Service Definition in OVSD

Chunk 3

>>Another major question is how should we
>>characterize applications within OVSD?
>>Configuration Management is loading most of
>>our hosted applications into our CMDB (over
>>500 apps). Yet the SLM team still doesnâ  t
>>have a solid understanding as to how we
>>relate these applications in OVSD. How do
>>major applications like PeopleSoft and
>>Oracle Financials get implemented into the
>>  Service  framework? How should all other
>>applications fit into the â  Serviceâ Â
>>framework?

In ver 4.5 OVSD does not offer the ability to detect the relationship of a CI to a service via its relation to another CI. Therefore, you either relate all CIs directly to services (which would probably become a hopeless unmaintainable mess, even with the small number of applications you use), or you relate only certain CIs - generally the applications - to the services. When a business service (for example, accounting) fails, what is the first place you look to diagnose the incident? I expect it would be Oracle Financials. If the problem is not there then you could look at the CIs related to the application (the servers, the databases, the upstream applications, etc.)

>>It should be noted that we are
>>planning to design application hierarchies
>>within the OV Service Navigator tool and
>>report availability in conjunction with
>>OVO.

You may wish to use this same information as a diagnostic tool for incident management. Ideally, one day OVO and OVSD will share the same database (it has been on the HP roadmap for a long time), and you will benefit from the shared information. Unfortunately, it is not yet available.

>>What is best practice for using Service
>>Calls-Incidents-Problems together in OVSD,
>>and how does the â  Serviceâ  relationship
>>come into play? Shouldnâ  t Service Calls be
>>used differently than Incidents? Donâ  t they
>>have a different purpose?

ITIL, H-P and most ITSM tool vendors face the same ambiguities in this respect and generally come up with similar solutions. According to ITIL an incident is an incident whether it be triggered by a call to the service desk or an alarm from a monitoring system. The practical issue is that the service desk needs to process all sorts of calls, and its procedure needs to be similar whether a call comes in for an incident, a complaint, or any other type of request. In OVSD, Service Calls are optimized for managing this direct contact between users and the service desk.

The question, then, is why didn't H-P decide to create "service calls" (of the category "System Incident") when an alarm comes in from a monitoring system. (By the way, you can do this if you want - you are not obliged to use the Incident Item, although you might lose some other functionality.) I am not H-P, so I can only guess. I suppose the idea is to support the reality of a single infrastructure event, like the failure of a switch or a router, that will result in a potentially large number of service calls. The "incident" is detected by the monitoring system. The Service Desk relates the service calls to the incident. When the incident is resolved, the service calls are resolved. Again, this could have been done uniquely with service calls, but I suppose it is conceptually cleaner. Ya pays yer money and ya takes yer choice.

Final remark. I think you need to work in a pilot environment to resolve the manifold issues you raise. It is crucial to work with someone highly experienced in using OVSD in the ways that meet your requirements.

-Josh
Pete_Pearson
Occasional Contributor

Re: Service Definition in OVSD

I still disagree or do not understand a couple things from the last response thread:

Josiah said:
>For me, all the rest are operations, not >business, services. In addition, >Gold/silver/bronze are not services, they >are service levels. There should be only >one service, but with 3 levels.

>BUS- Gold Application Hosting Service -
>BUS- Silver Application Hosting Service
>BUS- Bronze Application Hosting Service
>BUS- B2C Web-hosting Service
>BUS- B2A Web-hosting Service
>BUS- B2B Web-hosting Service

OpenView only gives me the ability to associate one service level to one service SLA which is then associated to the Service. Each Service can have multiple SLA's. I understand this. However, if I related all my Application CI's to one "Hosting Service" it doesn't give me the ability to associate different applications to different Service Levels, since I cannot associate CI's to SLA's in OpenView. Therefore, the only logical alternative is to create the three Services (Gold/Silver/Bronze) so I can relate only the application CI's that are going to be associated to the given Service Level. Unless I am missing something, I don't see another alternative.

Pete
Robert S. Falko
Honored Contributor

Re: Service Definition in OVSD

Pete,

I guess the question is what is your objective in wanting to associate a CI (an application) to a service level.

In reality, a single CI may be used to deliver one or more services to one or more customers, and therefore there may be various SLAs and service levels. Why do you want to model something that is likely to not correspond to the reality?

-Josh
Radovan Skolnik
Honored Contributor

Re: Service Definition in OVSD

Let me comment on few things (this starts to be a really interesting discussin targeting the biggest obstacles in OVSD and OpenView).

About relating CIs to Services and SLAs. You correctly said there was no way to propagate CI relationships into SLM (that comes with SD5). You can create a service tree in OVO but currently that is something that has no connection to CMDB and/or SLM (you can view only status of a tree node in OVSD). What we have done was creating Operational services and relating them to some of the CIs we monitor using OVO. On the level of integration between OVSD and OVO we selected the most critical messages that we propagate to OVSD as Incidents. These affect SLAs related to those services. There is also integration between OVO and OVIS that monitors the same services from a user perspective - so messages from OVO come as a second (and more authoritaive) source of information to OVSD (through OVO).

Another option that I found just recently is this: OV Service Navigator has an API that allows you to be notified of status changes on service tree nodes. As a service modeling using CIs is quite unmature as of now in OVSD it would be possible to delegate modeling of the services to Service Navigator, monitor it's top level nodes (the applications themselves) and propagate the status changes to OVSD as Incidents. This would overcome the limitations of OVSD service modeling.

Radovan Skolnik
Honored Contributor

Re: Service Definition in OVSD

Now about SLAs, Service Levels, ... The basic idae of how OVSD is implemented is correct IMHO. I.e.: you can relate as many SLAs to one Service as you like. Each SLA has its own Service Level and has its receivers (whether Persons or Organizations). This should be enough to implement any scenario I believe. So in this case I agree with Josiah.

That was for the idea now let's see the real implementation. The problem is (as with many things in OVSD 4.5) that the actuall implementation isn't up to par with the idea. The thing is that you can have many SLAs related to one Service however when an Incident arrives that affects this Service only one of those SLAs is affected (the one with most stringent Service Level)!!! So basically your Service can be down all of the time but your SLAs (except for one) will say it was 100% OK. Within Incident there is a View available from SP7 that shows you the tree of affected Services but that is View only - it affects nothing.
There's no easy cure for this. In SD5 this is solved by adding entity of "(Impacted) Services" to Incidents (maybe Service Calls as well - don't know precisely now) if I read the Data Dictionary correctly. From what I tried this was the same way some guy (outside HP) extended/patched SD4.5 sometime around SP6-9 or so. He was using the information fro mthe View I described to fill in entries to new entity he added to SD (Impacted Services) and also tweaked the SLA evaluation to use this inforamtion to overcome the limitations I described. He also did some other interesting features I really liked (for example adding Incident Category to SLA Metric definition so that only Incidents with that Category are taken into consideration - that way you can have multiple Availability metrics inside one SLA - one for HW availability conformation, one for SW availability conformation, one for Performance conformation, ...) However he stopped publishing these patches as HP didn't really like it (I still have the old files somewhere and his e-mail as well).

Another option would be implement your own reporting for SLM - something that would be able to evaluate the SLM metrics. We have done such a thing in PL/SQL on Oracle9 - it allows us to on demand evaluate any SLA together with its metrics for any period (sort of like Pre-Run for Metric). Within that we have more flexibility to select for example what Impact Codes should be included with evaluation (in SD implementation you set up the lowest Impact Code and and all above it are considered). It also allows evaluation for a long period (for example year) cut into smaller sub-periods (for exampe weeks). In such scenario you will get 56 values for each metric that you can plot into graph - something managers like very much...

Huh - I talk/write too much. As a conclusion here - in my opinion SLM module is not really usable without some hardcore tweaking in current version. SD5 should get rid of most of the limitations but that'll take some time. If you have to stick with 4.5 it's good to know the mimitations and design things with those limitations in mind.

If you have some question please ask - I'll gladly share what I know.

Best regards

Radovan Skolnik
mrduy
Acclaimed Contributor

Re: Service Definition in OVSD

I need some documents about bus B2C! Please help me. Thanks in advance!
Nasser Kolathum
Regular Collector

Re: Service Definition in OVSD

too many good information from experts are here! neverthless, let me show my views as well :)

We use this tool for over 11,000 user accounts and over 40,000 business users globally. Some of our services work following sun and other works regional basis, but provided to globally. I am not saying that product is perfect as your dream, but with most accurage strategy, we can establish a most closest to perfect SLM modules in service desk.

CMDB is the foundation of ITIL, but person record and the organisation is the foundation in service desk. Building up perfect boundries for person record, you need structural defined, not for short term but long term objective organisation should be build prior to load with complete person records. If you are able to define which users organisation you are allow to provide particular services, you are in the edge of your expectations.

2nd most is your Service level modules are defined with exact working hours and priorities. You need a clear understanding of your business expecations and your service deliverables, not based on small area, but end to end of your services. For example, we have a services link to multiple SLA, tied to various organisations with various service levels help to provide you exact out come of business expectations.

Then you are looking at the service level agreement, build exact image of your signed copy of SLA. Using all the valuable fields and related to right SL and customer organisation, you may surprise to see it works exactly as per your expectations.

These are possible!. eventhough we need to wait for Service Manager for local holiday settings or creating DB rules for some of the high priority services to measure the deadlines etc product is not compatable to any other tools. With help of perfect, broad minded consultant you can achieve your expectations.

Over all, if we dont know how to drive, we learn from some one, or get a good driver to drive the car. Product is complicated, find better way to use it :)

<< this is my views only, no response required >>
It's Miller Tim
Occasional Contributor

Re: Service Definition in OVSD

Lots of useful information everyone!

So I'm at a place where I really don't know where to start. I have a blank slate as it were and I want to avoid pitfalls and potholes that others have run into. Is there any one good resource to turn to for me to learn how to build a true ITSM product using OVSD 4.5? I have the original media (2002) and don't have the slightest clue where to get the updated documentation. I'm up to SP 31, running client 2008.

Any help would is greatly appreciated.
Radovan Skolnik
Honored Contributor

Re: Service Definition in OVSD

Updated docs come with SPs - so have a look at docs directory that you get when you unpack SP31. There is somewhere addednum PDF that describes significant changes.

Regarding building ITSM solutions: there are technical obstacles that prevent you from doing things here and there (read the above posts). Also it highly depends on what you want to achieve: do you want to use only what's availabel in SD? Do you want to integrate it with some monitoring solutions (i.e. Incident creation)? Do you want to integrate with some other systems?

//Add this to "OnDomLoad" event