Data Analytics (DA):

Data analytics (DA) is the process of examining data sets in order to draw
conclusions about the information they contain, increasingly with the aid of
specialized systems and software. Data analytics technologies and techniques are
widely used in commercial industries to enable organizations to make more-
informed business decisions and by scientists and researchers to verify or
disprove scientific models, theories and hypotheses.
Data analytics initiatives can help businesses increase revenues, improve
operational efficiency, optimize marketing campaigns and customer service
efforts, respond more quickly to emerging market trends and gain a competitive
edge over rivals , all with the ultimate goal of boosting business performance.

Types of data analytics applications

At a high level, data analytics methodologies include exploratory data

analysis (EDA), which aims to find patterns and relationships in data, and
confirmatory data analysis (CDA), which applies statistical techniques to
determine whether hypotheses about a data set are true or false. EDA is often
compared to detective work, while CDA is akin to the work of a judge or jury
during a court trial.

Data analytics can also be separated into quantitative data analysis and
qualitative data analysis. The former involves analysis of numerical data with
quantifiable variables that can be compared or measured statistically. The
qualitative approach is more interpretive. it focuses on understanding the content
of non-numerical data like text, images, audio and video, including common
phrases, themes and points of view.

Data analytics initiatives support a wide variety of business uses. For

example, banks and credit card companies analyze withdrawal and spending
patterns to prevent fraud and identity theft. E-commerce companies and
marketing services providers do clickstream analysis to identify website visitors
who are more likely to buy a particular product or service based on navigation
and page-viewing patterns. Mobile network operators examine customer data to
forecast churn so they can take steps to prevent defections to business rivals; to
boost customer relationship management efforts, they and other companies also
engage in CRM analytics to segment customers for marketing campaigns and
equip call center workers with up-to-date information about callers. Healthcare
organizations mine patient data to evaluate the effectiveness of treatments for
cancer and other diseases.

Many businesses are turning to data analytics to provide insight for making
operational decisions. Two areas in particular where data analytics can help
companies is (1) improved service delivery to customers, and (2) more efficient
and effective resource allocation. To arrive at actionable insights, the analysis
often relies on multiple data sets of varying size and content. In this article, we
will discuss one simple example where data engineering, data analysis, and the
merging of two data sets can help a company in both the above areas.

Business Outcomes Improved by Data Analytics

Because data analytics focuses on developing solutions, its an ideal tool to

help businesses solidify their market reach and develop new products. But many
explanations of data analytics focus on technical components instead of on your
business.
Data analytics should start with your business. Its a tool to help you
capitalize on opportunities and identify weaknesses.

Examples of the types of problems that data

analytics can help to solve:

Identifying your most profitable customers and figuring out how to

serve them better
Finding new revenue opportunities
Creating strategies to reduce fraud and theft
Managing business risk by connecting information with the
departments that benefit from it
 Identifying new customers and how to reach them
Finding emerging trends and determining how to take advantage of
them
Identifying unmet customer needs
Improving the effectiveness of services
Optimizing supply chains and development processes
Creating new business models

Answering these questions can make a big impact on your business , And
because the tools and techniques used in data analytics are advancing constantly,
new applications for data analytics are always being found.

Data Analytics In Operational Management

Operational analytics is a more specific term for a type of business analytics

which focuses on improving existing operations. This type of business analytics,
like others, involves the use of various data mining and data aggregation tools to
get more transparent information for business planning.

Within the general category of business analytics, the subjective definitions

of a number of similar terms make it difficult to concretely define the boundaries
of operational analytics. Many professionals within the industry use this term to
refer to analytics that is done "on the fly" or in real time observation of business
processes. In the planning and analytics world, there is the idea that in
operational analytics planners are looking at how specific business operations
work on a daily basis and coming up with quick solutions for change.

Businesses can pursue operational analytics in many different ways.

Different software packages will offer various models for showing what happens
within a business, in real-time or over a specific time frame. Many of these tools
will provide visual models. For example, businesses may be looking each day at
how many customers look at or buy a particular product in an e-commerce store.
Operational analytics tools may graph or chart these customer events in a visual
way to allow human decision-makers to see whats really going on.
 In general, operational analytics and other business analytics support the
idea of enterprise resource planning, where software systems aggregate
information across a complex enterprise in order to enhance communications
between stakeholders, streamline or optimize business processes, and give
leaders a better idea of how to chart a course for the future. Again, with
operational analytics, experts in the field will have specific guidance on how to
perform quicker or more targeted analysis and use of the valuable information
thats provided by operational analytics software.

Three things make operational analytics tough. One is that to make it work,
you have to integrate it with transactional or workflow systems. Two is that you
often have to pull data from a variety of difficult places. And problem three is that
embedding analytics within operational processes means that you have to change
the behavior of the people who perform that process.

Integration
Unfortunately, to succeed with operational analytics, a company has to
combine transaction systems, workflow systems, analytical systems, databases,
and display/user experience tools. Integrating with transactional systems takes a
good deal of effort, although modern systems architectures make it a bit easier.
Most transactional systems these days (including SAP and Oracle ERP systems)
allow API-based connections. But there is usually a fair amount of effort involved
in integrating an operational system sucking out the data you need, doing the
analytics somewhere (the cloud, in-database processing), and embedding the
result into an interface for the front-line user.

You might be able to accomplish much of the integration with a workflow-

oriented overlay tool like case management, business process automation (BPA),
or robotic process automation (RPA), although those types of systems generally
dont do any analytics. That means that human labor your organizations or
some from an external services provider will be required to combine workflow
and analytics.

Various Data Sources

Problem two is getting all the needed data. That can be handled fairly easily
if the data is in an information system and its in some sort of accessible format.
But in many cases, the data is in a variety of formats from paper reports, PDF
files, unstructured articles, or medical records, etc. In order to get that kind of
data into your operational analytics system, you need more than analytics you
need artificial intelligence. including a computational-linguistics engine, a
decision-tree engine, a business-rules engine, and so forth to rapidly develop
intelligent applications.

Changing Behavior

Finally, there is the need to persuade front-line users to change their

behavior toward decisions and actions based on operational analytics. A next
best offer system for bank tellers, for example, has to persuade the teller to
actually use the recommendations in working with customers. They wont employ
analytical recommendations if they dont trust them.

To build such trust, transparency of analytical recommendations is a key

factor. If the reason for the recommended product or action cant be described in
understandable language, the user wont be able to assess whether it makes
sense. That requires some sort of natural language generation capability to
describe the decision logic. It doesnt favor many machine-learning approaches to
analytics, because most of the time there is simply no way to describe or interpret
why a particular model prevails in a machine-learning process.

What organizations embarking on operational analytics are learning is that

analytics itself is the easy part. There is no shortage of available vendors, both
proprietary and open source, of analytical algorithms. But building an operational
analytics system means integrating and changing existing architectures and
behaviors, and thats always the hard part. Its well worth the trouble, however,
to build applications in which analytics and smart decision making are embedded
in a companys systems and processes.
Use case: Scheduling 24-hour support staff
Many companies provide ongoing support for their products and services.
This support often requires a round-the-clock team of support technicians and
engineers to quickly respond to issues as they arise. Depending on how customers
use the product and their geographic locations, however, it may be difficult to
appropriately schedule support staff across the 24-hour period, leading to the
possibility of overstaffing or understaffing during any given period.

Making appropriate support-staffing decisions, however, speaks to both

critical operations areas noted above. Understaffing can lead to delayed response
times when issues arise, reducing the quality of customer service. Overstaffing
indicates that resources are being underutilized, adding unnecessary costs.

A straightforward approach to making staffing decisions might involve

estimating a couple of metrics: (1) the baseline productivity of a single staff
member (e.g. how many tickets can a staff member respond to in a given period
of time), and (2) any temporal patterns to when tickets are generated (e.g., is the
ticket generation rate different by hour of day or day of week).

But these metrics can be difficult to determine without complex data

analysis, and using them in a straightforward way may also require making several
simplifications and assumptions. An alternative approach is to examine patterns
in the metric of interest and make scheduling adjustments based on that metric.

Measuring responsiveness
A good metric for support staff responsiveness is the amount of time it
takes for a support technician to take a first action in response to a service ticket.
In this scenario, we are imagining that issues are raised through a software
interface that generates a service ticket and that the entire service team has the
ability to respond to tickets in the service queue. The goal of the analysis, then, is
to understand how this metric varies by staffing level and determine if any
adjustments need to be made.

Preparing the data

For a software ticketing system like the one described above, service tickets
may be stored in a historical time series that produces a record each time an
action related to the ticket is taken. If the data are stored in a relational system,
these historical records may also connect to metadata related to the ticket, such
as the entity that opened the ticket, and further details about the ticket.

Regardless of the complexity of the database, however, it should be

possible to join and query the database system to obtain a single time series table
where each record contains the following information: ticket ID number, time of
action, and action taken. Depending on the specific problem, there may be
important metadata that should be included to further segment the data, such as
the type of ticket; but for this example, we will assume the simplest case, where
all ticket types can be treated the same.

The data table stub below shows a sample of what such a time series table
might look like

Ticket ID Time Action

TKT101 April 4, 2016 01:03PM GMT Created

TKT101 April 4, 2016 01:06PM GMT Modified by Technician

TKT102 April 4, 2016 01:13PM GMT Created

 TKT103 April 4, 2016 01:14PM GMT Created

TKT102 April 4, 2016 01:17PM GMT Modified by Technician

TKT104 April 4, 2016 01:17PM GMT Created

TKT104 April 4, 2016 01:21PM GMT Modified by Technician

TKT105 April 4, 2016 01:22PM GMT Created

TKT106 April 4, 2016 01:22PM GMT Created

Using these data, we can derive another data set that gives the amount of time
elapsed between when a ticket is created and the time of first action. These
derived data (sample shown below) will serve as the basis for our analysis.

Ticket ID Time Created Time to First Action (Min)

TKT101 April 4, 2016 01:03PM GMT 3

TKT102 April 4, 2016 01:13PM GMT 4

TKT103 April 4, 2016 01:14PM GMT 10

TKT104 April 4, 2016 01:17PM GMT 4

TKT105 April 4, 2016 01:22PM GMT 5

TKT106 April 4, 2016 01:22PM GMT 6

Aggregating the data

We can aggregate the data in several ways to obtain useful insights into
support operations. To answer the initial question we posed about whether
support staffing levels are adequate, we would aggregate the data by determining
the average time to first action for tickets created during each hour of day. Since
staffing schedules may change periodically, often on a monthly basis, we also limit
the analysis to tickets created during the specific period of time when a particular
schedule was in effect.

This plot shows the average initial response time, by hour of day that a
ticket was created (in red). For comparison, we also show the average number of
tasks opened, by hour of day (in blue). The black dashed line shows the number of
support staff working during each hour of day. Perhaps the most striking feature
of this plot is that large increase in response time for tickets opened between 16h
to 19h (4 p.m. to 7 p.m.); this increase also coincides with a drop in staffing levels
from three people to one person.

The immediate implication, based on a qualitative visual examination of the

above chart, alone, is that staffing levels should be increased during the 16h to
19h period. It is interesting, however, to examine this a bit more quantitatively.

Initial response time vs. ticket creation rate

We might expect there to be a relationship between the average initial
response time and the average numbers of tasks that are generated at any
particular time. The plot below shows, for each hour of day, the average response
time compared to the average number of tickets created (indicated as green
dots).

The black dashed line shows a linear fit to these data, used to determine if
there is a trend in this relationship. There is also a significant outlier
corresponding to the 18h to 19h period, with an unusually high response time. If
we remove this point when performing the linear fit, we obtain the trend shown
in the solid black line. After removing the outlying point for either fit, does not
indicate a substantial difference (1.4 versus 1.5), and its also apparent by visual
inspection that neither fit provides much predictive value.

For example, based on the fit alone, we might expect that at no ticket
creation rate below 4/hr should we expect the initial response time to exceed five
minutes, but the data clearly show five hours of day when the response time is
greater than five minutes.
Initial response time vs. staffing level
Another relationship we should examine is between the staffing level and
the average initial response time. The plot below indicates a much more apparent
trend where the higher the staffing level, the shorter the initial response time. For
each hour-of-day, the blue dots show the average response time for any given
staffing level. Once again, we perform a simple linear fit to the data with (dashed
black line) and without (solid black line) the outlier corresponding to the 18h to
19h block.

In this case, removing the outlier does appear to have a more significant
impact on the trendline, though the predictive value of both fits are similar. To
use the example above, both fits would suggest that keeping the minimum staff
level at three people or more would result in an average initial response time
below five minutes. There are only two hours of day where these models are
incorrect (11h to 12h and 13h to 14h), and in both of those cases, the average
response time is still below six minutes.
 Given this trend, the longer initial response time during the 18h to 19h
block is less surprising, though this hour remains a significant outlier. To better
understand this, we can go back to our initial plot, which showed the data as a
time series. When we do so, it becomes obvious that the increase in initial
response time occurs during the final hour of a three-hour block, where there is
only one person staffed. Analysis of additional data concerning the other duties
the support staff are attending to may offer better insight into this outlier. Initial
hypotheses, though, could be that either the staff member on duty begins to feel
fatigue during her third hour alone, slowing down her overall performance or she
develops a backlog of work from her competing responsibilities, which slows
down her initial response time.

The analyses we have already discussed above, however, suggest that to

make an improved staffing decision, the support operations manager does not
need to understand the cause for the 18h to 19h block outlier. Increasing the
staffing level to two or three people during this period is likely to reduce the
overall initial response time. If the manager sets an initial response time target of
around five minutes, these analyses also suggest that the team is overstaffed
during the 1h to 8h block, when there are four or five staff members on duty.
Rescheduling these staff to later parts of the day will likely reduce the average
initial response time overall, and significantly improve the response time during
the 16h to 19h block.

Making better decisions

Data analytics offer powerful tools for helping a company make better
operations decisions. In particular, combining data from multiple data sources
and applying time-series techniques can provide deep insights into a companys
operational strengths and weaknesses. In this example, we have shown how
combining straightforward analyses of a companys ticket management data with
information about its staffing scheduling can help a support operations manager
make better staff scheduling decisions.
References:
1.http://data-informed.com/effective-operational-analytics-is-about-more-than-analytics

2.https://www.techopedia.com/definition/29495/operational-analytics

3.https://www.slideshare.net/OracleAnalytics/optimizing-manufacturing-operations-using-big-
data-and-analytics?qid=8e2d5f5c-7fd3-448b-b0c7-66fd9edff778&v=&b=&from_search=3

4.http://searchdatamanagement.techtarget.com/definition/data-analytics

5.https://www.oreilly.com/ideas/improving-operations-using-data-analytics