Computerized network change management and communication system and method

Abstract

A system and method for implementing electronic communication regarding a change request over a computerized network is disclosed. In one embodiment, a change request data (RFC) structure is generated that describes a change request for the computerized network. A graphical user interface (GUI) is presented on a first user device that includes graphical items regarding the change request and a graphical discussion room creation option. An electronic discussion room electronically connecting user devices associated with the user regarding the change request is created in response to a user selection of the graphical discussion room creation option.

Description

[Background technology]

[0001] Telecommunications network systems include network devices (e.g., switches, routers, etc.) and other types of hardware. Some of this hardware implements software to perform network functions. In some cases, this hardware and software is proprietary or managed by a specific vendor or contractor. Thus, when a network user wants to make a change to a network service, the user submits a change request to a network operator. The network operator must review the request and obtain approval from the responsible party. The network operator then coordinates the implementation of the network change with the technicians and engineers who make the actual change. Managing changes to a network system is complex and difficult due to the amount of coordination and communication between different parties.

[0002] Aspects of the present disclosure are best understood from the following detailed description when read in conjunction with the accompanying drawings. It should be noted that, according to standard industry practice, various features have not been drawn to scale. In fact, the dimensions of various features may be arbitrarily increased or decreased for clarity of illustration. [Brief explanation of the drawings]

[0003] [Figure 1] FIG. 1 is a block diagram of a computing system according to an embodiment.

[0004] [Figure 2A] 1 includes a panel of a graphical user interface (GUI) used to generate a Request for Change (RFC) structure, according to one embodiment. [Figure 2B] 1 includes a panel of a graphical user interface (GUI) used to generate a Request for Change (RFC) structure, according to one embodiment. [Figure 2C]1 includes a panel of a graphical user interface (GUI) used to generate a Request for Change (RFC) structure, according to one embodiment. [Figure 2D] 1 includes a panel of a graphical user interface (GUI) used to generate a Request for Change (RFC) structure, according to one embodiment. [Figure 2E] 1 includes a panel of a graphical user interface (GUI) used to generate a Request for Change (RFC) structure, according to one embodiment. [Figure 2F] 1 includes a panel of a graphical user interface (GUI) used to generate a Request for Change (RFC) structure, according to one embodiment. [Figure 2G] 1 includes a panel of a graphical user interface (GUI) used to generate a Request for Change (RFC) structure, according to one embodiment. [Figure 2H] 1 includes a panel of a graphical user interface (GUI) used to generate a Request for Change (RFC) structure, according to one embodiment. [Figure 2I] 1 includes a panel of a graphical user interface (GUI) used to generate a Request for Change (RFC) structure, according to one embodiment. [Figure 2J] 1 includes a panel of a graphical user interface (GUI) used to generate a Request for Change (RFC) structure, according to one embodiment. [Figure 2K] 1 includes a panel of a graphical user interface (GUI) used to generate a Request for Change (RFC) structure, according to one embodiment. [Figure 2L] 1 includes a panel of a graphical user interface (GUI) used to generate a Request for Change (RFC) structure, according to one embodiment. [Figure 2M] 1 includes a panel of a graphical user interface (GUI) used to generate a Request for Change (RFC) structure, according to one embodiment. [Figure 2N]1 includes a panel of a graphical user interface (GUI) used to generate a Request for Change (RFC) structure, according to one embodiment. [Figure 2O] 1 includes a panel of a graphical user interface (GUI) used to generate a Request for Change (RFC) structure, according to one embodiment.

[0005] [Figure 3] 1 is a graphical representation of an RFC data structure according to one embodiment.

[0006] [Figure 4A] 1 is a GUI panel for a list of RFC structures, according to one embodiment.

[0007] [Figure 4B] 12 is a GUI panel for listing the approval status of RFC structures, according to one embodiment.

[0008] [Figure 5] 1 is a panel of a GUI showing a list of entities available for creating new electronic discussion rooms, and also displaying a visual representation of other electronic discussion rooms that have already been created, according to one embodiment.

[0009] [Figure 6] 6 is a table of communication information for a selected entity selected in response to selecting the graphical discussion room start option of FIG. 5 according to one embodiment.

[0010] [Figure 7] 1 is a panel that allows a user to manually set an electronic discussion room link (ie, meeting ID, passcode), according to one embodiment.

[0011] [Figure 8]1 is a flow diagram of a method for conducting electronic communication regarding a change request over a computerized network according to one embodiment.

[0012] [Figure 9] 1 is a flow diagram of a method for creating an electronic discussion room, according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0013] The following disclosure provides many different embodiments or examples for implementing different features of the provided subject matter. To simplify the disclosure, specific examples of components, values, operations, materials, arrangements, etc. are described below. Of course, these are merely examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, etc. are contemplated. For example, the formation of a first feature on or above a second feature in the following description can include embodiments in which the first and second features are formed in direct contact with each other, and can also include embodiments in which an additional feature may be formed between the first and second features such that the first and second features are not in direct contact with each other. Additionally, the present disclosure may repeat illustrated numbers and / or letters in various examples. This repetition is for the purposes of brevity and clarity and does not in itself dictate a relationship between the various embodiments and / or configurations described.

[0014] (Optional, used where applicable) Additionally, spatially relative terms such as "beneath," "below," "lower," "above," and "upper" may be used herein for ease of description to describe the relationship of one element or feature to another element(s) or feature(s), as shown in the figures. Spatially relative terms are intended to encompass different orientations of the device during use or operation in addition to the orientation shown in the figures. The device may be otherwise oriented (rotated 90 degrees or at other orientations) and the spatially relative descriptors used herein may likewise be interpreted accordingly.

[0015] In one embodiment, implementing a change to a computerized network involves multiple parties, such as a change requester, a change manager, a change request approver, a change implementer, and a third-party service provider and / or vendor. During the change request lifecycle (e.g., submitting a change request, approving the change request, implementing the change request, and closing the change request), multiple stakeholders contact each other to discuss the details of the change request (e.g., when discussing procedural changes, when there is a misunderstanding or when any party lacks sufficient information, when unexpected issues occur during the implementation of the change request, etc.). This specification describes embodiments of a system and method for creating an electronic discussion room. In one embodiment, the electronic discussion room is maintained throughout the change request lifecycle to allow various parties involved in the change request to communicate regarding the change request. In one embodiment, the electronic discussion room enables the parties involved in the change request to conduct group discussions in an effective and organized manner. In one embodiment, a record of the discussion (e.g., text messages, audio recordings, video recordings, etc.) is generated to allow other parties to easily access previous communications regarding the change request. In one embodiment, a log file (e.g., a text transcript) of the discussion in the electronic discussion room is generated so that even those who have not participated in previous meetings can easily and clearly review the issues that have already been discussed regarding the change request.

[0016] FIG. 1 is a block diagram of a computing system 100 according to one embodiment.

[0017] Computing system 100 includes network change management computer device 102, at least one database 104, computer network 105, and user devices 107, 109, 111, and 113. In FIG. 1 , computer network 105 includes cellular network 106 and Internet Protocol (IP) network 108. In some embodiments, computer network 105 includes only IP network 108. In some embodiments, computer network 105 includes only cellular network 106. In some embodiments, computer network 105 includes multiple IP networks, such as IP network 108. In some embodiments, computer network 105 includes multiple cellular networks, such as cellular network 106.

[0018] In one embodiment, the network change management computing device 102 and the cellular network 106 are connected to each other via an IP network 108. In one embodiment, the IP network 108 includes a wide area network (WAN) (i.e., the Internet), a local area network (LAN), a wide area local area network (WLAN), etc. In one embodiment, the cellular network 106 includes a wireless WAN (WWAN).

[0019] The cellular network 106 includes a Radio Access Network (RAN) 160. The RAN 160 is the wireless element of the cellular network 106. The RAN 160 includes network elements such as base stations, each containing one or more radio transceivers. A base station covers a land area called a cell. User equipment, such as a mobile phone, smartphone, or laptop, connects to each of the base stations that cover the cell. The RAN 160 connects to the Core 170 via a backhaul link provided by the Transport 180.

[0020] The Core 170 is the central part of the entire cellular network 106. The Core 170 allows mobile subscribers to access services (e.g., international calling, text messaging, local cellular calling). In one embodiment, the Core 170 is responsible for important functions such as maintaining subscriber profile information, subscriber location, service authentication, and switching functions required for voice and data sessions. The Core 170 includes network elements. In one embodiment, the network elements include a Mobility Management Entity (MME), a Serving Gateway, a Multimedia Broadcast Multicast Service (MBMS) Gateway, a Broadcast Multicast Service Center (BM-SC), and a Packet Data Network (PDN) Gateway. In one embodiment, the MME communicates with a Home Subscriber Server (HSS). The MME is the control node that handles signaling between user equipment and the Core 170. Generally, the MME provides bearer and connection management. In one embodiment, Internet Protocol (IP) packets are forwarded through the Serving Gateway, which is itself connected to the IP network 108.

[0021] Transport 180 refers to the transport network connecting the Core 170 and the RAN 160 of the cellular network 106. Transport 180 includes network elements 182 such as backhaul links, connectors, relays, voice over IP devices, etc. In one embodiment, Transport 180 includes a fronthaul connecting macro cells to small cells, radio units, digital units, etc.

[0022] Network change management computing device 102 (server 102 in one embodiment) is a computing device that includes at least one processor 126 and non-transitory computer-readable medium 128. Non-transitory computer-readable medium 128 stores computer-executable instructions 124. In one embodiment, non-transitory computer-readable medium 128 includes random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage, a combination of the aforementioned types of computer-readable medium, or any other medium that can be used to store computer-executable code in the form of instructions or data structures that can be accessed by a computing device. When processor 126 executes computer-executable instructions 124, processor 126 executes change management computer software 127.

[0023] Change management computer software 127 is configured to automate change requests. In one embodiment, the change request relates to a requested change to the hardware of computer network 105. In one embodiment, the change request relates to a requested change to the software of computer network 105. In one embodiment, the change request relates to a requested change in both the hardware and software of computer network 105. In one embodiment, the hardware of network 105 includes servers, base stations, radio units, and / or any other suitable hardware in a network system, and the software of network 105 includes multiple applications that perform telecommunications functions and manage telecommunications performance, and / or any other suitable software in a network system. In one embodiment, change management computer software 127 is configured to automate the approval and / or implementation processes used to make these changes in network 105.

[0024] For example, in one embodiment, the change request action is provided by change requester 130. Change requester 130 is a user requesting a hardware and / or software change within computer network 105. As described in further detail below, change management computer software 127 receives user input from a user device 107 operated by change requester 130 to generate RFC structure 134. Change management computer software 127 stores RFC structure 134 in database 104. In one embodiment, database 104 stores RFC structure 134 on non-transitory computer-readable medium 136.

[0025] The user device 107 includes a non-transitory computer-readable medium 135 and at least one processor 139. The non-transitory computer-readable medium 135 stores computer-executable instructions 137. When the processor 139 executes the computer-executable instructions 137, the user device 107 is configured to receive user input and transmit the user input to the change management computer software 127. The change management computer software 127 processes the user input and transmits authorization (which, in one embodiment, is provided by an external security system, etc.) to the user device 107.

[0026] The change request is reviewed by change manager 144, a user responsible for ensuring that the information in the change request is correct and that the tasks associated with the change request are performed according to requirements and on schedule. As described in further detail below, change management computer software 127 receives user input from user device 111 (operated by change manager 144) to receive approvals and modifications to the change request. In one embodiment, change management computer software 127 sends notification of the change request (e.g., via email, SMS, push notification, etc.) to multiple personnel who qualify as change managers 114, requesting at least one of the multiple personnel to receive / assign the change request. In one embodiment, once one of the multiple personnel receives / assigns the change request (e.g., by submitting a response to the change management computer software 127 notification), change management computer software 127 assigns that person as change manager 114, and no other members of the multiple personnel can receive / assign the change request without the permission of change manager 114. In one embodiment, the change manager 144 modifies the change request by modifying the RFC structure 134 (e.g., changing the urgency level, execution schedule, and any other appropriate fields of the change request). In one embodiment, the change manager 144 reviews and approves the change request without modifications. The user device 111 of the change manager 144 requests that the change management computer software 127 send the RFC structure 134 (including the modifications / updates, if any, made by the change manager 114) to the user devices of all users associated with the role of approver. In one embodiment, before sending the RFC structure 134 to the user devices of all users associated with the role approver, the user device 111 of the change manager 144 requests that the change management computer software 127 send the modified change request to the change requester to seek the change requester's agreement to the changes made.

[0027] The user device 111 includes a non-transitory computer-readable medium 149 and at least one processor 145. The non-transitory computer-readable medium 149 stores computer-executable instructions 146. When the processor 145 executes the computer-executable instructions 146, the user device 111 is configured to receive user input and transmit the user input to the change management computer software 127.

[0028] The change approver 140 approves the change request. As described in more detail below, the change management computer software 127 receives user input from a user device 109 (operated by the change approver 140) to receive approval for the change request. The user device 109 of the change approver 140 transmits the approval or denial (including updates in scheduling and classification, if any) to the RFC structure 134 to the change management computer software 127. In one embodiment, an available approver (such as the change approver 140) upon receipt can agree to review the change request described by the RFC structure 134. If the approver agrees to review the change request, the approver is assigned as the primary approver for the change request (other approvers can review the change request on the primary approver's behalf, but the change management computer software 127 requires that the primary approver approve / deny the change request).

[0029] The user device 109 includes a non-transitory computer-readable medium 143 and at least one processor 141. The non-transitory computer-readable medium 143 stores computer-executable instructions 142. When the processor 141 executes the computer-executable instructions 142, the user device 109 is configured to receive user input and transmit the user input to the change management computer software 127.

[0030] In one embodiment, a change maker 147 executes the change request. As described in more detail below, the change management computer software 127 receives user input from a user device 113 (operated by the change maker 147) to receive success or failure messages for task items related to the change request. In one embodiment, the change maker 147 implements the network changes (i.e., software and / or hardware changes) via user input from the user device 113. The user device 113 of the change maker 147 sends success and / or failure messages for task items associated with the RFC structure 134.

[0031] When performing manual execution of a task item, a change maker 147 performs the change described in the task item. In one embodiment, the user device 113 includes a non-transitory computer-readable medium 149 and at least one processor 148. The non-transitory computer-readable medium 149 stores computer-executable instructions 146. When the processor 145 executes the computer-executable instructions 146, the user device 113 is configured to receive user input and transmit the user input to the change management computer software 127.

[0032] In one embodiment, the change request is automatically executed by a change execution platform, which is executed by processor 126 as part of change management computer software 127. In one embodiment, the change execution platform is operated by processor 126 as software separate from change management computer software 127. Processor 126 of the change execution platform receives the change request RFC structure 134, executes the network changes, and sends a success or failure message to change management computer software 127 for the task items related to the change request.

[0033] Change management computer software 127 automates and coordinates the communication process and management of change requests for computer network 105. As described above, change requests are described to computing system 100 by RFC structure 134. In one embodiment, RFC structure 134 describes approved, supported, and / or baselined hardware, network devices, software applications, environmental changes, system architecture changes, desktop build additions, modifications, and / or deletions along with associated documentation.

[0034] The change management computer software 127 is configured to generate an RFC structure 134 that describes a change request for the computerized network 105. In one embodiment, the change management computer software 127 is configured to generate a graphical user interface (GUI) that is presented to the change requester 130 via the user device 107. In one embodiment, the GUI presents selectable computer options that, when selected as user input, describe the change request by indicating the type of change, urgency level, risk level, impact, execution schedule, recommended task performers, and any other suitable parameters. Once the user input is received by the change management computer software 127, the change management computer software 127 is configured to generate the RFC structure 134. In one embodiment, the RFC structure 134 is presented to the change requester 130 for review and to receive any changes to the data in the RFC structure 134 from the change requester 130.

[0035] Once the change management computer software 127 generates the RFC structure 134, the change management computer software 127 is configured to select a target automated change request workflow 152 from multiple automated change request workflows 152 based on the RFC structure 134. The automated change request workflows 152 are executable files that automatically implement a workflow for implementing a change request or a portion of a change request. Different automated change request workflows 152 include different procedures depending on the data in the RFC structure 134. In one embodiment, the automated change request workflows 152 include a standard change request workflow, a non-standard change request workflow, and an emergency change request workflow. In one embodiment, the approvers 140, change managers 144, and / or implementers 147 involved in implementing the change request are selected by the change management computer software 127 via the automated change request workflows 152. Different types of changes, urgency levels, risk levels, network impacts, schedules, and / or change types result in workflows that include different approvers 140, change managers 144, and implementers 147, along with different procedures for implementing the network changes in the change request.

[0036] In one embodiment, the standard change request workflow, non-standard change request workflow, and emergency change request workflow levels are selected by the change management computer software 127 based on the urgency / importance of the change request. In one embodiment, the change requester 130 specifies the urgency / importance level. For example, the change requester 130 enters user input into an input field in a graphical user interface (GUI) indicating the urgency / importance level, and based on the selected level, the change management computer software 127 automatically selects between the standard change request workflow, non-standard change request workflow, and emergency change request workflow levels. Allowing the change requester 130 to specify the urgency / importance level provides flexibility to the change requester 130. For example, the urgency / importance of a change request, in one embodiment, varies between different change requesters 130 depending on the function performed by the change requester 130 (e.g., in one embodiment, a change request to increase network capacity is less urgent for a fault monitoring team but very urgent for a network engineering team). In one embodiment, the change management computer software 127 automatically determines the urgency / importance of a change request based on correlation of keyword(s), based on information about the change requester 130, and / or based on the blast radius / impact radius of the change request.

[0037] When a target automated change request workflow 152 is selected, the change management computer software 127 is configured to implement the target automated change request workflow 152. In one embodiment, the change management computer software 127 is configured to send the RFC structure 134 to the user devices 109 of at least one change approver 140 associated with the selected automated change request workflow 152. In one embodiment, the change management computer software 127 is configured to send the RFC structure 134 to the approvers 140 who are domain approvers. The domain approvers include system engineers, system programmers, and system operators responsible for domains within the cellular network 105. The domain approvers are presented with a visual representation of the RFC structure 134 to review the change request defined by the RFC structure 134. If the domain approver approves the change request described by the RFC structure 134, the domain approver sends an approval of the RFC structure 134 to the change management computer software 127. If the domain approver does not approve the change request described by the RFC structure 134, the domain approver sends a rejection of the RFC structure 134 to the change management computer software 127. In one embodiment, the domain approver can make changes to the RFC structure 134 or recommend changes to the change requester 130 to amend / change the RFC structure 134 in order to approve it.

[0038] In one embodiment, the RFC structure 134 is first sent to the change manager 144 before review by the domain approver. In one embodiment, the change manager 144 reviews a visual representation of the RFC structure 134 via a GUI presented on the user device 111. In one embodiment, the change manager 144 is responsible for reviewing the RFC structure 134 and scheduling the execution of the change request described by the RFC structure 134. For example, if the scheduling of the change request is performed manually rather than automated, the change manager 144 coordinates with the vendor to coordinate the execution timing and / or priority of different tasks related to the change request. The change manager 144 performs these tasks by providing user input via a GUI presented via the user device 111. An example of a GUI presented via the user device 111 is the GUI 200 shown in FIGS. 2A-2O and 3 . In one embodiment, the automated change request workflow 152 is first sent to the change manager 144 before review by the domain approver. The change manager 144 first reviews the RFC structure 134 and / or the automated change request workflow 152. For example, the change manager 144 reviews the requested urgency level, request type, execution schedule, and approvers / executors to determine whether the RFC structure 134 and / or automated change request workflow 152 are appropriate. If not, the change manager 144 makes changes to the RFC structure 134 and / or selects a different automated change request workflow 152. In one embodiment, the change manager 144 simply rejects the RFC structure 134 and / or automated change request workflow 152. If the change manager 144 approves the RFC structure 134, the change manager 144 provides user input to the GUI indicating approval of the RFC structure 134 and / or automated change request workflow 152.

[0039] In one embodiment, RFC structure 134 is sent to change manager 144 after the domain approver has made the changes and / or approved the change request embodied by RFC structure 134. Change manager 144 reviews RFC structure 134. If change manager 144 approves RFC structure 134, change manager 144 provides user input to the GUI indicating approval of RFC structure 134. Otherwise, change manager 144 makes the changes to RFC structure 134. In one embodiment, change manager 144 simply rejects RFC structure 134.

[0040] In one embodiment, change management computer software 127 is configured to send RFC structure 134 to approver 140, a security approver, for review of the change request defined by RFC structure 134. The security approver includes security personnel responsible for security in network 105. The security approver is presented with a visual representation of RFC structure 134. If the security approver approves the change request described by RFC structure 134, the security approver sends an approval of RFC structure 134 to change management computer software 127. If the security approver does not approve the change request described by RFC structure 134, the security approver sends a rejection of RFC structure 134 to change management computer software 127. In one embodiment, to approve RFC structure 134, the security approver can make changes to RFC structure 134 or recommend changes to change requester 130 to modify / alter RFC structure 134.

[0041] In one embodiment, the RFC structure 134 is first sent to the change manager 144 before review by the security approver. In one embodiment, the automated change request workflow 152 is first sent to the change manager 144 before review by the security approver. The change manager 144 first reviews the RFC structure 134 and / or the automated change request workflow 152. For example, the change manager 144 reviews the requested urgency level, request type, execution schedule, and approver / executor to determine whether the RFC structure 134 and / or the automated change request workflow 152 are appropriate. If not, the change manager 144 makes changes to the RFC structure 134 and / or selects a different automated change request workflow 152. In one embodiment, the change manager 144 simply rejects the RFC structure 134 and / or the automated change request workflow 152. If the change manager 144 approves the RFC structure 134, the change manager 144 provides user input to the GUI indicating approval of the RFC structure 134 and / or the automated change request workflow 152.

[0042] In one embodiment, RFC structure 134 is sent to change manager 144 after the security approver makes changes and / or approves the change request embodied by RFC structure 134. Change manager 144 reviews RFC structure 134. If change manager 144 approves RFC structure 134, change manager 144 provides user input to the GUI indicating approval of RFC structure 134. Otherwise, change manager 144 makes changes to RFC structure 134. In one embodiment, change manager 144 simply rejects RFC structure 134.

[0043] In one embodiment, the change management computer software 127 is configured to send the RFC structure 134 to an approver 140, who is a service experience center (SXC) approver. The SXC approver is responsible for checking whether the requested change will have any adverse effects on or conflict with the operation of the network 105. The SXC approver is presented with a visual representation of the RFC structure 134 to review the change request defined by the RFC structure 134. If the SXC approver approves the change request described by the RFC structure 134, the SXC approver sends an approval of the RFC structure 134 to the change management computer software 127. If the SXC approver does not approve the change request described by the RFC structure 134, the SXC approver sends a rejection of the RFC structure 134 to the change management computer software 127. In one embodiment, the SXC approver can approve the RFC structure 134 by making changes to the RFC structure 134 or by recommending changes to the change requester 130 to modify / alter the RFC structure 134.

[0044] In one embodiment, the RFC structure 134 is first sent to the change manager 144 before review by the SXC approver. In one embodiment, the automated change request workflow 152 is first sent to the change manager 144 before review by the SXC approver. The change manager 144 first reviews the RFC structure 134 and / or the automated change request workflow 152. For example, the change manager 144 reviews the requested urgency level, request type, execution schedule, and approver / executor to determine whether the RFC structure 134 and / or the automated change request workflow 152 are appropriate. If not, the change manager 144 makes changes to the RFC structure 134 and / or selects a different automated change request workflow 152. In one embodiment, the change manager 144 simply rejects the RFC structure 134 and / or the automated change request workflow 152. If the change manager 144 approves the RFC structure 134, the change manager 144 provides user input to the GUI indicating approval of the RFC structure 134 and / or the automated change request workflow 152.

[0045] In one embodiment, RFC structure 134 is sent to change manager 144 after the SXC approver makes changes and / or approves the change request embodied by RFC structure 134. Change manager 144 reviews RFC structure 134. If change manager 144 approves RFC structure 134, change manager 144 provides user input to the GUI indicating approval of RFC structure 134. Otherwise, change manager 144 makes changes to RFC structure 134. In one embodiment, change manager 144 simply rejects RFC structure 134.

[0046] When an appropriate approver 140 approves the change request described by the RFC structure 134, the change management computer software 127 is configured to transmit the RFC structure 134 to the user device 111 of the change manager 144. In one embodiment, as described above, the RFC structure 134 is transmitted to the user device 111 of the change manager 144 each time an approver approves a change request, or at some time thereafter.

[0047] In one embodiment, the change management computer software 127 generates a change request task list 154. The change request task list 154 describes various tasks to be performed by the change implementer 147 to implement the change request on the network 105. Thus, the automated change management task list 154 includes one or more task items for implementing the change request described by the RFC structure 134. In one embodiment, the change manager 144 is configured to provide user input to modify, approve, or reject the task list. The change management computer software 127 is configured to schedule task items in the change request task list 154 for the change request described in the RFC structure 134. In one embodiment, the change manager schedules the task items using manual user input. In other embodiments, the change management computer software 127 automatically schedules the task items based on the RFC structure 134. The change manager 144 is then configured to provide user input to approve the change request described by the RFC structure 134. In one embodiment, the change management computer software 127 automatically sends notifications to the change administrator 144 in response to status updates from the user devices 113 of the change actors 147 regarding the task items (e.g., completed, incomplete, successful, failed). In one embodiment, the change management computer software 127 automatically sends notifications to the change administrator 144 in response to a task item not being completed according to schedule. In one embodiment, the change management computer software 127 automatically sends notifications to the user devices 113 of other change actors 147 in response to a task item not being completed according to schedule. In one embodiment, the change management computer software 127 automatically updates the schedule for a task item and sends notifications to the user devices 113 of other change actors 147 in response to a task item not being completed according to schedule. In one embodiment, the scheduling of task items in the change request task list 154 is performed via a change execution platform.

[0048] In one embodiment, once the change administrator 144 approves the change request, the change management computer software 127 sends a notification of the scheduled task item to the user device 113 of the change executor 147 and / or the change execution platform. In one embodiment, the change executor 147 and / or the change execution platform implements the task described by the task item using the change management computer software 127. In one embodiment, the change executor 147 and / or the change execution platform implements the network change to the computer network 105 described by the task item independently of the change management computer software 127. In one embodiment, the change executor 147 and / or the change execution platform implements the software change to the computer network 105. In one embodiment, the change executor 147 and / or the change execution platform implements the hardware change and / or software change to the computer network 105. The change executor 147 sends change implementation result data 156 to the change management computer software 127 via the user device 113 and / or the change execution platform. Change implementation result data 156 identifies whether one or more task items in change request task list 154 are completed (e.g., successfully and fully executed) or incomplete (e.g., failed to execute or partially executed).

[0049] One of the key issues involved when implementing a change request is communication between the different users / stakeholders involved in the change request, such as the requester 130, approver 140, change manager 144, and change implementer 147. Motivations, outcomes, technical details, logistics, issues, and changes related to the change request are often discussed among the stakeholders (e.g., the requester 130, approver 140, change manager 144, and change implementer 147). To facilitate discussions between different users, the change management computer software 127 is configured to generate a GUI to include graphical items related to the change request and a graphical discussion room creation option. In response to receiving a user selection of the graphical discussion room creation option, the change management computer software 127 generates an electronic discussion room 190 that electronically connects at least some of the user devices 107, 109, 111, 113 associated with the users related to the change request (e.g., the requester 130, approver 140, change manager 144, and change implementer 147). In this manner, different parties involved in a change request can communicate and discuss various topics requiring discussion. In one embodiment, the change management computer software 127 is configured to process an electronic record (ER) 191 of the discussion (e.g., text messages, audio recordings, video recordings, etc.). In one embodiment, the change management computer software 127 is configured to generate an electronic text transcript (ETT) 192 of the electronic record (ER) 191 or any other suitable type of log of the discussion. In one embodiment, the change management computer software 127 generates a GUI to present the ER 191, the ETT 192, and / or the log to any user who has access to the GUI. In this manner, anyone who did not participate in an earlier discussion can review the ER 191 or ETT 192 to catch up on earlier discussions regarding the change request.

[0050] In one embodiment, electronic discussion room 190 is a video conference room, in which case user devices 107, 109, 111, 113 are used to transmit audio and video that is presented via a GUI. In one embodiment, electronic discussion room 190 is an audio conference room, in which case user devices 107, 109, 111, 113 are used to transmit audio that is presented via a GUI. In one embodiment, electronic discussion room 190 is a text conference room, in which case user devices 107, 109, 111, 113 are used to transmit text messages that are presented via a GUI.

[0051] In one embodiment, the electronic discussion room 190 is always live, and users / stakeholders (e.g., approver 140, requester 130, change manager 144, and change implementer 147) can participate in the discussion by simply interacting with a GUI via their respective user devices 107, 109, 111, 113. The electronic discussion room 190 is maintained throughout the lifecycle of the change request (e.g., the discussion room 190 remains active and accessible by users after each discussion session) and is closed when the change request is completed (e.g., after the implementation change request is completed). In other embodiments, when one of the users (e.g., approver 140, requester 130, change manager 144, and change implementer 147) needs to communicate with another of the users (e.g., approver 140, requester 130, change manager 144, and change implementer 147), an invitation and / or notification is sent by the change management computer software 127 to the particular user device 107, 109, 111, 113.

[0052] In one embodiment, the electronic discussion room 190 is generated by the change management computer software 127 by presenting a visual list of entities via a GUI associated with the change request in response to a user selection of a graphical discussion room creation option. The change management computer software 127 then receives a user selection of an entity / user selected from the visual list. In one embodiment, the entity includes the approver 140, the requester 130, the change manager 144, and / or the change maker 147. In one embodiment, the entity is an organization associated with the approver 140, the requester 130, the change manager 144, and / or the change maker 147. The change management computer software 127 is configured to present a graphical discussion room creation initiation option via the GUI. The change management computer software 127 then receives the user selection of the graphical discussion room creation initiation option and retrieves communication information regarding the entity selected from the visual list. The change management computer software 127 then generates an electronic discussion room 190 that electronically and communicatively connects the user devices (e.g., user devices 107, 109, 111, 113) of the selected entities / users (e.g., approver 140, requestor 130, change manager 144, and / or change maker 147) based on the communication information. In one embodiment, the communication information includes email, phone number, IP address, messaging handle, account identifier, hyperlink, conference identifier, conference password, etc.

[0053] In one embodiment, the change management computer software 127 implements a unified communication platform to generate an electronic discussion room 190. According to one embodiment, when a change request is submitted by a requester 130 via the change management computer software 127, any stakeholder in the change request (e.g., approver 140, requester 130, change manager 144, and / or change implementer 147) can create an electronic discussion room 190 and invite other stakeholders. In one embodiment, the electronic discussion room 190 is maintained throughout the lifecycle of the change request. In one embodiment, the unified communication platform generates logs (e.g., ER 191, ETT 192, etc.) that allow users to review previous discussions. After the change request is implemented / executed and closed, the centralized change management system automatically instructs the unified communication platform to close the discussion room (e.g., to avoid message spamming of stakeholders, avoid wasting network resources, etc.). Nevertheless, logs (e.g., minutes and history of discussions) are stored in a centralized database (e.g., by a unified communication platform) so that interested parties can view and download them in the future if necessary.

[0054] FIG. 2A is a GUI 200 that includes a panel 202 used to create an RFC structure, according to one embodiment.

[0055] In one embodiment, change management computer software 127 is configured to generate a GUI 200 including a panel 202 that is presented to a change requester 130 via a user device 107 (see FIG. 1).

[0056] In one embodiment, panel 202 includes selectable items that describe the cause of the network change for which the change request is made. In FIG. 2A , the selectable items are “Capacity Expansion,” “Network Maintenance,” “Troubleshooting,” “Site Maintenance,” “Optimization,” “Software or Configuration Change,” or “Other Network Carrier Work.” The selectable item “Capacity Expansion” is selected when additional hardware and / or software is being added to network 105 (see FIG. 1 ). “Network Maintenance” is when maintenance is being performed on network 105. The selectable item “Troubleshooting” is selected when the functionality of a network element needs to be inspected and / or modified. The selectable item “Site Maintenance” is selected when maintenance is being performed on a portion of network 105. The selectable item “Optimization” is selected when optimizing a portion of network 105. The selectable item “Software or Configuration Change” is selected when software changes (e.g., additions, reductions, modifications, etc.) are being made or hardware reconfigurations are being made in network 105. The selectable item “Other Network Carrier Work” is selected when various network changes are being made to a portion of network 105. In at least one example, the selectable item "Site Maintenance" is selected.

[0057] Panel 202 also includes selectable items for the type of change. The change types include selectable items for “standard,” “non-standard,” and “emergency.” In one embodiment, panel 202 includes selectable items for more change types (e.g., predefined types such as “Level 2 Emergency” or defined by the change requester such as “Project X Emergency Change”) or fewer change types as shown in FIG. 2A . In one embodiment, these selectable items select the broadest categories of automated workflows. When the selectable item “standard” is selected, a workflow is selected for the automated implementation of standard network changes. When the selectable item “non-standard” is selected, a workflow is selected for the automated implementation of non-standard network changes. When the selectable item “emergency” is selected, a workflow is selected for the automated implementation of emergency network changes.

[0058] FIG. 2B is a GUI 200 that includes a panel 204 used to create an RFC structure, according to one embodiment.

[0059] In one embodiment, the change management computer software 127 is configured to generate a GUI 200 including a panel 204 that is presented to a change requester 130 via a user device 107 .

[0060] In Figure 2B, panel 204 includes selectable options regarding whether "Services Affected?" The change requester 130 (see Figure 1) selects yes, no, or unknown.

[0061] Panel 204 includes selectable options for the change requester to input a range estimate for the number of users affected by the network change. In one embodiment, the selectable options are a sliding bar and an input window (as shown in FIG. 2B). In one embodiment, the selectable options may be a drop-down list (not shown) or any suitable option for receiving user input for specifying a user range.

[0062] Panel 204 includes selectable options that indicate the urgency level of the change request. In one embodiment, the selectable options include selectable buttons such as "low," "medium," "high," and "critical," as shown in FIG. 2B. In one embodiment, the selectable options may be a sliding bar, a drop-down list (not shown), or any suitable option for receiving user input to specify the urgency level.

[0063] In one embodiment, panel 204 includes selectable options that allow change requester 130 to indicate which services, devices, and / or users within network 105 will be affected by the requested change. In one embodiment, these selectable options include a drop-down list or pull-down bar (e.g., shown in FIG. 2B as "Which services are affected?"). In one embodiment, these selectable options may be a drop-down list (not shown) that includes possible services, devices, and / or users within network 105 that will be affected, or any suitable option for receiving user input to specify the services, devices, and / or users within network 105 that will be affected.

[0064] In the summary section of panel 204, panel 204 displays a summary of the required fields for the change request as defined by the selections made by change requester 130. In addition, the summary section includes a pull-down bar / drop-down list with selectable options for change requester 130 to select a priority level for the change request. In Figure 2B, change requester 130 has selected "Low" as the priority for the change request.

[0065] FIG. 2C is a GUI 200 including a panel 206 used to generate an RFC structure, according to one embodiment.

[0066] 2C , panel 206 includes selectable options that allow the change requester to specify an execution timeline for the requested change. In one embodiment, these selectable options include a virtual calendar that allows the change requester 130 to select a start and end timeline (e.g., date and time) for the execution of the requested change. In one embodiment, these selectable options include an input window, a drop-down list, or other suitable options for receiving user input for specifying the start and end timeline for the execution of the requested change.

[0067] FIG. 2D is a GUI 200 including a panel 208 used to generate an RFC structure, according to one embodiment.

[0068] In FIG. 2D, panel 208 includes various drop-down lists / menus with selectable options.

[0069] One of the drop-down lists / pull-down menus includes an option (shown in FIG. 2D as "Will this change impact customers?") that allows the change requester 130 to select whether the change will impact customers. In one embodiment, the options include "Yes," "No," and "Unknown." In one embodiment, the options include more detailed selectable options such as "Yes - Level 1 Impact," "Yes - Level 2 Impact," etc., to allow the user to more specifically specify the customer impact.

[0070] One of the drop-down lists / pull-down menus includes an option to describe whether there have been previous issues implementing the same change (shown in FIG. 2D as "Have you previously deployed this change and encountered issues during implementation?"). In one embodiment, the options include "Yes," "No," "Not available," and "Unknown." In one embodiment, the options include more detailed selectable options such as "Yes - Last Month," "Yes - Within the Last Year," etc. to allow the user to more specifically describe the time range in which the same change was previously deployed and / or encountered issues.

[0071] One of the drop-down lists / pull-down menus includes an option for the change requester 130 to select whether the change will be implemented during a standard change window (shown in FIG. 2D as "Are changes implemented during a standard change maintenance window?"). In one embodiment, the options include "Yes," "No," "Not available," and "Unknown."

[0072] One of the drop-down lists / pull-down menus includes an option (shown in FIG. 2D as "How long will it take to implement the rollback plan?") for the change requestor 130 to input an amount of time for the cellular network 105 to reconfigure to the state of the cellular network 105 before the change request was implemented. One of the drop-down lists / pull-down menus includes an option (shown in FIG. 2D as "Is there redundancy available?") for the change requestor 130 to select whether there is a redundant system available to maintain the computer network 105 while the network change is being implemented. In one embodiment, the options include "Yes," "No," "Unavailable," and "Unknown." In one embodiment, the options include more detailed selectable options, such as "Yes - Device A," "Yes - Device B," etc., to allow the user to more specifically select a redundant device.

[0073] FIG. 2E is a GUI 200 that includes a panel 210 used to describe task items for a change request, according to one embodiment.

[0074] Panel 210 visually displays various data fields, including, but not limited to, the title of the change request (i.e., “Title” in FIG. 2E ), an urgency identifier (i.e., “Urgency” in FIG. 2E ), an identifier indicating whether network services will be affected (i.e., “Service Impact” in FIG. 2E ), a field identifying the number or scope of network users affected by the change request (i.e., “Affected Users” in FIG. 2E ), a field indicating the date and time the task item started (i.e., “Implementation Start Date” in FIG. 2E ), and a field indicating the date and time the task item was completed (i.e., “Implementation End Date” in FIG. 2E ). Panel 210 includes sub-panel 212, which is configured to display details about the change request (i.e., “Basic Details” in FIG. 2E ), display relationships between different task items within the change request (i.e., “Relationship Mapping” in FIG. 2E ), and display the different task items of the change request (i.e., “Tasks” in FIG. 2E ). User input is received from the user, resulting in the presentation of one of three options in sub-panel 212.

[0075] More specifically, in one embodiment, the illustrated text "Basic Details" is selectable by a user such that basic information about the change request is presented in panel 212. In one embodiment, the illustrated text "Basic Details" is selectable by clicking a pointer controlled by a mouse. In one embodiment, the illustrated text "Relationship Mapping" is selectable by a user such that relationships between different change requests (e.g., relationships between the current request and previous requests, relationships between the current request and request IDs of other requests, etc.) are shown in panel 212. In one embodiment, the illustrated text "Relationship Mapping" is selectable by clicking a pointer controlled by a mouse. In one embodiment, the illustrated text "Tasks" is selectable by a user such that relationships between different change requests are shown in panel 212. In one embodiment, the illustrated text "Tasks" is selectable by clicking a pointer controlled by a mouse. In the example shown in FIG. 2E, exemplary tasks for the current change request are shown.

[0076] In Figure 2E, a button labeled "Next" is selectable by the user to move to the next panel of GUI 200. A button labeled "Create" is provided to create a new task. A button labeled "Cancel" is provided to allow the user to cancel an undesired selection.

[0077] FIG. 2F is a GUI 200 including a panel 214 used to create a task item, and according to one embodiment, a template option is selected.

[0078] Panel 214 visually depicts a template option (i.e., "Template" in FIG. 2F), a definition option (i.e., "Define" in FIG. 2F), and a settings option (i.e., "Settings" in FIG. 2F). In one embodiment, the template option, definition option, and settings option are set sequentially. For example, a user first provides user input for the template option. Once the user provides user input for the template option, the user is presented with the definition option. Once the user provides user input for the definition option, the user is presented with the settings option. The user then provides user input for the settings option.

[0079] In FIG. 2F , various template options are presented in sub-panel 216 of panel 214. User input is received to allow the user to select between the manual task option (i.e., “Manual” in FIG. 2F ) or between the various template task options (i.e., “Template Task Item 1,” “Template Task Item 2,” and “Template Task Item 3” in FIG. 2F ). In an embodiment, the various template task options include an automated task option, a semi-automated task option, or any appropriate type of task option. If user input is received to select the manual task option, the user is permitted to manually create a task for the particular change request. Each of the various template task options has one or more predefined tasks. The task items defined by the selected template task option are automatically assigned to RFC structure 134 in response to selecting one of the template task options.

[0080] In Figure 2F, a button labeled "Next" is selectable by the user to move to the next panel of GUI 200. A button labeled "Create" is provided to create a new task using the selected template. A button labeled "Cancel" is provided to allow the user to cancel undesired selections.

[0081] FIG. 2G is a GUI 200 including a panel 214 used to create a task item, presenting a template option followed by a definition option and a basic information option according to one embodiment.

[0082] In FIG. 2G, sub-panel 216 is configured to allow the user to enter user input regarding basic information for the new task to manually define the task item.

[0083] A text bar named "Task Name" is provided where the user can enter text for the name of the task item. A text bar named "Environment" is provided where the user can enter text for the environment of the task item. In the text bar named "Environment", user text describing the location of the data center is received. A text bar named "Description" is provided where the user can enter text for the description of the task item.

[0084] In Figure 2G, a button named "Next" is selectable by the user to move to the next panel of GUI 200. A button named "Create" is provided to create a new task. A button named "Cancel" is provided to allow the user to cancel an undesired selection.

[0085] FIG. 2H is a GUI 200 including a panel 214 used to create a task item, where a definition option is presented after user input regarding the definition option is received and a scheduling option is shown, according to one embodiment.

[0086] In FIG. 2H, sub-panel 216 is configured to allow the user to enter user input regarding the scheduling of the task.

[0087] The scheduling menu is configured to allow a user to enter user input regarding a start date for a task item (i.e., "Start Date" in FIG. 2H). The scheduling menu is configured to allow a user to enter user input regarding a start time for a task item (i.e., "Start Time" in FIG. 2H). The scheduling menu is configured to allow a user to enter user input regarding an end date for a task item (i.e., "End Date" in FIG. 2H). The scheduling menu is configured to allow a user to enter user input regarding an end time for a task item (i.e., "End Time" in FIG. 2H).

[0088] In one embodiment, the task item includes an outage in the network. If no outage occurs, the associated field appears as N / A. In one embodiment, the scheduling menu is configured to allow a user to enter user input regarding a start date for the outage of the task item (i.e., "Start Date of Outage" in FIG. 2H). The scheduling menu is configured to allow a user to enter user input regarding a start time for the outage of the task item (i.e., "Start Time of Outage" in FIG. 2H). The scheduling menu is configured to allow a user to enter user input regarding a stop date for the task item (i.e., "End Date of Outage" in FIG. 2H). The scheduling menu is configured to allow a user to enter user input regarding a stop time for the task item (i.e., "End Time of Outage" in FIG. 2H).

[0089] In Figure 2H, a button labeled "Next" is selectable by the user to move to the next panel of GUI 200. A button labeled "Create" is provided to schedule a new task. A button labeled "Cancel" is provided to allow the user to cancel undesired selections.

[0090] FIG. 2I is a GUI 200 including a panel 214 used to create a task item, where devices for the task can be selected, as shown according to one embodiment.

[0091] In Figure 2I, the settings option is shown after user input for the define option has been received. Sub-panel 216 is configured to allow the user to enter devices for the task item.

[0092] In FIG. 2I, the manual and file upload options are configured to define devices related to the task item. When the file upload option is selected, the user can upload a file defining devices affected by the task item. When the manual option is selected (as shown in FIG. 2I), the user enters or selects a network element ID in the search bar. Additionally, the target option (i.e., “Target” in FIG. 2I) and the affected option (i.e., “Affected” in FIG. 2I) allow the user to identify whether a device is the target of the task item or whether the device is simply affected by the task item. Once the user selects a desired network element and specifies whether the selected network element is the target of the task item or simply affected by the task item, the user selects an interactive element (e.g., an “Add” button as shown in FIG. 2I) to add the network element to a list presented in sub-panel 216. In one embodiment, when the manual option is selected (as shown in FIG. 2I), the user enters or selects a keyword associated with the desired device (e.g., a keyword associated with device type, device location, device labeling, etc.) in the search bar, and the system presents network elements related to the keyword in a list presented in sub-panel 216. The user can then select one or more desired network elements from a list that provides a network element ID (i.e., "Network Element ID" in FIG. 2I), an identifier that identifies the device type (i.e., "Type" in FIG. 2I), an identifier that identifies the area affected by the device (i.e., "Impact" in FIG. 2I), and an identifier that identifies the location of the device (i.e., "Location" in FIG. 2I). In one embodiment, if the file upload option is selected and the user uploads a file to the system, the system processes the file to obtain relevant information and presents such information in a list shown in sub-panel 216.

[0093] In Figure 2I, a button labeled "Next" is selectable by the user to move to the next panel of GUI 200. A button labeled "Create" is provided to include a new device for the task. A button labeled "Cancel" is provided to allow the user to cancel an undesired selection.

[0094] Figure 2J shows the settings options shown after user input for the define option is received. Sub-panel 216 is configured to allow the user to select a device for the task item. Sub-panel 216 of Figure 2J is an alternative example of sub-panel 216 of Figure 2I.

[0095] In FIG. 2J , the manual and file upload options are configured to define devices related to the task item. When the file upload option is selected, the user can upload a file defining devices affected by the task item. When the manual option is selected (as shown in FIG. 2J ), the user enters or selects a network element ID in the search bar. Additionally, the target option (i.e., “Target” in FIG. 2J ) and the affected option (i.e., “Affected” in FIG. 2J ) allow the user to identify whether a device is the target of the task item or whether the device is simply affected by the task item. Once the user selects a desired network element and specifies whether the selected network element is the target of the task item or simply affected by the task item, the user selects an interactive element (e.g., an “Add” button as shown in FIG. 2J ) to add the network element to the map presented in sub-panel 216. In one embodiment, when the manual option is selected (as shown in FIG. 2J ), the user enters or selects a keyword associated with the desired device (e.g., a keyword associated with device type, device location, device labeling, etc.) in the search bar, and the system presents network elements related to the keyword in the map presented in sub-panel 216. The user can then select one or more desired network elements from the map. The map identifies each device within the specified area and identifies the device by device name (e.g., "Device 1," "Device 2," etc.). In one embodiment, if the file upload option is selected and the user uploads a file to the system, the system processes the file to obtain relevant information and presents such information on the map shown in sub-panel 216.

[0096] In Figure 2I, a button labeled "Next" is selectable by the user to move to the next panel of GUI 200. A button labeled "Create" is provided to include a new device for the task. A button labeled "Cancel" is provided to allow the user to cancel an undesired selection.

[0097] FIG. 2K is a GUI 200 including a panel 214 used to define a task item, according to one embodiment.

[0098] In Figure 2K, template task item 1 from Figure 2F has been selected. Sub-panel 216 is set up to allow the user to enter user input regarding basic information for the new task to define the task item.

[0099] A text bar named "Task Name" is provided where the user can enter text for the name of the task item. A text bar named "Description" is provided where the user can enter text for the description of the task item.

[0100] In Figure 2K, a button named "Next" is selectable by the user to move to the next panel of GUI 200. A button named "Create" is provided to create a new task. A button named "Cancel" is provided to allow the user to cancel an undesired selection.

[0101] FIG. 2L is a GUI 200 including a panel 214 used to define a task item, according to one embodiment.

[0102] In Figure 2L, template task item 1 from Figure 2F has been selected. Sub-panel 216 is configured to allow a user to input task items associated with devices, as described above with respect to Figure 2I. More specifically, sub-panel 216 allows a user to provide user input to select a device associated with template task item 1 (as described above with respect to Figure 2I).

[0103] In Figure 2L, a button named "Next" is selectable by the user to move to the next panel of GUI 200. A button named "Create" is provided to include a new device for the task. A button named "Cancel" is provided to allow the user to cancel an undesired selection.

[0104] FIG. 2M is a GUI 200 including panels 214 used to show change requests each associated with the same template task item, according to one embodiment.

[0105] In Figure 2M, Template Task Item 1 from Figure 2F is selected. Panel 214 also shows a selection option named "Template Task Item 1." Thus, each change request according to "Template Task Item 1" is shown in panel 216 in card view.

[0106] In Figure 2M, a button named "Next" is selectable by the user to move to the next panel of GUI 200. A button named "Create" is provided to include a new change request under template task item 1. A button named "Cancel" is provided to allow the user to cancel undesired selections.

[0107] FIG. 2N is a GUI 200 including a panel 214 used to define parameters in response to a card being selected in FIG. 2M, according to one embodiment.

[0108] In Figure 2N, manual and file upload options are included in sub-panel 216 for defining parameters for a task item. In Figure 2N, the file upload option is selected, allowing the user to upload a file that defines the parameters and parameter values ​​to be affected by the task item. In Figure 2N, sub-panel 216 includes a drag-and-drop area 217 where the user drops a file that defines the parameters (e.g., values, keywords, etc.) for the task item.

[0109] In Figure 2N, a button labeled "Next" is selectable by the user to move to the next panel of GUI 200. A button labeled "Create" is provided to include a new file with parameters. A button labeled "Cancel" is provided to allow the user to cancel undesired selections.

[0110] FIG. 2O illustrates an embodiment in which the manual option (described in connection with FIG. 2N) has been selected. In response to the manual option being selected (as shown in FIG. 2O), a user selects from among the parameters and enters parameter values. In FIG. 2O, a list provides entries for the parameters. The list identifies the parameters by parameter name (i.e., "Parameter Name" in FIG. 2O). For each entry, the list includes a text box into which the parameter value for the associated parameter is entered, and also includes a check box associated with each parameter that allows the user to select (e.g., by clicking the check box) which parameters in the list should be included to define the task item.

[0111] In Figure 2O, a button labeled "Next" is selectable by the user to move to the next panel of GUI 200. A button labeled "Create" is provided to include a new file with parameters. A button labeled "Cancel" is provided to allow the user to cancel undesired selections.

[0112] FIG. 3 is a visual representation presented in GUI 200 of a Request for Change (RFC) structure 300, according to one embodiment.

[0113] RFC structure 300 corresponds to RFC structure 134 of Figure 1. RFC structure 300 includes a change request identifier (i.e., "ID" in Figure 3), a change request title (i.e., "Title" in Figure 3), a ticket number (i.e., "Lab Ticket Number" in Figure 3), an urgency identifier (i.e., "Urgency" in Figure 3), a priority identifier (i.e., "Priority" in Figure 3), an impact on network operation indicator (i.e., "Is Network Operation Affected?" in Figure 3), an affected service indicator (i.e., "Affected Service" in Figure 3), an environment indicator (i.e., "Environment" in Figure 3), an outage duration indicator (i.e., "Outage Duration" in Figure 3), an escalator name indicator (i.e., "Escalator Name" in Figure 3), an escalator number indicator (i.e., "Escalator Phone" in Figure 3), a change requester identifier (i.e., "Escalator" in Figure 3), and a scalator ID (i.e., "ID" in Figure 3). 3), a project activity or operational activity indicator (i.e., "Project Activity or Operation Activity" in FIG. 3), a change request cause indicator (i.e., "Change Request Cause" in FIG. 3), a change request type indicator (i.e., "Type" in FIG. 3), an impact indicator (i.e., "Impact" in FIG. 3), a stop request indicator (i.e., "Request for Stop" in FIG. 3), an affected target indicator (i.e., "Affected Service" in FIG. 3), a task execution mode identifier (i.e., "Task Execution Mode" in FIG. 3), a change request description (i.e., "Change Request Description" in FIG. 3), a description of the impact assessment (i.e., "Impact Assessment" in FIG. 3), and a description of the expected outcome (i.e., "Expected Outcome" in FIG. 3). Identifiers of related documents are also included in the RFC structure 300.

[0114] According to one embodiment, the ticket number is used to identify a testing procedure for the requested change before actually implementing the requested change in the network 105. In one embodiment, if the change cannot be tested in a testing lab, an accompanying document indicates the exact reasons why the network change cannot be tested. In one embodiment, the ticket number is presented in various formats according to the results of the testing procedure. For example, if the requested change is determined to be unacceptable during the testing procedure (e.g., the requested change creates a security issue, the requested change has an unacceptable adverse effect on the network, etc.), the ticket number is presented in red, indicating that the RFC structure 300 did not pass the testing procedure. If the requested change is still undergoing the testing procedure, the ticket number is presented in amber, indicating that the RFC structure 300 is still being tested. If the requested change passes the testing procedure, the ticket number is presented in green, indicating that the RFC structure 300 has passed the testing procedure.

[0115] The target automated change request workflow is selected from multiple automated change request workflows based on RFC structure 300. In one embodiment, the broadest categories of automated change request workflows are standard workflows, non-standard workflows, and emergency workflows. According to one embodiment, which of these workflows is selected depends at least on the designation provided in the change request type indicator. Each of these different categories of workflows has different procedures, such as different approvers 140 (see FIG. 1 ) for approving the change request. Various workflows fit into different subcategories depending on the data provided in the data fields of RFC structure 300. For example, different workflows are selected depending on which portion of network 105 the change request is directed to and / or whether the requested change will impact customers.

[0116] RFC structure 300 is presented via GUI 200, and change approvers 140, change managers 144, and change implementers 147 review the information in RFC structure 300. RFC structure 300 describes a change request. In one embodiment, GUI 200 includes options that allow change approvers 140, change managers 144, and change implementers 147 to modify the data in RFC structure 300. In one embodiment, GUI 200 includes options for defining network elements affected by the change request, neighboring network elements affected by the change request, and a schedule for network outages and execution of the network changes. Each of these parameters defines a subcategory of the selected workflow.

[0117] FIG. 4A is a panel 400 of GUI 200 for a list of RFC structures, according to one embodiment.

[0118] Panel 400 includes an entry 402 for a standard workflow for an RFC structure, an entry 404 for a non-standard workflow for an RFC structure, and an entry 406 for an emergency workflow for an RFC structure. By selecting any of entries 402, 404, 406, change management computer software 127 is configured to present a visual representation of the RFC structure. Change requesters, change approvers, change managers, and change implementers are presented in panel 400 to select from among the different RFC structures associated with a particular change request.

[0119]

[0120]

[0121] FIG. 4B is a panel 408 of GUI 200 presenting a list of the status of RFC structures, according to one embodiment.

[0122] The panel includes various data fields, including, but not limited to, the amount of time that has passed since the change request was created (i.e., "Elapsed Time" in FIG. 4B - if enough time has passed, this feature will be indicated as expired), an indicator as to whether the approval process is progressing as scheduled (e.g., "On Track" in FIG. 4B is the status in the "Timeliness Status" field), an urgency identifier (i.e., "Urgency" in FIG. 4B), the amount of time the outage on the network was planned for (i.e., "Planned Outage" in FIG. 4B), the start date and time for which approval was sought (i.e., "Start Date / Time" in FIG. 4B), and the end date and time for which approval was obtained (i.e., "End Date / Time" in FIG. 4B).

[0123] Additionally, a list of different types of approvals for the change request is presented. The list includes entries 410, 412, 414, and 416. Each entry 410, 412, 414, and 416 has fields for the type of task being approved (i.e., "Approval Task" in FIG. 4B), the person to whom the approval is assigned (i.e., "Assigned Person" in FIG. 4B), the person who approved it (i.e., "Approver" in FIG. 3), and the date and time of approval (i.e., "Approval Date" in FIG. 4B).

[0124] Entry 410 relates to SXC approval and is selected, providing an authorized SXC approver with selectable options to reschedule the SXC approval of the change request, approve the SXC approval of the change request, or deny the SXC approval of the change request. Entry 412 relates to domain approval and is not selected. Entry 414 relates to security approval and is not selected. Additionally, entry 416 relates to CAB approval and is not selected.

[0125] 4B, panel 408 also includes a graphical discussion room creation option 418 ("Conference Room" button in FIG. 4B). In response to receiving a user selection of graphical discussion room creation option 418, change management computer software 127 is configured to generate an electronic discussion room that electronically and communicatively connects user devices (e.g., user device 107, user device 109, user device 111, and / or user device 113) of users (e.g., change requester 130, change approver 140, change manager 144, and / or change implementer 147).

[0126] In one embodiment, the electronic discussion room is already set up, and the electronic discussion room automatically starts in response to selection of the graphical discussion room creation option 418 without further user interaction with GUI 200. However, in one embodiment, the electronic discussion room is not set up when the user selects the graphical discussion room creation option 418. In this case, as described in further detail below, in response to receiving a user selection of the graphical discussion room creation option 418, the change management computer software 127 is configured to generate and present a panel in GUI 200 to enable the user to enter parameters specifying selections for setting up the electronic discussion room (e.g., specifying which entities / users should be included in the electronic discussion room, specifying a title for the visual discussion room, etc.). The change management computer software 127 then generates, based on the user input parameters, an electronic discussion room that electronically and communicatively connects the user devices (e.g., user device 107, user device 109, user device 111, and / or user device 113) of the users (e.g., change requester 130, change approver 140, change manager 144, and / or change implementer 147) based on the communication information.

[0127] 5 is a panel 500 of GUI 200 showing a list of entities (i.e., CA1, CA2, CA3, CA4, CA5) available for creating a new electronic discussion room, as well as a visual representation of other electronic discussion rooms that have already been created, according to one embodiment. In one embodiment, the list of available entities includes entities associated with the change request (e.g., change requester 130 or an organization associated with change requester 130, change approver 140 or an organization associated with change approver 140, change manager 144 or an organization associated with change manager 144, change implementer 147 or an organization associated with change implementer 147).

[0128] In one embodiment, the panel 500 is presented in response to receiving a user selection of the graphical discussion room creation option 418 of FIG. 4B.

[0129] The sub-panel titled "Available Entities" includes selectable graphical items (i.e., circles labeled with the names of entities CA1, CA2, CA3, CA4, and CA5) representing entities that can be selected to create a new electronic discussion room. The sub-panel titled "Available Entities" also includes a graphical start discussion room option 502 (the option titled "Start Discussion Room" in FIG. 5). A user selects a graphical item representing an entity. In response to selecting the start graphical discussion room option 502, the change management computer software 127 is configured to retrieve communication information (e.g., user ID, availability status, email, phone number, IP address, personal or entity identifier, etc.) of the entity selected from the visual list. Based on the communication information, an electronic discussion room is generated that electronically and communicatively connects the user's user devices.

[0130] In FIG. 5 , panel 500 also shows data about electronic discussion rooms (i.e., “Conference Room 1,” “Conference Room 2”) already created by change management computer software 127. Panel 500 shows graphical items for entities that are part of the already created conference rooms (i.e., circles labeled CA3 and CA4 for Conference Room 1, and circles labeled CA3, CA4, CE1, and CR1 for Conference Room 2). The panel also includes a conference room identifier for each electronic discussion room (e.g., “Meeting ID: 0001” for Conference Room 1 and “Meeting ID: 0002” for Conference Room 2) and a password (e.g., “Password: 209842” for Conference Room 1 and “Password: 219345” for Conference Room 2). In one embodiment, panel 500 includes an identifier (not shown in FIG. 5 ) for indicating the electronic discussion room as having a live discussion and / or describing which users are online and available for discussion (e.g., a status indicator such as “green” or “Live” indicating the room is live). Users included in an electronic discussion room can start a meeting simply by selecting the electronic discussion room.

[0131] FIG. 6 is a table 600 of communication information for a selected entity generated and presented in response to selecting the conference room in FIG. 5 (e.g., by clicking on the conference room identifier, etc.), according to one embodiment.

[0132] In this case, the entities identified as CA1 and CA2 in FIG. 6 were selected from a visual list including CA1, CA2, CA3, CA4, and CA5 in FIG. 5. The table includes a network availability identifier (i.e., "Status" in FIG. 6), a name identifier (i.e., "Name" in FIG. 6), an identifier of the type of entity (i.e., "Entity Type" in FIG. 6), an email (i.e., "Email" in FIG. 6), a phone number (i.e., "Phone Number" in FIG. 6), and an IP address (i.e., "IP Address" in FIG. 6). Table 600 presents details of each electronic discussion room that has been created. The above information in table 600 is an exemplary embodiment, and it is understood that the information included in table 600 can be any suitable information associated with an entity.

[0133] FIG. 7 is a panel 700 that allows a user to manually set up / reset up an electronic discussion room (ie, meeting ID, passcode), according to one embodiment.

[0134] In one embodiment, the electronic discussion room is provided by any appropriate channel and technology, such as a social platform, an instant messaging application, an audio application (e.g., a voice-over-IP application, etc.). In another embodiment, the change management computer software 127 automatically configures the electronic discussion room when the discussion room is created. For example, when a user selects a discussion room creation option (e.g., a “Create Discussion Room” button, etc.), the change management computer software 127 automatically collects information about each selected user to be included in the discussion room (e.g., which channels / technology are available to all users, which channels / technology are most frequently used, etc.), determines the discussion room type (e.g., video conferencing, instant messaging application, email, etc.) based on the collected information, and creates a discussion room with an appropriate conference ID and passcode (e.g., a video and audio conference room, a group chat in an instant messaging application, an email list, etc.) based on the determined discussion room type. FIG. 7 provides a text bar for the user to enter a desired name for the electronic discussion room (e.g., “Conference ID” in FIG. 7). FIG. 7 also provides a text bar for the user to enter a desired code or password for the electronic discussion room (e.g., “Passcode” in FIG. 7). Once an electronic discussion room is created, all entities involved in the electronic discussion receive a notification (eg, email, SMS, etc.) informing the users about the electronic discussion room.

[0135] FIG. 8 is a flow diagram 800 of a method for conducting electronic communication regarding a change request over a computerized network according to one embodiment.

[0136] In one embodiment, the flow chart 800 is implemented by change management computer software 127 executed by processor 126 of network change management computer device 102 shown in Figure 1. An example computer network includes computer network 105 of Figure 1, according to one embodiment. The flow chart 800 includes blocks 802-814. The flow begins at block 802.

[0137] At block 802, an RFC structure is generated that describes a request for a change to a computerized network. Examples of RFC structures include RFC structure 134 of Figure 1 and RFC structure 300 of Figure 3. Flow then proceeds to block 804.

[0138] At block 804, a GUI is presented on the first user device, the GUI including a graphical item related to a change request and a graphical discussion room creation option. According to one embodiment, an example GUI includes GUI 200 of Figures 2-7. According to one embodiment, an example graphical item related to a change request is shown in panel 500 of Figure 5. An example graphical discussion room creation option includes graphical discussion room creation option 418 of Figure 4. Flow then proceeds to block 806.

[0139] At block 806, in response to receiving a user selection of the graphical discussion room creation option, an electronic discussion room is created that electronically connects user devices associated with the user regarding the change request. According to one embodiment, an example of an electronic discussion room is electronic discussion room 190. Example user devices are user device 107, user device 109, user device 111, and / or user device 113 of FIG. 1 according to one embodiment. According to one embodiment, an example user is change requester 130, change approver 140, change manager 144, change implementer 147, and / or any stakeholder associated with the change request. Flow then proceeds to block 808.

[0140] An electronic record of the electronic discussion room is created at block 808. According to one embodiment, an example of the electronic record includes ER 191 of Figure 1. Flow then proceeds to block 810.

[0141] At block 810, the electronic record is stored in a database. An example of a database is database 104 of Figure 1. Flow then proceeds to block 812.

[0142] At block 812, an electronic text transcript (e.g., a log file) of the electronic record is generated. An example of an electronic text transcript is ETT 192 of Figure 1. Flow then proceeds to block 814.

[0143] At block 814, the electronic text transcript is stored in a database.

[0144] FIG. 9 is a flow diagram 900 of a method for creating an electronic discussion room according to one embodiment.

[0145] Flowchart 900 includes blocks 902-910. In one embodiment, blocks 906-910 are an example of block 806 of Figure 8. In one embodiment, blocks 902-904 occur before block 806. The flow begins at block 902.

[0146] At block 902, a visual list of entities associated with the change request is presented in response to a user selection of a graphical discussion room creation option. In one embodiment, an example of a visual list of entities is a sub-panel titled "Available Entities" that includes graphical items representing entities that can be selected to create a new electronic discussion room (e.g., circles labeled with the names of entities CA1, CA2, CA3, CA4, and CA5 in FIG. 5). Flow then proceeds to block 904.

[0147] A user selection of a selected entity from the visual list is received at block 904. In one embodiment, the entities identified as CA1 and CA2 in Figure 6 were selected from a visual list including CA1, CA2, CA3, CA4, and CA5 in Figure 5. Flow then proceeds to block 906.

[0148] At block 906, a second user selection of a graphical discussion room creation start option is received. An example of a graphical discussion room start option is graphical discussion room start option 502 of Figure 5, according to one embodiment. Flow then proceeds to block 908.

[0149] At block 908, communication information for the entity selected from the visual list is obtained. In one embodiment, an example of the communication information is shown in table 600 of Figure 6. Flow then proceeds to block 910.

[0150] At block 910, an electronic discussion room is generated based on the communication information, electronically and communicatively connecting the user devices of the users.

[0151] In one embodiment, a method for implementing electronic communication regarding a change request over a computerized network includes generating a change request data (RFC) structure describing a change request for a computerized network; presenting a graphical user interface (GUI) on a first user device including graphical items related to the change request and a graphical discussion room creation option; and generating an electronic discussion room electronically connecting user devices associated with the user regarding the change request in response to receiving a user selection of the graphical discussion room creation option. In one embodiment, prior to generating an electronic discussion room electronically connecting user devices associated with the user regarding the change request, the method further includes presenting a visual list of entities associated with the change request in response to a user selection of the graphical discussion room creation option and receiving a user selection of a selected entity from the visual list. In one embodiment, generating an electronic discussion room electronically connecting user devices associated with the user regarding the change request includes receiving a second user selection of a graphical discussion room start option, obtaining communication information related to the selected entity from the visual list, and generating an electronic discussion room electronically and communicatively connecting the user devices of the user based on the communication information. In one embodiment, the method further includes sending an electronic invitation to the electronic discussion room to the user's user device based on the communication information. In one embodiment, the users of the change request include two of the following groups: a change requester, a change implementer, a change approver, and a change manager. In one embodiment, the method further includes generating an electronic record of the electronic discussion room and storing the electronic record in a database. In one embodiment, the method further includes generating an electronic text transcript of the electronic record and storing the electronic text transcript in a database.

[0152] In one embodiment, a computing device for implementing electronic communication regarding a change request over a computerized network includes a non-transitory computer-readable medium storing computer-executable instructions and at least one processor. When the at least one processor executes the computer-executable instructions, the at least one processor is configured to: generate a change request data (RFC) structure describing the change request for the computerized network; present a graphical user interface (GUI) on a first user device including graphical items related to the change request and a graphical discussion room creation option; and, in response to receiving a user selection of the graphical discussion room creation option, generate an electronic discussion room electronically connecting user devices associated with the user regarding the change request. In one embodiment, prior to generating the electronic discussion room electronically connecting user devices associated with the user regarding the change request, the at least one processor is further configured to present a visual list of entities associated with the change request and receive a user selection of a selected entity from the visual list in response to a user selection of the graphical discussion room creation option. In one embodiment, the at least one processor is configured to generate an electronic discussion room electronically connecting user devices associated with the user regarding the change request by receiving a second user selection of a graphical discussion room start option, obtaining communication information regarding the entity selected from the visual list, and generating an electronic discussion room electronically and communicatively connecting the user devices of the users based on the communication information. In one embodiment, the at least one processor is further configured to send an electronic invitation to the electronic discussion room to the user devices of the users based on the communication information. In one embodiment, the users regarding the change request include two of a group including a change requester, a change implementer, a change approver, and a change manager.In some embodiments, the at least one processor is further configured to generate an electronic record of the electronic discussion room and store the electronic record in a database. In some embodiments, the at least one processor is further configured to generate an electronic text transcript of the electronic record and store the electronic text transcript in a database.

[0153] In one embodiment, a non-transitory computer-readable medium storing computer-executable instructions is provided. When executed by at least one processor, the at least one processor is configured to: generate a change request data (RFC) structure describing a change request for a computerized network; present a graphical user interface (GUI) on a first user device including graphical items related to the change request and a graphical discussion room creation option; and, in response to receiving a user selection of the graphical discussion room creation option, generate an electronic discussion room electronically connecting user devices associated with the user related to the change request. In one embodiment, prior to generating the electronic discussion room electronically connecting user devices associated with the user related to the change request, the at least one processor is further configured to present a visual list of entities associated with the change request and receive a user selection of a selected entity from the visual list in response to user selection of the graphical discussion room creation option. In some embodiments, the at least one processor is configured to generate an electronic discussion room electronically connecting user devices associated with the user regarding the change request by receiving a second user selection of a graphical discussion room start option, obtaining communication information regarding the entity selected from the visual list, and generating an electronic discussion room electronically and communicatively connecting the user devices of the users based on the communication information. In some embodiments, the at least one processor is further configured to send an electronic invitation to the electronic discussion room to the user devices of the users based on the communication information. In some embodiments, the at least one processor is further configured to generate an electronic record of the electronic discussion room and store the electronic record in a database. In some embodiments, the at least one processor is further configured to generate an electronic text transcript of the electronic record and store the electronic text transcript in a database.

[0154] The foregoing outlines features of some embodiments so that those skilled in the art may better understand aspects of the present disclosure. Those skilled in the art should appreciate that they may readily use this disclosure as a basis for designing or modifying other processes and structures to carry out the same purposes and / or achieve the same advantages of the embodiments presented herein. Those skilled in the art should also appreciate that such equivalent constructions do not depart from the spirit and scope of the present disclosure, and that various changes, substitutions, and alterations may be made herein without departing from the spirit and scope of the present disclosure.

[0155] Aspects of the present disclosure are best understood from the following detailed description when read in conjunction with the accompanying drawings. It should be noted that, according to standard industry practice, various features have not been drawn to scale. In fact, the dimensions of various features may be arbitrarily increased or decreased for clarity of discussion.

Claims

1. 1. A method for conducting electronic communication regarding a change request over a computerized network, comprising: receiving input for generating a change request data (RFC) structure describing a change request for the computerized network; automatically collecting information from a plurality of users regarding the change request; presenting on a first user device a graphical user interface (GUI) representing selectable entities for the plurality of users related to the change request, the GUI including one or more graphical items for creating an electronic discussion room and a graphical discussion room creation option; In response to receiving a user selection of the graphical discussion room creation option, determining, based on the automatically collected information, a type of electronic discussion room to electronically connect user devices associated with one or more users of the plurality of users for executing the change request; creating said electronic discussion room; receiving, from a second user device different from the first user device, an acknowledgement of the RFC structure describing the change request, the RFC structure enabling selection of a target automated change request workflow from a plurality of automated change request workflows, the second user device being associated with one of the one or more users associated with the change request; method.

2. prior to generating the electronic discussion room electronically connecting the user devices associated with the users related to the change request; presenting a visual list of entities associated with the change request in response to the user selecting the graphical discussion room creation option; receiving a user selection of a selected entity from the visual list; The method of claim 1 further comprising:

3. generating the electronic discussion room electronically connecting the user devices associated with the users regarding the change request; receiving a second user selection of a graphical discussion room start option; obtaining communication information regarding the selected entity from the visual list; generating the electronic discussion room based on the communication information, electronically and communicatively connecting the user devices of the users; The method of claim 2 , comprising:

4. sending an electronic invitation to the electronic discussion room to the user device of the user based on the communication information; The method of claim 3 further comprising:

5. The method of claim 1 , wherein the users associated with the change request include two of a change requester, a change implementer, a change approver, and a change manager.

6. generating an electronic record of said electronic discussion room; storing said electronic record in a database; The method of claim 1 further comprising:

7. generating an electronic text transcript of the electronic record; storing said electronic text transcript in said database; The method of claim 6 further comprising:

8. 1. A computing device for effecting electronic communication regarding change requests over a computerized network, comprising: receiving input for generating a change request data (RFC) structure describing a change request for the computerized network; automatically collecting information from a plurality of users regarding the change request; presenting on a first user device a graphical user interface (GUI) representing selectable entities for the plurality of users for implementing the change request, the GUI including one or more graphical items for creating an electronic discussion room and a graphical discussion room creation option; In response to receiving a user selection of the graphical discussion room creation option, determine a type of electronic discussion room to electronically connect user devices associated with one or more users of the plurality of users for executing the change request based on the automatically collected information; creating the electronic discussion room; receiving, from a second user device distinct from the first user device and associated with one of the one or more users associated with the change request, an acknowledgement of the RFC structure describing the change request and enabling selection of a target automated change request workflow from a plurality of automated change request workflows; It is set as follows: Computer device.

9. before generating the electronic discussion room electronically connecting the user devices associated with the users related to the change request; presenting a visual list of entities associated with the change request in response to the user selecting the graphical discussion room creation option; The computer device of claim 8 , further configured to receive a user selection of a selected entity from the visual list.

10. receiving a second user selection of a graphical discussion room start option; obtaining communication information regarding the selected entity from the visual list; generating the electronic discussion room based on the communication information, the electronic discussion room electronically and communicatively connecting the user devices of the users; The computing device of claim 9 , configured to create the electronic discussion room electronically connecting the user devices associated with the user for the change request.

11. The computing device of claim 10 , further configured to send an electronic invitation to the electronic discussion room to the user device of the user based on the communication information.

12. The computing device of claim 8 , wherein the users associated with the change request include two of a change requester, a change implementer, a change approver, and a change manager.

13. generating an electronic record of said electronic discussion room; The computer device of claim 8 , further configured to store the electronic record in a database.

14. generating an electronic text transcript of said electronic record; The computer device of claim 13 , further configured to store the electronic text transcript in the database.

15. On the computer, receiving input for generating a change request data (RFC) structure describing a change request for a computerized network; automatically collecting information from a plurality of users regarding the change request; presenting, on a first user device, a graphical user interface (GUI) representing selectable entities for a plurality of users related to the change request, the GUI including one or more graphical items for creating an electronic discussion room and a graphical discussion room creation option; responsive to receiving a user selection of the graphical discussion room creation option, determining, based on the automatically collected information, a type of electronic discussion room to electronically connect user devices associated with one or more users of the plurality of users for executing the change request; creating said electronic discussion room; receiving, from a second user device different from the first user device and associated with one of the one or more users associated with the change request, an acknowledgement of the RFC structure describing the change request and enabling selection of a target automated change request workflow from a plurality of automated change request workflows; Computer program.

16. Prior to generating the electronic discussion room, the computer further comprises: presenting a visual list of entities associated with the change request in response to the user selecting the graphical discussion room creation option; The computer program product of claim 15 , further comprising receiving a user selection of a selected entity from the visual list.

17. The computer, receiving a second user selection of a graphical discussion room start option; obtaining communication information regarding the selected entity from the visual list; generating the electronic discussion room based on the communication information, the electronic discussion room electronically and communicatively connecting the user devices of the users; The computer program product of claim 16 , further comprising: generating the electronic discussion room electronically connecting the user devices associated with the users related to the change request.

18. 18. The computer program product of claim 17, further causing the computer to send an electronic invitation to the electronic discussion room to the user device of the user based on the communication information.

19. The computer further comprises: generating an electronic record of said electronic discussion room; 16. The computer program of claim 15, which causes the electronic record to be stored in a database.

20. The computer further comprises: generating an electronic text transcript of said electronic record; 20. The computer program of claim 19, causing the electronic text transcript to be stored in the database.

Images