ERP Integration Considerations for Manufacturers

    3/21/18 10:00 AM

    erp_integration.jpg

    Guidelines for when integration of your ERP with a 3rd party application is appropriate

    The upside to buying enterprise resource planning (ERP) that is not custom-written exclusively for one company is the economy of scale. Since it is written for the masses, the cost per user plummets. Microsoft Office certainly costs much more to develop than the few hundred dollars it costs to license. One of the other upsides is thousands or tens of thousands of users create a robust community that quickly flushes out weaknesses in functionality, helping the software become stronger.

    The downside is that the ERP may not be totally in sync with the company’s culture and that’s when thoughts of ERP integrations come to most people’s minds. What some may call a production order, the ERP may refer to as a work order. Some screens may be laid out differently than what the company would have done. The process the software supports may not be in total alignment with the current processes.

    Most companies can’t afford a custom solution, nor do they have the expertise to design one. ERP development is not their core competency. The good news is there are ERP products that have been on the market a long time and matured over the years to offer broad, deep functionality to fit many situations.

    Learn the common sense process to help you choose the right ERP software

    It will come to no surprise that most companies opt for the non-custom ERP solution. It’s the most economical solution; it’s the best decision too. (We sell two: CloudSuite Industrial and VISUAL.) We have replaced a lot of “home grown” custom decisions. Oh, the expense and heartache they could have avoided if they came to us first!

    A deeper look at “software fit”

    There is still the issue of “fit” though. Common wisdom is that non-custom software will only be a 90% fit. Just because that’s common wisdom doesn’t make it right. Let’s go over the potential solutions that need to be explored before you consider integrating another solution to your ERP. Here are the areas that need to be considered first:

    1. Software functionality. It’s very dangerous to look for a solution outside of ERP if you don’t fully understand the ERP you are currently running. Chances are you bought or are thinking about buying an ERP system because you wanted an integrated system. Don’t start recreating your past environment. Remember, just because you or your team doesn’t understand how to solve a business problem in the ERP doesn’t mean it can’t be solved in the ERP. There is no shame in not being a subject matter expert in ERP. I know it’s very tempting to just use a spreadsheet or some other solution that you or your group understands. Long term, the odds of this being the best solution is really stacked against you. Reach out to an expert to help guide you to a solution. It’s the cheapest path in the long run.
    2. Change your procedure to match the software. This somewhat flies in the face of the conventional wisdom of, “We want the software to work for us, not the other way around.” Although that statement is true, changing your procedures to take advantage of the features in the software is not “working for the software;” it’s taking advantage of the software! It’s becoming more efficient. I remember talking to a controller of a large, complex manufacturer about six months after they went live. During the implementation, we brought multiple companies into one database and eliminated dozens of Access databases they built over the years. Everything they did was now in one ERP system. I asked him how everything was going. He told me, “Once everyone stopped fighting the ERP and accepted the new procedures, everything went great. We are getting the information we need to run the company.” The fighting he was referring to actually wasn’t fighting against the software, it was fighting against change, against learning curve. Leaders need to guide their teams past this stage.
    3. Reports. There is a lot of data in an ERP database. Sometimes you can’t see exactly what you want and in the format you want it. You could just be a report away from getting the information you need. When thinking of reports, don’t just think paper. There are plenty of tools that can be used to bring the data to your computer screen, even in real time. Also, most ERPs let you push data to Excel (this is different from entering data into Excel, which should be avoided). Excel can also be configured to pull data from the ERP database. In both cases, Excel is being used as the presentation layer for your data.
    4. Personalize the ERP using tools within the ERP. Every ERP software I’ve worked with has tools built in to allow you to personalize the software to your needs. You can add fields and functionality as needed. This allows you to address any unique business situation you have within the core ERP solution. Notice I’m using the word “personalization,” not “customization.” A personalization means you are using the tools in the software the developers provided. These personalizations typically survive upgrades. A customization means the developer is changing the source code of the software just for your company. This gives you a unique version of the software you are running. It can also complicate upgrading your software down the road. I never recommend customizing software.
    5. “Bolt-on” functionality to your existing ERP. This strategy is used when a solution is needed that would be complementary to the functionality already existing in the ERP. Commission calculations is a good example of this. The ERPs we sell allow a different commission level, with different commissions sharing rules for each line item of the customer order. It works flawlessly, but we had one customer that didn’t like it. Their problem was the system they created. They had commission rules, but then had 12 pages of exceptions. The time it took to modify each line item of each order to satisfy all their rules was painful. Heck, just figuring out the commission was painful. The bolt-on we created for them took the information from the customer order, ran it through the commission rules we created in the bolt-on, and then populated the proper commission fields with the correct rates in the ERP. The ERP still handled the commissions the same, it just got the initial information much quicker.

    There are reasons to execute ERP integrations with other software systems

    If you get the impression I’m trying to talk you out of doing an ERP integration into another software package, you are partially right. My actual message is don’t do it for the wrong reasons. An ERP integration should be your last option for a solution to your business issue. Too often, I’ve seen it be the first or second option, because we use the tools we know. But there are valid reasons to integrate your ERP into another software package. Usually this is done when the functionality needed is totally out of the ERP realm. An example of this would be an ERP integration into a CAD package. ERP and CAD serve completely different purposes; one can’t replace the other. However, information in CAD is used in ERP, and vice versa.

    Like anything else in life, the key to success is to execute a well-thought-out plan. Here are the areas to consider for ERP integrations:

    • Data points. Determine what data needs to flow, when it needs to flow, and in what direction. Remember, just because you can, doesn’t mean you should. Keep the data points to a minimum to limit the complexity.
    • Define the alpha software. This falls in line with your data strategy. Typically, your ERP database should be the home of all the data you need, so it is the alpha. Any other software package exists to provide data to the ERP. This certainly isn’t a rigid standard, but there should be a strategy to try to achieve this. Otherwise, you will end up with many silos of information, and you don’t want that.
    • Determine who is going to write the interface. Since the ERP is usually the alpha software, typically the interface is written by someone who has deep expertise in the ERP. Help may be required from an expert in the other software, but the project is still led from the ERP side.
    • Define the method to move the data. There are many choices here and the developer will be able to define the preferred method and why. Some of the options include using existing APIs (application programming interfaces) built into the software, or building a point-to-point interface.

    If I leave you with just one take-away, it’s this: Always make sure there is an ERP expert involved in any decision to introduce another software solution next to your ERP to solve business issues. I happen to be one of those experts, let me know if you’d like to talk.

    Free discussion

    Topics: ERP research

    Jack Shannon

    Written by Jack Shannon

    Jack is the President of Visual South and has been working with the product since 1996 when he bought it in his role as a Plant Manager. Since 1998 he has worked for Visual South with roles in consulting, sales and executive management.