Keywords

1 Introduction

Since the 1970s, information technology has found its way into the daily business activities of companies, and over the years its importance has continued to rise. In today’s society, companies of the so-called information age rely on IT in a way that a breakdown of the IT-based infrastructure quickly leads to severe problems. To prevent such a breakdown, it is necessary to professionalize IT operations. Such a professionalization is the aim of the so-called Information Technology Infrastructure Library (ITIL), a best practice standard which was first developed in the 1990s and is now in its third edition. It proposes looking upon an internal IT function as an IT service provider that provides services to the business units. This idea of a service orientation is not only used in practice but has also attracted academic intrigue since the turn of the century and is discussed here under the paradigm of “IT Service Management” (ITSM).

Research so far has focused on the diffusion of the ITIL in practice. Studies by Kemper et al. [1], Hochstein et al. [2], Tan et al. [3], Marrone and Kolbe [4] as well as Marrone et al. [5] document a broad adoption of the ITIL. The benefits that organizations associate with the implementation of the ITIL are, for example, a higher overall service quality, a higher first call resolution rate, and a reduction in downtimes. Remarkably, the benefits perceived seem to significantly diminish the higher level of maturity achieved [4]. Although the ITIL and ITSM in particular are widely adopted in practice, practitioners still struggle to understand the core concept of ITIL and ITSM – the IT service itself – as it is still not clearly defined and has yet to be researched in depth [6].

To counteract this gap, we conducted an in-depth literature review and developed an IT service definition, which is based on the few academic contributions in this field as well as the recommendations of the ITIL. This definition proposes six characteristics, which we believe, if taken together, fully capture an IT service in the sense of IT service management (for more details, see [7]). To evaluate our definition empirically, we have set up a research project with the IT department of a German university. In this paper, we will report on this research project and our evaluation approach as well as the results.

We will start in Sect. 2 with a brief overview about our six defining characteristics of an IT service. In Sect. 3, we will detail the case study and the research methods used, followed by an elaboration on the findings and results in Sect. 4. In the final section, we sum up our findings and provide an outlook on future research.

2 The Concept of an IT Service in the Academic Debate

In its broadest sense, the term “IT service” can refer to any service (somehow) related to Information Technology. Taxonomies that build on such an inclusive definition involve “software development projects”, “hardware deployment”, “hardware repair”, “software maintenance”, “software hosting”, “systems integration” as well as “IT hotlines”, “IT consulting”, “IT training”, and “IT outsourcing” [8,9,10]. Given this diversity, it is obvious that IT can play different roles in IT services.

The ITIL, as the de facto standard for IT service management, has a much narrower understanding of an IT service. Here, IT service is understood as a service that is “made up of a combination of information technology, people and processes” [11] and it “directly supports the business processes of one or more customers” [11]. This definition underlines that an IT service in the sense of the ITIL makes use of information technology to support the business of a customer. Therefore, IT is used as a means to produce an IT service but is not the outcome of the latter. Also, the direct support of the customer’s business is highlighted. This stands in contradiction to some of the exemplary IT services mentioned above.

Beside the ITIL, a small number of academic authors have developed their own definitions of an IT service in the sense of ITSM. They range from those that focus on generated value (“what?”), to those that stress the technical implementation of an IT service (“how?”). For example, Zarnekow et al. [12] define an IT service as “a bundle of IT accomplishments to support a business process or business product of the customer to generate a value for him” and therefore focus the business support and the value generation of an IT service. With a more technical view, Ebert et al. [13] for example define an IT service as “as a bundle of components that supports business processes with information processing, provisioning and storage. Components (i.e. sub-services) of an IT service can constitute manual services, as well as technical services”. They hence emphasize the technical implementation of an IT service. This variety of definitions might lead many organizations to struggle with the main ideas underlying IT service orientation. For example, a study by Winniford, Conger and Harris [6] found that IT executives, despite claiming to have successfully introduced the ITIL in their organization, had difficulties explaining what an IT service is and had trouble giving examples. Additional case studies and action research [14,15,16] reveal that organizations that adopt the ITIL do not necessarily understand and implement the underlying core concepts including, above all, that of an IT service. This is a devastating result, given that the IT service is the “nucleus of the entire ITIL” [17, 18].

A clear understanding of IT services is also a necessary prerequisite of any theory development on “IT Service Management”. In fact, the IT service is the core theoretical term of ITSM. But so far, researchers have not been able to clearly define what exactly is meant by the term “IT service”, thus the theoretical kernel of ITSM remains vague [19]. We took this situation as motivation to investigate the concept of an IT service as rooted in the ITIL and discussed deeper in ITSM. The objective of our research was to come up with a clear and substantial definition of “IT service”, which is desperately needed for ITSM research. As a result of our research, we have developed a set of six defining characteristics of an IT service (for a more detailed explanation, see [7):

Intangible

Services are bundles of activities, performed by a service provider and rendered to an external factor by the use of internal production factors [21]. This is called intangibility. For most IT services, the external factor is a so-called business process object: a process-shaping object that drives the process flow in that its status demands for the execution of specific processing functions (see [22]). Business objects are processed within customer business processes. For example, if the business process “Invoicing” is supported by an IT Service, one business process object would be the invoice itself. Some others further argue that the external factor of an IT service can also be a business product or service of an organization (see [12]).

Generating Customer Value

IT services are ordered by business organizations (the customers) that expect the service to generate a value for them by supporting the execution of business processes. Value may be generated for example, by shortening processing times or by raising the quality of the process outcome, thus resulting in cost reductions or higher customer satisfaction. Value generation through IT services require an employee of the organization (the user) to call upon the service. For example, an employee might use an IT service to create an invoice for a customer. This task requires them to fill in customer data and invoice positions before the invoice can be generated.

Produced by Means of an IT-based infrastructure

IT services are produced by means of an IT-based infrastructure. Such an IT-based infrastructure is the backbone of each service production and therefore also referred to as “production infrastructure” by Zarnekow et al. [12]. A production infrastructure is divided into layers for application systems and technical assets, like servers, basic software or network components. The higher-level components here use performances of the lower-level components. For example, the application systems use the performances of operating systems and hardware servers to provide the business logic for processing a business process object.

Produced in an industrial fashion

The idea of an IT-based production infrastructure is closely related to that of industrialization which implies that production processes are automated, specialized and standardized to reduce production costs, and increase the production speed and quality of the products. Automation refers to the substitution of manual labor by machines or technology in industrialized production processes. In effect, automation leads to production processes that are mainly executed, supported, and controlled by machines (the IT-based production infrastructure). Automation in turn furthers specialization by first dividing labor between machines and humans, and second by differentiating tasks and responsibilities of human actors. This results in human actors with dedicated skills performing highly specific tasks (the employees of the service provider). A third trait of industrial production is standardization. The idea is that reductions in unit cost are larger the higher the number of products produced (product standardization). Standardized products can be produced through standardized procedures that in turn allows for high levels of specialization and learning effects (economies of scale). Product standardization is particularly supported by the idea of composing IT services out of standardized technical component services, the so-called infrastructure services. The latter do not deliver any business value on their own, and thus are not offered directly to customers.

Mass Customized

The value generation for a customer and standardized production stand in contradiction to each other. As value is generated within the business processes of the customer, with each customer being unique, standardized services cannot suit the customers’ needs the same way individually produced ones can. In the theory of industrial production, this challenge is addressed with the concept of mass-customization. Mass customization proposes combining standardized pre-fabrication and individualized assembly for offering products that match individual customer needs better than mass products but are at the same time much cheaper than individually manufactured products. At the heart of mass-customization is the concept of modularization; IT services as end-products are to be composed out of modules, that is standardized and reusable components.

Provided Care-free to customers

The production of an IT service is often very complex in terms of the work to be done and the necessary production infrastructure. Moreover, the service provider is responsible for operating and maintaining the production infrastructure and ensuring that it is working to produce a service. The customer who orders the services, however, should not be burdened with technical complexity and production details. Hence, the whole service provision should be transparent for him. In turn, the customer pays a service fee to the service provider for the service usage.

These six characteristics have been developed based on the ITIL and the academic literature that we found by an in-depth literature review. For an explanation of the whole literature review process and the development of our definition, see [7]. To validate our definition empirically and to find out if it helps practitioners better understand what an IT service is and how to define it, we set up a research project that we will report on in the next section.

3 Research Design

We are drawing on a case study regarding the central IT function of a German university, which is called UnIT here. Following the contributions of Flyvbjerg, case studies might also be a valid research method to do an in-depth evaluation of concepts, like our service definition [23]. In the next paragraph, we will give a short introduction of our research partner, followed by an overview about the research methods used.

3.1 The Project Partner UnIT

UnIT is the central data center of one of the biggest universities in Germany. It operates central IT infrastructures and provides accomplishments to members of the university (like students, scientific, and non-scientific employees). These accomplishments are intended to foster productivity and support members in their daily business activities, for example by providing internet access. While the daily business activities of non-scientific employees might be relatively homogeneous, research is an especially creativity intensive process. It is therefore a very heterogeneous and non-standardized field of work. To support this heterogeneous work, a heterogeneous IT-based infrastructure is also necessary. As it would be almost impossible for UnIT to operate such a heterogeneous infrastructure, which powers the work of over 40,000 students as well as more than 5,000 employees, the university established additional, decentralized IT functions (called DecentITs) for each faculty, that provide special accomplishments and support for faculty members. For example, DecentITs offer the workplaces that include also accomplishments of UnIT (like internet access). The DecentITs are therefore the single point of contact for employees.

UnIT therefore must deal with two types of “customers”: on the one hand, they provide accomplishments directly to students and employees, whose technical affinity might vary from low to high. On the other hand, UnIT provides accomplishments to the decentralized IT functions, which combine them, and in turn provide them to their students and employees. It should be noted here that at the time of the project, a clear differentiation between UnITs responsibilities and those of the faculty IT functions was often not possible, and therefore responsibilities were overlapping in some points.

To deliver all accomplishments, UnIT has around 120 employees that are working in different departments: there are non-technical departments like administration or public relations, as well three departments responsible for the operation and maintenance of the IT-based infrastructure. Some of those departments were furthermore divided into teams. All of these teams are headed by a team leader and all departments have a departmental leader as well as a deputy. The departmental leaders stay in close contact with and report to the CEO of UnIT, which consists of UnITs CEO, a director as well as the deputy of the CEO. The top management, the departmental leaders and the team leaders together form the management board of UnIT.

The CEO and the director report directly to the rector and the chancellor of the university. Together with the rector and the chancellor as well as a small number of university employees, UnITs top management forms a steering committee of the university, which discusses strategic questions regarding the use of IT throughout the entire university. Moreover, this board is involved in developing an IT strategy every five years, which sets the directions for the IT functions.

In 2006, UnIT decided to introduce ITSM for the following reasons: first, the full range of provided accomplishments was requested to be made transparent by the central university administration. This might be due to the reason that the university was under high cost pressure due to changing laws: While in former times, the universities had been funded by the German state, since 2006, students had to pay tuition fees and the funding by the state has been reduced. Second, there was interest to clearly define the responsibilities of UnIT and the faculty’s own IT functions. This was due to the fact that the borders between those two had blurred and the number of cases, in which nobody felt responsible, e.g. for a system breakdown, was increasing.

Therefore, a first attempt has been made to introduce ITSM at UnIT. This attempt was unsuccessful as we will report later. Even a second try did not achieve the former mentioned objectives. Until today, the introduction of ITSM did not happen. Therefore, UnIT asked us to help them. For this, we set up a joint research project in March 2016 to establish an IT service definition.

3.2 Research Method

As already mentioned, we designed the research project as a case study and began our project by identifying the problem to be addressed and setting an objective to achieve. For this, we first interviewed the CEO and director of UnIT in March 2016. Questions in this semi-structured interview focused on the main rationale for introducing IT service management and here, especially, an IT service catalogue. Furthermore, we asked questions on their previous experiences and why the former attempts of establishing services had failed.

Based on the interview responses, we designed a first workshop with the whole management board of UnIT, which was conducted in May 2016. The focus of this workshop was on gaining an understanding of how the board members perceived IT services and what they find difficult, when defining those. To gather this information, we used a group discussion approach (see [24]). This approach is characterized by the fact that the researcher provides key questions to stimulate and uphold a debate, while not being an active part of the discussion itself. To be more precise, his role is that of a moderator.

The key questions for the discussion were the understanding of services in general and IT services in special as well as a demarcation of IT services from each other.

The insights from this group discussions were then analyzed and aggregated. We used them to develop an UnIT-own service definition, which we presented in a second workshop in June 2016. This workshop was again done with the members of UnITs management board. We used this appointment for another group discussion, in which we presented the aggregated service definition based on the results of the first workshop as a stimulus. Key questions here were if the prepared definition reflects the understanding of the board members correctly and if they feel comfortable with it. This workshop gave us a unique chance to double-check and verify the interpretation of the results of the first workshop, and to extend our own understanding of the situation and challenges at UnIT. After closing the discussion and feedback round on UnITs own IT service definition, we asked the management board to create exemplary service descriptions based on it. We then analyzed the experiences the board members gained while they created these descriptions. This gave us further insights as to whether the self-developed definition is practically applicable or not.

Finally, we set UnIT’s service definition in contrast to our own, literature-based one to get valuable feedback from the practitioners and to discuss our definition. We were hoping that the practitioners, especially due to their former experiences with IT services, could discuss our definition in a much more intensive and profound way. We also wanted the practitioners to use our definition and rework their service descriptions to validate the practicability of our definition. In the next section, we will report on the insights and results of the workshops and the feedback and applicability regarding our service definition.

4 Development and Evaluation of an IT Service Definition

After we agreed on a joint research project, in our first meeting with the CEO and the director of UnIT in March 2016, we conducted a semi-structured interview to identify the problem that we wanted to work on.

4.1 Motivation for Introducing IT Services

In the interview, we obtained information that UnIT’s first attempts to introduce an IT service orientation were going back to 2003. We asked in more depth, why – around 13 years later – no final catalogue of services has been established and identified different reasons for that.

First, the CEO told us that not enough resources had been put into the effort. This meant that the department leaders were requested to write down “accomplishments” of their department, but had to do this alongside their daily work. This led to multiple delays in the submission. After every department leader had submitted their list of accomplishments, the aggregated portfolio was found to contain around 300 of those. In contrast to other organizations, where normally 30–70 services are in place, this a surprisingly high number. A deeper look into the portfolio of accomplishments revealed that the list showed a great variety of accomplishments, ranging from small, single (and often very technical) activities, up to the execution of complete business processes, besides the delivery of products, provision of user support, holding lectures or rental services for hardware assets. As we were astonished about this long list, the CEO explained us, that the portfolio has been perceived as documentation about the accomplishments delivered for external stakeholders (like the university administration) and therefore, every employee of UnIT had a high interest in being represented within the list, so as to not be critically scrutinized for what they actually do. Beside this fact, the CEO told us that the department leaders had another problem: they did not know exactly, what they should write down in the list, or to be more precise: what “accomplishment” means. At that point in time, the ITIL was on the rise in public and services seemed to be an appropriate way to encapsulate the accomplishments. Therefore, all department leaders as well as the CEO and the director attend an ITIL Foundation course and successfully passed the certification exam. The management board was optimistic that this would establish a common ground to work on and another attempt was made to define a list of delivered accomplishments, which were now called “services”. When we questioned on the difference between “accomplishments” and “services”, the CEO told us that for him and the management board “this is just a synonym”. In former times, “everybody spoke on ‘accomplishments and now it is ‘services’ – for me, there is no difference”. While this might be doubted on a notional level, it made explicit – especially against the background of the former (very technical) portfolio – that the idea of leaving out technical details and taking a non-technical, customer-oriented perspective (as proposed by the ITIL and ITSM), had not been adopted thus far. When we questioned this and asked for general characteristics of a service, the CEO told us that this is a problem at UnIT, as the management board members do not have a common understanding of what an IT service is, even after being ITIL certified.

In a last step, we wanted to find out the goal, why UnIT wanted to introduce IT services. The CEO as well as the director told us there are two reasons: first, UnIT wanted to get an overview of the service delivered as there was not a complete list in existence. Such a list would be helpful in the future to analyze which services are not needed anymore and to stop providing them, as well as to question the scope of delivered services. Second, they wanted to assign clear responsibilities to the accomplishments. And third, they believed that service management would gain benefits: For example, that the standardization of production processes and services would ensure a steady quality.

4.2 Discussion and Development of an IT Service Definition

Based on what we discovered in the first interview, we set up a workshop focused on the different IT service understandings with the intention of developing a preliminary working definition. As mentioned above, we designed this workshop as a group discussion, stating the question, “what is the motivation for you (the practitioners) to introduce IT services?” at the beginning. From this, we gained different, interesting insights: first, one department leader told us that he has a personal interest in introducing IT services: As he is soon retiring, he wanted to finally structure his department before handing it over to his successor. He told us that IT services seem to be an appropriate means of structuring the departments’ internal activities as it carves out, what activity should be done for which IT service. Based on this overview of activities, responsibilities could be assigned to the different activities or – even more – to the whole production of the service. He furthermore mentioned that such responsibilities are not given for his department currently and sometimes nobody feels responsible in case of a breakdown. He summarized that IT services are a vehicle to (re-)define the internal, organizational structures.

Such an introspective view was also shared by another department leader, who adds that such an assignment of responsibilities is not only meaningful within a department, but also to coordinate the work between the different departments and teams. In his opinion, this is necessary, as the responsibilities between the departments are not clearly defined, which in turn leads to a “vacuum situation”, where nothing happens. IT services – in his opinion – would counteract this by clearly defining responsibilities within as well as between departments.

In addition to internal views, another department leader had a more external view and considered IT service more as a “marketing tool”. He told us that IT services and an IT service catalogue would allow him to make visible for the users what accomplishments his department delivers. This “marketing” was important for him as his department is the main interface between the users and UnIT: it is responsible for user regarding the accomplishments which the users (students, employees) can directly receive from UnIT (like printing or internet access).

After questioning the motivation, we went over to their understanding of an IT service. We asked openly, what an IT service is, leading to a very extensive discussion, bouncing from one point to another. The whole discussion began with one department leader stating, that a service is, “when the user gets help from UnIT”. This statement was influenced by a day-to-day understanding of “service” as being an activity of help or support. We took this statement and asked further, how it applies to the list of accomplishments the CEO told us about. The department leaders began to discuss and introduced another term to differentiate, the German word “Dienst”. “Dienst” is the translation of “service” and this was quite interesting, because the department leaders factually used the same term to describe different things: “service” was used for activities regarding user support or help, while “Dienst” was used for – mainly technical – activities that the employees of UnIT were performing. Within the discussion, another department leader even introduced another term, “Dienstleistung”, which can be translated as “rendering a service”. Regarding his understanding, “Dienstleistung” is about the initial activities that are done to establish a “Dienst”. He gave the following example: the provision of a network connection (“Dienst”) would first require the installation of a network socket (“Dienstleistung”). In case of a breakdown (e.g. the network connection not working), the user gets help or support (the “service”). Even more interesting, the practitioners led the discussion to the point that they were asking each other things like: “But if I think about X, what is then the ‘service’, ‘Dienst’ and ‘Dienstleistung’”. This underlined that it was difficult to differentiate the terms from each other.

We pushed the discussion forward by asking who the former described accomplishments or activities were delivered for. This started a discussion about service recipients. Within this discussion, different possible recipients were mentioned: from the university administration, the building authority of the university (e.g. for the installation of network sockets) and the institutes or chairs, to the employees and students. The group started to discuss these recipients and developed a differentiation between a customer and a user: the customer as the person or organizational unit that pays for the service (“Dienst”, “Dienstleistung”) and the user, who really uses the latter.

The discussion continued to the point that some customers or users needed different variants of the same service. Therefore, the practitioners agreed that the provided services need to be differentiated. They underlined this fact with an example where some faculties need higher availability of systems than others. This is turn pushed the discussion to the point that – explained by the availability example – services should be normally provided in a standardized way, to achieve standardized results and therefore allow for the promise of a certain degree of quality, besides those case of special requirements. Stemming from this, the practitioners also agreed that the service has to have a value for the customer or user using it. Although they mentioned this, it was hard for them to describe what the value is in detail. The discussion was around the example of the network connection again, where some of the practitioners mentioned that the network socket would generate the value while other said that the network connection for a device that is provided over this socket, generates value. They were not able to clearly work out how the value can be determined but agreed on the fact that a service has a value “somehow”.

The last question we asked was regarding the difference between a service in general and an “IT service”. The first answer we got was: “It is called IT service because it is a service provided by us – the IT”. This showed us that the understanding of an IT service is closely related to the providing organization. The same person substantiated this by telling us that, “for example financial services are provided by the financial department”. However, this view was not shared by other department leaders, who argued that it is called “IT service” because it uses information technology. This in turn was countered by another person who said that “nowadays nearly everything is or includes IT”. He furthermore questioned if it is necessary to differentiate the “amount of IT used” to demarcate if it is an “IT service” or a service in general. He underpinned his question with the example that UnIT also holds lectures on the use of application systems, like statistical software. He argued that there is also a considerable amount of IT “in it”, but felt uncomfortable with calling those lectures an “IT service”.

At the end of the discussion, the practitioners were confused about what an IT service is. Within the discussion, their own understanding had been questioned, either by us or their own colleagues. Their perception of an IT service had become blurred and therefore, at the end, they agreed upon the fact that it is difficult to establish a common understanding of an IT service.

After the first workshop, we took all the comments and analyzed them in detail to create a summary for the second workshop. In this summary, we worked out the key facts and intermediate results of the group discussion:

  • IT services have a user help or support part,

  • they are produced for a user and ordered by a customer,

  • they generate a value,

  • they are closely connected to technical accomplishments, which require initial activities (preparation) to be provided.

  • IT services should be standardized and produced by an interplay of UnIT’s different departments if possible, but

  • should not neglect specific and special requirements of customers.

  • Moreover, IT services use a large amount of information technology.

With these characteristics, we went back to UnIT and conducted the second workshop. We started this second workshop with an evaluation of whether we understood the practitioners correctly and if they agree upon the discussed characteristics. They confirmed that we understood them correctly and told us that since the first workshop, an internal debate on what an IT service is, had started again. The summary of the characteristics was a helpful first step towards a common understanding. After presenting these, the practitioners told us that – although they developed these features on their own – the explicit and condensed reproduction of what they discussed was helpful for them. We went over and showed them examples from their own list of accomplishments (or “service catalogue” as it had now been named) and asked them to reflect these against their characteristics, and to determine if they still believe that these are IT services. Within the discussion of these examples, the practitioners agreed that not everything in the service catalogue is an IT service. Furthermore, they concluded that they need to differentiate between general services and IT services. Services like “Provision of Handbooks” or “Camera Rental”, as well as “Lectures” were no longer recognized as IT services but as services in general. They further recognized that information technology is nothing that is provided to the user, but what is used to provide an IT service (as a means of production).

For the practitioners, this was a big first step towards a common understanding of what an IT service is. They were now able to distinguish services in general and IT services. We further asked them to “test” their characteristics and use them to describe a sample set of services of their own department either for end-users (students and employees) or for technical organizations like the DecentITs. After this had finished, we analyzed the descriptions within the group and found that on first glance the services were described quite homogeneous due to the defined characteristics. However, they varied in terms of details in the individual descriptions: while some of the department leaders wrote down the used IT components in a very detailed way (down to software protocols used), others kept a very high level (“the service uses a webserver and the software X”) description. The same happened for generated value. Here, some wrote “a network socket is provided” while others wrote “the user can print a document”. The practitioners were quite happy with their characteristics “somehow” but asked us for our opinion.

4.3 Evaluation of Our Literature-Based IT Service Definition

We took this as a chance to evaluate our own definition as outlined in Sect. 2. To make our characteristics comparable to those of the practitioners, we analyzed the practitioners’ characteristics and preliminary descriptions in terms of their meaning. We then related them to our characteristics, which led us to the comparison as depicted in Table 1.

Table 1. Comparison of UnIT’s and our IT service definition
Full size table

As can be seen, the developed definition of the practitioners was quite close to ours. Only the business process object as the external factor was not mentioned by the practitioners. When we presented our definition and the comparison to UnIT’s definition, the practitioners were happy that they were quite near to the “academic view” on IT services.

We then evaluated where their definition differed to ours by presenting the respective characteristic of our definition and asking the practitioners for their opinion in terms of their meaningfulness and practicability. We started with the business process object and explained what this means and how it is related to the generated value. The practitioners told us that it is obvious for them that a service has some “object” it renders to – although they never mentioned this in the discussions before and also never spoke of “business processes”. But they nevertheless agreed that the business process object as well as business processes should be part of each IT service.

The use of an IT-based production infrastructure as understood by us was very insightful for the practitioners. As outlined before, they struggled to answer the question, “how much IT” is used in an IT service and in which way. This is closely related to the degree of automation as proposed by industrialization. Although the practitioners did not talk about automation previously, after we explained the idea of automation in services, they agreed that the service is provided by information technology and the people around oversee setup, maintenance and support. Also, the other concepts of automation, standardization and specialization, were seen as meaningful by the practitioners. They agreed that the service production and the service results should be standardized (where possible) and that service production is done as a cooperation of multiple departments – what can be interpreted as specialization.

The characteristic of carefree provision was also mentioned by the practitioners in the workshop – although they understood it more in a way that the user obtains support in case of a breakdown. When we explained to them our understanding of a carefree provision – that the IT infrastructure used for the service is fully owned by the service provider – they told us that this is helpful for them to distinguish IT and non-IT services from each other.

For mass customization, the practitioners mentioned that services need to be offered in variants to meet individual requirements, but they did not go as far as mass customization goes. Therefore, they did not think of modules or technical services which are connected to each other to provide an IT service for the customer. Although they liked the idea of mass customization, they stated that this would be a future step for them as they first wanted to establish an initial list of services and just assign concrete IT components to those.

In the end, they agreed with what we explained to them and found our definition as a meaningful evolution to their own. To further validate our definition empirically, we asked the practitioners again to describe exemplary services from their department using our definition. We analyzed these descriptions and found that the generated value was now described in a more customer-oriented fashion. The only thing that was still complicating the matter was the concept of a business process object. Some of the practitioners seemed to have not correctly understood what such an object is. For example, the department leader, who specified the “e-mail communication service” wrote down that the mailbox of the user is the business process object. But in an e-mail service, the business process object is the e-mail itself that is being processed (created, sent and received) by the service. Interestingly, another department leader who had correctly understood what a business process object is, explained to his colleagues the concept, validating that the concept had been understood by some participants. They also validated that this characteristic is helpful. Furthermore, they also explained that they could figure out the customer value more easily by first identifying the business process object and then asking for the value that is generated by processing it.

5 Summary and Outlook on Future Research

Within the case study we gathered many interesting insights, which we distinguish into findings regarding the motivation for the use of IT services, the understanding of IT services before introducing our definition as well as the evaluation of the latter. The results are summarized in Table 2.

Table 2. Results of our case study
Full size table

We were able to validate our definition within this project, but we also noticed that the concept of a business process object was quite difficult to understand for the practitioners. Also, the implementation of mass customization seems challenging. Here, different approaches from the literature (see for example [25]) might be considered and tested further.

The next step after service definition is to specify the services in a customer-oriented way for a service catalogue. We are currently doing this with UnIT and the initial results are promising. We intend to work on this further to open the “black box” around the concept of an IT service.