Sunday, February 13, 2005

Retail Tagging

In order to maintain some kind of control over the Veryard household finances, we resolve to monitor how much we spend in different categories. These are of course our private categories, and do not necessarily correspond to the categories defined by the retailer. For example, we buy lots of books; some of them are intended as birthday presents, some of them are for the children, some of them are work-related, and so on. One category: Christmas Presents; another category: School Requisites.

At the end of the month, we get statements from the bank and from various shops, showing the amounts spent using several different cards. Translating these data into a more useful form is tedious - it requires a combination of recollection, receipt-shuffling and manual data entry.

What I'd like to be able to do is attach categories onto each item at the time of purchase. My monthly statements from the bank and other service providers will come in XML format, with all transactions broken down using my own categories and ready to be imported into a spreadsheet or accounting program. Surely with the explosive growth of tagging this facility shouldn't be too far off now?

The retailers will no doubt be delighted with the extra data; it will give them access to another level of meaning over our purchasing behaviour. Meanwhile, traditional banks will be horrified by the cost and disruption to their antique systems, and may well resist any innovation.

Did I say monthly? Make that real-time please. I want all my service providers to populate my personal data warehouse (on some server somewhere, permanently linked to my Blackberry, with appropriate BI tools thrown in), using my own tags and alerts.

From the demand-side perspective, this sounds too good to be true. What makes it radical (and therefore probably hard for the supply side to comprehend, let alone implement) is that it puts the user (and context of use) at the centre of the service environment.

Most service providers put themselves at the centre. This is a vending-machine metaphor of service: the user puts in some coins, makes a selection, and gets a bar of chocolate. We can specify the behaviour of the vending machine as a series of use cases, and design a system from these use case specifications. But this design approach (which is very common, not only among SOA methods) is exclusively supplier-centric and develops no understanding of the demand-side.

(I am aware of the user-centric design movement, but this is often little more than user-centric interface design - in other words, website navigation, with no basis for a broader analysis of the service economy. And even this is strongly resisted by a supply-side-dominant software industry.)

Our approach to SOA modelling embraces the demand-side as well as the supply-side. At present, we believe this is unusual if not unique.

Update: I just found a post by Rebecca Dias requesting something similar. She wants some technology that saves time producing expense reports. There are some responses to this request in the comments following her post. But the categories on my expense form don't match the categories defined by the retailer. The restaurant receipt doesn't show whether I'm just having dinner on my own or entertaining a client, but this difference is important when I do my expense report. So I think some form of user-defined tagging is an important requirement here.

Rebecca Dias, iPAQ without a phone, why bother? (30 November 2004 via WaybackMachine)

No comments: