Published: July 01 2009, 11:12 AM | no comments
by Robert Stroud

Part I can be viewed here.

As I mentioned previously, I spoke last week at a joint Korean itSMF and ISACA conference. This post continues with additional answers I prepared, answering excellent questions raised by the facilitator of the closing panel session.

The second question asked at the panel was an interesting one about inhibitors and accelerators for service management.  As many of you know I spend a good amount of time with large IT organizations globally so this allowed me to share some practical advice from a large Bank.

Question 2: How do we drive IT governance through ITSM or IT governance frameworks such as COBIT, VALIT? What are key accelerators and critical inhibitors? How these frameworks fit with IT organization of the future?

• When I met recently with the CIO and CTO of a large global Bank, she mentioned that one thing happening today is the rate of change and the fact that more change is being generated by the business rather than IT.  She quoted the example of interest rate changes that are controlled by the business and executed automatically by IT as a good example of IT automating Business As Usual (BAU) and collecting the relevant audit check points and approvals.  She also mentioned that social media and collaboration is transitioning business - staff are dynamically communicating and searching for resolutions to problems or knowledge for "how to scenarios" using technologies like Twitter and Facebook. Sales is using LinkedIn connections to drive business relationships. Web 2.0 is changing again, accelerating the rate of change and the way that functionality is delivered to our working environment.This is the perfect catalyst for changing the manner that we deliver technology to support the business. 
• The best accelerator is for IT to acknowledge it is part of the business and for the business to acknowledge that it is dependent on IT. There are few industries or even business processes today where IT is not on the critical path to service delivery. This mandates a phase in enterprise change and that the processes that IT employs are NOT onerous but appropriate based on business risk. 
• The risk here is that we become so focused on the process and not the risk to the business that we unnecessarily add delays to delivery of service. Thus like the little boy who cried wolf, when the real risk is exposed IT, it will not be believed and we will again fail, further increasing the divide between IT and the business.

Published: June 30 2009, 05:10 PM | 4 Comment(s)
by Eric Feldman

Many companies adopting a Service Catalog are faced with a dilemma. How do they define their services? Actually, there are two components to service definition. One is the processes employed to deliver or enable the service. These can be documented in a process modeling application, or made actionable using a tool, such as CA Workflow or CA IT Process Automation Manager. This is the "behind the scenes" part of a service definition.

While this is important from the Service Definition and Lifecycle perspective, I wanted to focus this time on the specific definition that is published in a catalog. If you think about it, most customers and department managers are concerned with what they are choosing from a catalog, not how it will be delivered to them.

Ever shop online? Many online merchants have setup elaborate systems to help you choose a product or service. There are glowing descriptions, photos, videos, customer testimonials, and rating systems. You may even see a service level listed, representing the time frame where the product will be delivered.

On the other hand, do you see an activity diagram detailing how your credit card will be authorized, how the product will be picked from the warehouse, and how shipper routing decisions will be made? You don't. While this information is important from the provider point of view, it is almost irrelevant from the customer's perspective. They certainly care about receiving their product within a specified or reasonable time. How that product arrives is typically of no concern.

To establish a Service Catalog, you must follow a similar mindset. The process behind the service definition is important, but primarily from the IT or service provider perspective. The backend, if you will. It is the technique and style you use to define the service from the customer or end user's point of view that becomes crucial, especially when acceptance or adoption of the Catalog is of concern.

But how does an IT organization actually describe their offerings? The technique is easy to describe from a high level:  Keep it informative, yet simple to describe. Think outcomes, not components. And use value added language that is meaningful to the appropriate user community. For example, a storage service could be described as “300 Gb logical volume size using SAS hard drives in a Raid 5 array. This description may be suitable for a technical user audience. For many business users, however, this information is inappropriate. A far more meaningful description may be “Reliable and secure data storage."

The Service Catalog is the publishing vehicle where IT does not just define their offerings. It also communicates their value to the business community.

Which brings us back to the original question. "My Cousin Vinny" and "Song Airlines" both can show us examples of how a Service Catalog was deployed. Each illustrates the parameters I described above, in entirely different ways.

In "My Cousin Vinny" the characters played by Joe Pesci and Marisa Tomei go to a diner and are handed a menu. It says simply "Breakfast," "Lunch," and "Dinner."

Song Airlines was a former division of Delta Airlines that featured an "upscale bistro" menu of food for purchase. It detailed elaborate descriptions of offerings more gourmet than geek. Here is an actual description taken from a Song menu: "Asian Chicken Salad. No, you don't have to eat it with chopsticks: Ginger-marinated chicken *** with romaine, napa cabbage, shredded carrots, water chestnuts and mandarin oranges. Served with chow mein noodles for crunch and a sesame-ginger vinaigrette for kick."

So, which method are you using to represent your organization's value? Do you use the "My Cousin Vinny" or the "Song Airlines" technique?

Or to ask this question in a different way, are you using relevant value oriented language in your Service Catalog, or do you get by with just a simple two word description such as "request access?"

Published: June 27 2009, 08:23 PM | 6 Comment(s)
by Peter Doherty

At CA Expo here in Oz I asked the 200 people in my session who thought they were an ITIL V3 shop and probably 20 or so hands went up sheepishly. Maybe the reason for this is that they have seen what happens to people who put their hands up in response to my questions or maybe they were unsure.

Word out of the latest Gartner conference is that lots of IT organisations are adopting V3.  Now for the record, I think they should. But just because I think they should does not mean that they are. So here in Oz, which is a very mature Service Management market, I get mixed feedback about the adoption of V3. When I asked the same question in the Sydney Expo I told some of the people to put their hands down (see what I meant about putting your hand up in my sessions!). So why did I ask them to put their hands down? For the same reason that I do not think there is the ITIL V3 uptake that the analysts are quoting.

And that reason is that if you are just doing Incident, Problem, Change, don’t kid yourself that you are a V3 shop. It is really good that you are doing those things, don’t get me wrong. It is just that IT is so bad at managing expectations and here is another example:

You need to be doing more than the old Service Support processes.

So are the analysts wrong? And if so where are they getting the data? Or are they asking the wrong questions? I think it is a combination of things. I twitter on Service Management (@ITILNinja) and David Ratcliff of Pink Elephant (@pinkerdavid) asked the question about why are we twittering on advanced topics when most people are still crawling? And he is so right.

There are so many shops out there still implementing the SS processes and here I am talking about Service Portfolio Management. If you are struggling with Incident and Change, SPM is fantasyland. But I want people to start thinking about how good fantasyland could be!

And this is how I think you can define yourself as an ITIL V3 shop – you have started to think and plan to eventually get to Peter’s fantasyland and it is a good place!
 
You are an ITIL V3 shop if you have started to embrace some of the new processes and are talking about a Service Lifecycle. Sorry, not just talking about it but it is starting to become part of the culture. When you start appointing Service owners and Business Relationship Managers that actually talk to the business, not just other parts of IT.

So if an analyst asks you whether you are a V3 shop or not, forget about the pressure for you to say yes and ask yourself how you stack up against some of my basic criteria and also ask yourself whether your CIO talks about this as well.

As I always like to do – if you think you are a V3 shop, leave a comment and tell me why.

Published: June 26 2009, 01:18 PM | 2 Comment(s)
by Jeff Foucher

I'm pretty amazed at the seemingly endless discussion and un-evolved thinking around "aligning IT with the business." Various machinations have surfaced ("it's about IT being part of the business" or "it's about aligning IT and business") and at least a dozen vendor-driven acronyms have emerged all purporting to put IT & business on the same page. However, I've yet to see a more detailed, behavioral analysis applied to better understanding the underlying human factors which still make this a relevant discourse and one that still appears to keep executives up at night.

As an IT outsider, it seems that this is no different than any other inter-departmental cultural divide hindered by a general misunderstanding of what one party perceives to be of value, exacerbated by disparate metrics and measures, and undermined by intra-departmental silos of dysfunction.

Finding Common Ground

As with any cultural divide, there are fundamental steps which can be taken to ensure that both parties find mutual benefit and success. And of course, technology can help play a part. Hence, a four part plan for IT:

1. Common Goals: As with any business, this is all about IT getting lean and orienting itself around a value/cost/risk axis. Starting with a firm (documented) understanding of business goals and priorities, IT then can establish a customer-centric beacon upon which all activities are then managed, executed and measured. If it's not on the business agenda, it should never get onto the IT agenda.

2. Common Language: In most areas of business, and certainly all areas of the public domain (government, education, healthcare), the value orientation is predicated upon the services being delivered to customers. Even manufacturing ‘output' can be considered a service since without the underlying orchestration of the supply chain, nothing would ever be built. Likewise, IT should start with the ‘language of business' and ground itself in the management of its own IT service portfolio. This requires a full understanding of IT cost, quality & function packaged in terms of the services being delivered or supported.

3. Common Currency: While business is based upon a service orientation, the way the business operates is actually quite different. Accounting principles require a more detailed view beyond just the ‘cost of the service' - for purposes of depreciation, tax, operating margins and capital expense. A service oriented view of IT "cost" is absolutely needed to establish a common language with the business around value, but the currency of business is more rigorous and requires cost accounting principles applied to asset expenses, labor expenses, application costs, license costs, maintenance on hardware, communications, infrastructure. Similarly, IT Financial Management must be able to plan, actualize and optimize its expense base against these same principles and detail -- whether they are IT assets or projects or telecom expenses or software contracts.

4. Common Knowledge: Underpinning all of this is the ability for organizations to create a shared sense of purpose, allowing them to galvanize against common goals with a unified language and currency system. In IT, this is essential to breaking down the long-standing silos of disconnect which have undermined IT for years. ITIL plays an essential role here, by focusing on processes, which quickly afford one function to realize their own role in the context of the broader organization.

Building A Common Culture

In the end, business may or may not care to engage fruitfully in an ‘alignment' discussion with IT. But they are forever connected to IT as their lifeline to innovation and competitive advantage. But by establishing a common framework for success based on shared goals, a language everyone understands, a single currency system and a shared knowledge base, IT leaders can indeed become business leaders and along the way, improve the way the business itself operates by embracing and driving toward a common culture of success.

How has Technology helped you bridge the divide?

Published: June 24 2009, 04:30 PM | 1 Comment(s)
by Robert Stroud

This week I was in Korea for the joint Korean itSMF and ISACA conference. Understanding the issues surrounding the business climate and the demands on their members' time and finances, these two organizations worked together for a single event instead of their usual independent events. The event was a huge success based on the attendance, attendee comments, press comments and the smiles on the organizers' faces. 

I spoke about Governance for your ITSM environment--more on that next week--and I wanted to share with you my prepared comments to the excellent questions raised by the facilitator of the closing panel session.

Questions: As you may know, we are facing a world economic crisis and many leading firms demand to sustain their businesses. What's your perspective on the role of ITSM and IT governance to sustain our business (in terms of efficiency) in this crisis? What can you suggest based on your global experiences, providing recent case examples? Will ITIL-based ITSM solutions or VAL IT enable us to sustain our businesses during this particular period?

• At the moment, the global focus is clearly on cost reduction. Unfortunately much of this is based on simply cutting people, deferring investments, wholesale removal of a service or introduction of service delays. Instead, focus needs to be on real immediate savings and this needs to be linked to business demands. 
• Frameworks, including ITIL or COBIT, give us the opportunity to deliver efficiencies but only where they are delivered through automation of process with a focus on the reduction in complexity - these must be linked to the demand side and the organization's strategy.
• We must balance supply and demand. 
• One of the real opportunities here is to expose the business to the operational services that are being delivered and the costs associated with their delivery, proactively providing information on how to reduce these costs. 
•  The Service Catalog is an good example of this - where the business consumes services expressed in business terms with business based service levels. IT has to opportunity to associate costs with the various service levels. 
• These services must be reviewed on a regular basis with efficiencies reviewed with the business - not just evaluated by IT.
• One example of this is a power company in the U.S. that is using COBIT for Governance and setting controls for risks and exposures. It also is linking IT strategy to the business strategy.  This organization uses ITIL for Service Management, uses PMBOK for project management and currently is implementing the Investment Management domain within VALIT. 
  
  The company has implemented a Service Catalog that defines business services. It has implemented self help for issue resolution, and the service catalog allows users to consume services acknowledging cost and all investments are linked to business strategy.
• This organization has been dictated a 10% overall cost reduction
• Immediately the investments could be prioritized for relevance to the new strategy of cost reduction. Projects were all reviewed and by slowing down several and completely removing two, a 15% saving was made.
• Operations wrote to all users of services that leveraged consumption-based third parties and advised them of the opportunity to cut costs.
• IT identified that by accelerating the VOIP initiative they could save 3% from the total IT budget in the first partial year of operation after all costs. Because of the near-term cost-savings, this project was accelerated.
• Self-service Catalog automation increased and provided another 2% saving.
• Overall the 11% of real savings were delivered.

What do you think?

Published: June 23 2009, 11:50 AM | no comments
by Marvin Waschke

There are many difficulties involved in CMDB federation that the CMDBf specification helps address.

 When you set out to integrate a CMDB product with another data source, such as another CMDB or a specialized device monitor, there are several steps that you must take and with each step there are choices to make.

Perhaps the most important architectural choice is the level on which to federate. You can choose to federate on a database to database level. That involves a detailed knowledge of the schema of both the target and the source system, and the federation is likely to break if the schema of either system changes. Because the schema is intimately tied to the internal operation of the applications, schema changes occur frequently when either the data source or target changes. Often, schemas are not designed with federation in mind and so data that is not relevant to federation may appear as columns in the same tables as federation data. This can complicate transactions and cause the federation to break when an unrelated feature in the federation source changes. In addition, exchanging schema information can become a thorny intellectual property problem, especially when the source and target are from rival vendors.

Due to the difficulties of database to database integration, APIs are often used instead. Using this strategy two products communicate by each calling the published APIs instead of reading or updating a database. These APIs are usually designed and published to support integration. Consequently, they do not require intimate knowledge of the products that support them and they tend to change less often than database schemas that often change to support new features and efficiencies. And finally, APIs are better documented than schemas.

API to API integrations are a distinct improvement, but they still have problems. For example, they still are subject to breaking if either party changes their API with a product change. Sometimes, good engineering rules are followed and the APIs are backward compatible so that existing integrations do not break, but this is not guaranteed. In addition, as new features are incorporated into products, new APIs are often added and integrations must change in order to take advantage of new capabilities. There is often little incentive to vendors to roll new features into existing APIs, which is often much more difficult than inventing a new API. This means that new releases always threaten the federation and adds an element of unreliability. Not only is there danger of  downtime and recoding costs, remediation for the unreliability also incurs more cost in the form of extended testing and more elaborate transition plans with new releases.

Most seriously, the APIs for every MDR and federating CMDB are all different. That means each integration project has to be designed and engineered individually. Not only is development of this form of federation expensive, each integration must be supported individually by engineers specially trained on the specific federation, which eliminates economies of scale in support.

In a word, API to API federation is expensive to the supplier of the federation and inconvenient to the user of the federation.

The CMDBf is a public specification for API to API integration and addresses two of the substantial problems involved with that type of federation. First, it puts everyone on the same API. Second, by placing changes to the specification in the hands of an organization like the DMTF, the change process is stabilized and the specification undergoes industry-wide scrutiny before it changes. Like code reviews in software development, this scrutiny can eliminate a large share of the problems with federation breakage.

When the specification becomes widely accepted, basically the same integration can be repeated and supported over and over again. The process of building a federation between an MDR and a CMDB requires a thorough understanding of the APIs of both the MDR and the CMDB.  Typically, the developer is only familiar with one of the two and has to fight a learning curve to master the unknown API. Then the federation must be designed, implemented and tested at considerable expense. If standard APIs are used, which apply to both MDRs and federating CMDBs, the expense and risk is not eliminated, but they are both reduced. The learning curve is diminished because the developer is experienced in the standard API, and much of the code will be identical to that used in previous CMDBf-based projects. Although specialized data may be unfamiliar and require some special processing, that is a small part of the entire undertaking. The bulk of the work and risk is eliminated by using the standard interface.

It is hard to over-estimate the importance of these basic improvements that come from standardization. There are other improvements that can be made to CMDB integration, but they all depend upon a well-defined and standardized API.

This is not the whole CMDBf story, but it is an important part. I'll be blogging more on this.

Published: June 19 2009, 01:38 PM | 1 Comment(s)
by Eric Feldman

I know of a company that has a very large user community. Most of the entry pathway to IT was via telephone. While there also were a significant number of email requests for services, their process required a help desk analyst to call the requestor back.

The company knew that a Service Catalog would enable a massive reduction in the number of phone calls to or from IT. This alone would help them down their path to Lean IT and a reduction in costly manual touch points.

There was another issue. Besides a minimal amount of IT process automation, the company offers unlimited IT support, for unlimited cost. Support and IT offerings were so widespread, that people were even phoning the help desk to open issues about their personal IPods and cell phones. As a service organization, there was a perception that it was their job to fix anything. Hence, it was often difficult denying these requests for services that would not be supported in most other organizations.

The IT department realized that offering unlimited support for anything the user wanted was an unsustainable model.

Yet they had a challenge. How could they reduce the need to provide unlimited support for personal items or systems outside of their domain, without the appearance of saying "no?"

How many of you find this situation familiar?

This is where a Service Catalog is of value, by changing perceptions and "reframing the conversation" around what IT does offer, not what it does not.

There are parallels to this concept found within virtually any other industry. An airline will not fly you to any city. They have routes and schedules -- not that they actually meet those schedules. A movie theatre does not show whatever film you desire at the moment. They have movie times and distribution agreements for only the latest releases. And you cannot go into a restaurant and order anything you like. It must be on the menu.

When IT or another provider organization within the enterprise, establishes a Service Catalog, they create a publishing vehicle. This enables them to define their offerings in descriptive terms, with associated costs, service levels, deliverables, and metrics for performance. A Service Catalog enables IT to illustrate the value of its offerings.

And by listing only what services are offered from IT, you can naturally provide a reduction in non-supported service requests, without the need to say "no." How?

Think about the next time you go out to eat. You do not go to a pizzeria and order Chinese food. You do not typically enter a seafood restaurant and order a cheeseburger. Why not?

It is not on the menu.

Published: June 17 2009, 03:43 AM | no comments
by Robert Stroud

The last few weeks meeting with organizations in New Zealand, Australia, India, France, Denmark, UK and the U.S. reinforced that the current economic climate is forcing IT organizations to get lean. 

Lean for IT does not mean slim and trim; lean in IT is about maximizing IT value while minimizing cost. For lean IT service management it requires focusing on the components that matter to the business to ensure that IT can deliver what the business needs at the right time and optimize service supply and demand. 

In my June 8 blog I discussed a conversation I had in India with a CIO and his approach to "leaning up" his IT organization by using a service catalog.  Not surprising, I am finding this approach is being applied by other organizations globally.

While attending the CA Expo in France earlier this month, another CIO commented that his business is now demanding to see a list of the services that IT can deliver with business related service levels and costs.  Users (or consumers as I like to call them) of IT-enabled business services are becoming more IT savvy. Just think about the growth in sales of goods and services over the internet such as books, airline tickets or satellite television.  Consumers are now very used to identification, negotiation, ordering and tracking goods and services electronically with the expressed service level agreement and cost clearly outlined. In business this is achieved using a business service catalog.  The business expectations are set, the business is engaged and understands the implications of its choice, and the decisions for cost reduction are transferred to the business rather than IT. This helps ensure IT support is directly aligned to business need - helping optimize service supply and demand.  

Published: June 11 2009, 03:59 PM | no comments
by Marvin Waschke

After a short hiatus from blogging, I'd like to ease back into it with a short series on CMDB federation. I will start with the problem itself.

The CMDB federation problem is highlighted in ITIL v3 where the Service Asset Configuration Management (SACM) and the Configuration Management System (CMS) both describe a number of databases working together in a federation to provide configuration management. IT system management architects knew long before ITIL v3 that effective configuration management hinges on bringing together data from many contributing sources and keeping the consolidated data current and accurate. This is one of the challenges at the foundation of enterprise IT management.

The driver behind this desire to combine configuration data sources stems from the heterogeneity of typical IT environments. They are usually a mixture of products from many vendors and usually include a few custom applications that are unique to the site. Good configuration management requires collecting information from all these sources into a single CMDB. Efforts to implement a single database as the CMDB have proved to be more difficult than expected and requirements have shifted toward federation.

The CMDBf spec addresses the difficulty in implementing effective federation between CMDBs and other subsidiary data sources (MDRs). This includes CMDB to CMDB federation. There is a lot of legitimate discussion of the meaning of federation. In the CMDBf context, federation means giving one application access to data from another application. Many people put additional requirements on federation, distinguishing between ETL (Extract, Transfer, and Load) technologies that literally copy data from one application to another and federation technologies that avoid copying data. These are good distinctions to make, but CMDB federation can involve both ETL and strict "non-copying" federation.

Whether there is copying of data or not, the essential characteristics of CMDB federation are related to the content of the data transferred and the way the data is used. A CMDB data consists of CIs (Configuration Items) which represent the physical and logical components of an IT system and relationships, which represent the physical and logical connections between CIs. A CMDB is used to control and understand the IT system. In many ways, the content of a federated CMDB is analogous to the blueprint of an IT system.

Next up:  What is wrong with federation without a standard?

Published: June 10 2009, 01:30 PM | no comments
by Jeff Foucher

A recent study found nearly 40 percent of large enterprises in North America do not have automated asset discovery and inventory management in place today.   When you consider the impact of IT assets as a percentage of an organization's capital expense, it begs the question: Just Who Is Minding The Farm?

IT wants to be viewed as an equal partner to the Business it supports, yet the mere notion that the IT estate is left to manual data entry or spreadsheets on its most critical, tangible and costly investments seems absurd.  

Is it possible that such a basic housekeeping function of IT can be so absent in today's modern world? If I'm in any other business, managing my inventory is so critical to the health and well-being of my bottom line, that leaving it to chance, or spreadsheets would seem otherworldly....or at least third-worldly.

With the emergence of smart phones, netbooks and the proliferation of laptops, Blackberries, iPhones and other access devices - each carrying unique software licenses, configurations and inherent data security risks --- how could this be possible?

If the old adage "you can't manage what you don't know" still holds - how can anyone in IT talk about managing IT services when many of them - almost a majority of them - don't even know where the "sticks and bricks" are?

Anyone fitting this profile and even broaching the four letter acronym CMDB must mean:  "Chickens Missing Dear Brother."

Published: June 10 2009, 09:20 AM | no comments
by Peter Doherty

What a week, nearly 2000 people evenly split across Melbourne and Sydney attended CA Expo here in Oz. It just gets bigger and better every year. Though you know one of my key performance indicators for an event like this is not how many people turn for the Keynote (sorry John and Ajei), it is how many stay around for the final sessions. I had nearly 200 people in my session in both cities on the ‘5 killer ITIL V3 processes to drive value’ in the Service Management stream! Incredible turn out for the end of a long, information packed day.

With the Global Economic Crisis we were preparing for a downturn in numbers but that was certainly not the case.

John Swainsons keynote talked a lot about Lean IT and the message resonated with many attendees as they are expected to continue providing high levels of service with diminishing budgets. They need to remove waste and increase efficiencies and this blog contains lots of information on Lean IT by my fellow contributors for you to read. The thing that started the whole Keynote off well was Johns venture into Second Life where we watched a virtual image of John come to Australia and encounter just about every stereotype of Australian culture there is. Australians enjoy some one with the ability to put themselves out there and to me it was a great success. At the end of the Keynote John invited Ajei to join him in Second Like and then Ajei came out on stage with a cricket bat and actually looked like he knew to use it was a great finale to the session as Ajei then showed how CA does some of the stuff John talked about.

The day was then split up into Manage, Govern and Secure streams. The first Manage stream was a panel session With Brian Bell, Tanvir Hussain and Chris Cook. It was pretty clear from the amount of Service Management questions from the Melbourne audience that it is quite mature here whilst Sydney had more about Lean IT. As an indicator of the importance of these topics this panel session there was standing room only in both cities – and they were large rooms.

The first general Service Management session was on ‘Managing Demand Across the Enterprise’. It concentrated on using Service Portfolio Management and Service Catalogue to evaluate and deliver both Strategic and Tactical Demand and it covered many things that I have blogged about here.

The University of NSW then presented on their Service Management implementation with CA and as a testament to the openness of the session it did not just cover the highlights but also explored the challenges and lessons learnt.

In my opinion, Knowledge Management is one of the Killer ITIL V3 processes yet so few customers have embraced it. One customer that has been using it to drive operational excellence for some time is Insurance Australia Group, who presented a session on this.

The stand out Service Management session was the next one, no need to guess who presented it! It talked a little about the overall new approach of ITIL V3 and then went into the processes that can drive most value. I have blogged about them all here previously.

And the last session was by Datacom on how they are simplifying managing customers in an MSP environment.

All in all a great event with many customers providing great feedback

Published: June 09 2009, 02:25 PM | 2 Comment(s)
by Eric Feldman

As companies strive to maximize value and optimize service supply and demand, they are employing Lean IT principles. One way to understand and maximize value is to have a thorough understanding of IT finance, from cost structure to consumption. Armed with this knowledge, an IT executive could potentially answer some important questions about his company's business model:

What is my cost of doing business?

• Am I competitive with other businesses in my industry?
• Can I be price competitive with an external vendor, outsourcer, or service provider?
• Is the unit cost indicative of the value of the services?

To answer these questions and more, I have developed a six-step method by which IT can calculate its consumption in financial terms. 

1. Define the service in business terms

• 2. Calculate or estimate the service cost within a fiscal time period
• 3. Decide upon a unit of measure that is meaningful to the business and appropriate to the defined service
• 4. Collect the usage metrics for the service grouped by the appropriate organizational unit (business unit, cost center, department, user)
• 5. Divide the service cost by the total usage to calculate a unit cost or price
• 6. Multiply the unit cost by the usage metric attributable to each organizational unit to determine the discrete financial impact of service usage

Some of these steps your company may have already accomplished. For example, if you are currently employing a Service Catalog, then you should be in good shape for step one. These are not necessarily difficult tasks, however they are not trivial either. This method will take a good degree of thought. Time is also needed, not because of difficulty, but to smooth out usage and cost variations.

Any company attempting this exercise will be met with several challenges:

• The organization may not know their service definitions
• They may not have visibility into their costs, or they attempt to make their costing model too simple or too complicated
• They may attempt to use operational or performance metrics when they should be looking at usage metrics
• Technology sometimes gets in the way of any meaningful metric grouping. For example, it can be difficult to calculate network bandwidth usage attributable to an individual user with an IP address obtained via DHCP.

This is obviously a simplistic view of what could be a very intricate topic. Like any financial model which could be developed in a reasonable timeframe, you will need time to understand patterns in the numbers. For example, if you use "transaction count" as a usage metric, one month's worth of data will not provide you with a significant per unit price. You will need at least six months of data for any meaningful analysis.

What challenges do you have with IT financial management?

Published: June 08 2009, 10:01 AM | 1 Comment(s)
by Robert Stroud

I was speaking with the CIO of a large IT organization while at the ISO working group meetings in India recently and he told me about the recent directive he had received to cut the IT expenditure in 2010\2011 by 10 Percent - or in CA-terms, get a bit more "lean" when it comes to IT and minimize cost and reduce waste, while still providing maximum value.  I am sure you will agree is not an unusual order in this climate, and I was very interested in what his approach to the problem would be.

Cutting headcount, although possible, was not his highest priority. Simply cutting staff without other changes may deliver the saving, but it would also reduce service.  He could also look to virtualization of services, outsource some or all the services, or press his vendors for contract savings.  The answer is partially in each of these scenarios, with some already in progress. But the real opportunity is for IT to use the organization's focus on costs to get closer to the business and let the business be accountable for the services that IT offer.

I pressed him on how this would be done from a practical perspective and his answer was indeed music to my ears -- a service catalog. A service catalog that isn't populated with IT systems, but rather offers services that the business consumes, described in business terms, not IT terms. It includes business service levels and realistic business costs, and even though the business will not initially be charged for the services, usage reports will be provided to the CIO. 

The winner here will be when the services are defined from the business perspective with metrics and documented importance to the business. That is when the IT organization will make decisions based on valid organizational data to cut real IT costs and drive automation, process improvement, outsourcing, virtualization and communication to the business of IT's contribution. 

It is clearly time to stop using over capacity as the vehicle for IT service delivery and make some hard decisions with the business about value and cost. Having that discussion in IT terms will not improve your credibility so it's time to offer IT-driven business services through a true Service Catalog.  And while you are doing this, remember that you need to balance demand with the basic principles of Lean IT!

Published: June 03 2009, 09:47 AM | no comments
by Robert Stroud

Not long ago I blogged on the recently announced ISACA Strategy. And lately there has been some commentary on the future of ISACA and the itSMF. As a Board member on both organizations I thought I would take a few moments to discuss one of the intersections between the two organizations.

ISACA, a global organization of IT professionals, is dedicated to delivering value to its membership with the delivery of guidance and frameworks such as COBIT.  Increasingly over the past six years I have been asked to communicate to ITSM professionals the value of COBIT and how ITIL and COBIT can be used together for business value. The industry press, analysts and even bloggers have acknowledged that the two bodies of knowledge are complementary.  For example COBIT 4.1, the Delivery and Support domain, and ITIL are very strongly aligned.  (COBIT 4.1 is a free download from the ISACA website http://www.isaca.org/).  More recently, we on the ISACA team worked very closely with professionals across both the ITIL and COBIT domains to produce the Service Managers Guide, which ITSM professionals have shown interest in and value.  This publication teams well with the publication Mapping COBIT, ITIL and ISO/IEC 27002 for Business Benefit which is freely available to both members and non-members.

ISACA recognize that ensuring continued complementary deliverables in the ITSM space is important.  That said, the scope of ISACA is to serve IT professionals who cover a much wider range than ITSM.  This is evident from reviewing the COBIT publication series.

COBIT Mapping: Mapping of ITIL V3 with COBIT 4.1

COBIT Mapping: Mapping of NIST SP800-53 Rev 1 with COBIT 4.1

COBIT Mapping: Mapping of TOGAF 8.1 with COBIT 4.0

COBIT Mapping: Mapping of CMMI® for Development V1.2 with COBIT 4.0

COBIT Mapping Overview of International IT Guidance 2nd Edition

The scope of COBIT is the complete lifecycle from inception to retirement dealing with all aspects of the IT department and its relationships across the enterprise. 

ITSM practitioners are increasingly demanding more detailed information around execution, as governance has become a more important topic.  This is demonstrated in the cooperation we see between local chapters of both ISACA and itSMF which are coordinating locally on ITSM issues.  ISACA believes its membership can add value to ITSM professionals by providing additional, relevant materials to complement the use of and proficiency with ITIL.

Published: May 28 2009, 05:49 PM | 1 Comment(s)
by Peter Doherty

I deal with a great many Service Management Programs from many different perspectives and one thing I often see is that we do not know how to enable the participants’ ability to learn. You will notice I did not say train as these are two totally separate things.

Learning is about enabling an environment where the people involved actually want to learn and one which caters to the learning needs of the individual. Gone are the days of expecting everybody to learn the same way.

I have just had an article published on SearchCIO.com that covers innovative ways of enabling the individuals to learn. It also talks about target programs that are based on roles and responsibilities as opposed to a cookie cuter approach that really misses most people.

The article can be found at http://searchcio.techtarget.com/tip/0,289483,sid182_gci1357303_mem1,00.html?track=NL-983&ad=705072&asrc=EM_NLT_7192212 and I would certainly be interested in peoples comments who have come up against cultural challenges around learning.