18-Year SAP Veteran: Career Truths I Wish I'd Known Sooner

An architect who has spent 18 years in the SAP world and completed over 40 implementation projects across three continents recently shared what he most wishes he could tell his younger self. This is not a technical tutorial, but an honest retrospective on career choices, communication styles, and mindset.

The Starting Point: That First Day When I Was Afraid to Ask Questions

On his first day, someone mentioned the word "mandant." He nodded along, but his mind went blank — he didn't know what the word meant, nor how it related to the "client" that his colleagues kept mentioning.

For the next two days, he didn't ask anyone. Instead, he tried to piece together his own understanding from context. It was completely wrong. It wasn't until the third week that someone finally told him what a client actually was.

He wrote in his retrospective: The window for asking questions closes by week six. In week one, no one expects you to know everything. But by week six, people have already formed a fixed impression of you. That question you think will make you look foolish would have taken just 45 seconds to get answered in week one.

---

"Mandant" is German and, in the SAP context, means "client" — the topmost organizational unit in an SAP system, used to achieve data isolation and multi-tenant architecture. A single SAP system can contain multiple clients, each with its own independent user master data, configuration, and business data, invisible to each other by default. For example, "100" is typically used for development, "200" for testing, and "300" for production. This three-tier system landscape (development-test-production) is built on the client concept. Beginners often confuse it with business organizational units like "company code" or "sales organization," but the client is a technical isolation boundary, not a business organizational structure. Understanding the client concept is the starting point for understanding SAP system authorization management, the transport mechanism, and system architecture.

Depth First, or Breadth First? A Costly Misjudgment

In years three through five of his career, he began adding experience in FI, CO, and some MM on top of the SD module. His résumé looked more "well-rounded," but his own assessment was this: knowing 25% of four modules is not as good as being irreplaceable in one.

He should have spent another three years deepening his SD expertise, becoming the kind of person a project manager would call at 11 PM when a pricing procedure broke. But in year three, he chose to chase breadth, because on paper, breadth looked like ambition.

Depth before breadth. Spend at least five years deepening one module before deliberately expanding. Breadth complements depth; it doesn't replace it. The "generalist consultant" strategy only works by year eight; in year three, it just means you're the first one replaced by someone who actually knows what they're doing.

He observed that consultants who became truly valuable early on did the opposite: they volunteered for the hardest parts of projects that no one else wanted, studied SAP's official help documentation like a novel, and found someone ten years ahead of them to shadow for six months — not to learn what that person knew, but how that person framed problems.

---

SD, FI, CO, and MM are the four core functional modules in SAP ERP. SD (Sales and Distribution) covers the entire sales process from sales orders, pricing, and delivery to billing. FI (Financial Accounting) manages general ledger, accounts receivable and payable, asset accounting, and external financial reporting. CO (Controlling) handles cost centers, profit centers, internal orders, and management accounting and cost control. MM (Materials Management) deals with procurement, inventory management, and material master data. The modules are tightly coupled through real-time integration — for example, SD billing directly generates FI accounting documents, and MM goods receipt automatically triggers FI material valuation postings. This integration means that configuration changes in one module often ripple into others. So "cross-module understanding" does have value, but only after you've built enough depth in at least one module to understand the trigger points and impact of integration.

An Email That Both a CFO and a BASIS Consultant Can Understand

Writing a status email that's genuinely useful to both a CFO and a BASIS consultant is a skill that's never formally taught. But the gap between those who can write one and those who can't was clearly visible in every project he worked on.

He used the same format for twelve years:

First line: [Green/Yellow/Red] — one sentence explaining why.

Completed this week: Three bullet points. Past tense, facts only, no commentary.

Action needed: [Name]: [specific request], by [date]. One line per person.

If it's longer than one page, you're writing a report, not a status update. If someone has no action item, remove them from the recipient list.

"The team will review this week" is not an action item — it's a wish. Naming a specific person, a specific request, and a specific date feels aggressive — but vague action items never get done.

Meetings You Should Skip, and Meetings Worth Protecting

He has sat in countless steering committees as the "technical representative." About 80% of the time, his contribution was zero — not minimal, zero. Decisions were made at a level unrelated to his input, and he spent two hours being a warm body just to make the attendee list look more complete.

The test is simple: if the honest answer to "What decision did I make, or what wouldn't have happened without me?" is "I updated information someone could have read in my status email," then you can always skip that meeting.

The meetings worth protecting are different: technical architecture discussions where your professional judgment shapes a decision that will still matter three years from now; workshops where you translate in real time between business stakeholders and developers, and that translation is the entire value; retrospectives where the team's process actually changes because of your participation.

In practice, he suggests saying: "I could use that time to better prepare the technical analysis you need to make your decision. Can I just attend when there's a technical decision on the agenda?" He says no one has ever refused, and most project managers were actually relieved.

Technology Gets You in the Room; Business Understanding Determines Whether You're Invited Back

Early in a manufacturing SD implementation project, he knew the configuration inside out, but didn't know that the customer's three sales organizations were a deliberate profit-isolation strategy designed by the CFO. When he proposed merging the sales organizations to simplify order management, he nearly created a reporting problem that would have obscured which product line was dragging down company performance.

The SAP ecosystem is full of people who are technically excellent but whose careers have stalled, because they can configure anything but can't explain to a VP of Operations why a configuration decision matters.

His advice: on every project, find a business stakeholder who's willing to put up with your questions, and ask them to explain the process as if you know nothing. Read the annual report of the company you're serving, and understand the impact of the system you're building on the P&L. This investment will make the last ten years of your career look completely different from the first ten.

---

Sales Organization is a core organizational unit in the SAP SD module, used to divide sales responsibility areas and pricing strategies. Multiple sales organizations can be set up under one company code. Common design considerations include: isolation by product line (different product lines managed by different teams, with independent pricing and profit accounting), division by geographic region, or differentiation by channel. When a customer sets up three sales organizations, it usually means the CFO needs to track revenue and profit independently by product line or region — merging sales organizations may simplify order management configuration but destroys this profit isolation mechanism, making it impossible for management to accurately determine which product line is profitable and which is losing money. This is a classic case of "technically correct but business wrong": simplification at the configuration level can destroy decision-making value at the financial reporting level.

Four Things That Took Too Long to Learn

First, writing is a career skill. The architects and principal consultants who keep getting invited back are almost all people who can write — proposals that make decisions obvious, status emails that don't waste the reader's time, and architecture documents that new team members can actually use.

Second, reputation travels fast. SAP consulting is a small world. Whoever you made look good in 2012 is now a delivery director; whoever you frustrated in 2016 is on the hiring panel for the job you want now. Making projects easier to deliver is both the morally right thing and the strategically right thing.

Third, ask questions in week one. The window for the question you're afraid will make you look foolish closes by week six.

Fourth, depth first, then breadth. Spend at least five years deepening one module before deliberately expanding.

Even in the era of SAP BTP, AI Core, and LLMs embedded in S/4HANA workflows, these underlying principles haven't changed: understand the business problem before touching configuration. Eighteen years later, the fundamentals are still the fundamentals.

---

SAP BTP (Business Technology Platform) is SAP's cloud platform-as-a-service offering, providing integration, extension, data analytics, and AI capabilities that allow enterprises to build extension applications without modifying the S/4HANA core. AI Core is the AI runtime environment on BTP, supporting the deployment and management of machine learning models. LLMs embedded in S/4HANA workflows refers to integrating large language models into SAP business processes, such as intelligent approvals, automatically generating procurement request descriptions, or assisting with financial reconciliation. These new technologies are indeed changing the SAP consultant's toolkit, but they haven't changed a fundamental fact: no matter how the tech stack evolves, a consultant's core value always lies in accurately understanding business problems, translating them into system solutions, and communicating in a language decision-makers can understand. The fundamentals needed 18 years ago — asking questions, going deep, writing, understanding the P&L — remain irreplaceable competitive advantages in the AI era.