Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

Intangible Values of Services

user-pic
Vote 0 Votes

We used to think about the value of services as something we can touch or as a work done for us. This is material or tangible values. When we talk about commercial enterprise and services, the tangible values are measured in money, more accurately, in revenue. For non-for-profit organisations, only a part of service business value is measured in money, in saved money in this case. You can locate "values of saved money" in almost all public enterprises. What is another part of business value consists of for such organisations? It is the intangible values.

For the last decade, intangible values are found in practically all types of business services and the more advanced commercial enterprises started using them a lot. Here are a few of business service's intangible values to give you an example:

• Consumer satisfaction and loyalty
• Consumer relationship management aspect
• Interpersonal relationship and related business trust
• Flexibility (coarse-grained interfaces and hidden implementation of the services)
• Team work ( service composability)
• Professional specialisation (service offers concrete business function and nothing else)
• Competitiveness (if the service does not provide for its SLA, it will be replaced together with the service provider)
• Promotion of business capabilities
• Social and cultural influence of the service tangible values on the consumers and providers.

Looking at the list above, I think there is no need to explain why intangible service values are so important. The major reason why I am writing about intangible service values is to show developers in IT that they are as responsible for these values as their business Functional and Marketing Departments, that intangible service values ought to be embedded into the automated business solutions. I would like to support my statement with a recent real life business case, which I describe on behalf of an abstract person named Jackson. He is a good American citizen - he lives in the UK and pays taxes in the USA as well as in the UK . He has banking accounts with Lloyd TSB and HSBC - two leading British banks.

This year, he prepares to file American taxes and called both his banks asking to send him the Tax Certificates for the interests the banks paid into his accounts for 2009. The only requirement was that the Tax Certificates had to cover a calendar year, from January to December, because the financial year in the USA matches the calendar year. And this simple requirement became a problem all of a sudden.

The telephone call to Lloyd TSB resulted in the Tax Certificate in the mail box in a couple of days. However, the bank representative in HSBS repeatedly explained that she was not able to prepare and send the Tax Certificate for the requested period of the time because British financial year is from April to March, i.e. she was not able to provide the Tax Certificate for the period from April to December, 2009, since the financial year was not ended yet. Let's leave Jackson to solve this puzzle and analyse the situation.

Why clerks doing the same job in the same country , under the same financial regulations (business context) did not respond to the simple request in the same way? I would allow myself to speculate and tell you that the Lloyd TSB's technical solution for the given case was service-oriented and worked well as expected. The solution for the same problem in HSBC was not service-oriented. Here is what I think how the solution was constructed in HSBC.

The Tax Certificate may be issued for any interest paid by the bank to its client. Since personal taxes are paid by people (we exclude companies and self-employed persons) once a financial year, developers in HSBC used the definition of the financial year for dwellers of the UK as a period from April to March. This is it. The automated system for bank clerks was designed and implemented to compose and issue the Tax Certificates for the British financial years and the clerks had to provide only the information of which year to process. Simple and quick. What else can you possibly want from IT?

Well, if Jackson were knew this speculative logic, he would, probably, reconsidered keeping his money in HSBC because it is served by the people who think that only British citizens live in the UK and who allow themselves to decide how the financial instrument such as Tax Certificate should be used. The described speculative logic considered only one, the simplest use-case and was predetermined for only one type of bank clients only. This logic and related system made the decision for the potential consumers dictating them that 1) the Tax Certificate may be issued only for the full British financial year, and 2) Tax Certificate is used for filing taxes in the UK.

I have said that the speculative solution from HSBC was non-service-oriented because it considered the convenience (simplicity) for the providers instead of convenience for the consumers who are entitled to use the Tax Certificates in any legal way they want. In other words, that solution served the provider instead of the consumer. This is the fundamental violation of the spirit of service orientation. I do not know was it a 'business requirement' or programmer's decision to limit the solution by the conditions 1) and 2) mentioned above but, in any case, it did not address the business need but rather a local task.

If I would filled the shoe of those HSBC developers and wanted to serve consumers (vs. managers) , i.e. preserved the intangible values of the service, I were developed the default track with minimal manual operations for the Tax Certificate for the British financial year and accompanied it by the mandatory feature allowed to issue the Tax Certificate for any arbitrary time where it made sense under the British financial regulations. Why it was not done? This is another speculation but one of the likely reasons is... the project cost. Adding a feature for arbitrary time-window for the Tax Certificate requires, at least: 1) additional calculations for an arbitrary period of time; 2) additional user interface components for selection of the beginning-end of the time-window; 3) additional input data validation. These additional development elements require additional time to build and cost additional funding. Some organisations worship the "philosophy" of doing things for today only, they also hope that they would be able to correct their work tomorrow, if needed, but tomorrow does not always come for such pragmatics; remember the Jackson's case.

Known to me researches say that extra investments in the service-oriented solutions are about 30 per cent of the original cost. However, these 30 per cent allow to gain up to 300 per cent of the revenue from the use of the service due to acquired consumer satisfaction, recommendations, trust and loyalty. This is how intangible service values work for tangible values.

Indeed, intangible trust and loyalty are almost priceless values for any business.

WebSiteAdvert.jpg

1 Comment

| Leave a comment

Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more

Subscribe

 Subscribe in a reader

Recently Commented On

Categories

Monthly Archives

Blogs

ADVERTISEMENT