Skip to main content
Solved

Organization - model aligned to our org structure

  • October 7, 2025
  • 4 replies
  • 246 views

New LeanIX user - we are just starting the onboarding process and already have some foundational questions that we want to get ahead of. One of these is how to setup the Organization model to best meet our needs. I looked through the Community posts and didn’t see exactly what I am looking for.

Our org structure is fairly simple compared to very large, geographically dispersed organizations.

  • One geographic location (City) with many physical building sites
  • Core org units are Division/Department/Branch (Ex. Corporate Services/Technology/IT Operations, City Operations/Transit/Transit Maintenance, etc)
  • Often have organizational structure changes where Division, Department, or Branch is renamed, merged together, split apart, new org-units created

I don’t think we currently have a need to track anything at the location level (although that may change in the future). We would like to track, analyze, report on applications, business capabilities, owners, users etc. down to the Branch level.

What is the best way to achieve this in the Organization model using the defined subtypes as there only seems to be 2 types to correlate to our 3 required levels?

  • Business Unit = Division ?
  • Team = Department ?
  • ??? = Branch

Looking for any insight into the best way to setup the Organization model, tricks, gotchas etc?  Thank you!

Best answer by Mohamad Alsughiar

Hello!

While you can rename and add sub-types in LeanIX to fit your scope. My impression is that the best way to use sub-types is to capture parallel structures instead of hierarchies, as it benefits you to filter on a certain structure in reports to only show landscape split based on different e.g. regions or business units. In your case, If you don’t need to explicitly capture the name of each level, you can capture the 3 level hierarchy within business unit sub-type.

 

Team is typically used for engineering team ownership of applications (in case they are self-built). If relevant, you can later use ‘’team’’ sub-type to capture cross-organizational team ownership across departments or divisions and have the ability to switch between horizontal and vertical view of your organizational structure.

I hope that helps.

4 replies

Forum|alt.badge.img
  • Royalty For Loyalty
  • October 8, 2025

You can add subtypes and change the values of the current subtypes. Set them to whatever makes sense to your organization. This is under the configuration for organization. 


Mohamad Alsughiar
SAP Team
Forum|alt.badge.img+1

Hello!

While you can rename and add sub-types in LeanIX to fit your scope. My impression is that the best way to use sub-types is to capture parallel structures instead of hierarchies, as it benefits you to filter on a certain structure in reports to only show landscape split based on different e.g. regions or business units. In your case, If you don’t need to explicitly capture the name of each level, you can capture the 3 level hierarchy within business unit sub-type.

 

Team is typically used for engineering team ownership of applications (in case they are self-built). If relevant, you can later use ‘’team’’ sub-type to capture cross-organizational team ownership across departments or divisions and have the ability to switch between horizontal and vertical view of your organizational structure.

I hope that helps.


Jochen
Forum|alt.badge.img
  • Royalty For Loyalty
  • October 9, 2025

Hi!

Perhaps some ideas on how we approached this topic:

We took our organization into consideration, but didn’t map it 1:1 in LeanIX. The main question is, what you want to achieve with the organizational object in LeanIX and what you want to show in LeanIX. For us, mapping the organizational structure 1:1 did not bring any benefit and would be hard to maintain over time.

What we found out what brings value for us:

  • Maintain our regional subsidiaries (“Region” subtype), because they are legal entities, that might use applications exclusively and we want to show the local specifics). You don’t seem to have this, but if the physical sites are something relevant to work with in LeanIX, this could be an approach
  • Subtype “Business Unit” Level 1 we use for divisions, but we flatten the structure. For example: Our Procurement reports to Production for historical reasons. But in LeanIX we keep Production and Procurement both on Level 1, because it’s different topics and showing the nested, historical structure is no benefit. On a EA-level we talk about production, procurement or both, but it doesn’t matter which department reports to where
  • Subtype “Team” we also flatten structures and use team names (abbreviations) and link them to the parent of “Business Unit”. The teams we utilize to show ownership in the business for certain applications & IT-components. It’s just this use case to identify someone to approach in case of questions or operational issues

Since you mentioned business capabilities: We aligned the “Business Unit” Level 1 with the Business Capabilities Level 1. This is why we didn’t mimic our organization setup 1:1, which would bring no benefit. It’s more about disciplines in the company and what we do. Not so much how we implemented it. Regarding the example above: Procurement is a Level 1 Business Capability together with “Business Unit” Procurement Level 1 and Production links to Supply Chain Manufacturing also on Level 1.

With the Data Objects we did the same (Procurement data level 1, Production data level 1). Therefore we have comparable structures on Level 1 for the different artifacts. This is it’s easier to understand and easier to maintain.

Our target was to simplify things in LeanIX and keep the focus on what we do, which also makes it then easier comparable with other companies.

So yes, no concrete answer to your questions, but some insights on how we tackled the topic (in the end, everyone has the same questions I guess)


Carsten
Forum|alt.badge.img+1
  • Everlasting Love
  • October 10, 2025

Hello ​@bclarke ,

we use user groups just for our Affiliate companies/branch/plants, major customers, suppliers and partners (e.g. where EDI implemented). For department level, we use (historically) 1st level business capabilities (department field). Since you are able to edit the metamodel, I’d go for create an additional relation user group to application called department. Anyway keep it as simple as possible, because administration of data sometimes develops exponential if you become too detailed.

Best regards,

Carsten