You are adding more customers to your SaaS app all the time. And these same customers want you to provide even more value by integrating your app with their enterprise resource planning (ERP) systems.
Your dev team selects an ERP several of your customers use and investigates what it would take to build an integration. It seems straightforward. The ERP has an API that's been around for a while but looks well structured. Based on initial discussions with a handful of customers, they need a simple one-way data sync between your app and their ERPs. Your dev team agrees it can include this integration in the next few months.
Then, as you gather more data, you find out that your customers currently use 40 different ERP apps. And that number is only going to increase as your customer list grows. Further digging shows that many of your customers expect complex, two-way integrations with their ERPs.
Telling your customers that you won't build these integrations is a non-starter. If you don't build them, they'll find a vendor with a product like yours who will. Larger customers might be okay with building these integrations themselves, but smaller customers often lack the dev or IT personnel necessary to do the job. Turning your integrations over to a third party means you no longer own the customer relationship. So, somehow, you need to figure out how to provide these integrations to your customers.
The challenge is clear. And there is a way forward. Let's check out ERP integrations in more detail and see how you might best serve your customers.
What is ERP integration?
At its simplest, an ERP integration connects an ERP app and another app for data transfer purposes. This usually makes it an ERP API integration (since modern ERP apps such as Oracle NetSuite, Odoo, SAP S/4 HANA and Microsoft Dynamics 364 have corresponding APIs).
Since ERP products help companies manage their day-to-day operations, processes, and resources, these systems are often integrated with most other systems in the company. For example, payroll may be managed via a dedicated payroll system, but the data may be regularly sent to the ERP to be combined with other operating cost data for roll-up reporting.
ERP integrations can be either internal to a company or external (intended for a SaaS company's customers). Internal integrations are built for a single company's use and function entirely within that company's ecosystem. An internal ERP integration may be built from scratch, with its code custom-written by company employees or consultants, or it may be built using an enterprise iPaaS (integration platform as a service). In either case, the integration is designed to address business needs only for that company.
Customer-facing integrations are built by employees or consultants of a B2B SaaS company to enable data transfer between the SaaS company's product and the other apps its customers use. Such integrations may be built from scratch, built with an enterprise iPaaS, built with an embedded iPaaS, or built with a unified API. A customer integration must usually meet broader requirements than an internal integration because it addresses the business needs of several customers.
As you can see from this G2 Grid, many ERP systems are in the market today. Because of this, B2B SaaS companies often find themselves needing to build numerous ERP integrations for their customers.
How do you integrate ERP with other apps?
Depending on your business needs, an ERP integration can be created in several ways. Here are the most common ways companies create ERP integrations.
Code an ERP integration from scratch
Historically, many businesses have chosen to create ERP integrations from scratch. To do this, they use a dev team that writes custom code for each integration scenario. This approach is used for both internal and external ERP API integrations. This approach is not as common as it once was because platforms (enterprise iPaaS, embedded iPaaS, and unified API) are now available to expedite and simplify integration development.
Build an ERP integration with an enterprise iPaaS
Many companies use an enterprise iPaaS to build internal ERP integrations. Many iPaaS platforms include standard API connectors to ERPs and related systems, allowing developers to create internal ERP integrations more quickly than the old way of coding from scratch. Some companies have even used an iPaaS to build customer integrations. However, this adds more challenges to the process because iPaaS platforms don't include the functionality (such as an integration marketplace, customer management, and customer dashboards) necessary to support an excellent customer UX. An enterprise iPaaS is not a good fit for creating customer-facing integrations for ERP.
Build an ERP integration with a unified API
A unified API combines multiple APIs within a software category (such as ERP). As such, it can be a good option for a company that must build the same integration with 40 different ERP apps (all covered by the unified API). But, unified APIs program to the least common denominator: if 12 of the 40 ERP systems have some feature, and the other 28 do not, chances are good the unified API doesn't support that feature. Unified APIs are used for external integrations, but many of these platforms do not include access to customer-specific functionality such as embedded marketplaces and customer dashboards. Unified APIs are unsuitable for building customer-facing integrations to non-standard or custom ERP systems.
Build an ERP integration with an embedded iPaaS
More and more B2B SaaS companies use embedded iPaaS to create customer integrations. These platforms include standard API connectors to ERP systems, streamlining the integration build process. However, unlike enterprise iPaaS, embedded iPaaS is optimized for productizing customer integrations, ensuring that the integrations and associated processes will properly scale with customer growth. And, unlike unified APIs, embedded iPaaS supports the configurability and complexity necessary to build integrations for every app in a market horizontal – not just the standard ones. Beyond that, an embedded iPaaS includes all the functionality needed to build, deploy, and support real-world customer integrations for every market sector. However, embedded iPaaS is not a good fit for creating internal-only integrations for ERPs.
Benefits of ERP integration with an embedded iPaaS
Of the options listed above, an embedded iPaaS provides the greatest benefits when building ERP integrations for your SaaS customers. Here are those benefits.
Save engineering time
Building ERP integrations for B2B SaaS customers without using the purpose-built functionality of an embedded iPaaS takes much more dev time investment than most companies can sustain.
An embedded iPaaS includes a low-code integration designer, a library of built-in components, an integration marketplace, an embedded workflow designer, integration deployment and support tools, and a cloud-native infrastructure – absolutely everything needed to build, deploy, and support customer integrations successfully. SaaS teams report dev time savings of up to 80% after implementing an embedded iPaaS.
Increase win rate and sales velocity
An embedded iPaaS allows your team to create reusable, configurable ERP integrations in days or weeks instead of months. Doing so lets you say "Yes" more often when an ERP integration is functionality your prospects need to become customers. Based on the quick dev turnaround supported by an embedded iPaaS, you can frequently include new integrations with customer onboarding.
Customers often want your product to do X, even if X wouldn't necessarily be helpful for your overall product direction. Integrating with an ERP system may allow you to offset these functional gaps by giving customers another way to solve those business needs.
Provide a great UX for integrations
When you create ERP integrations for your customers with an embedded iPaaS, you ensure that those customers will have a first-class integration experience.
Further, your customers won't suffer from the classic black-box integration experience, where they rely entirely on your support and dev teams to tell them what is happening with their integration. Instead, customers can enable, configure, and even support their own integrations because they have detailed access to integration configuration, status, log, and alerting data.
Change is a constant, and an embedded iPaaS makes it easy to make needed changes to integrations as you manage and version the underlying code within your standard CI/CD processes.
Improve your customer service
When you use an embedded iPaaS for ERP integration, your integrations run on a purpose-built infrastructure with redundancy, scalability, and security built-in. This greatly reduces performance issues and other problems that can occur with integrations.
Since no time is spent on infrastructure issues, your support team can focus on the integrations themselves. This is where the deployment and support tools built into the embedded iPaaS show their value. You can empower your non-devs to do much of the support traditionally handled by devs.
You can also set up your customers to self-service their ERP integrations, allowing them to resolve many minor issues immediately. Customers can view, configure, monitor, and otherwise directly interact with their integrations without relying on your support teams for first-level support.
Reduce customer churn
Using an embedded integration platform for your customers' ERP integrations can help reduce customer churn by making your product essential to your customers because it's a hub for their other critical apps. The platform can elevate embedded integrations in visibility and value, establishing them as key product differentiators.
For customers, leaving your product with its ERP integrations means removing your app and losing an essential piece of their business workflow automation. Finding another vendor to replace your app plus its ERP integrations drives up the cost of switching, thereby decreasing the probability of churn.
ERP integrations use case
Now, let's look at an ERP integration example. In this example, we are using the ACME app as a stand-in for your SaaS product and showing the integration steps within a low-code integration designer, which is part of an embedded iPaaS. ERP integrations can run the complexity gamut, from very simple to ones with hundreds of steps and many different flows. Our example shows a couple flows from a more complex integration.
SAP S/4 HANA
Our example is an integration between SAP S/4 HANA and your ACME app. This integration uses multiple flows (sections). We'll examine two of those integration flows as shown in the designer and explain what is happening.
Flow 1 – Import Suppliers to ACME from SAP S/4 HANA
This integration flow does a one-time sync of suppliers from SAP S/4 HANA to ACME. However, this only runs when this integration is deployed, and only if the underlying configuration says that supplier data should be imported.
- This flow starts with an on-deploy trigger. The trigger runs immediately when the integration is deployed.
- Suppliers are imported from SAP S/4 HANA as long as the behind-the-scenes configuration option for "Import Suppliers at Deployment" is selected. If it isn't selected, the flow terminates with the "Stop Execution" step.
- If the config says we can import suppliers, then we proceed to list all of the suppliers from SAP S/4 HANA.
- We then loop over each supplier record.
- We start the loop by mapping the supplier fields from SAP S/4 HANA to ACME.
- We then take a single supplier record from SAP S/4 HANA and send its ID to ACME.
- Based on its state (exists, doesn't exist), we then create or update the record in ACME with the data from SAP S/4 HANA.
- We keep doing this until we've processed the complete list of suppliers from SAP S/4 HANA.
Flow 2 – Sync Contacts from SAP S/4 HANA to ACME
This integration flow performs a one-way sync of Contact data from SAP S/4 HANA to ACME. It runs in real-time when the workflow is triggered from SAP S/4 HANA.
- In this flow, we start with a trigger in SAP S/4 HANA that fires every time there is a Contact event.
- We then take the payload of that webhook and map it to the data structure for ACME.
- Then, based on the type of event (create, update, delete), we process the request to the ACME app.
- If the event doesn't match up with one the three types specified, the flow terminates at the "Stop Execution" step.
Upgrade your customers to first class
No matter which ERPs your customers use, an embedded iPaaS allows you to build, deploy, and support integrations between your product and those apps – ensuring that your customers have a first-class integration UX.
Schedule a demo. We'll show you how Prismatic supports powerful, reusable, configurable integrations with your SaaS product and ERP systems.
