As you venture down the path of costing out your electronic commerce platform and process, here are a few things to keep in mind based on our experiences:

Define your goals.

This step has a huge impact on numerous aspects of your analysis. If you’re tired of getting asked the question ‘What is EDI costing us?’ and you just want to be able to come up with a number for capital and ongoing expenses, that’s one thing. It’s another to get into the level of detail needed to enable a comparison of platforms or channel performance.

Our two projects had very different goals. The first was to determine a ‘total cost of ownership (TCO)’ for two competing EDI translation systems that would allow us to make a selection to consolidate all company traffic. The other was to develop a cost per transaction comparison for orders placed through the various ways customers transacted with us. Both efforts took longer than expected, but the end products were worthwhile in that they provided information that allowed us to make good investment and operational decisions. The first project had a fairly well-defined goal and proceeded through a well-choreographed process to request a capital expenditure. The goal for the second was a little more nebulous and required more of an iterative approach. If you ‘nail’ your goal at the beginning, everything else follows a little more smoothly.

Define the parameters of the project, but be flexible.

You could probably run a cost analysis using continuous improvement methodology, defining objectives and goals, developing SIPOC (suppliers, inputs, process, outputs, customers), identifying issues, in/out-of-scope, etc. (we didn’t), or you can just be sure you take a real good run upfront at drawing a box around what exactly you want to measure. Again, if you just need a quick and dirty answer on something like the cost to process an average electronic transaction, it may be a matter of adding up all known EDI-related expenses and dividing by the total number of transactions. It’s typically more complicated that that, though.

Our TCO analysis was a financially driven effort initially focused on the quantifiable line item costs associated with the two platforms, both of which were in production at different company divisions. However, as interviews took place and the data began to roll in, it became apparent that differences in usability and flexibility were germane as well. We needed to figure out a way to quantify these aspects of our work that wouldn’t have made it into the original analysis. We didn’t change the rules mid-stream; we discovered relevant information and had to find a way to make it fit with the rest of the data.

The major challenge for the transaction cost analysis was to get ‘apples to apples’ comparisons for all the different channels and ways customers had of doing business with us. This wasn’t easy. We looked at the processes involved in each channel (phone, fax, web-site, marketplaces, EDI……), identified the portion of the end-to-end process that was relevant to our analysis, and then had to go through the laborious work of rationalizing terminology, tasks, support personnel assignments, and myriad other aspects of the channels. On the electronic side, our area of interest, we delved into areas seemingly tangential to the process of bringing in electronic orders that had a true connection and cost to the process. As you begin the work of filling in the boxes on your cost analysis, be flexible enough to allow some ‘coloring outside the lines’ if you encounter unanticipated, but relevant, expense categories.

Get the right players involved.

This is sort of a ‘no-brainer’, but also something that can bring your data and process into question if not done properly. Our TCO project was part of a formal process in our IT area to support a capital funds request. The team that assembled the data included a financial resource, a systems architect, various other IT folk, and me. However, it wasn’t until we brought in some of the users of the different systems, particularly those who had experience with both platforms, that we were able to identify additional UI and system flexibility elements that were critical to the final analysis.

We had a few ‘misses’ on our transaction cost analysis team for electronic orders as well. Originally, we decided to capture costs associated with bringing orders into the company electronically with the assumption that all orders were valid and integrated into our ERP. However, we eventually had to drop that assumption, since some percentage of orders failed validation and had to be processed manually by people in our call centers and branch locations. We therefore needed to expand our team to include people who could represent those areas and speak to the level of their support. Deciding to extend the breadth of the project to capture those costs not only allowed us to improve the accuracy of our final number, but it also provided a target for a very successful continuous improvement project we executed later. Once you get the right team assembled, you’ll be surprised at the improved perspective you’ll have of the entire process.

Work at the proper level of detail.

Although this one is directly related to a couple of the points already made above, it caused me so many problems that I wanted to call it out separately. Why was it so difficult? Well…..

EDI, eCommerce, inter-enterprise data exchange, or whatever you want to call it is, by definition, right in the middle of things. For us, since we employed a ‘center of excellence’ approach and supported almost every bit of electronic data coming into and out of the company, that meant we not only had a broad constituency of both internal and external partners, but we handled a dizzying array of transactions of various sizes and formats. So, when a supply chain VP asks what EDI costs us, what does he want? Supply chain-related EDI costs, all supplier and customer electronic transactional business, or the whole ball of wax including banking transactions, HR-related exchanges, credit card company transmissions? When you’re calculating a cost per transaction, how do you factor in the differences between processing a couple hundred KB invoice transaction versus a 4 GB transmission to a credit agency? What we ended up doing was developing a somewhat ‘official’ cost per transaction for electronic customer-side business, but supplemented that with additional cuts at the data to allow me to answer specific questions from other sides of the business. Lots of work, but actually a good exercise that increased my understanding of my own area’s cost structure and value to the enterprise.

I’ve mentioned in the past that my team was organized a little differently and that the company treated electronic commerce as a significant priority. We had project managers, mapping analysts, operational support personnel, the team that supported our translation landscape, and sub-team managers on my team. In addition to those resources, people who worked with customers to qualify opportunities and match services to requirements were also involved, as were personnel downstream in our service centers, branches, and credit offices that worked with electronic ‘exceptions’. Internally, I think we did a nice job including everything needed to give us an accurate picture of relative costs across our channels. When you went outside and tried to benchmark us against competitors, though, nothing matched up since we obviously took a much more comprehensive approach to identifying channel participants. There’s no real answer to this challenge, you just need to make sure you identify all relevant costs and then work with the team to validate which ones ‘count’ in your analysis and which ones do not. In our case, if we decided we had the equivalent of one resource handling the support requirements for all the financial, HR, and other non-customer-facing transactions, we would remove that person’s payroll expenses from any customer focused analysis.

So, those are a couple reasons why it was so hard to ‘come up with a number’ for what EDI cost us. You can generally come up with a single number, but nobody will buy off on that since it’ll include a bunch of noise. Or you can get extremely detailed and try to have an answer ready for any constituent partner base, but you can get driven batty working through all the relevant scenarios.

My recommendation, given a choice, is to match the level of detail to the type of electronic commerce program you support. If you’re a small manufacturer who has implemented EDI to support a mandate from a couple critical customers, then you probably can get to a total cost number and a cost per transaction that should suffice. However, if your program is more robust and your team is right in the middle of a bunch of critical processes, you should take a shot at separating out the costs for each process and making that number available. It will help the business to more accurately quantify all costs related to its processes and will also give you some great information to work with as you continue to streamline your operations.

Final recommendations

Don’t forget to ‘think out of the box’ to capture all costs. Most expenses are in labor, communications, and systems and should be pretty recognizable in your departmental reporting. But don’t forget other people, in particular, who are involved in the process but don’t directly work for you. My rule of thumb in capturing costs was to answer the question: What or who goes away if we don’t do this process?

Don’t kill your management with excessive detail. You may need the detail to develop your analysis, but a good executive summary will work wonders in explaining it.

Use a ‘reasonableness test’ with your information. If the data tells you it costs more to handle electronic orders than to take them over the phone, then you will probably want to get further into the data to identify what’s wrong (or work on integrating those EDI orders that are being re-keyed for some reason).

Leverage the information once you have it. Analyze outsourcing, do comparisons to other channels or departments, publicize your findings. The point is that information on its own is often interesting, but it becomes powerful as you find good uses for it.

Lastly, remember there are benefits and savings unleashed with your costs. If your company spends $2M annually to support EDI and eProcurement, but saves $6M in bottom line costs and is able to obtain contracts that provide $100M in top-line sales growth because of your capabilities, that’s a pretty good investment. Don’t be afraid to talk about what your area costs- that gives you an opportunity to explain all the wonderful benefits and efficiencies you provide.

Hope everyone is having a great summer! Please drop me a note at This email address is being protected from spambots. You need JavaScript enabled to view it. if you have any questions or observations about this topic.