29 Apr A Growing Need for Systems Thinking
When your fledgling product development company has six engineers, you’re hard-pressed to not think at a system level. You’re in every meeting. You know all the specs because you helped write them. And you have a deep, nuanced understanding of that one weird, fascinating bug that you, the two mechanical engineers, and the programmer stayed up until 1 AM troubleshooting that one night before the last prototype demo.
But as Key Tech has grown over the past 20 years to more than 40 engineers, programmers, technicians, and industrial designers, we have had to grow our systems approach from its organic roots to a more disciplined and comprehensive set of processes.
System engineering at Key Tech
Traditional system engineering processes cater to large companies with thousands of employees building staggeringly large, complex, and expensive systems over years or even decades. Those processes simply wouldn’t work for us, as Key Tech faces a unique set of challenges: First, the pace of medical product development is rapid and only increasing. Second, adaptability is critical: Though we frequently take on large, full-scope projects, we must also serve as a nimble extension to our clients’ capabilities, which means deploying small teams to tackle focused tasks prior to ramping up to a full development team.
These unique challenges demand a unique flavor of system engineering that works for Key Tech: one that is both thorough and adaptable, improving the quality of our designs while identifying and derisking cross-disciplinary issues earlier in development. As problem solvers, we have strived to develop system engineering processes to meet these needs.
Designing a good process
A bad process can hamstring an entire project. So we have deployed system engineering tactics gradually and iteratively, over many years and many projects. After each project, we meet internally to review what went well and what did not. If a particular tactic is more trouble than it’s worth, we can discard it and try a different approach. If some other method hits a resonance with the project team, we can enhance and formalize that method and deploy it to the entire company.
This method of “designing” our processes allows us to leverage input from all disciplines and experience levels—from the seasoned founders to brand-new hires—as well as to learn from every phase of a project—from concept development to early prototyping to pre-production builds to manufacturing transfer.
System engineering applied
When designing a cartridge heater, a mechanical engineer focuses on surface flatness and actuation force. Electrical engineers want to know the target power and temperature measurement accuracy. And programmers need to understand how the temperature must be controlled, and when during the assay to perform that control.
A system engineer thinks not just about the sum of these considerations, but about their interactions, and particularly about conflicts that arise at the system level: A large heat spreader may provide good temperature stability and planar uniformity, but makes for slower ramp rates, larger Z-axis temperature gradients, and clunkier software control. And a good system engineer doesn’t make the mistake of trying to eliminate all of these issues but instead relies on a deep understanding of the product requirements and risk factors in order to prioritize which features are most important, balancing those priorities to move the design forward.
A good system engineering process is not just about encouraging this system-level thinking; it’s also about facilitating good communication of technical information between each discipline, the system engineer, the project manager, and our client. When combined, these two facets of the process—systems thinking and systems communication—allow us to develop more robust products and to catch cross-disciplinary issues earlier, saving schedule time and project capital while improving ultimate product performance.
So what is our system engineering process? The short answer is that you should contact us to find out. The longer answer involves the following:
• Outlines and questionnaires to assist with developing detailed, useful project plans
• Guidance and templates for capturing system requirements
• Tools to accelerate and enhance the utility of formal risk analyses
• Direction for when and how to conduct and disposition formal system design reviews
• Methods for planning and tracking proper system configurations on large builds
• Instructions and tools for build and inventory management
• Comprehensive checklists to ensure all of these activities occur during development
We are always happy to share more about how our wealth of past experience allows us to approach new projects with ever more discipline and sophistication, and are always looking for more challenging and ambitious projects to take on. Let’s talk about yours at TalkToUs@keytechinc.com.