4 Tips to Turn Bad Data Into Good Results

When it comes to making better, data-driven marketing decisions, the No. 1 excuse I hear from professionals about why they’re not doing so is that they have bad data. Often, they are right. However, this is rarely a black-and-white scenario. Most times, marketers still have ample data to make better (not perfect) decisions.

bad data
“Misinformation,” Creative Commons license. | Credit: Flickr by jimjarmo

When it comes to making better, data-driven marketing decisions, the No. 1 excuse I hear from professionals about why they’re not doing so is that they have bad data. Often, they are right. However, this is rarely a black-and-white scenario. Most times, marketers still have ample data to make better (not perfect) decisions.

Many of my consulting engagements have resulted in sound strategic advice based on error-prone data sets. Below are four tips on how to work with bad data to yield valuable information.

  • Identify Corroborating Data: When encountering “bad data,” there are often other sources of data that can be used to corroborate what you are trying to measure. For example, I was working with a retailer who claimed to have unreliable inventory data. Naturally, for a retailer, this is a huge problem. However, we were able to leverage point-of-sale information to identify SKUs that were usually fast-moving, but suddenly exhibited zero sales. While the inventory system indicated low (not depleted) stock, the sales pattern could be used to confirm that there was an inventory issue directly affecting revenue. By leveraging this knowledge, we were able to reset replenishment thresholds and triggers, which kept high-demand merchandise in stock.
  • Investigate the Bad Rep: A data set sometimes gets a notorious reputation because of what I call “noisy outliers.” These are errors that get significant attention, but only represent a small proportion of the data which is mostly correct. Once, we were working with household policy data for a personal lines insurer. There were several cases where policies were identified as belonging to separate households when they weren’t, and visa versa. A quick investigation found a handful of issues (such as incorrect addresses, multiple addresses for the same household and policies sold by different agents) which drove most of the house-holding errors. Once identified, correcting code was written and a much cleaner data set was created.
  • Differentiate Between Zero and Null: Missing data can also prevent decision-makers from taking advantage of a valuable data set. The first step in such instances, is to determine if the values are really missing or if they are in fact zero. This often takes some investigative work to understand the logic behind how value is generated and if the system uses a zero or a blank to identify no activity. (Remember, no activity is not the same as missing information). Assuming that a value is indeed missing, then two immediate options are present. First are there proxy values that can be used to generate the missing values? Sometimes, the proxy data is a combination of several variables and requires some experimentation. Second, can the business question still be answered by ignoring the missing data and working with the data you do have? In my experience, most times missing data is more of a hurdle and not a brick wall when seeking a data-driven answer.
  • Use Random Error to Your Advantage: Finally, there will be times when either it is too time-consuming to fix bad data or it is just unfixable. However, If you are trying to measure differences among groups or time periods, then the data may still be helpful. If you can safely assume the errors are random, then it is possible that the errors will cancel each other out and actual differences between groups can still be measured. For example, my team was working with Web traffic data from two recently merged brands. As a result, there were two separate Web analytics platforms. Each system provided slightly different measurements and had visitor identification issues. However, there was no reason to believe one brand’s site had a bigger problem vs. the other, or that they were of a different nature. On the positive side, many of the segmentation factors were very similar. As a result, segment-level differences could be observed using data from both websites and a combined segment-driven strategy could be employed, saving the combined company millions.

The tips above are not exhaustive and every situation is unique; however, my experience is that most companies give up on bad data sets too quickly, especially when making important business decisions. The tips outlined above are a good starting point if you want to mine gold out of a bad data set. That said, I am also a believer in not being hostage to existing data. In many cases now, more relevant data can be generated in a few weeks, especially in digital marketing. Just something to think about.

How to Be a Good Data Scientist

I guess no one wants to be a plain “Analyst” anymore; now “Data Scientist” is the title of the day. Then again, I never thought that there was anything wrong with titles like “Secretary,” “Stewardess” or “Janitor,” either. But somehow, someone decided “Administrative Assistant” should replace “Secretary” completely, and that someone was very successful in that endeavor. So much so that, people actually get offended when they are called “Secretaries.” The same goes for “Flight Attendants.” If you want an extra bag of peanuts or the whole can of soda with ice on the side, do not dare to call any service personnel by the outdated title. The verdict is still out for the title “Janitor,” as it could be replaced by “Custodial Engineer,” “Sanitary Engineer,” “Maintenance Technician,” or anything that gives an impression that the job requirement includes a degree in engineering. No matter. When the inflation-adjusted income of salaried workers is decreasing, I guess the number of words in the job title should go up instead. Something’s got to give, right?

I guess no one wants to be a plain “Analyst” anymore; now “Data Scientist” is the title of the day. Then again, I never thought that there was anything wrong with titles like “Secretary,” “Stewardess” or “Janitor,” either. But somehow, someone decided “Administrative Assistant” should replace “Secretary” completely, and that someone was very successful in that endeavor. So much so that, people actually get offended when they are called “Secretaries.” The same goes for “Flight Attendants.” If you want an extra bag of peanuts or the whole can of soda with ice on the side, do not dare to call any service personnel by the outdated title. The verdict is still out for the title “Janitor,” as it could be replaced by “Custodial Engineer,” “Sanitary Engineer,” “Maintenance Technician,” or anything that gives an impression that the job requirement includes a degree in engineering. No matter. When the inflation-adjusted income of salaried workers is decreasing, I guess the number of words in the job title should go up instead. Something’s got to give, right?

Please do not ask me to be politically correct here. As an openly Asian person in America, I am not even sure why I should be offended when someone addresses me as an “Oriental.” Someone explained it to me a long time ago. The word is reserved for “things,” not for people. OK, then. I will be offended when someone knowingly addresses me as an Oriental, now that the memo has been out for a while. So, do me this favor and do not call me an Oriental (at least in front of my face), and I promise that I will not call anyone an “Occidental” in return.

In any case, anyone who touches data for living now wants to be called a Data Scientist. Well, the title is longer than one word, and that is a good start. Did anyone get a raise along with that title inflation? I highly doubt it. But I’ve noticed the qualifications got much longer and more complicated.

I have seen some job requirements for data scientists that call for “all” of the following qualifications:

  • A master’s degree in statistics or mathematics; able to build statistical models proficiently using R or SAS
  • Strong analytical and storytelling skills
  • Hands-on knowledge in technologies such as Hadoop, Java, Python, C++, NoSQL, etc., being able to manipulate the data any which way, independently
  • Deep knowledge in ETL (extract, transform and load) to handle data from all sources
  • Proven experience in data modeling and database design
  • Data visualization skills using whatever tools that are considered to be cool this month
  • Deep business/industry/domain knowledge
  • Superb written and verbal communication skills, being able to explain complex technical concepts in plain English
  • Etc. etc…

I actually cut this list short, as it is already becoming ridiculous. I just want to see the face of a recruiter who got the order to find super-duper candidates based on this list—at the same salary level as a Senior Statistician (another fine title). Heck, while we’re at it, why don’t we add that the candidate must look like Brad Pitt and be able to tap-dance, too? The long and the short of it is maybe some executive wanted to hire just “1” data scientist with all these skillsets, hoping to God that this mad scientist will be able to make sense out of mounds of unstructured and unorganized data all on her own, and provide business answers without even knowing what the question was in the first place.

Over the years, I have worked with many statisticians, analysts and programmers (notice that they are all one-word titles), dealing with large, small, clean, dirty and, at times, really dirty data (hence the title of this series, “Big Data, Small Data, Clean Data, Messy Data”). And navigating through all those data has always been a team effort.

Yes, there are some exceptional musicians who can write music and lyrics, sing really well, play all instruments, program sequencers, record, mix, produce and sell music—all on their own. But if you insist that only such geniuses can produce music, there won’t be much to listen to in this world. Even Stevie Wonder, who can write and sing, and play keyboards, drums and harmonicas, had close to 100 names on the album credits in his heyday. Yes, the digital revolution changed the music scene as much as the data industry in terms of team sizes, but both aren’t and shouldn’t be one-man shows.

So, if being a “Data Scientist” means being a super businessman/analyst/statistician who can program, build models, write, present and sell, we should all just give up searching for one in the near future within your budget. Literally, we may be able to find a few qualified candidates in the job market on a national level. Too bad that every industry report says we need tens of thousands of them, right now.

Conversely, if it is just a bloated new title for good old data analysts with some knowledge in statistical applications and the ability to understand business needs—yeah, sure. Why not? I know plenty of those people, and we can groom more of them. And I don’t even mind giving them new long-winded titles that are suitable for the modern business world and peer groups.

I have been in the data business for a long time. And even before the datasets became really large, I have always maintained the following division of labor when dealing with complex data projects involving advanced analytics:

  • Business Analysts
  • Programmers/Developers
  • Statistical Analysts

The reason is very simple: It is extremely difficult to be a master-level expert in just one of these areas. Out of hundreds of statisticians who I’ve worked with, I can count only a handful of people who even “tried” to venture into the business side. Of those, even fewer successfully transformed themselves into businesspeople, and they are now business owners of consulting practices or in positions with “Chief” in their titles (Chief Data Officer or Chief Analytics Officer being the title du jour).

On the other side of the spectrum, less than a 10th of decent statisticians are also good at coding to manipulate complex data. But even they are mostly not good enough to be completely independent from professional programmers or developers. The reality is, most statisticians are not very good at setting up workable samples out of really messy data. Simply put, handling data and developing analytical frameworks or models call for different mindsets on a professional level.

The Business Analysts, I think, are the closest to the modern-day Data Scientists; albeit that the ones in the past were less so technicians, due to available toolsets back then. Nevertheless, granted that it is much easier to teach business aspects to statisticians or developers than to convert businesspeople or marketers into coders (no offense, but true), many of these “in-between” people—between the marketing world and technology world, for example—are rooted in the technology world (myself included) or at least have a deep understanding of it.

At times labeled as Research Analysts, they are the folks who would:

  • Understand the business requirements and issues at hand
  • Prescribe suitable solutions
  • Develop tangible analytical projects
  • Perform data audits
  • Procure data from various sources
  • Translate business requirements into technical specifications
  • Oversee the progress as project managers
  • Create reports and visual presentations
  • Interpret the results and create “stories”
  • And present the findings and recommended next steps to decision-makers

Sounds complex? You bet it is. And I didn’t even list all the job functions here. And to do this job effectively, these Business/Research Analysts (or Data Scientists) must understand the technical limitations of all related areas, including database, statistics, and general analytics, as well as industry verticals, uniqueness of business models and campaign/transaction channels. But they do not have to be full-blown statisticians or coders; they just have to know what they want and how to ask for it clearly. If they know how to code as well, great. All the more power to them. But that would be like a cherry on top, as the business mindset should be in front of everything.

So, now that the data are bigger and more complex than ever in human history, are we about to combine all aspects of data and analytics business and find people who are good at absolutely everything? Yes, various toolsets made some aspects of analysts’ lives easier and simpler, but not enough to get rid of the partitions between positions completely. Some third basemen may be able to pitch, too. But they wouldn’t go on the mound as starting pitchers—not on a professional level. And yes, analysts who advance up through the corporate and socioeconomic ladder are the ones who successfully crossed the boundaries. But we shouldn’t wait for the ones who are masters of everything. Like I said, even Stevie Wonder needs great sound engineers.

Then, what would be a good path to find Data Scientists in the existing pool of talent? I have been using the following four evaluation criteria to identify individuals with upward mobility in the technology world for a long time. Like I said, it is a lot simpler and easier to teach business aspects to people with technical backgrounds than the other way around.

So let’s start with the techies. These are the qualities we need to look for:

1. Skills: When it comes to the technical aspect of it, the skillset is the most important criterion. Generally a person has it, or doesn’t have it. If we are talking about a developer, how good is he? Can he develop a database without wasting time? A good coder is not just a little faster than mediocre ones; he can be 10 to 20 times faster. I am talking about the ones who don’t have to look through some manual or the Internet every five minutes, but the ones who just know all the shortcuts and options. The same goes for statistical analysts. How well is she versed in all the statistical techniques? Or is she a one-trick pony? How is her track record? Are her models performing in the market for a prolonged time? The thing about statistical work is that time is the ultimate test; we eventually get to find out how well the prediction holds up in the real world.

2. Attitude: This is a very important aspect, as many techies are locked up in their own little world. Many are socially awkward, like characters in Dilbert or “Big Bang Theory,” and most much prefer to deal with the machines (where things are clean-cut binary) than people (well, humans can be really annoying). Some do not work well with others and do not know how to compromise at all, as they do not know how to look at the world from a different perspective. And there are a lot of lazy ones. Yes, lazy programmers are the ones who are more motivated to automate processes (primarily to support their laissez faire lifestyle), but the ones who blow the deadlines all the time are just too much trouble for the team. In short, a genius with a really bad attitude won’t be able to move to the business or the management side, regardless of the IQ score.

3. Communication: Many technical folks are not good at written or verbal communications. I am not talking about just the ones who are foreign-born (like me), even though most technically oriented departments are full of them. The issue is many technical people (yes, even the ones who were born and raised in the U.S., speaking English) do not communicate with the rest of the world very well. Many can’t explain anything without using technical jargon, nor can they summarize messages to decision-makers. Businesspeople don’t need to hear the life story about how complex the project was or how messy the data sets were. Conversely, many techies do not understand marketers or businesspeople who speak plain English. Some fail to grasp the concept that human beings are not robots, and most mortals often fail to communicate every sentence as a logical expression. When a marketer says “Omit customers in New York and New Jersey from the next campaign,” the coder on the receiving end shouldn’t take that as a proper Boolean logic. Yes, obviously a state cannot be New York “and” New Jersey at the same time. But most humans don’t (or can’t) distinguish such differences. Seriously, I’ve seen some developers who refuse to work with people whose command of logical expressions aren’t at the level of Mr. Spock. That’s the primary reason we need business analysts or project managers who work as translators between these two worlds. And obviously, the translators should be able to speak both languages fluently.

4. Business Understanding: Granted, the candidates in question are qualified in terms of criteria one through three. Their eagerness to understand the ultimate business goals behind analytical projects would truly set them apart from the rest on the path to become a data scientist. As I mentioned previously, many technically oriented people do not really care much about the business side of the deal, or even have slight curiosity about it. What is the business model of the company for which they are working? How do they make money? What are the major business concerns? What are the long- and short-term business goals of their clients? Why do they lose sleep at night? Before complaining about incomplete data, why are the databases so messy? How are the data being collected? What does all this data mean for their bottom line? Can you bring up the “So what?” question after a great scientific finding? And ultimately, how will we make our clients look good in front of “their” bosses? When we deal with technical issues, we often find ourselves at a crossroad. Picking the right path (or a path with the least amount of downsides) is not just an IT decision, but more of a business decision. The person who has a more holistic view of the world, without a doubt, would make a better decision—even for a minor difference in a small feature, in terms of programming. Unfortunately, it is very difficult to find such IT people who have a balanced view.

And that is the punchline. We want data scientists who have the right balance of business and technical acumen—not just jacks of all trades who can do all the IT and analytical work all by themselves. Just like business strategy isn’t solely set by a data strategist, data projects aren’t done by one super techie. What we need are business analysts or data scientists who truly “get” the business goals and who will be able to translate them into functional technical specifications, with an understanding of all the limitations of each technology piece that is to be employed—which is quite different from being able to do it all.

If the career path for a data scientist ultimately leads to Chief Data Officer or Chief Analytics Officer, it is important for the candidates to understand that such “chief” titles are all about the business, not the IT. As soon as a CDO, CAO or CTO start representing technology before business, that organization is doomed. They should be executives who understand the technology and employ it to increase profit and efficiency for the whole company. Movie directors don’t necessarily write scripts, hold the cameras, develop special effects or act out scenes. But they understand all aspects of the movie-making process and put all the resources together to create films that they envision. As soon as a director falls too deep into just one aspect, such as special effects, the resultant movie quickly becomes an unwatchable bore. Data business is the same way.

So what is my advice for young and upcoming data scientists? Master the basics and be a specialist first. Pick a field that fits your aptitude, whether it be programming, software development, mathematics or statistics, and try to be really good at it. But remain curious about other related IT fields.

Then travel the world. Watch lots of movies. Read a variety of books. Not just technical books, but books about psychology, sociology, philosophy, science, economics and marketing, as well. This data business is inevitably related to activities that generate revenue for some organization. Try to understand the business ecosystem, not just technical systems. As marketing will always be a big part of the Big Data phenomenon, be an educated consumer first. Then look at advertisements and marketing campaigns from the promotor’s point of view, not just from an annoyed consumer’s view. Be an informed buyer through all available channels, online or offline. Then imagine how the world will be different in the future, and how a simple concept of a monetary transaction will transform along with other technical advances, which will certainly not stop at ApplePay. All of those changes will turn into business opportunities for people who understand data. If you see some real opportunities, try to imagine how you would create a startup company around them. You will quickly realize answering technical challenges is not even the half of building a viable business model.

If you are already one of those data scientists, live up to that title and be solution-oriented, not technology-oriented. Don’t be a slave to technologies, or be whom we sometimes address as a “data plumber” (who just moves data from one place to another). Be a master who wields data and technology to provide useful answers. And most importantly, don’t be evil (like Google says), and never do things just because you can. Always think about the social consequences, as actions based on data and technology affect real people, often negatively (more on this subject in future article). If you want to ride this Big Data wave for the foreseeable future, try not to annoy people who may not understand all the ins and outs of the data business. Don’t be the guy who spoils it for everyone else in the industry.

A while back, I started to see the unemployment rate as a rate of people who are being left behind during the progress (if we consider technical innovations as progress). Every evolutionary stage since the Industrial Revolution created gaps between supply and demand of new skillsets required for the new world. And this wave is not going to be an exception. It is unfortunate that, in this age of a high unemployment rate, we have such hard times finding good candidates for high tech positions. On one side, there are too many people who were educated under the old paradigm. And on the other side, there are too few people who can wield new technologies and apply them to satisfy business needs. If this new title “Data Scientist” means the latter, then yes. We need more of them, for sure. But we all need to be more realistic about how to groom them, as it would take a village to do so. And if we can’t even agree on what the job description for a data scientist should be, we will need lots of luck developing armies of them.

Why Contextual Advertising Is Still Hard

Contextualized advertising is serving the right message to the right person at the right time. Standing in the way of that goal are several hurdles. Among them: user personalization, segmentation and a deluge of data

Contextualized advertising is serving the right message to the right person at the right time. Standing in the way of that goal are several hurdles. Among them: user personalization, segmentation and a deluge of data.

Mobile personalization can create additional complexities that we don’t generally see on the PC side of the world. This can be both a challenge and an opportunity, but adds some new dimensions to how we work to connect with consumers.

This difficulty in leveraging user behaviors makes micro-segmentation more difficult. This is where real value from contextualized ads is found. As close to one-to-one as you can make an ad, the more value it has for the recipient. Having segments that are too large can decrease the overall impact of the ads for a given consumer.

Advertisers can improved their segmentation by sifting through omnichannel data sets. While there’s great progress in this area, attributing online, real world and mobile actions to an end result remains elusive to some of the industry.

New Tools Making Contextual Advertising Easier
New data tools, optimization techniques and leveraging exchanges are all emerging to make contextual advertising easier.

Algorithms that can recognize and contextualize mixed data sets are paving the way for more relevant contextual ads. You can target based on location (information that’s automatically provided by a mobile device), behavior and by predetermined personalization rules. So, someone is now seen as a specific category of user based on what they do, where they are and other relevant data. Messages can be personalized based on these characteristics to get the right ad in front of the right person.

Once a user can be tied to a mobile number, this opens up a world of contextual opportunities. These IDs can be closely tied to segment and location, and passed along to real-time-bidding (RTB) exchanges. Here, brands and advertisers can serve a contextualized ad to the correct mere moments after he/she makes a trigger action. Where as before, this data would be aggregated and analyzed monthly or weekly, we are getting close to the point of real time analysis and optimization.

The Impact of Future Technology and Contextual Ads
The “Holy Grail” of contextual advertising is connecting relevant ads that are optimized for a single individual. Technology is heading in that direction.

Wearables will feed advertisers never before accessible biometrics that could indicate when someone needs a sandwich or bottle of water before the person realizes it.

Interactive TVs and cross-screen attribution will pull together all parts of a person’s day. Ambient qualities, like time of day or weather, will become data points that advertisers can assess and use to target consumers.

As these technologies, combined with faster servers, make valuable contextual advertising an everyday occurrence, we will see a shift in the advertiser/consumer relationship. It will become more symbiotic. Users will be able to decide with what and whom they want to interact. Those advertisers who can use data to provide users the greatest value will prosper. Those who can’t make sense of data will suffer as consumers take their business elsewhere with a quick click on an iPhone.

MDM: Big Data-Slayer

There’s quite a bit of talk about Big Data these days across the Web … it’s the meme that just won’t quit. The reasons why are pretty obvious. Besides a catchy name, Big Data is a real issue faced by virtually every firm in business today. But what’s frequently lost in the shuffle is the fact that Big Data is the problem, not the solution. Big Data is what marketers are facing—mountains of unstructured data accumulating on servers and in stacks, across various SaaS tools, in spreadsheets and everywhere else you look in the firm and on the cloud.

There’s quite a bit of talk about Big Data these days across the Web … it’s the meme that just won’t quit. The reasons why are pretty obvious. Besides a catchy name, Big Data is a real issue faced by virtually every firm in business today.

But what’s frequently lost in the shuffle is the fact that Big Data is the problem, not the solution. Big Data is what marketers are facing—mountains of unstructured data accumulating on servers and in stacks, across various SaaS tools, in spreadsheets and everywhere else you look in the firm and on the cloud. In fact, the actual definition of Big Data is simply a data set that has grown so large it becomes awkward or impossible to work with, or make sense out of, using standard database management tools and techniques.

The solution to the Big Data problem is to implement a system that collects and sifts through those mountains of unstructured data from different buckets across the organization, combines them together into one coherent framework, and shares this business intelligence with different business units, all of which have varying delivery needs, mandates, technologies and KPIs. Needless to say, it’s not an easy task.

The usual refrain most firms chirp about when it comes to tackling Big Data is a bold plan to hire a team of data scientists—essentially a bunch of database administrators or statisticians who have the technical skills to sift through the Xs and 0s and make sense out of them.

This approach is wrong, however, as it misses the forest for the trees. Sure, having the right technology team is essential to long-term success in the data game. But truth be told, if you’re going to go to battle against the Big Data hydra, you need a much more formidable weapon in your arsenal. Your organization needs a Master Data Management (MDM) strategy in order to succeed.

A concept still unknown to many marketers, MDM comprises a set of tools and processes that manage an organization’s information on a macro scale. Essentially, MDM’s objective is to provide processes for collecting, aggregating, matching, consolidating, quality-assuring and distributing data throughout the organization to ensure consistency and control in the ongoing maintenance and application use of this information. No, I didn’t make up that definition myself. Thanks, Wikipedia.

The reason why the let’s-bring-in-the-developers approach is wrong is that it gets it backwards. Having consulted in this space for quite some time, I can tell you that technology is one of the least important pieces in the puzzle when it comes to implementing a successful MDM strategy.

In fact, listing out priorities when it comes to MDM, I put technology far to the end of the decision-tree, after Vision, Scope, Data Governance, Workflow/Process, and definition of Business Unit Needs. As such, besides the CTO or CIO, IT staff should not be brought in until after many preliminary decisions have been made. To support this view, I suggest you read John Radcliffe’s groundbreaking ‘The Seven Building Blocks of MDM: A Framework for Success‘ published by Gartner in 2007. If you haven’t read it yet and you’re interested in MDM, I suggest taking a look. Look up for an excellent chart from it.

You see, Radcliffe places MDM Technology Infrastructure near the end of the process, following Vision, Strategy, Governance and Processes. The crux of the argument is that technology decisions cannot be made until the overall strategy has been mapped out.

The rationale is that at a high-level, MDM architecture can be structured in different ways depending on the underlying business it is supporting. Ultimately, this is what will drive the technology decisions. Once the important strategic decisions have been made, a firm can then bring in the development staff and pull the trigger on any one of a growing number of technology providers’ solutions.

At the end of 2011, Gartner put out an excellent report on the Magic Quadrant for Master Data Management of Customer Data Solutions. This detailed paper identified solutions by IBM, Oracle (Siebel) and Informatica as the clear-cut industry leaders, with SAP, Tibco, DataFlux and VisionWare receiving honorable mention. Though these solutions vary in capability, cost and other factors, I think it’s safe to say that they all present a safe and robust platform for any company that wishes to implement an MDM solution, as all boast strong technology, brand and financial resources, not to mention thousands of MDM customers already on board.

Interestingly, regarding technology there’s been an ongoing debate about whether MDM should be single-domain or multi-domain—a “domain” being a framework for data consolidation. This is important because MDM requires that records be merged or linked together, usually necessitating some kind of master data format as a reference. The diversity of the data sets that are being combined together, as well as the format (or formats) of data outputs required, both drive this decision-making methodology.

For companies selling products, a product-specific approach is usually called for that features a data framework built around product attributes, while on the other hand service businesses tend to gravitate toward a customer-specific architecture. Following that logic, an MDM for a supply chain database would contain records aligned to supplier attributes.

While it is most certainly true that MDM solutions are architected differently for different types of firms, I find the debate to be a red herring. On that note, a fantastic article by my colleague Steve Jones in the UK dispels the entire single-versus-multi domain debate altogether. I agree wholeheartedly with Jones in that, by definition, an MDM is by an MDM regardless of scope. The breadth of data covered is simply a decision that needs to be made by the governance team when the project is in the planning stages—well before a single dollar has been spent on IT equipment or resources. If anything, this reality serves to strengthen the hypothesis of this piece, which is that vision more technology drives the MDM implementation process.

Now, of course, an organization may discover that it’s simply not feasible (or desirable) to combine together customer, product and supplier information in one centralized place, and in one master format. But it’s important to keep in mind that the stated goal of any MDM solution is to make sense out of and standardize the organization’s data—and that’s it.

Of course there’s much more I can cover on this topic, but I realize this is a lot to chew on, so I I’ll end this post here.

Has your firm implemented, or are you in the process of implementing, an MDM solution? If so, what process did you follow, and what solution did you decide upon? I’d love to hear about it, so please let me know in your comments.