@Cybersal complains about Amazon. "Yet again Amazon ships a tiny book with an unreliable courier that my postman could have shoved through my letterbox." and explains "Post office 10 min walk. Courier depot 30 min drive. Courier not a good option for such a low value item."
This raises an important question about Amazon's capability and willingness to manage complexity - specifically differentiation. Amazon already uses multiple alternative delivery channels, but introducing an automatic selection according to the value and size of the item might well further complicate its delivery processes. If Amazon wished to differentiate customers according to the convenience / cost of different delivery channels, it would presumably need to have some geographical reasoning capability. And if Amazon wished to differentiate those products that would fit through a customer's letterbox, it would presumably need to know the size of each customer's letterbox.
We can easily imagine that Amazon could build this kind of capability, perhaps using Google Maps and Google Streetview to check the exact location of Sally's house and estimate the size of her letterbox. But has Sally a right to complain if Amazon doesn't bother?
To what extent do customers have a reasonable expectation of sophisticated differentiation of service - from organizations in general or from Amazon in particular? We may note that most large commercial organizations are way behind Amazon in their ability to enhance customer value through differentiation, while most small commercial organizations are way behind Amazon in their ability to integrate across a complex ecosystem. Because Amazon has already done some amazing things, we may expect it to go even further. But even Amazon has a practical limit of how much complexity it can manage.
We are surrounded by organizations that really can't be bothered, and the value deficit in some sectors is quite disgraceful. So it may be unfair to pick on Amazon, an organization that has done more than most to stretch the limits of the possible. But Sally is right - the future belongs to those organizations able and willing to pay attention to this kind of detail, if it helps to produce direct or indirect value.
Showing posts with label quality of service. Show all posts
Showing posts with label quality of service. Show all posts
Sunday, March 27, 2011
Wednesday, July 09, 2008
Services Not All Like Laundry
In my post on the Laundry Metaphor of Services, I said that all services are a bit like laundry, and some services are very much like laundry, but few services are totally like laundry.
We need a notion of business services that covers at least five types of service (plus composites, hybrids and cross-overs).
Product Service: "I give/get you something"
Examples: Catering, Information, Certificate
Typically the service is fulfilled in the form of one or more deliveries (events). A product service is typically triggered by a specific request by the service user, and fulfilled by a response by the service provider. The right to trigger product services may sometimes be delegated to the service provider - either by defining some business rules, or by delegating authority as part of a challenge-based service (see below). Charging is typically per product or per delivery. Or it may be governed by a prior access service (such as subscription).
Transformation Service: "I do something to your something"
Examples: Car Repair, Laundry, Haircut,
The service provider takes temporary charge of something that belongs to the service user, and returns it in an improved state (e.g. mended, cleaner, tidier, more fashionable).
Responsibility Service: "I take care of something for you"
Examples: Office Cleaning, Track Inspection & Maintenance
Typically the service provider takes ongoing responsibility for a defined entity or outcome over a defined time period. Beside the core service, the service provider may provide regular or adhoc reports about the state of the entity to the service user. Charging will often be based on a flat fee. An alternative form of charging may be based on time and materials, but this demands a higher degree of trust between the service provider and the service user.
Access Service: "I allow you to do something" Permit/Enable/Empower
Examples: Subscription, Licence, Fishing Permit, Rail Use / Landing Slot
The service is typically delivered in the form of a message that contains a key and/or allocates a resource. Access rights and allocations typically expire if not used. Access is typically tied to a specific identity (e.g. user, machine) and is not normally tradeable or transferable. May also include traded options and the like, which confer a defined right to some other service or trade.
Challenge Service: "I solve a problem for you."
Example: Diagnostics, Develop Software, Adapt Business On-Demand.
The service provider often (but not always) specifies the solution. The service provider may also specify the problem. This entails a high degree of trust. This may also involve some shared risk and professional indemnity. Charging is typically problematic, unless it can be done within an arbitrary “professional” fee structure.
Each type of service requires different kinds of charging and service level agreement, and relies on different forms of quality assurance and trust. In my post on the Business Service Architecture (Railway Edition), I mentioned the difficulty faced by the company in the UK with primary responsibility for the railway network (originally Railtrack, now Network Rail). Railtrack was delegating maintenance work (Responsibility Services) to engineering companies and subcontractors, while selling rail availability (Access Services) to train operating companies. Railtrack seriously miscalculated the complex algebraic relationship between two different kinds of service level agreement, resulting in a serious rail accident in Hatfield.
Not all like laundry then.
We need a notion of business services that covers at least five types of service (plus composites, hybrids and cross-overs).
Product Service: "I give/get you something"
Examples: Catering, Information, Certificate
Typically the service is fulfilled in the form of one or more deliveries (events). A product service is typically triggered by a specific request by the service user, and fulfilled by a response by the service provider. The right to trigger product services may sometimes be delegated to the service provider - either by defining some business rules, or by delegating authority as part of a challenge-based service (see below). Charging is typically per product or per delivery. Or it may be governed by a prior access service (such as subscription).
Transformation Service: "I do something to your something"
Examples: Car Repair, Laundry, Haircut,
The service provider takes temporary charge of something that belongs to the service user, and returns it in an improved state (e.g. mended, cleaner, tidier, more fashionable).
Responsibility Service: "I take care of something for you"
Examples: Office Cleaning, Track Inspection & Maintenance
Typically the service provider takes ongoing responsibility for a defined entity or outcome over a defined time period. Beside the core service, the service provider may provide regular or adhoc reports about the state of the entity to the service user. Charging will often be based on a flat fee. An alternative form of charging may be based on time and materials, but this demands a higher degree of trust between the service provider and the service user.
Access Service: "I allow you to do something" Permit/Enable/Empower
Examples: Subscription, Licence, Fishing Permit, Rail Use / Landing Slot
The service is typically delivered in the form of a message that contains a key and/or allocates a resource. Access rights and allocations typically expire if not used. Access is typically tied to a specific identity (e.g. user, machine) and is not normally tradeable or transferable. May also include traded options and the like, which confer a defined right to some other service or trade.
Challenge Service: "I solve a problem for you."
Example: Diagnostics, Develop Software, Adapt Business On-Demand.
The service provider often (but not always) specifies the solution. The service provider may also specify the problem. This entails a high degree of trust. This may also involve some shared risk and professional indemnity. Charging is typically problematic, unless it can be done within an arbitrary “professional” fee structure.
Each type of service requires different kinds of charging and service level agreement, and relies on different forms of quality assurance and trust. In my post on the Business Service Architecture (Railway Edition), I mentioned the difficulty faced by the company in the UK with primary responsibility for the railway network (originally Railtrack, now Network Rail). Railtrack was delegating maintenance work (Responsibility Services) to engineering companies and subcontractors, while selling rail availability (Access Services) to train operating companies. Railtrack seriously miscalculated the complex algebraic relationship between two different kinds of service level agreement, resulting in a serious rail accident in Hatfield.
Not all like laundry then.
Tuesday, January 08, 2008
Flight from Quality
TIBCO (TIBX:NSQ) shares soared in December, following impressive financial results. This week they have fallen to a 52-week low, following a Sell advisory from Goldman Sachs (Euro2day via Tim Bass). Goldman Sachs analyst Derek Bingham predicts a flight from quality.
The SOA mantra of Loose Coupling works both ways here. On the one hand, greater standardization and interoperability could mean there is less reason to buy everything from a single supplier, and so “best-of-breed” offerings become more viable, even during an economic downturn. On the other hand, some companies may feel that it is less critical to get the highest quality infrastructure from the beginning, since greater flexibility makes it easier to contemplate changing things later.
The traditional economics of the software industry has generally favoured the giants, which is why IBM and Microsoft have seen off so many rivals. Meanwhile, the ecology of SOA favours diversity and heterogeneity. Traditional investors such as Goldman Sachs and its Wall Street clients may not appreciate this yet. The important question for TIBCO and other niche vendors is the extent to which the economics of SOA can overcome the economics of software.
The TIBCO shareprice recovered on January 16th, and has risen further since, perhaps helped by buy-out speculation following Oracle's acquisition of BEA.
But Tim and I were misled by the original story (apparently from Thomson Financial) linking the shareprice fall to the Goldman Sachs advisory. According to Yahoo (another company that knows something about buyout speculation!), the Goldman Sachs advisory was last April.
I stand by my original point, however, that stock market investors and city analysts don't necessarily appreciate the economics of SOA.
Customers will move away from buying more expensive “best-of-breed” offerings, like Tibco’s products, and more toward buying less expensive “good enough” substitutes that are bundled with broader solutions from the likes of IBM, Oracle Corp. and SAP AG.This is not about whether TIBCO has the best products, but about the buying behaviour of TIBCO's customers.
The SOA mantra of Loose Coupling works both ways here. On the one hand, greater standardization and interoperability could mean there is less reason to buy everything from a single supplier, and so “best-of-breed” offerings become more viable, even during an economic downturn. On the other hand, some companies may feel that it is less critical to get the highest quality infrastructure from the beginning, since greater flexibility makes it easier to contemplate changing things later.
The traditional economics of the software industry has generally favoured the giants, which is why IBM and Microsoft have seen off so many rivals. Meanwhile, the ecology of SOA favours diversity and heterogeneity. Traditional investors such as Goldman Sachs and its Wall Street clients may not appreciate this yet. The important question for TIBCO and other niche vendors is the extent to which the economics of SOA can overcome the economics of software.
Update and Correction
The TIBCO shareprice recovered on January 16th, and has risen further since, perhaps helped by buy-out speculation following Oracle's acquisition of BEA.
But Tim and I were misled by the original story (apparently from Thomson Financial) linking the shareprice fall to the Goldman Sachs advisory. According to Yahoo (another company that knows something about buyout speculation!), the Goldman Sachs advisory was last April.
I stand by my original point, however, that stock market investors and city analysts don't necessarily appreciate the economics of SOA.
Thursday, February 09, 2006
BMW Search Requests
Another controversy hits Google. German car-maker BMW offends against Google's webspam policies and gets delisted. After three days of "death penalty", the listing is resurrected. (Smaller companies might be lucky to be reinstated months after a lesser offence.)
Google is here playing the same defacto regulatory role as a stock exchange - if you want us to list you, please play according to our rules. (Google can therefore add extra rules to those rules imposed by national or international law. Whether Google can subtract rules is of course an entirely different and perhaps even more controversial question.)
But there is a crucial difference. With a stock market, there is a documented agreement between the stock exchange and the listed company, and any disputes can be taken to legal process. However, it is difficult to see how any company, however large, might establish in law that it had been unfairly treated by Google in such a matter. Even if there was clear evidence of financial loss as a result of a material change in search ranking, it would probably be impossible to pin liability for this loss onto Google.
Look at BMW's position from a service-oriented perspective. BMW's promotional and marketing capability is critically dependent on Internet search services provided to BMW's customers by Google and its competitors. This is of course true of many companies, large and small. But for most or all of these companies (and I presume this is the case for BMW), there is no formal contract with Google that governs this particular dependency, and no defined service level agreement.
Google's published statements appear to offer some comfort, implying that it will only take this kind of action against a company in response to some detected non-compliance on the company's part with Google's rules. (We can interpret these statements as part of acontractual pseudo-contractual specification of the service provided by Google.) But there are two ways in which this official specification can fail. Firstly, Google might make a mistake - may incorrectly punish a company for something it hasn't done. And secondly, Google might be tricked by a third party (competitor or vandal) into punitive action. (For example, by a clever combination of cybersquatting and hacking.)
Bottom Line: If you are dependent on a service you don't control, then there is a risk that needs to be managed. In a service economy, there will be many services that you want to use, because the potential rewards of these services are well high enough to justify the risks. But these risks still exist, and service management needs to include proper attention to the relevant risk factors.
Sources: Matt Cutts (Google), Search Engine Watch
Google is here playing the same defacto regulatory role as a stock exchange - if you want us to list you, please play according to our rules. (Google can therefore add extra rules to those rules imposed by national or international law. Whether Google can subtract rules is of course an entirely different and perhaps even more controversial question.)
But there is a crucial difference. With a stock market, there is a documented agreement between the stock exchange and the listed company, and any disputes can be taken to legal process. However, it is difficult to see how any company, however large, might establish in law that it had been unfairly treated by Google in such a matter. Even if there was clear evidence of financial loss as a result of a material change in search ranking, it would probably be impossible to pin liability for this loss onto Google.
Look at BMW's position from a service-oriented perspective. BMW's promotional and marketing capability is critically dependent on Internet search services provided to BMW's customers by Google and its competitors. This is of course true of many companies, large and small. But for most or all of these companies (and I presume this is the case for BMW), there is no formal contract with Google that governs this particular dependency, and no defined service level agreement.
Google's published statements appear to offer some comfort, implying that it will only take this kind of action against a company in response to some detected non-compliance on the company's part with Google's rules. (We can interpret these statements as part of a
Bottom Line: If you are dependent on a service you don't control, then there is a risk that needs to be managed. In a service economy, there will be many services that you want to use, because the potential rewards of these services are well high enough to justify the risks. But these risks still exist, and service management needs to include proper attention to the relevant risk factors.
Update
A related example (March 2006), via Seth Godin. Kinderstart sues Google over lower page ranking (Reuters).
See also: Creeping Business Dependency (March 2011), Unruly Google and VPEC-T (January 2012)
Thursday, January 13, 2005
Support Economy
Review of The Support Economy, by Shoshana Zuboff and James Maxmin
Viking Penguin, 2002.
This book is a detailed and persuasive account of the distributed service economy, which the authors call Distributed Capitalism. The background is familiar. An ever-greater share of Western economy is occupied with services rather than products. And yet our experience of service is generally bad - and getting worse. Service providers are trying to achieve economies of scale and cost-savings, while maintaining or increasing revenues. Service staff are under increasing pressure and scrutiny, and "empowerment" is eroded by targets and other narrow initiatives. Consumers are subjected to the indignities of call centres, the persistent nuisance of "courtesy calls", and the inflexibility of business processes that have been tailored to fit an internal corporate agenda.
The promise of eCommerce was that it would offer a genuine alternative for business and consumer relationships. With some honourable exceptions, this promise has failed. Many early eCommerce efforts were coloured by naivety and amateurism ("if we can get a small cut from every purchase made by every large manufacturer, we'll be rich, rich, rich"), or by cynicism ("if we can persuade our customers to do their own admin online, we can get rid of half our staff"). General consumer experience of eCommerce is poor - often because the service details (good logistics, prompt and effective troubleshooting, and so on) have been neglected. And what has happened to all those B2B portals?
What Internet shopping encourages is something the authors call ninja shopping. If a consumer can easily compare prices for flights or car insurance (but cannot so easily compare other characteristics, including service quality), then selection will be based on price, and prices will be driven downwards. Initially this seems to work to the consumer's advantage. But the providers retaliate with an increasingly impenetrable array of extras, excesses and surcharges, which aim to recoup profit margins while making accurate price comparison near-impossible. (I call this Complexity-Based Pricing.)
Consuming services becomes an incredibly time-wasting activity. You have to wait in line to hire a car, because the clerk is obliged to try and sell an array of options to every customer. You have to check-in hours before a flight, and you still may miss the connection. You have to review all service bills carefully for unexpected charges and other errors. You have to wait for everything. (This waiting is an almost inevitable consequence of traditional process thinking: if a customer ever gets immediate attention for anything, this rings alarm bells in the process office, indicating that the relevant function is over-resourced.)
The authors argue that there is a huge potential wasted value locked up in these dysfunctional service relationships. They advocate a form of deep support, that will release/realise what they call relationship value, and they paint an attractive and detailed picture of the way it might work. They go on to argue that the realization of relationship value calls for a new enterprise logic: distributed, federated, dynamic, infinitely configurable; technologically supported by digital media and infrastructure convergence. From an SOA perspective, this sounds very familiar.
The book is not just an eloquent argument for the service-based business, but also a powerful vision of how it can and must be done properly. Recommended reading for everyone interested in the service economy.
Review first published in the CBDI Journal, July/August 2004.
The Support Economy Website
See also Shoshana Zuboff, Creating value in the age of distributed capitalism (McKinsey Quarterly, September 2010)
Related Post: Heartbeat Economy (January 2005)
Updated 14 May 2014
Viking Penguin, 2002.
This book is a detailed and persuasive account of the distributed service economy, which the authors call Distributed Capitalism. The background is familiar. An ever-greater share of Western economy is occupied with services rather than products. And yet our experience of service is generally bad - and getting worse. Service providers are trying to achieve economies of scale and cost-savings, while maintaining or increasing revenues. Service staff are under increasing pressure and scrutiny, and "empowerment" is eroded by targets and other narrow initiatives. Consumers are subjected to the indignities of call centres, the persistent nuisance of "courtesy calls", and the inflexibility of business processes that have been tailored to fit an internal corporate agenda.
The promise of eCommerce was that it would offer a genuine alternative for business and consumer relationships. With some honourable exceptions, this promise has failed. Many early eCommerce efforts were coloured by naivety and amateurism ("if we can get a small cut from every purchase made by every large manufacturer, we'll be rich, rich, rich"), or by cynicism ("if we can persuade our customers to do their own admin online, we can get rid of half our staff"). General consumer experience of eCommerce is poor - often because the service details (good logistics, prompt and effective troubleshooting, and so on) have been neglected. And what has happened to all those B2B portals?
What Internet shopping encourages is something the authors call ninja shopping. If a consumer can easily compare prices for flights or car insurance (but cannot so easily compare other characteristics, including service quality), then selection will be based on price, and prices will be driven downwards. Initially this seems to work to the consumer's advantage. But the providers retaliate with an increasingly impenetrable array of extras, excesses and surcharges, which aim to recoup profit margins while making accurate price comparison near-impossible. (I call this Complexity-Based Pricing.)
Consuming services becomes an incredibly time-wasting activity. You have to wait in line to hire a car, because the clerk is obliged to try and sell an array of options to every customer. You have to check-in hours before a flight, and you still may miss the connection. You have to review all service bills carefully for unexpected charges and other errors. You have to wait for everything. (This waiting is an almost inevitable consequence of traditional process thinking: if a customer ever gets immediate attention for anything, this rings alarm bells in the process office, indicating that the relevant function is over-resourced.)
The authors argue that there is a huge potential wasted value locked up in these dysfunctional service relationships. They advocate a form of deep support, that will release/realise what they call relationship value, and they paint an attractive and detailed picture of the way it might work. They go on to argue that the realization of relationship value calls for a new enterprise logic: distributed, federated, dynamic, infinitely configurable; technologically supported by digital media and infrastructure convergence. From an SOA perspective, this sounds very familiar.
The book is not just an eloquent argument for the service-based business, but also a powerful vision of how it can and must be done properly. Recommended reading for everyone interested in the service economy.
Review first published in the CBDI Journal, July/August 2004.
The Support Economy Website
See also Shoshana Zuboff, Creating value in the age of distributed capitalism (McKinsey Quarterly, September 2010)
Related Post: Heartbeat Economy (January 2005)
Updated 14 May 2014
Subscribe to:
Posts (Atom)