Improving a Fault Handling Process in Public Property Management A Case Study Using a Business Process Management Approach Master’s Thesis in Quality and Operations Management Axel Rahm Otto Stuhlhofer DEPARTMENT OF TECHNOLOGY MANAGEMENT AND ECONOMICS DIVISION OF INNOVATION AND R&D MANAGEMENT CHALMERS UNIVERSITY OF TECHNOLOGY Gothenburg, Sweden 2025 www.chalmers.se Improving a Fault Handling Process in Public Property Managment A Case Study Using a Business Process Management Approach AXEL RAHM OTTO STUHLHOFER Department of Technology Management and Economics Division of Innovation and R&D Management CHALMERS UNIVERSITY OF TECHNOLOGY Gothenburg, Sweden 2025 Improving a Fault Handling Process in Public Property Management A Case Study Using a Business Process Management Approach Axel Rahm Otto Stuhlhofer © Axel Rahm, 2025 © Otto Stuhlhofer, 2025 Department of Technology Management and Economics Chalmers University of Technology SE-412 96 Gothenburg Sweden Telephone + 46 (0)31-772 1000 Gothenburg, Sweden 2025 Improving a Fault Handling Process in Public Property Management A Case Study Using a Business Process Management Approach Axel Rahm Otto Stuhlhofer Department of Technology Management and Economics Chalmers University of Technology SUMMARY This master’s thesis investigates the fault handling process within a public property management organisation in Sweden, a process critical to maintaining service reliability and safety in hospitals. The study also examines the applicability of the Business Process Management (BPM) framework in a public sector context and aims to provide concrete, actionable recommendations for process improvement based on its application. The study used the first four phases of the BPM framework, identification, discovery, analysis and redesign. A qualitative case study approach was used with data collected through ten interviews and five workplace observations in both the case organisation and in three reference organisations. Process mapping served as the overarching method to document and visualise the fault handling process. Thematic analysis was used as the first level of analysis to structure insights from interviews and observations, while the process analysis leveraged tools from the BPM framework, such as root cause analysis and impact assessment. The analysis revealed that many subsequent issues in the process originated from poor information in the maintenance request descriptions. To address this, the implementation of a chatbot is recommended to guide users in submitting structured and complete reports. Additional recommendations include improving work routines and process standards, as well as improving KPI quality by ensuring feedback forms are routed directly to end users. It can be concluded that while BPM provides a valuable structure for the initial phases of process improvement, its successful implementation and long term impact depend on careful adaptation to the specific public organisational context. . Keywords: Business process management, fault handling process, property management, public sector, process improvement ACKNOWLEDGEMENTS This master’s thesis was conducted at the department of Technology Management and Economics at Chalmers University of Technology during the spring semester of 2025. First and foremost, we would like to express our deepest gratitude towards our supervisor and examiner, Petra Bosch-Sijtsema, who have thoroughly guided us throughout the entire project. Your expertise, support, and availability have been greatly appreciated, without it, we would likely have been stuck more than once. Secondly, we want to thank the case organisation for this opportunity and those who have positively supported us throughout the project. We also want to highlight all participants who have made it possible, without them, it would not have been possible. Lastly we want to thank the opponents for their contribution, and our classmates who have made the past years memorable and exciting. Thank you. Axel Rahm & Otto Stuhlhofer June 2025 Table of Content 1 Introduction .......................................................................................................................... 1 1.1 Background ............................................................................................................................................. 1 1.2 Aim and Research Question ............................................................................................................. 3 1.3 Delimitations .......................................................................................................................................... 3 2 Theoretical Framework ....................................................................................................... 4 2.1 Introduction to Business Process Management ...................................................................... 4 2.2 The BPM Lifecycle Framework ....................................................................................................... 6 2.2.1 Process Identification and Process Discovery ................................................................. 7 2.2.2 Qualitative Process Analysis ................................................................................................... 8 2.2.3 Process Redesign....................................................................................................................... 10 2.3 BPM in Organisations ...................................................................................................................... 12 2.4 Critique of the BPM Framework ................................................................................................. 13 2.5 Change Management ........................................................................................................................ 15 3 Method ................................................................................................................................. 17 3. 1 Research Strategy ............................................................................................................................. 17 3.2 Research Design ................................................................................................................................. 18 3.3 Data Collection .................................................................................................................................... 18 3.3.1 Sampling ....................................................................................................................................... 19 3.3.2 Interviews .................................................................................................................................... 20 3.3.3 Observations ............................................................................................................................... 21 3.4 Data Analysis ....................................................................................................................................... 22 3.4.1 Process Mapping ....................................................................................................................... 22 3.4.2 Thematic Analysis ..................................................................................................................... 23 3.6 Research Quality ................................................................................................................................ 24 3.6.1 Credibility ..................................................................................................................................... 25 3.6.2 Transferability............................................................................................................................ 25 3.6.3 Dependability ............................................................................................................................. 25 3.6.4 Confirmability............................................................................................................................. 25 3.7 Ethics ...................................................................................................................................................... 26 3.8 Usage of Generative AI .................................................................................................................... 26 3.9 Methodological Reflection ............................................................................................................. 26 4 Case Description ................................................................................................................. 28 5 Results.................................................................................................................................. 30 5.1 Process Discovery, Current as-is Model ................................................................................... 30 5.1.1 Problem Detection and Filing a Maintenance Request ............................................. 31 5.1.2 Categorisation and Assignment by Customer Service ............................................... 33 5.1.3 Job Selection from Watchlist and Resolving the Problem ........................................ 35 5.2 Qualitative Process Analysis ......................................................................................................... 37 5.2.1 Information and Communication ....................................................................................... 37 5.2.2 Process and Method ................................................................................................................. 39 5.2.3 People and Roles ....................................................................................................................... 41 5.2.4 System ........................................................................................................................................... 42 5.2.6 Impact Assessment ................................................................................................................... 43 5.3 Comparative Analysis with Leading Companies in the Industry ................................... 47 4.3.1 Quality of Information ............................................................................................................ 47 5.3.2 Workflow ...................................................................................................................................... 48 5.3.3 Digital Systems ........................................................................................................................... 49 6 Discussion ............................................................................................................................ 51 6.1 Understanding Process Differences in Similar Organisations ........................................ 51 6.2 Public Sector Specific Challenges ................................................................................................ 52 6.2.1 Siloed Thinking and Inter Organisational Challenges................................................ 52 6.2.2 System Challenges .................................................................................................................... 53 6.2.3 Change Beyond Organisational Boundaries .................................................................. 53 6.3 Evaluating the Use of BPM in the Case Organisation .......................................................... 54 6.4 Limitations and Future Research................................................................................................ 54 7 Recommendations .............................................................................................................. 56 7.1 Implement a Chatbot in the Maintenance Request System ............................................. 56 7.2 Improve Work Routines and Process Standards .................................................................. 57 7.3 Increase the Quality of KPI’s ......................................................................................................... 58 8 Conclusion ........................................................................................................................... 60 References .............................................................................................................................. 62 1 1 Introduction This chapter introduces the master’s thesis by presenting the background and relevance of the study. It outlines the aim and research questions that guide the thesis. Finally, the chapter concludes with delimitations stated. 1.1 Background Everything in life can be understood as a process, including life itself. It has a defined beginning, develops through a series of stages, and eventually comes to an end. This sequence of change and progression is true for all living organisms. A process is in the dictionary defined as a series of actions taken in order to achieve a specific result (Cambridge Dictionary, 2019). In company settings, some processes are carefully designed and structured, for example a hospital treating a patient for stage two brain tumor. Other processes emerge informally over time, shaped by habits, trial and error, or necessity. These unstructured processes often evolve organically, not unlike random mutations that, by chance, turn out to work well and become part of the system. Whether delivering cancer treatment, manufacturing thin plastic lids for takeaway coffee cups or handling service requests in property management, the flow of activities, the process, matters. When processes are well designed, organisations run smoothly and customers are satisfied. However, when the processes are outdated or misaligned with goals, inefficiencies build up, putting performance and service quality at risk. “As Michael Hammer once put it: ‘every good process eventually becomes a bad process’, unless continuously adapted and improved to keep up with the ever changing landscape of customer needs, technology and competition.” (Dumas et al., 2013, p21). This highlights that process improvement is not a matter of fine tuning details. It is a fundamental organisational challenge. Building on this, there is an important difference between doing the right things and doing the things right, that is, between doing things effectively and efficiently. Peter Drucker (1963) once said that “There is nothing so useless as doing efficiently that which should not be done at all.” Emphasising that doing the right thing is more important than a perfect execution of something that does not add value. In the 1980s, Ford noticed that Mazda operated a comparable department with significantly fewer employees, yet achieved similar or even greater efficiency (Dumas et al., 2013). Upon closer examination, Ford discovered that its own purchasing process was designed around identifying and resolving errors after they occurred. Essentially treating errors as a separate activity at the end of the process. In contrast, Mazda had structured their process to prevent errors from arising in the first place, leading to a far more efficient operation. This case demonstrates the importance of doing the right things. As organisations and their processes grow more complex and competition between companies intensifies, the need for structured approaches to process improvement becomes increasingly critical. The origins of structured approaches to process improvement can be traced back to Scientific Management, which introduced the idea of standardising work routines and laid the groundwork for later improvement methodologies (Taylor, 1911). Since then, numerous approaches have emerged, each varying in success and impact. Among the most well known are Total Quality Management (TQM), Lean and Business Process Reengineering (BPR). Building on 2 the foundation of TQM, Lean and BPR, Business Process Management (BPM) has developed as a comprehensive framework providing a systematic approach for analysing, improving, and managing business processes (Harmon, 2010). Through clearly defined phases BPM can help organisations structure improvement efforts. Its systematic and methodical approach makes it particularly useful for navigating complexity, a common characteristic of large organisations. Although BPM has been widely adopted in the private sector, its documented use in public organisations, particularly in terms of successful implementations, remains limited (Syed et al., 2018). Public sector faces unique challenges compared to the private sector, largely due to differing goals and accountability structures (Alford & Greve, 2017). While private sector companies are driven by profit, the public sector must balance social, legal and political goals with their economic goal. Another key feature of the public sector is a high level of public accountability where organisations are expected to be transparent in their decisions toward politicians, media and citizens. This accountability combined with multiple stakeholder interests in decisions from citizens, politicians, internal departments and others often lead to public sector organisations prioritising stability over speed. Another factor contributing to the slow pace in public organisations is the presence of strong bureaucracy (Boyne, 2002). Among the many functions of the public sector, one is public property management. Public property management involves overseeing properties owned by public organisations, such as schools, hospitals, and transport facilities, which are essential for delivering public services. Unlike private property management, which focuses on profit, public property management aims to meet critical societal needs which creates societal value and supports long term community needs (Vermiglio, 2011). A core function within any property management organisation is the fault handling process. That is, the sequence of activities from identifying a fault to resolving it. In a public organisation this process can be vital. For instance, failures in hospital infrastructure may result in delayed medical response or malfunctioning operating rooms. Such issues can lead to deteriorated healthcare delivery and, in the worst case scenario, loss of life. This highlights the importance of a reliable and efficient fault handling process in public property management. Given the complexity of public property management, characterised by multiple stakeholders, bureaucratic structures and high accountability, BPM is a relevant framework. It provides a structured, systematic approach that can help organisations map their current processes, identify bottlenecks, clarify responsibilities, and improve coordination across departments. In doing so, it has the potential to enhance transparency, accountability, and ultimately the quality and efficiency of service delivery. Despite the strong potential of using BPM for process improvement in public sector organisations, the research in this area remains limited. Only a small number of studies have examined the application and particularly success of BPM in public sector contexts (Syed et al., 2018). When narrowing the focus further to property maintenance, there appears to be a complete lack of research, highlighting a clear gap and a need to explore how BPM can be applied to map and improve processes within public property management organisations. 3 1.2 Aim and Research Question The aim of the report is to examine the fault handling process within public property management by mapping its current structure and exploring inefficiencies, both within individual activities and across the overall workflow. Using the Business Process Management (BPM) framework, the study aims to analyse the process internally and compare it to reference organisations in the industry, and also evaluate how the BPM framework can be applied in a public sector organisation. Ultimately, the goal is to provide recommendations on how the process could be improved, potentially through the integration of advanced technologies, based on the findings. Research Questions RQ1: How is the fault handling process structured within a public property management organisation, and what are its main challenges? RQ2: How does the current process compare to practices observed in leading organisations within the industry? RQ3: What contextual factors influence the applicability and effectiveness of Business Process Management (BPM) in public sector organisations? 1.3 Delimitations Given the time constraints and the scope of a master’s thesis, the following delimitations have been made in this report: While the overall fault handling process in property management includes various types of cases, this study focuses exclusively on non urgent issues. The choice was made to ensure a manageable scope but also because this focus allowed for a more in depth analysis and closer examination of the specific process and the issues related to it. Furthermore, a part of the process of handling non urgent issues also involves determining whether the issue is covered by warranty. However, the warranty process is not included in this report, as it is a complex area and an own process itself. The number of locations observed and included in the interviews has also been limited. Since the process is supposed to be uniform across the organisation, it was considered sufficient to visit two or more locations to gain a representative and holistic understanding. While the report touches on the potential for advanced technology implementations, broader issues such as legal, data privacy, and ethical considerations are acknowledged but not explored in depth. The theoretical framework applied in this study, Business Process Management (BPM) includes six phases, with phases five and six focusing on process implementation and process monitoring and control. Due to time constraints, the report will be limited to the first four phases: process identification, process discovery, process analysis and process redesign. 4 2 Theoretical Framework The following chapter presents the theoretical framework applied to the case organisation's process. The study is within the field of Quality and Operations Management, which also forms the foundation for the selection and assessment of relevant theoretical concepts. In particular, the chapter introduces the Business Process Management (BPM) framework as a central perspective for analysing and improving processes. To complement this, relevant aspects of change management are included to address the organisational challenges in implementing process improvements. 2.1 Introduction to Business Process Management Business Process Management (BPM) is closely connected to the field of quality management. In the early stages, quality work mainly focused on inspecting the final product but over time it became clear that all parts of an organisation influence quality and customer satisfaction (Hoyle, 2006). This led to a broader understanding where quality was not only about the product itself, but also about how the organisation functions as a whole, a shift often described as moving from “little q” to “big Q”. Today, a key principle of quality management is the pursuit of continuous improvement across all organisational processes. This broader perspective laid the foundation for frameworks such as Total Quality Management (TQM), and later BPM. BPM builds on the ideas of the quality movement by offering a structured approach for managing and improving business processes across the organisation. It is a system for handling core processes and has two main roots. One is the quality movement, which aims to improve performance through consistent work and the elimination of variation. Over time, this developed into structured approaches such as Six Sigma, where measurement and analysis were central. The other root is Business Process Reengineering (BPR), introduced in the 1990s, which focused on radical redesign of end-to-end processes to eliminate fragmentation and inefficiency (Hammer, 2014). BPM combines these two perspectives. It supports both continuous improvement and larger changes of entire processes. At the same time, BPM is not only a framework with defined steps. It also represents a broader process perspective on how organisations function and improve. A process perspective means focusing on how work flows across departments and roles, rather than looking at tasks within individual units (Trkman, 2010). This view is central in this thesis, as it makes it possible to identify areas of improvements that are otherwise difficult to detect. The process perspective also supports a more dynamic understanding of organisations, since they are shaped by context, culture, and strategy (Trkman, 2010). 5 Figure 1 The essential process management cycle. (Hammer, 2014, p. 5) Figure 1 illustrates the process management cycle which was originally described by Hammer (2014) and follows a logic of create, assess, intervene, and evaluate. The cycle starts at the bottom where a process is created and implemented. It is then assessed to determine if it meets internal goals or customer expectations. If it doesn’t, the organisation must choose an intervention and evaluate the result before starting the cycle again (Hammer, 2014). This cyclical view reflects ideas from Business Process Reengineering (BPR), where underperformance is either due to design or execution failures. However, BPR has been widely criticised for overlooking organisational complexity and for assuming that radical redesign is always the solution (Dumas et al., 2013). This is the most frequently cited critique and is also confirmed by Harmon (2010), who further argues that BPR places too much emphasis on technology and structure, while neglecting the human and cultural aspects of change. Yet, these people related factors are often the main reason change initiatives fail, IT projects, for example, frequently fail due to poor change management rather than technical shortcomings (Legris & Collerette, 2006). However, many early BPR efforts failed because they relied heavily on immature IT systems (Harmon, 2010). Due to the combination of poor change management and reliance on immature IT systems, BPR has historically experienced a high rate of implementation failures. To address these shortcomings, modern BPM builds on similar principles but adds more focus on continuous improvement, stakeholder involvement, and effective change management. Nevertheless, BPM has also been criticised over the years. One common concern is that BPM is often reduced to a set of tools or software, rather than being treated as a comprehensive management discipline (Harmon, 2010). The author also argues that some BPM efforts fail to achieve lasting impact because they are not aligned 6 with business strategy and lack a holistic approach. He further highlights that while BPM connects three approaches, quality, management and IT, many of its practitioners only come from one discipline and therefore have troubles connecting and balancing the different aspects. Despite these critiques, BPM remains highly relevant in today's environment of increasing complexity and digitalisation. It enables organisations to control and improve complex workflows and centralise process logic. BPM techniques are also increasingly embedded within systems without always being explicitly labeled as such, underscoring the importance of understanding BPM as a discipline (van der Aalst, 2013). At the same time, it is important to recognise that BPM is not a single unified approach. It comes from disciplines such as TQM, BPR, and continuous improvement and there are also different ways of applying it depending on the context. Some versions are more top down and tool focused, while others emphasise team based work and culture change (Lee & Dale, 1998). This variety means that BPM should be seen both as a set of methods and as an overall approach to managing change. 2.2 The BPM Lifecycle Framework While the process management cycle provides the overall logic for managing processes, the BPM lifecycle offers a more structured framework for how each phase of improvement is carried out. The lifecycle consists of six main stages: process identification, process discovery, process analysis, process redesign, process implementation and process monitoring and controlling (Dumas et al., 2013). Together, these phases guide how organisations understand, improve and manage their business processes. In the following subsections, each phase will be described in more detail. 7 Figure 2 The BPM Lifecycle. From Dumas et al. (2013, p. 21) 2.2.1 Process Identification and Process Discovery In order to identify processes, there must be a clear understanding of what a process is. A widely cited definition, originally published in Bulletpoint in 1996, states that a process consists of four distinct features. First, it must have “predictable and definable inputs”. Second, a process is linear and follows a logical sequence or flow. Third, it includes “clearly definable tasks or activities”. Finally, the process has “a predictable and desired outcome or result” (Zairi, 2018, p. 64). When a process is defined it is important to understand how it fits within the broader structure of the organisation. Many modern organisations have moved away from traditional function based management toward a process oriented way of working where functions overlap and collaborate within processes (Zairi 2018). Adopting this approach places emphasis on understanding how processes relate to one another and on identifying which processes are most important from a customer perspective. These should ideally align with those most critical to the organisation’s objectives. This structure is referred to as the process architecture (Dijkman et al., 2014). The process architecture typically consists of three levels. Level one provides an overview of the core processes within the organisation. Level two zooms in and corresponds to a simplified process map. It typically breaks down each core process 8 into its main sub processes or phases, such as planning, execution, and follow-up steps. These subprocesses are still described at a high level but help illustrate the internal structure of the core processes and their logical sequence. Level three includes more detailed aspects of the processes, such as data inputs and outputs and the assignment of participants (Dumas et al., 2013). As mentioned earlier, process identification focuses on identifying relevant processes and placing them within the architecture, while process discovery aims to map the as-is processes in greater detail. With this in mind, level one aligns with the identification phase, level two spans both identification and discovery, and level three belongs to the discovery phase. In the paper by Dijkman et al. (2014), the authors conclude that the most useful way to work with architectures is to combine a function-based and object-based approach. In the function-based structure, a hierarchy of functions is created, and processes are outlined either by looking at what happens within each function or by focusing on the flow between them. The object-based structure, on the other hand, looks at the business objects and defines processes based on how these objects flow and change throughout the organisation (Dijkman et al., 2014). Combining function- and object-based structuring allows for organisation to organise processes both in terms of what they do but also what the processes handle. Once the relevant processes have been identified and positioned within a broader process architecture, the next step is to understand how these processes are carried out in practice. This takes place during the process discovery phase, which focuses on mapping the current as-is processes. To do this effectively, a modelling language is needed and most often Business Process Model and Notation (BPMN) is used to describe and visualise process flows in a structured and standardised way. A strength with BPMN is that it is designed to be understood by both business analyst and technical developers making it very important in bridging the gap between process design and implementation (Chinosi & Trombetta, 2012). Another important aspect of using a common process language is that it facilitates agreement and communication among people within the same organisation about what is being done. As part of process discovery, different methods can be used to collect information about how processes are performed in practice. These include evidence-based approaches, interviews, and workshops (Dumas et al., 2013). Each method offers different strengths: document analysis provides objective data, while conversations capture informal practices and exceptions. The choice of method depends on factors such as the organisation’s digital maturity, availability of documentation, and access to key stakeholders. Often, a combination of methods is recommended to capture both formal and informal aspects of the process. 2.2.2 Qualitative Process Analysis The third phase of the BPM framework is, as earlier described, process analysis, which aims to break down the issues with the original as-is model. This can be done either through qualitative or quantitative analysis methods. In this thesis, the focus is on qualitative tools with particular emphasis on root cause analysis and impact assessment, which are used to understand why problems occur and whether they are significant enough to address. 9 Understanding the root causes of issues is essential to avoid treating only the symptoms. To explore the underlying drivers of inefficiencies, Dumas et al. (2013) propose a root cause analysis. A popular tool in root cause analysis is the cause and effect diagram, also known as the fishbone diagram or the Ishikawa diagram seen in Figure 3. To use the cause and effect diagram, Ishikawa (1986) highlights the importance of clearly defining the issue at the head of the fish. Categories of potential causes are then determined and written at the end of each fishbone branch. Figure 3 Ishikawa Diagram. From Dumas et al. (2013, p. 194) Ishikawa (1986) encourages unique categories, based on process understanding. However, a later adaption of the root cause diagram has been to use policy, procedure, people and place as cause categories for service and administration processes. After each category is defined, Ishikawa suggests brainstorming possible causes in each category. Each cause can then be divided into further sub causes so that the underlying causes are identified. It is recommended to repeatedly ask why something is happening until further sub causes can no longer be found. Once the issues and their underlying causes have been identified, Dumas et al. (2013) recommend conducting an impact assessment to evaluate the significance of each issue. Two common methods used are Pareto analysis and the PICK chart. The core idea behind Pareto analysis is that the majority of issues can be traced back to a few key causes, often mentioned as the 80/20 rule (Juran and Godfrey, 1998). To assess the impact with the help of the Pareto analysis, the idea is therefore to use historical data and sort the causes from most to least significant to identify the issues that have the greatest overall impact. 10 Figure 4 PICK chart. From Dumas et al. (2013, p. 204) Another common approach to impact assessment is to evaluate the action required to resolve the issue using the PICK chart, seen in Figure 4 (Dumas, et al. 2013). The Y- axis represents ease of implementation, while the X-axis indicates potential payoff. The purpose of the chart is to help prioritise ideas based on value and effort of implementation. Ideas that are easy to implement and offer high payoff should be implemented, while those that are difficult to implement and offer low payoff should be killed. Together, the root cause analysis and impact assessment help provide a structured approach to analyse, understand and improve the process before moving into the redesign phase. The root cause analysis helps explore the underlying reasons for issues while the impact assessment helps understand if the issues are significant enough to improve. 2.2.3 Process Redesign As the most central issues in the process have been identified in the previous phase, the process redesign aims to translate those challenges into solutions and the design of a new process, the so called to-be process. A framework commonly used to clarify what a redesign aims to achieve is the Devil’s Quadrangle seen in Figure 5. It consists of four performance criterias: time, cost, quality, and flexibility. While it is fairly intuitive that reducing time and cost while increasing quality and flexibility is desirable, the framework illustrates that these goals often conflict with one another (Dumas, et al. 2013). 11 Figure 5 The Devil's Quadrangle. Adapted from Dumas et al. (2013, p. 259) Redesigns of processes can have very different starting points. Historically, the most common approach was to start from a clean slate and create an entirely new process. Over time, it has become more common to begin by analysing the existing process and identifying areas for improvement. A more recent development is to use a state of the art process model as a benchmark and then adapt it to the organisation’s current conditions. Regardless of the starting point, there are common steps to follow when creating a new process according to heuristic process redesign (Dumas et al., 2013). 1. Initiate: Redesign project is started and an understanding of the existing situation is created as well as goals and objectives for the new process. 2. Design: Based on the goals set in the initiate phase, potential improvements are explored using redesign heuristics. These are assessed for relevance and grouped into realistic scenarios describing how the process could be changed. 3. Evaluate: The proposed redesign scenarios are assessed to determine which one best meets the performance goals. This is done through expert judgment and simulations. There are two general ways of redesigning a process, either through Heuristic process redesign, or through product based design (Dumas et al., 2013). Heuristic process redesign is an approach that uses general guidelines, or heuristics, to find ways of improving a business process. These heuristics are based on lessons from earlier redesign projects and point to typical changes that tend to work well in practice. The aim is not to find a perfect solution, but to explore practical improvements that fit the specific goals and context of the organisation (Dumas et al., 2013). The redesign process using the Heuristic model typically starts with the current process model and aims to improve it by using the Heuristics. Product based design on the other hand, aims to structure the process around the product or service being delivered (Dumas et al., 2013). It is a logic driven approach that starts 12 by analysing the final product and breaking it down into components such as data and outcomes. The next step is to identify dependencies between data and establish a logical sequence of creation, for example that component A is needed before component B. Finally, the design phase aims to find the most efficient order between steps to efficiently deliver the product. This method often leads to radically rethinking of how a process should work, while the Heuristic redesign often leads to incremental changes. Each approach comes with its own set of risks. Heuristic redesign may overlook deeper structural issues while product based design might be hard to implement in existing organisations. Choosing the appropriate model for the redesign phase depends on the desired outcome. Heuristic redesign is well suited for capturing quick wins and addressing obvious inefficiencies, whereas product based design is better suited for challenging existing structures and driving more substantial organisational change. 2.3 BPM in Organisations BPM is commonly used in organisations, either as a comprehensive framework or by applying specific elements to analyse or redesign processes. In the article by Venkatraman and Venkatraman (2019), the authors investigated a process involving a petrol station chain, focusing on how a centralised helpdesk team at the main office manages technical issues at individual stations. The current as-is process begins when an issue arises at the petrol station. The issue could be anything from a broken coffee station to a broken fuel pump. The station employee, acting as the client, contacts the help desk via phone or email. A level 1 help desk staff receives the request and attempts to identify the problem. If the issue is simple or known, the level 1 agent tries to guide the employee through the solution over the phone. If the issue cannot be resolved at this stage, the problem is sent to the level 2 support which is a more experienced personnel. The level 2 support first assigns a priority level to the issue, either critical, urgent or normal. They then attempt to resolve the problem remotely, and if that is not possible, a contractor is hired to solve the issue. Key issues identified in the as-is process are too much waiting time, non value adding steps as well as communication delays, typically related to the handovers between level 1 and level 2. Venkatraman and Venkatraman (2019) use the BPM framework much like the framework proposed by Dumas et al. (2013). The main process improvements highlighted in the article by Venkatraman and Venkatraman (2019) are the reduction of non value adding activities. By redesigning the process and implementing a more efficient system, and thus eliminating the need for Level 1 support, they significantly reduce waiting times and manual data handling. Because of the new process, the average cycle time per issue is shortened from 46.5 hours to 4.2 hours, with increased customer satisfaction and lower costs. Beyond the petrol station case and its help desk improvements, numerous other examples demonstrate the successful application of BPM. In the article by Ammirato et al. (2024) the authors describe how the BPM framework was successfully used to improve and digitalise the Business Trip Request and Approval process at an Italian public university. The original as-is process relied on manual handling and paper based 13 repetitive work which led to high throughput time, frequent errors and also interfered with national digital administration laws. The improvement initiative followed the full BPM lifecycle and led to the successful implementation of a new to-be process. The redesigned process introduced a fully digital, unified system across departments, incorporating automation and digital routing between actors. The result was a more user friendly experience and a significantly reduced cycle time. Gulledge Jr and Sommer (2002) point out that, although the BPM framework has been widely adopted in the private sector, there are few documented cases of successful implementation in the public sector. This makes the case presented by Ammirato et al. (2024) particularly valuable, as it demonstrates how BPM can be effectively applied in a public sector context. A third case to illustrate the usefulness of BPM is the optimisation of the market analysis process within a large energy company (Teixeira et al., 2024). The original as- is process was largely manual and unstructured. Analysts relied on routine knowledge to determine analysis needs and identify the necessary data. They searched and requested data from various sources and then recorded the data in excel. This was followed by time consuming data cleaning and transformation to then be able to then manually create reports using charts and tables. The full lifecycle of the BPM framework was utilised to redesign the process. Process discovery was conducted through structured interviews, document reviews and workshops. A BPMN model of the as-is process was developed and validated through iterative feedback from different stakeholders. The process was then analysed using value added analysis and waste analysis and redesigned using the Devil's quadrangle to balance improvement goals. The key distinction in the redesigned to-be process was the implementation of python scripts to enable automation of the process, such as scraping data from websites and standardised data transformations, improving efficiency. Collectively, the studies made by Venkatraman and Venkatraman (2019), Ammirato et al. (2024) and Teixeira et al. (2024) demonstrate the potential and effectiveness of applying the BPM framework to non producing processes such as information- and service oriented processes. While most examples focus on private sector contexts, Ammirato et al. (2024) also provide evidence of successful BPM implementation in the public sector. 2.4 Critique of the BPM Framework Although much of the work in the article by Venkatraman and Venkatraman (2019) is grounded in the BPM framework, the authors criticise the framework. They argue that BPM focuses too much on the process flows and too little on data and data driven change. While they acknowledge that BPM provides a solid foundation for process improvement, they believe that it is insufficient on its own for driving system level change. Especially in real world contexts involving data centric systems like Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM). To address this gap they propose to complement the BPM framework with a stronger data foundation, drawing from the more data oriented Business Object Oriented Modelling (BOOM) approach. 14 This limitation in the BPM framework is also recognised by Dumas et al. (2013). They note that although BPMN is great for modelling control flows as well as tasks, gateway and events, it does not provide enough support to model data lifecycles, detailed data structures and complex relationships between entities. Moreover, the authors see a weakness with the BPMN diagram, no matter how well structured it is, it cannot be directly transformed into a functioning automated system. To do so, it needs to be complemented with additional information and programming such as defining data object attributes, data types and relationships as well as adding programming logic. The distinction between Dumas et al. (2013) and Venkatraman and Venkatraman (2019) lies in how they respond to the limitations of the BPM framework. Dumas et al. acknowledge the weakness in the BPM framework, particularly in handling data, but still suggest that the BPM framework should act as the foundation in a process improvement. They suggest that the framework can be extended through detailed programming to bridge the gap. In contrast, Venkatraman and Venkatraman (2019) believe the gap between the BPM framework and modern, data driven systems is too wide. As a result they propose moving beyond BPM toward a more data centric framework, however still using the BPM as the foundation. Although both Ammirato et al. (2024) and Teixeira et al. (2024) present successful examples of process improvements by redesigning and automating processes, they also criticise and highlight flaws in the BPM framework. Ammirato et al. (2024) point out while the BPM framework is widely used in the private sector there have been few documented implementations in the public sector, which can lead to difficulty in public implementations. They discuss that this most likely is due to the public sector being inherently resistant to change and generally freezes the processes if there are not too many critical points. The conclusion of the discussion is that the general resistance to change in public organisations makes BPM harder to implement. Gulledge Jr and Sommer (2002) also emphasise that implementing BPM in public organisations tends to be more challenging due to bureaucratic structures, legal constraints, and cultural barriers. Unlike private companies, public sector organisations do not face the same competitive pressures, which often results in a lower overall motivation to pursue change. In addition, they point out that many public organisations operate with outdated IT infrastructure, further complicating efforts to automate and optimise processes. Addressing this, Ammirato et al. (2024) emphasise that BPM is not a one size fits all solution. The success of a BPM implementation depends on factors such as simplicity of the process, availability of data and the degree of stakeholder involvement. Gulledge Jr and Sommer (2002) agrees and add that successful public sector implementation requires both organisational and BPM specific adaptations. One organisational adaptation they suggest is moving from siloed departmental structures to a focus on specific end to end processes, where multiple units share responsibility for achieving a common outcome. They also emphasise the need to engage stakeholders early and foster a participation culture. In terms of BPM framework adaptations, Gulledge Jr and Sommer (2002) suggest adjusting language and simplifying how the BPM is communicated as well as gradually introducing BPM tools as the organisation often uses old and fragmented IT systems. 15 Teixeira et al. (2024) similarly stress that BPM cannot be treated as a plug and play model. They argue that traditional BPM assumes structured repeatable processes, whereas the original as-is process investigated in their study was far more dynamic and depended heavily on human interpretation. Because it did not follow a strict workflow, applying the BPM framework posed significant challenges. Unstructured processes are highly variable and therefore make them difficult to standardise, model and automote. Either each scenario has to be modeled or the process ends up being described in a way that lacks details. While they found the BPM framework to be a good starting foundation, it was not always practical strictly following the BPM lifecycle. Instead they suggest using BPM as base but adapting the implementation to the specific case. While each study highlights unique challenges in their respective implementation, neither of the authors reject the framework outright. Instead they suggest extending and adapting it to fit the specific context, emphasising case specific customisation to create a successful outcome. 2.5 Change Management While BPM provides a structured approach for improving processes, its success often depends on how well the organisation manages change. As noted earlier, many process implementation initiatives have struggled due to an overemphasis on structure and technology and too little focus on human and cultural factors (Harmon, 2010; Legris & Collerette, 2006). Even when a redesigned process is technically sound, it may fail in practice if employees do not adopt new ways of working. This is why change management is an important part of the implementation phase in the BPM lifecycle. It helps the organisation move from the current as-is process to the new to-be process. This section introduces organisational change as a perspective to better understand what influences whether process improvements succeed in practice. Change in organisations is not only about tools and models. Change is also a social process that happens in an organisational context (Armenakis & Bedeian, 1999). People do not just follow new routines automatically, but instead they react to change based on their own experiences, values, and how the change affects their daily work. For example, in a Turkish construction company, an organisational change was resisted by employees as they felt that the implementation of a coordinator would drive them away from the center of power in the company (Danışman, 2010). This example indicates that process improvement is not only about designing better processes but also about understanding how people in the organisation respond to those changes. To make the process implementation successful, it is important to create a shared understanding of why the change is needed. A well known model for managing organisational change is Kotter’s eight step framework (Kotter, 2009) developed from observations in a large number of organisations. The model outlines steps often needed for successful change, such as creating urgency, creating a guiding coalition, communicating a vision, removing obstacles and anchoring new behaviours in the organisational culture. Kotter (2009) argues that change is not only about structure and planning but also about leadership and communication. In the context of BPM this is relevant as many process initiatives fail because the organisation does not handle the human factors well. 16 The organisational challenges become even more complex in public sector organisations, such as the one examined in this thesis. These organisations often face strong external controls that can make change more difficult. Rules, political decisions and budget limits reduce the organisation's freedom to act and may hinder change (Fernandez & Rainey, 2006). Public organisations also have many different stakeholders who may want different things which makes it harder to agree on what the change should look like. While change models like Kotter’s eight step model emphasise urgency, it is important to note that his work is based on change in private companies. This can make it hard to implement that model in a public organisation where the autonomy is limited. Fernandez and Rainey (2006) argue that to overcome such barriers it is important to build relations with political stakeholders and by doing so create an external support for the change as well. A key factor in driving successful organisational change is understanding the underlying causes to why an organisation is shaped and behaves in a certain way. DiMaggio and Powell (1983) discuss that organisations in similar environments tend to be increasingly alike and describe the phenomenon as institutional isomorphism. They argue that institutional isomorphism typically is about creating legitimacy, following norms and managing uncertainty rather than creating an efficient organisation. They further explain that institutional isomorphism can take different forms depending on what influences their organisational behaviour. It could be a result from compliance with formal rules or directives by regulatory bodies, from the imitation of other organisations structures or processes in response from uncertainty, or from professional norms shaped by shared educational backgrounds among individuals working within the same industry. 17 3 Method This chapter outlines the methodological approach of the study. It includes the research strategy and design, describes how data was collected and analysed, and outlines ethical considerations and the use of AI tools. 3. 1 Research Strategy As stated earlier, the aim of this project was to examine a specific process at a regional property management organisation and provide recommendations for improvement. To achieve this, a qualitative research strategy was adopted, utilising a descriptive and exploratory case study design. This approach was best suited for the project as it allowed for a deep understanding of the process, given multiple stakeholder perspectives and the qualitative nature of the process which included few quantifiable aspects. A core aspect of any research strategy is the underlying reasoning process, which determines how data and theory interact to form conclusions. Research can be structured using either deductive, inductive or abductive reasoning (Bell, et al., 2019). Deductive reasoning starts with theory and then tests the theory by using empirical data, usually through experiments. Inductive reasoning on the other hand builds general conclusions from observations. This study however, aligns more with abductive reasoning, mostly related to inductive reasoning but containing elements of both. Abductive reasoning starts with observations and then uses both the data and theory to develop recommendations. Often working iteratively between them. This study began with the current process, mapping the process and identifying inefficiencies. By analysing the data and going through existing theory and research, recommendations were developed. Moreover, philosophical assumptions shape how research is conducted and how the findings are interpreted. They consist of two components, Ontology concerning the perception of reality and epistemology defining how knowledge is acquired (Bell, et al., 2019). Ontologically, research can take either an objectivist or a constructionist perspective. Objectivism is the perspective that reality is independent of people’s perceptions while Constructionism is the perspective that reality is socially constructed through people's experiences and interactions. This project adopted a constructionist perspective, as multiple stakeholders were interviewed and helped understand the process. Each interview contributed a unique perspective. Further, from an epistemological perspective, research can be approached through either positivism or interpretivism (Bell, et al., 2019). Positivism emphasises objective facts and measurable data, seeking a universal truth. Interpretivism on the other hand, emphasises subjective experiences, context and meaning. This study followed an interpretivist approach as the goal of the data collection was to understand the process, mainly focusing on how customers and employees, in this case, hospital staff, customer support and technicians, experience and interact with the process. 18 3.2 Research Design The research design of this project followed a descriptive and exploratory case study approach (Bell, et al., 2019). The descriptive phase focused on mapping the fault handling process by using observations and semi structured interviews, documenting the process structure, sequence of steps and interactions between stakeholders. This provided a clear understanding of how the process function currently. Further, the exploratory phase aimed to uncover underlying inefficiencies and different stakeholder perspectives. Semi structured interviews were conducted to understand both the specific process step, but also to understand how employees perceived dependencies and constraints between the different steps. This approach allowed the study to explore inefficiencies and bottlenecks as well as underlying issues. Bell et al. (2019) emphasises that research often is non linear, particularly qualitative case studies. This means that different phases of the research process can inform and refine one another. In this study an iterative approach was adopted during the observations and semi structured interviews. Both the descriptive and exploratory perspective was used to understand both the current state and inefficiencies simultaneously. By combining descriptive mapping with exploratory analysis, the study provided a structured overview of the process and a deep understanding of the challenges related to the process. The research followed the BPM framework to map and analyse the selected process. The process identification phase was mostly completed by the case organisation, while the as-is process was discovered and documented during the process discovery phase. The qualitative and comparative analysis conducted corresponds to the process analysis, and the recommendations developed can serve as a foundation for the process redesign phase. Furthermore the BPM framework also includes the phases of process implementation and process monitoring and control, these were not included within the scope of this study and are instead left to the organisation to carry out independently. 3.3 Data Collection The purpose of the data collection was to gain an understanding of the fault handling process in property management operations. The interviews included different stakeholders to enable mapping of the full process. When possible, respondents with similar roles were also interviewed to support data saturation. However, since RQ1 focuses on a specific process involving people with different responsibilities, data saturation is difficult to achieve as each person offers a unique perspective. Despite this variation, we believe that the collected data provides a clear and well rounded understanding of the process. The data in this study is of qualitative nature as it aimed to explore a complex real world process. Depending on the circumstance of each semi structured interview, meetings were either audio recorded and transcribed using a smart transcription tool, or detailed notes were taken during the interview. Similarly, detailed field notes were taken during the observations to capture what was seen and heard. 19 3.3.1 Sampling The sampling followed a contingent purposive approach, meaning that the criteria for whom to interview became clearer as the research progressed. (Bell et al., 2019). Since the study initially aimed to map a process and describe related problem areas, in line with the first research question, this sampling method was a natural fit. As the research progressed, it became possible to change the focus and narrow it to specific parts of the process that were found to be of greater interest for the aim of the study. The sampling for the process mapping was based on an internal process map where stakeholders and their sub processes were represented. Once the process and key problem areas became clear, a second round of interviews was conducted with representatives from companies identified by an internal resource as best in class in facility management in Sweden. With this in mind, each interview served one of two purposes. The first was to map the process and gain an understanding of its challenges and areas for improvement (RQ1). The second was to compare how leading companies within property management manage their fault handling processes, and how it compares to the case organisation (RQ2). The comparing companies were selected and pointed out by the case organisation which identified them as leaders in the field. Table 1 presents the number of interviews conducted, the purpose of each interview, and their respective durations. 20 # Interviewee Location Connected to Research Question nr: Duration (min) 1 Customer service Case Organisation Location 1 1 60 2 Technician 1 Case Organisation Location 2 1 75 3 Technician 2 Case Organisation Location 2 1 75 4 Technician 3 Case Organisation Location 3 1 30 5 Coordinator Case Organisation Location 3 1 30 6 Customer Location 3 1 45 7 Business developer Case Organisation (Teams) 1 90 8 Head of customer service Company A 2 60 9 Technical specialist Company B 2 60 10 Technical Department Manager in Property Operations Company C 2 60 Table 1 Overview of Interviews Conducted 3.3.2 Interviews In total, ten interviews were conducted and can be seen in Table 1. In all interviews, except for two, only one interviewee participated at a time. However, in interviews 2 and 3, two interviewees were present simultaneously. Interview 2 was the main interview, but the interviewee from interview 3 contributed so meaningfully that we chose to present it as a separate interview. Both authors of the report were present during every interview. 21 All interviews were done in person, except one who took place digitally via Microsoft Teams. The initial part of the interview focused on setting the stage, which included small talk as well as actively listening and showing respect to help the interviewee feel comfortable with the interviewers (Brinkman and Kvale, 2015). Interviews then followed a semi structured format. This means the interviewer used a guide as a base, while allowing the interviewee freedom in how they responded. The guide included topics and questions but the interview was also open to topics beyond the initial questions, depending on what the interviewee emphasised. This allowed the interviewer to follow up on areas that appeared important during the conversation (Bell et al., 2019). Since the first part of the study aimed not only to map the process but also to understand potential problem areas, this format was necessary. Potential problem areas for the process often emerged during the interviews and were not always possible to anticipate in advance. Brinkman and Kvale (2015) emphasise that while research is often focused around the “why” something is happening, interviews should first focus on “how” and “what” is happening. The reasoning behind people's actions should be analysed by the researcher, who can move beyond the interviewee’s own understanding. The authors liken this to a doctor's diagnosis. A doctor never asks why the patient is sick, but instead investigates how and what the patient is feeling. Asking why too early can lead to speculative answers with limited value. However, asking “why” was not excluded, it was simply reserved for after the “how” and “what” had been established. The second round of interviews took on a more structured approach, with a focus on answering specific questions. Rather than continuing to map the overall process, the emphasis shifted towards the initial step of the process and the quality of information involved. Despite the increased structure, the interviews maintained a semi structured format, allowing to explore unexpected but interesting topics that emerged during the conversations. 3.3.3 Observations In the study, multiple observations were conducted. The purpose of the observations was to follow an issue through the process, understand each process step and see how the different stakeholders interact with one another. It also worked as a method to validate what was said during the interviews but also as a method to refine interview questions based on observed insights. As observations were intended to complement the interviews in addressing the research questions, all steps of the process, except customer fault reporting, were observed. The initial reporting step was excluded due to feasibility constraints, as it was not possible to predict when or where the next issue would be reported. The observation method used was shadowing as a means of understanding roles and perspectives, as described by McDonald (2005). This technique involves closely following an individual in their daily work to gain insight into their role and subjective experience within the organisation. While shadowing is often conducted over several days, our observation period was shorter, as shown in Table 2. Throughout the sessions, the observers asked frequent questions, not only about visible tasks but also about verbal interactions, including both formal and informal communication. The level of participation varied depending on the situation. At times, this involved active 22 engagement, such as assisting technicians with simple tasks, while in other cases, it meant observing and asking questions as administrators demonstrated their use of software. The level of participation varied, but was always influenced by what was observed. However, we were never formally embedded in the organisation and did not hold any official roles, we maintained the position of external observers. During observations, brief notes were taken and then summarised more thoroughly afterwards to avoid interrupting the observation. Participants were encouraged to carry out their tasks as they normally would, in order to capture a process that closely reflects actual practice. # Observation Location RQ Duration (min) 1 Customer service + Work order categorisation Case Organisation Location 1 1 120 2 Work order selection + Work order execution + Closure Case Organisation Location 2 1 180 3 Work order selection Case Organisation Location 3 1 60 4 Customer service + sorting Company A 2 45 5 Customer service + sorting Company A 2 45 Table 2 Overview of Observations Conducted As shown in Table 2, observations among the reference observations were conducted only at Company A, as this opportunity came up during the interview. Observations were not possible at company B or C. 3.4 Data Analysis Two methods were used for the data analysis. First, process mapping was used to document and gain a structured understanding of the overall process. To explore the process in greater depth and identify issues and areas for improvement, thematic analysis was applied as a complementary method. After the thematic analysis was conducted, the process was analysed by utilizing the BPM tools outlined in the theory section. There were no strict selection criteria for these tools, but given their widespread use and the fact that alternative tools did not serve the purpose as effectively, they emerged as a natural choice. 3.4.1 Process Mapping To analyse and enable improvement of the fault handling process, process mapping was used, a method for visualising workflows and identifying inefficiencies. The process 23 map provided a structured overview of the different steps in the process, making it easier to detect bottlenecks, delays, and unnecessary activities. Following Heher and Chen (2017), the process proceeded with process mapping in several steps: 1. Defining the scope A specific troubleshooting process was selected, and the parts to be mapped were identified with clear boundaries established. 2. Involve stakeholders Key stakeholders were engaged to ensure that all perspectives were captured. 3. Brainstorming and mapping A whiteboard was frequently used to brainstorm, document and map each step in the process. 4. Validating through direct observation (Gemba Walk) The process in practice was observed to ensure that the map reflected reality. 5. Analysing and identifying improvement areas The process map was used to highlight inefficiencies and identify opportunities for workflow improvement. To further identify issues and themes in the process, a thematic analysis was used to further explore the process in depth. 3.4.2 Thematic Analysis To analyse these primary data sources, thematic analysis was leveraged, using an inductive analytical approach as themes emerged from the data rather than being guided by predefined theory. The thematic analysis was based on Braun & Clarke’s (2006) six step method. It was chosen because of its suitability for identifying patterns in qualitative data. The six steps included: 1. Familiarisation with the data The process began with transcribing and reading through the interviews as well as the notes taken to gain a holistic perspective and remembering the data. In this first step, initial notes and observations from reading through the primary data were also taken. 2. Generating initial codes In the second step, systematic coding was done of relevant data features, including interesting comments and process specific bottlenecks or comments of the specific process steps. The coding originated from the initial ideas from step 1 but was developed. The purpose of the coding was to break down and organise data systematically on the micro level, compared to themes which were generated later and which worked more on the macro level. 3. Searching for themes This third phase focused on a macro perspective of the codes and aimed at grouping codes into broader patterns or concepts. In the beginning of this step a whiteboard was 24 used to draw a mindmap, linking the different codes to each other and thereafter dividing them up into themes and sub themes. Themes were not determined just by frequency but also by relevance and significance. However, to be named a theme it had to be supported by multiple data points. 4. Reviewing themes The intention of the fourth step was to refine the themes and in the end of this phase know the different themes, how they were related and what the themes say about the data. As proposed by Braun and Clarke (2006) two levels of reviewing the themes were used. The first level was used to see whether the coded data in each specific theme formed a coherent and relevant group. The second level was used to see if all themes combined accurately reflected the entire coded data. 5. Defining and naming themes In this fifth step the final refinement of each theme was done. It involved analysing each theme in detail and trying to create a narrative that connected the theme to the research question. If clarifying was needed in some of the themes, it was done to increase clarity between the theme and research question. Lastly, each theme was assigned a clear and descriptive name. 6. Producing the report. The final phase of the six step method focused on writing the report and connecting the themes back to the research question. It involved creating a clear and structured narrative as well as selecting illustrative quotes to support the interpretations made. To support the coding process, a structured manual approach was used, primarily working in Excel to organise and store coded data. This enabled a consistent analysis across data types, where the observational notes added valuable contextual insights that complemented the interview material. Although Braun and Clarke’s (2006) six step model is presented as a linear process, the actual coding was more iterative. Codes were continually revised and merged as new data was analysed, reflecting the evolving nature of qualitative research. Similarly, Thematic Analysis was applied to the data from the comparative study, gathered through three interviews and two observations of the reference organisations, using the same coding approach as for the case organisation. The resulting themes were then compared to those identified in the case organisation to highlight similarities and differences. 3.6 Research Quality The trustworthiness of qualitative research should not be judged by whether different researchers can produce the same results. In fact, different researchers, settings, and time periods are expected to yield different outcomes. With this in mind, the quantitative concept of validity is not a goal in qualitative research. Instead, qualitative studies should aim to produce trustworthy results that inspire confidence and trust in the researchers' findings (Stahl & King, 2020). Lincoln and Guba (1985) suggest that researchers should strive for credibility, transferability, dependability, and 25 confirmability to establish trustworthiness. The following subsections will explain and elaborate on these four terms and how they have been considered in the study. 3.6.1 Credibility Credibility in this study refers to how believable the findings are. In a qualitative study there might potentially be several explanations for a certain result, this puts a lot of stress on the researchers to provide strong evidence for their conclusions (Bell et al., 2019). In the context of this study, it means that credible sources in interviews support the findings and that the respondents' answers were accurately interpreted. To ensure this, interviews were recorded when possible. When recording was not feasible, detailed notes were taken during both interviews and observations to enable reassessment of the answers in case of any unclarity. Furthermore, the use of follow up questions have been extensively used in cases where misunderstandings have been suspected. 3.6.2 Transferability Transferability addresses the question on whether the findings of the study are specific to the context in which they were found or if they can be generalised to different settings and cases (Bell et al., 2019). Since this study examines a process built on a standardised IT system designated for troubleshooting in facility management, it is likely that other companies using the same system have similar processes. Additionally, as the study is conducted within a public organisation, the findings related to organisational challenges and benefits may be generalisable to a broader context such as other public sector organisations. In summary, while certain findings from this study may be applicable to other companies and processes, one should carefully consider the specific context of each case. 3.6.3 Dependability Dependability refers to how well documented the research process is and how easily an external party can follow its progress and verify the legitimacy of the findings. This requires maintaining thorough records throughout all phases of the study, from problem formulation to data collection and the decisions made during the research process (Bell et al., 2019). To ensure dependability, the study followed a structured and well documented research process. Regular meetings with the supervisor were held throughout the project to reflect on methodological choices and ensure consistency. In the final stage, the report was peer reviewed to further enhance the reliability of the findings. 3.6.4 Confirmability Confirmability refers to the objectivity of the study and the assurance that researchers have acted in good faith. While complete objectivity is not attainable in business research, it is essential that researchers do not allow personal beliefs to influence the research process or its findings (Bell et al., 2019). This study has addressed confirmability in data collection by using non leading questions in interviews. 26 Additionally, continuous discussions regarding potential biases have been conducted to maintain clarity and transparency. 3.7 Ethics Ethical principles have been considered throughout the entire business research process. As Bell et al. (2019) emphasise, it is important to revisit ethical consideration throughout the entire work process instead of setting it aside once the planning phase is done and ethical approval has been gained. According to Bell et al. (2019), the most common ethical principles to consider in business research are whether any harm is caused to participants, whether informed consent is lacking, whether there is an invasion of privacy, or whether any form of deception is involved. These principles were carefully considered, and to ensure no ethical breaches occurred, all participation in interviews and data collection was strictly voluntary. Participants were informed that they could withdraw their participation at any time. Furthermore, transparency and research aim was clearly communicated to make sure that the participants were not deceived. Since the case study was conducted at a case organisation, which owns and maintains hospital facilities, the most important ethical consideration was to avoid any invasion of hospital patients' privacy during observations and interviews. To address this, a discussion was held with the case organisation before visiting the hospitals, where it was agreed that no information about what or who was seen at the hospitals would be shared or disclosed in any way. Non disclosure agreements (NDAs) were signed with the case organisation. The company name is included in the name of the report, however, is anonymised throughout the rest of the report. Before publication, the case organisation reviewed the content to ensure that no confidential information was revealed. The primary concern outlined in the NDA was to avoid disclosing any sensitive hospital related information, given its societal importance. For Company A, Company B and Company C no formal NDAs were signed. However, there was a mutual agreement to anonymise the company names. The relevant sections of the report mentioning these companies were sent to the respective interviewees for review, ensuring that no confidential information was included. 3.8 Usage of Generative AI In this report the generative AI tool ChatGPT has been used as language improver to enhance clarity and readability of the text in accordance with the Chalmers guidelines. To ensure full compliance, the supervisor was consulted throughout the project. However, it is important to emphasise that all original ideas, concepts, structure and content were written by the authors, AI was solely used to refine the language. 3.9 Methodological Reflection Overall, the methods applied and the sampling strategy used in the study provided the insights that were initially desired. After conducting the thematic analysis of the case 27 organisation a recurring theme and analysis was that the information quality was lacking. It was identified as a problem area and that a solution to the specific issue would also be the greatest possible improvement. To support this aim, the interview questions were designed to address information quality in detail. However, during the interviews, it became apparent that focusing solely on information quality was challenging. As a result the focus therefore shifted from just focusing on the information quality to a broader analysis of the overall process. While this shift meant that it did not follow the original plan, it eventually gave valuable insights. 28 4 Case Description The case organisation, a division of a Swedish region, is one of Sweden's largest property owners with more than two million square meters of property. The type of properties they own and manage are mainly hospitals, but also include public transport hubs, schools, museums and other public facilities. While the case organisation is responsible for constructing and maintaining these properties, the actual users, called clients, are separate organisations. For example, the case organisation owns and manages a hospital property, while the client in this case is the hospital organisation who operates independently in the facility. The case organisation is divided into different operational units. One unit is, for example, responsible for building and constructing new buildings as well as rebuilding existing properties. However, this project will focus on the service and maintenance unit, which is responsible for maintaining the properties used by clients. The maintenance of the case organisation's properties can be divided into three types of general cases. 1. Client reported issues: A problem is identified by someone in the client's organisation. These are further divided into: a. Urgent: Issues that pose an immediate risk of damage to assets or harm individuals, where timely intervention is critical. b. Non urgent: Issues that do not present an immediate threat of damage in the short term if left unaddressed. 2. Planned maintenance. 3. Customer orders of a new installation. Among these categories there are roughly 180,000 cases annually and about 25% of these, i.e 47,000 are non urgent issues. All three categories rely heavily on manual processes. In this report the first case of maintenance, where non urgent issues are identified by someone in the client's organisation, will be investigated. It should be noted that, although this is a fairly common process, it is subject to particularly high demands in the case organisation. For instance, faults such as malfunctioning automatic doors must be addressed immediately to avoid creating bottlenecks within the hospital. The process in general terms is described below. When a problem occurs, a staff member from the client's organisation sees the issue and either calls customer service or writes a report on what the issue seems to be. The customer service in the maintenance team then reads the report and tries to diagnose the underlying technical cause. This includes deciding from which area the specialised professional (electrician, HVAC technician, etc.) should be sent to address the fault. A complicating factor in this process is that the report writer, i.e., the person from the client's organisation, often lacks the technical understanding or does not know what the underlying cause is, leading to insufficient descriptions. The reader from the case organisation's customer service therefore has to interpret and guess the underlying issue and what profession is best suited for the problem, which sometimes leads to miscommunication. Customer support does not create a new report, but instead reviews the client's report, adds relevant information and assigns it to the responsible team. 29 The report is then placed in a watch list from where the service team can pick the reports. The service team reads the report and determines the necessary actions. The process for how cases are prioritised is not explicitly documented. Most of the time a team from the case organisation is sent to address the problem. However, in some cases the issue could be of a different character resulting in the need for a different team. For example, this involves issues covered by warranty which need to be handled by an external team. When the issue has been resolved, it is reported in the system. The system used in all steps is called Facilitate and consists of both a web version, WebLord, and a mobile app, PocketLord. Among these, the WebLord version is used significantly more for reporting the various steps. Despite the presence of various sensors in the buildings, the current maintenance and troubleshooting process remains largely manual. The case organisations have expressed interest in exploring more efficient ways of working and see potential in increased use of technical solutions. Moreover, with a high volume of cases handled annually, even a small reduction in time per case could lead to significant efficiency gains overall. 30 5 Results The Results chapter follows the BPM framework, beginning with a mapping of the current as-is process in the process discovery phase. This is followed by a qualitative analysis of the process. Finally, a comparative analysis is conducted between the case organisation and three leading reference organisations. 5.1 Process Discovery, Current as-is Model An overview of the current as-is model is shown in Figure 6. As illustrated, the process begins when an issue is detected. In most cases this happens within the client's organisation, where a staff member identifies a problem and submits a maintenance request describing the issue, its location and their contact details. There are however three other possible process starts. A technician from the service organisation may discover an issue during routine work and report it directly. A cleaning staff can email the customer service with an issue. Alternatively, the client may call customer service to report a problem. While this method is intended for urgent issues, it is occasionally used for non urgent matters as well. Figure 6 Current as-is model. Once a maintenance request has been submitted, it is reviewed by the customer service team, who interpret the issues and direct the issue to a team of technicians. The work order is then placed in a watchlist queue, where the different technicians can sort the watchlist based on geographical area and competence. A technician eventually picks a work order and assesses the report. If the technician determines that the issue falls within the scope of the internal team's capabilities, it is resolved internally. If not, the order is sent to an external contractor. When the work is completed, the case is closed and an update with a feedback form is sent to the client's organisation. 31 5.1.1 Problem Detection and Filing a Maintenance Request As stated earlier, the process starts in one out of the following four ways: 1. Client submits maintenance requests through either Weblord or Pocketlord. 2. Client calls customer service who then writes a report. 3. A technician from the case organisation discovers a problem during routine work and creates a work order. 4. Cleaning staff discovers an issue and reports it via email to customer support who then creates a work order. Out of the four possible starts, the client submission through either Weblord or Pocketlord is the most common one. Calling customer service should be limited to urgent cases but occasionally happens for non-urgent cases as well. Technician- and cleaning staff-reported issues are rare but are a possible starting point. When someone in the client's organisation reports an issue and creates a maintenance request they are required to fill in several information fields in the system. Firstly the reporter has to fill in their contact details. This information is intended to help other stakeholders follow up directly with the reporter if there are any uncertainties when resolving the request. To simplify filling in contact information there is a list of pre registered contacts that can be used to autofill the contact fields, however, if the reporter is not listed, they must enter their details manually. According to the customer service, it is common for reporters to select a random name from the autofill list instead of entering their own. This leads to problems if the request has to be completed with further information and when the customer service is unable to reach the original author. This statement is also supported by multiple technicians that confirms that it is a recurring issue, making it difficult to to track down the person who submitted the request. The maintenance request also includes a description field where the reporter is required to explain the issue. According to customer service, the quality of these descriptions varies significantly. Customer service wants the descriptions to be as informative and descriptive as possible, while still being short and concise. The current usage however, lacks a standard template and therefore leads to either vaguely formulated descriptions or too long descriptions which makes it hard to identify the real issue. One technician estimated that around 80 percent of the descriptions are unclear enough that they require a phone call or an on site visit to fully understand the issue. However, another technician did not consider poor descriptions an issue as he typically calls the report writer anyways. A third technician pointed out that language barriers between the report writer and the technician sometimes complicate understanding the issue. “Some people write in a way that makes the problem completely unclear, not just quirky Swedish, but downright incomprehensible” he says. Another mandatory field in the maintenance request is the location of issue, specified using house designation and room number. According to customer service, there has recently been a new update regarding room numbers to standardise the room number used across different organisations. Ensuring that the room numbers used by the hospital align with those used by the rescue services and maintenance teams. This has 32 led to recent miscommunications about which room the issue actually concerns. This was also evident during a shadowing session of a technician, where the room number in the maintenance request did not match the actual location of the problem. Another optional field in the maintenance request is the ability to upload photos. Photos are not mandatory and the feature is rarely added. However, all technicians interviewed agreed that having a photo would support their assessment of the issue, making it easier to prepare and respond effectively. The coordinator described the helpfulness of a picture using the following example. “....when a customer writes 'wall needs to be filled and painted,' I assume it means an entire wall needs to be patched and then a painter has to be called in to paint the room. But once you see a picture, it turns out it’s just a drill hole that needs to be sealed and then covered by a dab of standard white paint, something anyone could do. So yeah, pictures really help.” - Coordinator. However, when asked why photos are included so rarely, the regional manager for customer service and development explained that the previous response has been that the client's organisation believed that technicians seldom look at the images, so they see little reason in including them. A nurse from the client's organisation mentioned that she includes pictures when asked upon, but never includes them initially. When she includes pictures, it is via email to the customer service and not through the system. Both a technician and coordinator believe the primary reason for so few pictures is a system barrier. They described the web based platform, weblord, as unintuitive and difficult to use when it comes to attaching images. The coordinator even admitted that, despite multiple tries, he still does not know how to upload photos through the system. Instead, he uses the mobile app, pocketlord, to attach pictures directly to the work order. However, Pocketlord has its own usability issues. None of the participants in this study use the app for anything other than uploading photos to work orders. Another system related challenge highlighted by the nurse during the reporting stage is the difficulty in knowing where to direct maintenance requests. Property related issues are meant to be sent to the case organisation, while requests concerning medical or technical equipment should be forwarded to other specific suppliers. This division of responsibility creates confusion, especially in borderline cases. As the business developer explained, the maintenance of a lamp, depending on the use case, should either be sent to the case organisation or the supplier of the medical equipment. If it is a normal lamp, then it is a case for the case organisation, however, if it is a lamp used for specific cases, for example providing light during surgery, it is supposed to go to the medical equipment supplier. To help the clients organisation avoid miscommunication or report the same issue twice, the nurse says that her department has initiated a physical cover with all the maintenance requests printed in the reception to keep track of all the issues being reported. According to her, it is not visually easy to see the already reported issues from the clients perspective in the digital system and that they use this paper based system because of its user friendliness. To keep track of all issues reported in their department, the nurse says that it is typically the same person reporting all issues. In their case, the receptionist has unofficially taken 33 on this role, acting as both the reporter and a point of contact for technicians when follow up is needed. This receptionist is so confident in the role that he often attempts to diagnose and resolve minor issues himself before submitting a request. While this level of initiative is somewhat unique, the coordinator noted that they frequently see the same names appear on the systems watchlist, suggesting that several departments across the hospital have their own go to person responsible for reporting issues. However, this structured approach is not consistent across all hospitals. Technicians at another facility reported that they do not experience the same pattern, highlighting that the example with the receptionist may be an exception rather than the norm. In general, those assigned to submit maintenance requests often lack both the technical expertise and the time required to provide clear and accurate issue descriptions. This contributes to the ongoing challenges technicians face when trying to assess and resolve problems efficiently. 5.1.2 Categorisation and Assignment by Customer Service The next step in the process is categorising the issues which are managed by customer service. Altho