Getting it right first time isn't realistic when automating B2B procurement. Customers will face cultural challenges and should plan for their first implementation to fail.

	express delivery
	• print  • comment
	Technology is only half the story when automating B2B procurement. Business issues are critical factors in a project's success: Connecting separate departments requires new working relationships Being able to manage change is more important than getting the application build right first time Accommodating change at 'last-mile' connections to buyers or suppliers is key Economies of scale in procurement depend on a collaborative mentality Composite application assembly preserves existing investments
	Glossary terms: composite application, B2B, business process, workflow, EDI, lookup tool Sponsored links: your text link here

That's the advice of Narry Singh, chief marketing officer of Commerce One, who believes that corporate mindsets are as important in B2B as the technical challenges users face. He points out that successful cross-application integration breaks down the traditional barriers between departmental silos. As a result, individuals find themselves collaborating with new partners and departments for the first time.

A new more flexible style of composite application assembly is enabling faster, slicker integration across multiple participants. Composite applications consist of components of functionality drawn from different sources — including individual web services and outputs from legacy applications — that allow organizations to rapidly adapt their business processes. In effect, they bring business intelligence to basic connectivity. Commerce One, which has extensive experience in e-procurement but has struggled in the face of the hi-tech slump, released its own composite application platform, Conductor, in March.

Singh argues that in this new era of composite applications, customers should focus not on what it takes to build an application, but on what it takes to change it. "They should plan on the first system being wrong," he says. "They will have to build a system that can be changed rapidly, so they can't expect it to be perfect from the get-go." He adds that short timescales are essential: "If it sounds like a three-year project, walk away — it should be 90 to 120 days."

Commerce One was one of the pioneers in the B2B arena during the Internet boom, building electronic marketplaces that were designed to bring buyers and sellers together in a fast-moving collaborative purchasing environment. The concept of a public marketplace proved largely illusory, however, and although several private marketplaces have since performed well in sectors such as the automotive industry, Commerce One was hit hard in the hi-tech collapse. After securing significant investment from SAP and cutting back extensively, it focused its sourcing and procurement under the broader banner of supplier relationship management, while pouring development dollars into Conductor.

Lack of control

Singh argues that composite applications tackle the biggest problem that e-marketplaces faced — namely, that "the last mile is the killer". However adept the central technology platform might be in handling thousands of transactions, it's impossible to control the technology that's in use at the buyer and supplier ends. If there are any changes to the applications they use to support procurement business processes — even something as comparatively simple as adding a new signatory to an authorization workflow — they can have a significant technical impact on the central marketplace.

The Conductor project set out to isolate the key drivers that lead to disruptive change of this nature and manage them in a centralized repository. It contains a registry designed to handle four key elements of process change, beginning with a provisioning engine, which is designed to handle changes to the names or location of services, interfaces and interoperability. A semantics library manages the different types of business documents, while the "trust broker" caters for changes affecting the individuals who are authorized to handle different parts of the B2B process, covering roles, privileges, encryption and signature requirements. Finally, process mappings handle changes to the physical process, such as the adoption of different working methodologies.

Commerce One believes that early adopters in this sector are looking to solve several key process challenges. To begin with, they want to aggregate their spending in order to manage it better and benefit from volume discounts. In many organizations, procurement is decentralized using a wide range of systems to cover different types of spending, from specialist build-to-order purchases to office supplies. As such, they need to identify different demand sources (such as a forecast or bill of materials), categorize them and route them to the appropriate channel.

Specific challenges

As well as better managing the procurement process, Commerce One's dozen or so early adopters are also seeking to tackle specific individual challenges. Eastman Chemical, the chemicals and plastics manufacturer, uses Connector to connect its existing CommerceOne Procurement product to the Financials module in SAP's enterprise application suite. The linkage allows users to enter cost allocation information before submitting a shopping cart, which is verified within SAP in real-time. That checking process reduces errors and prevents the hassle of handling reallocation charges after the event. In addition, the company will be able to add purchasing account code verification to the buying process, allowing it to police the process and ensure that purchases are only made through approved suppliers that offer volume discounts.

Inevitably, these developments give rise to technical issues alongside the cultural challenges already highlighted. To begin with, while the Conductor product is built on open standards, users need to spend a short amount of time learning Commerce One's Common Object Framework and Rapid Application Framework, the underlying infrastructure used to develop and maintain composite applications. In addition, Singh argues that there are one or two "tactical" technical issues for customers to address. For one thing, he says standards in areas such as security are not robust enough to meet customers' demands, and while companies like Commerce One adhere to standards, they also build around them.

Above all, though, the message is that composite applications do not require customers to rip up their existing investments — rather, they leverage those investments. Many industry sectors have bought heavily into EDI networks, for example, to standardize purchase orders, acknowledgements and so forth. Composite applications will add a new dimension to those applications, not replace them — and indeed, in some instances EDI will continue to be the platform of choice where a critical mass of transactions need to be handled.

More on this topic