Protecting Mission-Critical Manufacturing Data with an ERP Firewall. A GXS White Paper for the Active Business

Transcription

1 Protecting Mission-Critical Manufacturing Data with an ERP Firewall for the Active Business

2 In today s manufacturing sector, outsourcing is becoming more the norm than the exception. Companies have become more and more specialized within their value chains. OEMs that traditionally were production-oriented are increasingly outsourcing many of their manufacturing and supply chain functions to third parties (contract manufacturers, freight forwarders, and third-party logistics providers). Back-office functions, such as accounts payable, human resources, and IT management are steadily being sourced to specialized Business Process Outsourcing (BPO) firms. The overall result of this outsourcing phenomenon is that manufacturers are more dependent than ever on business partners to perform daily operations. Additionally, enterprise IT systems are more dependent on data originating in the applications of these partners. In order to gain visibility to outsourced, external processes, manufacturers must be able to synchronize data in real time with their business partners. Thirty Percent of ERP Data Originates Outside the Enterprise A recent AMR Research report entitled ERP Projects Create Significant B2B Opportunities found that one-third of all data housed in an ERP system originated outside the organization. AMR found that external data came from three key sources: customers and distributors (43%), suppliers and contract manufacturers (31%), and third-party logistics providers and transportation carriers (17%) (see Figure 1). Source of Externally Originated Data in ERP 17% 9% 31% 43% Customers & Distributors Suppliers & Contact Manufacturers Third-Party Logistics Other Figure 1 AMR s study results put into perspective the critical role that B2B integration technologies play in enabling ERP. It also underscores the need to monitor the quality of information flowing in and out of external interfaces. Hundreds of millions of dollars have been invested in master data for products, customers, employees, assets, and suppliers in the past few years. However, there has been relatively little focus on information quality for nonmaster, transactional data related to a specific order. Data throughout the lifecycle of an order originates from a variety of sources (see Figure 2). The original purchase order might come from a customer. Shipment status updates might originate from transportation carriers and third-party logistics providers. Payment detail might be consolidated, enriched, and delivered by banking institutions. Unfortunately, these trading partners which conduct the highest volumes of B2B transactions (customers, suppliers, 3PLs) are also the ones causing the greatest number of data quality issues. 2 Protecting Mission-Critical Manufacturing Data with an ERP Firewall

3 Business Application Enterprise Resource Planning Procurement and Sourcing Transportation Management System Finance and Accounting Treasury Workstation Human Resources Information Technology Figure 2 Data Sourced from Outside the Enterprise Customer Forecasts, Customer Orders Product Catalog, Pricing, Promotions, Vendor Shipment Status, Import/Export Documentation Supplier Invoices, Customer Invoices, Remittance Advices, Payroll, General Ledger Bank Account Statements, Foreign Exchange Transactions, Securities Ownership Recruiting, Performance, Compensation, Employee Records Data Center, Network, Application Status, Trouble Ticket Status External Business Partner Sources Customers, Distributors, Brokers, Agents, Resellers Vendor/Suppliers Marine, Air, Rail Transportation Providers, Freight Forwarders, Customs Brokers, LTL, TL, Parcel Carriers, 3PLs Vendors, Customers, F&A BPO Providers, Payroll BPO Providers Cash Management Banks, Securities Broker/Dealers, Foreign Exchange Banks HR BPO Providers IT Outsourcing Providers Bad Data from Suppliers Supplier data is notoriously bad, especially from smaller vendors. However, buyers typically have leverage with suppliers such that they can require vendors to conform to data quality rules. Common examples of bad data passed from suppliers into ERP applications include: Shipment and Order Do Not Match Frequently, the quantities or part numbers in a shipment do not exactly match the original purchase order. Suppliers may over or under-ship quantities due to pallet configuration. One part number or SKU may be substituted for another due to inventory shortages or product discontinuations. Shipping Tolerances Suppliers frequently over-ship or under-ship relative to the quantity requested. For example, a buyer may have issued a PO for 500 units of a particular SKU. However, the vendor shipped a full pallet configuration consisting of 512 units. For high volume SKUs such over-shipments may be allowable as the inventory will be depleted quickly. In other scenarios with lower turn or higher priced SKUs, over-shipping may not be acceptable. Country-Specific Invoice Fields Each of the countries in the European Union specify that certain fields must be populated in an invoice for it to be considered legally valid. Examples of mandatory fields include VAT identification numbers, buyer/ seller name and address, nature of goods supplied (or services rendered), VAT rate, and amount paid. Several Latin American countries have introduced e-invoicing regulations in recent years as well. Invoice with no Purchase Order Buying organizations often use POs as a business control to ensure that only authorized personnel are placing orders with preferred vendors. The existence of an invoice without a PO suggests that someone is circumventing the normal procurement process. However, there are certain types of services such as telecommunications, utilities, and facilities leases for which there is typically no PO corresponding to an invoice. Protecting Mission-Critical Manufacturing Data with an ERP Firewall 3

4 Multiple Purchase Orders in one Invoice Most companies prefer that invoices only contain line items from a single purchase order. Mixing items from different purchase orders creates challenges during invoice approval, especially when the POs originated from different divisions. Different accounts payable organizations may be assigned to process invoices for the respective POs. Alternatively, the different POs may have originated from different ERP applications. Invoice on Goods Not Shipped Most buying organizations have negotiated payment terms of 30, 60, or 90 days with vendors. The invoice date is typically the baseline for the start of the payment period. To avoid premature billing, most buyers state that invoices will not be accepted until the goods have been shipped and the corresponding ASN processed. Invoice, Receipt and Order Do Not Match Frequently, the quantity, price, or part numbers on invoices do not match the corresponding fields on the original order or the actual physical goods received. In such scenarios, additional research must be performed before the invoice can be processed for payment. Bad Data from Logistics Providers Data from transportation carriers and logistics providers can benefit from an ERP firewall. Logistics data is frequently incomplete and inaccurate. Bad data leads to poor supply chain visibility, lack of carrier performance metrics, and inability to adequately plan receiving efforts. Common examples of bad data passed from logistics providers into ERP applications include: Missing Time Zone Many shipment status messages provide a date and timestamp for a logistics activity, but not an accurate time zone. Consequently, the date and time information are not useful for decision making or carrier performance measurement. Missing Quantity Many suppliers populate the quantity field in an ASN, but fail to provide the unit of measurement. For example, an ASN might specify that 3000 of a specific item has been shipped, but not state whether the unit of measurement is in kilograms or pounds (or individual units or cases). Missing Currency Shipment messages often contain the freight charges associated with a container or load. However, suppliers frequently do not populate the unit of measurement for the currency. Consequently, the customer does not know whether the amount specified reflects the currency of the originating or destination country. Meaningless Codes Buyers, suppliers and transportation carriers each use different codes in EDI documents to represent locations, vendors and countries. However, the codes are often company-specific, making them meaningless once they travel from one trading partner to another. 4 Protecting Mission-Critical Manufacturing Data with an ERP Firewall

5 Out of Sequence Due to the asynchronous nature of B2B communications, documents can arrive in a different sequence than the one in which they were created. For example, an ocean freight status message might arrive prior to the ASN indicating that the goods have left the point of origin. Backdated Shipments Suppliers and carriers sometimes attempt to backdate electronic documents for orders that were supposed to be fulfilled on an earlier date. Such a technique can enable suppliers to avoid costly invoice deductions or penalties for missed performance commitments. Bad Data from Customers Customers are the most challenging trading partner in terms of data quality. They are the greatest source of bad data, but often the group that companies have the least amount of influence over. Examples of common problems encountered with inbound customer data include: Discontinued SKUs or Part Numbers Manufacturers frequently change the part numbers or Global Trade Identification Numbers (GTINs) for their products. A GTIN or part number might be retired and replaced with a newer model when there is a substantial change to packaging, pricing, product features, or brand name. In other cases, a GTIN or part might be discontinued due to lower than expected sales volumes. Unknown Location Locations are often referred to as specialized codes in EDI documents. Customers may request that shipment be delivered to a warehouse, manufacturing plant, or retail store code that is not listed in the supplier s location database. Such an occurrence is common with new stores, plants, and warehouses. Inaccurate Pricing or Terms While sales orders containing invalid part numbers or ship-to locations can be corrected manually, errors in pricing or contract terms are not easily fixed. In many cases the transmission of a PO Acknowledgement constitutes acceptance of the customer s pricing, terms, and conditions. Suppose a customer transmits an order for 100 units of SKU ABC at a price of $50. However, SKU ABC s negotiated price for this customer is actually $500. Furthermore, the minimum order quantity of SKU ABC is 1000 units. If the supplier acknowledges the PO without correcting the data, they may be forced to accept the lower price and order quantity. Out-of-Sequence PO Changes Studies have found that the average Purchase Order changes 4.4 times during its lifecycle. Due to the asynchronous nature of B2B integration, it is possible that PO changes may be received by a supplier out-of-sequence. For example, the third update in a series of four might be received last (e.g. a sequence of ). If the supplier s ERP application does not re-correlate the sequence of changes then the order will be fulfilled incorrectly, resulting in customer satisfaction issues and possible compliance penalties. Protecting Mission-Critical Manufacturing Data with an ERP Firewall 5

6 Incomplete Order Data Customers sometimes send orders, forecasts, and requests for quotations without all of the required data fields necessary to process or confirm the request. Customers also use reference data that is meaningful to their internal applications, but not to their suppliers. For example, a customer sends their purchase order number or part number in a document, but what is needed by the receiving ERP application in order to process the request is the supplier s sales order number or part number. The Impacts of Bad Data Both line of business managers and IT personnel should be concerned about the consequences of this growing problem. Bad data pollutes a manufacturer s ERP system, resulting in decreased ROI from the ERP investment and a corresponding loss of productivity. A study by AMR Research conducted in the discrete manufacturing segment found that, on average, 2.9% of transactions originating from external trading partners required exception processing or error handling. The consequences of exception processing resulting from poor data quality are numerous: Longer Time to Process Time sensitive processes may be delayed while accounting, warehouse, and customer service personnel research and resolve data issues. For example, if an invoice is posted to an accounts payable system without a general ledger number to apply the cost against, then an accounting clerk must phone the supplier or internal buyer to capture the appropriate data. If a purchase order is pushed to an order management system with an invalid part number or SKU, then the sales organization must contact the customer to discuss an appropriate substitution. Higher Cost to Process Personnel must spend time and effort manually correcting data in the ERP application or fixing problems resulting from the processing of the bad data. Higher volumes of manual processing unnecessarily inflate costs and erode margins. For example, in the retail industry studies have determined that over 60% of invoices have data errors where each error typically costs between $40 and $400 to correct. More Mistakes During Processing The probability of an error increases exponentially as soon as manual processing begins. However, human intervention could be relatively inexpensive when compared with scenarios in which bad data goes undetected. Consider the costs of a manufacturer missing a contract commitment with one of their top five accounts? Or of fulfilling an order incorrectly with the wrong parts shipped to the wrong location? Individually, such data quality errors might seem like insignificant problems when viewed at a microscopic level for each order. However, the costs of increased Days Sales Outstanding (DSO) from invoice processing delays and customer penalties from failed order fulfillment commitments can quickly compound to have a material impact on financial performance (see Figure 3). 6 Protecting Mission-Critical Manufacturing Data with an ERP Firewall

7 USD Millions Costs of Processing Errors Cost per Month $600k $500k $400k $300k $200k $100k Transactions per Month (Thousands) Consider, for example, a $5B manufacturing company, which experiences a 2.9% error rate in its monthly transaction volume of 600K messages. The manufacturing company could be spending more than $500K per month just to resolve data errors on inbound B2B transactions. Figure 3 The Need for an ERP Firewall Why aren t ERP applications designed to capture these types of business process and data quality errors? Actually, SAP and Oracle can provide extensive business logic and data integrity checks within their applications. When an end user keys in data to a graphical interface, the native ERP business logic can be configured to detect a wide variety of errors. However, when the data flows through a B2B integration gateway and is subsequently uploaded into the ERP database, there is very little data checking that occurs. What can manufacturers running ERP do to prevent bad data from corrupting their enterprise applications? One option would be to hire a systems integrator to develop custom code to enforce data integrity standards for B2B imports and exports. Additionally, a new set of user interfaces would be required to manage exceptions identified by the data checks. Any customizations to ERP applications come with significant overhead. With each new release of the vendor s software, the customer must perform extensive regression testing and, often, software updates. Perhaps, a better option is to deploy an application at the edge of the enterprise that inspects incoming and outgoing documents from trading partners for data integrity issues. Such an application would effectively be acting as an ERP Firewall for bad data. The firewall would inspect the contents of EDI, XML, and other files in a Demilitarized Zone (DMZ) for quality of content. Bad data would be rejected to the sender or held in a queue for exception processing. Good data would be passed straight through to the ERP for immediate processing. The reality is that once bad data gets into the enterprise, it is the manufacturer s problem to deal with regardless of where it originated. An ERP Firewall is designed to identify and correct bad data before it gets that far (see Figure 4). Protecting Mission-Critical Manufacturing Data with an ERP Firewall 7

8 Customer A Customer B Customer C Customer A Customer B Customer C Customization to Support Large Accounts ERP FIREWALL Customization to Support Large Accounts Integration Middleware Integration Middleware Customization to Support Large Accounts Consolidated ERP Application Consolidated ERP Application Customer specific technology, business process and data field customizations within internal applications Customer specific technology, business process and data field customizations within internal applications Figure 4 ERP Firewall Defined An ERP Firewall is an application which permits, denies, or corrects electronic data interchanges between an enterprise s applications and those of its external business partners, based upon a configurable set of rules or criteria (see Figure 5). Customers and Distributors Financial Institutions ERP APPS Logistics Providers Direct & Indirect Material Suppliers Figure 5 8 Protecting Mission-Critical Manufacturing Data with an ERP Firewall

9 Restated, an ERP Firewall ensures that bad data from external business partners doesn t enter the manufacturer s ERP system, polluting the quality of information in their enterprise applications. Much like a normal firewall, an ERP Firewall examines all incoming and outgoing data against a pre-configured rule set. A traditional firewall rule might be to block all incoming clear text FTP traffic on port 21. Similarly, an ERP Firewall rule might be to block all ANSI X12 EDI formats which are not formatted, addressed, or structured correctly. Another example of a rule set might be to route any 810/INVOIC documents without a street address, general ledger code, or appropriate tax identifier to an exception queue for manual resolution by the supplier. ERP Firewall Severity Classes and Actions There are four typical actions that an ERP Firewall might take based upon its configured rule set (see Figure 6). The action taken will, of course, depend upon the scenario encountered: Fatal In this scenario, the electronic document is beyond repair. Not only will the document fail during later processing, but it could result in financial losses to the company or its trading partners if not stopped. As a result, the firewall should reject the electronic document entirely by sending a failure notification back to the originator. Error The electronic document has a critical error that will fail upon attempted processing. In this scenario, the error can be remedied, but only with the manual intervention of an end-user at the originating company. For such scenarios, the firewall should quarantine the electronic document in an exception queue for the originator to review and repair. Warning The electronic document has a minor data quality error that will not disrupt processing, but should be corrected, if possible, in future scenarios. The firewall will pass the document through to the ERP, but will also log the data quality issues in a report. The logged warnings should be examined for frequency and root cause. The most common occurrences should be identified and remedied through collaboration with the originating trading partner. Auto-Fix In this scenario, the original document has an error that can be automatically corrected by the firewall. This is the real power of the ERP Firewall. In many cases, bad data can be corrected automatically before reaching the ERP. For example, missing fields may be looked up in a table, database, or via an application web services call. The original document is then augmented or enriched with the new fields and then forwarded for processing. Addition auto-fix functionality can split documents and then route them to different ERP systems. Conversely, outputs from multiple ERPs could be merged into a single document. A fourth function is data filtering, in which unnecessary data can be stripped out of incoming or outgoing documents to simplify subsequent processing at the destination. Protecting Mission-Critical Manufacturing Data with an ERP Firewall 9

10 4 AUTOFIX Correct then Retransmit 3 WARNING Pass Through and Log EDI Incoming Document FATAL Rejectable Document ERROR Hold in Exception Queue 1 2 Figure 6 ERP Firewalls Necessary Data Protection for the Manufacturing Industry Manufacturers are investing tens of millions of dollars to consolidate, standardize, upgrade, and extend their ERP applications in order to optimize value from their ERP applications. However, these efforts are undermined and compromised when bad data from business partners corrupts and pollutes the ERP (see Figure 7). An ERP Firewall, which can be implemented at a small fraction of the typical annual software maintenance royalty, can reduce bad data by up to 50% with just a few simple rule sets significantly improving long-term ROI. ROI Payback from Investment in ERP Reduced by Poor Data Quality $600k $500k $400k $300k $200k $100k $- $(100) $(200) $(300) $(400) Year 1 Year 2 Year 3 Year 4 Year 5 Projected ROI Actual ROI Source: GXS-Hypothetical Analysis Figure 7 10 Protecting Mission-Critical Manufacturing Data with an ERP Firewall

11 About GXS GXS is a leading global provider of B2B e-commerce solutions that simplify and enhance business process integration and collaboration among trading partners. Organizations worldwide, including more than 70 percent of the Fortune 500, leverage the on-demand services on GXS Trading Grid to extend supply chain networks, optimize product launches, automate warehouse receiving, manage electronic payments and gain supply chain visibility. GXS Managed Services, GXS B2B outsourcing solution, empowers customers with the expertise, technical infrastructure and program support to conduct B2B e-commerce with trading partners globally. Based in Gaithersburg, Md., GXS has an extensive global network and has local offices in the Americas, Europe and Asia-Pacific regions. GXS can be found on the Web at Protecting Mission-Critical Manufacturing Data with an ERP Firewall 11

12 North America and Global Headquarters 100 Edison Park Drive Gaithersburg, MD U.S.A t t f Europe, Middle East and Africa 18 Station Road Sunbury-on-Thames Middlesex TW16 6SU United Kingdom +44 (0) t +44 (0) f Asia Pacific Room /F China Resources Building 26 Harbour Road, Wanchai Hong Kong t f About GXS GXS is a leading global provider of B2B e-commerce solutions that simplify and enhance business process integration and collaboration among trading partners. Organizations worldwide, including more than 70 percent of the Fortune 500, leverage the on-demand services on GXS Trading Grid to extend supply chain networks, optimize product launches, automate warehouse receiving, manage electronic payments and gain supply chain visibility. GXS Managed Services, GXS B2B outsourcing solution, empowers customers with the expertise, technical infrastructure and program support to conduct B2B e-commerce with trading partners globally. Based in Gaithersburg, Md., GXS has an extensive global network and has local offices in the Americas, Europe and Asia-Pacific regions. GXS can be found on the Web at Copyright 2009 GXS, Inc. All Rights Reserved. September 2009 A