Broadly speaking, the field of Analytics entails the discovery, interpretation, and communication of meaningful patterns in data.
Here at inlumi, the analytics team focuses mainly on the financial analysis of our customers' data. Our main source of data is the sales data warehouse but, as we will explore in upcoming blog posts, it's important to combine multiple data sources to form a complete analysis.
Traditionally it's been the financial controller's job to do data analysis in this space, but as the data volumes and processing power grows, so does the job description. Today financial controllers, data analysts and data scientists analyse data, all with their unique motivations and goals.
The goal of data analysis in the financial sector is to explain outcomes and identify areas of improvement. When sales are high, it's good to know why they're high and if they could be increased even further. When sales are low, it's good to know why they're low, identify business areas and products that are underperforming and pinpoint which efforts might give the most benefit.
The first part in the analysis is the discovery phase. This, of course, means that the analyst needs access to the data. One simple way is to get data extracts from the database department. This method is slow and cumbersome since the analyst doesn't have direct access to the data source and has to work through a proxy.
Another way is to get direct access to the SQL query engine. This method is better but is more technical since it requires SQL programming knowledge. This in itself is not a big hurdle since SQL is a fairly simple query language, but ideally, the analyst should have access to a tool which allows for simple graphical data exploration without having to bother with the technical storage implementation.
Data interpretation is an important area in data analysis. This is where data completeness and combining multiple data sources comes into play.
If a retailer sees that the profit for a period was unusually low, it could have been caused by different factors. Did the competition have better marketing or a better campaign? Did the retailer actually sell all of its stock or was the shortfall due to missing shipments? Was the profit low because of high personnel costs?
The analyst needs to fetch data from the sales database, the marketing database, inventory database and the HR database. Ideally, all of this data should already have been collected into a common data warehouse. Looking at these data sources in isolation can only get you so far, and it's when data sources are combined that they really start giving insight and value.
It's important that members of staff use the same data interpretations and data definitions. The business analysis tools should ideally enable people to share analyses with each other and should enable businesses to keep a central repository of common definitions and key metrics.
We could take the definition of a customer for a pharmaceutical company as an example. Is the customer: a) the wholesalers that distribute the products, b) the pharmacies that sell the product over the counter, c) the doctors who prescribe the products, or d) the people who consume the product? The answer will vary depending on who you talk to in the organisation, and it's the analyst's job to disambiguate the terms, to establish a common interpretation and to facilitate good communication.
Communicating analysis results can be a challenge, and the design and method of the communication varies from case to case. The requests for dashboards that we usually get from customers often fall into one of two categories:
- A list of dimensions and metrics.
- A giant table with everything but the kitchen sink.
Ordering a list of dimensions and metrics in a dashboard is like going to a car dealership and asking for a black car with four wheels, a steering wheel and high performance. There's a lot of information missing. If you asked me to design a car by those criteria, I would design something like a Lamborghini. But transporting your kids to school would be difficult since you would only have two seats. Buying things in bulk and transporting it home would also be difficult.
Ordering a giant table with all kinds of data is not good either. At some point the amount of data on the screen gets overwhelming and your end users fail to see the insights. This is a bit like going to the car dealership and ordering one car of each model since you don't really know what you want to use it for.
Things to take into consideration are:
- Who will receive the result?
- How often will they receive the result?
- Why do they need the result?
- What will they do with the result?
- Do they need a short status or a detailed analysis? Something in-between?
- Will they read the result in an email, browser, paper, computer, phone?
- How much time do they have to analyse the result?
In some cases, the end-users want complex dashboards with huge volumes of data because they have the time and the expertise to analyse it. In other cases, end-users could be very busy people who don't have time to delve into the details unless they know that something is wrong.
I've actually created a dashboard which simply showed green, yellow or red emoticons (the red being really angry) to the store management. If the status was red or yellow, they would look into the details behind the result. Communicating complex findings in a way that is intuitive and simple to understand is a vital skill for a data analyst.
This was simply an introduction to the field of analytics and we will look at different aspects of data analysis in this new blog category. The art of data analysis is a combination of technical, analytical and communication skills.
Analytics at inlumi
One of our focus areas at inlumi is Business Reporting and Analytics. With this blog post, we have launched a new blog category which focuses on Analytics. We will cover high level concepts and market trends and dive deep into technical topics. Keep your eye out for more Analytics blog posts in the future, or subscribe to our blog!