• Reporting a change - A change can be created manually or automatically. If a similar change exists, then the service team should link the Incident/Problem with the existing change in the Kovair ITSM solution. Otherwise, the Kovair IT Service Management Solution application will automatically create a change against the Incident/Problem, and establish relational links among them.
• Classification of proposed changes (at review stage) is based on the feasibility of the changes and their risk parameters with a full description of every step in the change process
• Post-implementation verification- This helps an IT service provider to maintain a high degree of service quality to minimize the number of potential Incidents /Problems that may occur due to that change.
• Defining the approval process for change verification- This pre-defined process can be enhanced with codeless configuration of the workflow as per business needs and objectives of the service provider.

Advantages of the Kovair Change Management Solution

• Easy to use – Kovair Change Management can be used with a minimal training.
• A single repository of application lifecycle entities - All application lifecycle entities (Requirements, Use Cases, Test Cases, Change Items, Change Packages, Issues, etc.) are available in a single repository. That seamlessly integrates changes with other entities and results in a better cross-entity visibility.
• Links similar type of Change Items to Change Packages – Change Items are basically Change Requests, and Change Package is the collection of Change Items on the basis of similar functionalities, features and groups. This linking aids in the effective management of implementation of Change Items.
• Allows for a two- way requirements traceability relationship - Users can update / create a Change Package while entering the Change Items. They can also view the Change Package status from Change Items and can similarly monitor Change Items from the Change Package.
• Process- driven methodology – Kovair helps organizations in defining their own Change Management processes. Once the process is defined, the system guides the concerned resources for performing the appropriate activities.

Change Items and Change Package

Change Items
• The Change Management process starts with the submission of Change Items which are basically Change Requests.
• The Business Analyst conducts the primary investigation of the Change Item and updates the status as:
  • Proposed – When the Change Item is submitted, its status is set as "Proposed"
  • Return for Clarification – The Change Item is returned to the submitter for clarification who can re-submit the Change Item with "Additional Info Required".
  • Approved – The Change Item is approved and will be included in the Change Package.
  • Defer– The Change Item is put on hold.
  • No Recommendation – The Change Item is "Not Sponsored' and is closed.
  • Close – The Change Item is "Not Sponsored" and is closed.
• The process moves further based on the Primary Investigation Review Status.
• If the status is "Returned for Clarification," then a task is generated for the submitter as "Change Item Modification".
• If the status is "Sponsored (Include in Change Package)," then a Task is generated for the Systems Analyst to "Assign Change Package".
• In all the other cases, the status is treated as "Not Sponsored" and the processing of the Change Item is stopped.

Change Package
• Change Package Creation - The Systems Analyst reviews the Change Item and searches for the Change Package on the basis of the Change Item's requirements and properties. In case an appropriate Change Package exists, it selects the Change Package under "Linked Change Package". Otherwise, the solution allows the Systems Analyst to create a new Change Package. Now the Change Item is linked to or added to the appropriate Change Package.
• Change Items' Evaluation - The Senior Systems Analyst vets each Change Items in the Change Package and updates the Change Review Status.
• Change Package Investigation & Analysis - The Technical Architect undertakes investigation and analysis of the Change Package. Under this, the Impact and Risk Assessment is done before committing to the Change Package implementation.
• Design Review - The Technical Architect also undertakes Design Review and finds out the Requirements impacted by the Change Package implementation. This also gives an idea about the Estimated Efforts.
• Change Package Efforts Estimation - The Change Control Manager undertakes Efforts Estimation to implement the Change Package, mainly on the basis of Analysis & Design, Coding, Testing and Acceptance.
• Change Control Board Review - The Change Control Board consists of Choosy Customer, Mature Manager and Sharp Architect. When all the information regarding Impact, Risk, Scope and Efforts, required to implement the Change Package, is ready, it is put forward to the Change Control Board.
  
  The Change Control Board evaluates the Change Package implementation on the basis of Impact and Risk Assessment, Cost of Implementing Change Package, and Delivery Schedule, following which the decision to implement, defer or reject the implementation is made.
• Change Package Implementation - Once the Change Package is "Approved" by the Change Control Board, the Technical Architect starts working toward implementing it with the system generating the task "Implement Change Package" for him/her.
• 
  Change package process flow
  
  
• Completion of Change Package Process - The Change Package process comes to completion with the implementation of the Change Package.
• 
  
  
  
  Change package process
  [ Click on the image for a larger view ]
  
  
  

Please check out our online demo. If you would like to know more, contact us at sales@kovair.com.