41,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Fachliteratur
- Sprache: Englisch
Expand your enterprise into new regions using systems engineering and data analysis In Data Driven Decisions: Systems Engineering to Understand Corporate Valuation and Intangible Assets, investment banker, systems engineer, and Cornell University lecturer Joshua Michael Jahani delivers an incisive and unique unveiling of how to use the tools of systems engineering to value your organization, its intangible assets, and how to gauge or prepare its readiness for an overseas or cross-border expansion. In the book, you'll learn to implement a wide range of systems engineering tools, including context diagrams, decision matrices, Goal-Question-Metric analyses, and more. You'll also discover the following: * How to communicate corporate value measurements and their impact to owners, executives, and investors. * Explorations of the relevant topics when considering an international expansion, including macroeconomics, joint ventures, market entry, corporate valuations, mergers and acquisitions, and company culture. * A comprehensive framework and methodology for examining available global regions in your search for the perfect expansion target. * A deep understanding of specific sectors in which intangible assets have a particular impact, including branded consumer products, ad-tech, and healthcare. A must-have resource for business owners, managers, executives, directors, and other corporate leaders, Data-Driven Decisions will also prove invaluable to consultants and other professionals who serve companies considering expansion or growth into new regions.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 300
Veröffentlichungsjahr: 2023
Ähnliche
Table of Contents
Cover
Table of Contents
Additional Praise for
Data Driven Decisions
Title Page
Copyright
Foreword
Prologue
Introduction
Systems Engineering Overview: Customer Affinity and Context Diagram
Part I: Intangible Assets
Chapter 1: When Intangibles Matter Most
Chapter 2: Examples of Intangible Assets
Goodwill, Reputation, Brand Recognition, Patents, and Copyrights
Chapter 3: The Rise of Intangible Economies
Intangible Assets Are More Valuable
Chapter 4: Defining Intangibles
Chapter 5: Valuing Intangible Assets
Strategic versus Intangible Assets
Chapter 6: EBITDA Is Not the Best Way to Value Intangible‐Heavy Companies
Chapter 7: Separability, Measurability, and Predictability
Chapter 8: Why Systems Engineering Is Relevant for Corporate Valuations and Intangible Assets
Chapter 9: What Intangibles Matter Most for Corporate Valuation
Chapter 10: What Intangibles Matter Most for Corporate Expansion
Chapter 11: Buy‐Side Intangibles
Industry Examples of Buy‐Side Intangible Assets and When Intangible Assets Matter to Buyers
Chapter 12: PE Ratios
Chapter 13: The Business Moat as an Intangible Asset
Chapter 14: How Investors Think About Intangibles
Chapter 15: Intangible Assets in Branded Consumer Products
Chapter 16: Intangible Assets in Healthcare
Part II: Systems Engineering Tools and Examples
Chapter 17: Systems Engineering Tools
Chapter 18: Customer Affinity and Context Diagrams
Chapter 19: Context Diagrams and Context Matrices
Chapter 20: Use Cases and Behavioral Diagrams
Chapter 21: Originating Requirements
Chapter 22: Decision Matrix
Chapter 23: GQM – Goal Question Metric Analysis
Chapter 24: Analytical Hierarchy
Chapter 25: Precedence Matrix
Chapter 26: Failure Mode and Effect Analysis
Chapter 27: Interface Matrix
Chapter 28: House of Quality
Chapter 29: Operations Description Template
Chapter 30: Interface Tracking
Chapter 31: Conclusion to Tools
Chapter 32: GQM, Decision Matrix, and Analytical Hierarchy for Ad‐Tech Industries
Chapter 33: GQM, Decision Matrix, and Analytical Hierarchy for Logistics Industries
Chapter 34: GQM, Decision Matrix, and Analytical Hierarchy for Manufacturing Industries
Part III: Geographical Application
Chapter 35: Introduction
Macroeconomic Perspectives of Intangible Assets
Chapter 36: The MENA Region
Chapter 37: The ASEAN Region
Chapter 38: The Latin American Region
Chapter 39: Case Studies: Bringing It All Together
Chapter 40: Case Studies: LATAM Expanding to the United States
Chapter 41: Case Studies: MENA Medical Devices
Chapter 42: Case Studies: ASEAN Aerospace Schema – Context Diagram
Chapter 43: Case Studies: In Conclusion
Chapter 44: Summary
Bibliography
Index
End User License Agreement
List of Illustrations
Introduction
Figure 0.1
Chapter 9
Figure 9.1
Chapter 11
Figure 11.1
Figure 11.2
Chapter 12
Figure 12.1
Chapter 15
Figure 15.1
Chapter 16
Figure 16.1
Figure 16.2
Figure 16.3
Chapter 18
Figure 18.1
Figure 18.2
Chapter 19
Figure 19.1
Figure 19.2
Figure 19.3
Chapter 20
Figure 20.1
Figure 20.2
Figure 20.3
Figure 20.4
Chapter 21
Figure 21.1
Figure 21.2
Figure 21.3
Chapter 22
Figure 22.1
Figure 22.2
Figure 22.3
Figure 22.4
Chapter 23
Figure 23.1
Figure 23.2
Figure 23.3
Figure 23.4
Figure 23.5
Chapter 24
Figure 24.1
Chapter 25
Figure 25.1
Chapter 26
Figure 26.1
Figure 26.2
Figure 26.3
Chapter 27
Figure 27.1
Figure 27.2
Chapter 28
Figure 28.1
Figure 28.2
Chapter 29
Figure 29.1
Chapter 32
Figure 32.1
Chapter 33
Figure 33.1
Chapter 34
Figure 34.1
Chapter 36
Figure 36.1
Chapter 37
Figure 37.1
Chapter 38
Figure 38.1
Guide
Cover Page
Additional Praise for Data Driven Decisions
Title Page
Copyright
Foreword
Prologue
Table of Contents
Begin Reading
Bibliography
Index
Wiley End User License Agreement
Pages
i
v
vi
xi
xii
xiii
xiv
xv
xvi
xvii
xviii
xix
xx
xxi
xxii
xxiii
1
2
3
4
5
6
7
9
10
11
12
13
14
15
16
17
19
20
21
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
41
42
43
45
46
47
48
49
50
51
52
53
54
55
56
57
59
60
61
63
64
65
67
68
69
71
72
73
75
76
77
79
80
81
82
83
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
103
104
105
106
107
109
110
111
112
113
114
115
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
137
138
139
140
141
143
144
145
147
148
149
150
151
153
154
155
156
157
158
159
161
162
163
164
165
167
168
169
170
171
172
173
175
176
177
178
179
180
181
182
183
184
185
187
188
189
190
191
192
193
195
196
197
198
199
200
201
202
203
205
206
207
209
210
211
213
214
215
217
218
219
221
223
224
225
226
227
228
229
230
231
232
233
235
236
237
238
239
240
241
242
243
244
245
Additional Praise for Data Driven Decisions
Joshua Jahani presents a powerful set of tools driven by a pragmatic engineering approach. I appreciate the definitiveness of this work and believe it can be a valuable tool for people seeking to understand corporate value and intangible assets.
—Turk Al Joaib, Managing Partner, Rua Growth Fund, Riyadh, Saudi Arabia
Data Driven Decisions captures the missing part of corporate valuations, driven by the opacity of intangible assets. All financial professionals would benefit from this book.
—Andrei Ugarov, Former PwC Corporate Finance and Valuations Partner, Abu Dhabi, UAE
Data Driven Decisions shows a commitment to the Systems Engineering tools and principles that have helped the field become more popular than ever before. I am particularly impressed with how the methodologies of this book build on an existing body of systems material taught across the world.
—Wesley A Hewett, INCOSE Chapter President, New York, USA
The organization of Data Driven Decisions serves Joshua's purpose to identify better ways to measure intangibles in the global economy. I believe capital markets benefit from this kind of organization.
—Andrew Hulsh, Partner and member of the private equity practice at Mintz Levin, a leading international law firm, New York, USA
Data Driven Decisions
Systems Engineering to Understand Corporate Value and Intangible Assets
Joshua Jahani
This edition first published 2024
© 2024 by Joshua Jahani.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by law. Advice on how to obtain permission to reuse material from this title is available at http://www.wiley.com/go/permissions.
The right of Joshua Jahani to be identified as the author of this work has been asserted in accordance with law.
Registered Offices
John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USA
John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, UK
John Wiley & Sons Singapore Pte. Ltd, 134 Jurong Gateway Road, #04‐307H, Singapore 600134
Editorial Office
The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, UK
For details of our global editorial offices, customer services, and more information about Wiley products visit us at www.wiley.com.
Wiley also publishes its books in a variety of electronic formats and by print‐on‐demand. Some content that appears in standard print versions of this book may not be available in other formats.
Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.
Limit of Liability/Disclaimer of Warranty
While the publisher and authors have used their best efforts in preparing this work, they make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives, written sales materials or promotional statements for this work. The fact that an organization, website, or product is referred to in this work as a citation and/or potential source of further information does not mean that the publisher and authors endorse the information or services the organization, website, or product may provide or recommendations it may make. This work is sold with the understanding that the publisher is not engaged in rendering professional services. The advice and strategies contained herein may not be suitable for your situation. You should consult with a specialist where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
Library of Congress Cataloging‐in‐Publication Data Is Available:
ISBN 9781394202331 (Cloth)
ISBN 9781394200054 (ePDF)
ISBN 9781394200061 (ePub)
Cover Design: Wiley
Cover Image: © Xuanyu Han/Getty Images
Foreword
By David R. Schneider
Professor of PracticeSystems EngineeringCornell University
Joshua Jahani's Data Driven Decisions: Systems Engineering to Understand Corporate Value and Intangible Assets is a novel work that bridges systems engineering and entrepreneurial business, investing, and corporate valuation. Although sometimes considered quite different, Joshua demonstrates how systems engineering tools, processes, methodology, and philosophies, can translate into entrepreneurial success. It takes an entrepreneur of significant skill and ingenuity to approach the mechanics of business decision‐making through the lens of systems engineering, and I applaud Mr. Jahani for this work that deeply enriches both fields of practice.
I welcome any endeavor that widens the audience for the methodologies that I have spent decades studying, and this book can only mean good things for the wider acceptance and understanding of systems engineering as it applies to bringing clarity to and reducing the complexity of any given scenario.
David R. Schneider, PhD
***
David R. Schneider graduated from Rensselaer Polytechnic Institute in chemical engineering in 1999, attended Columbia University Film MFA Program in 2001, and earned his master's and PhD from Cornell University in mechanical engineering with a concentration in controls and dynamics in 2007. David has taught at both Columbia University, where he was the highest student‐rated instructor in the College of Engineering, and at Cornell University, where he is now the Director of MEng Studies for Systems Engineering, the largest MEng program at Cornell.
With a strong focus on education, David created the first experience in the world recognized by the systems engineering professional society INCOSE as a knowledge exam equivalent, and the only person to have created two experiences earning this honor. Additionally, David created and runs the systems engineering courses for Lockheed Martin's largest Engineering Leadership Development Program. David's main course, Model Based Systems Engineering, is also now officially sponsored by Boeing. David has also received multiple recognitions for his educational work from the Obama White House Office of Science and Technology Policy.
Prologue
Because this is a systems engineering book, I thought it prudent to provide a short historic roadmap first to give you an understanding of my background in relation to the subject matter. So here is a little bit about how this journey all began.
My higher education life began with premedical studies. That was actually the name of the degree, but it looked like a biology course. I graduated with my Bachelor of Science degree in that field, and I found my way to Cornell through a somewhat unusual path.
In 2010, I was accepted to Cornell for the first time to attend their graduate school program in the field of regional planning. I was actually put on a waiting list for the program, and I had applied to the regional planning program because my minor for my bachelor's degree was in political science.
I had really great political science teachers, all of my friends were in political science, and I just emotionally connected with the political side subject matter much more than the science subject matter, which was very memorization oriented and was very much preparing you for medical school.
I decided not to go to medical school, and I decided to apply to this program in regional planning. I did not apply to many. I applied to a couple of schools in New York City, and I applied to Cornell. I visited the program in person during the open house and was able to secure a spot.
My first year at Cornell was actually matriculated as a master's student in the regional planning program, which is not engineering, and the AAP (architecture, art, and planning program), was very public policy focused.
I rapidly realized that this subject matter was not for me. The whole thing seemed too focused on Marxism.
Instead, I was able to use some of the skills I had in mathematics and science that I developed through my undergraduate degree, and I applied to join the program in systems engineering because I genuinely saw a very big overlap between the systems engineering program and my education in biology and premed studies as well as my year of regional planning at the Ivy League university.
So, I matriculated into systems engineering, and I started that program. They only admitted me based on the contingency that I passed some advanced math courses, which I was able to do, and I achieved the grades necessary to matriculate into the systems program.
I then spent a year and a half taking systems engineering courses, so my educational background in the area of systems engineering is quite broad. Most systems engineers received their bachelor's degree in some kind of engineering program, such as electrical engineering. Systems engineering is a very popular follow‐up to electrical engineering. Mechanical engineering, physics, and aerospace engineering are all very common precursors to the master's in systems engineering program at Cornell, but I came in through premed, a bunch of Cornell math classes, and a year of Marxist training under the school of architecture art and planning for the regional planning program.
For most of the students who study systems engineering, it is their first exposure to a less mathematical or less technical body of knowledge compared to their undergrad course, but for me, it was the opposite. I came in with a very broad, very nonmathematical background that then got pushed into this funnel of systems engineering to then start applying quantitative or technical metrics to this very qualitative material I had learned. Regional planning is, of course, super qualitative but even biology is fairly qualitative; even though you are studying nature, you are mostly memorizing the effects that nature has on biology, but it is a very macro view of the world.
When I showed up to the engineering program, I was really passionate and really impressed with how I could take these relatively simple tools – which we will get into throughout this book – and then apply them to the more macro frameworks that I understood.
Common tools within systems engineering include devices such as decision trees, which are taught at MBA programs all across the country, or any kind of management science program. But the systems engineering program takes decision trees to a new level.
There is also a failure mode effect analysis, which is essentially used to identify how an assembly line may fail and then to identify probabilities that each of these different failure scenarios may occur and then start to create solutions for them.
As a very qualitative and macro thinker, I was very excited to get exposed to these tools. It made me a very effective student. I ended up graduating with my master's degree, so my educational qualifications include a master's in engineering and systems engineering, and I was able to use this material to develop even more credibility, which is why Cornell ultimately invited me back to its faculty and my current title at Cornell is visiting lecturer.
After leaving Cornell, I went to Deloitte, where I did technology consulting. There you can see a very professionalized version of systems engineering with big healthcare systems or any kind of big technology‐system implementation.
After Deloitte, I entered the world of corporate finance and investment banking. I then opened my own consulting firm in the field of investment banking where we rely heavily on systems engineering tools both to run the business and to provide highly qualified advice to our clients. I knew I had found my niche, as we made millions of dollars in revenue in our first year and systems engineering has been a core part of that success and everything that we do.
I now teach several courses at Cornell, which are all very practically focused. The first one is a project where I lead students on how to use systems engineering to perform corporate valuations. The second course I teach is an introduction to systems engineering course that is available to seniors in the undergraduate program and master students in the graduate program.
Jahani and Associates came from the premise that we could provide better growth advisory services to clients than that available on the market at the time. We are a management consulting firm that has an investment banking capacity, but our clients leverage us for growth, so everything we do has to do with expanding a company one way or another. We broadly define the categories for expansion as investment banking advisory services, which include capital placement mergers and acquisitions (M&A), which ties heavily into corporate valuations and corporate expansion, with the second category of growth services we discuss called market expansion.
Everything we do at Jahani is cross‐border in one way or another. We will work with a Canadian firm, and we will help that firm expand to Dubai. We will work with a Dubai‐based firm, and we will help that company expand to Jakarta. We will work with a Brazilian‐based company, and we will help it expand to Saudi Arabia, and we will work with the Saudi Arabian company, and help it do business in Florida or in California. Those are all examples of different transactions and clients that we have actually worked with. The expansion can include investment banking, as I said, but it is bigger than that. It can include something as simple as opening up an office. Jahani and Associates does a lot of joint venture work, and we are the bridge that facilitates those joint ventures for our client companies.
When you are applying these growth services to these very different markets that have very different cultural, financial, business systems, and so on, you have to mesh them together so that they can grow. In every instance, there is a heavy focus on optimization of how the two systems that you are working within a cross‐border capacity must integrate.
You do not have that concern if you are only doing domestic deals, which is what most of our competitors and most of the companies in this space do. If a company from Connecticut is buying a company in Pennsylvania, the cultural, financial, and logistics systems are already integrated. All of those basic business processes overlap very nicely. But when you do it in a cross‐border capacity, particularly in the regions that we are talking about, they do not interface, so we have to find a way for them to interface. We have to develop a map from one platform to another. In software terms, this would be called an Application Programming Interface (API). Essentially, mapping one system's protocols to another enables the two platforms to “speak” with one another. Beyond software, there may be services we need to introduce to facilitate or amend one system or the other (or both) so that they communicate. There is always a way.
We use systems engineering tools and frameworks to facilitate that, and we use these tools to help communicate the benefits of the intangible assets that a company may have so that they can achieve an accurate valuation.
To provide a real‐world example, I will use a simple case‐study scenario to demonstrate the various action items, strategic moves, and workflows of providing a solution to a client.
One of our US‐based client companies purchased out of bankruptcy a software platform in Spain that the Spanish government had funded via grants. The first step was to gain an understanding of which triggers for growth could use and gain advantage.
The first step is to examine exposure. The company has this software technology that now exists in the United States and has ties to Spain. We would begin with regulatory compliance as it was funded through the Spanish government. They lend their money to help improve the Spanish economy so the company needs to make sure that the asset is free of any obligation or regulatory ties – any liens, or similar problems.
We make sure that the asset does not have any inbuilt requirement that would give the King an opportunity to take it back from you or have some right to your generated revenues. Essentially we are checking that the company is able to own all of the intellectual property clearly across international borders. That ownership component is extremely important, particularly in software. You also see this very often with pharmaceutical businesses or biology companies.
These companies are licensing key patents from offices of Harvard or Yale because these big institutions create so many patents and so much intellectual property, they cannot sell it because it was funded with government dollars, so they ended up giving a perpetual license for zero dollars. In this kind of cross‐border transaction between the United States and Spain, it is important to make absolutely certain that there is no copyright for the code that was actually funded by the Spanish government, which is therefore owned by the government, and the company does not have its own rights to it.
Assuming that the business is free and clear of all of those liabilities, the next step is a pretty basic commercial process, which is about how people are paying for the commercial value of the solution and how much they want to pay.
If the business is only doing 15,000 euros per month already, what is the number of customers generating those 15,000 euros? Are they primarily in Spain, or are they scattered about the world?
If the software is Linux‐based and open source, what are the limitations in selling it, and do the company provide the software for free and charge a subscription for training and support instead? Analyzing its nature will show us where opportunities for growth exist. If the customer base is predominantly situated in Spain and the 20,000 customers are loyal advocates, we can use that brand loyalty to open up opportunities in the United States and other countries. If the base is using it for a particular reason, for example, as an alternative to a Microsoft product that has a less intuitive interface and perhaps costs more money, the low‐hanging fruit in the market begins to reveal itself. Is it large companies or small companies that are likely to make this buying decision? Large companies are more likely to go with the incumbent for trust and credibility because they are less concerned with price and more concerned with keeping their jobs by not making a wrong choice. This means that we are now beginning to see a clear path to small businesses, perhaps with an in‐house IT staff member to configure it. This probably means that we need to target small to medium businesses with five or more staff who have an in‐house IT person who can understand the implementation process and save significant money on software licensing in relation to the company's revenue.
Now that we have established our laser‐focused target client, we need to consider buying cycles. How are they likely to consider a decision like this? If the base price for 5–25 users is just 195 dollars per year, it is too small for a meeting with any kind of major decision‐maker. Managers have a budget, and they can autonomously make a buying decision like this, so that removes a barrier for us. They have a corporate account or a corporate credit card that they are able to use. They want to acquire solutions that help them solve these very specific problems, so we need to establish what those are and market the solutions to them.
With this in mind, we can see that e‐commerce channels suddenly look like a friction‐free sales process rather than a traditional sales team approach.
The capital the company would have invested in a sales team can now go to a Google Ads campaign or a channel marketing campaign with existing networks, such as data centers where customers have a suite of software solutions on offer from the vendor.
Now we are firmly establishing what we have and who wants it, we can also begin to gear our search engine optimization (SEO) so that customers will find us organically and be funneled into an optimized free‐trial landing page. This is a very inexpensive growth strategy, but we have to do this preliminary analysis to start to understand the tangible and intangible assets of the offering, which then guides us to what kind of market expansion fit applies.
Is it a business‐to‐business process with a team doing cold calls, or is it a direct‐to‐consumer play?
Now we can get to work on an Excel formula to begin drawing a picture of our forward‐looking expansion plan to the Unites States and beyond.
This is how we use our framework, the systems engineering piece, to identify the product's core‐calling, which leads us to our target, who is obviously a technical person, which usually indicates that they are a smart person, so now we know how we are going to speak to them, what language we will use in our sales, and marketing outreach, and so on. This process continues as we triangulate the path to revenue. What worked in Spain would not necessarily work in the United States or elsewhere so this process must be done in context with the expansion geography.
Another Jahani and Associates' client is a Europe‐based tech company that allows you to manage cloud architecture. They have two go‐to‐market strategies. They acquire customers online through basic SEO and then via sales‐channel partnerships. We arrived quickly at these primary revenue generators using the same framework that we explored during the Spanish software case study.
Another one of our clients specializes in digital marketing solutions in the United States. We closed a substantial investment for them, and we helped them to form a joint venture in the Middle East with a conglomerate. It is a perfect case study to show the scope of what J&A is doing. It is not just consulting; it is not just capital.
They were based in the United States, and they specifically wanted to grow internationally because they have digital marketing solutions for physical spaces that apply anywhere, but that is a scenario that works very well in places like the Middle East and Asia. So, they hired us. Ten months later, they had a new institution that was then valued at several billion dollars on the cap table. That institution became their largest institutional shareholder. They also have several of their media devices being deployed in the Middle East.
We did another deal with a logistics company based in the GCC. We formed a joint venture with a large family owned conglomerate in Indonesia. This logistics company in the GCC owns a last‐mile delivery platform that helps e‐commerce shippers optimize shipping costs and routes so that they can either save money or they can pass the lower cost of shipping on to their customers, thereby building customer loyalty. In Jakarta, Indonesia – a country with a population of two hundred million people – last‐mile delivery is a huge challenge. Partnering with our client brought demand to local couriers.
Hopefully, this gives a well‐rounded walkthrough of what J&A does for companies, thereby providing the foundational elements to better utilize the information and tools in this book.
Chief Executive Officers (CEOs) are the de facto experts in their business, which means they know how to fulfill orders, they know how to reach their customers, and they know how to solve employee or labor problems or shortages.
He or she is the de facto expert in their domain, where they start to fail, and where they leverage any service provider is where there is an activity that is needed that is not core to the business. Think about a logistics company that needs an attorney. This logistics provider grew up in FedEx, and she or he is an expert in all‐things‐delivery, but there is some kind of dispute, and they need legal representation that is not a core competency of the business. This is where they leverage any kind of service provider.
Where we come in very valuably is helping them think about their business within the different systems and economic frameworks of these regions. For example, Chad Thomas from Connecticut has never even thought about the Middle East or Asia, but he knows that these are large markets that can exponentially generate business growth for him.
Another profile of a founder that we found to work with very successfully is Vishal Irma. Vishal is from India, and he knows that Dubai is an extremely relevant market. He knows that Egypt has over a hundred million people and that countries like Iran consume the most bananas in the Middle East. But Vishal went to Brown, and he got his MBA from MIT. Vishal's parents are familiar with these markets, but he himself does not have any kind of expertise or exposure, so although philosophically, he understands that these markets are important, he does not have any on‐the‐ground experience, and he could not possibly do it himself. It is almost always cheaper to hire us and pay our consulting fees than to try to do it themselves.
Systems engineering is driven by a set of tools that engineers use to get other engineers to work together. Systems engineering is most common in fields like aerospace, where you have to build a rocket, and it has got to go to the moon. You have thousands of engineers all doing little pieces of a massive design. Because systems engineering has this collaborative and highly quantitative nature around processes, it lends itself to analyzing intangibles.
Intangibles can be their own massive separate domain, but it is important to scope intangible assets within the context of systems engineering and valuations.
With systems engineering, it is about what you can conceivably measure. For example, you have a musician, and the musician is phenomenal and world‐renowned. An intangible asset of this musician could be the number of views or the number of clicks, or the number of followers that they have on a social media platform. Certainly, sales of albums are relevant, and that is directly correlated to revenue, so that would be considered a tangible asset since cash is overall tangible. But if you have two musicians, both of whom are relatively identical in sound and style, and one has ten million YouTube views, and the other one has one thousand, but neither has monetized those views, one of those is still more valuable than the other, regardless of the money that has been made.
That is how intangible assets matter within the context of a non‐financial situation. Systems engineering would allow you to diagram what kind of digital activity the musician with ten million views has done and how their digital marketing strategy has created ten million views versus the musician who has one thousand views and sounds exactly the same.
Linking these concepts of intangible assets with systems engineering tools is a core focus of this book because it has a direct impact on valuations, as we will explore in Part I.
There are three major variables that are inside this multivariate equation of this book. The first one is systems engineering – the tools, the principles, and the techniques that matter within the context of this subject. The second element is corporate valuations, which is ultimately what a company or an asset is worth. We will use the term “corporate valuations” relatively loosely here.
In the example I used with the musicians, they are not businesses themselves, but you can still value both of the profiles of those two musicians.
The third variable in the equation that this book is seeking to analyze is intangible assets, which are generally identified as technology‐driven, off‐balance‐sheet assets that can impact (either increase or decrease) the valuation of a firm.
To summarize, before we get into the guts of the principles, this book is about corporate valuations, systems engineering techniques, and principles for understanding intangible assets. When you combine corporate valuations and systems engineering, it keeps you focused on a very specific world of capital markets – which is about how much a company is worth and what impacts that worth up or down. Then, systems engineering, which is this platform specifically dedicated to keeping engineers – which can include operations research engineers – all on the same track and speaking the same language.
My premise is that systems engineering employs very specific techniques and principles that allow us to understand intangible assets, specifically within the context of corporate valuation. What is fundamentally important to you in deriving value from this book is that there are three variables that are constantly iterating and evolving as we go through this text. The first one is corporate valuations and, specifically, what changes a corporate valuation. The second is intangible assets.
Those are broadly defined and will be defined later in the book by anything that is off the balance sheet, and you cannot touch, mostly driven by technology. Then, the third variable is systems engineering which is the tactile and utile tools that we can use to understand the first two variables in greater detail.
It is important that stay focused on these three variables and constantly come back to them at any time when the subject matter feels like it may be getting too detailed or off course for you because we have gone very deep into a particular element of one of the three variants.
