Why Do ERP Projects Fail Even When the Software Is Good?

From our experience delivering custom software and ERP projects, the biggest problems rarely appear while developers are building features. They usually surface when the system reaches day-to-day operations. The menus exist, reports work, approval workflows are available, yet employees continue using Excel, asking for approval through WhatsApp, or keeping personal notes because the underlying business process was never properly agreed upon.

Consider a distributor handling purchasing, sales, inventory, and finance. The ERP already provides purchase orders, goods receipts, sales orders, stock adjustments, invoices, and payment records. Technically, the feature set may be sufficient. But the warehouse manager continues using a private spreadsheet because nobody established who is authorized to change inventory. Sales enters "Kopi 250g," the warehouse uses SKU "KOPI-250," and finance uses another accounting reference. The same product now has multiple identities.

The management team may conclude that the ERP is the problem. In reality, the software is simply executing the data and rules it has been given. Oracle notes that ERP implementation success depends on areas such as user adoption, process alignment, data quality, and enterprise fit, rather than software selection alone. https://www.oracle.com/asean/erp/what-is-erp/implementation/

One of the most common mistakes is choosing an ERP based primarily on its feature list and only afterward trying to fit the business around it. A stronger ERP implementation starts by understanding critical processes, defining business rules, cleaning master data, and then deciding which configuration or customization is actually necessary.

In ERP implementation, master data often looks like simple administrative work. In reality, its quality affects almost every downstream transaction. Products, SKUs, units of measure, customers, suppliers, warehouses, chart of accounts, price lists, tax settings, and bank accounts are not merely dropdown values. They become the foundation for transactions, inventory, reporting, and accounting.

Imagine a company with 3,000 products. Before implementation, product records may come from Excel files, marketplaces, a POS system, and purchasing notes. Product names may vary: "Cooking Oil 1L," "Oil 1 Liter," and "OIL-1L." If all three refer to the same item but are migrated as separate SKUs, inventory and sales reporting will be fragmented. The ERP may then appear to produce incorrect reports even though the underlying problem is bad master data.

The same issue applies to customers. The same company might appear as "PT ABC," "ABC Indonesia," and "PT ABC Indonesia," with phone numbers formatted differently. Without deduplication rules, customer history becomes fragmented. For businesses selling through marketplaces, websites, WhatsApp, and offline channels, the problem can become even more significant because each channel may identify customers differently.

Master data also affects accounting. Electricity, internet, transportation, marketplace fees, and stock-transfer costs may all need clear accounting mappings. If admins freely select accounting codes without defined rules, the profit-and-loss report may look complete while classifications remain inconsistent. SAP's Master Data Governance documentation describes centralized governance, validation, duplicate checks, approval workflows, and change tracking as mechanisms for maintaining consistent master data in complex ERP environments. https://help.sap.com/docs/SAP_ERP_SPV/f184745abebf416bb931952badbfa43c/3eb67a9facd34cb09ce87e3bc24b4c52.html

That is why one of the most practical ERP implementation tips is to clean and validate data before migration rather than waiting until production transactions expose the problems.

An ERP forces a company to become explicit about who does what. That can be uncomfortable. Before implementation, a company may rely on informal processes: sales sends an order through WhatsApp, an admin asks the warehouse to check stock, the warehouse responds, and the owner gives verbal approval. Once the ERP is introduced, those steps need to become defined statuses, permissions, and responsibilities.

For example, a sales process may use Draft, Submitted, Approved, Processing, Shipped, Completed, and Cancelled. Who can move Draft to Submitted? Can sales change the price after approval? Who can cancel an order after packing has started? If those questions are unanswered, the software may have the buttons, but the business does not have the rules.

This is especially relevant in Indonesian businesses where WhatsApp is heavily used for daily coordination. WhatsApp is convenient for requesting approval, but a chat conversation should not become a substitute for a controlled workflow. If an owner says "okay, ship it" in WhatsApp while the ERP still shows the order as pending approval, the company no longer has a reliable transaction status.

During ERP implementation, we normally recommend building SOPs around actual transactions rather than creating long theoretical documents. Take one process such as purchasing: purchase request, approval, purchase order, goods receipt, quantity verification, supplier invoice, and payment. Define the owner of each stage and the conditions required before the transaction can move forward.

A good SOP does not need to eliminate flexibility. A company can provide an override or special approval workflow for exceptional cases. The important point is that exceptions are recorded and auditable rather than handled invisibly through chat messages.

ERP implementation is not an IT-only project. Developers can build workflows, databases, APIs, dashboards, and permissions, but they should not decide whether sales can change an approved price or whether the warehouse can perform a stock adjustment without supervisor approval. Those are business-policy decisions.

Problems appear when company owners attend only the software demo and then tell the operations team to "figure it out" after launch. Employees discover that some workflows do not match how the company actually operates. Because there is no management decision-maker, developers receive one change request after another. One week it is feature A, the next week exception B, followed by workflow C because a branch manager has a different working habit.

For small and mid-sized ERP implementation projects, we generally prefer having one clearly designated decision-maker. That does not mean every decision must wait for the owner. It means decision authority should be defined so operational issues can be resolved quickly.

Management must also establish priorities. A company may want purchasing, inventory, sales, accounting, CRM, HR, payroll, marketplace integration, and WhatsApp automation in the first release. Technically, many of these can be built, but the project risk rises substantially as scope expands.

A safer approach is to define the core flow. For a distributor, for example: purchasing → receiving → inventory → sales → delivery → invoice → payment. Once that process is stable, additional modules and integrations can be introduced. A successful ERP implementation does not necessarily mean every available feature is active on day one.

The most practical way to reduce risk is to treat ERP implementation as a business-process transformation supported by software, rather than buying software and simply installing it. Before extensive development or configuration begins, the company should map each critical process from its starting transaction to its final outcome.

For example, an online sales process might look like this: website or marketplace order → customer and SKU validation → inventory check → stock reservation → payment → picking → packing → shipping → invoice → payment recording. Mapping this flow reveals what data is required, who owns each step, which system is the source of truth, and when the transaction status changes.

Then run a pilot using realistic data and realistic transactions. Do not test only one simple order. Test an order with two SKUs, nearly depleted inventory, a new customer, discounts, cancellation, returns, failed payment, and an address change. If the company uses Shopee, Tokopedia, WhatsApp, or its own website, those channels should be included in testing.

We also recommend measuring ERP implementation using operational indicators rather than simply declaring that "the system is live." Track how many transactions are still re-entered manually, how many stock adjustments are performed manually, how many invoices require correction, how long approvals take, and how many transactions fail because of master-data issues.

Go-live is not the finish line. The first few weeks usually reveal issues that were invisible during analysis. The important thing is to have a mechanism for recording problems, prioritizing them, and distinguishing software bugs from SOP or data problems. If every issue is classified as a software bug, developers will keep modifying the system while the underlying business problem remains unresolved.

As we regularly see at Sahabat Teknologi, a healthy ERP project is not the project with the largest number of features. It is the project that gives the business better control over its core processes, more consistent data, less manual work, and management information that can actually be trusted.