Menu
ASP and Ye Shall Receive

ASP and Ye Shall Receive

For larger companies considering application service providers (ASPs), some trends are already emerging despite the immaturity of the market. First and foremost is the Internet, of course. Competition among e-commerce sites is so fierce that leaders of the site need to be ready to make changes and add new functionality at a moment's notice. That kind of schedule is beyond the reach of most internal IS departments, which are struggling to keep up with all the demands on their time and are having trouble finding, hiring and keeping experienced e-commerce staff people. ASPs can get an e-commerce site up and running (and supported) in short order.

ASPs are also providing a good opportunity to fill a specialized niche in a company's application portfolio. Software functionality that is too specialized to be incorporated into big enterprise software packages, like ERP or supply chain planning, and too labor and resource intensive to be developed internally is beginning to be farmed out to specialist ASPs that can spread the costs of arcaneness across a number of different customers.

Another ASP charm for big companies is the commodity applications that IS spends too much time maintaining and supporting. Some examples include human resource and financial applications. What follows are some examples of the ways companies are using ASP services and, perhaps more important, the effects of the new order on the IS staffs and businesspeople.

First Union Mortgage

The Specialised ASP

When Gary Suess and Joan Sommerer, two non-IS business executives, came to US-based First Union Mortgage in 1998, their one and only goal was to make the consumer mortgage lending company come alive on the Internet. They saw an opportunity to create a competitive advantage for First Union's mortgage unit by offering the industry's first online mortgage application system.

Most bank and mortgage-lending Web sites already offered mortgage prequalification forms by late 1998, when Suess and Sommerer began hatching their plans. But no one had a full-fledged application system where the customer could get a response (and a legally binding commitment letter) over the Internet in three or four minutes. This kind of instant mortgage gratification could sharply differentiate First Union-if it acted before competitors did.

The two began by approaching First Union's IS department in mid-1998 to help them develop an online prequalification form as a preamble to the project. What they encountered was an IS group that was stretched to its limits serving First Union's many divisions' growing demand for Internet services-to say nothing of an approaching tidal wave of Y2K work.

Still, IS gave it a try, helping the two build some mortgage prequalification forms for the site. But the prequal form didn't happen as quickly as Suess would have liked. "Going through that process illustrated the bottlenecks you hit with available resources. That led us to consider going outside the organisation to achieve what we wanted to achieve," he says.

With IS's consent, the two canvassed First Union's mortgage unit to find out what sort of functionality bus-inesspeople wanted on the Web site, and Sommerer rifled through mortgage trade magazines looking for IS vendors that could provide it. She also called mortgage giant Fannie Mae, which had built its own software mortgage engine using Xpede, a small software vendor and nascent ASP in Oakland, Calif. Armed with a shortlist of vendors, the two approached IS in early 1999. Both understood the need to be diplomatic.

"This was treacherous ground we were treading on," recalls Suess. First Union's IS department had a history of building all its applications in-house and had never outsourced anything before. "There was resistance at first from IS," acknowledges Sommerer. "We were breaking new ground here. Most things were done internally, and the idea of having this application hosted outside the company caused a lot of apprehension. We were talking about having an outsider host some of the most sensitive customer information we had-credit histories, Social Security numbers. Having that hosted and transmitted by T1 lines over the Internet made everyone nervous."

But Joe Monk, First Union's senior vice president and CIO for consumer lending, had a few other things to worry about besides ASPs. All six of First Union's divisional CIOs were under pressure-direct from the CEO's office-to deliver Internet functionality across the company. "We had a declared corporate requirement to take the Internet to all fronts," recalls Monk. First Union's internal web monkeys were already spread pretty thin when Suess and Sommerer came along. Hiring more people to staff the project was out of the question-finding the right skills was difficult and unacceptably time-consuming. Monk had to act quickly. Oct. 31, 1999, was the last day he could add new applications to First Union's infrastructure before a Y2K moratorium went into effect, freezing everything in preparation for the date rollover. Building a new application from scratch and delivering it over the Internet before the freeze took effect began to look like a colossal stretch.

Despite the seeming intractability of the situation, Suess and Sommerer decided not to read the handwriting on the wall directly to Monk and his staff. "We had to go about it so we weren't attacking people's egos in IT," says Sommerer. "We had to approach it so that we made it clear we didn't have time to wait for this application and they didn't have the resources to do it themselves."

Monk agreed. "We were in a position where we needed to consider any kind of alliances to deliver solutions to the business as long as we could ensure the quality was there to support it," he says. "We didn't need to build it ourselves."

Both lobbied hard for support and were careful to include IS in any meetings they had. Of course, they needed IS to help plan for customizing and integrating the ASP's systems to fit with First Union's, but it didn't hurt to enter that phase of things in a spirit of collaboration. Taking the lead in the vendor search also helped Suess and Sommerer clarify their requirements for the application-a process that often can lead to communication breakdowns between IS and the business.

Still, the process was difficult for everyone involved. Sommerer needed to find a vendor that could meet IS's requirements for experience, data security and integration without compromising the business functionality necessary to the application's success. That meant not rejecting startups-like Xpede, the final winner-out of hand. "Since hosting had never been done before, we didn't have processes in place to determine what standards we needed," says Sommerer. "IS came up with a list of 21 questions that vendors needed to answer to determine whether they would be able to provide adequate security and reliability."

In the rush to qualify vendors' technical rsums, Sommerer and Suess sometimes had trouble keeping things focused on the core requirements of the site. "It was difficult to make everyone understand what the business requirements were," says Sommerer. "We wanted the online application and the online decision-making capability, and we would not settle for anything less. Pushing that was critical to our success." That meant Xpede got the job-once IS was comfortable that the young company would be able to scale the application, keep it available all the time and create seamless links into First Union's legacy systems.

So far, so good, say Suess and Sommerer. The site has cut the time a loan officer needs to spend with a mortgage applicant from an average of 30 to 45 minutes to about 5 minutes. Though they won't release specific numbers, the pair say that use of the application has increased 1,000 per cent since it went live last October, and it has only gone down once -on New Year's Day 2000. Other than that, it has been available every minute of every day of every week. And the mortgage unit has enjoyed a hefty 500 per cent bump in business since the application launched.

OshKosh B'Gosh

Instant E-Commerce

The Internet is relentless not just in terms of its capacity for change but in its demands on IS staffs. Not many IS departments are equipped to support an application that stays on all the time. Not all ASPs are equipped to do it either, which highlights the need for developing clear, strong contracts with ASPs that contain equally clear service-level agreements (SLAs) so that support and maintenance never fail (see "Putting Bite into Your ASP Contract," below).

Indeed, if an IS group does not have the experience developing and supporting an application, the relationship with the ASP is everything. Jon C. Dell'Antonia, vice president for MIS and CIO of apparel maker OshKosh B'Gosh, entered into an agreement with Pandesic, an ASP joint venture between SAP and Intel, to develop and support OshKosh's e-commerce Web site. "If you say you're going to get on the Internet, you'd better be there, even if it's just one order coming through the site," says Dell'Antonia. "In one day you go from nothing to 24 hours a day, 7 days a week."

OshKosh's deal with Pandesic is frighteningly all-encompassing, and it happened very quickly-from deal to go-live in three months. Not only did Pandesic (and its subcontractors) build the Web site (to OshKosh's specifications) and its e-commerce tools, but it also handles all the back-end processing and shipping of orders. OshKosh handles fulfillment at its warehouse and sucks transaction data off the Web site for analysis back at headquarters.

With so much hand-holding going on here, one might expect that the contract goes beyond the traditional outsourcing boundaries. And it does. OshKosh not only pays Pandesic a monthly fee for hosting the site, it also hands over a share of the online revenues. "We like that arrangement because it gives them a strong incentive to push forward," says Dell'Antonia. "When we do better, they do too."

Sometimes the partnership seems so close that it's like a marriage-Pandesic's team and OshKosh's IS staff have to adjust to the ways of the other if things are going to work. For example, Dell'Antonia can only pick up the phone and call Pandesic now, he can't roll up his sleeves and go fix things. He cannot call any of Pandesic's supply chain of providers either, even if he's pretty sure that one of them is causing a problem.

A few days after launching, the site went down for 24 hours while Pandesic swapped in a new piece of software that wasn't quite ready when the site went live. When he learned that the site was down, Dell'Antonia called Digex, Pandesic's web hosting provider, to find out what was wrong. "We didn't have the right to contact Digex, and the Digex people pointed out quite forcefully that Pandesic was their customer, not OshKosh."

The experience gave Dell'Antonia a sense of powerlessness that he is not eager to repeat. "You have to come to grips with the fact that you have a third party in there and their sense of urgency may or may not match yours," he says.

That feeling of powerlessness becomes even more acute when the calls begin coming from internal businesspeople who can't access the site. Dell'Antonia had to make people at OshKosh understand that he no longer has direct control over all the company's IT assets.

Likewise, he has to diplomatically tell businesspeople to wait for new functionality to be added to the site while he pleads with and/or bullies Pandesic to move an action item onto its priority list-knowing full well that Pandesic's other customers are making the same kinds of demands. For example, OshKosh salespeople want to offer conditional free shipping (for first-time customers or big orders, for example), but Pandesic's software isn't equipped to parse out the qualified customers yet. "They say they want to add the free shipping option in about six months. We say we want it in six weeks."

Dell'Antonia is the man in the middle. He has to sort out requests for changes from within OshKosh between those that are critical to the online business and those that are "nice to have" but aren't really urgent and could cause undue friction between him and Pandesic if he pushes too hard. He also needs to keep options open for going to other providers to get the technology his businesspeople need if Pandesic cannot provide it. That means perhaps having his own staff or yet another third party get involved in building something while all the while making sure that it will hook into Pandesic's back-end infrastructure (which is owned by Pandesic, not OshKosh). It's a complex subject that Dell'Antonia has not yet broached.

To keep the relationship strong, Dell'Antonia has weekly meetings with a Pandesic project manager, and he keeps a Pandesic executive's phone number in his Rolodex for the occasional call to higher-ups.

In his mostly smooth (he says) marriage to Pandesic, Dell'Antonia has taken on the role of a relationship manager while shaking off the traditional IS role of technology provider. "If I had to do it over again, I would," he says of the Pandesic partnership.

His new role-while uncomfortable at times-represents the future for every CIO.

Putting Bite into Your ASP Contract

When it's time to negotiate, remember these tips The same things that make ASPs so darn tempting-no network or application license fees to worry about, no servers to upgrade, no support or implementation staff to care for-also make them tremendously risky. The newness of the market and the herds of interlinked vendors that lurk beneath the shells of most ASP offerings add fragility to even the best-written ASP contracts. Here are some tips on the contract process:

Keep the contract term as short as possible "Who knows what web hosting will look like in six years?" asks Douglas Plotkin, a consulting manager at the Stamford, Conn.-based research company Meta Group. "Mainframe outsourcing contracts used to be 10 years. Writing a contract for that length doesn't have a meaning except to lock you into an argument with a vendor."

Benchmark through vendor competition

Pricing for ASP services is still in the "Well, it depends" phase. Most buyers benchmark ASP prices by trying to estimate what it would cost to provide those services themselves. But how can you reliably build in all the cost components if you've never done them before? Instead, Plotkin recommends having three or four ASPs submit detailed bids for your work.

Establish a metric-any metric-that tracks your usage growth If you don't agree on a metric to measure growth against the price of the service, Plotkin cautions that when the contract renews you could find yourself at the mercy of a vendor that exploits the lack of data "to justify a surreal cost increase." He recommends using one or two simple metrics-the number of users of the ASP application, for example, or the number of transactions processed through the e-commerce Web site, or the number of business documents developed using the application-in order to track the growth in usage. Agree on a firm price for how much more the service will cost as usage grows.

Create performance penalties that truly motivate ASPs make money by serving as many customers as possible. If stretched-as most inevitably are-they will respond first to the contract that screams the loudest. According to Plotkin, many contracts barely whimper. "I've seen [some] where the penalty for downtime is 3 per cent of the monthly fee," says Plotkin, meaning it just might be "cheaper to leave you down than bring you back up." And when they do bring you back up, there may be no incentive to fix the underlying problem-as opposed to just patching it when it breaks. Plotkin recommends making the penalties escalate each time a problem recurs. Stretch the interval for counting recurrences over as long a period as possible-at least a few months.

Have an out that won't cost you anything In case of chronic underperformance, you'll need to be able to get out of the contract and find a new ASP. Expensive exit fees and troublesome software ownership clauses can get in the way. You need to be able to get out clean and take whatever you need-data, customised applications-with you. If this means having to buy licenses for your customised software up front, it could be worth the extra dough. Otherwise, the ASP owns your software, and you may be stuck if you want to make a switch.

Don't expect to cut costs unless you want lower levels of service too If you're a big company, chances are your ASP contract will be for niche services rather than massive outsourcing. Don't expect to save money on a niche offering-the scale isn't there for the vendor to customise it to your needs and run it cheaply too. Most mature outsourcers like to keep profit margins above 25 per cent, says Plotkin, which means an outsourcer has to run the application at 65 per cent of your cost of running it to make the margin back and lower your cost by 10 per cent. That's not easy to do. "As an outsourcer, I have to drastically cut my own costs to get a profit and cut your costs," he says. "And now you're saying improve service levels? This is why SLAs fail. The customer is expecting both, and that equation just doesn't close."

-C. Koch

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about DigexFirst UnionIntelMeta GroupOshkosh B'GoshPandesicSAP Australia

Show Comments
[]