Value Engineering is so much more than just saving a few euros – says a lead system architect

After years of practical experience at Philips Healthcare, Goof Pruijsen now offers advice on value engineering and cost management. He provides training on these subjects for High Tech Institute.

‘Really enjoy it.’ Goof Pruijsen does, as people from different technical development disciplines reap the benefits of his views and knowledge. ‘It gives me a wonderful sense of appreciation.’ He himself is immensely curious. It fascinates him to understand in detail what it is that people are considering buying, how and why a product works technically and how you can improve it in order to improve a business.

Recently he received a big compliment from a lead system architect from ASML who attended a Pruijsen workshop together with his team. ‘I thought we were going to save a few euros, but I learned that value engineering was much more,’ says this system architect. ‘We dealt with some fantastic topics and posed questions about decisions that we had taken at a high level in system architecture. The insights we were left with didn’t only have an impact on costs, but also on the reduction of complexity, risk, time to market and the hours that we spent on engineering.’

Goof Pruijsen: ‘It is precisely the solution-driven approach, used by many teams, which makes them blind to alternatives.’

Therefore, value engineering is perfectly suited to Pruijsen. Although the definition is a bit boring: it’s about adjusting and changing design and manufacturing based on a thorough analysis. If it is done well, it often leads to cost reductions. That’s why developers often have a negative association with value engineering, the ‘squeezing’ of a design, to the saving of costs.

However, High Tech Institute’s trainer Goof Pruijsen, identifies a much more important value: value engineering creates bridges between marketing, development, manufacturing, purchasing and the suppliers. Precisely this interplay between different disciplines ensures that you can achieve large profits by using this approach.

Cost reduction often focuses on the component list of the current solution. This is what Pruijsen calls a beginner’s mistake. ‘You can see that newbies in the profession carry out a so-called pareto-analysis, in which they map out the 20 percent of the components that are responsible for 80 percent of the costs. They will then take something off the most expensive things. It’s not called the cheese cutter method for nothing.’

This approach is often not very effective, says Pruijsen. ‘When this happens, others have often intervened before. Then there is not much more to be gained and chances are that new interventions will affect the quality. If that is at the expense of your image, you are even more worse off.’

Value engineering therefore starts, according to Pruijsen, with value for the customer. ‘What does the customer want to achieve? Which functions are needed for this? What is the value of that function and what are the costs?’ An example that he often mentions is as follows: it is not about the drill, not about the hole, but about hanging the painting in order to decorate your house. Going back to the ultimate goal makes room for creativity and new solutions and concepts.

Tolerance is the cost driver

Thinking in functions is less well established than most developers think. Pruijsen sees that the solution focus with which many teams work, makes them blind to alternatives. ‘They don’t think out-of-the-box.’ It helps – and that requires practice – to analyse an existing solution and to gradually abstract it from there until the functions are perfectly clear. Without describing the solution. Then you can map out the costs functionally and together investigate why these functions are expensive. That is a good start for optimising current and future product generations. I call that cost driver analysis. If you do this well, everyone starts to understand the problem much better and you are already halfway to the solution,’ says Pruijsen.

Tolerance or accuracy is a typical example of a cost driver. Narrow tolerances result in more processing time or steps. An average power supply is usually not that expensive, but if the voltage ripple is very small, then the price rises.

You need to take a close look at those tolerances, according to Pruijsen. ‘Are they really needed everywhere, or only locally? Why is this tolerance so specified? This is often something that doesn’t seem to be considered. Tolerances may have been copied from the previous drawing, designers pay no attention to them, but they do appear on the invoice. Developers are usually unaware of the consequences of their risk-avoiding copying behaviour. If it turns out that a tolerance requirement is not so strict, the manufacturing suddenly becomes much easier, faster and cheaper. Problems with manufacturability and production yield are often resolved spontaneously.’

Large projects, multiple teams, balanced design

In large projects with multiple sub-teams each and every one optimises his own area as much as possible – even if only out of ambition. Pruijsen: ‘If the teams don’t understand how the job is distributed across the modules, then the chance of imbalance in design and specification is high. You don’t put a Formula 1 engine on the chassis of a 2CV. The performance of the components must be in balance with each other. The task of the system architect is to maintain that balance and prevent over-engineering.’

Pruijsen provides a practical case from his time at Philips Healthcare.  X-rays have been used for many years in medical diagnostics and material research. To generate these x-rays, you shoot high voltage electrons onto heavy metal. At one point, the marketing department asked for a new high-voltage generator. One with more power, better stability and higher reliability. And preferably also cheaper.

‘A project like this often starts purely for performance and technology driven purposes,’ says Pruijsen, from experience. ‘In this case, however, we decided to start formally with a value engineering workshop in order to improve the profit margin on the product as well as the technical direction. The old generator was analysed with respect to costs and functions. It turned out that a relatively large amount of money was invested in much smaller parts (the so-called ‘long tail of pareto’). You cannot quickly put your finger on that one expensive part; the syndrome is one of many components. A many-parts syndrome typically manifests itself in high design costs, high handling costs, and high assembly costs for all parts involved. Every step in the labour process also includes an error risk; and you can add to that an additional risk of quality problems and production loss. The direction for improvement is therefore usually reducing parts through integration, the so-called DFMA (Design for Manufacturing & Assembly).’

Another cost driver was decided in the concept. In order to safely protect the high voltage in the old concept, it was completely submerged in an oil tank. That later turned out to be too big, too heavy and unnecessarily expensive.

Pruijsen: ‘We brainstormed each function and built a consistent and optimal scenario. For the high-voltage generation, we could ride on new technology that makes it possible to transform at higher frequencies. That way we could greatly reduce the volume.’

Observing how it was used brought the biggest breakthrough. The old generator was developed by maximizing all individual performance requirements, without looking at whether these were useful combinations or not. However, doctors use either a single high power shot or several images per second with very low power (and some combinations in between). ‘When the engineers saw this, they were indignant. Nobody had ever told them that! The result was a large reduction in required power and a high voltage tank that was ultimately only a tenth of the original volume.

Cooling is still necessary, but instead of using large ventilators, Pruijsen and his team placed the largest heat source on the bottom of the cabinet. ‘This created a convection current. We used the heat source to improve cooling.’ This is an example of ‘reversed thinking’.

‘The end result was a smaller and quieter generator, 35 percent cheaper. Moreover, fewer components were needed and we achieved a better reliability. And there was another optimisation, the total space required for the system could be reduced by one cabinet.’

Could it have been even better? Yes of course it could, says Pruijsen. ‘We were unable to break through one specification point during this process. The generator was specified at 100 kW. It was said that this had to be so according to medical regulations. ‘It took me months to find the source of this misconception. It turned out to be a medical guideline that advises the use of a generator of at least 80 kW in order to be able to make a good diagnosis with greater certainty. That was therefore a piece of advice given, not a regulation!’ says Pruijsen.

This ‘advice’ dated back to 1991. In the intervening twenty years, image processing techniques have progressed so fast, that a better result can be obtained with much less power. Eventually, Pruijsen found a product manager who admitted that it was not a legal directive, but a so-called tender spec. ‘Because manufacturers have been telling their customers for years that only 100 kW gives sufficient quality, it has become an ‘accepted customer belief’.

‘If the tolerance requirements prove too high but can be relaxed, manufacturing can suddenly become much easier, faster and cheaper,’ says Goof Pruijsen. ‘Problems with manufacturability and production yield are then often resolved spontaneously.’

Managing modular architecture

Pruijsen gives another example. A large module in a production machine was designed in a number of small modules. This meant that a sub-module could be replaced quickly should there be errors. The assumption was that this was cheaper and provided less service stock. ‘The increase in the number of critical interfaces with high tolerance requirements, however, made the cost price double and the complexity increased so that the expected reliability was dramatically lower,’ says Pruijsen. ‘Add to this additional development costs and production tests. A one-piece design turned out to be the better solution. Components with the most risk of failure were thereby placed in an easily accessible location. The lesson was: Modularity is not to cut a module into submodules, but to place your modularity and interfaces correctly. In this case, with a view to providing the best service and also cost-efficient service. You have to keep thinking about the consequences and the balance.’

In his value engineering training course, Pruijsen makes it clear how the set-up of a value engineering study works in practice. First, he concentrates on analysis tools and then on creative techniques for improved scenarios. In addition, attention is paid to involving suppliers in this approach.

There is a lot of attention paid to practical training. One third of the training course consists of practical exercises. For example, there is a ‘Lego-car exercise’ in which course participants learn how to tackle cost reduction and value increase. In addition, they also carry out benefit analyses (case: on the basis of which criteria do customers decide to buy a car?), process flow analysis (case: optimisation of a canteen) and function analysis (the core of functional thinking). Many techniques are clarified on the basis of examples.

Pruijsen also asks course participants to prepare a short presentation of up to ten minutes in advance about their business and product. He may choose one to jointly analyse ‘on the spot.’

Goof’s tips for value engineering

Last but not least, here are some tips from Goof Pruijsen with relation to value engineering:

1. Analyze before considering solutions

2. Go back to basic comprehension: what does it do?

3. What makes it expensive and why?

4. Make an inventory of the assumptions and try to destroy them

5. Be creative; don’t limit yourself to thinking of traditional solutions (risk avoiding), but look for the boundaries

6. Bring the solutions together in a total overview and build scenarios

7. Don’t play down the risks, but also don’t use them as an excuse for not doing things either. Make them explicit and find mitigations for them

8. Keep an eye on the business side of things. Everyone likes to be creative, but money also needs to be earned. Which scenario best satisfies the financial and organisational preconditions?

9. Go for it!

This article is written by René Raaijmakers, tech editor of High-Tech Systems.