Interesting conversation.
We haven't reached the point where we have a formal document on branches/locations/subsidiaries/corporate hierarchies, but here are some points about the current state of our thinking. Although these thoughts primarily focus on subsidiaries and mergers and acquisitions, it does touch on when we create separate database records.
- In general, we don't create a new record for a subsidiary or branch unless the Smithsonian or one of its units has some formal relationship with the subsidiary or branch distinct from our relationship with the larger entity. Although there are exceptions, we also try not to create a new record unless the new entity is also a separate legal entity from the parent (so, perhaps, a separately-operated/separately-incorporated subsidiary or a corporate foundation, but not generally a branch office or location). Otherwise, we use one entity with multiple postal addresses for different locations/branches.
- We have relatively recently created Org Relation Type codes for "Merged/Acquired" and "Spinoff" to use (as you might suspect) in the case of mergers and acquisitions and spinoffs.
- In the case of mergers and acquisitions, we do not merge the entity records, but mark them inactive as appropriate and put them into a hierarchy. Most especially, where there have been gifts from an entity, we preserve those gifts on the entity record for the entity that was the legal donor at the time of the gift.
- It's something of a judgment call, but, in the case of acquisitions where one former entity is understood to be continuing (even if under a new name) and the other entity is understood to be absorbed by the continuing entity, we inactivate the entity that is not continuing and link it to the continuing entity using a org relationship code of "Merged/Acquired".
- In cases that are understood to be a "merger of equals," we generally create a new record for the new entity, inactivate the existing/former entities, and link the existing/former entities with an org relationship code of "Merged/Acquired".
- In the case of mergers of either sort, we leave the legacy data (addresses, employees, org contacts, etc.) on the existing record, for historical purposes, generally inactivating the data items. Information is selectively added to the new parent record as it applies (is the person an employee of the new parent, or an org contact for the new parent, is the address a valid address for the new parent, etc.). Any active prospect records related to the merged/acquired entities are reviewed and addressed accordingly (inactivated if the prospect and proposals are no longer viable, switched to the new parent entity if the prospect and proposals are continuing with the new parent, etc.).
- Similarly, in the case of spinoffs, data on the record of the former integrated parent that applies to contacts, employees, locations, etc. that are no moved to the spinoff are left in place but inactivated on the record of the parent and selectively added to the new record of the spinoff. (If the spinoff was already a subsidiary with a separate record, generally only the org relationship code needs to be updated.)
I'm sure that there is more, but that's what is top-of-mind at the moment!
My US$0.02 worth; the usual disclaimers apply.
Good luck!
Alan
Alan S. Hejnal
Data Quality Manager
Smithsonian Institution - Office of Advancement
600 Maryland Ave SW Ste 600E
PO Box 37012, MRC 527
Washington, DC 20013-7012
Voice: 202-633-8754 | Email: HejnalA@si.edu
------Original Message------
Hi Claudia,
In the scenario that you describe, I think having a hierarchy of the main parent record and all the child records pertaining to individual branch locations is the right approach, and therefore you are correct in your approach here. However, I see why this can get confusing to the users. In my opinion, the solution is to clearly document this scenario (which is what John suggested, but I want to go a bit into detail).
This documentation should be both in the system design documents, as well as Standard Operating Procedures. If necessary, hold a training session for your stakeholders who commonly work with this data entry, update and reports, and create a training process for new team members (if this is a frequent phenomenon).
Also, if your current policies support this, then you could consider naming those individual records differently, for those who are less detail-oriented. For example, try to incorporate the branch name in the main record name. For example, instead of having 5 records of XYZ Bank, you can have records that read as "XYZ Bank Moore Park" and "XYZ Bank Forest Greens" etc. That may help reduce the confusion. However, this is not an alternative to clear documenting.
Hope this helps!
------------------------------
Medha Nanal
Principal/CEO
Top Cloud Consulting
medhananal@topcloudconsult.com------------------------------