|
Custom Jobs Need Not Apply
SaaS wasn't always a heavy favorite. In fact, the first wave of SaaS vendors, known as application service providers (ASPs), hit the beach with a roar in the late 1990s and crashed just as hard. Like SaaS vendors, ASPs promised lower deployment costs, ease of implementation, and ready access to applications and data. Vendors boasted a less costly per-seat price given the economies of scale they could achieve by running a single instance of the software at their data centers.
But ASPs fell flat; performance was pitiful, with ASPs sending clunky client-server applications over the Internet during the days of dial-up bandwidth. Today, Internet-ready software development platforms such as J2EE and .NET -- coupled with the proliferation of lower-cost, high-bandwidth capabilities -- have solved many of these problems for next-generation SaaS vendors.
Still, SaaS shares some legacy constraints that plagued its ASP forerunners. The one-to-many nature of SaaS applications, for instance, means that heavy-duty customization isn't practical. For organizations that rely on niche applications or that require regular, quick changes to their software, SaaS is inherently too limited.
So says James Woolwine, CIO at $50-million Majestic Insurance Co. in San Francisco. Generally speaking, Woolwine believes in the benefits of SaaS, but his company is still firmly wedded to the premise-based model. Why? Blame it on minutia. Majestic, a workers' compensation insurance firm, is bound by legally mandated rate and policy changes. Such changes require a degree of flexibility that Woolwine says he can't get from a SaaS provider serving up vanilla-flavored software.
To be fair, SaaS applications are configurable. For instance, customers can amend workflow and business processes by changing fields. Many analysts and CIOs contend that this kind of configuration is good enough for most SaaS applications. But if you need to do extensive customization, "that won't be possible with SaaS," says Laurie McCabe, vice president of SMB Insights & Solutions at AMI Partners.
In order for SaaS applications to be highly customizable, vendors would have to hand over their source code for modification. And while some providers may opt for this route, most are unlikely to relinquish code since it wipes out economy-of-scale benefits.
To resolve the customization conundrum, SaaS vendors are selling business process expertise along with their software: best practices that reduce the need for customization. While some vendors offer templates for specific business practices, many others can configure workflows and business processes during implementation because they sell their software directly to customers rather than through a reseller. For example, an expense account management application may require three approvals, whereas your existing process needs six. "Having more than three [approvals] may not be effective," McCabe says. "You may not want software to conform to your wacky business process in the first place. You should really ask yourself how much customization you really need."
|
