Service Catalogs are NOT IT Software – They are Business Software

When you are standing at the base of a mountain, it’s usually impossible to see the true peak. You will see “a” peak in front of you, but upon reaching that summit, you’ll see another “peak” higher up, and upon scaling that one, another…until eventually, you reach an elevation from which you can see the actual top of the mountain.

You must reach the first mountain peak to see the next
Photo credit: Steve Maniam

So it is with service catalogs. They were originally defined in ITIL as “an exhaustive list of IT services that an organization provides or offers to its employees or customers.” According to Wikipedia, each service item within an IT service catalog typically includes:

  • A description of the service
  • A categorization or service type
  • Any supporting or underpinning services
  • Timeframes or service level agreement for fulfilling the service
  • Who is entitled to request/view the service
  • Costs (if any)
  • How to request the service and how its delivery is fulfilled
  • Escalation points and key contacts
  • Hours of service availability

While that’s a useful list, notice that none of these bullet points necessarily describe attributes of only IT services; a service description, timeframes, costs, etc. just as readily apply to services from human resources (e.g., a PTO request), facilities (e.g, reserving a meeting room), finance, marketing, or any other internal shared services group.

Service catalogs are still often thought of as “IT software” because that is the way most vendors have viewed them, built them, and sold them. They only see the first “peak” near the base of the mountain, and that’s all they show to customers.

Once those customers reach the first peak, however, they are able to “see higher up the mountain”—but the software they’ve invested in isn’t designed to let them climb any higher.

The result is that service catalogs are used only in IT. Other functional groups (HR, facilities, finance, etc.) each have their own systems and processes for handling requests. The onus is thus on employees to determine which department (or departments, in the case of complex requests) are responsible for service request fulfillment, which systems and processes to therefore use, and how to use each system or process—as well as to “manage” their request from initiation through fulfillment.

There is a better approach, both in terms of improving the user experience and in reducing cross-departmental service delivery costs. Take the service catalog concept to the next peak (and the next, and the next). View it as business software, not just IT software.

Forrester Research recommends rethinking the IT service catalog “as  a higher-level entity called the business service catalog.” In the enterprise request management (ERM) approach, employees have one single, intuitive, web-based portal for ordering any type of business shared service. Users have one simple system for initiating and monitoring the status of requests, with no need to understand all of the departments, approvals and processes involved. Enterprises get increased first-time fulfillment, time and cost savings, and visibility into actual service levels and delivery times.

Don’t let anyone limit your vision. You’ve got higher peaks to conquer.

To learn more:

10 Key Benefits of a Business Service Catalog: Forrester Research, Part 2

Forward-thinking IT organizations have embraced service catalogs as means to enable self-service and reap the attendant cost savings. Business users—whether remote or on-site—can request services from a standard set of IT offerings (e.g., password reset, new laptop, application access) and view the status of any previous request, all without a costly call to the help desk.

Business Service CatalogAt a high level, service catalogs reduce the time and cost of delivering technical services while improving the user experience. These and the other benefits of service catalogs needn’t be limited to the provision of IT services however; an expanded view of the service catalog to encompass all shared services groups in the organization (e.g., HR, finance, facilities, etc.) extends the cost savings of service catalogs while also providing employees with a single, intuitive interface for requesting any type of enterprise service.

The Forrester Research white paper Master the Service Catalog Solution Landscape in 2013 identifies a number of reasons for undertaking such a business service catalog effort, as well as the benefits to be gained from the initiative, such as that business service catalogs:

Facilitate self-help. Shifting service and support “to the left” (even to level 0) not only saves money, but in many cases accelerates issue resolution and creates a more positive user experience. Forrester notes the value of “implementing a self-service capability where business users can log their own incidents (and) check on the progress of those incidents.” This isn’t limited to IT support requests though; users should be able to check the status of any type of business service request online, and such self-service can lead to significant cost savings.

Centralize request management. A key benefit of this approach is “one-stop shopping” for business users; there’s no need to learn and use separate systems in order to request services from finance, IT, HT, facilities or other groups.

Simplify the user experience. Users don’t care what happens behind the scenes, they just want their request fulfilled.

Enable agile business processes.

Support IT governance. “End-to-end process governing and tracking the way assets enter and exist in the organization are essential to achieve the highest return on investment (ROI) for the lowest cost. One vendor stated that IT governance is imperative because you ‘must have a way to manage and document things,’ and service offerings within the service catalog are a means to do this.” Proper IT governance and risk management not only reduce costs but also support business growth.

Inspire business process improvement. Forrester calls “the need to map business capabilities to business services…perhaps the most important need and reason for service catalogs…Business service catalogs are top-down capabilities that describe and define IT”s deliverables from a business perspective.” In other words, the implementation of request management forces teams to take a critical look at current processes and encourages redesign based on the goal of a delighted (internal or external) customer.

Help standardize offerings and improve efficiency.

Provide end-to-end visibility into the value chain. “When the service catalog is not just an accessible front end but also automated and integrated with a variety of IT processes…IT operations teams are able to monitor, manage, and report on requests from start to finish. A service request from a business user sets off a value chain that can be tracked within the entire IT organization, from the ‘storefront’ request initiation to product delivery or fulfillment.” Indeed, a key element of the enterprise request management (ERM) strategy is the integrated analytics, which enable accurate costing, reporting on both quantitative (e.g., elapsed time) and qualitative (user satisfaction) metrics,  and continuous process improvement.

Reduce service costs. Forrester notes that globally, help ticket volumes are increasing–not only because of business growth, but also due to an increasingly mobile workforce. According to the white paper, “Forrester Research data shows a growth from 15% to 29% in U.S. and European information workers working anytime and anywhere. Inserting a service catalog that allows this mobile workforce to receive, manage,  and consume business and IT services will…reduce the cost of the service support team.”

Increase user satisfaction. “Customer experience is more than just closing tickets. Establishing a single place for your business users to go where they can request and receive services from either a business team or IT has immediate impact on customer satisfaction and customer experience.” Indeed, a key goal of implementing a business service catalog within an ERM initiative is to not only cut costs but also delight users.

What could go wrong? Forrester also warns about common inhibitors to BT success, including lack of clear purpose; improper tools; lack of ownership (“Ownership leads itself to accountability and pride, two key ingredients for success”); and lack of executive buy in.

Part one of this series defined the business service catalog concept, and part three will address request management architecture.

For more information about the benefits of business service catalogs:

What is this “Level 0” thing? (Part 2): Knowledge, Self-Analysis and Feedback

Tools of the Trade (Part 2)

A Vision From Down Under
By Michael Poole

In my last blog, I mentioned a major client who is ‘shifting to the left’ and implementing ‘Level 0’ methods.

For those who missed my last blog, in short, ‘Level 0’ is the process of enabling users to resolve their own incidents and requests.

Obviously, one way of implementing ‘Level 0’ is to shut off the phone lines and email addresses of the Help Desk. A very effective way of getting users involved in the process, but not one I would recommend to anyone wanting a long future in an organisation. Of course, sometimes we implement this method by under-resourcing our support teams – but that is the subject for another blog.

To implement ‘Level 0’, users have to have the information available to them to resolve issues as they arise. So how do we give these to them.

There are a number of tools available.

The Knowledge

It has been famed around the world that London cabbies spend years “doing the knowledge” — learning every street, lane, theatre, hospital and pub in London — before they can sit for the exam to obtain a cab licence. Do we need to ensure that before any person joins the organisation they have an intimate knowledge of computer hardware, software, networking etc.?

No, because now, they can be like today’s Sydney cabbies who avoid “the knowledge” by having a SatNav or GPS system in the cab. Our users’ SatNav can be a Knowledge Base.

The move to implementing “KCS” or Knowledge Centred Support has been going for a number of years, but for many organisations, this has been limited to building knowledge bases directed at and only available to the support team — not the user. With the development of Web 2.0+, users are becoming more accustomed to “googling” for solutions and answers and also using self-help resources that are a part of the major social media sites. I admit, in doing these blogs, I have often consulted the blog site’s help pages and Support Forums.

So KCS is one of the tools that can be deployed as part of the “shift to the left.” But to do this, we have to make sure that we develop our KCS articles, not for computer engineers, or if we are deploying across an enterprise , HR experts or accountants etc, but for the average user and common issues.

Self-analysis

No, I’m not becoming Tony Robbins — all “SHAMish” (Self Help and Actualisation Movement) — perish the thought — or bringing Freud onto the Help Desk — even though at times he might be useful in dealing with users, but more IKEA!

The results of some IKEA assembly projects might belie the concept — but I assume that they have more successes than failures through the step-by-step self-assembly process.

A few — well maybe many — years ago, I was involved in a project that required me to have what is called an “Assumed Rank” in the Australian Armed Services. I made Colonel for a month — the duration of the contract — but thankfully did not have to do the physical, wear a drab khaki uniform, bear arms or be saluted. But I did get into the Officers’ Mess and people had to answer my questions in a respectful way, but that is past. What I did get to find out was how the most complex maintenance and repair processes for a fighter jet could be broken down into simple steps and documented so that even I could have replaced, as an instance, the wiring loom on an F-111 or the laser-guidance system. The “repair manual” — and it was all hard-copy — was contained in a room-full of filing cabinets and needed a librarian to keep it in order and up-to-date. This of course was an extension of the production line methodology introduced by Henry Ford at his eponymous company to make the most complex consumer engineering  product of the day — the motor car — with relatively unskilled workers. Other car makers of the time were using skilled engineers and coach-makers to make one car at a time.

As the makers of the F-111 and Henry Ford knew, every process can be broken down to simple steps and delivered in an appropriate way to produce a complex result. For Ford this was a car; for General Dynamics it was the F-111 repair manual; for us this can be a fault-finding and resolution process.

In fact for the client mentioned above, we implemented such a system — a fault-finding process that enables staff with little or no technical knowledge to analyse and, in over 30% of cases, resolve issues with lap-tops ranging from OS to wireless network issues through a series of simple steps that relied on the answers to a number of questions and test activities that they could understand and carry out.

So another tool in the “Level 0” process, is intelligent and responsive self-analysis and resolution tools. What is sometimes called an “expert system.”

Information, Contribution, Monitoring & Feedback

Implementing “Level 0” also requires openness of information and a positive response to user feedback.

Users should be given every opportunity to be a part of the process.

Where KCS is implemented, users should be able to rate and suggest improvements to KCS articles and guides and also author and submit new KCS articles. As well as providing another source of input into the KCS system, users will develop a group ownership of the KCS system and its acceptance will be more easily gained.

This is also true of any self-analysis and resolution process. A network engineer may be able to define the step-by-step process for resetting a head-end switch, but it may take some input from an end-user to enunciate the process in easily understood vocabulary or point out areas that need better definition.

Users must also be contribute to the areas that need to be covered in the KCS or self-service system. What the experts think are trivial matters, may be a source of confusion to users.

Access to monitoring information in a easily understandable format can reduce calls on the Service Desk. If users know that a system is down for maintenance then they have no need to log a call.

And of course feedback to users is essential when they make a contribution or highlight an area that needs better coverage.

In part 3, I will look at ways to integrate these tools into web-based portals that can be deployed to users.

 

 

 

 

Why Self-Service Matters in Service Request Management

By Nancy Nafziger

In today’s competitive market, organizations are under pressure to provide visibility to the costs and benefits of existing and planned technology expenditures.

When considering technology, it is imperative for organizations to migrate to solutions that reduce the overall Total Cost of Ownership, (TCO). So what is essential for reducing TCO? Technologies that save time, reduce costs, reduce errors, and improve user satisfaction.

With that said, it is advantageous to consider technologies with self-provisioning features. Self-provisioning features have the power to reduce TCO. Let’s take a look at one technology that has made significant advances in self-provisioning—Service Request Management.

Leading Service Request Management solutions are automated and empower authorized users to self-provision their Requests. So how does this provide value? Self-provisioned Requests trigger a variety of automated processes that reduces time and eliminates errors. The lack of automation loads organizations with increased costs, security issues, and provisioning errors. Automating request fulfillment eliminates hours of staff time that was previously spent manually responding to requests.

In addition to reducing TCO, other self-provisioning benefits in Request Management include:

  • Enables process owners to have full control of managing their processes
  • Reduces support costs
  • Enables compliance with governance audit and reporting requirements
  • Empowers users with fast-response access to critical business services
  • Improves user satisfaction through greater transparency and better management 

In summary, self-provisioning features in Service Request Management Solutions requests enable requests to be fulfilled more efficiently, faster, and at a lower cost.

 

 

Service Delivery Management Software Helps Construction Materials Producer Build Automated System for Processing Requests

Organization:
Producer of high-quality construction materials.

Challenge:
Replace manual process for handling and approving user requests for system and account access, set-up, and application changes with an automated system to eliminate lost approvals, inconsistent processes and lack of control, as well as to provide an audit trail for approvals.

Results:

  • Reduction in routine request fulfillment effort from 5 days to 1.4 days.
  • Electronic documentation provides audit trail for approvals.
  • Service Desk and local IT offices save approximately 50 hours each month sifting through paper.

At this environmentally responsible producer of high-quality construction materials, five regional locations supply aggregate-based materials and contracting services to a wide range of projects including both large, publicly financed infrastructure jobs and commercial and residential developments. In addition to crushed stone, sand, and gravel, the company produces ready-mixed concrete, asphalt, and concrete products. Some regions offer recycling, liquid asphalt, soil remediation and retailing operations.

To keep a large, multi-location company successful, it’s critical to have rock-solid core business processes that run like clockwork. That’s why the company’s end-user-services manager was concerned about inefficiencies in a manual, paper-based system for handling user requests for system, application, and account access and set-up.

While the IT Service Desk is based in its corporate office, the manager is responsible for the company’s desktop support and Service Desk operations, and managing three full-time Level-One people who support approximately 1,600 end users and 13 Level-Two desktop personnel who support all five regions. The manager explains his concern, “User frustration among all of our lines of business was growing as approvals were lost or delayed by days and fulfillment lagged far behind expectations. Part of the problem was due to incomplete original user request submissions, which required requests to be handled by multiple employees and rerouted for approval signatures. In the end, it took longer than expected to fulfill user requests.”

The manager estimates that this extra time added up to an average fulfillment cost of at least $300 or more for each request. There were added costs: training and retraining IT staff responsible for execution of requests; lost time for end users who were not able to perform job functions because of execution delays; and the reworking of requests. “The problem basically boils down to an inconsistent and poorly managed process that offered average control and lacked solid and consistent accountability and audit capability to support our Internal Control Systems (ICS) compliance efforts,” he says.

A whole new landscape with automation and accountability

Using Kinetic Request, the company replaced its manual user-request process with an automated system that provides uncompromising reliability and accountability. “The most noticeable improvements we’ve seen are that user requests are completed the same day instead of over several days, and instead of taking us 10 hours of processing/fulfillment time, we can normally handle a request in one day or less,” explains the manager.

The system prompts the user with questions that lead them to correct responses needed to fulfill the request, and immediately routes requests to the appropriate system approvers under ICS control. System Approvers find it quick and easy to locate, review and approve the requests. “We don’t lose time having to resubmit a request because the information is incomplete. Today, we are correctly capturing everything we need the first time. What’s more, the system captures and stores all approvals for audit trails,” he says.

In charge of training Service Desk employees on Kinetic Request, the end-user services manager observes how easy it is to learn and use. “It’s all there—the information that needs to be entered before the system sends it off to the right person(s) for approval. And it’s all captured. If there’s a glitch, we know where it is and can easily respond with the quick and proper solution. Kinetic Request is an amazing enhancement to our BMC Remedy system. That’s why we’re planning to leverage its power to automate our other key ICS controls, general IT requests, and maybe even other business functions.”

Facebook Has Taken Over the World

A Vision from Down Under
By Michael Poole

 

We hear this, even in the antipodes, so often and it may be true, especially for anyone under 40.

Why? Well, obviously it provides a way to communicate with friends and acquaintances; but it’s unlikely it would have been as successful if it had followed the design methods that can be found in too many corporate intranets.

One of Facebook’s major features is “consistency.” Consistent styling; consistent behavior; consistent look-and-feel.

Consistency is paramount to the success of all successful social networking sites. In fact, consistency is such a hallmark of these sites that ANY change to the design makes headlines or at least millions of wall posts!

If Facebook was like most corporate intranets, I doubt if users would have returned again and again.

The “public” internet sites of companies are owned and controlled by the marketing department whose whole purpose is attract visitors and ensure that the site is friendly, usable and informative. They usually follow the same design philosophy that has produced Facebook – consistency and ease of use.

Intranets, on the other hand, are usually owned by IT departments and the content is produced and published by individual departments with differing design (or non-design) skills.

Each department will often have a different set of design parameters and styles. Without a set of design guidelines that stress consistency and ease of use, the intranet can easily look like a “mash-up” – or perhaps a “mess-up” – of isolated intranet sites with jarring and confusing inconsistencies from page to page and area to area.

We have all experienced the corporate intranet that changes themes, banners, fonts for each department area. Intranets that use different layouts, even within department areas – some departments may have text links to some forms, buttons for others; one part of the site may work with IE9 – other parts need will not work with IE7; one might use bold, bright colors, another subdued pastels. The variations can be as many as there are contributors to the intranet site.

Rule one for a successful intranet

The intranet should look and behave in a consistent way. Having an intranet that changes its appearance and behavior between sections disorientates users and can introduce doubts into their minds as to whether or not all sections are as reliable and current as each other.

Of course, I can hear some of my readers saying: “Yes, we tried to do that, we had a theme designed, set standards for user interaction, had a template for all pages. We did all that but then we had to integrate a web-based application into the intranet and it all went bad. We could not change the way that application looked or worked, so we just had to compromise and accept it.”

So, many people, though trying to build in consistency into the intranet, are brought to a crashing halt by having to incorporate inflexible and inconsistent applications.

Why has this happened?

Let’s face it, most corporate applications have been around for some time. Many pre-date the internet and most certainly Web 2.0. They have been developed for dedicated user clients – some were even developed for dumb terminals. And when they produced the “web” version they did try for consistency – but it was consistency with the old, pre-web version. As a result, they produced clones of the old client down to the colors, key-strokes, layout etc.

With this design philosophy – consistency with the past – when they developed “new” functionality, they repeated the design errors of the past. And because in the past they had prescribed the layout, theme and style of the application, they did it again with the new functionality. As a result, application portals came so they fitted in with the parent application and not easily, if at all, styled to be consistent with the intranet they would be integrated into.

If you want a graphic (no pun intended) proof of this, look at the majority of ITSM application vendor’s web offerings – nearly all clones of the dedicated client interfaces of the past.

Should this be the way?

No.

The web is designed to be able to be styled and themed in very powerful ways giving developers the ability to produce interfaces and pages that can be easily integrated into any existing style or theme or to any device.

One way to do this is to use Cascading Style Sheets (CSS) to define the look and feel of an individual web page or a whole site.

This is the strategy that we have embraced when designing not just Kinetic Request forms but the whole Service Request Portal interface. We have empowered our clients to easily integrate both Kinetic Request forms and portals seamlessly into their existing intranets by leveraging the CSS definitions that they use for the rest of the intranet site. The result is CONSISTENCY – consistency of style, functionality and experience, and a reduction of confusion.

By putting the focus on enabling consistency of styling and functionality in the web interface to request management and fulfillment, our users have not had to compromise the consistency of the intranet. The payback is not only better customer satisfaction and better adoption by the users but also a reduction in costs of implementation, user support and training.

It is not the magic bullet – your intranet will never be as popular as Facebook and you will still have to battle to get HR to follow a design guideline – but having the power to enforce consistency is a major step along the way!