Using Service Catalogs to Run IT as a Business

Using service catalogs to run IT as a business (not “like” a business)

Get Your Copy Now

Service Catalog Trends

Using service catalogs to run IT as a business (not “like” a business)

In most large organizations, the employees who rely on IT to provide and support the myriad devices and software applications that help them do their jobs have only a minimal appreciation of how these devices and applications really work. Consequently, the IT department’s importance in keeping the organization running is seldom fully appreciated.

This state of affairs makes many IT departments reactive and defensive. Frequently, they avoid new projects instead of embracing the opportunity to leverage these projects for the organization’s overall advantage. The burdens placed on IT just to meet minimal business and employee productivity needs has often led to defining IT services less by what the IT department does than by what it doesn’t do.

In recent years, frameworks such as the IT Infrastructure Library (ITIL) and Capability Maturity Model (CMM) have promised to show IT organizations how to operate like a business, instead of as overhead-heavy service units within organizations that under-deliver and downplay their own capabilities. “Like a business” is a loaded phrase, however. It implies that while IT units may adopt the trappings of a real business—treating employees and internal constituents with the same types of service levels and guarantees the business provides to actual customers; following elaborate escalation procedures when service delivery efforts falter; etc.—the effort, by definition, is euphemistic. IT organizations become “like” businesses. They do everything a business does but are rarely held accountable to bottom-line business demands and rarely suffer the consequences of delivering poor service.

This situation is changing, however. As enterprises become ever-more dependent on IT, they are demanding that IT organizations operate not just like businesses, but as businesses. Services and their associated costs have to be more clearly defined (in commonly understood business terms), easier to order, and delivered in a way that is far more transparent to customers than the traditional “black hole” into which service requests once disappeared. The most basic and crucial services are especially subject to this new sense of urgency. No longer are employees content to wait a week to get a desktop provisioned or gain access to a managed application such as Salesforce.com (which simply requires a license addition). IT will have to get faster and better at meeting business demands—but often without additional resources.

Service Catalog Benefits

Service catalogs deliver these tangible and intangible benefits:

• Reduced call volumes improve client service and satisfaction.
• Lower demand on departmental staff reduces routine workload and allows staff to focus on high-value strategic initiatives.
• Automated tracking and documentation fulfills compliance requirements and ensures process consistency.
• Online forms, knowledge bases, and FAQs provide employees with up-to-date information and reduce paper, printing, and distribution costs.
• Centralized electronic access to forms, procedures and information contributes to business alignment objectives.
• Complete, accessible information enables employees to make informed decisions and enhances job satisfaction.
• Service catalog metrics can pinpoint gaps in processes or documentation, highlighting additional opportunities for operational improvement.
• Service catalogs integrated with an existing help desk system improve accuracy and efficiency and increase return on investment (ROI) for system investments.

Service catalogs to the rescue?

Are service catalogs IT’s salvation? Many seem to think so, especially the growing number of service catalog vendors seeking to capitalize on this burgeoning marketplace opportunity. The appeal of service catalogs is obvious. Most organizations provide their customers or constituents with a list of their services and products—a convenient way for clients to order them—and lay out the terms of their delivery. For sophisticated businesses, these processes are often automatically tied into fulfillment and financial systems that automate the order-fulfillment and accounting processes. These systems routinely collect a variety of data, which is then used to identify service-fulfillment bottlenecks, improve delivery processes, reduce costs and personalize customer experiences. To run as a business, IT needs to adopt the same processes.

Though service catalogs can provide clear benefits across an organization, many IT organizations are taking an unnecessarily complex and expensive approach to their implementation. One reason is that IT organizations fail to appreciate that they are already doing much of what is required for successful service catalog implementation; there is no need for excessively complex and expensive service catalog applications that would require them to re-engineer their operations.

Another reason is that the straight importing of traditional IT elements—such as service and operating-level agreements, service definitions, identification of service “owners,” and master lists of services—into service catalogs limits the effectiveness of service catalogs and their usability by business-level users.

Start small and build

Many service catalog software applications have common characteristics beyond a hefty price tag. They are often heavy on definitions and light on both service delivery workflow management for IT, as well as light on providing a simple way for internal or external users to order services and track the progress of delivery tasks.

IT organizations are performing the back-end fulfillment tasks already, albeit often manually and inefficiently. In order to implement a service catalog, they need to develop efficient and repeatable processes for service request fulfillment, publish available services online, and tie online user service catalog interactions into back-end service delivery processes. This obviously requires some effort, but if IT organizations start with a focus on their four or five most heavily requested IT services (and plan to add more later), a simple service catalog implementation can be accomplished fairly quickly without a huge software investment and implementation project.

Business service delivery improvements such as reduced help desk workload can be realized quickly. IT can then redeploy resources into expanding the service catalog. In fact, service catalog initiatives that start modestly and grow over time produce measurable cost savings within just a few months. These savings can be reinvested in the service catalog, making it essentially self-funding very quickly.

A better alternative to Service Level Agreements (SLAs)

Service level agreements are frequently a roadblock to rapid service catalog implementation. SLAs often involve seemingly endless negotiations with user groups, yet end up as somewhat arbitrary measures.

For instance, 24 hours to restore a file seems “reasonable” to IT and user groups, so that figure becomes accepted. The number doesn’t mean much, but attempts to reconcile the expectations and perspectives of many different users can drag out the process of establishing acceptable service timeframes.

Service catalogs in IT and beyond

Service catalog applications can be used throughout organizations to streamline business processes:

Establishing SLAs is ultimately a needless effort to quantify what’s already happening.

Service catalogs enable IT groups to automatically measure service delivery times and calculate averages. These figures can be used to establish, for each type of service request, something far more meaningful to service requestors than an SLA—a service level expectation (SLE), or how long IT historically takes to deliver a service. Instead of an SLA of one week, for example, service catalog users can see that it takes an average of two days to fulfill a particular request. This sets expectations that are based on measurable reality rather than conference room discussions and establishes a baseline for process-improvement efforts. SLEs are unlikely to make SLAs and operational-level agreements (OLAs) obsolete. These standards will still be needed to set minimum performance benchmarks and, if consistently violated, to alert IT and business management to problems. But SLEs can offer these benefits: SLEs are a better reflection of reality than SLAs. And they can be established within a short time for all of the services an IT organization offers.

• They facilitate the rapid and efficient implementation of catalogs. They provide a quick, inexpensive and accurate reflection of service delivery times.
• They provide end users with a realistic assessment of when a request will be fulfilled, and service owners with information to help quickly identify problems and target areas for improvement, as well as a way to document and demonstrate these improvements.
• A basic business maxim is that you can’t improve what you can’t measure. With SLEs, IT has measurable data that can be used to reduce costs and improve efficiency.

The User Perspective

SLEs will change service catalogs as well as the user experience. In service catalogs that include SLEs, requestors can view three crucial metrics:

• the SLA that has been established for the service (e.g., seven days);
• the current SLE for the service (e.g., over the past 30 days, 75 percent of requests for this service were fulfilled in less than two days); and
• the current satisfaction rating of all users for that particular service.

Users can then request the service through the service catalog interface, and, after delivery, be prompted via email to rate their satisfaction. This scenario is possible with most service catalog and automated survey software tools available today, and delivers a more effective and satisfying user experience than lengthy “standard” service definitions, SLAs with no context, and instructions for off-line procedures to actually request the service.

How service catalogs will change IT

Service catalogs provide numerous benefits to IT departments, including reduced costs, improved delivery times and enhanced service quality. From a broader perspective, a well-implemented service catalog can radically alter the role and perception of IT within an organization.

IT will start marketing its services.

As IT streamlines service request and delivery processes through service catalogs, it will actually start to welcome new projects and encourage the additional use of its services by marketing projects to targeted internal constituencies. This is a major shift. Users will see IT as less of an unresponsive cost center and more of a business enabler.

Service catalogs will put IT back in control.

Impatience with the pace of IT projects has led many larger organizations to hire outside consultants and contractors. As a result, IT often loses control over technology services and infrastructure. Business and IT infrastructure projects can become ends in and of themselves, sidetracked from achieving critical business objectives.

Identifying key services and standardizing their delivery processes will allow IT to improve response times, assume more responsibilities, develop new and more business-focused skill sets, and reduce reliance on outsourcing for strategic projects.

The service-owner role will change.

IT roles in the past have been highly technical and often specialized. Service catalogs will result in more business-focused service ownership. Since service catalogs enable IT to run as a business, service owners will need more business skills as opposed to purely technical skills. And service owners will eventually utilize reporting to identify the types of people who should be taking advantage of their services. This will allow them to send marketing materials to potential users and educate all users on different functions in an application.

“Going to a catalog” for service requests will become less common as service catalogs are embedded into applications.

Today, service catalogs exist as separate entities. Though current applications enable organizations to implement useful service catalogs (e.g., with short, customized definitions; easy-to-use request forms; transparent and traceable processes; etc.), users still have to stop what they’re doing and access a separate website to request services.

In the future, relevant service catalog pages will be imbedded directly into applications, so users can request a service without interrupting their own workflow.

For example, in an organization that uses SAP, if users need a product code, account access or an order restored—all typical SAP service requests—they’ll be able to click on a link within SAP to go directly to the SAP service catalog page.

Today, many service catalogs are like a Sears “wish book”; they’re huge and describe virtually every service offered by the IT group. In the future, IT will offer dozens or even hundreds of different types of specialized catalogs embedded into specific applications (like SAP), functional areas (such as Web services) and/or departmental applications (like HR services in HR applications).

These service catalogs will be embedded where the services are needed. There will be real-time, on-demand service request capability in the application itself, as opposed to a separate service catalog that requires users to wade through irrelevant information and perform unnecessary steps. In short, the notion of “going to the catalog” will become less common even as usage of service catalog requests increases.

Putting together the service catalog

Simple and actionable is better than complex and slow.

The most important element of an actionable service catalog is the division of service requests into finite tasks that can be completed in short time frames. Excessive service catalog complexity frustrates users, who will eventually attempt to circumvent the service catalog process and submit requests through informal channels, making service measurement and improvement virtually impossible.

Use measurement tools.

There are many analysis tools available to measure the usability and effectiveness of Web-based applications. Since service catalogs are Web-driven, these same tools can be used to measure the usability of service catalogs.

Don't over-define

Some service catalogs devote far too much time and space to service definitions. Often these “standard” definitions are too generic to be meaningful to users with specific job-related or business needs. Worse, some catalog tools don’t provide online service request capabilities; they are nothing more than repositories of service definitions with off-line ordering instructions. While a static list of services meets the ITIL requirement, it has limited value to the organization.

Good service catalogs focus on making it easy for users to request services and track delivery status, while standardizing and automating back-end fulfillment activities.

Avoid prebuilt service content.

Although this notion runs counter to industry trends—as many software vendors are focusing their efforts on prebuilt service definitions and SLAs—every company is different and has unique communication and service delivery needs. One-size-fits-all content often doesn’t fit any organization very well. IT organizations increasingly recognize the need to define their own services and SLAs. These organizations realize that prebuilt content, which forces arbitrary process changes, has little real value and may even be counterproductive.

By starting small with discrete, easily definable services and using a flexible software package that makes it simple to add services over time, you can avoid the problems associated with prebuilt content.

Implement in less than one month.

Long-term service catalog and related Web-development projects are disappearing. The technology is now sufficiently mature and the service catalog concept so well understood that IT organizations no longer need to reinvent the wheel to produce actionable service catalogs. Off-the-shelf software now provides all of the functionality that once had to be custom developed.

With that in mind, many IT organizations are starting small on service catalog projects and eschewing the “big bang” approach. These organizations realize that they don’t need hundreds of services to build a useful catalog. Some start with as few as five commonly requested service items, enabling them to quickly provide real value to the businesses utilizing them. The support generated by getting a service catalog implemented and quickly providing value is a solid start toward maintaining the momentum. Continually adding groups of five–20 service items, until all standard IT services are made available through service catalogs, keeps the momentum going.

Start small, think big. That’s the way most successful businesses get going. And that’s the best advice IT organizations can follow when it comes to service catalogs.

About the author

John Sundberg, founder and president of Kinetic Data, is an entrepreneur who has demonstrated effective leadership by creating a team culture that has spearheaded the company’s consistent growth. During his two decades of designing and managing successful, innovative information system implementations, he has been a lead architect, developer, or project manager of over 100 projects for medium and large enterprises, with extensive work in large systems, distributed systems, systems management, and consulting.

Prior to founding Kinetic Data, Sundberg applied his technical and management expertise at 3M; Programming Alternatives, Inc.; Wilson Learning; and as an independent consultant. At 3M, he was a liaison between IT and several development groups, where he discovered why projects succeeded or failed, leading him to build his company around a team concept, as he found the groups that worked well together produced successful projects.

John is president of the Minnesota Chapter of AFSMI (Association for Services Management International).

About Kinetic Data, Inc.

Kinetic Data is one of the largest and most experienced third-party BMC Remedy software companies in the world, offering the most extensive portfolio of third-party, “built on BMC Remedy,” packaged applications available. A BMC Remedy Technology Alliance Partner since 1999, Kinetic Data has helped over 200 Fortune 500 and government customers—including General Mills, Avon, Intel, 3M, and the U.S. Department of Transportation—implement BSM and service delivery management (SDM) applications aligned with ITIL best practices. In 2009, the World Wide Remedy User Group (WWRUG), an independent group of BMC Remedy users, named Kinetic Data “Innovator of the Year,” and the group honored Kinetic Data with its "Best Customer Service and Support" award in 2010. The company serves customers out of its headquarters in St. Paul, Minn.; offices in Sydney, Australia; and through a network of leading BMC Remedy reseller partners.