Karen Phelan - I'm Sorry I broke Your Company

It was on a large transformation engagement where I had my worst consulting experience ever. We had teams of people working at numerous sites to improve the manufacturing and supply chain at a textile manufacturer. Because of the size of the engagement and the promised quick turnaround, each functional area of the supply chain was It's own project. Instead of an end-to-end process, we would have to fit the pieces together. I was assigned to a small plant on my own where my task was to reengineer the scheduling function. The situation was very similar to my first client experience — the factory was unable to fill It's orders on a timely basis and had lots of angry customers. When the plant was built, the industry had much more demand than supply, and this plant took all the rejected spools of thread from the other sites and respooled the product onto much larger spools that fit on weaving machines. This way the plant could sell initially rejected product to get more revenues. However, the nature of the industry had changed, and the plant was now making lots of customized spools with different sizes, thread counts, and so on. In short, over the years, the product line had become very complex. An initial consulting assessment had promised a vast increase in machine uptime and hence significantly larger throughput. Instead of expensive software to solve the plants problems, we were offering process reengineering.

Left to my own devices, I did what I usually do — I toured the facility and interviewed the employees. The problem was pretty obvious. There were about twenty huge spooling machines. On one end, a worker placed about a hundred small spools of thread on spindles and then manually threaded the machine that wound the thread onto the big spools. It often took days for a worker to thread one machine, and some of the runs lasted only a few hours. Many of the machines were idle because they were being threaded or because they had a complicated setup and were waiting for an order with that particular setup. To make matters worse, because the plant was built to repurpose rejected spools, many of the spools of raw material were only partial, and the workers were continually shutting the machines down to restring new thread. To say this was a labor-intensive operation is a huge understatement.

Like the refrigerator manufacturer, this client had sophisticated scheduling software, but It's customers frequently changed their orders. The customers served fashion houses, which reserved the right to change their orders on a whim because that’s just how the fashion business is. Demand changes rapidly. Ideally, the client wanted customers to send their orders in monthly so that the schedulers could enter the orders into the software to create an optimized monthly schedule. The schedulers were constantly trying to protect the monthly schedule, while their customers were constantly trying to change it to meet changing demand. This meant the machines were constantly down. At the other sites, where chemicals were poured in one end and thread came out the other, improving maintenance and machine schedules would improve the uptime; however, this was not the case here. The problem was much bigger. It wasn’t the process that was broken; it was the business model. When the plant was built and the product was more expensive, the labor costs were much lower, and only a few types of spools were sold. It made sense to retool the rejected spools into something sellable. In the current world, where the product was more widely available and the margins were much lower, it made little sense. Now every spool cost more to make than it was sold for. Gemini had promised that we could lower the plant’s manufacturing costs by increasing It's uptime as if it were a process plant like all the others.

As soon as I understood that improving the scheduling algorithm would have little impact, I called the project manager to tell him the situation. Getting the schedulers and workers together to work on «As Is» brown papers didn't seem to have much point. The plant had a small staff who were well aware of the problems but were powerless to address them. The problem was with the relationships with the customers — mainly one customer who was responsible for at least half the orders and most of the changes, so we decided that we would visit the customer. I organized a daylong meeting where teams from the client and the customer could start to address the problem together. People from both companies took turns discussing their problems and, in a nonthreatening way, their frustrations with each other. We spent the morning venting and getting to know each other on a professional level. We ate lunch together and started to learn about each other on a personal level. During the lunch, the customer team admitted that sometimes they ordered more than they needed to ensure that they would get enough product. At first, my client was furious that they were trying to optimize phony orders. I chimed in that I'd seen this practice at other companies, and others in the room admitted that this was common. This little confession set the tone for very candid communications.

In the afternoon, I led the teams through a structured brainstorming session, where we developed lots of ideas on how to work together better. After fully immersing ourselves in each others' problems, we tried to generate ideas that would help both companies. At the end of the day, we left with a list of possible solutions and actions to find out how we could make them work. One of the suggestions was to let the customer schedule some of the machines and take responsibility for determining which orders to fill first, and another was to provide spooling as a service rather than as a product, where the plant would sell the customer the time and labor involved. Then it wouldn't have to struggle to optimize throughput. We walked away from the meeting with a new understanding and some hope for finding a way to work together better. I was very pleased that we had moved beyond the «blame game» and now had the beginnings of a fruitful relationship.

When I returned to the plant, the project manager had been reassigned, and a whole new consulting team was now working there. Apparently, my alert that I would probably not deliver the promised benefits set a whole chain of events in motion. It was deemed that the challenge was too much for one consultant, and an entire team who had worked at another site was brought in. At this time, Gemini was starting to standardize It's service offering and It's methodologies. This team had brought tools and solutions from the other sites, and they were going to use them to do a full diagnostic and repair. The first thing that my new manager asked to see was my documentation for the As Is scheduling process. I explained the situation and that I really didn't see the point in documenting the current scheduling process. He was quite furious with me for going way out of scope and for not following our standardized process. That was why I couldn't find the benefits. I was directed to immediately stop what I was doing and to create the process flowchart. A little at a loss because I was unable to explain the real problems at the plant, I embarked on the As Is process, which consisted of about four steps: send orders-due reminders to customers, input the orders into state-of-the-art scheduling software at month-end, print an optimized monthly schedule and send it to the floor supervisors, and revise the schedule as new orders arrive. The last step had a loop back into the previous one.

When I showed this to the manager, he was again furious. What kind of documentation was this? Clearly, I was incompetent. He asked another consultant to show me what a scheduling brown paper was supposed to look like and to show me the tools I needed to use to develop the new process. The problem was, these tools and solutions were for simple process plants that had only a few products. This manager had yet to tour the plant or talk with the employees, but already he had the solutions because they had been successful at other plants. I was incredulous at his insistence that if I did the documentation correctly, the problems would be solved. When I was equally as insistent that these tools wouldn't work, I was asked to leave the project. Normally, this is a consulting career ender, but I already had some other successes under my belt, so I was given another chance. I switched from supply-chain processes to new product development, where I had more leeway to use my judgment. Eventually, it became well-known that that project was a disaster, and the partner who ran it was let go a year later. The manufacturer never realized the promised benefits at that facility, and it was eventually sold. (Are you sensing a trend?)