Run the job once. Let every team see the same truth.

A custom ERP system connects the records and workflows several parts of a business need to share — orders and jobs, stock and purchasing, approvals, operations and the commercial side. What it should contain is decided by how the business actually works, which is why the useful conversation starts with one real job rather than with a list of modules.

A good operations system makes handoffs explicit. When a stage finishes, the next team should know the work is ready, what information came with it, what is still missing, and who owns the next action — without anybody having to send a message or remember to check.

Approvals belong inside the workflow: the action is simply not available until the approval is given, and who approved it is recorded on the job. That is more reliable than a policy people are expected to remember, and it means the history answers the question later without anybody reconstructing it.

Connected operations means the job knows what it requires and whether that exists. When something is short, the shortfall becomes a request with an expected date, and the job that depends on it shows the dependency rather than quietly slipping. The same structure works whether the constrained thing is material, a person’s time or a piece of equipment.

No. A useful ERP can begin with the operational records and handoffs causing the most friction — usually the job itself, its owner, its stages, its approvals and its history — and expand once the connected model has proved useful. Starting with every department at once is how ERP projects become the thing everyone has a story about.

Custom is not automatically the right answer, and plenty of businesses are better served by configuring something that already exists. Equally, a lot of what gets asked for as an ERP is really a CRM, and the two solve different problems: a CRM owns the relationship and the deal, and an operations system picks the job up once the customer has said yes.

We review what each current system already does well before deciding what should stay, connect or move. Accounting is usually kept and connected rather than rebuilt. A spreadsheet that is really a workflow usually moves into the system. A legacy database is often kept as a source while the new records take over. What can actually be connected depends on what each system exposes, which we confirm before designing around it.

Operational reporting is a consequence of the records being connected, not a separate product. If every job has a real stage, a real owner and a real history, then what is active, what is blocked, what is waiting for approval and what is due this week are simply counts of that — and they are as current as the work, because they are the work.

Scope on an operations build is mostly arithmetic: how many workflows, how many teams and roles, how many shared records, how many approvals and permissions, how many other systems it has to talk to, and how much history has to move. What affects development time most is the number of distinct things to design, build, test and support — plus the state of the data being carried over and how many decisions are still open when the build starts.

Swift Logix B2B logisticswebsite UX/UI design · web development

Lotus Professional Beauty & skincareUX/UI design · product recommendations · skincare consultation UILex Polaris Law firmwebsite development · practice-page content structure · disclaimer and consultation flowLeanTrack Consumer health and fitnessmobile app UX/UI design · mobile app developmentDetail Driven Car detailing & carewebsite development · UX/UI design

Selected business systems work. Scope for each project is listed from its own record.

What is an ERP system?

An ERP system is software several parts of a business share, so that the same records — orders and jobs, stock, purchasing, approvals, costs — are read and updated in one place instead of separately by each team.

What is a custom ERP system?

One built around how your business actually works rather than configured from a product’s assumptions. It connects the records and workflows your teams genuinely share, and leaves out the parts of a standard ERP you would never use.

What is the difference between an ERP and operations software?

In practice, very little — “ERP” usually implies a wider scope covering finance and procurement as well as operations. Both mean the same thing that matters: teams working from connected records instead of separate tools.

What is the difference between an ERP and a CRM?

A CRM owns the relationship and the deal — leads, pipeline, quotes, everything up to the customer saying yes. An operations system owns the job that “yes” creates: planning it, resourcing it, doing it, handing it between teams, completing and invoicing it.

Custom ERP or off-the-shelf ERP?

Off-the-shelf is usually better when your workflow is standard for your industry, an existing product covers most of it, and configuration gets you the rest. Custom makes sense when the operational workflow is materially different, several systems are creating duplicate work, or the business rules are specific enough that you would be fighting the product.

Does every business need an ERP?

No. Plenty of businesses run well on a few good tools. The signal that something connected is needed is usually duplication — the same job being re-entered, re-explained or re-checked as it crosses teams.

Can an ERP start with one process?

That is usually the right way to start. Begin with the operational spine — the job, its owner, its stages, its approvals and its history — and expand once that is genuinely being used.

Does an ERP need every department?

No. A first release covering the operational records and handoffs causing the most friction is more useful than a system covering every department shallowly, and far more likely to be adopted.

Can it connect to our existing CRM, accounting or other software?

Where those systems allow it. We confirm what each one can expose — what can be read, what can be written, what it will not permit — and design around what is actually available rather than assuming an integration exists.

Do we have to replace the systems we already use?

Usually not. Accounting is normally kept and connected. A CRM keeps the pipeline and hands the job over. What tends to get replaced is a spreadsheet that was doing a workflow’s job all along.

Can our spreadsheet or legacy data be migrated?

Usually, with judgement about what is worth moving. We sample the source, map the fields, clean what is broken, import and verify against the original. Some history is worth carrying in full, some is worth summarising, and some is best left readable in the old system.

Can different teams have different permissions?

Yes. Roles decide what each person can see and do, sensitive fields can be restricted further, and high-impact actions can be put behind an approval.

Can approvals be built into the workflow?

Yes, and that is usually better than a policy people are expected to remember. The action is unavailable until approval is given, and who approved it is recorded on the record.

Can exceptions and escalations be tracked?

Yes. A blocked job can name its reason, show what it puts at risk, carry an owner and a next action, and stay visible where people already look, rather than going quiet until somebody notices.

Can it include inventory and procurement?

Yes, where the business needs it. A job can know what it requires, whether that exists, and what to do when it is short — including raising a purchase request and showing the resulting dependency on the job.

Can it include customer or supplier portals?

Yes, as a later stage rather than a first release. Once the internal records are trustworthy, giving a customer or supplier a view of the parts that concern them is a much smaller piece of work.

Do we need a mobile app?

Only if the work happens away from a desk. A responsive web system covers most office and back-office use, and is cheaper to change. Shop floor, warehouse or field work is where a mobile experience genuinely earns its place.

Who owns the system, code and data?

They are yours. Work is handed over with the repository, the deployment and the access it runs on, and with documentation where that is in scope. What applies to a specific project is written into that project’s scope.

What determines the scope of an ERP project?

How many workflows, how many teams and roles, how many shared records and how they relate, how many approvals and permissions, how many systems it must talk to, and how much history has to move.

What makes one ERP project much larger than another?

Usually the count rather than the industry: more workflows, more roles, more integrations, more migration. Multiple branches or legal entities is the single change that most often doubles a project, because it reaches into permissions, numbering and reporting at once.

What affects development time?

The number of distinct things to design, build, test and support, the state of the data being carried over, and how many operational decisions are still open when the build starts. We scope from your actual workflows rather than quoting a standard number.

What happens after launch?

The first weeks of real use show which stages people actually work through, where work stalls, and what the team is still doing outside the system. That decides what gets built next, and it is a better guide than anything decided in advance.

Can the system expand later?

Yes, and it is designed expecting to. The records and permissions are shaped so that adding a workflow, a team or a connected system later does not mean rebuilding the middle of it.