Forrester recently published “IT Service Management (ITSM) Case Study: Making The Transition From On Premises To SaaS With BMC” which is available to clients here. For non-clients (or hopefully “future clients”) I thought I’d create a blog on the good practices distilled from the discussion with the BMC client.

The situation … does it sound familiar?

The customer had found itself hamstrung by a highly customized on-premises ITSM tool that was: 1) too costly to run; 2) a poor fit to operational and customer requirements; 3) complicated and cumbersome to use; 4) unable to keep pace with the latest service management thinking; and 5) stranded on an out-of-date version because it would cost too much to upgrade.

The solution …

The customer used a honed set of requirements to select BMC Remedyforce from a shortlist of six SaaS ITSM offerings. In their words, they chose BMC Remedyforce because: 1) it was best suited to the agency's existing and future needs; 2) it was built on the salesforce.com platform; 3) its user experience was similar to (but better than that of) the incumbent Service Desk Express; and 4) it was the most cost effective.

Here's what they did:

• The initial deployment managed requests and tasks from both customers and internal IT.
• The customer took advantage of subscription-based licensing's ability to flex with demand.
• They also used BMC Remedyforce in different scenarios: in internally and externally facing call centers and, in addition to traditional IT support, addressing customer support, app development issues, and human resources (HR).

Remedyforce also met the organization's expectations of an online, open, and flexible tool.

Lessons learned: the dos and don’ts

The customer decided to Focus On Near-Term Business Requirements and:

1. Refused to include a long list of theoretical ITIL-based requirements in its RFP.
2. Achieved consensus among business stakeholders on a short list of core capabilities.

They also decided to Not Force The New SaaS Solution Into The Old On-Premises Tool's Box and as such aimed to learn from previous mistakes:

1. Keep the bigger picture for the SaaS-based ITSM tool front and center.
2. Configure rather than customize.
3. Avoid the common mistake of modeling the new tool in the image of the old tool.
4. Leave the (poor-quality) old data behind.
5. Don't go for a big bang approach to the new process enablement.

And finally some recommendations from me …

For a SaaS tool to truly be successful, IT or ITSM professionals need to:

1. Understand all of the reasons for wanting or needing a new ITSM tool. This means both looking back and looking forward, as well as being honest about the incumbent tool and its use.
2. Learn from previous tool purchases and implementations. Organizations often have issues not with tools themselves, but rather with how they were implemented and used — these are people rather than technology issues.
3. Invest only in a true SaaS solution. If you have chosen the SaaS model, ensure that the SaaS tool delivers not only against the required functional capabilities, but also against key nonfunctional capabilities related to SaaS.
4. Adopt the new tool at the right pace for the organization. Stretching beyond the IT organization's existing ITSM maturity capabilities is the equivalent of doing two things badly rather than one thing well.
5. Ensure that tool requirements allow for future growth. Plan beyond the tool implementation project and don't think just in terms of internal improvement initiatives, but also about how the vendor can provide support to improve service management maturity by adding new functional capabilities or providing better availability or capacity management.

So there you have it. A quick blog offering commonsense advice that sometimes isn’t as common as it should be. I hope it helps and, as always, I'm interested in your comments and thoughts.

Want to know more about SaaS ITSM Tools? Try this.