In this section, we present the design of the supportWatch application assisting workflows of support employees with smartwatches. This results in a software solution that can be applied in practice.
2.4.1 Problem Identification
During a workshop series targeting the capabilities of wearable computers in the industrial context and interviews with domain experts, a similar request appeared in the different kinds of companies: to utilize smartwatches for support employees. This is very promising, since supporters, ranging from technicians fixing machine outages to IT-supporters handling soft- and hardware problems, usually are mobile covering the entire company site, have to work collaboratively with their colleagues reconciling task assignments and have to react quickly to incidents requiring a noticeable notification while executing manual work. For this paper, during the discussion with the persons in charge, we identified three support scenarios predominantly characterized by many human-to-human interactions of a large-scale university illustrated in Figure 22, building the foundation of investigations in this paper.
Scenario (A) is grounded in the student IT-infrastructure support team. The employees have three primary areas of responsibility concerning public desktop workplaces, computer pools, and printers for students. First, they give support for soft- and hardware-problems, and second, they have to perform scheduled site inspections. Students can submit tickets in case they have technical issues at their workplace. These tickets accrue in a queue and are assigned to the support employees by the team leader at a desktop system, automatically or by the employees themselves. Also, the dispatcher allocates site inspections in which, e.g., every PC in a pool is investigated and checked for proper functionality. The concerned mobile supporter then has to complete these tasks as fast as possible with a priority on the tickets and has to give feedback about the results (e.g., whether a defect occurred and is repaired).
A similar scenario (B) is rooted in the lecture hall technology team. Lecturers use various digital systems as smartboards, projectors, microphones, cameras, and PC systems, including a broad range of software, during their lectures. Whenever technical problems occur in a lecture hall, lecturers need to contact the support by telephone, by (e-mail) ticket, or orally. The responsible team leader gathers all requests and transfers the tasks to the system. In the case of multimedia device defects, the ticket is passed to another team having specialized technicians. Based on the priority, requests have to be solved by mobile employees. If there is, for instance, a failure with the presentation PC and the lecture cannot continue, this has to be addressed immediately. Other issues like a request to install new
62 Studies: Smartwatch-based IS Supporting Mobile Employees Executing Manual Work
software for future lectures has lower priority. Besides periodic routine maintenance according to a checklist is executed (e.g., hardware checks and software updates). Every time feedback is required, whether problems occurred, which necessitate additional knowledge and effort to solve them efficiently.
Finally, scenario (C) applies to technical support in electronic assessments. Within the context of written examinations, students solve questions at individual PC workplaces in computer pools. Frequently the amount of students requires to use multiple rooms, which have to be coordinated (e.g., for a start and stop signal) by the responsible lecturer. Since PCs can drop out, or the periphery is not working correctly, in each room are technical support employees, who can solve these problems instantly during the examination without any time disadvantage for the student. Besides, a technical supervisor manages technical issues in real-time. This requires direct and silent communication between the employees to ensure adequate reactions within this critical period.
Figure 22. Three university support scenarios
These workflows offer the potential for improvement through digitalization due to two key problems. On the one hand, collaboration is complex due to employees are spread over the university, impeding oral agreements, fast and efficient reactions to technical incidents are difficult, and recent mobile communication systems require both hands for operation and interrupt manual work. On the other hand,
Mobile Employees
there are media disruptions, including digital, auditive, printed, and written representations of information sharing and personal notes.
2.4.2 Objectives
While analyzing and discussing the previously described scenarios with the team leaders, we can identify two main scopes we have to address in the smartwatch-based IS:
1. Tickets arrived in the existing queues should be transferred to supportWatch, assigned to an employee, who is then able to process the task assisted to the smartwatch.
2. We have to provide a possibility to manage scheduled site inspections with corresponding tasks that can be automatically assigned to employees who then can process their tasks successively.
To achieve this, we need to provide an interface for the ticket systems of the university for bidirectional information exchange, transferring tickets, and returning results of the processing (FR1). Furthermore, dedicated tasks have to be automatically generated and assigned to the employees’ smartwatches (FR2). For the handling of tickets, employees should be guided through the workflow, and there should be reasonable, predefined options to conclude tickets arranged in categories (FR3). To provide support for site inspections, the management of sites, and an organization of scheduled inspections due to maturity are required (FR4).
We summarize all functional requirements for supportWatch in Table 9, complementing the scope of operation of the underlying meta-artifact, which then builds the foundation for the design and implementation of the new functionalities in supportWatch presented in the next section.
Requirement Description
FR1 Interfaces for paired systems interface to ticket systems, for the input of tickets and to return the processed ticket result
FR2 Generation of assignments tickets and site inspections have to be assigned as tasks to employees’ smartwatches
FR3 Ticket handling process guidance with reasonable options to conclude a ticket FR4 Site inspection handling management of sites, organization of site inspections due to
maturities Table 9. Functional requirements for supportWatch
2.4.3 Design and Development
As we can rely on an existing meta-artifact developed by Zenker / Hobert (2019, study 1), the system already provides a web-based desktop backend and a Wear OS smartwatch application. This includes
64 Studies: Smartwatch-based IS Supporting Mobile Employees Executing Manual Work
all functionalities for the basic interaction between the smartwatch and the web-backend users, a REST-API, workflows enabling process guidance, assignment of activities, and workplace management.
During the conception and implementation phase, we deeply involved the leader of the student IT-infrastructure support team. In this way, we productively can apply the changes and modifications for the adoption to fit the requirements of support employees.
In the following, we present the implementation of the ticket workflow. First, a ticket occurs at the university ticket system. There are multiple frontends in which students, lecturers, or employees can add tickets (see Figure 23 (left)). We modified the corresponding system that it calls the supportWatch API whenever a scenario related ticket is submitted into the queue (FR1). Second, supportWatch creates a new activity with the team leader as the responsible person (FR2). According to the workflow, the ticket can now be dispatched to a mobile employee. Then, the request appears at the employees’ smartwatch (see Figure 23 (right)), the ticket can be processed, and the corresponding action can be selected, e.g., the PC has to be replaced (FR3). Finally, according to the selection, the result is returned to the ticket system over another interface, and a respective status is stored (FR1).
Figure 23. The components of supportWatch: (left) ticket system, (middle) overview over sites with color-indicated maturity including a map and (right) smartwatch view of the ticket and corresponding options
For site inspections, we added a new tab to supportWatch in which sites can be managed (see Figure 23 (middle)), and an import of rooms with a list of the IT-equipment over a university API is available (FR1). Hence sites hold information about the location, a map, and the maturity of the inspection indicated by color, e.g., red are the most urgent ones (FR4). Whenever an inspection is due, the system automatically generates activities for each site (FR2). According to the created workflow, these activities can be assigned to mobile employees who process the inspections guided by their smartwatch. Finally, the site inspection is concluded with a respective status that is stored by the system, and possible next steps can be triggered.
2.4.4 Demonstration
To initially introduce support employees within the university scenarios to smartwatches and the supportWatch application, we conduct a demonstration according to our research process. For this, we organized several live presentations involving the different teams and first presented basic information and the potential of smartwatches and second the supportWatch application within a realistic scenario.
This includes 22 employees working in the previously defined scenarios and accordingly for the teams of student IT-infrastructure support, lecture hall technology support, and electronic assessment support.
In addition, the four team leaders attend the demonstrations. All participants were rather open-minded and interested in our ideas as well as in smartwatches as an innovative device. To obtain deeper insights into the impression of support employees and impacts to support workflows regarding our system, we conducted a field study within two of the scenarios. Accordingly, supportWatch was integrated into these scenarios over four weeks, five employees are equipped with smartwatches, and two team leaders used the web-based backend.
2.4.5 Evaluation
Subsequently to the demonstration, we first conducted a questionnaire study to evaluate employees’
attitudes concerning smartwatches and their ratings about the concept. We determined that just 16 % of the participating employees have recently used smartwatches in private, and none of them in the corporate context. Nevertheless, some participants consider purchasing a smartwatch caused by the study due they like the functionalities such as “a fast overview, notifications and that it is always at the body” (Q1-Exp15) and “heart rate measure and direct vibrations at my wrist” (Q1-Exp17). The survey shows that 34 % of the participants found the idea to use smartwatches in the corporate context very good, 44 % assigned to good, 22 % to okay, and nobody to bad or very bad. Overall 62 % indicated that they do not have doubts about using smartwatches at work and that smartwatches “can accelerate workflows and make communication easier” (Q1-Exp11) and “provide fast reachability in case of critical
tasks” “protection of personal data,
66 Studies: Smartwatch-based IS Supporting Mobile Employees Executing Manual Work
tracking, low battery capacity, and small display size” (Q1-Exp18). On a scale ranging from 1 (very bad) to 7 (very good), the participants evaluated the idea to assist their work with a smartwatch-based system with 5.8 on average. In detail, they rated 6.0 for the case of site inspections, 5.6 for processing tickets, and a 5.7 to use the presented system during their work. The utility of functions regarding the site management got a 6.1 and the ticket system a 5.9.
Questionnaire 2, which was conducted subsequently to the field study, shows that the employees are even more convinced of the idea to use smartwatches in their daily work after they had the chance to practically apply and test the system raising the approval to 80 %. They positively evaluated supportWatch but emphasized several issues that have to be improved in the prototype to ensure practicability. Amongst others, sometimes crashes occurred, connection establishment took unreasonably long, and the usability of the application can further be revised. Although the study increased the consent for smartwatches in the corporate context, the study tightened concerns as “the smartwatch assists my daily work, but I also feel more supervised” (Q2-Exp5).