|
[EDI-L Mailing List Archive Home]
[Message List]
[Reply To This Message]
RE: <Tech> Back to EDI-to-FAX and OCR
A project dealing with incoming order faxes will only be successful when
the customers do not have to change the way they are ordering. Therefore
the idea with predefined forms will only work with a limited amount of
customers.
But you can easily identify values like the item description, order qty,
order #, ship to address, sold to address on each order fax which is
send to you.
The challenge is now to identify those data on every printed order fax
and translate them into an EDI-like format.
To do that a simple OCR result is not efficient enough. You need
methodologies to cross check and enhance the data.
For instance you might want to add your customer number - but on the
order fax you only find the customer address.
A solution also needs to deal with orders that have more that one page
or multiple lines per item in the item list. Therefore the ideal
combination is a B2Bi-Tool with a paper processing capability.
Our customers like Goodyear Dunlop Tires Europe and Corporate Express
have successfully implemented such a solution(SEEBURGER's Paper2ERP
solution).
Scott Lewin
SEEBURGER Inc.
Scott Lewin
Executive Vice President
5 Concourse Parkway, Suite 960
Atlanta, GA 30328
Phone: 770 604-3888
Fax: 770 604-3885
Email:
Web: www.seeburger.com
-----Original Message-----
From: Jeff Mick [mailto:
Sent: Wednesday, November 12, 2003 4:42 PM
To:
Subject: Re: [EDI-L] <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
Yahoo! Groups Sponsor
ADVERTISEMENT
<http://rd.yahoo.com/SIG=12cld6v0b/M=243273.4156324.5364586.1261774/D=eg
roupweb/S=1705005582:HM/EXP=1068759792/A=1750744/R=0/*http://servedby.ad
vertising.com/click/site=552006/bnum=1068673392053876> Click to learn
more...
<http://us.adserver.yahoo.com/l?M=243273.4156324.5364586.1261774/D=egrou
pmail/S=:HM/A=1750744/rand=627225725>
To unsubscribe from this group, send an email to:
Please use the following Message Identifiers as your subject prefix:
<SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC>
Access the list online at: http://groups.yahoo.com/group/EDI-L
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .
[Non-text portions of this message have been removed]
|
 |
Subscribe in XML format
| RSS 2.0 |
|
| Atom 0.3 |
|
|
Cart
