I caught up on the claims. I doubled up for three days this week and finished what I had left. But then the local accounting department got involved.

They told me that when I have a claim of short-shipment (right product, but fewer received than billed), I should use the RMA (a “return,” but in this case of something that never left; so the reversal of a transaction) to adjust the inventory. And if inventory was already adjusted, I would need to get the previous adjustment reversed, and use the RMA.

However, the accounting department will only allow one person to make those adjustments to the inventory. This one person, H.J., is not very prompt about making the adjustments in the first place (when we find that we are missing or have extra inventory, but do not yet know why). Things have been going okay just recently, after I basically threw a fit to H.J.’s boss, but the idea of increasing her workload must raise the likelihood of the adjustments not being done promptly.

On the phone with one of the Accounting minions, I said, “We can reverse the adjustments and use the RMA, but you will not be able to receive the RMA until H.J. reverses the adjustment.”

“I can’t do that,” said the accountant. “H.J. sometimes takes a while to get things done and the customer is waiting for credit. I have to book the RMA immediately.”

“Well, you can’t do that,” I said. “If we have previously adjusted in extra inventory and then you book an RMA for the same extra inventory, the system will reflect more inventory than we actually have and orders will drop against that inventory, thus telling other customers that their orders are about to ship when really they aren’t because we don’t have that stock.”

“Well, we will talk about it on Monday,” said the accountant.

So on Friday I did not process any claims, since I no longer know what I am supposed to do. I have a feeling I will lose the fight with accounting because they will just say, “H.J. should do her job promptly,” which of course sounds nice, but then it will happen as I said: besides having orders that we can’t ship because we discovered we were short, which already happens, and having to hold on to those orders for as many hours or days as it takes H.J. to get around to adjusting out the inventory, we will have more of the same where we already know exactly what happened to the inventory, but we still have orders dropping that we can’t ship.

Customers can find out if their order is about to ship. I think there is a way for them to do this online, but even if not, they can call the customer service center and those people can tell if an order has dropped for shipment. If so, they tell the customer that the order will ship, because they can’t imagine why we would have a dropped order sitting around for days without shipping it.

Of course, the simplest solution here is to allow yours truly to make adjustments corresponding to the validity of the claims. If I find that we have made a shipping error I should be able to make the corresponding adjustment. This is especially warranted given that the accountant I talked to who receives the RMA’s (inventory adjustments based on short shipment) makes these adjustments solely on the basis of my say-so. Since absolutely no further investigation is done beyond what I chose to do, I am basically adjusting the inventory already–albeit with the delay of going through another person, and without being able to do any negative adjustments.

Supposedly, there are legal (Sarbanes-Oxley) restrictions on who can adjust the inventory. Well, I should rephrase. I don’t doubt there are restrictions. Supposedly, those restrictions require that all the adjustments we need be performed by H.J. only, and I cannot be given the permissson. Of course, the accounting department found a way to give P.B. the permissions to adjust inventory when they realized it was either that or one of them would have to work weekend month-ends when Jennifer was not in to support the mania of maximizing month-end shipments. I guess Sarb-Ox has special provisions to prevent accountants from working overtime.

The day after I wrote my last post–that is, the Monday after I clocked a fourteen hour day to get this documentation for our new software done on schedule–they canceled the project. As suddenly as we began this new software implementation we ended it. Evidently when someone actually looked around at the different software in use they discovered that they would have to put together a customized interface during the transitional period while other sites were still using the old software, so we went from first on the list to last.

The man on the phone said we had gotten more done than he expected, although those of us the furthest ahead had only done what was required so urgently three days ago. And we were told to finish what we started, because the transition will still happen, eventually.

You can imagine how many places this project dropped on my priority list. So I turned again to claims, which I had kept up on well for December (and November, if memory serves), but had neglected in January. I decided that I was not going to be able to catch up day by day. A ten-day backlog of claims requires hours of devoted time. I have been trying to scale back on my overtime-as-problem-solving because it really isn’t; it is encouraging the problem by accomodating it. I had been struggling to bring the claims-processing to my eight-hour shift instead of an hour or two of overtime each day, but now I was staying an hour, or two, and not doing any claims.

Rather than pretending I would eventually get the claims done on regular time, while the backlog grew day by day, I decided to admit I had already let the problem go and come in on Saturday to clean it up. But I still let myself get up late, and mosey in to work very late in the morning. I sat down at my desk, went through my log-in routine, and realized–remembered–that IT had taken down the mother database that the sector customer service runs off of for some critical maintenance. In other words, my primary reference for all things order related was out for the weekend, and I was in.

Over this past year or so I have gradually developed my in-house resources to the point where I was actually able to answer most of the issues raised without the main database on line. There was that sinking moment when I was pretty sure I threw away my Saturday for nothing, but in the end I managed.

Now I’m down to about a three-day backlog. I think I can deal with this by doing two days of claims each day, which will mean probably two solid hours of overtime for three days, possibly all week.

Then I will be back to trying to get the claims work into my regular eight hours. That will be particularly hard now because P.B., the manager, was conscripted into being a member on this second A-Team coming in. He told his (and my) boss that he was too busy taking care of the other projects that had been placed on his lap, but he nevertheless got an e-mail on Friday from corporate HQ where our boss was hob-nobbing that he had been volunteered, to start Monday.

Probably the plant manager and other high-level staff, including aforementioned boss, will still expect him to continue tearing out his stockroom and reorganizing it in a way he does not agree with, not to mention the several other projects and basic functions of managing that he typically deals with, notwithstanding that these teams require 8+ hours of time from participants.

As perverse as that is, in my own way I am volunteering for it. Not for the same setup exactly, but I am trying to get into the Buzzword Training. This particular Buzzword Training requires, nominally, that the trainee complete projects with documented cash savings, so it seems like a good thing to get on my resume. I have discussed this with the Buzzword Manager and with my own boss, and in Q3, Q4 2007 we were all agreed that I was up for nomination in Q1 2008.

Following up on this in January, I found out that the process had changed and the Buzzword Manager no longer controlled, nor really understood, how candidates were nominated for Buzzword Training; so I sent an e-mail to the archeons of Acme Training and got some information back that my supervisor had to nominate me using the Dilbert Management Software. So I passed this information on to my boss. And then I followed up with him, to see if the information had taken hold; and he said he wanted to talk to the Buzzword Manager.

I believe this is when I am supposed to pathetically whine, “Who moved my cheese?”

My tempermant is more I’ll kill the rat who stole my cheese. You see, it’s not change I don’t like, it’s bad change. And there’s plenty of that going on.

Value-Steam mapping a electronic transactional process is dumb; Value-Stream maps are meant to show not so much what is happening as what isn’t, where work “in progress” is actually sitting around waiting to be worked on. Given large enough quantities of electronic data, it may also sit in queues and take time to process, but more generally data now moves as fast as any average person could hope to make it. The value-stream map springs from the “Just do it!” ethos of changing things in straightforward ways that most people can effect, not technical analysis for IT specialists.

Traditional process mapping,however, makes a great deal of sense when applied to computerized processes. In fact, the little detailed steps and the finer points of sequencing can be pivotal to the design of the software. So I was much happier this week to be working on process maps to facilitate the new factory software implementation than I was last week trying to puzzle out a value-stream map.

Still, there are always an abundances of necessary tasks in the office for which I am the best skilled to resolve, or fancy myself so, and I had to resolve to spend Thursday doing nothing other than the process maps. Since I did not lock myself in a room away from all the normal work, it wasn’t strictly all that I did; but you can fairly say I spent the day doing those. Maybe not all fourteen hours that I worked, but quite long enough.

It was fortuitous that I decided to spend so much time to get them done, because on Friday it was learned that Big Scary Guy (the same threatening power eliciting our sniveling compliance with every inane idea of the A-Team) was interested in the documentation our site was producing. This in turn gave our plant manager a whole new level of interest in what we were up to. So rather than putting finishing touches on the process maps, a good portion of Friday was spent explaining them to people who wanted previews before Big Scary Guy had his imperial review.

Right about when all that business was over with and I was feeling pleased with myself, someone from the customer service center contacted me on the corporate instant-messager and asked if I still reviewed the claims. I almost said that that the importance of the claims was insignificant compared to properly preparing for this software change over, but, as the rep was writing from the customer service center that will be closed in months, it hardly seemed appropriate to put on airs about the importance of, basically, her job function. If the claims still matter to someone who will be unemployed shortly, surely it would be brash for me to call them irrelevant.

Honestly, I think that the claims, having a direct affect on the customer, are empirically much more important than documents that will likely have very little effect on the introduction of a new software package. The day that was perhaps the highlight of the month for me in coporate politics was, in customer service ethics, unremarkable or dissappointing.

And how often the two do seem inverted.

The week before Christmas I was told by our multi-site IT manager that we had to upgrade our shipping software. This piece of software has no data validation and an inadequate interface that requires us to adapt fields for different uses on different shipments. Because the software does nothing to alert users to errors and because of the “Do this unless that” nature of our user instructions, every time we train someone new to run the software we experience a miserable period of errors surfacing when it is too late to fix them. But this same multi-site IT manager had gone to bat to get the software upgraded before and struck out; a particular hack critical to our use of the software was no longer supported, and nobody felt it was worth addressing.

Now I was told we had to upgrade, even though there was still no way for our crucial piece to be upgraded. Carrier rate changes were coming up that were not offered in a format compatible with our software. Upgrade, or stop using your primary freight carrier. How soon did this magic have to be worked? About mid January, I was told, so even though everything appeared to be headed straight toward a disaster that would require us to write down by hand every shipment, I didn’t panic. There was still time to investigate.

An hour or so later, the story changed. This upgrade must be done no later than December 31. It had to be done before the end of the month, before the end of the year, in that crucial period where if anything goes wrong the plant manager will personally lead the entire plant down to shipping to “help,” irregardless of whether the influx of people would necessarily help in a disaster like the loss of shipping software, because there is nothing more important at the end of the year than shipping everything we legally can.

Which is why we had already been bargaining and threatening and pleading with carriers to come in Saturday and Monday, December 29 and 31, when most other companies were going to be enjoying a holiday weekend. Depending on who within these companies you talked to, the answer was either yes or no. And no matter what, the rule from the plant controller (Accounting cheif) was anything that gets processed as a shipment must leave the property, and I don’t care if the truck doesn’t show up; it has to go.

Already fretting about whether trucks would actually show up, when I heard that we were facing a good chance of not having shipping software, I did panic. I told everyone in the office to panic too, for good measure. After all, when IT tells you that you can’t upgrade the software and still have it work, and then tells you that you must upgrade your software or it won’t be legal, and Accounting tells you that everything must be accounted for properly or it won’t be legal (and your job may be forfeit), and your boss’ boss says everything must be shipped (or your job may be forfeit), well, panic at least sets the right mood.

The IT guys and I decided to try the upgrade on Friday the 21st and see how it went. Filled with profound philosophical and religious thoughts on the ultimate meaning of life, we backed everything up and close our eyes and pushed the big red button. The software that we couldn’t upgrade was upgraded. Would it still talk to our main factory software, or was the hack broken beyond all use?

It worked fine. Absolutely fine. It still looked like the same program and worked like the same program. Unfortunately. I was left wondering why the IT guys had always said that we could not upgrade and the office was left wondering why I didn’t take a chill pill.

It’s basically the same story with the A-team, who were were told were a team of ruthless experts who would see through all our lies, catalog all our inadequacies, and fire top management and anyone else who stood in the way of righteousness and progress. Actually nobody lost their job, the team struggled to implement changes that had as many drawbacks as benefits, and within about two weeks after they left plans were already circulating to completely rework their processes.

Or when, on the last day of the month, one of the order printers went down. There are two printers and they have to work in tandem; one prints picking papers and one prints packing papers. We use some goofy paper that is half label, half plain, and always getting jammed, and this day we had the Big Jam that incapicated one of our key printers. Although all month long we assumed we would be racing around frantically busy on the last day of the year, it was actually a dull, slow day, without much being built or many orders for what we had; still, the loss of a printer was threatening to cease our operations completely. These two printers are not interchangable with any other model used in the factory. However, there was one of the models that had previoiusly been used collecting dust in the file room, and it was pressed into service will a fuser kit was ordered. It worked like an old, retired printer would work, badly, but it worked, and life went on.

Or at the end of the day, when we had a line of very large boxes and our small-package carrier’s truck was almost full. The aforementioned pleading had secured a promise for service on Saturday and Monday, but on Saturday the truck had only been removed from the premises so as to satisfy our controller’s understanding of Sarbanes-Oxley requirements. Our packages were still on the same truck when it was dropped off on Monday, and if it hadn’t been an eerily slow end of month, there would have been a huge disaster. As it was, it looked like several of the 100+ lb boxes were not going to get on the back of the truck, and we were considering emergency options (like taking a couple of pickup truck loads to the consumer terminal–if it was open). I had not succumbed to full panic, but I was definitely in a state of exitement as I stormed to the front office to get pictures of the inadequacy of the truck to use as proof the next time we were pressured, nearly blackmailed, into shipping when no carriers wanted to take our freight. And of course, they all fit. If there had been one more package that size, it would have gone (against regulations) in the front of the truck, and if there had been six or so that didn’t fit I am not sure what would have happened. But they all fit.

Likewise, when I found out on Wednesday, December 19th that we had to create value stream maps of our processes by January 4th, to be used to guide critical decisions of the team that would replace our obsolete factory-wide software with the Oracle-based replacement, it appeared to be impossible. Due to the slow end of the month I was able to create something I thought adequate, or as adequate as could be expected given how inappropriate value stream maps are for transactional processes (VSM’s are designed to find dead spots in physical processes) and how little time I had. VSM’s are meant to be built from on the spot observations, which take a lot of time to gather if you are going for the entire shipping process–so my data was crude estimates.

There are a couple of more stages to this documentation, but the other teams in the factory that are supposed to be mapping out their processes show little concern over the deadlines, or the detail and accuracy of their work. We all know, even me, that this information is going to be little used; yet I still incline to view this as a critical chance to prevent even just one or two monstrosities from masquerading as features in our new software. Although our work now might be just for show and tell, the larger undertaking is something we will live with for years, not forget as soon as it is done. So it is a cause for legitimate concern, right?