programmer who knows statistics. Their realm is IT and not business, and the two domains are worlds unto themselves. For example, the following bullet points are an excerpt from a profile on LinkedIn for an IT Director of Digital Process Automation for a major insurance company. While there are lots of technical accolades, there is little discussion of business application or benefits, and no delineation of ROI:
Managing a global team of 30+ RPA Architects, Programmers, Data Scientists, Technical Business Analysts and onsite consultants from Appian, InfoSys, IBM, and Cognizant
Managing the implementation of a Business Process Management Tool (Appian) into an on-premises architecture to automate & streamline Client Onboarding
Integrating InfoSys's ML Platform (NIA) and continuing to release new stories in 6-week intervals to generate operational efficiencies
Not to belittle talent, but the wide expanse between IT and business results from the lack of common language and mission. The IT speak in the previous list illustrates that IT and the business are not in the same business—as most of us have experienced.
The business speaks of sales and expenses, whereas IT speaks of systems and technology. As such, it should be no surprise that the typical data scientist is limited in business acumen; thus, engaging the data scientist to implement AI in the business first requires educating them about the business.
For example, a Director of Inventory of a major technology company recounted an exercise in attempting to engage data scientists to develop an application that could yield insights from their data. The amount of time and effort it took to educate the data scientists about the business was so exhausting that the project was abandoned.
The myth of AI and analytics requiring data scientists emanates from the notion that business users lack requisite skills (formal training in mathematics, statistics, and specialized programming languages). This is certainly true for projects that use AI platforms where a combination of data scientists, database administrators, and application programmers is required. However, these complexities can be mitigated with modern AI-enabled analytics software tools that empower business users to engage analytics on their data without incurring the costs and complexities associated with platforms and tools that require specialized resources.
SHOT IN THE DARK
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.
BASS-ACKWARD
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.
AI
