Walk into most industrial companies and the systems are old, the data's a mess, and nothing quite talks to anything. When the pain gets bad enough, the instinct is to fix the technology: rip out the ERP for a better one, or bolt on the next platform and mandate adoption. The hope is that you can buy your way to a clean system and get a quick fix.
Typically, it's not so easy. These projects have a way of running long, running over, or quietly underdelivering. Even the ones that land put you back in the same place eighteen months later: a new system of record, and the same pile of spreadsheets growing up around it.
These are not just tech problems. People and processes can't be removed from the equation.
It's a people-and-process problem
The usual sequence is backwards. People think you change the technology, refine the process, and then get the people on board. In practice, you have to start with the people. They know how the company actually works, and that usually does not mirror the org chart. Once you understand how the work really gets done, you can understand the process. That is the actual op model, not an operating model on a Visio diagram. It should determine the requirements for the technology, not the other way around.
The ERP is not where most of that knowledge lives. It is good at recording transactions. It is not designed to capture how exceptions get handled, who needs to sign off, or why the team does something differently in one case than another. So that knowledge ends up somewhere else: the spreadsheet, the macro, the SharePoint folder nobody will delete, or the standing call where two people reconcile what three systems cannot.
That is not shadow IT. It is where the missing process lives.
So when the plan is "replace the system of record," you are usually replacing the layer that holds the transactions, not the layer that holds the judgment. You can spend a year and a fortune and still miss the thing you were trying to fix: how decisions get made, who knows what, and how exceptions clear. That knowledge may still be sitting in a spreadsheet you did not migrate.
We start somewhere else. Here is how we think about it in four pictures.
First, how it actually runs
This is how most industrial companies actually run. There are several systems of record, and each one owns a different part of the business. ERP, or enterprise resource planning, owns finance and the supply chain. MES, or manufacturing execution systems, owns the floor. PLM, or product lifecycle management, owns engineering. Each one has its own vocabulary, its own owner, and its own version of the truth.
The important work usually crosses more than one system. A quality escape, an engineering change, or a late supplier cannot be handled cleanly inside one tool. The systems cannot see enough of the picture, so a person becomes the bridge. (We went deep on that coordination tax in beyond easy problems; I won't relitigate it here.)
The first thing myai does is connect them. But connecting systems is only part of the job, and plenty of vendors stop there. An integration layer can move data between your ERP, MES, and PLM. The harder part is the layer that was never captured in any of the three: the spreadsheet logic, the email judgment, and the tribal context. That is why myai sits across the systems and the tools around them. An AI bolted inside a single system only sees that system. The problems are cross-system, so the intelligence has to be too.
Your systems of record stay where they are.
Second, why the spreadsheet is still there
A lot of software is sold around the same promise: adopt the platform, and the spreadsheets finally go away. No more Excel, email threads, or SharePoint folders. One clean system of record.
That is usually not what happens. Five years later, the spreadsheets are still there because they were never the real problem. They were the workaround people built when the official tool did not fit the way the work actually happened. Rip them out too fast and you do not get cleaner. You get slower. You deleted the place where the real process was written down.
So myai starts with the tools your team already uses. If your team runs on Excel, myai works with Excel. If the real handoff happens over email, myai works there too. The point is to understand why the macro exists before trying to replace it.
That is not just a user-adoption choice. It is also a strategy. A macro is often a spec someone already wrote: the formula logic, the column where the data lands, and the order the steps run. Instead of asking six people to reconstruct the process from memory, an agent can read the logic, show its interpretation, and build from there under your sign-off. The tribal tools are not the mess to clean up before automation. They are the best starting map you have.
Third, what the spreadsheet points to
Look at that spreadsheet again, the one holding the process the ERP could not capture; it is not just a tool, it is a map to how the work actually happens. The tabs point to people: who owns this, who to call when the number looks wrong, and who knows the exception path. The formulas encode process: how the exception clears, in what order, and with whose sign-off. The point is not to fix the spreadsheet in isolation. The point is to use it to understand how people actually work and collaborate.
That is how to read the last picture. The ad hoc tools are not separate from the people and process. They point back to them. Excel, SharePoint, and Teams show you who owns the work, how the handoff happens, and what steps the official system did not capture.
For example, a part comes off the line as non-conforming. The MES captures the event, and the quality system owns the disposition record. But the actual decision, whether to rework it, scrap it, or use it as-is, does not live cleanly in either system. It lives in an email thread, a shared MRB tracker spreadsheet, and a meeting where someone pulls the drawing from PLM, the history from the quality record, and the cost from the ERP. MRB, or material review board, is the cross-functional process for making that call. Several systems are involved, but the judgment still gets assembled by hand.
myai can work from that pattern. It can trigger from the non-conformance, open the tracker the quality team already trusts, and add the drawing revision, prior dispositions for similar parts, and cost exposure where the team already looks for them. It can suggest a call and show the reasoning behind it. The point is not to replace the board's judgment. It is to scale that judgment by putting the right context in front of the team and preserving the reasoning once the decision is made. The board still decides, and the sign-offs still happen. When they do, myai records the disposition in the quality record, along with the evidence and approval trail.
We did not replace the MES. We did not replace the spreadsheet. We reduced the manual reconciliation around the decision: the human cost of pulling context from broken systems by hand. That is where the time goes.
When replacement does make sense
There is one honest exception. If you are a near-greenfield company with no real system of record worth keeping, and you genuinely want one clean platform, replacement may be the right answer. Connect-and-extend may not be the right fit yet. But that is the rare case. Most companies already run on real systems, real people, and a hundred spreadsheets that work. For them, the ground truth is already in the building.
Connect, extend, then replace
This is the same posture we wrote about in connect, extend, then replace, applied one level up. In that earlier piece, the goal was to avoid building the next spreadsheet. Here, the same thinking applies to the system of record.
We connect to what you have. We extend it with cross-system answers, audit trails, and the reports your team rebuilds by hand every week. That creates value this quarter without requiring a migration. Replacement can still happen later, but it should be earned by usefulness and trust, not demanded on day one.
We are not trying to replace your ERP from day one. We are trying to understand the work around it: the systems, the spreadsheets, the handoffs, and the decisions. The longer myai runs, the more of that context it can preserve and reuse.
The practical takeaway
The most valuable knowledge in your company may not be in the system you are about to spend a year replacing. It may be in the spreadsheet sitting next to it, because that is where the team captured how the work actually gets done. Do not bulldoze it before you understand what it is telling you.
Your systems of record can stay where they are. That is not a limitation. It is why this approach can work without asking the business to stop and migrate first.
If you run operations and want to see what that looks like in practice, start with the use cases. (Building agents yourself? The agent guide and the platform go deeper.)
That's what we're building at Make Yourself AI.