ERP for CEOs — What Matters from the Top
An ERP purchase is one of the few IT decisions that lands on the CEO's desk, and usually for the wrong reason: someone needs a signature on a number. The number is the least interesting part. What the system really costs is management attention over the following eighteen months, and that is a resource no budget line captures.
What you are actually buying
Strip away the vendor language and an ERP system does one thing: it makes every department work from the same record. Sales sees what production committed to. Finance sees the order before it becomes an invoice dispute. Nobody maintains a private spreadsheet that quietly disagrees with everyone else's.
That sounds modest until you count what the alternative costs. The classic symptoms — a month-end close that takes three weeks, inventory numbers nobody trusts, a quote process that depends on one person being reachable — are all the same problem wearing different clothes. They are data living in places that do not talk to each other.
What ERP does not buy you: better processes. The software encodes whatever process you feed it. Companies that treat implementation as a chance to fix broken workflows get a return; companies that pave the existing cow paths in expensive new asphalt get the same mess with a support contract attached.
Three decisions only you can make
Scope discipline. Every ERP project accumulates requests. Each one is individually reasonable and collectively fatal. Someone has to be able to say "not in phase one" and make it stick, and in most companies that person is you. Delegating scope authority to a project manager without political cover is how eighteen-month projects become three-year projects.
Who runs it. The project needs a business owner with real authority, not an IT coordinator. If the person leading it cannot overrule a department head on a process question, they will escalate every conflict to you anyway — just slower, and after the argument has hardened.
Whether to standardize or customize. When the system's standard process differs from yours, someone decides which one bends. Customization preserves how you work and permanently raises the cost of every future upgrade. Standardizing is cheaper and asks your people to change. Both are legitimate; drifting between them without deciding is not.
The economics, briefly
Ignore list prices. The number that matters is five-year total cost of ownership: license or subscription, implementation services, integration work, internal staff time, and the operating cost after go-live. Implementation frequently exceeds first-year software cost, and internal time — your best people, pulled off their day jobs — rarely appears in any vendor proposal. Our TCO calculator models the five-year view with your own figures.
On the return side, set measurable targets before signing: days to close, inventory turns, order-to-cash cycle, quote turnaround. Vague goals ("better transparency") cannot be checked afterwards, which is convenient for everyone and useful to nobody. Efficiency gains typically take twelve to thirty-six months to exceed the investment, and they arrive only if someone is tracking them.
When the answer should be no
Do not start an ERP project in the same year as a major acquisition, a plant relocation, or an ownership change, unless the system is the reason for one of them. Do not start when your leadership team is short a key role. And do not start because the current system is old — age is not a business case. The trigger should be a specific, expensive problem the current system cannot solve.
Practical next steps
Before any vendor conversation, get a written requirements document. It is the single artifact that keeps demos honest, because it forces the discussion onto your processes instead of the vendor's feature list. From there the selection process lays out the sequence, and the software directory shows what is actually available — including the enterprise suites, the mid-market generalists, and the industry specialists that often fit better than either.