Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Service Manager9.52

Develop > Processes and Best Practices Guide > Change Management Workflows > Normal Change (process ST 2.3)

Normal Change (process ST 2.3)

Normal Change is a change that is categorized, prioritized, planned and that follows all approvals before deployment. The Normal Change activities describe the steps necessary to process a Normal Change by coordinating work effort. A Normal Change can be further categorized as Major, Significant, and Minor. All Major, Significant, and Minor changes go through the same workflow except that, for a Normal Major RFC or a Normal Significant RFC the Build Authorization phase is a manual transition and the change has to be approved manually by Change Advisory Board (CAB) members. In a Normal Minor RFC the Build Authorization phase is auto approved. The Build Authorization phase is optional in a Minor RFC but it is still configured in the out-of-box system. The Change must be appropriately reviewed, approved, and executed successfully through the Normal Change process at least once prior to acceptance.

The following figure depicts the Normal Change workflow in Process Designer.

For details of the Normal Change process, see the following figure and table.

Normal Change process
Process ID	Procedure or Decision	Description	Role
ST 2.1	Register RFC	RFCs are logged by the Change Requestors. All RFCs are reviewed for completeness and accuracy.	Change Coordinator
ST 2.3.1	Assess Change	Assessing a change includes determining the risk and impact and identifying if the change requires a release to be generated. If a release is required, a Release and Deployment Manager is identified.	Change Owner
ST 2.3.2	Is a Release Required?	The Change Owner determines whether a release is required to implement the change.	Change Owner
ST 2.3.3	Determine Approval Requirements	The Change Manager reviews the change and decides whether a TCAB needs to be convened.	Change Manager
ST 2.3.4	Build Authorization Needed?	If Build Authorization is not needed, the Change Manager determines whether the change should be approved or rejected. If Build Authorization is needed, members are identified and change is submitted for approval.	Change Manager
ST 2.3.5	Build Authorization	Change Manager works with CAB and approves the Change.	CAB
ST 2.3.6	Review RFC	The Change Owner reviews the RFC for approvals.	Change Owner
ST 2.3.7	Approval Received?	Upon approvals, build and test is performed either by Release and Deployment process or Change Management process. If unapproved, the RFC is closed.	Change Owner
ST 2.3.8	Coordinate Build and Test	The Change Owner initiates the Release and Deployment Management process to perform build and test. The Service Validation Testing process is involved in validating and testing the build created by release. In case the build and test is unsuccessful, it is recommended to abandon the change to RDM which in turn is informed to the Change Owner. The Change Owner coordinates between the experts within Change process for building and testing activities. The change is built and tested thoroughly and validated.	Change Owner
ST 2.3.9	Build and Test Result Acceptable?	If the Build and Test result is acceptable, deployment is scheduled; else the RFC is sent for closure.	Change Owner
ST 2.3.10	Schedule for Normal Change	Change Owner involves the RDM and prepares the schedule for normal change. This schedule is based on the draft deployment plan obtained from the Release and Deployment Management process received.	Change Owner
ST 2.3.11	Release Related?	If release is related, the detailed deployment plan is created by the RDM process; else, Change Owner creates the same.	Change Owner
ST 2.3.12	Create and Submit Deployment Plan	The Change Owner creates the Deployment plan and submits it to CAB approval. The same is also received from RDM and is sent for CAB’s review.	Change Owner
ST 2.3.13	Deployment Authorization	CAB reviews the Build and Test results and approves / abandons / rejects as deemed fit. If the Build and Test results are approved, CAB reviews and updates the implementation schedule and authorizes the Normal Change implementation to commence.	CAB
ST 2.3.14	Rejected?	If the deployment plan is rejected, the change moves back to Build and Test.	CAB
ST 2.3.15	Decision on Rebuild	If CAB decides on rebuilding, the change is rebuilt and tested again.	CAB
ST 2.3.16	Rebuild?	If a rebuild is required, the Change Owner is informed; else, the change is deployed.	CAB
ST 2.3.17	Review RFC after Rebuild Decision	The Change Owner reviews the RFC to check whether the rebuild will be performed by RDM or within change. Also a decision is made on what modules to be rebuilt and the timeline.	Change Owner
ST 2.3.18	Release Related?	If the rebuild is related to RDM, the request is sent to RDM for rebuilding and testing; if not, these are performed within the Change Management process.	Change Owner
ST 2.3.19	Review RFC after Deployment Authorization	The Change Owner reviews the RFC to go ahead with the deployment.	Change Owner
ST 2.3.20	Release Related?	If RDM is involved for deployment, RDM carries out the deployment activities; else it is carried out by the Change Management.	Change Owner
ST 2.3.21	Coordinate and Monitor Change Implementation	The Change Owner coordinates and monitors the Normal Change implementation. Various tasks are created for carrying out the deployment activities as mentioned in the deployment plan. After the deployment, the Change owner verifies whether the deployment was successful or not.	Change Owner
ST 2.3.22	Remediation Required?	If the change is unsuccessful it is backed out and moved to closure; else CMDB is updated for successful changes.	Change Owner
ST 2.3.23	Provide CMDB Updates	Change Owner generates CMDB updates that are to be submitted to Service Asset and Configuration Management for processing.	Change Owner
ST 2.3.24	Determine if implemented RFC Is a Release	If the implemented change involves a release, control is returned to Release and Deployment Management for further review and closure.	Change Owner
ST 2.3.25	Implemented RFC for a Release?	If the RFC was for a release, the post-deployment activities will take place in the Release and Deployment Management process; else move on to PIR.	Change Owner
ST 2.3.26	Assess Change Success	The Change Manager determines whether the change implementation is successful.	Change Manager
ST 2.3.27	Remediation Required?	If a release needs to be backed out, this is done in the Release and Deployment Management process.	Change Manager

Send Help Center feedback