The latest EDI money saver? Paper invoices
Use humans, save money
So I was at a Kofax customer and partner meeting last week, where the standard view of the electronic digital world taking over the analogue paper document world was stood on its head.
The way for businesses to save buckets of cash is to abandon EDI (electronic document interchange) invoices and revert to human readable documents.
It has been thought that totally electronic invoices could be dealt with quicker and enable suppliers' accounts payable (AP) people to get discounts for fast payment. Paper invoices were necessarily dealt with more slowly and so the suppliers paid more for the goods or services. Analyst Harvey Spencer suggests that, with very clever document capture software, human readable invoices - paper or PDF with extractable data or similar formats - can be processed as fast as purely electronic invoices and so gain the same discount advantages.
He cites one document capture product customer who spent $250,000 on a capture system, saved $150,000 a year on reduced AP labour costs and more than six times that - $1,000,000 a year - through more invoice discounts. In other words: if we pay quickly, can we have a discount on the invoice?
The problem with EDI, Spencer says, is that the standards just keep on changing leaving IT departments perpetually recoding to recover lost ground. He just cannot see a single, all-embracing EDI standard emerging. Last year some 80bn paper invoices were issued, in a lamentable indictment of the colossal failure of EDI to become a standard for document interchange.
If EDI is a failure then deal with paper and part-digital invoices and other documents better. That's the Kofax proposition in a nutshell.
Kofax is the single brand company resulting from the Kofax Dicom acquisition in the somewhat staid world of paper business document scanning and storing. The software has got better such that intelligent document capture can cope better with paper, fax, PDF format documents and more.
Kofax recently brought OptiInvoice, a two-man Swedish company founded by ex-ReadSoft employees, for €1.57m, and has launched its e-Transactions product, based on that technology. It is used to process semi-electronic invoices, in print or other formats, and add their processing to that of captured paper invoices, meaning one automated invoice processing system for AP departments.
Kofax is also entering the ad hoc or front office document capture market with Kofax Express so that, for example, loan applications can be captured there and then, and authorised very much more quickly than via a paper transmission to a central office, which takes days.
Customers using these Kofax products look to be able to save direct labour costs, get more discounts off their invoices, and provide better customer service. That seems to be a pretty recession-proof business. Kofax' new CEO, Reynolds Bish, co-founded and ran Captiva, another document capture company, which was bought in October, 2005, by EMC where Bish ran it until resigning in June 2006. He was then hired to run Kofax in November 2007.
Bish also served on the board of external storage supplier Iomega from 2006 through to the closing of its sale to EMC in June 2008. He got a Director of the Year award from the Corporate Directors' Forum, upon receiving which he said: "I have a passion for helping companies to improve their performance while keeping a clear focus on shareholder value. I was fortunate to be able contribute in this manner on Iomega’s board.”
Should Kofax be concerned about that being the end-game for maximising shareholder value? This guy might have a thing about selling companies to EMC.
The business document capture market is forecast to grow 15 per cent this year and at roughly that rate through to 2011. This is a higher growth rate than the overall enterprise content market of which it is part, and higher again than the general IT market.
Gartner just revised its 2008 IT market growth figure down from eight per cent to three per cent because of the economic turmoil. Compared to that the document capture market is hot, and Bish, who has said his favourite movie is The Terminator, is back, hungry to do it again.
He scents that EMC Captiva, Kofax's main competitor in its core batch capture market, is getting weakened through closer integration into EMC and through staff leaving at all levels - none of his previous eight direct reports are still in place.
Kofax is being energised and reorganised for growth. Staid old document capture is turning out to be a good place to be, because there's lots of business processing left to automate and that saves cash - these days that's exactly what businesses want. ®
For Chuff's Sake
For chuff's sake, how difficult can it really be just to use XML and have done with it?
Incoming data is parsed by means of regular expressions (which have the benefits of being well-understood and implemented in every programming language). Outgoing data is shoved through printf statements (which also are well-understood and implemented in every programming language).
You show your XML-parsing regular expressions to the people who are sending you data, and they in turn base their XML-generating printf statements upon them. Or they show you their printfs and you base your regexps upon them. Either way, everybody ends up happy.
In the absolute worst case, you end up needing a different import routine per supplier and a different export routine per customer. But since your variable names and logic are the same, you just abstract data import and export away into modules. Or, if you're deeply into the object-oriented stuff, you create a "record" object which includes methods for every possible import and export style.
EDI is not bad in itself
What is bad is the approach that is usually taken to implement. Three points of contention I think:
1- EDI exposes how bad your data is. You just cannot miss EDI mandatory fields, or enter "fictional" data to overcome the limits of your system. You need to be very proactive and look out to fix the problems in your applications.
2- Violation of standards. Often, some big customers place additional demands over the EDI standard (such as "my department ID should be in the ZIP code field") that need expensive customizations. A body is needed that disallows those customers to advertise or demand EDI, just to avoid confusion.
3- Knowledge: so many people go with the most expensive EDI implementation possible. They buy an EDI gateway and pay someone to read or write flat text files. Those text files are the ones that your application uses. This is wrong. Most major packages have EDI modules, no need to do expensive interfacing.
Lots of truth in this article
EDI is great if your supply train is geared up for it, (as in the book trade) , but otherwise it is a nightmare. Capturing the data from paper at the organisations edge so that at least the internal processes can all be electronic is a practical way forward. You can then move to full EDI when suppliers catch up.
Sometimes you have to say NO! to the customer!!!!!
Most of the displeasure with customer changes apears to be the end result of a salesperson who can't say no to the customer. Or at least one that can't explain why the changes will cost more.
For example: Customer suddenly doesn't like the "look" of a particular agreed upon "document" format, decides to change it, and when discussed with their EDI suppliers salesdroid he/she says "Sure we'll do that for you, no charge" when all the while the people who actually make things work say "Are you out of your frikkin mind!!!!!! That will take an entirely new map and new fields in the database". This problem is due to the sales department never having to understand HOW something gets done, it just magically "appears".
Customer Rule to Remember... For the 10% of your customers that cause 90% of your problems; tell them to go to hell (nicely) and give them your competitors number. That way you are rid of an unrewarding relationship and have time to find others that make money for your company all the while your competitor is saddled with the worst of all possible customers wasting his time and resources trying to please the impossible dream.
Hmm, some truth in that marketing pitch !
At my last job I had responsibility for the EDI stuff. As a smallish business it was a f***ing nightmare that we used simply to pacify those larger customers that demanded it - or some of them. Yes there are standards, but the standards are so flexible that every implementation is effectively bespoke - one customer puts item X in field Y, another puts it in field Z, another doesn't supply X and puts item C in field G instead.
And then we had those customers that insist on using 'standard' EDI, but demand so much functionality, and with such a complete absence of flexibility, that we end up running the ONE package that they will approve of. To all intents, we were running a customer frontend to THEIR system, manually, on our time, in our office/warehouse - ZERO (actually, negative) advantage to us and making a mockery of the whole concept by preventing us using the (admittedly limited) facilities we already had (at great expense).
Quite frankly, for us, old fashioned paper would have been a lot cheaper and quicker. We'd have happily done more EDI, but customers just kept making it too hard - to the extent were it wasn't worth the investment to make our facilities better.