Inventory management is one of these things that many people think “it must be software”, but the physical inventory is physically something that exists outside of software.
Products flow across the different warehouses, materials go to production, there is receiving, picking, transfers, shipping and returns. How do all this things get integrated back to these databases?
An inventory-management architecture would require something else than just an inventory database.
That’s where the many tools to track, read or identify products and items, plus RFID, barcode, BLE, IoT, WMS, automation… enter the fray.
- Let’s Get It Identified
Your application has to be able to identify one inventory item, SKU, pallet, container or asset from another.
Barcode is old but works reliably and easily enough to deploy.
RFID can avoid using a barcode scanner by embedding tags on the objects.
But how does it works and what is your object?
Well your mileage will vary depending on the actual product type, how much granularity you need and the overall workflow.
- Not Just Identifying, But Capturing Events
You identify some objects and items, what’s next?
What I personally want to capture is:
• When
• Where
• What
Events in any inventory-management process are usually:
Event types range from: Receiving, Put-away, Picking, Movement, Transfer, Shipping, return, and consumption.
Sensors or RFID or BLE or even IoT devices, can be integrated at some point to supplement your inventory information, but again, depends on your use-case.
- Integration Time: Connecting The Data Layer
Now we have all these new data points captured with events, but what about integrating this new information to the many layers that need it?
Your enterprise systems may range from an inventory-management software, WMS, ERP, POS, supply-chain, manufacturing or anything that requires the flow of this information from a source.
If there’s no integration in place, everyone will likely end up doing their own thing and synchronizing in an ad hoc fashion, and it can quickly become out-of-synch between systems.
- But It Always Come Back To Events
As you think about what to do with your data model and software, maybe you can start with event-driven architecture.
Instead of:
SKU-123 = 50 units…
You would have:
Received → Stored → Picked → Transferred → Shipped
Once again I think it’s always good to model what actually happens on the ground.
It can help with analysis and visibility of what went on in an inventory lifecycle.
That’s when you can then see and analyze what’s wrong and who is at the fault.
Inventory systems and databases, especially event-driven ones, provide a good baseline for such analysis.
- But What About Automation?
Once everything works fine, you can think of adding automation to enhance inventory processes.
But again, only if everything has been already validated and you just want to speed things up.
Robotics can also be integrated to the warehouse environment, but only if the overall process workflow fits with your use-case.
But it’s also easy to think “I automate everything and it becomes perfect”. No. Don’t automate if your identification processes aren’t foolproof.
So instead of:
Identify → Automate
Do:
Identify → Capture → Integrate →Validate→Automate
- But What About Overall Data Quality?
We’ll have a ton of events, but do we have bad or missing data?
Duplicate events, missing events or erroneous entries can populate databases and wreak havoc on inventory records.
You need to factor data validation and validation exceptions in your overall architectural design.
A warehouse system should not take for granted all the data that flows in.
- What About Real-Time And Synchronization?
Depending on your overall inventory workflow, some events may require real-time or near-real time processing, while others can tolerate eventual consistency with periodic synchronization.
The overall technical debt and architecture should reflect your real-world inventory needs.
A bigger environment with more complex workflows will require event-driven inventory processes, while smaller environments will likely be more limited in their synchronization and communication methods.
But the question shouldn’t be:
“Can this system provide real-time?”
It should be:
“Can these decisions wait for synchronization?”.
It’s a more relevant question to ask yourself.
8.Where Smart Platforms Come Into Play
A lot of modern inventory-management systems are starting to integrate a wider variety of technologies to provide enhanced and increased inventory-management and visibility.
Inventory Master is an example of a system that takes inventory management softwares, WMS, RFID, BLE, IoT, automation and robotics — and combines them into an inventory-visibility and inventory-management stack. [See Inventory master website here]
Technologies don’t matter as much as the inventory identification and synchronization across all these layers to have a coherent and consistent physical and digital inventory representation.
Conclusion
Inventory management can be more than “just scanning barcodes”.
It requires an inventory application architecture that reflects the complexity of physical inventory management processes.
Identification and RFID (or other form of recognition), sensors to capture events, integration to exchange this information across different systems, and finally, using this data for analysis or automation.
Once all these layers come together, inventory management stop being a set of periodic processes to make records and entries.
This is all the more true as more and more warehouses are starting the move towards using automation, IoT, RFID to track and optimize their processes.
That’s also why building connected systems, for inventory-management or other purposes, is so compelling to many programmers wanting to solve real problems in a wider context.
Top comments (0)