[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?
Duciewicz: No, not really. We have taken a process and broken it into fewer tasks, but more entities are performing the tasks. You just have to make sure that all those entities are in unison. The key there is proper communication and proper visibility to data.
iSource: Have you put in a place a technology backbone to support your new processes?
Duciewicz: Up until now we have been putting processes in place utilizing existing systems. Now, knowing that our test pilots have worked successfully, we are developing our own technology.
iSource: In-house?
Duciewicz: In-house.
iSource: Did you make a conscious decision within Ricoh to build your systems internally, or did it just evolve that way?
Duciewicz: There are certain areas and functions within the company where packaged programs can work well Finance and Human Resources come to mind, depending on the current processes versus the processes required. But when you start getting into inventory, you have to take a look at your business. Some inventory packages offer 39 or 40 different formulas based on a condition. Well maybe my business is not that complex, so why should I buy a high-level package that is going to offer me more than I'm ever going to use? We understand our business, we understand the business conditions, and when we develop our own systems we have the flexibility of changing them as the business begins to grow or market conditions change.
iSource: When you look at changing a process, are you examining that issue from a cross-functional perspective?
Duciewicz: You have to, otherwise it's suicide. It is very, very rare that a process takes place within one department or one division. A process is made up of tasks. Tasks can be carried out by other departments or other divisions. So you better understand not only your tasks but everybody else's tasks, too.
And then, when you look at a process, the first thing you have to ask yourself is, what can I eliminate? The second thing is, which steps can I combine? The third thing is, what do I re-engineer? Most people want to re-engineer right away. That's the worst thing you can do, because if you can eliminate a task there's no need for it whatsoever. When you combine, you still have tasks to perform, but you have reduced the number of steps in a process. Re-engineer is just revamping the whole thing.
So yes, you have to clearly identify who is going to be affected by what particular process and then begin the behavioral change with those people at the right time.
iSource: And figure out which technology you're going to use to make sure everything works together.
Duciewicz: Yes, that's very key. But the biggest thing is that you have to make sure people understand the reason for the [process] change, are positive about the change occurring and are able to adapt to that change. You can put in any technology that you want, but if the person doesn't buy into it, the system's going to fail.
iSource: How do you address the return on investment for the projects that you're working on in the supply chain?
Duciewicz: Whenever you do a supply chain project there are two things you have to look at in the business case: number one is customer satisfaction, and number two is asset control.
For asset control, you set your expectations for things like the people-cost savings, inventory savings and transportation savings, and you constantly refer to those [goals] as you go through planning, designing and implementing. Then you have to check how you are performing against those expectations after you go live.
For customer satisfaction, measurement is always a challenge because a lot of areas are nebulous and difficult to put a dollar value on. I simply can't say that if we were able to achieve "X" level of customer service our sales would go up 20 percent. That's a questionable method that gets a lot of projects sold, but it generally doesn't deliver on the promise.
You have to ask, what value can I add to my customer that my competition cannot? That's my advantage over my competition. For example, let me ask you a question: Tell me what delivery means.
iSource: Getting the product to the customer.
Duciewicz: Wrong! Everybody thinks that, with delivery, the most important thing is getting the product to the customer. But what's most important is getting information to the customer. You will never be able to deliver 100 percent of the product, 100 percent of the time, 100 percent on time. You should always be able to present 100 percent of the information, 100 percent of the time, 100 percent on time. Because if your customers have information about their orders, they can use it in their decision-making processes.
iSource: Do you ever envision reaching what we are calling "Process Nirvana," the point at which you will no longer have to rework your processes?
Duciewicz: From a personal standpoint, the day I stop revising processes in this company is the day I retire. As far as I'm concerned, anybody who thinks that a process is finished is a complete idiot. You will always have to keep looking at your processes.
And it's not a matter of technology. Technology should not be the reason why you change. Technology can be a facilitator, but you change because there is a better way of doing something, because you can eliminate process steps or combine process steps or re-engineer process steps.
So you will always have to be changing processes. People say that if the wheel isn't broken, don't fix it. Well, if the wheel isn't broken, you haven't looked at it hard enough.
