CA Community






This Blog

February 2012 - Posts

CMDB at a Crossroads

Published: February 28 2012, 10:58 AM | no comments
by Crystal Miceli

Once upon a time, my job was to create product content, education and best practices to enable businesses to effectively implement and get value out of their CMDB. In those days, CMDB was a relatively new concept to most organizations. IT organizations grasped the need to capture and document interdependencies between the devices or systems that made up a service provided to the business, but had so many sources of record that it was very difficult to get started. Many started with just trying to combine a bunch of discovered data sources into a single data store, and encountered issues with data duplication, unique identification of Configuration Items (CIs) and reconciliation. Unfortunately not every investment in CMDB technology resulted in more effective root cause or change impact analysis, the primary goal of a CMDB implementation back then.

My team decided to balk the trend of "bottom-up" CMDB deployment and focus on business and IT services from the top-down.  We prescribed practices like starting narrow and shallow when it came to the types of CIs and the attributes that would initially be populated, enabling IT organizations to get a grasp first on what key services were being provided, and then adding depth and breadth once they had instituted sufficient Change Management procedures to ensure data consistency and freshness within the CMDB.  We emphasized process and federation over data bombardment, and encouraged our customers to avoid "boiling the ocean" in early implementation phases, and we have had a lot of success with this approach.

Fast forward a few years, and we're seeing the commoditization of such technologies as the service desk and CMDB.  More mature organizations are now focused on CMS, incorporating more than just change impact and root cause analysis information about their CIs, expanding to include Incident Management, Problem Management, Knowledge Management and Release Management.

EMA recently released its Enterprise Management Associates (EMA) RadarTM for CMDB/CMS Use Cases: From Database to Federation Q1 2012, addressing the crossroads that CMDB/CMS technologies are facing and how various vendors, CA Technologies included, are meeting the current and future needs of IT organizations. EMA took a use-case focused approach to the report, ranking vendors on functionality and cost effectiveness for Asset Management and Financial Optimization, Change Management and Change Impact Analysis, and Service Impact Management.

CA Technologies has been named a "Value Leader" across all three use cases in the EMA report. According to EMA's Dennis Drogseth, this is due to our "uniquely strong balance between cost effectiveness, design and functionality" and "commitment to helping customers streamline CMDB/CMS implementations, and to tie those efforts back to overall service management initiatives."

This makes me think we made the right call when it came to the top-down approach, enabling our customers to get value on their CMDB investment early in their implementations. The inclusion of CMDB within our CA Service Desk Manager offering positions us well for CMS initiatives as IT needs continue to evolve.

You can download the EMA report here.

Share this post:  

 

By: Crystal Miceli
Crystal Miceli serves as Sr. Principal Solution Marketing Manager for CA Technologies, specializing in Project & Portfolio Management, IT Asset Management and Service Desk solutions. Crystal has over 15 years of experience in designing and implementing IT Service Management solutions across a range...
Read More..

Service Management, Technical Support and Customer Service

Published: February 23 2012, 10:02 PM | 6 Comment(s)
by Eric Feldman

When we talk about service management, we often refer to IT systems and processes. But there is a human element as well, hence the emphasis on the word service.

 

I am sure everyone has had to call tech support and troubleshoot a software issue. And we all have our war stories of bad products and bad customer service.

 

But what do you do when the vendor needs you to solve their problem. Do you fix their issue, or take your business somewhere else?

 

I have an account with one of the largest banks in the world. I was recently reviewing bank statements online, and saving PDF copies locally. I had no issue opening and saving many different statements, until I tried to open a statement after a particular month. Then, my Internet Explorer browser would open a new blank window, and just hang there. Six months’ worth of statements were not available to me.

 

There was a change in the Bank’s infrastructure in their use of a new processing clearinghouse. They did have an alert on their website mentioning that I may have two statements for a period of time, as an overlap between the old bank processing and the new. It was immediately apparent to me that the bank statements could easily open in PDF form from their older clearinghouse, but would not work from the new one with my IE8 browser. And of course, I tried to access the statements from multiple computers.

 

I called the bank’s technical support to see if they could help. The support representative mentioned that they were aware of this issue (in ITIL terms, a known error), and proceeded to describe the symptoms which were an exact match to my experience. He then told me I could try a Safari browser which others had used to some degree of success. “I am using the most often used browser in the world, and this is an issue that you know exists. Why should I have to download and use a different piece of software to be compatible with you, when every company that I do business with supports IE8?” I told the rep.

 

He agreed to escalate the issue to the appropriate web team, and to get back to me within 2-3 days. Good thing we were not trying to accomplish something important, like online banking with a response like that. Surprisingly, he called me back about 6 hours later with a potential fix from their web team. “That was good service,” I mistakenly thought to myself. He proceeded to give me a few changes to my browser settings, which I had already tried, and knew would not solve the problem.

 

Since the so called “fix” from the bank did not work, the support rep told me that in order to escalate further, he would need screen shots from my browser which he would forward to the web team. Surprisingly, I could not contact the web team directly. There would be a problem, however, as the support rep could not accept any emails from outside the bank. I would not be able to send him these “required” screen shots - which I am not sure why they needed as this was a known error in the first place! To overcome their inability to accept outside emails, the support rep had a suggestion.

 

“If you can go down to your local bank branch, you could ask to login from one of their computers” mentioned the representative. “You can then ask them to send the screen shots to my attention, and I will forward to the web team.”

 

Startled by such a comment, I responded, “If I have to go to a branch to diagnose your known problem, I will just close my account. According to you, this is a known issue. I can open documents and statements from any other company without issue. So if I need to go to a branch to take screen shots to help you diagnose a problem you already know to exist, I will just close the account.”

 

“Well if you think you need to close the account, then go ahead” said the representative.

 

I have experienced many examples of bad customer service from banks. This is the first time that any company actually asked me to drive somewhere to document a problem they already know exists. And I might try to understand the bank’s point of view if the technical issue involved something proprietary or unique. But we are talking about an issue involving one of the most common activities - opening a bank statement - in the most ubiquitous of all document formats.

 

But of course, the bank did not attempt to understand my point of view. And while I know this bank may be a practitioner of service management principles, they certainly do not understand the meaning of the word “service.”

 

What about all of you? Do any of you have examples of bad customer service from banks or financial institutions? And how many of you have been requested to actually drive somewhere to help a multi-billion dollar company diagnose a problem they already know to exist?

 

Share this post:  

 

By: Eric Feldman
Eric Feldman has more than 25 years of experience as a senior architect. With a focus on the areas of service level management and IT asset and financial management, Feldman has specialized in designing and implementing solutions based on CA Service Catalog and CA Service Accounting. He has spoken and...
Read More..

IT will transform or be transformed

Published: February 21 2012, 09:50 PM | 4 Comment(s)
by Robert Stroud

Imagine for a moment that you get on the plane after using a valuable upgrade to get into a nice seat with allegedly better service, free movies (that you have probably already seen), a choice of meals and folks that call you by name. Unfortunately, you quickly realize that your expectations may need to be lowered. The staff keep skipping past you to take every body else's order for the meal, skip you during the drink service and forget your name constantly, and the worst outcome of all -- they forget to turn on the entertainment system.

The good news is that you reach your destination safely and on time - very important - but only by sitting through 10 hours of shocking (in a bad way) customer service. After you have traveled for a while on a single airline or airline group you become a captive audience to that airline. So what do you do? You suffer through a few bad experiences calling the airline, writing some emails, posting some tweets and the response is simply promises of better service or some points to your frequent flyer account.

Parallel this to the way that many businesses feel about their IT service delivery. Imagine that the business doesn't get the level of agility it needs with change taking too long. There is too much perceived "process" which is exacerbated with poor or non existent communication with the business. The business perceives little or no value from IT, and simply views it as a necessary evil. Many organizations simply refer to IT as the office of "NO."

IT doesn't have to be this way and in short if we don't transform we will be transformed.

When I spoke recently in Europe at a series of Application Portfolio Management events, a large part of the time was spent on the transformation that is taking place in many organizations. The transformation is sometimes by choice and sometimes imposed. I spoke to the head of IT with a large multi-country company who shared with me a story about the demise of the large central IT organization. The experience with the IT department was so bad that the business started investing directly in its own IT, creating a "Shadow IT" department. This was done initially for development; then they added delivery; and after 18 months there was no requirement for central IT.

The organization didn't own a datacenter, all infrastructure was delivered by third parties and the business was managing the relationship with the suppliers closely and established contracts that allowed them to rapidly transition to an alternative supplier should the service not meet expectation.

Value propositions of IT were agility, end-user satisfaction, adoption of capability through growing market share all whilst the business was profitable. The response from IT to this delivery was defensive of course, asking internal audit to be involved to ensure that the correct checks and balances were in place, privacy laws were being complied with, data was secure, continuity requirements were in place and so on. After a few months of reviews and a few debates with the CIO, head of the business division, the CEO and the CFO, the outcome was an excellent for all involved. IT established an Office of the CIO in Group IT that set base guidance for security, data privacy, and retention and agreed to negotiate and monitor contracts with third party providers. The business was responsible for all development, meeting capability requirements and so on. The result? Capability was close to the business, the business was driving IT-enabled business value, the responsibilities for IT were clarified and a charge-back agreement for the services consumed was met.

Back to my airline experience, yes the experience is true and the outcome is that I am transforming myself to leverage significantly more virtual meetings. I have changed airlines and I have no issue using social media to communicate both my excellent and poor experiences.

So what do you think, are you transforming or will you find yourself transformed? Just call me Robert "Transformed" Stroud.

Share this post:  

 

By: Robert Stroud
Robert Stroud serves as VP and as Service Management, Cloud Computing and Governance Evangelist at CA Technologies. Robert also serves as an International vice president of ISACA, is part of the Framework committee and was the former chair of the COBIT Steering Committee. Robert also serves on the itSMF...
Read More..

Customer Service making a difference and changing the way I travel to Europe

Published: February 09 2012, 04:09 PM | 2 Comment(s)
by Robert Stroud

For the next two weeks I will be traveling Europe hosting a series of executive round tables on Application Portfolio Management based on the Nordea case study where they saved 3.5 million Euro's. (Download the Nordea case study.)

Now, I love the interaction with senior business and IT representatives, but European travel in February can be challenging and with little margin for error. Based on a little research, I skipped making London my hub for the next 2 weeks and decided on Madrid, Spain - and based on my experience, I will never do anything differently.  From the moment I landed until 75 minutes later when I was in my hotel room the experience was brilliant - let me elaborate.

First we land exactly on time into the Terminal 4 and were directed with wonderful signage to the Immigration area where the whole process took no more than 10 minutes from gate to officer. My last visit to the UK saw gate to baggage claim at 90 minutes - thanks to long lines and only a few officers working the barriers.

After moving to the baggage claim, the belt advertised the time for baggage delivery to be 9:04 a.m. At 9:04 a.m., my expectations were met when the baggage arrived. Similarly, the hotel, which was aware of my flight arrival time, ensured they had a room available, well before the 3 p.m. check in time. I was in the gym before 10 a.m.  When I balance this against my usual experience in the UK, this is sensational and my future loyalty is assured.

As I was thinking about the positive customer experience and how it will impact my future travel plans, it led to my thoughts about how service managers could learn from this experience. In this trip, my expectations had been set throughout the whole experience:  

  • At the plane, the time to immigration was documented
  • The immigration area was appropriately staffed
  • My expectations were set by baggage claim with a time for my baggage arrival
  • The hotel emailed me the shuttle schedule so I would know precisely when a shuttle would be available.

In this new normal the traditional service management approach must transition from reactive incident resolution to incident deflection. In short, if you don't deflect incidents - the customers will defect. In fact I would argue that they are already defecting. Do you search the Internet or ask a friend for the answer or call the service desk? I know that I personally don't call a service desk unless I absolutely have to and then I do it begrudgingly! (note to American Airlines - why can't I request an international upgrade online?)

This is a cultural change for service management implementations everywhere. The need to focus on empowering the client forces a change to traditional service desk metrics. In the future, they should be relevant to a smaller number of calls as the value of the service management team moves to empowerment of the user. A little scary for traditionalists, but the world is changing as the IT millennials storm the workplace!

So from your virtual millennial, I continue my Europe adventure and will share more insights soon.  

Share this post:  

 

By: Robert Stroud
Robert Stroud serves as VP and as Service Management, Cloud Computing and Governance Evangelist at CA Technologies. Robert also serves as an International vice president of ISACA, is part of the Framework committee and was the former chair of the COBIT Steering Committee. Robert also serves on the itSMF...
Read More..

Service Catalog - The Driving Force to Deliver the Cloud

Published: February 03 2012, 02:33 PM | no comments
by Eric Feldman

With the widespread adoption of cloud services, there is enormous effort to define offerings and align to market based pricing.

Let's face it. If you are going through a cloud transformation initiative, one of your business drivers is to reduce expenditures. In order to calculate your savings, you must have at least some basis of comparison of the service cost or value. And to calculate service costs, you must first define those services. This is a business exercise, yet I see many companies incorrectly focus their cloud initiative exclusively on their infrastructure.

But how does a Service Catalog help with an enterprise or MSP cloud initiative?

We can explain this better with a more familiar metaphor. When you are in a restaurant, you have no knowledge of the types of stoves, cooking utensils, or what brand of knives the chef uses. While you will see a waiter or server write your orders on a piece of paper, you are not aware of the ticketing system used - whether the paper is given to the kitchen staff, or the order is entered into software. In reality, what is in the kitchen is almost irrelevant.

What you are aware of is the menu and the descriptions of choices which can be written in elaborate or simplistic terms. You know the price, and how the food offerings are bundled. And you might know the approximate time your food will be delivered, either informally, or by explicit obligation. Remember the pizza guarantee, delivered in 30 minutes, or it is free?

Do you really care how your food is prepared in terms of the type of  equipment used as long as it meets or exceeds your expectations, provides good value for the price, and service is appropriate? Does it matter how many burners are on the stove, or how many BTUs it consumes per dinner?

A similar environment exists for cloud services. When you request something from an enterprise catalog, you do not care what, if any, automation tools are employed, nor do you typically care about the process used to deliver the service. You do care that the service is delivered in the expected timeframe, is appropriate to your needs, and if being charged for its use, is priced competitively to market equivalents.

As a result, the Service Catalog becomes the central and primary component of a cloud initiative. In this regard, we refer to a Service Catalog as the "driving force to deliver the cloud." It provides the basis and environment for which cloud services can be defined and delivered.

The Service Catalog is not the actual service - regardless if it is cloud based, virtual, or with physical elements - but it provides a representation or abstraction of the various components and parameters. A Service Catalog is not the process, but provides seamless access to the process from an end user. A Service Catalog is not the infrastructure, but enables a pathway to leverage its use via the process. And a Service Catalog is not a specific entry to a general ledger, but it does publish the price, and can calculate and charge for the service usage.

When planning cloud service deployments, many IT organizations concentrate their efforts on infrastructure and tools. I refer to this as a bottom up approach - the equivalent of a new restaurant deciding upon the brand of stove, pots and pans, and refrigerator before the recipes or menu are prepared.

A better way may be the top down approach - beginning with a type of cuisine, recipes, pricing, and menu - and then building the appropriate kitchen. IT operations are really no different. Cloud service deployments should begin with the service portfolio, the service definition, and how they will be published in the service catalog, or the driving force to deliver the cloud.

For an example of how CA Technologies is leading the industry in providing agile and innovative cloud solutions, see our recent announcement for the CA Private Cloud Accelerator for VblockTM Platforms, a new solution to enable enterprises and managed service providers to offer automated self-service delivery of infrastructure as a service.

 Menu image used under Creative Commons License courtesty of pellis.

Share this post:  

 

By: Eric Feldman
Eric Feldman has more than 25 years of experience as a senior architect. With a focus on the areas of service level management and IT asset and financial management, Feldman has specialized in designing and implementing solutions based on CA Service Catalog and CA Service Accounting. He has spoken and...
Read More..

More Posts Next page »