What is an ERP Firewall?

In my last post, I made the argument that ERP applications are not designed to support the growing levels of outsourcing in today’s manufacturing ecosystem.  I think what is needed is an “ERP Firewall” for manufacturers to protect their enterprise systems from bad data.  Let me explain this ERP Firewall concept further:

ERP Firewall Defined 

ERP Firewall -         

noun

1.       fire•wall \’f?(-?)r,w?l\: an application which permits, denies or takes correction action to electronic data interchanges between an enterprises’ applications and its external business partners systems based upon a configurable set of rules or criteria. 

Restated, an ERP Firewall ensures that bad data from external business partners doesn’t enter your ERP system polluting the quality of information in your 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 documents which are not in the manufacturer’s list of standardized e-commerce processes.  For example, the firewall might block all ANSI X12 EDI formats which are not 810, 820, 850, 856 or 997 (or EDIFACT formats INVOIC, PAYMUL, ORDERS, DESADV, CONTRL).  As a result, a document such as a 214 or 824 which is not the expected input for any ERP module does not even pass the firewall.    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.

 

Firewall Severity Classes and Actions 

There are four typical actions that an ERP firewall might take based upon its configured rule set.  The action taken will, of course, depend upon the scenario encountered:

1.       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.

2.       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 hold the electronic document in an exception queue for the originator to review and repair.

3.       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 also log the data quality issues in a report.  The logged warnings should be trended for frequency and root cause.  The most common occurrences should be identified and remedied through collaboration with the originating trading partner.

4.       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 then forwarded for processing.  What other types of auto-fix functionality might exist?  Documents can be split and routed to different ERP systems.  Conversely, outputs from multiple ERPs might 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.

Manufacturers are investing tens of millions to consolidate, standardize, upgrade and extend their ERP applications 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.  An ERP firewall, which can be implemented at a small fraction of the annual maintenance royalty you pay your software vendor, can reduce bad data by up to 50% with just a few simple rule sets.

Also read and Download ERP Firewall - White Paper

Comments

[Martijn Linssen]

I like the idea Steve. A combination of default firewall functionality with business rules as they are managed by integration brokers
I see this as vision, yet far, far away. But we should strive to get there, at least to some extent

IBM's Datapower boxes do similar things, they're just not very flexible (a bit of XML and SOAP so far)
On a project earlier this year, I made acquaintance with ebXML's CPA - if you Google for it, you'll find most items to date to 2001 alone...

Both are challenging combinations of business and infrastructure. Nothing out of the ordinary really, as IRL there are lots of roads and bridges that allow for only a certain kind of traffic. It's just that the dynamics of infrastructure don't align very well to the dynamics of business

I'm used to doing business (EDI) at the level of business (applications). When all's said and done, the necessary infra changes are made (open Sesame!) and off you go. From then on, you can change the action and reaction to any business rule and exception on the fly

On the project mentioned above, which was a DBR one, severe problems were encountered trying to have the infrastructure keep up with the changing business (design and build) needs. That was also (greatly) caused by having a somewhat loose Agile approach to things (...), but it showed that the infra department is miles away from the biz & dev

I like a blacklist idea on this level though, as well as a whitelist. Return-to-sender in case of error is a great one as well. But isn't the limit to implementing rules like these imposed by the level of standardisation of the underlying business?

Currently, only gas, water and electricity are standard enough to be able "to pass the firewall" to all our different homes because they are extremely standardised, highly well-defined, and boringly static products. If we want at least part of IT to be able to follow suit, that would mean that our business applications would fit the above description... duller than dull!

Still, a challenge worthwile further challenging