ERP Software Built For Your Operation, Owned By You

A packaged product is bought and then configured. A system built for your operation is a different purchase. The risk in it is rarely that the build goes badly. It is that you cannot leave the firm that did it. So our answer is written down, against a published standard. You can buy that standard and hold every firm bidding for this work to it, us included.

Jobs live in one workbook, stock in another, invoicing in a third. The numbers are joined up by one person who is very good at it. That is not a failure of capability. The workbook is correct. It is unauditable, and it runs through a single pair of hands. Nobody else can check it, and that person cannot take a week off in the wrong week. If the number is wrong, it is wrong in their handwriting, and everybody knows whose handwriting it is.

There is usually a second thing, and it is rarely said in the meeting. Somebody in the room championed the last system. They sat through the demos, they signed the case, and it half-landed. Asking for another one means asking the same people to back the same judgement twice. A second demo moves nothing. What survives that conversation is something written down that the person who did not sit through it can check.

Those three marks are APQC figures, from its Open Standards Benchmarking General Accounting survey reported in 2018. It covered 2,300 responding organisations. A close that sits past is usually slow because the numbers live in several places. Somebody then has to make them agree by hand.

In its 2017 complaint the company alleges that after going live on a new ERP in November 2012, its first monthly close took 43 working days against a normal 4. United States District Court for the Eastern District of New York, No. 1:17-cv-06997, complaint filed 30 November 2017, paragraph 76.

That is one organisation and one close cycle, from a complaint that has not been proven. The close is where a wrong system of record shows first. It is the one moment when every part of the operation has to agree with every other part. What the filing gives you is a size you can check yourself, from a court record.

Of 237 organisations Panorama surveyed in 2018, the largest group reported modifying 26 to 50 percent of the application's code. Somebody maintains that difference for as long as the system runs.

The other half of the picture belongs beside it. In Panorama's 2023 report, from 183 organisations, more than a quarter implemented their software without any customization. The publisher's stated reason: "This lack of customization is possible because vendors' pre-built industry best practices are becoming much more tailored to the unique needs of certain industries. Also, vendors are making configuration easier, lessening the need for customization." The two reports cover very different populations. They do not form one trend line.

A packaged ERP product can hold your data. What comes with it is a way of working. Either the system changes to fit your process, or your process changes to fit the system. Reshaping the business around the software is the cost nobody prices at the start.

Our own reading of that, and it is ours rather than the publisher's, is this. Where an industry has a vendor template that already matches how the work is done, the gap closes. Where the way you run the operation is what you compete on, you pay for the gap twice. Once to buy it, and once to keep the difference alive.

If the market's ERP products fit your process, use them. We build for the companies they don't fit.

A system of record holds project cost, capital expenditure, procurement, inventory, job costing and compliance reporting. What it does not hold is the customer relationship. Pipeline, bookings and who spoke to whom are a different system. That is a system for the customer relationship, the pipeline and bookings rather than the operation behind them.

We ask about the awkward ones first. A variation order, retention, a part-received purchase order, and a cost code cross-charged between two jobs. The size of the work turns on two counts. How many of your processes get encoded as they are, and how many you change first.

Every change after that becomes a change note. Time, effort and cost are laid out before approval. It enters the plan only once you sign it off, confirmed in a meeting and in writing. Nothing in the build moves on a re-scope you have not explicitly accepted.

How much history has to come across, and how clean it is, is the other thing that moves the size of the work most. Years of jobs in a workbook with three spellings of the same supplier is a different piece of work from a clean database.

We will not put a number of weeks on any of this before we have seen how your close actually works. What gets agreed up front is which slice lands first, because that is the part you can feel.

The stack we build on is published, so your own people, or another firm entirely, can read it before you commit to us.

• The source code, in your own repositories
• Deployments running in your own cloud accounts
• Accounts provisioned and the keys handed over if you have none
• Architecture, deployment and CI/CD pipeline documentation
• BRD and SRS at the depth the foundation needs
• A change note for every change you accepted
• Documentation kept current through delivery

On ownership, the commitment is this. "Every project starts with documentation: architecture, deployment, CI/CD pipelines, BRD, SRS, and change notes. Progress is tracked and measured throughout. If you choose to move the work in-house or to another partner, the handoff is a process, not a hostage situation. The freedom is yours from Day 1."

Code lives in your repositories and deployments in your cloud accounts. If you have your own Git hosting, cloud accounts and storage, we work inside them. If you do not, we provision them, set them up, and hand the keys over.

You do not have to take any of that on trust. ISO/IEC/IEEE 14764:2022 is a published international standard for software maintenance, and this handover is built to its Clause 9 list. The standard names clauses called Scope of maintenance, Designation of maintenance organization, Processes, Organization and maintenance activities, Training, and Maintenance records and reports. Its own definition of maintainability is the "degree of effectiveness and efficiency with which a product or system can be modified", which makes it a property of the product. Buy the standard and hold every firm bidding for this work to the same list, us included.

The limits, so you can weigh the rest. A maintenance plan does not make us your maintenance organisation unless that is separately agreed. Owning the source is not by itself the ability to change it tomorrow: somebody still has to understand your operation, and documentation does not supply that.

We have built ERP for construction and capital-expenditure businesses.

Where compliance reporting is part of what the system carries, how we scope and verify compliance work against a named standard before it ships is a separate piece of work, and what a vendor security review actually checks before an enterprise build is approved is worth reading before you sign anything.

Saying this out loud costs us work, and it is the reason the rest of it is worth reading. If one of those is you, the honest answer sits somewhere else, and it is cheaper for you to find that out here than three meetings in.