This disclosure relates generally to Information Technology Service Management (ITSM) systems, and more particularly to method and system for integrating process workflows for ITSM systems.
Background
[002] In the age of digitalization, most enterprises have adopted a multi-supplier model that consumes specific services from specialist suppliers. Each supplier may provide services through unique applications and may manage the applications using customized Information Technology Service Management (ITSM) systems. Unification of records from various ITSM systems is challenging. Also, processes for customers and suppliers may be unique and may work in isolation. However, absence of a harmonized process leads to inconsistent and disintegrated operations. At present, the customer and supplier ITSM systems are designed and implemented based on unique process lifecycle, policies, and procedures predefined for such organizations which may make system integration more cumbersome and complex.
[003] The existing customer and supplier ITSM systems may have several limitations. Absence of a standardized process and a common reference ITSM process framework may lead to inconsistent and disintegrated operations. Further, inconsistency in the conventional ITSM processes may lead to conflict between suppliers, lack of reliable reporting, and lack of end-to-end performance visibility leading to impacted decision making. Further, in process records of customer and supplier ITSM systems for the same incident, change or a service request with a different individual process lifecycle status may create an operational challenge. Also, the Server-Level Agreements (SLAs) and Operational-Level Agreements (OLAs) may not be in sync with each other leading to unaligned activities in an ITSM process record.
[004] Additionally, Service Integration and Management (SIAM) operatives may work on multiple systems, communicating the same information through various means to ensure a collaboration among different suppliers which may make managing service delivery tedious and time-consuming. In cases where two or more ITSM systems from suppliers are integrated, a limited exchange of data may create variation in records for the same incident, request, or change. Thus, enterprise service managers face a conundrum of multiple sources of truth. Further, SIAM governance operatives may collect data from different sources, process the collected data, and create consolidated service level reports. The data collection and processing is time-consuming, laborious, and prone to human error. Furthermore, inadequate and inconsistent reports may often be generated due to a lack of coordination and collaboration or a mismatch in structure of the data.
[005] Therefore, there is a need in the present state of art for improved methods and systems for integrating process workflows for ITSM systems which may provide a common unified SIAM process that harmonizes ITSM systems of the customers and multiple suppliers for an improved operational stability.
SUMMARY
[006] In an embodiment, a method for integrating process workflows for Information Technology Service Management (ITSM) systems is disclosed. In one example, the method may include normalizing a unique process workflow of a service management process corresponding to associated customers and suppliers from each of a source ITSM system and a plurality of target ITSM systems based on a centralized unified reference process model through a process orchestration algorithm to obtain a normalized System of Record (SoR). The unique process workflow may include a plurality of the states associated with the service management process. The method may further include receiving a service management process record from the source ITSM system. The method may further include identifying events occurred corresponding to a change in a status of the service management process in the source ITSM system. The method may further include generating actions associated with the identified events in the source ITSM system. The actions may be configured to trigger process orchestration in at least one of the source ITSM system and the plurality of target ITSM systems based on the process orchestration algorithm. The method may further include assigning actionable events to entities associated with each of one or more of the plurality of target ITSM systems based on the normalized SoR of the service management process. The source ITSM system may be configured to integrate with the plurality of target ITSM systems.
[007] In one embodiment, a process orchestration system for integrating process workflows for ITSM systems is disclosed. In one example, the system may include a processor and a computer-readable medium communicatively coupled to the processor, wherein the computer-readable medium stores processor-executable instructions, which, on execution, may cause the processor to normalize a unique process workflow of a service management process corresponding to associated customers and suppliers from each of a source ITSM system and a plurality of target ITSM systems based on a centralized unified reference process model through a process orchestration algorithm to obtain a normalized SoR. The unique process workflow may include a plurality of the states associated with the service management process. The processor-executable instructions, on execution, may further cause the processor to receive a service management process record from the source ITSM system. The processor-executable instructions, on execution, may further cause the processor to identify events occurred corresponding to a change in a status of the service management process in the source ITSM system. The processor-executable instructions, on execution, may further cause the processor to generate actions associated with the identified events in the source ITSM system. The actions may be configured to trigger process orchestration in at least one of the source ITSM system and the plurality of target ITSM systems based on the process orchestration algorithm. The processor-executable instructions, on execution, may further cause the processor to assign actionable events to entities associated with each of one or more of the plurality of target ITSM systems based on the normalized SoR of the service management process. The source ITSM system may be configured to integrate with the plurality of target ITSM systems.
[008] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
[009] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles.
[010] FIG. 1 is a block diagram of an exemplary system for integrating process workflows for Information Technology Service Management (ITSM) systems, in accordance with some embodiments of the present disclosure.
[011] FIG. 2 is a functional block diagram of an exemplary system for integrating process workflows for ITSM systems, in accordance with some embodiments of the present disclosure.
[012] FIG. 3 illustrates an exemplary system for applying a process orchestration algorithm to normalize a System of Record (SoR), in accordance with some embodiments of the present disclosure.
[013] FIG. 4 illustrates an exemplary system for updating an SoR, in accordance with some embodiments of the present disclosure.
[014] FIG. 5 illustrates a flowchart of an exemplary process for integrating process workflows for ITSM systems, in accordance with some embodiments of the present disclosure.
[015] FIG. 6 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.

DETAILED DESCRIPTION
[016] Exemplary embodiments are described with reference to the accompanying drawings. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims. Additional illustrative embodiments are listed below.
[017] Referring now to FIG. 1, a block diagram of an exemplary system 100 for integrating process workflows for Information Technology Service Management (ITSM) systems is illustrated, in accordance with some embodiments of the present disclosure. The system 100 includes a process orchestration device 102, in accordance with some embodiments of the present disclosure. The process orchestration device 102 may be configured to integrate the process workflows by effectively mapping the process workflows across different customer and supplier ITSM systems and maintaining a normalized state for each corresponding process, thus, creating a single system of record acting as a ‘source of truth’ for a customer and associated suppliers. The process orchestration device 102 may further ensure that actions triggered through any update in a process record of an ITSM system in form of events are orchestrated and a standardized procedure is followed for each process through a process orchestration algorithm. This is further explained in conjunction with FIG. 3.
[018] As will be described in greater detail in conjunction with FIGS. 2 – 5, the process orchestration device 102 may normalize a unique process workflow of a service management process corresponding to associated customers and suppliers from each of a source ITSM system and a plurality of target ITSM systems based on a centralized unified reference process model through a process orchestration algorithm to obtain a normalized System of Record (SoR). The unique process workflow may include a plurality of the states associated with the service management process. The process orchestration device 102 may further receive a service management process record from the source ITSM system. The process orchestration device 102 may further identify events occurred corresponding to a change in a status of the service management process in the source ITSM system. The process orchestration device 102 may further generate actions associated with the identified events in the source ITSM system. The actions may be configured to trigger process orchestration in at least one of the source ITSM system and the plurality of target ITSM systems based on the process orchestration algorithm. The process orchestration device 102 may further assign actionable events to entities associated with each of one or more of the plurality of target ITSM systems based on the normalized SoR of the service management process. The source ITSM system may be configured to integrate with the plurality of target ITSM systems.
[019] In some embodiments, the process orchestration device 102 may include a processor 104 that is communicatively coupled to a memory 106, which may be a non-volatile memory or a volatile memory. Examples of non-volatile memory, may include, but are not limited to a flash memory, a Read Only Memory (ROM), a Programmable ROM (PROM), Erasable PROM (EPROM), and Electrically EPROM (EEPROM) memory. Examples of volatile memory may include, but are not limited Dynamic Random Access Memory (DRAM), and Static Random-Access Memory (SRAM). Further, the memory 106 may store instructions that, when executed by the processor 104, cause the processor 104 to integrate process workflows for ITSM systems, in accordance with aspects of the present disclosure.
[020] The system 100 may further include a display 108. The system 100 may interact with a user via a user interface 110 accessible via the display 108. The system 100 may also include one or more external devices 112. In some embodiments, the process orchestration device 102 may interact with the one or more external devices 112 over a communication network 114 for sending or receiving various data. The external devices 112 may include, but may not be limited to, a remote server, a digital device, a customer ITSM, a supplier ITSM, or another computing system. The communication network 114 may be a wired or a wireless network and the examples may include, but are not limited to the Internet, Wireless Local Area Network (WLAN), Wi-Fi, Long Term Evolution (LTE), Worldwide Interoperability for Microwave Access (WiMAX), Bluetooth, and General Packet Radio Service (GPRS).
[021] As will be appreciated by one skilled in the art, a variety of processes may be employed for integrating process workflows for ITSM systems. For example, the exemplary system 100 and the associated process orchestration device 102 may integrate process workflows for ITSM systems by the processes discussed herein. In particular, as will be appreciated by those of ordinary skill in the art, control logic and/or automated routines for performing the techniques and steps described herein may be implemented by the system 100 and the associated process orchestration device 102 either by hardware, software, or combinations of hardware and software. For example, suitable code may be accessed and executed by the one or more processors on the system 100 to perform some or all of the techniques described herein. Similarly, application specific integrated circuits (ASICs) configured to perform some or all of the processes described herein may be included in the one or more processors on the system 100.
[022] Referring now to FIG. 2, an exemplary system 200 for integrating process workflows of ITSM systems is illustrated, in accordance with some embodiments of the present disclosure. The SCF process orchestration device 202 may include a source ITSM system and a plurality of target ITSMs. The source ITSM system may be one of a customer ITSM system 204 or a supplier ITSM system (for example, a supplier ITSM system 206A and a supplier ITSM system 206B). In some embodiments, the target ITSM system may be the supplier ITSM system when the source ITSM system is one of a customer ITSM system or a supplier ITSM system. In some embodiments, the target ITSM system may be a customer ITSM system when the source ITSM system is a supplier ITSM system.
[023] It should be noted that, each of customer and suppliers may have a unique set of ITSM processes, stages, and policies. For example, the customer ITSM system 204 may track a process through customer specific process lifecycle, the supplier ITSM system 206A may track the process through a first supplier specific process lifecycle, and the supplier ITSM system 206B may track the process through a second supplier specific process lifecycle,. Further, each of the customer specific process lifecycle, the first supplier specific process lifecycle, and the second supplier specific process lifecycle may include a unique number of stages and a unique definition of each of the stages corresponding to the process.
[024] The SCF process orchestration device 202 may be associated with a unified process lifecycle, which may include a unique number of stages and a unique definition of each of the stages corresponding to the process. In some embodiments, communication between each of the customer ITSM system 204 and the supplier ITSM systems 206A and 206B may occur through the SCF process orchestration device 202. The SCF orchestration device 202 may integrate the supplier ITSM systems 206A and 206B by mapping the customer specific process lifecycle, the first supplier specific process lifecycle, and the second supplier specific process lifecycle with the unified process lifecycle. It may be noted that the system 200 may include more than two supplier ITSM systems corresponding to a customer ITSM system without affecting the scope of the invention. It may also be noted that the unified process lifecycle may be based on a centralized unified reference process model to optimize the process lifecycle. In particular, the SCF orchestration device 202 may map process workflows from the customer and supplier ITSM systems, and harmonize and unify the process workflows based on the centralized unified reference process model. This is further explained in detail in conjunction with FIG. 3.
[025] Referring now to FIG. 3, an exemplary system 300 for applying a process orchestration algorithm 302A to normalize an SoR 302B is illustrated, in accordance with some embodiments of the present disclosure. The system 300 may include a customer ITSM system 304, a plurality of supplier ITSM systems (for example, a supplier ITSM system 306A and a supplier ITSM system 306B), and an SCF process orchestration device 302. In an embodiment, the SCF process orchestration device 302, the customer ITSM system 304, and the at least two supplier ITSM systems (for example, the supplier ITSM system 306A and the supplier ITSM system 306B) may be analogous to the SCF process orchestration device 202, the customer ITSM system 204, and the supplier ITSM systems 206A and 206B of the system 200, respectively. The SCF process orchestration device 302 may include the process orchestration algorithm 302A configured to integrate process workflows of each of the customer ITSM system 304 and the supplier ITSM systems 306A and 306B by mapping the corresponding process workflows with a centralized unified reference process model to normalize the SoR 302A.
[026] It may be noted that each of customer and suppliers may have a unique service management process. The SCF process orchestration device 302 may normalize a unique process workflow associated with a service management process corresponding to each of a source ITSM system and a plurality of target ITSM systems based on a centralized unified reference process model through the process orchestration algorithm 302A to normalize the SoR 302B. The unique process workflow may include a plurality of the states associated with the service management process. In some embodiments, the plurality of states may include a plurality of stages, a plurality of events, and a set of policies for the service management process.
[027] In an embodiment, the unique process workflow of the customer ITSM system 304 may include 7 stages corresponding to the service management process lifecycle: “Draft” (A2), “Acknowledged” (A4), “Work in Progress” (A6), “Pending with Vendor” (A8), “Closed Cancelled” (A10), “Resolved” (A12), and “Closed Complete” (A14). The unique process workflow of the supplier ITSM system 306A may include 5 stages corresponding to the service management process lifecycle: “Open" (B2), In Progress” (B4), “Referred Back” (B6), “Closed” (B8), and “Cancelled” (B10). The unique process workflow of the supplier ITSM system 306B may include 7 stages corresponding to the service management process lifecycle: “New Request” (C2), “Logged” (C4), “Under Investigation” (C6), “Pending with Customer” (C8), “Cancelled by Customer” (C10), “Solution Provided” (C12), and “Complete” (C14).
[028] The normalized SoR 302B may include normalized fields, statuses, and timestamps corresponding to the service management process. The central unified reference process model may include 7 stages corresponding to the service management process lifecycle: “Open”, “Submitted”, “In Progress”, “On Hold”, “Cancelled”, “Fixed”, and “Closed”.
[029] To generate the normalized SoR 302B, the stages A2, B2, and C2 may be mapped to the “Open” stage of the central unified reference process model. Further, to generate the normalized SoR 302B, the stages A4 and C4 may be mapped to the “Submitted” stage of the central unified reference process model. Further, to generate the normalized SoR 302B, the stages A6, B4, and C6 may be mapped to the “In Progress” stage of the central unified reference process model. Further, to generate the normalized SoR 302B, the stages A8, B6, and C8 may be mapped to the “On Hold” stage of the central unified reference process model. Further, to generate the normalized SoR 302B, the stages A10, B10, and C10 may be mapped to the “Cancelled” stage of the central unified reference process model. Further, to generate the normalized SoR 302B, the stages A12, B8, and C12 may be mapped to the “Fixed” stage of the central unified reference process model. Further, to generate the normalized SoR 302B, the stages A14, B8, and C14 may be mapped to the “Closed” stage of the central unified reference process model.
[030] The SCF process orchestration device 302, in order to implement event-driven process orchestration, may further receive a service management process record from the source ITSM system. Further, the process orchestration device 302 may identify events occurred corresponding to a change in a status of the service management process in the source ITSM system. Further, the SCF process orchestration device 302 may assign actionable events to entities associated with each of one or more of the plurality of target ITSM systems based on the normalized SoR 302B of the service management process. In some embodiments, the source ITSM system may be configured to integrate with the plurality of target ITSM systems.
[031] In some embodiments, the source ITSM system may be one of the customer ITSM system 304 or the supplier ITSM systems 306A and 306B. In some embodiments, the target ITSM system may be the supplier ITSM system 306A when the source ITSM system is one of the customer ITSM system 304 or the supplier ITSM system 306B. In some embodiments, the target ITSM system may be the supplier ITSM system 306B when the source ITSM system is one of the customer ITSM system 304 or the supplier ITSM system 306A. In some embodiments, the target ITSM system may be the customer ITSM system 304 when the source ITSM system is one of the supplier ITSM systems 306A or 306B. It may be noted that the system 300 may include more than two supplier ITSM systems corresponding to a customer ITSM system without affecting the scope of the invention.
[032] Further, the SCF process orchestration device 302 may identify at least one change in a status of the service management process of the source ITSM system. Further, the SCF process orchestration device 302 may update the unique process workflow in the target ITSM system based on the normalized SoR and the identified at least one change in the status of the service management process of the source ITSM system.
[033] By way of an example, the SCF process orchestration device 302 may normalize the service management processes of each of the customer and supplier and may maintain a normalized state for each ITSM process, such that each process state corresponds to a single source of truth. Each of the process lifecycle in the customer ITSM system 304 and the supplier ITSM systems 304A and 304B may be mapped to a unified reference process. When a process change is detected in the customer ITSM system 304, the SCF process orchestration device 302 may trigger an action in the customer ITSM system 304 in the form of an event, which may then update and normalize the data, and create a normalized SoR that may be easily interpreted by the customer and the multiple suppliers.
[034] Further, the SCF process orchestration device 302 may trigger an action on the target supplier ITSM systems. Further, the SCF process orchestration device 302 may normalize the process records received from the customer ITSM system 304 and may make the process events actionable through the process orchestration algorithm 304A. Further, the SCF process orchestration device 302 may assign appropriate support groups to the actionable process events across multiple suppliers.
[035] For instance, an incident ticket may be created in the customer ITSM system 304 to be assigned to a third-party supplier system (for example, the supplier ITSM system 306A). A new ticket creation in the customer ITSM system 304 may generate an event and result in automatic creation of a new ticket in the supplier ITSM system 306A. Once the normalized SoR record is updated, the changes may be replicated in the respective process records of the customer ITSM system 304 and the supplier ITSM systems 306A and 306B.
[036] It should be noted that all such aforementioned modules 302A – 302B may be represented as a single module or a combination of different modules. Further, as will be appreciated by those skilled in the art, each of the modules 302A – 302B may reside, in whole or in parts, on one device or multiple devices in communication with each other. In some embodiments, each of the modules 302A – 302B may be implemented as dedicated hardware circuit comprising custom application-specific integrated circuit (ASIC) or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Each of the modules 302A – 302B may also be implemented in a programmable hardware device such as a field programmable gate array (FPGA), programmable array logic, programmable logic device, and so forth. Alternatively, each of the modules 302A – 302B may be implemented in software for execution by various types of processors (e.g., processor 104). An identified module of executable code may, for instance, include one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, function, or other construct. Nevertheless, the executables of an identified module or component need not be physically located together, but may include disparate instructions stored in different locations which, when joined logically together, include the module and achieve the stated purpose of the module. Indeed, a module of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different applications, and across several memory devices.
[037] Referring now to FIG. 4, an exemplary system 400 for updating an SoR is illustrated, in accordance with some embodiments of the present disclosure. The system 400 may include an SCF process orchestration device 402. In an embodiment, the SCF process orchestration device 402 may be analogous to the process orchestration device 102 of the system 100. The SCF process orchestration device 402 may implement a process orchestration algorithm 402A. The process orchestration algorithm 402A may perform normalization of customer and supplier processes, creating a harmonized process in the ITSM system and a single source of truth for customers and suppliers. It may be noted that the process orchestration algorithm 402A offers a one-stop solution for running effective process orchestrations and ensuring that processes are being executed as planned. Further, the system 400 may include a customer ITSM system 404 and three supplier ITSM systems 406A, 406B, and 406C. In an embodiment, the customer ITSM system 404 and the supplier ITSM systems 406A, 406B, and 406C may be analogous to the customer ITSM system 304, and the at least two supplier ITSM systems 306A and 306B of the system 300. It may be noted that the system 400 may include more than three supplier ITSM systems corresponding to a customer ITSM system without affecting the scope of the invention.
[038] In particular, FIG. 4 describes mapping of the process workflows of an ITSM process between the customer ITSM system 404 and the supplier ITSM systems 406A, 406B, and 406C through the event-driven process orchestration. It may be noted that in an IT ecosystem, each of customer and suppliers may use a unique ITSM system for customized service management processes based on a requirement of a delivery model. The process orchestration algorithm 402A may map the process workflows and associated status and data points to normalize the process workflow such that procedural level operational activities may not conflict.
[039] In case of a change management process, the versions of the same ITSM process may vary between suppliers and the customer. It may be noted that the customer and suppliers within the same IT ecosystem may prefer to follow different set of policies, procedures, and activities for the change management process in respective ITSM systems. As will be appreciated, the change management process achieves a common purpose irrespective of variations in adopted versions according to the ITSM practices. The centralized unified reference model normalizes the different variations of the same change management process that may be running on different customer and supplier ITSM systems. The centralized unified reference model may ensure that the different types of changes are mapped across ITSM systems. The process orchestration algorithm 402A may create change records in real-time in the customer and supplier ITSM systems. Additionally, the centralized unified reference model may provide ordering and sequencing of change tasks across supplier ITSM systems enhancing coordination and collaboration. The process orchestration algorithm 402A may orchestrate execution of the change in entirety. Thus, a uniform, consistent, and accurate single source of truth may be created in the form of the normalized SoR which may enable universal SLA and OLA calculations for uniform and consistent reporting.
[040] Referring now to FIG. 5, an exemplary process 500 for integrating process workflows for ITSM systems is illustrated, in accordance with some embodiments of the present disclosure. The process 500 may be implemented by the process orchestration device 102 of the system 100. The process 500 includes normalizing a unique process workflow of a service management process corresponding to associated customers and suppliers from each of a source ITSM system (for example, the customer ITSM system 304) and a plurality of target ITSM systems (for example, the supplier ITSM systems 306A and 306B) based on a centralized unified reference process model through a process orchestration algorithm (for example, the process orchestration algorithm 302A) to obtain a normalized SoR (such as, the SoR 302B), at step 502. It may be noted that the unique process workflow may include a plurality of the states associated with the service management process. The plurality of states may further include a plurality of stages, a plurality of events, and a set of policies for the service management process.
[041] The process 500 may further include receiving a service management process record from the source ITSM system, at step 504. Further, the process 500 may include identifying events occurred corresponding to a change in a status of the service management process in the source ITSM system, at step 506. The process 500 may further include generating actions associated with the identified events in the source ITSM system, at step 508. It must be noted that the actions are configured to trigger process orchestration in at least one of the source ITSM system and the plurality of target ITSM systems based on the process orchestration algorithm.
[042] In some embodiments, the source ITSM system may be one of a customer ITSM system or a supplier ITSM system. In some embodiments, the target ITSM system may be the supplier ITSM system when the source ITSM system is one of a customer ITSM system or a supplier ITSM system. In some embodiments, the target ITSM system may be a customer ITSM system when the source ITSM system is a supplier ITSM system. The process 500 may further include assigning actionable events to entities associated with each of one or more of the plurality of target ITSM systems based on the normalized SoR of the service management process, at step 510. The source ITSM system may be configured to integrate with the plurality of target ITSM systems. In some embodiments, the process orchestration device 102 may identify at least one change in a status of the service management process of the source ITSM system. The process orchestration device 102 may further update the unique process workflow in a target ITSM system based on the normalized SoR and the identified at least one change in the status of the service management process of the source ITSM system.
[043] Further, the process orchestration device 102 may generate a normalized report based on the normalized SoR. It may be noted that the normalized report may be displayed to each of the source ITSM and each of the one or more of the plurality of target ITSMs, and the normalized report may be published in a centralized location for SIAM governance.
[044] In an embodiment, the present techniques may focus on the integration of suppliers and corresponding ITSM systems with an emphasis on mapping the associated process workflows and effectively optimizing the process lifecycle. The techniques normalize process records coming from the discrete ITSM tools integrated with it. Thus, creating a single SoR acting as a ‘Source of truth’ for both customer and suppliers. Through the above-mentioned event-driven process orchestration, different processes may be mapped, and a harmonized workflow may be created. Each process may generate an event every time a ticket lifecycle stage progress. Event-driven process orchestration may further normalize the process records coming from the customer ITSM, make the process events actionable with the help of a process orchestration algorithm, and assign the process events to appropriate support groups across multiple suppliers. The techniques provide a progressive orchestration experience and ensure that a standardized approach is followed for performing the procedures pertaining to a process.
[045] As will be also appreciated, the above-described techniques may take the form of computer or controller implemented processes and apparatuses for practicing those processes. The disclosure can also be embodied in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, solid state drives, CD-ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer or controller, the computer becomes an apparatus for practicing the invention. The disclosure may also be embodied in the form of computer program code or signal, for example, whether stored in a storage medium, loaded into and/or executed by a computer or controller, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits.
[046] The disclosed methods and systems may be implemented on a conventional or a general-purpose computer system, such as a personal computer (PC) or server computer. Referring now to FIG. 6, an exemplary computing system 600 that may be employed to implement processing functionality for various embodiments (e.g., as a SIMD device, client device, server device, one or more processors, or the like) is illustrated. Those skilled in the relevant art will also recognize how to implement the invention using other computer systems or architectures. The computing system 600 may represent, for example, a user device such as a desktop, a laptop, a mobile phone, personal entertainment device, DVR, and so on, or any other type of special or general-purpose computing device as may be desirable or appropriate for a given application or environment. The computing system 600 may include one or more processors, such as a processor 602 that may be implemented using a general or special purpose processing engine such as, for example, a microprocessor, microcontroller or other control logic. In this example, the processor 602 is connected to a bus 604 or other communication medium. In some embodiments, the processor 602 may be an Artificial Intelligence (AI) processor, which may be implemented as a Tensor Processing Unit (TPU), or a graphical processor unit, or a custom programmable solution Field-Programmable Gate Array (FPGA).
[047] The computing system 600 may also include a memory 606 (main memory), for example, Random Access Memory (RAM) or other dynamic memory, for storing information and instructions to be executed by the processor 602. The memory 606 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor 602. The computing system 600 may likewise include a read only memory (“ROM”) or other static storage device coupled to bus 604 for storing static information and instructions for the processor 602.
[048] The computing system 600 may also include storage devices 608, which may include, for example, a media drive 610 and a removable storage interface. The media drive 610 may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a magnetic tape drive, an SD card port, a USB port, a micro USB, an optical disk drive, a CD or DVD drive (R or RW), or other removable or fixed media drive. A storage media 612 may include, for example, a hard disk, magnetic tape, flash drive, or other fixed or removable medium that is read by and written to by the media drive 610. As these examples illustrate, the storage media 612 may include a computer-readable storage medium having stored therein particular computer software or data.
[049] In alternative embodiments, the storage devices 608 may include other similar instrumentalities for allowing computer programs or other instructions or data to be loaded into the computing system 600. Such instrumentalities may include, for example, a removable storage unit 614 and a storage unit interface 616, such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units and interfaces that allow software and data to be transferred from the removable storage unit 614 to the computing system 600.
[050] The computing system 600 may also include a communications interface 618. The communications interface 618 may be used to allow software and data to be transferred between the computing system 600 and external devices. Examples of the communications interface 618 may include a network interface (such as an Ethernet or other NIC card), a communications port (such as for example, a USB port, a micro USB port), Near field Communication (NFC), etc. Software and data transferred via the communications interface 618 are in the form of signals which may be electronic, electromagnetic, optical, or other signals capable of being received by the communications interface 618. These signals are provided to the communications interface 618 via a channel 620. The channel 620 may carry signals and may be implemented using a wireless medium, wire or cable, fiber optics, or other communications medium. Some examples of the channel 620 may include a phone line, a cellular phone link, an RF link, a Bluetooth link, a network interface, a local or wide area network, and other communications channels.
[051] The computing system 600 may further include Input/Output (I/O) devices 622. Examples may include, but are not limited to a display, keypad, microphone, audio speakers, vibrating motor, LED lights, etc. The I/O devices 622 may receive input from a user and also display an output of the computation performed by the processor 602. In this document, the terms “computer program product” and “computer-readable medium” may be used generally to refer to media such as, for example, the memory 606, the storage devices 608, the removable storage unit 614, or signal(s) on the channel 620. These and other forms of computer-readable media may be involved in providing one or more sequences of one or more instructions to the processor 602 for execution. Such instructions, generally referred to as “computer program code” (which may be grouped in the form of computer programs or other groupings), when executed, enable the computing system 600 to perform features or functions of embodiments of the present invention.
[052] In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into the computing system 600 using, for example, the removable storage unit 614, the media drive 610 or the communications interface 618. The control logic (in this example, software instructions or computer program code), when executed by the processor 602, causes the processor 602 to perform the functions of the invention as described herein.
[053] As will be appreciated by those skilled in the art, the techniques described in the various embodiments discussed above are not routine, or conventional, or well understood in the art. The techniques discussed above provide for integrating process workflows for ITSM systems. Further, the techniques may provide a uniform reference process model thus, harmonizing the processes in the IT ecosystem and leading to an improved operational stability. The techniques enable the organizations to have a common unified SIAM process that harmonizes both customers and multiple suppliers. Further, the techniques create an accurate, consistent System of Record (SoR) with normalized process record information that acts as a single source of truth for all ITSM process records. Further, the process records reflect synchronized process statutes due to process orchestration to avoid operational conflicts between process activities carried out by different teams. Further, the techniques provide real-time updates in the SoR, thus, leading to an accurate reporting. Further, the techniques provide an improvement in the overall mean time to recovery/mean time to restore (MTTR) and customer satisfaction (CSAT).
[054] In light of the above mentioned advantages and the technical advancements provided by the disclosed method and system, the claimed steps as discussed above are not routine, conventional, or well understood in the art, as the claimed steps enable the following solutions to the existing problems in conventional technologies. Further, the claimed steps clearly bring an improvement in the functioning of the device itself as the claimed steps provide a technical solution to a technical problem.
[055] The specification has described method and system for integrating process workflows for ITSM systems. The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[056] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[057] It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims.

CLAIMS

What is claimed is:
1. A method (500) for integrating process workflows for Information Technology Service Management (ITSM) systems, the method (500) comprising:
normalizing (502), by a process orchestration device (102), a unique process workflow of a service management process corresponding to associated customers and suppliers from each of a source ITSM system and a plurality of target ITSM systems based on a centralized unified reference process model through a process orchestration algorithm (302A) to obtain a normalized System of Record (SoR), wherein the unique process workflow comprises a plurality of the states associated with the service management process;
receiving (504), by the process orchestration device (102), a service management process record from the source ITSM system;
identifying (506), by the process orchestration device (102), events occurred corresponding to a change in a status of the service management process in the source ITSM system;
generating (508), by the process orchestration device (102), actions associated with the identified events in the source ITSM system, wherein the actions are configured to trigger process orchestration in at least one of the source ITSM system and the plurality of target ITSM systems based on the process orchestration algorithm (302A); and
assigning (510), by the process orchestration device (102), actionable events to entities associated with each of one or more of the plurality of target ITSM systems based on the normalized SoR of the service management process, wherein the source ITSM system is configured to integrate with the plurality of target ITSM systems.

2. The method (500) of claim 1, further comprising:
identifying at least one change in a status of the service management process of the source ITSM system; and
updating the unique process workflow in a target ITSM system based on the normalized SoR and the identified at least one change in the status of the service management process of the source ITSM system.

3. The method (500) of claim 1, wherein the source ITSM system is one of a customer ITSM system (204) or a supplier ITSM system (206A), and wherein the target ITSM system is one of:
a supplier ITSM system (206A) when the source ITSM system is one of a customer ITSM system (204) or a supplier ITSM system (206B); or
a customer ITSM system (204) when the source ITSM system is a supplier ITSM system (206A).

4. The method (500) of claim 1, wherein the plurality of states comprises a plurality of stages, a plurality of events, and a set of policies for the service management process.

5. The method (500) of claim 1, further comprising generating a normalized report based on the normalized SoR, wherein the normalized report is displayed to each of the source ITSM and each of the one or more of the plurality of target ITSMs, and wherein the normalized report is published in a centralized location for Service Integration and Management (SIAM) governance.

6. A system (100) for integrating process workflows for Information Technology Service Management (ITSM) systems, the system (100) comprising:
a processor (104); and
a memory communicatively coupled to the processor (104), wherein the memory stores processor-executable instructions, which, on execution, cause the processor (104) to:
normalize (502) a unique process workflow of a service management process corresponding to associated customers and suppliers from each of a source ITSM system and a plurality of target ITSM systems based on a centralized unified reference process model through a process orchestration algorithm (302A) to obtain a normalized System of Record (SoR), wherein the unique process workflow comprises a plurality of the states associated with the service management process;
receive (504) a service management process record from the source ITSM system;
identify (506) events occurred corresponding to a change in a status of the service management process in the source ITSM system;
generate (508) actions associated with the identified events in the source ITSM system, wherein the actions are configured to trigger process orchestration in at least one of the source ITSM system and the plurality of target ITSM systems based on the process orchestration algorithm (302A); and
assign (510) actionable events to entities associated with each of one or more of the plurality of target ITSM systems based on the normalized SoR of the service management process, wherein the source ITSM system is configured to integrate with the plurality of target ITSM systems.

7. The system of claim 6, wherein the processor-executable instructions are further configured to:
identify at least one change in a status of the service management process of the source ITSM system; and
update the unique process workflow in a target ITSM system based on the normalized SoR and the identified at least one change in the status of the service management process of the source ITSM system.

8. The system of claim 6, wherein the source ITSM system is one of a customer ITSM system (204) or a supplier ITSM system (206A), and wherein the target ITSM system is one of:
a supplier ITSM system (206A) when the source ITSM system is one of a customer ITSM system (204) or a supplier ITSM system (206A); or
a customer ITSM system (204) when the source ITSM system is a supplier ITSM system (206B).

9. The system of claim 6, wherein the plurality of states comprises a plurality of stages, a plurality of events, and a set of policies for the service management process.

10. The system of claim 6, wherein the processor-executable instructions are further configured to generate a normalized report based on the normalized SoR, wherein the normalized report is displayed to each of the source ITSM and each of the one or more of the plurality of target ITSMs, and wherein the normalized report is published in a centralized location for Service Integration and Management (SIAM) governance.