Searching the Help
To search for information in the Help, type a word or phrase in the Search box. When you enter a group of words, OR is inferred. You can use Boolean operators to refine your search.
Results returned are case insensitive. However, results ranking takes case into account and assigns higher scores to case matches. Therefore, a search for "cats" followed by a search for "Cats" would return the same number of Help topics, but the order in which the topics are listed would be different.
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 |
|
|
Either word in a topic |
|
|
Topics that do not contain a specific word or phrase |
|
|
Topics that contain one string and do not contain another | ^ (caret) |
cat ^ mouse
|
A combination of search types | ( ) parentheses |
|
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.
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 |