From Customer Org. Chart to SAP Org. Structure

[islam_saleh]

Hello SAP Gurus,
While diving deep into the world of SAP ERP for over 10 years, I wanted to share some of my findings and experience on a topic that can be a challenge for many of us: How to Design the Customer’s Organization Hierarchy into SAP Enterprise Structure.

It's great to deploy what the SAP best practice says, but from the customer perspective it’s very sensitive step as it’s reflecting the overall business decisions. I recognized this during my career in implementing SAP projects, and I hope my findings can help you out there for whom might be starting on a similar journey.

Bridging the Gap Between Customer's Org. Chart and SAP Enterprise Structure

We all have our company's organizational chart hanging somewhere in the office or in a PowerPoint file. It shows the customer's department hierarchy, who reports to whom, and how teams are structured.

But how do we take that familiar hierarchy and map it to SAP's world of Company Codes, Plants, and Purchasing Organizations? It's not always a one-to-one match, and that's where the complexity (and honestly, the fun!) begins.

I found an example of this in old SAP Community question from 2008. A community user laid out a detailed case study of a company with 4 factories, 3 regional distribution centers, 15 sales offices, in addition of an R&D team and project management team. It was a fantastic real world scenario that highlighted the tough question we often face.

"since material from Plant and RDC is being transferred to Branches and from there it is distributed to customers therefore the valuation of FG at BRANCH and RDC should be different as transportation cost, packing, unpacking etc cost should get added at Branch level. Therefore in case I make branch as Storage location, I will miss the valuation part while if I make them as Plant then there will be lot of documents get generated for each movement."

This is exactly the kind of practical dilemma that gets to the heart of enterprise structure design. It's a constant balancing act between financial accuracy and operational efficiency.

Understanding The SAP Organizational Units

Before we define and assign the SAP enterprise structure, we need to know exactly what of each SAP org. unit represents. It’s helpful to think of them in a hierarchical way, starting from the top.

1. Client: the highest level in the SAP system hierarchy. Specifications that you make, or data that you enter at this level are valid for all company codes and for all other organizational structures. You therefore only need to make these specifications, or enter this data once. This ensures that the data is consistent.
2. Company Codes: is the central organizational unit of external accounting within the SAP System. You must define at least one company code before implementing the Financial Accounting component. The business transactions relevant for Financial Accounting are entered, saved, and evaluated at company code level.
3. Plant: organizational unit serving to subdivide an enterprise according to production, procurement, maintenance, and materials planning aspects. It is a place where either materials are produced or goods and services provided.
4. Purchasing Organizations and Purchasing Groups: An organizational unit subdividing an enterprise according to the requirements of Purchasing. It procures materials and services, negotiates conditions of purchase with vendors, and is responsible for such transactions. A purchasing group is a key for a buyer or group of buyers in SAP ERP. It is responsible for the procurement of a material or class of materials, and is the principal channel for a company's dealings with its suppliers.

Organizational Unit	Key Characteristics	Typical Use Cases
Client	Highest level, represents entire corporate group	One per SAP system
Company Code	Legal entity with independent financial statements	Subsidiaries, country operations
Plant	Operational unit where business activities occur	Factories, warehouses, sales offices
Storage Location	Physical storage area within a Plant	Warehouse sections, storage areas
Purchasing Org	Defines procurement scope and authority	Centralized or decentralized procurement
Purchasing Group	Actual procurement team or buyer	Commodity teams, regional buyers

A Visual Approach to Mapping

I'm a visual learner, so diagrams really help me solidify these concepts. I've created a couple of diagrams to illustrate how a typical departmental structure might map to SAP organizational units, and how those units relate to each other.
Here's a conceptual mapping from real-world departments to SAP units:

And here's a more detailed example of what a complete SAP organizational hierarchy might looks like, incorporating multiple company codes, plants, and purchasing organizations:

My Key Takeaways and Learned Lessons

After implementing a lot of SAP projects, here are some advices I have heard from my leaders:

Start with the "Why," Not the "What." Don't just create organizational units because they exist in your company. Think about your business processes and reporting requirements first. What do the customer need to see in his financial reports? How he manage his inventory? How do he want to analyze his procurement activities and expenses? The answers to these questions should guide you WHAT is the correct design decisions.

1. The Plant is probably the most versatile org. unit in SAP. I've seen Plants used to represent everything from manufacturing facilities to service centers. Don't be afraid to think creatively about how to use Plants to model your business operations. Just remember that each Plant needs to be assigned to a Company Code, so plan accordingly. And remember that SAP defines the plant as a logistics organizational element that is used by all the logistics modules. The plant is assigned to a company code that may have many plants assigned to it. A plant is typically configured in conjunction with the company code and valuation area due to tax rules and regulations.
   Depending on the role the plant has in the organization, a plant can be defined for the following purposes:
   • In Sales and Distribution (SD), a location from which finished goods and materials are stored and distributed.
   • A location from which services are rendered.
   • Materials Management (MM), a location where material flow is managed and stock requirements are managed from both the inbound and outbound perspectives.
   • A location where material stock is consumed, planned, and purchased.
   • A manufacturing facility where materials are produced, as in Production Planning (PP).
2. Purchasing org. structure has a huge impact on your procurement processes, approval workflows, and reporting. I learned that the hard way when we had to redesign our purchasing structure because we hadn't thought through the implications properly. Take time to understand whether a centralized or decentralized org. unit makes the most sense for your company.
3. Plan for Growth and Change, Your first design probably won't be perfect, and your business will expand over time. Build flexibility into your design where possible, and don't be afraid to iterate, I've seen too many implementations get stuck because they tried to create the "perfect" structure from day one instead of starting with something good and improving it over time.
4. Document Your Decisions, This might seem obvious, but document not just what you designed, but why you designed it. think in future questions, when someone ask why the regional sales offices are defined as plants instead of storage locations, you'll be glad that you wrote your reasoning.

Important Considerations

in past implementations i've encountered some comments from the customer that might help you think through your own design:

1. Multi-Country Operations: If the customer operates in multiple countries, you'll likely need separate company codes for each country due to legal and tax requirements, but you might be able to share plants across company codes for operational efficiency.
2. Shared Transactions: If the customer has shared service centers (like a centralized IT department or shared warehouse), think carefully about how to define and assign these on SAP, sometimes they're best represented as separate org. units, sometimes as cost centers within existing org. units.
3. Acquisitions and Divestitures: If the company invest in other legal entities by frequently acquires or divests business units, design the SAP structure to make these transitions easier, this might mean keeping acquired companies as separate company codes initially, even if the customer plan to integrate them later.

Summery

SAP Enterprise Structure design is a piece of art, a part of business administration science, and a part of overall company growth.
There's no one "correct" way to do it, but there are definitely wrong ways, the key here is to understand customer business requirements, think through the implications of your design, and be prepared to adapt as you may learn later.

I hope my thoughts and findings has been helpful for you, and I'm always learning new things about SAP organizational structures, so I'd love to hear your thoughts and experiences.

• What challenges have you faced when mapping customer's organization in SAP?
• What advice would you give to SAP community members or for a someone has just starting out?
• Have you encountered any particularly creative or unusual organizational structure designs?

SAP ERP SAP S/4HANA

[ahmad_algameel23]

Thank you Islam, this blog is very insightful.