It’s a Match! What Tinder has to do with Asset Management
Swipe right – it’s a match! Tinder is one of the largest dating apps in the world. In the first quarter of 2022, user numbers amounted to over 10 million paying users (statista, May 2022) – and the trend is rising.
Okay, but what exactly does Tinder have to do with asset management and especially with Favendo? Tinder is the perfect example to explain, close to everyday life, what has to happen in the background of a tracking solution to find exactly the asset you are looking for. But let’s start at the beginning:
Asset Management in a production environment
Let’s assume that in a production environment, containers with manufactured workpieces should be located within the production line as well as in the warehouse in order to reduce search times and create more transparent production processes. This requires an RTLS. Depending on the size of the premises, the environmental conditions and also the desired accuracy, different technologies and solutions come into play for the RTLS.
Together with the customer, Favendo evaluates in each individual case which solution is best suited to the specific scenario. Once a solution has been chosen, the next step is to plan and install the static hardware on site. In the end, the moving assets also need to be provided with hardware, the tags. And here we are again with Tinder and the matching process. Because obviously, the moving assets, in this case the multiple containers for workpieces, need to be “married” to the tags attached to them. Namely, in such a way that they are uniquely identifiable.
Example: The tag with the “ID 456” is attached to the “Container 123”. This physical connection must of course also be reflected on the software side. Thus, employees searching for “container 123” will receive the location of the tag with the “ID 456” from the RTLS and will be able to find the asset they are looking for.
This matching process between asset and tag is a key element for asset tracking solutions. If there is any confusion here, the unique localization of the assets is no longer given. Because then, let’s take the example from above, it could happen that “container 123” is linked to tag “ID 789” and this means that the wrong container will be located and found. In the end, this leads not only to annoyance and time delays, but possibly also to more protracted problems in the process chain.
In the case of containers that are used over and over again and carry the same items, and the tags can remain on the asset even when it is cleaned, the process of matching is quite simple and usually only needs to be done once before the rollout of the RTLS (not excluding minor adjustments while the system is running). If the connections between asset and tag tend to change frequently, the matching must of course always be adjusted.
So when matching asset and tag, very similar to Tinder, you have to be careful! 😉