Tag: voice picking providers comparison
This column was originally posted in March 2015 and has been updated.
We talk about voice enablement with enterprises throughout the supply chain a lot, and here a lot of stories about their prior experiences with traditional voice applications. Their stories are maddening. Their stories are horrifying. Their stories are the kind that make anyone with P&L responsibility want to scream. Too often, these recounted experiences are stories of large up-front investments and then a bunch of unforeseen expenses post-deployment. The problem is the traditional voice application model, which adds costs in these four common areas:
Voice-dedicated hardware: Traditional voice apps require a separate, proprietary computer (typically worn on the belt or shoulder of the worker), that houses the speech-to-text and text-to-speech processing. However, if the barcode scanning mobile computers you’re deploying are fairly current (introduced to market in 2008 or later)), they already have the audio capabilities and computing horsepower to handle the voice processing, so you don’t need to buy proprietary voice hardware.
Middleware or “System Interfaces”: In most warehouse applications, you’re workers are already interfacing to a host system – your WMS, ERP or other supply chain management system. And, in most of these cases, your workers are using Terminal Emulation on their mobile computers to interact with this host system. There is no need to wedge additional middleware in between your host system and mobile device client in order to enable voice. You’re interest is to recognize productivity gains by adding voice to your existing mobile application, so there is no need to buy middleware to enable voice.
Host System Modifications: Recently, I wrote about the problems that can arise when your voice vendor wants to make changes to your host system. You’ve invested a significant amount of money in your host system, and you don’t need another vendor putting their hands in there (and changing you consulting services fees to do it). Adding voice to the mobile application should simply pass data back to the host system in the same way that barcode scanned or key-entered data is communicated. Your host system shouldn’t even need to know which method of data capture was used for a given data field, so adding voice shouldn’t require changes to your host systems.
Post-Deployment Host Modifications: Once your workers are voice-enabled and you’re realizing the productivity gains of voice-enablement, should you discover a process change that will further optimize your workflow, many traditional voice vendors will require that you contract them to contribute to the changes you want to make to your host system. They want to be included because they’ve already made changes to your host system to make their voice application work, so if you want to make any changes, they’ll need to ensure their application isn’t adversely affected. Deploying voice-enablement shouldn’t require host system modifications, so you shouldn’t have to pay professional services fees to your voice vendor every time you want to make a change to your host system.
If you’ve encountered any of these issues when considering adding voice to your picking or other warehouse workflows, it’s time to look at Speakeasy. It’s 100% mobile device driven (no proprietary voice hardware or middleware required), and does not require any modifications to your host system (which also eliminates the associated post-deployment costs). You get the productivity benefits of full-featured voice-enablement, but without all these additional costs that often make traditional voice applications cost prohibitive. Plus, you can deploy in as little as 30 days, so the productivity gains and cost savings can start adding up quickly.
I was just re-reading Maida Napolitano’s article on Voice Picking from Logistics Management magazine mid-2010 (“Three Voices, Three Solutions”, Maida Napolitano, Logistics Management, July 2010). In it, Ms. Napolitano highlights three different voice picking solutions, from three different providers. All three solutions have different architectures. This provides the foundation for the segmentation of the voice solutions in the article.
Although the article is an excellent overview of three of the possible architectures for voice solutions, there is one small problem. There are actually FOUR different architectures available today, providing (at least), four different voice platforms.
Napolitano’s article covers the following designs:
- Proprietary Solutions – These are speaker-dependent solutions requiring custom voice hardware, and are the oldest voice solutions on the market.
- Open Hardware – These can be speaker-dependent, or -independent, and utilize off-the-shelf mobile device hardware with thick-client applications provided by the voice solution provider.
- Intelligent Networks – These are speaker-dependent, or -independent, and utilize a thin-client “approach”, with “more intelligence placed in the network” (Quotations mine).
Although this description gets very close to enumerating all the differences in voice architectures, it is missing one key design. Also, it tends to separate two solutions that share a fundamental design element, and lumps in the missing element as part of the last one.
Let me explain.