| Worldwide Sites | Careers | Contact Us | Site Map | SEARCH |
 |
||
 Syndicate   Authors
|
Living with IT pain Sometimes people learn to live with pain. The pain may be real, enduring and chronic but people choose to ignore the pain -- which isn't the same thing as making it go away. I was speaking with a prospect recently about our BSM solution, and though after listening carefully to our presentation this person’s first reaction was "we just don’t have the pain" to drive this sort of initiative. However, as conversation evolved, we began to uncover that not only was this organization living with pain -- the pain was in fact excruciating and had a direct impact on the highest levels of IT leadership. They had in effect, chosen to ignore the pain. Here’s the story as conveyed: We have a heterogeneous IT management environment. Our tools report silos of information that must be manually correlated to understand the overall health of the IT infrastructure. As such our users usually provide IT with the first indication that there is a slowdown or outage. For example, a user in California will call the helpdesk in New York to report that an application is running slow. Upon receiving the call, IT looks at their tools, but the screens are all reflecting green: IT can’t see the problem. Frustrated their issue isn’t being resolved, the users begin to assume IT isn’t worth their salt, and consequently stop calling to report incidents or problems. Later our CIO goes on a company-wide townhall tour, to visit users and better understand how IT can support the business. He’s taken aback when he gets blasted by users during a meeting (ambush?) at the California office because the PeopleSoft application has been running slow for weeks. Determined to get to the bottom of this issue the CIO returns to the office with this anecdote and thoroughly questions his staff. "Why wasn’t this problem addressed?" he demands, noting how critical the application is to the business. "No one reported the incident," is the response. This is a quintessential business case for BSM if I’ve ever heard one. By integrating those existing IT management tools, BSM can consolidate those silos of information and link the underlying infrastructure components to the service being provided (in this case a PeopleSoft application). The benefit of doing this has been proven time and time again: IT will be able to rapidly determine root cause of incidents and problems, often before their customers are even aware, and dramatically reduce the mean-time-to-repair (MTTR). This supports the overall organization’s maturity to move from a reactive to a proactive IT organization. Why not eliminate chronic pain instead of learning to live with it? As for my prospect, well, we have a second meeting soon and the CIO will be involved. - Randy 0 TrackBacksListed below are links to blogs that reference this entry: Living with IT pain. TrackBack URL for this entry: http://www.wearebsm.com/mt-tb.cgi/46 Visitor CommentsLeave a comment |
| Contact Us | Site Map | Legal | Privacy |
| Copyright 2008 Managed Objects, Inc. All rights reserved. |
The story you mentioned is interesting, but I was confused whether BSM could find IT issues that can NOT be found by underlying IT tools.
The Peoplesoft system is slow, yet all the screens of IT tools are green. Even we use BSM to integrate all the silo information, we also can not find the root cause of why the Peoplesoft system is so slow.
May you please give me a light?
thanks
David
Posted by: David | August 1, 2008 5:39 AM
Hi David,
The value that BSM provides is twofold. Primarily yes, you consolidate and federate everything into a real time view, and this in turn allows you to be more proactive in managing large IT environments. To my mind, what is a bit more important and less tangible is the ability to give your end users a quick lookup table that is often much simpler than the monitoring tools on which it draws.
Consider a similar scenario;
A user calls in with a problem, let’s say some piece of hardware in a distant geography is not functioning and therefore a shipment cannot be recorded as received. The operator to whom the call is finally routed looks on her screen and sees that everything is green. So she initiates a 6 way teleconference to start brainstorming, which takes two hours, by which time the problem has resolved itself, but not the underlying cause (which may or may not be found).
That’s the best case scenario. Worst case is the operators have no idea how anything can be down if all the green lights are showing otherwise, and the problem is determined to be a user issue.
So the first questions that I would ask are;
Where does the operator look? Is there a correlation between the different tools? Is the operator qualified to understand what they are looking at? Are the monitoring tools configured correctly? And you can keep asking these questions ad nauseum.
The draw of a BSM toolset is that it takes the expertise of a bunch of different people and tools and merges them into one simple, intuitive version that tells you right away if things are working properly.
So take the above example and place it in the hands of a mature BSM environment.
The operators have a quick, informative way to see trends and fix problems, making them proactive. A simple dashboard is posted on NOC info walls, leading to a lower bar for operators, and reduced cost of training staff to understand what they are looking at.
Operators become proactive as they can spot a problem before it actually becomes a problem, and yes, the lights are all still green, but now they know that things are not necessarily functioning as they should.
Hope that helps explain it!
Posted by: Jonathan Golan | August 4, 2008 7:11 PM