As the systems engineering community moves well into the first two decades of the 21st century, one of our biggest challenges is how we will extend the reach of systems engineering. Our own vision, A World in Motion, Systems Engineering Vision 2025 (INCOSE 2014), challenges us to move “well beyond its [systems engineering’s] traditional roots in aerospace and defense, to meet society’s growing quest for sustainable system solutions to providing fundamental needs, in the globally competitive environment.” Answering that challenge involves seeing beyond the familiar in order to venture into new markets and address new problems.
An example of the move to unfamiliar challenges is systems engineering’s growing interaction with the realm of healthcare delivery processes. Healthcare is an area that faces a number of critical forces that are rapidly converging into a growing crisis. Providing quality healthcare for ageing populations with their increasing needs is creating financial pressure and an attendant need for efficiency in delivery systems. At the same time, effective healthcare demands high-quality results. All of this adds up to a significant opportunity for systems engineering to address these challenges.
But in entering this non-traditional environment, we must remember that there are more systems engineers in the world than hold that title. Some understand systems engineering as a discipline but work in organizations that do not provide slots identified as systems engineers. Others include numbers of professionals who not only do not hold the position of “systems engineer,” but also do not think of themselves as systems engineers. They may not even know that there is such a thing as a systems engineer. But despite this lack of labels, there is systems engineering work underway in healthcare process design and improvement efforts.
In seeking to extend systems engineering concepts and methods into non-traditional fields such as healthcare, we are inevitably faced with the challenge of working with these folks and learning from and leveraging their work. We can’t simply take a colonialist mindset into their midst, displacing their work and knowledge and the leverage that goes with them. That would be a huge mistake.
But how do we avoid that mistake? There are four keys to extension—four things that systems engineers must do to successfully integrate into the healthcare process design and improvement field while bringing to bear the advantages and leverage of “overt” and intentional systems engineering.
1. Respect
First, systems engineers must respect the existing work and knowledge base. The people who are currently designing and improving healthcare processes are taking approaches that they have selected or constructed for specific reasons. Those reasons are tailored to their domain. Some are far from perfect. All involve advantages, disadvantages and trade-offs. Systems engineering will have much to offer and has the potential to improve and refine the existing approaches. But that offering must be made from a place of respect and not by simply shoving aside what we find already in place. Building relationships with incumbent professionals will allow the kind of dialog that will foster cooperation and integration of systems engineering methods and tools into their existing practice.
2. Translate
The second task, to translate, is related to the first. A key part of respecting the incumbent designers and their practice is owning the duty to translate systems engineering concepts and processes into language that allows the incumbents to understand the relationship between their work and systems engineering. Using the “foreign” language of traditional systems engineering domains with the areas into which we are trying to expand is both counterproductive and disrespectful.
3. Reflect
As we begin to work in these new domains, we must learn to reflect back what we are hearing. Process owners and designers need to move with us in a step-by-step way through our analysis and design decisions. The only way this can take place is if we are completely open in sharing our understanding of what they say about their own systems and our thinking about potential solutions. If we simply gather information about a problem, construct a solution and report it to the domain experts and owners, we can’t avoid the appearance of intermeddlers supplanting their judgment with our own. To avoid that, we must reflect our understanding of the problem they describe, the constraints that exist, the resources that are available and our thinking about how to proceed.
4. Iterate
The fourth and final principle is that we must learn to iterate and refine our reflections to the stakeholders. This means, for example, iterating our understanding of their descriptions of existing systems and processes. The iteration should elicit comments that spawn refinements. They continue until the stakeholders say “Yes. That is our system/process.” At that point there is a reasonable assurance that the systems engineer and the stakeholders have a common understanding upon which to build their problem-solving efforts. The same principle holds true for the solution process. As the granularity of the systems solution definition increases, the iteration process keeps the stakeholders on board and allows them to participate in the design.
By implementing these four key practices, systems engineers working in new market spaces can bring to bear the advantages and leverage of the systems engineering discipline. While the specific benefits are too numerous to treat in a blog post, they fall into three major categories.
Integration
The first is integration. For example, instead of seeing process as an independent consideration targeting a specific set of problems (cost, efficiency, compliance, etc.), integration establishes its relationship to all of the organizational outcomes. Integration reveals the impact of the system architecture on the processes it performs. The understanding of this traceability from outcomes through process into architecture and back again is often a new concept in domains where systems engineering has not been overtly practiced.
Insight
Out of integration arises the second category of benefits—insight. Many understandings emerge from the integrated view. Undesired (or undesirable) outcomes can be seen as the product of processes produced by the systems architecture. The realization that changing processes requires changing structure becomes clear when seen from an integrated point of view. These are not necessarily obvious to approaches that have attacked processes or structures in relative isolation.
Expression
The third category of benefits come in the form of new ways to visualize or express the problems and/or solutions. Particularly where the systems engineer uses a model-based approach there are a wide variety of ways to present the data captured in the model. This can include the problem space, the existing system, and the potential solutions. The form of expression can be tailored to the audience. Systems engineers can enable stakeholders, domain engineers and subject matter experts to “see” the model in the way or ways most understandable to them. This is a particularly powerful set of benefits.
By practicing respect, translating systems engineering concepts, and understanding into the language of the stakeholders, and by reflecting their understanding in an iterative way, systems engineers can gain entrance into new domains. In that way they can bring the benefits of integration, insight and expression to a new set of stakeholders. That is an effort worth the undertaking.
(For a fuller treatment of these concepts, including application examples drawn from the healthcare delivery process domain, join us for our Healthcare Webinar on Thursday March 8 at 11 AM (EST). To register, go here.)
