Let’s consider the case of a large hospital that noticed its inventory figures were not truly reflective of how many necessary items were available. When preparing for an operation, it’s important to overstock with required items for surgery, and in this instance, staff would constantly find that the number of syringes the computer said were in the cupboards, were there but in very different quantities. This led to manually ordering extra stock instead of relying on auto-replenishing. The problem fully unravelled when it was also discovered the average costing figures were completely wrong. This left the various departments in the hospital with stock budget blowouts.
With an item like syringes which are packed in boxes of 100 units, part of the problem comes about when there’s a discrepancy between whether one item vs one box of said items is counted into or out of stock. If when preparing for surgery a number of items are taken out of stock for use and then some are returned as items without noting the difference between boxes vs individual items, then chaos sets into the inventory system. In this instance, it was taking one staff member a whole day at a time to do returns, and stock was starting to pile up – further affecting the inventory reality.
The hospital in our case study was having exactly these issues. Once they identified the problem it seemed a relatively simple matter to resolve it, but the options before them to bring about real change were complex. They agreed they did not wish to hire consultants or write new code – both of which would be expensive, time-consuming, and require a lot of testing.