10-steps-whitepaper-13796538102703

10 Steps to Modifying User Behavior to Reduce IT Costs 1-800-COURSES www.globalknowledge.com Expert Reference Series of White Papers Written and provided by White Paper Stevie Sacks, Enterprise Architect CA Executive Technology Advisors February 2006 10 Steps to Modifying User Behavior to Reduce IT Costs Table of Contents Introduction 3 How to Use This Paper 3 Step 1: Document Services 3 Step 2: Document Service Levels 4 Traditional IT Application Service Agreements 5 Nontraditional Consumer-Usage Agreements 5 Step 3: Align Services with Business Goals 5 Aligning Services With Financial Management 5 Aligning Services to Corporate Goals 6 Aligning Services for Increased Efficiencies 6 Things to Keep in Mind 6 Step 4: Price Services 6 Price = Cost 6 Price = Cost + Profit 7 Cost Allocation = % of Usage x Total Budget 7 Step 5: Measure Resource Usage or Consumption 8 Usage Basis 8 Inventory Basis 8 Mixed Basis 8 Step 6: Define a Service Catalog 9 Step 7: Provision Services by Automating Workflow 10 Step 8: Provide Business with Visibility Into Service Costs 11 Step 9: Provide Self-Help and Self-Service Alternatives 12 Step 10: Provide Tools to Support Services and Measure Customer Satisfaction 13 Additional Guidance 13 Conclusion 14 2 Introduction In an economic climate of slow and cautious growth, IT is under intense pressure to manage costs and ensure that spending is well aligned with business drivers. Essentially, IT is being asked to run itself as a business — allocating resources where they will generate the most value while minimizing resources from nonproductive areas. One way to achieve this resource conservation and alignment is to increase efficiency. But that's only part of the battle. To truly optimize the business value returned by its investment dollars, IT must manage, measure and control the utilization of its services. After all, when users burn up IT service capacity in ways that don't return value, the result is waste, regardless of how efficiently IT may be operating. IT Service Management (ITSM) as defined in this white- paper enables IT to define, deliver, measure, support and cost mission critical services in the most cost-effective and efficient way possible to support business goals. IT can modify user behavior by making business units financially accountable for their consumption of services (or resources comprising of labor, asset and support). Steps can be taken to keep users from consuming IT capacity in ways that don't make good business sense. And by incorporating these strategies into ITSM mechanisms, IT can run itself more like a profit-making business and less like a subsidized utility. Usually, IT isn't in a position to say no or to curb demand for the resources it stewards. IT must change the environment so that it isn't driven by needless requests. Human dynamics will play a large role in this change. People modify their behavior only when they feel some sort of negative or positive impact. It will be necessary to change not only the number of requests but also the nature of the requests made to IT. This can best be done by giving users on the business side the information they need to make informed decisions. The 10 steps to IT Service Management are: 1. Document the services you provide. 2. Document the service levels that are expected. 3. Align services with business goals. 4. Price these services. 5. Measure resource usage. 6. Design a service catalog. 7. Provision services by automating workflow. 8. Provide business units with visibility into service costs. 9. Provide self-service and self-help alternatives. 10. Provide the tools to support the services and measure customer satisfaction. These steps give the user community and business managers the tools they need to modify their own behavior or "buying" patterns. They can see what services are being used by their employees, how well service levels are being met and how this affects their budgets. They have alternatives to calling the help desk. And they are presented with easy-to-use systems that remove the temptation to do an end run around support procedures. How to Use This Paper This whitepaper will help you understand the practices and procedures needed to implement the foundation for changing behavior in both the business and IT communities within your corporation. We will take you step by step through the various processes you need to consider when implementing your strategy. Each section of this document will take you further along the road toward measuring, controlling and managing IT resources and investments. The first step is the most difficult, but it makes each subsequent step that much easier. Do not think that you have to adopt all the steps, or in order — common sense should prevail depending on the maturity of your organization and other initiatives taking place. You can choose to adopt only certain concepts from various steps; however we propose that you follow these general precepts: • Communicate your plans early and often to the greater organization. • Build a usability lab for feedback when implementing new or changed user interfaces. • Modularize your approach when considering the larger projects and principles contained in this whitepaper. The two guiding principles behind the steps are simple: Empower users to make the right decisions by giving them information and choices, and provide financial incentives and penalties that motivate them to change usage patterns and behavior. Step 1: Document Services When you envision yourself as the CEO of a service provider company it becomes clear you must define the services that you provide, how you provide them, who is involved in their delivery and how much it all costs. Ask yourself what you need to do to make a profit. Part of the answer will be incentives and penalties that can change user behavior. These should be accompanied by empowerment, which allows users to make choices based on clear information, such as support levels and prices. By allocating costs back to users and giving them the 3 information they need to make informed decisions, they will be less likely to demand the fastest, biggest server when a smaller machine might do. Your users are your customers, and you should sell your services to them through a service catalog in which your tiered service levels are explained. Users can use this catalog to find out what you charge for services at various service levels, the charge method (as a monthly retainer, per subscription or by usage, for example) and whether you offer price points for size, usage or service levels. Dialog and negotiation should take place with your customers when defining services. If your customers are going to choose services and service levels that are appropriate to their requirements, the catalog should define your services in a business context, and the service definitions must be flexible and comprehensive enough for users to find what they need. Services must be measurable in relationship to service levels. Costing should follow standard financial guidelines, however this is not always the case. A discussion with your financial and legal departments should be on your task list. Where do you begin? Bring together people who understand what services the IT department provides, how they are provided and who provides them. At first, this will include only members of IT; later, members of the greater business community will become involved. Break down IT services into three main categories: 1. Services performed directly for individuals in the company. These are usually user support tasks such as provisioning. For each of these, include options, prices and service levels. 2. Services done to support line-of-profit application systems. These are the application systems hardware, software and related support. Include these in the catalog if the business unit has the freedom to choose components, options or service windows. 3. Services that are common to the support of the corporation. These are infrastructure devices, security and business continuity services, and other things deemed to be "overhead" functions. Some items may fall into multiple categories. For example, the business as a whole relies on email to carry out day- to-day functions, so the infrastructure and support of the email system might fall under overhead or shared services. Your catalog may have multiple items to accommodate different mailbox file sizes with associated pricing. Service level agreements may be placed on the size or number of emails received or sent, with a penalty adjustment for overuse during billing. Another example would be provisioning. You may already have standard hardware configurations based on the capabilities of each machine. For the service catalog, you may want to categorize the offerings by role, such as sales, executive or administrator. This will allow the customer to choose the correct equipment for the purpose based on a meaningful description. You don't want to include specifics such as models, however, since these can change frequently. One of the most common mistakes made is to define service offerings that have mandated or predefined service levels. Let us assume that you have a critical application, which by its inherent nature must be available 24/7; hence there would be no need to define a “Silver” service level objective calling for 8/5 availability. A few tips: • Don't confuse service level categories such as Gold, Silver or Bronze with defining a service. • Do group services under a relevant umbrella. • Don't define service offerings when the key performance indicator is pre-defined by the nature of the application system. For example: Your on-line retail site would by its nature require 24/7 availability with reasonable response time to support revenue generation. Therefore you would have an SLA but not a Service Catalog Entry. • Do choose names for your service offerings that users will understand. Use business-centric names such as "New Hire Provisioning," "Application System Hosting" or "Department Transfer." Step 2: Document Service Levels You should fully define all of your services, such as hosting critical business systems, provisioning new employees and responding to help desk calls. Then apply a litmus test to the services you've defined that will help you create a service level agreement for these services. SLAs are basic control mechanisms for IT, ensuring that business requirements are demonstrably met. The litmus test consists of a series of questions: 1. Can the service be measured in a way that aligns with the business requirements? a. Do you know all the components that make up the service? b. Do you have the tools to measure the service? 2. Whose perspective is to be measured? a. Will there be a service level definition from the consumer's as well as the provider's perspective? b. Are there any other groups that will be required to commit to an SLA? 4 3. Will the consumer or interested parties agree to reasonable terms and definitions? 4. What is the financial impact of a failure to deliver the agreed-upon service level? a. Based on that financial impact, is there an appropriate corresponding monetary penalty? In an ITSM environment, SLAs should include incentives for reducing resource usage and deterrents against overuse. After all, IT can't agree to provide a specified level of service for a transaction-processing system with an expected transaction volume of x if that volume suddenly spikes to 10x. That's why the process of negotiating an SLA is meaningful only if it is used to clarify mutual obligations and resource limitations, as well as work-unit benchmarks. (I am using the term work unit to refer to any unit of performance measurement. A work unit can be any quantifiable measure, including availability, response time or number of emails.) Let's look at three sample scenarios, two of which are traditional, and one that is not. Traditional IT Application Service Agreements A traditional IT service agreement usually focuses on the applications that generate revenue or are critical to corporate operations, such as accounting or payroll. The SLAs attached to these applications are usually based on availability. Keep in mind, a transaction-processing system may require round-the-clock availability, but others, like a payroll application, do not. When negotiating an SLA, make sure the customers understand that supporting greater availability increases costs. Allow them to determine whether the occasional need for a manager to have remote weekend access is worth the additional cost. You may also negotiate a guaranteed application response time from the user's perspective. The one caveat with this type of service agreement is that you must be able to measure response time from that perspective. You may want to set up a workstation to be used only for establishing a performance baseline and performing ongoing measurements. This ensures that response times aren't being viewed subjectively or by performance on a desktop that is seriously underpowered or misused. Traditional IT Support Service Agreements Another traditional type of service agreement is based on the time is takes to respond to a service desk call. The one caveat you should keep in mind when negotiating this type of service agreement is not to contract for a work unit based on mean time to repair. Mean time to repair can be based on so many factors that you may end up missing many of your service levels. Nontraditional Consumer-Usage Agreements Consumer-usage agreements are nontraditional methods of curbing IT resource demand. Printer and email usage are two areas where benefits can be reaped by cutting demand and costs. You may negotiate various levels based on the number of units, such as 500 pages printed per month on any given printer, or the volume of email sent or received by a user, specified in bytes. Such agreements may prompt business-unit managers to ask their employees to take steps like zipping or compressing large attachments or printing only what's necessary and not using hard-copy printouts just to view files. Financial and other such incentives are essential to change user behavior. The disconnect between SLAs and user behavior can be remedied when your service catalog, cost allocation/billing and service level management systems are coordinated and integrated. By integrating the SLA into a cost allocation/billing system, credit adjustments can be made should an SLA be missed or breached. Here are some pitfalls to look out for: • Make sure that all negotiations use the same terminology, business goals and executive sponsorship. • Ensure that there is some meaningful incentive to change behavior. • Ensure that you can provide baseline and ongoing, meaningful metering of the defined work units. Step 3: Align Services with Business Goals Aligning IT services with the implementation of service level agreements (SLAs) designed to formalize the contract between the business community and IT means ensuring that the performance of the service can be measured and is in line with the stated service level objectives (SLOs). Aligning Services With Financial Management When aligning service with financial management through cost allocation or a formal chargeback, the associated hard (asset) costs and the soft (support, maintenance, labor and usage) costs will need to be determined in order to effectively price the service. Varying prices can be established based on SLAs. This can help influence customer behavior toward the goal of reducing costs, since customers might decide that their needs can be supported through less-expensive alternatives than they otherwise might have chosen. Financial management encompasses a range of processes. Asset management and inventory provide data relating to what is owned and what is installed. Incident and problem 5 management provide more data, recording actual downtime of inventory components. Correlation of these records will allow management decisions based on objective data versus perception or anecdotal, subjective information and will support a viable cost allocation/billing system. As equipment ages, support and maintenance costs may climb, in direct relationship to the decreased value of the equipment due to depreciation. Payroll costs as a whole for every company can far outweigh equipment costs, hence the correlated data belonging to payroll must be married to some form of time-tracking system for accurate support costs. Aligning Services to Corporate Goals Compliance with government regulations is a major issue for IT. If it's one of the key drivers for defining the management of services within the wider context of your organization, you'll need to work closely with the department that's driving the compliance initiative. At the very least, you may be required to produce periodic reports to verify compliance. It's also possible that you will be the one who must implement the processes needed to meet new compliance standards. Cost reduction is always a concern for both IT and the business. Streamlining processes and offering self-service capabilities through a service catalog and knowledge bases can reduce costs while empowering users. Streamlining and automating processes for initiating requests and authorization can reduce time to service, freeing technicians to work on higher-priority issues like increasing efficiencies or providing additional revenue- generating capabilities. Aligning Services for Increased Efficiencies Capacity planning provides proactive IT management by enabling equipment to be replaced before it affects performance. By comparing the current and future needs of the business with existing computing power, IT can use budgeting and planning processes to achieve greater efficiencies. To this end you will need to have asset inventory and asset portfolio management in place. To align services for increasing efficiency of computing power, you may be turning to technologies such as server virtualization or on-demand computing. If so, you'll need to examine how these technologies will affect the pro- visioning of services. Server virtualization enables flexibility, since a virtual server can be moved from one physical computer to another. If the new server is larger or more costly, you need to know how this will affect current SLAs and cost allocations/billing. As for on-demand computing, it can challenge traditional service definitions based on set metrics such as MIPS, memory or processors. Things to Keep in Mind When reviewing your wish list of services, two very important factors to remember are your company's culture and the cost of implementation. The Information Technology Infrastructure Library (ITIL) recommends that all services be contained in a service catalog, but it's important to consider whether or not you want a user looking through an online catalog for services defined as underlying technology for your SLA or cost-allocation systems. There is no hard rule that says you have to have all of the services defined in any one service catalog. You may opt to have two: one master and another for online subscriptions. Always consider the end result you are trying to achieve. How you maintain the underlying systems will determine the level of success that can be achieved in having a service catalog that maps IT to business requirements. Step 4: Price Services It is important to understand the rationale for setting a price on services. Are you actually executing cash charge- backs for IT services in order to fully allocate all technology costs to departments or lines of business? Or are you trying to keep consumption of services within some defined budget, with departments incurring financial penalties only if they exceed specific thresholds? You have to weigh the precision and detail of your pricing scheme against the time and effort you want to invest in maintaining it. At some point, the incremental benefits offered by gains in accuracy will be outweighed by the burdens associated with administering an overly complex system. Before choosing a method of calculating service costs, make sure you're clear about your business purpose. Otherwise, you could wind up creating a system that's technically impressive but adds too much overhead cost to be viable. Next, you have to determine the specific financial model you're going to use for pricing your services. There are three primary approaches you can use: • Price = Cost • Price = Cost + Profit • Cost Allocation = % of Usage x Total Budget Price = Cost This method calculates the price of the service by determining the cost of providing the service. Typically, this includes the costs of hardware, software and labor. Since many of these resources will obviously be shared rather than dedicated, their cost has to be prorated based 6 on how much they are utilized by each department. Again, the precision with which this prorating is done, and the exhaustiveness with which every conceivable cost component will be discovered and tallied, will be determined by your business objectives. Historically, costs of shared resources are the hardest to determine. Usage is the most accurate of methods, but it is also the hardest to accomplish. You need to pick a metric such as network packets for WAN or LAN usage or CPU, memory or transactions for servers. Next, you will need to determine how you meter and accumulate the usage data. Usage data requires it to be mapped back to the business unit by some recognizable unit, such as application or application system. If multiple business units share an application, you will then need to do some additional calculations to determine a percentage of the entire application's usage. Besides computer-related expenses, you will need to take into consideration the cost of personnel, which usually proves to be the most difficult to determine. To be accurate, you need to know not only how much people cost (payroll + benefits + other expenses), but also how long it takes them to do any given task or how much time they spend supporting any given area. There are many ways to do this, but two examples include the “Attorney Model” and the “Mechanic Model.” The “Attorney Model” requires personnel to use a time-tracking system in which their time is accumulated and billed directly to the business unit. The Mechanic Model equates each task with an average or swag time and cost, and allows you to show the cost of labor in your catalog. Price = Cost + Profit This method determines a percentage of profit in assigning price. This is done for several reasons. One, it provides some cushion in case service delivery costs aren't properly captured or unexpected budget overruns occur. Also, the addition of a profit margin adjusts for the fact that costs are recouped after expenditures are made and that costs are always rising. Cost plus profit would be the same accounting methodology used if IT was a self sustaining service provider. Cost Allocation = % of Usage x Total Budget The cost allocation method sets pricing by apportioning IT's total expenses to each business unit based on metrics such as head count or metered service utilization. The calculation of service costs based on metered utilization typically requires use of a fairly sophisticated pricing application. Different pricing methods may be used for different types of services. As previously outlined in Step 1 there are three basic categories of IT services: common or shared services, consumer-based services and line-of-profit services. Common services are networking, facilities, security and business continuity that may be charged based on cost allocation. Consumer-based services are charged on a cost-plus basis. The real test of your pricing model is its acceptance by your business users and, by extension, its impact on their behavior. These decisions will typically be made by a consensus reached among finance managers, IT executives and business unit representatives. For example, if your pricing structure provides appropriate incentives for business units to be more judicious in how much power they specify for their desktops and laptops, your costs may be reduced. If, on the other hand, your measurement of service utilization doesn't have much credibility with your users, then they're likely to balk at overage charges, and not curb consumption. Keep in mind that customers expect a reasonable amount of documentation for pricing schemas and penalties. Clear pricing formulas should be included in service catalogs, service agreements and accounting records. Accurately pricing the services you deliver can do more than just improve ITSM. It can actually improve the quality of the relationship you have with your internal customers — since it provides them with a financially quantified expression of the business value you provide. 7 Step 5: Measure Resource Usage or Consumption The most commonly measured or metered items for audit, cost allocation/billing, service level management and reporting after a business unit has subscribed to a service are the following: 1. Meter each service for the number of subscriptions by business unit, department or user for audit and cost allocation purposes. 2. Measure usage of common services by business unit, department or user for both cost allocation and management reporting. 3. Report on violations of service level agreements by application system, common services and business unit. 4. Provide billing statements or invoices based on a usage, inventory or mixed bases, as defined below, by business unit. 5. Generate management reports that verify audit and compliance controls. 6. Measure shared infrastructure, then report the total usage while apportioning the cost to the business units. The two most common elements for measuring IT resources are usage and inventory. Usage is the measurement of a resource; inventory is determined by the number of physical entities. Usage Basis Some services may be based on ongoing usage statistics, such as server memory and requests. If you are concentrat- ing on violations of service level agreements based on outages or unacceptable performance, you must monitor or meter the availability and performance. If you are basing service levels on response time performance, note that perceived response time by a user may dramatically differ from the performance registered by the individual components of an application system. If user response time is a metric for service level agreements, you must monitor real time response against a baseline negotiated with your customer. One approach is to monitor a sampling of the user's desktop response times, calculating an average over a specific time. You could then set up a "control PC" in the data center for constant monitoring. You will need software or a script to run the same simulation as you did in real time with the users. By using the end-to-end user perspective, you achieve end-to-end monitoring by default. If you have extreme variations in network capabilities across your network, you may need to set up control PCs at various points to ensure reasonable results. If devices such as servers are shared, you may need to meter usage based on processes or users. Common metrics are CPU, memory or transactions. Note that hundreds of processes often run on any given server. Each may need to be mapped to application systems. Unique user IDs need to be correlated to the application system being accessed. Usage works well for service level management and accounting for resource usage, but may become extremely complex for service subscriptions. Inventory Basis Inventory is a lower-overhead alternative basis for measurement. If physical or virtual services are dedicated to a department, incurring the overhead of operating system metering usage may be unnecessary. Instead, you may want to allocate the cost of hardware, software and personnel to the department based upon the number of servers the department uses. Inventory basis works best with services that can be subscribed to, based on a flat fee per accounting period per unit, such as the number of servers within a hosting subscription. Why use an inventory basis? Billing by inventory method is the simplest way to apportion costs for servers, telephones or any other physical entity that can be mapped to a specific owner. If physical or virtual services are dedicated to an application system or business unit/department, you probably won't need to add the overhead of real-time metering of resources. Instead, simply allocate the cost of hardware, software and personnel to the department by server. The inventory method requires you have data on the cost per unit, for example the cost of a Microsoft Office license, plus the cost of supporting the software. You will also need to be able to compare who has installed the software, who requisitioned or requested the software and what business unit should be charged. Mixed Basis Mixed basis or historical basis will not add additional metering overhead for shared resources. Historical basis works well for service subscriptions and accounting but not service level management. If you are conforming to ITIL capacity management best practices, for example, you may already have the historical data you need. Whatever the source, you can use historical data to measure resource usage. For example, you could base usage on an average over a 12- or 13-month period. Using this average, you could assign a percentage of the use by department or cost center. Your clients may insist on actual usage metering if you assess penalties for waste or overuse. However, your clients should be aware that actual usage metering incurs additional overhead and cost which must itself be allocated back to the business. 8 High availability is a common requirement for many of the services provided by today's IT departments. Sophisticated software and redundant hardware for high availability are costly and may not be warranted for less critical "back-office" systems. IT customers sometimes request high availability for non-critical systems because they are not aware of the cost. When several cost scenarios are presented to business managers, they can make economic decisions based on fact. If you have the facts based on monitoring and metering, you are prepared to successfully negotiate customer expectations, use of resources, and requirements. Reducing IT resources through customer behavior is achievable, when IT and their customers work together based on facts, not perceptions. Step 6: Define a Service Catalog There are two types of Service Catalogs — internally focused and public-facing. Why two catalogs? The internally focused catalog is specific for use by IT and may include services not apparent to the user community such as decommissioning of hardware. The public-facing catalog for self-service subscription should be designed for ease of use and to support the customer's need to make informed decisions. The internal, IT-focused service catalog should include all information needed to support initiatives such as service level management, configuration, change and other libraries. An ITIL-compliant catalog should house service level information, ownership, support, authority and financial information. The catalog should be designed to work with or act as input to chargeback, service level agreement and service desk software, which serves as an underpinning for the standardization of definitions and terminology. If you're considering a move to a service-provider model, you'll probably need to create an online service catalog with a self-service menu and shopping cart. You may want to set up your online storefront with offerings that relate to each other, such as the human resources and facilities services that are needed for new employees, including adding user IDs, setting up email and file access, and assigning office locations. If you find yourself struggling with the level of detail you are planning on presenting to your customers, you may want to consider the following areas: • Group service offerings meaningfully for easy navigation. For example, consider the path for an employee who needs a new laptop. Your catalog might list new or used laptops with component upgrade entries, various memory configurations, hard drives and screen sizes. This will give the user an opportunity to choose the one that best fits his or her needs and budget. • Promote informed trade-offs between price and service levels, size and quantity, etc. An uninformed service-catalog user could choose an expensive level of service that might not be warranted by the task performed. Sometimes, one large server is substantially cheaper than two smaller servers. An informed user can make the choice that best serves the business. You can't expect customers to modify their behavior without providing preferred alternatives or incentives such as better prices. Let's look at an example that involves a new employee. A manager needs to order email to be provisioned. He or she is presented with three selections in the catalog: a standard-size mailbox at no charge or one of two larger mailboxes, each with an appropriate monthly maintenance fee. The manager will then be able to select the alternative that best fits his or her budgetary restrictions and the requirements of the new employee’s role. The look and feel of your catalog should be simple and straightforward, providing easy access and navigation from one offering to another. Design the catalog to be as intuitive as possible, use links to additional information or help screens while enabling search capabilities. Don't hesitate to duplicate sub-items like the purchase of a hard drive that might appear under offerings for repair, new purchase or upgrade. Depending on the hardware and software you choose to deploy, your service catalog will dictate the design of the catalog. You should perform usability studies and per- formance tests in advance. Take into consideration the many types of employees and levels that exist within your corporate structure. Testing should include both technical functionality and the more subjective usability testing. Usability studies are critical to your overall success of your catalog. Whether you set up single or multiple catalogs complete with software integration, automation or multiple repositories, the outcome will depend solely on your predetermined requirements, goals and resources available to support the effort. One of the most difficult parts of creating either catalog is the time and effort needed to research and define your services to provide an appropriate level of support to meet your requirements. With your goals clearly in mind, regardless of whether you're implementing one or more catalogs, their unique purpose should yield positive results. 9