The Process Imperative

[From iSource Business, October/November 2002] If you think your supply chain processes aren't broken, Mike Duciewicz says you haven't looked at them hard enough.

Mike Duciewicz has the deceptively prosaic title of vice president of the Business Systems Management Unit at Ricoh Corp., the $2.7 billion North American subsidiary of Tokyo-based office equipment and electronics manufacturer Ricoh Co., Ltd. But Duciewicz, who works at Ricoh Corp.'s headquarters in West Caldwell, N.J., has a broad purview, overseeing everything from customer support, distribution and purchasing to operational planning, inventory planning and forecasting. On top of that, he's also heading up the Americas component of Ricoh Co.'s global supply chain project.

Ricoh Corp.'s recent supply chain efforts have focused first on improving its demand planning and forecasting capabilities; second, reducing lead times for the products it orders from the company's manufacturing unit; and third, sharing greater amounts of information with other Ricoh subsidiaries and customers/partners to ensure the most efficient use of assets among the company's various units. With all these projects ongoing, Duciewicz, a 21-year veteran of Ricoh, with eight prior years of experience at United Parcel Service, clearly has his hands full, but he recently took time out to speak with iSource Business about what he views as the three most important components of any supply chain initiative: process, process, process.

iSource: What has been Ricoh's approach in applying technology to make its supply chain more efficient?

Duciewicz: Jumping right into technology is the wrong approach to take. First you need to understand your current processes to understand why you do those processes the way that you do. Then you can identify what we call "dependent events" jobs that have to be done first before a process moves to another task. The more dependent events you have, the more delays or bottlenecks that could occur, so you identify where the bottlenecks are and concentrate on eliminating them.

But a lot of people want to apply technology right away, without having eliminated any dependent events. In that case, you're really implementing a system based on your current processes, which could be inefficient. People must realize that software is nothing but process. Comparing the current process to the process you require and then to the software process is a major key in evaluating and implementing any type of system.

At Ricoh, we first concentrated on demand planning and forecasting. We found that there is normal demand, which is stable, and exceptional demand, which includes one-time occurrences, like when you win a deal for 700 machines with a major account, or promotions, new product introductions and end-of-life products. Because of exceptional demand, any kind of automated projection that you could use would potentially produce skewed numbers. So we had to come up with a forecasting process that would utilize our normal demand but also compensate for exceptional demand.

Next we looked at reducing lead time. Two years ago we began testing modular assembly. Let's say you have a family type of a product, with Product A and Product B. Since only certain parts distinguish Product A from Product B, we decided that instead of assembling the products overseas we would bring component-level parts into the United States and then give manufacturing a one-week notice for how many of which product we want. So we're really postponing the decision as to what product we want built until the last feasible moment. That has been extremely successful for us.

The other thing that we have done is come out with standard configurations, and now we are working with customized configurations, where if a customer wants the standard configuration plus two accessories put on, we'll do that through a configuration center.

iSource: Has moving toward these new models actually made your processes more complex?