Run IT as a business, not “like” one
In many large organizations, the IT function’s role is poorly communicated and so poorly understood. IT sees business users as demanding and unappreciative. Users see IT as reactive and defensive.
Frameworks such as the IT Infrastructure Library (ITIL) promise to show IT how to run “like a business.” A well-implemented service catalog goes further and helps IT run as a business: clearer communication, easier access to IT services for business users, and continuous improvement driven by measurement. This paper offers guidelines for implementing a service catalog and describes what catalogs do for IT and the rest of the organization.
Why IT gets defensive
Most employees who depend on IT for their devices and applications know little about how those devices and applications work. As a result, they rarely appreciate how much the IT department does to keep the organization running.
That makes many IT departments reactive and defensive. They avoid new projects instead of seeing them as a chance to help the organization. Just meeting minimum business and productivity needs takes so much effort that IT services often end up defined by what the department doesn’t do rather than what it does.
ITIL and the Capability Maturity Model (CMM) promise to show IT how to operate like a business instead of as an overhead-heavy unit that under-delivers and undersells itself. But “like a business” is a loaded phrase. IT may adopt the trappings of a business, offering internal customers service levels and guarantees and following elaborate escalation procedures when delivery falters. Yet the effort stays euphemistic. IT departments do everything a business does but are rarely held to bottom-line results and rarely suffer for poor service.
That is changing. As enterprises depend more on IT, they expect IT to operate as a business. Services and their costs must be defined in plain business terms, be easier to order, and be delivered transparently instead of disappearing into the old “black hole.” The most basic services feel this pressure first. Employees will no longer wait a week for a desktop or for access to an application such as Salesforce, which only needs a license added. IT has to get faster and better, often without more resources.
What service catalogs do
- Fewer calls to the help desk, which improves service and satisfaction.
- Less routine work for departmental staff, who can spend more time on strategic projects.
- Automated tracking and documentation that meet compliance requirements and keep processes consistent.
- Online forms, knowledge bases and FAQs that keep employees current and cut paper, printing and distribution costs.
- One place to find forms, procedures and information.
- Complete, accessible information that helps employees make decisions.
- Metrics that reveal gaps in processes or documentation.
- Integration with the existing help desk system, which improves accuracy and the return on that system.
Service catalogs to the rescue?
Many people think service catalogs will save IT, especially the growing number of vendors selling them. The appeal is obvious. Most organizations give customers a list of products and services, a convenient way to order them, and the terms of delivery. Sophisticated businesses connect those processes to fulfillment and financial systems that automate order fulfillment and accounting. The data those systems collect is used to find bottlenecks, improve delivery, cut costs and personalize the customer experience. To run as a business, IT needs the same processes.
Yet many IT organizations take an unnecessarily complex and expensive route to a catalog. One reason is that they don’t realize how much of the work they already do. They don’t need an elaborate catalog application that forces them to re-engineer their operations.
Another reason is that they import traditional IT artifacts (service and operating level agreements, service definitions, service owners, master service lists) straight into the catalog. That limits how useful the catalog is to business users.
Start small and build
Many service catalog applications share traits beyond a hefty price. They are heavy on definitions and light on two things: workflow for managing service delivery inside IT, and a simple way for users to order services and track progress.
IT already performs the fulfillment work, though often manually and inefficiently. To implement a catalog, it needs to:
- Develop efficient, repeatable processes for fulfilling service requests.
- Publish the available services online.
- Connect what users do in the catalog to the back-end delivery processes.
That takes effort. But if IT starts with its four or five most requested services and plans to add more later, a simple catalog can go live quickly without a large software purchase or implementation project.
Improvements such as a lighter help desk workload show up quickly, and IT can redeploy the freed-up time into expanding the catalog. Catalogs that start modestly and grow can pay for their own expansion out of the savings they produce.
A better alternative to service level agreements
Service level agreements (SLAs) often hold up a catalog. They involve long negotiations with user groups and still end up as somewhat arbitrary numbers.
Twenty-four hours to restore a file seems reasonable to IT and to users, so that figure is accepted. The number doesn’t mean much, yet reconciling the expectations of many user groups can drag the process out for a long time.
Establishing SLAs is ultimately an effort to quantify what is already happening, and a catalog can measure it directly. A catalog records how long each type of request takes and calculates averages. From those figures IT can publish something far more meaningful to requesters than an SLA: a service level expectation (SLE), or how long IT has historically taken to deliver a service. Instead of an SLA of one week, users see that a request takes two days on average. Expectations rest on measured reality rather than conference room discussion, and IT gets a baseline for improvement.
SLEs won’t make SLAs and operational level agreements (OLAs) obsolete. Those are still needed to set minimum performance and to alert IT and business management when they are consistently missed. But SLEs reflect reality better than SLAs, and they can be set quickly for every service IT offers. They also:
- Speed up catalog implementation, because they are a quick, cheap and accurate measure of delivery times.
- Give users a realistic idea of when a request will be fulfilled, and give service owners the data to spot problems, target improvements and show results.
- Give IT measured data for cutting costs and improving efficiency. You can’t improve what you can’t measure.
The user’s view
With SLEs, a catalog can show requesters three numbers for each service:
- The SLA for the service (for example, seven days)
- The current SLE (for example, over the past 30 days, 75 percent of requests were fulfilled in under two days)
- The current satisfaction rating from all users of that service
Users request the service through the catalog and, after delivery, get an email asking them to rate it. Most catalog and survey tools can do this today. It is a far better experience than long “standard” service definitions, SLAs without context, and instructions for requesting the service offline.
How service catalogs will change IT
Catalogs reduce costs, shorten delivery times and improve service quality. A well-implemented catalog can also change how IT is seen inside the organization.
IT will start marketing its services
As catalogs simplify request and delivery, IT will welcome new projects and promote its services to specific groups of internal users. That is a major shift. Users will see IT less as an unresponsive cost center and more as a partner to the business.
Catalogs will put IT back in control
Impatience with the pace of IT projects has led many large organizations to hire outside consultants and contractors, and IT often loses control of technology services and infrastructure as a result. Projects become ends in themselves and lose sight of business objectives.
Identifying key services and standardizing how they are delivered lets IT respond faster, take on more responsibility, build business-focused skills and depend less on outsourcing for strategic projects.
The service owner role will change
IT roles have been highly technical and specialized. Catalogs will make service ownership more business-focused, so service owners will need business skills as well as technical ones. They will use reporting to see who should be using their services, send those people information, and teach all users more about what an application can do.
People will “go to the catalog” less often
Today the catalog is a separate place. Current applications already support useful catalogs, with short, tailored definitions, easy request forms and traceable processes. But users still have to stop what they are doing and visit a separate website to ask for something.
Relevant catalog pages will be embedded in the applications people already use, so they can request a service without leaving their work. In an organization that runs SAP, a user who needs a product code, account access or a restored order (all typical SAP requests) will click a link inside SAP that goes straight to the SAP service catalog page.
Many catalogs today resemble the old Sears “wish book”: huge, and describing nearly every service the IT group offers. IT will instead offer dozens or hundreds of specialized catalogs embedded in specific applications (such as SAP), functional areas (such as web services) or departmental applications (such as HR services in HR software). Requests will happen where the service is needed, without wading through irrelevant information. People will go to the catalog less often even as they make more catalog requests.
Putting the catalog together
Simple and actionable beats complex and slow
The most important element of an actionable catalog is breaking each request into finite tasks that can be finished quickly. An overly complex catalog frustrates users. They start going around it through informal channels, and then measuring and improving service becomes nearly impossible.
Use measurement tools
Many tools measure the usability and effectiveness of web applications. A catalog is a web application, so the same tools apply.
Don’t over-define
Some catalogs spend far too much space on service definitions. “Standard” definitions are often too generic to mean anything to a user with a specific need. Worse, some catalog tools have no online request capability at all; they are repositories of definitions with offline ordering instructions. A static list of services meets the ITIL requirement but has little value to the organization.
Good catalogs make it easy to request a service and track its status, while standardizing and automating the fulfillment work behind it.
Avoid prebuilt service content
This runs against the industry, where many vendors focus on prebuilt service definitions and SLAs. But every company has its own communication and delivery needs, and one-size-fits-all content rarely fits anyone well. Prebuilt content that forces arbitrary process changes has little value and can do harm. Define your own services and SLAs.
Start with a few discrete, easily defined services, and choose software that makes it simple to add more over time. That avoids the problems of prebuilt content.
Aim to go live within a month
The technology is mature and the concept well understood, so IT no longer needs to reinvent the wheel. Off-the-shelf software provides what once had to be custom built.
Many IT organizations now skip the “big bang” approach. They know a useful catalog doesn’t need hundreds of services. Some start with as few as five commonly requested items, which delivers value quickly and earns support for the next phase. Adding groups of five to 20 items at a time, until every standard IT service is in the catalog, keeps the momentum going.
Start small and think big. That is how most successful businesses begin, and it is the best advice for IT organizations building a service catalog.
About the author
John Sundberg founded Kinetic Data and was its president when he wrote this paper. Over two decades of designing and managing information system implementations, he had been lead architect, developer or project manager on more than 100 projects for medium and large enterprises, with extensive work in large systems, distributed systems, systems management and consulting.
Before founding Kinetic Data, Sundberg worked at 3M, Programming Alternatives, Inc. and Wilson Learning, and as an independent consultant. At 3M he was a liaison between IT and several development groups. There he saw why projects succeeded or failed, and noticed that groups who worked well together produced successful projects. That observation shaped how he built the company. At the time of writing he was president of the Minnesota chapter of AFSMI (Association for Services Management International).