Can you ever be ready for marriage? Most likely not. But marrying without planning is likely to result in a painful journey, with consequences as severe as personal bankruptcy. Just like planning for your marriage, the enterprise digital transformation readiness step is not optional. It’s mandatory to avoid implementation disasters — and post-implementation disruptions. The more preparation you put in, the less painful the journey gets, with the lower total cost of ownership. Regardless of whether you pay during the prep phase or during implementation, you will end up paying about the same. So the only difference with the prep phase is that you can save yourself a ton of headaches.
Also, some people could perceive the digital transformation readiness step as abstract (and requiring sunk costs). They might be tempted to find shortcuts, such as keeping additional funds for unexpected risks or doing unnecessary chores. While these strategies might help to some degree, digital transformation readiness is about comprehensive planning, in putting the entire plan on a piece of paper (blueprinting). As well as identifying the issues with the initial plan (process re-engineering), assessing the financial feasibility (business case), and finally testing if the current resources can withstand the pressure exerted by new demand (enterprise architecture plan).
The phases would differ depending on the current state of your data (and processes) and how you want to segment your prep and implementation phases. But even with a prep phase, a structured process is necessary, which might lead to the following most common deliverables. These deliverables will help you stay on track without feeling lost in your journey.
1. Business and Strategic Plan
Creating a business and strategic plan is fundamental to your digital transformation readiness. It’s essential because it not only drives the annual operating plan but also helps plan the volumetric capacity expectations from digital systems.
Why it matters:
- No destination? Keep wandering. Even if you are completely off, that’s OK.
- Can’t define the destination? No Odds of getting there. Just defining it will help improve the chances of being closer to your destination.
- Writing it down will help define the destination. When you write something down, you will be slightly more informed. Otherwise, most executives like to dream of growing by 60% or 300% but would be clueless when asked about the execution plan.
- Business model and SWOT analysis. For example, the basic documentation of customers, channels, offerings, and SWOT analysis.
- Customer and supply chain journey mapping. E.g., High-level customer and supply chain journey that will be used as input for the process re-engineering step.
- Offerings and bundle strategies. Such as offerings, bundles, and how they map to each customer and customer channel. % split of revenue per offering and bundle. Strategic vs. non-strategic offerings. And pricing and discounting strategies.
- Strategic goals, execution plan, and expected results. Strategic goals and execution plans for each goal, as well as the desired KPIs that you plan to hit with each goal. Justification of why you believe technical changes are necessary to hit these goals.
- Financial Model. Detailed pro-forma financial statements of at least five years with forecasted ratios and KPIs aligned with the financial goals.
Make sure you don’t ignore this step, as it will help firm up an understanding of the direction and help you communicate the vision better.
2. Annual Operating Plan
Annual Operating Plan is a detailed forecasting and planning step that also outlines physical infrastructure growth. It uses a strategic plan as input and outlines a detailed plan for each individual function.
Why it matters:
- Wishlists are great, but can you afford them? In other words, each system and architecture assume a specific operational and transactional capacity. Define the capacity that is consistent with your growth plans.
- Helps firm up the strategic plan. Eliminates vague assumptions that might not be financially feasible and help you focus on the right objectives.
- Helps measure the outcome of transformation initiatives. Said another way, helps define the right KPIs that will be a true definition of success.
- Market, facility, site, product line, and warehouse expansion plan. Expands on the objectives defined in the strategic plan and build a financial model for each chart of account and dimensions.
- Human resources plan. Identifies the growth of human resources in each department, helping forecast the transactions and licensing requirements.
- Digital transformation strategic plan. Identifies the budget and high-level financial feasibility of different technology needs outlined in the strategic plan.
- Expected transactional volume. Details such as # of sales orders, purchase orders, sites, facilities, # of products, and production lines – all of which dictate the transaction volume and expected capacity from the architecture.
- KPIs and OKRs for measurement. Specific detailed KPIs per department, per role, in the as-is and to-be state.
- Key planned activities and stakeholders mapping. Mapping of stakeholders with defined activities, who does what, and which department is responsible for what.
Without an annual operating plan, it’s hard to estimate the internal capacity, transaction volume, and KPIs that will define the success of your digital transformation readiness.
3. KPI-Role-Compensation Plan As-is and To-be
This step analyzes the impact of the current compensation structure on KPIs and how that might influence the behavior of each role. As well as drive the resistance to change.
Why it matters:
- Let’s face it. Needles won’t move until compensation moves. Technology only goes so far. You need a lot more than technology to ensure people embrace the technology.
- Not willing to change the comp? Don’t even bother making a change. Regardless of how cutting-edge the technology might be, people won’t adopt it. So, change the compensation aligned with the expected change.
- Digital transformation initiatives are like financial markets. Not much difference between “bank runs” and “system runs.” The resources will run as fast as they can if they don’t see a personal benefit.
- As-is compensation. List down different variables of the current compensation of each role and department.
- Compensation-department-behavior mapping. Additionally, the analysis of current behavior with the compensation variables and how each department might be influencing these behaviors.
- As-is behavior and change impact analysis. As well as analysis of as-is behavior on the proposed changes and forecasting of any resistance expected motivated by compensation impact.
- To-be behavior and change impact analysis. Not to mention analysis of the desired behavior on the changes proposed and how the compensation variables need to be changed to influence the right behavior.
This step will decide the fate of your digital transformation readiness. So don’t forget to map the benefits with people’s paychecks for the enterprise’s digital transformation to be successful.
4. Role-Department-System Org Chart As-is and To-be
This step maps the role and department with the systems in both the as-is and to-be states. This is a crucial step both for change management as well as system architecture, as the to-be state needs to be designed depending upon teams’ comfort level in whether they are willing to give up on the processes or not.
Why it matters:
- Role system mapping is like an org chart for systems. No org chart → pure chaos. Disagreement among users might result in data siloes, process hijacking, data quality issues, and reconciliation nightmares.
- Forms the foundation of change management. Helps them understand their as-is and to-be workflows and helps them articulate the unforeseen issues or implications only known to them.
- Helps each resource visualize why the change is necessary. Enforces the buy-in as they are able to visualize cross-functional challenges of why a certain system or a process changes.
- Role and department mapping in the as-is and to-be plan. How each role would map in the new architecture. Would there be changes in the reporting structure or organizational hierarchy, as well as process ownership?
- Communication plan on why the org change is necessary. Identify the workflows for each change and provide a tailored plan for each stakeholder.
- How each role would map, including the owner of each system and dataset. How each role would map to each system in the as-is and to-be process model and what they need to do to be ready with the new system.
- Process boundaries of each role and data interaction workflows. The expectations from them during process handshake and their responsibilities for data ownership.
This is perhaps the first step in building a consensus on the draft-to-be process state and architecture.
5. Business Case and Transformation Roadmap
This step is where the rubber meets the road. This step reviews each of these proposed initiatives and build a brief business case, phased priorities, and appropriate sequencing based on technical and financial feasibility.
Why it matters:
- Helps eliminate “binary” vision and unqualified resources. Help executives filter out noise from the signal.
- Helps prioritize initiatives. Including the dollars in the conversations helps focus on the most essential without wasting time.
- Helps build a phased roadmap. The phased roadmap is essential to avoid the big bang approach and the risk of demotivating sponsors.
- ROI analysis of each initiative. Cost velocity and cash flow analysis of each initiative to help compare different options.
- Potential solutions and costs of each initiative. Focus on the entire solution rather than taking a siloed approach, including the costs of each integration, maintenance, support, etc.
- Buy vs. build vs. outsource analysis. Compute and compare costs based on the opportunity costs of internal resources, additional hiring, etc.
- Internal staffing needs vs. outsourced capabilities map. Include the map of what is expected to be done internally vs. outsourced. Identify the internal staffing needs. The poor internal hiring results into schedule slippage and overbudget issues.
- KPIs and definition of success of each initiative. Identifying KPIs for success will help stay on track and communicate the value of the initiatives.
Once agreed on a specific path and the total spend, the following steps will build on the solution path identified but come back to the roadmap and consider alternatives if the original solution might be financially or technically risky.
6. Change Management Plan
The changes may have wider implications and need to be planned and communicated. For example, say the to-be state requires a new SKU numbering or new configuration for license plates, which might require vendor and customer communication, along with making sure that the packaging team has the bandwidth to accommodate the changes timely.
Why it matters:
- Helps develop organization-wide language that everyone can understand and speak. Builds consensus on changing processes and customer/vendor communication elements.
- Provides cross-functional visibility and implications. Also helps identify and track cross-functional dependencies and builds the communication plan.
- Documented agreement on the current challenges. Documented processes help trace the root cause of the current challenges.
- Helps differentiate tangibly executable initiatives. Helps assess the cost and impact of the change on the branding and market share.
- Alignment on the to-be changes and why users’ contributions and commitment will make or break the initiative. Helps users see the big picture about why their contributions and commitment are important for the success of the program.
- Documentation of as-is workflows and process maps. Complete documentation of each role and their workflows for them to be able to relate, connect, and get trained.
- Identified changes aligned with strategic priorities and business case. Perform business case analysis as the cost of change is a factor for the overarching cost of the initiatives.
- Implications of changes on the business processes, roles, workflows, and the steps required to be successful. As well as the mapping of each change in the business processes, roles, workflows, etc.
- Documentation of key decisions, risks, and mitigation plans. Along with any proofs-of-concept that need to be performed to mitigate these risks.
Depending on the degree of the change and implication, appropriate plans and solutions need to be identified that are not only financially not feasible but technically not too risky.
7. Organizational Ledger Reconciliation Plan
Organizational ledger reconciliation requires tracking each of the datasets and how they will be reconciled. For example, decisions such as how many systems should be used in the architecture by building the reconciliation plan and estimating the cost of reconciliation. For example, if the team is fighting for an additional system, but the cost of reconciliation might be more than the 2 FT employees, then the additional system may not be worth it.
Why it matters:
- Helps define ownership of each dataset and agreement on the reconciliation.
- Help avoid reconciliation nightmares and whether reconciliation will be more expensive than simplifying processes or technology.
- Helps understand the transactional integrity and whether a specific process must reside inside ERP, best-of-breed, eCommerce, or Analytics warehouse.
- Set the tone for the enterprise architecture. Without a reconciliation plan, there might be issues with enterprise architecture with master data governance and process conflicts.
- Documented interactions of organizational ledgers AR, AP, GL, Inventory, cash, sales operations, marketing analytics, shop floor data, HCM, and supply chain forecasting.
- Documented impact on the financial or statistical ledgers. Classification of financial vs. statistical ledgers and their impact.
- Documented data ownership and reconciliations models, real-time or non-real-time posting. Real-time posting vs. batch? Summary vs. detailed?
- Defined ownership of KPIs and data marts and their interaction workflows. Reporting and data requirements from each ledger. Analysis vs. financial integrity of operations.
The ledger reconciliation plan help build how many datasets need to be reconciled, how many times, and how many variances will be expected, which will drive the expected capacity of the finance department.
8. Master Data Governance and Reconciliation Plan
Just like an organizational ledger reconciliation plan covers the functional aspect of the account and inventory reconciliation workflows, master data governance is the technical aspect (at the definition or at the metadata level) of reconciliation.
Why it matters:
- Helps understand the origins of each master data such as customer, vendor, products, services, chart of accounts, bank accounts, machines, equipment, human resources, credit cards, payment terms, etc.
- Helps understand the master data augmentation journeys and ownerships of each delta.
- Helps define processes for future master data integrity. Poor master data governance might lead the performance issues and the re-implementation of the system.
- Provides clear guidelines for the master data reconciliation plan in case of a conflict.
- Master data to system mapping at the field level. Map each master data at the field level to the system and who owns it.
- Master data augmentation journey per system at the field level. Define the augmentation journey at the field level, where the dataset gets originated, modified, and consumed.
- Master data relationships change across journeys. Flatting the layered data? Define the reconciliation path for each changed hierarchy.
- Master data mapping to key use cases. Define the master data structure for complex use cases such as buying groups, warehouse and location architecture, and transit locations.
- Admin and approval flow, given the implications of each master data. Define the approval flows and the stakeholders involved in approving datasets, including the governance process or automation needs.
- Producer-to-MDM and MDM-Consumer Workflow mapping. Using MDM for master data management? Define workflow for each MDM interaction across systems and departments.
A master data reconciliation plan helps refine the enterprise architecture and avoids data quality issues such as duplicate data, data siloes, and financial control.
9. Process Re-engineering Plan
The process re-engineering plan documents all the process re-engineering candidates in detail with their as-is and to-be workflows, including the migration plan for the new processes.
Why it matters:
- Identified process re-engineering candidates to stay within budget. Each broken process might lead to millions of dollars in overengineering of systems and architecture.
- Impact of process engineering on the current process. How much impact would the current processes have because of the re-engineering? Is that financially and commercially feasible?
- Impact of process re-engineering on the customer-facing workflows. Would customers be willing to adapt to the changes? Do the changes impact customers’ workflows?
- Impact on the product, branding, warehouses, facilities, and shop floors. Any physical changes needed in the warehouse layouts, packaging, etc., needed for process engineering to be successful.
- Cutover and training plan for current users. Training plan in coaching the current core team on the process of reengineering to be able to forecast the implications.
- Training plan and guides for the customer service and sales reps. Training plan and guides for the end users for the to-be state.
- Mock scripts to rehearse the process re-engineering scenarios. Design mock scripts for the current users to rehearse the new processes.
- Framework to enforce readiness and learning. Plan for compliance and digital transformation readiness, including automated governance processes and sustainability in the to-be state.
- Communication and training plan for the customers, resellers, and partners. Including any PR campaigns and asset development such as websites or internal portals.
Having a good process and re-engineering plan helps you avoid overengineering the systems or the critical success factors that lead to poor system selection.
10. Enterprise Architecture Plan
The enterprise architecture plan is written from the perspective of the technical teams to help align the technical and business teams. It helps the technical teams to challenge the assumptions and demonstrate the technical and financial feasibility of the plan.
Why it matters:
- Helps align technical teams with business, process, information, and technology. As well as helps align strategy, execution, quality, and KPIs.
- Reassesses the business case from the perspective of technology.
- Identifies red flags. As well as their mitigation plans.
- Sets the boundary of each system in the architecture, and their interaction flows
- Defines integration flows. Not to mention the cost of each integration.
- Defines users to system interaction flows. As well as setting their boundaries
- Detailed documentation of data. As well as process flows across system boundaries
- Pseudo code for major business rules and translations at the component level
- Mapping of each interface at the field level, inputs, and outputs. As well as the processing needed from each component.
- Documented requirement matrix, broken down at the story level and verified by technical teams, not to have more than 4-8 hrs of work.
- Documented quality plan, with acceptance criteria of each system, integration, and process.
- Documented release plan for how the systems will be released in production (including mitigation plans). As well as how stories map to sprints and how sprints map to releases. Finally, how each story maps to the goals in the business case.
- Documented production planning, including cut-over planning, financial translation of fixed assets, historical data migration plan, and production sanity check plan.
- Detailed migration plan, including identification of test environments of each system, how each system environment maps to another system environment, and how the finalized data and processes will be migrated to the upstream systems.
Having a good enterprise architecture plan allows you to foresee the technical issues that would otherwise not be visible with the siloed approach.
So, just like marriage requires comprehensive planning, the digital transformation readiness step is necessary. But the prep step is not about drawing a bunch of flow charts (like doing a bunch of chores with marriage) and writing a string of buzzwords to impress your executives; it’s almost similar to implementing an ERP on a piece of paper (being ready for marriage in your heart), which is more challenging than actually implementing it.
Just like you would not hire interns for your ERP implementation, asking interns to run the prep phase is worse than not doing it at all. So if you don’t want any headaches in your life, make sure these deliverables are as complete before you kick off your ERP implementation.