The real battle for e-procurement survival rests within the integration prowess of its implementers, and this battle is only beginning.
Now that most companies have, at least dipped their feet into e-procurement, a closer look at the landscape of activity reveals that what seemed to be wide-scale adoption is really wide-scale experimentation. The initial climax of the e-procurement movement delivered a plethora of choices in buyside solutions. The browser became the liberator of legacy systems that only purchasing managers knew how to tame. That browser gave qualified users the ability to tinker with the purchasing system and directly order goods or services. But was this behavior an expression of newfound freedom, a curiosity satisfaction binge or a true corporate strategy? The browser led us to experimentation, but will not get us near full-scale adoption due to its lack of integration capabilities. eProcurement must be married to computer-assisted automation, not human-initiated tasks. A full-fledged process integration is the acid test for e-procurement commitment.
Flavors of Integration
There is integration, and then there is integration. First, you can think of business integration versus technical integration. Then, there is front-end integration versus back-end integration. Although these classifications are really intertwined, separating them leads to failure. Looking at them together does not guarantee success either. In reality, e-procurement integration does not occur overnight. Here are the three major segments of integration evolution:
1) Data integration. Also known as data aggregation, it focuses on catalog integration. Vocabulary standardization and common taxonomies allow 45 disparate catalogs to look like one. Passing through this hurdle is necessary, but in no means sufficient alone.
2) Application integration. Usually the second step taken consists of connecting what appears to be a browser-based, front-end application (e-procurement) into the various enterprise-wide applications inside a corporation. This includes the following legacy applications: enterprise resource planning, financials, sales and marketing databases, customer relationship management and manufacturing planning. It also includes the automation of the workflow process - a buyside requirement - as well as EDI integration to the extent that existing practices move to the Internet. Application integration, also referred to as Web automation, gets us closer to filling the process gaps that link the procurement mega-process cycle; e.g. from order placement to inventory check, to special configuration, to production schedules, logistics, credit and customer support interfaces.
3) Supply chain integration. This is the ultimate destination. In simple terms, managing an electronic supply chain involves linking the demand side and supply side while allowing them to continuously share event status. If not done, the classic supply chain "blind spots" appear, where the supply side does not know where the demand side is, therefore leading to frequent inventory shortage or excess. These blind spots are amplified due to the efficiencies demanded by electronically linked participants. Supply chain integration demands cooperation obtained in one of two ways - either by a forced alliance between major competing supply chain participants, [e.g. Covisint (automotive), GlobalNetExchange (retail)] or by linking into a universal hub that automatically redirects e-process traffic to participating partners by smoothing the multiplicity of partner interface requirements into one cohesive bond (e.g Telstra's eConnect or Viacore.net). Some of the visible outcomes of broad supply chain integration include real-time collaborative forecasting, inventory allocation and replenishment, optimized logistics and lower restocking cycles. They all lead to reduced inventories, more accurate just-in-time manufacturing, intelligent analysis of supplier performance and more frequent customer feedback ‹ therefore directly impacting profit margins.