A System Usable in Indonesia and A User-Friendly System

Project success means completing the project on schedule and having the system operate according to requirements. As a result, this means a system usable in Indonesia has been created, but a user-friendly system is one with a gentle interface where the desired operations are immediately apparent.

The Common Gap Between Systems and On-Site Operations

Regarding the discrepancy (GAP) between systems and on-site operations, system implementation won’t succeed without the mindset of covering some aspects through operations. The following are common GAPs that tend to occur when introducing business systems in Indonesia:

• Case 1
  At a factory, production results are entered by the production management staff at 10:00 AM the following day, but if the night shift completes and ships products immediately, the system shows insufficient product inventory, preventing the issuance of a Delivery Order.
• Case 2
  For a trading company purchasing goods, even if the items have arrived, if the invoice hasn’t, the system cannot register the purchase, so the received goods aren’t reflected as inventory, halting shipment processing.
• Case 3
  On-site, it’s normal to print shipping instructions for the next day’s shipments the day before to prepare, but if the system bases shipping instructions on inventory allocation, insufficient stock prevents issuing them.
• Case 4
  When issuing a shipping instruction for 20 out of 100 ordered items, you’d want to track the remaining 80 as "ordered but not yet instructed." However, the system typically shows zero backlog until the shipping process is complete, only then recognizing the 80-item backlog.
  • Order: Shipping Instruction = 1:1
  • Order: Shipment Completion = 1:N

  In the system flow of "Order - Allocation - Shipping Instruction - Shipment Completion," if orders and shipping instructions can only be split 1:1, even though it’s correct system behavior, it causes operational inconvenience.

• Case 5
  When procuring materials for a factory, if the supplier sends a monthly invoice the following month, the invoice number isn’t known within the current month. Materials received and used immediately for production costs cannot be registered, preventing cost calculation entries.
• Case 6
  In a system handling order registration, shipment processing, and invoice issuance, corrections inevitably arise before month-end closing. Until these corrections are completed, physical inventory cannot be reflected in the system.
• Case 7
  There are cases where on-site staff can’t keep up with a system flow that assumes scanning barcodes on material tags for issuance and return, entering results each time defective or separately managed items occur, and attaching tags.
• Case 8
  If errors are found during physical inventory input and mid-month production results need retroactive correction, but the lot has already reached the customer, downstream invoices and delivery orders must be canceled sequentially. This reassigns invoice and delivery order numbers, affecting document management at the customer or partner, making corrections impossible.

Defining "Usable" and "User-Friendly"

Japanese manufacturing companies in Indonesia lag far behind China or Thailand in systemization, and replacing Excel-based manual processes with business systems has only recently become commonplace. Let me clarify: systemization isn’t always a good thing.
My definition of "a system is usable" or "a system is user-friendly" is:

However, "user-friendly" only comes after "usable"—the reverse isn’t possible.

You might hear such complaints, but reaching a level where operations run smoothly on the system requires significant effort from both the implementing and receiving sides.

How to Implement a Usable System?

Anyone who decides to pay for a system naturally feels anxious about "Will the project succeed?" Fundamentally, "project success" boils down to:

These two points.

Will It Be Completed Within the Planned Period?

"Whether it’s completed on time" is an issue during system implementation. System cutover (called "Go Live" more commonly in Indonesia?) often aligns with the fiscal year start in January or April. Missing this means prolonged double input with the old system, increasing workload and preventing core tasks—effectively an opportunity loss.
Causes of schedule delays include:

Task omission is rare with packaged software since tasks are mostly fixed, but with development-heavy systems, effort estimation errors can occur.
The implementation process starts with a Request For Proposal (RFP) from the customer, followed by a proposal and estimate based on it. At this stage, user requests aren’t 100% captured, forcing rough effort estimates.

Thus, once implementation begins and requirements definition starts, unexpected exceptions often increase effort.
Additionally, overlooking non-working days—like the shifting Ramadan period in Islamic regions—can cause miscalculations. During Ramadan, staff leave early, and flexibility is limited. Elections or protests in Indonesia can also unpredictably halt factory operations for half a day.

Will the System Function Properly?

This is an issue after implementation, essentially "Can operations run smoothly on the system?" Risks can be mitigated by carefully assessing whether packaged software matches company operations during selection.
Reasons a system might not function properly include:

Packaged systems are designed for broad use, so even if 80% fit, 20% GAP remains. If that 20% affects core operations, it’s a significant investment loss.
I’ve seen a case where a system only supported moving average or FIFO costing, but operations followed Japan’s directive to use total average costing, rendering the system unusable.
Even with lot management via material tags, if results aren’t entered for the correct lot, staff stop input arbitrarily due to missing lots, or inventory accuracy suffers with untagged lots scattered on-site—common in Indonesian factories.
Designing a theoretical business flow and matching applications to it can leave the site unable to adapt post-launch.

For Risk Mitigation

In fact, points and factors likely to cause delays in the implementation schedule can be roughly predicted.
When creating a schedule, breaking it down from monthly to weekly and daily as a master schedule, and detailing tasks on the vertical axis, makes it easier to visualize tasks and timelines horizontally and vertically.

Factors that could delay the schedule include issues from both the implementation side and the customer side:

In the overall schedule, the blue section is where Fit and Gap between user requests and standard system specs are identified, defining business and application flows during requirements definition. The red section is prone to delays, pushing subsequent phase tasks.

When implementing a system, customer scenarios fall into three patterns: new startup, Excel-based manual processing, or existing systems. Broadly, new factories are easiest, while the hardest are those with standalone systems scattered across departments. Introducing a new system to an existing setup causes friction during the project.
With an existing ERP, a full replacement levels the playing field across departments, so even reluctant staff input data. But when standalone systems—like a purchasing P/O issuance tool or a cheap local accounting package—are fragmented, operating independently without inter-departmental communication, it’s the toughest case.
Advancing the project with this awareness, sharing progress vs. plan weekly, can reduce delay risks.

How to Implement a User-Friendly System?

After overcoming these challenges and getting operations running on the system, end-users will inevitably demand more:

User-friendly means "easy to operate with convenient features," but the prerequisite is an interface where "desired operations" are immediately clear.

I believe these three are must-have specs in Indonesia. Beyond that, adding functions for Indonesia’s unique business practices and tax systems requires significant customization.

These are examples of features Japanese firms in Indonesia would find user-friendly, but they’re still usable without them.
It’s cliché, but you need to draw a line between what convenient features to implement and what to handle manually. For this, end-users must understand "customization takes effort."
Too many in Indonesia expect everything for free.