Case
Libra Data Shelf
- Service type:
- Prototyping
- Product type:
- IoT system
- Demo environment (admin:admin):
- oos.sandbox.daiquiri.team
Even small companies have to strive to solve significant problems
Food waste is one of the environment's sharpest problems. According to the rates, the sixth part of all food has never been bought, and for the USA that part is 40%. Food products spoil on the farms, in warehouses, and in shops. Our client saw the opportunity to solve this problem for a retail market on the selling stage in shops. The goods in a shop might be spoiled if temperature conditions are violated. Also, they might be spoiled in the warehouse if they weren't laid out on the counter in time. Our client, the company that makes smart scales, found a way to solve this problem. Our client has the following ideas:
Our main benefit is the ability to help the client to identify the actual product's goals and solve all technical tasks to achieve them. Our client prepared a detailed specification of requirements, which was an excellent beginning to plan a product's development with high quality and eliminate all threats. As a starting point for product development, we marked the moment when we have described and reached a complete understanding with the client about the product's goals. To achieve this point, we needed to dive into our client's domain and study the essence of the problem. That is why we found out what could make the product profitable before starting. According to such thoughts, the final product's goals were formulated as follows:
Some details about our client's market
The final product's goals
The product must perform its primary task: optimize the merchandiser's work in the shop. The merchandisers' work results must be rated by metrics inside the product.
The managers of sales points or retail chains can see the sales data and the number of products on the shelf at the current moment and in retrospect.
The product has to be ready for demonstration to our client's strategic partner, a manufacturing company interested in optimizing its expenses.
Formalizing goals helped us find cause-and-effect relationships between our client's interests and the description of requirements. For example, we didn't fully understand the analytical module in the requirements. In the goal clarification process, we understood how analytics could help define problems at the shop or trading network level. Having this information, we proceeded to the technical planning stage and started to work with specific product tasks.
User flow and the technical nuances of the product
How can we make sure that the shelf's data is correct? What should be the system's behavior if the shelf suddenly reports a weight of several tonnes or a temperature significantly higher than usual or sends data with tomorrow's timestamp?
Anything can happen in real life, and we can't always trust the data we receive. So we have to think through scenarios for handling implausible and invalid data.
What do we do if a shop worker or customer puts their hand on the shelf? How do we • handle such situations?
For the system, it may look like many goods were first put on the shelf, then almost immediately sold. It is only one example of an extreme case that the system must handle correctly. There are plenty of them in reality.
How to check that a worker set up the shelf incorrectly?
Such issues should be resolved in advance so there will be no surprises during the test at the shop.
What is the optimal structure of merchandisers' notification so they correctly understand what they need to do?
We need to consider that they might not fully know the product. That's why an alert must be a clear call to specific action and clearly define how to find this shelf.
When we found answers to these questions, we removed most of the uncertainties in the future product. It allowed us to move to the budget estimating and technical risk analysis stages.
The first significant technical issue was the hardware of smart shelves. We found out what kind of shelves they are; determined how we can identify the shelf in the system and how they can deliver information. The shelves sent information via HTTPS in CSV format, and we could identify them by serial number. We designed an easy and secure process for installing the new shelf into the system. We implemented a simple authentication system for all shelves, which protected the system from unauthorized access.
The next step was to develop the requirements for the system's interfaces. We defined a set of access levels and fixed permission for each role. For instance, merchandisers don't need access to the web application. We just gave them access to the messenger bot. A store manager can only access data from his store, a retailer network manager has access to the data from all stores, and a system administrator has full access to all the data.
We then defined formulas for calculating each metric. It was not obvious enough in some places. If "false alarms" come to the merchandiser too often, he will stop taking the notifications seriously. The number of items that have been removed from the shelf should be calculated by the system as accurately as possible; otherwise, no one can rely on it. The same applies to the percentage of time the shelf has been in a temperature violation state.
When we got all answers to our questions, we presented our development plan, time, and budget estimation to our client. The client accepted the plan, and we moved to the development stage. After finishing the development, we successfully demonstrated the product in a production environment to our client; further, they made a demonstration to their client.
It was crucial that we identified the successful presentation of the product as one of the main goals. By the day of the presentation, the hardware team did not have time to install the real shelf. But we had foreseen this in advance and developed a fake test shelf. It is a product module that simulates the work of a real shelf. Thanks to this module, the product interfaces at the demonstration were informative, and the client's partner understood how the product worked.
The most important thing is that the product created optimal conditions for testing our client's hypothesis. We got a high mark for the work we did. The client had no problems working with the product for a year after completing the work. To summarize, we made sure that we made a viable product to test the hypothesis. After completion, we kept in touch with the client and learned that he had successfully tested the product in a large supermarket in Kyiv, and the product metrics looked promising. And we would be happy to develop the product in the future.
