Well, yesterday vomited snow to the tune of six or eight inches all over us, just before my evening commute started. I left the office about an hour early to beat the rush. What a laugh. Travel normally in the 35-40 minute range took me about 90 minutes.
But I did make it home safe and sound, despite the incredible tsunami of stupidity. When it rains here, people drive safely, normally, as if life mattered. When it snows? Not so much.
But I’ve been doing some heavy duty computer programming this past week or two. Unfortunately none of it is related to the major projects I have on my plate. I have a mid-year performance evaluation from my boss coming soon. I’m a little nervous, so I’m going to start praying about that now. Long and hard.
I’m working my butt off to get up to speed on these things, to resolve the issues this website has. Unfortunately, the amount of knowledge required to do that seems continuously to escape me.
What I’m doing this week is macros for MS Excel. They’re very important. It’s critical we find out why our division and the manufacturing divisions don’t have orders which align. We keep missing shipment dates, the customers start counting what we call On Time Delivery (or OTD) on a quality score card they use to measure us, and if we’re sufficiently behind in our ability to meet their demands, they will go elsewhere. Sometimes they go directly to the manufacturing division. I think I told all of you how last year we lost one of our major customers to division direct. It was $12MM dollars. Not funny. Not good. We don’t want that to happen again, so we’re working to resolve the differences between our dates and divisional dates.
See, the problem seems to be the customer gives us a date on which they require the material. Whether they require it be shipped that day or whether they require it on their dock that day is up for grabs, and varies by customer. But one thing’s for sure – somewhere between us and the division. something’s going extremely wrong.
Here’s how it works:
We enter the customer’s required date in our system. Our system also requires we provide a promise date – which is the date the part is promised by. That would normally be provided by the division, but we have to put something in or the order won’t work, so we enter the same date for the required date and promise date.
The order transmits to the division and is consumed, somehow, by use of gremlins, gnomes and probably a few trolls and squirrels, by the division’s system. The order has then successfully transmitted via Electronic Data Interface (EDI) to the division’s system…which is probably not the same as ours, for many reasons I won’t get into here.
The division receives the order, provides what they call a promise date; that’s the day they promise they can provide the part. They examine the order and, if necessary, make the translation between their part number(s) and ours. Then, the division sends us an acknowledgment on the order, also via EDI, and provides us with their sales order number (which is different than ours), the promise date (affectionately known as a “PromDate”), and a lot of other information about the order on their side.
We only care about a couple of things, though. We want their sales order number, we want to know what they think we ordered, and we want to know if – and if not, why – they can make our required date. If they can’t, the Customer Service Representative will contact the customer and see if they can accept the division’s promise date. If they can’t, the CSR goes back to the division to see what they can do to get the part expedited. Yada.
So, what we think might be happening is, sometimes the CSR chokes. The division tells us somehow they can’t make the required date but the CSR forgets to update the sales order in our system. Or the division enters the dates incorrectly, if they have to manually address them (a few do). Or there’s some other hiccup in the system, since we’re migrating from our old standard mainframe system to a new, shiny, point-and-click system.
But we feel the biggest culprit might be the divisions are changing the dates without saying anything to our people. They’re free to change the PromDate. They’re free to tell us they can’t meet the required date. But they absolutely, positively cannot CHANGE the required date. Doing so means they are altering the customer’s requirements to attempt to make their division look better on OTD statistics. It means we are never going to get correct and acceptable OTD from the customer’s perspective. And it means the entire company, not just the divisions involved, look bad in the eyes of the customer and they don’t want to continue to do business with us.
Sure, our department can point to the manufacturing division and say “Their fault! They’re to blame!” But how does that look to a customer? If you go to Walmart and get a lot of finger pointing and excuses and blame put on other Walmart departments and employees, how do you react as a customer? It doesn’t do anything to address your needs, and it only makes the one pointing and shrieking look foolish and petty.
So we’re caught between a rock and a hard place. To solve that issue, we have a set of spreadsheets with the division’s order book and one with our order book And we compare them through a process which makes sure we have everything exactly the same. If there’s not a match, it’s for two possible reasons – either the order doesn’t exist in one of the systems and a match can’t be made, or the orders DO exist in both systems but something’s wrong. We can then sort the orders and highlight the orders due in the next two weeks to make sure THOSE pending problems aren’t issues. In this way, we should align the orders eventually.
So, I’ve been asked to do that work. And it’s getting there. I have one more to do. Our three biggest divisions will be done once a week. The CSRs get the spreadsheets with the mismatched orders highlighted, go through at least the urgent ones (due in the next two weeks), and then explain why the orders which are legitimately issues are such.
Two down, one to go. It’s sort of weird. VBA – the programming language integrated into Microsoft Office programs – is similar to ASP classic, the language upon which our intranet site is built. The one for which I have to create Appmageddon and have the other projects pending. So you’d think, because I’m facile with VBA, I’d be facile with VB or VBScript (variants of the same language, based on Visual Basic version 6 or prior). But it’s not so. There’s enough differences I can’t make the programs work right, and there’s no testing ability in ASP pages. I have to just…run the page and hope. Or hope I get something more helpful than a generic and cryptic IIS error message (IIS is the web server, FYI).
Tomorrow’s another day. Here’s hoping I can finish everything I’ve got to do and get back on track with the projects I’m now sure I’ll miss in terms of deadlines. *Sigh*
Prayers appreciated, and hope you all have a GREAT weekend. I’m going to the bank on Saturday to pick a new checking account because our bank is imposing them on all customers. Isn’t that charming?
No, it’s not.
See you Monday.