Inventory Audit Process using the Problem Solving Framework

This write up aims to serve as a guide to the problem solving framework applied into the inventory audit process. The main focus will be on the part of the process comparing physical and ledger count.

 

What is the Problem?

As part of the process, we must first understand what the problem is. In this case, the problem is that there is a discrepancy between our physical count and our ledger count. There is also discrepancy between physical count and accounting count but that is not the focus of this write up.

 

What is the Expected Outcome?

Now that we know what the problem is, we would need to be clear on the expectation. In this case, the expectation is straightforward – make sure there is no discrepancy between the counts.

 

However, just knowing that is not sufficient. We must also have a metric to measure whether we have achieved the objective. In this case, it would be that the delta column in our table is all 0. This is also a realistic expectation as given that if all our records are correct, there should be no difference in the inventory count. Delta column is derived by taking the difference between physical count and ledger count, the formula is as follows:

 

Delta = qty_physical – qty_ledger

qty_physical:

This column is obtained from staging. Data in the model is obtained when we request our warehouse to perform a count for us. 

 

qty_ledger:

This column is obtained from our CRM records. The necessary logic has already been built to count the quantity of each SKU in each warehouse. 

 

Possible Reasons for inventory movement:

Below are some of the more common reasons for inventory movement. Do note that this is not meant to be an exhaustive list.

1. Shipping to customers who have made an order with us
2. Return from customers (either cancel/warranty)
3. Internal transfer from one warehouse to another
4. Shipping inventory to partner warehouse

 

Improving reality using issue tree

Now that we have a good understanding of the problem, we can proceed to solve the problem. As the process of understanding the problem may take a while, it is always good to do a short recap of the problem and objective before proceeding. In our case, the problem would be that delta should be 0 but is not 0 and the objective to make delta 0.

 

Underlying concepts

Before we move to make necessary changes to the records, we must first look at the issue tree and understand the branches. There are some high level assumptions made in the issue tree:

1. Physical Count is correct
2. Logic used to obtain inventory ledger from CRM records is correct
3. Fulfilment models can be used as the source of truth to verify problems identified

 

These assumptions are made so that we can approach the most likely reason for the error – there is some error in our records in CRM.

 

The branch is split into 2 main sub-branches, one for delta > 0 and another for delta < 0. 

 

Delta > 0

With assumption 1 in place, we can then conclude that if delta > 0, it is because the physical count is larger than ledger count. The different sub-branches then go on to evaluate each step along the recording process to see where it could have went wrong, such as missing records in CRM.

 

Delta < 0

Similarly, this would mean that ledger count is larger than physical count. The tree then branches out into the possible causes such as duplicate records in CRM.

 

Divide and Conquer

Now that we understand why the issue tree is structured the way it is, we can move on to try to identify the problem. We can now check the model for each branch to see if there are any records which fall under that branch. If any branches do not yet have a model, be sure to create one to check for it.

 

After checking all the branches and still no error identified, we will need to exercise our critical thinking to think of possible ways that the records could go wrong. For each hypothesis, be sure to add it as a branch and create the relevant model to test the hypothesis. Repeat this process until the tree is MECE.

 

What to do if problem still persists

If even after the tree is MECE, errors still occur, it will mean that one of the assumptions we have made so far is wrong. This could mean that the warehouse has counted wrongly, or that fulfilment information from our partners is not correct. 

 

In the example below, we can see that Tiki actually shifted our stocks without informing us because there were buyers in Hanoi but no stock left. This caused our fulfilment records to not be accurate.

 

Screenshot of response from Tiki