When I heard this month’s topic, the question of whether EDI has a role in the world of mobile eBusiness (m-commerce), my first thought was “why the heck not?” Even though I know little about m-commerce, I do know that anytime there’s a need for data to be transformed and moved, there’s a potential role for “EDI”. That’s the rub, though: what do you mean by “EDI”?My old group was originally known as ‘the EDI Team’ but was re-named eBusiness Operations a few years ago. That was a reflection of not only how our team was built (a group that supported ‘traditional’ EDI was merged with the eProcurement team), but also the nature of the work we were doing. The business-to-business ecommerce world was becoming more complex and so were we. Occasionally, we would self-identify as the ‘EDI team’, but that was only in dealing with customers or executives who may have been confused by anything broader. EDI was a significant part of what we did, but we wanted our name to accurately reflect our entire role.
Our team was pretty big and our company was very focused on ecommerce. Obviously, not everyone is in that situation. If you’re a member of the ‘EDI team’ and you subscribe to the components of the old definition of EDI as processing ANSI X.12 documents communicated via VAN, then you might consider any work outside that to be off-limits. You’re probably right. You may not have the capabilities or processes to support activities beyond X.12 EDI, or you could even have some or all of your processes outsourced. Many teams are in that scenario and they’re right in thinking they already have all they can handle.
My problem is with teams who narrowly define their scope as ‘EDI’ and impose limitations on their involvement in other ecommerce activities. They hear about a project outside what they consider to be their ‘normal’ role and say “that’s not us, we’re the EDI team”, when they ought to be thinking “we do that same type of thing- maybe we can help”. They could be missing out on providing some valuable support to the organization.
Think about it. What do you do in your role? You pick up data, process it by translating it from one format to another, and move it to another destination. The data may be X.12, XML, fixed field length, or other formats. You communicate over the internet and VAN, in real time and using schedules. You’re in the data transformation and messaging game, and if you think like that you open yourself up for potential involvement in any project that needs those activities performed. Your only limitations are your translation and communication systems, your system architecture, the skills of the team, your work capacity, and your organizational role.
I’ll be the first to admit there’s a risk that you’ll step on some toes as you attempt to become involved in the type of work not normally associated with your team. There may be other parts of the IT organization who feel the project belongs to them, there may be a faction that wants to outsource it, or other agendas could be at play that may or may not be explicit. All I’m suggesting is that you shouldn’t limit yourself by thinking ‘it’s not EDI, so it’s not for us’. If there’s data to be moved and translated, and there’s nothing in your defined role that puts you in a ‘traditional EDI-only’ box, then you’d be remiss to not at least offer the organization the option of analyzing your capabilities against the project requirements. Your company leaders will need to select the most cost-effective way of meeting project goals. They should have all viable alternatives available from which to select. For the good of the company, you want to be a part of the process that results in the best decision.
M-commerce hadn’t hit our organization prior to my leaving, so I’m not as familiar with the architecture and process details as I should be. However, knowing some of the high-level functionality that’s out there, I’d be surprised if the capabilities of my old team weren’t at least looked at to support it in some way when the time comes. After all, we were there when our company began to support marketplaces, direct SAP connections, VMI and customer inventory systems, dispensing machines, and all kinds of other stuff you’d never think of as ‘EDI’. What’s one more? The point is that the world has changed and will continue to do so. Don’t limit yourself with an outdated view of what your role is. As long as you have the capabilities, make yourself useful!
