I might be able to share some insights on this one : I worked on the uses-cases, tech design and first deployments of RFID at decathlon, back in… 2008-2009 I guess.
We faced major issues back then, but the most important one was the cost of tagging every single product ; both cost of the tag and cost of attaching it (comparatively, antennas and IT where marginal costs at scale). Back in the end of the 2000s, tags were more expensive than today. Decathlon had one major advantage though : it manufactures most of the product. That means we could add the tag in the label at the factory. But still, to make it economically viable, we had to pile-up multiple uses cases. Every single one was important in the balance to justify buying so many tags and tagging so many products. So we went very creative, designing new ways to reduce costs in the whole manufacturing/logistics/storage/retail/after-life chain. Because no single advantage was enough by itself. We also had to imagine these new enablers and uses-cases with the state of this new technology (especially at the time) : airwaves are difficult to predict, and not 100% perfect in terms of detection, collision, …
We invented new ways to do things that were mostly already done, but cheaper (in man-hours for repetitive tasks mostly), better (quality and fiability of results), and/or more frequently. Thing logistics optimization (wrong door / parcel detected earlier), whole lifecycle and whereabouts tracking (for defective product callbacks for example), daily inventory (we had the idea to use cleaning carts with antenas to have a daily store inventory), NOSBOS (« not on shelves but on stock », detecting prodcts that where in inventory but not available at this specific moment in the department/shelf), warranty tracking, …
At the end of the story, self-checkout is mostly a by-product, not a target for the deployment. It’s something that was made possible but not a first target.
Not OP but I use multiple sources when doing consulting on mobile strategy. Not sure if every source allows to copy/paste data here so I'll just name the sources here :
- comScore MMX Multi-Platform, January 2017
- Deloitte Global mobile Consumer Survey, May 2016
- eMarketer, App Marketing 2015: Fighting for Downloads and Attention in a Crowded Market, July 2015
well, "sur-" in french means a lot of things, alone or as a prefix : on, over, more, about, upon, onto, against, ...
So I'm pretty sure there is a pun intended here.
About "surbooker", funny thing is that "booker" is literally the english verb converted to french verb (hence the -er suffix). Even if it is well used in modern french, it still is an anglicism.
Inovia | Front Dev JS, Front React Dev, Front React-Native Dev, Backend JS/Node Dev, Backend PHP Dev, Operations Engineer | Paris, France | ONSITE http://inovia.fr/
Our mission is to make tailor-made apps for startups. We are a growing company with offices in the heart of San Francisco and Paris.
We love to work on ambitious projects we believe in and driven by people we like. We want to see them succeed. Our values : technical excellence, solidarity, durability.
We are currently looking for the following profiles :
- Front JS Dev: Progressive Web Apps and other front-end technologies (WebGL, Asm.js, ...)
- Front React-Web Dev: React web, redux, ...
- Front React-Native Dev: React Native for both iOS and Androind
- Backend PHP Dev: ZF2 of SF
- Operations Engineer: Ansible, Docker, ...
We are looking for experienced and juniors, and we focus on thinking skills more than framework knowledge.
Drop us a line to rh at {the domain name from website}. Don't forget to mention HN.
We currently use a mix of a home-made redmine extension for scheduling, redmine tickets for time logging and google sheet with custom addon for compiling everything per project / period for easier birds eye and invoicing.
We do not plan on maintaining redmine extension, we have different tickets trackers for specific projets, and it is very limited / simple (when not clunky at times).
It worked well for last years and volume, but it tends to be too limited, and not suitable for bigger needs (requires too much hand work each week to cleanup data and handle exceptions).
Main features we look for are :
* simple staff planning/schedule (resource requirement, capacity, allocation)
* time logging with aggregation per activity per project and basic analytics. Custom rules like increments (1/2 hour, hour, ...), minimum logging per day, ...
* full API access to plug to ticket trackers (time logging), invoicing, ...
We looked at some ERP but they usually were to clunky or complicated, and dedicated tools always seems too simple (most don't have any staff schedule management for example).
We faced major issues back then, but the most important one was the cost of tagging every single product ; both cost of the tag and cost of attaching it (comparatively, antennas and IT where marginal costs at scale). Back in the end of the 2000s, tags were more expensive than today. Decathlon had one major advantage though : it manufactures most of the product. That means we could add the tag in the label at the factory. But still, to make it economically viable, we had to pile-up multiple uses cases. Every single one was important in the balance to justify buying so many tags and tagging so many products. So we went very creative, designing new ways to reduce costs in the whole manufacturing/logistics/storage/retail/after-life chain. Because no single advantage was enough by itself. We also had to imagine these new enablers and uses-cases with the state of this new technology (especially at the time) : airwaves are difficult to predict, and not 100% perfect in terms of detection, collision, …
We invented new ways to do things that were mostly already done, but cheaper (in man-hours for repetitive tasks mostly), better (quality and fiability of results), and/or more frequently. Thing logistics optimization (wrong door / parcel detected earlier), whole lifecycle and whereabouts tracking (for defective product callbacks for example), daily inventory (we had the idea to use cleaning carts with antenas to have a daily store inventory), NOSBOS (« not on shelves but on stock », detecting prodcts that where in inventory but not available at this specific moment in the department/shelf), warranty tracking, …
At the end of the story, self-checkout is mostly a by-product, not a target for the deployment. It’s something that was made possible but not a first target.