Every company I walk into runs on two systems. The one they bought, and the one their people built around it in spreadsheets.
The ERP holds the records. The CRM holds the contacts. And around both sits the real operating system of the business: the pricing workbook, the scheduling sheet, the export someone runs every Monday, the Access database in engineering that nobody in IT wants to talk about. That layer is where the actual process lives.
Leadership usually treats the workaround layer as a discipline problem. Why won't people just use the system? Wrong diagnosis. The workaround layer exists because it has to. Your ERP was built for your industry. Your company is not your industry.
The big platforms are engineered for the median company in a category, and they do that well. Records, transactions, compliance — the commodity 80 percent that every business in your space shares. But you do not win deals with the 80 percent you share. You win with the 20 percent that is yours: the approval flow that lets you say yes faster, the scheduling logic your ops lead carries in her head, the way you quote. And that 20 percent is precisely what the vendor did not build, because it is not theirs to know.
So your people did what people do. They rebuilt the missing 20 percent in the only tool that would bend, and now your differentiation runs on spreadsheets, re-keyed by hand, reconciled monthly, known fully by one person.
The obvious response is to customize the system, and I know exactly what a generation of leaders hears when someone says that. Consultants forking the ERP core, upgrades that break everything, a version so bent out of shape the vendor will not support it. That fear is earned. Twenty years ago, customization meant surgery on the core, and "never customize your ERP" was genuinely good advice.
It is not good advice anymore, because the architecture changed underneath it. Modern platforms expose APIs. You can now build against a system without touching its insides.
The real answer is neither of the two options everyone argues about.
The answer is a third thing: keep the core vanilla, and build the fit layer beside it.
Concretely, the fit layer is three kinds of software.
The core stays clean and upgradeable. The vendor keeps doing what they are good at, which is records at scale. And the part of your operation that makes you money finally lives in real software — with permissions and history and more than one person who understands it — instead of in files.
This is most of what my firm builds, so weigh my incentive accordingly. But there are real constraints worth naming.
Do not build the fit layer where you are the same as everyone else. Payroll is payroll — vanilla is a feature there, and wanting custom payroll is a sign you have lost the plot. Software you build you own forever, hosting and security and maintenance included, so the fit layer has to stay small and deliberate. A few systems owned properly, not thirty half-apps because building got cheap. The discipline is choosing the two or three places where fit actually pays, and those are almost always the places closest to how you win work.
The good news is your company already wrote the requirements. Every spreadsheet in the workaround layer is a requirements document. It tells you exactly where the bought system stopped and your real process began — what data it needs, who touches it, and how often. Your people have been specifying the fit layer for years. Nobody was reading it.
So here is the exercise. Inventory the spreadsheets and side tools that touch your ERP or CRM every week. Ask what each one does that the system could not. Rank them by how close they sit to revenue.
The top of that list is not a discipline problem. It is the most valuable software your company has not built yet.
Which spreadsheet would hurt most if it vanished tomorrow? Start there.