Has anyone implemented EDI in their organization?

W

Willy-2005

Has anyone had the privelege of implementing EDI in their organization? I've been given this task and have been told to run with it. Never done this before so I was wondering if someone could answer some of my early questions?

1) Are there any major pitfalls to be aware of in the early stages of planning and implementation?
2) Who have people used as their transaction agent, otherwise known as a VAN(value added network)?
3) What software have people used - are there any to avoid?
4) Typical timeline for implementation. I understand this depends on the individual organization but what might I expect.

We are a small corporation consisting of approximately 60 employees. We specialize in sheetmetal fabrication and powder coat painting.

Any insight to one or all of my questions would be greatly appreciated. If anyone has any additional advice, please share - I'm the blind, leading the blind here, with this project.

Thanks a bunch - Willy :D
 
A

Al Dyer

Willy,

EDI can be a daunting task. There a very few software programs available, Harbinger comes to mind. I think the best advice I can give is to meet with the customer that is requesting you to comply with EDI (big 3?) and use them as an initial resource.

If that fails I suggest contracting an outside source. They cost money, but how much is your time worth.

I'm sure there are other members of the forum that can give you a more definitive response. Let's here from them.

Good luck!
 

Marc

Fully vaccinated are you?
Leader
Are you automotive or what?

What information do you intend to communicate to / with other companies? How many other companies? Is this a customer requirement?

Need more info. Don't let Al scare you. It isn't always a bear. It depends upon answers to some of the questions above.
 
J

Jim Biz

Our computer techie - told me it really wasn't that difficult to accomplish here - the number of parts you are dealing with is not a major deal --- after the system is set-up.

He says - "EDI standard raw data" can be programmed for input (MAPPED) into a number of systems (We use MRP Plus as an example - not a reccomendation but - that's just what we use)

We have 180 folks at the plant and kick out as many as 2000 work orders per month - it took him (basically working alone) about 6 months.
 

Marc

Fully vaccinated are you?
Leader
That's been my experience. The mapping and verification were the only 'toughies' and they weren't that big a deal. One client had multiple customers and suppliers they exchanged data with. Each one was mapped and that was it. And they used multiple formats. Some was directly through the internet. Some data came in on tapes weekly or monthly. Some by daily ftp. It's mainly mapping fields in the databases.

But above I'm talking EDI between different companies. Internal EDI - such as data input into a database from an electronic device (such as a 'wired' caliper) isn't that much of a big deal either.

But - as Al notes, if you don't have the expertise inside you'll have to outsource. A lot of companies do this. One smaller company I worked with got a deal through Dell where Dell sent a contractor to do everything from wiring to install.

One last comment. Don't confuse true EDI - which is data interchange between different companies, with ERP and/or MRP which are typically bounded internally (internal control and synchronization and reporting). Not all ERP / MRP software has an EDI interface.
 
W

Willy-2005

Marc,

We have one automotive customer that we do powder coat painting for. They have asked that we become EDI capable or risk losing any future business. We will still retain the business we have now, we just won't be able to quote any new projects. We would like to grow the powder coat side of our business and maybe pick up a few more automotive customers. We do have an existing customer base (which isn't powder coat related) that has asked in the past if we were capable of EDI.

The information that we have been given from our automotive customer is pretty vague. They won't make any suggestions or recommendations for us so "were kinda flyin' by the seat of our pants." The documents that we know we need to communicate are the 830 (Planning Schedule with Release Capacity) documents. Is this just an automotive set of documents or will it work in other industries? Are there industry specific documents? Does the 830 planning documents include invoicing and purchase orders and what about accounts payable?

Our current MRP is MAS90, developed by SAGE software. Our software support guru says to use Sterling Commerce as the VAN and that they can "map" any document requirements to follow suit with MAS90. I'm curious if this is common practice or not. Our auto customer is using Brain North America with GEIS as their VAN. Anybody had any experiences with either of these two companies?

Implementation has been tentatively scheduled for 2nd Quarter of '02. I'm not sure if this is an optimistic timeline or not but it's what I have to deal with.

Thanks in advance for the help!:confused:
 
A

Al Dyer

Marc,

I sure wasn't trying to scare anyone. If so I would have posted my real EDI experience with G.M. and German/Chrysler.

That said, you make some very valid points.

But I still say it is up to the person that has been tasked to perform the deed...................
 

Marc

Fully vaccinated are you?
Leader
I'll respond more fully tomorrow, but read this:

(broken link removed)

If you should be afraid of something, this is it... In part, it reads:

The first thing Seyk did was purchase a Y2K-compliant ERP system—Lawson Insight version 7.1.5—from Lawson Software, a St. Paul, Minn.-based vendor. But just as he and his staff of five got around to testing the software, Lawson released a new version (Lawson Insight version 7.1.6) that included a function for prioritizing bill payments. That function had been promised but never delivered in any of the previous versions, Seyk says.

With just two months to go before the clock struck midnight on Dec. 31, 1999, Seyk didn't have time to deploy the upgrade, even though the payment prioritization function had been a critical selling point for the 53-year-old CIO. "We had to implement accounts payable, the general ledger, payroll and human resources to make sure they were Y2K compliant. It was no small feat," says Seyk, who is also a vice president of the private company.

Between November 1999 and July 2001, Lawson released seven new versions of its software to fix bugs or add functionality that had been promised but absent in each previous version. Seyk was outraged. He documented his problems in a series of letters to Lawson executives, met with them on two occasions, and sank a total of $594,974 into software and maintenance to correct the flaws in their products.

And then it dawned on Seyk why the software and support were so bad: That's the way vendors make money. They push products on the market before they've been adequately tested, demand payment up front and then are often not available to deal with the sequelae of poorly performing products. (Lawson officials declined to comment specifically on VisionQuest's problems with its software. All a Lawson spokesperson would say is that the company is working with VisionQuest in an effort to resolve its concerns. "We are committed to 100 percent customer satisfaction," says Bev Bergstrom, vice president of communications for Lawson.)

How Bad Software Pays Dividends

CIOs have been complaining about poorly designed and buggy software forever. In a recent survey on CIO.com, almost half of the 88 IT professionals questioned said they were unsatisfied with both the quality of their business software and the support. (For full survey results, see Does Business Software Stink?) The problem is a big one: Faulty software costs businesses $78 billion per year, according to Jim Johnson, chairman of The Standish Group, a research company based in West Yarmouth, Mass.

But now many CIOs are beginning to realize that the root of the problem may lie in the economics of the industry. Vendors generate most of their revenues through perpetual licensing agreements, which force CIOs to pay up front for an application. In return, CIOs own the software and the right to use it "in perpetuity." The problem with this model is that in reality, CIOs are lucky if they can get three years out of a product before vendors release entirely new versions of their software. Vendors further pressure CIOs to buy those new releases by threatening to stop supporting previous releases—a tactic they often take both to cut their tech support costs and to get CIOs to pay again and again for what is essentially the same product.

"We didn't pay Oracle. We owed maintenance of $300,000 to $400,000, and we just didn't pay it. We said, 'We're holding on to the money until you get this thing up and running.'"

—BILL CROWELL, CIO, MEREDITH CORP.

Another problem with the perpetual model is that CIOs have to fork over an additional 15 percent to 20 percent of what they paid for the software in annual maintenance fees to cover product updates and tech support, according to Chuck Phillips, managing director and software industry analyst at Morgan Stanley Dean Witter. If CIOs want to receive upgrades, patches and access to tech support—as inadequate as it can sometimes be—they have to pay the yearly maintenance fee. Software companies earn a significant amount of cash from these fees. So it's in the manufacturer's best interest, at least financially, to make products that need maintenance and that have to be continually improved with successive updates, patches and versions that CIOs pay for up front. In sum, bad software works for the vendors.

There are, of course, other reasons for all the bugs. IT professionals point to a whole litany of causes: bloatware, with all its useless bells and whistles; programmers working in isolation, blissfully ignorant of how people will ultimately be using their software on a daily basis; reusable components that may already contain bugs; an absence of agreed upon professional standards; and developers who take shortcuts to meet deadlines during development.
But a large part of the story may indeed be the way vendors sell software. CIOs are finally waking up to this, and a growing number are demanding that vendors change their business models. A council of IT leaders from a dozen heavy-hitter enterprises convened in August under the auspices of Boston-based analyst company AMR Research, intent on pushing for software industry reform. The group issued a peaceful statement of its desire to "work with" software companies for improvements in quality, delivery reliability and versioning. However, with big names like Becton Dickinson, Boeing, Cabot, General Dynamics and Kraft on the roster, the council has enough weight to change "work with" to "lean on."
Some other IT users have resorted to more extreme measures—such as withholding payments to put pressure on vendors—but new legislation may soon make it harder for CIOs to employ such brute financial tactics. The uniform computer information transactions act (UCITA) makes it harder for customers to sue vendors and allows vendors to more easily change contract terms. The UCITA has already been passed in Virginia and Maryland and is under consideration in seven other states and the District of Columbia.

Fortunately, there are a host of alternative solutions on the horizon, and a growing number of CIOs are determined to make them a reality. They include renewable licensing agreements, in which CIOs purchase the right to use software for two to three years at about 85 percent of the cost of what they'd pay under a perpetual license. CIOs then have the option to renew the license at the end of the term if they're happy with the quality of the product and the support. Subscription licensing agreements are similar to renewable licenses, except the term is shorter, lasting about a year, and CIOs rent the software, as opposed to owning it.

Finally, some CIOs are opting to circumnavigate packaged software wherever possible. They're turning to open-source technologies such as the GNU and Linux operating systems, the Apache Web server and Sendmail e-mail. "People are not involved with [the open-source movement] for profit; they're involved with it because they want to write good product," says Bill Lessard, coauthor of NetSlaves: True Tales of Working the Web and a former developer for Prodigy and AOL Time Warner. "If software makers see they are losing money to people going the open-source route, then they will change. Until then, it will be business as usual despite appearances."

As much as eight years ago, Patricia Wallington, president of CIO Associates and former CIO of Xerox, was envisioning a new method of buying software. "I wanted it to be like a lending library where you could find modules on the Web, buy the ones you were interested in, cobble them together and create your own software," she says. "We need to rethink the way we deliver software because it is so intransigent."
 

Marc

Fully vaccinated are you?
Leader
Originally posted by Willy

The information that we have been given from our automotive customer is pretty vague. They won't make any suggestions or recommendations for us so "were kinda flyin' by the seat of our pants." The documents that we know we need to communicate are the 830 (Planning Schedule with Release Capacity) documents. Is this just an automotive set of documents or will it work in other industries? Are there industry specific documents? Does the 830 planning documents include invoicing and purchase orders and what about accounts payable?
I have not been directly involved in the process. Hopefully someone here will have been directly involved with the system you mention and can help out. I know of no industry standard, but that does not mean that there is none. Just none that I am aware of.
Our current MRP is MAS90, developed by SAGE software. Our software support guru says to use Sterling Commerce as the VAN and that they can "map" any document requirements to follow suit with MAS90. I'm curious if this is common practice or not. Our auto customer is using Brain North America with GEIS as their VAN. Anybody had any experiences with either of these two companies?
Unfortunately I personally haven't any experience with those packages. Your statement from your IS / IT person sounds about right. The biggest problem is choosing the appropriate software with respect to your current systems and capabilities.

Maybe someone with direct experience can comment on your specific software and interfacing. I'm sorry I cannot help you any more than this. :(
 
J

Jim Biz

Relaying Info

Willy - Please bear with me here - I've not "personally" had expierience with it either - but our Techie says Harbinger was his choice over Sterling..

Why? Harbinger had mapped examples laid out in differing mapping formats that one could choose from Sterling - although end result would be the same - required that the process be done from ground zero so to speak - much more internal programming clean-up etc. required.


And Marc Fyi he thinks there are 2 or 3 (forms/versions) of "Standard EDI" raw data formats.
 
Top Bottom