Succeeding through Service Innovation

I was asked to give feedback on the IBM/University of Cambridge discussion paper Succeeding through Service Innovation. Like many such requests, it was prefaced with "it should only take an hour" - I do not know how long it took me to read it, and comment on it, then to turn my feedback into something that made sense. It was much more than an hour. But at least I am done now, and it was worth it.

We shall see what, if any, aspects of my feedback appear as the "green paper" evolves into a "white paper." Most of my comments come from looking at service science and innovation through the lens of user experience (and my focus on corporate information architecture for almost a decade). Some of the things I found most interesting about the document:

• In Section 1, I like that fact that they proposed extending the "Service Science, Management and Engineering" with a "D" for design. Adding more letters does not appeal to me - too many already - but adding in "design" (even though it is such a mooshy term) is one way to increase the focus on the human element (which I think does not come through enough in SSME literature in general).
• Also in Section 1, I think the shift to a "try before you buy" economy helps customers focus more on the value of the end-to-end services instead of only considering the surface features of the product, like the price. The obligatory mention of "Web 2.0" was included.
• In Section 2.2, key questions about architecture are listed, but I think they are missing one. How do we architect a service system to enable a quality experience for the people involved? (Both the customers and the front-stage staff that interact with them.) We all have a lot of stories about how hard it is to design for a quality experience when the fundamental building blocks of the system do not fit together ("lipstick on a pig"). And an even harder challenge: design an architecture for a service system that lets you build a seamless experience with a different service system.
• In Section 3, the 4 clusters made sense to me because I see a large corporate web site as an example of something that includes all of them. It has the (1) marketing element, with (4) tons of information, requiring (2) sophisticated software engineering and metrics, and based on (3) a thorough understanding of individual and group behavior.
• In section 4, I agree with the need for "inter" disciplinary instead of "super" or "multi" (but the "inter" diagram needs to look like a network, not a ring).
• Also in Section 4, I like the "broad and deep" skill analogy, even though I am not sure "T-shaped people" is the right way to explain it. Nonetheless, we UX folks have been arguing about this for a while already. Examples: one Peter likes the T while another Peter thinks more holistically and suggests balanced teams should be the goal.
• In Section 5, the recommendations were lacking an emphasis on the human element and enabling innovative experiences.

All in all, I see enough synergy between service science and user experience that I plan on seeing what other connections are useful to make. Feels like the tip of an iceberg.