The technical architecture of a business service catalog or enterprise request management (ERM) implementation encompasses a system of engagement (user interface), systems of record (underlying ITSM, ERP and other enterprise platforms) and an orchestration engine to manage communication between systems, as well as reporting and analytics tools to help manage and optimize service fulfillment.
Part one of this blog series defined the business service catalog; part 2 detailed the benefits of taking the service catalog beyond IT. This post defines system architecture based on an organization’s current request management maturity level.
In the Forrester Research white paper Master the Service Catalog Solution Landscape in 2013, authors Eveline Oehrlich and Courtney Bartlett define three levels of service catalog maturity. At the most basic level, organizations are focused on “delivering IT services to consumers through a standard set of choices and/or requests.”
At level two, the service catalog automates enterprise services, and at level three it acts as a “service broker.” The ERM concept operates at the intersection of these levels. For example, new employee onboarding is a process—but one that includes much more than just IT services (important as those are), also invoking required services from human resources, accounting, facilities, office management and potentially other functional groups.
According to Forrester, the highest level service catalog architecture comprises the demand side from the business and the supply side capabilities of IT (and other functions and departments). The “demand side” component is defined as “the highest level of the service catalog. It’s the front end, the portal, or the menu that presents only services that solve business user problems…It should be simple, intuitive, and in layman’s terms–too much detail complicates user experience. Less is more.”
That definition correlates nicely with the description of the ideal ERM front end: simple and intuitive (so it requires no training to use), web-based (so it’s accessible anytime, anywhere, from any device), and comprehensive (so it provides “one-stop shopping” for enterprise services, regardless of the department[s] responsible for service fulfillment).
Among the four components that comprise the “middle level” of the service catalog architecture are consumers of the service catalog and interfaces. It should be noted here that the “interface” need not be identical for all users. That is, while the fundamental look and feel is consistent, users can be presented with different service item choices based on their login (e.g., line employees can’t requisition a new hire; sales and other employees who spend a great deal of time traveling may be presented with different hardware options than those who work primarily in an office; etc.).
Finally, among the components of the “lower level service catalog” architecture is “integration with IT systems and business applications.” This is where an orchestration engine, or workflow automation software fits. It eliminates the need for redundant manual data entry into multiple systems by passing information securely as needed between different enterprise software systems and automating tasks such as management approvals and resource scheduling.
Oehrlich and Bartlett conclude that “In the future, the term ‘service catalog’ may be rendered obsolete, as a service catalog initiative is so much more than just a catalog—it’s the management of the life cycle of various services demanded and consumed by the business users.” This is achieved by an ERM strategy: business users get the intuitive service request, status tracking, and personalization of a site like Amazon.com, within the context of enterprise business service management.
For more on this topic:
- Join the discussion in the Enterprise Request Management Group on LinkedIn.
Cassy Lueneburg