8 Tips for Thinking Organisationally about Data Analytics

Data analytics is currently a major source of strategic aspiration for organisations. It's been a while since I've seen a technology strategy paper that doesn't talk about leveraging the organisation's data through a big data initiative, generating efficiencies or added revenue through the use of predictive analytics, or make profligate use of the term "data scientist". This is a good thing. No doubt there are massive productivity gains to be had from such initiatives. But while this type of practice has been de rigeur for a few years now in start-ups and high-tech companies the penetration in brownfield enterprise environments as always lags behind. 

A particular area of complexity that I have encountered talking to several customers is how to think about this at the organisational level. How initiatives will sit within current structures, what tools should be used and where, how projects will interact with existing reporting processes, etc. These kinds of questions can make it difficult for CIOs, CTOs or Chief Data Officers to get beyond an early pilot programme or a couple of silo'd implementations of limited scope. To try to help anyone faced with these challenges, I've compiled the following 8 tips from my own experience to help clarify some of the common issues: 

Understand the complex reality of analytics production and consumption

When your organisation has been around for a while the reality of producing and consuming analytical information tends to become intertwined with numerous pathways for disseminating information in numerous formats as parts of numerous processes. Many if not most users will be both producers and consumers of analytical information and while they may use a tool to produce or consume that is sanctioned (and known) by your IT department, then again they frequently will not. As exceptions to processes accumulate over time, so do workarounds and the shadow IT related to those workarounds. Add to this datasets of various quality, some commonly known, some known only to a small group used in a variety of ways in an already confusing technology environment and you have a nightmare on your hands when planning for a technology change project. This means doing the typical IT thing of just rolling out a new tool to replace an old one can in and of itself only be a very partial answer. Instead, you'll have to focus much more on soft factors, such as getting broad based buy-in, senior sponsorship and spurring adoption through internal sales and marketing. 

Different organisational levels have different needs 

Don't fall into the trap of looking for the "right" way to consume or produce analytics. How your front-line staff needs information presented to deal with day-to-day issues is radically different from how you want it presented for a board meeting. Don't think you can simply break this into different views or dashboards from the same data source. They need qualitatively different user experiences. Staff in fast moving operational environments will likely need ad-hoc self-service tools (e.g. search analytics, a simple ad-hoc reporting tool, or even an export to Excel option) whereas the team doing reporting for long term strategic planning will need deep exploratory access to large well-structured databases of appropriately coded data. The same goes for specialist use cases (e.g. compliance or government reporting standards). The attempt to fit everything into the same category and not allowing for diversity in practice just guarantees that you will have the kind of workarounds happening that makes everything truly ungovernable.

One tool will not fit all

It should go without saying from the previous two points that you are (extremely) unlikely to find a single tool to serve all of these use cases. I don't care what your vendor tells you. Their product will not solve all your problems. It's too complicated for that. Instead focus on finding a portfolio of solutions that works well within the context of your overall enterprise architecture and develop the capability you need to support these for the use cases you encounter. 

One process will not fit all

The same point applies to processes around analytics such as who gets access to what data and tools, who has ownership and stewardship roles and what the lifecycle is for developing reports, dashboards and data products. It simply isn't appropriate to standardise between a compliance team that needs to produce regulatory reports and an operational team that needs a report yesterday to make a decision. Most people realise this, but there is still often a tendency to try to find a single overarching process that defines all consumption, production and governance of analytics. A better idea is to think of a framework and toolkit that can be adapted to the specific organisational needs, where it is to be applied and then having a strong capability to facilitate adoption of this framework across the organisation. 

Invest carefully in organisation-wide platforms

Having read the last two points you may think I'm arguing against any type of standardisation. I'm not. There can be great value in adoption cross-organisational platforms in the data domain as long as you're realistic in your expectations and careful in your investment. For instance standardising and consolidating customer or product data has been shown to generate huge benefits in many organisations. A data warehouse or MDM solution can be a valuable investment even if the data in it isn't always quite up to date or of perfect quality. The point is that (once again) you have to deal with the reality that there are already lots of (complex) solutions in use across your organisation, sanctioned or unsanctioned, and that rolling out an organisation-wide platform puts you into automatic competition with a lot of existing investments and unless you've got the CEO standing behind you shouting at people to get things done that inertia can be quite difficult to shift. That means you have to be able to demonstrate value quickly and have very strong change capabilities in your team or you might as well not bother. 

Clarify organisational interfaces

One thing you definitely do want to standardise are the interfaces between organisational units. As I've said above, you have to deal with the fact that different parts of the organisation will have different toolsets and processes internally, however when it comes to exchanging data or processed analytical information between units you don't want there to be a lot of flexibility. It's easy for organisational systems to break down at the boundary. That's how you get silos. You don't want silos. (Yes, I know, easier said than done). Data and analytical products is one important part of cross-organisational working and you want to be quite rigid about how it is to be shared. Ideally data should be interchanged using a few standard formats and analytical information shared using a single common tool. This allows units to work effectively internally, but without having communication falter at the organisational level.

Build capability strategically

There isn't a single pattern that will guarantee successful deployment of capability in the sphere of data analytics. Some organisations focus capability in a center of excellence; others embed data scientists in the business teams they work with. Some do a little of both. Some organisations train a large user base in analytics; others have a central team servicing requests from the business. Some do a little bit of both. You probably already have a lot of analytical capability spread across the organisation. That is a good thing, it gives you something to build on. Fundamentally, you have to think about how and where you build capability in the context of the organisational structure and culture that you have and the existing levels of capability across the organisation. Don't assume that hiring a bunch of smart data scientists, analysts or programmers will solve the problem. You'll probably need some, but how to embed them in your organisation is anything but trivial.

Don't underestimate culture

Finally, and this may be the most important point here, using analytics effectively is most of all a cultural issue. If your employees don't buy into the values of data-driven decision making, wouldn't trust a machine learning algorithm to make a decision for them to save their life, or think that reports are mainly there because some manager asked for it to be produced seven years ago then it will be extremely hard to make anything more than point improvements. If you're looking to include data analytics as a key part of your strategy going forward, it therefore makes sense to start with communicating it clearly and repeatedly and taking the other necessary steps to prime the organisation for the change. Cultural change is hard and takes a long time, but it is essential if you want to make significant gains at the organisational level from these technologies. Otherwise, you may want to acknowledge that this path isn't for you, pay some lip service, run some pilots, and then move on.