We often call digital transformation and migrating to the cloud "a journey." And, as with any journey, once you know what’s involved and you’re ready to go, you need a map. With cloud migration, it’s an implementation roadmap that spells out precisely where you’re going and how you’ll get there.
Creating your roadmap requires several considerations:
- What is the end state you're trying to achieve?
- What is the scope of your journey? (This could be an area of the business you want to transform; the footprint of an IT application; some engineering aspect of your operations; or something else entirely.)
- What business outcomes do you want to achieve and how soon?
- Which technologies are you focusing on?
All of these elements will affect IT resources, budget, methodology, change management, timeline and so forth.
The implementation roadmap brings the digital transformation discussion from the boardroom — strategy and vision — to the “boiler room” where things get real. And over the past five or six years, I’ve noticed several areas where the mapping process can go awry.
Be Wary of Tall Promises
Digital transformation begins as a boardroom discussion. And in that context, promises are often made to save millions of dollars or increase revenue manyfold. These promises may come from software vendors, systems integrator (SI) partners, executives within the organization, or all three.
But “tall promises” create lofty and unrealistic expectations. The roadmap needs to align very closely with the original assessment of what can realistically be accomplished and measured. What can be done in three months, six months, a year, two years?
Also, the roadmap must have some built-in flexibility. For example, when moving from an on-premise application to a new cloud application or a cloud version of the on-premise app, product maturity can be an issue. Lack of a feature in a cloud app can create a process gap. You will be forced to come up with a workaround until that feature comes online, which the vendor may be promising in X number of months.
Part of an effective roadmap is a periodic review of its technologies and methodologies. It must allow room for change because technology changes much more quickly now than it used to. Sticking blindly to an inflexible roadmap can be damaging in terms of cost, time and business outcomes.
When tall promises are made, ask a lot of questions.
Choose the Right Approach and Relevant Metrics
When it comes to implementation, it’s important to make sure that everyone’s plans and expectations are fully aligned with what will be implemented. All problems and issues cannot be solved in one day. Metrics should reflect the approach taken and align with the organization’s strategy. Are the transformational objectives focused on revenue, cost or compliance?
An SI can help a client define appropriate metrics, but it is ultimately the client’s responsibility to identify the key performance indicators (KPIs) that matter to its business and are in sync with its strategy. Once a transformation project is complete, you want objective measures for gauging success.
Learn how organizations Win With Boomi and its ecosystem of partners.
One Size Does Not Fit All
A $70 billion company will have a different roadmap than a $300 million company. Some companies may have or want best-in-class solutions for enterprise resource planning systems (ERP), customer relationship management systems (CRM), human resources (HR), EPM (enterprise performance management) and middleware, all deployed by different vendors. Others want everything in one platform.
In a multi-vendor environment, you must consider how you’re going to implement and sustain your application and data ecosystem. Do you have a skills gap that will make that difficult? You want a highly contextualized solution that will meet your requirements, not one that met the requirements of another company.
Not surprisingly, budget is always a factor in building a roadmap. We have customers for whom cost is not a consideration. They have a goal — say complete process automation — and they’re willing to spend whatever it costs to achieve that, which will include a lot of performance testing and all on-site teams. With other customers, cost will be the number-one consideration. In that case, an implementation roadmap will be built around a model that includes on-site and offshore work.
Understand When to Apply a Big Bang or a Phased Approach
If you are doing a transformation in one specific area, a “big bang” implementation is often the most effective. Everything is done at once. When the transformation is companywide, a phased approach may work better. The company’s culture, technology needs, maturity and scale also play a role here.
Another factor often overlooked is business continuity. While migration to the cloud is happening, routine business must continue. This can strain resources, which may favor a phased approach. Of course, all roadmaps carry risks depending on timeline, scope, complexity and product maturity.
Processes and Technology Go Hand in Hand
When a company moves workloads to the cloud, the business processes attached to those workloads go with them. Cloud or no cloud, the processes are the same. And if the processes are flawed or broken, you don’t want to move them to the cloud. It won’t fix them. But there is a fallacy that once you move processes to the cloud, you don’t have to worry about them.
So, as you build the integration roadmap, you must look very closely at your business processes. Which ones are necessary? How can processes be simplified so they can be automated via technologies like middleware, robotic process automation (RPA) and machine learning?
Ultimately, automated or not, processes must be executed, and they involve people. Processes need to be well designed. Complexity cannot be wished away. That’s why design workshops are so important. Even though processes will eventually be automated, people still need to define them. That’s why processes and technology must go hand in hand.
Change Management Is Critical
Once implementation is underway, the importance of change management becomes obvious and tangible.
Changes need to be in sync with the implementation and managed. They can’t just be announced with no follow-up communication or contingency plans. When it comes to change management, everyone is a stakeholder. People need to be involved. Changes must be tested and approved before they’re rolled out.
As I said in my previous blog on operational readiness, a phased, well-planned and executed cloud migration can take three to four years from start to finish. And for a journey of that duration, you definitely need a map. Don't leave home (on-premise) without one!
About the AuthorFollow on Linkedin Visit Website More Content by Raja Sekhar