Service Management Software Selection

Objective

Our client works in Mechanical Services Field Service and had worked closely with their Service Management Software vendor for many years. They had paid for many changes to the core product, which were specifically aimed at market distinction.

Unfortunately, their Service Software vendor wanted to move away from an on-premise model to a cloud-based offering. In order to do this, they had decided to completely re-write the software and only going to include generic functionality. And, of course, some of the functions they would NOT be including were most of the additions that our client had previously paid for.

Our client had two options – either pay the vendor a second time for the original changes, in order to include them into the new core software; or find a new Service Management software package. They engaged us to… HELP! In other words, they asked us to help them find the best software solution for their Service Management business.

Solution Delivery

• This project didn’t start with System Selection. Our client really didn’t want to change software – they LOVED their current software and the Field Service App. It did everything they wanted to it to do. So, they initially asked us to help them negotiate with their current vendor. They first wanted a definitive list of what they would and wouldn’t get with the new software functionality. Second, they wanted to ask their vendor to include their prior changes without paying for them again. The vendor wouldn’t provide any documentation or functionality guarantees. They did, however, agree to let our client review a version of the new software. This only happened once the new software had developed to a point where it was “user-friendly”.
• All the way through the discussions, our client was confident that the vendor would meet their needs. They had been one of the vendors most positive, high-spending and loyal clients for years, so they thought this was a reasonable assumption.
• This positive belief lasted until our client reviewed the new version of the software. They were told that this version would be Phase 1. Timing and inclusion of later changes was to be determined in the future. Unfortunately, Phase 1 only included around 40% of the functionality they currently used and needed, even when they excluded their prior paid changed.
• The project very quickly changed into a Service Management Software selection project. We were able to put together a Functional Requirements list, due to our in depth knowledge of the business. The National Service Manager then reviewed the Functional Requirements list and made changes where needed. More importantly, he ranked the requirements in terms of importance to the business. He was very clear that he didn’t want to lose the functions and processes that they felt gave them market distinction.
• We did some research and came up with a Long List of 24 vendors. We then qualified that list further by doing some high level checks based on whether they could integrate to our client’s ERP; whether they covered basic functionality needed; and critically, whether what they called “Service Management Software” had the same definition as our client perceived it. These checks enabled us to cull the Long List down to nine vendors, one of which was their current ERP provider.
• Once we made contact with each of the nine qualified Vendors, we sent them the Functional Requirements List. We asked them to provide a pre-determined value against each of the items. This value indicated whether the requirement was core functionality; if it could be added as a customisation; or if it simply wasn’t possible to achieve.
• The responses back from the vendors were very interesting to read! There were some vendors, who we had all thought would be a great fit, who point blank refused to consider some of the more distinctive requirements. One vendor replied to these key requirements with comments of “Why would you do that? Your process to do this bad, out of date and should be modernised.” The National Service Manager thought the comments were very insulting, particularly since he was very aware of the pros and cons of their process. He immediately removed the vendor from consideration, even though that vendor had previously seemed like they would be a serious prospect.
• All the functional response rankings were populated, by Vendor, into our Assessment template. From here, it was possible for our client to see that only four of the vendors had % fit to their needs of over 90%. One of these vendors was the vendor excluded due to their disparaging comments regarding key requirements, so this immediately reduced the list to three vendors.
• We then contacted the vendors with more detail regarding the client requirements and arranged for software demonstrations. A successful vendor was chosen from the final three.

Achievements

• The requirements of this project changed quite significantly over its life – from working with the incumbent vendor, to leading the client onto the path of software change. We navigated these changes with the client, giving them advice based on their needs and not the vendor needs.
• We maintained a level of impartiality throughout the process, using it to help our client move beyond personal reactions when they were disappointed by vendors.
• The process gave our client to deal with the short-listed vendors and ultimately choose the right service software package for the growing business.

If you’d like to learn more about this project or talk to us, click here for our contact details.