Warning: Undefined array key "bio" in /home/techwatch/domains/test.bits-chips.nl/public_html/wp-content/plugins/wpcodebox2/src/Runner/QueryRunner.php(126) : eval()'d code on line 13
Author:
Reading time: 7 minutes
A good configuration management process for creating high-tech systems provides cost savings, strength and fully transparent development and production. Frank Ploegmakers, trainer at High Tech Institute, talks about obstacles and common mistakes in configuration management. “Those responsible for technology, development and operations are not always able to understand the essence of the configuration management complexity.”
Within a high tech organization, hordes of engineers produce an enormous amount of technical data: partial designs of printed circuit boards, motors, sensors, mechanical and optical components, you name it. Electronics engineers, software designers, optical engineers, mechanical engineers: they all have their own computer tools. Even prototyping itself is shifting to the virtual environment. Remove the design tools from any high tech company and you may as well shut it down.
The discipline of configuration management has been developed to control the coherence of all this design information. It ensures that different disciplines can work together on a design and that the process from design through to the delivered product is controlled.
It’s hard to believe, but only a small proportion of high tech machine builders have specified and implemented a configuration management process and method within the appropriate ICT tools. “This doesn’t exist in many companies,” says Frank Ploegmakers, trainer in system configuration management at High Tech Institute. “Configuration management tools are needed to exchange, test, secure, hold and place all design knowledge into a structure. I think that only a small proportion of machine builders have documented their development and manufacturing processes and correctly use them and, for example, understand what baselining is.”
Baselining
To explain what baselining is and to clarify relative issues, let’s take a trip into an ideal world. In this world, ingenious mechanics, electronics engineers and software engineers deliver perfect partial designs in close consultation. They are – miraculously – all correct first time round. Everyone is happy: that works! We can produce! The person in charge gives the starting signal and the design department draws up a baseline. This defines the machine design in a precise manner: materials, composition, purchasing parts, modules, coherence (think of geometry and quality specifications) and the associated software. Production can get started making the machine and the purchasing department can go ahead and order.
If only it were that simple, sighs every technician. In practice, there are many design layers. Improvement follows improvement. Before you know it, the mechanics department is on version 3, the electronics department on version 6 and the software team on version 4.11. Not a disaster either, since once a baseline has been drawn, the machine has also been defined in detail.
In practice, matters are different. We will continue to make improvements even after ‘drawing up the baseline.’ A component in version number 5 is in the baseline, but the manufacturer has still found something that makes it better or cheaper. Therefore, production will have to take version number 6. Even then, there isn’t a problem, but in practice, many technicians and disciplines all work on their own partial design.
Then, suddenly, there appear to be hundreds of small to large improvements let loose upon a baseline. Which person still maintains the whole overview? Who still knows the relationship between the product or machine at the customer and the baseline within their own organization? Ploegmakers says: “With today’s complex products and systems, you need something that you’re able to maintain an overview of, so that it’s clear what each person is doing at each precise moment while all changes to baselines are completely transparent. A large part of the machine builders have laid out their development and manufacturing processes properly, a small part actually uses them for what they are intended.”
Timestamps
In software development, configuration management is commonplace everywhere. At the end of a day of development, the engineers in that discipline check in their code and a build is run, creating the program with all recent additions. Ploegmakers believes that this working method should also be applied by other disciplines. “Strangely enough, companies do software configuration management, but they don’t apply it at the system level.”
According to Ploegmakers, this is because many companies do not (yet) realize that this is their major problem. “If I say to a software manager: ‘I’m now removing your software configuration system,’ he will panic completely because then he will no longer be able to carry out his software output. But in most product or machine building organizations, there are employees at a higher level who have to watch over multidisciplinary system integration with tens of thousands or even hundreds of thousands of components, while in the case in question, they don’t. When I talk to software people about it, they say to me: ‘Frank, you’ve just touched a raw nerve.’”
A complicating factor is the time between drawing up the baseline and a working machine. With software, everyone sees the result the next morning, but with hardware, it takes months. With a high chance that changes will slip through that have not been coordinated with everyone.
You prevent that by using a configuration management system, says Ploegmakers. “With this system, you create complete transparency. The power of baselining is that the entire company works with the baseline. Everyone can see the development and production situation at any given point in time.”
Ploegmakers compares it to a film. “You can rewind the entire history. You create time stamps. You simply see the historical development of your product with all the associated benefits. It can be useful to look back at baselines and it is also nice for the customer. You can recall the precise configuration if the client places an additional order.”
PDM
Via LTS, MTS and HTS mechanical engineering, Ploegmakers ended up reading Engineering and Construction Informatics at Eindhoven University of Technology (nowadays Technology Management faculty). Half of that was hard technology and the other half economics, business administration, marketing, philosophy and social psychology. He came into contact with virtual reality and witnessed the first wave of automation and its excesses: major IT projects that went wild. In this way, he became interested in how you ensure that information technology actually delivers something to a company.
By organizing a study trip to China, Ploegmakers got his first job. He started at WAIDE Consultants in the mid-nineties. This company advised Dutch companies on joint ventures to gain access to the Chinese market. Great projects and a great experience, but it was not technical enough for him and after a year and a half, he started working at Philips Display Components.
For five years, Ploegmakers and his design support department focused on the further optimization of picture tube design processes and tools. In addition, the field of product data management (PDM) rose strongly in the late nineties. “This involved recording and jointly using worldwide information about the display tubes, the production process and production machines. This had to be properly supported by PDM automation.”
Ploegmakers used much of what he learned at Philips Components at Assembléon, manufacturer of pick-and-place machines. There, his field of work expanded to the entire creation process: from product creation to logistics, production, delivery and service.
After his Philips days, for four years Ploegmakers worked at engineering firm Irmato Group as director of sales and operations. Together with his team, he helped the company grow from 20 to 135 employees. He learned a lot on the job. “We built everything from scratch.” In 2008, after four years of Irmato, Ploegmakers started working at various companies as an interim manager and project manager. He has now seen more than a hundred companies on the inside.
Insight and overview
Configuration management is not a problem for IT, the reliability department or the R&D department, emphasizes Ploegmakers. “This goes beyond all departments, from the CTO to the factory floor.” He believes the real problem often lies with the leadership. “Those responsible for technology, development and operations are not always able to understand the essence of configuration management complexity. Organizations can deliver beautiful configurations of products and machines to customers, but the internal control of these configurations often leaves something to be desired. Business leaders often fail to see that this leads to enormous inefficiencies and ineffectiveness.”
Managing and automating business processes starts with the insight into one’s own company and a good overview of the complexity. “It starts with a good company model. Many managers are unable to set that up with all teams. But it’s necessary if you want to achieve complex products or machines together with a large organization. If your product and your company become more complex, a simple method to manage the configuration process is essential.” Once that process and the associated working methods are known, the introduction of the required information technology is easy. “Then it can be configured in PDM and ERP systems in no time at all.”
Doesn’t Ploegmakers paint a somewhat rather too rosy picture with this last statement? “No,” he affirms. “The difficult thing is to first understand the complexity. That’s an absolute condition for doing configuration management. The implementation of the underlying details is then simple. The adage ‘organize first, automate second’ still applies.”
