Enterprise System Spectator blog: ERP and enterprise system vendor evaluation, selection, and implementation.

The Enterprise System Spectator

Sunday, September 08, 2013

With SaaS, the Software is Not the Only Service Needed

Software-as-a-Service (SaaS) simplifies much of the complexity involved in implementing and using enterprise software. However, in consulting on several SaaS selection projects over the past two years, I've grown concerned that some SaaS providers may be neglecting some of the key elements of success for buyers.

(Please note, that in this post, I am not addressing the distinction between multi-tenant and single-tenant hosted systems. Although there are important differences, my concern about services transcends this distinction and applies to both.)

As the name implies, software-as-a-service (SaaS) turns software into a service. No longer does the buyer need to install software in its on-premises data centers. Nor does the buyer need to provide its own day-to-day internal support for maintaining and operating the application infrastructure. The entire system is delivered to users "as a service" by means of a network connection. 

But is the software the only service that SaaS buyers require? It doesn't matter whether it's SaaS or on-premise. These systems do not implement themselves. What about implementation services, such as project team training, help with prototyping, data migration, end-user training, acceptance testing and go-live support?

Moreover, once the company goes live on the new system, what about on-going support? Is there a help desk to deal with problems, such as system unavailability or response time? What if a bug is uncovered or a patch needs to be applied? Who does the buyer turn to when there are questions about how the system operates? Is there good up-to-date system documentation and training materials?

SaaS-Only Providers May Attempt Arms-Length Implementation Services

Over the years, I've noticed a distinct difference in the selling approach of what I call the SaaS-only providers versus traditional enterprise software vendors. The SaaS-only players, being 100% committed to the online model, attempt to move as much of the selling process online as possible. For low-end applications such as survey software or email marketing, they offer free trials with online conversion to the paid service. For mid-level or higher-end applications (think, accounting systems or ERP), they offer self-directed online demonstrations and perhaps some sort of limited trial use of the system. If at all possible, to minimize cost of sales, they attempt to close the deal on the web or over the phone with as little on-site selling as possible. All of these sales methods are good, and I'd like to see the traditional vendors move also in this direction.

The problem in my mind, however, is when vendors attempt to move their implementation services to this low-touch model. They try to use online computer-based training, web-based instructor-led training, and phone support, with as little on-site or personalized service as possible. This may work for lower-end applications, but when you move into those mid-level or higher-end applications, the customer can often be short-changed. It puts more responsibility on the buyer to organize its own resources for deployment.

This may work for some small companies, but not all. Some simply need more hand-holding.

Now, where I think the SaaS-only providers generally do a good job is in post-implementation services. Because these vendors are entirely web-based, they generally have good capabilities for ongoing support, such as self-help systems, user support communities, and web-based training. They also have much experience in migrating customers to new versions, which is far less painful than the upgrade cycles of traditional on-premises vendors.

Traditional Vendors and Channel Partners May Not Be Good at Post-Go-Live Support

The traditional vendors--and their channel partners--face the opposite problem. Their sales model has always been a high-touch model. They conduct face-to-face sales meetings and demonstrations. They bring services people into the process to help close the deal. They derive substantial revenue from implementation services, so they invest in those resources.

What happens when these vendors offer a "cloud" or "hosted" version of their systems? This is where the traditional vendors and their channel partners risk falling down. They can sell their systems as they always have, but now, what about post-implementation ongoing support? The software developer often doesn't want to get involved in the day-to-day management of their customers' systems, so they push that responsibility to their VARs. The VARs, in turn, often cannot afford to invest in their own data centers, so they turn to data center hosting partners to operate the system. This arrangement can work, but the result can be a complex relationship:
  • The software vendor develops and issues new releases new versions of the software
  • The hosting provider operates the customer's system. 
  • The VAR helps the customer implement the software and provides day-to-day ongoing support for the customer, such as help desk services and resolving any issues with the hosting provider. They also provide services when customers need periodic version upgrades.
The risk in this arrangement with largely with the VAR.  Their legacy is as implementation partners. Their experience is in projects. They come in, do a job, then leave. They do not have a culture of providing day-to-day support to their customers. Furthermore, these partners almost always have a mix of on-premises customers and hosted customers, with hosted customers forming a smaller or much-smaller percentage of business. They might have some help desk personnel to take calls, but they cannot dedicate technical resources just to the hosting customers. Rather they must use their implementation consultants when a customer has a routine problem. If the consultant who knows that customer's business is deep in the middle of another customer's go-live, the first customer's problem may go unresolved.

Most of the SaaS-only providers do not have this problem. They develop the system, they host the system, and they provide day-to-day ongoing support for the system, including version upgrades. If there is a partner involved, it is usually only for initial implementation or help rolling out new functionality.

What Should SaaS Buyers Do? 

Seeing that there can be problems with both the SaaS-only providers and the traditional providers offering hosted versions, how can buyers minimize their risks? I would suggest that more due diligence is needed beyond what software buyers perform for on-premises enterprise systems.

When considering SaaS-only providers:
  • In the sales presentation: observe whether the SaaS provider pushing an approach of mostly virtual services, claiming the system is so easy to implement that you don't require much help? If you are prepared to implement without much direct support, fine. Otherwise, you may be starved for resources when you most need them. 
  • In your reference checking, ask about the implementation experience. Who provided implementation services, the SaaS provider directly, or an implementation consulting firm? What type of support did they provide? Were their on-site services adequate? What do you wish you had done differently?
When considering traditional vendors with hosted offerings:
  • In the sales presentation: observe whether the vendor mostly talking about the software and implementation services, or are they giving sufficient time to talk about on-going support after the go-live? This may indicate they are still thinking of themselves primarily as sales and implementation services providers, not as ongoing support providers.
  • In your reference checking: ask about the day-to-day experience with ongoing support. Does the provider schedule a lot of downtime for maintenance? Is there much unscheduled downtime? Do you ever have problems getting the right person on the phone to resolve issues?
Of course, all these questions can be asked of all vendors. But you might consider a different emphasis depending on whether the vendor is a SaaS-only provider, or a traditional vendor with both on-premises and hosted offerings.

Finally, if it's not in the contract, it doesn't exist. Be sure all of your needs are reflected in the actual contract and associated statements of work. If you're not experienced with negotiating these, seek help. 

Related Posts

IT Services in a SaaS World

Labels: , , ,

by Frank Scavo, 9/08/2013 02:38:00 PM | permalink | e-mail this!

 Reader Comments:

We've seen a lot of companies drop the ball on support and training, and some companies that charge some pretty outrageous fees for training and setup help.

While we're just getting started, our main concern is nurturing our existing users first, and our new users as close seconds. We do the sales, then help with setup and implementation for free, and follow up with free training as required.

Beyond that, while we offer phone and email support, a feedback database for questions, and include embedded documentation where we also add video tutorials for those who just want to teach themselves.

We find that the greatest service we can render is always being available and quick to answer the needs of our users. That, plus the inherent simplicity of our platform, has allowed a higher than industry average adoption rate and high satisfaction rating from our users.

It's about being there during every step of the process and at all times.

Brad Hodson
Post a Comment

Links to this post:


Powered by Blogger

(c) 2002-2016, Frank Scavo.

Independent analysis of issues and trends in enterprise applications software and the strengths, weaknesses, advantages, and disadvantages of the vendors that provide them.

About the Enterprise System Spectator.

Frank Scavo Send tips, rumors, gossip, and feedback to Frank Scavo, at .

I'm interested in hearing about best practices, lessons learned, horror stories, and case studies of success or failure.

Selecting a new enterprise system can be a difficult decision. My consulting firm, Strativa, offers assistance that is independent and unbiased. For information on how we can help your organization make and carry out these decisions, write to me.

My IT research firm, Computer Economics provides metrics for IT management, such as IT spending and staffing benchmarks, ROI/TCO studies, outsourcing statistics, and more.

Go to latest postings

Search the Spectator!
Join over 1,700 subscribers on the Spectator email list!
Max. 1-2 times/month.
Easy one-click to unsubscribe anytime.

Follow me on Twitter
My RSS feed RSS News Feed

Computer Economics
ERP Support Staffing Ratios
Outsourcing Statistics
IT Spending and Staffing Benchmarks
IT Staffing Ratios
IT Management Best Practices
Worldwide Technology Trends
IT Salary Report

Get these headlines on your site, free!


2014 Best Independent ERP Blog - Winner

2013 Best ERP Writer - Winner

Alltop. We're kind of a big deal.
Constant Contact 2010 All Star Technobabble Top 100 Analyst Blogs

Key References
Strativa: Business strategy consulting, strategic planning
Strativa: IT strategy consulting
Strativa: Business process improvement, process mapping, consultants
Strativa: IT due diligence
Strativa: ERP software selection consulting and vendor evaluation
Strativa: CRM software selection consulting and vendor evaluation
Strativa: Project management consulting, change management
StreetWolf: Digital creative studio specializing in web, mobile and social applications
Enterprise IT News: diginomica

Spectator Archives
May 2002
June 2002
July 2002
August 2002
September 2002
October 2002
November 2002
December 2002
January 2003
February 2003
March 2003
April 2003
May 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
November 2008
December 2008
January 2009
February 2009
March 2009
April 2009
May 2009
June 2009
July 2009
August 2009
September 2009
October 2009
November 2009
December 2009
January 2010
February 2010
March 2010
April 2010
June 2010
July 2010
August 2010
September 2010
October 2010
November 2010
December 2010
January 2011
February 2011
March 2011
April 2011
May 2011
July 2011
August 2011
September 2011
October 2011
November 2011
December 2011
January 2012
February 2012
March 2012
April 2012
May 2012
June 2012
July 2012
September 2012
October 2012
December 2012
January 2013
February 2013
March 2013
May 2013
June 2013
July 2013
September 2013
October 2013
December 2013
January 2014
February 2014
March 2014
April 2014
May 2014
June 2014
July 2014
August 2014
September 2014
October 2014
November 2014
December 2014
February 2015
March 2015
April 2015
May 2015
June 2015
July 2015
September 2015
October 2015
November 2015
February 2016
May 2016
June 2016
July 2016
August 2016
September 2016
October 2016
Latest postings