© Chris Partridge 2002. All rights reserved What is a customer? The beginnings of a reference ontology for customer Chris Partridge The BORO Program partridge@BOROProgram.org Abstract This paper describes the precisification of the notion of customer developed within the Core Enterprise Ontology (CEO) Project. The paper first benchmarks the current state of the art. It reviews the three main ways in which current applications attempt to specify the type of customer – highlighting their attractions and inadequacies and ranking them in terms of precision. It then outlines a more precise interpretation of customer, indicating why and where this improvement is needed. The interpretation is based upon the mereology of organisations developed within the CEO Project and an analysis by Margaret Gilbert of the nature of agreements. Introduction The specific theme of this year’s OOPSLA Workshop on behavioral semantics is “on serving the customer”. A general theme of these workshops is “fostering precise and explicit specifications of business and system semantics, independently of any (possible) realization”. This paper reports on a segment of the work done within the CEO project (part of the BORO Program1 ) that brings these two themes together, work that led to a more precise and explicit specification of what a customer is. Businesses are well aware of the need to serve customers better. They are improving their services through a variety of initiatives, currently including many that they classify as CRM (Customer Relationship Management). One of the things underpinning these initiatives is a notion of what a customer (and so a customer relationship) is. The results of the CEO analysis reported on here show that larger, more complex, businesses need to make their notions more precise. And they indicate both how this can be done and how it enables enterprises to manage their customers better. The CEO Project The CEO project is part of the BORO (Business Object Reference Ontology) Program, whose aim is to develop and maintain ‘industrial strength’ ontologies, that are a suitable basis for facilitating, among other things, the semantic interoperability of enterprises’ operational systems. The initial phase of the CEO involves a Synthesis of State of the Art Enterprise Ontologies (SSAEO) 2 to provide a foundation for the development of the CEO. The selected ontologies are: - TOronto Virtual Enterprise - TOVE (see (Fox 1993) (Fox 1996) (TOVE:http)), - AIAI’s Enterprise Ontology - EO (see (Ushold 1997) (Ushold 1998) (EO:http)), - Cycorp’s Cyc® Knowledge Base - CYC (see (CYC:http)), - W.H. Inmon’s Data Model Resource Book - DMRB (see (Inmon 1997)3 ). All of these, except the first (TOVE), include customer in their ontology – indicating its importance. 1 For more details of the CEO project and the BORO Program see the papers at www.BOROProgram.org. In particular, LADSEB Report 07-02 – An Introduction to the CEO Project and LADSEB Report 08-02 - STPO - Synthesis of a TOVE Persons Ontology. 2 Details of this can be found in the paper A synthesis of state of the art enterprise ontologies presented at last year’s OOPSLA Workshop on Behavioural Semantics and published in the proceedings (K. Baclawski, H. Kilov (Eds.). Proceedings of the Tenth OOPSLA Workshop on behavioral semantics (Tampa Bay, 2001). Northeastern University, 2001). 3 (Hay 1997) has, in most cases, a similar content to DMRB. A Revised Edition of DMRB has been published in two volumes - (Silverston 2001a) and (Silverston 2001b). -- 1 of 12 -- What is a customer? The beginnings of a reference ontology for customer Page 2 The CEO analysis of these ontologies is providing the basis for a benchmark of the state of the art in enterprise ontologies. This paper reports on how the work done to date gives us a benchmark of the state of the art for he notion of customer. Customer – Person – Core Category One of the main deliverables of the CEO is a framework of core entities, a core ontology: where this contains “the categories that define what a field [the enterprise] is about” (Breuker 1997). The CEO’s initial ‘guess’ of what these categories might be (which is being refined by the analysis) is: persons, transactions and assets. Where persons may enter into transactions (composed of agreements and their associated activities) involving assets. The notion of customer is closely linked to these categories. The dictionary definition of a customer – “one that purchases a commodity or service” – reflects these categories. Prima facie, it looks as if a customer is a person who purchases (transacts a transaction for) a commodity or service (an asset). This is an element of truth is this, however it is far from being precise enough for most enterprises’ purposes. The CEO analysis builds upon the insights in the state of the art ontologies to build a sufficiently precise notion. Level of precision – tolerance The goal of precision in the specification of an enterprise’s application needs to be responsive to the requirements for that application – the level of precision needs to be adequate. Different tasks require different levels of precision, a situation familiar from traditional physical engineering: where a ‘tolerance’ is specified. Adequate tolerance for the engineering of a nut or bolt will be inadequate for etching a silicon chip. The representation of customers is ubiquitous in enterprise applications. These representations show a wide variation in precision, only part of which can be explained by the requirements for the applications. Typically applications for small enterprises with a restricted scope can function with less precise representations – the analysis will provide examples of this. Applications in larger enterprises with wider scopes usually require more precise representations. CRM and customer accounting applications for which the notion of customer is central tend to fall into this category. In many enterprises’ applications, the representation is not precise enough for calculating accurate customer accounting figures (such as Customer Life Time Value (CLTV)). And increasing the precision not only enables accurate accounting but also creates opportunities for better customer management. A structured approach to precisification Making specifications of business and system semantics more precise is an admirable goal – however one of the problems in achieving it is a lack of a mainstream structured approach to this kind precisification. The BORO Project has developed and is applying a structured approach to precisification. This has two main elements. The first is the REV-ENG re-engineering methodology 4 whose purpose is the precisification of existing applications through re-engineering. What distinguishes it from most other computing methodologies is a multi-disciplinary element – that it draws upon work done in ontology a branch of philosophy. For example – and this will be clear in the analysis below – it focuses on philosophical questions about objects’ extensions, identities and mereology (partial identity). These kinds of questions are not the normal fare of most computing methodologies, but they are common in philosophy. The second element of the approach is the re-use of relevant content from philosophy. For the domain of person (and so customer) the work of Margaret Gilbert and John Searle 5 , among others, has proved particularly useful. Aiming to build a more precise understanding What is holding back the precisification of many elements of the enterprise, and customer is a good example, is a lack of a clear understanding of what they are. What this paper aims to start doing is building a more precise understanding of what a customer is. This is, of necessity, largely an informal process. However, it is an essential precursor to any formalisation process. After all, how can anyone develop a precise 4 This is based upon the REV-ENG Methodology described in Business Objects: Re-Engineering for Re-Use (Partridge 1996). 5 See in particular (Searle 1995) and (Gilbert 1992) -- 2 of 12 -- What is a customer? The beginnings of a reference ontology for customer Page 3 formalisation of something that they have an imprecise understanding of? The more precise understanding outlined in this short paper, provides a solid basis for more precise formal specifications. The precisification analysis Ontology studies what exists – an ontology is, at one level, a categorisation of the (types of) things that exist. The ontological analysis of the enterprise aims at categorising the (types of) things that exist in enterprises. This ontological analysis of customer aims to identify what (types of) things we are talking about when we say that enterprises have customers and, more particularly, that this enterprise has 505 customers. Or, to put it another way, what (types of) things make these statements about customers true or false. The way in which customers are represented in applications provides a good guide to what types of things the developers thought and users think exists. The first part of this paper reports on an analysis of the ontologies for customer assumed by existing applications. The second part then reports on how a more precise analysis of how we deal with customers in practice leads to a new interpretation of what a customer is. Customer type in current applications The CEO’s ontological analysis looked at the general form of instances of customer and asked: what type of thing is being referred to? Examination of current applications showed it is being represented as a range of different formal types. The three main ones (in increasing order of precision) can be differentiated by their formal type – these are: • Particular, • Role, and • Relation. Broadly speaking6 , a particular is a single individual thing, a role is something that is adopted or played by a particular for a period of time and a relation is some kind of association between particulars. A particular’s participation in a relation is sometimes thought of the basis for playing a role. The identity of a role is formally dependent upon the thing playing the role, and the identity of the relation upon its participants7 . Each of these types has some initial attractions. In the following sections we examine these and, for the first two types, the deficiencies that make them inappropriate for customer. Customer as a particular (person) In many organisations’ applications customers are represented as persons, a type of particular. In sales / order applications they are usually represented as particulars that are related to one or more sales orders. This is a standard perspective in the industry, one that many data modelling courses teach and many textbooks describe8 . It is commonly accepted, appearing, for example, in industry standards such as ISO/IEC 10746 – ODP Reference Model9 (where it is used as a database example). Within this perspective, it is also usual to regard a customer as a sub-type of party (where a party can be a human or an organisation). Normally associated with this is a purchasing model that has supplier entities that are related to one or more purchase orders 10 . At first sight this seems to reflect the way we talk about customers – hence the dictionary definition “one that purchases a commodity or service”. When someone says ‘John is a customer of Acme Telecom’, they 6 This broad informal characterisation is sufficient for the purpose of differentiating positions and their deficiencies. 7 There are technical questions as to whether a thing can have more than one role of the same type – or participants more than one relation of the same types – and if so how. These are not relevant here. 8 This and many of the following points are made in DMRB (Inmon 1997). See p.68 – “Most organisations model orders using the standard data model which is shown throughout many textbooks on data modelling. … A CUSTOMER can be related to one or more SALES ORDERs …” 9 See ISO/IEC 10746-1 ODP Reference Model Part 1. Overview. (ISO/IEC 10746-1 1995) Section 12.4. Database example. 10 DMRB’s Figures 4.1 and 4.2 (pp.69-72 (Inmon 1997)) has diagrams of both the sales and purchase models. -- 3 of 12 -- What is a customer? The beginnings of a reference ontology for customer Page 4 seem to mean that John (the human) is an instance of the type customer. It is presumably uncontroversial to regard individual humans as particulars and John is an individual human – so he is a particular. A similar situation holds for organisations that are customers. However, this perspective reveals itself as inconsistent when one starts to ask identity questions. John (the human) was not always a customer of Acme – for example, when he was 5 years old, he was not a customer. This gives us our inconsistency. This interpretation implies that the ‘is’ in ‘John is a customer’ is the ‘is’ of identity and so John (the human) is the same as John (the customer) and that it is the same John (the human) that was 5 years old and is now a customer. Yet the customer entity recorded in Acme’s application must be different from 5 year old John (by definition as the young John is not a customer). We are left trying to explain why John (the human) and John (the customer) are both the same and different. One might argue that most sales systems are not interested in 5 year old boys. But the same problem surfaces in more common circumstances. For example, where John stops being a customer and the starts again. This also raises a further identity questions. Here is an example of the problem in more common circumstances. Is it the same John (entity) who is at first a customer and then not a customer? If it is, then this entity cannot be a customer entity, as at some time it is not a customer. But this is inconsistent with the interpretation which suggests that John is the customer – not some other entity – and this is why we regard customer as a sub-type of party. It looks like we have to give up one element of the interpretation, if we want to make it consistent. The obvious element to surrender is our intuition that John (the human) is the same as John (the customer) and accept the counter-intuitive conclusion that they are different. But this leaves us with two things to explain. Firstly what type of thing the new customer entity is, given it is not human. And secondly, what the link between the customer and the human is – because they surely have one. Here is the further identity question. Is it the same John (entity) who is at first a customer and then again a customer after not being one? Intuitively we want to say they are the same. But this implies counter- intuitively that customers (unlike humans) can have an intermittent existence. Where, as is often the case, the associated purchase model has been implemented with supplier entities, the counter-intuitive nature of this interpretation becomes even clearer. Whenever the same enterprise is both a customer and a supplier, this enterprise is represented as two entities, a customer and a supplier entity. Our intuition tells us there is one only enterprise, the representation implies there are two 11 . The philosophical flavour of the analysis may make these seem like abstruse (philosophical) points, but they have direct practical implications. They highlight the problems that one will face developing or using an application that adopts this perspective. They highlight, for example, the inconsistency that will result from treating a customer as a sub-type of a person – of regarding John (the human) as the same entity as John (the customer). They indicate a need for having separate, but linked, person and customer entities (and person and supplier entities). They also highlight the need to make a decision on whether to treat each episode of being a customer is to be treated as a separate entity – or stages in the same entity. Within a restricted context this ‘particular’ perspective may be ‘good enough’, but in wider contexts, as these examples show, its lack of precision makes it inadequate. These deficiencies are explored in the next section where the more precise (and less counter-intuitive) notion of a customer as a role is analysed. Customer as a role Regarding the type of customer as a role is a more sophisticated (and less counter-intuitive) perspective. We noted earlier that a role is something that is adopted by an entity for a period of time. On the face of it, this seems to be true of customer and resolves the problems encountered with customer type as a particular. It explains the situation described above: John adopted the role of customer for a time, then he dropped the role, then adopted it again. Also, and this turns out to be a problematic feature in the case of customer, at a particular time an entity either has or has not adopted a role. In the situation just described, at each stage John either had or had not adopted the role of customer. There are a number of applications that treat customer as a role. An example from the CEO’s SSAEO sample is the EO, another example is SUMO12 . EO explicitly states that a customer is a role that is played by 11 DMRB makes a similar point - pp. 70-71 (Inmon 1997). 12 For details of the SUMO (see (SUMO:http)), a more recent ontology that takes a similar position linking customer and its WordNet description “Someone who pays for goods or services” to SOCIAL ROLE. -- 4 of 12 -- What is a customer? The beginnings of a reference ontology for customer Page 5 legal entities13 . It also notes that roles are typically dependent upon a relation – in this case, a customer will be a role of the sales relation. Like the customer as particular interpretation, this also has an egotistical or ‘I’ perspective 14 . In a simple context where there is a small enterprise (consisting maybe of one person) and no requirement for interoperability then this perspective may not cause too many problems. Here all that is required is for the enterprise to identify when a party is in a customer role (in relation to it). In wider contexts this is too simplistic. The underlying reason for this is that in a simple context one can consider a customer as dependent upon the single enterprise at the centre of the context (the ‘I’) – it is a customer in relation to this particular enterprise. As the context widens and the number of enterprises increases, there is no one ‘I’. Each of the enterprises will have customers in relation to itself. And using roles, it is impossible to track who is a customer of whom – merely whether someone has adopted a customer role. To see this consider an application with enterprises A and B as users. Let us assume enterprise A has John in a customer role. Then, John is in a customer role simpliciter – and the application records John as being such. Let us also assume that enterprise B does not have John as a customer. There is no way for the application to record this information in terms of customer roles. Hence there is no way for it to report on how many customers enterprise B (or A) has or even list them – making customer management impossible. The same kind of problem can occur within an enterprise, if it is large enough to have units. For example, if enterprise A has a number of divisions, then it can make sense to talk about and differentiate their customers. We can talk about John being a customer of division I but not of division II. But we cannot capture this information in an application that treats customer as a role. Source of the problem is not the notion of role. Other things fit neatly into it: for example, father. A person playing the father role is a father to at least one child, and these children can change over time. The problem is rather that customer does not fit into the type role. These examples show that treating ‘customer as a role’ is not really a sufficiently precise way of capturing our intuitions or practices of what a customer is in contexts wider than a single small enterprise. Even the most basic customer accounting system needs to be able to distinguish between ‘being a customer of division A’ and ‘being a customer of division B’. In the next section we look at the more precise and sophisticated notion of a ‘customer as a relation’ that enables this to be done. Customer as a relation Some notions of role assume that a role is played within a relation. The EO is an example of an ontology that makes this assumption. So the two types, role and relation, are closely linked. But as this section will show, the type ‘relation’ captures more precisely our notion of what a customer is than the type ‘role’. There are applications that represent customers as relation. Examples from the CEO’s SSAEO sample are CYC and DMRB. CYC has a predicate #$customers which represents a relationship between two #$Agents where AGENT1 sells goods and/or services to AGENT2. Within CYC, #$customers is a specialisation of #$doesBusinessWith. DMRB has a general party relationship ‘entity’ between parties, one of whose sub- types is a customer/supplier relation. DMRB notes that the customer and supplier name the two ways of participating in a customer/supplier relation. If enterprise A is a customer of enterprise B, then enterprise B is a supplier of enterprise A. Treating the type of customer as a relation avoids the problems that arise when treating it as a role. Reconsider the earlier ‘problematic’ example where there are two enterprises (or divisions) and one has John as a customer and the other does not. If customer is viewed as a relation then this is interpreted as there being only one customer relation between the relevant enterprise (or division) and John. In this scheme there are no difficulties in capturing who is (or is not) a customer of whom. 13 The EO seems to adopt an unusual perspective on customer. It takes this to be the role played by a legal entity in a particular sale transaction. This is quite different from the usual notion of customer that often covers a number of sales – as CYC notes a customer can have “a one-time relationship or a more long-term relationship”. 14 A point noted by DMRB on p.71 of (Inmon 1997). -- 5 of 12 -- What is a customer? The beginnings of a reference ontology for customer Page 6 More generally, applications with a relation interpretation of customer can answer the standard questions one expects to be able to ask of a customer accounting application. If one wants to know how many customers an enterprise or division has, the application can count the number of customer relations it has. There is an identity question that this scheme raises. To illustrate it we return to another earlier example. Suppose John is a customer of enterprise A then takes his custom elsewhere and then returns to enterprise A. Are there two customer relations or one? Interestingly we do not have clear intuitions about this – our intuitions are not sufficiently refined. To answer it our best guide is probably considerations of consistency and simplicity. DMRB takes the position that there are two relations – and notes their start and end dates. This is probably the simplest position. The basis for a customer relation To guide the analysis in answering these kinds of questions, it is useful to understand the basis for a customer relation. There are many clues as to what might be ranging from a dictionary definition to ontologies such as EO. The dictionary definition, (quoted earlier) is: “one that purchases a commodity or service” The EO description is: “ACTUAL CUSTOMER: the Role of the LEGAL ENTITY agreeing to exchange a SALE PRICE for a PRODUCT in a SALE.” (Section 6.1.1 – Roles in Sales Relationships). Elsewhere the EO even more directly states that sales are the basis for customer: “The notions of customer, vendor, product and price are usually associated with sales. They are essentially roles that distinguish between the entities exchanged and the LEGAL ENTITIES involved.” (Section 6.1.1 – Roles in Sales Relationships). All three of the above extracts rightly suggest that the notion of a customer is dependent in some way upon purchase /sale transactions. Their use of the terms purchase, sale and actual raises some naming issues that are dealt with below. Purchases and sales The first extract refers to ‘purchases’ and the second ‘sales’. They are referring to the same objects but from different perspectives. From the perspective of the party offering the product for sale, the transaction is a sale. From the perspective of the party buying, it is a purchase. Typically purchase and sale are used to distinguish the party who brings the cash into the transaction. It is important to note that the purchase-sale perspective, though often aligned with the customer-supplier perspective, it not always so. It is often the case that a customer will purchase a product and a supplier sell it, but there are many (counter-)examples of customers selling to a supplier. For example, a stockbroker both purchases and sells securities for his customers. Similarly, a pawnbroker purchases items for cash from his customers. As the examples show, the purchase-sale and customer-supplier distinction have different bases15 . To avoid confusion the types of transaction we are discussing here will be called customer-supplier transactions. Potential customers (and suppliers) The dictionary extract talks about a ‘customer’, where the EO extract talks about ‘ACTUAL CUSTOMER’. These refer to the same thing – a customer in a customer-supplier transaction. For the moment, this paper follows the dictionary convention in using customer to refer to actual customers, while recognising that potential customers – and potential transactions – exist. This is a common convention appearing in many applications – including CYC, which notes about its notion of customers both that agents “must actually buy something” and that this is a “narrower meaning than colloquial English”16 . 15 The DMRB description of the standard sales and purchase models shows that these assume there is no distinction – see p.68 of (Inmon 1997). 16 The full text is: “The predicate #$customers represents a relationship between two #$Agents. (#$customers AGENT1 AGENT2) means AGENT1 sells goods and/or services to AGENT2. AGENT2 must actually buy something from AGENT1 in order to be one of AGENT1's #$customers. (Thus, #$customers has a narrower meaning than `customer' in colloquial English, which includes potential buyers.)” -- 6 of 12 -- What is a customer? The beginnings of a reference ontology for customer Page 7 From basis to relation The customer-supplier transactions are the basis for a customer relation – without the transaction there is no (actual) relation. In the degenerate case, the relation can be based upon a single transaction. Typically however, there are a number of transactions and the greater the number the stronger the relation. Benchmarking by customer type The review of typical customer types in existing application provides us with a good first level benchmark for assessing the precision with which an application is representing a customer. It is relatively easily to determine which customer type an application is using and then to see the implications in terms of restricted functionality. Where a number of applications are being considered they can easily be ranked in table. An example using the applications mentioned in the text is given below. Customer Type Precision Level Level 1 Particular Level 2 Role Level 3 Relation Standard Sales / Order Model X ISO/IEC 10746 Database Example X EO X SUMO X CYC X DMRB X Table 1 – Example of a First Level Benchmark Table Of course these rankings only give the broad overall picture. But they provide a framework for a more detailed analysis into whether applications have (or need) workarounds that try and bypass the restrictions that come with their choice of customer type. CEO’s analysis of customer type To date the majority of the CEO analysis has focussed on the first core category of person. Customer- supplier transaction (and so customer-supplier relation) naturally belongs to the second core category transaction – on which not much work has yet been done. However, the analysis of person has looked at a couple of areas that show the interpretation of the type of customer as a relation is inadequate – and found an interpretation that does not have these inadequacies. The first of these areas is the mereology of organisations – a much neglected area. This examines the way in which persons (including organisations) are part of organisations. It turns out that this helps to explain the nature of customer relations and provide a more accurate picture of what they are. The second area relates to an analysis by Margaret Gilbert into what she calls plural subjects – which, for our purposes, can be considered organisations17 . Her central conclusion 18 is that agreements are the archetypal plural subject. This makes agreements into a type of organisation or (CEO) person. These two areas, and how they relate to customer, are described below. Precisifying our unclear, even mistaken, current intuitions Gilbert’s conclusion is not immediately intuitively obvious and, as this suggests, it helps to refine our current intuitions rather then merely represent a more accurate picture of them. Customer and organisation are socially constructed objects19 , and it may seem odd that people (society) should not have an exact intuition of what they have constructed. Yet philosophers working in this area (for example, Margaret Gilbert and John Searle) consistently note that the intuitions of people creating and working with these socially constructed objects are often not only unclear but mistaken. 17 Margaret Gilbert regards membership of a plural subject as being the product of something like informed consent – which, as she notes, is not obviously the case for some enterprises. Following legal convention, the CEO takes as given that enterprises are plural subjects, which results in a weaker membership condition. 18 For a refreshing short and simple statement of her analysis see pp. 379-80 (Gilbert 1992) 19 For more on social construction see, for example, (Searle 1995). -- 7 of 12 -- What is a customer? The beginnings of a reference ontology for customer Page 8 Mereology of organisations It may not be immediately clear how understanding the mereology of organisations can give us a better idea of what a customer is. The examples below illustrate the need for a better understanding. The next section describes how the CEO organisational mereology provides it. Example of nested (mereological) customer relations Many representations of customer relations assume that they are flat and exclusive. They do not take account of the way in which these relations are inherited up and trickle down an organisation’s mereological hierarchy building a nested and overlapping hierarchy of relations. It becomes useful to be able to represent this hierarchy with its nesting and overlapping when an enterprise starts aiming for more global customer management. As a thought experiment, consider Zenith Industries whose only relationship with Acme is having its Electronics Division as a customer. Customer relations are automatically inherited up the mereological hierarchy. This implies that Zenith also has a customer relation with Acme 20 . There is a sense in which this is the ‘same’ relation as the same set of transactions forms the basis for both relations. This is reflected in the way in which the customer accounting would be done: it would say Zenith only has one customer. Things get a bit more tricky if Zenith also has another division of Acme (its IT Division, say) as a customer. This also implies that Zenith also has a customer relation with Acme. However, here the Acme level relation seems to have the two divisional level relations as parts. The sets of transactions forming the basis for the divisional relation are sub-sets of those forming the basis for the Acme level relation. This feels correct, as one would expect that if Zenith wanted to manage its relation at the Acme level, then it would see managing each of the divisional relations as part of this. To represent these situations properly one needs to be able to represent the firstly the whole-part relation between the organisations and secondly the seeming ‘sameness’ and parthood of the customer relation. It would also be useful to understand why the relation are inherited automatically. These kind of automatic inheritances are often the result of an underlying structure. Example of successive customer relations Acme’s divisions divide Acme at a particular time. We can get a similar situation over time. Organisations can and do change their legal form: a topical example would be partnerships incorporating. In western law, organisations are not allowed to change legal form, so this is accomplished by terminating the original legal entity and having a new legal entity with the new form take over as a successor. Let’s assume that Acme Partners is a customer of Zenith Industries and that it is incorporated and becomes Acme plc. From a business perspective, there is little or no change in the customer relation. This assumes a single customer Acme that persists through a change in legal form (and name), with which the relation holds. However, from a legal point of view there are only the two legal entities. An integrated view recognises three Acmes, where Acme Partners and Acme plc are temporal stages of Acme. It would also recognise a similar structure in Zenith’s customer relation. To represent these situations properly one needs to be able to represent both the organisations and customer relations as temporal stages of other organisations and customer relations. It would also be useful to represent the successor relations and have some explanation of why the organisations being temporal stages implies that their customer relations are (literally) inherited. CEO’s Person mereology The CEO analysis focused on person (which includes humans and organisations) and a large part of the analysis centred on its mereology – in particular how organisations are parts of organisations. The results help to explain the examples above. The CEO regards organisations, like humans, as physical: the main difference being that they are intentionally constructed. It takes the view that organisations are constituted by the relevant actions of their members. For example, the football playing actions of the football club members are the parts of the football club – and so on. This provides a neat explanation for problem cases such as organisations that have the 20 For simplicity we do not bother with a caveat that Acme’s division is not a subsidiary but a ‘real’ division (otherwise the inheritance is more complicated). -- 8 of 12 -- What is a customer? The beginnings of a reference ontology for customer Page 9 same members. They are different because they are constituted by different activities – rather than different members. The CEO analysis developed this to explain a range of cases. This approach explains the mereology of the organisations in the examples. As Acme’s Electronics Division is part of Acme, all its activities are also activities of Acme. Each of the Zenith customer-supplier transactions involved some activity on the division’s part and this activity is part of both the division and Acme. This explains the seeming sameness of the customer relations – they are underwritten (in a way that is explained below) by the same activities. This activity-constitution approach also neatly explains what is going on in the other examples. Consider the example where Acme has two divisions both with a customer relations with Zenith. The activities in each division constitute their participation in the customer relations, with the sum of the activities constituting Acme’s participation in the customer relation. The Acme Partners / plc example has a similar explanation. Agreements as plural subjects Gilbert has an overwhelming range of arguments for her position that agreements are plural subjects (roughly CEO persons). There is not space to repeat her analysis here, it can be found throughout (Gilbert 1992). The essence of the analysis is that an agreement (or transaction) is necessarily a joint agreement entered into by the participants jointly – and the participants acting jointly constitute a plural subject. This suggests that customer is of a new type – plural subject, which is formally a particular. To distinguish this new interpretation from the previous one, we will call it customer relationship – customer subject is too unwieldy a name. Gilbert also offers a rough rule of thumb for identifying plural subjects – whether one can use the pronoun ‘we’ of the object – the Gilbert test. Both customer-supplier transactions and customer relationships pass this test. One can say of a transaction that ‘we have agreed to do such and such’. And one can say of a client relationship that ‘we have done business this way in the past’. Applying the CEO analysis to Gilbert’s position, one takes agreements, as plural subjects – and so CEO persons – as constituted by their activities. This gives a simple neat explanation of the features of customer relationship that we have looked at so far. Under this analysis there are two ways of looking at the customer-supplier transaction. At one level, it is a person (plural subject) constituted by the activities of the participants. As first Acme example showed, there may be a nesting of participants for a participant in the transaction – the illustration below in Figure 1 can help one visualise this. Electronics Division Acme Zenith Industries Transaction Participations Figure 1 - Nested Acme participation At another level, these transaction-persons are at the core of a state of affairs that records the participants in the transaction-person. So in the example in Figure 1 above, there are two states of affairs. One involves Acme participating as a customer in the transaction-person and Zenith participating as a supplier. The other involves Acme’s Electronics Division participating as customer in the transaction-person and Zenith participating as supplier. The seeming ‘sameness’ mentioned earlier is explained because the same transaction-person is involved – the difference due to wider and narrower participations. In the degenerate case where there is only one transaction, the transaction is also the relationship. In the more usual case, where there are a number of transactions, the relationship is the fusion of the transactions. -- 9 of 12 -- What is a customer? The beginnings of a reference ontology for customer Page 10 Here the individual transaction-persons are parts of the relationship-person. This fits neatly with the way people speak. It seems natural to say, in relation to the second example, that there are two parts to our global relationship with Acme, the relationships with the Electronics and IT divisions. The illustration below helps one to visualise this – and see the various levels of nesting involved. IT Division Acme Zenith Industries Acme Level Relationship Acme’s Participation Electronics Division Divisional Level Relationships Zenith’s Participation Figure 2 – Divisional relationships as parts of Acme’s relationship Customer (relationships) as particular persons In this scheme, we have come full circle in terms of the formal type of customer. Under this interpretation, it is of the formal type ‘particular’ – a particular person. Even though this is the same formal type as the standard sales / order model, it is a radically different perspective. The scheme deals with all the various features of customer relationships that have been looked at. It is an improvement on the earlier interpretations. For example, it explains the mereology of customer relationships and the associated inheritance of relationships in a simple direct way that the relationship type interpretation does not. It is also a simpler more general interpretation, using a common framework for organisations, transactions and relationships. Further work One of the intriguing areas for future work that the analysis has suggested is that the notion of a customer relationship may not be fundamental. That there is a more general fundamental notion of Counterparty Relationship underlying our idea of customer and supplier relationship and that what we call a customer- supplier relationship may in fact be a family of related, overlapping notions that need to be unbundled. The first point to note is that there are a number of markets where the participants do not – and often cannot easily (or usefully) – fit transactions into a pattern of a customer purchasing from supplier. Typically these are trading markets – such as the interbank foreign exchange market. Here the participants trade currencies with each other – neither trading counterparty is a customer or a supplier. Because the participants in the transactions are symmetrical, it is virtually impossible to divide them sensibly into customer and supplier. For the time being, this non-customer trading relationship has been named a Trading Counterparty Relationship. The general relationship encompassing both this and the customer-supplier relationship has been named a Counterparty Relationship21 . Secondly, though there are a number of markets where there is a long tradition of identifying a customer and supplier participating in the transaction, no-one seems to able to identify a general principle behind their practices. Different areas seem to use different principles. For example, the notion of customer in retail markets, such as banking, is based around business patronage. Whereas in manufacturing enterprises, it 21 CYC also recognises a more general relationship - #$doesBusinessWith. -- 10 of 12 -- What is a customer? The beginnings of a reference ontology for customer Page 11 seems to be based on the direction of flow of goods through the enterprise as described, for example, in Porter’s value chain22 . A future task is to analyse current practices to identify the various principles underlying the use of customer in the different areas to develop a taxonomy of Counterparty Relationships. It may well turn out when this is done that the notion of customer no longer has a front place. Conclusion It is worth noting that the precisification of customer follows a common pattern in the CEO analysis – and in the history of science. The analysis reveals a radically different perspective (a paradigm shift) of an ordinary everyday notion, one that is not only more precise but simpler and more general. These benefits flow through to the implemented system. From a more immediately practical point of view, the analysis has identified areas in the current commonly used notion of customer that are insufficiently precise for large customer-oriented applications and offered the beginnings of a solution. 22 Porter, Michael E., “Competitive Advantage”. 1985, Ch. 1, pp 11-15. The Free Press. New York. -- 11 of 12 -- What is a customer? The beginnings of a reference ontology for customer Page 12 References (BOROProgram:http) The BORO Program http://www.boroprogram.org/ (Breuker 1997) Breuker J, Valente A., Winkels R. Legal Ontologies: A Functional View in P.R.S. Visser and R.G.F. Winkels, Proceedings of the First International Workshop on Legal Ontologies, 1997 (CYC:http) CYC - http://www.cyc.com/publications.html (EO:http) EO, http:// www.aiai.ed.ac.uk /project/ enterprise/enterprise/ ontology.html (Fox 1993) Fox, M.S., Chionglo, J., Fadel, F., A Common-Sense Model of the Enterprise, Proceedings of the Industrial Engineering Research Conference 1993. (Fox 1996) Fox, M.S., Barbuceanu, M., and Gruninger, M., An Organisation Ontology for Enterprise Modelling: Preliminary Concepts for Linking Structure and Behaviour, Computers in Industry, Vol. 29, pp. 123-134. 1996 (Gilbert 1992) Gilbert, M.. On social facts. Princeton, N.J., Princeton University Press, 1992. (Hay 1997) Hay David C., Data Model Patterns: Conventions of Thought, Dorset House, 1997. (Inmon 1997) Inmon W.H.. The Data Model Resource Book: A Library of Logical Data and Data Warehouse Models, John Wiley and Sons, 1997. (ISO10746-1 1995) ITU-T X.901 | ISO/IEC 10746-1 ODP Reference Model Part 1. Overview. 1995 DIS (E) (Partridge 1996) Partridge, C. Business Objects: Re-Engineering for Re-Use, Butterworth-Heinemann, 1996. (Partridge 2001) Partridge C. A synthesis of state of the art Enterprise Ontologies. In K.Baclawski, H.Kilov (Eds.). Proceedings of the Tenth OOPSLA Workshop on behavioral semantics (Tampa Bay, 2001). Northeastern University, 2001 (Porter 1985) Porter, M. E. Competitive advantage: creating and sustaining superior performance. New York, Free Press, 1985 (Searle 1995) Searle, J. R. (1995). The construction of social reality. New York, Free Press, 1995. (Silverston 2001a) Silverston, L. The data model resource book. Revised Edition. Volume 1. New York, John Wiley, 2001 (Silverston 2001b) Silverston, L. The data model resource book. Revised Edition. Volume 2. New York, John Wiley, 2001 (SUMO:http) SUMO - Suggested Upper Merged Ontology http://ontology.teknowledge.com:8080/rsigma/index.html (TOVE:http) TOVE - http://www.eil.utoronto.ca/tove/ (Ushold 1997) Uschold, M., King, M., Moralee, S., and Zorgios, Y. The Enterprise Ontology, AIAI, The University of Edinburgh, 1997 (Ushold 1998) Uschold, M., King, M., Moralee, S., and Zorgios, Y. The Enterprise Ontology, in The Knowledge Engineering Review, Vol. 13, eds. M. Uschold and A. Tate, 1998 -- 12 of 12 --