Sunday, July 22, 2007

 

Bridging the Front Stage and Back Stage in Service System Design

A couple of months ago I gave a talk titled "Bridging the 'Front Stage' and 'Back Stage' in Service System Design" at a conference (and wrote about it here). I've now turned that talk into a paper (with my graduate research assistant Lindsay Tabas as co-author). You can download the paper but let me say a few words about it because it represents a milestone in my evolving thinking about information and service design.

For most of my professional career I've designed and deployed information-intensive applications and systems. I wrote a book about Document Engineering and teach courses about it at UC Berkeley. And in the last year or so that I’ve been blogging here, a lot of my posts have been about business informatics, information supply chains, and document automation. In all of this work, writing, and teaching I've generally focused on the "back stage" where information is managed, transformed, and moved within and between business systems, and haven't paid much explicit attention to the "people parts" or "front ends."

But I've now come to recognize that it is essential to consider the entire network of services that comprise the back and front stages as complementary parts of a Service System. This paper is my first attempt to present a methodology for designing service systems that synthesizes (front-stage-oriented) user-centered design techniques with (back-stage) methods like Document Engineering for designing information-intensive applications. The paper briefly sketches the core ideas, especially those that most explicitly concern the interactions and tradeoffs between front and back stage design.

The typical design conflicts and tradeoffs between front and back designers are lessened by a service system perspective. Front stage service providers need capabilities for capturing information about front stage preferences, contexts, and events. This and other back stage information can then be exploited by the front stage to enhance the service experience.

Lindsay and I are working on a longer paper that more fully develops this approach, and I'm also developing a new course tentatively called "Design Models and Methods" that will be a good forum for seeing if a unified methodology is learnable and useful.

-bob glushko





Tuesday, July 10, 2007

 

Designing {a, with} Discipline in Service Science

I’ve just finished writing a paper that will be published in a special issue on Service Science in the IBM Systems Journal in February 2008. This journal doesn’t allow authors to post accepted manuscripts before they are officially published, which strikes me as a bit quaint, but it is OK if I post the abstract and say that the full manuscript is available from me if you ask for it. So here's the abstract, and if you ask for the full paper (glushko at ischool.berkeley.edu), I'll send it to you.

The paper is called Designing {a, with} Discipline in Service Science, which is probably too clever but I like it and if you can't parse the title you probably won't understand the paper anyway. The paper was motivated by the call by IBM and others for universities to train students for new career opportunities in the information and service economy, usually urging the creation of a new discipline called “Service Science” or “Service Science, Management, and Engineering” (SSME).

Several professors at UC Berkeley are interested in topics that potentially fit into an SSME curriculum, and we might simply have declared that the Service Science curriculum consisted of the set of courses we were already teaching, putting old courses in new bottles. But that didn't seem very satisfying. We wanted to design a discipline of service science in a more principled and theoretically motivated way, and the paper explains what we did and why we did it.

Here's the Abstract:

Should we think of service science as a new discipline or simply as a new curriculum? Some might say it doesn’t matter. At the University of California, Berkeley, we cared relatively little about the institutional form that service science might take (i.e., what to call it and how to organize it), but we cared immensely about the intellectual form (i.e., what it would be about). We sought to design a discipline of service science in a more principled and theoretically motivated way – designing a discipline with discipline. Our work began by asking “What questions would a ‘service science’ have to answer?” and from that we developed a new framework for understanding service science. This framework can be visualized as a matrix whose rows are stages in a service lifecycle and whose columns are disciplines that can provide answers to the questions that span the lifecycle. This matrix systematically organizes the issues and challenges of service science and enables us to compare our model of a service science discipline with other definitions and curricula. This analysis identified gaps, overlaps, and opportunities that shaped the design of our curriculum and especially a new survey course which serves as the cornerstone of service science education at UC Berkeley.

If you're not up to reading the entire paper, take a look at the
Information and Services Design program at the School of Information at UC Berkeley.

-Bob Glushko




This page is powered by Blogger. Isn't yours?