Embedded Analytics

Chapter 1. Introduction to Embedded Analytics

Most of us are familiar today with business intelligence (BI). At one time it was a new and exciting capability, but now—thanks to self-service technologies, the cloud, and the power of in-memory processing—richly featured analytics applications, data visualizations, reports, and dashboards are available to almost any business user who wants them.

However, all of these capabilities typically depend on separate applications. To perform business analysis, you need to open your BI suite. If you want to create a special chart, you use a data visualization application.

Embedded analytics takes a somewhat different approach. The aim of embedding is to integrate visualizations, dashboards, reports, and even predictive analytics or artificial intelligence capabilities inside your everyday business applications. Then, if you are managing a production line, preparing a budget, or reviewing HR issues, you can have analytic insights on hand to guide you.

For a business user, this means that the analytic process takes place in the context of a business process. It also means that the data and the analytic experience become part of your everyday work. This makes analysis more accessible to a business user.

In this chapter, we will review some of the benefits of analytics for enterprises, and we’ll also consider what makes for a successful implementation. With that knowledge, we will look at how we could map out a strategy to take us from our current situation to being a more fully informed, analytics-driven enterprise.

Analytics for Business Users and Consumers

There are several advantages to embedded analytics that business users and IT teams appreciate.

From the point of view of an IT team, which is concerned with issues such as security and data governance, embedding your analytics in another application that is already secure has a simple but significant benefit. There is only one environment and one login to be managed; the analytics application does not add an additional layer of complexity. We will look at this topic in more detail in Chapter 6.

Business users will be most familiar with their existing operational applications. Embedding analytics in this well-understood environment affords a nonspecialist user insights and information in a way that works with their existing skills and practices.

In addition to being familiar, it is also more efficient to embed analytics in a commonly used application. If we need to switch from our working application to an analytics application, we interrupt our workflow; we have to open and navigate to another application and may lose focus while we’re doing it.

How does this work in practice? In a call center, an operator taking customer calls for support can see on one screen not only the customer record, but also (thanks to the embedded analytics) trends and patterns related to this and similar cases. These patterns (perhaps the customer is calling increasingly often over time) may prompt the operator to route the call to a specialist who can better diagnose and resolve the underlying issues. The result should be a better resolution for the customer and more efficient handling by the call center.

Another example might be a salesperson on the road with an application that helps them select the next customer to visit and optimize the offers they make. They could see, embedded in that application, even on a mobile device, recommendations driven by machine learning.

Other applications may sound more advanced, but in principle are very similar. A doctor may use an embedded algorithm to assist with diagnosis. A production-line manager in a busy factory may need to compare the performance of different machines to see where improvements can be made. An HR person, interviewing an employee with performance issues, may need to compare the employee’s work and achievements with those of peers within and across organizational boundaries to suggest a best course of action.

Embedded Analytics for Consumers

We can see some of these principles not only in our work but in our personal use of technology as consumers. Although we grapple with a different set of challenges, as consumers we still make decisions and take actions. As our consumption increasingly moves online, so do our decisions and actions. In ecommerce, you expect to be given recommendations of products that may interest you, the famous example being “customers who bought this also bought that.” These recommendations are in fact analytics, embedded inside the web experience of the ecommerce site. We don’t think, when browsing for books or clothes online, that it’s an analytic experience. Yet analytics are driving our interactions in a way that is so seamlessly embedded, we don’t even notice it.

The same is true if we’re watching movies online. Our watch list likely includes recommendations made by the artificial intelligence engines of the streaming company. Again, the analytics are there, but seamlessly embedded.

In business we often want to be making decisions that are consciously data-driven. Some users are very interested in their data and like to explore it and make new findings. However, we can learn from a consumer experience when we’re dealing with users who must make operational decisions very quickly with the least possible distraction. In that case, an alert or a recommendation can be served up without drawing unnecessary attention to the analytics behind it.

So, one thing we need to think about with embedded analytics is what we’re trying to achieve. Are we looking for a simple business outcome? Or are we informing a user with an analytic experience that enriches their use of data, their analytic thinking, and their understanding of the business?

What Success Looks Like

Our discussion so far suggests that what makes for a good embedded analytics experience is variable. In many cases, the best analytic experience will be one that is more or less invisible to the user, like the recommendation engine.

In other cases, we wish to prompt the user into a mode of analytic thinking. Having the analytics or data visualizations right there where they are currently working makes that process more seamless, and, we might hope, will also make it more effective.

So, in each case, there’s a slightly different measure of success. For some scenarios we have specific business goals to achieve, but often we just want people to be better informed in their work.

Measurable Business Outcomes

Ultimately, in the business use case of analytics, the business outcome should be straightforward in principle: we make better decisions. Therefore, the most important outcome for embedded business analytics should be smarter, more effective, more impactful business decisions.

Perhaps not surprisingly, measuring a “decision” can be tricky, but in general we should be focusing on a business outcome. For example, we may be looking for increased sales numbers, lower costs, or improved customer satisfaction. Those are the ultimate measures of the success of our process, although it may be difficult to draw a clear line from one decision to the overall outcome.

There are also measures of the process itself: for example, how quickly a decision can be made, how quickly we can process an order, or how many customers or clients our call center can deal with in a day. If we have a recommendation engine, we can measure how often the recommendations are actually accepted, and whether that leads to an increase in sales.

Always, it’s important to measure an outcome in terms that makes sense to the business. Simply measuring the process itself doesn’t tell us much about its ultimate effectiveness.

Engagement and Adoption

There are important ways in which the process of analyzing can have business advantages in itself, however tricky to measure. Among these merits are the engagement of the user with data and the adoption of analytics software.

Industry analysts often say that business intelligence software only reaches between 25% and 30% of business users. BI software vendors have struggled for over 20 years to increase user adoption. However, the vendors themselves are perhaps part of the problem! It’s time to recognize that one of the barriers to adoption is the nature of their specialized tools, requiring a business user to drop out of their business experience and into an analytic experience. This breaks their workflow and disrupts, rather than deepens, their thinking.

Vendors are beginning to realize that one way to increase adoption of and engagement with their software is to embed it in a tool that people already know and use. The advantage of more engagement and adoption should be that your business decision-makers are better informed. We might also hope that business users take an interest in the data, sharing tips and tricks and insights with other users.

Even though engagement and interest may not factor directly into decisions business users make, having greater situational awareness of the business environment, and of the current situation and trends within their department or company, should help. In fact, sometimes we should be wary of putting precise metrics on these outcomes because there’s a common habit of managing to the metric, where we focus too much on narrow measures of business value and miss the bigger picture.

Engagement and adoption may also add value through increasing employee satisfaction by giving a broader understanding and adding more business context to what may be a narrowly focused task.

Spreadsheets and Analytics

We have mentioned before that it’s important for embedded analytics that the new features live within already familiar software. For many of the people with an interest in analytics—such as financial analysts, marketers, and sales operations staff—their daily work involves a lot of spreadsheets. In fact, for many business people, the spreadsheet is their default analytics tool. Even when they have reports and dashboards, they will often reach for the “export” button so they can load the data into a spreadsheet and do new work.

We don’t want to break that paradigm; it’s reasonable to recognize that spreadsheets are extremely powerful, flexible, and simple to use. Most people learn to use spreadsheets, including quite advanced features, without any training. So there’s definitely a case for embedding analytics into spreadsheets, or extending spreadsheets with analytics.

One way of doing this is simply to provide better visualization features than a spreadsheet can offer natively. Or, we extend the spreadsheet’s functions with new capabilities, often integrating with external—and more powerful—analytics engines, especially to handle more data than spreadsheets are designed for.

Another approach is to accept the capabilities, simplicity, and limitations of spreadsheets, but then embed your calculations into another application. For example, you may be able to build a useful mortgage and loan calculator in a spreadsheet (a common scenario for a financial advisor), but with the right tools, you could embed that calculator in a web page or another application, so that your existing or potential clients could use it easily when they browse your site.

It’s a little secret of business intelligence vendors, especially of self-service BI apps, that their number one data source is actually not the enterprise data warehouse or cloud applications but the traditional spreadsheet, where the data already exists, and where users can do a lot of the shaping and reviewing of data that’s necessary before they build an analysis tool.

Later, we’ll talk about several of these scenarios in more detail.

A Game Plan for Embedded Analytics

It may be tempting just to dive into embedded analytics and start inserting charts and visualizations and recommendations throughout your operational systems, hoping to inform your users better. Let’s not rush into it! We need a strategy.

We think of this as being more like a game plan than a traditional roadmap. By a game plan, we mean the sort of strategy that a football or basketball team learns before going into a game. They know the strengths and weaknesses of their opponents and their own team. Therefore, they can work out a rough plan of how they’re going to approach the problem and how they might respond to developments during the course of the game. But, of course, they never know exactly what’s going to happen. They certainly can’t predict if the other team is going to have a good or bad day. Maybe this is the day their opponents are at their best, or the day on which they stumble and fall at every opportunity. So any plan must be flexible.

Our goal with a game plan is to give businesses a strategic tool with which they can set a course for a specific technology—in this instance, embedded analytics—while being flexible in how they get there. The first step is knowing where you are starting from.

Understanding Where You Are

The first step of a game plan is to orient yourself, taking stock of your current capabilities, data assets, skill sets, and demands. It’s fair to say that when we look at traditional maturity surveys of an entire business, they try to give a single answer that will apply across departments, but that is often too broad a measure to be useful. Different divisions and departments have varying strengths and weaknesses, skills and practices, and indeed, in many enterprises today, tools. They may even have different platforms, especially in businesses that have grown by merger and acquisition.

So step one in designing a game plan is to understand where we are, remembering that organizations can be internally varied and complex, and that each team or department may give different answers.

Setting a Goal

Step two is setting a goal. The same principle, that there is no one-size-fits-all strategy within a company, is true for goal setting too. The manufacturing team or the production team may well have a different level of analytics maturity than the sales and marketing team. So we need to understand not only where every team starts from, but where it needs to end up. What different departments want to achieve with analytics will also differ.

Now you can see why we need that strategic flexibility. Not only is the route from our origin to our destination going to be different between teams, but as we implement tactical solutions for each team, there are likely to be synergies and intersections (and conflicts!) along the way.

So we have unique starting points, varying ending points, and different journeys.

Mapping Out the Journey to Success

The journey that we take from our present situation to our goal can be quite long. It’s important, therefore, that we break that journey up into achievable steps.

We strongly suggest that you identify a series of projects, each one taking not more than one business quarter, and define them in such a way that even if you only complete the first one, you will have achieved something. Every step should deliver business value and be in many ways complete in itself. This achieves two very important goals.

The first is that you’re constantly adding business value. If for some reason the project has to pause, or even if the project is canceled, you have still achieved concrete goals.

The second is that this continuous process of adding value encourages engagement and adoption with business users because they see the value being added. This approach also increases the commitment and sponsorship of business executives who see progress and a return on investment.

It is much more satisfying to see new features and new capabilities becoming available every quarter than it is to have to wait for a whole year. In the world of embedded analytics, it is straightforward to identify more concrete, less abstract steps that make up this incremental game plan.

However, before we start discussing the architecture and development of embedded solutions, we need to understand a little more about the decision-making process that we are trying to improve. We’ll explore this topic in the next chapter.