One of the big tasks ahead in the Next Generation project is redefining all the ways in which a constituent relates to other constituents. Today we call this Associations and we know that it doesn’t begin to cover all the bases. So just as we have in the past, we need you to help us out with your thoughts on any or all of the following questions:
1. What are the ways that constituents relate to one another, particularly ways that aren't so easy to track in Tessitura today? 2. What are some scenarios that describe ways that your business needs to communicate with different segments of related constituents? (A simple example: “Sometimes I need to send a mailing out with only one piece per household. But if I’m doing the same promotion in an email I need to send it to all the members of the household.”)3. One of the things we struggled with in designing Tessitura the first time was the whole name1/name2 construct. Is there a reason to treat spousal relationships differently than any other type of family/household relationship? 4. What other questions need to be asked about this topic?
Cool! From the Chicago Summit discussion and this thread great design needs begin to emerge! Of course I would fully expect that Chuck and his design team already have some models in mind. However, it's completely appropriate to see what the membership thinks. So, some of these comments are just recapping or restating some of the other comments we've read so far.
I fell that the answers to Chucks original questions show that we don't want to build in any constraints that are not technically required.
Imagine that we move to a different environment where every entity gets its own record. If its a person, they get a record. A foundation gets a record. A school gets a record. Even a group can get a record.
Each of these entity records could be typed so we know what kind of entity it is. We would need to establish what the minimum base amount of data is that would be required to create one of these records. For example, we'd have to decide if we can create an entity record for a person with only a first or last name. If so, we'd have to come up with other identifiers to make this record unique.
Uniqueness would be a key concept for entity records. Every entity record would have to be unique with no duplicates allowed.
Transactions could be tied to an entity. However, we may need to build in the ability to split the value of the transaction according to both predefined and perhaps on the fly rules. However it's done, we will probably need the ability to assign value and benefits to one or more entity based on relationship rules.
Relationships could become the connectors that tie entities together. If we follow these ties we could get pictures of entity groups that have different functions. Again, a rules engine would need to be used to build the views according to organizational standards.
For example, the term "household" has been mentioned many times in this thread. What is a household? What relationships determine which entities can be tied together into a household group? Are spouses automatically part of a household? What about married people who live separately? If there are child records tied through relationship to a parent record should we assume that they are in the same "household"?
Why are we even concerned with what a "household" is? Is this for marketing and communications purposes? Are there other ways to do that?
Imagine again that in this model we establish location records that could contain an address of a particular type such as a private residence. The location or address records could stand on their own and also be tied to an entity in a similar way that entities can be tied to one another.
When you're communicating with a direct mail piece who are you trying to reach? Are you trying to reach an individual entity or a group of entities that reside at the same location?
If you establish the relationships between these records (entities and locations) correctly, you should be able to create a communication that is targeted to one or more specific entities, but only delivers one copy to a specific location. The salutation could also be manipulated through similar rules.
It looks like I'm rambling now so I'll summarize...
The greatest flexibility may come from keeping data elements grouped together at the most granular level possible. Then building mechanisims that allow us to link these grains of information togeather.
Perhaps not technically feasible. But it could be interesting to follow the concept through some modeling.
Question for Chuck...
Is speculating about the constructs of an entity record relevant? Or should we be focusing exclusively on defining scenarios of usage?
I like many of the thoughts that are coming through, thanks everyone! I think Ken and Dan are proposing some grear thoughts that are very much aligned with what I've been thinking as we've dealt with varied business needs in several organzations. Let me throw out two extensions to what everyone has said for further comment and thoughts. 1. Relationships - what if these relationshis were flexible, and could join multiple entities to an actual grouping? For instace, several individuals could be related to a particular Family, and that family grouping would have an ID# of it's own and be treated as a 'first class object' in it's own right. 2. What if you could link both an individual entity (person or organization) AND a grouping to transactions or orders or payments, etc? With the thoughts already expressd y others, this would allow you to identify the individual person or organization AND the capacity in which they are acting (the 'grouping/relationship entity) to any action in the system. It would seem to address all of the issues/needs raised by everyone on this discussion. The relationships become primary objects, after all, this is a 'Customer Relationship' Management system! Alan
From: Chuck Reif <bounce-chuckreif3941@tessituranetwork.com> Sent: 10/16/2009 8:30:12 PM
1. What are the ways that constituents relate to one another, particularly ways that aren't so easy to track in Tessitura today? 2. What are some scenarios that describe ways that your business needs to communicate with different segments of related constituents? (A simple example: “Sometimes I need to send a mailing out with only one piece per household. But if I’m doing the same promotion in an email I need to send it to all the members of the household.”) 3. One of the things we struggled with in designing Tessitura the first time was the whole name1/name2 construct. Is there a reason to treat spousal relationships differently than any other type of family/household relationship? 4. What other questions need to be asked about this topic?
Alan,
Great point!
I was thinking of a situation where the grouping of relationships could be built on the fly. However, our rules may demonstrate that some relationship groupings would be commonly used, and could have attributes of their own. Thus the relationship becomes a record itself so that those attributes could be tracked and maintained.
Exactly!
From: Alan Levine <bounce-alanlevine7254@tessituranetwork.com> Sent: 10/20/2009 8:50:39 AM