Systems Engineering, Just Good Engineering
I had a great conversation with a colleague while at the 2014 PDA “Universe of Pre-filled Syringes and Injection Devices” conference. Mike is a 15-year veteran of the pharma and medical device world and has seen examples of both good and bad engineering practices. We talked about the discipline of system engineering and why it is necessary to the successful completion of programs. I realized that one of the difficulties in getting organizations to adopt systems engineering is one of nomenclature: systems engineering does not have the awareness it deserves because in some organizations that it’s just called “[good] engineering”. In these organizations, “systems engineering” practices, though not by name, are the crucial component of how to do engineering well.
Mike told me that 3M’s biotech divisions have followed this. Suttons Creek team members who have worked at Lockheed Martin confirm that aerospace companies follow this model. In each case, systems engineering is part of the company culture, though only one company has a formal systems engineering department. Systems thinking pervades the entire organization, and everyone in the corporation is trained on it. Unfortunately, even Fortune 200 companies sometimes fail to define a strong process for product development that can handle our increasingly complex and integrated world.
Let’s consider a current example for why systems engineering is needed from the pharmaceutical industry: the growth of combination products. Pharmaceutical companies are working on large-molecule, biologic drugs that require injection systems. These companies don’t have the expertise in-house to develop electromechanical systems, so they outsource to many vendors. But which vendors should you choose? And how do you integrate what they do with your product?
It doesn’t get easier if you decide to build an engineering team in-house. Consider a pharmaceutical company with 3 engineering teams that are tasked with designing a new drug delivery technology. The mechanical engineering team is more likely to design a mechanical auto-injector. The electrical engineering team might build a transdermal iontophoresis device. A software engineering team might recommend you create a electromechanical patch injector that has many indicators and sensors… and you guessed it…. those features require software. So who is right? How are all the variables in that complex decision managed?
In many companies, there is no clear authority, and so it ends up falling to politics: the VP of R&D started out as Mechanical Engineer, so the mechanical engineering team wins. But it is the job of a systems engineer, or someone serving that function, to properly answer this question. It takes a strong technical leader to make a balanced decision based on all of the inputs, including human factors, development time, business risk, cost schedules, reliability, etc. It takes someone who has systems engineering training, whether through education or practice, and often both. This is one of the things we try to impart upon our clients: one component of “doing engineering well” is learning how to manage the technical aspects of programs with a variety of tools, none of which is a soldering iron.