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.
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:
- Download the white paper Enterprise Request Management: An Overview.
- Join the discussion in the Enterprise Request Management Group on LinkedIn.
Cassy Lueneburg