Most ‘new technology’ firms have trouble stating what they do
The technology marketplace is rife with weeds posing as exotic flora. Razor-edged grasses and thorns abound, making the bleeding edge as dangerous a place as it has always been.
Two events this past May served as technology milestones: The first draft of the ebXML (“electronic business XML”) standard was announced, and OrderFusion — one of the most deliberately innovative e-commerce and catalog system vendors — shut its doors, unable to secure a desperately needed round of venture capital.
OrderFusion began as Dover Pacific. Driven to push the envelope from the outset, the company had launched its software business in the mid-1990s on the NeXT platform. By the late 1990s, OrderFusion had become the most aggressively Web-oriented order entry and fulfillment system for direct commerce.
OrderFusion is a good example of the risks inherent in cutting-edge software development. By tailoring its application to the whims of an ever-evolving technology, the company was caught when the wind shifted, leaving it with no way to stay aloft.
Allergy season
I think that OrderFusion was also the victim of another kind of hype: its own. The company attracted a mixed bag of users, primarily because it had a hard time defining exactly what its system was about.
Is it just my impression, or do most “new technology” firms suffer from an inability to state in simple terms exactly what they do? A rose may be a rose by any other name, but ragweed is not a gorgeous flower no matter how fondly you describe it.
The current crop of technological poseurs may be more dangerous because they promise to do more than ever before in an environment — Web-enabled commerce — that both invites hyperbole and actually requires that the inflated promises are met for participants to be served effectively.
For Web-enabled commerce to be more than a self-service order interface, systems must be able to talk to each other. In particular, marketers must communicate at the systems level with a tangled web of suppliers and a vast variety of both new and existing customers. To fully appreciate some of the challenges of making that happen, let’s first understand the order interface “space” more thoroughly.
Exceptional rules
With the novelty of online order entry long since worn thin, it’s time to fit this weed into its commercial taxonomy.
We’re talking about a rather primitive organism here. Sure, Web order entry is here to stay, and it is accounting for 5%, 10%, 15%, and sometimes closer to 25%-35% of direct commerce orders. No order management solution can afford to be without a Web module, or open interfaces and functional support for whatever third-party platforms you choose.
What’s missing, however, is the ability to support exceptional customer interactions. At best, today’s rules-based systems can support a series of branched options that allow for some customer-driven parameters. But this is a far cry from the normal give-and-take of customer activity supported by human beings in a call center.
The issue is how people actually shop, and how well-trained CSRs support that activity when talking to a customer. Customers have questions, and CSRs have answers. But more than that, they have knowledge about what it is possible to do to meet or exceed the customer’s expectations.
Take future shipments just as one small example. The customer wants to know if the future shipment date can be “don’t arrive before,” rather than “must arrive by.” If the CSR doesn’t know, or doesn’t have the ability to specify whichever option the customer wants, a brief moment on hold (ideally) should secure an answer.
Sure, these kinds of questions can be answered with real-time chat, or on an online FAQ sheet, but there are probably thousands of such questions, based on each customer’s particular wants and needs. It is impossible to predict them all.
And sure, a “knowledgebase” such as those used in technical help desk applications can try to systematize questions and answers for future reference. But be honest — how many times have such knowledgebases failed to provide a satisfactory answer to your particular query?
No Luddite
Don’t get me wrong. I am not arguing that e-commerce sucks, or that it is destined to remain a stepchild order medium forever. I am simply saying that it is still very much in its infancy, and that childhood and adolescence are not going to be a picnic. What’s more, those two phases of maturation will be lengthy ones.
I am inclined to this conclusion primarily because I appreciate only too well the multidimensional challenge of a frustrating paradox: To support the complex “web” of e-commerce requires standards-based solutions, yet there is still no real progress on creating those standards.
If you think that coping with specific customer requests and idiosyncrasies is a challenge, coping with the vagaries of the supply chain is even more complex. You’re extremely lucky if any one company’s business rules are coherent; try getting any two of them in sync, and you’ll soon be tearing out your hair. Try getting multiple sets to sync and you’ll probably consider more drastic measures. And don’t forget, we’re talking (for the most part) about automating these interactions.
Alphabet soup
eXtensible Markup Language, or XML, was supposed to get us out of these woods by providing a systematic way to manage information. It is proving to be as useful as an alphabet is — that is, critically necessary to verbal communications but not sufficient to support them.
The core issue is whether my system can really talk to your system. The current state of XML has each specialized “vertical” market working on its own “grammar” and “vocabulary” to support such interactions. There are huge gaps as well as a few overlaps in these efforts.
There is also some crazy zigging and zagging. One of the most promising new protocols, ebXML, which has been under development since 1999 by the United Nations and the Organization for the Advancement of Structured Information Standards (OASIS), announced the first draft of its specification in May 2001, but without support for SOAP, the Simple Object Access Protocol that both Microsoft and IBM are supporting. By June, that little oversight had been corrected, and support for SOAP was added.
Microsoft and IBM are both major sponsors of another protocol, UDDI, or Universal Description, Discovery, and Integration. If you haven’t heard much about UDDI, you will soon, and it will sound much like the hype for XML did a few years ago. To keep it in perspective, remember that UDDI is like the telephone directory, consisting of white pages to tell you who a company is and how to reach it, yellow pages to tell you what products and services it offers, and “blue” pages to tell you the protocols it uses or supports.
That’s a good start, but we’ve got a long way to go. Remember, in England tires are “tyres,” and that’s just a variant spelling. Gas is “petrol,” and many parts of the car and its engine are called different things. This is both an analogy and a reality, since what things are called (and the way they are measured and described) is critical to how they are bought and sold when everything must be supported systematically.
In the meantime, if you are interested, there are a number of XML translation tools and services emerging. These tools have prices starting at around $30,000 and climbing to several hundred thousand dollars. If you need help standardizing conflicting “standards,” start with SPS Commerce (spscommerce.com), PFN Inc. (pfn.com), bTrade.com, or Excelon Corp. (exceloncorp.com).
Ernie Schell, President of Marketing Systems Analysis, Inc., Southampton, PA, can be reached by phone at (215) 396-0660, by fax at (215) 396-0696, and by e-mail at [email protected].