Category Archives: Thought Leadership

ThrivOn’s Big Data Framework published in TDWI newsletter

ThrivOn’s  “A Framework for Understanding the Big Data Revolution” published in TDWI newsletter

A Big Data article co-authored by ThrivOn’s director of analytics Sachin Sinha was selected to be published in the TDWI Business Analytics newsletter. This article introduces a broad level big data framework for understanding the big data revolution. This Information Life Cycle Framework, introduced in the article, helps you navigate the big data technology landscape and see big data in light of a complete, end-to-end solution that can tackle the entire information life cycle.

To read more, click the link

How to Build a Business Case for Your Master Data/Governance Initiative

April 24, 2012, Knowing how to get started is key to building a successful project — and obtaining the funding to get the project off the ground.

By Sachin Sinha, Director of Business Intelligence and Analytics, ThrivOn

Today, all organizations share a common problem. We know that progressive organizations are process driven. Many of the most critical business processes depend on high-quality data: customer data, product data, and location data, among others. These critical processes also depend on the relationships inherent in the data: relationships between the customer and the location or between the product and the customer, and relationships among the products themselves. These critical data assets and relationships are central to running a business.

We call these critical data assets master data. However, the data on which these processes rely is often of very poor quality — inaccurate, incomplete, missing, or duplicated — and, thus, the business processes that depend on this data becomes inefficient, ineffective, costly, and riskier. In addition, the data is dispersed among a number of non-integrated and siloed information repositories; and, as we know, data volumes will continue to grow exponentially, most likely compounding the problem over time.

Companies that realize this but are new to master data management (MDM) are often overwhelmed by the sheer variety of technologies and processes involved in MDM solutions. Where do we start? Do we need data quality? How does MDM integrate into our infrastructure? How do we measure MDM success? These are the questions managers and executives in charge of enterprise data will ask. It seems a gargantuan effort to think about master data elements, let alone identify them.

Master data is the high-value, core information used to support critical business processes across an enterprise; it is at the heart of every business transaction, application, report, and decision. An MDM project, therefore, should begin with a discussion of those business processes, objectives, and performance metrics; this is key to selling MDM to business users. Before organizations adopt MDM, they must agree on a definition of master data and reach agreement about what should be managed as master data. This definition may vary for different industries, and even for organizations within the same industry.

Exploring, defining, and agreeing on why and where business users rely on master data across business processes and IT systems is one way to approach MDM. The use of definitional techniques will help us separate master data from application-specific data because it allows us to quickly locate master data elements. One such technique successfully employed by many organizations is to first identify an organization’s core business entities, in terms of parties (customers, employees, vendors, suppliers), places (sites, locations, offices, regions), and things (assets, products, services).

We should also be prepared to ask additional questions while identifying core business entities. For example:

•Is this core entity a building block of critical business transactions? (“Critical business transactions” are those significantly impacting revenue generation, customer satisfaction, profitability, safety, efficiency, or other elements critical to the success of the organization.)

•Is the data in our core business entity created and managed in multiple systems?

•Is this leading to possible redundancies and discrepancies in the structure and meaning of this data?

•If the data for these core entities is incorrect, inaccurate, incomplete, mismanaged, etc., does it have the potential to do harm to our organization? In other words, how much does this data really matter to our organization?

The last question in this list helps prioritize which master data element(s), or business area or processes, should be managed first.

Create a table of core business entities; detail why these entities are important and describe their effects on critical business transactions. Additionally, list common attributes of each core business entity. A core entity, together with its attributes, constitutes a master data entity, or element. Once you’ve established a list of core business entities and identified their details, it will be much easier to explain to business users how, through a 360-degree view provided by MDM, they can reduce operational costs, improve customer service, and drive additional revenue through improved cross-selling, and up-selling.

This conversation will prove more successful with business users because it engages them in a discussion about the effectiveness of key processes instead of focusing on speeds and feeds. This type of discussion has a much better chance of winning a champion — as well as budget approval — for an MDM effort. Additionally, for an MDM effort to succeed, it is necessary to start with a small project — a single data domain, use case, or set of business processes.

Lastly, keep in mind that we really can’t perform MDM without governance. By definition, MDM is a governance project — the governance of your master data elements. We can empower business users to make data decisions with governance and data policies and, in turn, make MDM successful. The best way to get this started is by setting up a cross-organizational structure to discuss governance and MDM, but we’ll have to leave that discussion for another time