Granted, we did things a little differently at our company, but I’m sure we had a lot in common with analysts across the profession. In my experience, people ‘outside’ normally feel one of two ways about EDI roles: ‘How hard can it be? You just move data from one system to another’. The other is ‘it’s magic….. you have programming wizards down there that make it happen’. It’s obviously neither, but closer to the second than the first, since a lot of wizardry is indeed involved.

Our daily work was heavily skewed toward helping customers establish connections with us to place orders, receive invoices, make payments, and perform other electronic transactions. There are standards (X12, xCBL, etc.) for these, so where’s the challenge? Well, our company dealt with well over 1 million other businesses of every conceivable type and size, so our relationships were all over the curve with respect to standards,  versions, connectivity, data integrity, and technological sophistication. We handled traditional EDI using ANSI standards and value added networks, but also processed XCBL, CXML, proprietary XML formats, IDOCs, positional files, and even spreadsheet data through every conceivable type of internet-based secure connections. Complicating matters even further, we were multi-channel, with every customer having different ideas about how electronic  documents fit into their transaction process with us. 

A couple years ago, we had to answer a question about the feasibility of establishing a relationship with a consulting group that could provide supplemental mapping support. The thought was that anytime we had projects in our queue that we were unable to start immediately due to  manpower constraints, we’d simply call our local consultancy and they’d pluck a mapper off the shelf that would help us out. In creating our answer, we took up the challenge of cataloging all the skills necessary for an analyst to actually be able to contribute meaningfully to our projects. It was a great exercise in that it not only opened our eyes to the complexity of the role, but also gave some key people a better appreciation of the ‘value add’ of our team. Without going into much detail, following are the key categories of what an analyst needs to know.

• - *Standards*. Obviously, X12, cXML, xCBL for the various supported transactions - *Mapping techniques*. This is the basic knowledge of how you transform data from one format to another.
• - *Translator*. How to make Sterling Integrator, GIS, or whatever your integration engine is do what you need it to do, what processes are available, etc.
• - *Application file formats*. IDOCs, flat files, or whatever it is comes out of, or goes into, your ERP.
• - *Communications protocols*. In some shops, the analyst does the set up of communications, in others (like ours), another team does this and the analyst needs to be familiar with what’s supported.
• - *Team standards*. As you know, there are multiple ways to ‘skin a cat’ in every translator for mapping, developing processes and so on. You have to know expectations with respect to how the work is done by your team, what mapping and process standards are in place, and so on. Your team’s map naming convention is a good example of this type of standard.
• - *How your ERP system works*. You need to be familiar with the system you connect to and how it has been configured for your company. For example, our instance of SAP didn’t allow addresses at the line level in sales orders, which obviously has an impact on what you do with an inbound order that has line level addresses.
• - *How your ERP has been configured for electronic orders*. Our instance of SAP had a number of modifications specific to electronic orders, and even treated web-generated orders differently from EDI and marketplace transactions.
• - *What the system on the customer’s end looks like*. Although our process is system-agnostic, the more the analyst knows about what we’re dealing with on our partner’s side the better. Since we worked quite often with customers using SAP and Ariba, it’s extremely useful to know their capabilities.
• - *Internal processes*. In order to get a project moving forward, an analyst would often need to deal with these processes: project prioritization, implementation, content file creation, functionality development, invoice quality, and production control. Each of these includes either internal handoffs across our team or working in conjunction with other teams.
• - *Communication*. Last but certainly not least, the analyst must be able to communicate not only with internal parties, but also to customers, who may hold technical or business titles at several different levels, and consultants.

The analyst is the key member of the project implementation team. Members of the implementation team would include a project manager from our group, the analyst, one or more representatives from the customer’s team, a field-based ecommerce manager from our company, and the seller from our company that brought in the project as an opportunity to improve the customer relationship. The role of the analyst is to lead the requirements gathering, understand the technical and business implications of the project, and then develop the maps needed for the integration. I can’t emphasize enough how important the ability to communicate to these internal and external partners is to our analysts.

After completing our analysis of the role of the analyst, we quickly concluded we didn’t have anybody that could do all that! Seriously, an experienced analyst with us could do it all, to some extent, and through the years we’ve had a few people who were ‘plusses’ in every category.

To all EDI and eCommerce analysts out there, you have at least one cheerleader who respects your work and appreciates all the skill and knowledge it requires! You have a really tough job and you do it well, so what’s your next career move? Where can you go from here? The topic of a future blog will be career paths- watch for it! 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.