Data is King.
In today’s connected world, data is the lifeblood of all successful organizations. With data, organizations are able understand their markets, make decisions that help drive increased traction and revenue, and build products that their customers want, purchase and use. Without data, organizations are fumbling in the dark: making wild guesses about what they should or shouldn’t do.
Data is King.
In today’s connected world, data is the lifeblood of all successful organizations. With data, organizations are able to understand their markets, make decisions that help drive increased traction and revenue, and build products that their customers want, purchase and use. Without data, organizations are fumbling in the dark: making wild guesses about what they should or shouldn’t do.
One major issue that most businesses face in the attempt to be data-driven is that most of their data is stored in disparate, siloed systems that are owned by different departments.
When organizations attempt to merge this data, the effort fails because of data system quality or because they are unable to map the different entities between the systems together. These pervasive entities within organizations are referred to as master data.
Typically, these entities tend to be things like business accounts, customers and sales items/SKUs.
In addition, typically these items are mastered, or originate, within that organization’s Enterprise Resource Planning system or ERP. ERP systems tend to be owned by finance which usually means that Master Data Management or MDM is done by the finance department using various tools offered by off the shelf products and software policies set up in the ERP system.
However, this can create a myopic view of the type of entities that can and should be managed by the master data system.
While finance departments care about customers, sales items/SKUs, and accounts; other departments tend to need additional data points about these entities to make more data-driven decisions.
For example, sales might need information about the various contacts that might be at an account. In different domains, this may change as well.
At a consulting agency, you tend to have one skew but tend to track even more data about the various projects at a given client and how you might be able to help.
By considering different data types, organizations can change the way their departments coordinate and understand each other’s efforts.
Communication is done by data and analytics as a shared language instead of meetings. This helps everyone within the business understand how each department operates and helps individuals spot issues and make better decisions.
This business utopia of shared understanding can be achieved, but there are some common pitfalls that organizations run into from a technical perspective.
The first common pitfall is maintaining high data quality within the ecosystem. As data is entered into many different systems that exist within the organization, it’s possible that the systems develop split brain: two different systems believing that they have the right data.
This can be avoided by using clear boundaries of ownership of where data is mastered.
Accounts may originate and be owned by the Customer Relationship Management or CRM system, projects originate in the work tracking system, and sales items/SKUs may originate in the ERP system.
This prevents split brain within the distributed ecosystem of products because each system has clear ownership of what data they own and which they do not.
This means that each system will be the system where that data is managed and pushed out from via integrations with the other systems.
Another common pitfall that occurs is that the proper master data architecture is not selected by the organization. There is no perfect architecture in software, but there are architectures with strengths that boost your business, while any weaknesses don’t affect your ability to do business.
One common architecture is having a centralized system like an ERP master all data within the architecture. This can be perfect for an organization that uses its ERP system for most of its business activities.
However, in the case where each department has their own system: sales has its CRM and engineering has its project management system, the systems may be unusable if the ERP becomes unreachable.
This could mean that the sales system can’t get access to the right accounts to generate leads, projects are not accessible for engineers to work on, and other consequences.
It’s important that as you are selecting a master data strategy that the correct architecture is selected for the business at hand as there is no one size fits all strategy, only best practices.
A third common pitfall that occurs with master data implementations is the lack of understanding of the business rules surrounding the data that is being mastered. Projects tend to originate with an IT or finance department and these organizations may lack the information needed to identify what a type of data means.
For example, the sales team might have a strict definition of an account that finance or IT does not understand.
To mitigate this step, it’s important that each department is in contact as the master data implementation is ongoing.
This will prevent misunderstanding of fundamental business rules that can cause incorrect data to proliferate the business systems within an organization.
Master data projects are becoming incredibly popular as organizations attempt to become more data-driven.
Done correctly, master data can give organizations a common view and understanding of how the business executes within their domains.
Done incorrectly, it can cause confusion and frustration among departments. As data becomes increasingly critical to the success of businesses, organizations should analyze not only the typical entities that get modeled within a master data system but also other entities that could, once mastered, could provide critical insight that helps them execute and win in their markets.
Andrew has an M.S. in Computer Science from Georgia Tech University. But he prides himself over 10 years of experience working in the software industry for well-known companies such as Diebold, Tableau, Explorys, and Onshift. After years in the corporate and startup worlds as well as running his own consulting firm, Andrew realized he had to do more to improve software products and practices. From that, Skiplist was born. Skiplist is the opportunity to focus on thoughtful, quality software and change the software consulting industry.