Would you recommend to have a unique "Data dictionnary" through-out the countries/subsidiaries/Business Units?
I guess this is not an issue when there is little commonality from one to the other, but in case the Business Objects seem similar, what is your return of experience: must do? should do? must not do?
I don't have a one fits all solution but let's try something.
I think it is close to the topic of the worldwide deployment of the roles.
You may have either an integrated company or a "not so much" integrated company.
For the first case, I would suggest to use "synonyms" and add the country/subsidiary/business unit origin, for them to have a perspective. If you face people saying "it's not exactly the same", rename the column to "similar to".
Nevertheless, it is important to aim a unique standard name. At least to promote synergies between these country/subsidiary/business and consistency for global performance measure. I don't see how you can have a global KPI of sales of product if you are not aligned on what is a product ... or a sale.
For the second case ... target should be the same but the effort may be huge. You can try correspondance mapping between dictionary. It can work for a while but maintenance cost may kill it. Doing an upfront alignement effort would be my preference. If your Business Units really don't have any communality in their value stream (like you are renting houses and building cars), you may focus only on common capabilities Business Objects like HR, Finance, Procurement, Sales ... To have at least federated KPI on these areas.
By the way, I would prefer the term "Business Object Dictionary" rather than "Data Dictionary", I'm sure there are at least 3 different possible understanding of this last one.
Feel free ton connect on linkedIn to continue discussion !
Very interesting approach. I would mostly agree with most of the responsibilities to cover. We are also trying to keep a lower amount of different roles in order to simplify (complexity comes with the number of interactions). And finally we are not using the same terminology. Thanks for sharing!
Many thanks for this insight.
Would you recommend to have a unique "Data dictionnary" through-out the countries/subsidiaries/Business Units?
I guess this is not an issue when there is little commonality from one to the other, but in case the Business Objects seem similar, what is your return of experience: must do? should do? must not do?
Looking forward to reading your feedback!
Hello Guillaume,
Thanks for your question !
I don't have a one fits all solution but let's try something.
I think it is close to the topic of the worldwide deployment of the roles.
You may have either an integrated company or a "not so much" integrated company.
For the first case, I would suggest to use "synonyms" and add the country/subsidiary/business unit origin, for them to have a perspective. If you face people saying "it's not exactly the same", rename the column to "similar to".
Nevertheless, it is important to aim a unique standard name. At least to promote synergies between these country/subsidiary/business and consistency for global performance measure. I don't see how you can have a global KPI of sales of product if you are not aligned on what is a product ... or a sale.
For the second case ... target should be the same but the effort may be huge. You can try correspondance mapping between dictionary. It can work for a while but maintenance cost may kill it. Doing an upfront alignement effort would be my preference. If your Business Units really don't have any communality in their value stream (like you are renting houses and building cars), you may focus only on common capabilities Business Objects like HR, Finance, Procurement, Sales ... To have at least federated KPI on these areas.
By the way, I would prefer the term "Business Object Dictionary" rather than "Data Dictionary", I'm sure there are at least 3 different possible understanding of this last one.
Feel free ton connect on linkedIn to continue discussion !
Frederic
Very interesting approach. I would mostly agree with most of the responsibilities to cover. We are also trying to keep a lower amount of different roles in order to simplify (complexity comes with the number of interactions). And finally we are not using the same terminology. Thanks for sharing!