Your ERP Isn't Broken. It Just Doesn't Run the Whole Process.

For decades, companies have invested enormous amounts of time and money implementing ERP systems, and for good reason. ERP has become the backbone of the modern enterprise. It manages orders, inventory, purchasing, production, finance, suppliers, customers and countless other critical transactions. Yet walk through almost any manufacturing company and you’ll find something interesting.

Alongside the ERP, you’ll probably find Excel spreadsheets tracking work, emails requesting approvals, Teams messages asking for status, SharePoint folders holding supporting documents, employees entering information from one system into another, meetings held simply to determine what’s happening and experienced employees who know how to navigate exceptions nobody ever formally documented.

It’s tempting to look at all of this and conclude: Our ERP isn’t working. But that may be the wrong diagnosis. Your ERP might be working exactly as designed. It just doesn’t run the whole process.

The transaction isn’t the process

Consider something as ordinary as a customer order. The ERP may do an excellent job recording the order, but what happens before and after that transaction?

A real-world process might require someone to:

The ERP may own several of those steps, but it may not own all of them. Other systems likely handle pieces of the process as well: MES, QMS, WMS, PLM, CRM, SharePoint and specialized applications. Then there are the spaces between those systems. That’s often where the real work happens.

When employees become the integration layer

In recent conversations with operations leaders, we’ve heard numerous examples of employees compensating for gaps between systems and processes.

Sometimes that means maintaining a spreadsheet. Sometimes it’s sending an email when something needs to happen. Sometimes it’s copying information from one system and entering it into another. Sometimes it’s knowing that after Step A, you need to call Mary in Purchasing because Mary knows what has to happen next. Each workaround can seem perfectly reasonable in isolation.

The problem appears when you step back and look at the entire process. You may discover that employees have effectively become middleware between your enterprise systems, and unlike software integrations, human integrations aren’t particularly visible.

They take vacations. They forget. They make mistakes. They leave the company.

And perhaps most importantly, the organization can gradually forget that the workaround is a workaround at all. It simply becomes “That’s how we do it.”

Workarounds have a habit of becoming permanent

One operations executive we spoke with described an enterprise-system migration where an existing integration was disconnected. Orders stopped flowing automatically into the new system. The logical solution would have been to restore or replace the integration. Instead, the organization created a manual process. Employees received the information and entered it into the system themselves. Temporary problem solved.

Except the temporary solution wasn’t temporary. Years later, people were still performing work that had once happened automatically. That’s an extreme example, but the underlying pattern isn’t unusual. 

An operational gap appears and someone creates a workaround. The workaround solves the immediate problem, and the business moves on. Eventually, nobody asks why the workaround exists, and that’s how a five-minute manual task can become thousands of hours of annual labor.

Your system of record isn’t necessarily your system of work

This creates an important distinction for operations leaders. Your enterprise systems tell you a great deal about your business, but they don’t necessarily tell you how the business actually gets work done. The official process might look like this:

Order → ERP → Production → Shipping

The actual process might look more like:

Order → Email → Excel → Employee → ERP → Teams → Approval → Employee → Production → Manual Update → Shipping

Both processes eventually produce the same transaction in the ERP, but only one tells you what really happened. That matters because management can have excellent visibility into the system of record while having surprisingly little visibility into the system of work.

That’s when operational problems become difficult to see

Imagine looking at an ERP dashboard and seeing that an order took eight days to complete.

You know when it started and you know when it finished. What happened during those eight days? Was someone waiting for an approval? Was engineering looking for a drawing? Was purchasing waiting on a supplier? Did an employee forget to update something? Was the process sitting in someone’s inbox for two days? Did somebody enter information incorrectly and have to redo the work?

Your ERP may accurately tell you the elapsed time without telling you where the actual effort, waiting or friction occurred. That’s a significant distinction. Knowing the outcome isn’t the same as understanding the process.

So we buy another application

When companies discover these gaps, there’s an understandable response: Find software that solves them. Sometimes that’s absolutely the right answer. The challenge is that organizations have been doing this for years. ERP doesn’t handle something, so another application is added.

Then another.

And another.

Eventually an employee’s workday might involve:

ERP + MES + QMS + SharePoint + Teams + Excel + email + several specialized applications. Every application may be doing exactly what it was purchased to do. Yet the employee still has to understand how the entire process fits together. So we’ve solved individual technology problems while sometimes creating a larger operational problem: fragmentation.

Adding another application doesn’t automatically solve that. In fact, it can make it worse.

Start with the process, not the software

Before asking “What system are we missing?”, operations leaders may want to ask different questions: 

These aren’t merely technology questions. They’re operational questions.

Having the technology isn’t the same as using it

There’s another complication. Sometimes the system already contains what the organization needs. The problem is that people aren’t using it. A manufacturing leader recently gave us a simple example. An organization may have data about supplier lead times, inventory levels, historical consumption and expected demand. Yet purchasing decisions can still be heavily influenced by experience and “gut feel.” That doesn’t necessarily mean the ERP needs another feature.

The breakdown is somewhere between

Data → Decision → Action

This pattern shows up everywhere. Having the data isn’t the same as using the data. Having the procedure isn’t the same as following the procedure. Having the workflow isn’t the same as executing the workflow. Having the software isn’t the same as changing how work gets done. That’s why technology initiatives eventually become operational and cultural initiatives.

What operations leaders really need: visibility and control

Ultimately, many of these problems come back to two things.

Control

Can you ensure that the process is executed consistently? Can you make sure:

• the right steps happen,
• the right information is used,
• the right people are involved,
• approvals aren’t missed,
• current documents and procedures are followed,
• and exceptions are surfaced before they become bigger problems?

Enterprise systems provide tremendous control over the transactions they’re designed to manage. The opportunity is to extend that visibility and control to the work surrounding those transactions.

The next step may not be replacing anything

Manufacturers don’t need to rip out functioning ERP, MES, QMS or other enterprise systems every time they discover an operational gap. Those systems remain essential.

The better question is:

How do we connect the systems we already have with the people, documents, decisions and workflows required to execute the entire process?

That’s the problem we’re thinking about at Klyck.

Klyck is designed to help operational teams manage critical processes that extend across people, documents and existing enterprise systems without trying to become another system of record. Because your ERP may not be broken.

The work may simply extend beyond where your ERP ends.

A question worth asking your team

Pick one important operational process and follow it from beginning to end, not how the procedure says it works, but how people actually perform it.

Then ask:

Where are people acting as the integration layer?

Those places may tell you more about your next operational improvement opportunity than another software requirements meeting ever will.