GAP for common systems and field operations
As for the gap between the system and the field operation (GAP), the system introduction will not go well without the idea that the operation will cover it to some extent, but the following are the GAPs that tend to occur when introducing a business system in Indonesia.
- Case 1.
On the other hand, the night shift staff cannot issue a delivery order due to insufficient product inventory in the system when the product is shipped immediately after completion.
- Case 2.
When a trading company purchases goods, if the goods have arrived but the invoice has not arrived, the system cannot register the goods for purchase, so the goods that have already arrived are not stocked and cannot be shipped.
- Case 3.
However, if the system assumes that shipping instructions are based on an inventory reserve, shipping instructions cannot be issued due to insufficient inventory.
- Case 4.
When 20 shipment instructions are issued for 100 orders, we would like to identify the 80 unordered instructions as “remaining orders received”.
- Noted: Shipping instructions＝1:1
- Order: Shipping Completed
In the system processing flow of “Order – Allowance – Shipment Instruction – Shipment Completion”, it is operationally inconvenient to be able to split the order and the shipment instruction only 1:1, even if it is the correct move in the system.
- Case 5.
In the case of purchasing materials in a factory, if the invoice arrives in the next month, it is not possible to register the invoice for the materials that are turned in and costed in the current month because the invoice NO is not known in the current month.
- Case 6.
In a series of processing from order registration to shipping and invoice issuance in the system, various corrections are always required before the month-end closing process.
- Case 7.
In some cases, the site cannot follow the flow envisioned in the system, for example, by having the barcode on the item slip be read to process material dispatch and reversal, and then entering the actual results and affixing the item slip each time a rejected or separately managed item occurs.
- Case 8.
If a mistake is found in the input of the results in the physical inventory and you try to correct the production results during the month, you need to cancel the downstream invoice and shipping slips in order if the lot is already flowing to the customer, but then the invoice number and shipping slips number will be newly assigned, which will affect the document management of the customer or customer and you cannot correct it.
Definition of “usable” and “easy to use
The Japanese manufacturing industry in Indonesia lags behind China and Thailand in terms of systematization, and the move to replace manual processing using Excel with business systems is finally becoming the norm. I would like to say no, because systemization is not necessarily a good thing.
My definition of “the system is usable” or “the system is easy to use” is
- The system can be used = the business turns on the system.
- The system is easy to use = it is easy to use and has all the convenient functions.
It’s only when you have “usability” that you have “ease of use”, and it can’t be the other way around.
- I paid for the system, so it’s only natural that I should be able to use it.
However, it takes a lot of energy for both the implementer and the user to reach the level where the business runs on the system.
How do I get the system up and running?
When anyone decides to pay for and implement a system, they usually wonder if the project will be successful. To begin with, “successful project” means
- Complete it in the planned period.
- Get the system working properly.
It boils down to these two points.
Will it be completed in the planned period?
Whether or not it will be completed in time is a matter of system implementation. Cutover of the system (is Go Live more mainstream in Indonesia?) However, if you don’t make it in time, you will have to double-input with the old system for a long time and the load will be high, which means that you won’t be able to do the work you should have done.
Causes of schedule delays
- Estimated man-hours for the task were not enough.
- Unexpected tasks occur due to incomplete task identification, and man-hours are consumed.
In the case of packaged software, it is rare to fail to post tasks because tasks are almost fixed, but in the case of a system that involves development, a mistake in estimating man-hours can occur.
At this stage, however, we have no choice but to estimate the number of man-hours without having heard 100% of the user’s request.
Therefore, when the introduction is actually decided and the initial requirement definition is about to begin, there are many exceptions to be handled unexpectedly and man-hours may increase.
As you know, in the Muslim world the fasting period is shifted every year, but there is a mistake in taking this into account. During the fasting period, your staff must return home early. Also, in Indonesia, there are many unpredictable events such as half-day holidays for factories due to elections and demonstrations.
You’re going to get the system working properly.
If you carefully consider whether the package matches your business or not, you can avoid risks to some extent.
Why the system doesn’t work properly
- A gap between the business and the system was discovered after the operation, and input was delayed.
- The business cannot keep up with the system and input is delayed.
Since the package system is designed to have the maximum commutative function so that it can be used in various companies, even if 80% of the system is FIT, 20% of the system will be GAP. However, if 20% of the 20% is GAP, which is the foundation of the business, it’s a huge loss of investment.
I have seen a case where a company introduced a system that only supported moving average unit price calculation and the first-in, first-out method, but was unable to use the system as it was because the actual business was ordered from Japan to use the gross average method.
Also, even if you intend to manage lots by physical inventory slips, it is a common occurrence in Indonesian factories that the actual input is not done for the correct lot, or the input is stopped by itself because the lot is not found, or the accuracy of inventory control is poor, and lots without physical inventory slips are scattered in the field.
If you design a new business flow with a theoretical first approach and then design the application to match it, the field may not be able to keep up with it after it goes live.
In order to avoid risk.
As a matter of fact, the points and factors that are likely to cause delays in the system implementation schedule can be roughly predicted.
When you create a schedule, break it down from monthly to weekly to daily as a master schedule, and then break the tasks down into smaller pieces on the vertical axis, so you can see the tasks and the time series vertically and horizontally, so it’s easy to get a picture.
There are two factors that can cause schedule delays, one on the implementation side and the other on the customer’s side.
- Lack of resources on the deployment side
- Mistake in estimating man hours
- failure to account for tasks
- Failure to take into account non-working days
- There’s a delay in confirming the master.
- Result input is delayed.
- I can’t get all the requests.
The blue part of this overall schedule is the requirements definition part, where the parts that fit between the user request and the standard specification of the system and the parts that have Gap are identified and the business flow and application flow are defined. Also, the red area is the area that is prone to delays and pushes out the next phase of the task.
When introducing a system, the customer’s situation can be divided into three patterns: new start-up, manual processing using Excel, and existing systems. Generally speaking, new plants are the easiest to introduce, and the most difficult is a plant with a single system scattered in each department. When a new system is brought into a situation where an existing system is running, various frictions will occur during the project process.
If the factory has an existing ERP system, it is a total replacement, so all departments are the same and there is no unfairness, so the input will be done reluctantly, but it is the most difficult case when the P/O issuing system for purchase, local cheap accounting package, or a single system specialized in a specific business is divided and it is operated completely within the department without communication between departments.
I think we can reduce the risk of delays by keeping this in mind before proceeding with the project and sharing the current situation at weekly meetings.
How to implement an easy-to-use system?
If we can get over a number of hardships up to this point and work on the system, new demands are sure to come out from the end user side.
- Make it easier to use.
Easy to use means “easy to use and convenient functions”, but first of all, it is a basic premise that the screen structure is easy to see the “operation you want to do”.
- Fewer menus (minimum required)
- Large buttons (visual appeal is important)
- The hierarchy is shallow (up to two levels)
I think these three specifications are essential in Indonesia, but it takes a lot of customization to have them and also to have features that correspond to Indonesia’s unique business practices and taxation system.
- We want to reflect the onboard management of imported goods in our accounting.
- I would like to record provisional accounts payable (for accrued expenses) on a receiving basis.
- Taxes and expenses on import declarations (PIBs) and shipments of goods (SPPBs) are entered into the cost of goods.
- I want to scan a lot-by-lot item sheet with a barcode and easily enter the results.
- We want to share information on the web for customs (bonded area) and internal use.
These are examples of features that are easy to use for Japanese end users in Indonesia, but in other words, they can be used without them.
It’s a bit of a cliché, but it’s necessary to draw a line between how far to implement useful functions into the system and where to handle them manually. In order to draw this line, we need to make sure that end users understand that customization takes a lot of man-hours.
There are too many people in Indonesia who are willing to let you do anything for free.