The Power of Systems Engineering

Posted on November 14, 2014 by Craig Louie

The Problem

Complexity is increasing everywhere, with increased software, connectivity, public policy issues, and development cycle acceleration. The trend is to add features and functionality, often implemented in software. Software size and complexity are growing exponentially, with the marriage of hardware and software enabling systems-of-systems – with examples being portable phones or airliner cockpits.

New integration problems result from combining rapid technological advancement and obsolescence, increasingly complex hardware and software evolution, and a migration to increasingly software based systems. Yet an increase in software leads to increased interfaces and an increase in integration problems. Software interfaces are not as “transparent” as mechanical interfaces and go beyond inputs and outputs. Additionally complex system interfaces are crossing multiple suppliers, both hardware and software. Overall the trend is that it is not going to get better, it is only going to get worse as software lines of code increase, and integration, verification and validation efforts also increase.

Success is getting harder in the “New Normal”.

50% of product launches fail to live up to company expectations
33% of new products fail to provide a satisfactory return
70% of resources spent on new launches are allocated to products that are not successful in the market
80% of projects cost 20% more person-hours to launch than initially forecast

Problems that arise from unmanaged complexity are no longer affordable. For example there were 18 million vehicle recalls in the US in 2012, which is more recalls than vehicles sold, and each recall costs $100/vehicle/recall leading to $1.8 billion in direct costs!

The Solution

The Systems Engineering Approach is the most effective way to manage complexity and change. Reducing the risk associated with new systems or modifications to complex systems is one of the primary goals of the systems engineer. Solving problems early in the development cycle saves enormous costs and time in the later phases of development. Costs and schedule overruns lessen with increasing systems engineering effort.

Things that go wrong include:

Weak or non-existent basis to requirements
Inadequate costing and time-scale estimation
Weak control of suppliers and subcontractors
Integration problems
Inadequate test and acceptance strategy

The project who’s turn to be “it”:

Scope problems
No overall orchestrated cracking of the whip
No idea of costs at the outset
No system-wide vision
An ‘odds and sods’ approach
Bitten by unproven technology

Hidden benefits:

Risks that didn’t materialize
Rework that didn’t need to be done
Customer complaints that didn’t occur
Product deficiencies that are circumvented

Engineering roles are changing – what an engineer does and is expected of an engineer now includes broader market, financial and social issues.

It is difficult to train good systems engineers and foster “systems thinking” and get organizations to apply the “systems approach”. The systems approach has both an art and science component to it, and like similar disciplines like medicine, it can be taught by expert practitioners, typically from industries that successfully develop complex systems.

Whether you are developing a product or a process, a well implemented systems approach produces superior performance.

Why are Kei cars so popular in Japan and will they be popular elsewhere?

Posted on October 8, 2014 by Craig Louie

During my stay in Japan, small 660 cc engine Kei-cars are very noticeable, especially in the more rural areas. In the past few years in Japan, approximately 40% of new cars sold are Kei cars.

Kei cars are very popular in Japan because they are inexpensive – about half the price of a Prius, they get the same fuel economy as a Prius, they are very practical and roomy, they are easy to park in crowded Japan, and they have lower taxes and licensing costs. Women make up approximately 65% of the owners, and in some Prefectures, 99% of households own one, often as a second car. They are more popular in rural areas as compared to a big city like Tokyo, where it is more convenient to take public transit and owning a car is not as necessary as a more rural area.

Kei cars are not planned for the US or Canada because small cars are not really popular here, nor would they meet the US or Canadian safety standards because of their small size and lightweight build. The safety of Kei cars is not much of a concern in Japan, because road traffic accidents are amongst the lowest in the world in Japan (about 1/3 the victim rate of the US), and continues to drop every year, even with so many Kei cars on the road. Japan has good road safety measures, good driver training, and Kei cars are more popular in the more rural areas where road speed tends to be lower (though Japan has the highest rate of elderly traffic deaths at 54% vs. the US at 17%).

The Kei cars in Japan are made by all the major Japanese auto manufacturers, and they are becoming increasingly loaded with high technology based on customer demand – turbochargers, infotainment systems, airbags, remote controlled doors, keyless start, collision avoidance systems, CVT, and four wheel drive.

One of car reviewers I like is Bertel Schmitt, of the Blog “The Truth About Cars”, and he writes a pretty good review of a typical Kei car. It is a positive review for its market segment.

The Japanese Government is concerned that the Kei cars are too popular in Japan, as they not manufactured for export, because of their small size and insufficient safety equipment. The Japanese Government would prefer Japanese automakers to develop “world cars” for the economies of scale to compete in the Global market. Therefore, the Japanese Government has raised taxes on the Kei cars in 2014 and plans further tax increases in 2015.

One advantage of these small cars is that they contribute to lowering the amount of oil imports into Japan. At current oil prices, Japan has a net outflow of $100 billion/year from their economy from oil imports. The automotive sector in Japan has been steadily lowering its oil consumption over the past 10 years.

Honda is planning to raise their production from 4 million cars today to 6 million by 2017, and they see these minicars as one of the main ways to do achieve their targets by targeting markets in India or Southeast Asia. They will then be able to realize a return on their Kei car technology investments.

I think Honda is on the right track. The Japanese market is purchasing Kei cars much more than expected because for a large percentage of Japanese consumers – especially younger people, women, families that need a second car, small business owners, and rural areas – these vehicles make sense. Even with the 2014 Kei car tax increases, Kei cars are up 12% year to date over 2013, and higher than forecasts. While the numbers may drop with the 2015 Kei car tax increase, Kei cars have gone from a car to settle for to a desired car. There will be many world wide markets that have similar conditions where these cars, or similar minicars will make sense.

I don’t expect Kei cars will come to the US or Canada for a long time, if ever. In the US and Canada, the safety standards are not going to change, small cars are not popular, and fuel and other operational costs are relatively low compared to many other countries.

Honda has also introduced their S660 Roadster which they plan to introduce in 2015 as a Kei car for Japan, and perhaps with a 1 liter motor for other markets. I’ll be interested to see how this vehicle sells.

How useful is the free, open source Scilab/Xcos vs Matlab/Simulink?

Posted on September 8, 2014 by Craig Louie

One of my clients has requested a dynamic fuel cell power system model, so I investigated both Matlab/Simulink and Scilab/Xcos modelling environments. These packages are able to model complex electrical power and control systems using a graphical block diagram modelling tool. Here is an example of Xcos’ DC DC Boost Converter:

Xcos DC DC Boost Converter

To model the fuel cell power system in Matlab/Simulink requires the addon toolboxes SimPowerSystems and SimScape. This raises the license price to about $12,000 USD plus further yearly license fees (~20%). An advantage of Scilab/Xcos is that the software is free. Simulink/SimPowerSystems has a more extensive library of predefined component or subsystem models than Xcos, yet Xcos has the most important components defined. Simulink/SimPowerSystems has much better documentation, which is typical of commercial software vs open source software. There are some Xcos documentation and tutorials available, covering the most important topics.

I had difficulties getting both packages up and running on my Windows 7 computer as in both cases there were problems in getting external C compilers connected. With Matlab, I was able to go back and forth with their helpful customer support to resolve the issue. With Scilab, I had to do internet searches for forum posts by other users with the similar problems. In both cases I was able to get the packages running with some delay. Matlab has better user support as it is easier to call someone for help, but Scilab has a fair number of users posting problems and solutions, and with a bit of sleuthing, resolving my problem was not too difficult.

Working inside the environments is pretty similar. Simulink/SimPowerSystems has the most capability, yet Xcos is impressively capable, with more and more tools being published by their user community. Perhaps Xcos is roughly 80-90% of the capability of Simulink/SimPowerSystems for my application, and good enough for what I need at this time.

One further advantage of Xcos is that it is much easier to share models, as it is easy to get access to the modelling environment. With Matlab/Simulink, you really need your other collaborators and clients to have Matlab/Simulink available, and that is an expensive proposition, especially being tied to yearly maintenance fees.

Xcos is steadily improving in capability, documentation, tutorials, and links to other programs. It has come a long way in the last three years. By being free, it is more accessible to a larger community, which will help accelerate its development and usefulness through the network effect. For many practitioners, it is a great choice.

Matlab/Simulink will have some threat from Scilab/Xcos in the lower end of the market, yet I expect it to lead the high-end market as it continues to add capability, modules, applications, and linkages to other programs. For larger institutions, it is a good choice.

Product Comparison for my application

Overall I am pleasantly surprised and impressed with Scilab/Xcos, and while it takes a little more time and effort to be productive with it than Matlab/Simulink, for my application, it is worth it.

Movie Review: The Challenger Disaster

Posted on July 5, 2014 by Craig Louie

9/10

This excellent 90 minute movie brings to life the great story of Richard Feynman’s investigation into the Space Shuttle Challenger disaster. I found the movie had good pacing, rang very true to what actually happened, and had very good acting by William Hurt as Feynman, Bruce Greenwood, and Brian Dennehy.

The movie is based on Feynman’s book “What Do You Care What Other People Think”, which is also a terrific book. The story follows Feynman’s instrumental role in uncovering the truth about the root cause of the disaster – both technically and politically. Feynman’s personal heroism against strong headwinds and personal illness makes for a compelling story.

The movie does great justice to key scenes – the dramatic O-ring experiment, the personal difficulties of Feynman, to the political conspiracy surrounding and both supporting and opposing his investigation.

William Hurt’s performance was able to draw me in emotionally into the story. I’ve not really been a big fan of William’s performance in other movies, as I didn’t like him as Duke Leto in Frank Herbert’s Dune (too stiff), and he was ok in Dark City. Yet in this movie he was able to capture Feynman’s unique character very well.

The movie inspired me to re-read “What Do You Care What Other People Think?”, which I had read over 20 years ago. The overall story of Feynman and the Challenger continues to be sharply relevant today with widespread complex system development, that have significant safety consequences, large multi-stakeholder interests, often conflicting, and sometimes these interests are inclined to bury the truth.

One of the most interesting short stories in “What Do You Care What Other People Think” is the story of Richard, and his first wife, Arline. It is a great love story, despite its tragic nature. The book’s title came from her.

This movie (and book) is highly recommended!

For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. – Richard Feynman

Is your Complex System Project on track for Ultraquality Implementation?

Posted on June 29, 2014 by Craig Louie

We expect complex systems like an airplane, a nuclear powerplant, or a LNG plant to practically never fail. Yet systems are becoming increasingly complex, and the more components there are in a system, the more reliable each component must be, to the point where, at the element level, defects become impractical to measure within the time and resources available.

Additionally, in future, our expectations will increase for complex systems durability, reliability, total cost of ownership, and return on investment, as energy and raw materials increase in cost.

Ultraquality is defined as a level of quality so demanding that it is impractical to measure defects, much less certify the system prior to use. It is a limiting case of quality driven to an extreme, a state beyond acceptable quality limits (AQLs) and statistical quality control.

One example of ultraquality is commercial aircraft failure rates. Complexity is increasing: the Boeing 767 has 190k software lines of code, whereas the Boeing 777 has 4 million lines of code, and the Boeing 787 about 14 million lines of code. The allowable failure rate of the flight control system continues to be one in 10 billion hours, which is not testable, yet the number of failures to date is consistent with this order of magnitude.

Another example of ultraquality is a modern microprocessor, which has the same per chip defect rates despite the number and complexity of operations have increased by factors of thousands. The corresponding failure rate per individual operation is now so low to be almost unmeasurable.

What are the best practices to achieve ultraquality in complex systems?

Meier and Rechtin make a strong case that while analytical techniques like Six Sigma and Robust Engineering Design will get you close, the addition of heuristic methods will get you over the top. This includes using a zero defects approach not only in manufacturing, but also design, engineering, assembly, test, operation, maintenance, adaptation, and retirement – the complete lifecycle.

There are many examples how analytical techniques alone underestimate failure; for example the nuclear industry analysis of core damage frequency is off by an order of magnitude in reality.

A sample of applicable heuristics include:

Everyone in the production line is a customer and a supplier [also extended to each person in the development team – engineering, supply, etc.]
The Five Why’s
Some of the worst failures are system failures
Fault avoidance is preferable to fault tolerance in system designs
The number of defects remaining in a system after a given level of test or review (design review, unit test, system test, etc.) is proportional to the number found during that test or review.
Testing can indicate the absence of defects in a system only when: (1) The test intensity is known from other systems to find a high percentage of defects, and (2) Few or no defects are discovered in the system under test.

[pie chart courtesy Boeing. FBW = Fly By Wire]

There is a lot more material on “how-to” in the works of Meier and Rechtin, Juran, and Phadke.

Ultraquality requires ultraquality throughout all the development processes, and by extension throughout the delivering organization. That is, certify a lack of defects in the final product by insisting on a lack of defects anywhere in the development process. Developing both the processes and organization to achieve this state is possible, is being done in some organizations, and allows for superior business performance.

There are many examples how organizations lack ultraquality in their processes or organization. General Motors is under heavy criticism these days following the Valukas report, which exposes the poor organization and development practices. This is anecdotally impacting the GM dealers and turning them into ghost towns.

So back to the tagline: is your complex development project on track for ultraquality implementation?

Model Based Systems Engineering Readiness for Complex Product Development

Posted on May 22, 2014 by Craig Louie

The increasing nature of complexity of today’s systems and systems-of-systems make it increasingly difficult for systems engineers and program managers to ensure their product satisfies the customer. As an example, in this year alone, General Motors has recalled more vehicles in the US than it made in 2009 to 2013 – and it is only May!

May 21, 2014, http://www.huffingtonpost.com/2014/05/21/gm-recall-more-than-sold_n_5367478.html

Over the past 5-10 years, a formal discipline of Model Based Systems Engineering (MBSE) has been developed by the Systems Engineering community to catch up with rigorous model tools available to the other domains, such as CAD/FEA for mechanical engineering, or VMGSim/Hysys for chemical engineering, or C++ code generators for software development.

The combination of increased complexity, increased domain model usage, and drive towards virtual product development and simulation capability have made it very difficult to make sure there is consistency in all the models, documents, and data sets for a complex product. Without one single truth in the data set, there is increased likelihood of downstream problems. MBSE is now in a position to allow systems engineers develop a rigorous coherent flexible system model that can be an integrating design and development function across the program lifecycle, enabling this future vision:

Source: INCOSE MBSE Workshop, Jan 2014

The main benefits of MBSE are:

Reduced rework, earlier visibility into risk and issues
Reduced cycle time, reduce development cost, cost avoidance
Better communication and more effective analysis
Potential for increased re-use (product line reusability: engineering done once, reuse elsewhere)
Ability to generate and regenerate current reports and work products
Knowledge management (long-term and short-term)
Single source of truth
Competitiveness (our partners and competitors are doing it)
Think about how much of an engineer’s time is spent on data management rather than critical thinking (Change that ratio! Shift the nature of my hours)

While models have always been a part of the document-centric systems engineering process, they are typically limited in scope or duration, and not integrated into a coherent model of the entire system.

MBSE uses a graphical modelling language, called SysML, which is an extension of UML (Universal Modelling Language) developed by the software industry. The SysML language and a MBSE modelling tool allow systems engineers to develop descriptive models of the system. As an example:

Source: INCOSE MBSE Workshop, Jan 2014

There are several MBSE tools available, Rhapsody (IBM), MagicDraw (No Magic), and Enterprise Architect (Sparx). These tools have been successfully been used by companies like Ford, Boeing, or Lockheed Martin, and they continue to improve. MBSE is still relatively early in development as compared to other domain tools, like CAD, FEA, or PLM (Product Lifecycle Management), but is now at a stage that it can have an immediate impact on the developing system. There are many connecting tools to PLM tools or Requirements Management tools like Rational DOORS or other disciplines.

I have found it really tough (and to a certain degree impractical) using the document-centric systems engineering approach to keep all the various design documents and models up to date and consistent with each other. I’ve been using MBSE tools from both NoMagic and Sparx, and they are both pretty good at capturing all the necessary systems engineering information in one model. There aren’t many good tutorials and examples available to the public domain, but still enough to learn from. I have been able to steadily and productively apply MBSE to my system design and analysis work.

I highly recommend any organization that is doing complex product development to consider MBSE. It is the future for fast and high quality product development.

Winning Strategy for Canada’s Hockey Gold

Posted on February 24, 2014 by Craig Louie

Canada’s Men’s Hockey team won gold in the 2014 Sochi Olympics yesterday with both a winning strategy and a committed execution of that strategy.

Until the final game and result, it was not fully clear what their strategy was, nor whether it would meet the goal of a gold medal. The Canadian team was clearly loaded with scoring talent, but so were the Americans, Russians, Swedes, and Finnish teams. The International Ice Rink size is larger than the NHL rinks, which changes the game to require faster skaters and skill players, and is the development environment for the European Hockey players. In the first four games of the tournament for the Canadians, they did not score as many goals as expected with only a 2-1 overtime win vs. the Finns and a 2-1 win over Latvia. The US team had been scoring on average 5 goals per game over their first four wins, including a 5-2 win over the Czech team in the Quarterfinals.

The Semi Finals

The story going into the Semi-final game between the US and Canada was that the Canadian team was slightly stronger overall on paper, with a little more depth, but that the US team was clearly playing much better. Analysts were pretty split on who would win, as they seemed evenly matched, the outcome was difficult to call, and if anything the momentum seemed to be on the US side.

The Canadians won the game 1-0, and while the score was close, most observers commented that the Canadian team was pretty dominant defensively, and the American’s really struggled to get any sustained pressure or second chances.

The Bronze Medal Game

The American’s went up against the Finns in the Bronze medal game, and again were favoured, because the Finnish team was not as talented or deep, with only about half their roster from the NHL. The American team was embarrassed 5-0, and went home without a medal. In this game, the Finnish team showed that when they play their European style of hockey they are very strong, and the US team showed that a lack of heart, intensity, and poise, and fell apart.

The Gold Medal Game

Going into the Gold medal game, again, there were many doubts on whether the Canadians would win. The Finnish team showed the night before that the European style of hockey can demolish a more talented US team. The Swedish team was stronger than the Finnish team, and beat them 2-1 in the semi-finals. The Canadians still seemed to have trouble scoring goals, though had also been demonstrating very few goals against. The Canadian goaltender, Carey Price, had not been tested much in the tournament, and had not had to make that many difficult saves, whereas the Swedish Goaltender, Henrik Lundqvist had seemed to have demonstrated stronger performances in the past 5 games. Overall the story going into the game was that either team had a good chance of winning.

The Canadian’s won 3-0 in a dominating, clinical performance and won Gold.

The Strategy

The medal was won with a complete commitment to a team defense model that emphasized offensive puck possession. It was not a sit back and turtle team defense. Instead it relied on a combination of the forwards coming back to help the defense when the other team had the puck, and then when the Canadians had the puck, they kept it as much as possible through puck possession, strong backcheck and forecheck, and help from the defensemen in the attacking zone. The Canadian’s scored only 17 goals in 6 games the 2014 tournament, whereas in the previous 2010 Olympics they scored 35 goals. But in the 2014 Olympics, they only allowed 3 goals over those 6 games, and had two shutouts in the semi-final and gold medal game. While they did not score a lot, they didn’t need to. The other teams really could not generate sufficient chances against the Canadian team.

Defense wins championships.

This strategy was unrolled to the team in August 2013 at the Calgary training camp, and used Ball Hockey to demonstrate the system of team defense. They had to use ball hockey because for insurance reasons they couldn’t use an ice surface.

During the Olympic tournament, observers could see that the players had totally bought into this system, from their between game interviews, to their short shifts, to their selfless play.

“It was a feeling of absolute trust,” was how Jonathan Toews described the feeling of being one of Canada’s team members. “As soon as you jump over the boards you’re going out there to do the exact same thing the line before you did, and to keep that momentum going. Even when we got up two goals, we never stopped. We just kept coming at ’em, backchecking, forechecking. We didn’t give ’em any space. It was fun to watch and fun to be a part of.”

“That’s why we won,” said Steve Yzerman, the architect of a golden back-to-back. “Our best players said, ‘Guys, we’re going to win. We don’t care about individual statistics.’”

Mike Babcock, the Team Canada coach, said as much before he left a post-game press conference to partake in the closing ceremonies.

“Does anybody know who won the scoring race? Does anybody care?” he said.

The answer to those questions were, for the record: Yes, Phil Kessel. And, um, probably not.

Babcock continued.

“Does anyone know who won the gold medal?”

Babcock wanted a point clarified, mind you, when the talk turned to defensive genius. It should be remembered that Canada, he essentially said, wasn’t partaking in Euro-brand defensive hockey. Canada wasn’t mimicking the bronze-winning Finns collapsing in a shell around Tuukka Rask, begging you to beat one of the world’s best goalies from beyond the human blockade.

“When we talk about great defence, sometimes we get confused,” Babcock said. “Great defence means you play defence fast and you have the puck all the time so you’re always on offence. We out-chanced these teams big-time. We didn’t score (as much as they would have liked). But we were a great offensive team. That’s how we coached it. That’s what we expected. That’s what we got. We didn’t ask guys to back up.”

“Canada was much, much better,” said Marts, the Swedish coach.

Concluding remarks

There were high expectations placed on the Canadian team, and a nervous concern through the first four games of the tournament. The only revealing of the strategy during the tournament was what we saw on the ice during the games. After the gold medal game was won, the team revealed the thinking behind their brand of team defense system, and their strategy became clear. It is never good to be to clear about your strategy during the tournament, as it can be countered by your opponents.

While execution of the strategy on the ice was an important part of the result, developing the team first culture was an inherent part of the strategy and improved the likelihood of executing the system on the ice. We all know that a coherent high performing team always outperforms a looser collection of individuals. In this case, the strategy of how to develop that team and the system of play during the games was a strong key for winning Gold.

Insight and Heuristics in System Architecting

Posted on February 14, 2014 by Craig Louie

One insight is worth a thousand analyses

-Engineering and Art: Iron Man 3

Systems Architecting is as much art as it is science. The best book on this subject is from Maier and Rechtin, and I highly recommend it.

-Maier and Rechtin, The Art of Systems Architecting, second edition, CRC Press, 2000

One of the best section of the book deals with using the method of Heuristics in architecting. Insight, or the ability to structure a complex situation in a way that greatly increases one’s understanding of it, is strongly guided by lessons learned from one’s own or others’ experiences and observations. Given enough lessons, their meaning can be codified into “heuristics”. Heuristics are an essential complement to analytics.

As in the previous post, where the system engineer is to consider the whole and apply wisdom, Maier and Rechtin also promote the use of wisdom but they note that “Wisdom does not come easy”

Success comes from wisdom
Wisdom comes from experience
Experience comes from mistakes

While required mistakes can come from the profession as a whole, or from predecessors, it also highlights the importance of systems engineering education from those skilled in the art.

Examples of heuristics are:

Don’t assume that the original statement of the problem is necessarily the best, or even the right one
In partitioning, choose the elements so that they are as independent as possible; that is elements of low external complexity and high internal complexity
Simplify. Simplify. Simplify.
Build in and maintain options as long as possible in the design and implementation of complex systems. You will need them.
In introducing technological and social change, how you do it is often more important than what you do
If the politics don’t fly, the hardware never will.
Four questions, the Four Whos, need to be answered as a selfconsistent set if a system is to succeed economically; namely, who benefits?, who pays? and, as appropriate, who loses?
Relationships among the elements are what give systems their added value
Sometimes it is necessary to expand the concept in order to simplify the problem.
The greatest leverage in architecting is at the interfaces.

-taken from Maier and Rechtin, The Art of Systems Architecting, second edition, CRC Press, 2000

Heuristics are tools, and must be used with judgement. The ones presented in the book are trusted and time-tested. They may not apply specifically to your complex systems architecting work, though I think you will find most of them do.

Just Enough Systems Engineering

Posted on February 9, 2014 by Craig Louie

I’ve been putting together a teaching course on Systems Engineering, and I came across a gem of an eBook by Dwayne Phillips, called “Just Enough Systems Engineering”. I have found it very useful reference to help me develop the course, as it is filled with systems engineering wisdom.

There is large amount of systems engineering material available from various sources – from Incose, many books, many presentations, and many research papers. It can be hard to summarize the large body of knowledge into a useful teaching course. I find this eBook unique in that is comes from the angle of how to use systems engineering practices from a very practical perspective. And it is free!

http://dwaynephillips.net/systemsengineering/JustEnoughSystemsEngineering.pdf

There are many quotations in the book that I find very useful:

What does a systems engineer do?

“The systems engineer examines the entire system and applies a little wisdom.”

I think this is a good perspective as it helps simplify a very complex topic and help a practicing systems engineer remember the importance of using good judgement, which typically comes from experience – both of the practicing engineer, and any learnings from the experience of others.

When and how much systems engineering to apply

“Use systems engineering when the system and project are bigger than any two people.”

The importance of asking questions in the best way

“Here is where much of systems engineering collapses.”

Systems engineers have to work with a wide variety of people –the client, the builder, the development team, etc., and asking questions of these people in the right way is a key skill. Many engineers have very strong problem solving skills. A systems engineer also needs strong people skills, and this eBook has a wealth of material on how best to ask questions in the systems engineering context. I haven’t found any other references that explain this angle well, and give very practical suggestions on how to succeed.

For anyone interested in becoming a better engineer, I highly recommend this eBook.

Systems Approach to Health Care

Posted on September 30, 2013 by Craig Louie

Applying a systems approach to health care significantly improves quality, speed, economics, and customer satisfaction. I have now experienced both the North American and Japanese Health Care Systems, and I can now see the clear benefits of the systems engineering approach applied to technology, activities, and people (i.e. using the Design Structure Matrix approach).

Figure 1 Personal Hospital Pager, Japanese Hospital

When you are a patient at a Japanese Hospital, you get a Personal Hospital Pager, so they can immediately notify you of your next diagnostic or consultation appointment and potentially slot you in earlier. Japanese hospitals operate like a modern manufacturing plant or logistics center with a fully integrated Information Technology System with all scheduling and results and reports in the digital domain. Japanese hospitals have all the diagnostic procedures in the hospital – MRI, CT, PET, etc., and the waiting times are so short, there isn’t really a wait time. The doctor is able to order all the necessary diagnostic or treatment procedures from her PC and you basically go from one station to another in the hospital all in one day.

Figure 2 Personal RFID Card and Diagnostic Schedule

As a patient, you also get a Personal Card with a RFID chip that stores key data (Fig 2, middle left) and a printout of your daily schedule, in this case seven diagnostic or consultative events. In Canada, it is often weeks between each event, and sometimes much longer, such as for a MRI or CT scan.

From a patient perspective, the speed and very short delay times is both comforting, and must increase the likelihood of successful treatment for any degenerative disease. From a macro perspective, a comparison of health care systems bears this out.

Figure 3 Health Care Systems Comparison

What is striking for Japan is the relatively low health care expenditure, good results in life expectancy or infant mortality, the high amount of diagnostic equipment, the number of hospital beds with a typical nurse count, the low amount of “out-of-pocket payments”, and the short wait times. A MRI here is about $100, vs. $1500 in the US. For major surgery, in Canada you stay in the hospital for 5-6 days, in Japan, you come in 2-3 days before and you stay 21 days until they are really, really, sure you are ok (with lots of diagnostic tests). Patients that have experienced both the Canadian and Japanese system very much prefer Japan.

How can the Japanese System be so good and efficient? While Japanese people may be more fit and have a better diet than North Americans, they are also one of the fastest “greying” populations, and smoking is more prevalent in Japan than in North America. After experiencing this system first hand, the high level of integration, full information technology system, modern logistics/manufacturing process, competition between hospitals, and overall design of the system to keep results high and costs low, have forced process innovation in the right areas. Is the Japanese System perfect? Not by any means, but compared to North America, it is at another level.

There is great benefit to applying the systems approach to any system. In case of the Japanese Health Care System, it even includes ensuring the political side is appropriately managed. When the Japanese physicians tried to game the system by ordering more MRI’s, the next year, the Japanese Government lowered the MRI fee by 35%.

Figure 4 Automatic Reentry

While there are many administrators and health care professionals and technicians at a Japanese Hospital, there are also automated kiosks everywhere for many procedures, such as checking-in, paying any out-of-pocket expenses, urine tests, etc. which makes the whole time spent at the hospital very smooth and efficient. You put your Personal RFID card from Figure 2 into these kiosks, complete your procedure, your card and file is updated, and move onto the next station.

For Health Care, the system design is kind of easy. We experience full IT tracking systems in our daily lives, like Amazon.com’s reviewing, inventory, purchasing, and packaging tracking systems. We know that modern manufacturing process logistics systems exist. We have ways of measuring results, like outcomes, wait times, or customer satisfaction. Japan has integrated these best practices into a low cost system. It is just good business, and a good human system. North America needs to shamelessly borrow this better system from Japan, and tailor and improve where necessary, as was done with the Taguchi Quality method etc.

The SysEne Blog

Systems thinking for the real world