In business, it’s a little different.  In the baseball analogy, if you’re on a major league team, you have the same number of teammates as every other team, the same positions, you play the same number of innings in a game, and you play the same teams. That’s one reason why I love the sport: somebody hitting .320 in a given year is a really good hitter, no matter what team he’s on. You have relatively reliable standards against which performance can be measured.

In our world, though, since we all do things our own way in trying to please our owners/shareholders, there are wide variances in what is and should be measured.  So why bother measuring anything, since there’s a paucity of general baseline data out there and competitive intelligence won’t be able to provide any really good information about other companies? Some key reasons from my perspective were that I needed to know how much volume our system was handling, I needed information on how much work each individual on the team was doing, we needed to understand and communicate the cost and value of our work, and we had continuous improvement projects to identify and support.

Our measurements evolved from the inside-out. We initially looked at the number of transactions we were processing, since that gave us an idea of how hard our system was working. We looked at how many maps our analysts were creating, how many errors our operational support people were handling, and how long it took our technical team to complete system-related projects. These were all internally focused things we needed to run our translator, do planning, and evaluate our people. Our measurements eventually expanded outward as our internal constituency grew and became more sophisticated. We went from supporting supply-side and a little customer EDI in the early days of the program, to supporting electronic exchanges for everyone in the organization, including finance, other divisions, marketplaces, HR, and more. Once we became heavily involved in Continuous Improvement efforts, a whole plethora of metrics beyond our standard ones resulted.

So, recognizing how different we all are, how will you decide what to measure? Here’s how I would approach it. Every team has aspects of its work, such as Quality, Throughput, Cycle Time, and Cost/Value that should be measured. Some of these statistics are needed for internal partners (ie. supply chain, customer service, finance), some for marketing or promotional purposes, and others for your own operational needs, whether system or people related.  You could take these dimensions and create a spreadsheet where the rows are the categories like Quality, and the columns are your constituencies. Then ‘fill in the blanks’, soliciting input from your team and the areas you support. For example, the Quality for Internal Partners cell might reference reports required for supplier scorecarding. The Cycle Time for Marketing cell could contain data on how quickly an average project can be implemented by your team so that the information can be included in the brochures produced to promote your offering. Everyone’s list would be different, but you should be able to come up with the general categories for the rows and columns pretty easily.

Before you move ahead with building a metric, you should answer two questions: Is it actionable? Is there a recurring need for it? Again, you don’t want to expend energy creating a nice report that nobody reads. You also need to make sure you’re not building a reporting system in response to a single question that may never be asked again. There’s a real risk in both of those. You can suck an incredible amount of scarce resource time into reporting activities, particularly in light of the sheer number of groups that could potentially be asking for information from you.  Be sure to ask those key questions first before committing to the work.

I can’t give you a comprehensive list of every measurement and metric you should capture.  You need to decide what’s important to you and hear requirements from the groups you support.  At a minimum, though, I’ll bet you’ll need these:

• Transactions by type by partner. Customer service may want to see how many inbound customer orders and outbound invoices are being processed, and other areas would likewise be interested in how you’re supporting them. You need statistics to help you identify trends, and it’s also good to be able to track how individual partners are performing.
• Cost per transaction, driven to whatever level of granularity you need. This metric is helpful in defining your value to the organization.  It’s also useful in providing a comparison for different channels, and in our situation we even developed information to tell us how costly it was to implement a partner and to provide ongoing support.
• The average time it takes to do a basic unit of work, such as develop a map, implement an entire project, or correct an error, and how many of each is handled per some time period. For basic operational purposes, this can help you forecast resource requirements and can allow you to identify performance issues among your resources. Since we actively promoted our customer- side services, we needed to be able to tell potential partners the expected length of a project with us.
• Base work effort supported by your translation software, such as transactions, business processes, etc. Depending upon how much load it’s handling, you may need to do this on a daily or even hourly basis, so you can see if your schedules can be adjusted to reduce the load at peak periods
• Errors by type, wherever they’re handled, by partner if possible. This may be a challenge in that your team probably doesn’t handle all errors, and the others may be spread out into other parts of the organization. However, do what you can to identify them wherever they are, since this category is teeming with targets for continuous improvement projects.

One thing to keep in mind is the potential to drive a process improvement at the same time you’re creating the metric. For example, let’s say your ERP validates inbound ASN data against purchase order numbers. Rather than counting errors where they are trapped and investigated in SAP, why not move the validation upstream and do it in your translation environment, reject incorrect ASNs without sending them into SAP, and format an email with the offending data back to the partner? Yes, it’s more work for your team, but in a short period of time the process would save much more time than you spent developing it. When you look at the entire process, instead of just your piece of it, you can really drive efficiency. This is part of the continuous improvement process so crucial to groups that perform eCommerce-related work.

I wish we all belonged to Major League EDI (MLE) or some other organization that provided universally understood, totally standardized baseline information. We’d then know exactly what to measure, how our competitors were doing, and how our metrics stood up to everyone else’s. We would know that a 4 week project cycle time for implementing orders, POAs, invoices, and EFT for a large complex customer was world-class and 50% better than the average. Well, as you know, it’s not like that. Define what you need to do your work and manage your process, find out what your business partners need to know, look for areas throughout the entire process that may need improvement, rack ‘em and stack ‘em, and get to work!

As always, feel free to drop me a note with any suggestions or comments to This email address is being protected from spambots. You need JavaScript enabled to view it.. Thanks, and keep warm!