Web Services Yields Fresh Approach on Perishable Product

 
 
By Larry Dignan  |  Posted 2006-02-07
 
 
 

Bill Strauss, chief executive of e-commerce

Company Provide Commerce, the parent of online florist ProFlowers, has come to rely on Web services—even though he can barely define what they are.

"I'm not even sure I can explain Web services," he says, "but I've made it a point to have the right people in technology who start out asking what problem we're trying to solve."

QUESTION: What is the biggest challenge involved with getting technology workers to deploy Web services? Learning the technology? Or learning how the business operates? Tell us at baseline@ziffdavis.com.

A couple of years ago, the company, which sells perishable goods such as flowers, meat and fresh fruit through its ProFlowers, Uptown Prime and Cherry Moon Farms Web sites, was facing a few challenges.

Provide Commerce operates an electronic marketplace that links a consumer directly with suppliers, eliminating intermediaries such as wholesalers and importers. The theory: Goods that make fewer stops on the way to consumers are fresher. It's a business that depends on choreography between the merchant and a global network of suppliers to ensure that goods stay as fresh as possible and hit target delivery dates such as, in ProFlowers' case, a birthday or Valentine's Day.

Back in 2003, Provide Commerce was growing at 20% to 30% a year and its systems, a mix of manual and automated processes, couldn't keep up with spikes in demand, says Kevin Hall, Provide Commerce's chief information officer.

Today, however, the company has deployed Web services—software that enables two computers to automatically speak to each other and carry out functions such as credit card processing over the Internet—to improve customer service and keep information-technology costs under control.

The system it uses can handle almost a half million orders a day, some 50 times more than the 8,500 orders projected daily, and stores the records of 4.3 million registered customers.

Provide Commerce has come a long way since its 1998 launch. Back then, it built proprietary systems using Microsoft .NET and Java technology to tie together its network of suppliers via the Web. Its systems were broken into six primary areas—commerce, supply chain, customer relationship, transaction processing, data warehouse/reporting and user interface.

These systems were loosely coupled through eXtensible Markup Language—a standard that allows data to be shared over the Internet—and communicated through a messaging infrastructure that shuttled instructions built by Sonic Software.

Check out eWEEK.com's for the latest news, reviews and analysis in Web services.

Before the Web services-based system, ProFlowers scanned its Microsoft SQL database daily in batches to find orders that might be waiting to be processed. That technique worked during slow periods, but Strauss says ProFlowers missed some orders when the company scanned for periods with spikes in order volume, say, the day before Valentine's Day.

If a husband misses his wife's birthday because of a processing error, it's unlikely he'll be a repeat customer. Strauss couldn't quantify how many orders were missed, but anecdotal stories from customer service representatives tipped him off to the problem.

Hall calls his former system "monolithic" and attributed the problem to a series of unconnected manual and automated processes employed for things like picking suppliers and shipping goods. The automated processes were bogged down by balky components such as new orders that could only be scanned at certain times, information embedded in databases, and applications that were hard to revamp without an overhaul.

In other words, the company had a mishmash of systems and lacked a trigger to automatically set off a chain of events such as finding a supplier, processing a payment and finding the most appropriate shipper.

This was a problem that Strauss had to solve—quickly.

Provide Commerce needed a system that could automate orders placed well in advance, say, a request for a dozen roses on Valentine's Day made the previous September. The company also didn't want to spend more than 3% of sales on information technology.

"We are a retail company that deals with time-sensitive material, produce that can't last when it's cut," says Bharat Gogia, vice president of information systems at ProFlowers, reporting to Hall. "So, we have to keep products in our supply chain for the most minimal time possible."

When Hall and Gogia pitched Strauss on the idea of using Web services, the team focused on two points: Customer service and Strauss' goal of keeping technology spending to 3% of revenue. Gogia proposed a Web services-based system that could expand easily, automate orders and break down the business into manageable components that would make ProFlowers respond better to orders that were in the queue more than a week ahead of delivery date. Today, when the order is ready, the Web services system sends a message to begin processing, instead of database queries trying to find the order.

Quantifying a Return

The idea, which made a lot of sense to Strauss, cut Provide Commerce's business down to a series of modules such as payment processing, shipping notification and finding the right suppliers. Web services modules could be built for each process and then connected.

Why did that appeal to Strauss? Provide Commerce could change modules without rewriting code for multiple systems, within an enterprise suite for an investment Hall describes as "very low six figures." In the previous system, eliminating a few steps in a process required a change in the business rules underlying a database that might touch multiple systems.

Provide Commerce can now focus on one problem, say, credit card processing steps, and change one module instead of installing financials-processing software or an enterprise planning system.

QUESTION: What is the biggest challenge involved with getting technology workers to deploy Web services? Learning the technology? Or learning how the business operates? Tell us at baseline@ziffdavis.com.

Once these Internet services modules were perfected, manual processing could be cut, thereby reducing errors in orders. "We don't want to throw big dollars at technology," Strauss says. "The alternative to what we did was to get some Oracle or SAP system with a big mainframe architecture."

Gogia's team was charged with building the messaging systems between the components of the company's business, and automating everything from payment processing to credit card authorization to picking Federal Express or United Parcel Service packages for shipping.

Provide Commerce automated its payment processing in 2003 by simplifying processes and installing Sonic's software. Its supplier communications network was automated in 2004, and its shipping systems followed last year.

Both Gogia and Strauss say the biggest hurdle in implementing a Web services system is training technology workers. The architecture requires technology staffers to know the business, break down functions step by step, and then follow up and monitor the system to make sure it continues to work. Training I.T. workers to think in terms of specific business processes "requires more thought," Strauss says.

Have Web services delivered a return? Strauss says they have, but acknowledges it's hard to quantify items like enhanced customer service. Gogia says automation will cut down on errors and returned packages, and speed order processing. Provide Commerce wouldn't disclose figures on these particular metrics.

But if it saves a nickel on each one of 8,500 daily orders, it can save $155,125 a year, in line with Hall's low-six-figure price tag.

More important, Web services have allowed Strauss to meet his 3% tech-spending goal. For the year ended June 30, the company spent $5.54 million on technology systems, or 3.13% of its $177 million in annual sales. In 2004, Provide Commerce spent $4 million on technology systems, or 3.10% of $128.8 million in annual sales. For 2003, it spent $3.56 million on technology, or 4% of its $88.68 million in sales.

And there won't be a big enterprise planning system expenditure on the horizon. AMR Research estimates that a planning system for a company of Provide Commerce's size would run roughly $700,000.

Meanwhile, any upgrades or technology changes will focus on functions, or processes within functions, to keep projects modest and spending within the 3% target.

It's not that Strauss isn't open to big ideas, but he prefers to keep spending in line and get returns in increments. As he puts it: "If you come in with a plan to spend big dollars, you'd better have a bunch of little dollars in savings."

Automating Savings
TProvide Commerce automated many of its processes by using software from Sonic Software. Here's what a business rationale for a similar company may look like.

EXPENDITURES 2003 2004 2005
Software costs* $300,000 $50,000 $50,000
Consulting costs** $75,000 $0 $0
TOTAL: $375,000 $50,000 $50,000
SAVINGS
Investment in planning software*** $0 $700,000 $0
Lowered shipping costs**** $0 $0 $155,125
TOTAL $0 $700,000 $155,125
NET (375,000) $650,000 $105,125
NET in first-year dollars (2003)
Discounted to present at 10% a year
($375,000) $590,909 $86,880
Dashboard Decision

GREEN LIGHT Go

YELLOW LIGHT Evaluate

RED LIGHT Stop

GREEN LIGHT Quick return.
NET PRESENT VALUE:
$302,789.26
*Six licenses at $50,000 for six servers, each responsible for a location. Adds one server each year to boost capacity and add new functions. **includes consulting services and training required to teach developers how to work with web servers. ***provide maintains that its web services architecture substitutes for an enterprise planning system. Amr research provided cost estimate. ****automating systems with shippers cut 5 cents in cost for each daily order. Assumes 8,500 orders a day. source: sonic software, amr research