Most ERP implementations fail to deliver their early promise not because the software is wrong, but because the data environment it arrives into is ungoverned.
The new system connects to the same undocumented processes, the same field inputs that arrive late and inconsistent, and the same absence of agreed definitions for what a job cost or a time entry or an approved invoice actually means. The implementation partner does the technical work. The company goes live. Six months later, the reports are cleaner but the decisions are not better, because the underlying data still has the same gaps it always had — now they are just faster.
The answer is not to delay the ERP. It is to build the foundation before it arrives.
The foundation is not the software. It is the data contract, the identity layer, and the agent skills. Those move with you.
Start with the data contract
The first three weeks are not about connecting any system. They are about defining what the company actually needs to see in order to run the operation.
We define ten read-only views. Each view has four things: a company key (which entity in the structure), a source system, a refresh expectation (daily, weekly, or on-demand), and a named owner role — not a person, because people change.
The ten views: open receivables, job cost by project, approved time by crew and job, materials and inventory on hand, open purchase orders, vendor invoice aging, subcontractor work order status, equipment maintenance due dates, safety incident log, and cash position summary.
Each view excludes payroll. Payroll data in an operational read layer creates compliance risk and almost never improves an operational decision. We write the exclusion explicitly into each view definition.
The controllers review the exact field lists. Not the view names — the field lists. What fields appear in the open receivables view? What does "approved time" mean exactly — is it time approved by a supervisor, in the payroll system, or in the field service platform? These questions, when asked before anything is built, surface definitional disagreements between entities that have been generating silent inconsistencies in reporting for years.
The data contract is a document, not code. It lives in SharePoint. It is the agreed definition of what the company will look at and how it will look at it. It is reviewed by the controller for each entity and signed off by the CFO before any agent is connected to anything.
Build the identity layer
Microsoft 365 is usually already the company's identity system, but it has grown without governance. Shared mailboxes used for operational workflows. Access to field service tools managed by whoever has been there longest. Document libraries with no versioning and no clear ownership.
We map the current state: who has access to what, through which credential, and whether that access has ever been formally reviewed. The map is not pretty. It is not intended to be — it is intended to be honest.
From that map, we build a simple governance structure. Each system has a named owner role and a named backup. Access requests go through a one-page form. Document libraries in SharePoint are reorganized into project, operational, and administrative categories, each with version history enabled. Shared mailboxes are converted to functional inboxes with clear ownership.
The identity work is the least visible and the most foundational. When the ERP implementation partner arrives, they get a clean Microsoft 365 environment with documented access — not a credential landscape that requires three weeks of archaeology before anyone can begin provisioning.
Wire the agent skills against the existing systems
Agent skills are written against the ten views defined in the data contract. Each skill follows the same pattern used across every Mesa AI engagement: read from a narrow, permissioned source; assemble a draft in the channel the team already uses; route to a named person for review; stop. The agent does not post, does not adjust, does not decide. It reads and drafts. A person reviews and releases.
The first three skills: invoice matching (read from open AP view, match to PO database, draft a routing recommendation, route to the controller), timesheet exception review (read approved time, flag overtime against project budget, route to the operations manager), and job cost variance alert (read job cost weekly, flag jobs where actuals exceeded estimate by more than 10%, route to the project manager by entity).
Each skill is reviewed against the data contract before connection. If the skill needs a field that is not in the contract, the contract is updated first — not the skill. The contract is the governed set of what the company has agreed to look at. Skills run inside that boundary.
What carries forward
The ERP will replace the current source systems. When that happens, the data contract views are repointed to the new source. The field lists may change. The refresh expectations may change. The view names and the owner roles stay the same.
The identity governance stays. The document structure stays. The agent skills are repointed to the new data contract views.
The foundation does not go away when the ERP arrives. It becomes the governed layer that the ERP connects into, instead of the blank environment that most ERP partners inherit and have to build from scratch on the client's budget and timeline.
When the implementation partner arrives, they receive a data contract that defines what the company needs to see, an identity environment that is governed and documented, agent skills already running against the current systems, and controllers who have reviewed and agreed on the definition of a job cost, an approved timesheet, and an open receivable.
That is not a typical ERP starting point. It is a better one.
The foundation is not the ERP. Build the data contract, the identity layer, and the agent pattern against whatever systems you are running today. They will outlast the software they are currently connected to.