CHAS ERP Case Study: Unifying Scattered Operations into One Integrated System

There is one pattern I keep seeing in many businesses that have been growing for a few years: on the surface, operations run smoothly, but behind the scenes the data is scattered everywhere. Sales are recorded in one Excel file, stock is counted manually in the warehouse, purchase requests go through chat, and financial reports are reassembled at the end of every month. Everything "works" — until something goes wrong, and no one can confirm which number is correct.

The CHAS ERP project was born from an even more challenging situation: not replacing spreadsheets, but modernizing an ERP system already used daily by dozens of employees. I wrote this article as an honest business digitalization case study: how the system was conceived, what decisions I made, and what considerations you should weigh before walking down a similar path.

Context: A Legacy ERP That Could Not Stop

PT. Cipta Hasil Sugiarto (CHAS) already had an ERP: fleet.chas.co.id, a pure PHP application without a modern framework, with 193 pages used every day for purchasing, warehouse, finance, and operations. This was not a system that could be switched off and replaced overnight — inside it were thousands of transactions, master data, and work habits that had formed over years.

An analysis of Nginx access logs showed roughly 2.44 million requests over six weeks. That number taught two important lessons. First, the system was genuinely alive and in use. Second, not all parts were equally important — some modules were accessed hundreds of thousands of times, while others were barely touched. It was from that data that the modernization priorities were set, not from a list of features that sounded impressive.

Signs That a Legacy ERP Needs Modernization

From the experience of this project, the signs are fairly consistent:

• Every page re-fetches master data (dropdowns, item lists) — it feels slow and burdens the server.
• API code is duplicated per endpoint and per date, so a single fix has to be copied to many places.
• Approval processes (purchase requests, cash advances, leave) still depend on flows that are hardcoded per document.
• Attachments are scattered across each module's endpoints, with no centralized storage.
• Reports and summaries can only be assembled manually, and there is no concise dashboard for management.
• If one key person is absent, operations stall along with them.

One sign alone does not necessarily mean anything. But if three or more of these feel familiar, it is usually the right moment to start talking about modernization.

The CHAS ERP Solution: One Source of Data, Built in Phases

I built CHAS ERP on a simple premise: one source of data for core business processes, with clear roles and access rights — who may see what, who may approve what. The stack is SvelteKit (Svelte 5) on the frontend, NestJS on the backend, PostgreSQL with Drizzle ORM, plus Redis for caching and MinIO for centralized attachment storage.

You can see the module details and the approach in the CHAS ERP project portfolio, but in essence it works like this: every transaction is recorded once, in the right place, and the derived information — reports, statuses, notifications — follows automatically. There is no longer an "Excel version" of the same data.

What I emphasized from the start: ERP here does not mean a giant application packed with countless features. What is needed is an application that fits the business processes, not the other way around.

How This Project Was Executed: Starting from Processes and Data, Not a Feature List

The most common mistake in ERP projects is starting from a feature list. I deliberately avoided that path. The first step of this project was to map the processes that actually happen and read real traffic data: which modules were used most often, which endpoints failed most frequently, and at which points work was most often repeated.

From there, the migration was split into eight phases. The modules that caused the most problems and were used the most came first — Purchasing, then Warehouse & Inventory, Finance, Accounting, Operation, Workshop, and finally Marketing. The HRMS module (attendance, leave, overtime, payroll master) and Asset Management, on the other hand, were already running earlier and connected to the CHAS mobile application.

The hardest part was not writing the code, but moving the data without stopping operations. Master data — 187,805 items, 5,437 employees, 3,189 suppliers, 1,596 customers, and 1,856 heavy equipment units — was migrated via Change Data Capture (CDC) from the old database to PostgreSQL. The old ERP kept running read-only until every module was ready for cutover, so there was not a single day when employees lost their system.

The most important lesson from this project: a successful ERP is not the one with the most features, but the one whose flow most closely resembles how your business works day to day. If a system forces people to change their habits, it will be abandoned — no matter how good the code is.

Qualitative Results and an Honest Assessment: When a Business Needs an ERP, and When It Doesn't

The most noticeable results after the system went live are qualitative, and that is precisely what makes them most valuable: no more debates about "which number is correct", summaries no longer have to be assembled manually from multiple sources, and the trail of every transaction can be traced without having to ask a specific person. Accountability also became clearer because every step has an owner within the system.

But I want to be honest about the other side: ERP is not for everyone. If a business is still very small, its processes are still changing frequently, or the volume does not yet demand it, a well-organized spreadsheet may be enough — building an ERP too early can be a waste. Conversely, if the signs above are felt every month, delaying means letting those hidden costs keep running. The term ERP often sounds like a big-corporation affair, yet an ERP application for SMEs is actually most useful at exactly this kind of transition point.

Another equally important consideration is choosing who will build the system. I discuss this in more depth in the article about an honest way to choose between a solo developer and a software agency for a business application. The same approach — starting from processes, not features — was also applied in the CHAS heavy equipment transportation operations system project, because the principle is the same: the system must follow how the field works, not force it.

If you are facing a similar situation — an old system that is starting to hold you back, fragmented data, manual summaries, numbers that never reconcile — I would be glad to discuss whether a system modernization like CHAS ERP fits your business stage right now, or whether it is indeed still too early. Tell me about your operational situation through the contact page, and we will start from your business processes, not from a feature list.