web.iti
ID

// systems · erp · modules follow your process

An ERP whose modules are written, not configured

If your core process doesn't fit any off-the-shelf ERP template, the answer isn't forcing your team to bend — it's building the part that's genuinely specific to your business, and leaving the rest where it already works.

Free scoping call → (opens in new tab)See the cost breakdown

Custom ERP development is the building of an integrated system — sales, purchasing, warehouse, production, and finance — whose modules are designed around your company's processes, not around the template of an off-the-shelf ERP product. Every module runs on one database, one item master, and one customer master, so warehouse figures and finance figures come from the same transactions. The difference from implementing a ready-made ERP product: here the modules are written, not configured. We build only the parts that are genuinely specific to your business — for the rest we'd suggest leaving things in the apps already running, and now and then we'll suggest you don't build anything at all. Full ERP projects range from Rp 15jt to Rp 60jt+, with 1-2 weeks of discovery and 6-12 weeks of build. The exact written scope, price, and timeline only land once process mapping is finished.

// why erp projects fail

Four ways an ERP project dies, and what you can put in place to stop it

Picture yourself in month five of your ERP project, and the only thing actually in use is the purchasing module. "Almost there, Pak — just finishing touches." What's slowing things down isn't the technical team, it's a request list nobody ever closed. ERP projects rarely die because the technology was wrong. There are four ways they die, and in week one all four look trivial. First, scope creep — every demo produces a "while we're at it", with nobody writing the schedule consequence on the same line. Second, the "we'll clean the data later" trap: duplicate item masters and stock discrepancies get carried straight in, and the new system inherits the old mess with a tidier screen. Third, a PIC with no authority — a diligent person, but every decision has to go up to the directors, and the project stalls in an inbox, not in the code. Fourth, training that stops on go-live day; two months later three warehouse staff resign, their replacements learn from a colleague who only half understands it, and by month six everyone's back on shadow Excel. We can't erase any of the four. What we can install are the countermeasures in the workflow: written scope limits per module, a data audit up front, one authorised PIC agreed from the start, and a refresher training session 30 days after go-live. The rest comes down to budget and management's willingness.

// building vs implementing an existing product

Two different jobs that get treated as one

AspectOff-the-shelf ERP rolloutCustom ERP
Time until it's genuinely in useFaster, and we won't pretend otherwise. Standard Odoo or ERPNext modules can be running in 4-8 weeks as long as your processes are willing to adapt. What stretches the timeline isn't the installation, it's the customisation requests that show up after the first month.Discovery 1-2 weeks, build 6-12 weeks, UAT 1-2 weeks, go-live 1 week. The release is phased: the warehouse module is usually in real use long before the last module finishes being built.
Fit with the processes you already runYour processes get mapped onto the product's built-in ones. Eight out of ten generally fit; the other two get solved through third-party add-on modules, or by asking the team to change how they work.Those two non-standard processes are exactly what gets mapped first — that's usually where your margin and your differentiation live. Modules are built around the exceptions, including when the normal rule can be broken and by whom.
Long-term per-user licence costPer-user, per-year licences for the paid editions, plus the cost of add-on modules. The community edition is licence-free, true, but implementation and upgrade services still get billed. This line item recurs every year for as long as the system is in use.There's no per-user licence. Adding 30 warehouse staff doesn't add to the annual bill — the only thing that moves is server capacity, in the hundreds of thousands per month. The heaviest cost sits up front, once.
Dependence on consultantsWorkflow changes generally go through a consultant who knows that product. The number of people who understand your customisations precisely is limited, and their rates follow that scarcity — especially heading into year-end.There's no product certification acting as a gate. The next person to take over just needs to read ordinary web code, and there are plenty of people like that in the Indonesian market — including your own internal team, if you have one.
Ability to change workflows yourselfApproval flows and extra fields can be changed through configuration, up to the limits the product provides. Beyond those limits a change turns into customisation, and every customisation has to be retested at each version bump.The approval matrix, amount thresholds, and workflow stages are stored as data, not buried in code. Your operations head shifts the routing themselves when someone changes role, with no queue waiting on us.
Risk when the vendor bumps the versionA major upgrade is a project of its own with a budget of its own. Customisations and third-party modules have to be retested; a module whose maker stops updating it pins you to the old version, security holes and all.There's no major version forced on you from outside. The only routine updates are security libraries, and the schedule is set by your own internal meetings. Functionality changes because you asked for it, not because somebody else shipped a release.

// modules we build

What ships with every ERP project

  • ✓A sequential sales module — quotation, sales order, delivery note, invoice — with per-tier customer pricing and credit limits that hold back orders on their own
  • ✓A purchasing module with requisition, approval, PO, and three-way matching between PO, goods receipt, and supplier bill
  • ✓Multi-location warehousing: inter-warehouse transfers, stock cards per SKU, stock counts with a written variance record
  • ✓A production module for those who need it — bill of materials, work orders, and cost of goods calculated per batch, not averaged out at month end
  • ✓One item master and one customer master across every module; the single biggest source of discrepancies between departments sits right here
  • ✓An approval matrix based on amount and job title, stored as data so you can shift it yourself without touching code
  • ✓Receivables and payables ageing, plus a due-invoice list whose reminders can be sent to customers automatically
  • ✓Integration with Accurate, Jurnal, Moka, Olsera, Pawoon, or HubSpot — sync direction set per field, in writing
  • ✓Dashboards per role: the warehouse head sees stock ageing, directors see margin per product, sales see their own pipeline
  • ✓A full document audit log with 10-year retention, following UU No 8/1997 on Company Documents
  • ✓Migration of master data and opening stock balances, reconciled against a physical count — not against the old records
  • ✓Operational reports with filters and Excel/PDF export, including the formats external auditors usually ask for
  • ✓Your own staging environment away from live data, daily database backups, and scheduled restore tests
  • ✓Source code and database schema owned by your company on final payment, Indonesian-language documentation, per-role training, and 3 months of bug fixes

// how it works

From process audit to a phased go-live

01

Process audit & the build-or-implement call

1-2 weeks. We sit down with the warehouse head, the purchasing admin, and finance — each one separately, because their versions of the same process often differ. Ten to fifteen core processes get mapped, then flagged: standard, or deviating. If only one or two deviate and the differences are cosmetic, we'll tell you an off-the-shelf implementation makes more sense, and the conversation stops there with no invoice. If the deviations sit at the heart of operations, the output of this stage is a scope document: the list of modules, roles, and approval paths that the final number is built on.

02

Module map, release order, and the integration boundary

Modules are sequenced, not run in parallel — we set which ones go into the first release and which ones wait. The boundary with the apps you already use is drawn per field, not per app. Decisions that have to be closed at this stage, for example: who owns the selling price, the ERP or the accounting software; who holds tax invoice numbering; whether stock is counted in one place only. Questions like that are cheap to answer now and extremely expensive to answer in month four. Wireframes for each module get tested on the people who'll use them before a single line of code is written.

03

Build by sprint, operational modules first

Build takes 6-12 weeks, split into two-week sprints with a demo at the end of each one. The warehouse and purchasing modules usually finish first and can be used for real while sales is still being built. Every new request that surfaces in a demo goes onto the change list, with its schedule impact written on the same line — you decide whether it lands in this release or the next. Running alongside the build, we audit the item and customer masters: duplicate SKUs, units that aren't consistent between warehouses, customers recorded three times with different spellings. The findings list goes back to your team to decide, because determining which data is correct isn't ours to call.

04

Integration, migration, and reconciliation testing

UAT runs 1-2 weeks in the staging environment, not on live data. Integrations with Accurate, Jurnal, or the POS get switched on first, then run for one full period with real data and compared: document counts, values per account, and stock positions all have to match. Opening stock balances are reconciled against the physical count, because the old records are precisely what you're leaving behind. Your team uses the system with day-to-day scenarios — rush orders, short deliveries, returns, partial payments. The bugs and confusion that surface here are the cheapest to fix in the whole project.

05

Phased go-live, layered training, handover

Go-live takes 1 week per wave, and we don't recommend every module switching on the same night. Training is split by role, with a one-page guide taped to the desk — not a sixty-page PDF nobody ever opens. Thirty days after go-live there's one refresher session; that's when the real questions surface, and that's also where old habits usually get caught creeping back. Handover covers the repository, hosting accounts registered in the company's name, the database schema, and technical documentation. Bug fixes in the first three months aren't billed separately, and you're free to turn down the maintenance contract afterwards.

// integration

What actually happens when we connect to what you already run

An ERP isn't one big application, it's an agreement about master data everyone shares. That's why the first question isn't "which technology", it's "which modules get built, which ones just get bolted on, which ones don't need to exist". What's worth building is the module carrying rules specific to you: stock allocation between branches, tiered pricing, customer credit limits, sales commission schemes, or job-order production. What's better bolted on through API integration: accounting, the shop till, and the CRM that's been running for years. What's better not built at all — payroll and fixed-asset depreciation; both are mature in off-the-shelf products and the rules change every year. On sequencing, building the finance module first is almost always wrong for a mid-sized company in Indonesia. There are three reasons. First, your accounting is most likely already running and is in fact the least broken part. Second, the general ledger sits downstream — if goods receipts are still written by hand, a new journal just speeds up the journey of a wrong number. Third, the finance module carries the most rules, so the first release slips and the team loses momentum before it ever sees a benefit. Start with the warehouse and goods receipt, then purchasing, then sales. The journal comes last, and can often just be pushed into the old accounting system without being rebuilt — that's also what keeps the numbers sensible.

// investment

Ranges, not packages

Tight scope

Rp 15-30jt

Three to five core modules, usually warehouse, goods receipt, and basic sales. One location, 1-3 roles, no third-party integration. It makes sense if you really only have one target: stock that finally matches what's on the shelf.

Most often chosen

Rp 30-60jt

The full chain from purchase requisition to billing, tiered approvals across job titles, one integration with accounting or a POS, and custom reports for the directors. Two to three warehouses. Requirements with this scope generally fall in this range, but the final figure follows process mapping and the written proposal.

Large scale

Rp 60jt+

Many branches or many legal entities, production with a bill of materials, high daily transaction volume, and migration from several sources at once. Released in phases so the transition risk stays controllable.

These are ranges, not packages, and none can be locked before process mapping. The number of modules, integrations, warehouses or branches, and the condition of master data determine the exact written quote. Full ERP work starts at Rp 15jt; a smaller one-module or integration request belongs to lighter Custom/Add-on scope. Cost drivers are explained on the system cost page, and terms remain in the terms & conditions.

// a good fit when

The conditions that make bespoke worth it

  • →Distributors or manufacturers with 30-200 staff, more than one warehouse, and stock that never matches the physical count
  • →Companies whose accounting is already tidy in Accurate or Jurnal, but empty on the operational side before the journal is even formed
  • →Businesses with tiered pricing, customer credit limits, or sales commission schemes that no product offers off the shelf
  • →Companies that tried a ready-made ERP and stopped halfway because two core processes couldn't be forced to fit
  • →Job-order or make-to-order manufacturers whose cost of goods has to be calculated per batch, not averaged at month end

// not a fit when

When you should just roll out an existing product

  • ✕

    Your processes are standard and the team is willing to adapt — implement Odoo or ERPNext through an implementer who genuinely knows it; it's faster to get running and cheaper in year one

  • ✕

    You need a complete suite down to payroll, fixed assets, and group consolidation in one product — that's SAP Business One or paid-edition Odoo territory, not bespoke work

  • ✕

    What you actually need is bookkeeping, invoicing, and tax reports — Accurate or Jurnal solves that this week, with no project at all

  • ✕

    You need the ERP live next month — our realistic timeline is 10-20 weeks, and cutting it means cutting the reconciliation testing

  • ✕

    The master data has no owner yet — appoint one person with the authority to decide which SKU is correct first, because without that the migration never finishes

// questions

What people usually ask first.

When should we just implement Odoo or ERPNext instead of building from scratch?

Count your core processes first, then flag which ones genuinely deviate from the norm. If eight out of ten can run as they are on the built-in modules, an off-the-shelf implementation is almost always cheaper and faster — find an implementer who knows that product, not us. We build bespoke, and bespoke is the wrong answer for a company with standard processes. The tipping point shows up when those two deviating processes are exactly where your margin lives: inter-branch stock allocation with its own rules, tiered pricing, commissions, or job-order production. Forcing that into an off-the-shelf product means heavy customisation, and heavy customisation is a debt collected every time a major version lands. If discovery shows you're in the first group, we'll say so in that same session.

Which module should be built first?

Almost always the one that generates the most documents and whose numbers get argued about most — in trading and manufacturing companies, that's the warehouse and goods receipt. Not finance. The general ledger sits downstream; if goods receipts are still recorded in a notebook, the fanciest journal module in the world just speeds up the journey of a wrong number. The order we use most often: warehouse, then purchasing, then sales and billing, journal last — and the journal frequently doesn't get built at all, just pushed into Accurate or Jurnal. There's an exception: if your biggest complaint is stuck receivables, sales and receivables ageing can move up into the first release. What we never recommend is switching on seven modules at once on the same day.

We already use Accurate. What can genuinely be synced, and what can't?

What connects cleanly: the customer master and item master one-way, plus journal pushes from documents that are already final — usually sent daily as a batch, carrying the source document number as a reference. What's never clean comes down to four things: stock counted twice in two systems, partial payment allocation across several invoices at once, returns against already-posted documents, and tax invoice numbering, which has to have a single source. Our rule is simple — one field, one owner, set down in writing at the architecture stage. Two-way sync isn't a feature you just switch on; it's operational discipline. The price of it: a daily variance report someone actually reads, a ban on manual edits in the downstream system, and one person responsible for closing variances before month end. If that person doesn't exist, we'd suggest one-way only — more boring, and far less likely to blow up. We go into the technical detail on the [integration page](/layanan/crm-integration).

How long until the ERP is in daily use?

The honest numbers: discovery 1-2 weeks, build 6-12 weeks, UAT 1-2 weeks, go-live 1 week. For two or three modules the total often lands at 10-14 weeks; for the full purchasing-to-billing chain plus integrations, 16-20 weeks is more realistic. But "in use" doesn't arrive all at once — the warehouse module is usually in real use by week eight, while sales is still being built. What shifts the schedule most often isn't the coding, it's two things on your side: deciding who has authority to approve above a given amount, and cleaning the master data. If those two run on time, the schedule holds tight. We lay out the full sequence of stages in [how we work](/cara-kerja).

What determines the number, and why do other vendors quote a price up front?

Vendors putting a fixed opening figure in a headline may be costing an off-the-shelf implementation with standard modules. Custom ERP work needs its modules counted one by one. The full-system ranges are Rp 15-30jt, Rp 30-60jt, and Rp 60jt+, while the number of modules, integrations, warehouses or branches, and the state of master data determine the exact written quote after discovery.

How do you hold back scope creep without making us feel locked in?

By separating two things that often get mixed up: a change in understanding and an addition to scope. If a demo shows we misunderstood a flow that was already agreed, that's a fix and it adds nothing. If what surfaces is a new module or field, that's an addition — logged on the change list with its schedule and cost impact on the same line, and then you decide whether it goes in this release or the next. What we don't do: nod and smile at everything, then quietly move the go-live date. This boundary is also written into the [terms & conditions](/syarat-ketentuan), so it doesn't depend on anyone's memory after month three.

Our item master is a mess. Clean it first, or clean it as we go?

As you go, but with a deadline — and never "after go-live". In practice the data audit starts in week three alongside the build, and produces a findings list: duplicate SKUs, different units between warehouses, customers recorded three times with different spellings, negative stock values. Deciding which one is correct sits with your team; we have no authority to choose, and we won't pretend to know. For 5-10 thousand SKUs, this stage realistically takes 2-4 weeks of internal team effort, and most of that load genuinely sits on your side. A system built on dirty master data just produces dirty reports faster — that's the only difference.

How do we stop the team quietly going back to Excel after go-live?

Treat this as the main risk, not a side issue. Four things we put in place. First, the people who run the process help test the wireframes before code is written — the fiercest resistance always comes from people who feel the system was handed down from above. Second, the wording on screen uses the wording used on the floor, including internal abbreviations no outsider would understand. Third, training is split by role and repeated 30 days after go-live, when the real questions finally surface. Fourth, shadow Excel is easy to detect: a module whose transaction count sits far below the estimate means someone's still recording things somewhere else. The boundary is clear — we can build the tooling and the alarms, enforcing the policy stays with your management.

Have you done ERP projects before? Can we see the client list?

No client logo is displayed without consent. This pillar contains one composite Karanganyar cooperative narrative, not proof of a manufacturing ERP project. The relevant pattern is legacy-data audit, parallel testing, reconciliation, and [handover](/sistem). The 1,800-member, six-days-to-four-hours, and +78% figures are only reported in that narrative; no consent reference, supporting artifacts, raw data, or public URL is available, so they cannot be independently verified or used as a guarantee.

// go next

Related pages

Composite narrative: one data source for 1,800 members

Not an ERP project; no consent reference or public artifacts are stored in the repository, figures are not independently verified, and results are not guaranteed.

Custom Warehouse Inventory App Development

A custom warehouse system: multi-location, inter-warehouse transfers, batch and expiry, stock counts with variance approval, unit conversion, POS sync.

Custom Business System Development

If daily operations still run on spreadsheets that clash and a manual scramble every month-end, what you need isn't another website — it's a system that follows how you already work.

// ready to start?

Build Your Business a Website
Right Now!

Free consultation via WhatsApp. We review your needs, give you a time & price estimate, then start together — no drama.

Free Consultation via WhatsApp → (opens in new tab)Check pricing

→ See examples of our workTerms & Conditions