1 Institutionen för datavetenskap Department of Computer and Information Science Final thesis Development of a customer support process tool in SharePoint Online by Andreas Larsson LIU-IDA/LITH-EX-A 15/017 SE June 11, 2015 Linköpings universitet SE Linköping, Sweden Linköpings universitet Linköping
2 Linköpings universitet Institutionen för datavetenskap Final thesis Development of a customer support process tool in SharePoint Online by Andreas Larsson LIU-IDA/LITH-EX-A 15/017 SE June 11, 2015 Supervisors: Examiner: Magnus Bång (Linköping University), Matz Höög (HOW Solutions) Rita Kovordanyi (Linköping University)
3 Abstract Management thinking has changed focus from bringing in new customers to understanding the significance of maintaining existing customers and the need to attain loyalty with these customers. This has increased the importance of keeping good customer relationships. One important element to attain good customer relations is through a solid customer support. In this thesis a customer support approach for a software consultancy company has been implemented. The goal was to create a SharePoint Online application that would work as a single point of contact for the customers to improve the issue resolution process. Requirements elicitation was done through five customer interviews to obtain opinions and needs. Moreover, based on the customer requirements a workshop were held with developers from the consultancy firm to design a workflow prototype. The final result is a customer-centered process that takes reported issues and manages the tickets through the issue life cycle until the issue is resolved. The approaches relies heavily on light-weight feedback in terms of mail notifications, reminders, and automatic assignment of tasks. The new process was developed in SharePoint Online and implemented using SharePoint Designer. i
4 Contents 1 Introduction Background HOW Solutions Problem Goal Method Structure Limitations Theoretical background Customer support Customer Relationship Management CRM levels Information technology and CRM Customers in CRM Benefits of CRM Incident Management Process Problem Management Process Knowledge base Workflow Types of workflow When to use workflows Case based Trouble tickets Structure of the trouble tickets Features in TTS Method Customer interviews Workshop Software SharePoint Online SharePoint Designer ii
5 3.3.3 SharePoint Workflow Result Current problem Customer interviews Result from workshop Initial stage Answer or continue Continue or discard Under investigation Need feedback Solved Ready for testing - test environment Evaluate failure cause Deliver to production Ready for testing - production environment Case closed and archived Special cases Other topics Requirements Implemented workflow Ticket partitioning Notifications Tasks as a part of the automatic delegation Reminders Flexibility Discussion Mail to ticket Improved reporting form State machine workflow Alternative solutions Future work Conclusion 43 A Workflow scheme 45 B Requirements 47 Bibliography 49
7 1 Introduction 1.1 Background Customer relationships play a very important role for businesses when it comes to stay competitive. By achieving a healthy relationship toward the customers, organizations can obtain many benefits, such as more satisfied, loyal and profitable customers. Management thinking have shifted focus from bringing in new customers to understanding the significance of maintaining existing customers and the need to attain loyalty with these customers. As customer support is an important element in customer relationships organizations put a lot of effort into optimize their customer support. With the use of information technology, customer support has gained much improvement. Customer support can be provided to a large amount of customers by utilizing the web. 1.2 HOW Solutions HOW Solution is a consulting company located in Linköping and Stockholm that specialises in portal solutions, especially in Microsoft SharePoint. Their vision is to establish close and long-term relationships with their customers and their business concept covers the whole process, including feasibility study, implementation, monitoring, support and administration of software solutions.
8 1.3 Problem The problem that is experienced today is that there is no coherent process for communication between customer and supplier when it comes to user support. The current communication regarding support and issues are spread out over several mediums besides the issue management system, such as telephone, and faceto-face meetings. The communication in the current reporting system is limited, there are restricted forms for interaction in the collaboration room today, which is why large parts of the communication are carried out through other mediums. This behavior can result in loss of valuable information regarding issues and difficult to manage issue tickets. The procedure to access the collaboration room is cumbersome compared to other means of communication. This have resulted in long response times, questions are not answered in a reasonable period of time and regular updates regarding the resolution process are foregone. This have resulted in a general low usage of the collaboration room and have affected the customers confidence towards the system. During the tickets life cycle there are a great deal of manual management of the ticket, such as assignment, status changes, delegation and coordination of people. As the developers try to find solutions for issues as fast as possible, it is important that they can direct their focus on solving the issue instead of managing tickets. 1.4 Goal The goal of this thesis is to develop a flexible and coherent process for issue management that is applicable on the variety of issues that customers reports to their supplier. The process needs to be well-adjusted to suit both the customers and the developers needs during the resolution process as well as implementation process. Another goal is to minimize the manual management of the tickets throughout the solution process and ticket life cycle by automate parts of ticket management, such as assignment, customized tasks, coordination, notifications and status updates. 1.5 Method The thesis theoretical background is retrieved from literature and reports covering SharePoint development, customer relationship management, different processes in issue management, trouble tickets and workflows. Besides literature studies, interviews and evaluations were held with current customers of HOW Solutions. The purpose of these was to find out how customers perceived the current situation with the support process, experienced shortcomings, and requests and wishes of future systems. A portion of the interview focused on how the communication was carried out between customer and HOW Solutions,
9 including what were communicated, in what purpose, what mediums were used and how often they were in contact with HOW Solutions. As the goal was to develop a process that is suitable, not only for the customers, but also for the developers at HOW Solution, a workshop where held together with some of the employees at HOW Solutions. The purpose with the workshop was to brainstorm potential processes for issue management that, from the developers perspective, was desirable. With the interviews and the workshop in mind, a set of requirements where formed. These requirements where used during the development of the prototype of the new issue tracking system. The new customer management system was developed for SharePoint Online and to develop the new approach SharePoint Designer was used. The new solution uses SharePoint workflows to implement the process. They workflow were mainly based on the prototype brainstormed in the workshop together with knowledge obtained from literature studies. Along the workflow, other features were included. These features is based both on the requirements stated earlier, as well as influenced from other issue tracking systems on the market. 1.6 Structure The remainder of the thesis is divided into the following parts. Chapter 2 presents the theoretical background for the thesis. Chapter 3 describes the methodology used in the thesis. Chapter 4 presents the results and the new approach for a issue tracking system, including the implemented workflow in more detail and other implemented features. Chapter 5 is a discussion regarding the new approach. Chapter 6 concludes the thesis. 1.7 Limitations For the purpose of issue tracking, user support and other functionalities there are many third-party applications to increase the extent of SharePoint. In order to facilitate implementation on customer premise in the future as well as ongoing maintenance and updates, only out-of-the-box features will be used in this thesis. By refraining from using third-party applications and only utilize out-of-the-box features no further installations, besides the already installed SharePoint environment, have to be performed when implementing the solution in the future. As the purpose of this thesis is to evaluate customer support in SharePoint Online, only this variant of SharePoint will be investigated.
11 2 Theoretical background In this chapter the theory behind the thesis will be presented. First, there is some general information regarding customer support. Second, the theory and principles behind Customer Relationship Management are explained. Then follows an introduction to workflow and trouble tickets. 2.1 Customer support Support is a highly important component for organizations when dealing with customers. Most companies have some kind of user support, but they still have issues in satisfying the needs of the customer in user support . The user support is the face of the organization towards the customer, which is why this element plays such an important role in the business operation and in the customer relationship. The support department should be the only interface in which the customer and supplier communicates, hence if the customer have a problem with confidence towards the user support they might also have weak trust towards the whole IT-department . A good user support have the ability to understand the needs of the customer and give satisfactory feedback that ensures that the customer always are informed and up to date regarding the latest news . The user support is responsible for reporting and documenting issues and problems that the customer addresses. Problems concerning users needing assistance or instructions for applications and guiding new users getting started with the system are also services that user support should cover. Information concerning updates, scheduled maintenance and status on issues is also relevant information that user support should be providing . As mentioned above, the user support should be the customer s only channel for IT-related issues, a Single Point Of Contact (SPOC). If there only is one telephone 5
12 number, address or site to go to, it facilitates the process for the customer to contact user support . Contrary to have several different departments to contact depending on the type of issue where the client has to figure out what department it is and then finding the right contact information. In the case of user support, one central point of communication, both outgoing and incoming, is a convenience not only for the customer but for the supplier as well. SPOC is a step to get away from the informal communication, for example if a client directly contacts an IT-specialist regarding a problem. Such calls prevent the employees from being able to perform their regular assignments as they unable to work undisturbed. In user support you want to document issues that have occurred earlier in order to be able to prevent them from happening again. If the customer directly contacts IT-specialists there is a risk that no documentation will be performed. This in turn complicates the process of follow-ups and getting reliable statistics of user support. Documentation could also be very useful for wsolving similar problem in the future . 2.2 Customer Relationship Management Customer Relationship Management (CRM) is business philosophy with the primary goal to better understand its customer and establish a healthy and longterm relationship between the supplier and their customers. CRM have had an increased importance in recent years when management thinking have changed focus from bringing in new customers to understanding the significance of maintaining existing customers and the need to attain loyalty with these customers . A company s relationship with its customers has been acknowledged as the most valuable asset, especially in today s conditions where there is a high customer turnover, falling brand loyalty, lower margins and profitability. As a result many companies moves to a more customer-centric marketing approach instead of the previous product-centric and brand-centric approach . There is no clear consensus regarding a definition of CRM amongst researches.  suggests that this is due to the formative stages of development that CRM still is in.  provided some quotes from other authors concerning CRM in his report: enterprise approach to understanding and influencing customer behaviour through meaningful communications in order to improve customer acquisition, customer retention, customer loyalty, and customer profitability. the strategic use of information, processes, technology, and people to manage the customer s relationship with your company (Marketing, Sales, Services, and Support) across the whole customer life cycle. a comprehensive strategy and process of acquiring, retaining, and partnering with selective customers to create superior value for the company and the customer. It involves the integration of marketing, sales, customer service, and the supply chain functions of the organization
13 to achieve greater efficiencies and effectiveness in delivering customer value. The common factor of these definitions is to point out the importance of considering CRM as a complete process of recruiting and maintaining valuable customers to boost the profit of the customer to the organization  CRM levels As CRM is a philosophy that concerns the whole organization, the benefits from CRM can be split into three different levels : Operational level The benefits obtained from the operational level include daily functions of the organization. One of these is improved customer data management. In organizations, customer data may be spread amongst many different departments and also in different formats. CRM strives to centralize all the information from all departments into one system. This will allow employees to get a complete view of the customers, which is beneficial when managing customer relationships. With a central system of information, time can be reduced to access customer information, which is of great importance for customer service. Other benefits from operational levels are improved productivity and process management . Tactical level The tactical level includes functions concerning marketing and tactical strategies. By analyzing customer data, companies can adapt their marketing strategies and profiling a certain kind of customer based on their needs and preferences. Tactical moves such as development of new products in order appeal to new customers and increase the customer base can be influenced by identifications of trends in customer data . Strategic level Benefits at the strategic level regard the long-term visions and goals in the organization. One of these is customer satisfaction. Increased customer satisfaction can increase loyalty amongst customers and increased customer retention. Providing satisfactory customer service and support will also increase the value perception of the company with the customers. Improved business performance can also be a result from CRM at a strategic level. CRM can bring a competitive edge by providing products and services tailored to suit the customers  Information technology and CRM Information technology (IT) has highly affected CRM and plays a huge role in CRM practices and can be used to support and integrate CRM into an organization
14 . Through the use of technology CRM made it possible for a more personalized customer attention, especially with the possibilities of the web. With customer service on the web, companies can answer customers inquires, providing order status and place orders online. With the use of databases organizations can store and analyze customer data to recognize patterns and evaluate the profitability of existing customers. Databases Databases are a central element in CRM. In the databases organizations can store information about their customers, such as previous communication, issues or problems and purchases. This information can facilitate future communication and makes problem solving more efficient and effective. When new information about the customer emerges, this will be added to the database and making it accessible for the employees . It is important that this mindset is spread among employees all over the organization and also willing to share information about the customers to be able to take fully advantage of the database. A system that is easy to use is essential in this scenario. If the system is too complicated the employees will deviate from the system and thus risk losing valuable information. It is also of great importance that the database is easily accessible for the employees to help build good customer relations . By storing all of the interactions, good or bad, with customers it opens up the possibility to individualize the relationship after the customers needs. The database also enables organizations to remember certain customer preferences which can be used in future offers, it also reduces the need for the customers to repeat themselves regarding their preferences . Databases allows for analyzing of customer profitability. Acquiring and keeping the profitable customers is one of the essential aspects in CRM and also the key to success in any business. By analyzing the data companies will know which customers are profitable, which ones who might never become profitable and the ones that can be profitable in the future . Customer service and support Customer service and support is one of the fundamental elements in CRM. It is becoming more and more acknowledged by companies that satisfying customer support brings several advantages when it comes to customer relations. One way IT have affected CRM is the help desk to manage customer support and service. Organizations can have thousands of inquiries every day by establishing a help desk, which allows experts to take calls, s and chat with customer regarding their problems. To maintain satisfied customers, supplier of course have to deliver a satisfactory product, but to maintain loyal customers and make them come back for more, businesses have to sustain a relationship with the customer over a longer term. Strong relationships with customers is built and enhanced upon interactions with the customers . By improving the processes where the companies have interactions
15 Most likely to benefit Least likely to benefit High accumulation of customer data Little contact with customers Differentiated needs Identical customer needs Close customer relationships High customer turnover Table 2.1: Characteristics affecting the likeliness to benefit from applying CRM  with the customer there are opportunities to attain a better customer relationship. One of these interactions is customer service and support. By having an efficient customer service the supplier enhances their reputation for taking care of its customers and thereby builds a relationship bonding . Customers that are satisfied with the product or service are more likely to come back for more. When a customer contacts the customer service the support should have all the relevant information regarding the customer available. Information such as what service or product they have, previous issues and problems the customer has encountered, which will allow for an efficient and effective support process  Customers in CRM As mentioned above, customers have been recognized as the most valuable asset for companies. Since recruiting new customer is significantly more expensive than maintaining existing customers, retention and loyalty among customers have a huge importance in many organizations today. All though, this does not imply that companies want to keep all of their customers. With a successfully implemented CRM system, organizations can gain insight regarding the profitability with certain customers by selectively initiating, building and maintaining appropriate relationships with them. In CRM customers can be divided into three categories : Most valuable customers Secondary customers Least valuable customers Where the most valuable customers are the most profitable customers, the secondary customer might be more profitable than what they currently are. The least valuable customers costs more for the company than what they generates for the company, hence the partnership with these customers should preferably be ended . Depending the initial relation between customers and supplier CRM might not have the same effect for every company.  refers to Bose (2002) that argues that some companies may gain more from CRM than others. Table 2.1 presents some characteristics of companies that can influence the impact of CRM in the organization.
16 2.2.4 Benefits of CRM The concept of CRM is to get better understanding and insight into the behavior of customers and figure out the value of those customers. With CRM and with the help from IT, businesses can identify and target customers that are most profitable. By knowing what type of customers are more profitable, organizations can customize marketing campaigns with clear goals and objectives. CRM also enables companies to form individualized relationship towards customers. This is especially important for smaller companies with a small-scale customer base. CRM processes can provide employees with information regarding customers that enables for more efficient and effective customer support . 2.3 Incident Management Process When an incident occurs this means that a service is unavailable or having limited functionality. The goal of the incident management is to as soon as possible get the service available and to perform as usual again to minimize the impact on the client s day-to-day work and their core business. Examples of incidents could be that a user cannot send or receive s or that the search function on the corporate web page does not work. As the goal of the incident management is to restore the service as soon as possible, it is not unusual that the solution is temporary just to circumvent the incident. A classic example of a solution for an incident could be to restart the server providing the service. These kinds of solutions are accepted as long as the issue is classified as an incident. All though the incident could require some more investigation, the incident then becomes a case for the problem management process . An efficient incident management process will reduce the downtime for services and lower the effect of the incident on the core business of the customer. One way to get an efficient incident management process is to thoroughly document their occurrence. Documentation can be used for priority classification, detect trends and for future help in the problem management process . For every incident that is reported a new case should always be registered. In a case certain information is provided to help during the incident management process. However, fields such as good to know do not contribute much to the incident. Either these fields will be left blank because they are not sufficiently defined or information written down will never be read, which means that only time were wasted filling it. Some information will be filled as the case is created and some information will be supplemented throughout the process. Information may be added either manually or automatically. According to  examples of relevant information for a case could be: Case number, date and time Category and type Description, status and owner Priority
17 Description for solution Amount of time it took to solve the incident Informing the users During an incident it is also important to provide the users with current information. They do not need any detailed specification on the issue, but enough information to know what services that are affected by the incident. An estimation of when the problem should be resolved and when and where next update about the issue will take place is also relevant information to provide to the user. The language used should be user friendly and not too technical advanced . 2.4 Problem Management Process The main purpose of problem management is to resolve the underlying cause for incidents. This will lower the risk of the same incident from happening again which would cause unnecessary down time. By preventing same incidents from recurring resources can be used to improve software by focusing on forestalling future incidents from happening. The problem management process will benefit IT-services by contributing to higher reliability, availability and quality . The problem management process is responsible for solving the incident. The first step of the process could be a temporary solution just to get the service up and running again. A diagnosis of the incident will then be conducted to determine what the underlying reason for the issue is . The problem management is heavily dependent on the incident management process. This information that will determine if incidents will be solved by the problem management process. Every incident cannot be solved by the problem management process and there have to be policies and criteria that determine if an incident will be further investigated in the problem management process. Criteria could for example be that an incident that was recently solved have occurred again after a short period of time, or that an incident has taken too long to resolve or that an incident has proven to be a lot more complex than expected. During the problem management, information provided from incidents will be the primary data for solving the problem . The incident will then be analyzed in order to identify what the underlying reason for the issue is. If a problem is found a new case will be registered. A case will contain information like a case number, priority and a category. Any earlier incidents associated with the problem will be coupled with the case. When the root of the problem is identified, a solution will be developed and finally implemented. As the solution is verified the case will be closed. After this process it is important to properly document the incident and how it was solved. This is done to be able to efficiently solve related problems in the future and shorten the life cycle of the issue .
18 2.5 Knowledge base To be able to pass down information and knowledge into a knowledge base within an organization is essential for good user support and is commonly used as a complement for user support. This principle will allow for less dependency on certain individuals and a faster incident management . With solid documentation of previous incidents and how these were solved helps to cut a great deal of time if the same, or related, issue would occur again. It also reduces the risk of having to contact the customer again for further information. The problem is to provide the knowledge base with useful information and keeping it up-to-date. This takes time and dedication and is something that should be deeply integrated in the organizations culture when it comes to user support. Unfortunately, descriptions like ok and fixed are frequent used and are of little help for latter solving. Author  emphasizes the importance that the knowledge base have to be easy to create, maintain and update in order to fully take advantage of the knowledge base. Consistency, usability and validity are crucial in this case. By looking at the history of previous cases it is possible to see trends and draw conclusions and one important element for this is the closing tags of the cases. The closing tag indicates what the root of the problem was. Together with a robust description of the issue and its solution, this could facilitate the process of identifying the cause of future problems . 2.6 Workflow The Workflow Management Coalition has defined workflow as an automation of a business process where documents, information or tasks are passed through a number of participants. Each participant in the process performs some sort of action according to predefined set of procedural rules . As a business process runs from request to final delivery, many intermediate steps have to be performed and coordinated before the product or service is ready for delivery. As projects grows in size and several individuals are involved in the project the complexity of the process increases which quickly makes it difficult and time consuming to coordinate . A workflow system will help with a lot of the coordination of work between employees, which will allow them to focus on their main task instead . This is done by automating parts of the process so that employees receives all the information he or she needs in their task list. A workflow management system will help with making sure that the right person is doing the right job at the right time with the right information Types of workflow There are mainly two different kinds of workflows; sequential and state machine workflow .
19 Sequential Workflow In a sequential workflow one step in the process is executed sequentially one after another. Everything in the workflow moves in a one-way direction, the process always progresses forward and never goes back to previous steps. Although sequential workflows allows for simple branching and parallel logic flows, thus the exact order of execution can vary . State Machine Workflow A state machine workflow represents a set of states, transitions and actions that executes in no particular order. There is a state that is defined as start state, but the following states will be determined by the logic of the completed state and can be caused by events. There can also be a final state that concludes the end of the workflow, but is optional. State machine workflow allows for jumping between stages as many times as required . Sequential workflows can be used when there only is one way to complete a task. A state machine workflow is more flexible and the path of the process is not predefined, instead the path depends on events that occur during the workflow, such as human interactions  When to use workflows Workflows are widely used within organizations where humans uses software to perform a process, for example insurance companies, banks for mortgages. By automating the interactions for involved people in a process can help increasing the efficiency and lower the probability of errors. Workflows are beneficial in many different variations where automation can support humans in their work . For example: Approval: In processes where human approval is needed from several individuals. This may be a wide variety of things that needs approval, but essentially participants reviews the information, possibly add information, then states approval or rejection. Coordinating group efforts: Many processes require people to work together in an organized way, for example translating a document into several languages. By having an automated workflow with defined steps the whole process can make it more efficient and the outcome can be more predictable. Issue tracking: Whether an organization is software oriented or not, many business processes produces lists of issues that needs to be taken care of. Automated workflows can facilitate the process resolving these issues by maintaining lists, tracking the status, coordinate involved people, assign issues to individuals who have the capability of solving them.
20 2.6.3 Case based One of the central characteristics of a workflow process is that they are case-based . Which means that every part of work is completed for a specific case. This could for example be an order, customer complaint or tax declaration. This is why these types of matters are popular examples of workflow processes. Unlike processes such as assembly of bicycles, where some stages of assembling may be dependent of the type of bike and thus not case based and hence not a workflow process . The main purpose of workflow management is to administer cases as efficiently and effectively as possible. The workflow process is developed to handle cases that are similar to each other. The different steps in a workflow process are defined in the workflow process definition. The definition specifies what steps are included in the process and in what order tasks must be performed, what conditions that have to be fulfilled before entering the next step. This definition may also be called flow diagram, workflow schema or procedure. The workflow process definition describes with standard routing elements how cases travels throughout the workflow, this could be sequential, alternative, parallel, and iterative routing . 2.7 Trouble tickets Many help desks and user support departments uses Trouble Tickets Systems (TTS) in their work on a day-to-day basis. TTS is a tool to track trouble tickets and include functions such as recording, management of tickets, escalation, and allows for analyzing of incoming calls. These tools are of great assistance for handling calls and help streamline the resolution process. The trouble tickets themselves contains information regarding a problem, which can be raised both internally and externally, by a customer for instance . A TTS receives incoming inquiries that occur in a system. These inquiries can both the raised automatically by a management system or by an individual who experiences some problems with the system. As the ticket is received in the TTS, employees will begin the work to solve the reported issue. The system will assist with the coordination of employees who needs to be involved in the resolution. In a RFC regarding trouble tickets, the author compares trouble tickets with hospital charts that help coordinating the work of several people who may need to work the issue . According to  the main functions of a trouble ticket system include: Logging fault tickets; Tracking progress of fault tickets; Updating fault tickets status; Logging fault resolution/diagnostics and resolution timescale; Alerting operations of SLAs that are about to be breached;
21 SLA reporting on fault resolution and expectations; As mentioned above, trouble ticket is a common tool for problem resolution and there are a lot of different TTSs out there. These systems are usually developed for a specialized environment and customized after specific context related needs, such as project development, host administration and helpdesk  Structure of the trouble tickets According to , the trouble-ticket is organized in two major fields; the header and the body. The header includes fixed fields of information that is common for all tickets. And the body, also called description, which is used to describe the problem. The header contains information such as title, identifier, priority, state and category. Since these fields help to filter and sort trouble-tickets they should not be able to alter . The body contains information such as who is responsible for the ticket, which should be the manager responsible for the category in question. The manager is responsible for managing the information in the ticket and to assign the correct staff to solve the problem. The staff that will be assigned to solve the problem is also information that should be included in the trouble-ticket. The resolution itself is a free process since this could be a wide variation of procedures. The ticket should have a state attribute, which describes the situation that the ticket is in. Examples of different stats could be open, suspended, blocked, solved or archived. A ticket is also assigned a priority. A priority will enable users to easily identify high-priority issues, which is usable in populated lists. This priority is also affiliated with a timer. If a ticket remains unchanged for a specified amount of time a notification will be sent to the person or persons responsible for the ticket  Features in TTS  lists some features that should be included in the fault management process. One was the to provide the user with information regarding planned engineering works and current open faults, with estimated fault resolution time, to avoid opening new faults tickets that are already being resolved by another process that have the same fault condition. This will also ensure the customer/end user that the problem are noted and about to be dealt with. Time estimation might be difficult guess but should be provided as much as possible if known.  suggested a set of severity levels. Of course these might be individual/specified to specific organization and their SLAs. But here is an example of severity categories: Category 1 total loss of service (fault resolution of 5 hours); Category 2 partial loss of service (fault resolution of 10 hours); Category 3 degradation of service (service to be restored within 24 hours);
22 Category 4 minor fault, not affecting service (corrective action to be applied within three working days); As we are dealing with customers, it is also important to provide good customer service. One way of obtaining good customer relations is to maintain rich communication with the customers. Therefore regular updates regarding faults are essential . Several points mentioned by the author are related to providing the customer with information and updates during the resolving process. This could be sending confirmation that the ticket is received, time estimations when the problem might be resolved, additional information regarding the issue, the possibility for the customers to view fault ticket status. One attribute that can help is the status of the fault. Fault status and points should be predefined and be updated throughout the course of fault management process. All the status changes and updates should be provided with date and time stamps . There should be a procedure that handles fault tickets that are about to breach time limits. If a fault hasn t been updated during specific time, specified in the SLA, a notification should be sent to appropriate persons regarding this. This functionality will reduce the risk of tickets falling through the cracks and remind responsible individuals that something has to be done .
23 3 Method The following chapter will describe the methodology of this thesis, including customer interviews, workshop and the tools used to implement the system. 3.1 Customer interviews To get a deeper insight in how the system is used and perceived a number of semiinstructed interviews were conducted with some of HOW Solutions customers. Semi-structured interviews allow discretion on the number and order of predefined questions posed to the participant. Semi-structured includes open-ended question as well as closed-ended questions. Unlike structured interviews where an interviewer follows a detailed script of questions with few opportunities for asking of-script questions that may emerge during the interview . In this thesis, semi-structured interviews were used. The reason for this is the fact that semi-structured interviews allows to in an efficient way gather information about an important area and at the same time gives the opportunity to explore new issues or topics as they may arise during the interview . One of the strengths of semi-structured interviews is that it may uncover issues that was previously unknown. According to  are some of the general goals with semi-structured interviews is to understand how a process or function works, understanding how particular groups in an organization work together and determining what is efficient and inefficient about particular workflows. These goals, of course, shapes what types of questions to ask during a semi-structured interview. Semi-structured interview is also applicable when some knowledge about the topic is known but more information and details is necessary . In this case, some knowledge about the system is acquired on premise at HOW Solution, such as a rough description of the process, but further details from the end-user is significant for the research, which is acquired through interviews. 17
24 To get the most out from a semi-structured interview the length of the interview is important to consider. If the interview is planned to take too long this may result in qualified people rejecting the request for an interview. On the other hand, if the interview is too short, there is a risk of not extracting enough qualified data and/or cause the interview not to able to go deep enough to cover all the relevant topics. Semi-structured interviews are recommended to span between 30 minutes to 2 hours . In this thesis the length of the interviews are planned to take around 30 minutes to one hour just to minimize the risk of qualified people declining the interview since the number of customers around the area is limited. When preparing the interview questions it is important to know what kind of information the interviewee can provide, especially regarding design questions and how users remember certain events. Questions that require the interviewee to remember how they used a certain service or website have great chance of giving a skew picture of their experience since the human memory is fallible . It is not uncommon that the interviewee makes up stories to justify their experience. A topic that involves new designs or technology only with a description of it, without a prototype, is also not recommended and should be avoided. Users are pragmatic and concrete and it is difficult to anticipate how they will react to a new service or technology solely on a description. Questions that can give useful information are the ones that answers general attitudes among users and how they view a particular problem. Valuable information could also be an incident or a problem that had occurred, i.e. when the system did not perform as the user expected. The same goes for when something that went notably well. Cases when the system performed as intended does not provide as much information and in the cases of the unusual events there is a greater chance that user have a more memorable details . In this study five interviews were held from four different customers of HOW Solutions. Four of the interviews where conducted face-to-face and one interview where conducted by telephone. The persons interviewed had previous experience with the system and was either developers or responsible for the communication between them and HOW Solutions. I was not in before hand aware of any experienced difficulties with the current issue tracking system. Therefore I wanted to keep the questions as one open as possible in order to find details about the issues they were experiencing. Depending on their answer, the follow up questions may vary from interview to interview. The main focus of the interviews was to obtain details about how the customer experienced the current approach regarding issues and the communication with HOW Solutions. Another point of interest was the overall functionality in the collaboration room, if the customer felt that it was sufficient and if they had any requests. 3.2 Workshop A workshop is session where a group of participants work towards a common goal. During the workshop the participants brainstorm and share ideas and new concepts
25 . Some of the ground rules for workshops according to Ellen Gottensdiener are: Share all relevant information, everyone s input is equally valued, cut to the chase, no idea is bad, be open to new concepts and ideas and do not shoot down ideas . The members of the group are individuals with different skills, knowledge and experience. The point of the workshop is to take advantage of the participant s different areas of expertise. A workshop should not include too many people in order to be productive. To keep the number of participants down to a minimum only one representative from each relevant department is required. A rule of thumb is as many as necessary, as few as possible . Workshops can be used for many different purposes; set up specifications for a project, define a product s vision or to specify requirements of a project in varying detail . To conduct a successful workshop it is important that the participants are aware of and have agreed to the workshop s purpose before the workshop. It is also important to have a process for decision making in order to reach a closure for the workshop . With the result from the customer interviews a workshop were organized together with employees at HOW Solution. The purpose of the workshop was to, along with the summarized observations create a prototype process for issue tracking. The workshop was also conducted in order to get insight in how the developers whished that the processes worked. For the workshop I held, I briefly explained to the participants what the purpose of the workshop was, what I wanted to achieve, and what insights I wanted to gain. Employees that where asked to participate in the workshop were developers who had a lot of customer interaction and had insight in how the current process works. This way we could discuss parts of the process that could be improved and new stages that could be implemented in the new approach. During the workshop we decided to use SharePoint workflow to implement the new process for issue tracking management. The proposed workflow will be described in chapter Software One of the goals for this thesis was to develop a issue tracking system for Share- Point Online. Therefore development has only been conducted on this variant of SharePoint SharePoint Online The new collaboration room was implemented in SharePoint Online. SharePoint Online is a variant of SharePoint where the user does not have to manage the infrastructure of SharePoint themselves, instead SharePoint Online is located in the cloud, hosted by Microsoft s data center. Since the management of the servers are outsourced, the capabilities of SharePoint Online is somewhat limited compared to other variants of SharePoint.
26 3.3.2 SharePoint Designer For the development of the new collaboration room, SharePoint Designer 2013 was used. SharePoint Designer is a tool to create and modify SharePoint sites, workflows and web pages. When designing workflows, SharePoint Designer provides a text-based and visual designer, see figure 3.1. Figure 3.1: Structure of stages and transition in a workflow in SharePoint Designer SharePoint Workflow Microsoft describes workflows in SharePoint as preprogrammed mini-applications. These applications helps streamlining and automate a broad spectrum of business processes. Workflows are designed to help organizations to save time and effort, increase consistency and efficiency to tasks that are performed on a regular basis . During a process that is run manually, a lot of unnecessary time may be spent on checking up, sending reminders to involved people, documents going back and forth and so on. This kind of format may also result in avoidable interruptions that slower the whole process. With workflows in SharePoint many of these steps can be automated. By having predefined steps, participants does not have to keeping track of what is next in the process, reminders and s can be sent automatically, and notifications can be sent if a there is an interruption in the process. Workflows can be integrated and used in many different elements of SharePoint, such as lists, list items, libraries, to facilitate the management of the life cycle of these items . Workflows can either be initiated when a user activates it or automatically when an event occurs, for example when an item is added to a list. SharePoint supports workflows as a out of the box feature (OOB). These workflows allow developers to design business processes with many possibilities for customizations. Different variants of SharePoint have different workflow support. SharePoint 2013 supports both sequential and state machine workflows. But state machine workflows require that you develop the code in Visual Studio, to run this on a SharePoint site the code have to be deployed as a farm solution. As this
27 is not available on a SharePoint 365, only sequential workflows are available on SharePoint 365. If there is a need for more flexibility of built-in workflows, SharePoint Designer lets you customize these workflows. It is also possible to create new workflows from scratch to make them more suitable for the organization . SharePoint Designer allows developers to divide the workflow into different stages with 2013 workflows (see 3.1). Each step contains a series of sequential actions to be performed. At the end of each stage the workflow moves to another stage or terminates the workflow. With conditions we can decide to move to either stage A or stage B, including previous stages, depending on variables in the workflow.
29 4Result In this chapter the results of the thesis will be presented. First, a description of the observations made regarding current situation. Secondly the results from the interviews and workshop will be presented. The remainder of the chapter will present the new implemented process for issue tracking. 4.1 Current problem Every customer at HOW Solutions is assigned a contact person. It is not unusual that the contact person manage several customers at the same time. The contact person is the customers way of getting in touch with HOW Solutions regarding different kinds of questions. What the questions are concerning depend on the service level agreement (SLA). Usually the errands could be inquires to add pictures to their web site, change requests, issues they are experiencing, or requests for new features. Some customers have their own support department or third party actor, which is their first point of contact for these kinds of errands. If the internal IT department cannot solve the issue, they in turn will contact HOW Solutions. Other customer goes straight to HOW Solutions with their inquiries. On the customer premise, it is usually some designated employees who are assigned to be responsible for the contact with HOW Solutions. If some other employee detects an issue, fault or requests a new functionality he or she notifies the responsible employee who in turn creates a ticket in the management system or contacts HOW Solution through other mediums. This person is also responsible for testing and approval during the whole resolution process. To report a new issue, the customer registers a new issue in the collaboration room, which will be explained After the users submits the ticket, the contact person at HOW Solutions can see the ticket in the list on the web page. Except from the new tag on the new item in the list no other notifications are sent when 23
30 a user submits a ticket and will first be noticed by people at HOW Solutions as they log on to the external web page. When the ticket is noticed at HOW Solutions, employees can begin working on the issue. The developer sets the status of the issue to in progress. When the issue has been solved the changes are implemented in a test environment. The consultant at HOW Solutions changes the status and assigns the ticket to the customer. Then the customer have to approve that the changes are correct in the test environment, if the changes meets the customer s request, the customer approves it and assigns the ticket to HOW Solutions again. The changes are then implemented in to production, before the ticket is marked as solved and closed, the customer have to approve that the changes works properly in the production environment as well. However, if the ticket does not meet the customer s request, there are no defined procedures and the contact between HOW Solutions and the customer are carried out over other mediums, such as mail or phone until the issue have been solved. Each customer to HOW Solutions gets a dedicated external web page, a collaboration room, which is built on SharePoint. It contains a standard issue tracking web part, which is a default template included in SharePoint. Each time a customer wants to report an issue to HOW Solutions, they have to log on to an external web page, which requires an additional account, and fill out the form. In the standard SharePoint issue tracking web part a ticket consists of the following fields (some of these are provided by consultants at HOW Solutions or are filled out during the course of the ticket lifecycle): Title Assigned To Issue Status Priority Description Category Related Issues Comments Due Date Invoice Information Estimated Time In addition to these fields, user can also add attachments to the ticket, such as images or other documents. The collaboration room is a SharePoint 2007 site that HOW Solutions uses to communicates with their customers. The main part of the site is a list where the customers can report inquires. The list is an Issue tracking list which is a standard list template included in SharePoint. This list includes some basic features, such as a related issues field, but is otherwise very limited and essentially just a simple list. The included Issue Tracking list in SharePoint contains some basic features, such as a related issues field where the user can relate previous issues to the issue they are currently reporting, but is otherwise very limited and essentially just a simple list. As mentioned above this is the type of list that HOW Solutions currently are using for their issue tracking and customer management. As mentioned in the background chapter many trouble ticket systems are specialized and
31 Figure 4.1: Form to report new issues in SharePoint. customized for the particular environment and requirements to fit the particular organization. Even though there exist possibilities to modify lists, such as workflows and customization of list properties, HOW Solutions still uses a list with little or no modifications Customer interviews In the following section the result from the interviews will be presented. During the interviews it became clear that the customers were little interested in the underlying process for resolving issues. Instead the customers were more interested in functionality of the report form, for example easier way for them to use the report system and describe their issues and accessibility.
32 Description field One question during the interviews was if the interviewee felt that they could properly describe the problem to the developers. The possibilities that the users have today are to describe the problem with text in a regular text field and add eventual attachments, such as screenshots or documents. Many interviewees felt that there are some shortcomings in the current approach regarding the description. Adding a screenshot of a problem on their site is a common method for the customers to describe their problem, but everyone who participated in the interviews thought that the attachment process for screenshot was too cumbersome. To attach a screenshot, the user first have to take the screenshot, open a program that can save screenshots, i.e. Microsoft Word or Microsoft Paint, paste the image, save the file, and finally attach the saved image file to the ticket form. This can be compared to the process of adding screenshots to Microsoft Outlook where the user take a screenshot and then paste the image directly in the mail client. The result of this tedious process led to that some users ignored to attach images and instead described the problem entirely with text or reported the issue by with the attachments. Some customers chose to call to HOW Solutions instead, since it was easier to make themselves clear and to minimize the risk of misinterpretations. Assignment When the customers report a new issue they have to assign a person in the creation form. The users always entered their contact person at HOW Solutions. Some customers expressed their concern regarding this, since they do not know if the assigned person is available or not, or how long it will take before someone will take care of their issue. Some customers requested the functionality to assign groups instead of a certain person. This have led to that customers now only reports errands that not are considered acute, such as changing colors on a button on their web page. Urgent matters are instead taken by telephone or instead where they can have a more direct contact with HOW Solutions. Some customers admitted that they are increasingly using other mediums because of the varying response times that the collaboration room entails and the lack of direct contact with HOW Solutions. Comments The comment field is supposed to be used during the course of the ticket and can be used for various purposes. In this field the contact person at HOW Solutions can directly respond to the customers query, write an update to the customer on the current state of the issue, the customer could add additional information and so on. But most respondents in the interview felt that this field was not regularly used. Some respondents said this was because there was due to the tedious process of either adding or viewing the ticket information since they had to log in to an
33 external web page with an additional account. Other said it was easier to just ask questions regarding a ticket through mail instead. Most respondents admitted that they rarely visited the collaboration room just to see if there was any news regarding their issue. Since most users, both at HOW Solutions and customers, did not use any kind of notifications, they were never informed about changes in the tickets, thus resulted in that any updates mostly went unnoticed. Notifications One of the significant issues that arose during the interviews was the problem with the lack of notifications. Some interviewees felt that this was the main reason for why they rarely visited the collaboration room. Customers expressed that they wanted to be notified when events had taken place or new information was provided concerning the issue. The customers also pointed out that there existed a function for notifications within SharePoint but they did not use it since they would be notified with events that did not concern them which made it unbearable. Minor updates and questions Customers felt that there were too few minor updates concerning the errands. Sometimes they felt left out on what was going on, and they did not even know if someone was working with the issue. One interviewee described a previous scenario where they reported an errand, then nothing happened for about two weeks then suddenly the issue were solved by HOW Solutions. During this period almost no information were communicated concerning the issue. Other interviewees also mentioned that they would like better functionality to ask questions during the course of the solution of an errand and that the comments field was not sufficient for this and the troublesome process to access the collaboration room did not help the situation. Today, questions regarding an issue are carried out over other mediums instead. Mediums One of the problems with the current process is that errands and information regarding errands are often spread out over several mediums. Issues that once been reported in the system might not ever be touched again due to that the rest of the communication are carried out in other ways, such as meetings, phone calls and s. One reason is that neither the customers nor the suppliers visit the collaboration room very often. Therefore, the reliability in the system is low and no acute errands are taken through the collaboration room since the users feel like the might never be answered. In the acute cases the customer rather makes a phone call or take it over since these are read at a much higher frequency and also notifies the users when an is received. The interviewed customers have admitted to not look at the external web page very often. When they visit the collaboration room it is because they either received an from HOW Solutions that implies that they should or when
34 they report a new issue, and they see that a previous issue have been answered. If nothing have happened in a while they might also look at the external web page or either mail their contact person at HOW Solution right away instead. Communication All of the interviewed customers were satisfied with the communication in general and the relationship they have with HOW Solutions, this is also one of the selling points for HOW Solutions; that they have a close and personal relation towards their customers. The problem that the customers experienced was the response times regarding issues they posted in the collaboration room, especially during the solution process where they often felt left out and few updates were posted concerning the issue. In these cases some customers would contact HOW Solutions questioning if someone is working with the issue or how long it will be until the issue is resolved. 4.2 Result from workshop In the following section the proposed workflow that were brainstormed during the workshop are presented Initial stage The customer reports a new ticket as usual. When the ticket is created, the workflow should automatically start. In the first step, when the ticket is received, a notification should be sent to the group or person that is assigned to the ticket (either automatically by a default value or specified by the issuer). The notification should contain the description of the ticket, such as who issued the ticket, a link to the ticket, and what needs to be done next in the process Answer or continue In the next step the assigned person (HOW Solutions employee) have to decide if the issue can be answered directly and does not take much effort to answer or implement, such as more simple questions that occur occasionally, or if the issue needs considerable work to complete. If answered directly, HOW can fill in a form associated with a task. As they press send, the ticket should be assigned to the customer again. If the issue needs considerable work, a time estimation have to be done before they can begin working on the issue. This stage should therefore have two alternative outcomes: Answered directly If the question can be answered directly the customer have to review the answer. If they are happy with the answer the ticket will be archived and closed. If the customer are not satisfied with the answer they can comment the ticket and the ticket will go back to the first stage, reported, and be assigned to HOW again for further investigation.
35 Time estimation needed If the ticket need considerable amount of work, HOW will need to estimate the required time for the issue. The ticket should then go to the status Time estimation needed, the ticket should still be assigned to HOW. When HOW fills out the time estimation-form, the ticket will be sent to the customer Continue or discard After HOW Solutions estimated the time for the issue, the customer has to decide if they want to continue with the issue or not. If they consider it to costly they can choose not to go any further and the ticket will be archived to another list. The ticket should be archived with all the information provided in the ticket but no one should be assigned to the ticket and the workflow should be ended. If the customer wants to report the same issue later on, the information will still be there and they should be able to report it again. If they choose to continue with the ticket, HOW will be assigned the ticket again, and the ticket will go into a stage where it waits to be worked on. During all cases both parties should be informed about the relevant events the ticket goes through Under investigation After the customer accepted the time estimation, HOW can begin to solve the issue. To do this they should have to accept the ticket again. When this is done, a notification will be sent to the customer, keeping them informed about the events regarding the ticket. This stage is also used to point out when HOW Solutions begins working on the issue. This will be used to calculate how long they have been working on it Need feedback During investigation of the issue, the developer might need more information or description about the issue. In that case they can assign the ticket to the customer. The customer will be informed about this in an , containing the issue details, a short description from the developer and a link to the item. The customer should be able to either update the information in the ticket item in the collaboration room or send an directly to the developer. There should also exist an alternative to fill out a simple automated form with the required information. After the customer have provided the information, the ticket should automatically be assigned to HOW Solutions again, and HOW will be notified about this. This stage may be repeated several times, which the workflow has to support Solved When HOW Solutions have solved the issue, they will set the state to Solved. The time will be noted and the time taken for the issue will be calculated (this
36 number will only be a rough estimate of how long it took since employees might not work on the issue constantly until it is solved) Ready for testing - test environment The only possible transition from the stage Solved should be to Ready for testing (test environment). During this stage HOW Solutions will implement the changes to a test environment, here the changes will be tested in an isolated environment. The customer should also have to confirm that the new implementations work as they requested. An will be sent to the customer provided with a short description informing them that they have to confirm changes in a test environment, including a link to the changes and to a acceptance form. If the changes are confirmed by the customer, the ticket should be assigned to HOW Solution which in turn will implement the solution to production for further testing. If the customer rejects the solution the ticket should be assigned to HOW Solution and go to stage Evaluate failure cause Evaluate failure cause The ticket should be able come to this stage from the test stages, both from test or production environment. In this stage HOW Solutions have to evaluate if the reason the customer rejected the ticket was justifiable. From previous experience there might have been a misunderstanding with the requirement specification or some other misinterpretation along the process. Therefore it is reasonable to confirm the failure cause, to evaluate what went wrong and why the solution failed. If HOW Solutions decide that the failure cause is either unreasonable or only need minor fixes to satisfy the customers needs, they will implement the changes or provide a comment for the customer and the ticket will be moved to Ready for testing again. If HOW Solutions on the other hand estimates that the issue need considerable modifications they can accept the fail cause and the ticket should be moved back to the stage Under investigation again Deliver to production This is an intermediate stage between the two testing procedures and during this stage there are no decisions to be made. When this stage is done HOW Solutions will have implemented the changes to the production environment, and the ticket will go further testing in Ready for testing - production environment Ready for testing - production environment This stage is basically the same as in the test environment stage, except in this stage the changes are implemented in to production by HOW Solutions and waiting for approval from the customer. If the implementation is accepted, the ticket should be marked as Approved and go to stage Case closed and archived. The
37 same conditions apply regarding rejection as in test environment, i.e. the ticket will go the stage Evaluate failure cause Case closed and archived When the process is finished the ticket should be moved to another list to be archived. Tickets that have been answered, either in the beginning of the ticket lifecycle or have gone through the whole process should be stored here. During this stage the ticket should be tagged with [Solved] and remove any assigned persons or groups. All information about the description and solution should be kept in the ticket for future problem solving and references. By separating solved tickets from the main list it will easier to get a clear overview of the current situation of active issues and the other list with archived tickets can be used as a knowledge base Special cases Not every ticket might need to go through all the stages in the workflow, for example change requests such as changing the color of a button. In these cases it could be more time consuming just to go through all the stages, including all the acceptance forms, notifications and coordination, to implement the changes. There might also be cases where time estimation or any other stage in the workflow is not necessary. As one of the goals of the new system is to get as many customers as possible to use the system, it is important that it is as flexible, allowing the customers to use it on a variety of issues. To allow the workflow to be flexible, the workflow should be able to skip certain stages if necessary and still work properly. During the workshop we came to the conclusion that the workflow need to be able to handle manually transitions to stages that are not part of the preprogrammed path Other topics During the workshop the description field were also discussed. Employees at HOW Solutions were also aware of the problems with the few alternative options to describe issues that were available for the customers. They also experienced a problem with this since descriptions of issues solely by text is hard to comprehend and also increases the risk of misinterpretations. Customers can attach files such as documents and images but as mentioned above this process is cumbersome compared to other software, and it is not unusual that the user only uses the text field to describe their problem. During the brainstorm, ideas like screen recording and share screen came up. But most realistic idea was the function to live chat, were the customers could chat directly to a developer.
38 4.3 Requirements From the literature studies and observations from interviews, workshop and the current situation, a set of high-level requirements were derived for the new system and its approach. The requirements are also influenced by the goals that were set in the beginning of this thesis. These requirements are provided in Appendix B. 4.4 Implemented workflow The workflow implemented is divided into 9 different stages. During the development the workflow outline from the workshop was mainly used, together with the requirements stated in chapter Ticket partitioning As mentioned in the workflow description, with the new approach tickets will be tagged as they are solved depending on how they were solved. Tickets can either be solved directly when the issue is reported, or go through the whole process. The tickets will automatically be appropriately tagged and stored in the corresponding list. When a new ticket is reported, HOW Solutions firstly investigate the matter. The query that the user reports can either easily be answered by an HOW Solutions employee or referenced to a previous case. The ticket will then get the tag Answered when it is archived. If the ticket has to go through the whole process it will be tagged as Solved and then archived. When a ticket is archived it is moved to another list. If the issue is dealt with it will be moved to the list Solved issues. Items could also be archived in the list Future suggestions, which occurs when the customer does not accept the time estimation. Instead of having one large list, that becomes longer and longer over time with inactive and active issues, we now split the list. By partition the tickets into active and archived issues the list with the current issues will be kept as short as possible. This way new and active issues can avoid getting lost in a long list of outdated issues. But old issues can still be used for future problem solving and as references. The goal with sorting out inactive tickets is to give the users a justified view of the current situation regarding active issues. Another purpose with this approach is to extend the usability of the collaboration room to also work as a knowledge base. Earlier, questions that the user considered easy to answer were carried out over or telephone. If this query was found to be more difficult than expected the issue resulted in a new ticket or the solution of the issue are just carried out directly by an employee at HOW Solutions without the use of the issue tracking system. The problem with this approach is that the query might never be reported in to the issue tracking system because individuals perceive the issue as trivial. Nevertheless this information could be valuable to keep in the system and over time build an extensive knowledge base, also trivial solutions could be referenced to in future queries from customers. By referencing to previously solved issues time and effort can be saved. The result of
39 irregularly behavior of reporting issues is that changes that might have been done to the customers web page (or other solutions they have ordered from the supplier) might not be documented. As changes and updates are carried out over time, these changes might not be considered when for example updating the database that eventually could result in time consuming troubleshooting. Some customer expressed their concerns regarding this during the interviews. Figure 4.2: An overview of reported issues from a customer Notifications The issue with notifications was one of the biggest problems with the earlier approach and all of the interviewees felt that the lack of notifications highly inhibited the usability of the issue tracking system. In SharePoint there exist a notification function that allows users to follow certain parts of the portal. The problem the customer experienced with this feature was that follow means that the user would be notified on any changes and events that occurred on the web part in question. The customers felt that this made the feature almost unusable since many of the notifications did not concern them. However, there is possibilities to customize this feature to some extent but customer felt that it was too complicated and had difficulties to customize it to work as they desired. This drawback resulted in that no one of the interviewed customer used the feature. The lack of notifications resulted in long response times, since new issues and updates only were notified when the users visited the collaboration room. In order to prevent this, and also increase the general use of the system, notifications have been implemented. s will be sent to the concerned individuals when certain events take place. Using s for this purpose is very suitable since most people keep an eye on their somewhat often, and is also a regular means for communication. By utilizing this there is a great chance/opportunity to increase the awareness of ongoing events on the collaboration room. An alternative notification method could also be to use the microfeed function that is included in SharePoint. Although since the collaboration room only is used
40 for issue tracking (the external web site), this might not work be sufficient as a notification method. Since this method require that the users still checks the web page and logs in to the external web actively. This is the same problem as earlier; the users will not log in to the page just to check up on the latest event. If they would log in to watch the feed they could just as easily just to the issue tracking list to check if there were any updates. So no attempt have been made to implement functionality to post events on the micro feed in the new issue tracking system. This implementation could also suffer from the same drawback as the subscribe function that some interviewees mentioned during the interviews, which means that the feature includes every event that occurs on the subscribed page, which, described earlier, is not desired by the users. The users described a notification system that just informs them about events that concerns them. One of the requests from the customer was easier access to the collaboration room. In the s sent out regarding events, a link to the item or the task will be provided in the . Together with ADFS this will result in only one click to the item or task in question for the user. The will also contain a short predefined description of the task or event that occurred. Figure 4.3: Mail notification for Microsoft Outlook. In the current approach, the most acute issues were communicated by or telephone. Due to this, there could arise a minor drawback with notification by . The new notification approach might give the users the perception that every issue is view as acute. The result of this, over time, might be that the most acute errands will not stand out as much as they did earlier since all issues, more or less, are carried out over mail. Structure the title of the so that the priority of the issue is distinctive: [Priority][Issue description][task (what to do)][customer (issuer)] Tasks as a part of the automatic delegation Tasks are used to allow users to provide information to the workflow. In this workflow users can provide information in two different ways: either by accepting or declining certain information, or provide information to other users of the workflow
41 Figure 4.4: Definition for messages with workflow variables. by filling out specific forms. While a task is pending, i.e. waiting for input from users, the workflow is paused and will not transfer to another stage during that time. When the user provides the required information or preform the required task, the workflow will proceed with the process. Tasks where the user needs to accept or decline something will determine what the next stage in the process the workflow will transfer to. For example reviewing test cases, depending on if the customer is satisfied with the solution, the case may either move forward in the process (more testing or case closed) or move backwards to under investigation again. In the case where for example HOW Solutions4 need more information regarding the issue, the customer will need to fill out a form where they can provide information. The information will then be added to the issue as well as a mail with the provided information will be sent to HOW Solutions. Therefore it is not required for the users to always log on to the collaboration room to see the information that the customer provided or when new events take place.
42 Figure 4.5: Task form for time estimation. During the whole issue tracking process the following tasks, with corresponding forms, exists in the workflow: Answer or continue: HOW evaluate the description, if they found that the issue is already solved, they can either provide the answer to the customer or carry out the solution right away. The other option is to continue and the ticket will be moved to time estimation. Estimate time: an HOW Solutions employee fills out the form for time estimation, other information could also be provided in the form. The provided information will be appended to the issue ticket. Accept time estimation: form with the information HOW Solutions provided in the time estimation form, the user can accept or decline the proposed time estimation. Satisfied with given answer: a form containing a field with the provided answer from HOW Solutions. The customers decision to accept or decline the answer. The user can also provide information themselves if they want HOW Solutions to review the question again. Provide further information: form with comment field that the customer has to fill out to further describe the problem they are experiencing or answer a question from HOW Solutions. Need considerable modification: a form with accept or decline for HOW Solutions where they have to review the customers comment regarding why they are not satisfied with the solution.
43 Evaluate failure cause: during this stage HOW Solution might check logs and examine the code and report back to the form. Accept changes in test environment and production environment: a form with description fields and the customer could either approve or reject the solution. The purpose with the tasks is that it provides a limited interface for the users. Only the information they need to perform the task they are asked for are provided. The user themselves do not need to keep track on the other parts of the process, such as what the current state is, what the next step is, who do they need to assign, and so on. 4.5 Reminders To help reduce the number of issues that have been overlooked or have fallen between the cracks, the new system will include reminders. The reminders will be sent out after a specified period of time, depending on the state that the issue currently is in. For example in Time estimation -state reminders are sent out after a shorter period of time than a reminder of the Under investigation -state. If the properties of a ticket have not changed during the specified period of time, a reminder is sent out to the individual who are currently assigned to the ticket. Both customers and employees of HOW Solutions believed that reminders could help during issue tracking process. As mentioned earlier, the users did not log on to the collaboration room without receiving an or phone call from the other part. Because of the sporadic use of the collaboration room, issues and questions could easily be forgotten as the users actively never logged in to the collaboration room just to check up with the latest events. Reminders, together with notifications, can highly raise the awareness on the collaboration room by regularly provide users with information instead of them having to search for it themselves. The information is also brought to the users in the matter they themselves wants, by which most people use, they are familiar with the concept, this was their go to technique when the issue tracking system did not work as the anticipated. By utilizing as dissemination of information, we can with simple means implement notifications. All of the interviewed customers used Microsoft Outlook as their mail client. By sending them information my mail, the mail client will take care of notify the user. By providing a link in the we also give the users an easy way to access the collaboration room. This means, with client, notification and ADFS, that the user could with only 2 clicks see a ticket or perform a task - first click to open the mail client with the mail and then click on the link to the item, ADFS will automatically login the user on the collaboration room.
44 4.6 Flexibility One important aspect of the workflow is that it is flexible. This means that the workflow should be able to avoid from the predefined course of a ticket if it is necessary. This is a requirement that is based both from the workshop as well as the interviews. Some customer experienced the issue tracking system to be too linear, and felt that the system only worked when it came to more simple issues, such as changing the color of a button or update a image on their web page. If the workflow is flexible users can, during the course of the ticket, change its state manually and still be able to work properly. This is useful in cases when a ticket does not need to go through all the stages in the workflow, for example simpler tickets might not need to be tested in both test and production environment, some other tickets, that are a bit more complicated, might need to go back several stages and so on. Figure 4.6: The user can select what the next action for the workflow will be.
45 5 Discussion The result of the implementation is solely based on SharePoint built in features. This was one of the limitations for this thesis in order to be able to easy implement the new approach. Although, many improvements could have been achieved if third-party applications have been used. The implementation proposed in this thesis could be a good starting point for a full fledged support system, but from the customer perspective a lot of improvements could be added in the future. Many of the planned features could not be implemented because of the limitations from SharePoint Online, which is a limited version of SharePoint since we do not control the whole SharePoint solution. With SharePoint on premise, some of these features could have been implemented, but this would also require the supplier to provide the collaboration room with their own servers and also to pay for a more expensive SharePoint license. The provider has to consider if the features that an on-premise solution brings are adequate to the additional costs that it entails. 5.1 Mail to ticket Mail to ticket was an idea that was discussed during the workshop. This feature could be valuable to the collaboration room since it could reduce the amount of time spent adding information to cases. Another benefit from this approach is that it uses a medium that is regularly used by the end-users today and they are familiar with. Many of the issues are also communicated through mail, which implies that this feature might not be such a big change for the users. The outline for this feature was that the users could send information to a specific ticket containing information concerning the ticket more easily and also be able to report new issues through . The reason that this could not be implemented was because of the limitations of SharePoint Online, but this feature is included in on-premise SharePoint. The 39
46 reason for this limitation is because of the extra load that this put on the servers hosted by Microsoft. Third-party applications that does exactly this exists on the web store for SharePoint Online. 5.2 Improved reporting form A large portion of the focus during this thesis was to create a prototype for the workflow for issue tickets. But the interviews with the customers also revealed that many customers were unsatisfied with the functional parts of the collaboration room. Not much time has been spent on improving the interface of the collaboration room, or the functionality of the reporting form. The feature that was the most frequent request from the customers was an alternative way to attach images in the reporting form. The current approach to attach files is, as mentioned earlier in this thesis, cumbersome compared to other software used. An idea that arose during the thesis was to be able to paste images from the clipboard directly in a text field when the user reports a new issue. Again, SharePoint (not only SharePoint Online) restricts the alternatives. When a user uploads a file to a SharePoint site, the image will have to reside somewhere on the site. With a text field with paste from clipboard options, the issue of where it should be uploaded to emerges. Another problem with this kind of text field is the security. There is not much written about why this feature is not supported but on forums dedicated for SharePoint, Microsoft MVPs (most valuable professionals) points out that this approach imposes security issues. They argue that user s permissions could contradict each other. Users that have permission to report new issues might not have permission to upload specific files to the site. 5.3 State machine workflow In this thesis, SharePoint Online was evaluated. One of the shortcomings due to this limitation was the workflow alternatives. In SharePoint Online only sequential workflow are available, this meant that I had to emulate a state machine workflow in order to get the desired result. A sequential workflow would not be sufficient in this case and would be of little help in the solution process. In order the get the workflow as desired, a sequential workflow was used to emulate a state machine workflow. The result of this is a workflow that is very difficult to get a proper overview of and could be very time consuming to troubleshoot or customize in the future. I believe that a genuine state machine workflow should be developed for this purpose. This would allow for more features to be implemented, easier to overview, troubleshoot, customize and manage. Although this is not available for SharePoint Online, on-premise SharePoint need to be used for this purpose in order to be able to deploy the code as a farm solution.
47 5.4 Alternative solutions As I mentioned above, SharePoint Online comes with limitations that inhibits the development and features that can be implemented on a site. This applies for not only for SharePoint Online but also for on-premise solutions. But I believe that for this purpose, collaboration room for issue management, and for organizations that already have invested in SharePoint, who does not require extensive issue tracking and the number of calls to the help desk is are not immense, the built in SharePoint functionality in a SharePoint Online site could be sufficient. SharePoint Online is, compared to other SharePoint alternatives, very cost efficient. With SharePoint Online you still many of the features that are included in on-premise SharePoint. Because Microsoft hosts SharePoint Online, the supplier does not have think about the management of the site. This is a considerable benefit since the operating cost for on-premise SharePoint is rather high. As the workload on the collaboration room is not considerably high, since it is almost solely used for issues for customers, and the number of users is not very high either, even entry-level of SharePoint Online could be used. For the entrylevel of SharePoint Online organizations pay a monthly fee which depends on the number of users on the site. When it comes to the limitations of SharePoint Online for the issue management, using third-party applications can circumvent many of these. As mentioned above, applications that improves the current text field, which makes it possible to paste images from the clipboard, exists. There are also plugins for Microsoft Outlook that makes it possible to send s to list items in SharePoint. With these applications the collaboration room could cover the requirements for this thesis and be suitable as a issue tracking system. What could be considered when implementing a issue tracking system is the alternatives that does not involve SharePoint at all. There is a lot of software on the market that is dedicated for ticket tracking purposes that also is accessible through the web. These applications often also include other features such as knowledge base, live chat and statistics for solution time and so on. 5.5 Future work In this thesis little effort have been put into the client-side of the issue tracking system, i.e. the web site. Instead the focus has been on the general process for the ticket management. I believe that by improving the overall client-side functionality for the issue tracking system the experience for the customers could be greatly improved. This includes functionality that the user felt missing, mainly alternative ways do describe the experienced issues. Further work could also be done on the process, mainly by improving the workflow by using a genuine state machine workflow instead of using the emulated workflow as in this thesis. This is beneficial since it would facilitate the ongoing maintenance of the system. I believe that the workflow developed in this thesis could be sufficient also for a state machine workflow.
48 During this thesis five interviews where held with some of the customers. One of the problems during this thesis was go get enough people to participate for the interviews. At the customer premise, usually one person were responsible for the communication between the customer and HOW Solutions which narrowed down the number of possible interviewees. In order to get a more accurate view of the current situation, more customer interviews should be conducted.
49 6 Conclusion The goal of the thesis was to develop a prototype for a issue tracking system where customers to a supplier could report issues and questions regarding the product. The system was intended to be used in SharePoint Online and it should be easy to implement and manage. A desired property of the issue tracking system was that it should be flexible and able to support different kinds of customer calls. The result is a prototype for a issue tracking system which implements a workflow to coordinate the issue ticket throughout the solution process in SharePoint Online. The workflow covers the whole process, beginning with a new issue being reported to the end where the ticket is closed and archived. The process supports alternative paths that the ticket might need to travel before the issue is solved which are induced by the users, such as further information from customer or when more testing is needed for the implemented solution. The new approach can also handle issues or questions that does not require the whole process but only certain parts of the process. The system includes notifications and reminders for both the supplier and the customer, which are carried out over . These functionalities were implemented in order to prevent reported tickets to fall between the cracks or be forgotten, which can cause issues to take more time than necessary to be solved. In order to implement the new issue tracking system in SharePoint Online, SharePoint Designer and SharePoint Workflow were used. To enable easy implementation and management of the system, no third-party applications are used, meaning that no further installations other than SharePoint are necessary. 43
51 A Workflow scheme A workflow scheme for the suggested approach. 45
Analysis, Design and Implementation of a Helpdesk Management System Mark Knight Information Systems (Industry) Session 2004/2005 The candidate confirms that the work submitted is their own and the appropriate
Developing Real Time Tracking of User Behavior, with Google Analytics for Mobile Phone Devices Ahmed Hulo & Johnny To Master's Thesis Department of Design Sciences Lund University EAT 2015 Abstract Sony
MASTER'S THESIS 2010:111 CIV Customer Relationship Management Jens Berfenfeldt Luleå University of Technology MSc Programmes in Engineering Industrial Business Administration Department of Business Administration
Outsourcing Workbook Page 1 Copyright 2008 Notice of rights All rights reserved. No part of this book may be reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, recording,
Viðskipta- og raunvísindasvið School of Business and Science Knowledge Management in an IT-Help Desk environment Final Year Project 2010 Gunnar Ingi Ómarsson Institutionen för kommunikation och information
A Comparison between Agile and Traditional Software Development Methodologies M. A. Awad This report is submitted as partial fulfilment of the requirements for the Honours Programme of the School of Computer
Ville-Pekka Peltonen Software Asset Management Current state and use cases Helsinki Metropolia University of Applied Sciences Master of Business Administration Master's Degree Programme in Business Informatics
THE IMPORTANCE OF CUSTOMER RELATIONSHIP MANAGEMENT IN SOFTWARE ENTERPRISES LIFE CYCLE By Kranidioti Diamanto A THESIS REPORT Presented to the Project Management Program in the School of Management of City
Problem Management Contents Introduction Overview Goal of Problem Management Components of Problem Management Challenges to Effective Problem Management Difference between Problem and Incident Management
MASARYK UNIVERSITY FACULTY OF INFORMATICS Issue Tracking Systems DIPLOMA THESIS Jiří Janák Brno, spring 2009 Declaration I, hereby declare that this paper is my original authorial work, which I have worked
Making Smart IT Choices Understanding Value and Risk in Government IT Investments Sharon S. Dawes Theresa A. Pardo Stephanie Simon Anthony M. Cresswell Mark F. LaVigne David F. Andersen Peter A. Bloniarz
An introduction and guide to buying Cloud Services DEFINITION Cloud Computing definition Cloud Computing is a term that relates to the IT infrastructure and environment required to develop/ host/run IT
White Paper Implementing Your Help Desk A Practical Guide Implementing A Help Desk Implementing a Help Desk may sound either remarkably easy or terribly difficult, depending on who is pitching the solution.
Guide to Implementing Quality Improvement Principles Foreword Quality Improvement in health care continues to be a priority for the Centers for Medicare & Medicaid Services (CMS). In the Affordable Care
A GUIDE TO WRITING YOUR MASTERS DISSERTATION School of Management & Languages i Table of Contents 1. Introduction... 1 2. The Dissertation in Outline.... 2 2.1. Aims of the Dissertation... 2 2.2. Dissertation
DO VIRTUAL DATA ROOMS ADD VALUE TO THE MERGERS AND ACQUISITIONS PROCESS? by Dr. Christopher Kummer Vlado Sliskovic Institute of Mergers, Acquisitions and Alliances (MANDA) Zurich & Vienna, Dezember 2007
Process mapping for microinsurance operations A toolkit for understanding and improving business processes and client value MICRO INSURANCE CENTRE Developing partnerships to insure the world s poor Process
Stakeholder Relationship Management for Software Projects BY FRANCESCO MARCONI B.S., Politecnico di Milano, Milan, Italy, 2010 M.S., Politecnico di Milano, Milan, Italy, 2013 THESIS Submitted as partial
John Inverso Technology Overview 10 November 2000 Help Desk Systems and Software: Overview Summary The help desk can be both a boon and a burden to a company, either increasing customer satisfaction and
CRM Forum Resources http://www.crm-forum.com Critical Steps to Successful Customer Relationship Management Staffware ecrm, Inc. Developers of MarketForce Copyright Staffware ecrm, 2000 Critical Steps to
HP Performance Engineering Best Practices Series for Performance Engineers and Managers Performance Monitoring Best Practices Document Release Date: 201 Software Release Date: 2014 Legal Notices Warranty
THE FUTURE OF INSURANCE IT INFRASTRUCTURE A SURVEY OF GLOBAL INSURANCE LEADERS This is an authorised reprint of an independently researched and executed report granted by Celent exclusively to Wipro Technologies.
USE-CASE 2.0 The Guide to Succeeding with Use Cases Ivar Jacobson Ian Spence Kurt Bittner December 2011 USE-CASE 2.0 The Definitive Guide About this Guide 3 How to read this Guide 3 What is Use-Case 2.0?