Warehouse mobility is probably the oldest mobility solution area in SAP. In the warehouse they scan barcodes when doing goods receipt at the loading dock, walk the aisles and pick orders, do goods issue at the counter and make periodic or ad hoc inventory counts. In the warehouse they probably call it the barcode scanners, the RF solution or the Intermec terminals, but connected to SAP WM or MM-IM it’s SAP mobility none the less.
Now what counts in the warehouse is performance and reliability: transaction load speed, response times, session persistence, network coverage, scanning accuracy, distance and robustness etc. Not the latest colorful UI or the latest iTech toys. Most implementations around today are based on the old trusty SAP MDE (Mobile Data Entry) transactions and are enabled on a handheld terminal by SAPConsole or (most likely) by SAP ITSMobile (Internet Transaction Server for Mobile). It may have been enhanced in-house or with 3rd party content from companies like Zetes or IGH Infotech. New implementations are still fairly common today even though it’s old tech, but are often augmented with voice picking to avoid the old UI and boost efficiency further.
A synchronization (or data) strategy should be an integral part of any mobility project for B2E. In other words planning and designing for robustness against limited connectivity and low bandwidth.Yet I keep meeting the same wrong expectations from clients and consultants alike: we’ll just use 3G and even 4G, it’s everywhere so lets go for fully on-line communication. And the devices have GB’s of memory so let’s not worry too much about data volume. Almost every project I’ve been involved with has proven this wrong once it meets real life in industry, and especially so for blue collar solutions.
The root cause is of course in the properties of EM transmissions in the UHF range used by cell phones. For a good transmission between a sender and a receiver (mobile device and cell tower) you should have:
- Good antenna properties in the mobile device
- Line of sight to the receiver antenna (or few obstructions)
- No EM interference for the signal
Ideal conditions will give you advertised ping times, little or no package drop and full multiple channel bandwidth. No problems!
So why does this rarely happen in a real world scenario?
1. Good antenna properties in the mobile device?
- For industrial (ruggedized) devices this is an important design parameter, hence often external antenna “stubs”.
- For consumer grade devices it’s almost secondary to design, case in point the iPhone 4 “antenna-gate”. Antennas are internal, packaged tightly with the battery and PCB’s. You’ll degrade the signal strength of an internal antenna just by holding the device, so on to #2:
2. Line of sight to the receiver antenna, or few obstructions?
- Metal reflects, most other materials dampen, so:
- A technician with a 20% signal strength puts his device in a jacket pocket. His body and the wet jacket dampens the signal and he loses signal.
- He’s in a lumber yard with wet wood stacked everywhere, serious dampening.
- He’s in a basement, surrounded by re-bar and concrete and tons of dirt, no signal
- He’s in a loft full of metal ventilation ducting, reflection, interference, poor signal
- He’s in the countryside with hills and woods, poor signal
- It’s raining or snowing, dampening
- Your providers 3G coverage is not universal, you’ll often be dropping to EDGE speeds due to the distance between towers
3. No EM interference for the signal?
- Back to antenna properties: especially consumer devices emit many frequencies from multiple antennas simultaneously. GPRS/3G/4G on 2 frequencies, WiFi on 2 frequencies, Bluetooth and NFC. They interfere internally to a certain degree.
- EM noise from machinery like electric motors, engine ignitions, frequency transformers etc. are very common in industrial environments.
Often the telco providers themselves have problems: faulty gear, bad hand-overs between towers or peak traffic on a cell tower will also influence quality and bandwidth.
So my conclusion is that you can either do the work on your sync/data strategy, or you can get a nasty surprise after go-live. Consider these questions as part of your design:
- What types of wireless protocols will I be using, and in what scenarios: WiFi, WiMAX, EDGE/3G/4G?
- Can my app/device switch between them automatically (ie. jump to WiFi when in range)
- Will I be designing for on-line or off-line? Both? A mix (ie. lookups in large tables on-line)?
- How can I trim my datamodel? (Don’t just sync a whole table if you only need 6 fields)
- How can I limit my dataset? (Limit by relevance for user: by location, customer, plant etc.)
- Will I be sync’ing my full datamodel on WiFi, only a subset on 3G and a minimum subset on EDGE?
- Will I sync event-driven (typically transactional), on a fixed or situational time sequence or manually? A mix?
- Error handling for sync events, especially automatic retries (notorious way to drain a battery)?
- User notifications? (“Warning: 45 min. since your last sync”)
Going through this exercise I’m sure you’ll end up happy, with a robust and fast communication to your backend systems, transmitting only what you need, when you need.
As it happens I’m finishing this post while at a Syclo special academy in the UK. I’m glad to see that the SAP Syclo Agentry Editor – coming from a rich history of blue collar off-line implementations – gives you total configuration control of sync strategy: slow or fast connections, how much gets updated and when, control of retries, push control etc. Something that was sorely missing on the SUP side.
Gartner @ SAP innovation forum
In five years all enterprises will be running as Internet companies
B2E is not just about making apps; there are a lot of issues that need to be addressed when entering this area and one of them is the time spent using the app.
With smartphone B2E apps employees can work anytime and anywhere, but how do employers handle this work time?