An analogy to bring closure:
You would not buy a thoroughbred race horse for a premium price if the
gate purse did not offer the potential of high stakes and large
In development we are challenged to push speed and time-to-market. We
sometimes find the answer to the question, when is enough enough. That
is; "What is the time value of money"? The answer will be apparent
when you submit a proposal for a new time saving gizmo to save a day
in development/tooling and you are shot down. Or, when you submit a
proposal to a client which meets their deliverable dates and they
don't move forward with the request because they couldn't justify the
price for the time saved. Enough can be enough!
Optimizing available machine capacity by out-sourcing is strategically
and financially superior for ROI. How many companies generate enough
product to fill capacity of their RP systems. How many realized this
in the early days of RP and began out-soucing capacity to justify
investment. e.g. Baxter, Becton Dickinson, and I'm sure there are
more. How many more produce trash and trinkets (and call them
engineering models) just to justify the investment (show charts to
management with capacity utilization).
Thanks for the exchange,
______________________________ Reply Separator _________________________________
Subject: Re: Re: Machine Hour Capacity Gage
Author: Preston Smith <firstname.lastname@example.org> at INTERNET
Date: 6/6/97 4:45 PM
On Mon, 2 Jun 1997 email@example.com wrote:
> Hello Preston,
> I wonder how much capital investment you are responsible for and how
> much of it is yours personally. If your a manufacturer or large OEM
> justifiying a half million plus expenditure may be paled by your
> savings if you are quicker and first to the market.
> However, the rest of the world needs ROI and profit to stay in
> business regardless of the type of investment. Hence, efficient
> queuing of machine to optimize capacity equals throughput. Throughput
> equals ROI and sooner profit. All our stakeholders would appreciate
> it if our investments were profitable. This analogy is no different
> then developing product from concept through distribution.
Thanks for your response. You are exactly right that we all need profit
to stay in business.
All to often managers do not include time to market in their business
profit-and-loss decisions in a business-like way. Time to market has
become a "religion" that some managers think is universally good. Then
they exclude it from their quantitative business decisions. Using just
intuition to make business decisions on time to market results in grossly
overvaluing or undervaluing time.
All I am suggesting is that time be included in the business equation, just
like the capital investment. For some projects the profit impact of
getting to market faster is high, and the project manager would be wise to
be rather "wasteful" with his/her rapid prototyping capability. For other
projects the profit impact is low, and perhaps they shouldn't be using the
rather expensive rapid prototyping technologies at all on these projects.
The only way to separate these two groups is to calculate the cost of
delay, on a project by project basis, and use it for making business
I'm assuming that on this rapid prototyping list there are an above
average number of readers for whom time to market has a large profit
impact. If so, the proposed time to market calculations will more often
justify more (rather than less) rapid prototyping equipment and services
and perhaps paying more to keep them responsive.
> ______________________________ Reply Separator
> Subject: Re: Machine Hour Capacity Gage
> Author: Preston Smith <firstname.lastname@example.org> at INTERNET
> Date: 5/30/97 2:54 PM
> On Fri, 30 May 1997, Steve Deak wrote:
> > Joseph DeGuglielmo wrote:
> > >
> > > Do any of you fine folks out there have a feel for how many hours a month
> > > your machine needs to run to be considered "At Capacity"?
> > >
> This has been an interesting thread. The emphasis has been on been on
> keeping the machine as loaded as possible to maximize return on your
> investment in the machine.
> This viewpoint totally ignores the value of fast response to the demand
> for prototypes -- the very argument for having rapid prototypes in the
> first place.
> We work with many manufacturers to help them speed up their product
> development, and we find that there are two major related mistakes that
> most of then make. One is that they have no idea what one day of schedule
> slippage on a development project is worth to them financially (dollars of
> profit lost due to a day of slippage). Second, because they do not place
> a financial value on time, they try to minimize expenses by overloading
> their people and equipment, trying to squeeze every second of up-time out
> of them. As a result, everything sits in queue awaiting scarce resources.
> Managers who know the cost of delay for each of their development projects
> include this factor in loading their people and equipment, deliberately
> allowing some slack that provides the flexibility needed to respond
> These topics are covered in detail in Chapters 2 and 11, respectively, of
> our book, Developing Products in Half the Time. A second edition edition
> of this book with even more powerful information on these two vital topics
> will appear in a few months under the title Developing Products in Half
> the Time: New Tools, New Rules.
> Preston Smith
> New Product Dynamics telephone: +1 (503) 248-0900
> Portland, Oregon USA fax: +1 (503) 294-1192
This archive was generated by hypermail 2.1.2 : Tue Jun 05 2001 - 22:39:43 EEST