Recent Personal Observations about a Specific Service System

Several years ago, when I was working at IBM, I enjoyed a video of Linda Sanford (IBM Senior VP – at the time she was the most senior woman VP at IBM and perhaps she still is) talking about turning enterprises on their sides (transforming enterprises). She is responsible for IBMs internal transformation. Her talk was actually about SSME (Service Science, Management, and Engineering), innovation and IBM’s jams and ThinkPlace (an interesting idea-generation collaborative tool through which I participated but which is now “retired”) but one of the points she made was about moving from a view of functional units within an enterprise to a client-view across an enterprise. The example she gave was banks. Banks have silo’d functions (mortgage, investment, chequing accounts, etc.) that work very well but clients want a view that cuts across the bank horizontally. The business processes are set up vertically within the functional units or silos instead of horizontally across all service offerings of the bank.

The bank example clicked with me and, not long ago, I experienced this silo perspective first hand. I withdrew money from an ATM which was inside my bank branch. The money came out but was short by $20. I walked no more than 5 metres to the customer service desk (did I mention this was my bank branch?) and explained what happened. I was told that the ATMs were a on different system and the person at the service desk couldn’t give me the $20 but would notify the ATM part of the bank about what had happened and the ATM part of the bank would contact me after they had reviewed the money-in / money-out of the ATM in question. From a customer perspective, this is a tad messed up. The bank service system should be one service system that allows me to withdraw the correct amount of money regardless of the channel I’m using (teller, ATM, Internet, etc.).

I recently encountered another more complex example. Before I start, I should say that this isn’t a rant but an observation (as a service science researcher) that there continues to be opportunities for fairly basic innovation in service systems. In December, I had surgery to replace a torn tendon in my ankle which involved breaking my heel and repositioning it with screws. This procedure required and will continue to require several service interactions with medical professionals and medical facilities (service systems). I had MRIs in the MRI section of the hospital and the way in which my surgeon is notified that I’ve had the MRI is by my calling his admin office to let him know. I also have appointments with my surgeon in his Orthopedic office in the hospital. I interface with his Orthopedic office through his assistant (via the phone) for surgery date information and follow up appointments in his Orthopedic office. I had a pre-op appointment with another unit in the hospital (the pre-op unit). They weren’t sure exactly what kind of surgery I was having done and had trouble reading my surgeon’s writing (on the paper requisition form). After the surgery, while my bone is still healing, I have a couple of visits with my surgeon in the Fracture Clinic part of the hospital. To set up and confirm appointments in the Fracture Clinic, I must speak with the Fracture Clinic appointment desk (which is not connected with his Orthopedic office). In another week or two, I will require physio-therapy in another medical facility (maybe also at the hospital, maybe somewhere else) but I don’t know yet because that information is not available anywhere.

From my perspective, I would like to interact with an “ankle surgery” service system that cuts across the different functional units in the hospital. Instead I have had to learn about the different individual functional units (service systems) and how they interconnect and work together. In some cases, they don’t. In order to change my appointment date with my surgeon (in the Fracture Clinic), I have to phone the Fracture Clinic unit instead of his Orthopedic office.

And speaking of phoning, it would be wonderful to be able to interact with the ankle surgery service system through channels that are more intuitive and convenient (such as booking appointments via the web or email, getting general surgical information online instead of on a paper pamphlet which I’ve already lost, etc.). Perhaps that’s a topic for a future blog post.

I want to restate that I’m not meaning this to be a rant. I couldn’t be happier with the quality of care I’ve received and the tremendous skill and talent of everyone I’ve encountered (especially my surgeon). This is simply an observation that there continues to be room for seemingly simple innovations and implementations within common and important (even critical) service systems.

Summer Plans: Research Project 1

For an academic, summer really starts when the marks are all submitted after the end of classes. So, my summer has already started. In fact I’m two months in (almost half-way). This is not a comforting thought. There was (is) so much I want to (need to) do this summer.

I started by (finally) writing up the service science research landscape I blogged about last year. It has been submitted as a book chapter to the theme: “Service Systems Implementation”, a Volume in “Service Science: Research and Innovations (SSRI) in the Service Economy” Book Series, Springer.

I’m also working on three fun research projects with smart people this summer. I will briefly introduce each of them in the next few posts.

The first is a project on the decision-making needs of future knowledge-workers. I’m working with PhD student John Peco in the Faculty of Information who is studying how young people use social networking sites and other online tools to help them engage with information and people for decision-making. A survey will be out soon to help us learn more. I'm also working with soon-to-be masters student in Computer Science, Fan Dong, who is looking into collaborative decision making in cross-site software engineering groups. Fan is conducting a literature review looking at research into what are key decisions that are made in software engineering, how those decisions are made (in what ways using what methods), when various decisions are made (at what stages of software engineering), with whom (when / why do they engage with others) and using which tools or models.

Fan and I are also compiling a list of the kinds of decisions that are made during a software development effort, whether during design and requirements gathering, coding, testing, release planning, deployment, configuration, maintenance, etc.

So, my question to all the software people out there is:

What are some of the decisions you make (or made) in your software development work?

Please respond as comments to this post or to me directly and I’ll summarize and post back.

Proposed Service Science Research Landscape

Many individuals and groups are working to establish a research program and research projects in Service Science, Management, and Engineering or Service Science. These individuals and groups come from different research backgrounds and bring different perspectives and points of view to this emerging field.

The purpose of this blog post is to propose a research landscape which can help us situate service science research from across our varied disciplines. My hope is that, through this blog medium, we can collaborate to enhance and evolve the landscape so that it can serve several roles, including:

1. Help researchers understand how their research relates to existing service science research activities and that of specific researchers so that they may define effective collaborations;

2. Help researchers and project leaders determine which aspects of service science research are not addressed within a large research project or program; and

3. Help educators define service science curriculum and courses that cover specific aspects that are being addressed in service science research.

First I will provide some definitions, a practice which is extremely important when discussing topics that cross disciplines. For the context the proposed research landscape, “service” is defined independently of the notion of technology. In [1], a service is defined as “the application of competences for the benefit of another”. More broadly in [2], a service is defined as “the application of resources (including competences, skills and knowledge) to make changes that have value for another”.

A “service system” is defined as “a configuration of people, technologies, and other resources that interact with other service systems to create mutual value” [2].

By contrast, a “web service” is more narrowly defined as “a software system designed to support interoperable machine to machine interaction over a network” [3]. In the context of service oriented architectures (SOA), “services” are described as network-accessible software components that are aligned with business processes [4].

“Service Science” then is the study of the application of resources in one or more service systems to the benefit of another service system. Service Science is trying to develop a science of service systems and their interactions [2].

“Service Science, Management, and Engineering” (SSME) is sometimes used interchangeably with the term “service science” but it involves more than “service science” does. It includes applying management and engineering principles to services and has been defined as, “ the application of scientific, management, and engineering disciplines to tasks that one organization (service provider) beneficially performs for and with another (service client) [1].

Note that the definition of “services” has changed over time from meaning tasks that one performs for and with another in [1] to the application of resources for mutual benefit in [2]. This is evidence that the field is emerging and changing in such a way that it will benefit from having a landscape on which to ground various research activities.

The vision of service science remains boldly or ambitiously to be to create a coherent integrated body of knowledge to support ongoing innovation in service systems design, operation, and improvement [5]. A picture that has been used by IBM researchers to show the breadth of service science activities shows three layers:

The lowest level of this diagram represents the technical architecture, the middle layer defines work practices and on the top layer sits the services business. Research in service science or SSME spans these three different layers; thus, these three layers define one of the dimensions of the proposed landscape.

To articulate the other dimension of the proposed research landscape, we first look at the definition of a service system since research in service science requires researching service systems. A service system is defined as “a dynamic value co-creation configuration of resources, including people, organizations, shared information (language, laws, measures, methods), and technology, all connected internally and externally to other service systems by value propositions” [6].

Because organizations contain people and technology and information is shared through people and technology, the second dimension of the research landscape focuses on the people and technology resources in service systems.

Recall that a service is defined as the application of competence for the benefit of another entity. Services, therefore, involve at least two entities, one applying competence and another integrating the applied competences with other resources and determining benefit [6].

For benefit to be realized and competences to be applied, these two entities must interact in some way. The interaction could take place between two technological systems and be performed through web services. It could be that people in one entity are interacting with technology in another as in business to consumer e-commerce. Finally, it could be that technology is mediating people to people interactions such as when a researcher interacts through chat or email with a reference librarian to find information.

The second dimension of the proposed landscape, therefore, differentiates research as to whether it studies connections and interactions between people, between people and technology, or between technology and technology.

There are a couple of points to note about research that is situated within this landscape. First, the research may study interactions and sharing between two entities that are within the same organization or in different organizations. That aspect of the research is not differentiated on the landscape.

Second, the underlying goal of research that gets situated within this landscape has to explicitly address services as defined in [1] or [2]. In this way, we would not include research on the bottom level of this landscape picture that advances technology in a way that could simply be applied to service paradigms as well as being applied to several other paradigms. Rather, the research we situate on this landscape must study an effective and novel application of technology in new ways to enhance services or advances in technology that are motivated by specific kinds of services.

So for some examples of where research would fit within this proposed landscape, consider SOA and Web Services research which fits in the bottom to middle left side of the landscape. Two pieces of work I’ve collaborated on in virtual worlds fits in the upper right. And work I’ve collaborated on in understanding the structure of the social network in corporate blogs (technology mediated person to person interaction and sharing) fits in the middle right side of the landscape.

I think it’s important to realize that different kinds of business services may drive the research differently so I explicitly list 4 kinds on the landscape (large enterprise, small enterprise – although I’m not 100% sure there is a difference between them for the purposes of services research – government services, and non-profit services). Most of the work on theories of service science assume for-profit services and, while I haven’t looked at it very closely yet, I think it’s worthwhile to consider that some of the theories and definitions may not apply as well in non-profit services.

In a future blog post, I will describe how my current research activities fit within this landscape.

References:

[1] J. Spohrer, P. P. Maglio, J. Bailey, D. Gruhl, “Steps Toward a Science of Service Systems,” IEEE Computer, Jan. 2007

[2] J. Spohrer, S. L. Vargo, N. Caswell, and P. P. Maglio, “The Service System is the Basic Abstraction of Service Science”, Proceedings of the 41st HICSS, Jan. 2008

[3] W3C, http://www.w3.org/TR/ws-gloss/

[4] Wikipedia, SOAhttp://en.wikipedia.org/wiki/Service-oriented_architecture

[5] Kieliszewski, C., From a presentation at a meeting of the Alberta CAS (Center for Advanced Studies) Research Board Meeting, December 2007.

[6] Maglio, P., From a presentation at a CAS Alberta Workshop on Service Science, Management, and Engineering, March 2008.

What is Service Science?

So, I’ve arrived here (at the University of Toronto) to embark on my scholarly and academic career. “So, what area are you in?” I’m asked. My first thought is, “I’m a computer scientist. I came from IBM. I’m interested in Service Science.” So, the next question is, “What’s Service Science?” Below I summarize what I think it is, why I’m interested, and briefly what (I think) I’m going to do next.

Service science (I am using this term – others may say “service science, management and engineering (SSME)” or simply “services”) is being called an emerging discipline. There is a big push in IBM and other companies to address this area and engage with academia to do so because the services sector (vs. manufacturing and agriculture) is the fastest growing segment of the economy in most if not all nations. Because of this significant economic shift and human labour migration, there is a claim that there is a need for organizations to be more systematic about services and services delivery; therefore, there is a need for research and innovation in services and for service science research and teaching programs to emerge (See Communications of the ACM July 2006 and IBM Systems Journal January 2008.

Programs are emerging in business schools, computer science and engineering schools, and through new multidisciplinary institutions. There are a host of others.

Establishing a research and teaching program in service science requires a multidisciplinary approach. It must combine knowledge about computing and technology with the social and cultural implications of how technology will be used in a specific business or societal service domain (or service system). I’m a computer scientist at heart and a proud member of the computer science community. I am very interested in how research advances in computer science can be made in order to impact something of importance (perhaps even change the world). I am fascinated by how these advances require understanding of and participation by people and society. Therefore, service science (as I understand it) is a very exciting area for me.

Most research to date has focused on service science with an underlying assumption that the service system or service is a business / profit service. Very broadly, I’m interested in service science in which the “business” domains are not-for-profit or community organizations. Most literature today assumes the services business is a profit-making entity. I will focus on the not-for-profit and community services organizations such as libraries, museums, healthcare facilities, etc. My initial investigations show that there are many interesting problems that come up in these contexts that are not prevalent in business environments.

So, that’s a start … within this framework, I’ve identified several interesting problems that I will blog about in future posts.