There are two basic arguments for going with an application service provider: to reduce operating costs and increase security through economies of scale and to gain productivity through economies of scale and the easy-to-use, ubiquitous browser.
I buy the first argument. However, there are few mainstream applications that make me think the second argument will bear out. Basically, it boils down to Newton: Unless someone is willing to do some work, a body at rest stays at rest. You need buy-in from users, and someone has to enter all those bits that eventually get moved around.
Applications in vertical markets, particularly CRM (customer relationship management) applications, seem to be bucking this trend, however. I wrote about one such application, MarketTouch SE, several weeks ago. With MarketTouch, the application design acts as the information coordinator to kick out customized, ready-made sales pitches. That potentially saves the salesperson a few hours of information gathering per pitch. While someone must still collect the information and move it into the application, there should be a one-to-many relationship between the person inputting information and those receiving it.
The flip side would be applications designed to save work for a particular user by offloading it to others. The BridgePath Recruiters Network (www.bridgepath.com), a CRM tool for headhunters, is a perfect example. Basically, the problem for recruiters is managing the information for many contacts, both employers and prospective employees. According to officials at BridgePath, the typical recruiter spends a couple of hours a day just inputting information to update contact info and résumés.
The reasons for recruiters to use a hosted Web-based application are obvious. They need an answer to the Internet logistics of a Monster.com site, which provides an easy means of matching candidates to job openings. The market itself is small in the grand scheme of things, with few large companies. Developing a CRM application for the recruiting field would be too risky for a software vendor, and building a custom one for each company would be too expensive.
In addition, recruiters need to maximize their time by creating and maintaining one-to-one relationships both with employers and with job candidates to distinguish their service from the want ads.
Job placement had largely been apaper bound affair until the arrival of the Monster.coms of the world. If you aren't working through the Web, though, résumés remain paperbound, circulated via fax, with updates to contact information having to be rekeyed by the recruiter. Ideally, the typical recruiter would spend more time on the phone getting feedback both from interviewer and interviewee about job fit rather than spending time updating contact info.
So the BridgePath model largely relies on self-help. It is much simpler to route candidates to the Web to update their own contact information than to take the information over the phone and rekey it.
The single point of failure in the system lies with the job candidate. Few people are in perpetual job search mode, so they won't be compelled to keep in touch with a recruiter, much less update their information. In that time when the candidate isn't looking, how likely will it be that his or her contact information has changed? c
I'd like to hear more about companies using ASPs for line-of-business applications. Please write me at michael_caton@ zd.com.