Tag Archives: Service Catalog

Six PDG (Pretty Darn Good) Reasons for IT to (truly) define Services

Share twitterlinkedinmail

How would you answer the following question?

“How does your IT organization deliver real business value?”

In the October 6, 2016 CIO.com article, “Business value is key to IT success”[1], Mike Sisco describes business value as including five very specific things:

  1. Increase revenue
  2. Decrease cost
  3. Improve productivity
  4. Differentiate the company
  5. Improve client satisfaction

Does your IT organization have a role in delivering business value? Sure, it does. Does your business know what IT does to deliver business value? Unfortunately, in many businesses, the answer is “no”.

Is it the fault of our business colleagues that they don’t know what IT does to deliver value? In my opinion, it is IT’s job to educate the business regarding how it delivers value.

Can your IT organization articulate how it delivers business value? That’s often the challenge with many IT organizations, especially if they’ve not defined services in terms of business value and outcomes.

Services are about “outcomes”, not “things”

Too often, IT organizations will list things like PCs, application access, and password resets as its “services”. Do these things provide (some) value? Yes. But are they services? No.

A service is a means of delivering value for a customer (or business) by facilitating outcomes (or results) the customer wants to achieve[2].   I’m sure you’ve heard or read that definition many times before, but what does it mean? Think about it this way: A PC without application software, network connectivity, and the like does not facilitate an outcome. In fact, in such a scenario, a PC is nothing more than an expensive paperweight. But include the PC as part of a value chain (comprised of software, infrastructure, processes, and people) that results in increased company revenues or improved productivity or client satisfaction, and wham! – you’ve got yourself a service!

Many IT organizations struggle with the critical, fundamental concept of defining its services. The IT organization is unable to identify and map the combinations of people, process, technology, and suppliers – or value chains – that work together to deliver business value and outcomes. Because these value chains aren’t identified or defined, the IT organization struggles to articulate how it delivers value. As a result, IT is often left out of strategic business discussions.

Instead, many IT organizations list the things they do as its “services”. But when an IT organization lists “things” as services, it sends a distinct message to the business it serves. The message? “Welcome to IT – we are here to take your order”.

Is that how you want IT to be known within your company – just as “order takers”? If so, prepare to be outsourced – because by only listing “things” as “services”, you are describing IT as ‘cost’, and not as ‘value’. And your business will look to increase value by reducing cost – in this case, the cost of its internal IT – because it can get those “things” cheaper elsewhere.

Six PDG reasons to define services

Why define your IT services? Here are six PDG (pretty darn good) reasons:

  • Provide transparency into IT – Demystify what IT does, while at the same time, relate IT deliverables to business value and outcomes.
  • Identify what really needs to be managed – Too often, IT organizations attempt to control everything rather than manage the right things. By defining services, what really needs to managed in a CMDB and controlled through appropriate change management can be identified.
  • Enable management of IT as a portfolio, not as a “collection of things” – IT should be viewed as at a strategic investment, and therefore, should be managed as a portfolio. This means that investments in IT should be based on matching those investments to business objectives, developing policies that enable good decision-making, and balancing risk and reward. IT never has an opportunity to be managed as a portfolio if services are not defined.
  • Enable cost modeling – By identifying and understanding what makes up each service, needless redundancy and obsolescence can be identified. By eliminating this redundancy and obsolescence, IT reduces its cost – without impacting quality or results. Cost modeling also facilitates “like for like” comparisons of service solutions and “build vs. buy” decisions.
  • Enable the business to take advantage of IT services – Services provide value by facilitating outcomes. The more business can take advantage of the outcomes of IT services, the higher the value of IT. Defining services not only articulates the IT solutions available to meet business needs, it also aligns IT to business outcomes and helps lead IT in creating business value.
  • Get IT a seat at the table – Defining services helps both business and IT understand the role that IT plays in enabling and delivering business value chains – the activities within a company that result in a product or service that delivers value to a customer. Having the ability to discuss its services in terms of business value will help get IT a seat at the business strategy table.

Define your Services…or else!

So how can you define your services? Start by getting the answers to these questions:

  • What does your business do?
  • What are the activities within your business that result in a product or service that delivers value?
  • How does IT enable or support those business products or services?
  • What are the combinations of technology, process, people, and suppliers that enable or support those business products or services?

Getting the answers to these questions not only will help you define your services, it will also help you articulate how IT delivers real business value.

Want to get started, but don’t know where to start?  Perhaps a quick chat would help!  Click here to schedule a free, no obligation 30 minute session to talk about defining services at your organization.

Image Credit: Olivier Le Moal

[1] http://www.cio.com/article/3128724/leadership-management/business-value-is-key-to-it-success.html, retrieved 12/12/2016.

[2] ISO/IEC, (2011). ISO/IEC 20000-1:2011 Information technology – Service Management – Part 1: Service management system requirements. Geneva, Switzerland: ISO/IEC.

Share twitterlinkedinmail

What message is your Service Catalog sending to your business?

Share twitterlinkedinmail

ISO/IEC 20000:1, the Information Technology Service Management (ITSM) standard, defines a service as a “means of delivering value for the customer by facilitating results the customer wants to achieve.” ISO 20000 continues by stating that a service “is generally intangible”. [1]

In other words, services do not sit on shelves.

Yet many ITSM vendors would have you believe that their tool provides a “service catalog”, when what is really being provided is “request fulfillment”.

Don’t misunderstand – your IT organization can realize significant efficiencies from defining and publishing request models within a centralized portal. But recognize that what you’re doing is not a service catalog. Your portal is providing access to products or activities – service requests – managed via the request fulfillment process – that provide the means to consume a service. The product or activity itself is not a ‘service’.

Why understanding ‘service’ vs. ‘service request’ is so important

Services are the critical foundation for the relationship between IT and the business it serves. When services are described in terms of business value and results, IT is able to articulate how it provides benefit in terms that the business understands. Defined services are outcomes of business strategy – the plan for how the business intends to achieve goals and objectives – and how IT will support achieving those business goals and objectives. By defining services, IT illustrates its capability and readiness to be a strategic partner to the business.

Service requests, on the other hand, are simply a means of achieving those business objectives. Strictly speaking, it really doesn’t matter what brand or type of PC that is being used to access a service. It’s the use of the service – the realization of value and outcomes – enabled by using the PC that actually provides the business value.

Why is understanding the difference between ‘service’ and ‘service request’ so critical? One answer is the difference between an IT organization that is recognized as a ‘strategic business partner’ versus an IT organization that is perceived as an ‘order taker’.

A simple example

Think about the following products: a PC, a MacBook®, an iPad®[2], and a Microsoft Surface®[3] – perhaps all suitable entries in a company’s service request portal. Why would a consumer choose one of these products over another for use with his job? Perhaps it’s the form factor. Or maybe it’s personal preference. Perhaps it’s dictated by a company standard. Maybe it’s the color of the device.

Whatever the reason, can any of the devices listed above just be delivered to the consumer – out of the box – right from the shelf? Basically – no. Most companies require some sort of device protection to be installed – whether that’s simply a userid/password combination or some kind of security software. Then there’s configuring access to the corporate network, without which, none of the devices listed would be useful for the consumer for doing work for the company. Of course, the consumer will need to use corporate applications ranging from email to CRM systems.

Does the device itself deliver value by facilitating the results the consumer wants to achieve? Without the use of appropriate security measures, combined with access to the corporate network and email and CRM systems, the answer is “no”.  So, is the device itself a ‘service’? No.

If this sounds like what was implemented with your ITSM tool’s “service catalog”, do you really have a service catalog?

Move from ‘Order Taker’ to ‘Strategic Partner’

To be clear, I’m not suggesting that you “turn off” your service request portal. But what I am advocating is take what you’ve defined in your request portal and look at each item from the perspective of business value and business outcomes.  By doing this, you’ll be enabled to begin to move from the perception of ‘order taker’ to becoming the strategic IT partner for your business.

To start the move to ‘strategic partner’, answer the following questions for each entry in your request portal (I will use a service request for a PC as an example):

  • How is the requested product or activity being used? A PC is used for multiple purposes – access email, use personal productivity tools, access to corporate systems.
  • What are the technologies and activities involved with fulfilling the request? The PC requires software installation, configuration, physical installation, network connectivity, shared file system access, and other technologies and activities before it can be made usable.
  • Are there any dependencies or relationships between this request model and other request models? Perhaps the PC user also needs access to corporate systems, which may be handled by other service requests.
  • What is the ultimate outcome or result from the fulfillment of this request? Using the PC enables personal productivity for the consumer, which enables her to fulfill her job responsibilities.

As you get the answers to these questions, you will start to recognize similarities in outcomes or dependency patterns – indicators of the value chains that constitute services. Review these dependency patterns to identify the path that outcomes follow from the point(s) of origin to the point(s)  of business value realization  to complete the value chain. When you’ve done that, you have begun to identify services.

Workshops from Tedder Consulting can help you identify and define Services, develop your Service Catalog, and enable your Request Fulfillment process!  Want to know how? Contact Tedder Consulting today for a free 30-minute consultation!

For more pragmatic advice and service management insight, click here to subscribe to my newsletter!

Photo credit: conrado

[1] ISO/IEC, (2011). ISO/IEC 20000-1:2011 Information technology – Service Management – Part 1: Service management system requirements. Geneva, Switzerland: ISO/IEC.

[2] MacBook® and iPad® are registered trademarks of Apple, Inc.

[3] Microsoft Surface® is a registered trademark of Microsoft Corporation in the United States and/or other countries.

Share twitterlinkedinmail

‘Man in the Middle’ or ‘Solution Provider’?

Share twitterlinkedinmail

When I was a kid, I sometimes played a rousing game of “man in the middle”.  Are you familiar with that game?   One person stands between two other people, trying to catch a ball that is being tossed between the two outside people.  When the “man in the middle” runs toward one of the people on the end, that person tosses the ball over the “man in the middle” to the opposite person.  The “man in the middle” then runs over to the opposite person, who in turn, tosses the ball back.  Back and forth, back and forth the ball would go…the game would be over if the “man in the middle” ever caught the ball.  Or if was time for dinner.  Hey, kids have to eat.

If you stop and think about it, doesn’t the “man in the middle” game describe what happens with some IT organizations?  See if this sounds familiar:

Each year, IT puts together a budget for the next fiscal year.  The budget discusses staffing, new projects, maintenance costs, capital and operating expenditures, and the like.  After much gnashing of teeth and some back-and-forth, a budget is agreed between senior management and IT.  IT then runs into the next fiscal year and begins work according to its agreed budget.  At some point during the year, invariably, an end-user calls the Service Desk with a question regarding the new smartphone they bought, but are having trouble with…or that new tablet that can’t seem to access the corporate intranet.  “See new technology, love new technology, got to have new technology”—we all like the new technology….aren’t we all end-users in that regard?  But wait, IT doesn’t have the wherewithal to provide support for that new smartphone—it is not the corporate standard, and providing support for that particular smartphone wasn’t in the budget that was approved by senior management.  So maybe IT says “sorry, we don’t support that.”   So what if IT makes one end-user upset… it’s just one user.

But sometimes that shiny new smartphone belongs to one of those senior managers, who by the way,  approved that IT budget….then what does IT do?   IT might say, “We’re really not supposed to do this, but for you…” and proceed to help with the new smartphone….ignoring other (budget approved) work.  Or IT might say, “Yes, of course we can help with that”, again, ignoring other (budget approved) work.  Then before you know it, one call turns into ten calls, turns into a whole lot of work that was unplanned and unbudgeted, at the expense of projects and activities that were in the approved IT budget.   Next thing you know, it’s time to start budget planning for the next year, and there are some projects in this year’s budget that didn’t get done….and some embarrassing answers to some pointed questions.

IT just played the “man in the middle” game.  Senior managers approved a budget.  End-users wanted the new stuff that wasn’t in the approved budget.  IT got caught in the middle.

Perhaps the scenario above is a bit extreme, but I hope you can see my point.   IT often gets put in the middle between making end-users happy—even with things that IT could do but isn’t supposed to be doing – and the expectations of the senior management that funds IT.  The bottom line is that IT simply cannot afford to play “man in the middle”.   And while “man in the middle” may have been fun to play when we were kids, IT can never win at this game—even if we “catch the ball”.  Someone is not going to be happy.  And IT doesn’t help its reputation or establish itself as a solution partner to the business.

So what can IT do to stop playing the “man in the middle” and become “solution provider”?

  • Define Services and publish a Service Catalog

The Service Catalog represents the set of services that available for deployment and have been agreed with the customer – likely senior management.  Having a published service catalog sets expectations by describing what services and outcomes IT delivers and supports.

  • Produce and publish performance reports

How many calls to the Service Desk were for ‘unsupported’ technology?  How much work effort was involved with these calls?  Having this information and understanding the impact on the organization enables IT to have a fact-based conversation with senior management about the issue.

  • Become an expert on the business of the business

Understand what drives your company – beyond just revenue and profits.  Who are the company’s customers?  What are the business drivers for the company?  How does IT contribute to the success of the business?  Being an expert on the business of the business enables IT to talk – in business terms – about the business impact of non-supported technology.  Being an expert on the business of the business further enhances IT’s ability to articulate how an existing service may satisfy the end-user need for such technology.

  • Ask questions

Perhaps there is a good reason to expand services or support to include that new device.  Probe a bit deeper – ask questions and find out how providing this additional support benefits the business.  Perhaps this idea will enable new business opportunities, reduce costs, or have some other business benefit.   If there is a good, legitimate reason (other than “I want the new shiny toy”), then ask the requester to partner with you to develop and present a business case for the suggested solution to management for decision.

Playing “man in the middle” is a game that requires a lot of energy and drains resources and morale in IT organizations.   Changing the game from “man in the middle” to “solution partner” is a win for both IT and the business.

Click here to subscribe to my newsletter!

Share twitterlinkedinmail

Eating an Elephant: Service Catalog vs. Service Portfolio

Share twitterlinkedinmail

During my recent BrightTalk webinar, “Five PDG (Pretty Darn Good) Reasons to Define a Service Catalog”, I was asked for my thoughts regarding starting the Service Catalog when the Service Portfolio was not in-place or defined.

The Service Portfolio is made up of three components:

  • Service Pipeline – Services that are being discussed or designed, but are not yet available for deployment
  • Service Catalog – “Live” services or services that are available for deployment
  • Retired Services– Services that are or were in-use, but are now no longer available for deployment

As you can see, the Service Portfolio represents every Service within an organization.  It is a significant commitment by an organization, moving from a mentality of “my component” to “our services”.  Many organizations struggle even to define their “live” services, much less those services that are (should be) retired or in the pipeline.   “Services” are often confused with “products” or “activities”; both of which may be components of a services, but in and of themselves, are not “services”.

From my perspective, defining and maintaining a Service Portfolio is much like the proverbial “eating of the elephant”. You can’t eat an elephant in a single bite.  Likewise, you won’t be able to define a Service Portfolio in a single bite.   So which to do first–Service Catalog or Service Portfolio?  My advice–start with the Service Catalog.

Why?

First, this will force you to come to grips with the definition of “service” – the valuable outcome(s) that customers want without having to own the specific risks and costs of delivering and supporting that outcome.  So what is a “service”?  To use a simple analogy, consider an oil change.  The customer simply wants the oil changed in their car—they don’t want to worry about the disposal of the used oil, the maintaining of the inventory of oil and oil filters, being trained on how to change the oil, and all of the other things that are needed to deliver that outcome—having fresh oil and a new filter for their car. Defining what is and is not a service is the crucial first step.

Secondly, it allows you to focus on those things that should be known and familiar – the things the IT organization is doing today – as you start to win hearts and minds in the cultural shift to an outcome-based, value-added, service-oriented IT organization. It helps the organization recognize and understand how their specific contributions enable those outcomes to be realized by the customer.

Okay, so now “how”?

First, establish the “boundaries” for the Service Catalog. A service is either “in” or “out”.  As you identify services, determine whether those services are “in” – as in “in use”- or not.  If a service is “in”, it goes into your Service Catalog.  If a service is “out”, then this service should appear somewhere else in the Service Portfolio.

Then, for those services that are “out”, or somewhere within the other parts of the Service Portfolio, the choice is either “coming” or “going”. Simply put, if the service is “coming”—under development, being discussed – then that service definition should be included in the Service Pipeline.  If the service is “going”, then the service definition should appear in Retired Services.

Once you’ve completed this exercise, you’ve developed the basics of a Service Portfolio. Keep in mind that you won’t get this done in “two weeks”—it will take some time, thought, planning, and discussion.  To really exploit and embed the concept, you’ll need to decide things like how and when new projects are represented in the Service Pipeline.  Likewise, you’ll need to decide when and how Services move from the Catalog to Retired Services.  Use of the Portfolio for evaluating emerging business needs against existing solutions will need to be decided.  Service Owners must be named to maintain service descriptions, represent the service throughout the organization, and manage the lifecycle of the service.   A critical success factor in this work is to include the Customer as part of the definition and design of the Service Portfolio.    Who better than the Customer than to help us understand the outcome and value that a service should provide?  By including the Customer, acceptance of the portfolio approach and your chances for success improve dramatically.

One bite at a time…

Click here to subscribe to my newsletter!

Share twitterlinkedinmail

Five PDG (Pretty Darn Good) Reasons to Define a Service Catalog

Share twitterlinkedinmail

In my previous blog article, “Top 10 Things Companies Don’t Think About When They’re Thinking About a Service Catalog”, I said that the number one thing that businesses do not think about is the answer to “Why are we defining a Service Catalog?”

My answer was, “When you can answer this question, you’ve likely thought about the other 9 things I’ve listed above.”

Well, that got me to thinking.

And while I stand by my answers to numbers 2 through 10 of my “Top Ten List”, the more I thought about it, the more I didn’t like my answer to “why are we defining a Service Catalog?”

So, I’ve come up with what I think are five PDG (Pretty Darn Good) reasons to define a Service Catalog. See what you think.

  1. Improve IT strategy.

Moving beyond the mantra of “run IT as a business” begins by defining what the business of IT is – and a significant portion of that definition comes with the establishment of the service catalog.   This enables IT to begin to look at itself as a portfolio by identifying what is being done today, what are the emerging needs of the business and how well is IT positioned to meet those needs, what are the core competencies of the IT organization, where do partnering and other sourcing opportunities exist…sounds like what a business would do, right? Having a service catalog helps sharpen the business’ focus on the use of IT, where to invest resources, and how to make IT a differentiator among the competition—a real integration of IT within overall business plans and strategies.

2. Build and maintain good business relationships.

Defining a (true) Service Catalog drives IT to improve its understanding of the business by learning and articulating how IT enables and supports business outcomes. A good Service Catalog, devoid of “IT speak”, illustrates the critical role IT has in the success of the business and articulates how IT provides value.  The Service Catalog should be used to market IT’s current capabilities, help manage expectations and demand for IT services, and facilitate delivery of meaningful metrics and reporting from the business (not technical) perspective.

3.  Enable better decision-making.

What solutions are available from IT? What do the solutions provided by IT do for us?  Having a single definitive source for knowledge about IT services not only enables better decision-making for customers, it enables better decision-making in other areas.  For example, having a service catalog enables informed business decisions regarding a sourcing strategy for IT.  By understanding IT’s core competencies and the goals for the use of IT within the business, opportunities for partnering or outsourcing commodity services can be identified.  Understanding the lifecycle of a service improves planning.  Knowing when a service is expected to be retired or a new service will come online, as part of the overall IT strategy, helps customers make better plans about the use of IT services.

4. Develop better IT budgets.

One of the ways to identify and define services is to define the value chain – the relationship of the components that make up an IT service from end-to-end. What can you do with this?  Develop cost models.  Developing and using cost models will identify and articulate where redundancy exists, and cost-justify existing (and future) services.  Cost modeling enables value determination by allowing a like-for-like comparison of service costs and facilitates a fact-based conversation with the customer regarding IT investments.  Having a service catalog and understanding what makes up the costs of services also enhances IT’s ability to leverage economies of scale in negotiating contracts with suppliers.

5.  Do better ITSM.

Defining services aligns IT by establishing accountability, and moving the focus of the individuals in the organization from ‘my component’ to ‘our service’.  By defining services, an IT organization will enable further integration between ITSM processes.  For example, ‘service’ should become the basis for a categorization scheme shared between the Incident, Problem, and Knowledge Management processes.  By identifying and defining the value chain of components that make up an IT service, the basis for configuration models within the CMDB will be defined.  Having a good CMDB, in turn, enhances the ability to make educated evaluations of risk and impact within the Availability, Capacity, IT Service Continuity, Change, and Problem Management processes.  Defining the Service Catalog will help identify and justify what else you should be doing from an ITSM perspective, and how to incorporate those efforts into the exiting ITSM ecosystem.

Don’t miss my monthly take on all things ITSM!  Click here to subscribe to my newsletter!  Need help defining your Service Catalog?  Consider starting  with my Service Identification and Definition workshop. 

Share twitterlinkedinmail

Top 10 Things Companies Don’t Think About When They’re Thinking About a Service Catalog

Share twitterlinkedinmail

With a little bit of thought and planning, the Service Catalog can become one of the most valuable artifacts of an ITSM implementation….but it requires some thought and planning before starting!   Here is my “Top 10” list of things that I’ve encountered that most organizations don’t think about when they’re starting to think about developing a Service Catalog.

10.  A Service Catalog takes longer than two weeks to define

A lot of IT organizations try to define their Service Catalog by either a) listing all of their applications and calling them “services” or b) list every activity they do and calling those activities “services”.  Neither approach is correct.  Take some time to identify services by mapping how people, processes, suppliers and technology work together to deliver or enable the outcomes that the business requires.  The result will be a Service Catalog that makes sense to the business.

  1. Service Requests” and “Services” are not the same thing

ITIL® defines a service as a means of providing value by delivering outcomes that customers want without having the ownership of costs and risks.  Note a keyword here- “outcome”.  A “service” is outcome-based; that is, it enables or supports a business result.  A “service request” is performed by consumers for things that IT gives or has.  A “service request” is often fulfilled by delivering some product that sits on a shelf.

I bring this up because many ITSM tool vendors will trumpet that they deliver a “Service Catalog” with their product, when in fact, what they are delivering a “service request catalog”.  Having a service request catalog is not a bad thing, but understand what it is.  A service request catalog is used by consumers (users) to obtain the products that are provided or enabled by a service.  Services are not products that sit on some shelf somewhere.  To say it differently, a smart phone (the product or object of a service request) isn’t so “smart” without the technology, processes, tools, and people (the services!) of the cellular network provider.

  1. Just because your name appears on the IT organization chart doesn’t mean you provide a “service”

I’m not saying that what you do isn’t important – it is!  Frankly, if what you do wasn’t important, or you weren’t making a valuable contribution, your name *wouldn’t* appear on the organization chart.  However, a service isn’t about just one person’s job function or contribution, but how everyone contributes to the delivery and support of a service.  Remember, a service represents the end-to-end picture of how people, process, and technology work together to deliver an outcome the business requires.

  1. A Service Catalog will make you do other ITSM stuff…if you want to do the Service Catalog well

A Service Catalog, developed without having other processes like Change Management, Incident Management, SACM, and others in place, will become obsolete 5 minutes after the “ink dries”.  Defining services and developing a Service Catalog demonstrates an organization’s commitment to ‘service’.  Defining and using processes like Change Management, Incident Management, SACM, and others makes ‘services’ reality, by focusing IT efforts on service defined in the Service Catalog.

  1. Service Catalog should be (is) more than just a “catalog”

The Service Catalog can and should be used for more than just the authoritative source of information regarding live services.  The Service Catalog is a great tool to market the capabilities and solutions provided by the IT organization.  Use the service descriptions in the Service Catalog to document corporate-wide base service level objectives rather than repeat those objectives within each Service Level Agreement.  Having a new IT employee review the Service Catalog is a great way to bring them up to speed on not only what IT does, but how what IT does is used within the business.   These are just a few uses for the Service Catalog!

  1. A Service Catalog does not need to be “perfect” – it just needs “to be”

A Service Catalog demonstrates the capacity and ability of the IT organization to deliver outcomes needed by the business. Defining services helps the IT organization articulate its value to the business.  By defining services and developing a Service Catalog, IT can tell its story—without a Service Catalog, everyone else within the business tells IT’s story.   So when someone in your company says “I don’t understand the value, much less what I’m getting from IT”, point them to the Service Catalog – and tell the story.

Also keep in mind that your first Service Catalog will not be your last Service Catalog.  One of the goals of the first catalog is to establish ‘services’ and the baseline for continual improvement.  Perfection is an aspirational goal; learn from that first Service Catalog (and subsequent catalogs!) and make progress.

  1. The Service Catalog usually does not have an ROI in year 1

In my experience, a Service Catalog done right is a lot of work up front and rarely has any kind of return on investment with ‘version 1’.  But in year 2 and beyond, the Service Catalog will help identify existing needless redundancy and help the organization make decisions that avoid future redundancy.   The Service Catalog helps facilitate the development of cost models to further define the costs associated with delivering services.  If your business requires it, the Service Catalog will help with the development of differentiated service levels (think “gold”, “silver”, and “bronze” service levels).  It can help Supplier Management leverage economies of scale to drive volume discounts with supplier contracts.  It can start to further drive standardization across the company.

Think of the Service Catalog as a long-term investment.

  1. ‘Service’ implies ‘Choice’

You fuel up your car at one gas station over another.  You decide to have lunch at the new place down the street.   You make service choices every day.  The same thing applies when you develop your Service Catalog.   If you list a service, you’re implying that there is a choice.  In other words, is the Service Desk a ‘service’?  Can consumers within the business really get a PC without software, network connectivity, anti-virus software, etc.?  Be careful not to introduce a ‘choice’ you aren’t intending as you describe services, when in actuality, there is no choice that can be made.

  1. Who is the ‘customer’?

If you’re struggling with the ‘service’ vs. ‘service request’ concept, answering this question will help.  As you do ‘more ITSM’ (see #7), one of the processes you may consider is Service Level Management.  One of the artifacts produced and maintained by the Service Level Management process is a Service Level Agreement, or SLA.  SLAs are signed with CUSTOMERS, not CONSUMERS.   You are not going to negotiate SLAs with consumers; you will negotiate SLAs with customers.  Why?  It’s the customer who has defined the business requirements and is paying for the service; not the consumer.  The Service Catalog represents those services that the customer has agreed to pay for.

  1. Why are we defining a Service Catalog?

When you can answer this question, you’ve likely thought about the other 9 things I’ve listed above.

Click here to subscribe to my newsletter!

ITIL® is a trademark of AXELOS Limited, London.

 

Share twitterlinkedinmail

Fire-Aim-Ready!

Share twitterlinkedinmail

We IT people are an interesting bunch.  On one hand, we often preach about how we want to be seen as a reliable and consistent service provider, so business can trust us to deliver predictable, repeatable results.  We talk about wanting to be the ‘trusted advisor’ to the business in the use of technology to drive opportunities for improvement and open up new market spaces.  We promote how IT wants to be seen as providing value, while at the same time, being cost-effective.

Did you notice something there?  We “want to be”.  We want to be, but what we often do can often be interpreted as “fire-aim-ready”.

IT always wants to deliver solutions quickly, but often doesn’t take the time to internalize the company’s mission, vision, and goals.  As a result, often the solutions that are delivered are overly expensive and don’t meet long term business needs.

IT wants to be seen as a trusted advisor, but produces reports that are in “IT terms” (does anyone outside of IT really care about CPU utilization?) and doesn’t provide any transparency into IT.

IT doesn’t want to be seen as an “order taker”, but doesn’t take the time to produce a true Service Catalog that discusses the value of IT Services and the business outcomes that are enabled through those services.  Instead, IT produces a list of applications, products, and systems (again often in “IT terms”) that resembles the menu board at a restaurant drive-through window….”May I take your order please?”

IT doesn’t take advantage of the opportunity to teach the business about what IT does and explain why a PC provided and supported by IT costs $3000 instead of $499.  Because these conversations are sometimes difficult, IT will put itself into positions where it is making business decisions on behalf of the business, and avoid having business representation in CAB meetings or working with the business to develop IT Service Strategy.

How can IT shift to a “ready-aim-fire” perspective?   I would suggest a great place to start is with the Service Catalog.  In my experience, business is willing to pay for quality IT services, but not willing to pay for IT just for IT’s sake.  The business would like to trust and count on IT, but needs IT to speak in business terms, then translate into IT-speak internally.  IT wants to better articulate the business value it provides, but may not know how to start that conversation with those it serves.  Working with the business to build a Service Catalog is a great way to address these issues and more.  In time and done well, the Service Catalog can help establish IT as the trusted advisor and reliable partner it wants to be, and lose that perception of being an “order taker”.

My next few blogs will explore some of my thinking about the Service Catalog.  If you have some thoughts to share, drop me a note!  I look forward to the conversation!

Click here to subscribe to my newsletter!

Share twitterlinkedinmail