As regular readers know there are quite a few subjects I know pretty much nothing about. One of things about which I admit this involves running any kind of restaurant, but there's a Paul Murphy in Colorado who's really very good at this kind of thing and if you happen to know him, well, I'd like to talk to him about Unclebunny's -and, meanwhile, I'd like to use it here to illustrate something about IT services.
In one of last week's talkbacks Erik suggested that people try to make themselves organisationally indispensable by doing their basic jobs in idiosyncratic ways that are both hard to duplicate and hard to displace.
I've seen lots of people do this - in IT management it's a particular concern with respect to people who work in user departments but have long since stopped doing their real jobs to become, instead, the local go-to guys on PC problems. As part of this, these are the people who create and "support" local spreadsheet or Access applications no one else understands, no one can audit, and everyone in the department agrees are of magical significance to daily operations.
In general their success is an obvious sign of IT management failure, since the department heads sheltering them wouldn't do so if they trusted IT to do its job, but the problem goes much deeper since junior management's willingness to sustain these costs as a hedge against IT ultimately signals a general failure to align IT with the business.
That failure is the norm in larger organizations where IT has a clear data processing heritage - because data processing, from its origins in the 1920s, has always been a cost sink in Finance whose surplus capacity can be grudgingly shared out among the chosen, and whose bottom line mission is therefore always accounting and control, never production and customer service.
Look at the heritage and what you see is business units going to Finance with support requests - a process that underlies the traditional business analyst job description and the assumption that IT has to be aligned with the business rather than co-evolved with it.
In practice top down alignment rarely works because the analysts generally misrepresent the Systems agenda and users tell analysts what they think they're supposed to do, not what they actually do - which is why planning processes tend to combine unrealistic service expectations with equally unrealistic business process maps to create the usual big project havoc.
That's data processing; in computing the better route is co-evolution. User controlled prototyping where the business already exists, and building the business unit and its support systems concurrently where it doesn't or can be easily changed.
The Unclebunny's concept is a case in point.
Unclebunny's is envisaged as a Canadian and American restaurant chain aimed at meeting the needs of the affluent, and near affluent, obese. Basically the customer scenario looks like this:
- the restaurants are open to everyone, but members get special treatment. Each restaurant has an on-staff dietician and new members meet, on signing up, with the dietician to develop an appropriate weight control plan including at least weekly visits to an Unclebunny's.
- the restaurants are club-like, serving high quality food in comfortable surroundings with an emphasis on building personal connections between staff and customers.
- members carry remote readable cards that identify them to the hostess when they enter a restaurant. As a result, Mr Jones, a member from San Diego, can be greeted by name when he enters a restaurant in Calgary. More importantly, his dietary needs and preferences can be used to provide his menu.
- the same device that displays his default menu choices can then used to collect, if he wishes to provide it, intake information for the period since his last meal at an Unc's, and that information can be used first to modify the list of recommended choices for his current meal, and secondly to produce a listing (if requested) of appropriate foods and quantities for the immediate future.
The big idea here is that making the information management process both seamless across the country and invisible to the customer allows us to build a business around an unbreakable relationship -that between the customer as individual and individual employees representing the business as a sprawling international entity. Basically the information system lets us make the customer feel welcome, feel safe, feel understood, and feel at home in any of our restaurants.
In delivery that can be as simple as a friendly waitress noting that the diet cola has two ice cubes "just as you like it, Mrs. Jones" or as complicated as a personal chat with the on site dietician -either way, however, what we're illustrating here is that information is power, power that can be harnessed to build a business while enabling our customers to make the long term behavioural changes needed to get and keep control of his or her weight.
So what makes me think this could work? Two things: first it's hard to doubt that there are enough over weight people with the money to participate; and, secondly I think the information system needed to make this happen can also be used to make money on the buying side of the business.
The main point, however, is simply that this entire business concept hinges on a particular view of technology and its implementation. Start by concurrently building a business, and an information system, around the customer's needs and the technical design falls trivially into place.
You can't do this kind of thing any other way. You can't build Unclebunny's without the information system, and you can't add the information system to an existing business without radically changing that existing business.
Try to avoid the business change part, and you'll get squeezed into playing catch-up forever because you'll be ground between the opposing pinchers of sequential business and IT adaptation.
I'll talk about this more next week (or later) but there's actually a more interesting moral to this story too: where you can co-evolve business processes and information management you'll find that the latter is always about communication over time and space -and that's the opposite of data processing's focus on counting the dead, and shooting the wounded, after the battle.