Two questions that will have definitely surfaced in our thoughts are as follows:

Lets see how this will be helpful. While solving a problem, understanding the current state of the problem is essential for the analyst. Whenever we solve a problem, we would always prepare for the next state of the problem life cycle knowing that change in the problems current state is inevitable. If the problem is currently in the clear state, then the amount of time and effort we would invest as a data scientist would be considerably less than if the problem would have been in the muddy or fuzzy stage. However, the problem remains for the least amount of time in the clear stage. The jump from clear to muddy is shorter compared to any other transition in the problem life cycle. Being aware about the problem life cycle, an organization/data scientist would then prepare better for radical changes that are bound to happen in a short while. We would need to design our solution to be agile and prepare for the next change. Similarly, if the problem is in the fuzzy stage, a lot of our solutions will be designed in such a way that they can be productized for a particular use case or industry. Finally, when the solution is in the muddy state, our solutions in problem solving will be more of a service-based offering than a product. The amount of experiments and research that we would need for the problem to be solved is highest in the muddy state and least in the clear state:

The problem life cycle in brief

So how does this relate to IoT and Decision Science and the intersection of the two? Decision Science has been a bit more widespread and prevalent in the industry than IoT. There have been tons of experiments and research conducted on data to find insights and add value that make Decision Science currently in the fuzzy stage. IoT, on the other hand, is fairly new and requires loads of research and experiments to get tangible results, which makes it in the muddy stage. However, when we talk about the intersection of the two, we are dealing with a set of interesting problems. On one side, we have a fairly mature ecosystem of Decision Science that has given tangible value to the industry through its experiments whereas IoT is still nascent. The intersection of the two is a very promising and lucrative area for business. It is in a position where it is steadily moving from the muddy to fuzzy stage. Very soon, we will see tangible results from large-scale IoT use cases in the industry that will immediately trigger the revolution for productization on Decision Science for IoT. Decision Science for IoT is rapidly being experimented and the initial results seem to be very promising. The era, where Decision Science for IoT will be in the fuzzy state, is very near.

With this in mind, we can now get to the basics of problem solving while being prepared for the use case to evolve into a fuzzy state. With the understanding of the problem life cycle concrete, lets now explore the problem landscape in detail.

What is the problem landscape? Why do we need to bother about it?

A simple answer would be, understanding the current state of the problem is just one dimension, but understanding the type of problem is a more essential part of problem solving. Lets make this simple. To understand the problem landscape, refer to the following image and try to visualize the problems on two dimensions-frequency and impact. Just like any other scatterplot, this one can also be divided into four major areas:

Apart from these four components, we can identify one large spot/circle that has a flavor of all these areas. Here, the problems can be with a high or low frequency and also a high and low impact. So we name it the Region of Uncertainty:

The Region of Uncertainty

Lets understand what kind of problems appear in each of these boxes. Every organization will have a plethora of problems; some of them occur very frequently and some of them very rarely. Some may have a huge impact whereas some may have a small impact. Consider a large organization with hundreds to thousands of employees. There are a couple of problems where the frequency might be low and impact might also be very low. We would generally tend to avoid solving these problems as they are not worth the effort. Some problems, even though they may have a low impact, might have a huge frequency. They would mostly happen on a daily basis. These problems are solved with the typical IT solution approaches such as Support for Technology Infrastructure, CRM, attendance management, employee leave application portal, and so on. There are some problems where the impact will be extremely huge, but the frequency will be extremely low. Events such as making the company public, acquiring a new company, or changing the business model would happen probably once in a lifetime or once in a few years. These problems can be solved from a consulting approach. Then there is one class of problems that has an extremely huge impact and occurs very frequently, for example, a pricing model for Amazon, Google's page rank algorithm, Search Engine Optimization, and others. These problems again require a completely different approach to solve. Here, we would need an approach that would be a combination of heuristics as well as algorithms blended with products.

Apart from these four obvious types of problems, we will have a special set of problems that has a flavor of all these types: moderate problems. Here, we might have a moderately good impact and frequency. Solving these problems requires a special approach. These are neither completely heuristic-based nor completely algorithmic. These are sweet spots for businesses where the tangible results can be experimented and validated very early and many companies can target for conceptualizations to deal with specific areas of the problem landscape:

The problem landscape

When we explore the sweet spot, that is, the Circle of Uncertainty, we find that the problems again are of a different nature. They could be any one of the following:

To understand the nature of the problem, we basically try to ask what question is the solution answering. It could be what, how, when, why, and so on. Lets understand this better with a simple example.

Consider a Loyalty Program launched by a retail giant such as Walmart, where customers can use a Loyalty Membership Card to earn and burn cash points on each transaction. For simplicity, lets assume that the campaign ran for around three months and the Director of the Loyalty Program would like to know the answers to a few questions.

He would first like to know what happened?

This means how many people enrolled, how many transactions were recorded, how many products were sold, how many points were earned or burned, how much profit was earned during this season, how much revenue was generated, and so on. We basically get into the details of what happened during the period.

The nature of the problem that we are trying to solve here is Descriptive. The entire solution can be captured by asking one question-What happened?

Once he has a fair understanding of what happened, he would want to know about-Why it happened in a few scenarios. For example, he will have observed that sales from one particular geographical location, say Texas, have not increased in spite of the Loyalty Program, so he would like to understand specifically, why did that happen? Here, the problem solving will focus on understanding the reasons for no increase in sales in the Texas area when other areas have performed much better. We would then try to understand the Why question by digging deeper into the problem. We may study the offers that were rolled out to Texas compared to other regions or analyze how targeting customers and marketing campaigns differ between them and so on.

Here, the nature of the problem would be Inquisitive. The entire solution can be captured by asking one question-Why did it happen?

After understanding the reasons for why the event happen, we would probably want to take precautions to avoid failure due to the reasons found. Say, we found out that due to bad services, a lot of customers churned out to other competitors. We would then try to understand more about customer churn propensity where we would like to predict when the customer might churn out, so that we can take preventive measures to keep the customers happy.

Here, the nature of the problem would be Predictive. The entire solution can be captured by asking the question-When will the event happen?

Finally, once we have a complete picture of the series of events that happened and why and how it happened, we would like to take corrective measures to mitigate the perils of the event. So we would then ask Now what/So what, where we would try to seek guidelines for corrective actions. For example, we might have observed that due to bad service, a large number of customers churned out to other competitors and we would like to run customer retention programs and campaigns that could win back the churned customers.

Here, the nature of the problem would be Prescriptive. We can understand the entire solution with the question, Now what/So what?

To understand the nature of the problem better from an IoT perspective, consider the following example of an Oil and Gas Industry. Lets say that Shell, a leading oil company, has subsea operations set up in one of its prime locations. It would then deploy tons of machinery for the operations in order to extract oil from the reserves. In the IoT ecosystem, all the machinery or assets here would form a connected network where machines are equipped with a variety of sensors that can capture information about various real-time parameters and communicate to other machines and a central server. Assume that you are now the Operations Head for the plant and you are entitled with the responsibilities of executing the operations smoothly and effectively. As the head of Operations, at the end of the day, we would like to know what happened during the day in course of the oil extraction process. This would be answering the question, What happened? We would basically explore how much amount of oil was extracted, how many hours the machinery was under operation, and how many man hours and machine hours were utilized. This would be the basic set of analyses where the nature of the problem would be Descriptive. During the analysis, we discovered that the total amount of oil extracted today was extremely low compared to the threshold benchmarks and targets. We would then want to know what exactly happened, why the production decreased, and what were the causes. We would try to dig deeper into the problem and understand whether there was any issue with the workforce, did any device/equipment have a downtime, or whether any machine was underperforming. Here, the nature of problem would be Inquisitive, where we try to answer, Why did the event happen? Similarly, when we identify that the root cause for the problem was the downtime due to the failure of the drill machine deployed on the site, we would then try to understand when the assets would fail in future so that we could prepare in advance with maintenance and logistics to reduce downtime. A statistical model can be built that predicts the failure of an asset based on the real-time dimensions captured from the sensors to implement predictive maintenance for the assets to reduce downtime. This would be a classic Predictive problem. Finally, when the failure was catastrophic, we understood that we need to get a corrective action plan in place to reduce the effects to the best extent. We would get logistics ready for periodic maintenance of assets and condition-based maintenance for the machinery deployed on the site. Here, the nature of the problem is Prescriptive.

In a nutshell, we have explored the problem landscape and studied various dimensions of the problem. We studied how problems can be in different stages of the life cycle, how problems can be defined based on their type as low and high impact and frequency, and we also synthesized the nature of the problem, which can be Descriptive, Inquisitive, Predictive, or Prescriptive. Now that we have understood how the problem can be defined, lets move on to another important topic: understanding what it takes to solve a problem.