Implementing changes within your ServiceNow environment can be a complex undertaking. From minor updates to major platform upgrades, each change has the potential to impact your workflows, user experience, and overall system stability. Oblytech’s Change Management Advisory services provide expert guidance and support to help you navigate these transformations with confidence and help reduce the risks they carry.
We meticulously analyze the potential impact of proposed changes on your workflows, user experience, and overall system stability. This allows us to identify risks, develop mitigation strategies, and aim for a smooth transition.
We create a comprehensive change management plan that outlines communication strategies, training programs, and user adoption initiatives. We’ll work closely with your team to tailor the plan to your specific needs and organizational culture.
We engage with key stakeholders throughout the change process, ensuring they understand the benefits of the changes, addressing their concerns, and fostering buy-in.
We develop clear and effective communication materials and training programs to educate your team about the upcoming changes and help them use new features and functionalities.
We provide ongoing support and guidance to help your team adopt new ServiceNow capabilities.
We track the progress of the change implementation and evaluate its effectiveness. We’ll identify any areas for improvement and make adjustments as needed.
A change request workflow records that a change was proposed, reviewed and approved. It does not tell you whether the people who use the platform will notice the change, whether their work will slow down for a month, or whether the support queue will fill with questions the release notes never anticipated. Change management advisory is the route for those questions. It is worth buying when a change will reach users in a way that the approval step cannot see, and it is usually not worth buying for routine configuration tweaks that affect nobody outside the team that made them.
The decision usually comes down to three things: how many people the change touches, how much their daily routine depends on the part of the platform being changed, and how much time they will have to adjust before the change goes live. A change that alters an approval path used by every manager in the company needs advisory support. A change to a catalog item used once a quarter by a single team may only need the normal review.
Platform changes differ in the kind of risk they create. Technical risk, such as a failed deployment, is handled by testing and back-out plans. People risk, such as confusion, workarounds and lost work, is handled by advisory work. The table below separates the two, so that you can see which changes need which kind of help.
| Type of change | Main risk to people | Advisory focus that helps most |
|---|---|---|
| Platform upgrade that alters screens and navigation | Users cannot find things they used every day | Before-and-after walkthroughs by role, and a short list of what has moved |
| New module going live beside an existing tool | Two places for the same work, and no agreement on which to use | A decision on the system of record, and the date the old route closes |
| Changed approval path | Requests stall because approvers do not know they have been added or removed | Stakeholder sign-off on the new path, and a plan for requests already in flight |
| Reorganization that moves ownership of a service | Nobody knows who to contact, and old assignments remain in place | An ownership map, a cut-over date and a clear message from the sponsor |
| Policy-driven change, such as a new access or approval rule | People comply with the letter of the rule and create new problems elsewhere | Scenarios drawn from real requests, tested with the people who will apply them |
The table is a sorting aid, not a checklist. A single change often belongs to more than one row. An upgrade that also changes an approval path needs the advisory focus of both.
The output of advisory work is practical. It is not a generic change plan with the platform name substituted in. For a specific change, the work usually produces four things, and each one should be recognizable when you see it in a proposal.
Advisory work begins before the change is final. A useful time to bring in advisory support is when the design is still open enough for user feedback to matter. Once the build is complete and the go-live date is fixed, advisory support can still help, but the choices it can influence are narrower: the wording of messages, the timing of training and the order in which groups are switched over.
Advisory work also stops at a definable line. In general it advises the people who run the change board, approve changes and own the release calendar, rather than doing those things for them. If a provider describes its role as running governance for you, ask which part of that governance will stay with your team once the engagement finishes. Change authority should remain with the owners who are accountable for the platform, and advisory work should make their decisions better informed.
Most organizations judge a change by the absence of complaints, which is a weak test. A quiet support queue can mean that people have adapted, or it can mean that they have given up on the platform for that task and started using email. The more useful question is whether the work is still getting done in the intended way, and whether anyone has built a workaround that now carries risk.
A practical check is to look at the requests that moved through the changed process in the first few weeks after go-live. Look for returns, reassignments and manual interventions. Each one points to a gap in training, communication or the design itself. Advisory work that ends at go-live misses this stage, so ask any provider whether it includes a short review after the first full cycle of the changed process.
Usually not. A small change to a single form with a small user group can be handled by the owning team with a clear note and a few direct conversations. The advisory route becomes worth its cost when the change crosses teams, changes an approval, or alters a process that people run under time pressure.
The sponsor should be the person who owns the process that changes, not only the platform team. When the platform team sponsors a change to a business process, users tend to read the communication as a technical notice and ignore the parts that require them to act.
This depends on the change, and it is one of the most frequently overlooked decisions. Some requests can finish on the old path, some need to be moved, and some are safer to restart. The decision should be written down before go-live and communicated to the people who own those requests.
Yes, and an upgrade is a common point to do so. An upgrade has a technical plan that tests the platform, and an advisory plan that tests the people. The two are coordinated, but they are different pieces of work with different owners.
A useful starting point needs three things: the change itself, described in terms of what users will see differently; the groups who will feel the change most, named by role; and the date by which the change must be live. If the date is not yet fixed, say so, because it affects how much advisory time is needed before go-live.
Related pages on this site cover parts of the same ground. The change governance and release management page covers change decisions and release evidence, and the change request and service catalog page covers how people recognize the service or change they need. The platform operating model page covers who decides about architecture, access, data and standards. Read those alongside this page if your change touches governance as well as people.
If you have a specific change in view, the change description, the affected groups and the go-live date are what is needed to judge whether advisory work fits or whether the owning team can manage the change with a lighter plan. Questions about a particular change can be sent through the contact page.
An approval path change is a clear case for advisory support, because everyone who submits or signs off a request meets it on the first day. Take a change that moves sign-off for one request type from a line manager to a team lead. The configuration is small. The work around it is not, and it falls into three stages.
The first stage happens while the design is still open. The change owner has to decide what happens to requests already waiting for the old approver. Letting them finish on the old route keeps the queue moving, but two routes stay live for a while. Moving them across gives one route, but changes the approver partway through a piece of work. Both options are worth setting out in plain terms, with the people each one affects, so the owner can choose before the build fixes the answer. How the path sits inside the wider change enablement process decides which approvers are in scope, so settle that first.
The second stage is a dry run before the go-live date is fixed. Two or three real requests of each type are walked through the new path by someone from the affected group, not by the team that built it. Builders know where the path is meant to go. A requester who has never seen it shows where the path is unclear, and that is easier to fix in a dry run than after go-live.
The third stage is the first full cycle after go-live. If the old route is still in use after go-live, the cause is often a group that never received the note. The fix is one short message from the change owner, not a redesign. Where a group still struggles with the new step, a focused session from the user adoption and training work is a better fix than a longer guide.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.