One of the most pernicious myths about electronic trading is that it’s about selling. It’s a myth because e-trading is about so much more. It’s pernicious because, though e-trading is immensely powerful, treating it only as a sales channel invites disaster, as we’ve seen for two Christmas seasons in a row. Logistics is only a fraction of the story. Many of the problems arise because there is poor integration between all the systems involved, particularly between fancy web front ends and the back-end systems that do all the real work. But the real issues hardly concern technology at all. Dan Roberts of industry consultancy Cambashi says consumers have learned to expect certain things from Internet purchasing, and business customers are even more exacting. If a website is to be an inviting place to come back to it has to deliver ‘personalisation’. Visitors expect to be recognised on their second and subsequent visits. They expect the site to track the pages they’ve looked at and show them only ‘relevant content’. Roberts notes that customers also expect order tracking and, if they’ve bought from you before, a discount. The sales manager, meanwhile, wants a system secure enough not to reveal to customer B the discount he’s offering customer A. All this implies access to customer data – whether in a customer relationship management (CRM) system, or the sales order processing or customer order management system. “Making sure all this happens,” says Roberts, is “complex, and not cheap.” Doug Miles of business planning systems supplier Infor:Swan says discounts are a particular problem: “Sales order processing has developed over many years in most companies, and you would not believe the complication of discount structures – customer special pricing, special pricing on parts, special pricing on delivery – that is ingrained in these systems.” Often there’s a stark choice between trying to keep the flexibility these discounts give the sales force and abandoning it to suit web trading, even though web trading is still only one of many sales channels. Customers also expect to be able to configure the product. For Roberts this implies a link back to a product data management (PDM) system. Miles points out that even sales configurators can be too complicated for non-specialist outsiders to use. But even if a configurator is fit for outsiders to see, can you replicate it on your website? Says Simon Bragg of analyst ARC: “The problem is integrating the configurators with manufacturing scheduling. Manufacturing configurators tend to be different beasts to the front end sales configurators.” Manufacturing configurators need to interface to scheduling systems and they have to go deeper into the bill of materials to find out what subassemblies can be combined and what can’t. “The challenge is to combine sub-assemblies below the top-level Bill of Materials into one batch to get manufacturing efficiencies.” Manufacturers offering ‘available to promise’ or ‘capable to promise’ may have to connect incoming sales back to the supply chain management (SCM) systems they use to order components or raw materials. Payment systems offer another challenge. Then you have to solve other problems: “How do you do end-to-end traceability?”, asks Bragg. “If you’re in the dairy industry you need to trace a rotten pint of milk not just back to the cow but to what she ate.” There are systems that will do it. The size of your integration problem, says Bragg, depends on what you have got to begin with. ERP, as ever, sits at the centre. David Atkinson, e-commerce strategist with Sun Microsystems, lists the main back-end systems as human resources (HR), financial ledgers, ERP, PDM, BoM and high performance computing. To Sun, these are all linked into an enterprise applications integration (EAI) layer which uses XML messaging to link the home system with those of suppliers, customers and partners over an extranet. So for Atkinson, XML is central to the integration issue. Every ERP provider will say they provide back end integration: “The question to ask is ‘does your system support XML?’. If it doesn’t support XML you have to go through a few extra hoops to do back-end integration.” EAI, he says, “can be as complicated or as easy as you want.” But you can get it out of the box, he insists: “If you have a pure XML feed, i-Planet Fusion will work… In theory, as long as two applications can swap XML files then they should be up and running.” In reality, says Bragg, most manufacturing ERP users lag three or more versions behind the current version. Now they have to share the data these legacy systems store and use in various horrible formats with the outside world, though there are ways of doing it. Bragg mentions solutions from webMethods and Extricity, which extract data from these systems and present it in XML. Even then, says Bragg, “The technology of shoving data around is the simple bit.” The real problem, he points out, is defining the processes between separate businesses – about how suppliers introduce a new product or change a price, or about how customers place a sales order and how the supplier then acknowledges it. Bragg points out that the US Collaborative Planning, Forecasting and Replenishment Committee, made up of retailers, manufacturers and solution providers (www.CPFR.org) has developed a set of business processes that describe in detail how two companies need to work together. “Technology,” says Bragg, “is 15% of the problem.” Atkinson concedes that users have to change what they do. His chief target is that old favourite, rekeying – which he says is still “endemic”. It’s common for information from front-end websites to be rekeyed up to eight times, once for each of the back end systems it needs to talk to. For Mark Holmes, European e-business practice director for Lotus’ professional services offshoot, “too many companies are bedazzled by the technology. They should ask themselves what they need to do for the business. ‘What do we need to tackle first, and what are the inter-relationships between those things that we need to tackle?’.” Integration is critical He cites a big car dealer communications system Lotus built for Daimler Chrysler in South Africa: “it provides everything from press releases to new product information and prices – and Shell Chemicals’ Shell Inventory Managed Order Network. Says Holmes: “We invariably find we end up cutting across three or four different systems. Once we trap the information and model the workflows, we find the billing’s in one system, the inventory records in another, plus a customer service system or helpdesk, and a product configuration in another system. “Most of the risk that you manage in a project is around the integration,” he adds. The biggest technical variable is operating systems, which “have a major influence in terms of your ability to manage risk.” It’s not just a matter of connecting this Unix system with that NT system either. Holmes speaks of interconnection problems involving persistence, fault tolerance, fail-over and other characteristics. “You want to join these up, but the customer wants to understand not only what you’re doing in terms of supply but what you are doing in terms of implementing the change orders they’ve passed down; what you’re doing in terms of quality conformance and in other ways.” There’s always some juggling to do. Miles points to Ascom UK, which supplies franking machines and other post room equipment. It sells consumables on a website and promises to deliver orders taken before 4.30 pm the next day. Miles says that, at first, the way the website collected and aggregated the orders and returned them to the back office didn’t match the 4.30 delivery schedule, so the systems had to be changed to put the two in synch. Now the system, piloted in Croydon before Christmas, is being rolled out to Ascom’s other sites.