Enterprises have multiple ServiceNow instances for many good reasons, for example: data residency requirements, regional or business unit autonomy, history of acquisitions, etc...
Consolidating into one single ServiceNow instance also comes up for very good reasons, such as reducing maintenance and license costs, IT landscape rationalization, etc. Often, a change of CIO will be the trigger for this.
To learn about the typical journey leading to ServiceNow consolidation, check out my previous article.
inloook! Your company got acquired. What happens to your ServiceNow platform? part 1
Now, it has been decided - we are consolidating - and the project is launched. Like every undertaking, having the idea is the easy part. It gets more difficult when we look at the execution.
It is the same platform, let's lift and shift! .... I don't think so.
If you are lucky, both platform follow the same upgrade cycle. If not, one platform will have to undergo 2 upgrades in the same year (a typical project lasts more than 6 months). If you have no clue which one to upgrade twice, I suggest you chose the target instance, as you want that one to be the most current. It may also be beneficial to reap the benefits of new capabilities and avoid transferring technical debt.
In terms of technical migration strategy, you may be tempted to lift and shift update sets, or XML files. For objects like catalog item forms (excluding logic and flows) this can be a safe, and effective approach.
However, there are many objects for which it is not such a bright idea:
Reports: due to small differences in data/data structure these may become ineffective, or inaccurate. Furthermore, is there a need to transfer the report - was it really used?
Scripts: due to different coding practices, policies and continuation of technical debt, would these be better being reviewed and refactored?
Workflows: for So. Many. Reasons! transition to flow designer anyone? Lifting and shifting workflows, you’ll probably overlook references to missing objects, variables, or fields.
To summarize, the target platform owner must understand, take ownership, and be held accountable for whatever lands on the target platform.
One note about interfaces: It's likely there are duplicate tools in the legacy and target ServiceNow ecosystems (SCCM, SnowMirror, Dynatrace, Flexera are common ones). You’ll need to involve Enterprise architects to help decide on the plan for of them.
A policy of “Buy rather than build” could lead to dropping a legacy custom interface for one procured from the ServiceNow store.
We are ITIL compliant ! - Yeah, right...
Common sense suggests that ServiceNow consolidation is easier because we are talking about the same baseline setup and the same processes. Both platform teams claim to be OOB, and ITIL compliant (whatever that means). Still, you find significant differences between the two implementations, and face a real struggle to get alignment
For example, take a different Incident Priority matrix. 4 levels on instance, 5 on the other. Doesn't sound like a big deal.
BUT seeing the larger picture:
Priority levels affect Major incidents, SLAs, reports
Priority levels are formally stated in vendor contracts and business commitments...
You end-up with a widespread impact for a minor change.
Another example is around policies for CSAT and emails.
One company policy could be to collect customer CSATs for every single ticket, so we can continuously improve.
Another policy may be to avoid “spamming” users with too many emails. We assume they are satisfied if we don’t hear from them after resolution.
These 2 assumptions are both fair, but it's still a very different driver and outcome.
For such cases, it's key to have an authoritative exec. who is empowered to make these decisions on behalf of the business.
There is no point to a one-month study to find THE right answer. There is no plain good or bad decision. What’s bad is NO decision all, or an awkward arrangement to make everyone OK (but failing to fully satisfy anyone).
Emotions drive actions.
In movies, when Aliens come to Earth to force theirs ways on us, we usually fight back. We feel a bit the same when when instances get consolidated: it causes a fight-freeze-flight reaction.
If it results from an acquisition, the ServiceNow consolidation program may be the first time there is a low-level practical impact on day-to-day work.
Like it or not, the anxiety about the acquisition is conveyed and felt in the ServiceNow workshops, and as a Business analyst, you may face passive-aggressive behaviour in workshops.
Sometimes, it is openly defensive when we unearth and question some weird scripts that were written 5 or more years ago.
It takes an effort from both the teams undergoing the consolidation to be open and non-judgmental about what is found in both theirs’, and the other team’s instance. We all have our skeletons in the closet.
Investment in OCM is key to address those challenges. However, be warned - it can take up to 40% of the whole consolidation budget. This is especially true when shifting from one ServiceNow instance to another because you lose the novelty effect and open-mindedness that comes with a greenfield implementation or total platform migration. People may focus on differences with a defensive mindset, trying to rationalize why they didn’t do it before.
To facilitate collaboration, it is advised to mirror the program for both platforms. Teams are usually more comfortable collaborating with “one of their own" rather than aliens.
Even with OCM, people like to have control of their future, and may decide to leave the company if there is any uncertainty on their future role.
The thing is, you need those key stakeholders to ensure you succeed in the convergence as they have the institutional knowledge.
As program leader you may face this kind of push back: “You ask me to work hard on BAU and put in extra effort on the program consolidation, but I have no clue where this is going, and what I’m going to do in the target model”.
I advise here to promote and socialise new and exciting roles in the future organization VERY EARLY. Otherwise the doubt will grow, and people will leave.
If we quit our comfort zone, it'd better be for something SPECTACULAR !
Sweep the mess away: when converging instances, teams are - understandably - proud of their past work and want to migrate EVERYTHING to the target environment.
Well, no. we won't migrate everything. Much of the configuration and data were created years ago with a different perspective, and different business needs in mind. No doubt it made sense at some point, but it most likely does not today (some perhaps, but not all).
A good practice is to pull some stats on usage of data, catalog items and reports in the legacy instance to then prioritize with a MoSCoW approach.
Drop the custom for the OOB: many customers have created custom features that then became OOB (on-call scheduling, Walk-up experience,...). Consolidating is a great opportunity to let go of the technical debt and re-align to the OOB.
Add in some swagg: for teams to let go of the legacy and put themselves in a vulnerable position, it must be worth it. Excitement can be created by adding novelty and introducing new modules that will wow the business and teams. A Business alignment workshop with ServiceNow can help you identify the relevant "wow" capabilities.
Novelty: renaming the instance URL, start on an upgraded version, rebrand the portal
Capabilities: add the virtual agent, mobile or workspace experience, agent intelligence.
Resource. Intensive.
During a consolidation program, you need the most knowledgeable SMEs (platform owners, process owners, business analysts, architects,...). These are rare resources who can think out of the box, take decisions, who know the implementation and business both inside and out.
Generally, it turns out that those SMEs are also in high demand over in BAU (it used to be their full-time job). There is still a backlog, a cadence, commitment to the business Here and Now.
These SMEs are naturally more keen to work on BAU where they get immediate recognition (or punishment) from the business, rather than a project that may eventually conclude by destroying their job.
There must be a managerial decision to deeply reorganize the BAU to free up the SMEs, and, re-set the expectations to the business.
__________________________________
For me, running large consolidation programs feels like chasing 2 wild horses to harness them together. It's an endeavor! It takes effort and grit. When well executed it is also very satisfying and it allows great optimizations.
Key takeaways for this article:
Don't assume it will be a technical migration because it is the same platform. Some objects can be lifted and shifted. Often, you need to question the status quo, retro-engineer, or redesign. It’s still a transformation in par with the operating model.
The same process on 2 platforms can be configured differently for good reasons on both sides, with cascading consequences. You’ll need senior leadership to make a firm decision on one direction or the other in case of incompatibility.
Anxiety rising from an acquisition is conveyed in the ServiceNow consolidation program. As a BA, you cannot say in a workshop "Your concern about losing your role has nothing to do with today’s agenda. let's talk incident categories!".
The ambition must be spectacular, but still in the realms of possibility for stakeholders to contribute both voluntarily and positively.
The SMEs you need for the consolidation may leave during the program on account of uncertainty, especially when there is a lack of vision on the target operating model.
Stakeholders will prioritize BAU over consolidation if there has not been a re-staffing of BAU and updated commitments to the business.
GG if you made it here in the article. I’ll be keen to read your comments and experience if you have experienced such transformation.
By the way, the opposite of a ServiceNow consolidation also exists! Spin off! I'm working on such a program now. This will be a topic for another article.
For structured guidance from ServiceNow on consolidation, I highly recommend this playbook. It's a goldmine.
https://www.servicenow.com/success/playbook/production-instance-consolidation-guide.html
1 Comment
