|
[EDI-L Mailing List Archive Home]
[Message List]
[Reply To This Message]
Re: <Tech> Back to EDI-to-FAX and OCR
At 10:00 AM 11/12/03, Allen Hoffman wrote:
>I had a strange call today, someone wants to actually start using OCR to
>take tose orders that are not EDI. Most of them are mail but some are
>FAX. I gues I was shocked when I heard the question since I couldn't come
>up with the reasons why not to do it. I know there are plenty of
>opinionated people here who will tell me why not. What are the
>biggest obsacles to OCR even if the quality of the document is good?
>
>Allen Hoffman
Hey, Allen, sounds like an "SME enablement" situation? Lots of small and
mid-sized repeat customers with limited IT capability, requiring costly
manual order processing. Your client should think about enabling them to do
some kind of semi-manual e-commerce.
I think you will find OCR to be very problematical. It's slow, different
typefaces drive it nuts (not to mention handwriting giving it a coronary),
and it needs careful proofreading so your client doesn't ship 1,000
flounders instead of 1.000 fenders. And if you aren't scanning a standard
form, the output needs all of the manual processing of an unformatted email
message, since you don't know what fields any of the numbers belong in. A
better choice would be two different keyboard operators whose work is
compared before it goes to the backend -- crude, but time-honored crude
However, instead of rushing to a technology, maybe the first step should be
to examine the business problem, which appears to be how improve your
client's profit by automating the manual, non-EDI side of their order
management operation. That includes getting inbound non-EDI purchase orders
into the backend at minimum cost, but also could include shedding no-profit
customers or setting minimum order size. It's a no-win situation to allow
the client to dictate the technology to you, then be happy with you, or
not, based on whether their unstated business goals were met. Been there,
done that, on this exact same problem.
As always, you've got to get some benchmark data first, both for planning
and to later show your contribution to their profit. Then, approach the
solution as one of bumping each type of your client's customers up the
automation ladder, which is to say, down the cost/line ladder. That ladder,
in decreasing order of processing cost per order line, is something like:
1. phone-in
2. fax or snail mail
3. email (in body, unformatted)
4. email (attachment, unformatted)
5. email (in body, seller's format)
6. email (attachment, seller's format)
7. EDI
8. Web form
If they have dedicated personnel for each type, you can easily estimate the
cost per line for each level of automation.
Virtually every SME has, or would get, a dial-up Internet connection, a Web
browser, and POP3 email service from his ISP. Some don't know how to use it
well, so you may have to go into a tutoring/support/help-page-authoring
mode for a while. Most are eager for targeted help in improving their
e-commerce capability, so be ready for a flood of help requests.
You can score one early success by examining recently faxed-in and
mailed-in POs for any which were printed from a computer, then stuffed into
a snail mail envelope or trotted over to the fax machine. Contact those
customers, asking that they attach the file to an email and send it in. My
experience is that about 90% will slap their foreheads and say, "Why didn't
I think of that?!" Expect the less Internet-savvy ones to ask how to do
email attachments. Of course, someone in your client's order management
function can easily and accurately copy-and-paste between a
machine-readable document from a customer and their backend's order input
screen. Not elegant, but better than keying from fax or paper, and
certainly better than OCR.
More client-pleasing low-hanging fruit comes from a survey of your client's
customers for the kind of back end they use. Just a handful of Quick
Books-like backends dominate the SME market. You can ask the appropriate
users to print their PO's to file, then email that file. When those files
arrive, the adaptors which you have written for the popular ones will turn
those attachments into importable documents for your backend. Your client's
backend will generate documents for the customer (order confirmation, ASN,
invoice) which can be sent to the customer by reversing the flow.
Depending on order size and mission criticality, you might want to reply
with an emailed "tech ack" and/or order confirmation. Later, you can email
an advanced ship notice and invoice. Digital signatures and/or encryption
might be necessary for authentication, privacy, non-repudiation and message
integrity. PGP is a good resource for email security. (http://www.pgp.com)
Other issues include once and only once delivery, and time to perform, but
that's why you are making the big bucks.
I'll bet that an analysis of these orders will show that some are
unprofitable due to small orders size coupled with high order processing
cost (especially key-in errors). You may want to recommend a minimum order
size.
Anyway, in my humble opinion, walk away from OCR and don't look back.
--Jeff Mick
|
 |
Subscribe in XML format
| RSS 2.0 |
|
| Atom 0.3 |
|
|
Cart
