Customer Multiple

A friend of mine shares an email thread from his organization discussing the definition of CUSTOMER, disagreeing as to which categories of stakeholder should be included and which should be excluded.

Why is this important? Why does it matter how the CUSTOMER label is used? Well, if you are going to call yourself a customer-centric organization, improve customer experience and increase customer satisfaction, it would help to know whose experience, whose satisfaction matters. And how many customers are there actually?

The organization provides services to A, which are experienced by B and paid for by C, based on a contractual agreement with D. This is a complex network of actors with overlapping roles, and the debate is about which of these count as customers and which don't. I have often seen similar confusion elsewhere.

My friend asks: Am I supposed to have a different customer definition for different teams (splitter), or one customer definition across the whole business (lumper)? As an architect, my standard response to this kind of question is: it depends.

One possible solution is to prefix everything - CONTRACT CUSTOMER, SERVICE CUSTOMER, and so on. But although that may help sort things out, the real challenge is to achieve a joined-up strategy across the various capabilities, processes, data, systems and teams that are focused on the As, the Bs, the Cs and the Ds, rather than arguing as to which of these overlapping groups best deserves the CUSTOMER label.

Sometimes there is no correct answer, but a best fit across the board. That's architecture for you!

 

Many business concepts are not amenable to simple definition but have fuzzy boundaries. In my 1992 book, I explain the difference between monothetic classification (here is a single defining characteristic that all instances possess) and polythetic classification (here is a set of characteristics that instances mostly possess). See also my post Modelling Complex Classification (February 2009).

But my friend's problem is a slightly different one: how to deal with multiple conflicting monothetic definitions. One possibility is to lump all the As, Bs, Cs and Ds into a single overarching CUSTOMER class, and then provide different views (or frames) for different teams. But this still leaves some important questions open, such as which of these types of customer should be included in the Customer Satisfaction Survey, whether they all carry equal weight in the overall scores, and whose responsibility is it to improve these scores.

 

In her book on medical ontology, Annemarie Mol develops Marilyn Strathern's notion of partial connections as a way of overcoming an apparent fragmentation of identity - in our example, between the Contract Customer and the Service Customer - when these are sometimes the same person.

Being one shapes and informs the other while they are also different identities. ... Not two different persons or one person divided into two. But they are partially connected, more than one, and less than two. Mol pp 80-82

Mol argues that frictions are vital elements of wholes,

... a tension that comes about inevitably from the fact that, somehow, we have to share the world. There need not be a single victor as soon as we do not manage to smooth all our differences away into consensus. Mol p 114

Mol's book is about medical practice rather than commercial business, but much of what she says about patients and their conditions applies also to customers. For example, there are some elements that generally belong to "the patient", and although in some cases there may be a different person (for example a parent or next-of-kin) who stands proxy for the patient and speaks on their behalf, it is usually not considered necessary to mention this complication except when it is specifically relevant.

Similar complexities can be found in commercial organizations. Let's suppose most customers pay their own bills but some customers have more complicated arrangements. It should be possible to hide this kind of complexity most of the time.

Human beings can generally cope with these elisions, ambiguities and tensions in practice, but machines (by which I mean bureaucracies as well as algorithms) not so well.  Organizations tend to impose standard performance targets, monitored and controlled through standard reports and dashboards, which fail to allow for these complexities. My friend's problem is then ultimately a political one, how is responsibility for "customers" distributed and governed, who needs to see what, and what consequences may follow.

(As it happens, I was talking to another friend yesterday, a doctor, about the way performance targets are defined, measured and improved in the National Health Service. Some related issues, which I may try to cover in a future post.)

---

Annemarie Mol, The Body Multiple: Ontology in Medical Practice (Duke University Press 2002)

Richard Veryard, Information Modelling - Practical Guidance (Prentice-Hall 1992) 

• Polythetic Classification Section 3.4.1 pp 99-100
• Lumpers and Splitters Section 6.3.1, pp 169-171
  

Walking Wounded

Let us suppose we can divide the world into those who trust service companies to treat their customers fairly, and those who assume that service companies will be looking to exploit any customer weakness or lapse of attention.

For example, some loyal customers renew without question, even though the cost creeps up from one year to the next. (This is known as price walking.) While other customers switch service providers frequently to chase the best deal. (This is known as churn. B2C businesses generally regard this as a Bad Thing when their own customers do it, not so bad when they can steal their competitors' customers.)

Price walking is a particular concern for the insurance business. The UK Financial Conduct Authority (FCA) has recently issued new measures to protect customers from price walking.

Duncan Minty, an insurance industry insider who blogs on Ethics and Insurance, believes that claims optimization (which he calls Settlement Walking) raises similar ethical issues. This is where the insurance company tries to get away with a lower claim settlement, especially with those customers who are most likely to accept and least likely to complain. He cites a Bank of England report on machine learning, which refers among other things to propensity modelling. In other words, adjusting how you treat a customer according to how you calculate they will respond.

My work on data-driven personalization includes ethics as well as practical considerations. However, there is always the potential for asymmetry between service providers and consumers. And as Tim Harford points out, this kind of exploitation long predates the emergence of algorithms and machine learning.

 

Update

In the few days since I posted this, I've seen a couple of news items about autorenewals. There seems to be a trend of increasing vigilance by various regulators in different countries to protect consumers.

Firstly, the UK's Competition and Markets Authority (CMA) has unveiled compliance principles to curb locally some of the sharper auto-renewal practices of antivirus software firms. (via The Register).

Secondly, new banking rules in India for repeating payments. Among other things, this creates challenges for free trials and introductory offers. (via Tech Crunch)

---

Machine Learning in UK financial services (Bank of England / FCA, October 2019)

FCA confirms measures to protect customers from the loyalty penalty in home and motor insurance markets (FCA, 28 May 2021)

Tim Harford, Exploitative algorithms are using tricks as old as haggling at the bazaar (2 November 2018)

Joi Ito, Supposedly ‘Fair’ Algorithms Can Perpetuate Discrimination (Wired Magazine, 5 February 2019)

Duncan Minty, Is settlement walking now part of UK insurance? (18 March 2021), Why personalisation will erode the competitiveness of premiums (7 September 2021)

Manish Singh, Tech giants brace for impact in India as new payments rule goes into effect (TechCrunch, 1 October 2021)

Richard Speed, UK competition watchdog unveils principles to make a kinder antivirus business (The Register, 19 October 2021)

Related posts: The Support Economy (January 2005), The Price of Everything (May 2017), Insurance and the Veil of Ignorance (February 2019)

Related presentations: Boundaryless Customer Engagement (October 2015), Real-Time Personalization (December 2015)

Rolling Review

I have long argued for the benefits of an outside-in view of business architecture. In 2008-9, Tony Bidgood and I developed a worked example based on the fictional delivery company Springfield Parcels, to illustrate a range of different business improvement paradigms and modelling notations. One of the key insights from this material was the importance of modelling your customer's process as well as your own. See also my post on Customer Orientation (May 2009).

A few years later, I worked with a regulator that had a complex relationship with the industry (industries) that it was regulating. The regulator's processes consisted largely of a series of complex responses to external events and activities, so I built a business service architecture to provide an outside-in view.

In those not-so-far-off days, regulated companies submitted meticulously compiled dossiers of information to the regulator for review and adjudication. This was a highly sequential and slow process, each stage typically taking several months if not years.

This delay was always a particular challenge in industries such as pharmaceuticals, where regulatory approval is needed before a new drug can be put on the market.

The UK drug regulator, the Medicines and Healthcare products Regulatory Agency (MHRA) was already looking at changing this sequential process before the COVID-19 pandemic struck. With the new Rolling Review approach, the regulator is able to start pre-assessment during the late clinical trials, and substantially reduce the time to market for innovative new treatments. This helps to explain the remarkable speed with which the COVID vaccines were tested and approved. The BBC Horizon programme includes a contribution from Christian Schneider, the MHRA's Interim Chief Scientific Officer.

The principle of rolling review also applies internally within organizations, where innovations often need to be reviewed from various perspectives. Some stakeholders prefer to wait until all the details of the innovation have been worked out, so they can be reviewed holistically. Others prefer to be involved as early as possible, since this provides more chance to influence the overall design and approach. Late involvement may seem a more efficient use of expert resource, but often leaves the expert with little more than a go/nogo decision.

We often see this dilemma with privacy and security. Advocates of security-by-design and privacy-by-design like to get in early; however, it may be difficult to carry out a rigorous Data Protection Impact Assessment (DPIA) if you don't yet know any of the answers to the questions on the template.

The fundamental point here is that all these side processes - regulation, assessment or governance - are only meaningful in terms of the main processes that they are regulating, assessing or governing. So it doesn't make sense to optimize the side process in isolation. The point is to innovate quickly and safely, not to make life easier for the regulators. And the outside-in business service architecture is a great tool for focusing everyone's minds on this.

---

ICO, What is a DPIA?

Sandra Kanthal, Marvellous Medicine (BBC Radio 4 - Horizon, 20 June 2021)

MHRA, Rolling Review for Market Authorisation Applications (UK Government, 31 December 2020)

Richard Veryard and Tony Bidgood, A Brief Evaluation of Business Modeling and Improvement Methodologies (CBDI Journal, December 2008)

Information Superiority and Customer Centricity

The business value of consumer analytics and big data is not just about what you can discover or infer about the consumer, but how you can use this insight promptly and effectively across multiple touchpoints (including e-commerce systems and CRM) to create a powerful and truly personalized consumer experience.

In a new article for the Cutter Business Technology Journal, I explore how the concept of information superiority interacts with the concept of customer centricity, and look at three modes of information superiority: conventional, adaptive, and collaborative.


Richard Veryard, Information Superiority and Customer Centricity (Cutter Business Technology Journal, March 2017)

Personalized emails (not)

Here's a sample from my email inbox, which arrived yesterday.

Dear Richard
I know how important your organization's big data strategy is. That's why I want to personally invite you to attend our webinar. 

How does he know? Is he basing his knowledge on big data or extremely small data? I'm curious to know which.

And what is his idea of a personal invitation? Does he think that personalization is achieved by having his email software insert my first name into the first line? Gosh, how very customer-centric!

But at least the email arrived at a civilized time. Unlike the one that arrived as I was getting into bed the other night, from an eCRM system whose idea of personalization didn't extend to checking what time zone I was in. I guess one must be grateful for these small mercies.

On Customer Insight

On Customer Insight from Richard Veryard

Ghetto Wifi 2

Following my post on Ghetto Wifi, I passed a pub yesterday with a sign "Free wifi for customers only".

Thought of another perspective on this problem. How long do you remain a customer after you have bought a drink? One hour? One day? Is there some kind of dwindling right to use the facilities as time passes? If you bought a coffee within the last half hour then you are a full-status customer with full rights; if you haven't bought a coffee in the last two hours, then maybe your customer rights are weaker.


Let's look at some more examples. If you have lunch in a restaurant, and then do some shopping, can you then go back to the restaurant to use the toilet before driving home? (If you left a reasonable tip, then maybe the aura of "customerhood" still lingers.) If you have lunch in a pub, can you leave your car in the "customers only" car park for the rest of the day? Some establishments have strict limits - for example, some supermarkets have free parking for two hours, and then start clamping or ticketing people who stay longer.

Obviously there will always be some people to try to cheat - to use the facilities without buying anything at all. The point here isn't whether this is possible, or the extent to which the establishment tries to make you feel welcome (in order to convert you to future customer) or unwelcome (to reserve its facilities for genuine customers), but what moral rights you have in the first place.

Some people might think that the "customers only" goes without saying - you shouldn't need a notice - but presumably there are some people whose behaviour will be influenced by a reminder that these facilities are intended for genuine customers.

So it comes down to a question of what counts as a genuine customer, and for how long.

Customer Orientation

@adamshostack objects to something I quoted from Clayton Christensen: Understanding your customer isn't enough.

What Christensen is saying, and I absolutely agree with this, is that understanding the customer is the wrong level of analysis (granularity). What we need to focus on is the job the customers are trying to get done when they use your product or service.

Adam thinks this is "fascinating & wrong. W/o understanding customer orientation, you can't from job" (via Twitter).

I think pharmaceutical sales and marketing provides an excellent example of why Christensen is correct. As I have explained before, a typical twentieth-century business model involved drug company representatives making personal visits to doctors. To support this kind of model, you collected lots of information about the doctor - not just professional (size of practice, specialization, and so on) but also personal (ethnic group, sexual preference, ages of children, golf or squash). The drug company employed a range of representatives of different types, and selected the appropriate rep to visit a white gay squash-playing doctor.

The trouble with this business model is that it is not aligned with the products and services of the drug company. Doctors increasingly regard these kind of sales visits as a complete waste of time; even if they accept the hospitality of the drug companies, they have learned to be resistant to the sales messages.

What the drug company needs to focus on is how to provide more value to the doctor. For this purpose, you don't need information about the doctor, you need information about what the doctor actually does. In particular, you have to understand the decision process in which the doctor thinks about prescribing particular drugs to a particular patient, as well as the collaborative process in which the doctor and other healthcare practitioners discuss alternative courses of treatment with a patient.

Understanding the doctor is missing the point. The opportunity to create business value comes from understanding the work of the doctor. Different doctors may have different styles and habits, and may approach similar cases in different ways (although this is increasingly constrained by procedure and protocol imposed by health authorities or health insurance companies). That's the right level of analysis.

One technique we use for this analysis is business process modelling. But we're not interested in the company's own processes, we're interested in the customers' processes, and in the variations in these processes. Business survival depends on providing products and services that add value to these customer processes, so it's the customer processes we need to understand. Not the customer as a passive and indivisible entity (as in many CRM systems) but as an active bundle of behaviour and capability and purpose.


See also Clayton Christensen on jobs needing to get done (via Anders Sundelin).

---

Related post

Misunderstanding CRM and big data (November 2014)

Update: I have removed links to tweets by Chris Lawer and Gunnar Peterson, who were part of the original conversation, because the URLs in their tweets now point to irrelevant and NSFW content.

Laundry as Intelligence

During the "troubles" in Northern Ireland, the British Army operated a laundry - an apparently innocent laundry with some additional hidden functionality - checking dirty clothes for traces of explosive. [Washington Post via Bruce Schneier]

In my earlier post Services Like Laundry I said "I do not expect the laundryman to draw any inferences from the state of my clothes, or to pass these inferences to anyone". Clearly the actions of the British Army would count as a breach of this kind of expectation, but this would be justified by its effectiveness as a clever counter-terrorism measure. However, laundries might well test for various other substances, or test the DNA of any stains on the clothing, for a broad range of purposes other than counter-terrorism.

So what's the lesson from this? Basically, if you have any illicit substances or just embarrassing stains on your clothing, you can't trust the laundry service not to notice. And you certainly can't specify this not-noticing as part of the service contract - what are you going to do, draw the laundryman's attention to the thing he isn't supposed to notice?

And what if the laundryman noticed your shirts were getting a little frayed about the collar, and sold your address, together with details of your designer-label preferences, to a mail order shirt supplier? You might think this was unreasonable if you knew about it, but you would probably never find out. You might receive a mailshot from the shirt supplier, but you probably wouldn't connect it with the laundryman. (One possible mechanism for tracing abuse of your name and address is to give slightly variant names and addresses to every supplier, but lots of organizations nowadays have clever data cleansing software that wipes out these variations.)

How does this apply to other kinds of service? If I use CRM-as-a-service, how can I prevent my service provider picking up information about my customers? If I use a third-party delivery service, how can I prevent the service provider selling details of my customers and their purchasing habits to my competitors? How can I even specify this as part of the service level agreement?

WS Security standards cover some aspects of confidentiality and trust, but this merely relates to the security of a message in transit (at the technology level), and not to the broader questions of confidentiality and trust between two parties (at the enterprise level).

According to legend, the automatic telephone exchange was invented by an undertaker (Almon Strowger) who believed his business was being redirected to his competitors by corrupt telephone operators. (See Call Forwarding.) So this suggests a possible answer to this difficulty is to redesign the service architecture to reduce the enterprise vulnerability, supported by more sophisticated technology. For example, does your CRM provider really need unencrypted names and addresses, or can you pass your customer data through an encryption module?

So what's the lesson from this? You need an enterprise view of trust and security that is supported by (aligned with) a technology view of trust and security. The relationship between these two views is tough.

Responding to Uncertainty 2

Following my previous discussion on Faithful Representation and Uncertainty, here's another example. Which of the following statements are facts, straightforwardly representing something in the "real world", and which ones are more problematic?

• John has a garden behind his house. Three quarters of the garden is plain green, presumably grass.
  
• There is an object in the garden visible from the satellite picture. It looks as if it might be a rusty lawnmower. It has been there all winter.
• It is nearly Spring. John might need a new lawnmower soon.

All of these statements might be represented by events, which are fed into an event processing system. As a result, the computer sends John an attractive brochure of garden equipment, including a range of lawnmowers.

Note that many of the observations are uncertain. The grass might be artificial, and the rusty object might be an exercise bike. The garden supply company might wish to purchase higher-definition images, or invest in better image recognition software to improve the interpretation of the raw images, but this investment would be wasted unless there was a good chance of increasing the number of lawnmowers sold.

In any case, there are lots of other things that might influence John's purchasing decision. John might have another lawnmower in the shed. He might be too busy to mow his garden, so he pays Harry (who brings his own mower). Meanwhile, John might want to buy a new lawnmower as a house-warming present for his daughter.

From both a business perspective and an engineering perspective, we can construct effective and profitable systems without bothering our heads whether the rusty lawnmower really exists, or whether it is just an unreliable interpretation of pixels on a satellite image. And what about John's desire for a new lawnmower? Does this really exist, or is this just a bit of hopeful speculation by the marketing department?

So I want to build models that include things like probability, intentionality and the future. Do these things "exist" in the real world, or are they some kind of construction? Rick Murphy explores the question of Representation and Realism in the context of the Semantic Web. In a later post on Signs of the Singularity, he argues that because the semantic web follows Tarski, model theory implies realism. "The relation between a model and the world may be only one of approximation, but without realism, technological utopianism quickly precedes to simulacra and simulation."

I don't think it's as simple as all that. And if it was, would it matter?

---

See follow-up post on Analyzing the Rusty Lawnmower.

Responding to Uncertainty

How does a system respond intelligently to uncertain events?

"A person may take his umbrella, or leave it at home, without any ideas whatsoever concerning the weather, acting instead on general principles such as maximin or maximax reasoning, i.e. acting as if the worst or the best is certain to happen. He may also take or leave the umbrella because of some specific belief concerning the weather. … Someone may be totally ignorant and non-believing as regards the weather, and yet take his umbrella (acting as if he believes that it will rain) and also lower the sunshade (acting as if he believes that the sun will shine during his absence). There is no inconsistency in taking precautions against two mutually exclusive events, even if one cannot consistently believe that they will both occur." [Jon Elster, Logic and Society (Chichester, John Wiley, 1978) p 84]

Austrian physicist Erwin Schrödinger proposed a thought experiment known as Schrödinger's cat to explore the consequences of uncertainty in quantum physics. If the cat is alive, then Schrödinger needs to buy catfood. If the cat is dead, he needs to buy a spade. According to Elster's logic, he might decide to buy both.

At Schrödinger's local store, he is known as an infrequent purchaser of catfood. The storekeeper naturally infers that Schrödinger is a cat-owner, and this inference forms part of the storekeeper's model of the world. What the storekeeper doesn't know is that the cat is in mortal peril. Or perhaps Schrödinger is not buying the catfood for a real cat at all, but to procure a prop for one of his lectures.

Businesses often construct imaginary pictures of their customers, inferring their personal circumstances and preferences from their buying habits. Sometimes these pictures are useful in predicting future behaviour, and for designing products and services that the customers might like. But I think there is a problem when businesses treat these pictures as if they were faithful representations of some reality.

This is an ethical problem as well as an epistemological one. You've probably heard the story of a supermarket, which inferred that some of its female customers were pregnant and sent them a mailshot that presumed they were interested in babies. But this mailshot was experienced as intrusive and a breach of privacy, especially as some of the husbands and boyfriends hadn't even been told yet. (A popular version of the story involves the angry father of a teenaged girl.)

Instead of trying to get the most accurate picture of which customers are pregnant and which customers aren't, wouldn't it be better to construct mailshots that would be equally acceptable to both pregnant and non-pregnant customers? Instead of trying to accurately sort the citizens of an occupied country into "Friendly" and "Terrorist", wouldn't it be better to act in a way that reinforces the "Friendly" category?

Situation models are replete with indeterminate labels like these ("pregnant", "terrorist"), but I think it is a mistake to regard these labels as representing some underlying reality. Putting a probability factor onto these labels just makes things more complicated, without solving the underlying problem. These labels are part of our way of making sense of the world, they need to be coherent, but they don't necessarily need to correspond to anything.


Minor update 10 Feb 2019

Faithful representation

Systems people (including some SOA people and CEP people and BPM people) sometimes talk as if a system was supposed to be a faithful representation of the real world.

This mindset leads to a number of curious behaviours.

Firstly, ignoring the potential differences between the real world and its system representation, treating them as if they were one and the same thing. For example, people talking about "Customer Relationship Management" when they really mean "Management of Database Records Inaccurately and Incompletely Describing Customers". Or referring to any kind of system objects as "Business Objects". Or equating a system workflow with "The Business Process".

Secondly, asserting the primacy of some system ontology because "That's How the Real World Is Structured". For example, the real world is made up of "objects" or "processes" or "associations", therefore our system models ought to be made of the same things.

Thirdly, getting uptight about any detected differences between the real world and the system world, because there ought not to be any differences. Rigid data schemas and obsessive data cleansing, to make sure that the system always contains only a single version of the truth.

Fourthly, confusing the stability of the system world with the stability of the real world. The basic notion of "Customer" doesn't change (hum), so the basic schema of "Customer Data" shouldn't change either. (To eliminate this confusion you may need two separate information models - one of the "real world" and one of the system representation of the real world. There's an infinite regress there if you're not careful, but we won't go there right now.)

In the Complex Event world, Tim Bass and Opher Etzion have picked up on a simple situation model of complex events, in which events (including derived, composite and complex events) represent the "situation". [Correction: Tim's "simple model" differs from Opher's in some important respects. See his later post The Secret Sauce is the Situation Models, with my comment.] This is fine as a first approximation, but what neither Opher nor Tim mentions is something I regard as one of the more interesting complexities of event processing, namely that events sometimes lie, or at least fail to tell the whole truth. So our understanding of the situation is mediated through unreliable information, including unreliable events. (This is something that has troubled philosophers for centuries.)

From a system point of view, there is sometimes little to choose between unreliable information and basic uncertainty. If we are going to use complex event processing for fraud detection or anything like that, it would make sense to build a system that treated some class of incoming events with a certain amount of suspicion. You've "lost" your expensive camera have you Mr Customer? You've "found" weapons of mass destruction in Iraq have you Mr Vice-President?

One approach to unreliable input is some kind of quarantine and filtering. Dodgy events are recorded and analyzed, and then if they pass some test of plausibility and coherence they are accepted into the system. But this approach can produce some strange effects and anomalies. (This makes me think of perimeter security, as critiqued by the Jericho Forum. I guess we could call this approach "perimeter epistemology". The related phenomenon of Publication Bias refers to the distortion resulting from analysing data that pass some publication criterion while ignoring data that fail this criterion.)

In some cases, we are going to have to unpack the simple homogeneous notion of "The Situation" into a complex situation awareness, where a situation is constructed from a pile of unreliable fragments. Tim has strong roots in the Net-Centric world, and I'm sure he could say more about this than me if he chose.

Does ERP matter?

Having announced his departure from SAP (apparently quitting the software industry to work on alternative energy and transport) Shai Agassi continues to blog about enterprise software on the SAP Network as well as his personal website The LongTailPipe. His latest post: Does ERP matter?

People in the software industry often use labels like ERP (enterprise resource planning) and CRM (customer relationship management) to refer to computer systems or application packages, such as those purveyed by SAP and its competitors. So most people will probably read Agassi's post as a discussion of the ongoing relevance and value of these packages.

But these packages are merely a software solution to a particular class of management problem. So we might first ask: does enterprise resource planning matter?

This is not such a stupid question as it might seem. Like MRP and MRPii before it, ERP represents a certain management style. Invoicing is integrated with inventory control and logistics not just because data management likes to have all the data in one place, not just because it makes the transaction processing more efficient and effective, but because this integration enables a set of higher-level management capabilities, including planning and coordination. ERP is therefore not just a transaction processing system, it is a command and control system.

In the early days of MRPii, I can remember considerable resistance to the notions of planning and coordination that MRPii entailed, from factory managers who were accustomed to planning next week's production of widgets quite oblivious of the fact that the warehouse was already full-to-overflowing with widgets.

And it is possible to imagine a fictional enterprise in a totally service-oriented world that doesn't need resource planning - because it doesn't possess any resources. Everything it ever needs is invoked from somewhere else in the network, on a just-in-time basis. You would still need systems to handle logistics and invoicing and all the rest, but you wouldn't need ERP.

Enterprise resource planning represents a kind of management coupling between different management functions - sales and marketing, distribution, manufacturing, purchasing. In the past, there were many enterprises where the coupling between these functions was loose and incompetent. There are many enterprises today where the coupling between these functions is now tight and efficient - and some of the credit for this improvement may go to SAP and its competitors.

Clearly we don't want to go back to a loose and incompetent style of management. But is there a real alternative to enterprise resource planning, one that is loosely coupled (as befits a service-oriented world) but still efficient and effective? I think that's the fundamental question as to whether ERP matters.

But this is not the question Agassi is addressing. I'll come back to his argument in another post.

---

See also Ian Thomas Does ERP Suck?

Value Deficit

Roman Rytov has blogged before about services from the consumer perspective. (For example, my previous post on Self-Service draws on his ideas about customers having access to their own CRM data.) In his latest post, he blogs about flaws of frequent flyer programs and sensitivity to customer needs. He points out that the standard reward point program, as provided by airlines, hotel chains and other service providers, is no longer working. It doesn't provide real competitive advantage to the service provider, and fails to accommodate the needs of different categories of customer.

For many customers, one of the most important differentiators is between private travel (where the customer is paying) and business travel (where someone else is paying). Rytov imagines (probably correctly in most cases) that private travellers would prefer to receive compensation for delays or other service shortfalls in the form of a cash refund ("the internet in your room was a bit slow - okay we'll delete that item from your bill"), while business travellers would prefer to receive extra airmiles or reward points.

But how is the service provider supposed to differentiate between private travellers and business travellers? I don't think this is as easy as Rytov asserts, and I don't think it should be that easy. Am I flying to Las Vegas for a business conference or a weekend of excess - and do I really want this to be public knowledge? Surely the best approach is to allow the customer a choice between alternative compensation schemes, rather than try to second-guess the customer's preference based on an attempted invasion of the customer's privacy.

But there are larger problems with the whole pseudo-economy of reward points, which this kind of differentiated service will not address.

• The schemes are complicated, with all sorts of arbitrary restrictions, making it practically impossible to compare like with like. Benefits are tied, and are generally not transferable. This increases the transaction cost, and reduces the economic efficiency of the market. This exemplifies a general pattern of dysfunctional service relationships - see review of Support Economy on this blog.

• The schemes are closed. Given that there is a value deficit, there is a theoretical opportunity for an independent service provider to create some value-adding services, perhaps through some kind of mash-up. But something tells me that the airlines and hotel chains would be less than enthusiastic about such innovation; and I doubt that the schemes are open enough to make such mash-up feasible.

• The schemes are primarily designed to reward employees, ultimately at the expense of their employers. I am sure there are lots of people who take extra business trips, with questionable value to the business, in order to win or retain some privileged status with the airline. Therefore the whole economy of reward points and airmiles only appears to be value-adding if you ignore the companies that are ultimately funding it.

Of course SOA thinking (such as differentiated service or context-based service) can be used to put sticking-plaster on the current schemes. Rytov is correct as far as he goes - service providers certainly need to be more sensitive to customer needs. But I believe there is an opportunity for much more radical and genuinely value-adding transformation.

• Can we unbundle the services? Why am I paying the hotel for the internet connection? Why isn't the hotel just providing me with a platform of services, from which I can compose my own experience? Who pays whom for what?

• Can we decouple the services from the reward point program? Surely there are economies of scale for the providers, as well as increased flexibility for the consumer, if reward points are transformed into some form of exchangeable token. Especially as the reward point program has long since ceased to be a focus of innovation or competitive advantage, and has become a tiresome necessity.

Data Ownership and Trust

This month, I've been looking at some complicated questions of data provenance, data protection and copyright, prompted by a tricky but fascinating client problem - how to convert a legacy archive into a network of information services. (Among other things, this involves dividing material according to the ownership of the content.)

So I was particularly interested to see the following three separate items appear in my blogreader today.


1. Identity Theft and Brand Damage

A UK charity had its donor list stolen by a hacking gang, which then proceeded to beg funds from the same donors. Source: Silicon.com via Emergent Chaos

This is being described as a security breach


2. Software as a Service

"If information about you is stored on your own computer, it's generally not available to others unless they are able to hack your machine or serve legal process on you. In contrast, if information about you is stored on Google's computers, the law generally treats it as Google's, not yours." Cindy Cohn via Tecosystems

This is being described as a privacy issue.


3. Platforms and Stacks

Alexa (part of Amazon) is exposing its index for commercial reuse, via a series of web services. Source: Jon Battelle via Simon Bisson

This is being described as a ground-breaking innovation


There are undoubtedly new business risks that emerge whenever we make a significant change in platform. (That's not to say we shouldn't change, merely that we need to do it with our eyes open. As Stephen O'Grady puts it, "the point here is not to be alarmist, but rather to build awareness".) The new technologies of interaction carry the potential of new forms of sociotechnical intimacy, which may take a little getting used to.

Most importantly, sociotechnical shifts like these may cause us to rethink whether we really own the data (or knowledge) we thought we owned. If an email platform can use email content to target advertising, if a communication platform can analyse message traffic to identify friendship clusters, what else is fair game?

Ultimately this comes down to an important strategic choice. Do we want intimate relationships with intelligent service providers, who can interpret (and customize) both content and context to provide deeper service value? Or do we want arms-length relationships with service providers that don't know us from Adam? Where does the platform stop and the true service begin?

Repurposing Data and Services

Does it make sense to talk about reusing services, or should we talk instead about repurposing?

The word repurpose is largely being pushed from the data/metadata side, especially the XML/XSL crowd. XML is certainly relevant to technical reformatting and interoperability, but may also support data being put to new uses.

• IBM defines repurposing in terms of metadata, with specific reference to XML
• The Role of XSL in e-business Solutions (May 2001), by Mark Colan of IBM
• Xerox Research on XML Schema Management

Meanwhile, some examples of data repurposing look like old-fashioned data sharing. Look at this abstract, which (when you strip away the fashionable technology such as intelligent agents) is just finding new uses for existing data.

• Using Intelligent Agents to Repurpose Administrative Data ... (Jan 2004) (abstract)

The word also makes the bandwagon-jumping antics of some product vendors explicit. For example, following 9/11, Siebel repurposed its CRM software to deal with Homeland Security. (Government Computer News, Sept 2002) What's terrorism got to do with customer relationship management, I hear you ask. Well it does, in the same sense that an FBI agent might say "He's a tricky customer."

XML is very good for this kind of repurposing, because it operates at a level of semantic vagueness where it doesn't really matter whether "customer" means "customer" or "terrorist". To my mind this is both a strength and a weakness of XML. It seems to me that if we want to promote the repurposing of services, we need to explain how to design services that can operate with a calculated lack of semantic specificity, with weak preconditions. (But strong postconditions.)


See also Reuse or Repurpose (May 2005)

From CRM to SPRM

Service providers generally engage (with more or less competence) in something called Customer Relationship Management (CRM).

If this were a symmetric world (which of course it isn’t), then we would expect service consumers to engage in something called Service Provider Relationship Management (SPRM). Why not?

I have relationships with a great many service providers, all of whom try (sometimes with comical levels of incompetence) to manage their relationship with me. One of the mechanisms I use to keep track of what they are all up to is to vary the data I give them.

If I give everyone the same email address, then I don’t know who’s been passing my address out to third parties (whether deliberately or as a result of lax security). But if I vary the email address, then the leakage is easier to track. It also helps me to sort incoming mail into folders for different levels of attention. (My notion of importance/urgency is not always the same as my service provider's notion.)

I used to do the same with street addresses, adding spurious details which I assumed the postman would ignore, but which would show up on junk mail to reveal the source. But for a long time now, I have been prevented from doing this by address cleansing routines, which convert all addresses into a standard “correct” form, and remove any spurious codes. (I was reminded of this recently, when I saw a press release for a web service for address data cleansing.)

Melissa Data Web Service
Case Study: Saab Cars USA DW Institute DS Star

There are two general points arising from this. Firstly, this example shows their CRM interfering with my SPRM. In a symmetric world, CRM and SPRM would be perfectly aligned, so this conflict is evidence of asymmetric demand. (Another example of asymmetry is in matters of trust – we are supposed to trust them, even though they evidently don’t trust us.)

Secondly, data cleanse routines support a particular set of purposes in the use of the data, and generally foreclose another set of purposes. My attitude to data cleanse is critical and selective - acceptance when absolutely necessary, awareness of side-effects, avoidance when there are viable alternatives. (In medicine, I take a similar line on antibiotics.)

Finance Industry View of security

Asymmetric trust

---

[Update May 2006] In a post called CRM is Dead, Seth Godin has just discovered something similar at Disney: Customer Managed Relationships. But this could be just trying to reassert control by the supplier. I shall be interested to know more about this.

Reification and Ratification

Reification means viewing something (such as a process or relationship) as an object. Reification is an important technique of Software Engineering. 

• Database
• Object-Orientation

What is the opposite of reification? I call it Ratification. This means viewing an object as something else (such as a process or relationship). 

Many OOSE developers use reification techniques excessively and uncritically. We therefore make a point of practising and teaching the reverse techniques. An example of the importance of ratification can be found in Customer Relationship Management (CRM).

---

Software engineers with a database background are accustomed to treating customers, products and other business concepts as data objects. From a data-oriented perspective, a key task of business systems analysis is to divide up "customer-space" and "product-space" into fixed, predictable, discrete units of customer and product. Customer and product information can then be captured as a set of data records, each representing a fixed set of facts about a specific customer or product.

But from a business perspective, this can be a gross simplification. Customer relationship management is a (collaborative) process of relating to the customer; product management is a process of developing products. Business management often needs much more flexible, fluid, complex notions of customer and product.

The object-oriented way of describing the world is extremely useful, especially for designing and managing components. It is also useful for describing the behaviour of components, and their performance in complex environments. There are excellent techniques for creating objects out of processes, out of relationships, or perhaps even out of nothing. Philosophers and software engineers have a word for this; they call it reification.

When relationships are regarded as things, this usually focuses attention either on the bridging mechanism, or on a static snapshot of the relationship, as for example represented by a legal contract. When processes or services are regarded as things, this usually focuses attention on the deliverable or end-result.

But there are limitations to an object-oriented view of systems and components. Sometimes we need the reverse procedure - to understand things as dynamic clusters of activities and relationships. We call this ratification.

Database development requires data to be identified and classified. Naive reification results in fixed and unchangeable identities and classifications - and this suits the normal constraints of data management software - but often results in information systems that are inflexible and cause difficulties to business users. Ratification of the identification and classification processes, although sometimes harder to code in software, can result in a much better alignment with business requirements.

 

Many companies (especially financial service companies) have invested large amounts of information system effort on converting their information systems to being customer-centric. This has typically been motivated by significant levels of duplication in the databases, and an inability to identify when a customer has more than one relationship with the company - e.g. multiple accounts. A common reason for this is that legacy systems have been account-centric - with separate customer details for each account. Another common reason is that the customer base has grown through merger and acquisition.

In Customer Relationship Management systems, there is typically an object called CUSTOMER, which is the primary focus of the system and its data structure. A naive view of this object is that it represents a person or company - or any other PARTY playing a customer role. A consequence of this view is that if a customer is represented twice, and if the details don't match (e.g. different addresses), then one of the records is simply wrong.

But this naive view stems from an implicit act of reification, which can sometimes produce misleading results. In a customer relationship management system, CUSTOMER is actually a reification of the customer relationship. If there are multiple relationships, it may well be appropriate to have different information associated with each relationship.

Our approach to information modelling takes these implicit reifications and analyses them to expose the underlying relationships and processes. Of course, it may still be good to reduce or eliminate duplications and discrepancies in customer information - but we think it better to do this on the basis of explicit ratification rather than implicit reification.

 

Update May 2024. The distinction I'm making here between reification and its opposite, which I've called ratification, can be compared to Simondon's distinction between ontology and ontogenesis, so I shall need to write more about that.

---

Originally posted at http://www.veryard.com/infomgt/reification.htm

Related posts: Deconstructing the Grammar of Business (June 2009)