I was starting to sketch out my next post. It was going to be on EDI (Electronic Data Interchange) System design and I started with "Assuming you have an ERP system that processes sales orders, invoices, remittances, stock balances etc. how do add EDI capabilities?"
Then I thought wait!!! Important EDI life experience lesson - assume nothing!!!
EDI has a wide reach. It is used in all sorts of areas. While I am most familiar with EDI in ERP systems, it is also used in health care, logistics, military etc. So I thought I'd better at least provide a link to explain the term. This got me thinking about the different types of people who might be interested in these posts, what your situation is and how you came to EDI. And this brought to mind 2 experiences that challenged contrasting assumptions.
1) Assuming Everyone is Big
After many years of being familiar with ERP systems running businesses that employ many people, I had a shock. I came across a software package being used to run a small family service business. It was the sort of thing you can buy off the shelf in PCWorld. It was one of those friend-of-a-friend, help desk situations. I took the opportunity to familiarise myself with it, always looking to learn something new.
My shock came from the fact it had an invoicing function but no orders or quotes. It could purchase but had no stock control. Most of the functionality I thought was needed was missing. How could they run their company with this? The answer was, quite well thank you. You see they did have an order book but the number of orders you could count on your fingers. High value, but low volume. They didn't have a product line, no two jobs were the same. They would produce whatever the customer wanted. If they wanted to know what material stock they had, they looked in the shed.
It made me think. Could I configure my current, all singing, all dancing ERP system to run a similar company? Would it be as easy to use? If they experienced rapid growth, at what point would they need additional functionality?
What if they got an important contract from a big customer who wanted to send orders by EDI and receive invoices by EDI? How would they cope? How would they benefit?
2) Assuming Everyone is Small
Three years later I am summoned to a meeting with our then biggest customer, a major retailer. Lots of suppliers are there as they announce their Electronic Trading imitative. They have done their research and decided that past EDI initiatives have failed because they were too technically complicated and costly for all their small suppliers. They had a solution and from the audience response it went down well.
All suppliers needed was a browser and an Internet connection. They could log on to a website, print off PDF's of orders, confirm acceptance, record supplier order references, alter pricing, update delivery dates, confirm deliveries and even read the latest news from our important customer.
The small suppliers, who had feared warnings of "integrate or die", loved it. Suddenly I could see this was the solution for the small company I had experienced earlier.
The big suppliers sighed. How were we going to explain? You see we already did all this inputting on our computer systems. To repeat it on a web page would dramatically increase our workload. We organised hundreds of deliveries a week to hundreds of stores. Confirming a full order delivery was 1 click, detailing a partial delivery (or split delivery) was click, type, click, type, click, type... Unless we could persuade them to add another option, we were going to have to throw human resource at the problem.
Meeting after meeting followed.They eventually offered an FTP connection, but although most suppliers already outputted information in one of two EDI formats, the customer wouldn't accept them. They invented their own format. Every time we requested more time, we were told we could go live with the browser interface.
After we did go live, the customer provided a telephone help line. When we called we would get nonsense questions about what we had clicked on the web page.
Me: [Sigh, keep calm] We don't use the web page. We communicate server-to-server.
Operator: Eh... I'll just speak to my supervisor.
Lessons Learnt?
Trading partners have differing levels of ability.
Trading partners have many varied business styles and processes.
When volume splits 80/20 and problems split 20/80, 80 x 20 = 20 x 80 (if you see what I mean). Both half's are important. Don't design a solution to one half without consideration of the other.
Maybe Mashups are the future.