5th rule of agile ERP: interface where possible

One of the biggest absurdities about ERP systems springs from the very word we use so often when describing ERP: integrated.

ERP is an integrated system: it integrates all data and processes into a single application. Different modules look over different aspects of data and processes, but a change in one module automatically reflects in all others.

A fantastic concept. When it was invented, it streamlined processes, boosted productivity and eliminated overhead and error.

So, whenever a new functionality is needed by a company, it should be integrated into the ERP, to benefit from the integrated system. Right?

Wrong.

There aren’t always clear boundaries between what ERP is and what it is not. Even though everything that comes as a part of ERP is integrated into this single application, it doesn’t mean that everything that a company will ever need to do with computers should end there as well.

Integration, or interface, is connecting to a functionality and/or data residing outside a system, to achieve more consistency, boost productivity, eliminate repeated data entry, eliminate overhead, eliminate error, or achieve any other conceivable benefit. Integration and interfaces are most commonly achieved by exchanging data between two different applications, but can include more tight mechanisms such as direct function calls.

It might be less costly to interface, or integrate with, than to integrate within, especially when it is about added value. There is a lot of pain, and little gain, in having your ERP handle scanned documents for example, with versioning, security, and all the accompanying gizmos. Instead of developing document-management functionality, simply integrate with SharePoint in a couple of soft spots and move on.

Document management is obvious, there might be less obvious ones. Shop-floor micro-planning, configure-to-order, process manufacturing, cost accounting, quality control, most of these don’t exist in standard NAV (not in every country local version, anyway). While these might be business-critical, they don’t need to go into ERP. Try to devise a leaner way, have your ERP handle what is absolutely necessary for it to handle.

I hear it in the background already: integrations are costly! Yes, they are. But customizations are also costly. And it’s the matter of elementary arithmetics. If customizing ERP and maintaining the customized ERP costs the same or less while delivering more value than developing integration with a specialized line-of-business application, then customize, by all means please do! But don’t just plain customize because integration is costly.

But, think of this. For most specific functionalities there are at least two kinds of solutions readily available: add-on solutions and standalone solutions.

If developed by a dedicated vendor who develops them as their mainstream activity (not as a side-job to monetize their customization effort beyond initial implementation), add-ons are much better choice than customizations. I’ve blogged about it in “Why is add-on better than custom, any day?”, and a lot of people have expressed their strong opinion on that topic there.

Often overlooked alternative are external standalone solutions. All that is true about add-on solutions regarding cost-effectiveness, functionality and industry expertise, is doubly true about standalone solutions. Since they are not meant to be deployed over one and only one ERP solution, they often have larger customer base (which means more know-how built into them), and they are rarely a bi-product of a highly specialized implementation where a consultancy decided to squeeze an extra buck from the market by packing their customization into an add-on. On the contrary, they are often very solid pieces of software, developed, maintained and supported by a dedicated company.

Sure, they don’t work directly with your ERP, you’ll have to integrate, or interface with them, and it will cost some money. But if you don’t need that functionality tightly integrated into the ERP data and processes, a highly specialized standalone solution with an interface to the ERP will bring you more benefits in the long run.

What must be integrated inside the ERP system is what the ERP itself can’t function without. Think about general ledger. If it wasn’t in the ERP, the ERP wouldn’t be all that integrated, because financial aspect of every transaction ends there. Interfacing that data from dozens of specific applications would be too costly to maintain and too prone to errors.

Now take a random non-ERP functionality. For NAV, it can be quality control in chemical manufacturing. It doesn’t reflect in general ledger, it doesn’t share any master data except possibly something about items, it may halt the execution of a production order or posting of an inventory receipt. But if that’s it, and you have a fantastic standalone quality control application, don’t replace it by an ERP customization. First, you’ll never get to the functionality level of your standalone application. Second, if you do, it’ll cost incomparably more than a simple interface that would transfer a few flags, master data entries and notifications between your ERP and that application.

To achieve an agile ERP implementation, draw clear boundaries between the things your company does inside and outside of the ERP. Not everything needs to go into the ERP. A lot of stuff barely has a few touching points with ERP—everything else can live happily outside it. For everything that doesn’t absolutely have to go into the ERP, just develop an interface and maintain it.

This way, your ERP implementation will be shorter, cost less, and likely give you a predictable and sure return on investment. Customizing a standard ERP to the world’s end might easily be customizing it to… your end.