Don’t Organize for AI, Organize for Analytics

Artificial intelligence has been getting a lot of attention lately, and rightly so. New techniques and advances in technology now make wide use of AI possible across all major industries and sectors. But being successful with AI requires more than selecting the right technology. Knowing this, organizations are scrambling to hire or develop the right talent and establish suitable structures to make effective use of AI. And if you look for it, you’ll find plenty of advice on “organizing for AI”.

But there is something missing in much of this advice: How to organize for analytics in general. It wouldn’t be as much of a concern if these basics were already in place in most organizations, but they aren’t. Decision makers in large enterprises still must contend with missing data, overlapping and inconsistent reports, and “information” presented as perplexing stacks of numbers without even the most basic visualization applied. Besides, why would you want to put the burden on decision makers to decide whether the analytics they need are “advanced” or “regular”?

In a properly designed analytics function that serves the entire enterprise, there is – and always has been – a place for advanced techniques. While it does make sense to put together a task force to assess the potential value of AI, it would be a mistake to assume that this team should ensconce itself as yet another permanent silo. It would be much better to thoughtfully align the capability with existing functions while simultaneously addressing a long-standing need to better serve the organization with information and analysis of all kinds.

Whether AI provides the impetus or not, here are a few things to do when creating an analytics team.

Define the mission of the team. The purpose of the team should be comprehensive without going too far. The team should be responsible for offering reporting and analytics along with associated business insights throughout the organization. However, it should not be responsible for establishing (de facto or official) production data resources, unless you are willing to take this responsibility away from the existing IT department. You should also be clear about departments that are to be served and any departments that will be responsible for their own reporting and analytics. Overlaps and conflicts can last for years – better to address them right at the beginning.

Identify an existing team that could be transformed into an analytics team. In almost every case, if you look, you’ll find an organization that is already offering reporting and analytic services to other departments. There’s usually such a group in the finance function, for example. Even if they are primarily focused on reporting financial information, they usually venture beyond that core and into factors that affect financial performance. In some cases, groups that just happen to have good analytic skills – such as marketing, operations research, or strategy functions – generously offer those capabilities to other areas outside of their group. In other cases, there is an IT group that goes beyond technical enablement and into business analysis. Often, you’ll find all of the above. Even if one of these groups is not selected to become the primary enterprise analytic team, you’ll need to solicit their buy-in and participation and, again, avoid overlap.

Define and fill the role to lead the team. Whatever the actual title, the role to lead the team would essentially be serving as a Chief Analytics Officer. So, this role could be labeled as such, or the responsibilities could be assigned to an existing Chief Data Officer, possibly renamed to a Chief Data and Analytics Officer. If neither a CAO nor CDO is currently in place, it’s probably best to create one combined role at least initially, then split the responsibilities if that seems right after some experience. (See here for a starter to-do list for a CDO). The role could report into the CFO, CIO, COO, or even directly to the CEO, depending primarily on the mission and organizational influence of the executive.

Define the team structure. Even though you’ll often hear that “there is no one right way”, I believe in this case, there is. Any other choice is just a concession to political realities. However, there are variations on the theme. Any internal function, like an analytics team, that offers services to other areas within the organization should have a centralized core for shared capabilities and representation for each department served. The departmental component of the analytics team can either report straight line to the central group and dotted line to the served department (my preference), or straight line to the served department and dotted line to the central group – or a mix of the two. One of the shared capabilities in the central group should be advanced analytics, including artificial intelligence. Of course, if specific departments require full-time dedication for advanced capabilities, that should be provided as well.

Define the relationship of the team to other functions. I already mentioned the need to coordinate with IT for production data deployment, but there are other important relationships to consider. For example, the analytics team should work with IT business liaisons and associated application teams to ensure that there is one and only one funnel for production application deployment. While the analytics team should develop and deliver production analytics – whether one-off studies or institutionalized report distribution – IT should be responsible to deploy custom or packaged application software solutions, even if they contain an analytic component. There isn’t a hard line here, and a good working relationship between the liaison and the lead analyst assigned to the same department will be crucial. Keep in mind that when any advanced capability – including artificial intelligence – demonstrates repeatable value, it’s likely that software companies have already packaged that value into an off-the-shelf application, so it’s important for both groups to understand the broad range of possible ways to solve a problem – avoiding the hammer-nail syndrome.

Develop or recruit the needed skills. If your kids ever wonder why they need to take math in school, just show them the latest salary figures for a capable data scientist. Of course, it’s not so much the mechanics of mathematics that matter, but the ability to use logical thinking to leverage the most appropriate techniques to solve problems. (See here for an interesting take on what this should mean for the way math is taught in schools.) These abilities, combined with good communication skills, are the key. You do not have to participate in the frenzy to hire a team of seasoned data scientists. With the right base capabilities and mindset, the technical part can be learned. And if there is an effective division of responsibility between IT and the analytics team, as noted earlier, the data scientists (and other analysts) won’t have to spend most of their time collecting and managing data. Placing excessive data management burden on data scientists inflates the number of analysts needed for the team and increases the breadth of skill requirements for the role, making it much more difficult to staff.

I often encounter resistance to recommendations like these. There are various reasons for this – always understandable, but ultimately, I believe, political. Or maybe it’s better to call it organizational inertia. I think that’s why it’s so tempting to treat AI as an add-on to the organization. Dealing with legacy is tough business. Making changes to deep-rooted organizational structures requires a lot of finesse and, let’s be honest, at least a little bit of force. But if you’re willing to address analytics with the breadth and seriousness that it deserves, you will be rewarded with a world class capability that has meaningful impact on a broad range of opportunities, unconstrained by a narrow – if valuable – focus on AI alone.