対象が技術システムではなく社会や企業である場合、システムの要素として利害関係者が挙げられます。単純な販売店と顧客の関係では製品を受け取り、対価を払うという関係があります。長期間にわたって継続的に利用する製品の場合はサポート企業もいるかもしれず、車のような製品であれば燃料を提供する企業も必要です。このような場合、製品の単体性能が優れているだけでは顧客が望むものになりません。利害関係者である、販売店、メーカー、サポート企業、燃料提供企業などから創発する性能に顧客は魅力を感じ、購入することになります。利害関係者がどのような関係性で結ばれているか、あるいは利害関係により構成されているシステムがどういうものであるか、についてはStakeholder Value Networkという図式による記述が利用できます。特定の利害関係者への働きかけが他の利害関係者に想定外の影響を及ぼすこともあり得るので、そのようなことを図から読み取ることを考えます。
利害関係を図示した後、顧客の要求の分析を行います。要求は、製品を所有するという基本的なものから、サポートや燃料補給の容易性などの補助的なものの2種類に分けて考えることができます。前者を機能要求、後者を非機能要求と呼んでいます。すべての利害関係者がどのような機能要求、非機能要求を持っているかを記述しながら理解を進めることで、顧客が望んでいる創発すべき機能を明らかにし、またその創発のためのメカニズムを組み立てることができます。
マーケティングにおいてコトラーによりニーズ、ウォンツ、デマンドという概念が整理されています。「ニーズ」は根本的な欲求、満たしたい状態、欠乏を示します。マーケティングに寄らず、より一般的な定義と考えられます。ニーズに対して、「ウォンツ」は人間や社会によって具体化された欲しいもの、解決策を指します。ウォンツが商業ベースに乗るレベルまで高まるとデマンドになります。レビットによる、ドリルを買いに来た人が欲しいものは穴であるという話では、ニーズが穴、ウォンツがドリルに相当します。顧客の求めるものを深掘りすることの重要性が述べられています。
OPMのフォーマットやシステムアーキテクチャの考え方を活用することで、このニーズやウォンツの分析を手続き的に行うことができます。システムアーキテクチャのテキストにおいて、システムの機能の分析は「オペランド（操作対象物）」の「属性」を変更するという記述を行います。ドリルの購入と穴を希望するというニーズとウォンツを書き起こすと以下のようになります。
「顧客（オペランド）」の「ドリル所持状態（属性）」を「無い」から「有る」に変更する。
「板（オペランド）」の「穴あき状態（属性）」を「無い」から「有る」に変更する。
分析を行う際には、これらの記述を階層的に扱います。効率的にニーズやウォンツを充足できるシステムを考えるには、それぞれのステークホルダーの立場で実務上可能な手段を選択します。オペランドと属性、またその変更という形式での記述は、顧客自身にとっても曖昧なニーズやウォンツを明示するうえで有効に働きます。
When the target is not a technical system but a society or a company, stakeholders are the elements of the system. In a simple dealer-customer relationship, there is a relationship of receiving a product and paying for it. For a product that is used continuously over a long period of time, there may be a support company, and for a product like a car, there needs to be a company that provides fuel. In such cases, just having a good standalone performance of the product is not enough to make it what the customer wants. Customers will be attracted to the performance created by the stakeholders, such as dealers, manufacturers, support companies, and fuel providers, and will buy the product. The relationship between the stakeholders can be described by using a diagram called Stakeholder Value Network.
After illustrating the relationships, analyze the customer's requirements. The requirements can be divided into two types: basic requirements such as ownership of the product and auxiliary requirements such as support and ease of refueling. We refer to the former as functional requirements and the latter as non-functional requirements. By describing what functional and non-functional requirements all stakeholders have, it is possible to identify the functions that customers want to be created and to build a mechanism for their creation.
In marketing, the concepts of Needs, Wants, and Demands are organized by Kotler. A "Need" is a fundamental desire, a state that one wishes to achieve, or a feeling of deprivation. This is generally considered a more universal definition, not limited to marketing. In contrast to needs, a "Want" refers to specific things desired or solutions conceived by individuals or society. When a want is backed by purchasing power and reaches a level where it can be commercially viable, it becomes a "Demand."
The famous anecdote by Levitt—that the customer who comes to buy a drill is not looking for a drill, but for a hole—illustrates this: the Need is the hole, and the Want is the drill. This emphasizes the importance of deeply exploring what the customer is truly seeking.
By utilizing the framework of OPM (Object-Process Methodology) or system architecture principles, this analysis of needs and wants can be carried out procedurally. In system architecture texts, the analysis of a system's function is described as changing the "attribute" of an "operand" (the object being operated on). The Need (a hole) and Want (a drill) can be transcribed as follows:
Change the "drill possession status (attribute)" of the "Customer (operand)" from "none" to "has."
Change the "holed status (attribute)" of the "Board (operand)" from "none" to "has."
In the analysis process, these descriptions are treated hierarchically. To conceive of a system that efficiently fulfills the needs and wants, practically feasible means are selected from the perspective of each stakeholder. Describing needs and wants in the format of an operand, its attribute, and the change to that attribute is an effective way to articulate even those needs and wants that may be ambiguous to the customer themselves.
Dori, D. (2002). Object-Process Methodology. Object-Process Methodology. https://doi.org/10.1007/978-3-642-56209-9
Edward Crawley, Bruce Cameron, Daniel Selva: System Architecture: Strategy and Product Development for Complex Systems, Pearson, (2015)