Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: HGaray
New Today: 19
New Yesterday: 72
Overall: 139509

People Online:
Visitors: 60
Members: 2
Total: 62 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Log Incidents against CI's
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Log Incidents against CI's

 
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management
View previous topic :: View next topic  
Author Message
valkner
Newbie
Newbie


Joined: Mar 10, 2006
Posts: 6

PostPosted: Tue Mar 28, 2006 7:21 pm    Post subject: Log Incidents against CI's Reply with quote

Hello,

How many of you have experience with logging incidents against the CI's in the CMDB?

I do understand this principle, but it seems harder than I thought to convince Sr. Management into using this principle -> thus not easy to get their support.

From my point of view, logging against CI's is key for anything else you undertake within the ICT organisation. At least, you get a good, objective feel what is happening on and to your infrastructure.

I agree that a good working CMDB is key in this discussion, but I rather hear from you how you see this.

Many thanks

Bart Van Brabant
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Tue Mar 28, 2006 8:59 pm    Post subject: Reply with quote

If you have a good CMDB, and a tool that can do the linking this is a useful thing to do - but....

Incidents are not defined as disruptions to CI's but to Services.
Any disruption (or potential disruption) to agreed service availability, capacity and capabilities.

There are many more incidents than those related to CIs. So if you do log against CI's it should only be an option to use where a CI is found to be the problem.

Which leads nicely to the next point. The object of incident resolution is to restore the end user to business capability - not fix things.

Things will get fixed, sometimes the root cause will be found, or even known in advance. But root cause analysis is where the faulty CIs are hunted down - and this not the responsibility of incident management, it belongs to problem management.

Also none of the Incident Management metrics are about fixing CIs.

So, yes, but remember that the goal of incident management is to improve service quality by minimising the impact of incidents - not to improve the quality of your infrastructure (through direct remedial action).

You definitely should record affected CIs on the incident record where that information is relevant, or create relationships between the incident record and CI records, but logging incidents against CIs is not something I would recommend.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
itilimp
Senior Itiler


Joined: Jan 20, 2006
Posts: 172
Location: England

PostPosted: Tue Mar 28, 2006 9:27 pm    Post subject: Reply with quote

We log incidents in the name of the user who is reporting it usually, and also capture the asset tag of affected hardware. Where there isn't any specific hardware issue we use the user's PC number for remote control purposes. This does allow us later on to run reports to find out, for example, which printers have had the most incidents to see if there are any problems that need to be addressed. I'm not sure if this is what you mean by 'logging against'?


Theoretical question for RJP, isn't it possible to create services as a CI in their own right? So instead of linking the incident solely with the user and infrastructure affected, you could have the service too (rather than in opening categorisation which is how we do it at the moment).

I attended a seminar on defining ICT services a few months ago and they suggested that a service could be a CI. Thoughts?
Back to top
View user's profile Visit poster's website
valkner
Newbie
Newbie


Joined: Mar 10, 2006
Posts: 6

PostPosted: Tue Mar 28, 2006 11:36 pm    Post subject: Log On CI Reply with quote

Hello,

To place some things in a better context:

We are in the process of designing Services, but alas, this is more difficult than initially thought. I have done quite some implementation in my past, but it is rather difficult to introduce the 'service' concept - but step by step we are nearing our goals.

In the mean time, we consider our Critical Applications as a Service (although they are not, they are more than just programs). We will negotiate, agree and sign SLA's to have an official target in the organisation which can come under a SLM review cycle and SIP.

Incidents are now logged against something called a SCIM (Peregrine), which is a category setting. We would like to log against CI (but take into account that we are not only speaking hardware here - we speak Hardware, but also software, inhouse developed applications, interfaces, network components, etc;... all components of our infrastructure).

This means that we will be able to identify and link almost any Incident to a CI - giving us tremendeous information about the status and state of our infrastructure and with this an direct link to the Support organisation to underpin services (read actions) to the CI's impacted by the incident (and therefor to the users affected).

Maybe this reply makes it more difficult now, but I am not talking small DBase with PC's here (no offense meant).

I am most happy with your replies, for it started already a nice internal discussion.

Regards

Bart
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Wed Mar 29, 2006 6:59 pm    Post subject: Reply with quote

valkner,

you'll be pleased to know - it's in the book:
Quote:
What is a Service? The question is not as easy to answer as it may first appear, and many organisations have failed to come up with a clear definition in an IT context. IT staff often confuse a 'service' as perceived by the Customer with an IT system

pg. 33 of the Service Delivery book.

So yep - wot u sed Smile

I would still caution against making "information about the status and state of ... infrastructure" a central operational objective on incident management. Yes...but again, this is the primary focus of problem managment. Make sure you are deploying allocated resources to the primary obejctives first. And then get the linkage into your problem mangagement.

[Editorial - not specifically in reply to you comments Valkner]: Many oragnisation actually handle break-fix 'issue' response fairly well. It's what we techie types do. And quite frequently incident management is deploy to simply record and make visible what the organisation is already good at it, or to better equip them to do what they do. Sometimes an underlying rationale is - if we can show em what we do, perhaps they will stop hitting us. But one does not improve an organisation by making it better as what it is already strong at. One gets real improvements by focusing directly on its weaknesses and transforming them into strengths. This is one of the reasons the difference between incident and problem management is a 'high-value' ITIL concept. Sticking to the core objective of incident management can really get an IT organistion focused on its weakness in responding to impact on the business, instead of being concerned with its own infrastructure.

Itilimp - excellent! 10 out of 10. Having services in the CMDB is the ideal approach, and primary classification of incidents whould be against services. You will also be please to know this is 'in the book' just below the passage cited above:
Quote:
"Some organisations integrate amd maintain their Services Catalogue as part of their Configuration Management Database. By defining each Service as a CI and, where appropriate, relating these to form a service hierarchy, the organisation is able to relate events such as incidents and RFCs to the services affected, thus providing the basis for service monitoring via an integrated tools. This can work well and is recommended (My emphasis)


It takes some effort but it really gets your incident management reports cooking. I have had opportunity to do this, and when I present the management reports to, well, managers, they actually get excited. (And I mean non-IT managers here).

Anyone who has seen the contrast between that and how a group of managers react to a chart showing how many 'network incidents', 'application outages' and 'desktop service requests' we had last month would be a convert to this approach for ever!!
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
itilimp
Senior Itiler


Joined: Jan 20, 2006
Posts: 172
Location: England

PostPosted: Thu Mar 30, 2006 3:26 am    Post subject: Reply with quote

*sticks a gold star in her pot of gold*

I'd forgotten the book actually supports the approach of services as CIs - thanks for the reference.

This further reinforces my view that our current provider (who has a new ITBM solution out which we are considering changing to) needs to ensure that we can create services in this way, and furthermore publish them to an intranet easily without having to duplicate effort.
Back to top
View user's profile Visit poster's website
eisbergsk
Senior Itiler


Joined: Nov 01, 2004
Posts: 81
Location: Sask, Canada

PostPosted: Wed Apr 12, 2006 9:19 am    Post subject: Reply with quote

(a view from Problem management land)
I like the idea of relating incidents to CIs in the CMDB, (and CIs includes services). I try to relate problems/known errors to CIs as well, since it is the infrastructure that PM is trying to get changed to make incidents go away....
I just question the need to record that information within the CMDB on the CI. Our infrastructure changes so much, that even major problem resolutions are irrelevant after a year or so.
I would love an effective Incident Management tool where the CI affected is recorded in a consistent manner.
I think RJP has hit the nail on the head with his suggestion on focussing on primary obejctives first, and getting the linkages into PM and IM.
*wandering thoughts from a nomad in an ITIL desert*
/Sharon
Back to top
View user's profile Send e-mail
Itilitarian
Newbie
Newbie


Joined: Apr 27, 2006
Posts: 8

PostPosted: Fri Apr 28, 2006 2:40 pm    Post subject: Reply with quote

rjp wrote:

It takes some effort but it really gets your incident management reports cooking. I have had opportunity to do this, and when I present the management reports to, well, managers, they actually get excited.

Anyone who has seen the contrast between that and how a group of managers react to a chart showing how many 'network incidents', 'application outages' and 'desktop service requests' we had last month would be a convert to this approach for ever!!


Hi RJP, we will be implementing a CMDB very shortly. Can you elaborate on what you mean by 'it takes some effort....." when developing services in your CMDB. In your opinion is the hard part developing the defined "services" for your support organization or is it the defining of CI relationships that comprise the service that you think is difficult? Is there something else that's tricky?

As an aside, do you have any words of wisdom/experience for early adopters of BMC's Atrium 2?

Thanks!
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Fri Apr 28, 2006 6:54 pm    Post subject: Reply with quote

It take 'effort' for a number of reasons but the key ones are:

Service CIs should not simply be the top level of your technology trees (i.e., IT systems) Services are capabilities delivered to the business. They have different information requirements - often not accomodated in CMDBs or poorly bolted on. There is no 'machine' that can do this for you. It takes face to face relationships with the business and human creativity to link services correctly to infrastructure and actually deliver a real end-to-end view. (And skill sets not normally in high supply in IT departments.)

There is a saying that to a man with a hammer every problem looks like a nail. True, but it's actually more appropriate to say that to a man with a nail every tool will look like a hammer. I.E, it's not the tool that determines our attitude to the problem, its our problems that determine our attitude to the tools. Even where ITIL is an explicit programme and or objective, scratch the surface and you will find people are still totally focused on technology management - not service delivery.

Tools like open view and Atrium are built by people who know this, and if they were purists, would not have a market. Those tools are primarily suppporting infrastructure management and service managment functionality is a value add, not a core rationale. Problem is, if you really want Service Management outcomes that's not always a helpful thing. A lot of technology managers are adopting service management processes with the objective of making themselves better technology managers. The top end technologies make em happy - but for the wrong reasons. The organisation can end up continually playing to its strengths and not addressing its weaknesses. IT: "But our availability is %99.999999999 - that's awsome!!!" Business: "Your services are crap!!!" Laughing

High-end 'CMDBs' are generally still infrastructure management tools - getting them integrated with a high qualiity customer facing service portfolio isn't something they do not do particularly well 'out of the box'. So if you want to do this well and effectively, it will be a) a very hard sell, and b) a major area of toolset customisation - always painful and costly.

P.S. There are signs that the '4th' generation of products is emerging in the market. I call them '4th gneration' primarily becasue what distinguishes them from previous approaches is the re-positioning of the 'Service' as the core 'object' around which all the other information architecture is organised. Some of these are mind numbingly mission-to-mars expensive, and some look like they might be very cost effective indeed. It's a really interesting market right now.

Haven't been fully exposed to the latest BMC stable - around the ITSM 5.1 was my last hands on - approx 1.5 years back, just as the Atrium stuff was ramping up. We did look at it pretty closely, But back then the 'Service' as such has no coherent model, was not represented consistently accross the application suite and was far from a core architectural concept. In every way it was heavily 'mushed' up with the representations of SLA,s (which in most tool sets aren't - they're just escalation rules, which are only a small part of an SLA), and not really differentiated from the representation of a 'System'.

I sound so negative - I'm not really - oh well Smile

And finally the other factor that makes the CMDB hard work is that some of the best results come from keeping your processes and suppporting information streamlined, lean, focused on value, and as simple as possible. It takes a terrible amount of hard work to keep things simple. And worse, in the face of massive technology acquisitions, with everyone getting excited about all those hundreds (thousands?) of features, getting simple and focused is also a 'cultural battle'.

Ever watched what a good carpenter can do in a day with a hammer, some nails and a cross-saw. Have you ever seen one of these guys with a Swiss Army knife in their hands?
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.