Working in an Enterprise Environment
SAP Implementation Consulting & ERP - Startupistan Germany · Block I · study notes for revision.
The whole block answers one question: I know the tech, but can I actually work inside a big company? An enterprise is not just a large team - it’s a slower, more careful machine, and most of my early reputation rides on soft habits, not code. This chapter is the map of that machine and the handful of behaviours that make me easy to trust in it.
1 · The Enterprise
Section titled “1 · The Enterprise”What “enterprise” actually means
Section titled “What “enterprise” actually means”An enterprise is a large, established organization - a bank, a car maker, an insurer, a national retailer, an energy company. Size alone isn’t the point; four traits together are:
- Size - hundreds to hundreds of thousands of people, often across countries.
- Complexity - many departments, products, and systems that must all fit together.
- Regulation - outside rules bind it: tax law, data-protection law, industry regulators, auditors who check the rules were followed.
- Longevity - it plans in years and decades, and expects to outlive any single project.
These are exactly the organizations that run SAP.
Why enterprises feel slow - and why the slowness is often the point. It’s rarely lazy people; it’s the cost of three things the org genuinely needs: coordination (a change touching five departments needs five to agree), risk control (when a mistake costs millions or breaks a law, checking twice is cheaper than failing once), and accountability (it must be able to show an auditor who decided what, when). My skill isn’t fighting this - it’s getting things done through the structure.
How an enterprise is organized
Section titled “How an enterprise is organized”Four ideas build the mental map:
- Departments (functions) - Finance (the money), HR (the people), Operations (the core business), Sales & Marketing (customers and revenue), IT (the systems everyone works in). SAP is organized along these exact lines - its modules mirror the departments, which is why understanding the business is part of the technical job.
- Hierarchy - the chain of reporting lines, from the CEO down. It answers day-one questions: who assigns my work, who I escalate to, who approves things. I should always know my own chain two levels up.
- Matrix organization - on almost every SAP project I answer to two lines at once: my department owns my role, growth, and contract; my project owns my daily tasks for a while. Two bosses, but the split is clean - project owns the what and when, department owns the who and long-term.
- Stakeholder - anyone affected by a piece of work or able to affect it. It sounds abstract until a real project: replacing an invoicing tool has the finance team (wants usability), IT (wants maintainability), and management (wants the promised savings) all wanting different things. Listing stakeholders tells me who to talk to - including the quiet everyday users, who are the ones that resist a project late if forgotten.
Where IT sits - and where I sit
Section titled “Where IT sits - and where I sit”Internal IT does three things: infrastructure (networks, servers, accounts), support (the help desk), and business applications (the big systems the departments live in, including SAP). Business applications is where my career points - that team doesn’t just install software, it configures it to fit the company, connects systems, and manages change.
My two possible homes as an SAP professional - both are real paths, and people move between them:
| At a consultancy | In-house at an enterprise | |
|---|---|---|
| Employer | A consulting firm, placed at clients | The enterprise itself |
| Trade | Breadth & pace - many industries fast | Depth & stability - one business deeply |
| Daily life | Travel, new client environments | Stable environment, long-term consequences |
Why enterprises run software like SAP
Section titled “Why enterprises run software like SAP”Picture an enterprise with no shared system: Sales logs orders in one tool, the warehouse tracks stock in spreadsheets, Finance keeps its own books. Each record is locally correct, yet the company can’t answer “can we promise this customer delivery next week?” - the answer lives in three disconnected places that disagree.
That shared book is an ERP (Enterprise Resource Planning) system: one system where selling, purchasing, stock, production, payroll, and accounting all run on the same data - not copies. When the warehouse books goods in, Finance sees the value change immediately, because it’s the same data. SAP is the company that has built the leading ERP for over fifty years.
In three-tier terms (from System Design), an ERP is presentation → application → data, and the application layer is the star: it holds the business rules - what an order must contain, when credit is checked, who may approve what. Configuring those rules to fit a company is the consultant’s job; extending them with custom code (in SAP’s language, ABAP) is the developer’s job.
| Driver | Why it pushes enterprises to ERP/SAP |
|---|---|
| Scale | One shared truth across thousands of users and many sites |
| Integration | One order auto-checks credit, stock, production, invoice - no copying between tools |
| Compliance | Enforced rules + an audit trail auditors and regulators can inspect |
2 · Communication
Section titled “2 · Communication”Most communication failures at work aren’t writing problems - they’re routing problems: a good message sent through the wrong channel.
Which channel for which message
Section titled “Which channel for which message”| Channel | Best for | Bad at |
|---|---|---|
| A record; reaching outside the team; things that can wait | Urgency; long back-and-forth | |
| Chat (Teams/Slack) | Quick internal questions, fast coordination | Being a record; long arguments |
| Call / meeting | Real-time discussion with trade-offs | Anything a message could’ve handled (it’s the most expensive channel) |
| Ticket | A trackable work request (owner, status, history) | Discussion |
| Document | What must outlive the conversation - designs, decisions, guides | Speed |
Two habits sit on top of the table. Default to asynchronous (send, they answer when they can) and spend synchronous time only where live discussion earns its cost - every interruption breaks someone’s focus. And when a chat has gone three rounds without converging, offer a short call - then post the outcome back into the chat or ticket, so the record the chat failed to produce exists anyway.
Writing a professional email
Section titled “Writing a professional email”The subject line decides when my email gets read and how it’s found later. State the topic and, if there’s an ask by a date, the date: not “Question” but “Access request for the reporting system, needed by Thursday”. Then the body follows one shape:
- Context - one or two sentences: what this is about and why I’m writing. Assume the reader has 40 other emails and no memory of my project.
- Request - what I need, plainly. One email, one main request.
- Deadline - when, and the why if it helps them judge it.
- Next step - what happens next, or what I’ll do once I hear back.
To / CC / BCC carry meaning: To = I expect you to act or respond. CC = know, no response expected (adding someone’s manager changes the tone - do it deliberately). BCC = hidden recipients; its one clean use is protecting a big address list from each other. Secretly BCC-ing someone into a conversation surfaces eventually and costs trust - forward openly instead.
Tone is three habits: polite, direct, brief. Not old-fashioned stiffness, not chat-style looseness. Read it once and cut what it doesn’t need - long emails get skimmed or postponed. Urgency is communicated with a deadline and a reason, never with capitals and exclamation marks.
What makes a meeting worth the time
Section titled “What makes a meeting worth the time”Knowing the type tells me how to behave: a status meeting synchronizes (short, factual - the daily stand-up), a decision meeting chooses between prepared options and ends with the decision written down, a working session produces something together (the SAP requirements workshop), a retrospective looks back to improve.
No agenda, no meeting. The agenda - topics, a goal per topic, rough timing, sent with the invite - is what makes a meeting preparable and refusable. An invite with no agenda is asking people to reserve an hour for an unknown purpose. Polite reply: “Could you share what you need from me so I can prepare?”
Notes capture three things, not a transcript: decisions (one sentence each), action items (who does what by when), and open points (raised but unresolved). A one-page set sent the same day beats a perfect transcript next week - and the person who writes the decision is the one whose version everyone works from. An action item has exactly three parts, and if any is missing it quietly dies:
Etiquette that’s small and visible: prepare (read the agenda), be punctual (joining 3 min late to a 10-person meeting burns 30 person-minutes), follow the team’s camera norm and be actually present, and speak up briefly in the room, not in the corridor after - questions are a comfortable way in (“Before we decide, do we know the accounts are ready?”).
International & hybrid work
Section titled “International & hybrid work”Enterprise teams span countries and much of the work is remote, which runs on signals that replace physical presence:
- Across time zones - protect the overlap hours (the team’s scarcest resource) for synchronous work; push everything else async. End the day with a short written handoff - where I got to, what’s blocked, what to pick up - so a colleague’s morning is progress, not detective work.
- Remote norms - keep calendar and chat status honest (they’re how people decide whether to interrupt me), state my responsiveness (“heads-down until 14:00”), and overcommunicate progress slightly - remotely, my written updates are the only evidence I’m working.
- Across cultures - the same sentence lands differently by where someone grew up professionally. Directness, small talk, and formality vary most. The meta-skill: notice the difference before judging it - a colleague who seems blunt or evasive is usually running a different but internally consistent set of norms.
Asking for help & escalating
Section titled “Asking for help & escalating”The four-part help frame doesn’t change at work - what I was trying to do, what I expected, what happened, what I tried - only the channels do: quick question to the team chat (in the open, so others learn), bigger blocker to my lead with a specific ask, technical fault into a ticket. And the timing rule survives: try first, then ask early - silent stuckness is even more expensive here, because someone’s work is usually waiting on mine.
Escalation is deliberately raising an issue to someone with more authority because it can’t be solved at my level. It’s a designed part of the hierarchy, right when: I’m blocked by something outside my control and asking directly hasn’t worked, two instructions genuinely conflict, or something risks the project / breaks a rule above my authority.
3 · Professional Conduct
Section titled “3 · Professional Conduct”Professionalism isn’t suits and stiff language - those are surface. It’s a short list of behaviours other people see and use to decide how much responsibility I can be trusted with.
- Reliability - I do what I said, by when I said. My commitments are load-bearing; people plan their work on top of them. A reliable person with average skills beats a brilliant one nobody can plan around. Its quiet half is committing carefully: “I can’t promise Thursday, but Friday noon is safe” builds more trust than a yes I half-deliver. And when something starts to slip, I say so the moment I know, not on the due day.
- Accountability - everyone makes mistakes; accountability is the minute after I notice one. I name it plainly, say who it affects, say the fix and its timing, and close the loop. Hiding a mistake and quietly repairing it is almost always wrong, because at work someone may build on the broken piece before my quiet fix lands.
- Punctuality - reliability’s most visible daily proof. Being late transmits my time matters more than yours, whether I mean it or not. Once with an apology is human; as a pattern it silently reprices everything else I promise.
The German workplace
Section titled “The German workplace”| Norm | What it means in practice |
|---|---|
| du / Sie | German has two words for “you”: du (informal, among friends and increasingly within teams) and Sie (formal, for strangers, clients, across hierarchy). Follow the room; when unsure, start formal - Sie is never wrong, du where Sie was expected can read as disrespect. |
| Punctuality | Read directly as respect and reliability. Meetings start at the stated minute; a delay is announced in advance, not excused after. Deadlines mean the date on the page. |
| Directness | Feedback is plain and about the work - that plainness is respect, not rudeness. |
| Working time (law) | Day capped at 8h (10 with averaging back to 8 over 6 months); 30-min break past 6h; 11h rest between days; employers must record working time (confirmed by the Federal Labour Court, 2022). |
| Work-life boundary | The rest rules are protection, not decoration - quietly working every evening is not expected. Time tracking is normal here, not surveillance; fill it in honestly, breaks included. |
Giving & receiving feedback
Section titled “Giving & receiving feedback”Feedback is routine maintenance on work, not a verdict on my worth - and being easy to give feedback to is a career skill, because people stop correcting those who react badly, and then those people stop improving.
- Listen to the end without defending - I’m collecting information about how my work landed.
- Clarify until I could repeat the point back (“do you mean the structure or the content?”).
- Decide what I’ll do with it, and say so - feedback is input, not command (“You’re right about section two, I’ll rebuild it; on the naming I’d keep it, it follows the client’s convention”).
- Thank the person, even when it stung - correcting someone is work, and thanking it keeps it coming.
Giving it is three words: specific (point at the exact thing, not “it feels off”), behavioral (about the work, never the person - “this function does two jobs and is hard to test”, not “you write messy code”), and kind (kind ≠ soft; the goal is the other person’s success - plain and warm). This whole skill is just code review with the rails off - comments point at specific lines, discuss the code not the coder, aim to merge well.
Confidentiality & ethics
Section titled “Confidentiality & ethics”Safe working definition: information I only have because of my job is confidential unless it’s explicitly public. That covers client identities (often the fact that a client is a client is secret), business data (any figure - prices, margins, salaries, contracts), internal plans and problems, and personal data. When unsure, treat it as confidential and ask - nobody was ever harmed by checking first.
An NDA (non-disclosure agreement) is a binding contract to keep defined information secret - not a formality (breaching one can end employment and cost money), its duties usually survive the project and the job, and it binds what I share, not what I learn (my skills stay mine; the client’s specifics don’t). On social media, the line runs at other people’s and other companies’ information: I can share my own milestones (“passed my SAP certification”), never client names, internal details, or workplace photos (whiteboards, screens, even branded lanyards leak).
Managing my own work
Section titled “Managing my own work”Enterprises generate more requests than anyone can do, so I choose deliberately and say honestly what I can’t. Urgent = time-pressed; important = consequential - they’re independent, and much of the loudest traffic is urgent-but-unimportant. Best work lives in important-not-urgent, which the urgent noise crowds out; the daily question is “what’s the most important thing I owe today?” - not the loudest.
A professional no has three parts: capacity as fact (“this week is committed to the test cycle through Friday” - no apology spiral), an alternative (“I could take it Monday” - a no with an alternative is help), and escalation when priorities genuinely collide (“both won’t fit before Friday - can you and the lead agree which comes first?”). Making the collision visible to whoever owns priorities isn’t weakness; it’s the structure working. It all runs on a current task board - a glance answers “can you take this?” with facts, not feelings.
4 · Rules & Security
Section titled “4 · Rules & Security”Why so many rules?
Section titled “Why so many rules?”Compliance means following the obligations an org is bound by, from three directions: laws (data protection, tax, working time, industry regulation), contracts (client promises, NDAs, security commitments), and standards (frameworks it certified against). The key personal point: an enterprise can only comply through its people - a company doesn’t handle data carefully, its employees do or don’t. That’s why compliance reaches me as trainings, policies, and rules: it’s the org’s obligations, divided into everyone’s share.
When it fails, the costs are concrete: fines (data-protection authorities can fine a percentage of worldwide revenue), breach cleanup, lost trust (“arrives on foot, leaves on horseback”), and sometimes personal consequences. Understanding why a rule exists is the difference between following it and merely being slowed by it.
Everyday information security
Section titled “Everyday information security”Most incidents start with an ordinary person doing an ordinary thing, not a brilliant hacker. Five habits close the ordinary doors:
- Passwords & MFA - one account, one password, never reused (leaked lists are the first thing attackers try); use the approved password manager. MFA (multi-factor authentication) proves identity with a second factor - enable it everywhere, and if a prompt appears when I didn’t just log in, someone has my password: decline and report. Never share credentials in any direction; no real IT department asks for my password.
- Phishing - a message impersonating someone I trust to get credentials, a malicious click, or a payment. It targets me, not the firewall, because one click out of 500 succeeds. Defence is a habit, not cleverness: slow down on anything that wants something from me, and verify through a second channel.
- Least privilege - everyone gets exactly the access their job needs and no more. It protects me too: access I don’t have is access nobody can misuse through my account. Request access with a reason; let unused access be removed without taking it personally.
- Physical security - lock my screen every time I stand up (muscle memory), keep a clean desk (no printed confidential material, no written passwords), and never allow tailgating - following someone through a badge door without badging. Politeness is exactly what makes it work, which is why controlled doors are the one place I don’t hold the door.
- Shadow IT - any tool used for work without approval (the free converter, a browser extension, a personal cloud drive). The problem isn’t that they’re bad software - it’s that nobody checked where they send data or whether they meet the company’s legal duties. Request tools, don’t smuggle them.
GDPR in daily work
Section titled “GDPR in daily work”The GDPR (General Data Protection Regulation) is the EU’s data-protection law. Personal data is any information relating to an identifiable person - and the definition is wide: names and addresses, but also email addresses, user IDs, IP addresses, location, combinations (“the female team lead in the Nuremberg office” can identify someone with no name), and specially protected categories (health, beliefs, union membership). In enterprise systems I swim in it - customer records, employee data, supplier contacts - so recognizing it is the skill.
My working share is three habits: collect less (test with anonymized or dedicated test data, don’t hoard exports “just in case”), share carefully (data moves only to people and systems entitled to it - a customer list pasted into an unapproved tool is a data-protection incident, not a shortcut), and delete when told (retention deadlines and erasure requests are legal obligations, not housekeeping - including the copies in my downloads).
The AI rules from earlier - no real names, no client specifics, no personal data into unapproved AI tools - were the GDPR in miniature: those tools were unapproved processors and the data was other people’s. Approved tools have a data processing agreement binding the vendor to protect the data; arbitrary tools don’t. That’s why tool approval is a legal process, not a taste question.
Acceptable use & software licensing
Section titled “Acceptable use & software licensing”An AUP (acceptable use policy) states what I may and may not do with company IT - devices, accounts, network, email. Usual contents: work systems are for work; no circumventing security controls; conduct rules for communication; and monitoring disclosures (what the org logs, in Germany shaped by data-protection law and often negotiated with the works council). Read mine once, properly, when I join - it’s the written answer to most “am I allowed to…” questions.
Licensing is the second trap for well-meaning people: many tools are free for personal use only, with the license explicitly requiring payment for commercial use - the freeware editor, the diagram tool, the font I downloaded. Enterprises are audited for exactly this; vendors actively check large orgs. The habit is the same two words the whole section keeps producing: request, don’t smuggle.
5 · Delivery & Roles
Section titled “5 · Delivery & Roles”The enterprise project lifecycle
Section titled “The enterprise project lifecycle”Enterprise IT work mostly happens in projects, and projects have a stable arc (names vary by company and method):
This is not a return to rigid waterfall: the arc sets the destinations (commitments, budgets, go-live dates the whole org plans around) while agile practice organizes the daily work inside it - build and test run in sprints, stand-ups synchronize, backlogs order, retros improve. I work in both at once. And a deliverable - a defined piece of work the project commits to hand over - prominently includes documents: the design doc stakeholders approve, the test results that prove readiness, the handover guide the permanent team runs the system with for years. In enterprise projects, documentation is a product with my name on it, not an afterthought.
Consultant vs developer
Section titled “Consultant vs developer”| SAP implementation consultant | Enterprise developer | |
|---|---|---|
| Core work | Configures the standard system to fit the business; runs workshops | Writes custom code (ABAP) that extends the system |
| Signature activity | Fit-to-standard workshops - walk the client through standard processes, record what fits and what needs adapting | Works inside legacy code - read before writing, change the minimum, test around it |
| Essence | Translator between business language and system reality - the translation is the product | A communicator who codes - not a coder excused from communication |
| Around go-live | Cutover support, end-user training, hypercare | Moves changes through the landscape under change management |
| Works with | Client experts, testers, project lead | Consultants/analysts, testers, operations, other developers |
First 30 days - running onboarding deliberately
Section titled “First 30 days - running onboarding deliberately”Onboarding is the org’s process for making me functional (accounts, hardware, policies to sign, trainings, introductions). I run it actively - the person fully functional in week two, because they chased their own onboarding, has quietly given the team its first evidence of reliability. And I spend the temporary new-joiner advantage deliberately: for a few weeks I can ask anything and it costs nothing (“why is it done this way?”, “what does this abbreviation mean?”) - I’ll never learn this cheaply again. The org chart isn’t the whole map, so I find the unwritten rules by observing respected colleagues, asking about norms (“is it usual to message people after five?”), and mirroring before I customize.
- Week 1 - arrive. Chase onboarding, get tools working, set up the task board day one, actually read the policies. Meet my immediate team; write down every name, role, and system.
- Week 2 - map. Sketch the departments, the stakeholders around my team, and my own chain two levels up. First one-to-one with my lead: what does good look like in 90 days?
- Week 3 - contribute. Take small, completable work and deliver it with full professionalism - on time, documented, board current. Small and reliable beats large and late for a first impression.
- Week 4 - reflect. Review notes and board: what surprised me, which unwritten rules I found, what I’ll do more of. Share a short summary with my lead - manage-upward, applied to myself.
Revision summary
Section titled “Revision summary”| Must-know | One-line recall |
|---|---|
| Enterprise | Large, established: size + complexity + regulation + longevity |
| Enterprise slowness | The cost of coordination, risk control, accountability - not laziness |
| Org map | Departments · hierarchy (know 2 levels up) · matrix · stakeholders |
| Where SAP lives | IT → business applications; configuring the app layer’s business rules |
| Why ERP/SAP | One shared truth: scale, integration, compliance |
| Channels | Email=record, chat=quick, meeting=real-time, ticket=work, doc=lasting |
| Async default | Protect synchronous time; chat stuck after 3 rounds → call, then log it |
| Email shape | Subject with topic+date; context · request · deadline · next step |
| To / CC / BCC | Act / know / hidden (BCC almost always wrong in a conversation) |
| Meetings | No agenda no meeting; notes = decisions + actions + open points |
| Action item | Owner (one person) · action · deadline - repeat it back |
| Hybrid | Protect overlap, write handoffs, keep status honest, overcommunicate slightly |
| Escalate | The situation not the person; show the trail; state+cause+recommended option |
| Professionalism | Reliability · accountability · punctuality - visible, not suits |
| Own a mistake | Name it, who’s affected, fix + timing, close the loop |
| German workplace | du/Sie (start formal) · punctuality=respect · 8h/30min/11h · honest time-tracking |
| Feedback | Receive: listen·clarify·decide·thank. Give: specific·behavioral·kind |
| Confidential | Job-acquired info is secret unless explicitly public; NDAs outlive the job |
| Manage my work | Urgent≠important; professional no = capacity+alternative+escalate |
| Compliance | Laws+contracts+standards, divided into everyone’s daily share |
| Security habits | Unique passwords+MFA · verify phishing 2nd channel · least privilege · lock screen · request don’t smuggle |
| GDPR share | Collect less · share carefully · delete when told; breach → report fast (72h) |
| AUP & licensing | Read the AUP on joining; free-for-personal ≠ free-for-company |
| Project lifecycle | Discovery→Design→Build→Test→Deploy→Support; go-live·cutover·hypercare |
| Arc vs agile | Phases carry commitments; sprints organize the work inside them |
| Consultant vs dev | Configure & translate vs custom code in legacy; both communicate |
| System landscape | Dev → test → production; change management is the controlled movement |
| First 30 days | Chase onboarding, spend the new-joiner advantage, find unwritten rules |