Implement Enterprise Request Management in Five Straightforward Steps

 This article has been contributed by John Sundberg, Co-founder and President of Kinetic Data.

John Sundberg
John Sundberg

A new approach to service request management is gaining ground in companies around the globe. Called Enterprise Request Management, or ERM, this framework is finding favor with organizations because it allows them to take an incremental and evolutionary approach to centralizing and modifying business processes and service requests across the company.

ERM operates at the intersection of the three levels of IT service catalog maturity identified by Forrester Research:

  • Level one – organizations focused on “delivering IT services to consumers through a standard set of choices and/or requests”
  • Level two – service catalog automating enterprise services
  • Level three – service catalog acting as a “service broker”

Let’s take a look at five steps involved in implementing ERM:

  1. Design your business process;
  2. Involve your stakeholders;
  3. Identify gaps in technology;
  4. Test the processes; and
  5. Refine and build onto the processes.

Design Your Business Process

Every business has request fulfillment processes that employees would love to improve, whether it’s as simple as resetting a password or as complex as onboarding new employees. The first step is to identify and prioritize improvements in these processes in terms of what is both realistically achievable and what has the greatest impact on user satisfaction.

Next, break the process down into discrete tasks. What task is the easiest to improve in the shortest amount of time? Start there before proceeding to tackle the more vexing tasks.

Look at what types of phone calls are overburdening your IT service desk. Are most of them for password resets or are users having problems with software installs? Also, look at which other departments have common support request issues, like paid time off requests in the human resources department, or conference room reservations in the facilities department.

With a service request portal and a back-end process automation tool, ERM provides a simple solution to these types of calls. With an online self-service request portal, users can log and track common service requests themselves while the “back-end” system manages the approval and fulfillment workflow of the request.

It doesn’t stop there, however. The flexible and extensible design of ERM allows you to add more (and more complex) types of requests over time.

ERM is designed to automate most, if not all, of the tasks within the service request management lifecycle – including centralized request management, scheduling, approvals, analytics, Service Level Agreement (SLA) tracking, status, charge back, billing and reporting – by linking to and coordinating with the software systems enterprises already have in place (systems of record) to handle these tasks.

Involve Your Stakeholders

With ERM, fulfillment processes are customer-centric. In other words, they’re designed from the customer’s perspective rather than from what appears to be the most convenient or logical approach for internal service providers.

So, it’s important to involve the appropriate stakeholders by assembling a small project team consisting of a business analyst, a developer, the “owner” of the process, a representative from management, and, most importantly, the users themselves, who can articulate the desired outcome in their own terms.

Keeping the team relatively small is important, since larger teams are more bureaucratic and take longer to get things done.

By keeping an open dialogue, users will be accepting of — and possibly even eager for — the changes that ERM will facilitate in simplifying complicated or broken request fulfillment processes.

Identify Gaps in Technology

As with any project, it helps to take one step at a time. Don’t get mired in the current state of your technology or existing processes, which can be a recipe for inaction. Often you’ll find that if you “think small” by breaking processes down into realistically achievable goals and by building on the momentum from these small victories, your current technology may not be as inadequate as you first thought.

However, frequently new front-end “systems of engagement” and flexible process automation tools may be needed. But make sure they’re designed to interact with back-end systems of record with little or no modification.

Test the Processes

With the ERM approach, it’s easy to create and test processes with very little risk because the core programming code doesn’t get modified. Feel free to make changes as needed and then test again. Once the process is concrete, is can be cloned and modified for other similar needs.

Refine and Build Onto the Processes

With ERM, the best approach is an evolutionary one. Start with the low-hanging fruit — the broken processes that have the greatest impact on customers. Work from these successes and the experiences gained, and then expand efforts wider and deeper into other request fulfillment processes.

After making any desired adjustments, deploy a more efficient way of fulfilling requests by using ERM and determine the next processes that need to be fixed. By learning, iterating and improving, ERM can easily move out of IT and unify service request fulfillment across your organization.

As you can see, the benefits and ease of ERM simply are too good to pass up. After all, who wouldn’t want lower service delivery costs and happier customers? So, wait no longer – now is the time for your organization to join the ranks of those realizing the benefits of ERM:

  • An improved user experience
  • Centralization of business services
  • First-time and automated fulfillment
  • Leveraging of existing systems.

Regardless of your organization’s level of request management maturity, you’ll find that ERM is the “glue” that unifies service request fulfillment across your enterprise. You can learn more about ERM here. 

The ITSM Review are holding a series of seminars this year headed by ITSM superstar Barclay Rae. We will be starting in March with Transforming User Experience – Enterprise Service Management & Self Service. For more information click here

Stephen Mann – ITSM Tool Verification: A Good Or Bad Thing?

ITSM Tool Certifications - Good or Bad Thing? What is your view?

This article has been contributed by Stephen Mann, Senior Analyst at Forrester Research.

I recently stumbled upon the fact that Pink Elephant had introduced a new PinkVERIFY “version,” PinkVERIFY 2011, I assume to move into line with ITIL 2011.

It reminded me that I still owed the IT Service Management (ITSM) Community a blog on such ITSM tool verification or certification schemes based on my own thinking and some quick-and-dirty analysis I did at the start of 2012.

I ran two polls – one I pushed out to 20 ITSM tool vendors and the other I made available to ITSM tool customers via a Forrester blog (“How Do You Value IT Service Management Tool Verification Or Certification Schemes?”).

A Summary of Vendor Responses: 

Firstly, please be advised that this was an unscientific, quick-and-dirty ITSM tool vendor survey and the results should be treated as such. I am just trying to “paint a picture” rather than be precise with a certain degree of accuracy. Of the 13 ITSM tool vendor respondents (2 could not help, 5 didn’t reply):

  1. 10/13 either have, or are planning to get, the latest PinkVERIFY endorsement (this was 3.1 back then). The other 3 all have a previous version of PinkVERIFY and consider it adequate (for now).
  2. Most have seen an increase in RFPs asking for PinkVERIFY (or similar) endorsement, particularly in Europe and North America – the larger the prospect, the more chance there is that they will ask for PinkVERIFY or similar.
  3. In terms of not having PinkVERIFY (or an alternative) being a barrier to shortlist, the consensus was that not having it definitely doesn’t help (Of all the questions answered this was the most vague).
  4. 7/13 of the respondents felt the version of PinkVERIFY certification held to be irrelevant – that RFPs just ask if the product is endorsed and then move on.
  5. All vendors still see PinkVERIFY as the de facto certification/endorsement scheme; with the OGC scheme having greatest traction in the UK and consequently appearing most in UK RFPs.

Customer poll feedback

It was a low response rate (77 responses versus 2000+ blog reads after a month):

As you can see, only 8% would not consider an ITSM tool that does not have an independent verification. In my opinion I think this is great – I expected it to be much higher. Although, from the vendor feedback, most prospective customers still ask for independent verification of some sort in RFP/RFIs. Hopefully customers are not using the lack of it as a barrier to entry.

At the other extreme, 35% place little value in a tool having the “stamp of approval.” Perhaps this is biased by the type of people that generally read my blog? I imagine that if this poll had been publicized via more traditional means this would have been considerably lower.

However, the main headline for me is that ¾ of respondents (thankfully) perceive ITSM tool verification to be a “lesser element” of the overall tool selection process; with just ¼ seeing it as a key part or its absence a deal breaker.

And thus my conclusions …

Whether it is for the right or the wrong reasons, ITSM vendors think that some form of product verification is needed to put a proverbial “tick-in-the-box” to the RFP question around certification. I can’t help think that certification is seen as a “necessary evil” by some and as a good marketing investment by others. The verification itself is not evil – one would like to think that it is purely intended to help organizations with ITSM tool selection – but does it really help? Does certification help find the perfect tool for a not-so-perfect organization? I personally think not, at least not in its current guise (or the popular perception of its current guise).

Such certifications are merely an MOT test (Wikipedia: an annual test of automobile safety, roadworthiness aspects and exhaust emissions required for most vehicles over three years old used on public roads in the United Kingdom) for ITSM tools rather than a robust mechanism for ITSM tool selection. And if the vendor feedback is indicative it is merely the waving of a piece of mandatory paper rather than showing that a tool is “fit-for-purpose” as of right now.

To me the “popularity” of such schemes (and the way that they are currently used) raises a number of thoughts/questions:

  • I have to question what is driving the demand for verification in RFPs: is it ill-informed purchasing functions or ill-informed ITSMers? This definitely needs further analysis. The customer poll response says otherwise (again please note the perceived bias assumed on my part) but maybe it is a little too much of “no one was ever sacked for buying Microsoft/IBM/etc.”
  • Does anyone ever fail verification/certification? I hope that some do at least to give some semblance of reliability and credibility to such schemes. In the case of PinkVERIFY shouldn’t failed certifications also be listed on the Pink Elephant website? At least the OGC shows a few failures have happened BUT without naming names
  • Maybe the real value is in focusing on the differentiators? Is the number of processes verified an indicator of the tool’s capabilities or of the vendor’s marketing budget? Should it focus more on the uncommon processes? Or newer processes? At least some form of process differentiation (at a glance) would allow prospective buyers to step back from the fact that it is 10 verified processes to see which they really need to be supported. Customers should also be educated in the fact that more verified processes doesn’t mean it is a better tool (as the listing by process numbers suggests).
  • Ultimately, the ITSM community needs better educating in the value and use of, and the differences between, certification schemes such as PinkVERIFY and OGC endorsement. BUT, before this, there is still that bigger education need – that of understanding that the current method of creating RFPs and selecting vendors based on a cut-and-paste, ask-for-everything-possible-mentality is so, so flawed. I eventually hope to address this is in a formal piece of work, Forrester willing.

So that’s my 2 cents on ITSM tool verification. How about depositing yours with the Bank of ITSM Review?

This article has been contributed by Stephen Mann, Senior Analyst at Forrester Research.