Lawrence S. Maisel - AI-Enabled Analytics for Business

Another myth of analytics is the need to start with a “discovery” project, which retains a consultant to identify opportunities for the application of analytics. A recommended list of about a half-dozen pilot projects is prepared, each of which has a specified objective, budget, resources, and target return. However, it is to be determined whether the analytics can be developed and/or the return achieved, as this will have to wait until the pilot is well underway or completed before the values can be measured. We call this the shot in the dark , as the applicability and/or ROI of any recommended project is ambiguous at its start.

We consider that there is a low to medium risk of no ROI with this approach because there is so much low-hanging fruit for the application of analytics. However, this is an unnecessarily long, complex, and expensive journey, which ultimately increases the risk to achieving a successful implementation.

A side myth to note regards software vendor selection, in that consultants are not the objective arbiters of technology that they often claim to be. They have made significant investments to learn a few software products. This is not a bad practice; it is just that no one should be surprised when a consultant's recommendation of a software vendor happens to be one of their partners.

Note, too, that we are not advocating against consultants. Quite the contrary: consultants are an important part of the landscape for implementing an Analytics Culture. In fact, as we will discuss later, consultants are too often under-utilized for their expertise in business processes that the business critically needs to develop.

Analytics are best implemented by the business, and to avoid the shot in the dark, the business should identify its priorities—for after all, who knows more about the business's needs? From here, the business should select and work directly with the analytics software vendor. These folks know their product and its business applications. They can also bring consultants whom they consider best fitted to the customer. With this method, the business, not the consultant, is in charge—and that will bring focus, speed, cost efficiency, and lower risk to implementing analytics.

A director for a technology venture accelerator asked two of his portfolio companies that had AI products to help him with a problem he thought AI could solve in his venture portfolio management. The director was in the middle of describing his problem when the founder of one company said the solution was using ML with JSON. The founder of the other AI company said, “Hold on! We don't even know the problem yet, to know what technology to bring to bear.”

This is a common error for people in technology: putting technology in front of the problem. It is like bringing plumbing tools before knowing if the problem is plumbing or carpentry. This is simply a backward approach to problem solution, affectionately known as bass-ackward .

By focusing on technology first, the business problem or optimization being sought becomes secondary. The quest becomes finding people with skills who know the technology selected and tools that run the technology. Once found, they are given the “secondary” task to solve the problem; but their interest lies in using the technology, not in solving the problem. These people want to be clever about what the technology can do vs. curious about what insights can be gained from the data. This gap often manifests itself in more limited results for the business.

In combination with leaping to a particular technology is making the solution overly complex. For example, I sat with a PhD statistician at a large telecom company discussing demand forecasting. I had selected a particular forecast formula using a single variable to forecast demand from historical shipment data. Back-testing confirmed greater accuracy than was being achieved by the company's current method. The statistician wanted a similar forecast formula but with multiple variables and using as data inputs two other forecasts: the internal forecast and customer forecast.

His theory was that the internal forecast skewed lower than actual demand and the customer forecast skewed higher; thus, the blend should yield a more accurate forecast. I opined that this approach of using two forecasts to make a third forecast was like two drunks trying to help each other home. He disagreed, and I wished him well in his efforts to prove his methodology.

As predicted, the statistician's efforts were unfruitful, and when we resumed our talks, he now wanted to manipulate my formula by adding more variables. I reminded him that the forecasts achieved with my method had materially better accuracy and we were now pressed for time to deploy a forecast. The adage we should heed is, a good plan today is better than a perfect plan tomorrow.

Nevertheless, the statistician said he would not accept any forecast that was not multi-variable and that he could not manipulate, regardless of the accuracy of the results. He was focused on mathematics for the sake of mathematics and not the accuracy of the forecast for business. At this point, I wished him well and departed his company for the last time.

Einstein said, “Everything should be made as simple as possible, but not simpler.” 4 Wise words that all statisticians and data scientists should heed, as leading with their ego to show everyone how smart they are only introduces complexity that ultimately breeds error. The solution to bass-ackward remains for the business and its users to define the problem and drive the analytics solution.

It is natural to think that anything with computers is the domain of IT. True, but only to a point. Think of IT as the Department of Transportation that makes the rules of the road, like weight and height limits of vehicles. The DOT does not, say, tell a trucking company what trucks it can or cannot buy. Similarly, IT should set policies for data security and software support but not decide what software a user can use.

IT should provide computing infrastructure and security for the data, but the choice of the software must be up to the user, as long as the software complies with the policies. However, IT usually becomes a roadblock by interjecting itself in the decision process. How many times have users found software that meets their needs wonderfully, only to be told by IT that they cannot have it because IT does not want to support it, or they must accept software already in-house, or they must use other software chosen by IT, or IT will build the software?

IT's job is to support the user who knows best what software will meet the business's needs. For example, a division of a Fortune 500 consumer package goods (CPG) company's demand planning group invited four software vendors to bid to provide demand forecasting. After proof-of-concept tests and bids from the vendors, the user group rejected one vendor and rated the other three for the gold, silver, and bronze medals. However, the vendor that won was selected by IT and was the vendor that was rejected by the users—twice!

The consequence of IT dominance in software selection is typically software that, in the best case, underperforms because it does not fully meet the business needs, and in the worst case is modestly used or goes unused. As such, when selecting analytics tools, be sure the choice is that of the users, not IT, or the value obtained will be marginal.

There is a tendency, especially with IT, to “boil the ocean” on big data AI and analytics projects. While these can deliver a high return to the business, they are complex, long, and expensive, with price tags that only larger companies can afford. The risks are higher in this approach as it has many moving parts that require the integration of large infrastructure and people with specialized technical skills to communicate, coordinate, and collaborate with people who know the business to define the requirements and deliver a usable application.