Centralized vs Decentralized Analytics: All You Need To Know

Having spent the past dozen years in an Analytics role, both as an individual contributor and as a manager, I’ve had the opportunity to see the analytics function work within centralized, decentralized, and matrixed organizational structures. The relative merits of building a centralized versus decentralized Analytics organization depend largely on exactly what you expect to get out of the Analytics function in your organization, so it’s important to consider the pros and cons — and to structure the Analytics function correctly to meet your organizational goals. 

Immediacy / Responsiveness

At the most basic level, a decentralized Analytics organization will provide your line-of-business managers (think Marketing, Product, Biz Dev, possibly Finance) with direct, full-time access to an analytics resource, and those managers will get the quickest turnaround on their requests. Of course, it’s unlikely that all your lines of business will be able to hire and train their own analyst — more likely, in a decentralized scenario, some business functions have full access while others receive limited or no analytics support. Another way to think about this: What happens when you give two or three pieces of candy to a dozen kids? (Hint: You already know the answer, which is why nobody gives two or three pieces of candy to a dozen kids.)

In some cases, a matrix structure is proposed to address this need to make Analytics available as a distributed resource. Matrix structures have some well-known shortcomings, in particular the problem where individual contributors have two or more bosses who may or may not coordinate workload or expectations. This problem is compounded in making an analytics function work, for one simple reason: in most organizations, the business function with the dotted-line to the analyst often has a shorter path to the CEO than the dark-line, central analytics function does. Regardless of the intent, I’ve seen this have the practical effect of pushing the CEO to conclude that specific line-of-business managers were being under-serviced, rather than that requests from those lines of business were lower priority or simply of less value than requests from other LOBs. My conclusion: A matrixed Analytics function will in most cases result in Analytics being decentralized over time, with the side effect of some Analytics casualties in the re-org.

Data, Data, Everywhere

In most of the organizations I’ve worked in — particularly the ones trying to start up an Analytics team — data are literally lying around everywhere. Transactional information may be in a MySQL database accessible with DBVisualizer; financial information sits in a SQL Server database queryable with Query Analyzer; Web logs are in Akamai log files, and email data are stuffed in Amazon SES. Historical numbers may be in an old Microsoft Access database, and daily sales numbers are stored in Excel pivot tables on the network drive. Affiliate numbers from two different third-party Web sites have to be manually cut-and-pasted. And tracking for your newest site features is on the Hadoop cluster, which is accessible via HBase, or by using SAS or Tableau via Hive.

There are literally dozens of technologies within which your organizational data may be hiding. Who’s going to train the analyst to do all this? Your marketing guys? Your developers? Perhaps more importantly from an efficiency standpoint, who’s going to help the second, third, and fourth analysts learn it — should each and every new analyst lean on the developers and DBAs to learn their jobs? Do your organization’s developers have time to answer every new analyst’s questions? Like it or not, most answers to the  “How do I count this?” question are going to take up your developers’ time unless you already have an analyst who has already asked those questions before.

Analytics Infrastructure

In most scenarios, the Analytics function is a specialized occupation that’s dependent on other skillsets within your organization to reach its full potential. Analysts need specific software and often specific hardware to do their jobs. While analysts are often highly skilled, they’re almost always differentially skilled — one analyst is good in SQL and Excel, another has advanced SAS and Reporting Services skills. Under a decentralized structure, one LOB will tend to invest along the skillset of its own analyst — in this example, developing Excel VBA programs to pull SQL data into live Excel reports — while another LOB my purchase SAS and install an instance of SQL Server to easily support cross-database warehousing. (An equally bad scenario: the CTO refuses all such purchases, recognizing they’re not strategic investments — leaving the analysts completely unsupported.) Without some kind of central coordination, decentralized Analytics will frequently lead to non-strategic infrastructure investment that may become obsolete as soon as their specialized analyst finds a job that offers a real career path in their chosen profession.

Career Path

From an organizational cost perspective, here’s perhaps the biggest argument against a decentralized Analytics organization: In a decentralized organization, there is no tangible career path for most analysts.

Decentralization isn’t without some advantages to the analyst: specifically, there will inevitably be points at which the organization must invest in software, hardware, or training in order to support the analyst, and these decisions will be heavily influenced by what the analyst knows to do or wants to do. However, this may or may not be in the best strategic interests of the organization.

In contrast, a more centralized organizational structure inherently promotes internal communication of all the information-consumers within an organization, and provides something of a mandate to create more strategic solutions and center on fewer technologies that the organization can develop and maintain competency around. As part of that, a career and competency ladder relative to the Analytics role becomes clear: to increase value to the organization, an analyst should master these additional technologies, cross-train on these specific lines of business, and approach the level and quality of work already benchmarked by senior analysts. Without a career path, your analysts are highly incented to learn in-demand technology on your dime — whether or not your organization has a need for it — and then jump ship to an employer who will compensate them for that skill. Perhaps even more to the point: rock-star analysts will avoid employers with a decentralized Analytics function, because they know it’ll take them longer to come up to speed and that there is likely no performance incentive program specific to their accomplishments.

A Man With One Watch Knows What Time It Is…

To quote Lee Segall: “A man with one watch always knows what time it is; a man with two watches is never quite sure.”

One of the first things you will discover in a decentralized Analytics organization is that the numbers on some, perhaps many, of your reports will not match. You will quickly gain the sense that your analysts don’t know how to count anything; you will be frustrated with and come to lack confidence in your reports; and you will discount the potential value of a great analytics organization. In short, you will set yourself up to fail to compete on analytics.

Consider the alternate scenario: The numbers foot on all your reports, business-rule changes are reflected consistently across all your information sources, AND you can get that rush ad-hoc report even though one of your analysts is out sick. Unfortunately, in most organizations, “counting beans” isn’t nearly as straightforward as it sounds. In my experience, it’s not uncommon for nobody to really know how to count something correctly out of a database, and finding the right answer consists of asking a lot of questions and a lot of trial and error. Having a common reporting codebase, access to other analysts who’ve worked on the problem — and candidly, having a managerial mandate to get some help from developers and DBAs — goes a very long way toward driving consistency and accuracy.

Level of Expertise

After my second year in my first “big” job, I remember thinking: “Man, I didn’t know anything a year ago.” At the end of my fourth year, I remember thinking: “It really takes two years to get an analyst up to full competence.” I’ve frequently seen an argument that decentralized analysts have a deeper knowledge of their specific line of business. I can’t give a lot of credence to that argument, specifically because line-of-business analysts are likely to leave the job around the time they become fully competent, leaving the line of business to backfill with a novice. In a centralized organization, on the other hand, no line of business should ever be left without an analyst without experience in that LOB. Additionally, centralized analysts should be conducting strategic research into that LOB as well, which will result in a higher level of expertise in that LOB than could be achieved through purely tactical work.

Competing on Analytics

I’ve said it before, and I’ll say it again: Centralization provides time and resources for your analytics team to be strategic, to answer questions that aren’t being asked, to generate revenue, to NOT be a cost center — instead of being 100% allocated to producing static reports. (And let’s be honest: most top-down reports never get read anyway.) Providing some degree of independence for the Analytics function is ultimately how organizations begin to compete on analytics, and generally speaking, centralization will go a long way toward making this goal a reality. In a decentralized organization, sure, you can still compete on Analytics — right after you finish these 75 TPS reports.

Control

At the end of the day, the key argument for a decentralized analytics organization is this: control of information. While there are undoubtedly cases where this level of control is warranted and even strategically valuable, such cases will be relatively rare. Every line-of-business manager has (or should have) specific business objectives they’re working toward; the job of the analyst is (or should be) to describe, explain, and ultimately to predict that performance. The last thing you want to do in a data-driven organization is to give any single person — even the CEO — complete control over which analyses are done and which results are (internally) communicated. Business performance metrics should stand on their own, good news or bad. If only the good news is asked for or communicated, there’s likely not much of a career path for anyone in the organization.

 

Header Image: jscreationzs / FreeDigitalPhotos.net