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

The Enterprise System Spectator

Monday, September 23, 2013

Best Practices for SaaS Upgrades as Seen in Workday's Approach

If you're involved with enterprise software, you need to pay attention to what Workday is doing--even if you're not interested in HR or financial systems. Because Workday is one of the best examples of how enterprise applications can and should be delivered in the cloud.

This was one point I took away from Workday's annual user conference in San Francisco and from a day-long series of briefings for industry analysts earlier this month. 

The differences between Workday's practices and the approach of traditional enterprise software vendors are striking. There are several points of contrast, but in this post I'd like to focus on how Workday delivers software upgrades and some new twists in how it does this.

Traditional Approach to Software Upgrades

In the traditional enterprise software model, vendors develop new versions and provide them to their customers that are under maintenance agreements. The customer takes delivery of the new version, installs it on a test copy of the system, migrates data from the existing production version, retrofits any customizations or interfaces with other systems, revises its user procedures, performs system testing,  and migrates all of its users to the new version. In the process, if there is any time left in the schedule, the customer also may investigate how it would like to use any new functionality offered in the new version.

The bottom line is that in the traditional model, software upgrades are both a technical exercise as well as a business exercise. The technical challenges of data migration, retrofitting of customizations, and reworking system interfaces can be significant and can encourage customers to stay on older versions of a vendor's system for many years. When such a customer finally wants to get current on the latest version, the upgrade process can rival the time and expense of the original implementation. The technical aspect can be so much work that companies often retain outside service providers to manage or assist in the effort. The business aspects--accommodating changes to business processes or embracing new functionality--are often jettisoned for the sake of simply getting the new version installed from a technical perspective. As a result, customers often do not realize the benefits of the new functionality that the vendor offers.

The Workday Approach

Workday's approach to upgrades, from the beginning, is simple: it takes responsibility for all technical aspects of the software upgrade, allowing the customer to focus solely on the business aspects. There are at least three reasons that Workday can do this:
  • Workday's object model allows most customizations to be brought forward to new versions of the system with little or no retrofitting.
  • Likewise, Workday's Integration Cloud, based on technology it obtained through its acquisition of Cape Clear,  allow most custom integrations to continue to work with new versions of its system.
  • Since Workday operates the system on behalf of the customer, Workday takes all responsibility for migrating the customer's data to the new version. 
The impact of this last point should not be underestimated. Last year, Workday's CTO, Stan Swete, wrote about how important it is for the SaaS provider to take full responsibility for migrating customer data to new versions: 
[The] Software-as-a-Service (SaaS) model improves service delivery quality by letting the provider own the end-to-end process of development, conversion, and deployment. In the on-premise software world the vendor controls development (and associated QA), but there is a hand off for conversion and deployment. At Workday, the update process is not done until every customer is on the new version. The same team that project manages our development also project manages conversion and deployment.
When it comes to version upgrades, not all SaaS providers are created equal. Some are little more than single tenant hosting providers. Others are multi-tenant SaaS providers, but they deploy new versions as separate instances of the system and allow customers to stay on older versions for long periods of time. This makes version upgrades considerably more difficult if and when customers do decide to upgrade. Workday, as discussed, is at the other end of the spectrum, keeping all customers current on the latest version. Salesforce.com, NetSuite, and Plex, are similar to Workday in this regard, though they may differ in the details of how they do it.

    Further Improvements in Workday's Approach

    This year, Workday has further refined its approach to version upgrades in three ways:
    1. Single production instance for all versions. Previously, Workday would deploy a new version of Workday as a system instance that was separate from the previous version, and Workday would migrate customers in waves from the old version to the new version over a three week period. Workday's new approach is for the current version and the new version to exist simultaneously on the same system instance. Workday will now move customers to the new version by means of a set of "switches" that dictate which features of the system the customer will see. This new approach is possible because of Workday's object orientation discussed earlier.
    2. Continuous development and deployment of new functionality. Instead of holding all functionality enhancements for its periodic version upgrade, Workday is now introducing smaller changes on a weekly basis. This is especially important for small but high-priority changes or for tax and regulatory updates. Contrast this to the traditional vendors, who required many months or years between the time customers request changes and the time they actually see them in updated versions.
    3. Continuous conversion of customer data. As Workday develops new features that require changes to its data model, the single production instance now allows Workday to convert customer data in the background in advance of actually migrating customers to the new version. This reduces the amount of downtime required during the when the customer is moved to the new version. 
    4. Preview instance. Now that there is a single production instance and continuous conversion of customer data, Workday is now able to offer customers a preview instance of the new version, giving customers a longer time-frame in which to evaluate and plan for the new version. Under the traditional model, customers only get a hands-on look at the new version when they take delivery of the upgrade, install it, and convert their data to it in a prototype environment. Workday's approach gives customers much more time and encourages them to make use of the new functionality.
     Swete summarized these changes in a blog post during the user conference:
    Probably the best example of embracing continuous change is happening on the service delivery side of our business. Workday has moved to continuous deployment of new features to a single code line. This move, along with the continuous background conversion of data for new features, enables us to complete updates for our production customers with less scheduled downtime. Application of changes to a single code line reduces the expense of maintaining multiple code lines around each update we do. Moving to continuous deployment also gives us the flexibility to continue to respond to our customers’ requirements when it comes to the number of updates we do each year.
    As Swete indicates, the single production instance, continual development approach, and continuous conversion of customer data allow Workday to scale back from three new major versions a year to just two. The conference audience applauded when co-CEO Aneel Bhusri made this announcement, perhaps indicating that many companies have difficulty absorbing three major upgrades a year. At first blush, the reduction in the number of new versions a year would imply that Workday is slowing down the number of new features per year. But in an sidebar conversations with Workday executives the next day, it became clear that these most recent improvements actually mean that Workday will be introducing more new features each year. The difference is that the smaller changes will be trickled-in on a weekly basis, while major new features will be held for the twice-yearly updates.  As indicated earlier, this approach also allows Workday to accommodate regulatory or tax-law changes on short notice, which have become more common in recent years.

    Workday's core strategy of reducing or even eliminating the technical burden of version upgrades is a best practice for SaaS providers, allowing customers to focus exclusively on business improvement and maximizing the value of their system investment. More SaaS providers should follow this example.

    Postscript: Over at Diginomica, Phil Wainwright has two good posts covering some of these same points:
    Note: Workday covered my travel expenses for attending its user conference.

    Update, March 19, 2014: This Workday post by David Clarke provides a detailed explanation of Workday's single codeline development process.   

    Related Posts

    The Simplicity and Agility of Zero-Upgrades in Cloud ERP

    Labels: , , ,


    by Frank Scavo, 9/23/2013 08:55:00 AM | permalink | e-mail this!


    Read/post comments!
    (2) Links to this post

    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!


    Read/post comments!
    (1) Links to this post

    Powered by Blogger

    (c) 2002-2017, 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, technology adoption and investment trends, IT management best practices, IT salaries, 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
    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!
    Awards

    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
    January 2017
    February 2017
    Latest postings