Phase 17 — Consulting Skills & Capstone
🎯 In plain words
❓ Why it matters
Plain truth: "certified" is not "hired." Plenty of certified people don't get offers because they can't explain a process clearly, can't gather a requirement, or freeze in an interview. The skills in this phase are what separate the consultant who gets the role from the one who doesn't — and a strong capstone project lets you show rather than just claim.
🧠 Key concepts you must know
1. Requirement gathering
The skill of asking the business the right questions and listening — "what do you actually need this process to do?" You translate vague business wishes into clear, specific statements a project can build against. Good consultants ask; weak ones assume.
2. Writing functional specifications
A functional spec (FS) is the document that says, in business language, what something should do and why — so a developer or another consultant can build it without guessing. It bridges business and technical. Being able to write a clear FS is a core, daily consulting skill.
3. Handling tickets & change requests
- Incident (support ticket) — something is broken; you investigate and restore it (incident → resolution). "The GR won't post."
- Change request (CR) — someone wants something new or different; it's a planned, approved enhancement. "Add a new plant."
Knowing the difference — fix what's broken vs. build what's new — is fundamental to support work.
4. Client communication & estimation
- Talk to your counterparts — MM doesn't live alone. You constantly coordinate with FI (account postings/OBYC), SD (sales/deliveries), and PP (production/MRP).
- Estimate effort — give a realistic sense of how long a change will take. Over-promising kills trust.
- Communicate clearly — explain options and trade-offs in plain language the business understands.
5. Interview mastery
Rehearse the classics until they're automatic:
- "Walk me through a P2P cycle." Structure it as a clean flow: PR → RFQ/source → PO → GR → invoice (3-way match) → payment, naming the T-codes and documents.
- "Defend a config decision." State the decision, the business reason, the alternative you rejected, and the impact — calmly and confidently.
- The common MM questions on movement types, valuation/OBYC, special procurement, and release strategies.
6. The capstone — your portfolio piece
A full mock implementation you can show and talk through: take a fictional client brief, design the org structure, configure it, run all the P2P scenarios, document your decisions, and present it end to end. It proves you can deliver, gives you concrete interview stories, and sets you apart from candidates who only have a certificate.
🛠️ Do it now — practise alongside
First, drill the interview questions:
📘 Interview Bank + Capstone (full page) PO interview Q&AThen build your capstone — the project that gets you hired:
- Take a fictional client brief (a new company that needs procurement set up).
- Design the org structure for them.
- Configure it live in IDES.
- Run all the P2P scenarios end to end.
- Document your decisions (re-use your configuration-rationale style from Phase 15).
- Present it — out loud, as if to a client or interviewer.
Lean on what you've built: Setup steps Scenarios plus the full interview bank.
🔗 Connects to
- Phase 15 — SAP Activate Methodology: the project lifecycle these soft skills operate inside.
- Phase 16 — Certification Prep: the cert plus this phase together make you hireable.
- Curriculum: your capstone pulls together everything across all 18 phases.
🎓 Cert focus & quick recall
Not on the exam — but this is the difference between passing the exam and landing the role. Rehearse these out loud.
What is a functional spec?
A document that describes, in business language, what something should do and why — so a developer or consultant can build it without guessing. It bridges business and technical.
Incident vs change request?
An incident is something broken that you fix to restore service; a change request is a planned, approved request for something new or different (an enhancement).
How do you structure a "walk me through P2P" answer?
As a clean flow: PR → RFQ/source selection → PO → goods receipt → invoice verification (3-way match) → payment — naming the documents and T-codes at each step.
What makes a strong capstone?
A complete, documented mock implementation: a client brief, a designed org structure, live configuration, all P2P scenarios run end to end, decisions written up, and a confident walkthrough presentation.
✅ You're ready to move on when…
- You can confidently walk someone through a full P2P cycle out loud.
- You can explain incident vs change request and what a functional spec is.
- You can defend a config decision with reason, alternative and impact.
- You've built and can present your capstone implementation end to end.