CEC Europe | Papers & Case Studies: e-Procurement

E-Procurement - Integration with Suppliers

by Terry Woodgate
Head of Electronic Supply Chain

Introduction

The contents of this paper have been compiled from practical “hands on” experience gained during a variety of e-Procurement implementations across Europe, within the IT supplies sector. These initiatives adopted either a full buyer to supplier integration using “punch out” solutions or provision of static electronic catalogues. Integrations have been executed with various solution providers like Ariba, SAP, Oracle, Click2Procure and CommerceOne as well as bespoke point to point systems, resulting in over 200,000 electronic orders per year.

Having collaborated with several high profile multi-national organisations, across diverse industries, I can offer what I hope you consider is positive and useful commentary as well as some observations to improve the overall success of the integration between buying party and supplying party.

Sourcing & Procurement Strategy

Generally an e-Procurement initiative is strongly linked to, or indeed part of, an overall enterprise sourcing and procurement strategy. Adopting a full integration between procurement system and preferred supplying parties will lead to more disciplined and compliant processes and more importantly will take full advantage of pre-agreed terms and conditions – thus maximising cost benefits. However, supplier selection must not be isolated to the terms they are willing to offer but must take account of their ability to support electronic processes throughout and beyond the current initiative lifecycle.

Additionally the term e-Procurement should not just be considered as an electronic ordering process or e-enablement of a current purchasing process, but should be viewed as the whole purchase to pay chain, including electronic catalogues and electronic invoicing and matching.

There are many opportunities to remove traditional transaction “touch points” and consequently manual intervention, by converting specific processing elements to an electronic process. Additionally there are likely to be revised procedures and uses of data adopted by the buying party, again with a view to taking full advantage of the new procurement application. Therefore it is critical that the source organisation has a clear vision of new procedures/processes and any changes to the use of key data attributes. Failure to recognise, predict and model these new processes and data manipulation with the supplier, may result in transaction “events” which could impact data quality, productivity and impair anticipated cost reductions. It could also hinder the management of change within the organisation.

The Collaboration

In order to minimise the impact in these above areas it is crucial that the buying party and supplying party fully understand the fine detail of the process and interaction between systems – transaction content (data attributes), onward functionality and flow. Furthermore the supplier should have an opportunity to view the actual process and procurement application(s) from the buyer perspective. This can be very useful in identifying elements within the buying process which are not visible or realised by simply looking at the electronic transaction schemas. For example:

Manually entered data – potential data inconsistency
Intended use of key data further up the chain
Concatenated data / data manipulation – purpose and implications
Potential length of key data attributes – compatibility with destination system
Data formatting

Order data must be mapped (translated) by the source system and then re-mapped by the destination system prior to order load into the supplier mainstream system. As it is rare for the two parties’ transaction systems to be identical, certain data may have to be mapped on a “best fit” basis as data attributes in the source system are not likely to be of the same structure and length as the destination system.

It is therefore of paramount importance that the buying party confirms from the outset, the key data attributes, their methods of data capture in the procurement system and onward functionality, so that the supplier can determine any areas of incompatibility or where quality of data may be impacted. Similarly it is imperative that the buying community have minimal opportunities to deviate from the agreed data format procedures. The more process information which is known “up front” then the better prepared both parties will be. This is particularly important for the buying party in setting internal expectations during this critical period of acceptance and change.

Sourcing & Procurement Strategy

The Process

For the following examples I have assumed a full buyer / supplier e-Procurement integration using a “punch out” web shop solution (e.g. Ariba). This type of process will minimise but may not negate transaction discrepancies caused by price variance, product end of life and availability issues. Many of the examples will also apply to systems driven by static e-Catalogues with electronic ordering, however this type of system may result in a higher number of transaction issues due to catalogue content aging, the frequency of update and type of product involved.

Generally an e-Procurement initiative should involve at least the following standard transaction process components:

Electronic Supplier(s) Catalogue or Punch Out web shop
Requisition and requisition approval process
Purchase order generation
Product classification and management reporting
Inbound / Outbound message translation software (e.g. Microsoft BizTalk). Message translation into XML / EDI type formats.
Message delivery and transmission status mechanism
Application to process an order status message from the supplier (e.g. acknowledgement, rejection, shipment)
Process to change and/or cancel a purchase order with supplier(s)
Integration between buying party procurement system and buying party back office system / ERP
Mechanism to process electronic invoices / credits
Invoice to Purchase Order matching process
Payment process (Open Account or Procurement card)
Returns authorisations

Data Elements

Address Data

There are a number of areas of data which may cause mapping conflict, manual processing or issues with order delivery, if they are not identified from the outset. For example, within the delivery address schema of an XML style order message (Figure 1) there are an “infinite” number of characters supported in an address line. In reality there may only be a maximum of 40-50, depending on the intended use of that address line. If it is, for example, a manually entered “deliver to” reference, then this may result in multiple format styles from multiple buyers. Alternatively the “deliver to” reference could represent a contact name + cost centre + department and thus exceed the number of characters supported by the supplier ERP system address line or contact name schema.

Figure 1 – XML Order Schema sample

<Name xml:lang="en">The Test International Electronics Company S.A.</Name>

<DeliverTo>Jean-Marie Chessel/B427A/Room 16, First Floor

Purchasing</DeliverTo>

<DeliverTo>Test International Electronics Company S.A.</DeliverTo>

<Street>Chemin du Feu Route Nationale</Street>

<City>Le Grand-Chevrier,Geneva</City>

<Country isoCountryCode="CH">Switzerland</Country>

</PostalAddress>

The key point here is that the supplier must map this “long” address data string to a data element in their ERP addressing system. That same address element is likely to be used as part of the consignment delivery address for the carrier. Consequently this “deliver to” data may carry critical information for the order originator and/or the order recipient and may be truncated due to its abnormal length - consequently its significance lost in the process. Further complications may exist if the supplier does not inventory a product but uses a third party to ship to the customer, in which case there could be yet another address schema to consider.

As many ERP systems have a fixed address schema and a limited number of characters available per address line, it is obviously critical to understand what the intentions are with even a simple data schema like delivery address and what is the source of the data – drop down menu, or manually entered by the buyer. Similarly what data attributes make up a contact name or address line. Are there any non-standard address elements present which will impact the destination address schema or where there is onward functionality or reporting expected? Many days development could ensue if issues like these are not identified until the order testing phase or beyond, thus impacting not only the full implementation but also the management of acceptance of change.

Pricing Data

Pricing is another area worth recording here. Even with an “on line” punch out model there can still be discrepancies between buyer and supplier regarding pricing. Take a procurement system with a hierarchical authorisation process.

There could be several days delay between “checkout”, authorisation and order transmission and thereby receipt by the supplying party. With volatile products (e.g. IT hardware) the pricing may change regularly. Even with a custom pricing agreement, a change to a supplier buying price may impact a cost+ agreement. Similarly product availability (viewed at point of checkout) may also be impacted. Both the buyer and supplier need to adopt a system to manage this type of pricing irregularity in order to minimise any verbal communication and onward process issues e.g. invoice matching. The “electronic” Purchase Order on the buyer system must match the corresponding order at the supplier, in order to maintain transaction integrity. Ideally the supplier system should be capable of calculating the variance (order line price versus current price) and only reject or suspend the order / order line if the agreed variance or tolerance is exceeded. The buyer would not be very happy if after waiting five days for an authorisation, the order / order line was rejected by the supplier due to a minimal price variance and the whole requisition process had to be re-started.

Alternatively there are more sophisticated ways of handling data this type of event. Some procurement systems allow an order acknowledgement message which may include, by order line, price updates, line rejects (perhaps due to product discontinuation), delivery schedule updates and so forth. In order to maximise the potential of this type of transaction then both sending and receiving systems need to be able to take advantage of the information by updating the attribute amendments in the originators system thereby maintaining the transaction integrity. However this type of sophistication adds a high degree of complexity and development costs to the whole process.

Electronic Invoicing

The pricing issue above becomes particularly relevant if an open account periodic invoice is requested (i.e. all transactions over a period are grouped to form a single invoice). In this instance the whole periods invoice could be rejected due to a single transaction pricing mismatch, causing the buying party to delay payment and the supplying party to set a credit hold status to inhibit order processing.

Although this style of invoicing is being requested, my personal advice would be to wait until the procurement implementation has stabilised before attempting to introduce this type of consolidated invoicing. Conversely certain businesses have taken a relatively fast track to electronic invoice processing by requesting simple .CSV files of invoices to enable easy uploads and matching to original purchase orders, while maintaining receipt of the paper invoice as the legal copy. Once this “automated” invoice/matching process has been adopted the need for a consolidated invoice may diminish.

Delivery Schedule

Some XML procurement systems allow a delivery schedule by line item. Not all receiving ERP systems can accommodate this, so features and functionality between both parties requires mapping and discussion at an early stage in the project in order to uncover these types of irregularities.

Product Classification

There are various industry standard categorisation and classification methods (e.g. UNSPSC – United Nations Standard Products and Services Code – www.unspsc.org) is one. These standards are becoming more widely used in support of eCommerce projects. They tend to be implemented in major corporations as part of a strategic purchasing / supply chain initiative enabling associated reporting and classification of products and services across the enterprise. Provision has been made for them in major e-Procurement systems like Ariba Buyer, Oracle, CommerceOne and SAP.

The UNSPSC is a hierarchical classification system, having five levels. The levels allow users to search products more accurately (as searches will be confined to logical categories and irrelevant hits eliminated) and it allows managers to perform expenditure analysis on categories that are relevant to the company’s situation.

From a supplier perspective a “home grown” classification system may be in use, focussed more on internal business requirements rather than external influences. Consequently the supplier may have to adopt a new standard of product classification, potentially solely for this initiative. The supplier would need to cross reference their own classification system to that required by the buying party, in order that any electronic catalogue or punch out transaction carried the correct reference. This may add a number of day’s development at the supplier to accommodate this.

Defective Products

A buyer creates a requisition for a product via a punch out option and then waits 3 days for an authorisation/approval. The order is transacted, but on delivery the item is found to be “dead on arrival” i.e. defective. Although this is not a regular occurrence it does happen periodically.

Both parties need to consider this “event” and discuss the available options prior to implementation. There may be a “workaround” solution for the small number of occurrences, with which both parties feel comfortable and secure. However the process discipline and procedures may be inflexible, for all the compliancy reasons mentioned throughout the document. If this is the case then it is crucial that there are pro-active and pre-emptive discussions with the buying community at an early stage and this “event” put into perspective. Any negative service issue like this can once again impact the management of change and overall acceptance of the “new system”.

In Conclusion

There are certainly many documented advantages in implementing an e-Procurement solution, particularly if the option of full integration is selected. However in order to achieve maximum benefits there are areas of process which must be very carefully considered or the full expectation and payback may be compromised. Additionally a revised sourcing strategy together with a more disciplined requisitioning and ordering process will require strong change management and empowerment. Understanding the detail and potential process “events” is a critical factor in supporting this change, for both the source and destination parties. Generally both parties become fully engaged in ensuring their applications can support the new data flows and processes, however this must not be a parallel process but an entangled process, in order to fully identify and resolve the inevitable issues which will arise. Both parties have to benefit from the cost reductions in order for the solution to be considered successful.

For more information please e-mail us or call Consulting on 44 (0) 20 7251-4646