Creating an Electronic Data Interchange System? 47
jgrumbles asks: "I've been in a PC support technician internship for the past 7 months for a polyethylene (plastic) pipe company which has doubled in size the past 4 years. I've been notified that management wants me to head a new initiative within the company. The main goal, in the beginning, is to basically restructure the slipshod EDI system they are using right now. The IT director even admits he should have had some training when implementing the system, but it was at the time of the boom so he had to do it as he went along. Are there any definitive EDI/E-Commerce information conglomerates, websites, listservs, groups, or other sources of information? My main mission will be to recreate the EDI system, which includes an AS/400 in a Windows environment, from scratch. Further down the road I'll be in charge of implementing technology in other areas such as getting RFIDs on every piece of pipe we ship in order to further automate tracking and billing. So, does anyone have suggestions on where to look for information and possible case studies?"
I can see the memo now. (Score:4, Funny)
Boss: jgrumbles, our company is growing fast; we've doubled in size over the past 48 months. We need you to design, build and implement an EDI to replace our AS/400 system. Plan for expansion into RFID, shipping and automated tracking & billing. Would you mind using Ask Slashdot for guidance in this risky, company-wide endeavour?
Hey (Score:1)
Do you really need RFID that badly? It's pipe, for god's sake
2)
What the HELL are you talking about? Like, stuff used to control machines or what?
Re:Hey (Score:2)
Google and OLD IRON (Score:2)
Still, given IBM's movement to bladeservers, I'd suggest whatever solution you come up with should eliminate the maintenance cost of the old iron, the AS/400. You'll save enough money there alone to purchase a fleet of blades, and even if you're running Oracle or MySQL, you're better off than DB2 on a single mainframe.
Re:Google and OLD IRON (Score:3, Informative)
There are a few of us. Actually probably quite a lot of us.
Still, given IBM's movement to bladeservers,
Obviously you haven't, EDI is not about hardware. You should have googled too....
http://www.x12.org/ [x12.org] would be a good place to start.
Simply put, EDI is a set off transactions for communicating B2B. (Business to Business) Electronic ord
Re:Google and OLD IRON (Score:2)
Re:Google and OLD IRON (Score:4, Insightful)
Riiiight. This really cements my opinion that you DKWTFYTA. If they're using an AS/400 for their EDI now it probably means that it's also doing their ERP, invoicing, and other accounting. Doing away with their AS/400 would most likely mean even wider changes in their organization than just changing edi platforms. You can never simply "dump your as400." Were you even aware you can work with your DB2 UDB on your MIDRANGE (NOT A FUCKING MAINFRAME) iSeries with vanilla SQL?
Besides, you can create all the x12 text files you want, but if you're dealing with a lot of customers or vendors you're probably going to need to go through a VAN in which case you'll want their EDI suite anyway.
And going back to your original post, have you ever even worked on an iSeries (as400)? Long after all your blade servers have died strange and varied deaths, that iSeries will be chugging in the back room. I don't think you'll ever find a system as stable and well documented as the iSeries.
When it comes to business continuity you can't put a price tag on it. I'd MUCH rather pay a shit load of money for an iSeries that will run without complaint for decades with little intervention, than a slightly lesser shit load of money for a raft of pc blade servers.
Re:Google and OLD IRON (Score:2)
Re:Google and OLD IRON (Score:1)
You must know what you're talking about. That looks like an OS/400 command to me.
Re:Google and OLD IRON (Score:3, Informative)
It's like someone asking you how to do a mail merge, and you telling them to rip out MSOffice and Windows and install Linux and OpenOffice.
And no, it's not 'drop dead simple' to go from SQL to x12 EDI. Because there are going to be a lot of business rules in there. Most EDI is legacy, and companies are not using XML yet.
Re:Google and OLD IRON (Score:3, Insightful)
But tell me, why are other programmers so scared of a well defined set of business rules, no matter how large it is? A data transform
Re:Google and OLD IRON (Score:2)
To our users, our Alpha VMS machine is still the 'mainframe'. Even though we probably have laptops with more computing power. And our SQL server leaves it in the dust all the way around (memory, CPU, storage). IMO, mainframe has become more about the experience. They don't know the difference, so why confuse them. Just as long as we know.
As far as ripping out legacy, it comes back to 'if it works...' You s
Eliminating Legacy, the primary business reason (Score:2)
Re:Eliminating Legacy, the primary business reason (Score:2)
Well, I'm not going to argue with you. I work and consult with the programmers who write the code for our EDI every day. We are in the middle of a migration from an VMS system to Axapta, so all of our EDI work is being redone. Despite the fact that we use Gentran for the actual packaging and transmission.
Here are some examples that you might run into: a 210 for Yellow Freight may not work as a 21
Re:Eliminating Legacy, the primary business reason (Score:2)
Re:Google and OLD IRON (Score:1)
Value added.
Time = money. Time for testing, time for programming = more money. All to get a transform that is doing about the same thing that
Re:Google and OLD IRON (Score:2, Informative)
Re:Google and OLD IRON (Score:1)
Re:Google and OLD IRON (Score:2)
Why? (Score:2, Insightful)
Tell your boss that buying standard software is usually cheaper than programming and supporting custom software to do the same job. Are you going to be writing the companies word processing software next. If so, quit now!
Try here [google.com]
Re:Why? (Score:3, Informative)
Regardless, unless you find a package that handles EDI and communicates directly to the software you already run (which is rare), there is still going to be time required to learn how to create the proper maps. And if you deal with any large companies, you will find that many use their own 'flavor' of certain datasets.
Re:Why? (Score:2)
Softshare Delta [softshare.com] is raved about a lot, and it's relatively cheap.
Cheaper than Gentran, anyway.
Re:Why? (Score:1)
For high-volume concurrent processing of EDI documents it doesn't do too badly. Then again, it doesn't do too good either...
Re:Why? (Score:2)
We process over 250MB daily (a Fortune 50 company) in our MVS version and I can't remember the last time we lost a bundle of data.
RFID on *every* piece of pipe? (Score:2)
Second, EDI is something very few people ever mess with because there are too many companies out there that can handle it for you. The trucking company I work with does EDI with some of our larger customers and it's completely automated and tied into our dispatching software. A company called TSi handles th
Re:Ask Slashdot: Do it yourself brain surgery? (Score:3, Funny)
2. No, I don't think so. You might want to perform your surgery at the local LUG's next install fest. That way you can get lots of support.
Develop Exit Strategy Now (Score:3, Insightful)
We do EDI. We do it big. It's complex. It's a pain. Hire consultants. They'll waste your money, but it's not the sort of place into which one hops with no experience. Heck, hire a vendor like (Covast|Mercator|Gentran|Amtrix) to do it end-to-end. You'd be much better off career-wise learning to track and manage a project like that rather than to do it yourself.
(We're not consultants, by the way. We're a distribution company.)
Re:Develop Exit Strategy Now (Score:3, Informative)
Re:Develop Exit Strategy Now (Score:2)
Just remember that EDI is not the system but a component in a larger process. Don't confuse EDI with the business process. You need to establish business policies and practices that incorporate ERP,
Re:Develop Exit Strategy Now (Score:2)
And they will NOT like you. "Cost recovery" is the euphemism they use for charging you for correcting your EDI fuckups.
Slashdot (Score:1)
You seem to have mistaken us for the airheads you meet at cocktail parties.
Maybe I'm just mad because I can never adequately explain what I do for a living to the airheads I meet at cocktail parties.
-Peter
No offense, but... (Score:1, Insightful)
This is where you step up and tell your Supervisor, IT Director, or the President that you're utterly unqualified for this task.
Unless you're some whiz experienced systems analyst with experience in EDI and supply chain that could only get a job as a PC Support Tech,
Re:No offense, but... (Score:2)
AS LONG as you remember the primary caveat enumerated earlier; that you must be well versed with your business process. If you don't, you're no better than the 2500-rupee whizkid from Chennai who can bang out an EDI map. An EDI analyst who has a good grasp of the business concepts, and who can partner with their internal business partners AND their trading partners, will never lack for w
I moderate an EDI mailing list (Score:2)
I have a few years of EDI experience as well, and it's my day job. I don't mind knowledge transfer either.
Re:I moderate an EDI mailing list (Score:1)
Links (Score:4, Informative)
EDIFACT [unece.org]
X12 [x12.org]
How Radio Frequency Identification Affects EDI [dcs-is-edi.com]
Integration for Logistics: RFID, EDI, XML, and Beyond [builder.com]
If you are using an off-the-shelf inventory/billing system they you should probably consider letting someone else handle the integration and format-translation.
I have implemented an EDI system from scratch at my previous company. It was based on EDIFACT and email, and had extensive tracking&tracing, status feedback, error handling. The major challenge in implementing and EDI system is the integration with your EDI partners. It took 3 months from start of testing to the first real EDI message getting through, and almost a year before the workflow was right. Another challenge is that touches on legal responsibility - who said what, why, when.
I believe that ROI was good. No more manually entering 5 batches of 100 items every day. And the deadlines were improved so the final information set could be imported half an hour before work was initiated.
As far as I know the system is still chugging along 5 years after I left the company.
You know those TV ads... (Score:3, Insightful)
Seriously though, you need to get someone that has massive experience doing this sort of thing and doing it in anger.
EDI (Score:1)
I am the author of FreeB [freeb.org] which is the first GPL medical billing engine available under the GPL. One of the standards that we support is a classic EDI standard, namely the X12 837p4010a medical billing standard. Hairy beast.
We have had a surprising amount of success using, of all things, PHP and S
Take a step back (Score:3, Insightful)
(1) get your boss to write down the business reasons for the change. Not technical reasons, business - cost savings, productivity increases, etc.
If there aren't well defined reasons, then you can't technically come up with a solution that's much use, as they haven't defined the problem for you.
(2) Get your boss to write down the goal of the project. This is usually a single statement. Eg if you worked in an oil company the goal might be "deploy a pipeline from turkey to russia that can carry 5m L oil per day". If he won't write it down, you write it, and get him to approve it formally.
If he can't or won't, then you don't have a baseline to judge all future decisions against. I.e. whwnever you have a question or problem, ask yourself does it help or hinder this goal.
(3) Figure out what the parameters of the deployment should be: think what, when, why, how, where. E.g. it should be completed within X months, should not cost more than $Y, should be availble in Z% of offices, should not take more time to complete a transaction than the exisiting system.
These parameters help define what you should and shouldn't do, how much resource to devote etc. Basically they give you the rules of the game.
(4) Figure out who the stakeholders are - ie who is affected, and who has power within the company. This typically includes the fincial director at a high level, and end-suers at the low level. Speak to the FD - he often has final say over everything, and has his own set of expectations different to the IT director. Speak to the users - they can suggest problems that need to be fixed, and things that work and they want kept.
Knowing the stakeholders and keeping them informed and happy is the biggest challenge.
No offense, but you say you're a 7m technician intern. This makes me suspicious they putting a core business function in your hands that if fucked up could kill the company.
I suggest after doing basic research, going back to the IT director and saying something along the lines of "the total cost of switching, impacts on the business and risk to business interruption are not clear. Yes the current solution might look expensive on paper, but it might be less expensive than swapping. We need to scope this in a bit more depth, and possibly engage outside experts for a small study to understand costs, benefits and impacts." then hand him a short list of potential expert companies that can help. by this stage you'll have called these companies, and in general terms described your problem, and checked out if than can help, how and will it cost. You'll have names, phone numbers and email addresses for all of them.
I agree with the others when they say EDI isn't something to take on alone. Use the experts. If you've never project managed before on any scale, I suggest you get help with that too - internally or externally.
Best of luck. this can be a great learning experience.
Ps if your company throws a wobbly at any of the things I've suggested above, tehn that means they're not serious. Find yourself another job, they don't pay you enough to deal with bad management on top of everything.
webMethods (Score:2)
EDI can be mind-numbing. You'll need attention to detail, clear headed thinking, very good and very tightly controlled documentation, and a well thought out and documented processes for new EDI-partner implementation and existing-partner transitions.
For software, try getting something that simplifies life as much as possible. If your company is w