The above is with all due respect to the Milk Advisory Board and their advertising campaigns.  But, the other day, I came across this wonderful bit of news online… And I thought – wow…  Take a read…

 Bank Robber Hires Decoys on Craigslist, Fools Cops

By Caroline McCarthy, CNET News

In an elaborate robbery scheme that’s one part The Thomas Crown Affair and one part Pineapple Express, a crook robbed an armored truck outside a Bank of America branch in Monroe, Wash., by hiring decoys through Craigslist to deter authorities.

It gets better: He then escaped in a creek headed for the Skykomish River in an inner tube, and the cops are still looking for him. “A great amount of money” was taken, Monroe police said, but did not provide a dollar value.

It appears to have unfolded this way, according to a Seattle-based NBC affiliate: Around 11:00 a.m. PDT Sept. 30, the robber, wearing a yellow vest, safety goggles, a blue shirt, and a respirator mask went over to a guard who was overseeing the unloading of cash to the bank from the truck. He sprayed the guard with pepper spray, grabbed his bag of money, and fled the scene.

But here’s the hilarious twist. The robber had previously put out a Craigslist ad for road maintenance workers, promising wages of $28.50 per hour. Recruits were asked to wait near the Bank of America right around the time of the robbery–wearing yellow vests, safety goggles, a respirator mask, and preferably a blue shirt. At least a dozen of them showed up after responding to the Craigslist ad.

“I came across the ad that was for a prevailing wage job for $28.50 an hour,” one of the unwitting decoys, named Mike, said to the NBC station. As it turns out, they were simply placed there to confuse cops who were looking for a guy wearing a virtually identical outfit.

Authorities eventually found the getaway inner tube (a getaway inner tube!) and suspect that accomplices may have picked up the robber in a boat. According to the NBC affiliate, police hope to track him down by figuring out who posted the Craigslist ad in the first place.

Craigslist founder Craig Newmark was not immediately available for comment.

RoboCop was a futuristic view of life in the US – specifically in Detroit, MI – where violent crime is the norm – much like today?  Throughout the movie, there are glimpsed scenes of a sitcom TV show (later identified as “It’s Not My Problem”) where a major character uses the catch phrase “I’ll buy that for a dollar!”

This wonderful ditty of a catch-phrase came to Me over the past few days when I was reading a post on the EDI-L Yahoo! group about “What is a decent price/cost per EDI message?” and everybody started weighing in with replies – some giving us examples of how much it costs per message at their company (about 50 cents per message) and others going down the “I pay 20 cents per KC” and others talking about the varied costs of the VANs per KC charges.  The poster suggested something about “32 cents per message” – a flat fee.

But here’s where the logic of the question – and the answers – falls apart.

Think about the documents – the messages – which you work with everyday in your EDI system…  Some are POs, some are ASNs, and some are Invoices.  You may be also sending or receiving catalog data, revised POs, acknowledgements, and more.  And now think about the SIZE of those messages.  The 997 Functional Acknowledgement (FA) can be a very short document or message – maybe just a hundred characters long.  It takes 10 of those to make a single KC…  Well, it takes 10 and nearly a quarter to make that KC – there are 1024 characters in a KC.

And then look at a BIG record – the 832 Price/Sales Catalog – and how many KCs are included.  It’s probably a few hundred KCs long – at least.

Or just think about a simple set of transactions:

     ·         A PO for a single line item
     ·         The FA
     ·         An ASN
     ·         Another FA (for the ASN)
     ·         An Invoice
     ·         Another FA

So we’ve got 6 documents.  But now let’s say that the PO is for 15,000 units of the single item.  It, too, will be a small document – we’ll say its 1 KC of data.  Above, I show an FA at about 1/10^th of a KC.  The Invoice will also probably be a short document – as it’s for just the single item – so another single KC of data flow.  In just 5 documents, we’ve got less than 3 KCs of data.

But that ASN; now there’s a big document to trade…  Let’s say that the vendor packages those items being ordered – My famous WIDGETS! – at 10 units per carton.  With 15,000 units, that’s 1500 Cartons!  And if your ASN is a carton level detail, that’s 1500 line items – actually 3000 lines (2 for each carton) – plus the data for the Shipment level and the Order level loops.  Now we’re talking SIZE.  Of course, we may still only be talking about – maybe – 10,000 characters – 10 KC.

But the concept of paying per message – now that’s not really quite fair is it…?  You’re paying 32 cents for that ASN, but you’re also paying 32 cents for the FA.  Big price difference…! 

For that 10 KC document, you’re spending 3.2 cents per KC.  But for that FA at 100 CHARACTERS, you’re spending - what - $3.20 per KC…?  Or is it $32.00….?  And if it’s just that 1 KC PO or Invoice, it’s .32 cents per KC.

Let’s take that comparison out of the EDI world for a second; let’s think about houses.  Assume that a new program comes down the pike where EVERY house will cost the same.  Size, location, amenities, all the rest – doesn’t matter.  It’s all about a unit – the house.  And each house will sell for $250,000.  The problem is that you can have small shacks of 500 square feet selling for the same price as one of the big, 5000 square foot mansions in Beverly Hills or a Malibu Beach house.  A 400 square foot studio “condo” in “the ghetto” selling for the same price as a huge 8000 sf penthouse apartment on Fifth Avenue in New York.

Can you see the problem with this logic?  Using the same concepts I used above on the KC scale, let’s go to the unit of measurement for buildings - the square foot.  In that 500 sf shack, you’re spending $500 per square foot!  But that mansion?  You’re only spending about 50 bucks a square foot.  It’s 10 times the cost for the smaller space, once broken down to the square foot level.  The studio is $625 per foot and the penthouse is just $31.25 per square foot.

Which place would YOU rather have…?  Where’s the bargain…?  Would you buy that concept for a dollar?

It’s the same problem in “per message” pricing vs. “per KC” pricing.  You’ve got these tiny little messages costing as much as the huge monster messages.  And your figures are skewed.  Now, since it costs as much to send the FA as it does to send the Catalog, you might get trading partners that balk at sending the FA for the traded documents.  Then you’ll get trading partners using charge-backs to enforce that FA compliance.

Suddenly, the “low cost per message” now starts to have a lot of other costs involved.  Charge-backs and the human hours required to track down messages – if they’ve been received by your trading partner – and more.  All to save – what, a few cents?

And that’s really one of the problems I’ve often talked about – especially on those groups – in that you can’t just look at the basic cost – the per KC charge – and base your decision off of that fee.  If you do, you’ll likely end up costing yourself a LOT more money in the long run.  Suddenly, that cheap 2 cents per KC rate you worked so hard to get is really costing you an extra 5 cents per KC in other features and benefits that maybe were included in the 6 cent per KC quote you got from that other VAN or SaaS provider you also heard from.  That cut rate deal maybe isn’t such a deal anymore.

There is another catch-phrase that comes to mind – Caveat Emptor; Latin for “BUYER BEWARE”.  It basically means you should look into what you’re buying – and all the aspects of it – and not just buy something without thinking.  Another “Look before you leap” comes to mind.

I’ve said it before – maybe in a blog, maybe in our forums, maybe on EDI-L or some other EDI related group.  But I’ve mentioned how – every once in a while – I’ll get a call or an e-mail or … something … from a VAN or network provider promising Me that they can save Me “50% of your VAN costs!” – expecting that I’m just going to JUMP right onto their wagon and sign up to save a few pennies.  But then again, what about the possible down time?  Or the archival storage?  Or any of the other features I get from My current VAN provider that aren’t included in that “50% off” cost…?

You get what you pay for – there ain’t no such thing as a free lunch – and everything has strings attached and other aspects of the deal to consider.

Yep, I’ll buy that for a dollar, indeed!

Of course, there are just as many that are simple, plain and unadorned.  Simple economy cars – even if they’re not too good with the MPG.

But I would have loved to have brought one of My Teddies to work today… Maybe the 5 foot tall polar bear.  Or the one My mom got Me for My 40^th birthday from Vermont Teddy Bear Company – with custom clothing and My name embroidered on his back.  Or maybe the one from My youth…?  Could even go with current events and bring in the Banker Bear a pal gave Me for Christmas a few years ago.

I use My  teddies in the “theme” of My PT Cruiser – and take quite a selection of them with Me to the shows I attend and use them as … well … props.  PT Bearnum (My PT Cruiser) is festooned with bears of all shapes and sizes.  And then there are all of the bear paw prints on the car; a very cohesive look.  I’ve won a few awards and was a runner up in “Crowd Favorite” at a show a few years back.

But it’s this customization – this personalization of the Cruisers that comes to mind with My comments today.

Over on the EDI-L yahoo group, somebody had posted about how a semi-non-technical person was hired to fill a supervisory position (a contractor, really) over and above the regular employees that had been working for the company for a while and have major amounts of experience in IT and with EDI.

Somewhere in the thread, one poster commented on how upper management (the ones making the hiring decisions) seem to feel that “non-tech” people make for better employees than “tech” people – at least when it comes to management – or business skills.  And I had to disagree.  Where I work – our 1^st level support positions generally tend to come to us from the stores.  They understand how we do things, why we do things and the way things work at the store level – they’ve BEEN THERE.

In the original post, it could be that our poster got his feelings a bit hurt because he’d wanted the job and they hired this outside source.  But maybe the upper management wanted some new ideas – some new ways to take what they’ve got – a functioning EDI program – and make it better.  Make it different.  Customize it, personalize it and make it a much slicker program – something more in-tune with a changing philosophy, a changing business landscape, a changing world.

If you’ve ever been to a custom car show – whether a PT Cruiser show or the Japanese Imports (Rice Rockets) or hot rods from the fifties and sixties – you’ll notice that there are many cars that are similar to others, and yet are completely their own creation and often very unique and different from the others.  Even if they’re the same make and model of car – the Chrysler PT Cruiser, for example – you can have so many different ideas and concepts and projects and looks and feels and … you get the idea, right?

Same can be said of our MIS/IT departments and our EDI programs.  We all don’t use the same documents, we all don’t require the same data segments and elements.  We all use the documents and the data that will best suit our own needs.  And our own business practices.  It’s what fits US.

Just like My PT Cruiser – PT Bearnum – fits ME.  It’s something from My world and My desires and My tastes – My Bears – and it’s put onto a similar “medium” as the guy that’s into Winnie the Pooh characters…  Or a fan of RC model planes… or hot air balloons, Betty Boop, Charlie Brown and his pals, Disney villains, Little Red Riding Hood, or even Dean Martin and Sammy Davis Jr. and Frank Sinatra and the “Rat Pack”…  not all themes work together and all are unique and different approaches to the same vehicle.  And then there are the PT Cruisers with the “factory” flames or the “factory” woody look or whichever.  There are the unique – and not-so-unique – flaming paint jobs.

And these are just like some of our EDI programs.  Some of use the EDI application we do right out of the box; with no changes, alterations or customizations needed.  Some of us use EDI applications that are custom made for us – based on a box stock application – but fully customized and personalized to suit out own business needs.

Same can be said of the hiring practices above.  The company may have found that it would better suit their needs to hire an outside source – with a different background and experience than our poster – and bring him on to manage the group and maybe – just maybe – point them in a new direction or down a different road.  Maybe take their fine running system and finely tune that engine to really make it roar and get and give more bang-for-the-buck – balancing and blue-printing the engine, super-charging it, adding performance enhancers and features – all to really make it GO!

And maybe – just maybe – it was easier to hire somebody with that “new way of thinking” as a leader, rather than promoting the “same old thinking” to leader and bringing in the “new way” as an underling and causing strife and discord from the start.

Often times, it seems that a trained monkey could do many of the IT jobs out there.  You just train them to push button A when light B goes off or throw lever C at 12:15 PM.  It’s not rocket science.  But then again, even rocket scientists had to be trained SOMEPLACE.  Maybe they were the monkey earlier on.

So maybe hiring the outside guy rocked the boat and made some people … less than pleased.  Maybe they wanted a really special look and feel to their program that they weren’t getting from the guys that just wanted that PT Cruiser with the factory flame package…  They wanted some OOMPH and something stupendous and unique – they wanted flames – and fireworks - and maybe even some bears…  maybe even “Da Bears!”…

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

At the particular location she worked for – they did a 4-day work week.  Monday through Thursday, 40 hours a week, off on Friday and the rest of the weekend.  Now, mind you, this was in the late 70s and early 80s – not too long after a fairly famous – and campy – movie called “Thank God It’s Friday”.  A little disco-era flick starring Jeff Goldblum, Debra Winger, Donna Summer, The Commodores, and a few other faces from the Funk and Disco era of pop music.  Even a girl known as Terri Nunn - soon to become famous as a singer for the “alternative” - New Wave - group BERLIN - best known for the ballad “Take My Breath Away” from the Tom Cruise flick - Top Gun.  I think it may actually have been Jeff Goldblum’s first BIG role….

The movie gave rise to a quick and fun little acronym – TGIF – Thank God (goodness, whatever!) It’s Friday – meaning you had the weekend to go and have fun!  It was Friday night, you could go out to a disco and dance your stress away or drink yourself into a stupor or do whatever else it was you wanted to do on a fun and potentially fun Friday night.

Back to Racal/Vadic.  Since they only worked 4 days a week, their Thursday was a lot like everybody else’s Friday…  So they came up with a great concept – “Let’s get a slogan and put it on a shirt!”

So they did.

So Happy It’s Thursday.  S H I T …  Ooops!

Of course, it was known that the acronym would be … well … just that.  And it was a big joke and a great laugh for the manager that approved and had the shirts made and given out and sold to the employees…  Big letters down the front of the shirt:

So
Happy
It’s
Thursday

Ah, yes.

OK, now the reason for this tale of fun with words…?  Well, it kind of goes back to My previous blog about TOOLS and using them, and how we can give people these great tools and show them the fantastic benefits of those tools, but if they don’t use them, we’re lost.

This morning, on My commute, I was annoyed…  And that is an understatement.  I was nearly hit by a woman with her cell phone to her ear.  Then there was the erratic driver – also with the cell phone pasted to their ear.  And then at least 3 more people with cell phones attached to their ears!  Yet, in that other blog, I’d talked about those wonderful tools – that Bluetooth or headset – and how those tools can make life so much better…  Easier…  Safer.

And now you’re asking yourself – what the heck is this guy going on and on and on about…?  What does a blog about TOOLS have to do with an acronym that sounds like a “dirty word”…?  What is it all about, Alfie…?

And I’ll tell you…  It’s all about making lives easier and better – through the use of TOOLS – and giving up the “old” and embracing the new.

These days, so many people still stick to the old way of doing things – kind of the “if it ain’t broke, don’t fix it” line of thought.  No need to make a better mousetrap, because the original works so well.  Everything old is new again.  Blah, blah, blah.

As you’ve maybe read in the past, I’ve been working on the 810 spec for our accounting department.  It’s been … a struggle … and I think I can finally see some light at the end of that tunnel.  Of course, it’s been interesting to see how some of the attitudes and concepts have changed in the accounting department; one of the first supporters of the concept has now turned into one of the hurdles and roadblocks we need to overcome.  This accounting manager was all gung-ho for the concept and yet now is throwing up new requests and changes to a report that has already been finalized.  Or at least HAD been finalized…

And then there’s the flip side – the accounting clerk that was happy with the “old way” of inputting invoices and didn’t want to change, but is now a major proponent of the NEW way.  “Oh, my job is so much easier now!” is a regular comment…

Then I can go back to the cell phone users I talked about earlier – they’re still clinging to the “old way” – having that little electronic box in their hand, at their ear, yakking away.  But it could be SO MUCH EASIER if they just did a headset.  The NEW way IS better.  And safer; and easier.

“But I don’t want to change!”

Same can be said of any new concept that comes along to make life better; easier; more efficient.  Over on the EDI-L Yahoo! group, one of the posters mentioned – or rather asked – if anybody had a kind of “EDI FOR DUMMIES” presentation or similar that she could use to explain the concepts of EDI to a sales director.  She was looking for a way to explain – what can be – a fairly technical concept to a completely non-technical person.  Something that could show the sales director what value existed in EDI.  But in his terms and in a way he could understand.

To the sales director, the concept is outside of his bubble – his sphere of knowledge and understanding.  And it’s not really something he’s interested in.  And the only reason he’s probably asking about it is because some possible new client is asking about it.  And he wants to look smart and with-it and in-the-loop and not appear to be a dolt.

And it’s something new and different.  At least it is to him.

The concept of the 4 day work-week is “new and different”, too.  Or at least, it was.  But it was shown to have a benefit.  And it worked.  And it made people’s lives better.  Telecommuting is “new and different” to some people’s ways of thinking, too.  But it can make things better and easier. 

Think of all of the things that have changed in just the past – 10 years?  20 years?  Think of where we were before the advent of the cell phone; before DSL; before iPod.  We did things the “old way”.  We used pay phones, we walked next door to talk to a neighbor; we used dial up or didn’t even have “the Net”.  We read books, listened to portable radios, bought CDs.

Things HAVE changed.  In many ways, things HAVE gotten better.  But things have also gotten more complex and not always easier.  We’ve advanced as a society and as a world with some of our technologies and our changes.

All that it took was a brave soul (or two or two-thousand!) to make and accept the change and go with it; to use those tools and to better their lives.  To understand what benefits could be had by using the 4-day workweek, the telecommuting, by using EDI.

And sure, there have been some … pitfalls … with those advances.  People’s attention spans seem shorter; driving can be more dangerous; EDI communications can fail.  Some of those advances can seem to have made us take a step back; or at least a step on a wrong track or in a seemingly wrong direction.  But if we stay that course – follow through, use those tools and keep looking to the future and watching out for those pitfalls – imagine what can happen.

Shi…  Um… I mean So Happy It’s Thursday.  At least the weekend is almost here.

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

So, you’ve decided to come back for more, eh?  Glutton for punishment, I guess.

This time around, we’re going to cover the concepts of the “STANDARDS” and also the SYNTAX and the Content of your EDI Document.  Now, again, I’m coming from a background in retail and using the ANSI/ASC-X12 standard.  And we use version 4010, which is, arguably, a few versions behind, but that’s not truly important.  I know that UN/EDIFACT and TRADACOMS have their own standards and documents, but, again, I’m just dealing with what I know – X12.

For each industry that uses EDI and the standards, there are different forms that can be used.  The book on My desk for the X12, v 4010, is the size of a dictionary.  And it’s printed on that same super thin paper in tiny little type-face.  And it’s almost 1800 pages of that tiny type.  But not every document is used in every industry that may use EDI and use the X12 standard.  Some are strictly for retailers; some for real estate; some for insurance, for banking, for hospitals.  Some of the documents MAY be used across the industrial lines, but some are very specific and specialized.

 Within that X12 standard, there are literally HUNDREDS (at least 300 by My count) of documents that can be traded – from the 850 Purchase Order, the 810 Invoice, the 860 PO Change, the 852 Activity Data to the 262 Real Estate Information Report, the 255 Underwriting Information Services and 249 Animal Toxicological Data.

Wow…  Who knew?

With TRADACOMS (the Standard used in the United Kingdom for most retailers), there are a couple of dozen.  I’m not sure how many documents are in use for the UN/EDIFACT standards, but I’m sure there are a few.

For each document, there are then a series of hierarchy loops – levels, basically – of the information structure.  These levels – the hierarchies – lay the data out in a defined pattern, so that you can have similar data “grouped” with similar data.  Within those levels, you will have the SEGMENTS and the ELEMENTS we touched on last time.  And you can have segments in multiple levels and even repeated within a level, as needs require.

Still there and with Me?   Good.

When you come to the hierarchies, they’re going to – GENERALLY – follow a structure or a pattern.  Kind of like the e-mail analogy I used last time, where we had a TO, FROM, SUBJECT, BODY and CLOSE, the hierarchies will follow a similar kind of pattern.   For example, an 856, the ADVANCED SHIP NOTICE – or ASN – will follow a particular pattern.  A very common pattern is called SOPI.   SOPI stands for SHIPMENT, ORDER, PACK, and ITEM.

The SHIPMENT hierarchy is all about just what it says – the SHIPMENT information and data.  In this hierarchy loop (or level), you’ll find information about the ASN Number, shipment date information, some ship to or ship from information, a bill of lading or tracking number and more.  You can specify the kind of container that is being used (corrugated cardboard) and the name of the shipping company, the weight of the shipment, the number of cartons, and so much more information about the SHIPMENT.

Following SHIPMENT, you’ll generally find the ORDER hierarchy loop.  This contains information and data, as it pertains to the order information.  You’ll find some date references – order date, ship date, arrival/anticipate date, the Purchase Order Number, maybe vendor identification (number, etc.).  Again, this hierarchy loop is all about the ORDER information.

Next up, you’ll generally have a PACK loop.  Most times, this is a pretty small bit of data.  In the ASN spec I use, it’s all about the marks and numbers – the carton label number – for that box.  That’s pretty much it.  In here, however, there could be any data that refers to the packaging of the products ordered.

Then we’ll see the ITEM hierarchy loop.  This is where you’ll find all the data, as you guessed, about the ITEM being shipped in the ASN.  Widgets…  Shoes…  Apples…  Whatever…  This is all about the goods being ordered and shipped.  Everything that’s in that shipment should be listed on the ASN and this is where the item specific detail goes: colors, sizes, quantities, UPCs, SKUs, the works.

Within each hierarchy loop, there are a number of SEGMENTS that contain the elements and the data.  Each segment has a name – an identity.  Within the ASC X12 standards, it’s generally a 2 or 3 character code that identifies what data should be contained in the SEGMENT.  For example, there’s the TD1, TD3, TD4 and TD5 segments.  This is where you would – generally – find the information pertaining to the CARRIER DETAIL.  Things like who the trucking company is, any routing transit time, special handling, hazardous materials information and more.  Or there can be the SN1 segment.  This is all about the item detail – the shipment.  This segment is where you put in the information – the details – about the item being shipped.  Here’s where you can have UPCs, Item Numbers, SKU numbers, Item Descriptions and more – as long as it’s all about the item being shipped.

The SEGMENTS are further split up into DATA ELEMENTS.  This is the nitty-gritty detail of the shipment.  This is where your content really comes into play.  And the STANDARDS also come in here, as the STANDARD lays out what SEGMENTS fall into which hierarchy loops or levels and what elements and data can be included in the segment. 

The ELEMENTS are all about the actual detail of the shipment: quantities, PO numbers, costs, UPCs, item numbers, carton sizes, and more, are all displayed in the ELEMENTS in the SEGMENTS.  This is the level where you really need to have a keen eye for details, as there may be any one of a dozen possible elements to use to identify the data being sent.

Let’s assume you’re working at the ITEM level and the LIN (Line Item Detail) segment.  And you’re trying to get across a VENDORS STYLE NUMBER or designation.  There are a number of choices – looks like 4 in the copy of the X12 Standard I use.  You can use VA (Vendor’s Style Number) or you can use VC (Vendor’s Catalog Number); or how about VP (Vendor’s Part Number), VN (Vendor’s Item Number) or even VU (Vendor’s Basic Unit Number).  Hey!  That’s five!  Of course, then I also see XA (Preferred Part Number), the MG (Manufacturer’s Part Number) and more and more and more.

In this same SEGMENT, you can also have all the information related to OTHER numbers and information related to the item being shipped – the UPC, the SKU, and so forth.  Truly, however, this qualifier (known as the Product/Service ID Qualifier) could be for use in many documents and many segments.  It could be used for financial records, medical records, educational records… 

This can be where many people who create EDI translation documents have to be really careful.  Since there are a lot of codes and qualifiers that could be used to relay the data and information you’re trying to get across, you need to be sure of what you and your trading partners will recognize.

In a previous blog, I talked about the concepts of EDI being replaced by XML; how there’s the DTD/Schema that tells you want the data being transmitted is.  Well, that DTD/Schema basically functions as the formal “STANDARD” of the document, even though there isn’t any formal STANDARD with XML…  The only “RULE” in XML is that you have a set of tags around each bit of data you’re sending.  The DTD/Schema then tells the receiver what it is that this TAG means.  Think of the TAG as the ELEMENT QUALIFIER in the SEGMENT of an X12 document.

Even with all of the potential for confusion that can be found in any of the standards, having that standard and set of rules makes EDI something that’s not exceptionally difficult.  It can be easy to master, as long as you pay attention to the details and work with your trading partners on the documents you’re trading – from syntax to content – to be sure that the data you’re trading – sending back and forth – is clean, reliable and usable.

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

But one of the things that Tim was ALWAYS looking for was “MORE POWER!” from his tools - and just about everything else in his life.  Tim’s tinkering with tools would often lead to disastrous results - with an over-powered tool that did far more than it should and was usually pretty destructive.

The other day, I wrote a bit about the power of DETAILS in our EDI world.  But this morning, I was reminded that - even with all the details in the world - we’re nothing without the tools to use them.  And how our actions and all the details we can monitor and provide, how they’re for nothing if the users don’t use the tools we provide them.

This concept of TOOLS and how we should use them was pushed to the forefront of My head this morning, on My drive in to work.  Here in California, we have a newly enacted law that requires the use of “hands free” devices for your cell phone when you’re driving.  Doesn’t matter if you use the phone’s built-in speakerphone abilities (if applicable), a wired headset that plugs in or one of the wonderful Bluetooth devices - whether an ear piece, a clip-on speaker or the one installed in your car (if you’ve got it).  I know that a lot of the “high-end” car companies offer this option in their models.  Lexus, Mercedes, Jaguar, BMW and more have a Bluetooth “kit” built into many of their cars.

Well, this morning, driving on I-10, making My way from Rancho Mirage (home) to Riverside (work) - about a 50 mile trip - I was being passed by a recent generation Lexus LS - the top of the line sedan.  After the Lexus passed Me, I noticed that she started slowing down and … jiggling … a bit in her lane.  When I pulled alongside (she’d slowed by about 5 to 10 MPH), I could see that she was doing something with her arms - moving them around quickly.  Then, a half-second later, into her hand comes her cell phone.

Now, we all know that cell phones are tools - and can be very good tools; very useful when used properly and to our benefit.  Of course, like a 3 year old with a hammer, sometimes tools are abused - like when some … youthful … person is texting messages to their pals - all the while driving down the road at some speed and (obviously) not paying attention to the details of driving. 

But here’s a great instance of a wonderful tool that’s not being used.  The Bluetooth (or other hands-free device).  If that driver in the Lexus had used the device she’s got - and chances are, she’s got SOMETHING to use her phone hands-free - she wouldn’t have had to fish around in her purse or a pocket or wherever her phone was and her attention to the details of her driving wouldn’t have suffered.  She wouldn’t have nearly swerved into My lane.

There are a lot of other tools we can use in our EDI daily lives, too.  And there are great tools we can provide to our users - those accounting clerks and supervisors, those buyers, those warehouse receivers, and all the others.  We can provide them with EDI Invoices, EDI Purchase Orders, EDI Shipment Notices.  We can provide them with records and forms and documents and other forms of data that can be used by them to help make their jobs just a little easier…

We have other tools in the shed that can be used to great benefits by us, our users and even our trading partners, vendors and suppliers.  We can offer solutions for nearly any question or problem - from changing a PO automatically in the system (the 860 in X12-world), provide activity/sales information (the 852), and more.  All of these tools can help us - and our users - to make work easier, better, and - very importantly - more accurate and with less errors.

We can use the 832 - Vendor Catalog - or one of the outsourced catalog website (Inovis and SPS Commerce both have them) to download and - even - automatically update our product management system with the latest and greatest information from our vendors and suppliers - size runs, color availability, UPCs, style numbers and more.  We can keep our systems up to date with product information and changes.

Another example is that it’s often important for a retailer to provide some kind of reporting to their suppliers and vendors as to how a certain product or line is doing in their stores.  These days, it’s become even more important for a buyer and a seller to work more closely together and “fine tune” the product mix in the stores and carried on the shelves and stored in the warehouse.  Retailers are having to pay more attention to their bottom line and the big picture and keep inventories to a more controlled size so they’re not saddled with left-overs come the end of a selling season.

In house, we have a reporting system (called The Eye) that can help our buyers look at trends and see how products are doing, based on sales history and comparisons of different sales periods - whether weekly, monthly, yearly or for a specific advertised sale.  However, because of the large number of products we carry - over 10000 active SKUs and many thousands more that may no longer be carried and in stock - and the large number of stores - over 400 in 10 states - tracking all of that history creates some VERY large databases for The Eye to keep track of.  So we limit some of the levels of detail available to be viewed - we don’t track each item, for example, to the store level, but keep track of the classes.  Or at the Style level of merchandise, we only can see how well that style is doing over the entire chain.

Kind of limited tools.  These tools need “MORE POWER!”

Additionally, our buyers may want to work more closely with a vendor rep on some products or lines and need to provide them with the information on how Widget X is doing in our chain and what we can do to maximize sales and limit overstock levels and all the rest.  And there are many ways that we can get that information - tools we can use - to share that with our suppliers.

If we want to do just the EDI route, we can use the 852 Product Activity document.  By creating this document and trading it with our suppliers, we can provide them with a snapshot of how well the product(s) are doing in our stores and provide them with the appropriate data that they need - and data that we can see, too - so that we can come to a better understanding of our needs and how they can help us to meet those needs.

We could also just send paper reports - or e-mails - to the rep and do it that way, as well.

There are also a number of 3rd party sources that we can use to give access to that data.  Tools that we can provide to our suppliers and that we can use with them to better understand how well a product is doing.

We recently started using Edifice as a 3rd party provider for POS Activity data reporting to our vendor community.  Every week, we compile reports on how well products are selling - or not! - in our stores and the stock levels we have and send the information - via FTP - to Edifice.  They then work with that data and create reporting that our vendors and suppliers can access (if they subscribe) to view that very same information.  Additionally, we can view that same reporting that they’re viewing, so that our buyer and the company rep can be looking at the exact same numbers and data.  They can be comparing apples to apples instead of grapes.

It’s a great tool.  And it’s got “MORE POWER” than our in-house system because Edifice can give the detail down to the size and color - the individual item or SKU - and also down to EACH store in our chain.  And the reporting compares this year to last year, and can also compare seasons and months and a lot of other points of interest.

Right now, about 2 dozen of our suppliers are subscribed to this reporting from Edifice.  And our buying department can see that exact same data.  But here’s where it all falls down - like a house of cards in a strong breeze.

Remember My tale about the Lexus driver and how she didn’t use a great tool - her Bluetooth (or similar)…?  Well, it was a case of not using a tool that can make life better.  Well, the same can hold true for this kind of Activity Data reporting - it’s a great tool - but only if the buyer - and the supplier - can open up that tool box and pull it out!  And, of course, they have to use that tool, too.

That’s really something we all can relate to in the world of EDI.  As I’d mentioned earlier, we have some great tools in our shed that we can provide to our users.  We’ve got some great ways of trading data back and forth with our vendors and suppliers - some great tools - but it’s getting our users to actually use those tools that will suddenly reap the benefit and the rewards from that hard work.

MORE POWER, indeed.

But, let’s face it - EDI isn’t sexy. It’s not glamorous… We’re not going to get many invites to black-tie-and-beaded-gown-red-carpet-fancy events. There are no EDI “Oscars” or “Emmys” or “Tony Awards” or anything like that. There’s just data. And details. Lots and lots of details.

And they do say that “the devil is in the details”…

And do I know a thing or two about details! I’ve often been told that I sometimes put in TOO much detail. When I was taking some creative writing courses in college, one teacher was always fascinated and enthralled by the amount of details I’d provide in a story and another always warned Me about too much detail - to let the reader create the image in their mind, of their experiences. If you’ve read much of My work on EDI Talk (or My latest blog over at Inovis), you’ll know I do tend to go into some details - and, yes, sometimes get a bit off track with them…

Now, where were we…?

OH! Yes. Details. And not the men’s fashion magazine!

Truly, however, it is just those details and our attention to them that can make or break our EDI career. How well we provide those details to our trading partners in our outbound documents and how concise we can make our EDI Document specs, the better documents we can receive from our trading partners in return.

In a lot of ways - whether related to our work, our homes, our personal relationships, our cars, whatever - if we do not pay attention to the details, we can lose track of something that can - and usually and probably will - create havoc a bit later on. Take the driver on their cell phone… They’re so into that conversation, that they seem to neglect the details involved in driving… So they don’t stay in their lane; they run that red light or stop sign; they sideswipe some car on the road or cause some other kind of accident.

True, it doesn’t happen all the time. But the opportunity is there for disaster. That recipe has at least an ingredient or two and just needs a few more to be complete.

The daily newspaper and the evening news always have stories of issues or disasters or problems - and oft times you can see that if somebody had just paid attention to a detail or two, the situation may never have gotten out of control. Remember the bridge collapse in Minneapolis in 2007? How about the plane exploding just after take-off in Madrid in 2008? These disasters - and may others - may have been prevented if somebody had just paid attention to the details.

Years ago, I was taking a Carribbean Cruise. 10 wonderful days aboard the SS Rotterdaam, in the Holland America fleet. I was living in Northern California at the time and had to fly to Fort Lauderdale to meet the cruise. And, of course, the travel agent couldn’t seem to find space on a non-stop flight and so I had to swap planes in Dallas-Fort Worth. At the time, DFW Airport had 2 sets of runways - one for all Eastbound flights and one for all Westbound flights.

So, here I am, all snug in My 727 as it’s zooming down the runway and beginning to lift off. Now, if you’ve ever flown on a 727, it’s an experience, as they tend to build up all of their speed on the ground and - seemingly - LEAP into the air, with a quick and very angled climb. Only then, after they’re so many feet into the air, do they begin to level off. Back to My flight, the nose was lifting and you knew it was just a second or two before the back wheels would lift and we’d be in the air…

Just a milli-second before the rear wheels left the ground, a warning light flashed on the dash and the pilot put us back down, stopped us and turned us around and headed back towards the terminal. He told us, as we were heading back, about the light and how he wanted to get it checked out so to be sure it was nothing.

An hour later, we all find out that the bulb socket is what caused the problem and it wasn’t related to the systems it covered. Never did know what system it covered… But a new socket was installed and the light bulb replaced.

Of course, now that we’re an hour later, there’s a stormfront moving in from the west and the Eastbound runway is backed-up with other planes on their way out. Luckily, our pilot talked to a tower controller and got permission to fly out Westbound - where there was far less traffic - and turn around and head east. We were up and flying again in minutes, rather than sitting on the tarmac, waiting in line to take off.

That pilot was paying attention to the details. Because of his attention to details, we were only marginally late in arriving in Florida, but we also all arrived safe and sound. Never knew if the warning lamp COULD have been a big issue and could have resulted in a disaster. But because of a detail oriented pilot, disaster was averted.

Hmmm… where was I…? RIGHT! DETAILS…! DISASTER…! Aversion therapy…

WHAT?

But truly, it’s those details that keep us going. By getting the right information to our vendors and suppliers and customers, we can avert disaster. Or, in the very least, we can avert some problems and issues that could arise later on.

One of the things I’ve always mentioned - in blogs and comments here and on other sites - is how wonderful EDI is at helping to curb errors and mistakes. You don’t get keying errors from an AP clerk or a Customer Service clerk that types in the wrong information and your order for 100 widgets becomes 1000 widgets. Or the invoice for $568.00 becomes 5680…  You miss the errors where somebody wasn’t paying attention to the details and “Oops!” - an error happens.  Hopefully somebody catches that error, but…

And what about the details of our translation specs..?  They matter a lot too.  It makes much more sense if we put an “order quantity” (from the PO1 segment of an X12-850 Purchase Order) into the correct field in our ERP, rather than just put it any ol’ place.  It matters that we pull the total dollar value of the invoice - the amount we’re looking to get paid for the productds or services we’ve rendered - from our accounting application and put that in the TDS segment of the Invoice (or similar, based upon the standard you’re using!) so that when the customer gets the invoice, they pay us the right amount.

Those details matter. Those details can be the difference between “No problemo!” (Terminator 3) and “Houston, we’ve got a problem!” (Apollo 13). 

Those details make it so we have the right information in our systems and can do the right thing with that information; from filling an order to creating that order; paying an invoice to setting up items to be ordered to be put on that invoice.  Details are truly important cogs on the gear wheels we use in every day life.

Details are not sexy. 

Details are plain, dull and ordinary. 

But details matter; details get the job done.

Craig covers the basics of EDI, why it exists, communications, and standards.  Its a great read for those new to the EDI world.

Basically, at the core, EDI is a way of sending data back and forth between two entities. It can be two companies, two universities, or two hospitals; even two divisions of the same big company or corporation. EDI is used in a large number of industries - from retail sales and automotive manufacturing, to banks, hospitals, insurance and so many other industries and uses…

But what being “penny wise and pound foolish” means (basically) is that your so concerned with the pennies and how they’re being spent, you kind of lose sight of how you’re spending your pounds.  Or dollars and cents…  It’s all pretty much the same.  But it’s all about being so concerned with the small stuff - the petty details - that you lose sight of the BIG picture - the final outcome.

Anyway, the original poster over there was wondering on where he could receive some “AS2 training” – and everybody then kind of went off into the “oh, we use ______ for our AS2 connection and love it!” kind of comments – but very few seemed to offer an answer to the poster about his question – AS2 TRAINING.

Like there is such a thing!

“But, wait!” You say.  “What does this have to do with being ‘Penny wise and pound foolish’?”  I’m getting there, I’m getting there.

Seriously, though, let’s take a look at what AS2 really IS.  It’s a method of communications.  It’s a way to connect.  In a nutshell, AS2 is (from Wikipedia):

“Applicability Statement 2 (AS2) is a specification about how to transport data securely and reliably over the Internet. Security is achieved by using digital certificates and encryption.”

I kind of liken AS2 to DSL/broadband connectivity for surfing the net vs. the “old” dial up that is BSC.  It’s connecting to our trading partners via the same protocol that governs the Internet – the place we surf, download and blog – Hyper Text Transfer Protocol (HTTP).

And did you really need any kind of “training” when you started using your DSL – or your wireless broadband or your cable modem or your ____ connection to the internet…?  Nope.  There’s not really a whole heckuva lot to learn.  Other than a “how to hook up your new AS2″, there’s not a much there.

Data goes in, data goes out…  Just like the Itsy Bitsy Spider…  Or the waves, crashing to shore…

But back to AS2 and what it’s all about.  AS2 is just a way for us to send data over the internet connection (HTTP) from one system to another.  No muss, no fuss, no bother.  And in some cases – or as many would lead you to believe – at no cost.

But, wait a minute!  Hold on there!  There ARE some costs involved in AS2 communications…!

When it comes to communications – sending our EDI information back and forth – so many people seem to focus solely on the concepts of the “per KC charge” or fee structure for trading data.  Inovis, GEIS, AT&T, Sterling, ICC, and all the rest, charge us (generally) a flat fee for each KC we send or receive.  Depending on how you’ve set up your contract, you may get a flat fee – say, $4000.00 a month – for a flat amount – say 50,000 KCs – of data you send or receive.  Then, after that, they charge you an “over-limit” fee of 5 cents a KC – or more or less – depending upon your contract.

With AS2, those KC charges all go far, far away…  But, what so many seem to forget – or if they’re selling – want you to forget – are the OTHER charges that can be and are associated with AS2.  Depending on what system(s) you may use to translate and transmit your data, there could be some licensing fees associated with setting up AS2.  Maybe, just maybe, your software provider allows one AS2 connection for “free” but charges a license fee for each and every AS2 connection over and above that “freebie”.  Some may not even have AS2 built into their system and you need to “add” programs or modules to your EDI application to get AS2 connectivity.

Then you get to think about the wondrous wonder of the Internet and connectivity – BANDWIDTH.  If you have a narrow “band” for your Internet connection, then this additional data may clog that tunnel.  Just think of the scenes from “Independence Day” and how Will Smith’s girlfriend (fiancé?) was caught in the tunnel as Los Angeles was being blown to bits by the invading alien horde and her and her kid and the dog were trapped in the tunnel as the fireball of alien laser energy was blowing LA apart.

Now, while your bandwidth may not be as limiting as a 2 lane tunnel in LA, it can still have some limits.  And congestion in your tunnel may not be as dire and deadly as it was in “Independence Day” – lives may not be wiped out in seconds.  But it can cause you problems with your ISP if they only give you a limited bandwidth per month.  Now you’re over and you’re getting charged for that overage.

Then there’s the concept of labor…  And right after Labor Day, too.  But there is the cost of the man-hours (or woman-hours!) it takes to set up those connections and maintain those connections.  It may only take a few minutes to set up those AS2 connections and maybe a few more to test that connection, but there are still some costs involved.  And then what if Jane AS2 Master quits and you hire Joe EDI Master who knows NOTHING of AS2 and has to learn by the seat of his pants, on the fly, as he goes along?

Plus, here’s another wrinkle in the smooth fabric of cost – wrong, bad, or error data…  Let’s say that ABC Company’s newest shipping clerk created a shipment (and, therefore, generated the ASN) for a shipment, but missed an entire pick-sheet of cartons in the truck or container.  Once he’s hit send (or whatever) and that shipment notification is generated, he can’t go and fix it – without RESENDING that ASN – corrected, of course.  So now you’ve got 2 documents – one is missing information that the other document contains.  Sure, if the EDI system at ABC Company is set up correctly, that new ASN is sent out as a replacement, but how does YOUR system handle it…?  Does it just delete the old record and rewrite the new record?  Or do you have 2 records in your system…?

So many people and companies seem to focus on the pennies of the situation those darn “per KC charges” and then lose track of the big bucks of the EDI process and programs and all of the other systems that EDI touches.  They’re so focused on the small things and the smallest cost, and they lose track of the overall costs of the project or system.  They’re so concerned with the “per KC charge” that they forget (or lose track of, anyway) the other associated costs with what they’re doing.

Don’t get Me wrong - the small stuff matters, too.  Like those “per KC charges”…  But if you’re so focused on that small figure, what happens to your bottom line costs when you take into consideration the other costs (as suggested above)…?

Penny wise and pound foolish.

It’s the same when you get that sales call from some network or VAN claiming they can save you up to half of your VAN costs!  WOW!  Sign Me up!  But, wait a minute!  What about those other costs…?  Beyond those pesky KC charges?  Don’t they matter, too?

The sales folks at those other VANs and providers aren’t thinking about your total dollars – they’re just hitting you with the easiest cost to argue – the KC charge.  They know it’s a high-profile cost of EDI.  It’s one that you have to justify every time the contract comes up or the bill needs approval.  But what of those other costs…?  The costs of downtime – what happens when the network is down…?  What about the time you’ll have to spend on trading partner notifications?  What about the time you may have to spend on reconfiguring your communications systems – or even worse – the translation set up.

So, basically, the concepts of just saving a few cents here or there on KCs are very Penny Wise, Pound Foolish.

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…