Blogs

Frankie-the-frustrated worker dealing with lack of direct Line of Business integration and Manual Data Entry

By Kevin Neal posted 08-31-2012 14:45

  

For this particular blog post I would like to use a light-hearted approach to a major problem.  The problem is lost productivity and user frustration around populating data into Line of Business applications via Manual Data Entry versus Automation. 

 
To illustrate my point let's take one of the most popular Software as a Service (SaaS) applications ever, Salesforce.com.  And while the application is absolutely simple to use and easy to manage, what lacks is the ability to take information from paper and/or an image and put it directly into Salesforce.com database fields.
 
1.  Let’s take a moment to go through the steps to import data into Salesforce.com and follow the steps Frankie-the-frustrated worker must take to get this task done. 
 
 
2.  Commentary of Frankie-the-frustrated worker:  
 
"Frustrating!  Step 1 of 7????"
 
 
3.  Commentary of Frankie-the-frustrated worker:  
 
"MORE FRUSTRATING!!!  WASTING TIME!!!"
 
 
4.  Commentary of Frankie-the-frustrated worker:  
 
"MORE THAN EVER FRUSTRATED!!!!!!!!!  WASTING TIME, MONEY, AND ENERGY!!!!!!!!!!!" 
 
 
5.  Commentary of Frankie-the-frustrated worker:  
 
 "FORGET IT!!!!!!!!!!!! 
 THIS WILL NEVER END!!!!!!!!!!!!!!!!! 
 WHY IS IT LIKE THIS????? 
 ISN’T THERE AN EASIER WAY????????????????
 
 
 

 

Education and modern technology reduce Frankie's frustration

Are we still living in the stone age when it comes to data entry into computer systems?  Isn’t there a more efficient method to automatically populate data in your software application instead of costly manual data entry?  It’s 2012 after all, not 1912.  Why do we accept such primitive methods of data entry?
 
Answer:  Because we need to educate the market on the capabilities of capture technologies.  We also need to strive to make integration and usage as easy as possible.  If you build it, they will come. 
 
 
Eliminating Frankie's frustration with Ubiquitous Information Capture
 
Realizing the dream of Ubiquitous Information Capture directly into applications is much easier than you might think but we must educate the market on current capabilities.  The idea is simple, yet highly effective.  Embed the ability to take photos with a smart phone and/or capture paper documents from a scanning device directly into your software application.  Note that all I've done in the screen prints below is add a small icon of a camera and scanner directly into my CloudConnectMashup software application.
 
 
Now, I can offer my users a truly great user experience because contributing information is nearly effortless and removes pain associated with manual data entry.  This translates directly into reduced operational costs, improved efficiencies and an overall better work environment.
 
 
Think about all the lost opportunities to drastically reduce labor costs, most likely in the billions if not trillions of dollars, associated with manual data entry in just the use cases below:
 
1.  Transportation applications with Bills of Lading, Proof of Deliveries, Trip Sheet or Scale Tickets
 
2.  Field Service applications with Proof of Work delivered, Vehicle Identification Number, Work Orders or Assessment documentation
 
3.  Contracts Management applications with Amendments, Terms and Conditions or License Agreements
 
4.  Invoice Management applications with Invoices, corresponding Packing Lists or Proof of Performance
 
5.  Sales/Contact Relationship Management applications with Business Cards, Agreements or Correspondences
 
Do you know a Frankie in your organization?  Do you have a story, good or bad, to tell?  I'd love to hear your feedback.
 
Thanks,
Kevin


#Capture #thin-client #lob #line-of-business #OCR #Scanning #ubiquitous #integration #webscan #ScanningandCapture #browser #datacapture
3 comments
89 views

Permalink

Comments

09-11-2012 14:43

Dave, you are absolutely correct. The only thing worse for Frankie-the-frustrated to not upload data in the first place is to upload incorrect data. Frankie-the-frustrated would soon be Frankie-the-fired. To include this all-important step is quite easy actually but you have to carefully consider the User Interface real estate/screen size available, and particularly on mobile devices. There are ways to validate and verify data within a browser so it certainly can be done. It's just that organizations have to have the fortitude and governance to enforce workers to accurately verify data and this might take a bit extra time, but is critical important. This, in my opinion, is the real challenge.
http://www.aiim.org/community/blogs/expert/Demystifying-Forms-Processing-and-Data-Capture
"One of the most important objectives of any data capture system should be the quality of the information being captured versus just the pure speed of the system."
Sample of a Verification and Validation User Interface:
http://www.kevinneal.com/blog/wp-content/uploads/2012/01/verification.png
Thanks a bunch for your comments!

09-11-2012 13:46

If I may: what might help Frankie is something like Captricity's Paper-to-Lead Salesforce integration, which allows scan / mobile capture to a hosted service, then a visual browse/edit/re-process interface, and then a push-button import to Lead objects.
Captricity is available at captricity.com
Our Salesforce.com integration will drop before Dreamforce this year! Email us at info@captricity for an early look.

09-11-2012 09:51

..but it fails on delivery: the approach Kevin outlines assumes that the data that's captured from a scanner or digital camera will be perfectly-read. This is rarely the case and so our poor Frankie-the-frustrated ends up bulk-loading inaccurate data. At best, he earns the reputation of Frankie-the-FUDder, at worst, he causes endless pain to the business when it relies on his effort.
Kevin: you're missing the all-important step of data correction. Can you explain how that fits into this model without adding extra steps (and ending up with the frustration of multiple-step imports) or taking us away from the any-browser requirement?