18 Years in SAP: What I'd Tell Myself on Day One
The skills that matter, the ones that don't, and the meetings you should skip. Architect lessons from 40+ implementations across 3 continents.
Day one. Someone mentioned a mandant. I nodded. I had no idea what it was — not the word, not the concept, not how it related to the "client" I kept hearing in the same breath. I spent two days building a private theory instead of asking a question that would have taken 45 seconds to answer. The model was wrong. Someone eventually told me what a client actually was in week three, which was more embarrassing than asking in week one.
Eighteen years later, here's what I wish someone had said out loud when I started — specific enough that it couldn't be ignored.
2006 — present
The Years, In Order
Eighteen years later, here's what I wish someone had said out loud when I started — and wasn't generic enough to ignore.
The 5-Year Rule (and the Mistake I Made)
In years three through five, I added FI, then CO, then some MM exposure. My resume looked well-rounded. I was not well-rounded. I was 25% effective across four modules instead of genuinely dangerous in one. I had been doing SD. I was getting good at SD. I should have stayed in SD for another three years and become the person your PM calls at 11pm when a pricing procedure breaks.
The consultants who become genuinely valuable early do the opposite. They find the hardest implementation on their project and volunteer for the piece nobody else wants. They read the SAP help docs for their module the way other people read novels. They find one person ten years ahead and watch how that person thinks — not what they know, but how they frame problems.
Depth before breadth. Five years minimum in one module before you deliberately expand. Breadth is a complement to depth, not a substitute. The "broad consultant" play makes sense in year eight. In year three, it just means you're the first to be replaced by someone who actually knows what they're doing.
The Status Email Formula
Writing a status email that a CFO and a basis consultant can both read and both find useful is a skill. It is not taught anywhere. The gap between people who can do it and people who can't is visible in every project I've ever worked on.
The format I've used for the last twelve years:
Line 1: [GREEN / AMBER / RED] — one sentence explaining why.
This week: Three bullets. Past tense. Factual. No editorializing.
Action required: [Name]: [specific ask] by [date]. One line per person.
If it's longer than a page, you're writing a report, not a status. If someone has no action item, remove them from the To: line.
The discipline is in the last part. Naming a specific person with a specific ask by a specific date feels aggressive until you realize that vague action items never get done. "Team to review by end of week" is not an action item. It's a wish.
The Meeting You Should Actually Skip
I have sat in steering committees as "technical representation" for more projects than I can count. My contribution in roughly 80% was zero. Not low — zero. The decisions were happening at a level where my input wasn't relevant, and I was spending two hours being a warm body so the attendee list looked thorough.
The meeting you can always skip is the one where your honest answer to "what decision did I make or what did I contribute that couldn't have happened without me?" is "I updated people on things they could have read in the status email."
The meetings worth protecting are different. Technical architecture sessions where your expertise shapes a decision that will still matter in three years. Working sessions where you're translating between a business stakeholder and a developer in real time, and the translation is the whole value. Retrospectives where the team's process actually changes as a result.
Everything else is overhead dressed up as participation.
The political version of this: you can't just stop showing up. The way I've done it is to say, "I can make better use of that time preparing the technical analysis you'll need for the decision. Would it be alright if I joined only when there's a technical decision on the agenda?" I have never been told no. Most project managers are relieved.
The Business Conversation You're Avoiding
Early in my career, I worked on a manufacturing SD implementation. I knew the configuration cold. What I didn't know was that the reason they had three different sales organizations was a deliberate margin isolation strategy — designed by their CFO. When I proposed consolidating them for cleaner order management, I nearly created a reporting problem that would have masked which product line was dragging down the company.
The BW consultant who understands supply chain beats the one who only knows BEx. Not because supply chain makes them better technically — it makes them better for the business. The technical skill gets you in the room. The business understanding determines how long you stay there.
The SAP ecosystem is full of technically exceptional people who plateau because they can configure anything but can't explain why the configuration decision matters to the VP of Operations.
On every project, find one business stakeholder who will tolerate your questions and ask them to explain the process as if you knew nothing. Read the annual reports of the companies you work for. Understand the P&L impact of the systems you build. That investment makes the last ten years of a career look completely different from the first ten.
Four Things That Took Too Long to Learn
The career advice I wish I had received isn't technical. The technical stuff gets figured out. It's everything underneath it — how to ask the question in week one, how to pick one thing and go deep before you go wide, how to write an email that a CFO and a basis consultant can both use, how to walk out of the meeting that isn't worth your time. Eighteen years in, those are the skills I still notice first when I'm watching someone who's going to be exceptional.
Quick check — did this stick?
Question 1 of 3Keep exploring on ayraix.com
Stay with us · explain
What was your biggest challenge when starting out in SAP?
Reflect on your early days working with SAP. What was the most challenging aspect you faced?
No account needed — pick a take, then keep reading. We rotate these prompts so each piece feels like a conversation, not a clone.
