Years of budget cuts and still-painful scars from the overheated tech-buying spree of the ’90s have left many companies nervous about being early adopters. Being first in line for products based on cutting-edge technology is even more hair-raising when you’re holding hands with a startup vendor. But a few braver-than-average companies are taking chances and making them pay.
The reasons they become early adopters vary. For some, it’s a necessity rather than a choice, when they find no mature technology to meet their needs. For others, it’s a calculated attempt to save gobs of money. For others still, it’s a necessary step to leapfrog larger competitors. With our "State of the CIO" survey showing that expectations for IT to drive innovation and competitive advantage have climbed year-over-year, the urgency to try something new is mounting. Even Nicholas Carr—Mr. "IT Doesn’t Matter"—admits in his book that IT first movers have an opportunity to gain competitive advantage.
Whatever the motivation, being an early adopter involves significant risks as well as rewards. As with bungee jumping, careful preparation can mitigate many dangers. But at some point, you’re still going to have to take that big step off the bridge.
Before you do it, early adopters uniformly warn, you must make a strong business case for the move—the stronger the better. Will using the new technology ensure that you will gain ground on the competition? Will it allow you to win new business you can’t acquire any other way? Will it cut costs out of your operations like nothing else can? Will it make you orders of magnitude more agile than you are today? If you can’t build a sound case around any of these business outcomes, then waiting or seeking a more established solution is probably the wiser way to go.
And even if you can build the case, you need to look inside and make sure that you and your company have the intestinal fortitude to follow through with the implementation. Working with new tech can have remarkable benefits, but the path to those rewards may be significantly more strenuous than when you deal with established technology from a known vendor. You’ll be building best practices, not borrowing them. Technical support may be limited or nonexistent. You may in effect be beta testing (or even alpha testing) the product. The implementation process will require more risk mitigation planning and ongoing monitoring than you’re accustomed to.
Still interested? Good. Now it’s time to see how several companies made it work.
Reasons and Rewards
Cost reduction When Mysia Benford became information systems and logistics director at Associated British Nutrition and Agriproducts (ABNA) in November 2001, she knew she was getting into a company that didn’t make changes lightly. Some inefficient business processes had been in place for decades at the agricultural products and services company. Farmers, for instance, often called for grain feed delivery when their feed bins were just about down to dust. Feed products are made to order, so a late order would alter the manufacturing schedule, introducing the possibility of raw material substitution with its increased cost. And pickup and delivery times were not always well- coordinated. Empty trucks—fresh from delivering feed to a farm—would sometimes pass other empty ABNA trucks on their way to the same farm to pick up products that the farmer was selling.
The typical solution for overhauling inefficient logistics is an ERP system. But Benford wouldn’t hear of it. "My view is that [ERP] is an executive solution to ’Wouldn’t it be lovely if there were one thing in the world that would solve all my problems?’" she says. "To be generous, it’s naive."
Instead, Benford wanted a solution that would allow her to quickly integrate new business processes—and even new businesses—without the hassle that she associated with ERP. "All the [ERP] configuration issues mean you need a load of consultants before you can see how this software works," she says. And if that happens, "you’ve lost as an organization the ability to understand how your business works." Her alternative was something brand-new at the time (early 2002), a service-oriented architecture (SOA) built on an enterprise service bus (ESB) from Sonic Software. The integration flexibility it provides ABNA means that a $2.8 million software-plus-implementation investment in Sonic ESB and a separate enterprise logistics product "have the potential to generate a 5 percent to 10 percent reduction in ABNA’s $100 million yearly costs for logistics," Benford says.
But convincing every piece of the supply chain to take advantage of the flexibility that SOA can provide remains an ongoing challenge. In the case of the empty farmer silos, for instance, ABNA has begun testing sensors that could generate an XML request when feed drops to a specified minimum level. The ESB would then treat that request as a B2B transaction for more feed, replacing the last-minute phone call from the farmer and eliminating the need for human data entry.
Convincing ABNA’s service people how things should operate took some work.
"They talked about hiring someone on the customer service team to go online and see who needs feed," Benford sighs. "I said it was a waste of time, just send [the XML message to the order system]. The problem isn’t necessarily that end farmer; it’s the people who interact with that farmer. They’ve always done it one way, and they want to keep doing it that way. It’s a fairly conservative environment."
Being an early adopter may be the only practical option for companies whose size and resources prohibit costly custom development or megapackage purchases from the big vendors—particularly if the company is looking to find a way to leap ahead of bigger competition. Such was the case for Epsilon, an approximately $120 million subsidiary of Alliance Data Systems, which manages large-scale marketing databases and campaigns. Epsilon needed more data-mining power, but for a fraction of the price of a traditional system purchased from a more established vendor.
Through careful searching and a little luck, Epsilon discovered Netezza. In 2000, Netezza was a startup with an interesting idea: to build a data-mining appliance that would deliver better performance than existing options for far less money. It didn’t even have a customer yet, but the product seemed ideal for Epsilon’s needs. So after a period of close scrutiny, Epsilon opted to become customer number one.
By being a first customer, Epsilon carried a lot of weight with Netezza, which was always accommodating in making changes. At one point, for example, testing revealed some performance issues for certain customer-critical tasks, according to Epsilon Vice President of Marketing Technology Products Mike Coakley. But unlike a large company that might have simply added Epsilon’s requests to a long list of fixes for some future upgrade, Netezza went to work immediately. "That’s a side benefit of being an early adopter," Coakley says. "You get a lot of input into the product."
Coakley says that putting the Netezza box’s benefits into dollars is difficult, but its time-saving features enabled one customer to run seven times more campaigns than in the same period in the previous year using Epsilon’s proprietary system. The system has made a competitive difference for Epsilon customers in a couple of critical areas. First, its remarkable speed lets customers run many more variations on campaigns more quickly. Second, the Netezza box also works as an off-the-shelf relational database, replacing the proprietary data store on which Epsilon used to depend. That fact allows Epsilon to connect the app to standard marketing front-end clients, such as Unica and Business Objects, making it easier for customers to manipulate their own data. While he can’t provide a percentage, Coakley says that Netezza’s product contributed significantly to a $1 million savings in Epsilon’s IT budget by allowing the company to move off an aging, mainframe-based system.
JUST RIGHT FOR THE JOB
Beyond saving money and giving you a leg up on the competition, sometimes cutting-edge technology is the only thing available that meets your cutting-edge needs. Four years ago, Mark Cotner, then manager of network and application development at Cox Communications, was challenged with building a data warehouse capable of handling a constant stream of diagnostic data from 1.2 million broadband customers. The resulting database would contain some 2 billion rows of data—more than 600GB of information.
Being an engineer, Cotner did what he always did: He started testing. And his results pointed him to what was then an unusual place—that is, the open-source MySQL database. "The particular piece of software that I was working on had some strict performance requirements," Cotner recalls. "It was a very insert-heavy data warehouse, and MySQL [version 3.23.41] was better at data inserts than any other database we tested." MySQL was also available for free, though Cox purchased enterprise-level support from MySQL AB, the company that created the software and ultimately released it as open source. But Cotner says that cost wasn’t an issue. "We knew [the database] was going to be important for the business," he says. "We could have spent any amount of money we needed," noting that the data is used regularly by 500 support people and gets some 500,000 internal hits per day.
The warehouse has worked so well that Cotner says Cox plans to expand it soon to hold six months of data instead of three, and to include telemetry information from the company’s set-top boxes as well. Ultimately, the database could house 12 terabytes of data.
SPEED TO MARKET
Finding the right early adoption solution takes luck. Sitting in a class on venture capitalism at Notre Dame, Doug Wait wasn’t exactly expecting to find the answer to his company’s sudden supply chain management challenge. Wait, a plant manager for $1.3 billion glass manufacturer Pilkington North America, suddenly faced a wave of new orders that would radically increase the volume and number of products produced at his operation within weeks. Spreadsheets—his then-current means of keeping track of everything—weren’t going to do the job, and other solutions seemed to be biting off more than Pilkington was willing to chew. "I wasn’t looking for the holistic solution to solve scheduling and world hunger," Wait says.
But when one of the venture capitalists teaching the class found out that Wait might have a need for some advanced scheduling software, he pointed Wait to a company he’d invested in, JRG, which offers a hosted supply chain management service that looked like it would fill Pilkington’s needs—and do it quickly. "We started talking to them in October 2003, declared our intention to do business with them in November, and implemented between December and February," Wait says. It took a fraction of the time and cost that other products, such as those from i2, would have taken, he adds. Better yet, JRG was eager for the work.
"They’re hungry. They’re aggressive. They need to make sure the perception that they leave you with is good," he says. When Wait needed something, JRG was quick to deliver.
Keep an Eye on Risk
"The number you have dialed has been disconnected or is no longer in service."
The ultimate nightmare scenario for any early adopter is a vendor that goes belly-up. And given that most startup businesses fail, it is a real risk. But properly prepared mitigation efforts can help companies avoid or recover from a bevy of unfortunate incidents, even the complete collapse of the vendor.
The first step toward mitigating the potentially debilitating effects of early adoption is to establish a sound process for identifying new technologies worth using. In some cases, that involves a full-blown advanced-tech unit charged with testing new technologies in an R&D setting. But such setups can cost big bucks—and thus few companies even want to consider the option.
But there are ways to keep track of technological advancements without adding a new wing to your IT department. Bill McCreary, vice president, CIO and operating excellence for Pilkington North America, says the company uses a three-stage process to monitor technologies it may one day adopt. All IT employees are encouraged to keep an eye out for new technology opportunities as part of their jobs.
Once a new technology matures a bit (meaning it hasn’t "just shown up in the newspapers," says McCreary), it can go on the radar screen, which is stage one. Then someone will be charged with tracking its progress and developing a working understanding. Technology can stay in this stage indefinitely if Pilkington’s technology evaluation committee feels it is still interesting but not ready for prime time. (RFID fits squarely in this category right now, McCreary says.)
If the technology continues to look promising and has matured sufficiently, it will move to stage two, the on-deck circle, where a business case can be built and possible alternatives identified. If it survives that process, Pilkington is ready to begin the third stage, some form of implementation.
Cox’s Cotner has an even simpler process—test, test and test again. And he notes that success with one version of your early adopted technology shouldn’t necessarily mean jumping enthusiastically to the next iteration. "We made that mistake with mySQL 4.0.xx when we tried it right away," Cotner says. "We had some issues as a result" (including a small table-corruption problem that was later resolved in a minor version upgrade). That experience has made him much more cautious about subsequent upgrades.
VET THE VENDOR
The drive to keep up with the Joneses—and then pass them in a blur on the right—has led more than one early adopter to a crash. But many such problems can be avoided with proper vetting of your new vendor.
Epsilon’s Coakley may have the most nightmare-inducing story. Almost 15 years ago, the company decided to build a large part of its marketing program’s management platform on the then-new Thinking Machines massively parallel processing platform, making Epsilon (at the time owned by American Express) the first company to put commercial applications on cooler-than-thou Thinking Machines hardware. It looked like the perfect mating of Epsilon’s software needs with hardware horsepower, until Thinking Machines went up in a flaming ball of mismanagement in 1995.
"We had to replatform [the entire application]," Coakley recalls. "Thinking Machines was so new, we had to write everything for that damn machine." It took months for Epsilon to make the switch. But the experience taught Coakley to be very careful when working with new vendors. When Epsilon decided to investigate Netezza, for instance, Coakley brought in people from groups outside IT—including the CFO’s office—to cast a cautious eye on the deal. "Folks like me, as much as we’re supposed to be skeptical, we get excited about this stuff," Coakley says. "Sometimes you need somebody else to ask the tough questions." Epsilon’s financial people delved into Netezza’s fiscal footing, while the sales team made sure the company had a solid idea of how to turn Netezza’s technology into a salable product.
Assuming that your vetting process results in a business deal, you should still prepare your staff for the possibility of failure. Doreen Griffith, CIO and senior vice president at securities-broker service provider Securities America (SA), recalls when a software vendor (she won’t name names) made a shift away from the company’s industry space, potentially leaving Griffith with an orphaned product that is part of a core offering to more than 1,500 representatives. But, she says, her company’s entrepreneurial culture saved the day: SA bought the source code and continued development on its own.
That same philosophy applies to several open-source products that SA uses as well (including a clustering platform from Emic Networks, the MySQL database and open-source voice-over-IP technology from Asterisk). Once the product comes in-house, SA developers learn it inside out, in case they need to support it on their own sometime down the road.
Midsize companies such as SA aren’t the only ones that can benefit from this "once you have it, you own it" approach. PPG Industries, a 30,000-plus-employee global manufacturer of glass and related chemicals, followed the same philosophy when it sought a tool to track idea generation across the company. PPG was ready to build its own Web-based idea generation and tracking system to replace its manual process. But as the company was about to get started developing the system on its own, a call from a startup vendor, MindMatters Technologies, led to the installation of a prebuilt system that delivered what they needed without the hassle and expense of going through a large development effort. And, says Jim Johnston, PPG’s IT director of enterprise architecture and advanced technology, the fact that his company was prepared to build the software itself meant that MindMatters’ going under wouldn’t be as big a problem as it might have been. Part of the contract puts MindMatters’ code in escrow, and PPG would pick up the development effort itself should the unthinkable happen.
LIMIT THE SCOPE
Narrowing the scope of a new technology can also help, even if the tech will be running some critical part of your business.
"Would we have put our entire Western Hemisphere network on something that looked like a JRG? No," says Pilkington’s McCreary. Instead, JRG’s hosted service let the company more closely manage operations at a single plant, allowing for faster switchover to different products and helping maintain the near-real-time manufacturing environment the auto industry requires.
If things hadn’t panned out with JRG, McCreary was certain that it wouldn’t cripple the company. "Had this failed, we’d be back on spreadsheets," he says. "We’d be working Saturdays and Sundays and have higher costs, but the customer wouldn’t have seen anything." And purchase contracts with JRG arranged by plant manager Wait helped guarantee minimal financial losses if things didn’t pan out. "We set up the business structure to minimize risk, Wait says. "There wasn’t a lot of money up front." And the fact that JRG was a hosted service only loosely coupled to the company’s data meant the plant could disconnect quickly and stop paying for it at the same time—a far cry from tightly integrated ERP systems with long-term support contracts.
DON’T GIVE AID TO THE ENEMY
There’s one other risk that might not occur to some companies until well after the implementation: Your efforts may ultimately help your competitors.
Epsilon’s Coakley, for instance, expects some of the labor that his company put in to ensure that Netezza’s data-mining box works well for Epsilon will now benefit Epsilon’s big competitor, Acxiom, which bought Netezza products last summer.
Coakley notes that early adopters might be able to arrange exclusivity agreements with their vendors. But those agreements will cost money. "If you don’t make that decision to go exclusive, then you know ultimately it’s going to open up to your competitors," he says. The key, he cautions, is determining if you’ll still be able to take good advantage of the product, even when you’re no longer the only user. And even if Netezza’s products no longer provide the leapfrog advantage they used to, Coakley says, he feels Epsilon can still take good advantage of the products to add value to its offerings. And if he’d never gone with Netezza, he reasons, he never would have gotten his initial jump. The reward was simply worth the danger. "You never want to be in the position where you’re going, ’Me too.’ You always want to be viewed as a leader," Coakley says.
PPG’s Johnston reiterates the mentality that drives companies to risk early adoption. Taking a cue from PPG’s own drive to constantly create new products, Johnston says, "If you’re first to the market, you capture that market. You can always follow other companies and take their breadcrumbs. But I’d rather be out there."
Christopher Lindquist is CIO’s technology editor. He can be reached at firstname.lastname@example.org.