Reasons for this insight vary from political power to “strange eyes” that can see beyond the “internal blindness of knowing”. I prefer to support the latter.

I can best compare this to my own experience with my two sons. For me they are completely different. They are 14 months separated in age, have different shade of blue in their eyes, have different interests and walk completely different. Nevertheless strange people confuse them easily or even ask “are they twins”.

A similar effect can be observed when (we) European Caucasian people look at Asian or African people. For us it it much harder to see subtile differences in them as in other Europeans.

I think this principle is also true for designers, engineers and sales people of customized products. They tend to see more differences than similarities. For them all products are purely unique.

Our challenge is to help these professionals to see and describe the commonalities in function, form and structure to enable optimization towards “intelligent customization”: design customizable products families that can be efficiently adopted to specific customer needs and manufactured accordingly. With this, companies can benefit from serial production efficiency and enjoy value from customized products.

This week I attended a “theme day” in Eindhoven about Smart Customization. Smart Customization aims to design variable products in a way that enable a short and cost effective production of a customized product. Several representatives of different companies shared experiences in their process to move from traditional engineer-to-order to configure-to-order.

One of the big challenges for engineer-to-order companies is to regard their product with different eyes. If you ask engineers or sales people about their product, they will often say that every product is unique. Participants of the theme-day agreed that external expertise is of essential value to help recognize patterns and common structures in existing products.

In a way we could say we have to look for easter eggs (features unrecognized in day-to-day way of looking at it) in customers products. We can be of great help for customers to do so and also give advice how to get moving towards configure-to-order in small, low-risk steps. More news about this topic will follow in the coming weeks.

For now I wish everybody a happy Easter…

The same seems to be true for people who start working with a new SolidWorks release. Many customer wait until a later SolidWorks Service pack to start working on in production environment. Of course this is for obvious reasons, you don’t want to find yourself amidst a rioting engineer department where people cannot do their job efficiently because there is an unobserved function combination not working for you as it did before.

What is easily forgotten in this behavior is a negative side-effect that we could compare to an immunity against antibiotics. If everybody does the same, the problems unobserved during beta are still not discovered within the version life cycle. The problem is than that if problems are discovered, people will get the answer: “it will be solved in the next version” instead of “it will be solved in the next service pack”.

To prevent this, I see a kind of community responsibility. We all could identify and document our key-processes in SolidWorks (which would be a good exercise anyway) and run these a couple of times through the first release. If you can do it with the beta it would be even better. We would find much more unobserved exceptions in the first version and have a perfect SP1 (or SP0 is everybody would participate in the beta). I know that some companies do this and deliver invaluable information to SolidWorks. They are sure that they can work in their process with the early versions…

Best Regards,
Bas (S.P.) Koomen (yes, these are my real initials)