right hand, meet left hand… now… who’s doing what..?

In some recent readings on other websites – geez, you’d wonder if I actually have a job with all the reading and blogging I do – there have been recent posts, blogs, commends, entries and more, about how it seems like the old adage about the right hand not knowing what the left hand was doing is still alive and well and with us today – no life support needed…

Over on the EDI-L board, one of our own forum members, Earl, was discussing – well – venting – about his current client and some issues with testing through one of those 3rd party EDI providers (won’t mention any names!)…  But if you read it, you know.  Anyway, part of this goes back to the trading partner of his client – we’ll call them ABC COMPANY, INC….  So, in good faith and in following with the concepts of implementation, Earl’s been working to complete the testing for his client to trade with ABC Company.  Now it turns out that the division at ABC Company that they’ve been testing for has been sold off to another company – XYZ, LLC.  And now testing is no longer needed.

Forget about the costs that the client has encountered in testing with the EDI provider.  Forget about the costs that have been incurred in paying for Earl and his services…  Forget about all the OTHER trading partners (like Earl’s client) that have also been testing…  And let’s not forget that mergers and acquisitions don’t happen overnight in the world of big business.

How does this relate?  Well, if the EDI department at ABC had KNOWN that this division was to be sold off, why where they so hot-n-heavy about testing and compliance…?  Why was ABC forcing all these possible trading partners – remember, the tale was from Earl – through this fairly expensive testing program…?  And, from what I’ve heard – this provider does have one of the most expensive testing programs out there.  But still, why was the EDI group forcing the testing when the division was in the process of being sold and testing would no longer be needed until XYZ, LLC, takes over and decides what THEY want to do…

It’s a case of the right hand not knowing what the left hand is doing.

On another site, a blogger was commenting on the differences between the “sides” of EDI – the Technical vs. the Business.  In other words, how, in days gone by, an EDI Coordinator – or manager or whatever – needed to grasp both the Technical side of EDI – how to format the data and make it get to the trading partner – and the Businessside of EDI – understanding how the different groups or departments would be using the data…  They had to attend business meetings with those departments to find out how the data was going to be used – in or outbound.

These days, our blogger contends, with the plethora of outsourcing of EDI functions, it seems that one side of the equation isn’t being met.  The technical aspect is being taken care of by the EDI outsourced provider, but the Business side of the equation is now being handled by … who?  Obviously, somebody at the company is handling it – but who?  An accounting clerk?  A buying clerk?  Some secretary..?  Or how about a shipping or warehouse manager or clerk?  There’s a point in there about the disconnect.

It’s a case of the right hand not knowing what the left hand is doing.

Another blogger on that same site talks about the “800 lb gorilla” in EDI – generally, the “hub” or, in My case, the retailer, that’s calling the shots.  I’ve talked about that gorilla before.  But this blogger talked about how the company, a retailer, was requiring a specific EDI document – the 846 – and how they (the supplier – the company our blogger was working with/for) was getting hit with a ton of chargebacks because one data element was wrong.  We’re then told of the trials and tribulations – and 3 week timeframe – of trying to solve the issue and complete testing the fix.

What I don’t understand, however, was how the error was missed during the initial testing for the document to begin with.  But I’m digressing.

Turns out that our blogger finds a phone number (after hunting and searching through the wilderness of the hub) and gets in contact with an overseas (outsourcing!) “tech support” – and the 1st level support has no idea about what EDI is.  They finally get in contact with 2nd level support (which has some rudimentary EDI concepts and knowledge – and they’re given the contact information for the EDI testing coordinator.  They call this other person – only to find out that he/she is out of the office for “a few days”…  Now they are weeks into trying to get this resolved – and the supplier is STILL receiving and paying these chargebacks for a wrong format for a data element.

A case of the right hand and the left hand, not knowing what the other is doing.

Even in non-EDI concepts this can be true.  My own company is building some new offices… Or, rather, they’re tearing some out to build more.  But instead of – oh, I don’t know – scheduling the work for times when there would be a limited number of people around, it’s happening right now.  And a major connecting hallway is closed off for a few hours.  Which means that the employees need to go outside, through one door, come back in through another, only to bypass this hallway that has the work being done.

Or the issue of printers – taking them down for repairs or maintenance – or even changing printer servers – and not letting anybody know.  Instead, an employee prints out some important document – an e-mail, a 200 page report his boss needs, something – only to find that the printer he was printing too is no longer online and is now installed on a different server.  Now he’s got to go back and re-create that report or e-mail and print to the new printer – only after, of course, it’s been mapped to be used by his system…

More cases of the right hand not knowing what the left hand is doing.

We can see this concept in everyday living, too, just by reading/watching/hearing the news or driving down the road, or shopping in a store and more.  We can see many times when somebody doesn’t know what somebody else is doing…  Or how, through somebody’s in-action – lack of action – causes somebody else to have problems and negative impacts abound.  Somebody forgets to clean up a spilled soda and somebody else slips and falls…  Somebody is yakking on a cell phone and doesn’t realize the light is red and slams into somebody else… 

All cases of not knowing what’s being done by the other.

How can we help to solve these issues?  Maybe by communication?  Maybe by sending messages to each other – right hand to left hand – letting somebody know what somebody else is doing.   Maybe by paying attention to what’s going on, as well.  Taking some of that responsibility of knowing what that somebody is doing – or observing that situation – and not blindly walking (driving) into that situation…

Maybe, in Earl’s case, it could have helped if he’d been reading the news about ABC Company and read that they were selling that division to XYZ, LLC….  That might have helped him….    Maybe if our blogger’s companies were paying more attention to the concepts of Business and Technical sides of the argument, or were making sure that they were not using a wrong format – maybe that could have helped them?

Sometimes, in life, we have to think outside of the box – think outside the bubble we’re in – and realize that there are others out there and we may have to interact with them outside of the scope of our box or bubble…  We have to take off the blinders of a project and look at the broader impact of our actions – or reactions – and how they’re going to affect what’s going on.

If our left hand is wildly wielding a hammer, it’s probably a good idea for the right hand to pay attention to the path of that hammer and stay out of the way – lest the right hand gets a smashed thumb…

Author: Craig Dunham – EDI Coordinator
Read more about Craig here: http://editalk.com/contributors/

EDI & Vendor Partnerships and Relationships – Take 2

Just recently, I had responded to a post over on the EDI-L Yahoo! group, and this set off a “chain-reaction” e-mail chain between our esteemed “admin” John Burmeister and Myself about collaboration… of course, we were talking about the EDITalk blog-site and a book deal – co-authored by him and I… Mind you, that’s just “pie-in-the-sky” kind of thinking, but it got Me thinking more about COLLABORATION and what it can mean to our EDI partnerships.

It probably should be mentioned that our admin and I share a trading partner relationship. He’s the EDI guy over at one of the vendors that we buy from. We also, obviously, share the EDI-L Yahoo! group, as well. When we discussed collaborating on the book (HA!), we bandied about a few titles – including “EDI DONE RIGHT! A Perspective From a Vendor and a Buyer“… Of course, I also likened it to the reputed “Rap Wars” between the East and West Coasts – and I was thinking about how we both use the same basic EDI formats and standards and data, but to different results…

Late in 2007, I went to the Inovis Roadshow Training event when it swung through Southern California. Again, as I am an Inovis user and customer, I found it to be a very helpful conference/seminar to attend. One of the things that made it great, for Me, anyway, was to be in some of the same training sessions and groups with some of My trading partners that also use Inovis products. One of the trainers likened Me to the “800 pound gorilla in the room”, as, in most cases in the EDI world, it is the buyer – the hub – that dictates what EDI documents will be used and what segments and elements and data is required to be there, what data is optional and what data we will not accept nor send.

Having Me, the 800 pound gorilla, helped with those that were there that are suppliers – either Mine or somebody else’s – gain some insight into “WHY” we send and require what we do on the documents we trade. And being able to discuss some of the issues that we have with the data we trade with each other helped us to understand a little better the why we do what we do. It’s not just because I thought the segment looked cool. There’s actually a reason for that MSG segment or that ISS segment.

Another aspect of collaboration that is kind of front-and-center for Me is a data collaboration with many of our vendors. Often times, it is beneficial for a supplier to receive some sales and stock and order level information about the products we buy, have bought and are planning on buying from them, so that they, in turn, can be sure to have the products on-hand for our orders, or at least have the ingredients – the stuff, if you will – to make the products we’re going to be ordering in time for our orders.

In this regard, there are a number of SAAS solutions out there – from big and small providers – to fill that need. We’re looking at one and working with one of them to create that data flow to provide the history of the item(s) we buy from them, our sales history and trends and allow them to possibly forecast what we’re going to be buying in the future, so that they can better plan their own levels of stock – those ingredients – from their own suppliers. This will help them to better serve our needs, which, in turn, will help us better serve our customer’s needs – the general public.

Nike (or Reebok or Adidas or UnderArmour or _________) will be able to look at the sales and inventory history for their products we carry and sell and better be prepared to fulfill our orders. Or maybe they can see that SOC (Some Other Company) is selling that same product in the same area and is just kicking our butt and maybe help us to rethink the way we do things. Maybe we’ve got too many SMALL sizes in an area that is rife with MEDIUM and LARGE sized folks. And our SMALL folks are unable to find anything besides MEDIUM and LARGE in their stores. Of course, our own buying group will be able to look at this same data and figure that out too, except for the data of how our competition is doing it.

Collaboration is an important thing in our lives – professional and personal – and works hand-in-hand with the concept I’ve covered before – about partnerships and relationships – and allows us all to prosper and grow our business. By sharing needed information, we can better help those that help us to actually help us. They can be better helped by those that help them, as well.

Wow, that was a nifty bit of alliteration, eh?

But, let’s take that collaboration thought to another level. Over on that Inovis blog, they also posted about No Supplier Left Behind and how something called MMOG/LE (read their blog!) is being used in the Automotive Industry to try and streamline the automakers processes – so that maybe it will help them with some of the issues that they’ve been facing of late. It’s hoped, at least from what I read, that this program (MMOG/LE) will help to cut costs and automate a lot of that effort between the automaker and their supplier. I’d commented about how, back in the late 80s, Chrysler had worked with some of their suppliers to create the “America” car program. It was applied to 2 different car lines – The Omni and Horizon compacts and the Aries and Reliant mid-size – over at Dodge and Plymouth. It was a program to work with suppliers to cut the costs of many of the parts used in building those cars, and also by Chrysler limited the options available on those cars, thereby eliminating the need for some parts that may have been slow moving options, anyway. The cars came equipped decently at a great price and had only a few option groups available.

This concept – this collaboration between Chrysler and their suppliers – created a program that worked pretty well for the manufacturer, as well as for the dealers and the final consumer of the car. It also helped the suppliers of the parts, in that maybe that seat fabric that they supplied now only had to come in 2 colors, instead of 6.

There are dozens (if not hundreds or thousands) of ways that collaboration can be used in the world of EDI and in our lives in general. Think of the different documents that could be traded between EDI partners – the 846 Inventory Inquiry/Advice or the 852 Product Activity Data both come to mind – that could allow vendors and buyers to better understand the products they have on hand 0r need. The products that they have too much of or not enough of. Think of the concepts of using a 3rd party provider (Edifice and AfterBot come to mind) that allows a supplier/vendor to see the product history – taken in many cases directly from a retailer’s POS data – and see how well those widgets are selling and what colors are selling better in what stores.

Collaboration is yet another tool that we can use to enhance our Trading Partner Relationships, as well as our business relationships, to better serve our own needs and our own customers. And isn’t that one of the primary goals of EDI?

Author: Craig Dunham – EDI Coordinator
Read more about Craig here: http://editalk.com/contributors/