So, how do you know if you and your team are measuring up? Should you just ask your partners, or are there more objective ways of assessing your performance? Certainly, talking to partners is a good idea, and it’s always nice to hear their opinion about how you support them. However, the problem is that it usually is just an opinion, and that could be very subjective, possibly uninformed, and potentially colored by preconceived notions about you or your team. It’s one source of information, but it isn’t enough.

I’d like to say that we had it figured out all along and always had sophisticated, accurate ways of assessing performance, but that would be far from the truth. Like every EDI team, we started small and grew up through the years, and as we became bigger the need for determining how we were performing on an almost constant basis became necessary. Here are some of the drivers that nudged us down the path of developing operational measurements.

• Increased responsibility. During our major ERP implementation in 2006, we stepped into a much more prominent role in support of additional streams of data exchanged with the outside world. Much of this, especially on the financial side, was extremely time-sensitive.
• Transition from batch to real-time.  As EDI and the world of electronic commerce began moving faster, the old paradigm of scheduled VAN transmissions went by the wayside and partner expectations were raised to a higher level.
• Demanding partners. With our emphasis on electronic commerce with our customers and our reputation for being a rock-solid operational company, our EDI and eProcurement partners became very focused on achieving all the benefits of electronically improving their processes. Any deviation from their expectations was usually brought to our attention very rapidly.
• Continuous improvement efforts. Since our resources were sometimes constrained while demand for our services increased, we focused on improving resource utilization by using Lean and Six Sigma methodologies. These efforts not only helped us eliminate waste and improve processes, but also provided a framework of measurements that helped us moving forward.
• Problems. When something did indeed ‘blow up’ or a hiccup of some sort caused us to miss a deadline, we typically worked with our IT group’s problem management team to assess the issue, communicate to the appropriate partners who were affected, and determine root cause. In working with this group we established performance standards in processing different streams of data.

Obviously, every organization is different, but you’ve probably experienced some or all (or more!) of these pressures yourselves. It would’ve been optimal to have had everything in place in advance to address these challenges, but in reality a lot of what we accomplished was reactive in nature. That’s the nature of the beast, but it doesn’t mean you can’t try to get ahead of the curve. Here’s the best way we found to do that.

• Deconstruct your entire end-to-end process. Whether you use value stream analysis, process mapping, or whatever, it’s really important to take a comprehensive look at the entirety of what you do. As you come across the inevitable ‘ah ha’ moments that allow you to fine tune a process, look to implement goals and standards when appropriate. For example, you may have a certain percentage of inbound orders that fail and must be manually processed. Establish a time limit on how long that should take and figure out how you can monitor it.
• Recognize that you’re not the only player in the process. You need to look upstream, laterally, and downstream at the other teams and processes that contribute. In our case, we received projects from a group managed by our eCommerce area, we worked with a cross-functional group from sales, sales support, credit, and elsewhere in the course of a project, other teams contributed services (for example, creating a punch out connection or a price file), and teams in the field, service center, and corporate processed error documents from different streams. The work we did in several continuous improvement projects to collapse our elapsed time for new implementations had to start at the very beginning of our process, which in many cases was weeks before we even saw the project.
• Don’t discount the impact of error processing. One valuable outcome of a series of problems we encountered with a translator upgrade project was the identification of dependencies other teams had on us for providing a constant flow of work to them. When we experienced delays in processing certain streams of data, obviously any transactions that errored out would likewise be delayed and the people who manually processed those transactions would be sitting with nothing to do. Once we learned the nuances of these dependencies, we were able to modify our processing schedules to improve our transaction flow consistency.
• Measurements need to be customized for each flow. If you only handle inbound customer orders or a limited number of transaction types for one type of partner, you should be able to create realistic goals and measurements pretty quickly. However, if you’re a center of excellence that provides services across the organization to a number of partners, you have your work cut out for you. Communicate with your internal partners (ideally using the first step above) to not only ensure you get their thoughts about service levels, time expectations, and so on, but to also learn about processes on their end that affect the flow. In some cases, it’s necessary to get into the guts of the ERP side of the processing to see how its schedules affect the timeline. If SAP, for example, only sweeps outbound purchase orders into the EDI process once an hour, the expectation that a transmission to a drop ship supplier occurs within 15 minutes of order creation is unrealistic.

So, with all of the above being said, what do you end up needing to measure and/or monitor? It’ll be very different for everyone, but some things you can focus on would be:

• Time. How long should it take to implement a customer project? To certify a new supplier through 3^rd party testing? To get an order received from a partner into your ERP? To follow up on outbound orders that you’ve not received a functional acknowledgment on? You can get as sophisticated as you like to automate the monitoring of these things, but in reality there may be manual methods involved. The more transactional the process is you’re trying to monitor, the more likely it is you’ll be able to find a way to systemically capture the data. Our implementation process was at the opposite end of the automation continuum, with lots of handoffs, verbal communication, etc. involved that were not able to be tracked electronically.
• Non-receipt. How do you track the absence of something? For example, you may receive 1000 orders a day and you have standards on how quickly they’re to be processed, but what if you have a 4 hour gap in the day with no orders being received? What if inbound payments that must be received by 8 a.m. don’t show up? Non-receipt is a problem that’s often monitored manually or not at all, but our technical team developed some very slick methods of assessing the absence, or presence, of files in destination directories, for example, and automatically sending emails out to warn partners (and us) when something didn’t show up by its appointed time.
• Errors. Some translators provide adequate reporting for the quantity of different error conditions. In other cases, your ERP may also be a source. For example, if your inbound problem orders end up in SAP’s workflow application, there are likely some SAP reports that can help you monitor the documents by partner.  We used a combination of sources, one of which was a tool developed to identify problematic inbound ASNs and invoices from suppliers that not only captured the number and types of errors but also sent error messages back via email to the partners. If you’re a supplier to a big retailer or hub, it’s likely you’re scorecarded and will have error information captured for you. That’s not the best way of finding out about problems.
• Customer satisfaction. This is one of the most important things that can be measured. It’s kind of a macro view that may or may not be consistent with some of your other measurements. For example, you may take 3 months to implement a certain partner, which is two months too long from your perspective, but it may have exceeded the customer’s expectation and they were overjoyed to be in production so quickly. This one is best measured by survey, by informal conversation with your internal business partners, and by more structured operational reviews.

A  huge number of things can be measured, monitored, and controlled in an EDI or eCommerce support environment. That doesn’t mean they all should be. Usually, you add value to your organization by providing key project, translation, and communication services, not necessarily by having all of your people wrapped up in reporting and watching transaction flows. However, to be a top-notch operational team you need to keep a handle on those aspects of your processes most important to you and your partners. Try to get a few steps ahead of your challenges by developing easy-to-use service level agreements with your partners and well-crafted methods of monitoring key processes for your team.

As always, thanks for reading and feel free to contact me directly at This email address is being protected from spambots. You need JavaScript enabled to view it. with any questions or suggestions.