Lawrence S. Maisel

AI-Enabled Analytics for Business


Скачать книгу

roles. Too often, the roles are reversed, and the users are secondary.

      Many businesses assume that implementing analytics requires data scientists, as they have the skills required for AI and know how to apply AI in the business. While the former assumption is true, the latter is a misconception.

       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.

      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.

      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.

      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.