Going Back In Time

Jim Croce sang once about “… if I could save time in a bottle…” – and I just wonder where time goes…  Yes, it’s been a LONG time since you’ve seen the crazed writings I create on these pages. 

Has the silence been golden?

Of have you been secretly pining away for more wit and wisdom from the one and only; is it writings from this one that you have been yearning for…?  Or do you really just not care one way or the other and you’re just about to go read something else…?  I guess I’d better get to the topic, huh?

I know its ground I’ve covered before, but it’s still a fertile field to … darn, what’s a good word for plow that starts with an “F”…?  How about farm…?  It’s still a fertile field to farm…  There.  I got some alliteration in.

But I’m rambling on (again?) about changes and not doing things the “new” way because it’s too difficult.  Or it requires us to think of a different way of doing things that maybe – just maybe – we don’t want to think about.  It’s about adapting to change and dealing with the change that comes along as newer (and better?) ways of doing things come along.

OK… since the last time we talked, the economy has tanked and slid way down the scale… Retail sales are way off from just a few years ago and some retailers have gone the way of the Eagle and the Plymouth – they’re gone and not forgotten, a lingering memory of their products still firmly entrenched in the minds of many.

By the way – the retailer I work for is not doing horribly bad in this economy sink… Mind you, our sales aren’t growing – much – but we were only down about 4% from last year…  Some days we’re up, some days we’re down, but we’re certainly not out of the game…  Truly, if we can last out this recession, we’ll be doing pretty well.

There’s this one vendor of ours that we buy a LOT of stuff from.  And I’m not just talking about the quantities we buy from them, but even across the product lines.  We have thousands of SKUs that we buy from this vendor.  And they’re shipped directly to the stores.  We use a module within our merchandising system that can track sales and generate POs based upon last year’s sales trends.  From that data, we can create POs – one for every store – that are pretty accurate.

“How does this pertain to EDI?” you’re probably asking.  And I’ll tell you.

Each of those orders we’d generate for each of the stores was sent via EDI to the vendor, who would then fill each and every of those orders and ship the products (generating an ASN for each) and then even (now) invoice us for each of those orders.  On a monthly basis, that could save the “manual” creation of about 400 Purchase Orders.

Good stuff, eh?

But now, it seems, we’re no longer doing that.  Instead, that vendor is going into each and every one of our stores and seeing what’s needed on the shelf and stocking those shelves and then sending us a list of the items they put on the shelves and we then generate the PO (after the fact) and send the vendor the PO number (but not the actual PO) so that they could update their system (manually) with the PO number so that they could then process the invoice.

All the wonders of our working system – with minimal manual intervention – are now buried and – poof, they’re gone.

We’ve gone from that super economical, safe and efficiently powerful car of the current decade and we’re driving some 50’s era heap without even the comforts of a radio or air conditioning, let alone all those safety advances of the last 50 years…

And why?

That’s what I’m spending a lot of time today trying to figure out…  Why did we abandon this system that was working well for a number of years and go back in time to a manual process that lends itself too well to errors, mistakes and “oops” events?

Isn’t that one of the key benefits we’ve all used to push EDI into our companies and grow our EDI programs by adding new documents and vendors to the system…?  One of the key goals of processing orders via EDI has been that it helps to eliminate much of the possibility of wrongly keyed data…  If there’s an error, we know it’s probably going to be before the document was sent via EDI.  It was keyed in the beginning and then was never caught and flowed through the process from start to finish.

*sigh.  It’s just so … negative … and so disheartening to the way I’ve been thinking and working over the past few years.  To see all those positive changes being swept away and all of these negatives taking their place.  It’s like watching the past 8 years of the Bush Presidency all over again, but on a smaller scale.

OK, that was a cheap shot across political lines – but it can be viewed as a valid analogy.  But I’ll let it slide and not really give you the details of the way I’m thinking.

But, again, here we are, creating orders and getting errors in return.  Wrong PO numbers, wrong store number entries, wrong items sent and other errors.  And who’s to blame; is it our fault or the fault of the vendor?  Probably a bit of both; but I’m the retailer, so I’ll blame them.

I’m still trying to figure out from the buying department why they’ve changed their processes…  But I don’t want to sound like some whiner…  So I’m taking “other” routes – using different people in different departments – to do that dirty work.  I’d like the guy that’s now taken over that automatic process we were doing before to “suggest” the orders and create the POs from; I’m asking him to find out why they’ve stopped with the process.

And I want to know why we’re not sending those orders via EDI anymore.  I mean, if it’s because the vendor would end up “doubling” the order, since they’d already supplied it to the store, then it’s really on the vendor to make the changes in their system – to get the list of EDI POs and find that they already exist in their system and change those existing orders to use the POs we’ve sent over via EDI.

I mean, somebody is already taking those existing orders and modifying them to add the PO number in their system so that they can send us the ASN and the Invoice via EDI.  So why would it be difficult for them to take the EDI generated orders and NOT ship them and populate some table or file in their system, generate a report from that data and then manually process those changes…?  Or even handle it through a program that would go and search that file that they populate from our EDI data for a “key” bit of information – such as the store number – and then change their order to add the PO number.

Of course, there’s another way that we could do this, too.  We COULD receive an EDI document – like the 852 – and process it into an order that is then turned around as the 850 back to the vendor.  I mean, that’s what we’re doing manually as it is – we’re taking their suggested stock levels and numbers and creating a PO off of a file (usually an excel spreadsheet) they send us.  What’s the difference if it’s sent as and 852 via EDI or sent as a flat file as an e-mail attachment?

The times, they are a-changing and we’re not going “Back To The Future” – but we’re going back in time, to the land that time forgot.

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

Unemployed? Don’t move here…

I just read this article – well – a pair of articles – over on MSN – about the 25 WORST cities for finding a job and the 25 BEST cities for finding a job.  Truly interesting stuff; however the methods used to create the article are – at best – flawed.  The flaw is that they only use the unemployment rates, as compiled and published by the Bureau of Labor Statistics – a federal agency that is responsible for researching and compiling labor economics and statistics…

The list of the bad cities includes quite a few cities located in California.  But if you were to look at the list – and if you’re not from California – you’ve probably NEVER heard of many (if ANY) of those cities.  Here’s the list:

1.    El Centro, Calif.       
2.    Yuma, Ariz.               
3.    Flint, Mich.               
4.    Merced, Calif.
5.    Yuba City, Calif.      
6.    Modesto, Calif.      
7.    Visalia, Calif.            
8.    Monroe, Mich.
9.    Palm Coast, Fla.      
10.  Stockton, Calif.         
11.  Fresno, Calif.             
12.  Bakersfield, Calif.
13.  Hanford, Calif.          
14.  Redding, Calif.          
15.  Muskegon, Mich.    
16.  Jackson, Mich.
17.  Rocky Mount, N.C.
18.  Saginaw, Mich.         
19.  Madera, Calif.           
20.  Detroit
21.  Elkhart, Ind.               
22.  Sebastian, Fla.          
23.  Kokomo, Ind.            
24.  Rockford, Ill.
25.  Niles, Mich.

11 of them are from California.  But, of those 11 – only one is NOT located in the Central Valley area of California.  And the biggest (and almost only!) jobs in most of those cities are related to farming and agriculture.  And some of them are downright tiny cities.  And they’re surrounded by miles and miles and miles of … well … nothing. 

Most of the cities listed that are in the mid-western areas of the US – like Indiana, Michigan, Illinois – are areas that have industries tied deeply to automotive industries and – an even more beleaguered segment – RV manufacturing.

Let’s face it – political statements aside – the economy sucks all over…!

Now the 25 “good cities” many tend to be … well, mid-west centered, too.

1.   Sioux Falls, S.D.           
2.   Idaho Falls, Idaho       
3.   Rapid City, S.D.            
4.   Bismarck, N.D.
5.   Houma, La.                    
6.   Morgantown, W.Va. 
7.   Logan, Utah                  
8.   Fargo, N.D.
9.   Casper, Wyo.               
10. Billings, Mont.           
11. Lafayette, La.             
12. Ames, Iowa
13. Midland, Texas 
14. Iowa City, Iowa         
15. Lincoln, Neb.              
16. Great Falls, Mont.
17. Charlestown, W.Va.
18. Des Moines, Iowa   
19. Portsmouth, N.H.    
20. Missoula, Mont.
21. Salt Lake City              
22. Provo, Utah                
23. Sioux City, Iowa        
24. Odessa, Texas
25. Pocatello, Idaho

Sure, there are a few standouts in the North East and the South, but many of them are solidly Mid-West cities.  Of course, they’re also cities that, if you research them more, you’ll find they’re pretty stable cities with no great industrial claims.

Truly, outside of a religion, what does Salt Lake City hold a claim to – industry wise …?  And Casper, Wyoming and Billings, Montana – what’s going on there?  Besides being near major National Recreation areas, what industry calls those cities home?  And, as for Texas, Midland and Odessa are right next to each other (geographically speaking) and so the “gains” in one will be similar to the gains in the other.  But again, what’s their industrial base…?  Where are those job gains…?

But even then, the growth isn’t anything … huge.  Not anything like the high unemployment numbers for the California and Michigan cities.

But, again, the basic study – the reasons behind the articles – is flawed.  It gives a decidedly myopic view of things… And an exceptionally dire one, at that!

Why?  Well, it’s because they’re only looking at one single point of data – the unemployment rate.  That’s it.  Nothing about the industry that supports the area, the number of residents that do not work anyway (i.e. retirees, stay at home parents, whatever).  They don’t look at the kinds of jobs in the area – from flipping burgers at Burger King, Carl’s Jr. or McDonalds to legal secretaries, doctors, nurses and other types of “skilled labor”…

Take a look at St. Louis, for example.  They’ve got a lot of industries there – from auto manufacturing to hospitals to finance…  They’re all over.  But what does Ames, Iowa offer in the way of industry…?  What kind of jobs are even available in Ames…?  Do you think that there is a lot of call in Ames for an EDI manager…?  Or some other kind of IT position…?

That same flaw – the single source of data and the single point of data being used – can also be a major flaw in our EDI system and what we do with those documents.   What good is an EDI system that only processes a single document for a single department for a single trading partner…?  How does that improve your supply chain or your business…?

Opening up your focus – whether by the data you want to trade or by the “who” you want to trade with – can make your EDI world that much better.  That much more … well … impactful and worthwhile… leaving your EDI program just focused on one thing does not make it very useful information.

It’s like the articles I reference above – how valid is that information to you if you want to move to Sioux Falls, South Dakota and – while there is low unemployment and some growth in their job market – there is not a job for you to take…?  If you’ve achieved your MSCSE certificate, but there are no jobs for people with your abilities and qualifications, of what value is the fact that Sioux City has low unemployment..?

Or – on the flip side – you’re moving to Bakersfield or Fresno to take care of an ailing family member – but you’ve already got a job lined up – in your field of expertise – so the high rate of unemployment doesn’t matter to you.

Job futures – and EDI – need to be … far ranging and “big picture” – taking into account a lot of smaller details.  It can’t just be focused on one little fact or figure.

There’s that big retailer – WhoM shall remain nameless  – that is always the Target of the wrath and ire of many an EDI “guy”.  Those that deal with that big retailer (or the other one) know that they seem to be “our way or the highway” kind of mentality.  Do it our way or we’re not doing business with you.  It’s a very limited eye view of EDI.  It doesn’t allow for any deviation or options.  It’s this or nothing.  It’s one sides and just one point of reference.  It’s very limiting.

Now, in some ways, that limited versatility may be good – in that there’s not a lot of “extra stuff” to worry about.  Just like the one point of reference in the jobless rates in those cities – not a lot to worry about.  There aren’t many (any?) jobs, so don’t go there.

But isn’t it better when you have more to work on than just one number; or one point of view or one way of thinking…?  Where’s the value then?

Author: Craig Dunham – EDI Coordinator

Read more about Craig here: http://editalk.com/contributors/