How Empathy Drives More Robust Solutions in the SAP Ecosystem

#sap #productivity #leadership

Introduction

SAP's project management framework (SAP Activate), focused on S/4HANA implementations and cloud-native SAP solutions, adds an extra layer to the solution-building process: the functional consultant.

Functional consultants act as Product Owners — they not only master business rules but are also specialists in modules such as FI (Financial Accounting) or CO (Controlling), and are invested in keeping the product as aligned as possible to the client's context.

Because this layer exists, solution translation happens through a well-known artifact: the Functional Specification (FS). Typically authored by the functional consultant, the FS is handed to the ABAP developer (who builds SAP extensions using the ABAP language), who is then expected to deliver the solution back to the functional, so both can discuss approaches, exchange perspectives, and validate test scenarios across environments.

Since solution ideation is largely the functional consultant's responsibility, ABAP developers often don't engage actively in that design phase — becoming a replication machine, relying entirely on the spec's rules to write and structure code.

Being dependent on the functional consultant to understand requirements, business rules, and data mappings creates a narrow bias. Even if the functional is a domain expert, they must simultaneously engage with the client and actively participate in SAP Activate rituals. This centralizes a huge amount of knowledge and responsibility in a single person, who must juggle multiple solutions, handle issues and suggestions directly, and then relay everything to the ABAP developer — making incomplete specifications far more likely.

You might be wondering: what does empathy have to do with delivering excellent solutions? And where does SAP fit into this? There is more connection than most people would expect. Here's how it plays out — and why any technical niche should pay attention to it.

Practical Examples

To ground some of these points, consider what happened on August 1, 2008, when Clean Code was published by Robert C. Martin (Uncle Bob). In its preface — amid all the technical content — he touches on the philosophy behind clean code: the act of caring. He draws from two distinct worldviews.

He references Danish wisdom (the Ga-Jol candy wrapper), emphasizing that honesty with code, leaving a codebase cleaner than you found it, and transparency within Scrum all contribute to a solution's long-term survival.

He also references Japanese craftsmanship traditions — quality as the result of altruistic acts of caring, the value of daily disciplined work, and the power of small, continuous improvements that positively shape the environment. Both lines of thought speak directly to the importance of empathy in technology.

Back in the SAP world, then-CEO Bill McDermott stated in 2016: "Everything has to start with empathy for the end user and the experience they are receiving from your company." — putting empathy at the center of solution delivery and client service.

Following that direction, SAP launched several initiatives grounded in this philosophy:

SAP BTP (Business Technology Platform), first introduced in 2021, consolidated multiple services and products into a single platform for intelligent, integrated business decision-making — a direct application of empathy and design thinking in product strategy.
SAP Build (Apps — recently discontinued in March/April 2026 to be restructured), which enabled business users to create their own applications and workflows to solve real day-to-day problems, embodying concern for user autonomy and agility.
The Clean Core architectural principle (2025), which advocates minimizing custom objects to simplify S/4HANA environment upgrades — a design philosophy that considers the long-term maintainer of the system, not just the original developer.

Beyond the technical domain, Brené Brown's TED Talk "The Power of Vulnerability" reinforces this point: empathy is the antithesis of shame. She argues that practicing empathy — listening without judgment, sharing one's own experiences of vulnerability — requires genuine exposure and interest in others' realities. Applied here: disengagement, passivity, or simply doing only what the spec dictates distances a developer from the best possible solution.

What Can We Do?

Building better solutions starts with small changes that gradually influence the surrounding team.

What is within our control: stepping out of the comfort zone to understand more about the business — processes, rules, regulations, and solution decisions. Thinking about what is genuinely good for the project and for the product. This can begin simply with questions and by demonstrating interest.

From there, trust and recognition can be built — which may lead to closer integration with the project methodology and more active developer involvement, something project management teams can then formalize. This is a sensitive point, especially in consulting environments: it depends on the client's framework, team training, and openness among other ABAP developers. Many variables must be mapped and considered.

Depending on available tools and practices, this engagement can lead to standardized documentation, design artifacts, and architecture records that also serve as execution controls — User Stories, architecture diagrams, BPMN flows in SAP Signavio, LeanIX, or Cloud ALM. This is context-dependent: if it touches native project processes and documentation, it involves the previous point's considerations. Strategy-level changes require leadership alignment.

Finally, collaborating directly with functional consultants and other stakeholders for validation is key — reviewing a data model (ERD) or BPMN with a functional consultant, or a backlog and Gantt chart with a project manager. They will likely be able to interpret these artifacts, but initiative without alignment is just an unsanctioned action with unpredictable consequences. The approach is to demonstrate interest gradually, deepen questions over time, earn respect and trust, and use artifacts as collaborative support tools.

Real-World Scenario

I once received a bare-bones FS from a module that few people have expertise in — and that has little documentation even on the internet. I had to study extensively to deliver an acceptable first version.

The task was an enhancement of an event in the TM (Transportation Management) module, which invoked a graph-based structure triggered by a SAP cloud solution: SAP Logistics Business Network (SAP LBN). The functional consultant who originally authored the FS had left the company, and the one who took over was split across another project. I had very little interaction with the functional and even less with the client stakeholders (PMO and Key Users), leaving the core requirements and edge cases largely unclear.

I deployed the solution to the QA environment since no test scenarios existed in DEV. The initial results looked fine — but they reflected an incomplete test scenario. Later, when testing under a more realistic scenario, we discovered that the event was triggered differently depending on whether it came from an internal flow or from LBN's external communication. That communication layer was still unstable, requiring multiple enhancements to capture nearly all event movements within TM.

Two months could have been saved had the test scenarios been aligned upfront, the Business Object (BO) node navigation explored through debugging, and the core business rule properly understood from the start. A more targeted solution would have been possible — fewer restructurings, only precise corrections — avoiding much of the rework entirely.

Conclusion

Empathy and proactivity enable us to build more robust solutions — ones that genuinely consider the client and the business case, with broader test coverage, better development quality, and cleaner architecture.

Exploring the client's perspective and test scenarios is important. But the fundamental goal is that Functional Specifications should be revised only for identified improvements — not for bugs or structural rework. That is how time is preserved for incremental features, code cleaning, and meaningful refactoring.