Master Data Management (MDM)

From my experiences there are few methods of managing master data that need to be set up at least at the beginning of system implementation.
Even though master data is not transaction data that changes often (that’s why it is called as Master Data), it should be update-able by users. The update is required when the element is no longer required, there is new elements need to be inserted, or change element name. So the update can be:

1. Insert new element
2. Rename the existing element
3. Remove/delete the existing element

1. Insert new data (new element)
What we need?

– New element name
– Description for the new element name (if required)
– Attributes for the new element name (if required)
– Where it will be put? Under what parent? (it is related to hierarchy)

What we need to do?
a. Validation before inserting process
Check if the new name is exist in the list of elements
Check if the aliases name is exist or used by another element (in TM1 alias name     is unique)
Validate the attributes (if required)
b. After validation process
Insert new element
Update Attributes and aliases (if required)
Make sure to put the element under the correct hierarchy

2.  Rename the existing element

What we need?
Existing element Name to be renamed
What we need to do?
a. Validation before renaming process
Check if the new element name is exist
Check if there is data attached to that element
b. Moving data from the old name to the new name
If there is data attached to the old element, it has to be moved to the new element     first before removing the old element. Practically we should not remove/delete any     element from a dimension. Or to be save, we can put the ‘deleted’ data under        specific hierarchy where this hierarchy will not be read in any processes.

3. Delete the existing element
What we need?
Existing element Name to be deleted
What we need to do?

a. Validation before renaming process
Check if the element mentioned is exist
Check if there is data attached to that element
In TM1, data will be lost when element is removed, so we need to make sure there     is no data attached to that element.

b. Moving data from the old name to the new nam

There are some methods I ever worked on regarding this MDM:

1. Insert elements directly by loading data through data source outside TM1 but no need to     keep the data source. So the process will create and update dimension based on data       source loaded to TM1. The data source can be RDBS table or flat file.
2. Insert/update elements based on data on cube source. Cube source become data             source of dimension elements and the data source will be kept in TM1.
3. Using xdi Excel where dimension updated through xdi excel. The original data source         will not be kept in TM1.
4. Manual update: directly copy the list of element and manage the hierarchy manually
(not recommended)

What difference between MDM with data source inside TM1 or not?
If you keep MDM data source inside TM1, you can change data on that cube source. Users find the code that they want to change and do updating process. Here, users can see the complete data elements in one MDM dimension and the whole attributes. They have to choose which data element they are going to update and what thing they want to change. They can change multiple data elements since all element dimension is there. Flexible.
If you the data source is not inside TM1, users have to find the unique code in dimension and system have to provide the data related to that element code for users to be able to do changes. For me this method is more secure since system will only show one element data that requested by users, and users will do changes only to that element data. Less flexibility but more secure.
As mentioned above, Master data is something that will not change daily like transaction data, so it should be ok if it is less flexibility but more secure.