To increase robustness of their business model, manufacturers need to be present in as many as possible product markets, as well as labor markets. However, becoming less sensitive to business disturbances on the global scale comes with a price. It is usually paid by sudden drop in product development throughput and upward burst in cost of operations. The two often compound into a vicious punch that can throw manufacturers on ropes for a prolonged period of time. Yet, globalizing is a must for growth. The key to successful globalization is achieving scalability of development and supply chain operations.
I recently visited a large volume manufacturer of automotive components to discuss their efforts to achieve scalable, global product development operation. When exposed to accelerated loss of revenue coming from their long term customers (Detroit 3), the company decided to rapidly increase global presence. Aside from few logical acquisitions, their globalization strategy was based on the premise that product portfolio, or assortment as they call it, will cover all market segments, ranging from a full spectrum of price/performance/volume contracts with OEMs to boutique aftermarket. With successful branding strategy that would give them an edge against other global, as well as local competitors.
To globalize operations, it is required to foremost standardize and normalize business processes, so proper control can be established to quickly comprehend and react to adverse trends. In the first phase, the company successfully normalized supply chain operations, which they found much more portable than expected. The company had some starting advantage in the fact that both their original operations and the ones they acquired use ERP systems from the same vendor, and had (other then using different terminology) very similar material and financial transactions flows. They say that, in brief, what it took was an agreement to reconcile terminology, followed by few organizational changes to streamline communications between corporate planners and local operations... and, of course, few pounds of Advil for the IT folks. But, they were quite happy with the results of the effort. Customer orders matched inventories, materials procured globally yielded better costs, global data masters were reconciled with local applications, even few unplanned opportunities surfaced to better optimize inventory distribution and increase fulfillment velocity.
However, when it came to standardizing product development process, challenges started creeping up, some perceived and some totally unpredictable. As one of their engineering managers put it: "We had to dig deep into our souls... It's like trying to sequence your own DNA to figure out if you should shave in the morning." Yes, engineers love to do that. But, that deep dive into the basic reasons could easily be why, every once in a while, they invent a "killer product" that has potential of sustaining their company for many years... until the next flash of bright idea. Therein lies the predicament. If you are a global company, are you better off with a number of autonomous dedicated development teams (that may compete from time to time), or should you try to standardize all efforts and manage them from a centralized command and control tower? Depends. We'll discuss later what does it depend on. Back to our company.
Quickly after the kick off of the global research and engineering council, the company figured out that the metrics used for evaluating effectiveness of product development was largely missing. Furthermore, what it meant to be successful to one development operation, was not that much critical to the other. For example, one "pole of wisdom" operated in a tight partnership with OEMs and had become accustomed to somewhat longer lead time tooling and extensive iterative evaluation loops. In short, they thrived on optimizing for cost and volume. The other "pole of wisdom" excelled in fast decision making, taking risks with innovative offerings sold to high end customers and consumers hungry for differentiated performance. In short, they thrived on optimizing for performance and durability. Yet, products were conceptually strikingly similar, with naturally some differences in underlying technology and materials used. Nothing was overwhelmingly unique, while technology and knowledge was excitingly complimentary and convergent, what sparked the promise of a unified kick-a** global portfolio.
Another difference discovered was that development teams used very different approach to major decisions and process flow, what was a logical consequence of having to master different development drivers.
Cost conscious team would postpone conceptual design freeze until their customer validation results of the prototype were fully reviewed. No production layout drawings were even started before conceptual design was approved. That was embedded in the quality system and was not for negotiations - period. Proud managers had quality related blurbs on large posters all over their cubes. However, just takt between conceptual design freeze and production samples was over ten months, and was undergoing third cycle time reduction initiative in as many years (surviving various lean and six sigma attacks).
Performance conscious team would develop multiple concepts, evolve them through simulation, run the prototype in their own lab and combine tooling details for production samples (in parallel with engineering) from multiple already proven production designs. Then, relatively quickly they would fine tune the final production layout and tolerances. Manufacturing had a big say in the design, embedding the quality right in the product, vying not to having to say much about it afterwards. The overall takt from idea to production was ten months.
Nevertheless, first team could work on multiple designs in parallel providing they stagger their introduction times, and through serialized workload could do more work with less engineers. Second team could do less parallel designs, but in a given year would make more total number of designs, given shorter cycle time. Yet, total throughput per development budget was roughly the same. Hence, the teams could not achieve consensus on which approach is better for scaling. They sensed that the truth is in between, but could not advise even a basic roadmap for merging the two approaches.
However, product planning with different product introduction takts was spreading havoc across portfolio planning and marketing efforts that were trying to benefit from reuse and re-purposing of developed technologies. Soon enough, the idea of exchange of knowledge and reuse of technologies seemed more like an academic exercise than an executable business strategy. So much so, that global branding strategy (another pillar of globalization strategy) was now under board scrutiny.
Then, someone at the executive steering committee proposed that they should do in development what supply chain people had done. Compare and contrast processes at the level of detail that will build terminology consensus at least, knowing that the design and engineering tools they used were similar (same CAD, PDM and most of CAE applications), and products after all, very similar. In addition, they would determine the common metrics based on which both approaches can be compared and contrasted and then define a hybrid approach with common takt times and normalized phase-gate model for portfolio planning. The highest support for the idea came from - marketing and sales. IT and business architects were asked to help and they developed a plan to try same approach that they used in supply chain. Everybody said - let's give it one more chance before we throw in the towel.
Did it work? What do you think? The closing of the story in the next blog... Drop me a note if you want to predict the outcome.
