Your custom MDM solution: Don’t make these mistakes (Part 1)

Most MDM implementations will be based on a commercial software product.  By relying on a packaged solution, the architectural considerations have been addressed by the software vendor, allowing the project team to focus on the data management considerations.  However, there are cases when a custom MDM solution may be needed.  When proceeding down the path of custom development for MDM, we have some advice for you: avoid these common mistakes.

The most common data domains addressed by MDM solutions include customer, financial, products, partners, employees and locations.  Most organizations begin with a single data domain, typically focused on customer. Often additional data domains such as product or partners are created as separate MDM instances, managed by separate departments. As the customer data matures, it becomes apparent that an integration or federation between the customer and the product domain is necessary to get an accurate, consistent and complete picture of what each customer has purchased or considered.  The same relationships may be needed between product and partner.  The existence of multiple single data domain MDM solutions within an organization creates siloes of data that complicate the governance process and present challenges for data analytics and data quality.  Many organizations realize they need a multi-data-domain approach to master data management.

Read Also:
10 Tools for Data Visualizing and Analysis for Business

For these organizations, there are two options: extend a software product or custom develop a solution.  Many software vendors offer specialized solutions focused on a single data domain.  Extending a software product that was designed for a specific single data domain into a multi-data-domain model can be risky, complicated and expensive.  This is a complex decision and every organization has to decide which option is best for their unique requirements.  Many organizations build a custom solution to address multi-data-domain master data management requirements.  At Sullexis, we want to share several common mistakes that you should avoid when building a custom MDM solution.

Mistake #1: Separate your Master Data from your Transactional Data

Separating master data from transactional data should be a simple process.  But it often isn’t.

Our guiding rule is that master data is data that does not change frequently and is at the core of the business. Transactional data is more dynamic, changing frequently in status and content; it is something that happens at a certain point in time.

Read Also:
An Intuitive Explanation of Convolutional Neural Networks

Is Contract data dynamic? Well, it depends. Massive retail companies have a high volume of contracts that are constantly changing.;

Read Full Story…6448529

Leave a Reply

Your email address will not be published. Required fields are marked *