OK, I admit that personal freedom and business freedom are very different things. On a personal level it's possible to take action that affects you alone, and you don't have to convince a committee or board of directors that it's the right decision. But business decisions of any magnitude have farther reaching consequences. Unless you're running a one-person shop, or you have exceptional control over the organization, you need to make decisions based on the betterment of the whole organization. For instance, if I want to pull off the road and have lunch in a cheesy-looking diner, I can do just that. I may have concerns for the condition of my stomach for the next hundred miles or so, but it's only my stomach at stake. Hiring that diner to deliver meals for the company cafeteria carries a much bigger risk, and one I'd probably not be willing to impose on my fellow workers.
But there are ways to mitigate the risks of making these kinds of decisions. I would feel a lot better about hiring the diner if I had looked at the kitchen, interviewed its suppliers, talked to some of its patrons, and finally eaten a few meals there. Once I was sure that the results I expected (good food with no adverse consequences) were the results I received, I could feel more confident about a recommendation.
It's a shame that even though we know, or at least can figure out the right steps to take in order to make a reasonable decision, we skip over the 'right' way for a choice that is more expedient. In business, it doesn't take too many bad consequences to kill off any savings that may have come from the easy decision. Just putting a couple people out of the office with intestinal problems for a few days is likely to cost more in lost productivity than what might have been saved by not checking out the cooks personal sanitary habits.
To put that back in the realm of EDI, think about the testing process and the consequences of minimal or sloppy testing. I've seen about as many different ways of defining testing as I've seen eating establishments (and that's a big number). The difference between EDI testing and cooking is that when you eat a bad meal it may taste good and you won't find out that it was spoiled until a few hours later. EDI transactions will fail right away... but both will keep you from doing business.
I'm not convinced that I have the right answer to either picking a safe meal or defining the best testing methods for EDI. For that reason, I'm sure that I'll continue to have many uncomfortable miles ahead of me, looking for the closest rest stop. I'm much more sure that there's a 'right' way to test EDI. Take a read of the introductory story in this newsletter issue, then send in your comments. I'll weigh in from time to time on the specifics, but it's your opinion that will make the difference in the long run.
Till next time Cheers!
CecilLast modified on Friday, 17 February 2012