Integration of standalone ERP systems - the pros and cons
Depending on your situation, there are a number of ways to involve yourself with the value of ERP ranging from the clean-sheet purchase of an existing system, to interfacing or integrating your current systems with one or more individual ERP modules. While these decision points may appear to be pretty simple they aren’t since you always have to consider the fact that ERP processes, tend to subsume and alter the ways that enterprises behave once they are entirely spun up.
Consequently, leaving the ‘new ERP smell’ aside, let’s take a look at three ways that either ‘interfacing’ or ‘integrating’ your standalone ERP system can offer the promise of more business efficiencies; or in the inverse, of face the potential of experiencing one or more painful outcomes. Before we get started, however, you’ll need to understand the differences between ‘interfacing’ and ‘integrating’, since operationally these words create entirely dissimilar values.
Interfacing vs integrating
In simple terms; ‘interfacing’ one standalone ERP system with another represents the bridging of two dissimilar systems; or in the case of software, creating a linear relationship between two separate applications that allow initial information products to be created, then pushed along to a secondary application; while not necessarily interoperating directly. Typically, these binary relationships exist at the data level, where one system produces low-level records that are, in turn, passed through an ‘interface’ to a secondary system via various follow-on processes. Ultimately, this extended technical relationship experiences to further manipulation that leads to final sets of consolidated results.
Considerations associated with the ‘integration’ of standalone ERP systems involve a host of additional complexities, and consequently, offer a host of ways to either get it right, or blow an entire enterprise infrastructure should you get it wrong. In this case, the mating of what were originally dissimilar systems involves the melding the two systems from the data-side to the user interface, in order to marginalize any likely errors between the selection of a function to pushing the ‘Enter’ button. This means that ‘every process’ associated with both software frameworks must be compliant with the other. If you do your work accurately you’ll get expanded business capabilities, but if your development team does a bad job, or a third-party partner offers more sales vaporware rather than operational viability, the inverse will occur.
So, applying either of these approaches offer both up and downsides at the enterprise level; and consequently here are just three potential outcomes from the evolutions.
Pros of integrating standalone ERP systems
Typical concerns associated with standalone ERP systems happily coexisting within a singular enterprise framework, are not usually much of a problem. However, the larger question, then becomes, what business values will apply. In the first instance, interfacing can offer rapid and highly cost-effective ways to get more information out of an overall enterprise software infrastructure. This ranges from better business intelligence, to more detailed financial consolidations.
However, while the interface concept represents a fairly quick and dirty way to get from here to there; the leveraging of a full-blown integration offers the same values, only this time, times ten.
Cons of integrating standalone ERP systems
Now; the implications of using an ERP/third-party interface provides for a number of ways to fall off the road pretty quickly. First, many, if not all, interfaces involve some kind of ‘batching’ process where upstream data elements are pushed across the interface, received on the other end, and final work products occur on the basis of the execution of a tertiary operation. The rule here is simple, the more processes involved, the more chance you (or your system) will create some element that is non-compliant, and consequently, create an error condition that can cascade forward, and skew one or more final results.
In the case of integration, the same event(s) can occur, only similar to our expanded upside value, failure to ensure that all integration elements are entirely compliant with a primary system, can cause 10X problems, and in the event ‘could’ even cause an enterprise to grind to a stop entirely. So, be really careful in this option, and if you and your IT people don’t feel confident in your research, and pre-purchase testing just say ‘No’ and leave it at that.
Second, as the old saying goes, ‘you get what you pay for,’ so the potential of interfacing may look to be tempting if you base your decisions on price alone. That said, are you going to get what you think you’re paying for in the end? Deciding on an integration approach can cost you a lot of money, just to create an enormous mass of information that is meaningful. So, in these events this is where you, and/or your IT cadre, need to be heads up and ready to drill down to the degree necessary to avoid wasting money, that could be better directed elsewhere.
There you have it, some things to consider when looking at either interfacing or integration with a standalone ERP system. As usual, these are clearly not the only things to worry about, but they should get you on the tracks to a better than average decision.
PLM and ERP: what's the difference and do you need both?
We explain the crossover between PLM and ERP, and how this affects your software requirements
Quickbooks: integrate or abandon once you’ve selected ERP?
Should you integrate Quickbooks with your new ERP or move to your ERP's financial management tools?
What ERP workflow integration can do for you
Workflow integration is entirely based on the delivery of faster, more efficient decision-making ...