Supply Management Policies and How to Manage Them

Supply Management Policies and How to Manage Them

Going forward I plan to occasionally use this blog as a vehicle for sharing professional experiences that hopefully shed light on how to operate in a Next Generation Supply Management world. I understand that experience is usually the best teacher. Hopefully, though, reading about other’s experiences can provide you with enough schooling that you will get “advanced placement” credit from the school-of-hard-knocks.

Today’s story deals with policies and their administration. Policies are written to provide guidelines of practice. Specifically, they define pre-determined sets of behavior for addressing scenarios that will likely occur during the normal course of doing business. The best ones are based on market needs and pass the “smell” test, i.e., they make sense. In addition to providing guidance, however, they also function as a vital means of communication between functional areas—such as design and supply management—and between organizations, i.e., customers and their suppliers.

One factory I worked at had a product change policy that defined timing guidelines for implementing design changes based on the level of manufacturing “stress.” Seasonality in demand was a big issue for this company with up to two-thirds of its annual sales occurring over only a quarter of the calendar year. Consequently, there were times of very high production—where manufacturing stress was rampant—as well as times where production was either very low or was, in fact, stopped, i.e., little or no stress.

During a period of high manufacturing stress the slightest production “hiccup” is magnified, and such hiccups tend to occur more frequently during periods of extreme product flow through a factory. Consequently, business risk associated with design changes varies greatly whether a factory is experiencing peak production or not. This is where a policy can play an important role. The product change policy at the factory being discussed provided (among others) the following guidelines:

  • Design changes required to address safety issues would be implemented immediately.
  • Design changes that would significantly increase customer perceived value would be implemented as soon as practically possible, with the term “practically” assuming common sense.
  • All other design changes would be made during a non-peak production period.

The first two guidelines were self-evident. The third usually applied to changes related to reducing cost and intended to avoid the higher risk of quality problems and/or productivity loss during a period of time when both our manufacturing facility and the manufacturing facilities of our supporting suppliers were under their highest periods of productive stress.

During one such peak production period I received a design change request on a purchased part. Since the change was not related to product safety or improved function, I rejected the request for immediate implementation, instead scheduling it for an upcoming production lull period. This was an organization in which supply management reported up through product engineering, and the next morning their top guy (my boss’s boss) stepped into my office and closed the door—generally not a good omen.

He asked me why I was delaying implementation of a design change originating from his department. I cited the product change policy. He replied that the change would yield about 13 cents savings per part; that over the next six-week peak production period over 100,000 units would be produced; and that as an executive of the company I needed to have more of a concern for company profitability. I explained about the high risk of production related problems over the next six weeks and that, if they occurred, the costs associated with them could significantly outweigh a $13,000 cost reduction—this was an explanation he didn’t want to hear. As he walked out of my office his last words to me were “Just manage it, and if you don’t think you can I’ll find someone (for your job) who can!” I got the message and approved the immediate implementation of the design change!

My next step was to “just manage it” so I called the part’s supplier to both give them a heads-up on what was coming and ask if there was anything I could to do help them mediate the manufacturing risk. His reply was along the following lines:

  • Their normal operation was a five-day, two-shift week.
  • To support our production peaks they ramped up to a seven-day, three-shift schedule with the extra manpower brought in through temporary employment agencies.

Because the change was to be implemented with virtually no opportunity to prepare the employees for the change—and remember, many were very inexperienced—he felt that successful implementation of the change during this high stress period would require intensive supervisory oversight, something his company would be hard-pressed to provide. He asked if we could send in supplier development engineers to assist supervising production during the “off shifts”—those with the most temporary employees—which I agreed to do.

The out-of-pocket costs of providing this supplier development support were approximately $20,000 for things like airline tickets, car rentals and lodging. This figure didn’t include salary and benefits or account for delaying the implementation of cost reductions on the projects these personnel had been working on which they were pulled off of to man this assignment. So, with these thrown in, the cost to “manage” the immediate implementation of the design change—remember, it was for a $13,000 savings—was probably more in the $50,000 range.

By the way, the supplier development support was, in fact, needed and effective since through our supervisory oversight we headed off several what would have been significant production foul-ups related to bringing the revised design into production.

Being naturally curious, I did a little nosing around afterward to try to figure out “the rest of the story.” Our peak production period coincided with the end of a financial quarter. Product engineering had quarterly cost reduction goals that figured prominently in evaluation of their performance. The $13,000 savings—because it was implemented during that peak production period—allowed them to achieve their quarterly goal in that area. So in the end it appeared that the main reason the design change policy guideline was “broken” was so that an individual department could look good on one of their performance metrics. Yikes!

Go back to my first blog entry—“Management by the Numbers”—and you’ll understand that this is a prime example of a performance goal that led to a non-optimal business result. In addition to being a bad overall move for the business, it was a bad move for supply management since the expenses and delayed savings that supported the $13,000 benefit came out of my budget, not product engineering’s!

So, what are the “hard knocks” lessons here?

  • Properly crafted policies can be important in guiding activity. Deviating from a policy should require visible, financial justification, i.e., it should pass the “smell test.”
  • Performance metrics—particularly those related to savings—really need to be cross-functionally balanced or they run the risk of driving sub-optimal results or causing competition between functional areas for the same savings dollars.
  • Executives aren’t above putting their personal and/or department needs above company benefit (as if anyone really doubted that in the first place).

The last lesson here—at least for me—was that when I later progressed up the ladder I can truthfully say that I tried to never put myself or department ahead of the company, nor did I let my peers do so without at least having the issue given executive level visibility, which usually led to rational decisions being made.

The next blog will build on this entry by elaborating on the role of policies as a management and communication tool.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish