ERP that matches how the operation already runs.

Production, inventory, procurement, finance and HR on one system, rolled out module by module, with a way back at every stage.

  1. 01How you run now
  2. 02What disagrees
  3. 03One record
  4. 04A way back

In productionGuru ERP on a plastics production floor in Riyadh, and at a trading company in Dubai. One codebase, two industries, two tax regimes.

Why ERP implementations fail

Almost always in the same place: the system assumes a process, the floor has a different one, and the gap fills with spreadsheets.

  • The software had opinions

    A reference model was implemented and the operation was asked to change to fit it. Within a year the ERP holds the official numbers and the spreadsheets hold the real ones.

  • One big cutover

    Everything moved on one date, and when something was wrong there was no version of Monday that worked.

  • The workaround was ignored

    The spreadsheet on a supervisor’s desktop is not a discipline problem. It is the requirement nobody wrote down.

  • Tax handled in code

    A rate change becomes an engineering project instead of a setting, so it is done late and by hand.

How the rollout is run

Six commitments, and the second one is the one that makes the rest possible.

  1. Configure to the operation

    Discovery happens on the floor, not in a meeting room. The exception somebody handles manually is a requirement.

  2. Module by module

    One module at a time, each behind a switch that can be thrown back. You are never asked to move the whole operation on one date.

  3. One master record

    One item master, one employee master, one customer. Most of what makes an ERP disagree with itself is a second copy of a definition.

  4. Multi-plant and multi-company

    More than one site or entity on one system, with the reporting that assumes they are related.

  5. Reporting the floor recognises

    The same figures for the supervisor and the owner, drawn from one source rather than assembled per audience.

  6. One codebase across deployments

    Riyadh and Dubai run the same build under two tax regimes. What differs is configuration, so neither is a fork and both take the same fixes.

Modules we implement

Guru ERP where it fits, which shortens delivery. Built for you where it does not, and we say which up front.

  • Production and planning

    Work orders, routing and output booked on the floor rather than reconstructed afterwards.

  • Inventory

    Raw material, work in progress and finished goods on one ledger, moved by the events that move the stock.

  • Procurement

    Requisition to receipt, with the receipt closing the loop against the stock record.

  • Finance and accounts

    A ledger fed from operational events, so the close starts from numbers the floor already agreed with.

  • HR and payroll

    One employee master shared with attendance, shifts and production booking.

  • Tax and localisation

    Configuration rather than code. UAE VAT is live in Dubai on the same build that runs the Riyadh plant.

OutcomeOne set of numbers for the floor and the office, and a way back at every stage.
CapabilitiesProduction and inventory · Procurement and supply chain · Finance, accounts and VAT · HR and payroll · Multi-plant and multi-company · Operational reporting

What we build it on.

Grouped by what it does rather than shown as a wall of marks, and short enough that your own team can judge whether they could take it over.

Backend
PythonDjangoFastAPINode.js
Frontend
ReactTypeScriptNext.jsDesign systems
Data
PostgreSQLMySQLRedisData modelling
Cloud
AWSDockerCI/CDInfrastructure as code

Work we have done under this line.

Derived from the engagement record rather than listed here, so this section cannot claim work that is not in it.

ManufacturingRiyadh, Saudi Arabia

Three Arrow Plastics Factory Co

Guru ERP across production, inventory, procurement, finance and HR on a single facility, configured to the process the plant already ran.

ChallengeProduction planning, inventory, procurement, finance and HR each lived somewhere different, and none of them agreed.
ConstraintThe line does not stop. Every stage of the rollout had to be reversible.
ResultOne set of numbers for the floor and the office.
StatusIn production
Read the case study

TradingSaudi Arabia

AL Rukan Al Hassan Co

Guru ERP configured for trading: sales, procurement, HRM, accounts and VAT. Same codebase as the Riyadh plant, two industries.

ChallengeA trading operation needed the same operational control a factory system gives a plant.
ConstraintVAT had to be correct from the first invoice, not bolted on later.
ResultOne platform serving two operations that have almost nothing in common.
StatusIn production
Read the case study

All case studies

Questions we get asked.

The objections specific to this line, answered here rather than in a first call.

Do we have to use Guru ERP?

No. It is where we start when it fits the operation, because starting from a system that has already survived a production floor shortens delivery considerably. Where it does not fit we build for you, and we tell you which of the two it is before you commit rather than after.

Can we see it before we commit?

Yes. A public demo tenant runs Guru ERP and Guru POS on generated data, with the credentials printed on the product page. It resets overnight, so you can change anything in it.

How do you handle a plant that cannot stop for the migration?

That is the usual case and it is why the rollout is module by module rather than a cutover. Each module goes live behind a switch that can be thrown back, and the rollback is rehearsed rather than assumed.

Where to go next

You do not need to arrive with a perfect technical specification.

Start with the problem. Tell us what is slowing the business down, what you want to build, or where the current system is failing. We will tell you the shortest path forward, including when that path is not us.

Start your build