Cloud and Service Catalog Blog

The Product Manager role

This is a repost of a popular post from four years ago. More applicable to cloud than ever.

For the IT organization to start behaving as a Managed Service Provider, it will have to create and nurture the role of "Product Manager".  The product manager assembles and defines the services which will be offered to the business and its consumers through the Relationship Manager.
They are the central coordination point between all the stakeholders, including the customer.

Service cut across silos, they cross different functions -- it is the product manager's role to assemble them into unities that make sense to IT's customer.    The product manager both leads and collaborates in defining, supervising and enhancing services to achieve the needed levels of customer satisfaction, regulatory compliance, and operational effectiveness.  Outsourcers and most high-tech companies have this role already. 

This role is responsible with coordinating defining both the specific services to be provided as well as the roadmap of future IT services. This is done in conjunction with both the relationship managers, IT executive management and owners of specific service domain. To do this the product managers must own the definition the SLA’s, measures, bundles, resources, pricing, cost allocation. 

They are the ones who design the options between quality and cost which the customer can then select. Because of this, they are responsible for the strategic roadmap for improving service quality and cost -- they do this in conjunction with the IT planning function.

PM’s are responsible for the competitiveness of their offer in their marketplace. That means benchmarking their offers against external providers, leaders in their industry, the important metrics.

There’s a lot more than that… but don’t despair, here are a few resources to help you construct a definition for you.

Gartner wrote a report  on "Evolving Roles in the IT Organization: The IT Product Manager (Article G00131012)"  for those of you that have access to client access Gartner.

While IT Product management is a new role, product management is a well-established discipline.  You may want to talk to product managers in your organization to get an overview of the job.  There are also resources like this one and this one (PDF).  They are more traditional ones but the fundamentals are similar. There are even organizations that train on traditional product management.

They have this neat image that gives you some sense of the different activities a Product Manager undertakes:

More at: http://www.productmarketing.com/productmarketing/magazine/1/2/07sj.asp

Managing Service Providers through a Service Catalog

This is a bit of a long post, but one that I've been working on for quite a while.

IT outsourcing continues to grow. And so do the problems. Leading IT organizations now look for better ways to manage the relationship with their managed service provider (MSP's).

Managing outsourcing is a growing challenge

There's no question there's a growing problem. Many outsourcing initiatives fail. According to a Dun and Bradstreet survey in 2000, 25% fail in the first two years and 50% fail within five years. And the causes? According to a Cutter Consortium survey it's because in 43% of cases internal personnel are unprepared to manage the complexity of relationships, and in 73% of cases they say that managing multiple vendor relationships is difficult. (See Six common outsourcing errors for more)

And this is what people say is difficult.

Too Much Focus on the Financial Aspects of the Relationship at the Expense of the Operational Aspects

Having worked with several customers and also with MSP's, I have observed many of these challenges from the front line. Including massive temper tantrums.  More on that later.

Most of these problems could be helped or resolved by the use of a service catalog on both sides of the relationship. Here's what's difficult:

• Managing work and automating processes is complex or impossible
• Policy, entitlements, governance and auditability are non-existent
• Tracking SLA terms and conditions is difficult
• Disputes are hard to resolve
• Internal shepherds manage assignment, follow up & tracking between the outsourcer and internal customer
• Large, hidden costs not accounted for in contract
• Breakdowns and slowdowns occur
• Prevents the automation of internal processes
• A myriad of disparate and incompatible systems impede visibility, management and automation of the outsourcing relationship.

And day to day life in these relationships is tough. Start with untraceable e-mails, phone calls, faxes, paper, and procurement records. Then add a multitude of incompatible help desks, multiple intranets and portals. Followed by uncollectable metrics and meaningless reports. No one knows which way is up.

Set Up to Fail

In many cases, the day-to-day operations people at the  MSP don't know what's in the contract. So they ask their clients, but the client doesn't know either because the contract was negotiated purely from a financial perspective and it's not "actionable" or operational perspective. Service request get stuck in endless approval cycles because it's not clear if it's in the contract. Every improvements cost money because the CFO beat the MSP on price, so now there's no money for innovation. This forces the MSP to charge more for any changes to recoup their losses.  Every change requires $$, budget changes. The CFO then says "Our savings are not what we expected". In disputes, the vendor can goes straight to the CEO or board.

It all ends in the dreaded weekly "Invoice and SLA Meeting" where both sides try to figure out what is chargeable, what is in contract, were SLA's met and should there be a penalty or bonus? This is not a pretty meeting. Soon everybody just walks away in disgust.

How bad can it get? The only time I have seen a chair thrown, a table overturned, a colorful and large variety of expletives used, and people come close to punching each other was at a meeting between an end user organization and their MSP to review complaints and SLA's.

Most if not all of these problems are helped by implementing a service catalog. It helped the chair-throwing customer rebuild trust with their MSP.

So why is the need for a service catalog ignored in less mature IT shops? Because there's a vain hope that out of sight means out of mind. Read on.

My Mess for Less.

Both sides are often unprepared for the relationship. The MSP often does not have a catalog that maps to what is agreed on the contract. At best they bring a quasi-purchasing system that can't be deployed to the end user community, only work for some services and are complex to set up.

On the customer side, there's often a sense of: I outsourced, it's their problem. This "all-or-nothing" perspective is unrealistic. There are many aspects of IT that simply CANNOT be outsourced. IT has a fiduciary duty to explain why money was spent and what controls are in place; you can't outsource that. And there several other aspects of service outsourcing that cannot be outsourced. Here's my list. I'm sure it's incomplete.

1. Benchmarking and SLA management. Is this a fair market price? Are they meeting their commitments?
2. Supplier selection. Who do we buy from and why?
3. Supplier process coordination / collaboration. It's a multi –vendor world.
4. Authorizations and entitlement management. These controls need to be owned by the customer.
5. Change orders, contract changes, bidding (RFP), pricing (RFI). All of this belongs in the catalog.
6. Managing relationships with internal customers. In the end, you own the relationship and understand the business.
7. Integration with internal processes such as HR. Like new hires, terminations.
8. Financial controls, auditability, governance, contract management. Explain to your stakeholders where the money went.

New Roles, New Processes, New Tools

The picture below shows that there's a whole set of roles and "supplier management" processes and roles that come into play.  Most of these map to ITIL V3.

And all these roles and people have to execute a whole new set of processes in a different manner than they were used to (if at all). These include:

• Service request process
• Change and scope management
• Contract management, RFP, RFI
• Relationship management
• Authorization and entitlement management
• Audit and Governance
• Process integration
• Issue and escalation management
• Invoice and payment verification
• Benchmarking
• And more

If you look at this picture, it's the same picture that's evolving in ITIL v3 and it is centered on the service catalog. So we need new roles, new processes, and new tools.

Service Catalog for Supplier Management

The service catalog is a strategic tool to achieve effective management of the outsource relationship for both customer and MSP. In fact, ITIL V3 introduces a formal supplier management process. And there's picture that goes like this.

This graphic shows that there are many services that are not outsourced; that we are living in a multi-vendor world. Our catalog should include our supplier's catalog because this allows IT to effect governance, controls and effective reporting. Also makes it easier for users to go to that single point of contact for everything IT does. And it has strategic value: it allows you to change MSP's for certain services as needed.

Note: This need to bring coordination between the IT service catalog and the MSP service catalog is why newScale launched the SPACL standard with other industry leaders. SPACL will enable IT to quickly import a MSP's service catalog to enable intercompany service delivery management. Ask your MSP if they are supporting it.

At one of our earliest customers, the users go to the service catalog and request "Wireless Access. If the employee is local, IT provides the service; if the employee is regional, the MSP provides the service. This is transparent to the user. The request flows electronically to the service provider, who then invoices matching the specific transaction ID. This makes invoices, SLA's, and tracking very clear and non-disputable.

In another case, a large retail chain has a multitude of service providers for their facilities (think broken window – a mission critical breakdown in the retail world). So the catalog serves to determine who does the work and the price.

Should I Use my Manage Service Providers Service Catalog or My Own?

You must control your own. Even if provided by your MSP. This graphic from the Forbes article says it all: Sourcing is a multi-vendor strategy.

If you can, spread your risk between service providers and countries. You wouldn't want to get caught flatfooted if your only claims processing center in China gets destroyed in an earthquake. For maximum efficiency, try to have software developers sprinkled around the world so someone is always working on your next project. Just remember the more people you have involved in a project, the more oversight that's required (see slide #1).

Some service providers push their own service catalog software; either homegrown or licensed from someone (including newScale). (In fact, we have some cases where both the customer and the MSP use newScale software on each side to manage the relationship.)

Here are some questions you ought to think about if your MSP is offering their catalog:

1. Are you allowed to manage other service providers?
2. Can IT use the catalog software to build services not outsourced to the vendor?
3. Are you able to build and maintain business services without having to constantly go to the service provider for help
4. When the contract ends or changes, can the service catalog be owned by you
5. Is the service request catalog integrated to the business service portfolio?
6. Is the service catalog separate from the help desk function provided by the MSP?
7. Will retained IT be able to use the catalog software to manage metrics, authorizations, and other vendor governance functions?
8. Is the data secure when I use it for access requests?

If the answer is no, then you need to have your own catalog. If your MSP provides newScale software, you should be in decent shape, as our tools allow for federated control. This means that IT can add their own services for their own needs without affecting the MSP catalog.

Conclusion

The coming wave of technology in the form of virtualization, cloud computing, mobile computing, green computing, software as a service and open source all point to one unequivocal trend: there will be more services, more complexity, and even more value from using technology intelligently.

No single vendor or service provider will be able to deliver what you need. You will have multiple service providers.

A service catalog is core to implementing a successful MSP relationship. It's the cornerstone to IT's relationship with its customers. Therefore you must have it and control it. That can't be outsourced.

Managing Service Providers through a Service Catalog

This is a bit of a long post, but one that I've been working on for quite a while.

IT outsourcing continues to grow. And so do the problems. Leading IT organizations now look for better ways to manage the relationship with their managed service provider (MSP's).

Managing outsourcing is a growing challenge

There's no question there's a growing problem. Many outsourcing initiatives fail. According to a Dun and Bradstreet survey in 2000, 25% fail in the first two years and 50% fail within five years. And the causes? According to a Cutter Consortium survey it's because in 43% of cases internal personnel are unprepared to manage the complexity of relationships, and in 73% of cases they say that managing multiple vendor relationships is difficult. (See Six common outsourcing errors for more)

And this is what people say is difficult.

Too Much Focus on the Financial Aspects of the Relationship at the Expense of the Operational Aspects

Having worked with several customers and also with MSP's, I have observed many of these challenges from the front line. Including massive temper tantrums.  More on that later.

Most of these problems could be helped or resolved by the use of a service catalog on both sides of the relationship. Here's what's difficult:

• Managing work and automating processes is complex or impossible
• Policy, entitlements, governance and auditability are non-existent
• Tracking SLA terms and conditions is difficult
• Disputes are hard to resolve
• Internal shepherds manage assignment, follow up & tracking between the outsourcer and internal customer
• Large, hidden costs not accounted for in contract
• Breakdowns and slowdowns occur
• Prevents the automation of internal processes
• A myriad of disparate and incompatible systems impede visibility, management and automation of the outsourcing relationship.

And day to day life in these relationships is tough. Start with untraceable e-mails, phone calls, faxes, paper, and procurement records. Then add a multitude of incompatible help desks, multiple intranets and portals. Followed by uncollectable metrics and meaningless reports. No one knows which way is up.

Set Up to Fail

In many cases, the day-to-day operations people at the  MSP don't know what's in the contract. So they ask their clients, but the client doesn't know either because the contract was negotiated purely from a financial perspective and it's not "actionable" or operational perspective. Service request get stuck in endless approval cycles because it's not clear if it's in the contract. Every improvements cost money because the CFO beat the MSP on price, so now there's no money for innovation. This forces the MSP to charge more for any changes to recoup their losses.  Every change requires $$, budget changes. The CFO then says "Our savings are not what we expected". In disputes, the vendor can goes straight to the CEO or board.

It all ends in the dreaded weekly "Invoice and SLA Meeting" where both sides try to figure out what is chargeable, what is in contract, were SLA's met and should there be a penalty or bonus? This is not a pretty meeting. Soon everybody just walks away in disgust.

How bad can it get? The only time I have seen a chair thrown, a table overturned, a colorful and large variety of expletives used, and people come close to punching each other was at a meeting between an end user organization and their MSP to review complaints and SLA's.

Most if not all of these problems are helped by implementing a service catalog. It helped the chair-throwing customer rebuild trust with their MSP.

So why is the need for a service catalog ignored in less mature IT shops? Because there's a vain hope that out of sight means out of mind. Read on.

My Mess for Less.

Both sides are often unprepared for the relationship. The MSP often does not have a catalog that maps to what is agreed on the contract. At best they bring a quasi-purchasing system that can't be deployed to the end user community, only work for some services and are complex to set up.

On the customer side, there's often a sense of: I outsourced, it's their problem. This "all-or-nothing" perspective is unrealistic. There are many aspects of IT that simply CANNOT be outsourced. IT has a fiduciary duty to explain why money was spent and what controls are in place; you can't outsource that. And there several other aspects of service outsourcing that cannot be outsourced. Here's my list. I'm sure it's incomplete.

1. Benchmarking and SLA management. Is this a fair market price? Are they meeting their commitments?
2. Supplier selection. Who do we buy from and why?
3. Supplier process coordination / collaboration. It's a multi –vendor world.
4. Authorizations and entitlement management. These controls need to be owned by the customer.
5. Change orders, contract changes, bidding (RFP), pricing (RFI). All of this belongs in the catalog.
6. Managing relationships with internal customers. In the end, you own the relationship and understand the business.
7. Integration with internal processes such as HR. Like new hires, terminations.
8. Financial controls, auditability, governance, contract management. Explain to your stakeholders where the money went.

New Roles, New Processes, New Tools

The picture below shows that there's a whole set of roles and "supplier management" processes and roles that come into play.  Most of these map to ITIL V3.

And all these roles and people have to execute a whole new set of processes in a different manner than they were used to (if at all). These include:

• Service request process
• Change and scope management
• Contract management, RFP, RFI
• Relationship management
• Authorization and entitlement management
• Audit and Governance
• Process integration
• Issue and escalation management
• Invoice and payment verification
• Benchmarking
• And more

If you look at this picture, it's the same picture that's evolving in ITIL v3 and it is centered on the service catalog. So we need new roles, new processes, and new tools.

Service Catalog for Supplier Management

The service catalog is a strategic tool to achieve effective management of the outsource relationship for both customer and MSP. In fact, ITIL V3 introduces a formal supplier management process. And there's picture that goes like this.

This graphic shows that there are many services that are not outsourced; that we are living in a multi-vendor world. Our catalog should include our supplier's catalog because this allows IT to effect governance, controls and effective reporting. Also makes it easier for users to go to that single point of contact for everything IT does. And it has strategic value: it allows you to change MSP's for certain services as needed.

Note: This need to bring coordination between the IT service catalog and the MSP service catalog is why newScale launched the SPACL standard with other industry leaders. SPACL will enable IT to quickly import a MSP's service catalog to enable intercompany service delivery management. Ask your MSP if they are supporting it.

At one of our earliest customers, the users go to the service catalog and request "Wireless Access. If the employee is local, IT provides the service; if the employee is regional, the MSP provides the service. This is transparent to the user. The request flows electronically to the service provider, who then invoices matching the specific transaction ID. This makes invoices, SLA's, and tracking very clear and non-disputable.

In another case, a large retail chain has a multitude of service providers for their facilities (think broken window – a mission critical breakdown in the retail world). So the catalog serves to determine who does the work and the price.

Should I Use my Manage Service Providers Service Catalog or My Own?

You must control your own. Even if provided by your MSP. This graphic from the Forbes article says it all: Sourcing is a multi-vendor strategy.

If you can, spread your risk between service providers and countries. You wouldn't want to get caught flatfooted if your only claims processing center in China gets destroyed in an earthquake. For maximum efficiency, try to have software developers sprinkled around the world so someone is always working on your next project. Just remember the more people you have involved in a project, the more oversight that's required (see slide #1).

Some service providers push their own service catalog software; either homegrown or licensed from someone (including newScale). (In fact, we have some cases where both the customer and the MSP use newScale software on each side to manage the relationship.)

Here are some questions you ought to think about if your MSP is offering their catalog:

1. Are you allowed to manage other service providers?
2. Can IT use the catalog software to build services not outsourced to the vendor?
3. Are you able to build and maintain business services without having to constantly go to the service provider for help
4. When the contract ends or changes, can the service catalog be owned by you
5. Is the service request catalog integrated to the business service portfolio?
6. Is the service catalog separate from the help desk function provided by the MSP?
7. Will retained IT be able to use the catalog software to manage metrics, authorizations, and other vendor governance functions?
8. Is the data secure when I use it for access requests?

If the answer is no, then you need to have your own catalog. If your MSP provides newScale software, you should be in decent shape, as our tools allow for federated control. This means that IT can add their own services for their own needs without affecting the MSP catalog.

Conclusion

The coming wave of technology in the form of virtualization, cloud computing, mobile computing, green computing, software as a service and open source all point to one unequivocal trend: there will be more services, more complexity, and even more value from using technology intelligently.

No single vendor or service provider will be able to deliver what you need. You will have multiple service providers.

A service catalog is core to implementing a successful MSP relationship. It's the cornerstone to IT's relationship with its customers. Therefore you must have it and control it. That can't be outsourced.

Managing Service Providers through a Service Catalog

This is a bit of a long post, but one that I've been working on for quite a while.

IT outsourcing continues to grow. And so do the problems. Leading IT organizations now look for better ways to manage the relationship with their managed service provider (MSP's).

Managing outsourcing is a growing challenge

There's no question there's a growing problem. Many outsourcing initiatives fail. According to a Dun and Bradstreet survey in 2000, 25% fail in the first two years and 50% fail within five years. And the causes? According to a Cutter Consortium survey it's because in 43% of cases internal personnel are unprepared to manage the complexity of relationships, and in 73% of cases they say that managing multiple vendor relationships is difficult. (See Six common outsourcing errors for more)

And this is what people say is difficult.

Too Much Focus on the Financial Aspects of the Relationship at the Expense of the Operational Aspects

Having worked with several customers and also with MSP's, I have observed many of these challenges from the front line. Including massive temper tantrums.  More on that later.

Most of these problems could be helped or resolved by the use of a service catalog on both sides of the relationship. Here's what's difficult:

• Managing work and automating processes is complex or impossible
• Policy, entitlements, governance and auditability are non-existent
• Tracking SLA terms and conditions is difficult
• Disputes are hard to resolve
• Internal shepherds manage assignment, follow up & tracking between the outsourcer and internal customer
• Large, hidden costs not accounted for in contract
• Breakdowns and slowdowns occur
• Prevents the automation of internal processes
• A myriad of disparate and incompatible systems impede visibility, management and automation of the outsourcing relationship.

And day to day life in these relationships is tough. Start with untraceable e-mails, phone calls, faxes, paper, and procurement records. Then add a multitude of incompatible help desks, multiple intranets and portals. Followed by uncollectable metrics and meaningless reports. No one knows which way is up.

Set Up to Fail

In many cases, the day-to-day operations people at the  MSP don't know what's in the contract. So they ask their clients, but the client doesn't know either because the contract was negotiated purely from a financial perspective and it's not "actionable" or operational perspective. Service request get stuck in endless approval cycles because it's not clear if it's in the contract. Every improvements cost money because the CFO beat the MSP on price, so now there's no money for innovation. This forces the MSP to charge more for any changes to recoup their losses.  Every change requires $$, budget changes. The CFO then says "Our savings are not what we expected". In disputes, the vendor can goes straight to the CEO or board.

It all ends in the dreaded weekly "Invoice and SLA Meeting" where both sides try to figure out what is chargeable, what is in contract, were SLA's met and should there be a penalty or bonus? This is not a pretty meeting. Soon everybody just walks away in disgust.

How bad can it get? The only time I have seen a chair thrown, a table overturned, a colorful and large variety of expletives used, and people come close to punching each other was at a meeting between an end user organization and their MSP to review complaints and SLA's.

Most if not all of these problems are helped by implementing a service catalog. It helped the chair-throwing customer rebuild trust with their MSP.

So why is the need for a service catalog ignored in less mature IT shops? Because there's a vain hope that out of sight means out of mind. Read on.

My Mess for Less.

Both sides are often unprepared for the relationship. The MSP often does not have a catalog that maps to what is agreed on the contract. At best they bring a quasi-purchasing system that can't be deployed to the end user community, only work for some services and are complex to set up.

On the customer side, there's often a sense of: I outsourced, it's their problem. This "all-or-nothing" perspective is unrealistic. There are many aspects of IT that simply CANNOT be outsourced. IT has a fiduciary duty to explain why money was spent and what controls are in place; you can't outsource that. And there several other aspects of service outsourcing that cannot be outsourced. Here's my list. I'm sure it's incomplete.

1. Benchmarking and SLA management. Is this a fair market price? Are they meeting their commitments?
2. Supplier selection. Who do we buy from and why?
3. Supplier process coordination / collaboration. It's a multi –vendor world.
4. Authorizations and entitlement management. These controls need to be owned by the customer.
5. Change orders, contract changes, bidding (RFP), pricing (RFI). All of this belongs in the catalog.
6. Managing relationships with internal customers. In the end, you own the relationship and understand the business.
7. Integration with internal processes such as HR. Like new hires, terminations.
8. Financial controls, auditability, governance, contract management. Explain to your stakeholders where the money went.

New Roles, New Processes, New Tools

The picture below shows that there's a whole set of roles and "supplier management" processes and roles that come into play.  Most of these map to ITIL V3.

And all these roles and people have to execute a whole new set of processes in a different manner than they were used to (if at all). These include:

• Service request process
• Change and scope management
• Contract management, RFP, RFI
• Relationship management
• Authorization and entitlement management
• Audit and Governance
• Process integration
• Issue and escalation management
• Invoice and payment verification
• Benchmarking
• And more

If you look at this picture, it's the same picture that's evolving in ITIL v3 and it is centered on the service catalog. So we need new roles, new processes, and new tools.

Service Catalog for Supplier Management

The service catalog is a strategic tool to achieve effective management of the outsource relationship for both customer and MSP. In fact, ITIL V3 introduces a formal supplier management process. And there's picture that goes like this.

This graphic shows that there are many services that are not outsourced; that we are living in a multi-vendor world. Our catalog should include our supplier's catalog because this allows IT to effect governance, controls and effective reporting. Also makes it easier for users to go to that single point of contact for everything IT does. And it has strategic value: it allows you to change MSP's for certain services as needed.

Note: This need to bring coordination between the IT service catalog and the MSP service catalog is why newScale launched the SPACL standard with other industry leaders. SPACL will enable IT to quickly import a MSP's service catalog to enable intercompany service delivery management. Ask your MSP if they are supporting it.

At one of our earliest customers, the users go to the service catalog and request "Wireless Access. If the employee is local, IT provides the service; if the employee is regional, the MSP provides the service. This is transparent to the user. The request flows electronically to the service provider, who then invoices matching the specific transaction ID. This makes invoices, SLA's, and tracking very clear and non-disputable.

In another case, a large retail chain has a multitude of service providers for their facilities (think broken window – a mission critical breakdown in the retail world). So the catalog serves to determine who does the work and the price.

Should I Use my Manage Service Providers Service Catalog or My Own?

You must control your own. Even if provided by your MSP. This graphic from the Forbes article says it all: Sourcing is a multi-vendor strategy.

If you can, spread your risk between service providers and countries. You wouldn't want to get caught flatfooted if your only claims processing center in China gets destroyed in an earthquake. For maximum efficiency, try to have software developers sprinkled around the world so someone is always working on your next project. Just remember the more people you have involved in a project, the more oversight that's required (see slide #1).

Some service providers push their own service catalog software; either homegrown or licensed from someone (including newScale). (In fact, we have some cases where both the customer and the MSP use newScale software on each side to manage the relationship.)

Here are some questions you ought to think about if your MSP is offering their catalog:

1. Are you allowed to manage other service providers?
2. Can IT use the catalog software to build services not outsourced to the vendor?
3. Are you able to build and maintain business services without having to constantly go to the service provider for help
4. When the contract ends or changes, can the service catalog be owned by you
5. Is the service request catalog integrated to the business service portfolio?
6. Is the service catalog separate from the help desk function provided by the MSP?
7. Will retained IT be able to use the catalog software to manage metrics, authorizations, and other vendor governance functions?
8. Is the data secure when I use it for access requests?

If the answer is no, then you need to have your own catalog. If your MSP provides newScale software, you should be in decent shape, as our tools allow for federated control. This means that IT can add their own services for their own needs without affecting the MSP catalog.

Conclusion

The coming wave of technology in the form of virtualization, cloud computing, mobile computing, green computing, software as a service and open source all point to one unequivocal trend: there will be more services, more complexity, and even more value from using technology intelligently.

No single vendor or service provider will be able to deliver what you need. You will have multiple service providers.

A service catalog is core to implementing a successful MSP relationship. It's the cornerstone to IT's relationship with its customers. Therefore you must have it and control it. That can't be outsourced.

Do All Roads Lead to CMDB?

Strategic Planning Assumption: In three years, 75 percent of all CMDB implementations will fail
to achieve a comprehensive services view of all consolidated IT domains (0.8 probability).
       Do All Roads Lead to CMDB?
       Ronni Colville
       Gartner 25th Annual Data Center Conference, Las Vegas, NV 2006

Interesting presentation and article. Here are just a few quotes as to why this will be the case.

1 Proprietary API's will prevent all the tools from working together well. Quote: "No vendor has
proven their CMDB technology capable of federating the multitude of configuration data sources that any given enterprise might have." Which I believe is true. There are really important specialized data silos such as procurement, the service catalog, source configuration management that need to remain independent.  Because...

2 The CMDB can't scale to meet the real time data requirements of many applications and will have at best 25% to 3% of the data.  This means that islands of configuration data will need to exist.
Quote "Gartner believes the value of the CMDB is to maintain a services view; therefore only the data necessary to understand the relationships between and amongst the component that represents the service should be "in" the CMDB."  Which makes eminent sense. In fact, Gartner believes the CMDB will be much more valuable as an analytical tool, like a datamart or datawarehouse, than a real time repository of all data in IT.

3 Performance is a real issue if we tie events, incidents, problems.  Quote: "Storing all data in a CMDB would be extremely difficult and complex to maintain and would likely never
represent a "real time" view. More importantly, no data store would be able to scale to maintain that level of depth."   Or transaction support, or specific data models.   Tidbit: most implementations of CMDB's are in data centers, not the service desk. 

This is why I believe that the service catalog needs to addressed up front.  By focusing on what customers need and want, building your catalog first ensures that you focus on the services that have most impact and the attributes of the service with the most value to your customers. It also buys you political goodwill to engage on your multi-year CMDB project while reducing the potential work.

To read the whole presentation, you need to be a Gartner client, or buy the document at their site. Gartner.com.

Do All Roads Lead to CMDB?

Strategic Planning Assumption: In three years, 75 percent of all CMDB implementations will fail
to achieve a comprehensive services view of all consolidated IT domains (0.8 probability).
       Do All Roads Lead to CMDB?
       Ronni Colville
       Gartner 25th Annual Data Center Conference, Las Vegas, NV 2006

Interesting presentation and article. Here are just a few quotes as to why this will be the case.

1 Proprietary API's will prevent all the tools from working together well. Quote: "No vendor has
proven their CMDB technology capable of federating the multitude of configuration data sources that any given enterprise might have." Which I believe is true. There are really important specialized data silos such as procurement, the service catalog, source configuration management that need to remain independent.  Because...

2 The CMDB can't scale to meet the real time data requirements of many applications and will have at best 25% to 3% of the data.  This means that islands of configuration data will need to exist.
Quote "Gartner believes the value of the CMDB is to maintain a services view; therefore only the data necessary to understand the relationships between and amongst the component that represents the service should be "in" the CMDB."  Which makes eminent sense. In fact, Gartner believes the CMDB will be much more valuable as an analytical tool, like a datamart or datawarehouse, than a real time repository of all data in IT.

3 Performance is a real issue if we tie events, incidents, problems.  Quote: "Storing all data in a CMDB would be extremely difficult and complex to maintain and would likely never
represent a "real time" view. More importantly, no data store would be able to scale to maintain that level of depth."   Or transaction support, or specific data models.   Tidbit: most implementations of CMDB's are in data centers, not the service desk. 

This is why I believe that the service catalog needs to addressed up front.  By focusing on what customers need and want, building your catalog first ensures that you focus on the services that have most impact and the attributes of the service with the most value to your customers. It also buys you political goodwill to engage on your multi-year CMDB project while reducing the potential work.

To read the whole presentation, you need to be a Gartner client, or buy the document at their site. Gartner.com.

Do All Roads Lead to CMDB?

Strategic Planning Assumption: In three years, 75 percent of all CMDB implementations will fail
to achieve a comprehensive services view of all consolidated IT domains (0.8 probability).
       Do All Roads Lead to CMDB?
       Ronni Colville
       Gartner 25th Annual Data Center Conference, Las Vegas, NV 2006

Interesting presentation and article. Here are just a few quotes as to why this will be the case.

1 Proprietary API's will prevent all the tools from working together well. Quote: "No vendor has
proven their CMDB technology capable of federating the multitude of configuration data sources that any given enterprise might have." Which I believe is true. There are really important specialized data silos such as procurement, the service catalog, source configuration management that need to remain independent.  Because...

2 The CMDB can't scale to meet the real time data requirements of many applications and will have at best 25% to 3% of the data.  This means that islands of configuration data will need to exist.
Quote "Gartner believes the value of the CMDB is to maintain a services view; therefore only the data necessary to understand the relationships between and amongst the component that represents the service should be "in" the CMDB."  Which makes eminent sense. In fact, Gartner believes the CMDB will be much more valuable as an analytical tool, like a datamart or datawarehouse, than a real time repository of all data in IT.

3 Performance is a real issue if we tie events, incidents, problems.  Quote: "Storing all data in a CMDB would be extremely difficult and complex to maintain and would likely never
represent a "real time" view. More importantly, no data store would be able to scale to maintain that level of depth."   Or transaction support, or specific data models.   Tidbit: most implementations of CMDB's are in data centers, not the service desk. 

This is why I believe that the service catalog needs to addressed up front.  By focusing on what customers need and want, building your catalog first ensures that you focus on the services that have most impact and the attributes of the service with the most value to your customers. It also buys you political goodwill to engage on your multi-year CMDB project while reducing the potential work.

To read the whole presentation, you need to be a Gartner client, or buy the document at their site. Gartner.com.

User satisfaction beats cost savings

Big change from a few years ago.

“KPMG's Canadian Advisory practice commissioned a survey from Ipsos Reid in the last quarter of 2005. One senior respondent was qualified and interviewed from each of 254 companies. Each respondent had to be a senior decision-maker within the company in either an IT or business executive capacity.

When asked to rank a wish list of needs with respect to the IT function, 58 percent chose 'enhance user satisfaction' as something they would like to see, only three percentage points behind the leading need, 'lower costs,' and one point behind the second-leading need, 'eliminate redundancies.' The need to enhance user experience with IT was most pronounced in very large companies (1000+); 63 percent of such companies expressed this need….”

Link: ITworld.com - Casting a vote for sound IS governance.

 

User satisfaction beats cost savings

Big change from a few years ago.

“KPMG's Canadian Advisory practice commissioned a survey from Ipsos Reid in the last quarter of 2005. One senior respondent was qualified and interviewed from each of 254 companies. Each respondent had to be a senior decision-maker within the company in either an IT or business executive capacity.

When asked to rank a wish list of needs with respect to the IT function, 58 percent chose 'enhance user satisfaction' as something they would like to see, only three percentage points behind the leading need, 'lower costs,' and one point behind the second-leading need, 'eliminate redundancies.' The need to enhance user experience with IT was most pronounced in very large companies (1000+); 63 percent of such companies expressed this need….”

Link: ITworld.com - Casting a vote for sound IS governance.

 

User satisfaction beats cost savings

Big change from a few years ago.

“KPMG's Canadian Advisory practice commissioned a survey from Ipsos Reid in the last quarter of 2005. One senior respondent was qualified and interviewed from each of 254 companies. Each respondent had to be a senior decision-maker within the company in either an IT or business executive capacity.

When asked to rank a wish list of needs with respect to the IT function, 58 percent chose 'enhance user satisfaction' as something they would like to see, only three percentage points behind the leading need, 'lower costs,' and one point behind the second-leading need, 'eliminate redundancies.' The need to enhance user experience with IT was most pronounced in very large companies (1000+); 63 percent of such companies expressed this need….”

Link: ITworld.com - Casting a vote for sound IS governance.

 

The privacy catalog

This article, "Privacy Is Good Business" and all the recent privacy and data-theft scandales got me thinking that privacy will require it's own set of services inside IT.  Privacy is another, emergent IT silo for which having well defined services in a catalog will pay off nicely. 

From the article

In addition, CIOs need to take steps to ensure that personal data the company collects is accurate and current. One way to improve accuracy is to provide customers with the ability to access and, if necessary, correct, personal information collected about them. And when personal data is no longer relevant (or required by law), companies should get rid of it. The storage of stale or outdated personal information is almost always a threat to privacy.

Privacy is becoming a front page of New York Times issue.  The collection of data, the managing of privacy preferences, the moving of data, and the disposal of data -- in short, the entire life cycle of customer's data is going to come under heavy regulation. 

From an ITIL perspective this means that we are going to have to bring the same management processes (Service Request, Change, Release, Incident) to data that today we have for infrastructure elements. 

We will have to have a privacy catalog for requesting access or use of customer data, applying approval processes and controls and then managing it as asset and CI. Data will have to have regulatory attributes, specific life cycle and disposal.

What do you think?  Is this an issue for your company yet? Do you see it coming up?

The privacy catalog

This article, "Privacy Is Good Business" and all the recent privacy and data-theft scandales got me thinking that privacy will require it's own set of services inside IT.  Privacy is another, emergent IT silo for which having well defined services in a catalog will pay off nicely. 

From the article

In addition, CIOs need to take steps to ensure that personal data the company collects is accurate and current. One way to improve accuracy is to provide customers with the ability to access and, if necessary, correct, personal information collected about them. And when personal data is no longer relevant (or required by law), companies should get rid of it. The storage of stale or outdated personal information is almost always a threat to privacy.

Privacy is becoming a front page of New York Times issue.  The collection of data, the managing of privacy preferences, the moving of data, and the disposal of data -- in short, the entire life cycle of customer's data is going to come under heavy regulation. 

From an ITIL perspective this means that we are going to have to bring the same management processes (Service Request, Change, Release, Incident) to data that today we have for infrastructure elements. 

We will have to have a privacy catalog for requesting access or use of customer data, applying approval processes and controls and then managing it as asset and CI. Data will have to have regulatory attributes, specific life cycle and disposal.

What do you think?  Is this an issue for your company yet? Do you see it coming up?

The privacy catalog

This article, "Privacy Is Good Business" and all the recent privacy and data-theft scandales got me thinking that privacy will require it's own set of services inside IT.  Privacy is another, emergent IT silo for which having well defined services in a catalog will pay off nicely. 

From the article

In addition, CIOs need to take steps to ensure that personal data the company collects is accurate and current. One way to improve accuracy is to provide customers with the ability to access and, if necessary, correct, personal information collected about them. And when personal data is no longer relevant (or required by law), companies should get rid of it. The storage of stale or outdated personal information is almost always a threat to privacy.

Privacy is becoming a front page of New York Times issue.  The collection of data, the managing of privacy preferences, the moving of data, and the disposal of data -- in short, the entire life cycle of customer's data is going to come under heavy regulation. 

From an ITIL perspective this means that we are going to have to bring the same management processes (Service Request, Change, Release, Incident) to data that today we have for infrastructure elements. 

We will have to have a privacy catalog for requesting access or use of customer data, applying approval processes and controls and then managing it as asset and CI. Data will have to have regulatory attributes, specific life cycle and disposal.

What do you think?  Is this an issue for your company yet? Do you see it coming up?

IT portfolios, service catalogs, and enterprise architecture

Read this a while ago. Still has some interesting musings.

The service catalog seems to be more operational in flavor than the application portfolio.

I agree, but the operations are different. The catalog is operational in that it has to support the PODI cycel of Publish, Order, Deliver, Integrate; while the portfolio supports a Publish, Budget, Agree, Plan cycle. The former is for consumption by consumers, the latter for budgeting and planning.

A savvy investor would of course be very concerned with how the offerings of their companies were being received, but the service catalog per se wouldn't necessarily have all the information needed to assess itself;

This is the confusion between the service catalog and the backoffice of IT.  The service catalog is part of the front office of IT. Other elements of the catalog "front-office" are ordering, configuration  (to-be, not the as-is that is tracked in the CMDB), relationship management, provisioning and delivery elements. It's these elements together that give the service catalog it's actionable nature.

the service catalog is just that, a catalog -- not all the operational information associated with every item in it, which is what is needed for the portfolio management process. However, having established a formal service catalog, it would seem to be a good thing to have the tools and processes supporting detailed record-keeping with respect to those services.

Absolutely agree with this notion. 

More at:  erp4it: IT portfolios, service catalogs, and enterprise architecture.

IT portfolios, service catalogs, and enterprise architecture

Read this a while ago. Still has some interesting musings.

The service catalog seems to be more operational in flavor than the application portfolio.

I agree, but the operations are different. The catalog is operational in that it has to support the PODI cycel of Publish, Order, Deliver, Integrate; while the portfolio supports a Publish, Budget, Agree, Plan cycle. The former is for consumption by consumers, the latter for budgeting and planning.

A savvy investor would of course be very concerned with how the offerings of their companies were being received, but the service catalog per se wouldn't necessarily have all the information needed to assess itself;

This is the confusion between the service catalog and the backoffice of IT.  The service catalog is part of the front office of IT. Other elements of the catalog "front-office" are ordering, configuration  (to-be, not the as-is that is tracked in the CMDB), relationship management, provisioning and delivery elements. It's these elements together that give the service catalog it's actionable nature.

the service catalog is just that, a catalog -- not all the operational information associated with every item in it, which is what is needed for the portfolio management process. However, having established a formal service catalog, it would seem to be a good thing to have the tools and processes supporting detailed record-keeping with respect to those services.

Absolutely agree with this notion. 

More at:  erp4it: IT portfolios, service catalogs, and enterprise architecture.

IT portfolios, service catalogs, and enterprise architecture

Read this a while ago. Still has some interesting musings.

The service catalog seems to be more operational in flavor than the application portfolio.

I agree, but the operations are different. The catalog is operational in that it has to support the PODI cycel of Publish, Order, Deliver, Integrate; while the portfolio supports a Publish, Budget, Agree, Plan cycle. The former is for consumption by consumers, the latter for budgeting and planning.

A savvy investor would of course be very concerned with how the offerings of their companies were being received, but the service catalog per se wouldn't necessarily have all the information needed to assess itself;

This is the confusion between the service catalog and the backoffice of IT.  The service catalog is part of the front office of IT. Other elements of the catalog "front-office" are ordering, configuration  (to-be, not the as-is that is tracked in the CMDB), relationship management, provisioning and delivery elements. It's these elements together that give the service catalog it's actionable nature.

the service catalog is just that, a catalog -- not all the operational information associated with every item in it, which is what is needed for the portfolio management process. However, having established a formal service catalog, it would seem to be a good thing to have the tools and processes supporting detailed record-keeping with respect to those services.

Absolutely agree with this notion. 

More at:  erp4it: IT portfolios, service catalogs, and enterprise architecture.

IT Service Catalog - Know Your Audience

I published this a few months back.  Enjoy!

 

The ITIL framework recommends the development of a Service Catalog as a necessary step in the Service Level Management process. The recent ITIL Business Perspective publication reinforces the need to use a Service Catalog as the focal point for interactions between IT and the business. Industry experts agree that the Service Catalog is the first step, and a fundamental requirement, in the shift to a more service-based, demand-driven approach to IT.

There are more and more IT Managers wanting to produce a Service Catalog and a word of wisdom, One-size does NOT fit all. The requirements and content are likely to be quite different, depending upon the primary audience that will use the Service Catalog.

Users versus Customers

The most important requirement for any Service Catalog is that it should be business-oriented, with services articulated in business terms. In following this principle, the Service Catalog can provide a vehicle for communicating and marketing IT services to both business decision-makers and end users.

The ITIL framework distinguishes between these groups as "customers" (the business executives who fund the IT budget) and "users" (the consumers of day-to-day IT service deliverables). The satisfaction of both customers and users is equally important, yet it's important to recognize that these are two very distinct and different audiences.

To be successful, the IT Service Catalog must be focused on addressing the unique requirements for each of these business segments. Depending on the audience, they will require a very different view into the Service Catalog. IT organizations should consider a two-pronged approach to creating an actionable Service Catalog:

    * The executive-level, service portfolio view of the Service Catalog used by business unit executives to understand how IT's portfolio of service offerings map to business unit needs. This is referred to in this article as the "service portfolio."

    * The employee-centric, request-oriented view of the Service Catalog that is used by end users (and even other IT staff members) to browse for the services required and submit requests for IT services. For the purposes of this article, this view is referred to as a "service request catalog."

The Business Executive View

Business executives need to gain visibility into the value delivered by IT infrastructure and operations. According to a recent Gartner and IBM survey of 456 senior business executives, only 17% of finance executives agreed with the statement "Our investments in IT are delivering business value."

As the economic buyer of IT services, these executives look for a portfolio view of the service offerings provided by IT at the budget planning level. They demand greater transparency and they expect the service portfolio to help them answer questions like, "What does IT do? Why does IT cost so much? Is IT doing a good job?"

An executive-level service portfolio should describe the broad categories of service offerings, with service tier options and cost elements. Examples of services represented in a service portfolio may include application hosting for an ERP system; or email with gold, silver, and bronze service level options. Taking the portfolio a step further, services can be represented in the context of how IT supports business processes, such as the infrastructure to operate a kiosk at a retail location, or the IT deliverables that enable the order-to-cash process.

Once this portfolio of services has been defined, business decision-makers can browse the service offerings and drill into the associated agreements, service components, and financial information. With a business-oriented view of available services, including key cost and quality metrics, they have greater visibility into the business value of IT. IT relationship managers and service level managers can create a tailored portfolio of service offerings, establish agreements, set pricing and objectives, monitor performance, forecast demand, and track service consumption for each business unit customer.

The End User View

End users want improved service quality and reliability. What's critical is that the day-to-day IT services they need to perform their jobs are easily accessible, delivered consistently, and of high quality. Yet a TNS National Omnibus Survey found that 43 percent of employees are dissatisfied with the responsiveness of IT service delivery. A common complaint from the end user audience is "Why is IT so difficult to work with? Why does it take IT so long to fulfill a simple request?"

End users need an actionable and easy-to-use service request catalog that describes the products and services they are entitled to order or request from IT. Items in this view of the Service Catalog typically include orderable services where the user initiates a service request that results in a series of delivery activities. Examples of orderable services include the traditional IMAC (install, move, add, change) services required to provision a new PC, upgrade an email account, or provide access to an application.

Other examples in the service request catalog include more advanced IT services, such as application enhancement requests, or even IT-to-IT requests like setting up a new server to host an application. As the central intake point for all IT demand, users will expect to submit "break/fix" incidents through the service request catalog; this view of the catalog may also provide FAQs and other information-only content readily accessible to end users.

The user view of the Service Catalog offers a way to standardize service deliverables, establish service level expectations, and market services to end users. The user can quickly browse or search for available services in the catalog, submit a request, and monitor delivery status - making it as easy for employees to find and order IT services as it is for consumers to order a book on Amazon.com.

Individually, both the end user and executive view of the Service Catalog can help to improve internal customer satisfaction and re-establish trust between IT and the business. When adopted as part of a complete IT Service Portfolio Management solution, IT organizations find they are able to quickly transform the IT-business relationship.

There are multiple paths to realizing the benefit of a Service Catalog, whether starting with the portfolio of services for business executives or publishing the service request catalog for end users. IT organizations should begin by focusing initially on the view that addresses the most pressing challenges in their interactions with the business. Either way, get started today; every moment delayed is time wasted and opportunity lost.

Originally I published this in ITSMWatch.com

IT Service Catalog - Know Your Audience

I published this a few months back.  Enjoy!

 

The ITIL framework recommends the development of a Service Catalog as a necessary step in the Service Level Management process. The recent ITIL Business Perspective publication reinforces the need to use a Service Catalog as the focal point for interactions between IT and the business. Industry experts agree that the Service Catalog is the first step, and a fundamental requirement, in the shift to a more service-based, demand-driven approach to IT.

There are more and more IT Managers wanting to produce a Service Catalog and a word of wisdom, One-size does NOT fit all. The requirements and content are likely to be quite different, depending upon the primary audience that will use the Service Catalog.

Users versus Customers

The most important requirement for any Service Catalog is that it should be business-oriented, with services articulated in business terms. In following this principle, the Service Catalog can provide a vehicle for communicating and marketing IT services to both business decision-makers and end users.

The ITIL framework distinguishes between these groups as "customers" (the business executives who fund the IT budget) and "users" (the consumers of day-to-day IT service deliverables). The satisfaction of both customers and users is equally important, yet it's important to recognize that these are two very distinct and different audiences.

To be successful, the IT Service Catalog must be focused on addressing the unique requirements for each of these business segments. Depending on the audience, they will require a very different view into the Service Catalog. IT organizations should consider a two-pronged approach to creating an actionable Service Catalog:

    * The executive-level, service portfolio view of the Service Catalog used by business unit executives to understand how IT's portfolio of service offerings map to business unit needs. This is referred to in this article as the "service portfolio."

    * The employee-centric, request-oriented view of the Service Catalog that is used by end users (and even other IT staff members) to browse for the services required and submit requests for IT services. For the purposes of this article, this view is referred to as a "service request catalog."

The Business Executive View

Business executives need to gain visibility into the value delivered by IT infrastructure and operations. According to a recent Gartner and IBM survey of 456 senior business executives, only 17% of finance executives agreed with the statement "Our investments in IT are delivering business value."

As the economic buyer of IT services, these executives look for a portfolio view of the service offerings provided by IT at the budget planning level. They demand greater transparency and they expect the service portfolio to help them answer questions like, "What does IT do? Why does IT cost so much? Is IT doing a good job?"

An executive-level service portfolio should describe the broad categories of service offerings, with service tier options and cost elements. Examples of services represented in a service portfolio may include application hosting for an ERP system; or email with gold, silver, and bronze service level options. Taking the portfolio a step further, services can be represented in the context of how IT supports business processes, such as the infrastructure to operate a kiosk at a retail location, or the IT deliverables that enable the order-to-cash process.

Once this portfolio of services has been defined, business decision-makers can browse the service offerings and drill into the associated agreements, service components, and financial information. With a business-oriented view of available services, including key cost and quality metrics, they have greater visibility into the business value of IT. IT relationship managers and service level managers can create a tailored portfolio of service offerings, establish agreements, set pricing and objectives, monitor performance, forecast demand, and track service consumption for each business unit customer.

The End User View

End users want improved service quality and reliability. What's critical is that the day-to-day IT services they need to perform their jobs are easily accessible, delivered consistently, and of high quality. Yet a TNS National Omnibus Survey found that 43 percent of employees are dissatisfied with the responsiveness of IT service delivery. A common complaint from the end user audience is "Why is IT so difficult to work with? Why does it take IT so long to fulfill a simple request?"

End users need an actionable and easy-to-use service request catalog that describes the products and services they are entitled to order or request from IT. Items in this view of the Service Catalog typically include orderable services where the user initiates a service request that results in a series of delivery activities. Examples of orderable services include the traditional IMAC (install, move, add, change) services required to provision a new PC, upgrade an email account, or provide access to an application.

Other examples in the service request catalog include more advanced IT services, such as application enhancement requests, or even IT-to-IT requests like setting up a new server to host an application. As the central intake point for all IT demand, users will expect to submit "break/fix" incidents through the service request catalog; this view of the catalog may also provide FAQs and other information-only content readily accessible to end users.

The user view of the Service Catalog offers a way to standardize service deliverables, establish service level expectations, and market services to end users. The user can quickly browse or search for available services in the catalog, submit a request, and monitor delivery status - making it as easy for employees to find and order IT services as it is for consumers to order a book on Amazon.com.

Individually, both the end user and executive view of the Service Catalog can help to improve internal customer satisfaction and re-establish trust between IT and the business. When adopted as part of a complete IT Service Portfolio Management solution, IT organizations find they are able to quickly transform the IT-business relationship.

There are multiple paths to realizing the benefit of a Service Catalog, whether starting with the portfolio of services for business executives or publishing the service request catalog for end users. IT organizations should begin by focusing initially on the view that addresses the most pressing challenges in their interactions with the business. Either way, get started today; every moment delayed is time wasted and opportunity lost.

Originally I published this in ITSMWatch.com

IT Service Catalog - Know Your Audience

I published this a few months back.  Enjoy!

 

The ITIL framework recommends the development of a Service Catalog as a necessary step in the Service Level Management process. The recent ITIL Business Perspective publication reinforces the need to use a Service Catalog as the focal point for interactions between IT and the business. Industry experts agree that the Service Catalog is the first step, and a fundamental requirement, in the shift to a more service-based, demand-driven approach to IT.

There are more and more IT Managers wanting to produce a Service Catalog and a word of wisdom, One-size does NOT fit all. The requirements and content are likely to be quite different, depending upon the primary audience that will use the Service Catalog.

Users versus Customers

The most important requirement for any Service Catalog is that it should be business-oriented, with services articulated in business terms. In following this principle, the Service Catalog can provide a vehicle for communicating and marketing IT services to both business decision-makers and end users.

The ITIL framework distinguishes between these groups as "customers" (the business executives who fund the IT budget) and "users" (the consumers of day-to-day IT service deliverables). The satisfaction of both customers and users is equally important, yet it's important to recognize that these are two very distinct and different audiences.

To be successful, the IT Service Catalog must be focused on addressing the unique requirements for each of these business segments. Depending on the audience, they will require a very different view into the Service Catalog. IT organizations should consider a two-pronged approach to creating an actionable Service Catalog:

    * The executive-level, service portfolio view of the Service Catalog used by business unit executives to understand how IT's portfolio of service offerings map to business unit needs. This is referred to in this article as the "service portfolio."

    * The employee-centric, request-oriented view of the Service Catalog that is used by end users (and even other IT staff members) to browse for the services required and submit requests for IT services. For the purposes of this article, this view is referred to as a "service request catalog."

The Business Executive View

Business executives need to gain visibility into the value delivered by IT infrastructure and operations. According to a recent Gartner and IBM survey of 456 senior business executives, only 17% of finance executives agreed with the statement "Our investments in IT are delivering business value."

As the economic buyer of IT services, these executives look for a portfolio view of the service offerings provided by IT at the budget planning level. They demand greater transparency and they expect the service portfolio to help them answer questions like, "What does IT do? Why does IT cost so much? Is IT doing a good job?"

An executive-level service portfolio should describe the broad categories of service offerings, with service tier options and cost elements. Examples of services represented in a service portfolio may include application hosting for an ERP system; or email with gold, silver, and bronze service level options. Taking the portfolio a step further, services can be represented in the context of how IT supports business processes, such as the infrastructure to operate a kiosk at a retail location, or the IT deliverables that enable the order-to-cash process.

Once this portfolio of services has been defined, business decision-makers can browse the service offerings and drill into the associated agreements, service components, and financial information. With a business-oriented view of available services, including key cost and quality metrics, they have greater visibility into the business value of IT. IT relationship managers and service level managers can create a tailored portfolio of service offerings, establish agreements, set pricing and objectives, monitor performance, forecast demand, and track service consumption for each business unit customer.

The End User View

End users want improved service quality and reliability. What's critical is that the day-to-day IT services they need to perform their jobs are easily accessible, delivered consistently, and of high quality. Yet a TNS National Omnibus Survey found that 43 percent of employees are dissatisfied with the responsiveness of IT service delivery. A common complaint from the end user audience is "Why is IT so difficult to work with? Why does it take IT so long to fulfill a simple request?"

End users need an actionable and easy-to-use service request catalog that describes the products and services they are entitled to order or request from IT. Items in this view of the Service Catalog typically include orderable services where the user initiates a service request that results in a series of delivery activities. Examples of orderable services include the traditional IMAC (install, move, add, change) services required to provision a new PC, upgrade an email account, or provide access to an application.

Other examples in the service request catalog include more advanced IT services, such as application enhancement requests, or even IT-to-IT requests like setting up a new server to host an application. As the central intake point for all IT demand, users will expect to submit "break/fix" incidents through the service request catalog; this view of the catalog may also provide FAQs and other information-only content readily accessible to end users.

The user view of the Service Catalog offers a way to standardize service deliverables, establish service level expectations, and market services to end users. The user can quickly browse or search for available services in the catalog, submit a request, and monitor delivery status - making it as easy for employees to find and order IT services as it is for consumers to order a book on Amazon.com.

Individually, both the end user and executive view of the Service Catalog can help to improve internal customer satisfaction and re-establish trust between IT and the business. When adopted as part of a complete IT Service Portfolio Management solution, IT organizations find they are able to quickly transform the IT-business relationship.

There are multiple paths to realizing the benefit of a Service Catalog, whether starting with the portfolio of services for business executives or publishing the service request catalog for end users. IT organizations should begin by focusing initially on the view that addresses the most pressing challenges in their interactions with the business. Either way, get started today; every moment delayed is time wasted and opportunity lost.

Originally I published this in ITSMWatch.com

CIO article on Relationship managers

CIO Magazine (continuing with their focus on relationship managers) has an article on the challenges relationship managers have in organizations and how to go about overcoming them.  Some excerpts that drew my attention and resonate with my discussions with you. 

Many clients rejected their relationship managers when they learned that these well-meaning people weren’t in a position to make any commitments on behalf of IT or to solve their technology problems.
....

An internal service provider such as IT is a business within a business, there to deliver products and services to clients throughout the company. It has tough competition from decentralization and outsourcing. And despite monopolies in a few commodity areas (like phones and networking), it must earn “market share” by delivering great value and by developing great customer-focused relationships with clients.
...
In this context, IT absolutely needs a sales and marketing function. Sales in this context is not pushing products to get clients to spend more than they otherwise would (an expense to shareholders). Its purpose is to build excellent relationships, as well as to help clients discover really strategic uses of IT’s products and to align IT with business strategies. It’s a consultative process that helps clients understand and address their key strategic challenges by creatively using IT’s products. In the sales literature, this is termed “strategic selling,” “counselor selling,” or “partnership selling.”

I strongly agree with the need for a marketing role in IT; particularly the "product marketing" role that defines the services and products the IT organization will make available.  This is why the service catalog is so critical to a healthy relationship between IT and the business: without a clear set of service offerings, the relationship manager is forced to invent every single offer on the fly.  The predictable results? Rejection by the rest of IT because it doesn't map to their delivery capacity and loss of trust with their client because they couldn't deliver.

Here's the link: Relationship Managers - Beneath the Buzz - Leadership RC - CIO.  As you read, imagine how the interactions would change if there was an effective service catalog in place.

CIO article on Relationship managers

CIO Magazine (continuing with their focus on relationship managers) has an article on the challenges relationship managers have in organizations and how to go about overcoming them.  Some excerpts that drew my attention and resonate with my discussions with you. 

Many clients rejected their relationship managers when they learned that these well-meaning people weren’t in a position to make any commitments on behalf of IT or to solve their technology problems.
....

An internal service provider such as IT is a business within a business, there to deliver products and services to clients throughout the company. It has tough competition from decentralization and outsourcing. And despite monopolies in a few commodity areas (like phones and networking), it must earn “market share” by delivering great value and by developing great customer-focused relationships with clients.
...
In this context, IT absolutely needs a sales and marketing function. Sales in this context is not pushing products to get clients to spend more than they otherwise would (an expense to shareholders). Its purpose is to build excellent relationships, as well as to help clients discover really strategic uses of IT’s products and to align IT with business strategies. It’s a consultative process that helps clients understand and address their key strategic challenges by creatively using IT’s products. In the sales literature, this is termed “strategic selling,” “counselor selling,” or “partnership selling.”

I strongly agree with the need for a marketing role in IT; particularly the "product marketing" role that defines the services and products the IT organization will make available.  This is why the service catalog is so critical to a healthy relationship between IT and the business: without a clear set of service offerings, the relationship manager is forced to invent every single offer on the fly.  The predictable results? Rejection by the rest of IT because it doesn't map to their delivery capacity and loss of trust with their client because they couldn't deliver.

Here's the link: Relationship Managers - Beneath the Buzz - Leadership RC - CIO.  As you read, imagine how the interactions would change if there was an effective service catalog in place.

CIO article on Relationship managers

CIO Magazine (continuing with their focus on relationship managers) has an article on the challenges relationship managers have in organizations and how to go about overcoming them.  Some excerpts that drew my attention and resonate with my discussions with you. 

Many clients rejected their relationship managers when they learned that these well-meaning people weren’t in a position to make any commitments on behalf of IT or to solve their technology problems.
....

An internal service provider such as IT is a business within a business, there to deliver products and services to clients throughout the company. It has tough competition from decentralization and outsourcing. And despite monopolies in a few commodity areas (like phones and networking), it must earn “market share” by delivering great value and by developing great customer-focused relationships with clients.
...
In this context, IT absolutely needs a sales and marketing function. Sales in this context is not pushing products to get clients to spend more than they otherwise would (an expense to shareholders). Its purpose is to build excellent relationships, as well as to help clients discover really strategic uses of IT’s products and to align IT with business strategies. It’s a consultative process that helps clients understand and address their key strategic challenges by creatively using IT’s products. In the sales literature, this is termed “strategic selling,” “counselor selling,” or “partnership selling.”

I strongly agree with the need for a marketing role in IT; particularly the "product marketing" role that defines the services and products the IT organization will make available.  This is why the service catalog is so critical to a healthy relationship between IT and the business: without a clear set of service offerings, the relationship manager is forced to invent every single offer on the fly.  The predictable results? Rejection by the rest of IT because it doesn't map to their delivery capacity and loss of trust with their client because they couldn't deliver.

Here's the link: Relationship Managers - Beneath the Buzz - Leadership RC - CIO.  As you read, imagine how the interactions would change if there was an effective service catalog in place.

Unraveling the mystery of IT costs

IT cost transparency is a key component of what we at newScale think of as the "next-generation infrastructure." This new approach to managing infrastructure involves discarding the traditional build-to-order mind-set in favor of creating standard, reusable IT "products," such as storage and telephone service. Cost transparency provides the business with three things: a

1. catalog of IT products that specifies features, prices, and service levels;
2. bills showing the infrastructure assets consumed by these products and the cost of their consumption;
3. and management reports that roll up total costs by product type and business unit

Here's an excerpt from a great article on IT budget spend and transparency from McKinsey that I just came across.

Unraveling the mystery of IT costs
[Note: To access the article online, you need to register at the McKinsey site]

Many business managers don't understand IT costs, but explaining them can help forge a true partnership between IT and the business. Andrew M. Appel, Neeru Arora, and Raymond Zenkich Web exclusive, August 2005 Many companies see IT as a black box that generates significant costs; few business managers know exactly what they are paying for and why their outlays keep rising. By making these costs transparent, the IT organization can fundamentally change the way business units consume IT resources, drive down total enterprise IT costs, and focus on IT spending that delivers real business value. The CIO who leads this change can usher in a new era of strategic IT management—and true partnership with the business.

IT cost transparency is a key component of what we call the "next-generation infrastructure."1 This new approach to managing infrastructure involves discarding the traditional build-to-order mind-set in favor of creating standard, reusable IT "products," such as storage and telephone service. Cost transparency provides the business with three things: a catalog of IT products that specifies features, prices, and service levels; bills showing the infrastructure assets consumed by these products and the cost of their consumption; and management reports that roll up total costs by product type and business unit (Exhibit 1).

More...

Unraveling the mystery of IT costs

IT cost transparency is a key component of what we at newScale think of as the "next-generation infrastructure." This new approach to managing infrastructure involves discarding the traditional build-to-order mind-set in favor of creating standard, reusable IT "products," such as storage and telephone service. Cost transparency provides the business with three things: a

1. catalog of IT products that specifies features, prices, and service levels;
2. bills showing the infrastructure assets consumed by these products and the cost of their consumption;
3. and management reports that roll up total costs by product type and business unit

Here's an excerpt from a great article on IT budget spend and transparency from McKinsey that I just came across.

Unraveling the mystery of IT costs
[Note: To access the article online, you need to register at the McKinsey site]

Many business managers don't understand IT costs, but explaining them can help forge a true partnership between IT and the business. Andrew M. Appel, Neeru Arora, and Raymond Zenkich Web exclusive, August 2005 Many companies see IT as a black box that generates significant costs; few business managers know exactly what they are paying for and why their outlays keep rising. By making these costs transparent, the IT organization can fundamentally change the way business units consume IT resources, drive down total enterprise IT costs, and focus on IT spending that delivers real business value. The CIO who leads this change can usher in a new era of strategic IT management—and true partnership with the business.

IT cost transparency is a key component of what we call the "next-generation infrastructure."1 This new approach to managing infrastructure involves discarding the traditional build-to-order mind-set in favor of creating standard, reusable IT "products," such as storage and telephone service. Cost transparency provides the business with three things: a catalog of IT products that specifies features, prices, and service levels; bills showing the infrastructure assets consumed by these products and the cost of their consumption; and management reports that roll up total costs by product type and business unit (Exhibit 1).

More...

Unraveling the mystery of IT costs

IT cost transparency is a key component of what we at newScale think of as the "next-generation infrastructure." This new approach to managing infrastructure involves discarding the traditional build-to-order mind-set in favor of creating standard, reusable IT "products," such as storage and telephone service. Cost transparency provides the business with three things: a

1. catalog of IT products that specifies features, prices, and service levels;
2. bills showing the infrastructure assets consumed by these products and the cost of their consumption;
3. and management reports that roll up total costs by product type and business unit

Here's an excerpt from a great article on IT budget spend and transparency from McKinsey that I just came across.

Unraveling the mystery of IT costs
[Note: To access the article online, you need to register at the McKinsey site]

Many business managers don't understand IT costs, but explaining them can help forge a true partnership between IT and the business. Andrew M. Appel, Neeru Arora, and Raymond Zenkich Web exclusive, August 2005 Many companies see IT as a black box that generates significant costs; few business managers know exactly what they are paying for and why their outlays keep rising. By making these costs transparent, the IT organization can fundamentally change the way business units consume IT resources, drive down total enterprise IT costs, and focus on IT spending that delivers real business value. The CIO who leads this change can usher in a new era of strategic IT management—and true partnership with the business.

IT cost transparency is a key component of what we call the "next-generation infrastructure."1 This new approach to managing infrastructure involves discarding the traditional build-to-order mind-set in favor of creating standard, reusable IT "products," such as storage and telephone service. Cost transparency provides the business with three things: a catalog of IT products that specifies features, prices, and service levels; bills showing the infrastructure assets consumed by these products and the cost of their consumption; and management reports that roll up total costs by product type and business unit (Exhibit 1).

More...

The role of the relationship manager

Another good article in CIO magazine on the "The New IT Department: The Top Three Positions You Need." You can find a good description of the relationship manager role here

The role of the relationship manager

Another good article in CIO magazine on the "The New IT Department: The Top Three Positions You Need." You can find a good description of the relationship manager role here

The role of the relationship manager

Another good article in CIO magazine on the "The New IT Department: The Top Three Positions You Need." You can find a good description of the relationship manager role here