The Long and Winding Road to a Course on Service System Design Bob Glushko University of California, Berkeley glushko@berkeley.edu Art & Science of Service Conference 9 June 2011 Three Co Evolutions Conceptual the ideas that shaped what I wanted tdto teach Publications my systematization of these ideas that I could use as cornerstones in my course syllabus Pedagogical how could I best teach these systematized ideas 1
Evolutionary Phases 0. Pre history: before coming to Berkeley in 2002 1. Systematizing my experiences 2. Teaching my systematized experiences 3. Extending the scope to service systems 4. Designing a discipline with discipline 5. Teaching two interleaved methodologies: a failed experiment 6. Design patterns for service system design: a successful experiment 7. The future: experiments not yet conducted Course Evolution: Five to get One 2
Five Courses Taught in Eight Years One Has Survived 2002 2007: Document Engineering 2003 2004: Document Engineering Laboratory 2006 2007: Service Science Lecture Series 2006 2008: 2008: Information & Service Economy 2008 present: Information Systems & Service Design Conceptual Evolution (Phases 1 & 2) Document Centric Application Design Document exchange patterns Business process patterns XML design artifacts 3
The Drop Shipment Pattern Document Exchange View 4
Business Process View Key Publication 1 Glushko, Robert J. & McGrath, Tim. DOCUMENT ENGINEERING MIT Press (2005) 5
Lessons Learned in Phases 1 & 2 Hands on projects are essential, especially whenthey arerealisticrealistic Have students start with individual tasks that need to be integrated into team efforts But students with little work experience won t understand real world operational and technological lconstraints t The project needs to be intrinsic to the course, not in a concurrent course Conceptual Evolution (Phases 3 & 4) Emergence of the SSME Concept Discipline x Lifecycle Matrix Broad view of the information and services economy 6
Designing a Discipline vs. Designing a Curriculum A discipline is a principled model of a coherent body of research and practice A curriculum is a program of study leading to a degree or certificate Fundamental decision we made was that we wouldn't simply repackage existing courses as SSME This might create an SSME curriculum, but it would be biased and not easily comparable to SSME efforts elsewhere Designing a Discipline Don't start from any existing curriculum or courses Instead, ask "What are the key concepts, themes, and challenges that a SSME discipline should encompass" Treat every participant's discipline as an equal partner until you have a principled reason not to do so 7
Some Cross Disciplinary Questions Candidate disciplines: economics, law, organizational sociology, business strategy, business operations, information science, user centered ddesign, computer science... Does the discipline have a theory about how firms change over time? What mechanisms does each discipline propose that firms use to seek and maintain advantages? How does each discipline propose that firms encode what they learn in new mechanisms, organizational forms, or information technology? How does each discipline explain why and how services combine, standardize, and evolve? Discipline x Lifecycle Matrix 8
Key Publication 2 Glushko, Robert J. "Designing a Service Science Discipline with Discipline", IBM Systems Journal, 47(1): 15 27, 2008 Lessons Learned in Phases 3 & 4 The Document Engineering perspective on value creation is too incremental with not enough emphasis on co creation SSME theory and practice is too broad to cover in a single course but separate theory and practice courses won t achieve the desired synergy A lecture series with industry practitioners sounds good but won t achieve the desired synergy 9
Conceptual Evolution (Phases 5 & 6) Service Systems Real world design projects Multidisciplinary design teams Front stage vs. Back Stage and Methods Portfolio Co creation of value Seven contexts as building blocks 10
If Only This Were Just One Book Seven Contexts 11
Seven Contexts Framework Seven Contexts in Banking 12
Design Patterns for Service Systems Moving the line of visibility between the front and back stage changes the potential for service personalization A generic service offering can be increased or decreased in service intensity by changing the number of touch points Capturing, managing, integrating and retrieving information allows the substitution of information for interaction The level of abstraction of the interfaces that specify the inputs and outputs of a service determines the degree to which one provide can be transparently substituted for another. Key Publications 3 & 4 Glushko, Robert J. & Tabas, Lindsay. "Designing Service Systems by Bridging the 'Front Stage' and 'Back Stage'", Information Systems and E Business Management, 7(4):407 427, 2009 Glushko, Robert J. "Seven Contexts for Service System Design," in Maglio, P. P., Kieliszewski, C, & Spohrer, J. Handbook of Service Science, 219 249, 2010 13
Lessons Learned in Phases 5 & 6 You need to teach a variety of design methods but this can confuse / overwhelm students Students learn more in aggressively multidisciplinary teams If course project reports follow a standard template they make good case studies and then students do better projects Design patterns can convey concepts and methods very efficiently If you think your course is perfect, it is time to stop teaching it! The Three Co Evolutions 14
Phase 7 Design Traceability 15