Systems engineering E-Book

Nicolas Godlewski

• Herausgeber: Books on Demand
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 240

Veröffentlichungsjahr: 2020

Beschreibung

Designing complex systems is about integrating multiple components, but the main challenge is human rather than technical. A technical interface between components A and B requires a human interface between the designer of component A and the designer of component B. When the skills and competencies are multiple, when the teams are split over different departments, if not different companies, they will speak different languages. How can they work together if they don't understand each other? In this book, we will raise awareness of the risks on misunderstandings when teams from different background collaborate on a complex system. We will analyse how it impacts systems design, and propose managerial solutions to handle those risks.

Leseprobe

Table of content

Introduction

Communities and languages

Communities

Linguistics

Finding the right name

Designing a system

Use case 1: brakes

Use case 2: lockers in touristic areas

Points of view

Interrelated systems

Designing a system organisation

Who’s in charge?

Mirroring

Systems organisation

Conclusion

Introduction

There’s a lot of literature on Systems Engineering. There are some methodology books. There are trainings, undergraduate or graduate. There’s an international council (INCOSE). And even a norm, ISO15288. Many businesses talk about it. And yet, it’s very hard to find an agreement on what it is. Some say there is no such thing, today, as real Systems Engineering. Some say everybody’s been doing systems all their lives, but they just didn’t call it this way. There are jokes on professional networks that if you gather 10 systems engineers to agree on what a system is, you will get 11 definitions.

Systems methodology has been described over and over, and yet, it is still hard for non-expert to grasp what this is all about. Some team members report that the department should do systems? Other team members report they’re already doing systems? External consultants propose to help you manage your systems? They all have a clear vision for you, they’re all consistent, but they also all use the word systems differently.

As the saying goes, when everybody is in charge, nobody is in charge. When everybody has a different understanding of “Systems Engineering”, nobody understands it. Before applying any kind of system methodology, it’s mandatory to ensure there is a common language between the teams.

Stephen Hawking said the greatest enemy of knowledge is not ignorance, it’s the illusion of knowledge. Applied to team’s collaboration on complex systems, the greatest enemy of understanding is not misunderstanding, it’s the illusion of understanding.

To ensure efficient delivery of a large system, it is necessary to ensure efficient communication, which means ensuring good understanding between teams. This good communication requires the right organisation, the right interfaces between teams. Systems Engineering is supposed to manage these interfaces, but the word System is a perfect example of the “illusion of knowledge”. Systems Engineering is understood differently by different teams. If the team don’t even agree on what the methodology means, how can we be sure they will agree on the product they’re working on?

The objective of this book is to raise awareness on the risks of misunderstanding, and to propose solutions to handle these risks, using tools to set up an organisation where teams robustly understand each other. This is why I’ve chosen to write a book about language and engineering. With linguistics as our guideline, we will lead the way towards better engineering through better communication between teams.

In a first section, to clarify what “better communication” means, we’ll first have a look at the importance of language, which relies on context, mindset, non-verbal exchanges as much as words, maybe more.

We’ll then see what it implies on defining a system, by looking at a few examples. We will see that a good definition is not just words, because words can be interpreted differently. A good definition is a complete description of the context.

In a third part, we’ll give practical tools to set up an organisation where teams from different background can understand each other, a prerequisite for efficient collaboration.

Communities and languages

People speaking the same language form a community. People gathered in a community need a language to communicate. We can’t talk about one without the other. We’ll start by looking at communities, why they need language, and then we’ll see the importance of language, from a practical and theoretical point of view. All this information is general, not specific to Systems Engineering, but the awareness of the traps of language and the understanding of how the principle of communicating through language will help us understand the constraints of Systems Engineering.

Communities

Human villages (or businesses)

In a small village, everybody knows what everybody else does or can do. Back in the days, jobs or skills were part of the names, which is why there are many Smiths and Coopers as last name. Today, it’s less obvious, and in towns or cities, or in medium to large businesses, it’s not easy what is everybody’s role.

Knowing naturally what everybody’s role is requires a special condition, size matters. In a small group, like a small village, all the villagers know each other. But the larger the group becomes, the more difficult it is to know everybody.

The threshold to manage direct relationships between members of a group is around 150 (for humans). Below this number, any individual can manage to know about everybody else. It’s not necessarily a close relationship, but it’s still a relationship. Above this threshold, individual one to one relationships can’t be sustained.

The same number shows up in different areas, for instance in management (maximum size for a department) or in military organisation (maximum size for a company).

It comes from experience, but there is also some science supporting it. Anthropology studies our primates cousins or our ancestors. Analysing several different primate species, research showed there’s a correlation between the group size of a species and its brain structure; more precisely, the size of the neocortex. The neocortex is the part of the brain managing high level functions, such as spatial reasoning or language. When the neocortex represents a large portion of the brain, individuals can successfully manage more parallel relationships (Dunbar 92), and the maximum size of a manageable group will be higher. The more intelligent a species is, the bigger the groups it can manage. The individual “brain power” enables the “collective power”.

For homo sapiens, based on human neocortex ratio, theoretical estimations predict 148 individuals in a group. This value is confirmed by observation of hunter gatherers population, with an average group size of 153, giving a good level of confidence on this socio-biological threshold, confirmed by business experience.

When the group exceeds this size, it requires an additional level of organisation. In the history of the human race, there is evidence that the need for management of larger groups led to the rise of language. When the groups were small enough, individuals would socialise through direct contact, with activities such as social grooming for instance. Grooming has health benefits of its own, but grooming another member of the community is also a way to build relationship. It can also be used as a conflict resolution tool. Our close cousin bonobos also use sexual intercourse as a conflict resolution tool. (Note that we will definitely not recommend grooming or sexual intercourse as a conflict resolution tool in a business context, even in small businesses).

In larger groups, it was not possible anymore to use this kind of tools. Verbal communication became necessary to enable exchange in the group or to resolve conflicts. The growth of the groups size, enabled by enhanced cooperation and the shift from foraging to farming, may be the reason for the apparition of language. However, we must admit this is only one of the many theories regarding the origin of language, and it is widely disputed. The origin of language is so controversial a topic that the Societé Linguistique de Paris (Paris Linguistic Society) simply banned it when it was created in 1866 (Article 2: the society forbids any communication regarding the origin of language or the creation of a universal language).

However it appeared, language was a new way to exchange information within a group. Language is not specific to humans. Different species also have some kind of languages, from our primate cousins to the much more basic insects such as ants or bees.

The specificity of the human language is its capacity to describe not only the things which are, but also things with don’t exist. Linked with language was the apparition of fiction, invented by homo sapiens. To enable collaboration within groups bigger than their brain can handle, populations have to share a myth or a belief, or a sense of belonging to a nation, or a purpose in a group enterprise (Sapiens, YN Harari). We won’t debate religions or politics here, and we’ll focus on businesses, but the concept is the same in all these different situations.

We use the word fiction here not as something which is false, but as something which is created by the human mind. A country can be defined by its boundaries and institutions. A business can be associated to its facilities and its products. Money can be implemented in coins and notes. But these concepts hold only as long as the group believes in it. If people stop believing in money, the coins and notes still exist, but they are not money any more, and become worthless.

Money is particularly interesting as a fiction. The first homo sapiens didn’t have money, they would exchange goods. When technology improved and there were too many goods to handle, it became necessary to introduce money to manage growth. Money, like language, is an invention of the humans to handle interactions between large groups.

Because of the limitation of the brain capacity, larger groups need a common fiction, and the language to describe it. However, that’s not enough. A larger group can’t be managed as a smaller group. Small tribes can be egalitarian, without a need for structure. When the group size exceeds its threshold, it has to be split into smaller groups. This leads to hierarchy as well as specialisation (Naroll 1956, Forge 1972). We are still citing anthropological studies here, but it does apply to gathering of humans in a community such as a business.

Hierarchy comes from the need of connecting and structuring the groups. Alternative to this structure is isolation, or even conflict between the groups. We’ll come back later to hierarchy, in the context of systems.

Specialisation is required for optimisation of a bigger population.

In old times small villages, everyone had a speciality. As the village is small enough, they could afford to skip the formal roles and responsibilities allocation. Any small business can also skip the structuring activity. Startups can bring incredible products and services with unstructured small teams. But there are things which require bigger structures. Apple has about 100 000 employees, Google more than 70 000 and Tesla has reached 30 000 in 2016 (from 3 000 in 2012, which was already much more than 150…)

Small businesses don’t have specialisation issues. Thanks to their small size, they can reach efficient interactions between their employees naturally. Interviewing engineers in various context, it appears clearly that the problems faced by organisations are very dependent on the size of the business. Some issues are universal, for engineers, and even for salesperson (define the problem before the solution), but lack of understanding or lack of communication between employees, is not something small businesses report as a priority.

However, if your company has more than 150 employees, direct communication won’t work any more. Obviously, it gets even worse, if your department within the company has more than 150 employees.

The transition from a small business to a large business is not easy. Similarly, the handover from a small team to a larger team, within a large business, does not come naturally. Usually, innovations are handled by smaller, independent teams in research department or in “innovation labs”. Their small size enables more flexibility, better efficiency between the team members. All the stakeholders can be gathered in one place. But once the innovation is defined, it needs to be transferred to the bigger team. Activities handled by less than 10 people in advanced engineering, to define the concept, may end up involving 200 engineers split across 10 departments, when the time comes for delivery, manufacturing, maintenance, etc.

What was done informally within the small group needs to be done formally for the bigger group. A small group will develop a common vision naturally. A bigger group needs leadership to cascade their vision. To reuse Harari’s vocabulary, the vision is the fiction which will join the whole group. To ensure smooth communication the fiction needs to be shared, through a common language, to enable connection of all the sub-groups. Language is of primary importance. In a small group, the vision is shared through direct interaction. In a large group, vision is transmitted through words, whether orally in conferences or in written form in documents. If the language used for transmission of information is not shared by all the employees receiving it, then the information will at best be lost, at worst be misinterpreted.

When we mention “common language”, we’re not referring to English or French. Even people speaking the same “language” can misunderstand each other because they use this “common language” differently.

When I started working, my first job title was “diagnosis expert”. As a young graduate, I had little idea of what “diagnosis” was. During my induction, discussing with all the teams involved in diagnosis, it became clear quickly that everybody had their own idea about what it was, but there was no unified vision.

For the electrical engineering team, diagnosis was just about communicating with Electronic Control Units (ECU). There was a standard protocol for “on board diagnosis”. If you’re using this protocol, you’re doing diagnosis, period.

For the manufacturing team, diagnosis was historically about end of line control of the newly build cars. The activity had evolved into more complex activities, such as programming ECUs or pairing smart keys, but electronic end of line activities was still mostly called diagnosis.

For the aftersales team, diagnosis was about solving the customer problem at the dealer. If you’re sick, you go to the doctor and they will do a diagnosis, and prescribe a treatment (medication, rest, surgery, etc.). Similarly, if your car is broken, you take it to the dealer and they will do a diagnosis, and prescribe a repair (part replacement, etc.)

Being at the center of these 3 worlds, Engineering, Manufacturing and After Sales, I gradually learned the different meanings, but it was clear that using the same word for different concepts could be a problem.

The focus at this time was the after sales. That was back in the early 2000’s, when the mechanical technicians were struggling with all the great electronic technologies engineers had introduced in the car.

When developing a new diagnosis tool for the dealer which embedded the service manual (diagnosis and repair methods), it took us month to realise that, even within the after sales department, the service manual team and the diagnosis tool team were talking about completely different things.

For the service manual team, anything electronic was diagnosis, anything mechanical was repair. For the diagnosis tool team, any information received from the car (either through a reading from ECU or through a manual control) was diagnosis, while any modification made to the car (either through a writing on an ECU or through a manual modification) was repair. Sometimes, their definitions matched (electronic diagnosis or mechanical repair). More often than not, they didn’t...

At some point, to identify without ambiguity what was being discussed, we talked about “diagnosis in the service manual meaning” or “diagnosis in the diagnosis tool meaning”. It was not very convenient, but at least prevented misunderstanding. As it was too long for everyday discussions, people tried to find some shorter expressions, but we couldn’t always agree on one.

Whenever we started to have discussion about which word to use in a given context, and we couldn’t reach a consensus, I started to propose some fancy words. I finally settled on one which is universal and can be used in any situation: smurf, as a reference to the language used by the Smurfs, those little blue creatures living in mushroom shaped houses.

Later on, I moved from the diagnosis world to the Systems Engineering world, where discussions on “what is a system?” and “what does Systems Engineering mean?” can be a full-time activity. Speaking the smurf language (basically replacing ambiguous words by smurf) was very helpful to move on from the “system definition” arguments, and start discussing real engineering.

To understand the benefit of the smurf language, it’s worth spending some time understanding language.

The smurf language

Reading a smurf cartoon, there is never any problem understanding what the Smurfs are saying. The context is rather simple (it is initially a kid’s cartoon), and the author always makes sure that enough words are spoken in proper English, so the "smurf" words can be easily inferred.

Actually, in some French primary school manual, they refer to the Smurf cartoons to teach kids how to infer a word’s meaning from the context. For instance, in these examples, kids have to find the right word to replace “smurf” in sentences such as “This is high jump, be careful not to smurf the bar”.

In our engineering world, we have many words which we can’t really understand without the context. We’ve already mentioned diagnosis and of course systems, but we can also talk about architecture (and architects who create it), function, service, control. In a given group, everybody will have an agreement about what it means, but if you mix groups, it will certainly lead to misunderstanding.

If you talk with a contractor, architecture is about designing building. Software engineers have a lot of respects of architects, who design the framework connecting the pieces of software together. To fit hundreds or even thousands of components into the limited space under the bonnet of car, you will need skilled automotive architects. As long as the building architect, the software architects and the automotive architects stay in their own perimeters, that’s not an issue. But when you expand the old mechanical business into complex mechatronics systems, you need to get together teams who will have a completely different idea of what the architect responsibilities are, and what the output architecture will look like.

Everybody is interested in “performance”, but they can all have very different vision of what it means. For the engineer writing a detection algorithm, the performance will be the accuracy of the detection, measured as a rate of good detection. For the engineer designing the hardware, the performance will be the speed of execution, measured as the number of milliseconds before the result (positive or negative) is delivered. For the sales team, the performance is the customer satisfaction, measured by the customer surveys. For the finance team, the performance is the return on investment, measured by the bottom line. Everybody will agree the system must be performant, but nobody will agree on what it means.

Even within the same group, the same word can be used simultaneously with different meanings. In a school document about an internship, my son had to answer several questions, including:

What are the product or services delivered by the business?

How is the business organised? what are the services?

It’s obvious, with experience, that the first service is something the company offers to its customers while the second service is an element of the hierarchical structure (like a department or a group). There is little risk of misunderstanding for professionals. They use the word service as the Smurfs use the word smurf. It has a perfectly clear meaning for them, depending on the context. For pupils doing internships, as for people not speaking the smurf language, it is trickier...

Language is not rocket science. We all use words naturally. Like Mr. Jourdain, we are speaking prose without being aware of it. When talking or writing, we choose certain words or structure unconsciously to convey a message. In order to be understood correctly, it is useful to analyse the way we use language, and be aware of these unconscious choices.

It is often said in businesses that the team have to speak a “common language”. Quite often, the proposed solution is to sit around the product. When the item being considered can be seen, understanding it comes from vision, not from words. The item can be a physical or digital mockup. Either way, the teams will agree on its definition and perimeter more efficiently than with mere words. But not everything can be implemented into a visible mockup, so words may be mandatory.

We’ll have a look about the mechanisms of communicating through words. Starting with foreign languages and their obvious difficulties, we’ll see that even when using the same language, we may face some unexpected issues...

Foreign Languages

Most kids in developed countries have learned at least one foreign language when they were at school, and it’s assumed everybody has at least some knowledge of English. It’s unfortunately not completely true, and the lack of a basic common language can literally lead to catastrophes.

In 2012, the Costa Concordia cruise ship hit a rock in the Mediterranean Sea, leading to a partial sinking. The weather was nice, and the sea was calm, so it’s hard to understand how the ship could have been led to this rock. The blame is usually put on the captain’s incompetence. But a further look at the investigation report reveals a different story. The captain may not have been very efficient, but even if he had, his instructions were not transmitted correctly. On this Italian ship, the crew had 38 different nationalities. Official language was Italian, but many crew members didn’t speak this language at all. Chief operator was from Bulgaria, and confessed he had not understood the orders in English. The captain also blamed the Indonesian helmsman for not applying his orders correctly. Language barrier certainly is not the only reason for the crash, which left 32 dead, but it largely contributed to the mismanagement of the ship trajectory.

When people haven’t learned a foreign language, or haven’t practiced for a long time, they are at least aware of the difficulty of making themselves understood when speaking a foreign language. But speaking a foreign language is not just about the grammar. It’s not just about the vocabulary. It’s also about context. Even people giving the impression of being comfortable with a language may make a lot of mistakes, by lack of context.

A well known category of words being misunderstood in a different context are the false friends. Here are a few examples, the most well-known between French and English.

In French, a calendar is called an agenda. As agenda is also an English word, it’s very common to hear French people use it instead of calendar, without realising it has a different meaning. When referring to the list of items that people agree to discuss in a meeting, it is not a big deal, but it is more worrisome if it can be understood as the personal objectives, for example in the sentence “he has his own agenda”. This could mean for a French speaker “he manages his time independently from the rest of the team”, which is a neutral, practical comment. But it would mean, in proper English “he has personal objectives different from the rest of the team”, which is likely to be negative.

A moment, both in French and English, refers to a period of time. But it has taken, in English, a specific meaning “a particular time or period of success, excellence, fame, etc.”. If French speakers say “we had a good moment”, they likely mistranslated “nous avons passé un bon moment”. A better translation would be “we had a good time”. This can lead to awkward interpretation, as an English speaker may understand “we had a good moment” as “something special and intimate happened between us”.

The English word location means localisation in French, while the French word location means renting. To ask where a group is, the right translation of “what’s their location” is not “quelle est leur location?”. That would mean “what are they renting?”. At best, if there is no renting involved for this group, the listener won’t understand the question and ask for rewording. At worst, the listener will answer about the renting, leading to a complete misunderstanding.

The word engineer or ingénieur is widely understood to refer to a person who has studied science, and is somehow disconnected from the practicalities of the world. Just look at the engineers jokes. However, who is an engineer is very country dependent. In France, you can be an engineer only if you have at least 5 years of studies, validated by a diploma equivalent to an MSc (Master of Science). In the engineering department of a French company, everybody does engineering, but not everybody is an engineer. Employees who don’t have a diplôme d’ingénieur are technicians, not engineers. In other countries, any member of the engineering team would be an engineer. In UK, the word engineer is used even more frequently, as anybody going a technical job can be referred to as an engineer. Someone servicing domestic appliances, for instance, is an engineer.

Actuellement in French means currently and French people will naturally use actually instead of currently when speaking English. This one is rather harmless, but it may give weird sentences, but not misinterpretation.

If a French person says “I don’t have money”, an English person would be surprised to see they have notes in their wallet. Are notes not money? You would have to know monnaie in French means change. Money and monnaie are not the same thing…

While we’re talking about money, note that British use notes as paper money, while Americans use bills. If you tell your British friend you’ll “leave a bill” as a participation for a party, they’ll think you’re charging them rather than paying your part. Indeed, the bill is what you would ask at the restaurant in Britain. In America, that would be the check. And in France….la note. How confusing...

In a business context, we’ll mention delay and délai. In French, it is the time it takes to do something. In English, however, a delay is a lateness. How many times do you see project managers with worried faces when their French counterparts ask “what is the delay of this project?”. Why would they ask this question, if the project is on track? Quite simply, French are talking about something under control, only wondering about the plan. English would understand there’s something wrong.

Another one, used quite often in professional environment, and can be quite dangerous: Éventuellement. It means maybe in French. It means something may or may not happen. Eventually, on the other hand, will definitely happen, though we don’t know when. So be very careful if French people tell you they will “do something eventually”. It’s very probable they won’t do it. By saying eventually, they’re thinking “maybe, I’m not sure”, and are genuinely trying to give you low expectations. Possibly they have no intention of doing it, and are just leaving the door open rather than say no bluntly. So don’t be disappointed when they come back later to say they won’t.

On the other hand, if a French person asks an English speaker if they can do something for them, and they answer they’ll do it eventually, the French may be very disappointed, and possibly feel insulted not to get any commitment.

A last business one, which you may have noticed in the previous paragraph, definitely. Its French equivalent définitivement, means finally, permanently. For instance, “le magasin a fermé définitivement” means “the store is closed permanently”. This is very different from “the store is definitely closed”, which is a confirmation of a doubtful status at a specific point in time. “Are you sure it’s closed?”. “Definitely”.

The source of these false friends is usually a common source at the origin, with different languages following different evolutions in different countries. That’s quite common in Europe, where many languages are evolved from latin (French, Italian, Spanish, etc.). But even non latin languages such as English have included a number of words of latin origin.

In Portuguese, baraça is a rope. En-baraça-ar is the action of making someone’s action difficult, a metaphor of being hampered by a rope. This became embarazar in Spanish, embarasser in French or embarrass in English. You would think they all have the same meaning. However, embarazada in Spanish took a different path in the mysterious evolution of languages and now means being pregnant. This should be a happy state, not an embarrassment! An advertisement for a pen once stated "won't leak in your pocket and embarrass you". This was mistranslated in Spanish to "No te embarazará chorreándose en tu bolsillo", which means literally "Won't leak in your pocket and impregnate you". Funny, but clearly not intended…

Another common source of misunderstanding is idioms, where each word can be known individually but their global meaning doesn’t make sense. In Britain, it rains cats and dogs, but in France, it rains ropes / il pleut des cordes (or like a pissing cow / il pleut comme vache qui pisse). Englishmen call a spade a spade (well, that’s actually quite rare, English culture is quite consensual, and English speakers tend to avoid being too direct), while Frenchmen call a cat a cat (most of the time, to the point of being rude…).

My kids having spent some time in England, they sometimes use mysterious expressions imported from English into French sentences. With their perfect French accent and their good vocabulary, it can be very confusing! When my daughter told me “tu regardes comme ton frère” (literally, you look like your brother, which is true), it meant something like “you stare the same way your brother does”. As I was not staring at anything, and my brother wasn’t present, it took me a while to understand what she meant.