I walked into a customer business review meeting and was quite surprised to see our scorecard results on cost were lower than my expectation. The disappointment was because we had made significant progress on quality but what we had not taken notice was the significant cost that we incurred in doing so.
If you are a supplier in the server industry, then I’m sure that you have heard this feedback from your customers:
“How do we reduce cost, increase quality, and time to deploy
all at the same time?”
While the first time we hear this comment it is no doubt frustrating, as we dig a little deeper and remove the veneer of exasperation, and dive into their world, and understand their pain points, then we hear the faint rumblings coming from within the deep recess of their organizations and their customers. I have listed those key requirements as we learnt them here:
1. Product development time is shrinking by half
2.Quality is increasing in some cases by 2 times
3. Cost of Goods continues to be driven down by customers with significant volume and buying power
4. Dev Ops. model is the way forward and there is continuous integration, development, and deployment even in a hardware centric world. This introduces new processes that needs a new Roles & Responsibilities mapping
5. Product development is dynamic, agile and certainly moved away from staged gate waterfall approach
6. Expectation of product readiness is earlier in development cycle
7. Quality processes need to be ingrained earlier into the development cycle
8. Factory processes need to be matured much earlier in development (test fixtures, tooling, diagnostics)
9. Readiness is driven by data center solutions which requires Hyper scale engineering and processes instead of single server product mindset
10. Business is lumpy, unpredictable, and dynamic
11. Requirement of quality of data into NPI, factory quality, Services quality, BOMs, costs
Apart from each of them being hard to achieve in solo, they become almost overbearing and unconquerable when considered together, as a host of them directly contradict each other.
The question that stares right at us then is, how do we address these conflicting requirements?
We realized that sharing, reusing, and customizing are cornerstones to achieving some of the contradicting yet relevant constraints of cost, quality, solution focus, and time to market. If sharing is a key tenet, then as a consequence to that, modular design building blocks become important as well.
However, there are several questions that arise as we ruminate on this topic.
What are the causes for the differences that exist today that impedes such an architecture to be implemented? What does such a modular common platform need to achieve? What is the driving reason for commonality and why do we modularize?
What are the grounding principles to modularize hardware and firmware? If such an architecture is implemented, what is the major driving force that will be needed for the industry to adopt and standardize?
If and when we apply these defining principles and framework, what will that new building blocks of this modified architecture look like? Are there any process enhancement and organizational design modifications that need to happen in order to build, deliver, and service the products that use these new building blocks?
We were as bewildered as you are but we diligently explored these questions on how best we can contribute to address them. Along the way we had our moments of discovery and insights that we would like to share with you if you are interested, in the subsequent blogs, in this series called “Modular Common Platform”.
It would be great if you can share some of your thoughts, your own experience, and insights on this topic. We are eager to know whether the questions that we are addressing are relevant to you and if so, in what ways? We would love to hear your feedback in the comments section.