MASARYK U N I V E R S I T Y F A C U L T Y O F E C O N O M I C S A N D A D M I N I S T R A T I O N Analysis and design of incident management and escalation processes, based on ITIL and Agile frameworks Bachelor's thesis M A R T I N S A M E C Supervisor: Ahad Zareravasan, PhD Department of Corporate Economy Programme Business Informatics Brno 2023 IUI UN I ECON ANALYSIS AND DESIGN O F INCIDENT MANAGEMENT AND ESCALATION PROCESSES, BASED ON ITIL AND AGILE FRAMEWORKS MUNI ECON i i s í í í n m unuEKZira llDIDllt H - S H l U l t FJIILTI L I P DVA 411, 111 D D B f ľ J D IC: iiiiein Bit: [ZDDMS224 Z A D A N Í B A K A L Á R S K E P R Á C E Akademický rok: 2022/2023 Student Maren Samec Program: Podniková iform3:lki Název práce: Analýza adasrgn rľzenl ibckJentu aeskalacnlchprocasu na základe ITILa agilních frameworku Název práce anglicky: Analysls and design of Incident management and ascatalon processas, based on ITIL Cil práce, postup a poulila metody: Cti práce: Bakalářská práca sa bude zabýval problematikou kombinace «ilhcvny ITIL 3 agl In ich Tamewcrca O D ; ty1 :; sNsujiiy - J Í ~vé soeclfické beneflty a na/z dory |ich lozdlHm bude bakalářská práce usilovat o |efch komblnacf š cile m dcsáh nc ut maximálních efeklu pro vybranou společnost. C lam práce bude návrh restrukturalizace dvou IT procasc (Tížení nadáno a eskalacnlho procesu), které |SDU vystavané v ITIL Irameworkij do vlca agilních verzľ. Pbaup a použitě metody: v" první fátzl autor analyzuje vybrané procesy a vysvetlí, [akým způsobem Je ITIL framework ovlvriuja. Dála procasy modeluje (vlétne vlzuallzaca) pro Jejich lepĚT porozuměni. V druhé fázr pak Identifikuje způsoby, [ak dosáhnout u techlo procesů vetší aglllry. Resmjkturaltzované procesy aulor znovu namodeluja a vysvätil očekávané benantv ptynouci z resmjkturallzaca. Student použije procesní modelovací nástroje Jako Vlsual Paradlgm pro účely modelováni a analýzy. Zdroji dat budou rozhovory sa zástupci spolecnosir, inemi dokumenlace podniku a případová studie a články, které sa zabývali problematikou ITIL a agilních fTameworkrj. Rozsah grafických prací: Podle pofcynfl vedouclho prace Rozsah práce bez prilob: 35-45stran Literatura STEINBERG. Randy A. ArcnUedlng fill : a reference tor arctXodlng me complete enterprise arc/Mtedure and conSguratan Hems needed la operate an IT service management Irtrastructtie. Victoria: Tralford Publishing, 2003. 363 S. ISBN 97814251U034B. Basic approach So ITIL service opefaSon isettmg the foundation for 1TL VS. ISBN 6780515392370. KFLAL, Jaroslav. Developing an iforniatlDn System of Software Metrics. In Sys:ems Davalopmen: Melhcds fonhe tot Century. In Dev&oplnp a,i Information System of Softtvars Metlcs, in Sys. Plenum Press, 1087. s. 498soa. ISBN rj-aoa4r>es3r|. Ef ecurjves OUJOB So IT govsnancssmproving systems processes v/tth serines managsmenf, COBfT, andiTL. Erlted by Robert F. Moeller. Hobcken, M.J.: John Wiley a Sons, Inc., £013. xvl, 335 p. ISBN 978111B224053. SWANSON, E. Burton, information system Implementation : budging the gap between design and iiSzatlon. homewood, III.: Irwin, 1988. 7.U. 145. ISBN 0256032093. IriroducSonloiTIL. London: TSO. 2005. x.242. ISBN 9780113309733. i T H A UI. L I 2 2 ANALYSIS AND DESIGN O F INCIDENT MANAGEMENT AND ESCALATION PROCESSES, BASED ON ITIL AND AGILE FRAMEWORKS Vedoucr pracs: AhedZarerav-aEan. PhD PracwIStů vedoucího prače: Katedře fodnkiwéha hospodářství Datum zadaní prače: 19.3 2022 Tenmin odevzdání bakalářská práce a vtažen í da IS je uveden v platném heninnor.jramu ekedemickérirj roku. V Bme dne: 23.4. 2023 3 ANALYSIS AND DESIGN OF INCIDENT MANAGEMENT AND ESCALATION PROCESSES, BASED ON ITIL AND AGILE FRAMEWORKS Bibliographic record Author: Martin Samec Faculty of Economics and Administration Masaryk University Department of Corporate Economy Title of Thesis: Analysis and design of incident management and escalation processes, based on ITIL and Agile frameworks Degree Programme: Business Informatics Supervisor: Ahad Zareravasan, PhD Year: 2023 Number of Pages: 70 Keywords: IT Service Management, ITIL, Agile, Incident Management, Escalation Process 4 ANALYSIS AND DESIGN O F INCIDENT MANAGEMENT AND ESCALATION PROCESSES, BASED ON ITIL AND AGILE FRAMEWORKS Abstract Concerning ITSM frameworks, ITIL is generally viewed as bureaucratic and inflexible, whereas agile methodology is thought to be almost its polar opposite. In spite of these apparent differences, the thesis will focus on showcasing interactions between these two methodologies in a specific company setting. Particularly, in the area of incident management and its encompassing escalation process. The thesis will aim to showcase the differences between methodologies, or lack thereof, by analysing the company's problems and the set of changes made to combat them through ITIL and agile lenses. 5 ANALYSIS AND DESIGN O F INCIDENT MANAGEMENT AND ESCALATION PROCESSES, BASED ON ITIL AND AGILE FRAMEWORKS Declaration I certify that I have written the Bachelor's Thesis Analysis and design of incident management and escalation processes, based on ITIL and Agile frameworks by myself under the supervision of Ahad Zareravasan, PhD and I have listed all the literature and other sources in accordance with legal regulations, Masaryk University internal regulations and the internal procedural deeds of Masaryk University and the Faculty of Economics and Administration. Brno October 22, 2021 Martin Samec 7 ANALYSIS AND DESIGN O F INCIDENT MANAGEMENT AND ESCALATION PROCESSES, BASED ON ITIL AND AGILE FRAMEWORKS Acknowledgements I would like to thank my thesis supervisor Ahad Zareravasan, PhD for continuous help, feedback and guidance. I would also like to thank the senior manager of the company for his willingness, cooperation and the sheer extent of detail provided concerning the company's business oper- ations. 9 TABLE OF CONTENTS Table of Contents List of Figures 13 List of Tables 15 Glossary 16 1 Introduction 17 2 Literature Review 18 2.1 IT Service Management 18 2.2 IT Service Management Frameworks 19 2.3 ITIL Incident Management and Escalation Process 21 2.4 Agility in Service Management 28 3 Method 32 3.1 Goals and procedures 32 3.2 Description of the company 34 3.3 Information Systems Analysis 34 4 Results / Analysis 40 4.1 Process Analysis and Problems 40 4.2 ITIL retrospective 47 4.3 Changes & Improvements 49 4.4 Agile retrospective 57 5 Conclusion 60 References 63 11 LIST OF FIGURES List of Figures Figure 1- ITIL Service Operation (Kempter, Kempter, 2019) 23 Figure 2 - Generalised incident management (Zhang Cao, 2016) 24 Figure 3 - SM9 Incident page 36 Figure 4 - Category level 1 37 Figure 5 - Category level 2 37 Figure 6 - CBI calculation matrix 42 Figure 7 - Escalation Process 46 Figure 8 - ServiceNow Incident Page 50 Figure 9 - ServiceNow Incident Page 50 Figure 10 - Incident Overview Page 51 Figure 11 - Incident grouping 51 Figure 12 - Incident reporting 52 Figure 13 - Incident Page through Self-Service (ServiceNow, 2023) 53 13 14 LIST OF T A B L E S List of Tables Table 1 - Priority to SLA table 41 Table 2 - Functional escalation structure 45 Table 3 - Hierarchical escalation structure 45 Table 4 - Modified Functional Escalation Structure 55 Table 5 - Summary Table 57 15 G L O S S A R Y Glossary IT - Information Technology Service Management ITSM - Information Technology Service Management ITIL - Information Technology Infrastructure Library IM - Incident Management EP - Escalation Process SMS - Service Management System CI - Configuration Item SVS - Service Value System SVC - Service Value Chain SM9 - Service Manager 9 SLA - Service License Agreement SC OPM - Service Chain Operating Manager SC - Service Centre CBI - Customer Business Impact OT - Operating Team MoD - Manager on Duty 16 INTRODUCTION 1 Introduction The IT service sector is one of the more volatile ones in the economy. One of the ways that companies navigate its uncertainties is by adopting various IT Service Management Frameworks (ITSM). One of the most popular of these frameworks is the ITIL framework, ITIL is a management framework conceptualised as a set of best practices which focuses on IT service processes, it is structured as five core books, which cover the fullservice life cycle: service strategy, service design, service transition, service operation and continual service improvement (Gartner, 2020). As a response to increased infrastructure complexity, more demanding customers, calls for higher service availability and pressures to reduce costs, IT organisations around the globe are increasingly adapting to the principles of ITSM and are redesigning their IT processes based on the concepts of the ITIL (Iden, Eikebrokk, 2014). Among the many processes and practices the ITIL framework describes, are Incident Management (IM) and Escalation Process (EP), which will be the focus of this thesis. However, there are other ways, apart from ITIL, which IT service companies use to adapt to the volatility of their markets. One such example lies in the frequently used agile methodology. Agile is the ability to create and respond to change. It is a way of dealing with, and succeeding in, an uncertain and turbulent environment (Beck, et al., 2001). The primary focus of the agile methodology are individuals as expressed through the first agile tenet "individuals and interactions over processes and tools" (Beck, et al., 2001). Even though agile was created to be used for software development, it has evolved and its usage has increased beyond its original bounds, namely for business process improvements. Improving business processes and conforming to existing approaches, do not always give a quick response to business needs. In some cases, it is indispensable to adopt agile approaches to business process improvement (Zacarias, Martins, 2017). There seemingly exists an inherent incompatibility between ITIL and agile, with one being focused more on processes and the other on individuals. As such, this thesis will aim to show that ITIL and agile can be combined to achieve a positive outcome for a company by restructuring the ITIL prescribed IM and EP using agile. 17 LITERATURE REVIEW 2 Literature Review 2.1 IT Service Management In recent years, many organizations emphasised on business model innovation and process design to build sustainable competitive advantage along with globalization. For this, organizations integrate various information systems and disruptive technologies into their business operations, which both support digital transformation and contribute to business model innovation (Ozdenizci, 2020). Since organisations have started to see the importance of IT, they have begun to implement complex and dynamic IT systems to support their business processes Qamous et al., 2017). These integrated information systems introduce software as an inherent part of business processes. As such, activities designed to be performed within the realm of IT, most prominently ITSM could be extracted and their concepts used as Service Management outside of its "IT bounds". This extracted Service Management is defined as a set of specialized organizational capabilities for enabling value for customers in the form of services (Agutter, 2020). Services, within this context, are defined as interactive processes between customers and service providers where the customer benefits from the expertise of the service provider (Stokburger-Sauer et al., 2016). This definition of services is presented through the lens of customer and service provider relationship. However, services are increasingly beginning to be viewed as relationships confined within the company itself. ITSM is becoming an integral part of organisations, since it provides a set of activities to align, design, deliver, manage and improve how IT is used within an organisation (Faustino, et al., 2020). Keeping in mind this widened view of ITSM, a more specific definition can be presented. IT service management refers to the implementation and management of quality IT services that meet the needs of the business. ITSM is performed by IT service providers through an appropriate mix of people, process and information technology (Tank, Todo, 2013). These needs of the business need not fall under a customer - service provider relationship but may represent more internal business ones, such as increase in efficiency of the company's processes or improvement in employee productivity. 18 LITERATURE REVIEW As illustrated, since IT is so heavily integrated with businesses, ITSM is responsible for making all departments in a company run smoothly in terms of technology. ITSM acts in advance and anticipates the company's needs in areas like communication, marketing finance, administration, operations, production, human resources, and more (Sydle, 2022). According to itSMF USA's "Service Management not just for IT anymore" survey 2014, more than 50% of the organizations surveyed are either applying or planning to apply service management principles in business areas outside of IT (Gillingham, 2022). The concept of "extracting IT principles outside of IT realm" is not limited to only ITSM, frameworks built on top of it such as ITIL, or methodologies for software development like agile, as mentioned previously, are all be subject to this "extraction" and are used to restructure and improve processes and operations within a non-IT business. 2.2 IT Service Management Frameworks A question seems to present itself when it comes to the ITSM frameworks, whether they are worthwhile for companies to consider implementing. Many companies opt for the use of ITSM frameworks due to the benefits they bring. Using predefined best practices and standard processes help provide a structure and guidance for IT - which reduces risk and improves efficiency by focusing on industry standards. Organizations can more easily support their IT services by hiring experts, and training internal staff, on standard frameworks rather than trying to reinvent the wheel (Watts, 2017). As a concrete example, in the implementation of ITSM methodology in Local Electoral public institutions in Mexico, demonstrated an astounding improvement by 88% in response times to incidents or service requests (Barcelo-Valenzuela, Leal-Pompa, 2020). There are problems however, although some ITSM processes have been implemented in most large IT organizations, only few have adapted all processes recommended by established ITSM frameworks, while most smaller organizations have introduced only some basic ITSM processes or none. While containing many useful and comprehensive concepts, the most established ITSM frameworks are quite complex and seem to be written primarily for large enterprises. Generally, smaller and medium sized companies do not have the capabilities to fully implement 19 LITERATURE REVIEW all of the ITSM frameworks' recommendations (Michael, Michael, Thomas, 2019). Company size therefore, should be a factor for consideration whether to invest into a ITSM framework, partially, fully or not at all. The most popular of these frameworks, used by the likes of IBM, HSBC and NASA (Goddard, 2019) is the aforementioned ITIL. Besides ITIL, there exist other frameworks which all provide a nuanced view of ITSM. • ISO 20K: ISO/IEC 20000 - It is an international standard which, in contrast to ITIL, simply defines the minimum requirements of a Service Management System (SMS). USM defines SMS as a set of coherent elements that generate routines for the realization of service management (USM, 2022). • FitSM - FitSM combines aspects from ISO20K: by providing minimum requirements, however, in addition it also adds processes and application examples. The focus of FitSM are the objectives of each defined process. • MOF: The Microsoft Operations Framework - This framework is more focused on general principles and guidelines, with operations being its focus. There is also a heavy inclination towards Microsoft technologies within the framework and it is in its entirety based on an underlying concept of IT service lifecycle (similarly to ITIL as demonstrated later). The MOF service lifecycle consists of 4 stages, each having defined Service Management Functions (SMF) which in turn define a collection of processes, roles and activities (Michael, Michael, Thomas, 2019). • COBIT - Standing for Control Objective for Information and Technology, it is used for governance and management of information and technology across the whole business. It defines governance system components such as processes, organizational structures, policies and procedures, information flows, culture and behaviours, skills, and infrastructure. (Hiererra, et al.,2019). The main distinguishing factor setting COBIT apart is its focus on governance and control, it does not include process steps and tasks. It focuses on what an enterprise needs to do, not how it needs to do it (Kozina, 2009). 20 LITERATURE REVIEW 2.3 ITIL Incident Management and Escalation Process ITIL provides guidelines and definitions for diverse types of processes, it defines a process as a set of interrelated or interacting activities that transform inputs into outputs. A process takes one or more defined inputs and turns them into defined outputs. Processes define the sequence of actions and their dependencies (Agutter, 2020). ITIL has had over the years four versions labelled VI through V4. V3 holds the latest and most detailed information for process knowledge, as such, through its lens will the following processes be described. V3 provided grouping of processes around five service lifecycle stages, in addition with the standard process goals defined below: • Service Strategy - To decide on a strategy to serve customers. Starting from an assessment of customer needs and the marketplace, the Service Strategy process determines which services the IT organization is to offer and what capabilities need to be developed. Its goal is to make the IT organization think and act in a strategic manner. • Service Design - To design new IT services. The scope of the process includes the design of new services, as well as changes and improvements to existing ones. • Service Transition - To build and deploy IT services. Service Transition also makes sure that changes to services and Service Management processes are carried out in a coordinated way. • Service Operation - To make sure that IT services are delivered effectively and efficiently. The Service Operation process includes fulfilling user requests, resolving service failures, fixing problems, as well as carrying out routine operational tasks. • Continual Service Improvement - To use methods from quality management to learn from past successes and failures. The Continual Service Improvement process aims to continually improve the effectiveness and efficiency of IT processes and services, in line with the concept of continual improvement adopted in ISO 20000 (Kempter, 2019). The thesis will focus on service operation because of the problems in the company's IM, which falls into this stage. Nevertheless, a proposition for general improvement of service operation for any company can be given. The importance of good service operation management can be seen from its function as an alignment of day-to-day activities in the business process to maintain the quality of service provided by the 21 LITERATURE REVIEW organization (Ratnawati, Huda, Sopiana, 2021). Since the operations occur on a recurrent basis, choosing them for improvement, or at least their examination, could be one of more optimal strategies for business efficiency increase. Request Fulfilment Access Management Request Fulfilment Access Management Event Management Incident Management L Facilities Management Problem Management IT Operations Control Application Management Technical Management Application Management Technical Management 22 LITERATURE REVIEW Figure 1- ITIL Service Operation (Kempter, Kempter, 2019) Similarly to the general proposition for improvement of service operation, a proposition for IM can be made as well. Despite the existence of some IT frameworks to assist organisations in ITSM implementation, some organisations still struggle to understand the conceptbehind ITSM, how its processes are implemented and how to identify which process should be implemented first. However, one of the most implemented ITSM processes is the IM process (Faustino, etal., 2020). Due to its prevalence, examining IM more closely might be advantageous for businesses at large. IM, as defined by the ITIL, is the process through which IT support organizations manage to restore normal service operation after a disruption (Bartolini, et al., 2009). IM also encompasses the area of EP. ITIL incident escalation is recognition that if an incident cannot be resolved at the first point of contact - namely the service desk, then it must be passed to a second level support group. This escalation is referred to as functional escalation (The ITSM Encyclopedia, 2007). In this instance, the second level group refers to relevant personnel to receive support as quickly as possible. A typical example would be to send an on-site technician or seeking assistance from certified support staff (Process Street, 2020). Hierarchic escalation is typically required when an incident is of a serious nature, or a multiple set of incidents mean that the resolution for the set of incidents may take an excessive amount of time. Hierarchical escalation is an escalation up the management chain (The ITSM Encyclopedia, 2007). Typical examples of such an escalation would be escalating to incident manager, manager of the data processing centre, or the CIO himself (Process Street, 2020). 23 LITERATURE REVIEW Incident Met Web Telephone Incident Confirmation Incident Records Incident Classification Incident Priority Initial diaanosis Investigation &diagnosis Resolution and recovery Incident Close Email To Significant Incident Proce« To Escalation Process Figure 2 - Generalised incident management (Zhang, Cao, 2016) Due to the competitiveness of the market, organisations want to provide a service of excellence to their customers, and one way to do it is to minimise the negative impact of service interruption on businesses by implementing IM correctly to restore services promptly (Yun et al., 24 LITERATURE REVIEW 2017). Therefore, it is imperative for any company within the IT service sphere to have their IM process as flawless as possible. Zhang and Cao in their process diagram do not go into extensive detail about how incidents occur, as such, the thesis will elaborate. It will also revisit and put into context the diagram from Figure 1, and explain how other parts of it interact with IM. The Incident Confirmation part of the diagram shows a moment in time when an incident is acknowledged and passed into the system, it takes as input IM, Web, Telephone and Email. The last three elements belong in the Request Fulfilment from Figure 1. Request fulfilment is the process of resolving a customer's service request and refers to managing the entire lifecycle of all service requests. The service desk team is dedicated to responding to and fulfilling requests while delivering the highest level of service support quality to the customer (Atlassian, 2020). Service requests are mostly minor changes, such as requests to change a password or requests for information (Kempter, 2020). Incidents which come from requests are most often related to customers, as such they can be thought of as human-invoked incidents. Consider the notation "human-invoked", as the incident arises from an interaction with a human, that is, a customer, even though the incident itself might be due to a technical error, (e.g., a service that the customer is paying for is slower than agreed upon). However, they are not the only sources of incidents. In juxtaposition to these human-invoked incidents, lies non-humaninvoked incidents, or incidents that arise from interaction purely technical. The incidents of this category fall under the Event Management sphere from Figure 1. Event management is the process of monitoring, responding, and resolving the events triggered in infrastructure through a lifecycle approach. A generic event's lifecycle can be represented through phases starting from notification, registration, categorization, prioritization, diagnosis, resolution, and closure (Tambrali, 2021). The objective for the domain is to provide a constant stream of operational information about the infrastructure., which in ITIL is comprised of Configuration Items (CIs). A CI in ITIL is defined as any service component, infrastructure element, or other item that needs to be managed to ensure the successful delivery of services. They can range from an entire service, which may consist of hardware, software, and documentation, to a single program module or a minor hardware component (IBM, 2023). More important however, is the motivation behind event management, especially 25 LITERATURE REVIEW in its relationship to IM, as it provides a provides a proactive mechanism for early detection of incidents (Tambrali, 2021). Event management passes inputs to IM if monitoring systems identify a condition that requires a response (Kempter, 2019). Having clarified the inputs of IM, it would seem appropriate to also shed light on its outputs, as they can seem unintuitive. When an incident is resolved, business operations are returned to normal, nothing has been produced, no service has been delivered, no value created. However, there is information about the incident, how it was resolved, what were its causes, etc. This information is the key output for IM and represents and input for an area that is linked to it, namely Problem Management. A problem is simply a cause, or a potential cause, of one or more incidents (Dalton, 2021). Problems are handled through problem records, which hold information about the symptoms, affected services, business areas and so on. The main motivation of problem management lies in its analysis of incidents. The analysis serves to identify root causes of incidents, especially since a single root cause can lead to distinct types of incidents. It also provides a way of measuring their overall impact on the business (Dalton, 2021). The identification of root causes is vital for their subsequent removal or mitigation, reducing the overall number of incidents within the company. The best way of dealing with incidents is to prevent them from happening, as such, any modification or process restructuring of IM, will have effects on problem management as well. The step-by-step specific documentation that ITIL V3 provides has earned itself not only a positive, but also negative reputation. ITIL is frequently perceived as overly wordy and bureaucratic while agile and lean methodologies are often positioned as a rejection of heavy-handed process and governance (Smith, Rahman, 2017). Over the years, ITIL has changed its focus in their latest evolution from V3 to V4, shifting its focus from processes to a set of 34 best practices, ITIL defines practice as a set of organizational resources designed for performing work or accomplishing an objective (Agutter, 2020). These practices offer companies increased flexibility to implement specific processes aligned with specific needs of their customers and innovating processes to embrace modern ways of working such as DevOps (Mathenge, Stevens-Hall, 2019) or the aforementioned agile and lean methodologies. It is important to note that the 5 stages and ITIL V3 processes have not been invalidated with the release of ITIL V4 and are still widely used (Kempter, 2019). Many companies, including the one within this thesis, use a combination of V3 26 LITERATURE REVIEW and V4, using the predefined processes from ITIL V3 as templates, ready to be customized and tailored to their needs with the principles from V4. To achieve the best characterization of ITIL V4, one should look to its foundations. One of the core foundations that it is built upon, is value. Value is the perceived benefits, usefulness and importance of something (Agutter, 2020). On this value, V4 built a Service Value System (SVS) which, being a stand-in for the service providing company, can be regarded as a system that converts demand from a myriad of sources into value for multiple stakeholders. (Anand, 2019). The main part of this SVS is the Service Value Chain (SVC), which contains activities that every service management practice contributes to. The activities in the SVC in- clude: • Plan - Interacting with external stakeholders to provide a good understanding of needs, to promote transparency, and to foster good relationships with all stakeholders. • Improve - Creating a shared understanding of the vision, status and improvement directions for all products and services. • Engage - Ensuring continual improvement of products, services, and practices across all value chain activities • Design and Transition - Ensuring that products and services continually meet stakeholder expectations for quality, cost, and time to market • Obtain/build - Ensuring that service components are available when and where they are needed, and that they meet agreed speci- fications. • Deliver and Support - Ensuring that services are delivered and supported according to agreed specifications and expectations. (Anand, 2019). These collectively are the pillars upon which ITIL V4 stands and through this value-oriented lens, are all the best practices that it offers, viewed through. The service management practice of IM falls under the Deliver and Support activity. The best practice of ITIL V4 concerning IM can be summed up accordingly: Incidents need to be logged, prioritised and resolved within agreed timescales. They might be escalated to a support team for resolution, depending on the product or service affected and how quickly the resolution is required (Agutter, 2020). Besides the general prescription, V4 also offers additional activity explanations in the IM practice. 27 LITERATURE REVIEW • Design the IM practice: the practice must react appropriately to different incident types, depending on their impact. Major incidents and information security incidents might require special handling • Prioritise incidents: incidents with the highest impact and urgency need to be resolved first. Classification and timescales are agreed with customers • Use and IM tool to log and manage incidents: the tool may provide links to changes, known errors and knowledge articles. It may also provide incident matching and links to problems (Agutter, 2020). To summarize, ITIL V4, by throwing out the rigid predefined process prescriptions, opened itself up to be more malleable and subject to a greater degree of interpretation. This of course does not always have to result in better outcomes however, as is the trend with adoption of ITSM, some companies might not have the capacities to invest, learn and figure out how to apply these principles for their own needs. For some companies even, straightforwardly defined processes might even be better, like those presented in ITIL V3, as they are told from the beginning what to do and how exactly to do it. The reasons given could explain why ITIL V3 is still largely used, as mentioned previously. Nevertheless, when it comes to combining ITIL with other frameworks and methodologies, such as agile, V4 is more welcoming to the subject in comparison to its straightforward predecessor. 2.4 Agility in Service Management ITSM, agile, and lean are all focused on the same thing: How to get valuable work done quickly and efficiently in the complex world of IT in order to enable a business's competitive edge (Smith, Rahman, 2017). This gives rise to the opportunity of combining various frameworks and methodologies to compensate for their individual shortcomings and achieve superior results. This thesis will focus on the combination of ITIL with the massively popular agile methodology. The main principles of agile go back two decades ago, with the introduction of the agile manifesto in 2001 by a group of software engineers. Agile is introduced through the four core values, and twelve principles set out in the Agile Manifesto (Indrasiari, etal., 2021). Omitting the values themselves, although one of them will be a temporary point of contention, a general idea of agile can be summed up as follows. Agile is 28 LITERATURE REVIEW an iterative approach to project management and software development that helps teams deliver value to their customers faster. Instead of wagering everything on a large launch, an agile team delivers work in small, but consumable, increments (Atlassian, 2009). As well as agile software development concepts consider reducing planning complexity, focusing more on customer value, and creating a beneficial climate of participation and collaboration (Stober, Hansman, 2009). Today, agile software development has penetrated to most IT companies across the globe, with an intention to increase quality, productivity, and profitability (Ali Babar, Brown, Mistrik, 2014). In line with the aforementioned trend of "extracting IT principles outside of IT realm" agile has penetrated into the non-IT sphere of businesses, who use its principles to achieve their goals, coined as Enterprise Agility (Mundra, 2018) and Business process agility (Raschke, 2010). Conceived as a second-order formative construct formed by responsiveness, reconfigurability, employee adaptability, and a process-centric view (Raschke, 2010). This view interestingly goes against the first tenet which was mentioned in the Introduction "Individuals and interactions over processes and tools" (Beck, etal., 2001). Since agile methodology does not give processes importance, restructuring processes using agile methods might be undesirable. Mundra and Kohlenbach both point towards this problem and remind that this statement needs to be read within the context of the last tenet in the Manifesto. "While there is value to the items on the right, we value items on the left more" (Mundra, 2018). Even though one of the four main values of agile is "individuals and interactions over processes and tools", anyone who has any experience with the approach knows that good processes are vital to making agile work (Kohlenbach, 2022). Seemingly, the agile methodology can be used for process-specific purposes, however similarly to ITIL, agile is not without its critics. Agility gets hailed as the new order for organizations striving to unlock value in an uncertain and rapidly changing market environment. As a philosophy, agility has few tangible downsides, however relies on being applied for the correct reasons, in the correct places and in a correct way. Done well, it delivers tremendous impact. Misused, it can trigger disruption and productivity loss. Agile principles are universal, but their application varies depending on the work targeted (e.g., product development vs. sales operations). Emulating someone else's model without a clear vision and 29 LITERATURE REVIEW deep understanding of agile can cause significant harm (Mahadevan, et al., 2018). The criticism expresses the need for specificity, demonstrated further by Smith and Rahman. Attempting to copy exact methods out of a book without understanding the context where they are being applied (business needs, environment constraints, existing processes, etc.) is at best a waste of time and money and likely will only make existing problems worse (Smith, Rahman, 2017). Combining agile with a different framework, intends to mitigate its drawbacks, demonstrated by the appropriately named article "Have we taken Agile too far?", which calls for its combination. Agile is a powerful process for product development, but many organizations are taking it too far and using it to avoid careful planning and preparation. They will get a better result if they combine it with a different approach that we learned working as executives at Amazon. Working backwards can make up for its shortcomings in the crucial early stages (Bryar, Carr, 2021). The combination of ITIL and agile in the context of this thesis will strive to increase the agility of IM, however, presenting an answer to what that means is not trivial. Some interpretations do exist. Making IM process more agile means stripping out every step that has no customer value or adds nothing to their experience. Doing so means a critical analysis of current processes must be carried out, with every step being evaluated. The specific analysis is based on whether value for the customer is being created in each step of the process (Louisnord, 2018). If the agile methodology is incorporated into an IM process, it will not only automate the lifecycle progress but also reduce the escalation rate of incidents in an organization. An agile IM consists of steps like- lifecycle management, data collection, association, description, and adaptability. On the other hand, an ITIL IM process consists of steps like inputs, identification, logging, classification, prioritization, initial diagnosis, escalation, investigation and diagnosis, resolution, and closure (KnowledgeHut, 2017). However, the accuracy of these interpretations is up to debate, as for example in the process step of incident logging logging itself does not create or possess any inherent value for the customer, yet removing it does not seem to be appropriate. The interpretations do seem to share a common idea, that being a faster, responsive and adaptable IM. Nevertheless, a more nuanced view exists. The agility can be thought of as simply the summation and adherence to the original values of the agile manifesto. Shannon Winter, a product marketing manager at Atlassian points to this by showing how adherence to manifesto's values, 30 LITERATURE REVIEW produces a more agile IM. For example, by adhering to the first principle of preference of individuals over processes, she gives importance to communication between people. Communication is crucial when an issue arises, whether it is a small bug in production or a total system failure. Even the most complete incident plan requires frequent communication with customer in order to reach resolution and maintain trust (Winter, 2018). In conclusion, agility in service management seems to be a rather fickle subject with no clear definition. Nevertheless, the thesis will strive to shed more light on it. 31 METHOD 3 Method 3.1 Goals and procedures The goal of the thesis is to provide insight between how ITIL and agile frameworks can interact with one another in a specific business environment. Firstly, the company's IM (including the main IT systems used in it) will be analysed, as well as their relationship to ITIL. The company's IM problems will be defined following a short ITIL retrospective, demonstrating that implementing ITIL in a company does not mean a seamless flow of operations. After the problems are established, a documentation of the "agile" changes that the company made will follow and explanations will be given how these changes solve or mitigate the defined problems. The agility of these changes will also be elaborated on. Through these steps the thesis aims to fulfil its goal. Concerning procedures and my role in the company, I was accepted to document and analyse the company's problems and solutions, being accompanied by the company's senior manager, or more specifically in the company's hierarchy, a Senior People / Line Manager and Senior Chapter / Squad Lead (the manager indeed has multiple positions in the company). All the information regarding the company's processes, their perceived inadequacies as well as the systems used that this thesis will build upon and analyse in later parts will have been provided by the manager in question. 3.1.1 Data sources and collection The question of who will be providing the information required for this thesis has already been answered. There are two more questions however, that need to be answered. • What is the type of data collected? • What ways and methods will be used to collect the data? The answer to the first question, regrettably, is not simple. Types of data in the context of this thesis can be split into two categories, quantitative (statistical) and qualitative (non-statistical) (Saunders, et al., 2012). Most of the data collected will be qualitative, (description of IM and EP). The problems the company faces will also have a qualitative character, as they all deal with how operations work, explaining their 32 METHOD functions and cannot be easily represented in a mathematical format. Nevertheless, a certain part of the data collected will have quantitative character (e.g., how many incidents were in the ticket queue). As such, the methods chosen to extract these data will have to account for this reality and be tailored accordingly. The method used for data collection, considering previously discussed matters, will be a research interview. Research interview is a purposeful conversation between two or more people, requiring the interviewer to establish rapport, to ask concise and unambiguous questions, to which the interviewee is willing to respond, and to listen attentively. It is about asking purposeful questions and carefully listening to the answers to be able to explore these further (Saunders, et al., 2012). There exist several metrics by which interviews are grouped by types, the most common of these is a typology related to the level of formality and struc- ture. • Structured • Semi-structured • Unstructured or in-depth interviews (Saunders, et al., 2012) From these, for the purpose of this thesis the most optimal will be the semi-structured interview. Researcher will have a list of themes and some key questions to be covered, although their use may vary from interview to interview. The order of questions may also be varied depending on the flow of the conversation. On the other hand, additional questions may be required to explore your research question and objectives given the nature of events within organisations (Saunders, et al., 2012). The explanation for the superiority of this type of interview over the others lies in the hybrid type of data collected. The mix of quantitative and qualitative elements discourage the interview to be conducted via a form of a strict questionnaire for example, as that would rob the thesis of context, whereas completely unstructured one would have trouble capturing some of the numbers The themes and their questions of the semi-structured interview will be presented below to give an idea how it will be conducted: • Information Systems in the company • What systems are used in the company for IM? • How are they connected? • IM • How is IM conducted in the company? • EP 33 METHOD • How is EP conducted in the company? • ITIL • How does the company use ITIL? • Problems • Describe the problems the company had faced with its IM / EP processes. • Changes • Were there any previous changes the company has made in its operations? • Agile • Concerning agile, was it used primarily as an umbrella term, or was there a more specific meaning to it in relation to the changes the company has made? 3.2 Description of the company The examined company, _ Solutions, is located in eastern Slovakia. In the past, the company has served as a centre of various supporting services for a plethora of different information technologies, from operating systems, ERP systems all the way through specialised customer applications. Nowadays, its main market can be categorised into administration of information and communication technologies, or ICT in short. The company itself is now a part of a large multinational corporation with market and influence spanning across the entire Europe. The company is one of the biggest employers in eastern Slovakia with more than 1000 employees. 3.3 Information Systems Analysis Considering the size of the examined company, as well as its affiliation with a multinational corporation, a detailed description of all the systems and applications within the company is far beyond the scope of this thesis. Nevertheless, the thesis will focus on the systems and applications with highest degree of influence and usage concerning the management of incidents, namely ITSM ticketing tools with a modicum of light shed on monitoring tools as well. 34 METHOD 3.3.1 ITSM Ticketing Tools and ITIL Before delving into specific software, some characteristics and principles that are the same or only slightly modified between various ITSM ticketing tools, will be presented. These systems primarily work on an objectoriented basis. Meaning that the system has some predefined classes and then creates specific instances of these classes called objects, these objects hold some information through attributes or fields. Each of these systems has a main page which can be modified and customised depending on the viewpoint of who is looking at it (e.g., a system admin or a CEO of the company). Based on these customizations, the main page (as well as other pages) then presents different data to the user. For navigation purposes, a search bar is present where pages relevant to the entered query are presented, beside the search bar, navigation can be done through standard clicking fashion by selecting related information and then clicking through the links until the desired page is reached. When it comes to information about the objects stored within the system, each unique object has a separate page containing its fields, as well as links to related information (e.g., its parent object). The main system that the company has primarily used for reporting and IM was the HP Service Manager 9 (SM9) software. SM9 is an onpremise ITSM software tool primarily used for incident ticketing, the SM9 has pre-built and predefined several key processes and concepts based on the ITIL framework. It needs to be said that this connectedness between ITIL and ticketing tools is not exclusive to SM9, other tools (such as the one in later part of the thesis) share it as well. As such, a joined analysis examining both features of these ticketing tools as well as their connection to the ITIL framework will be performed. 35 METHOD SERVICE MANAGER « Favorites and Dashboards Change Management Configuration Management Help Incident Management Incident Queue New Incident Search Incident SNOW ticket? Problem Management Service Desk Archive Publisher Subscriber Miscellaneous Calendar Dashboard My Environment My Homepage Password Change To Do 0 jeue (SM) J Search for Ticket. CI name and more | TODODefault | IncidenTQueue: Incidents by Assignment Group • | Create New Incident • | ® Cancel B 5ave & Exit B Save Q. Find i f Fill • Apply Template I More v Incident 111 | IM0058044620 Incident Type: | NOME Title: J | Details General Attachments - 0filefc)attached Cust. Info Customer Location Category 1: Ca-e-j-: -y 2: Ca_ e-;o'v 4: AssignmentGroup: -s: = = : Notified by: + o ' •* Figure 3 - SM9 Incident page SM9 software comes pre-configured with the most basic ITIL differentiation of change, asset, incident, and problem management, as can be seen on the left panel of Figure 3. This differentiation is consequently carried into the predefined classes that the objects created within the system (e.g., a problem or an incident) follow. It is worth to mention that these predefined ITIL adhering classes cannot be changed. As such, any company that acquires SM9 or other versions of the system is already introducing ITIL into their ITSM processes. The system also supports management of CIs (another ITIL related term introduced in the Literature Review) in the Configuration Management section on the left panel. Complex filtering using advanced filter logic is not possible. Grouping objects on the other hand is, as can be seen on the header of the page denoted under Incident Queue: Incidents by assignment group. Concerning incident objects themselves, it is important to discuss what information do they store. From Figure 3, the fields highlighted by a red star are mandatory. Title and Customer fields are self-explanatory, the Category 1 and 2 fields are not. The reason why only 2 of the 4 category levels are mandatory within the company configuration of the system, is that the company could sufficiently categorize an incident based on 2 levels of categorization. The categories are shown below: 36 METHOD I I Category 1: * ITRAINI N G | V Category 2: * 7?? Category 3: ACCESS CENTRAL SERVICES Category 4: COMPLAINT Search in Categories: DETAILED CATEGORIES Assignment Group: * HARDWARE INFORMATION Assigns?: INFRASTRUCTURE T Notified by: Phone V + Figure 4 - Category level 1 s Select subcategory X Category 2 Category 1 ? ??? ADMINISTRATION ACCESS — AUTHORISATION ACCESS • AUTHORIZATION ACCESS BUSINESS APPLICATION ACCESS GROUP MANAGEMENT ACCESS LOCAL CLIENT ACCESS — OTHER ACCESS — PASSWORD ACCESS USER MANAGEMENT ACCESS BUSINESS APPLICATION CENTRAL SERVICES FILE CENTRAL SERVICES — GROUPWARE CENTRAL SERVICES — INTEGRA CENTRAL SERVICES MAIL CENTRAL SERVICES MOBILE DEVICE SERVICES CENTRAL SERVICES MYCARD ZENTRAL SET, CE.: • 1 to 1 « of 143 1 Show 2000 1v 1 Back Figure 5 - Category level 2 It is worth to mention that this categorization (system-default, however possible to customize) goes hand in hand with the "prioritise and categorise incidents" from the best practice guidelines for ITIL IM. The 37 METHOD Group fields on the incident object are groups responsible for handling the incidents. Apart from these mandatory fields, there is also a value called Priority on the incident object. This value is used for the computation of standard service license agreement (SLA) duration, which is a duration during which the incident should be resolved. The subsequent SLA is represented as a time value within the system (e.g., 1 month). Incident, apart from its information, has an important parent object called problem. As was stated in the Literature Review, a "problem is a cause of one or more incidents", therefore the object-oriented design of problem being the parent object for incident is perfect for displaying this relationship. These problems are located in the Problem Management section of the application. Any given problem within the SM9 system holds the collection of all incidents related to it. Complementing the IM within the SM9 system is the closely related EP. The word process being vital as a distinction as the SM9 does not have a predefined class for escalation objects and neither does it store them. The escalation is handled via a set of escalation rules which can be configured based on the company's needs. The main parts of the configuration are defining the entry criteria for escalation and subsequently defining the change in escalation level that should follow upon meeting the criteria. The escalations themselves are then part of the incident object as a true/false value. ITIL V4 IM best practice also calls for an implementation of a knowledge library for IM. Later versions of SM do have this library implemented as a collection of stored documents which contain information about past solved incidents, namely description of the incident and methods of solving it. Regrettably, the SM9 that the company was using did not support any sort of semi-automated knowledge library. The knowledge regarding incidents and their viable solutions was passed by shared documents between members of the team responsible for incident handling. 3.3.2 Monitoring Tools and Servers Hearkening back to the division of incidents based on their initiation by a human or non-human entity, the monitoring tools of the company serve to cover the latter half of such incidents, which fall into the Event Management practice. The company uses primarily two tools for their monitoring operations. 38 METHOD Micro Focus is used for the company's distributed control system whilst Nagios is used for native environment. The specifics of these software tools are beyond the scope of this thesis. However, a general description of their functionality can be summarized as follows: Each of these systems receive IP address of the computer or server they are meant to monitor as well as a configuration file. This configuration file specifies what sort of information should be monitored and relayed by the service (e.g., CPU load, disk space, memory usage). This information is then presented in a compact form grouped by the individual servers or computers. Both applications offer overview views of the entire system of interconnected servers for increased clarity. It must be noted that the word phrase "interconnected servers" ties only to the context of them being monitored together. The servers themselves run siloed on their own and operations on them must be performed separately for each server. 39 RESULTS / ANALYSIS 4 Results / Analysis 4.1 Process Analysis and Problems Before delving into the specific processes of IM and EP, the first point of examination should be the system communication between the SM9 ticketing tool and Microfocus / Nagios monitoring systems. Currently there exists no direct communication between these systems, the systems run completely siloed from one another. When the monitoring systems report an error of any kind, the responsible technician of the company must contact (either via email, or phone) the service chain operating manager (SC OPM) or service centre (SC) operator to notify him about the occurrence of the incident so it can be logged. The operator has to create an incident object within the SM9 system, fill in the details regarding the incident from the information obtained by the technician and then give him a confirmation about the successful creation of the incident. The communication process can seemingly be evaluated as ineffi- cient. 1. Problem 1 The ticketing and monitoring systems of the company are siloed, leading to inefficient communication process. The reasoning for this is as follows: • Not clear who the technician should be notifying, sometimes it is the SC OPM himself, other times it is the SC operator. • Time spent relaying the information from one person to another, with possible additional checks to verify the exactness of the infor- mation. • The technician does not always have the information from the monitoring system at hand, so it is possible that an error goes unnoticed. The last point has happened on several occasions within the company, where a customer has called, demanding a fine to be paid for the unavailability of the servers. 4.1.1 Incident Management The entry point to the IM process would primarily be the service desk, as per standard ITIL recommendations (SC in the company terminology). 40 RESULTS / ANALYSIS Occasionally, frustrated customers would contact the SC OPM directly via email to notify them about their problems. Nevertheless, standardly, a customer would call in to the SC and relay the information regarding their incident. Based on this information a subsequent incident ticket would be created and the mandatory fields filled in by the operator. When creating the ticket, its corresponding prioritization is also needed. Concerning the priority value, the company had 5 distinct priority values possible on the incident object with each value having a corresponding standard SLA value associated with them. The relationships between these values are in the table below: Table 1 - Priority to SLA table Priority Value Standard SLA 1 1 week 2 1 month 3 2 months 4 6 months 5 1 year With the relationship clear, the priority determination can be investigated. Two new variables have to be introduced that are used in the company called Customer Business Impact (CBI) and CI Criticality. CI criticality is a measure of multiple factors of the CI, namely its performance and availability to the customer represented through maximum allowed service downtime. Through the CI criticality, the customers choose what services to purchase from the company, with the ones with highest CI criticality being also the most expensive. The definition of CBI is relatively vague, the company uses it as a measure of impact that the incident has on the company and the customer, the value is highly corelated to the priority value and it is computed through a matrix presented below: 41 RESULTS / ANALYSIS Config item (CI) Impairment Cicriticaiity: Critical Top elements Cicriticaiity High Top dements Cicriticaiity Medium Non-lop elements CI critcality: Low/None Non-top elements Total failure/ contract disruption 1 CBI = Critical 1 CBI = Ugh 2 CBI = Medium 3 CBI = Low High application/service degradation SLA-related service incident CBI = High 2 CBI = Medium 3 CBI = Low 4 CBI = None Partial failure/ medium application/service degradation Business-related service incident 2 CBI = Medium 3 CBI = Low 4 CBI = None 5 CBI = None Low applicab'onfsereics degradation Process disruption 3 CBI = Low 4 CBI = None 5 CBI = None 5 CBI = None Incident wiffl lowJno impact 5 CBI = None 5 CBI = None 5 CBI = None 5 CBI • None Figure 6 - CBI calculation matrix The correlation between priority value (the numbers in the matrix) and the CBI can be seen, as the higher the number is the higher the CBI level is as well, however the value 1 can be represented by both High CBI and Critical CBI. In addition, the CBI values were not clearly defined, for example the value Critical sometimes meant that the incident needed to be resolved in the day it was reported, other times it meant it needed to be resolved in 3 days because of some customer specifications. These specifications and modifications could not be put into the system in any conspicuous manner, and most of the time they were simply written into the description section of the incident. These sections were not always noticed which led to frustration on the customer's end and an increased need for escalations. The escalations themselves were done during business hours and if the escalation were to occur outside the business hours, either it would get delayed until the next day, or if the incident was of serious enough nature, the managers and technicians had to be contacted outside business hours (sometimes late at night) to solve the issue. 2. Problem 2 Inaccuracies and inconsistencies in the company's evaluation criteria led to an increased number of escalations within the company, increasing the chance of them falling outside business hours. When the incident was created and reviewed, it needed to be passed onto a person with adequate skillset to solve the issue. A group of the company's employees called the operating team (OT) were responsible 42 RESULTS / ANALYSIS for solving the incidents. The individual members of the OT were also members of various assignment groups (one member of the OT was a member of multiple assignment groups). The tickets were put into a ticket queue and from this queue they were assigned to the assignment groups. However, there were no rules dictating which member is supposed to solve which incident. The incident queue also did not use any filters. 3. Problem 3 Lack of personal responsibility for incidents led to members of the operating team choosing via their own discretion which incidents they will solve, resulting in stacking tickets in the queue. The reasons for this are as follows: • Discretion of the OT did not guarantee any prioritization of incidents based on remaining SLA. • The discretion also led to the OT choosing incidents based on their difficulty to solve, rather than their Priority All of this led to the ticket queue lengthening, which made the absence of proper filtering increasingly noticeable. This led to OT members forgetting many of the older tickets as they could not easily filter over the queue as well as the fact that many of the tickets were of low (3) priority with standard SLA of 2 months, making the OT inefficient in their operations. The inefficient operations led to even more tickets arriving and the loop repeated itself. The result was that at the worst point in the company's operations, the incident ticket queue was over 550 incidents long with many of the tickets being over a year old. During the entire incident resolution process, the customer had no other way of checking the state of their reported incident besides directly calling the OT member and asking them for specifics. As such, when the incident was assigned to the assignment group, the phone number of the OT member was given to the customer. Since one OT member was part of multiple assignment groups, he had to personally notify the SC desk that he took charge of the incident resolution so his number could be given to the customer, or if the incident was urgent, the OT member himself called the customer as a way of providing his phone number. The communication between the OT member and customer was purely phone based. 4. Problem 4 43 RESULTS / ANALYSIS Highly ineffective and non-interactive method of communicating incident status to the customer led to unhappy customers. Coupled with the fact that when an unsatisfied customer voiced their feedback, they had no formal method of verifying if the feedback was noted down and passed onto higher management of the company. The only assurance the customer had at their disposal was the word of the OT member, or the SC operator they were calling with. The IM improvement process falls within the ITIL V4 continuous improvement guidelines, which shows another element of ITIL that the company had implemented, however its specifics were not handled in an optimal way. Every 2 weeks, a service meeting was held within the company. The topic of the meetings' discussion was an action item list. The elements of the action item list were varied, including migrations, projects, server patching and improvement areas. The method of defining what an improvement area is, was simple. Anything the customer reported as a problem was considered a potential improvement area. Immediately, it can be stated that the entire improvement process was reactive, rather than proactive as it waited for a self-initiated input from the customer before an improvement was considered. Additionally, the structure of the service meeting where the projects for example, were not separated from improvement areas as well as the fact that the meetings were time constrained, led to the improvement area discussion being limited or sometimes omitted entirely. 5. Problem 5 Reactive IM improvement process with undiversified service meetings where it was not a priority led to the improvement process being inefficient. When it comes to problem management within the company, there was no one personally responsible for handling problems. Therefore, there was no formal process for creating problem objects within the SM9 system. Additionally, there was no oversight whether a problem object was created at all. The company had some problems created within their system, but they were treated as an afterthought and they were left to the discretion of the individual employees or managers whether they wanted to steer a discussion for example, to discuss the problems and ways of preventing incidents related to them. 6. Problem 6 44 RESULTS / ANALYSIS No one dedicated to the problem management sphere meant that the area was left without direction which resulted in repeating incidents. It is worth to highlight that this problem is of similar nature to Problem 3, where leaving a particular area or responsibility to an individual (or collective) discretion without formal rules, checks and verifications led to inefficiencies within the company. 4.1.2 Escalation Process As per the differentiation of incident escalations described in the Literature Review the escalation structures can be split as well into functional and hierarchical. It is worth to mention that the escalation levels in the tables are sorted in a descending order, meaning that the highest level of escalation is at the top of the table. Table 2 - Functional escalation structure Team OPM (grouped by technology) SCOPM SC Table 3 - Hierarchical escalation structure Vice-president Head of Unit Head of Department Head of (technical) Team The rules and conditions of when each of the presented structures should be accessed are portrayed in the diagram below: 45 RESULTS / ANALYSIS Customer Contact Service Desk to update incident Access Functional escalation structure Handled within^ functional? Access Hierarchical escalation structure Figure 7 - Escalation Process The EP then is as follows: The customer (a person from another business) initiates the process by contacting the SC. If the customer does not get a response, he contacts his own IT department where the chief of the IT department accesses the functional escalation structure by contacting the SC OPM. The SC OPM contacts the team OPM based on what technology has been affected in the incident, as the team OPM are responsible for different technologies within the company. If the team OPM does not provide a response, the SC OPM accesses the hierarchical 46 RESULTS / ANALYSIS escalation structure and the rest of the escalations are handled there. When the incident does get updated, an email confirmation is sent back to the customer. A parallel can be seen between this process and the improvement of the IM, the parallel being that both are being initiated by the customer. More specifically, it meant that the customer had to be involved with every EP instance, which combined with the Problem 2 meant further customer dissatisfaction. 4.2 ITIL retrospective Some of the aspects of ITIL were already brought to light when examining the processes within the company, this section aims to organize them more thoroughly and use them as a proof that even though a company runs ITIL and fulfils many of the requirements the framework presents, it does not necessarily mean a flawless or even an efficient run of operations within the company. As ITIL has steered from clear definitions and step by step processes and moved onto general guidelines and best practices, as discussed in the Literature review, the details of how these guidelines are implemented within the company are the deciding factor in the success of its operations. The standard categorization of areas in Figure 1 and which were discussed in the Literature review is present and adhered to in the company. • Event Management - Through the company's systems Nagios and Microfocus which check the status of its service providing servers. • Request fulfillment - Through the existence of SC, the customers have a direct link to the company and can communicate their issues. • Problem Management - Simply through acquiring SM9 software, the company already supports problem management sphere through SM9's preconfigured ability to create problems within the system and link incidents to it. Despite this, event management is inefficient because the information provided by the systems is not always acted upon because the systems are not connected. Request fulfilment provides a direct link, but the direct link is the only link that the customers have, forcing them to make repeated calls to check on their incident status. Problem management is supported, however no one is responsible for it, as such it is treated as an afterthought. 47 RESULTS / ANALYSIS IM itself can be looked through two lenses, one being ITIL V3 rigid process structure and the other being ITIL V4 general best practices. If looked at through purely process based lens of V3 and taking Figure 2 as a template, almost all of the process steps are present in the IM of the company as well. The first four steps of the diagram (incident confirmation, records, classification and priority) are handled through SC which confirms to the customer that the incident was registered and the SM9 software which comes preconfigured with categorization options, as well as the priority calculations. Significant incident decision is present as well, however the only thing that differentiates a significant incident in the context of the information system SM9, are notes in the description section of the incident ticket, which as was discussed, were not always noticed, thus escalations had to occur. The escalation decision as well as resolution and incident close are present. The initial diagnosis and investigation & diagnosis steps of the IM are arguable, considering what was analysed. The initial diagnosis step is a precursor to whether an escalation will be needed, however the customer was the one who initiated the EP. Therefore, it can be stated that the initial diagnosis is not part of the company's IM, at least on the side of the company. The investigation & diagnosis can be considered present, since the SM9 software does support creation of problems which are used in this context for diagnostical purposes (finding / diagnosing the cause), however considering Problem 6, it can be argued if this step is truly present. The thesis' conclusion is that the step is not consistent and therefore should not be considered present within the IM. The ITIL V4 lens presents a more nuanced view. However, even in this version, the company adheres to most of the IM principles that the V4 calls for, namely: • "The practise has to react appropriately to different incident types." - The company's IM does react with variety through its CBI calculation matrix. • "Prioritise incidents. Incidents with the highest impact and urgency need to be resolved first." - The CBI calculation matrix is used to derive the SLA value of the incident, which serves as a benchmark for when and which incidents need to be resolved first. • "Use an IM tool to log and manage incidents." - The company uses SM9. The best practice that is amiss is the presence of an organised knowledge library. 48 RESULTS / ANALYSIS The key characteristic that the company is conceivably missing from the ITIL V4 recommendations is value. The value upon which V4 builds itself through its SVC as shown in the Literature Review. There is no proactiveness in the company's IM workflow, most of its operations are reactive, where the customer is the one steering events. There is no active collaboration between the company and its customers and most importantly, there is little conversation about improvement. As was discussed in the very beginning of this thesis, the IT sector is highly competitive and rapidly changing, and a company in this sector that is not willing to improve is a company doomed to failure. 4.3 Changes & Improvements The company went through a larger restructuring after it has become a part of the multinational mentioned in the Company Description section of the thesis. Part of this restructuring was an implementation of a set of proposed changes and improvements to its IM area. This section of the thesis will aim to serve as a list of these changes with corresponding explanations how these changes solved or improved the problems highlighted in section 4.1. A proposition was given based on the inadequacies of the SM9 to switch to a more modern solution. The implementation of the switch was the transition to ServiceNow ticketing system. ServiceNow has much of the same functionality as SM9, since they are the same type of system, the main difference being that ServiceNow is cloud based whilst SM9 was an on-premise solution. It also provides enhanced capabilities such as real data reporting and easier to use filtering. The figures below are used for demonstrative purposes and easier visualization of its features. 49 RESULTS / ANALYSIS Figure 9 - ServiceNow Incident Page The similarities to SM9 can be seen from the figures, the main differentiating factor being the number of related links to the incident object itself (Figure 9 related links), making navigation in the system easier. 50 RESULTS / ANALYSIS — 88 Incident Overview T incidents Opened Today £ , 2 Open Incident; 18 Unsigned Incidents 12 Incident not updated for 7 days 10 Open Incidents older than 30 Days 7 Overdue incidents 0 Open Incident}: - Grouped Open incidents older than 3Q Days- Grouped 51 RESULTS / ANALYSIS Figure 12 - Incident reporting Before delving into a key feature that ServiceNow possesses in relation to the set of Problems, a brief showcase of a missing aspect presented in section 4.2 will be given. The missing aspect in question is the presence of an organised knowledge library (Knowledge in Figure 8). The company is able to put articles into this Knowledge section (Create KCS article in Figure 9) for employees to access. Through this the company brough itself closer to adherence to ITIL. 7. Solution - Problem 4 The key feature of ServiceNow is the customer self-service portal. Within IM, this portal allows customers to submit incidents themselves and fill out the required fields. When the incident is confirmed, the portal represents an interface between the customer and the company, where the customer can view the status of their incident, mitigating Problem 4. 52 RESULTS / ANALYSIS . . B — , • • < , , e S6rVICÔ Knowledge ServMe Cmtof Requests.* SystemSUtus BCart Joe Employee Home > Service CaOIOf. > CanweHelpvouř > Create Incident Search Q Create Incident Create en Incident record 10 report and reouett assistance with »n issue you ire fitvtng Request assistance with an issue you are having. An incident record will be created and managed through to successful resolution. You will also be notified of progress. 'urgency |»-H» | - | Measured the business critically Based on the impact and on the buvness needs oi the Customer, Togetfiei with impact, it is the major me*m of assigning priority lor dealing with * Please describe your issue below • ^^^J & Add attachments ^ . ^ f a M l l M f f K B l Figure 13 - Incident Page through Self-Service (ServiceNow, 2023) Unlike the previous figures, this one belongs to official product documentation of ServiceNow, as the self-service view is not available to the author of the thesis or the company's senior manager (it is available to admins / customers). However, in spite of the views being customisable, their main functionality remains the same from company to company. 8. Solution - Problem 1 The transition to a cloud-based ticketing system enabled the company to more easily integrate a software called Asset Manager to connect all the systems and applications together, namely the ticketing and monitoring systems. This increase in interconnectedness of the company's software solved the Problem 1 of the thesis, being siloing of the systems. This has prevented the company from accruing monetary losses for breached SLA due to server downtime or other errors not being noticed by the technicians, as now with all the systems connected, a procedure could be created in ServiceNow, which automatically created an incident from the information reported by the monitoring system. This meant that the time spent to create non-human invoked incident tickets was reduced to 0. 9. Solution - Problem 2 As was mentioned in the previous section, the incident description text area was primarily used to distinguish major incidents. However, 53 RESULTS / ANALYSIS since it did not have any formal rules as to what exactly should be written in the text area, the managers or OT members did not know what they needed to be on alert for and sometimes major incidents went unnoticed at first. A proposition was given to introduce a set of codewords to increase the visibility of major incidents. The implementation itself was multivariate, firstly, a shift of responsibility for handling major incidents was given exclusively to the SC OPM, introducing a personal responsibility element. Secondly, a set of labels was implemented with clear meanings which were needed to be added to the incident description. • ESC - Escalated incidents. • URGENT - Any incident that needed to be resolved on the day they were labelled. • M0R_MEET - a roundtable discussion among the technicians responsible for the given technology of the incident. These discussions were realised every day on a half hour basis (assuming tickets with these labels existed). These labels increased clarity and supported discussion among the company's employees in an effort to stimulate knowledge sharing and prevention of these incidents. Additionally, a list of VIP customers was prepared, whose tickets needed to be processed within 1 hour of their opening to further prevent escalations and inconveniences on the side of the IT management of the customer. To ensure that these incident tickets were being noticed, a role of a dispatcher was introduced dispatcher into the company's ranks. The list of VIP customers was always made accessible to the dispatcher. Among their responsibilities was that as soon as a ticket from one of these VIP customers was opened and appeared within the incident queue, the dispatcher immediately raised the priority level of the ticket and appropriate actions underwent to deal with the incident. Through these measures the Problem 2 of the company was mitigated, as customers who were escalated on an almost daily basis are now rarely escalated. To further differentiate handling major incidents, a rapid meeting was organised every time a major incident occurred, this meeting was steered by Lead Incident Manager, the point of this meeting was to solve the problem as quickly as possible and to give insight into the solution for the participants. As for the business hour issue, the company named a Manager on Duty (MoD) who would be responsible for escalations of this nature. Should the issue be serious enough, it would be escalated to the global manager on duty. This addition would not change the EP itself; it would merely modify the functional escalation structure. 54 RESULTS / ANALYSIS Table 4 - Modified Functional Escalation Structure Global MoD MoD SC operator This modification increased clarity for the company's employees as they knew who would be responsible for handling serious issues outside business hours and would not have to worry about sudden interruptions to their life outside of work. 10. Solution - Problem 3 To combat the lack of personal responsibility mentioned in Problem 3 a proposition was given to introduce the missing aspect through a dedicated employee. The implementation was the introduction of the Administrator role. Administrator was a chosen member of the OT team who was responsible for an entire assignment group. One of the administrator's duties was to accept any incident created within 24 hours and assign it to a specific member of the OT. Making use of the ServiceNow's reporting system, the company also started reporting the number of incident tickets resolved by each OT member, as well as the number of assigned tickets to each OT member. The purpose of these reports was twofold. The reporting of assignments strived to ensure an even distribution of tickets among OT members and the reporting of resolutions served as a performance indicator for employees. Apart from individual responsibility, the implementation presented a motivational element for the employees, knowing that their resolution progress was being tracked and noticed by the management through the reports. To further combat the problem, the company introduced reporting of incidents older than 30 days (seen in Figure 10 & Figure 11), to make sure that they were not forgotten with the influx of new incident tickets. As the process increased in its efficacy, this number was reduced to 10 days. 11. Solution - Problem 5 Another given proposition was to increase the proactiveness in the company's IM engagement with its customers, especially their largest ones as a response to Problem 5. The implementation was carried out by holding regular incident meetings with its customers on a weekly basis. The subject of these meetings was collection of feedback, upon which the process was modified if needed. Another set of meetings was introduced, this time within the company's ranks. The meetings were held 55 RESULTS / ANALYSIS with senior service delivery management (from the multinational) in order to share experience, these meetings occurred 3 days per week. 12. Solution - Problem 6 The last problem, Problem 6 highlighted in the thesis concerned itself with problem management, similarly to Problem 3, the notion of personal responsibility was absent. Therefore, a similar proposition was presented, designate an employee responsible for the area. The company gave the responsibility to a designated problem manager. Problem manager was contacted during recurring incidents. The manager then had to create a problem ticket within the system and bind corresponding incidents to it. He also needed to prepare pre-emptive measures for the problem's solution. These measures were presented during a newly introduced set of calls to monitor the problem event. The event was tracked this way and solutions were proposed among the problem manager and members of the OT responsible for the technology until the problem's solution was found. Upon its finding, the solution was documented by the problem manager, placed within the knowledge base as a KCS article and removed from the system. 56 RESULTS / ANALYSIS 4.4 Agile retrospective Table 5 - Summary Table Problem Solution Siloed systems Connect with Asset Manager Unclear escalation rules / procedures Labels for clarity + calls for knowledge sharing + Dispatcher role No individual assignment of incidents Administrator role for assignment to individuals Ineffective communication with customer Self Service portal through ServiceNow Reactive improvement process Proactive feedback gathering through customer calls / meetings + meetings with senior service delivery management Problem management not utilised properly Problem manager role + problem meetings / calls In this section, the thesis will seek to explore the agility of the changes and solutions to the presented Problems. The agility analysis will be done in two ways, one way will take a proverbial page out of Shannon Winter's book and examine the changes through the core tenets of the agile manifesto. The other will be carried out as a more general analysis of agility presented in the Literature Re­ view. Examining core tenets will be done in a following way. First level will be a specific tenet and second level will be a list of solutions which brought the company closer to adherence to the tenet. • "Individuals and interactions over processes and tools." • Problem monitoring calls in Solution - Problem 6Chyba! Nenalezen zdroj odkazů. • Daily half hour roundtable discussions on incidents labelled MOR_MEET in Solution - Problem 2 • 3 days a week calls with senior service delivery management in Solution - Problem 5 • "Working software over comprehensive documentation." - not applicable since company does not develop software. 57 RESULTS / ANALYSIS • "Customer collaboration over contract negotiation." • Weekly calls with customers in Solution - Problem 5 • Customer interface in Solution - Problem 4 • "Responding to change over following a plan." • Upon the feedback collected from customers, IM was modified. Concerning validation purposes of this "tenet analysis", (why were the changes assigned to which tenet), for first and third tenet it was simple. All that needed to be checked, was if the number of individual interactions or active customer collaboration increased compared to the past where these changes were not implemented. Adherence to the fourth tenet had to examine the way the company responded to change in IM. Due to the existence of biweekly service meetings, it could be stated that the company followed a plan, since even if there was important feedback gathered, it had to wait until the next service meeting until it was even discussed, let alone implemented. The proactive feedback gathering meant that the IM process was modified when a change was requested, not when a biweekly meeting occurred. The agility described in the Literature Review contained words like responsiveness (speed being tied into it) and employee adaptability. The introduced set of calls and meetings can be considered to comply with employee adaptability (calls with customer to gather feedback to adapt the process), however responsiveness seemingly cuts both ways. On one hand, the increased number of meetings and calls (especially those with senior SD managers) aims to provide employees with knowledge and expertise so they can react faster to rising issues. On the other hand, the meetings are held during business time, thus consuming it and it could be argued that the business time spent on meetings could be used to solve issues. Nevertheless, there are still two solutions whose agility was not examined. The interconnectedness of the company's systems in Solution Problem 1 certainly did increase the speed with which the company was able to function and react to different incidents, as employees no longer needed to call each other to obtain information from other systems. Nevertheless, defining any increase in speed of company's operations on the as an increase in agility seems a bit overreaching, as that would mean for example that a production company who managed to cut down its production time by X would be considered as "more agile". The Solution Problem 3 of better assignment rules introduced individual 58 RESULTS / ANALYSIS responsibility and motivation, which in turn did increase incident resolution speed, however it falls into the same problem of speed not equating agility. The thesis will conclude this section by offering its own view on agility. Any set of changes which increase the number of meaningful interactions between company employees or customers, is an agile set of changes. A meaningful interaction can be defined as any interaction which has the potential to increase the long-term longevity and efficiency of the company. For example, an interaction where a manager has to call the technician to ascertain information about servers would not be considered meaningful, as there is no efficiency increase. On the other hand, a meeting between employees to share their knowledge would be, as the shared knowledge could help other employees solve their issues faster. From this definition Solution - Problem 1 and Solution - Problem 3 would not be considered agile, whereas Solution - Problem 2, Solution - Problem 4, Solution - Problem 5, Solution - Problem 6 would be agile. It is worth to mention that solutions considered agile by this definition are the same ones that appeared in the first agile tenet analysis, demonstrating a plausible connection between adherence to agile values and meaningful interactions. 59 CONCLUSION 5 Conclusion The thesis set out to map interactions between ITIL and agile on a specific set of problems and their workarounds, in a particular area of the company's operations. As well as to highlight that these two methodologies can be combined for optimal business results. The Literature Review therefore focused mainly on ITIL, as that was the original framework that the company was using. As well as delving into agile and trying to present an answer as to what it means to be agile in an ITSM context. The ITIL analysis of the company's IM domain was carried out partially in the section ITSM Ticketing Tools and ITIL and then summarised in more detail in the ITIL retrospective section, showcasing that simply implementing ITIL and adhering to most of its principles (at least on paper) does not guarantee an efficient workflow in the company. The existence of inefficient workflow has been demonstrated by the set of Problems the thesis established and defined in the Process Analysis and Problems section. The thesis followed with presenting changes that the company has made in its workflows following its affiliation with a multinational, and analysing how these changes solved or mitigated the Problems defined. The analysis of the agility of these changes was carried out in the Agile retrospective section, the thesis additionally provided its own version of agility. Since the thesis did not highlight any problems arising from the combination of ITIL and agile, its goal to showcase their seamless union can be deemed a success. Despite the seamless union, limitations do exist. The main limitation of implementing a similar set of changes in any company is time, as was mentioned in the previous section. The time it takes to organise and conduct all of the various meetings and calls. Working remote could alleviate the problem, as the meetings could be held online and employees would not have to spend additional time relocating for the meeting. On the other hand, no physical presence could also mean that employees would pay less attention to the contents of the meeting. The situation naturally worsens if some employees work remote and others work in office. A particular company must also have access to senior level employees who would be willing to participate in meetings where the goal is to share knowledge. Of course, these senior employees have higher wages and 60 CONCLUSION their presence in the meetings increases the cost even further. Another important aspect is balance. Too many meetings can cause chaos and lose their meaning, whereas too little could be insufficient. In the end, a company has to evaluate how many problems it is facing and what percentage of these problems can be mitigated by increased meaningful interactions in the company before trying to implement similar changes. 61 R E F E R E N C E S References Gartner. 2020. Definition of ITIL - Gartner Information Technology Glossary [Online], Gartner, 2020 [cited 29 05 2022]. Available at: https://www.gartner.com/en/information-technology/glossary/itil Iden, J., & Eikebrokk, T. R. 2014. The impact of senior management involvement, organisational commitment and group efficacy on ITIL implementation benefits. Information Systems and e-Business Management, 2014, 13(3), 527-552. DOI:10.1007/sl0257-014-0253-4 Beck, K., et al. 2001. The Agile Manifesto [online]. Agile Alliance, 2001, [cited 29 05 2022]. Available at: http://agilemanifesto.org/ Martins, P., & Zacarias, M. 2017. An Agile Business Process Improvement Methodology. Procedia Computer Science, 2017. 121. 129-136. DOI:10.1016/j.procs.2017.11.018. Ozdenizci Kose, B. 2020. Business process management approach for improving agile software process and agile maturity. Journal of Software: Evolution and Process. 2020, DOI:10.1002/smr.2331 famous, N., Bosse, S., Gorling, C, Hintsch, J., Khan, A., Kramer, F., Muller, H. and Turowski, K. 2017. 'Towards an IT service lifecycle management (ITSLM) concept', Proceedings - 4th International Conference on Enterprise Systems: Advances in Enterprise Systems, ES 2016. 2017, pp.29-38, DOI: 10.1109/ES.2016.10. Agutter, C. 2020. ITIL® 4 Essentials: Your Essential Guide for the ITIL 4 Foundation Exam and Beyond, Second Edition. Ely, Cambridgeshire, United Kingdom: ITGP, 2020. v. Second edition, ISBN 9781787782181 Stokburger-Sauer, N.E., Scholl-Grissemann, U., Teichmann, K. and Wetzels, M. 2016. 'Value cocreation at its peak: the asymmetric relationship between coproduction and loyalty', Journal of Service Management. 2016, Vol. 27, DOL10.1108/JOSM-10-2015-0305 63 R E F E R E N C E S FAUSTINO, J., PEREIRA R., ALTURAS B., SILVA M. 2020. Agile information technology service management with DevOps: an incident management case study. International Journal of Agile Systems and Management [Online]. 2020,13(4), 339-389 [cited 26 12 2022]. ISSN 17419174. DOL10.1504/IJASM.2020.112331 X. Tang and Y. Todo. 2013. A Study of Service Desk Setup in Implementing IT Service Management in Enterprises, Technol. Invest., 2013, vol. 4, no. 3, pp. 190-196, DOI: 10.4236/ti.2013.43022 Sydle. 2022. What is ITSM? why is it important for modern businesses? [Online], Sydle, 2022, [cited 23 12 2022]. Available at: https://www.svdle.com/blog/itsm-5faed482dlc5274a5f54796f/ Gillingham J. 2022. ITIL Adoption in IT and Non-IT Business Functions [Online], Invensis, 2022, [cited 18 11 2022]. available at: https://www.invensislearning.com/blog/itil-adoption-in-it-and-non-itbusiness-functions / Watts S. 2017. ITSM Frameworks Explained: Which Are Most Popular? [Online], CompTIA, 2017, [cited 18 11 2022]. available at: https:/ /www.comptia.org/blog/itsm-frameworks-explained-which- are-most-popular Barcelo-Valenzuela M. and Leal-Pompa C. M. 2020. An ITSM Framework Adaptation: Case Study in an Electoral Institution, 2020 International Conference on Computing and Data Science (CDS), 2020, pp. 468- 473, DOI: 10.1109/CDS49703.2020.00098. Michael S., Michael B., Thomas S. 2019. IT Service Management Frameworks Compared - Simplifying Service Portfolio Management, 2019 IFIP/IEEE Symposium on Integrated Network and Service Management (IM), Arlington, VA, USA, 2019, pp. 421-427. Goddard W. 2019., IT Services Management (ITSM) Frameworks [Online], ITChronicles, 2019, [cited 18 11 2022]. available at: https://itchronicles.com/itsm/itsm-frameworks-search-and-trends- on-google/ 64 R E F E R E N C E S USM. 2022. Service Management System (SMS) [Online], USM portal, 2022, [cited 16 01 2023]. Available at: https://usm-portal.com/servicemanagement-system-sms /?lang=en Hiererra, S. E., Gaol, F. L., Ranti, B. and Supangkat, S. H. 2022. Proposed IT Governance Model for Smart Tourism Destinations based on COBIT 2019 Framework, 2022, International Conference on Information Management and Technology (ICIMTech), Semarang Indonesia, 2022, pp. 499-504, DOI: 10.1109/ICIMTech55957.2022.9915077. Kozina, M. 2009. COBIT - ITIL mapping for business process continuity management, 2009, Varazdin: Faculty of Organization and Informatics Varazdin. Available at: https://www.proquest.com/conference-papers- proceedings/cobit-itil-mapping-business-process-continu- ity/docview/1313188452/se-2 Kempter S. 2019. ITIL processes [Online], IT Process Wiki - the ITIL® Wiki, 2019, [cited 26 12 2022]. Available at: https://wiki.en.it-processmaps.com/index.php/ITIL Processes Ratnawati, S., Huda M. Q. and Sopiana, F. 2021. Evaluation of IT Service Operation for Public Service Using ITIL Version 3 and PDCA CYCLE, 20219th International Conference on Cyber and IT Service Management (CITSM), 2021, pp. 1-5, DOI: 10.1109/CITSM52892.2021.9589017. Kempter, S. Kempter, A. 2019. ITIL Service operation [Online], IT Process Wiki - the ITIL® Wiki, 2019, [cited 26 12 2022]. available at: https://wiki.en.it-processmaps.com/index.php/File:Service-operation- itil-jpg Bartolini C, Stefanelli, C. and Tortonesi, M. 2009. Business-impact analysis and simulation of critical incidents in IT service management, 2009 IFIP/IEEE International Symposium on Integrated Network Management, 2009, pp. 9-16, DOI: 10.1109/INM.2009.5188781. ITSM Encyclopedia. 2007. ITIL incident escalation [Online], The ITSM Encyclopedia, 2007, [cited 21 05 2022]. Available at: https://itsm.certi- fication.info/incidentescalate.html 65 R E F E R E N C E S Process Street. 2020. Itil Incident Management Process Template [Online], Process Street, 2020, [cited 26 12 2022]. Available at: https://www.process.st/checklist/itil-incident-management-process- template/ CAO, J., ZHANG, S. 2016. ITIL Incident Management Process Reengineering in Industry 4.0 Environments. Proceedings of the 2nd International Conference on Advances in Mechanical Engineering and Industrial Informatics (AMEII 2016), 2016. ISSN edsbas. Available at: DOI:10.2991/ameii-16.2016.193 Yun, M., Lan, Y. and Han, T. 2017. Automate incident management by decision-making model, 2017 IEEE 2nd International Conference on Big Data Analysis (ICBDA), pp.217-222, DOI: 10.1109/IC- BDA.2017.8078811. Atlassian. 2020. What is Service Request Management? A guide [Online], Atlassian, 2020, [cited 18 01 2023]. Available at: https://www.atlassian.com/itsm/service-request-management Kempter, S. 2020. Request fulfilment: It process wiki [Online], IT Process Wiki - the ITIL® Wiki, 2020, [cited 18 01 2023]. Available at: https://wiki.en.it-processmaps.com/index.php/Request Fulfilment Tambralli, K. 2021. ITIL event management [Online], ITIL Docs - ITIL Templates and Training Courses, 2021, [cited 23 01 2023]. Available at: https://www.itil-docs.com/blogs/itil-concepts/itil-event-management IBM. 2023. IBM Documentation, Configuration items [Online], IBM, 2023, [cited 18 01 2023]. Available at: https://www.ibm.com/docs/en/control-desk/7.6.1.2?topic=overview- configuration-items Kempter, S. 2019. Incident management: It process wiki [Online], IT Process Wiki - the ITIL® Wiki, 2019, [cited 18 01 2023]. Available at: https://wiki.en.it-processmaps.com/index.php/Incident Management 66 R E F E R E N C E S Dalton, R. 2021. Problem management at the DWP case study [Online], Axelos, 2021, [cited 24 01 2023]. Available at: https://www.ax- elos.com/resource-hub/case-study/problem-management-at-dwp Smith, A. W., & Rahman, N. 2017. Can Agile, Lean and ITIL Coexist? International Journal of Knowledge-Based Organizations, 2017, 7(1), 78- 88. DOI:10.4018/ijkbo.2017010105 Mathenge, M. J., Stevens-Hall, J. 2019. ITIL 4 Management practices [Online], BMC Blogs, 2019, [cited 2022-25-11]. Available at: https://www.bmc.com/blogs/itil-management-practices/ Anand A. 2019. Itil 4: Connecting the key concepts part 3 [Online], Axelos, 2019, [cited 24 01 2023]. Available at: https://www.axelos.com/re- source-hub/blog/itil-4-connecting-key-concepts-part-3 Anand A. 2019. Itil 4: Connecting the key concepts part 4 [Online], Axelos, 2019, [cited 24 01 2023]. Available at: https://www.axelos.com/re- source-hub/blog/itil-4-connecting-key-concepts-part-4 INDRIASARI, E., PRABOWO, H., GAOL, F. L., PURWANDARI, B. 2021. The adoption of Design Thinking Agile Software Development and Cocreation concepts A case study of Digital Banking innovation. 2021 International Conference on Platform Technology and Service (PlatCon), Platform Technology and Service (PlatCon), 2021, 1-6. ISBN 9781665417662. ISSN edseee.IEEEConferenc. Available at: DOI:10.1109/PlatCon53246.2021.9680763 Atlassian. 2009. What is Agile? [Online], Atlassian, 2009 [cited 23 12 2022]. Available at: https://www.atlassian.com/agile Stober, T., Hansmann, U. 2009. Agile software development: Best practices for large software development projects., Springer, Berlin, 2009. ISBN 9783540708322 Ali Babar, M., Brown, A., Mistrik, I. 2014.. Agile software architecture. Amsterdam: Morgan Kaufmann, 2014. ISBN 9780124077720 67 R E F E R E N C E S Mundra, S. 2018. Enterprise Agility: Being Agile in a Changing World. Birmingham, UK: Packt Publishing, 2018. ISBN 9781788990646. Raschke, R. L. 2010. Process-based view of agility: The value contribution of IT and the effects on process outcomes. International Journal of Accounting Information Systems, 2010, 11(4), 297-313. DOI:10.1016/j.accinf.2010.09.005 Kohlenbach T. 2022. Using processes to achieve organizational agility [Online]. Process Excellence Network, 2022, [cited 21 05 2022]. Available at: https://www.processexcellencenetwork.com/organizational- change/articles/using-processes-to-achieve-organizational-agility Mahadevan, D., Comella-Dorda, S., Karin, A. 2018. The drawbacks of agility [Online]. McKinsey & Company, 2018, [cited 21 05 2022]. Available at: https://www.mckinsey.com/business-functions/people-and-or- ganizational-performance/our-insights/the-organization-blog/the- drawbacks-of-agility Bryar C, Carr B. 2021. Have We Taken Agile Too Far? [Online]. Harvard Business Review, 2021, [cited 21 05 2022]. Available at: https://hbr.org/2021/04/have-we-taken-agile-too-far Louisnord, V. E., N. 2018. Cutting Some Fat - A More Agile Incident Management Process [Online], ITchronicles, 2018, [cited 24 05 2022] Available at: https://itchronicles.com/agile/agile-incident-management-pro- cess/ KnowledgeHut. 2017. Incident Management Nuances In Agile & ITIL [Online], KnowledgeHut, 2017, [cited 24 05 2022] Available at: https://www.knowledgehut.com/blog/agile/incident-management-nu- ances-in-agile-itil Winter, S. 2018. Incident response for agile development [Online], Atlassian, 2018 [cited 18 01 2023]. Available at: https://www.atlas- sian.com/agile/software-development/incident-response 68 R E F E R E N C E S Saunders, M., Lewis, P., Thornhill, A. 2012. Research Methods for business students, Sixth Edition. Pearson, Harlow, England, 2012, ISBN 9780273750758 ServiceNow. 2023. Product documentation [Online], ServiceNow, 2023 [cited 28 03 2023]. Available at: https://docs.servicenow.com/en- US/bundle/utah-it-service-management/page/product/incident-man- agement/concept/incident-management-process.html 69 R E F E R E N C E S 70