Estimated reading time: 4 minutes, 32 seconds

The Case for EDI ROI - It Depends

martz-ROIthLet’s face it: the more money you want to spend, the more likely it is that a solid ROI will be needed by the business to provide funding. If you’re talking about spending a million dollars implementing EDI software and building an EDI team, trust me, you’ll need one. It’s more of a grey area when you’re planning to do the bare minimum to satisfy a customer EDI mandate or even to implement additional partners onto an existing platform.  I think there are a limited number of scenarios you should consider when looking at ROI requirements, including:

  • ‘Doing EDI’ for the first time
  • Adding partners to your program
  • Substantially changing an existing program (for example, integrating a ‘rip and read’ or portal-based process)
  • Scaling up an existing program by spending money on additional (or replacing) systems, transactions, processes or people

martz-ROI

Would all of these require an ROI?  Probably not, since there’s a wide range of potential costs involved. For example, the first scenario, which usually results from a big customer’s mandate to send you EDI orders, can be executed a number of ways. You could have orders converted to fax by the VAN and forwarded to you for rekeying. You could outsource the process and receive a hardcopy version of the document to enter just like a mailed-in order. A more likely (and recent) option would be to use a 3rd party service to trade via a series of web-based screens. Now, these alternatives aren’t really EDI on your end, but they are for your partner. Lastly, you could go ‘all in’ and buy a translator and develop maps to integrate orders and support all the other transactions required. As you look at the cost continuum, you’ll move from ‘just a cost of doing business’ territory into definitely needing an ROI. If a webform process costs you $10/order and your average order size and margins are such that you’ll still make a good profit on the transaction, then you’ll probably opt to accept it as a new way of doing business. However, if you want to buy software and hardware, hire developers and support staff, and really make an investment, you’d better have a good business case.

Each scenario listed above will have its own types of costs and returns to consider. For example, when adding new suppliers to our existing program, there was little cost to us and therefore no justification was needed. However, due to the nature of our customer-side program, we did have requirements for customer size and sales volume. Was this a customer-specific ROI requirement? No, but it was an effective proxy for one. By requiring a certain volume to flow through the pipeline we were ensuring the company would enjoy a net benefit of eliminating enough manual processing over time to ‘pay for’ the cost of implementation. Even if no sales growth resulted from the project, we’d still come out ahead.

Although everyone’s situation is different, there is still some commonality in buckets that should be included in ROI calculations. There are obvious ones, like elimination of manual processing, but also others equally important, such as error reduction. These may be more difficult to quantify, but are well worth the effort. One critical thing to remember is that many of these categories are ‘net’ of incremental expenses. For example, integrating your ‘rip and read’ process may allow you to reduce the number of customer service agents who key in sales orders, but you will now be required to have personnel available to handle errors that drop out of the EDI-based process. Similarly, in the last scenario, adding a new transaction may seem like a no-brainer that will save the company a lot of money, but you have to consider the costs of ERP changes, mapping, partner communication, and other expenses required to actually make the new transaction work. Don’t take shortcuts in calculating your ROI- you want to have a realistic view of the costs and benefits, and you also need to ensure that the business recognizes the additional work required up front and on an ongoing basis.

Other benefits may be a bit more nebulous, but just as significant. In the last scenario, upgrading to a new major release of your translation and messaging software may seem like a logical thing to do, but it could be costly and the business will want to know what they’ll get out of it. Look at new capabilities, better processes, improved reporting, and support for new transactions. Unfortunately, when the business hears ‘upgrade’ it often seems to them like an unnecessary expense, but if you can sell it on the returns it’ll generate you’ll have a better chance to get it funded. Software is always evolving, and keeping current is often the best way of staying in alignment with customer requirements.

In general, almost everything that costs money in the business world requires an ROI, whether it’s explicitly stated or not. EDI is no different. What you know instinctually as an EDI professional will often need to be proven to the business. The key is to identify all the net benefits, put together a cogent analysis of what you need to spend, and trust that you’ll be able to earn the backing of the business to ensure the success of your program.

Enhanced by Zemanta
Read 3737 times
Rate this item
(0 votes)

Visit other PMG Sites: