How many companies have multiple orgs within Windchill on the same system

[lhughes]

We are currently exploring the positives and negatives of having two organizations within the same system to determine if it may or may not allow the flexibility our different divisions need for change management processes.

The questions I hope to have answered are;

1. Does your company have multiple organizations of Windchill.
2. If so, are these Organizations on the same system or separate instances (separate hardware) and why?
3. If you have multiple organizations on the same hardware, do you share CAD data between the organizations?
4. Have you been able to control what the org level admins are able to do/not do?
(i.e.: turn of principle administrator at the org level)
5. If they are on the same instance of Windchill (same hardware) what has been your experience with multiple organizations.

Thank you in advance for your insight!

[MikeLockwood]

Key things to understand are what configurations are shared and which are separate for multiple organizations.

1. Does your company have multiple organizations of Windchill. Not yet but we may at a future time and have thought about it.

2. If so, are these Organizations on the same system or separate instances (separate hardware) and why? Don't think that hardware can even a consideration for where Windchill "is." Definitely you can control where files are vaulted though, if needed. This should not be a consideration except for physical location, and only if replication is used.

3. If you have multiple organizations on the same hardware, do you share CAD data between the organizations? Sharing CAD data should have nothing to do with hardware; it's all about access control (user permissions).

4. Have you been able to control what the org level admins are able to do/not do? (i.e.: turn of principle administrator at the org level). If users are created in each Organization (rather than at Site Level), then each Org should be able to manage their own user accounts I'm pretty sure.

5. If they are on the same instance of Windchill (same hardware) what has been your experience with multiple organizations. N/A.

[ddemay]

By multiple organizations on different hardware, are you trying to explain a
scenario when for some business reason, you install Windchill, create the
default organization during install and then later repeated that process on
separate hardware. Time passes on, and you federate the systems to talk to
one another?



The current system I am architecting will use multiple organizations.
Organizations are treated as a group in the background, so there are several
advantages to using multiple organizations on new 9.1 systems. Upgraded
system offer less of an advantage except for access control and even that
can be a stretch.



Profiles in 9.1 can keep Organization Administrators from doing many things.
However, proper leveraging of roles on a shared team can provide a data
administrator whom is separate from someone with orgadmin powers. You also
have the creator roles for the three context types.



There is a lot of misnomers about multiple organizations out there. Some of
that has to do with the original software design by PTC. However, now that
PTC has improved the underlying architecture, much more is possible. For
example you can have organizations that are holders of product and libraries
whilst others are not.



I am creating Finance, Marketing, and Manufacturing organizations for
internal users who are outside Engineering but need read access to
Engineering data as an example. When adding users to the system in principal
administrator, you select the correct Organization for them and
instantaneously they have implicit access to many different things. (If
configured in such a manner.)



For change management purposes, using soft types for change objects and
groups to define who can create what type of soft typed change object is
enough to allow for different change management processes. Organizations
are not needed to solve that problem.



CAD data can be accessible to principals of both organizations. However, if
you add a member of another organization to a context of another
organization, even via the implicit teamMembers role, they are still not
able to create or modify data in the other organization. You have to create
additional ACL's for them.





David DeMay

[#4]

Make sure that you know and understand the difference between an Org created
on the Organization tab and an org created through the Principal Admin.
They are not the same things.



When created on the Org tab, they have all the capabilities and containers
etc. When created in the principal admin they are simply a domain and group
for principals that can be used in the ACLs.



~Dan

Dan Harlan

602.320.4187

[patrick.chin1]

To answer your questions:

• Does your company have multiple organizations of Windchill

The past companies, yes. It was configured with multiple organizations IDs with Supplier Management (SUMA). For OEMs, we would create an Organization and Project Context so that they could check in their work which belonged to them. We could then tie their CAD OEM data to manufacturer parts with MPMLink. Thus, it would avoid confusion. The OEM would not have access to other internal CAD models. Thus, they can use their own file names (it might be identical like prt001.prt) and not conflict with yours.

OOTB, the Projects in one organization behave like multiple orgs. I have a fix for that. Eventually, you will get the odd duplication error and have issues fixing and checking inif it is released.

The company I'm in currently no, but we have immediate plans to.

• These Organizations on the same system or separate instances (separate hardware) and why?

We currently have one website where all outsourced design OD, outsourced engineering manufacturers (OEMs), suppliers and vendors use. Also for maintainability, we have one system this way we don't have to worry about ferderated. Our single system is working well with 70 concurrent ProE users with absolutely no load 5% average. We are planning to add an additional 1000 Non, CAD users.

It also depends on control of the partnumbering and publishing to the ERP system. It is harder for the PLM system to be the source and take control of the number generation if there are multiple systems feeding the ERP. It avoids collision or more complicated controls when feeding the single ERP system. If it is one ERP system, it should only be one internal organization with many external organizations. Thus, number generation is specifically for internal.

• Share CAD data between the organizations

Yes, you make not decide to call up your internal generic model but a specific OEM part with their part number. Thus, you CAD assembly has to be able to search and find that external CAD assembly

• Have you been able to control what the org level admins are able to do/not do

Because it is inone system, we have a site level admin who are the same at the org level. Thus, most of the ACLs arecoming from a standard controled methodology.

• If they are on the same instance of Windchill (same hardware) what has been your experience with multiple organizations.

See above

Good Luck.

[patrick.chin1]

Lee, Nice background in your picture. Definely have to go there.

[jcrowe]

Hey Lee,

Before you take this route of multiple organizations, ensure that it makes sense for your business needs. It sounds like a PTC businessconsultant could be very beneficial to your future efforts. I'm referring to someone who can listen to your business needs/processand give you the best solution to address them, not someone whocan only functionally implement your business need.

Multiple orgs aren't for everyone no matter how good the idea sounds. You definitely needto have a very tight handle on how this org structure works (specifically the long term effects of taking this route).

[DanielReid]

Old topic -- I was on "vacation" status for a while and probably missed
more in this discussion.

Has anyone noticed that if you use the initial organization in
Windchill, it has different access rules for org admins than if you add
another organization and use it? It is hidden in the customization
guide documentation somewhere. Basically, there are certain types of
access that are available to org admins within any additional
organization you create but are not available to org admins in the
default or initial install organization. You need to give site admin
level access to get this access, which of course adds a whole lot more
than might be desired. This also means if you use the initial org as
one of your multiple orgs, you will have to give "org admins" within
that org "site admin" access to do what the other org admins can do
within their orgs.

We built off of the initial organization (named it as we wanted during
install) and now are stuck with providing more site admin level access
than we want. We are hoping that we'll be able to build up WC10 with an
additional new Org and transfer our currently used org into that instead
of into the default again, somehow.

So, there's a recommendation if you have not deployed yet. Get PTC to
review the pros and cons of using the default org vs. a new org (perhaps
leave the default org empty or as a test space).