It's all in my head

December 22nd, 2007

Usually I try to avoid writing about the technical details of my work because it is basically talking to myself; I doubt most of you are very interested in the obscure quandaries of the trade. But I am going to indulge in those details today.

My database died. The error it was producing was no longer fixed by running a compact & repair. Microsoft Access databases have a tendency to develop permanent fatal errors, especially when they are undergoing heavy structural change. Deleting an entire table of data is a more drastic change than deleting all the records from the table; creating new queries is more drastic than running existing queries. A database is meant to continually accumulate more data, of course, but it is least stressful to do this by simply adding information into an existing table, or perhaps changing some existing data. Creating and deleting the places and rules for the data, and the ways it is manipulated, always risks loose ends, orphaned bits of data, gaps, and leftovers. As usual for Microsoft, Access is far easier for most people to use but a lot less resilient and powerful than industry-grade software.

Microsoft Word is great for writing letters, memos, and short documents. It’s bad for writing book-length manuscripts and completely incapable of producing publication-ready electronic document files. Microsoft Access is great for small-scale data management, like maybe a Mom-and-Pop floral shop, but not up to tracking the volume of data that describes the operation of a factory.

Realizing this, I tried to make my last version of my workhorse database complete and concerned with only a limited amount of the data available. There were a few things that I still relied on temporary tables to do, which meant some “high trauma” was an integral part of the database from the beginning. On top of that, I kept using the wealth of information in that database for new purposes, both one-time offbeat requests and new regular data reports. Constantly adding new pieces to the database, and usually not knowing in advance if I would need to reuse the pieces, left me with a mess of tables and queries, tied together in such overlapping ways that I did not know what was critically necessary and what was long since obsolete.

This is why you are supposed to carefully document the reasons, design, and function of your original database, and continue to document all changes. When any work you do on your database is considered superfluous or at best accessory to your job, though, time is too paltry to spend time explaining what you are trying to do.

When an Access database does fail, you can usually fix it by copying all the pieces into a new database. This can be a pain, but it is better than the whole thing becoming absolutely worthless. But with my ever-expanding chores for my database, I wanted to rebuild the database from the ground up to be more robust, able to support more demands.

With the eventual demise of this database certain from the start, I planned to separate the basic building blocks of the database into separated database files, using one database to tie all the pieces together. Also, I plan to do all my ad-hoc work in another database, so that the central coordinating piece can churn out reports automatically without tying up my work time or being disrupted by my innovations.

Because my databases are working parasitically off of the official factory software, combining the data the official system has in disparate, unrelated pieces into coherent meaningful information, the first challenge for me is to actually get the data. I have one database siphoning off the demand inforamtion, one siphoning the inventory information, and anothering siphoning the transactional information, and another siphoning the shipment information. Order and shipment information has to be augmented with data not available from our factory database, which is sent nightly to our site from the hub site. I also have developed some information that never reaches our official database at all, some from the shipping software and some just collected as direct input, regarding claims and productivity. I will be able to tie this into my new database, but I haven’t gotten that far yet.

Coordinating this information is the real trick. A shipment fulfills an order by way of a transaction, depleting inventory. Since my database does not own any of this information but clones it from the official system (a live data connection is too slow and times out), I have to make decisions on when I will refresh my information. The larger data pool I hold the longer it takes to add new data too it (if I use indexing, or data rules that insure the same information is not captured twice, which necessarily involves checking the existing data when adding). Also, larger amounts of data are more likely to develop corruption. But part of the necessity of my database is that the system database does not keep adequately detailed or related information, so if I don’t archive the data for an adequately long time I have not gained anything.

The approach I am taking this time is to keep the most detailed data, which requires the most frequent cloning or sampling from the official system, for a relatively short time, and roll some of that back into a long-term archive that will still be short in terms of serious data retention, but long enough for useful comparisons. I have mulled this over in my head for months and months, trying to find an ideal set of numbers (two different time periods or three, or four? Short data daily or weekly or monthly? Long data for years or quarters or months?), and I can’t remember for certain what I finally wrote down and comitted to, for better or worse. I believe I decided on ten days for short term (a week, plus buffer time for “dud” data days like holidays) and 100 days for long term (about one quarter and one week). One hundred days is not a long term, but at that point I realized I have to just admit that I am not building a real industrial data system, and refer all questions back to the official database, however dissappointing it may be.

Just as I do not have time to document my system, I likewise cannot afford to build it as a coded, error-trapped, well-tested system. I am using quick and dirty macros to run queries that all presume the data is there; that the connection to the official system is working, that the supplementary data has been sent up on scheduled, that nothing has corrupted one of my databases and that the macros to update their information have also run. This is about like planning that it won’t rain a single day for a given two-week period; in our climate, that is possible, and very well might not happen during a dry spell, but you also know that at some point within a year the assumption will not hold.

Thus, even though I need my routines to run automatically, they have to run within my realm of awareness so that I can fix the problems and get them going again when something breaks down. But when an automatic routine is running, I am unable to use the database that is working or to open up another database; and the morning routine opens all kinds of windows that get in the way of what I am trying to do. I solved this by taking advantage of a computer that is used for little besides printing off some extra shipping labels as needed. The computer used to sit in the break room but P.B. had it moved into the office, which, although he had his own reasons for doing it, provided me with the perfect vehicle for doing my slave work.

The dangerous thing about this system is that is uses a generic log in. Almost anyone in the factory could get on the computer while it was doing whatever, and get in my database. So far I have never secured my databases, because it is incredibly easy to lock yourself out of a database (as I have done several times); but one thing I would like to do with the new database system is allow other people in the factory to access some reports themselves, providing their own parameters, so that my time is not taken up with requests for ordinary data. I would use another, locked-down database to accomplish this, but it would still behoove me to have ever database in my system secured to prevent accidental or incompent corruption of a fundamental part of my data network. Of course this is completely undermined if I have a generic account running my most sensitive administrative tasks.

The most essential pieces of my new system are now operational. Without any bother from me, the information is being stowed away for later use, available to be analyzed and compared and referenced at any time later. Now I need to begin opening that up into actual useful reports, and that is where the system that I built is exposed to abuse, damage, and ruin. By separating key data into distinct databases, less of the system should go bad at any one time, and it should take less time to rebuild. But the keystone database that coordinates all the information, and uses layers upon layers of queries to accomplish it, is already turning into a maze.

I wanted to have several coordinating databases, so that each long-term stable report could run on its own, but that is not possible without sophisticated coding, because besides relying on the same base tables of information, many of my reports rely on the same sub-queries that have to be tweaked and updated. It is hard enough to maintain version consistency between the queries used in the basic databases and their clones in the coordinating database (because, with ordinary Access means, you cannot share queries between databases the same way you can share tables).

All of this could be greatly improved on, but it would take more time, to be coded, or more money, for a better system, or–heaven forbid–an central, official system that is properly designed for data storage and open for retrieval so that none of this fooling around with Access hacks is necessary. But I shouldn’t complain, as it is my ticket to developing my skills in database concepts.

In this overview of the larger structure of my database, I haven’t gotten into the considerations of sorting away the data, how it is divided up and kept most efficiently, and various compromises on those principles for sake of usefulness. But this is what I like to do.

Only a little smoke

December 8th, 2007

Twice this week I came in to find the database that was supposed to be cranking out morning reports instead saying, “Invalid argument.” For those without any coding background, this is basically saying “The thing you want to use can’t be used that way, or maybe it doesn’t even exist.”

In a previous generation of the same setup this would happen if the routine had previously failed midway through execution, because a table would have been deleted and not recreated (the error message was different, though: “Object not found”). Because of this very problem, in my last redesign I made sure that no tables were deleted and recreated so that this would not happen.

The first time I saw this message I figured something had been accidentally deleted or that something was corrupted, and I would most likely need to recreate the database–either copying all of the objects out of the old into a new, or just building the third generation of the database. I have been wanting to build the third generation for months now, but my needs for this next version entail a complex of separate databases interdependent on one another, which all need to be updated off of the real, official plant software, and have to be updated in the right sequence to produce useful data.

It will be a big project, one that requires at least periods of intense concentration to think it out in an orderly way, and I have been trying to get my direct-value work done first. (Direct-value–I made up that bit of business jargon to mean the stuff I do that has an immediate result for people who respond to my work.)

Just so as not to abandon the ship when a little bailing would do the trick, I ran compact & repair and that actually did make the problem go away. Except that it appeared again two or three days later. Compact & repair worked again. If this were a machine at Acme and not a piece of software, we would say that it is good working order. But then that’s just because we don’t understand TPM.

I persist in thinking that one of the reasons I was hired to work directly for Acme was to retain my skills with Access as a way to get useful information presented with a modern manufacturing perspective out of an old system built around outdated manufacturing theories. Whether this was part of the original thinking or not, it has not been much of my actual job. My boss does not seem to be very interested in this cabability of mine. While I have made time to put together a few reports that add valuable information to what is readily available, these reports seem to be mostly ignored, and I do not often field requests for regular reports on key business functions. I have had drive-by requests for good enriched data, and many requests for momentary data, but not a request for serious sustained data with the clearance to spend the time it would take to deliver that kind of result.

My database needs to be rebuilt and I would love to do it, but I am not sure that it is actually my job or that my boss would appreciate my using the time that way.

After all, what I’ve got is only smoking a little.

Pass the buck

November 26th, 2007

Shake those cobwebs out of your head and try to imagine this:

If we are pretty well sure that we shipped something and the customer says they didn’t get it, then we have to go beat up the trucking companies for compensation. Only we are too busy getting beat up by other customer who want us to (attempt) to ship them their orders.

Now, anything that’s worth doing is worth getting someone else to do. I was in one project that attempted to map out how we get an order from a customer and get paid for fulfilling it. . . the transaction went through so many hands, both inside the company and then to contracted agencies, that we never really did quite figure it all out. But I got a nice polo t-shirt.

So of course when Acme realized it was losing a lot of money because nobody was held responsible for MIA freight, it decided to: outsource the claims! Of course. We decided to use the Mafia collection company. (Fictional name.) But it turns out that Mafia does not bother with claims less than, oh, let’s just make up a number and say ten thousand dollars. Most claims are filed for a few items. The volume of claims is such that in total, Acme has a lot to lose in not pursuing the blame-the-trucker claims, but the individual claims almost all fall beneath Mafia’s radar.

Supposedly, Mafia passes along all small claims to the Shrill collection company. But persons in Acme contacting persons in Mafia get very disinterested replies to the smalls claims. Something on the order of, “Oh, you are holding your claim in your right hand. Try holding it in your left hand, and go to the back of the line, and when it’s your turn again we will see what we can do for you.”

Pop quiz, class! Does Shrill company return money to Acme? Do they care about our claims? Do they ever even see our claims? Does Shrill Inc. even truly exist?

The real problem here goes right back to that project I was in about how we get paid. Since nobody at the site of shipment tracks, tabulates, or ever–ever!–knows about the actual end-customer payment for a particular shipment, anything we say we shipped is income to our plant. It is presumed income. The sale has been made, the cash received, move on, move on, don’t stand around gawking!

If the shipment is outright returned, that’s a debit. But it’s kind of like throwing a fastball around a world–eventually it hits you in the back of the head, but you have no idea where it came from. Because usually returns are repackaged by the service center before they get to our plant, and they are always cleaned up of any and all shipment information and looking like ordinary product by the time we see them again at shipping.

But if the shipment is just MIA, someone else (I don’t know who) has to take the hit. Probably the same entity that takes the hit for claims that can’t be adequately answered by the shipping site, or that are valid but have been previously adjusted for by the shipping site (because claims can come in months–think even quarters–after the time of shipment, and we still entertain them).

Think about what this means for the factory. We say we shipped the product. Customer says he didn’t get it. Okay. Assuming we don’t tell the customer to get lost and never come back, than no matter what happens, we will still have to:

  1. Build more product
  2. Ship more product
  3. Get “paid” for shipping more product

If we just kind of do nothing and the customer gets sick of waiting and orders more, the above applies. If we graciously concede, the tools don’t magically come back so the above applies. If we go beat up the trucking company and get some money back, the above still applies. And those steps above are all anyone at the factory cares about.

Now, it takes time to investigate a shipment claim. I know. I’ve wasted enough time on it. In general, for what I in particular do, it takes the most time to investigate the claims worth the least amount of money. Checking if we shipped an entire pallet of product is easy. Checking to see if we shipped one tiny little bitty part (we have tens of thousands on hand)–well, that’s impossible but there are thing down there in that range that can be checked, with enough time.

Actually talking to someone on the phone so that you can complain that they didn’t perform a service they were already paid for–yep, that takes time, too. Lots of time. Nobody’s in a real hurry to return the calls that say, “You may already have lost a thousand dollars. Please call me back so I can bill you for it.”

Let’s pretend they do call back. Get ready with your conclusive evidence that they did not deliver the product (all 200 items of different kinds, mind you–nobody argues that they delivered 198 items, it’s the last two we’re arguing about). First at your disposal will be the delivery receipt, available online, which 95% of the time shows a signature from a customer employee along with the statement that the shipment was recieved in good order. Oh, wait. That might not help.

We had one claim for an entire pallet of missing product that was signed received in good order. The claim was from another branch of Acme! And they kept pestering us about it, too. We would say, “Uh, you signed for it. It weighed hundreds of pounds when it left. Go ask the guy who signed for it where it all is.” And a couple of weeks later they would ask if we had an answer yet.

It’s hard to blame the customer. Freight comes all bundeled up in mish-mashed heaps without good marking. Checking to see if it is all there would be like making the mail man wait on your doorstep until you read all of your mail. In the case of freight delivery, its actually possible to do. . .but it takes some really tough gumption.

Not to mention that the trucking companies have little disclaimers like “claim must be filed within one business day, per statute something or other, etc.” I might hear about a claim within 24 hours of the customer’s reciept. And maybe, if you take a really long shot, maybe I even determine that this problem was not our fault within the 24 hours. But there is no way that Mafia corp. begins pursuing the claim within 24 hours.

So, with that mountain to climb, how much do you think Mafia corp. has to be paid to make a profit chasing other people’s claims? I’m thinking that as soon as the trucking company hears that Mafia is not an actual customer of said trucking company, the rest of the claim just fades into the ethereal music of the spheres. . .nevermore to trouble the mind of a mortal.

Obviously, there must be a little more traction here than I imagine, or Mafia corp would not even exist. Still, it must take some effort. And that must cost some money. So out of what we actually even refer to Mafia–remember, that’s only the shipments where we don’t admit any wrongdoing and the customer doesn’t admit any wrongdoing–taking from those the claims that Mafia wins, within the value caps set by trucking companies for uninsured freight, cutting out a piece to pay Mafia corp with profit, how much money do you think returns to Acme?

I am not given to understand that this is unique to Acme. I am inclined to think it is pretty common for a global company–not necessarily any company with international orders, but probably any company that styles itself “global,” and tries to achive the upside-down pyramid of maximum cash flow with minimum overhead, so called.

Never fear. Mafia corp is disappointing, so we may well switch to some other claims handling company.

A parable

November 18th, 2007

Not much to say about the past week. I did keep up with the claims as they came in, and I spent Saturday dispatching the remaining backlog. But as the second (or third?) week of working overtime to quell the claims came to a close, my capacity to continue doing so waned. on Thursday and Friday I closed the log I was making of how I spend my work hours without ever having saved it. A couple of times I got very muddled trying to address a claim, and while they are almost always tricky, there was nothing that exceptionally tricky about those. I am not sure I can stay mentally effective for 10-hour days weeks on end.

The A-team, while certainly changing some portions of our operations, does not appear to be taking any kind of serious look at the underlying culture, or the root cause of why we were unable to change ourselves and they had to be sent in.

I’ll close with a parable, a true story but also an illustration. Probably any factory has a certain amount of airborne oils, but when you have older equipment, not designed for tidy operation and leaking at the seams to boot, there’s grime to go around. Although my actual workspace is in an office area, the compture will develop a visible layer of grime around its vents in a week or two, which I absentmindedly rub off with my finger. But the walls, the floors, basically every surface not touched simply accumulates grime.

The carpet gets the worst treatment. Early in the year we rearranged the furniture, and the places underneath the shelter of desks were shocking in their difference. Not that the carpet was never vacuumed–well, when I arrived I don’t know when it last was vacuumed. But I vacuumed it, I asked around why it wasn’t vacuumed by the janitorial contractors, and it has been vaccuumed on and off ever since. The besetting gray couldn’t be touched by a mere vaccum cleaner, though.

So I made mention of it, how filthy it was and how bad for morale, and how a carpet that filthy was not worth having. And I and fellow complainers were promised a new carpet. In January. Or February. Or March. Sometime in the first quarter of 2007, for sure.

Of course, no carpet actually ever was presented. So perhaps a month or two ago, some enterprising coworkers decided to rip out the old carpet, figuring nothing under it could be worse than the top. Underneath was a layer of glue, still tacky in some spots and worn to powder in others, a nasty yellow color. We shrugged our shoulders and said, “Yep, no worse than the carpet.”

But it did attract some more attention from outsiders, who seemed to think it actually was worse. More promises of carpet. More, “What, nobody got the carpet yet? I thought I asked so-and-so to take care of it.” Finally the manager, not technically the person designated for that level of renovating decision, called in some contractors, got some quotes, and ordered carpet.

I was there when the winning bidder said, “Please have all the stuff on the desks boxed so we can keep the stuff with the desks it belongs to.” So we did that, as asked.

We came in the next Monday and found a new carpet in the office and the office out on the shop floor. Not being a mover, I don’t know how they contrived to get those heavy desks out there, their boxed belongins, computers, and miscellany untouched. The doorway was barely wide enough to get the desks through–no knuckle allowance–and they were so heavy that ordinary dollys couldn’t maneuver them. I and one of the crew wound up hauling them through by hand, and it was about all I was up to.

Even when things were physically in place, it took a good while to sort out the cable connections. The office is a maze of discarded cables (I had three extra PC power cords and one extra phone AC/DC adapter when I was done), patched in wiring (a digital phone jack is literally just stitched into the side of a thick cable that truncates uselessly, and another thick cable sprouts from the wall with no termination whatsoever), dead cat-5 connections, and mislabeled jacks.

When the old carpet was torn up, we wondered if new carpet was really wise. But there are few kind of flooring cheaper than cheap carpeting, so when the manager had to chance a do-and-dare approach, he did not try for tile. I did mention to every contractor that we needed a fiber that would not trap the oil, but leave it free to be cleaned out.

By the time we had finished moving the furniture in, though, there were obvious grey-brown footprints over the blue carpet. When we had been asked, we choose a dark blue pattern mottled with tan and black. But that was offered by a contractor who didn’t win the bid. What we got was a somewhat lighter blue, and essentially a solid shade.

Once the desks were all back in I attempted to vacuum, but the footprints only got a little grudging lighter. The new-carpet fumes were going strong, though, so after heaving and hauling the office furniture over the new rug, staining it with grey footprints, and deducing my way through the perverse, inbred wiring, I got to go home with a headache from the fumes.

We finally got the new carpet we’d been asking for nigh on a year, and it was the most depressing day of the month.

Problems don't go away, they come back

November 11th, 2007

A while ago–a longer while than I realized–I outlined a plan to reduce shipping errors. At that time I promised to give updates and to stay focused on what I could control.

I’ve strayed from that worthy plan. It began to fall apart when the supervisor of the spare parts order pickers would not or could not have his people play their part, and check the stock counts. It continued to fall apart when I did not address the claims for tools which the supervisor of the tool order pickers had checked out. I would be busy all day and only notice them sitting there waiting to be addressed as I headed out the door at the end of the day.

The process crumbled a little more when P.B. did not review and print the claims. It fell apart completely when we had a plant-wide inventory, which reset our inventory accuracy and made it impossible to evaluate shipping errors by comparing a physical count to the current system count. Claims for shipments prior to the inventory needed to be evaluated by reviewing on the system adjustments made to the numbers. My area of expertise more than anyone else in the process.

Ironically, even as the process was falling apart, support and appreciation for it was growing among the workers. They have commented from time to time on its absence. It just goes to show why there is a need for managers, because a lot of people will initially resist an idea even if it is reasonably beneficial.

My great effort of overtime has only got me about half way through the backlog. This past week I pulled between an hour and two hours of overtime every day, but I was only dealing with the complaints that came in that day. And whatever other lose ends I was trying to tie up; but I kept those to a minimum. Sadly, to really deal honestly and completely with these claims, it takes time.

For instance, one claim where the customer said they had not received some items, I decided to first check the paperwork. When a customer says they did not receive an item at all, rather than the wrong item or the wrong quantity, often it has been overlooked by the picker and will be initialled as it should be; or it will have been missing at time of the pick, and will be zeroed off by myself or some other office staff, the person adjusting having forgotten to change the system.

In this case it was initialed and indicated proper shipment. So I went out to the assembly lines where the parts were and counted them, and found discrepancies not exactly in line with the claim. If I remember, rather than having extra parts (as we would if they had not actually been shipped), we had too few–although not in quantites exactly matching the complaint.

For some reason I decided to really go the extra mile and check in the spares packing area, where I found the parts, bagged, tagged, and ready to ship, but still in the plant.

That took a lot of time for a few measely parts. My pay for the time spent was almost certainly worth more than the parts. People have suggested that I shouldn’t spend so much time investigating the claims, just go with my first instinct and call it good enough. But the majority of the claims are cases where we at Acme have made a mistake. By waving off the individual problems as insignificant, we allow them to build up to a mass of mistakes that seriously affect our inventory accuracy (which directly relates to knowing what we are able to build) and our customer relations. I think it is worth multiplying the cost to the company of each misshipment, if it will help bring about corrections to the root problems.

But who’s to say my zealous investigation actually will lead to process improvements? I’ve already learned that it’s not wise to “teach them a lesson” by working overtime. When I’ve gone to my boss and tried to explain it, he has said, “Don’t try to do it all yourself. The other person (nominally) in customer service can help. The supervisor for tool orders can help. The highschool co-op can help. The manager of shipping and receiving can help.”

  1. The other person in customer service spends most of her time fixing the endless problems with international orders, and glitches with orders not processing through the system correctly.
  2. The supervisor of tool orders, while potentially the “right” person to investigate misshipment of tools, has to spend the majority of her time helping to ship orders, or they won’t all get done.
  3. The high-school co-op that we used to have, who graduated from highschool and was staying on, might have been able to help somewhat. i had asked for her help before, but her primary responsibility was helping the other customer service person with the order processing, and my work would often get sidelined or delayed. That could make it even harder for me to figure out what was going on when I did have time to work on it. Furthermore, all that anyone besides me is able to do is the basic fact-finding. Checking on the “third possibility,” finding the key piece of data the customer service center forgot to include, deciding on ambiguous cases, and writing the actual response come back to me. Recently I used my technological skills so that most of the routine data is autmatically found by the system. All that’s really left is the finer decision making, that needs to be done by a permanent employee of the company. And they got rid of our trained, competent, available co-op and brought in a new one with no clue and little available time. I’ve got her helping by getting weights for the tools so that we can check the weight of outgoing shipments (our computer system does have weights for most of the products, but the weight is often wrong).
  4. The manager–it would be nice if he could help, because he is an experienced professional, knowlegable and appreciative of the right way to approach matters but seasoned enough to adapt to present realities. But he has his hands full with things a manager should be taking care of–personnel issues, major departmental changes, implementation of corporate policies, and so on.

I’ve tried sharing out different pieces of the task, as outlined in the beginning of this post and in previous posts on the topic, but it’s difficult to find others with the ability and authorization to handle key parts of the process. Then finding people with the time to do it, and the inclination to do the job well, approaches impossible. I don’t supervise anyone, so I can’t set their priorities to ensure the claims get due attention, and I can’t do more than ask them to do the job to my high standards. Like me, they are genuinely busy and have to deal with requests and prioritizations from people in the plant with a lot more authority than I’ve got.

Most of all, I’ve found that when you try to share out a process like this, even among well-meaning and cooperative people, if there isn’t a central authority comitted to seeing the process work well, it becomes a disorganized chain of work-in-process with no coordination, no clear communication, and hopeless delays. When I do it myself, I clearly understand what the facts are, I’ve followed up if there were any unusual symptoms in the claim, I’ve filled in whatever gaps were present in the claim, and even when I have not checked all the details I have a balanced sense of what details were overlooked and whether it is reasonable, considering the import of the claim.

“I have to do it myself to do it right” is a tell-tale of poor management. But, again, I don’t manage anyone. The person who manages me, and also has authority over all the people who might be able to assist in the process, uses the opposite motto and simply says, “Get somebody to do it.” Ultimately that’s not better management. Real awareness of the work, what it involves and how people are currently dealing with it, has to proceed delegation and the discipline or oversight thereafter.

How can I find my way out of this paradox? I doubt that I really will. For most of this past week I have been keeping a spreadsheet of how I spend my time. Detailing how time is actually spent is considered beneath salaried people, but I am doing it anyway. A motto on my boss’s wall says, “In God I trust; everyone else, bring data.” Hopefully this kind of log will give me more credibility when I say there is too much work for me to handle. There’s really no defense for “Somebody else can do some of that,” devoid of any real understanding of what people are doing. But I can explain how many of the tasks on the list I am either the only person who can accomplish, or in the best position under the circumstances.

The amount of overtime it is taking me to keep up with the current claims is not so excessive. It is comparable to the amount of time it used to take me commuting to and from work. If I decide that I do not want to be doing constant overtime, or if I am told to stop, I can look at this log and decide what will be eliminated.

For this first week, I can say that it’s a relief to know that these claims are not backlogged, waiting, building up customer irritation and a towering backlog (I still have the balance of the backlog I had let build up). And it is hard for me or anyone to count inventory to check a claim while the inventory is being used, so it the claims can be more accurately assesed during odd hours. But if I ever do want my full evening, something will have to give.

Duh

November 2nd, 2007

I sort of forgot I was enrolled in an on-line class. It is beneath my level in the subject matter and boring. But I should still finish the assignments so I can put it down as complete.

On the job training/learning is so much better. But if they are only training you in doing things the wrong way, is it really any better?

Way too much overtime this week, on top of a cold. Well, it will be way too much overtime after tomorrow. Bleh. But that procedure for logging and reducing shipping claims that I talked about has gone untended for over a month. I really have to get some answers back to the customer service center.

Not sure why I really have to. They can’t fire me. They don’t have much sway with my boss. But they are decent folks trying to do their jobs, which they can’t complete without my participation… and they represent the customer. All cheese aside, that should count for something.

I still don’t feel like working all day tomorrow, though.

Treat and Trick

October 31st, 2007

Forgive the title. I know I shouldn’t be making easy, thoughtless puns on crass holidays, but judge for yourself when you have read.

At the end of every month we are substantially shy of our shipping quota, and at the end of every month the shipping manager asks for any available help from the rest of the plant. Perhaps one time in six we actually see people in response to our requests.

Today, looking at how far we had to go to reach the quota, and what our rate of shipments had been the previous day, I noted in a report on our status toward goal that we would not make it without additional help. I expected to see few if any people come down to help. I also did not think we would really need any help, inasmuch as it seemed to me that the majority of shippable orders were shipped. I figured product completed today our normal crew could handle. About noon I thought we were surely going to run out of orders. And midway through the afternoon, when we really were just about to run out and have to send all our unexpected help away, orders came pouring in.

This was a result of the assembly areas finishing off their work, and sending it to us late in the day.

Originally the shipping manager said we would work 10 hours, starting at 6am and leaving at 5pm so employees with kids could enjoy Halloween. About half the crew came in at 5 am (myself at 5:30) because of the work we had outstanding from the end of work on Tuesday. There we were, late in the afternoon, surrounding by people who had been rousted from their normal jobs to help us. Several members of plant staff were there. We had an abundance of orders to process.

The problem is that our shipping area is not meant to handle a much larger crew than we usually run. Two or three extra people we can accomodate. But the more extra people, the more specialized the skills really need to be. Can you run the shipping terminal? Can you operate a forktruck? Can you operate the stretch wrapper? Can you even pick tools without making serious errors, and will the person who is packing your order know enough to catch your mistake?

What began as a sane day, just us shipping folk shipping out what we could for the end of the month, turned into a madhouse of shippable product, clueless help, and management scrutiny. I was the last to leave (because I had to send of the final report) at 7 pm. Most of our crew 15-30 minutes earlier.

And the production manager had the chutzpah to ask me why were going to be able to ship all of the orders (that had dropped late in the day), and why we weren’t changing our process to accomodate the last-minute production that happens every month. Talk about backwards! Why isn’t production fixing their issues so we can ship at a sane pace all month long?

So we had an unexpected treat in all the extra help. But it had a fishook inside of it.

Holiday cheer

October 28th, 2007

Instead of the Scary Guy coming back and telling us who’s been naughty and who’s been nice, we are now going to host a newly-formed Acme A-Team. The team will be in our plant starting November till just before Christmas. Officially they are here to jump start our transformation to a modern, Lean factory. Unofficially, they are taking names. Woe to those who do not find favor in the eyes of the Lean team.

These kinds of teams are not unique to Acme by any means. People who now work for Acme have seen, or even been on, such teams operating in other companys. They have seen these teams identify who is hindering progress and who is helping. They have seen the hinderances fired, without warning. They have seen factories truly transformed into more profitable, more efficient, more effective facilities.

I am trying not to let my hopes get up. I can imagine Acme, with its demonstrated level of competence at executing good theory, brining in an A-Team that will fire the wrong people, or slap some hands and let be, or spend the better part of two months constructing grand theories of how things ought to be done right, but not enforcing any of these ideas, so that once again we are abused with a perverse form of a good idea.

But the amount of time they will be in the factory gives me some hope. Can they really spend a month and half in our plant without noticing certain patterns? Can the sycophants really ply their art so long? It’s hard to imagine that high-paid people could waste nearly two months in a place without making a real difference. Maybe they’ll just say that we’re all hopeless and shut the plant down.

I would hope the A-Team notices and deals with events such as this week’s assasination attempt on P.B. To remind you, P.B. is in charge of all material handling, including receving and shipping. Technically he and I work for the same person, the supply chain manager; for the most part, you could say that I work for P.B. At any rate, I think we work well together.

To continue setting the stage, let me also reprise the role of a planner. A planner does not directly oversee the purchasing of parts or materials, nor does a planner directly oversee the application of labor to develop the components into the product. Basically, a planner’s job is to be aware of all the complications, constraints, and problems arising in the areas of supply, demand, and capacity, and manage them to produce the most effective production schedule possible.

Unfortunately in our plant, people (inclusive of the planners but also the production force) are much given to the habit of gaming the system, for instance by printing out paperwork requesting material be moved before it is ready to be moved–to have parts moved from stock to assembly when assembly is not ready to build, or from machining to stock when the parts are not done being machined. Then they sit on the papework until such time as the parts are ready, whereupon they produce the paperwork and complain at the next available opportunity that P.B.’s people aren’t moving the material in a timely manner, and that the paperwork has been sitting around unfulfilled for days.

This kind of basic dishonesty is almost an acknowledged fact. I say “almost” because nobody stands up and says, “I know you all are doing this and, hey–just keep doing it, I don’t care.” Rather you will get wry looks and behind-closed-doors admissions. But the people who ought to say, “I am your boss and if you lie to me I will fire you,” haven’t.

So on one fine morning this week, at our daily finger-pointing blame-shifting meeting, one of the planners says to the collected bunch that he could be building those tools which are so needed, so past-due, if only the material were pulled. Given that we have a 100% Effort project on to reduce that backlog, says this planner, why can’t P.B. pony up and get him the material he needs?

On this particular morning, by the way, the plant manager is in attendence. Usually he is not, and so he misses a lot of the profanity and degredation that goes on there.

P.B. does not argue the details. He happens to check every night and see if there is a backlog of work his people were supposed to do, but he does not mention this. He says only that he has put as much manpower as he can afford to toward helping that line. The planner insists, reiterating that given what a priority this is for the whole plant, P.B. ought to be doing more to help. Can’t give you more help without hurting someone else, says P.B. Take from someone who is lower priority and give to me, says the planner. Someone will have to tell me who the lower priority is, says P.B. So the planner turns to the master planner, P.B.’s nemisis you might say, and says, “Can you please help him figure out his priorities?”

Now after the meeting is officially over, P.B. has a little talk with the planner and explains that there wasn’t any work last night, so if the planner has a sudden crisis it would be much more polite and professional to speak with him about it personally, rather than presenting to everyone as if P.B. is willfully negligent.

Then, after that, P.B. went around and found out that of the 22 orders the planner said were waiting to be pulled from stock, 0 were ready to go. Yes, for every single order there was at least one part which had insufficient stock or a quality problem. P.B. checked with the area leader in the stockroom and at the assembly line. According to them there was no problem and had been no problem.

Next thing you know the plant manager was calling P.B. on the carpet for his uncooperative attitude, and P.B. had to explain to him all those pesky details.

If nobody else can take note of such unethical and unhelpful behaviour, and do something about it, perhaps the A-Team can. We shall see. But it may be a long two months.

Abbreviation of fatigue

October 21st, 2007

I have been getting more requests from more people for different reports–which orders absolutely must ship today, which important customers are about to get really upset with our performance, other things of that nature. I’ve told everyone that it reminds me of getting the women and children off the Titanic. In other words, triage implies disaster.

The effort to improve response on customer claims has fallen almost completely apart. Mentally I have advanced what could be done; I’ve found more ways to semi-automatically gather more data. But turning theory into reality has been interrupted, largely by above requests for reports.

i don’t feel like thinking any more about it. Plus the details get steadily more personal and more incriminiating and i don’t know how far down that road I want to go on a public blog.

Forecast, Supply, Demand, Recriminate

October 14th, 2007

Some of our products are made exclusively for certain high-profile customers. In these kinds of arrangements, the customers are expected to forecast ahead of time what quantity of product they will need. The forecast does not have to be precise down the the last unit, but it does have to be in the right range by a hundred or so, because it can take a long time for all the necessary components to make their way from Russia, China, India, Korea, England, and Mars.

If the customer sells far more tools than anticipated, they will ask us why we are not sending them more product and what is taking so long. We will try to find a polite way to tell them that parts are harder to make than promises. If the customer does not go over the forecast and we are still unable to deliver the planned quantity for some reason–a quality issue, let’s say–than the customer will want to know what’s going on and why they shouldn’t order the next lot from our competitor. We will try to find a convincing way to tell them it will never happen again and to make up for it without making another committment that maybe we won’t be able to keep.

If both of these things have happened with regard to the same customer, only different products, then when the sales people who get paid for making promises talk to the production people who get paid for making tools–but not too many unneeded tools–then the marketing people will ask why we did not meet their unrealistic promises, and we will ask why they made promises that broke the rules for what we could keep, and then they will ask how they are supposed to make promises we can keep if we are aren’t going to keep the promise they made that did follow the rules. And the marketing people will suggest that we get closer, more reliable sources for our parts, and we will say we’d love to do that but we’d all get fired for choosing the higher-cost provider, and then the marketing people will say that’s fine we’ll just lose the customer. And people will use naughty words.

And then the people in charge of getting the components in here on time will ask me to put together reports showing how naughty the sales people were in placing and changing orders, and also on how bad we really did measured by the official and agreed standards versus the arbitrary sales promises. Also the people who are responsible for building the tools once the parts are available will point out and emphasize all the times when the tools were built but did not get shipped, so the plant manager will ask me to put together a report showing the specific reason why each item did not ship and also to fix the problems while I am at it. Most of those reasons will wind up being rules that people in another part of the business made about what days we can ship to what foreign countries and whether we can ship part of the order or must ship the whole thing at once, but none of that seems very relevant to the production people who just want to ship the hot potatoe.

Then I will tell everyone that I can make a report that will tell them anything about any order at any time, only it will take several days to complete. And my boss will say, “Good, have it done by lunch. Just kidding.” And I will wonder if he has any idea what size kid that is. And I will go back to my desk and there will be a message from one person wanting me to cancel an order that is in the process of shipping and a message from another person wanting me to ship an order today, urgently, for an important customer. Also there will be many more things like that so that at the end of the day, or rather half an hour after the end of my shift, when I am shutting down open programs, I will come across one and say “What is this?” And then I will remember, “Oh yes, that is the report I was supposed to finish before lunch. Well, tomorrow I will really concentrate on it.”