ERP Without Custom Code?
In the 1980s and 1990s, writing custom code was a standard part of an ERP software implementation. Custom software development was used to fill gaps in ERP functionality, work around unique processes, and integrate outside systems. In many cases, off-the-shelf technology like Visual Basic, FileMaker, Access and FoxPro was leveraged alongside the ERP implementation to make this type of development efficient and somewhat affordable.
However, in recent years, custom software development as part of an ERP implementation has become an outdated and cumbersome solution, thanks to new best practices filling the voids present in legacy software. Just a few of these practices include:
Seamless customization features. Modern ERP systems offer an array of options for customization without bespoke code, such as robust custom fields, tailored printed documents, advanced workflows, and user-modifiable reports. These types of features allow many processes that previously necessitated custom code to instead be handled with the software’s built-in capabilities.
Out-of-the-box integrations. Legacy ERP systems were often limited in their integration capability. Modern solutions offer a wide variety of out-of-the-box, direct integrations with e-commerce systems, payment processors, business intelligence (BI) tools, shipping carriers, and third-party products.
Increased capabilities. Many legacy ERP systems were limited in scope to basic financial and operational applications – financial accounting, order processing, purchasing, inventory, and manufacturing. More complex tasks, such as customer self-service, shipping, warehouse management, barcoding, CRM, and time tracking needed to be handled with third-party software, which in turn necessitated custom integration. But many modern systems, including Bizowie, provide these advanced functions right out of the box – no third-party software or custom integration necessary.
Simplified EDI. In the past, EDI integration was often a costly endeavor. Custom code and mappings would need to be written linking the ERP system to each counterpart you wanted to connect with. But cloud-based solutions and broadband Internet have made EDI much easier than it used to be. Third-party VANs (Value-Add Networks) allow you to maintain only one EDI connection – between the ERP and the VAN – with the VAN performing mappings directly with the vendors and customers you wish to communicate with.
When custom code is necessary
Sometimes, custom development is unavoidable. Perhaps you have a homebrew e-commerce system handling unique facets of your business that you can’t easily move away from. Maybe you need to integrate with a vendor or customer who isn’t able to use industry standard methods of communication like EDI. Or perhaps you even need to collect data directly from a variety of equipment or IOT-based sensors throughout your plant.
In cases like these, working with a software developer may be the right way to achieve your needs. But keep these best practices in mind to ensure a seamless experience.
Utilize APIs instead of bolt-ons or direct database access. Many modern ERP systems offer Application Programming Interfaces (APIs) that make it simple for third-party coders to manipulate data and perform functions in the software. Instead of providing a direct connection to the software’s source code or database, APIs use a predefined set of inputs and outputs to perform actions, meaning that upgrades won’t break your functionality or force you to re-implement your code… even if the software source code or database schema changes.
And unlike the unwieldy APIs that were all too common in decades past, modern systems like Bizowie offer simple JSON-based interfaces that allow programmers to rapidly prototype and develop integrations without complicated XML.
Limit the scope of your integration. When working with your developers to put together a specification, carefully consider the process being utilized and any unusual exceptions that may come up. If there are many possible exceptions, consider which ones can be handled manually and which should be handled by your custom code – as code becomes more complex, the probability of error increases.
Future-proof your code. While use of APIs provide a standardized way to communicate with ERP systems, it’s possible for the data they provide to change. The data structures returned by APIs may be expanded to provide a broader range of data, and actions you perform in your ERP (like changing settings or creating/deleting custom fields) may impact the data returned by your ERP’s API. Make sure that your programmers build their integrations in such a way that unidentified fields are ignored, instead of erroring out.