Eursap's Ask-the-SAP-Expert – Roman Khromin

Eursap's Ask-the-SAP-Expert – Roman Khromin.

This month, we feature Roman Khromin. Roman takes conceptual SAP ideas and turns them into reality with real returns on investment and utilization of top-drawer technology. For most SAP gurus, this is technical alchemy, but Roman takes it in his stride and has built a career out of it. Let’s find out how. 

Roman, thanks so much for agreeing to talk to us. For me, your journey is fascinating, but can we start with a short background for readers who don’t know you?

Thank you, Jon. It’s a pleasure to be here. My journey into SAP started in the early 2000s. After graduating, I began as a business analyst for custom software development serving Boeing and Deutsche Bank before joining Accenture in 2003, where I learned SAP on some of the largest programmes in the Energy industry: Total, Shell, BP, Maersk Oil, BG Group. Those early years meant living out of hotel rooms across the Middle East, Asia, and Europe, sometimes for months at a stretch. It was intense but formative. Over 25 years, I've worked across the full spectrum: Big 4 consulting at EY and PwC, corporate transformation roles at BP, RBC and AWS, and now I run my own advisory practice focused on what I call “CFO Tech Value” - helping organisations turn their ERP and data investments into measurable P&L impact. I’ve been fortunate to lead programmes across Financial Services, Energy, Utilities, Retail and Aerospace, from £5m country rollouts to £300m multi-year global transformations spanning 30+ markets.

And was there a defining moment or SAP project early on that shaped your direction?

Absolutely. It was 2003, my first major SAP programme with Accenture - a multi-country rollout for Total across Syria, the UAE, Qatar and Yemen. I was the SAP Finance and JVA lead, and we were integrating FI/AA/CO/JVA with MM/PM/PS across complex operated and non-operated venture structures, production sharing agreements, the whole lot.

What struck me was the gap between the technical elegance of the solution and the business reality on the ground. We built impressive SAP configurations, but the real value came from understanding how a production sharing agreement actually flows through the books, how joint venture partners need to see their cash calls and expenditures, how the field operations people think about CAPEX and OPEX.

That experience taught me that SAP is never really about the software – it’s about the business problems you’re solving. I still approach every programme that way: start with the business, work backwards to the technology.

Which SAP modules or areas (e.g. S/4HANA, data governance, integration) have you focused on most — and why did you choose to specialise there?

My core has always been Finance - FI/CO, including Joint Venture Accounting (JVA), then Central Finance, Financial Products Subledger (FPSL), Group Reporting, and now the full S/4HANA Finance stack including SAP Analytics Cloud and PaPM. But I’ve deliberately stayed broad across the end-to-end value chain: Record-to-Report, Procure-to-Pay, Order-to-Cash, Plan-to-Produce.

Why Finance? Partly due to my background - I am a certified management accountant, so I think in P&L terms instinctively. But also, because that's where the value realisation rubber meets the road. Every business case for an SAP programme ultimately lands in finance - cost take-out, revenue uplift, working capital improvement, faster close. If you cannot trace the technology investment through to the P&L, you haven't delivered value.

But here’s what I genuinely enjoy: the helicopter view. Understanding how all the pieces connect. Finance doesn’t exist in isolation. The quality of your financial reporting depends on your procurement master data, your sales order accuracy, your production costing. That’s how the business actually makes money, through those handoffs between functions. I find that integration layer fascinating, and frankly, that’s where programmes succeed or fail. More recently, I’ve added cloud data platforms and migrations to my toolkit. Data is the new battleground. You can have the best SAP configuration in the world, but if your data is poor, your insights are worthless. And you certainly cannot build reliable AI solutions without quality data.

Realising value from SAP projects is notoriously difficult and has come to be known as something of a holy grail in the industry. And yet you have chosen to specialise in this area! Tell us about CFO Tech Value and how it works and how it can help in this difficult area?

You’re right – it’s the holy grail, and frankly, the industry has a poor track record. I’ve seen too many programmes that hit every technical milestone but left the business wondering where the promised benefits went. The go-live happens, the consultants leave, and the CFO is left asking: “Where’s the £50m we were promised?”

CFO Tech Value has become my answer to that problem. It’s a methodology that starts with the CFO’s P&L and works backwards to the technology, not the other way around.

Most programmes start with the software. “We are implementing S/4HANA” and then bolt on a business case to justify it. I flip that. I start with the business outcomes: What does the CFO need to see in the P&L over the next three to five years? What are the specific value levers - cost reduction, revenue acceleration, working capital release, risk mitigation? Then I trace those back to the capabilities required, and only then to the technology enablers.

The methodology has three pillars. First, Transformation Design - creating a board approved roadmap that’s explicitly linked to P&L outcomes, not just technical milestones. Second, Delivery Assurance - governance that tracks benefits realisation alongside schedule and budget, with proper stage-gates. Third, Value Realisation - embedding benefits tracking into BAU operations so the value doesn’t evaporate after go-live. At its core, it’s about making the CFO the true sponsor of the programme, not just the budget approver. When Finance owns the outcomes, not just IT, the whole dynamic changes.

As a recognised SAP “guru,” how do you mentor or develop other SAP professionals — and why is that important to you?

I’m not sure about “guru” – that’s very kind, but I’ve made plenty of mistakes along the way! What I do believe is that talent development is one of the most important things we do.

Throughout my career, I’ve built teams from scratch - 300+ people across EMEA, APAC and the Americas at various points. What I’ve learned is that the best SAP professionals aren’t just technically brilliant; they’re people who can bridge the gap between technology and business, who can sit with a CFO and translate their concerns into solution requirements.

I’ve always focused on a few things. First, structured coaching, i.e. regular one-to-ones, skills matrices, certification paths. Second, giving people stretch assignments. The best learning happens on live programmes, under pressure, with support. I’ve always tried to give people opportunities slightly beyond their comfort zone, then backed them up when they needed it. Third, building communities of practice. At BP, I established an SAP Functional Centre of Excellence with 65 core SMEs and an extended community of 180 across regions. That knowledge-sharing culture outlasted any individual project.

Why does it matter? The talent crisis in SAP is real. We’re losing experienced consultants faster than we’re developing new ones, and the problems we’re solving are only getting more complex. If we don’t invest in the next generation, who’s going to deliver these programmes in ten years?

How have the myriad of major changes in the SAP ecosystem over the last decade affected the way you work?

The changes have been profound. When I started, SAP was essentially R/3 on-premise (in fact, there was no such term - everything was on-premise). You implemented it, you customised it heavily, and you ran it for 15-20 years. The relationship with SAP was transactional - buy the licence, do what you want with it, as long as you pay for annual support.

Now we’re in a completely different world. The shift to S/4HANA was the first major disruption. It is not just a new product, but a fundamentally different architecture. HANA as the database layer, the simplified data model, Fiori as the UX layer. That required everyone to retool. Then came flavours of cloud: Private Cloud, then Public Cloud, RISE with SAP, and the whole managed services model. The relationship with SAP has become much more of a partnership, for better or worse. You’re not just buying software; you’re buying a service, an operating model, a roadmap.

And now AI is changing everything again. Joule, agentic AI, embedded ML in business processes. We’re only at the beginning of understanding what this means for how work gets done.

How has this affected my work? Three ways. First, I’ve had to stay current - constant learning, certifications, hands-on experience with new platforms. You cannot advise clients on RISE if you haven’t worked on a RISE implementation. Second, I’ve become more vendor-agnostic. The ecosystem is so complex now that no single vendor has all the answers. Clients need advisors who can navigate across SAP, hyperscalers, best-of-breed tools, and help them make the right choices. Third, I’ve leaned harder into fundamentals. Technologies change, but the evergreen core principles of programme delivery, stakeholder management, change leadership, value realisation - those are timeless. If anything, they matter more now because the technology complexity is higher.

What’s your view on SAP’s cloud-first strategy (e.g., S/4HANA Cloud, RISE)? Do you think it aligns well with what customers really need?

This is a nuanced question, and I’ll give a nuanced answer. SAP’s cloud-first strategy makes sense from SAP’s perspective. They need predictable recurring revenue, they want to reduce the fragmentation of their installed base, and they genuinely believe that cloud delivery enables faster innovation. All fair points.

For customers? It depends. And that’s where I sometimes worry about how the message gets communicated. For organisations that can genuinely adopt standardised processes - and there are many that can - Public Cloud S/4HANA is excellent. You get continuous innovation, you’re always on the latest release, and your total cost of ownership can be significantly lower. For mid-market companies especially, this is often the right answer. But for complex enterprises with heavily customised landscapes, decades of technical debt, and differentiated processes that genuinely create competitive advantage? The “clean core” message can feel like it’s dismissing their reality. These organisations can’t just standardise overnight. They need a managed transition path.

My concern is that some customers are being pushed towards cloud for commercial reasons when their actual business needs would be better served by a different approach. The best outcome is when the technology choice is genuinely driven by business requirements, not by vendor incentives or partner margins.

What I tell clients is: be clear about what differentiates you. Standardise ruthlessly where you don’t differentiate. Preserve flexibility where you do. And don’t let anyone tell you there’s only one right answer.

How do you see emerging technologies like AI, machine learning, and predictive analytics shaping the future of SAP?

This is the most exciting and most uncertain time I’ve seen in 25 years. Let me separate hype from reality. The reality is that embedded AI and ML in SAP processes is already delivering value. Intelligent invoice matching, predictive maintenance, demand sensing, anomaly detection in financial transactions - these are production-ready capabilities available today. Not science fiction anymore. What’s coming next is agentic AI, where systems don’t just recommend but take action. Imagine an Al agent that doesn’t just flag a payment risk but actually holds the payment, notifies the supplier, and creates a case for resolution. That changes the operating model fundamentally. 

But here’s my concern: the change management implications are enormous, and I don’t think the industry is ready. Every AI capability that automates a task is also eliminating or transforming a role. We’re not just implementing technology; we’re redesigning work. The human side - the fear, the resistance, the need for reskilling – that’s going to be the real challenge. I’d also caution clients to think critically about where Al value comes from. Not all of it requires an S/4HANA migration. Some of the most capable Al tools sit outside SAP entirely. The question should always be: what’s the fastest, lowest-risk path to the business outcome you need?

If you could suggest one “must-do” item to SAP’s roadmap team to prioritise for the next 3-5 years, what would it be and why?

Value realisation tooling - embedded, not bolted on. Here’s what I mean. SAP has invested massively in implementation accelerators: SAP Activate, Signavio for process design, LeanIX for enterprise architecture, Cloud ALM for delivery. All valuable. But there’s a gap: once you go live, tracking whether you actually achieved the promised business benefits is almost entirely manual. Benefits realisation is treated as a post-project activity, often owned by a PMO that’s been disbanded, using spreadsheets that nobody maintains.

What if SAP built benefits tracking directly into S/4HANA? Imagine: during the Discover phase, you define your value targets: days sales outstanding reduction, close cycle improvement, procurement savings. Those targets get embedded as KPIs in the system. Post go-live, the system automatically tracks actual performance against the baseline. Dashboards show whether you’re realising value or not. Alerts trigger when you're off track. This would transform the conversation. Instead of arguing about whether the project succeeded, you’d have objective data. It would also create accountability as sponsors couldn’t declare victory prematurely, and partners couldn’t walk away from underperforming programmes. 

I know this isn’t as straightforward as it sounds as benefits realisation depends on many factors beyond SAP. But if anyone can solve it, SAP can for sure. And it would be a genuine differentiator.

You’re very active in the SAP ecosystem. How do you balance day-to-day consulting work with contributing to the broader SAP community (blogs, talks, mentoring)?

Honestly? It’s a constant tension, and I don’t always get it right. The client work always comes first, and those commitments are sacred. But I’ve learned that thought leadership and community contribution aren’t separate from client work; they feed each other. When I write about value realisation challenges, I’m processing what I’m seeing on live programmes. When I mentor younger consultants, I’m forced to articulate principles I might otherwise take for granted. When I speak at events, I get challenged by peers and learn from their perspectives. Practically, I protect certain time slots. Early mornings are for writing, before the emails and calls start. I try to do one substantive piece of content per week, whether that’s an article, a blog, or a LinkedIn post. I’ve found that consistency matters more than volume. The mentoring happens within the natural rhythm of projects. I don’t schedule separate "mentoring sessions". I coach in the moment, during programme meetings, on client calls. It’s integrated into how I work. What I struggle with is conferences and in-person events. With client delivery pressures, it’s hard to take days out for speaking engagements. I’ve had to be more selective, focusing on events where I can genuinely add value rather than trying to be everywhere.

Can you tell us about a project you are most proud of? Not just technically, but from a business impact perspective?

The one that stands out is the work at RBC, Royal Bank of Canada's Investor and Treasury Services business. When I joined, the brief was to modernise the finance subledger across 12 European and Asian jurisdictions to meet ECB regulatory demands. We were implementing S/4HANA in a tier-one regulated bank, with the European Central Bank scrutinising every architectural decision. What made me proud was not just that we delivered, though we did, on time and on budget. It was how we delivered. This project became a model for running SAP implementation using genuine Agile methodology. We ran two-week sprints, and each sprint delivered a production increment: a set of features that went into the pre-production system following product owner demos. To this day, people struggle to believe you can run an SAP implementation this way! But the team is living proof. That approach allowed us to eliminate traditional UAT entirely as everything was tested during product owner demos. We also removed separate training sessions because users were involved throughout. The result? We rolled out to some countries in under three months, from design to go-live! We also secured ECB approval for the new SAP subledger architecture - not a trivial thing in a post-2008 regulatory environment. The regulators were satisfied that our data lineage, controls, and reporting met their requirements. 

But the thing I’m most proud of? The team. We built that capability from zero: hired, trained, developed a high-performing group who stayed together through the programme and beyond. Less than 3% attrition. Several have gone on to lead their own programmes. That’s the impact that lasts - not just the system we built, but the people we developed.

Looking back, is there any decision or project you regret? What would you do differently now?

Yes, and I’ll be honest about it. Early in my career, around 2006-2007, I was leading a global finance and BI rollout, and I didn’t push back hard enough on an unrealistic timeline. The business was under pressure to deliver certain reporting capabilities by a fixed date, and the programme timeline was set accordingly. I knew the data quality wasn’t where it needed to be, but I convinced myself we could fix it in parallel. We made the go-live, but the first few months were painful. The reporting had gaps, the business had to implement manual workarounds, and my team was firefighting instead of stabilising. We got through it, but at real cost to people’s wellbeing and the client’s confidence. 

What would I do differently? I’d have the difficult conversation earlier. I’d present the risks more starkly to the steering committee. Not just “data quality is a risk” but “here are the specific things that will break if we don’t address this, and here’s the cost of fixing them later versus now.” I’ve learned that stakeholders can handle bad news if you give them options. What they can’t handle is surprises. My job as a programme leader is to surface reality, not to tell people what they want to hear. That lesson has stayed with me. Now I’m almost obsessive about data quality governance, mock migration cycles, and having explicit go/no-go criteria that everyone signs up to in advance.

SAP consulting can be very demanding. How do you make sure you keep your passion and avoid burnout?

This is so important, and I’ve learned it the hard way. SAP consulting is indeed very demanding. The travel, the long hours, the constant context-switching between clients. In my 30s, I thought I could just power through. Now, I know better. A few things that help me. 

First, physical health. I’m serious about exercise and sleep. Not because I’m naturally disciplined, but because I’ve seen what happens when I’m not. When I’m physically run down, my judgement suffers, my patience shortens, and I’m not the leader my team needs. 

Second, boundaries. I’m much better now at protecting time: evenings and weekends where possible, proper holidays where I can actually disconnect. Not always achievable on a troubled programme, but as a default setting and a mindset.

Third, variety. I deliberately take on different types of work: delivery leadership, advisory, thought leadership, mentoring. I can always shift energy from one to another. It keeps things fresh.

Fourth, meaning. The work has to matter to me beyond just the commercial outcome. If I’m helping a client genuinely transform their business, if I’m developing people who’ll go on to do great things, if I’m contributing to how our industry thinks about value realisation – that’s energising. Pure grind without purpose is what leads to burnout.

If you had a magic wand and could design the “perfect SAP system of the future,” what three innovative features would you include — and how would that transform business?

Great question. Let me dream a little! 

First: true natural language everything. Not just Joule as a chatbot but genuinely being able to interact with the system as you would with a knowledgeable colleague. “Show me which customers are likely to pay late this month and suggest actions.” “Why is our gross margin down in the Nordic region?” “Create a purchase order for 500 units of product X from our preferred supplier with standard terms.” The system understands context, remembers history, and acts intelligently. This would democratise SAP as you wouldn’t need months of training to be productive. Second: automatic value tracking. I mentioned this earlier but imagine if your ERP could automatically measure and report on business outcomes! Not just transactions, but actual value created. “Since go-live, your DSO has improved by 4 days, worth £2.3m in working capital release. Your month-end close is 1.5 days faster, releasing 240 person-days annually.” Real-time, objective, auditable. This would transform how programmes are justified and measured. Third: self-healing data quality. Master data problems are at the root of so many SAP headaches. What if the system could detect data quality issues proactively, trace root causes, suggest corrections, and even implement fixes with appropriate controls? “We've detected 47 vendor records that may be duplicates. Here's our recommended consolidation. Approve, modify, or reject.” This would shift data management from reactive cleanup to proactive governance. Together, these would transform SAP from a system you operate to a system that operates with you - a genuine business partner rather than a technology platform.

The question we always like to finish on: For newer SAP consultants who want to reach “guru” status, what’s the advice you always give? What mindset or habits matter most?

I'd offer five things.

First, never stop learning. The SAP ecosystem is constantly evolving - S/4HANA, BTP, AI, cloud. If you stop learning, you quickly become obsolete. But learning isn’t just about technology; it’s about business. Understand how your clients make money, what keeps their executives awake at night, what their competitive pressures are. That context is what separates a consultant from a configuration specialist.

Second, own the outcome, not just the task. Early in your career, you’ll be given work packages: configure this, test that, document this. Do them to the best of your abilities, but always ask: what are those for? What business outcome are we trying to achieve? When you start thinking in outcomes rather than activities, you’re on the path to leadership.

Third, communicate relentlessly. The best SAP people I know are translators. They can explain complex technical concepts to business stakeholders, and they can translate business requirements into solution designs. Work on your written and verbal communication. Practice explaining things in simple terms. Learn to tell stories with data.

Fourth, build relationships. This is a people business. Your network, clients, colleagues, partners, is your most valuable asset. Be helpful, be reliable, be the person others want to work with. Your reputation follows you for decades.

Fifth, and perhaps most importantly: remember that technology serves people. Every SAP programme affects real human beings - employees whose jobs change, managers who need new skills, customers who experience different service. If you keep that humanity at the centre of your work, you’ll make better decisions and build better solutions.

The path to “guru” status isn’t about knowing every transaction code, Fiori app or configuration option. It’s about consistently delivering value, developing others, and earning trust. That takes time, but it’s worth the journey.