Product configuration: The Answer to Staying Competitive?
Globalisation can attract strong competition, partially because of technical exposure, and partially because of the success that the global business brings. European businesses can no longer expect to maintain supremacy in an increasing competitive market. But what can be done to regain an edge when so much company time and effort must be put into chasing bids and engineering solutions? This article explores whether product configuration can provide one answer.
One of my clients, a successful materials handling company, is renown as a market leader in their field, having developed both the products and technologies which are now accepted as industry standard. Their business grew rapidly over two decades, quickly reaching new markets in Asia and the Far East. It wasn’t long, however, before new competition challenged their success. Strong patents, a great reputation and a strong brand staved off competition for more than a decade but slowly the competition caught up.
As competition grew, my clients retained market share by globally sourcing components and moving assembly close to the installed location. Engineering teams worked hard to value engineer the products and reduce cost. New sizing methods were adopted to ensure that systems were sized no larger than needed to meet the customers’ requirements.
Yet, over time, the knowledge became available to competitors. Patents on key components had expired and it was difficult if not impossible to protect the remaining intellectual property. With a falling order book and concern for the continuity of work, my client cut their core staffing levels, relying more on temporary staff for specific projects. New business started to be governed by the availability of skilled engineers to quote and deliver projects rather than the market demand. The company was forced to take on more complex, higher risk projects as the easier, safer projects were snapped up by local competitors. High numbers of projects were quoted with a diminishing order conversion rate and prices were reduced to maintain a sustainable order volume.
Asian/Far Eastern competition was getting good. They had the ability to employ large project teams with well qualified and organised engineers at a fraction of the European cost. The competition was often the first choice for the most attractive projects, and not only because of the price. My client started to cut back on research and development and it became more difficult to maintain morale and key staff.
What can be done?
In a strategy meeting, the future of one product was reviewed, and many solutions were voiced. A seemingly ridiculous proposition was tabled, perhaps more in frustration than seriousness, “What if engineering was always complete and accurate”. Whilst this was outwardly a ridiculous and unachievable goal, it was given serious consideration.
Without engineering delays customers could be quoted within minutes, this would remove the high cost of the proposal preparation and concerns for the low order conversion rate would vanish. Customers would be pleased with an immediate response, and without the need for estimation the accuracy of the quotations would be exact. Products would be right first time without errors, and lengthy periods of uncertainty. Without looking at the irrationality of the idea the conversation continued. Manufacturing could start the same day as the order was received, components could be sourced in larger batches as information was available instantaneously. Without engineering, the company would be able to be more competitive than the overseas competitors with low staffing costs. But of all the things that could be shaved off an engineering company to save money, surely the last thing to cut back would be engineering, right?
Like so may hypothetical situations, the solution was too idealistic and seemingly unachievable. Maybe it was time to discuss how to reduce cost further and find ways of becoming more efficient at doing more of the same? But the idea remained, and I was positive there was some potential in it.
The start of a concept
20 years ago, I worked for a product company which operated under license, but the products were outdated, costly to manufacture and relied upon extensive manufacturing facilities. With falling profits, our group management decided that the business should be relocated under the wing of the successful parent. We relocated without our old factory and all but three of us remained after the move. Given a fresh opportunity to push the company forward I developed a new product around a modular principle. The final design was made up of a few interchangeable, modular components and the result was that we had more configurable options than the previous product offered. The modular components could be easily outsourced, and assembly was achieved in a small warehouse with minimal cost.
From there, I employed a bright young graduate to help me develop a sales configurator which was written around an access database. The configurator embedded the logic and engineering rules that the company use for sizing and selection. In a few months, we had the means to configure the product modules with accurate costings in a few clicks. Furthermore, the configurator generated a written quotation and a costed bill of material, all in far less time than it would have taken to generate estimates.
The new business was a fraction of the size of the old business with few overheads, and a product range that was now modern and competitive. By simply making the product configurable and embedding the engineering knowledge in a configurator tool we had taken significant steps towards losing the dependency on re-engineering. Certainly, preparing a quotation took a few minutes, and the results were always accurate.
I relayed this story to my client and it was agreed that such a configurator could go a long way towards a business where “engineering was always complete and accurate”, a previously irrational idea. Once the concept of embedding engineering into a software tool was accepted, the configurator was adapted to carry out every possible process carried out in the quotation and execution of both a proposal and live project. Apart from generating 3D models and an accurate costing, the configurator generated wiring diagrams, flow sheets, spares list and maintenance manuals to name just a few. It was essentially a “business in a box”, with the product only having been engineered once to cover a whole range of solutions. New data was simply input, and the 3D model reflected the changes made. A design could be submitted in a few minutes and, if the customer wasn’t happy, a revised version configured a few minutes later, the whole time the system ensured an accurate and integrated result with no room for human error.
The results
This was not all without issue however, and whilst the results spoke for themselves in the time that could be saved, this was not the end of the story. The configurator worked, it did what it was set out to achieve. It delivered on all its proposed features, but it was the integration into the business that caused a problem. The configurator worked with the data given to it, but without being integrated into the main business process, the content was static and soon out of date. If any changes were made to any of the components, the same changes then needed to be reflected in the configurator. Maintaining the configurator would need to become a core business process, and this required the engineering teams to develop new skills and to invest time to perfect the tool.
With the best intentions the company side lined the configurator to focus on several large, new commercial projects. My client maintains that the concept of the configurator is a strong one, but struggles with the ability to integrate it into the core business. Perhaps one day the configurator will get the attention it deserves and be fully put to the test.
Since this configurator was implemented, a new generation of configurators have been developed by us, which simplify the maintenance task. With our improved knowledge, the code used to write the configurator software has been re-written to be modular like the products it manages. With re-usable code, the task of maintaining products has become easier and requires less skill. Over the next decade I believe coding will become a necessary tool in every engineer’s toolbox, favouring tools like ours.
The development of this configurator itself is one I will cover separately, along with a further article that digs deeper into an engineer’s role in designing and maintaining configurator’s. The product configurator is an extension of the business process, and not a static tool that can be purchased and ignored.
What does this all mean?
Where does this leave us? If you are responsible for a product company that offers customers bespoke variants of a standard products or systems? If you have a large team of sales support engineers to provide customers quotations but achieve a low order conversion rate? If products can be adjusted to become re-usable with interchangeable modules? If project execution requires extensive engineering to provide similar documentation? Then perhaps a product configurator could be for you. A configurator is a big investment for a company and not only retains and uses core knowledge but needs to be continuously updated and evolved along with the company. It needs engagement from the engineers that will be using it and a common knowledge inside the business of what it can do and how it works. But the power and flexibility it gives a team is invaluable in a world of strong competition. A strong configurator can become the core of a competitive business, augmenting all facets of a company, but not without ownership and effort.
If you would like to read more on the power of configurators then please read our article on configurator scalability.
Otherwise you might be interested on our thoughts behind coding as an important tool for engineers.
Written by Peter Slee Smith, Editted by Jason Spencer – 20/03/2018