Request
Change type, description, justification, rollback plan and a risk assessed by impact and likelihood.
Modules · Change management
Change without surprises: assess, approve, schedule.
Change management governs every change to your information system: who requests it, which items it affects, who approves it and when it takes place. Each change keeps its decision and its review.
Benefits
- Impacts known before actingThe items affected, and those that depend on them, are worked out from the relationships in the CMDB.
- Clear, traceable decisionsThe board decides from the record or in session; each decision is kept with its comment.
- Conflicts avoidedChanges that overlap on the same item are flagged as soon as they are submitted, and freeze periods are respected.
- Lessons retainedA post-implementation review is required before closure: outcome, deviations and lessons learned.
How it works
Assess
The affected items are identified; their dependants are calculated and can be set aside.
Approve
Immediate approval for a standard change, the board for a normal change, the emergency board for an emergency.
Implement
The change is scheduled in a window, carried out, then closed after its review.
Related modules
- CMDB You choose the target items; dependent items are calculated by following the relationships in the repository, with the path that links them. A clash with another change on the same item is flagged as soon as the change is submitted.
- Service Desk The emergency change is created from an open incident, already filled in, and the ticket shows the linked change: the agent knows which intervention is planned and when.
- Problem management The change that fixes a problem starts from its record, with the root cause already carried over; when the change closes successfully, the record offers to resolve the problem.
- Major incidents From the war room, the emergency change is created with the title, affected items and ticket already filled in, then goes to the emergency change board; it keeps track of the crisis it came from.
- Release management A release groups approved changes; each calendar shows the other, and a warning appears if the deployment window falls within a freeze.
- Project management A project, task or milestone can rely on a change: the milestone moves to “Reached” when the change is closed, with no manual update.
- Event management: monitoring alerts During a change window, alerts on the items concerned stay visible but open no incident: the intervention does not send false alarms to the Service Desk.
Functional scope
- Three change typesStandard, normal and emergency, each with its own approval rules; further types can be created, named in each language.
- Governed life cycleFrom request to closure; a rollback plan is mandatory before a normal or emergency change is approved.
- Approval workflowsApproval by a board or by a multi-level workflow, with conditions on risk, deadlines and delegation.
- Impact on the repositoryAffected items and dependants calculated automatically, with the path that links them.
- Calendar and freezesMonth, week and day views, global or targeted freeze periods, detection of scheduling conflicts.
- Board meetingsAgenda, decisions taken in series, minutes and a frozen closure.
- Management reportingSuccess rate, emergency changes, rollbacks, approval time, risk matrix and a Kanban board.
- RemindersThe requester and the owner are notified before the implementation window starts.
Integrations
- CMDB repository, for the impact assessment
- Process engine, for approval workflows
- E-mail and in-application notifications, with editable templates
- AI assistance to assess risk and draft text, when the AI module is configured
Prerequisites
- The approval board and emergency board groups, to be designated
- The CMDB repository, so that impact can be calculated (optional)
The essentials of this page in PDF, to keep or pass on.
Download the sheetWant to see this module on your own processes?
We will build the demonstration around your operational reality.