View multiple Root OrgUnits in single OrgChart.

[Former Member]

Dear Nakisa Experts,

We are planning to implement NAKISA OrgChart 4.0 SP1, my client SAP HCM system have different company codes and different root Organizational units

(Ex: OrgUnit 1, OrgUnit 2, OrgUnit3, OrgUnit4 and OrgUnit5), Root OrgUnits are not reports to each other (Different Company codes). When I configure Nakisa OrgChart, I can give One Root OrgUnit only in AdminConsole but client wants to see all root OrgUnit(Ex: OrgUnit 1, OrgUnit 2, OrgUnit3, OrgUnit4 and OrgUnit5) OrgCharts using only one OrgChart AdminConsol and one user OrgChart Application.

My Queastions are:

1. Can we enter more than one root OrgUnits in AdminConsole?

2. Is there any posibility, client can see all Org Stuctures of different company codes.

3. How can I achive or resolve this issue?

Thanks in advance for your great support and ideas.

Best Regards,

Sekhar.

[StephenMillard · Accepted solution]

It's one root ID per hierarchy, so you could create multiple hierarchies and start them at different roots.  The user could then select which hierarchy they want to visualise.

Or, you could start the user at their own org unit and let them navigate up to their own root as normal.  They could then search using a listing to find the other root (which could be "bookmarked" as a saved hierarchy).  Or you could combine this with the multiple hierarchies option above.

Or, you could add a new "dummy" org unit under which to put the other two roots and visualise from there, but the wider implications of this would obviously need to be considered first.

If you're using a live architecture you could also apply structural auths to limit movement between hierarchies if required.  If you happen to be using a staged or hybrid architecture then you also need to consider how to handle the data extract ... multiple roots mean a bit of customisation here as by default the extract runs based off of one root.

We have a client who has a single OrgChart instance visualising three companies in OrgChart who is presenting on this (and OrgAudit) at the upcoming SAP UK&I user group conference (2013) if you wanted to hear first hand how the multi-company visualisation works for them from a user perspective (and you happen to be attending the conference).

Regards,

Stephen.

[Former Member · Accepted solution]

Hi Stephen,

Thank you so much for providing the solutions to meet my requirement, I have few more questions regarding the same.

--> we are planning to create multiple hierarchies for different roots, my questions regarding this solution

1) Is there any standard Hierarchies & Detail Designer template to copy, rename and do the configurations as it is like standard hierarchy?

2) If I create multiple Hierarchies, do I need to create multiple listings for searching OrgUnit, Positions and Employees?

3) If I create multiple Hierarchies, I should create A741 relationship between OrgUnits and Position (Eg: OrgUnit1, OrgUnit2, OrgUnit3 A741 to Position)if that position managing 3 OrgUnits?

4) Some of the positions managing only One OrgUnit, some of the position managing more than one OrgUnits so what are the authorizations should I assign to that person?

5) In this requirement, what are the roles should I assign to user to access Nakisa OrgChart and Particular Hierarchies only.

Best Regards,

Sekhar.

[StephenMillard · Accepted solution]

1) If I were going down the multiple hierarchy route I would look at duplicating the existing hierarchies for everything but name and root ID.  In terms of details panels I would re-use the existing ones unless there was a specific requirement not to.

2) Listings are not tied to a hierarchy and so I would not opt to duplicate them.

3) The hierarchies you create if based on the existing hierarchies would use the same relationships.  There should be no need to change relationships or create new ones purely on the basis of new hierarchies.

4) There are a full list of authorizations in the admin guide for using each Nakisa application.  If you mean structural auths then I would suggest discussing your requirement for who can see what with your security team.  Chances are that they are already in place as otherwise users would be able to freely access the data in SAP GUI.  Nakisa simply leverages any existing structural auths.

5) You need to determine roles based on your requirements - i.e. what groups of users are there and what do they need to access.  If you wish to restrict access to hierarchies then you would probably be looking at duplicating existing roles and amending the security permissions accordingly in each case.  One thing it is worth considering is what hierarchy will be set as the default?  I'm not sure what would happen if the default hierarchy was one that was inaccessible to a particular role ... I've never tried it.

Hope that helps.

Regards,

Stephen.

[StephenBurr · Accepted solution]

Thongjerm,

This is a key decision in your solution design ... do you use SAP's struc auths or Nakisa's role security?

If you use struc auths then you can have 1 hierarchy and 1 set of listings, etc.  Struc auths will control the range of data that each user can see.

If you don't ... then you need to have separate hierarchies and separate listings.  Then control access to each item using Nakisa's roles.  This might result in a large number of roles which can become cumbersome.  This is certainly the route of most effort and while it can be done in the AdminConsole, then a well experienced consultant would probably duplicate a few XML files to more quickly replicate an existing hierarchy.

Either way, 741 relationships (AoR) are not used in OrgChart and won't (unless you bespoke) control access to the range of data you are visualising.

Stephen B

[Former Member · Accepted solution]

Hi Stephen,

1) I would like to duplicate the existing hierarchies for everything, and there is no specific requirement so I would like to re-use the existing details panel.

Could you please tell me how I can copy the existing Hierarchies and Details Panel in my project?

Best Regards,

Sekhar.

[Former Member · Accepted solution]

Hi Stehen Burr,

Thank you so much for your grateful guidance

I would like to duplicate the existing hierarchies for everything, and there is no specific requirement so I should know xml to replicate an existing Hierarchies and details panel.

Generally as per the field mapping checklist, we just maintained the below relationships in SAP HCM, apart from those what are the other relationships should I maintain in SAP system.

S to O	A012
O to O	A002
S to O	A003
S to P	A008

Best Regards,

Sekhar.

[StephenMillard · Accepted solution]

As Stephen suggests below, one method might be to engage someone who understands the XML architecture underlying the configuration and have them amend that to match the requirement.

The alternative is simply be to review the configuration of an existing hierarchy in AdminConsole and then recreate it in AdminConsole via the option to create a new hierarchy (see the Custom Org Charts section in the Admin Guide).