{"id":94305,"date":"2015-06-16T21:12:32","date_gmt":"2015-06-16T14:12:32","guid":{"rendered":"https:\/\/bahtera.jp\/indonesia-erp\/"},"modified":"2025-03-20T12:57:21","modified_gmt":"2025-03-20T05:57:21","slug":"indonesia-erp","status":"publish","type":"post","link":"https:\/\/bahtera.jp\/en\/indonesia-erp\/","title":{"rendered":"A System Usable in Indonesia and A User-Friendly System"},"content":{"rendered":"

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.
\n\t\t\t\t\r\n\t\t\t\t

\r\n\t\t\t\t\t\t\t\t\t\t
\r\n\t\t\t\t\t\t
\r\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\u30a4\u30f3\u30c9\u30cd\u30b7\u30a2\u306e\u751f\u7523\u7ba1\u7406\u30b7\u30b9\u30c6\u30e0\u307e\u3068\u3081\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/dt>\r\n\t\t\t\t\t\t
\r\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t

Production Control System in Indonesia<\/p>\r\n\t\t\t\t\t\t\t\r\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t

\r\n\t\t\t\t\t\t\t\t\t

It\u2019s not limited to Indonesia, but it\u2019s often said that the ultimate goals of the manufacturing industry are twofold: “cost reduction through productivity improvement” and “delivering products on time without delays.” From a management perspective, business plans are crafted to maximize growth based on market supply and demand adjustments. However, even if sales increase due to low pricing, it only reduces gross profit, leading to losses from selling and administrative expenses or non-operating costs. On the other hand, raising unit prices isn\u2019t straightforward due to market price considerations. Therefore, process management based on production plans aimed at reducing costs through … <\/p>\n\t\t\t\t\t\t\t\t<\/div>\r\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t

\u7d9a\u304d\u3092\u898b\u308b<\/p>\r\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/dd>\r\n\t\t\t\t\t<\/dl>\r\n\t\t\t\t<\/div>\r\n\t\t\t\t<\/a>\r\n\t\t\t\t<\/p>\n

The Common Gap Between Systems and On-Site Operations<\/h2>\n

Regarding the discrepancy (GAP) between systems and on-site operations, system implementation won\u2019t 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:<\/p>\n

    \n
  • Case 1
    \nAt 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.<\/li>\n
  • Case 2
    \nFor a trading company purchasing goods, even if the items have arrived, if the invoice hasn\u2019t, the system cannot register the purchase, so the received goods aren\u2019t reflected as inventory, halting shipment processing.<\/li>\n
  • Case 3
    \nOn-site, it\u2019s normal to print shipping instructions for the next day\u2019s shipments the day before to prepare, but if the system bases shipping instructions on inventory allocation, insufficient stock prevents issuing them.<\/li>\n
  • Case 4
    \nWhen issuing a shipping instruction for 20 out of 100 ordered items, you\u2019d 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.<\/p>\n
    \n
    \n
      \n
    • Order: Shipping Instruction = 1:1<\/li>\n
    • Order: Shipment Completion = 1:N<\/li>\n<\/ul>\n<\/div>\n<\/div>\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\u2019s correct system behavior, it causes operational inconvenience.<\/li>\n

    • Case 5
      \nWhen procuring materials for a factory, if the supplier sends a monthly invoice the following month, the invoice number isn\u2019t known within the current month. Materials received and used immediately for production costs cannot be registered, preventing cost calculation entries.<\/li>\n
    • Case 6
      \nIn 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.<\/li>\n
    • Case 7
      \nThere are cases where on-site staff can\u2019t 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.<\/li>\n
    • Case 8
      \nIf 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.<\/li>\n<\/ul>\n

      Defining “Usable” and “User-Friendly”<\/h2>\n

      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\u2019t always a good thing.
      \nMy definition of “a system is usable” or “a system is user-friendly” is:<\/p>\n

      \n
      \n
        \n
      1. A system is usable = Business operations can run on the system.<\/li>\n
      2. A system is user-friendly = It\u2019s easy to operate with convenient features.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n

        However, “user-friendly” only comes after “usable”\u2014the reverse isn\u2019t possible.<\/p>\n

        \n
        \n
          \n
        • We paid for the system, so it being usable should be a given, right?<\/li>\n<\/ul>\n<\/div>\n<\/div>\n

          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.<\/p>\n

          How to Implement a Usable System?<\/h2>\n

          Anyone who decides to pay for a system naturally feels anxious about “Will the project succeed?” Fundamentally, “project success” boils down to:<\/p>\n

          \n
          \n
            \n
          1. Completion within the planned period, and<\/li>\n
          2. The system functioning properly.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n

            These two points.<\/p>\n

            Will It Be Completed Within the Planned Period?<\/h3>\n

            “Whether it\u2019s 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\u2014effectively an opportunity loss.
            \nCauses of schedule delays include:<\/p>\n

            \n
            \n
              \n
            1. Overly optimistic task effort estimates.<\/li>\n
            2. Incomplete task identification, leading to unexpected tasks eating up effort.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n

              Task omission is rare with packaged software since tasks are mostly fixed, but with development-heavy systems, effort estimation errors can occur.
              \nThe 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\u2019t 100% captured, forcing rough effort estimates.<\/p>\n

              RFI (Request For Information) was my first invite to a Zoom meeting, only to see familiar industry faces lined up. Unlike an RFP (Request For Proposal), I realized this was a 1-to-N bidding scenario\u2014panicked and awkward.<\/div>\n

              Thus, once implementation begins and requirements definition starts, unexpected exceptions often increase effort.
              \nAdditionally, overlooking non-working days\u2014like the shifting Ramadan period in Islamic regions\u2014can 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.<\/p>\n

              Will the System Function Properly?<\/h3>\n

              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.
              \nReasons a system might not function properly include:<\/p>\n

              \n
              \n
                \n
              1. Post-launch gaps between operations and the system cause input delays.<\/li>\n
              2. Operations can\u2019t keep up with the system, slowing input.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n

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

                For Risk Mitigation<\/h3>\n

                In fact, points and factors likely to cause delays in the implementation schedule can be roughly predicted.
                \nWhen 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.
                \n\"For
                \nFactors that could delay the schedule include issues from both the implementation side and the customer side:<\/p>\n

                \n
                \n
                  \n
                1. Resource shortages on the implementation side<\/li>\n
                2. Effort estimation errors<\/li>\n
                3. Task omission<\/li>\n
                4. Overlooking non-working days<\/li>\n
                5. Delays in finalizing master data<\/li>\n
                6. Delays in result input<\/li>\n
                7. Incomplete requests<\/li>\n<\/ol>\n<\/div>\n<\/div>\n

                  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.
                  \n\"For
                  \nWhen 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.
                  \nWith an existing ERP, a full replacement levels the playing field across departments, so even reluctant staff input data. But when standalone systems\u2014like a purchasing P\/O issuance tool or a cheap local accounting package\u2014are fragmented, operating independently without inter-departmental communication, it\u2019s the toughest case.
                  \nAdvancing the project with this awareness, sharing progress vs. plan weekly, can reduce delay risks.<\/p>\n

                  How to Implement a User-Friendly System?<\/h2>\n

                  After overcoming these challenges and getting operations running on the system, end-users will inevitably demand more:<\/p>\n

                  \n
                  \n
                    \n
                  • Make it more user-friendly, YO!<\/li>\n<\/ul>\n<\/div>\n<\/div>\n

                    User-friendly means “easy to operate with convenient features,” but the prerequisite is an interface where “desired operations” are immediately clear.<\/p>\n

                    \n
                    \n
                      \n
                    1. Few menus (bare minimum)<\/li>\n
                    2. Large buttons (visual appeal matters)<\/li>\n
                    3. Shallow hierarchy (max 2 levels)<\/li>\n<\/ol>\n<\/div>\n<\/div>\n

                      I believe these three are must-have specs in Indonesia. Beyond that, adding functions for Indonesia\u2019s unique business practices and tax systems requires significant customization.<\/p>\n

                      \n
                      \n
                        \n
                      1. Reflect on-board management of imported goods in accounting.<\/li>\n
                      2. Record provisional payables (accrued expenses) based on receipt.<\/li>\n
                      3. Incorporate taxes and costs from import declarations (PIB) or goods removal permits (SPPB) into costs.<\/li>\n
                      4. Scan barcodes on lot-based material tags for easy result input.<\/li>\n
                      5. Share info online for customs (bonded zones) and internal use.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n

                        These are examples of features Japanese firms in Indonesia would find user-friendly, but they\u2019re still usable without them.
                        \nIt\u2019s clich\u00e9, 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.”
                        \nToo many in Indonesia expect everything for free.<\/p>\n","protected":false},"excerpt":{"rendered":"

                        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.<\/p>\n","protected":false},"author":2,"featured_media":81260,"parent":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[633],"tags":[],"class_list":["post-94305","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-indonesia-production-control-system"],"_links":{"self":[{"href":"https:\/\/bahtera.jp\/en\/wp-json\/wp\/v2\/posts\/94305","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bahtera.jp\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bahtera.jp\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bahtera.jp\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/bahtera.jp\/en\/wp-json\/wp\/v2\/comments?post=94305"}],"version-history":[{"count":0,"href":"https:\/\/bahtera.jp\/en\/wp-json\/wp\/v2\/posts\/94305\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bahtera.jp\/en\/wp-json\/wp\/v2\/media\/81260"}],"wp:attachment":[{"href":"https:\/\/bahtera.jp\/en\/wp-json\/wp\/v2\/media?parent=94305"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bahtera.jp\/en\/wp-json\/wp\/v2\/categories?post=94305"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bahtera.jp\/en\/wp-json\/wp\/v2\/tags?post=94305"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}