by Patrick Dineen on February 23, 2024
Three years ago, in advance of commencing a large-scale SAP S/4HANA transformation project, I talked to thirty CIOs to get their best practice advice.
The exercise was invaluable, and full of critical insight and tips often presented by SAP and other expert partners. But the incredible experience of leading a project from inception through go-live has taught me so much more about end-to-end process improvement, organizational change management, operating models, competitive advantage, and real enterprise transformation. The opportunity for a company to digitally transform finance, HR, and operations with the SAP S/4HANA suite is a fundamental value-shift that can easily be squandered if not managed well. And so, there is much to learn from others who have undertaken this journey… and arguably more from the tougher projects.
This post is a quick survey of the more interesting (and often controversial things) I learned along the way; lessons that I know can make SAP S/4HANA projects more successful. All are based on real-life, hard-knock moments, mistakes, surprises, and successes. May these be a great conversation starter for those about to commence their SAP S/4HANA transformation.
First and foremost, the project founders must define and broadly communicate a simple and compelling statement: How will this SAP transformation enable capabilities vital to the enterprise's future survival? This visioning effort is an important test if the executive suite is aligned. The tighter the vision is tied to strategic survival, the better. Will key leaders trade their current jobs for one in the future state? Will they put their bonuses on the line? This vision will be a north star that will be referred to often in times of trouble and change. Write it down and proudly put it on the wall, on t-shirts, and compensation plans.
Everyone must be aligned and incentivized, including controller, FP&A, revenue, billing, commercial, product, operations, HR, and the C-suite. The goal should be zero detractors from day one. Extra points if all agree on how to mutually manage the inevitable cutover challenges ahead. Alignment means no finger pointing. No one should assume this is going to be easy, or someone else’s problem. Any lingering doubts or reservations will continue to resurface unless leadership demonstrates that alignment is mandatory. Do surveys regularly and confirm all stakeholder commitment often, both in public and private settings.
Focus on avoiding benchmarks and top-down index estimates, which will not stand the test of time. All executives must be aligned on the numbers, and signed up personally to deliver. A PE exec once challenged me that a true ERP business case must have a list of employee numbers with exit dates, or it will likely never happen. That’s the detail rigor most organizations will need, as most will find that eventually, they will not have a choice.
It is so easy for these epic projects to be waylaid by questions and challenges along the way. It is important to build resilience into your vision, budget, and governance to steer you through tough waters. What if key leaders or executive sponsors go? Can/should it live through organizational and strategy changes? Ownership changes? PE vs. public? Your transformation will undoubtedly need to remain relevant and supported through multiple years of operating plan cycles. It needs to be important and big enough in vision to last five years or more. The strength of your future state vision and the rigor of your business case are the key drivers of the project’s resilience.
This office should be multi-disciplinary, focused on verifiably changed processes/data, customizations proposed/confirmed/rejected, unanimous approval gates, testing gates, training confirmed, capacity effectiveness, budget and business-case progress. Signal that attendance is mandatory. Document all decisions and votes, especially for customizations. Any software customizations must be publicly PMO-approved with a finance-approved business case, ideally unanimously. Make sure to have measurable KPIs.
Optimally, this committee should be made of those in the C-suite (and ideally, include the CEO, CFO, and COO), a top SAP leader (a key designate from the SAP product; I recommend the President of SAP North America, Lloyd Adams), and a top five systems integrator (SI) executive (ideally a chair/division lead superior to the project team). Compel monthly attendance for these steering committee leaders.
It’s important to have everyone work together in person when possible, especially during the design phase. It is too easy for folks to be cheerleaders for transformation that may be quarters and years away… and even more when working remotely and in less-engaged video calls. Insist on in-person, dedicated sessions where participants clearly and publicly articulate how processes and roles will change in the future state.
Include sales force automation tool processes, pricing proposals, contracting, and all the relevant boundary systems for provisioning/fulfillment/delivery. Where are there manual processes today? Can they be automated/eliminated in the future? Create a manual work heat map where “human middleware” connects disparate systems and build automation into your transformation business case.
Arguably, the most important battleground of a finance transformation is an exhaustive line-by-line revenue/contract operating model review, considering all customers, contracts, products, proposals, and pricing processes. What are the revenue models that will exist in your future state? Don’t lift and shift bad processes here. Do this before you start your project as this may be the hardest and most controversial part. Can you consolidate products and revenue models? Can you reduce variation in contracting, pricing, milestone, and revenue recognition scenarios? Are your largest client revenue models different than longtail smaller clients? Identify your long-term strategic vision for revenue, and design SAP S/4HANA accordingly.
Next, consider whether your revenue recognition accounting is ready to be automated in SAP S/4HANA. You may have overly flexible or manual practices that have been accommodated in your legacy systems that are best not enabled/customized in new technology. Are your teams and executives ready for this discipline? SAP S/4HANA is designed to automate revenue in a lights-out process. It will be controversial to remove ad hoc human intervention in these processes. Engage your auditor/internal audit teams to help identify these scenarios.
It is also important to consider how your new SAP S/4HANA Finance cost planning and reporting ties to your Human Relations Information System (HRIS) or headcount control processes. Are you planning to optimize your current methods? Are finance and HR aligned on how systems should be integrated and normalized? This is not to be taken for granted, in particular, if HRIS and ERP transformations are not happening at the same time.
Experts will recommend that you should “stay standard” and “keep the core clean” by avoiding the customizations of SAP functionality out of the box. Your teams may agree to this in principle, but then be conflicted when it becomes time to actually change current legacy processes. Incentivize and applaud public commitments to legacy processes change during early project stages. Encourage your teams and partners to not just give in to the status quo in what I’ve come to call the “quiet lift and shift.” Insist that your SI push you to best practice, and not customization. It will be much harder to undo later.
If stakeholders do not buy into new system processes, even if the software is perfectly implemented, your project will be challenged with defects and quality problems at cutover. Incentivize key user leaders and train teams early; make sure they are convinced and looking forward to the change. Create detailed bottoms-up procedures for how all finance jobs change. Consider ancillary functions like HR and commercial functions. What must change in commercial contracting? Client expectations? What jobs go away and when? What expertise must be imported? Specific job change management documentation cannot be detailed enough.
These post-cutover measures are things such as monthly close financial timeliness, billing accuracy and speed, well-trained associates, and defect/manual work elimination targets in the first six months after go-live. This will change the dynamic about readiness to go live and hypercare. Talk to your integrator about other cutovers they have managed, and what their expectations are for yours. Insist that they call your team out if they have concerns about readiness. Experienced SIs have seen it all before, so listen to their stories and insist they bring veterans to your project.
Budget accordingly to afford additional cost here. Even the biggest system integrator firms rarely have all the expertise needed, and multiple perspectives are often useful for complex problems. A best practice is to have your integrator and SAP Services create a mutual RACI for the project, with all designs approved by SAP. Things will go wrong, and you will not want to hear that the design is not standard SAP practice.
This is where your stakeholders will first feel the impact of your transformation, and in most cases the first impression will raise questions and concerns. It is vital that key financial report stakeholders understand how information flow may be disrupted and delayed for some time after cutover as defects are ironed out. It is also important that controllership and FP&A teams are fully ready for the new close process. Do all actors in the close process know exactly how their jobs must change on day one? Are they really well trained and comfortable from hands-on testing? Do they all believe and want a successful transformation? Steve Jobs once said this about love, “The one who loves you will never leave you for another because even if there are 100 reasons to give up, he or she will find one reason to hold on.” You need a preponderance of transformation lovers and a few reason-finders for the first few months and quarters.
The SAP Analytics Cloud concept of XPA (distributed planning and analysis) versus traditional FP&A is compelling. Are executives across your company, and especially your finance colleagues, ready for automated real-time dashboards instead of pivot tables and PowerPoints? How will your finance team operating model change with a well-implemented SAP S/4HANA, SAP Analytics Cloud, and group reporting system? Effective and accurate reporting is a key scorecard item for SAP S/4HANA project success. Like your initial financial close efforts, reporting effectiveness is a key first impression opportunity on your project’s success.
This executive should be on the steering committee or PMO, with compensation tied to system data quality and availability. Measure data quality success with regular KPIs/validations for transforming the value of your data. Do not accept bad data or the technology (and more importantly, the user experience and change management) does not have a chance. It will be tempting to “fix data later.” Start with where data problems are in your current state legacy system. What workarounds must your teams endure today to fix data? Do folks download extracts and create “the real financials” in pivot tables outside the system? Your vision should correct data in the system automatically and make it available “on the glass.” Your future state vision should highlight how much better you could run the company if you had accurate, real-time, highly available data.
Be transparent with key leaders to set their expectations. Reporting could be hampered, revenue reconciliation discrepancies could need significant incremental manual work. Monthly close could be awkward and manual for a while, typically months. Communicate clearly and well in advance, and remind everyone about future state benefits. Again, understand your integrator’s experience and best practices for cutover effectiveness, and how they will bring their best efforts to assure your success. Again, engage your auditor, board, and entire C-suite in cutover scenario planning.
Support, plan, and budget for continuous improvement post cutover, as enhancements and automation opportunities will always be available to make the solution better, faster, and less manual. Invariably, a minimum viable product (MVP) process will limit the full capabilities of the system at launch and require rapid releases in the first few months. Ideally, your team will have developed a depth of new SAP S/4HANA suite architecture skills and the capacity to run and build on your new environment (and enable you to migrate to business as usual and away from your SI sooner). Note that in a competitive environment for SAP expertise, this may take quarters, if not years. Planning well ahead of cutover is important here.
These are but a few of the more interesting lessons that I learned on my SAP S/4HANA journey—and many of these were learned by not getting it right at first, or believing we got it right, only to learn we had more work to do. Growth mindset, metrics-driven leadership, and feedback loops are essential along the path. Leadership’s future state visioning work early on is critical across all of these change management considerations. An SAP S/4HANA migration should be a foundationally transformational opportunity for any company, providing a clean digital core for decades to come. Executive leadership dedication to truly change is essential for this enterprise generational investment to pay dividends.
