How We Built a Custom ERP for a Precast Concrete Plant

PT. Indo Karya Beton casts precast concrete in Central Java and sells it by the contract, not by the item. A single job runs for months: a contract sets a ceiling per product, sales orders draw against that ceiling, the plant produces to spec, trucks deliver in batches against surat jalan, and invoices follow the deliveries. That work lived in spreadsheets, printed books and accounting software that did not talk to each other — so answering "how much of this contract is left?" meant adding up sales orders by hand. We built IKB a custom ERP modelled on their own document chain, and the short version of what made it work is this: we did not start from an ERP template, we started from their paperwork.

Key Takeaways

• Off-the-shelf ERP fits most businesses. It fits badly when the document chain itself is the business, which is the case in contract manufacturing.
• Every document in the system knows its parent — so a contract's remaining ceiling calculates itself, and every invoice line traces back to the delivery that earned it.
• The catalogue is modelled as family plus specification, not a flat product list, because that is how the plant and the contractors both talk about spun pile.
• Purchasing was rebuilt on the same chain, so buying and selling finally share one stock figure.
• The interface is in Indonesian, with role-based access and command-K search — an internal tool is only as good as the adoption it gets.

Who is IKB, and why didn't off-the-shelf ERP fit?

IKB manufactures PC spun piles and related precast products for contractors on infrastructure and building projects across Indonesia. The catalogue alone runs to dozens of variants — spun pile in A, AB and B classes, diameters from 400 to 500, wall thicknesses from 75 to 120.

Standard ERP products assume a fairly standard shape: you sell items, you ship them, you invoice them. IKB's shape is different in three ways that compound.

• The contract is the unit of business, not the order. Everything downstream draws against a ceiling agreed months earlier.
• Delivery is incremental. One order becomes many truckloads over weeks, each with its own surat jalan.
• The paperwork is Indonesian, and non-negotiable. Surat jalan, berita acara, tanda terima and proforma are not translations of Western documents — they are the documents the business and its customers actually exchange.

You can bend a template into that shape. What you get is a system where the most important number in the business — how much of this contract is still open — lives outside the system, in someone's spreadsheet.

What was actually broken?

Before the build, the operation ran across three disconnected surfaces: spreadsheets, printed books and accounting software. The failure modes that produces are predictable, and IKB had all of them.

• Contract balances were manual. Working out remaining quantity meant summing sales orders by hand, every time someone asked.
• Deliveries and invoices were reconciled by eye. That is exactly where double-billing and missed billing come from — the two errors that cost the most and get caught the latest.
• Recorded stock drifted from yard stock. Two numbers, no single source.
• Purchasing was disconnected. Material, supplier POs and goods receipts had no link to what the plant had committed to produce.

Note that none of these are software problems. They are all the same problem: no document knew what any other document meant.

Why did we model the document chain instead of starting from an ERP template?

Because IKB's paperwork was already a working data model. It had been refined by years of operating a plant, and every document in it existed because something in the business required it.

So the system was built to mirror it end to end:

Contract → sales order → proforma → surat jalan → berita acara → tanda terima → invoice → pembayaran.

Each document knows its parent. That single rule is what makes the rest work:

• A contract's ceiling draws down on its own as sales orders and deliveries are entered. Nobody maintains the balance, because nobody has to.
• Every invoice line traces back to the delivery that earned it, which closes the door on billing the same truckload twice or never billing it at all.
• Any surat jalan reads backwards to its sales order and forwards to its invoice, so "where is this order?" is a lookup, not an investigation.

This is the transferable part of the project. When a business has run for years on a specific chain of documents, that chain is not bureaucracy to be modernised away — it is domain knowledge, already encoded. The fastest route to a system people will actually use is usually to model what they do, then remove the manual arithmetic between the steps.

How do you model a catalogue that isn't a flat product list?

A spun pile is not one product. It is a family with a specification: class, diameter, wall thickness, length. A flat product list forces every combination into its own row, which is how catalogues end up with hundreds of near-duplicate entries that nobody trusts.

So the catalogue is modelled as family plus spec — the way the plant and the contractors both talk about it. A family carries the identity; the spec carries the variants; stock is tracked at the level that matters for production and delivery.

Getting this wrong is one of the more expensive mistakes in a manufacturing build, because the product model sits underneath everything: orders, stock, delivery and invoicing all inherit its assumptions. It is worth spending the extra week on.

What does connecting purchasing to production actually fix?

Purchasing mirrors the same chain on the buying side: purchase request → supplier PO → goods receipt → supplier invoice → freight bill.

The point is not tidiness. It is that both sides of the business now read from one stock figure. Before, the sales side committed to quantities against a number the buying side could not see, and the buying side ordered material against demand it had to be told about. Joining the two chains at stock is what turns two systems into one.

Why is the interface in Indonesian?

Because that is what the team speaks. It sounds obvious written down, and it is routinely ignored — internal tools get shipped in English because the developers wrote them in English.

An internal system earns its cost through adoption. Every extra second of translation between what a person is doing and what the screen is asking is a reason to go back to the spreadsheet. Three decisions followed from that:

• Indonesian throughout, using the document names the business already uses.
• Command-K search that jumps straight to a PO, invoice or surat jalan by number — the operation runs on document numbers, so the search does too.
• Role-based access, so the owner, the plant and the office each see their own slice instead of the whole ERP.

New staff are walked through the system by a step-by-step in-app guide rather than by a colleague's memory, and the interface follows light, dark or system theme — a small thing that matters when half the team works from a plant office and half from a screen at night.

What does IKB have now?

Contracts, sales orders, deliveries, invoicing, stock, purchasing and payroll run out of one system. Remaining ceiling per product is visible on the contract itself. Any delivery note traces back to its sales order and forward to its invoice. The buying and selling sides share a stock figure.

The full breakdown, with more screens from the build, is on the Indo Karya Beton case study.

When is a custom ERP the wrong call?

Most of the time. Off-the-shelf systems are cheaper, faster to deploy, maintained by someone else, and good enough for the large majority of businesses. Custom is the exception, and it is worth being honest about when it is justified:

1. Your document chain is the business. If the sequence of documents encodes how you actually operate, a template will fight you at every step.
2. The workaround has a headcount. When people are employed largely to move data between systems, that salary is already paying for a build.
3. The errors are expensive and late. Missed billing and stock drift are found weeks after the fact, which is what makes them worth engineering out.
4. Your terminology has no English equivalent. Local documents and local practice are a genuine sign that a global template will not fit.

If none of those apply, buy the product. If two or more do, the sums usually favour building — and at Lenka Studio we would rather tell you which of those you are before anyone writes a line of code.

Frequently Asked Questions

If your operation has outgrown its spreadsheets, we would be glad to look at it with you. Tell us what you are running on and we will come back within 24 hours with a free consultation — no strings attached.