Your ERP Doesn’t Need to Do Everything

Your ERP is at the heart of your operations. It records orders, tracks inventory, centralizes costs and supports invoicing.

Over time, though, something else can happen.

You add an online store. Then a customer portal. Next comes a tracking tool for people on the shop floor, a very specific quality control process or a planning feature tailored to how you work.

Each addition meets a real need. Taken individually, each one makes sense. A few years later, the ERP has been customized so heavily that even a routine update becomes a project in itself.

The problem isn’t necessarily your ERP.

It may be doing exactly what it was designed to do. The question is whether you’re now asking it to handle things that would work better elsewhere.

In some situations, the best approach is to keep the ERP as the company’s transactional core and build the experiences and processes specific to your operations around it.

Has your ERP become too heavily customized?

The early signs can be easy to overlook.

Data gets exported to Excel to be reworked. The same information is entered in several places. Employees create their own spreadsheets to track a step that doesn’t fit well into the system. Some reports still have to be put together manually.

Another sign deserves particular attention: you’re putting off ERP updates because there are too many customizations to rework or test.

An update that should give you access to new features, fixes or improvements becomes a source of concern.

Will our existing custom features still work? What will need to change? How much testing will we need? Which processes could be affected?

At this point, the customizations that were meant to make operations easier start creating a form of dependency.

That doesn’t necessarily mean you need to replace the ERP. It may mean you’ve gradually given it responsibilities that go beyond its main role.

The ERP isn’t always the problem

An ERP is particularly useful for managing transactions and centralizing essential business data.

Orders, inventory, invoicing, costs, purchasing and other financial or operational information naturally belong in this system.

Things become more complicated when you try to make the ERP the interface for every employee, every customer and every process specific to your business.

A customer portal, for example, needs to offer a simple, intuitive experience. A tool used on the shop floor needs to fit the way employees actually work every day. A quality control process may involve very specific steps that are unique to your organization.

These needs can also change much faster than the company’s transactional core.

Trying to handle everything directly in the ERP can lead to more customizations and make the system harder to update and adapt.

Another approach is to let the ERP do what it does well and build tools around it to meet the company’s specific needs.

A simple rule: transactions in the ERP, operations around it

One way to decide what belongs where is to separate the transaction from the experience and workflow around it.

Anything that directly involves money, inventory or an important transaction should generally continue to be recorded in the ERP.

A solution built around it can manage how a customer, employee or partner interacts with the process.

Consider a merchandise return.

A customer could sign in to a portal designed for their needs, find their order and submit a return request through an experience that’s much simpler than the ERP interface.

The portal collects the necessary information and sends it to the right system.

The return merchandise authorization (RMA) and credit note are created in the ERP.

The ERP remains the source of truth for the transaction. The portal handles the customer experience and the workflow leading up to that transaction.

This separation lets you develop an experience that fits your needs without changing the ERP’s core every time a process evolves.

In other words, the ERP is your system of record. What you build around it is your operational workspace: the tool your people use all day, following your rules and sending the ERP what needs to be invoiced and accounted for.

Why build around the ERP?

The goal isn’t to add systems simply for the sake of adding them.

It’s to separate responsibilities that don’t necessarily change at the same pace.

Your ERP may remain relatively stable for several years while your customer experience, operations or production processes continue to evolve.

When a separate tool handles these needs, it can evolve without requiring major changes to the ERP each time.

The reverse is also true.

ERP updates are generally easier to manage when fewer highly customized features have been built directly into the core.

The company keeps a more flexible architecture. The ERP remains responsible for the data and transactions that belong there, while the solutions around it can adapt to the processes that truly set the organization apart.

Three practical examples

1. A customer portal connected to the ERP

Imagine a distribution company whose customers regularly contact customer service to check their orders, find documents, submit a request or get a status update.

One option would be to try to adapt the ERP to provide all these functions directly.

Another is to develop a customer portal connected to it.

Customers get an interface designed around their needs. They can view the information they’re authorized to access, submit certain requests and track their progress.

When a transaction needs to be created, it’s sent to the ERP.

The portal can evolve with the experience the company wants to offer, while the ERP continues to manage the core data and transactions.

You’re no longer asking the same system to serve as both a transactional platform and a customer experience.

2. A production planning or tracking tool

In a manufacturing environment, the ERP may hold orders, products, quantities, costs and inventory.

That doesn’t necessarily mean its interface is ideal for the employees who organize and track work on the shop floor.

A company may need a very specific view of its priorities, production stages or operational constraints.

A tool built around these needs can retrieve the necessary information from the ERP and present it in a way that actually works for the teams using it.

Employees work in an interface suited to their operations. Transactional data continues to be recorded in the right place.

If your ERP’s production module already does this for you, keep it.

3. A quality control process specific to your business

Quality control processes are a good example of the limits of a one-size-fits-all approach.

Two companies in the same industry can have very different validation methods, responsibilities and steps.

When a process is truly specific to how you work, forcing every detail into the ERP can lead to a growing number of changes that are difficult to maintain.

A dedicated tool can manage forms, approvals, steps and process tracking while exchanging the necessary information with the ERP.

The same principle can apply to other needs. A CRM integration, for example, can allow certain data to move between systems without turning the ERP into a sales tool.

Building outside the ERP has a cost too

Developing a separate solution isn’t automatically the best decision.

A new system needs to be hosted, secured, maintained and eventually improved. Its integration with the ERP also needs to be monitored and adapted as the systems evolve.

You don’t need to create a custom application for every frustrating problem.

Building around the ERP becomes particularly relevant when the need is important, lasting and specific enough to the company to justify the investment.

If a process gives you a competitive advantage, involves several employees, creates a lot of manual work or changes regularly, the flexibility of a separate solution may outweigh the additional maintenance cost.

For a very standard need, the calculation can be completely different.

Sometimes, the built-in module is the best solution

Not all ERPs work the same way.

Some offer good extension mechanisms, specialized modules or well-supported ways to add features without making major changes to the system’s core.

Be clear about what “inside the ERP” means, because your integration partner will be. There are three levels: configuration, extensions supported by the vendor and changes to the core. The first two carry through updates. It’s the third that vendors themselves are working to prevent. SAP has made this a guiding principle with its “clean core” approach, which reserves extensions for processes that differentiate the business and keeps them separate from the core.

For a small business, an online store or a built-in module included with the ERP may also meet the need perfectly well.

In that case, developing a new solution would add more complexity without creating enough value.

The question isn’t about always choosing between the ERP and custom development.

The real issue is avoiding major changes to the ERP’s core to handle needs that could be better served elsewhere.

The best architecture is the one that fits your business, your transaction volume, your processes and how you want the business to evolve.

How can you assess your situation before investing?

Before making more changes to your ERP or building a solution around it, start by understanding what’s actually causing problems. What does your ERP do well today? Which customizations have you accumulated? Are they causing you to postpone updates? Where are employees still relying on workarounds such as Excel files, duplicate data entry or separate tracking tools?

Then look at each function individually and ask the same questions. Within a single company, some functions will belong in the ERP and others outside it. That’s normal.

First, is it a transaction? If the function creates or changes a financial transaction, inventory or an accounting document, it stays in the ERP. A separate tool can trigger it, but it should never replace the ERP’s role in recording it. For everything else, ask six questions.

1. Does your ERP understand the things this process deals with? Customers, items and orders: yes. A batch, a job site, a train or a pricing rule unique to your business: those may require substantial work to represent.

2. Can it serve the people involved? Office employees with a licence: yes. Teams on the shop floor or on the road, customers and partners, using mobile devices or working offline: that can be more difficult.

3. How would it handle the need? If it can be done through configuration or an extension supported by the vendor, that’s your integration partner’s job. If it requires workarounds or changes to the core, pay attention.

4. How often does this process change? Is it configured once and left in place for years, or does it change several times a year?

5. What kind of processing is involved? Data entry and reports, or calculations, real-time processing and artificial intelligence?

6. Does it need to outlast your ERP or become a product? You may be planning to change systems, or this business logic may be an asset you want to keep and potentially commercialize.

If four or more answers point outside the ERP, build alongside it and connect the two. If two or fewer do, stay within the ERP through configuration, a module or a supported extension. Three is the borderline case, where an analysis is worth doing before writing a line of code.

And building alongside the ERP doesn’t necessarily mean custom development. If specialized software meets the need without workarounds and connects to your ERP, look at that first. Custom development makes sense when no available software reflects how your business works, or when the rules that set you apart are precisely the ones a standard product would force you to give up.

Your ERP can remain at the heart of the business without doing everything

A good ERP doesn’t need to become your company’s only interface.

It can remain the source of truth for your orders, inventory, costs and transactions while other tools handle the experiences and processes they’re better suited to.

This distinction becomes particularly important when customizations start slowing down updates or making the system difficult to adapt.

The answer isn’t necessarily to replace the ERP. It isn’t to develop a new application every time, either.

Start by determining what truly belongs in the transactional core and what would benefit from evolving around it.

That separation is often what lets you keep a solid ERP while developing tools that fit the way your company actually works.

For a closer look, explore the full decision framework, the reasoning behind each criterion and three practical cases: ERP or Custom Development Guide (in French).

Is your ERP handling processes that go beyond its role? Let’s talk about what should sit alongside it: Contact Altevo.