We Have Met the Customer, and He is Us
This is going to get technical, and also not make much sense. Proceed with caution.
One of the first things I had the privilege of working on when I came to the shipping department was intra-company orders. In a very small way I helped make this an issue that our plant needed to deal with. In the preceding autumn we had gone through a campaign to improve our delivery to our original promise date, for which I helped provide the critical data. The campaign was successful enough that other sites in our area, such as regional distribution center, wanted to know what we had done. Ultimately they found their own way to improve and did so even better than we had, to the point that one of their major complaints was sales orders they could not ship because they were waiting for products from our site.
So they came to us saying “You have to ship intra-company orders faster, our customer is waiting on you.” I started looking at the process of shipping intra-company orders and found that, unlike normal sales orders, intra-company orders did not automatically allocate available stock and did not automatically “drop” (that is, print out) for picking and shipping. Instead, the basic process required human intervention to hook individual requests into a shipment and drop the shipment for pick.
Since this cumbersome process was insufficient to meet the volume of requests from the regional distribution center, a special add-on to the system had been created that automatically hooked the requests to a shipment number and then dropped the shipment for pick–but not on the standard picking paperwork. Instead, they printed on “cards” (printer paper that tears into thirds), which the pickers would use to pull the inventory. Unlike the usual pick paperwork, when these cards were printed inventory did not actually allocate to the orders. In other words, while the pickers were physically picking the inventory and packaging it for shipment, the system could be allocating the same parts to be assembled into tools, or shipped on customer orders.
After the pickers were through, a clerk would review what they had picked, adjust the order, and then drop the usual pick paperwork, which was then shipped out with the product without further ado. This “standard” paperwork never matched the actual shipment, because the system had been allocating the inventory while the pickers were at work. When it comes to that, the computer system used here is very poor at tracking inventory anyway. We use inventory faster than we charge it off, we allocate more inventory than we actually have, and, in a particular conjunction of the preceeding, on two specific classes of inventory we are perpetually out of synch because it is accounted for in a special cost-saving way that encourages us to keep as little inventory in our system as possible–which by itself is great, but when your system is not keeping up in real time with what is happening to the inventory, it means that the system can never account for where things are at until we bring the factory to a standstill once a year to do an accounting.
Hence in the shipping department we are very frequently making changes to the inventory picture to allow orders to ship, since the inventory is no longer where it was when the system allocated it to the order. But that is just for the ordinary sales orders that allocate and drop automatically. It is always worse with the intra-company orders, which S. B., one of my compatriots in shipping, always has to correct. The paperwork S. B. deals with is the “standard” pick, dropped after the “card drop”, and it does actually allocate the inventory, but since unlike regular sales orders the intra-company orders to not charge off the inventory when they are run through the shipping software, S. B. must manually issue them. The odious nature of this task is enriched by the fact that, if you will recall, this “standard” picking paperwork doesn’t even reflect what is actually shipping, since not all of it seemed to be available to the system at the time when it actually allocated to the intra-company order (as opposed to the “card drop” that may have been run days earlier). No, the order is not fully shipped until the clerk who adjusted the shipping order to match–well, more closely resemble–the card drop goes back after the fact and cleans up any remaining discrepancies. It is quite possible for the distribution center to receive product before it has been completely processed to show shipping out of our factory.
The items the distribution center wants are the same items that the assembly area wants to build tools and that are being ordered directly by the customer (on sales orders that do automatically allocate and drop). All this competing demand, poorly managed by the plant software, means that orders frequently have to be “shorted” because inventory the system thought was available in fact was not. The process requires several more steps than it should just for sales orders, but intra-company orders are even more finicky; and that is one of the reasons for using the “card drop,” because then the adjustments are about where the inventory is, not whether there is any (those issues having been addressed by the clerk who cleaned up after the card drop).
When we first looked at this process in the first quarter of the year, I concluded that the card drop needed to group fewer requests to a shipping order than the current 200 requests per order, so that the orders did not take so long to pick and left the factory sooner, and that they should be hooked up by date order rather than alphabetical order, and that they should allocate when they were dropped for pick. This was all discussed, but we took care of the immediate problem by putting more manpower into delivering intra-company orders. Meanwhile, the service by the same personnel to supply the assembly lines and the sales orders suffered.
None of the changes I identified were made, because they involved changes to the system. That requires a system change request, which apparently are put into glass bottles and thrown into the sea to go to India.
In the time between then and now, some small things were done to try to help the situation. First, the report I created last fall to show show unfilled customer orders due to our original commitment (something you would have thought our official software could readily provide, but no) was expanded to also show the intra-company demand. This was not a trivial change, since the information on intra-company orders is stored in different tables and has only a similar, not identical, set of data; but I did it so that if I was asked why we weren’t shipping something and I said we had none to ship, I could also say with good cause that the production planners were aware of the need for the parts.
Second, directly after the lay-off-the-temps scare, we were given a set of college interns to help in our department, and two of them were assigned to help with the intra-company orders. One has been dropping smaller orders on the standard paperwork, by due date, and one has been picking those orders. Generally this has been and improvement, except that the intern is using a report of mine that actually takes into account the system allocation before hooking orders, so where previously we had been blithely picking and shipping the product that the system, on the whole, would not have thought we could ship, now we have not been.
But this has not been enough. When it was announced that there would be a multi-site team effort to improve the delivery between our factory and the distribution center, a manager about four or five levels down from the top of the international company volunteered to be on the team. He and a bunch of people from the distribution center came to our factory to help us figure out how to do our job.
The first and most disconcerting thing we learned was that the distribution center was measuring our performance based on how many customer orders they could not fill because of us. While this simple measurement was admirably customer-focused, it did not give us any indication of what we could control or improve. On top of that, the intra-company requests, if left to themselves, are always planned from the current date–if they are not filled when first intended to be, they simply bump forward. This can be curtailed by “firming” the request, which makes its due date permanent. However, the requests from the distribution center are based not only on actual customer orders, but also anticipated customer orders and the current stock level in the distribution center. Unexpectedly run out of stock in the distribution center, and the request to our site is increased. Do not receive all the anticipated customer orders, and the request to our site is decreased. By the time we are ready to ship the product, in other words, the distribution center may need more or less than the original request.
Worst of all, one of the most vocal representatives wanted to dispense with the firming of the intersites (so that her staff would not have to adjust them) and let the orders continuously and dynamically change until such time as we dropped the order for pick. It would then be impossible for us to say how long we had been aware of a need in the distribution center, as the date would constantly bump forward, and impossible to know how much and what product we would really have to ship ahead of time.
The planning manager at our site actually liked this idea, as he would not have to deal with numerous trivial past-due intra-company orders, but could ship one nice big one whenever he was ready. I opposed it because it left us without any responsibility–completely liable for blame if we were late, completely without meaningful proof if we had peformed well. In the end a compromise was reached, wherein at least the items shipping is directly responsible for will be given fixed dates.
Other than that, we mainly concluded that the intersites should be dropped a few at a time, in date order, allocating at the time of drop. Exactly what I had already figured out. However, neither the fourth-level manager nor the regional IT representative had anything encouraging to say about the chance of the system change request getting completed; apparently the people who actually make the changes are responsible to almost nobody. Without a doubt, the few people permitted to make changes have more work than they can handle; but in this case the “customer” is us, the sites generating saleable product, and their responsibility to the “customer” approaches zero.
We did also try to set up another “exception” process, whereby those items which are on the factory property but owned by the supplier until we pull them out for use–items constantly showing fewer in the system than actually, practically available–will be moved into yet another metaphorical inventory location that exists for the purpose of enabling the system to deal with it. This process may just need time to work out the kinks, but it is not off to a good start.
About all that was really gained, then, was those folks from the distribution center remarking, “I never knew how hard it was for you guys to ship product too us. I’ll never complain again.”
The last, of course, cannot be taken seriously, but it was gratifying to hear.