IT
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.
BIG IS NOT BETTER
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.
However, analytics need not start here. In fact, it is better to start with a small to mid-size project because it is fast to value—and that value, when seen by others, begets the buy-in for more value, and so on. Smaller size also means lower cost, complexity, and risk.
A great start is simply automating existing spreadsheet reports in AI-enabled analytics tools. This has three immediate benefits: (i) it frees staff bandwidth by automating much of their time-consuming manual work in compiling spreadsheet reports; (ii) once the data is in the analytics tool, you get the analytics on the data as a by-product; and (iii) when staff reclaim bandwidth and have analytics, they now have time to explore their data to reveal insights for better decisions and planning.
This approach enables the rapid institutionalization of analytics: that is, since the reports to be automated are already part of the business process, the medium by which reporting is created becomes part of that process, too. So, without consciously launching analytics, you have launched analytics.
This is the most powerful technique for executives to employ to start analytics, and it is the path with the lowest cost, shortest time, and lowest risk as it involves the least amount of organizational change management.
NOT NOW
A particular affliction of many finance departments is to delay starting analytics because finance struggles with basic financial reporting and month-end close. The thinking is that if these rudimentary tasks cannot get done timely, accurately, and with accessibility to support operations, then the very function of finance is questionable. However, if the financial planning and analysis (FP&A) group of the finance organization is not ushering in AI and analytics to be a hub of predictive intelligence for planning, then it provides no modern value for business performance improvement.
As such, FP&A can and must leap-frog to analytics to both solve current reporting and advance to data-driven decisions, or it will be side-lined to routine tasks. In this configuration, the consequence is that finance is nothing more than a bean counter. The excuse that basic reporting comes before analytics or that difficulty with basic reporting precludes analytics is just that—an excuse. Finance can solve standard reporting and accommodate analytics using modern analytics and data visualization tools to both automate reporting and deliver analytics insights.
An analogy to this approach can be found in Third World countries in the 1990s and early 2000s that had poor telecom infrastructure. Instead of spending limited capital to upgrade and expand landlines, the jump was made to new cellular technology. It was faster and lower cost and shot them forward into the twenty-first century.
Using analytics tools to replace spreadsheet reports is a similar approach, as it accommodates the foundational business reporting; then, once the data is in the analytics tool, reports leap-frog to reveal added insights that can be found from the data. This approach is not limited to finance: all areas of the business that are awash in spreadsheets can use analytics tools in the same manner.
NOTE TO EXECUTIVES
The adage that software projects need executive support is very true in analytics, as analytics will change decisions, and change requires executive leadership. Executives, even when they want to develop a data-driven culture, often diminish or destroy its implementation.
The primary failure of analytics projects comes from executives who do not accept the use of analytics, perceive its benefits, have clarity of vision and understanding of AI/analytics, or have the leadership to discipline their companies to build an Analytics Culture.
Here is a true tale of a CEO (we will call him Jimmy) who runs a CPG manufacturing company (we will call it JimCo) of about $500 million that sells its products to distributors that then resell the products to retailers. In this business model, the shipments of products from JimCo to its distributors are known as shipments, and the shipments from the distributor to the distributor's retailers are called depletions. In this case, JimCo has data on both shipments and depletions.
Jimmy was forward-thinking to use ML to forecast depletions. The AI model worked well and had a last recorded accuracy for the full year 2020 of 93% across a representative swath of the company's business.
The company installed new master planning software for manufacturing that required increased accurate forecasts of shipments. While the ML forecast worked well for depletions, the characteristics of shipment data were significantly different, and the ML algorithm yielded materially lower accuracy of 86% across the same swath of business.
In search of better shipment forecast accuracy, the manager in charge of the depletion forecast (we will call him Bert) found a software company with a new approach to AI forecasting and ran a proof-of-concept (POC) test. Figure 3.1 displays the percent error of the forecast made 12 months in advance by the new POC software compared to the existing ML model across five major SKUs. As presented, the POC software achieved materially higher forecast accuracy for shipments across three of the SKUs and overall had a total error of only about 5% one year in advance (95% accuracy) vs. the ML model with a 14% error (86% accuracy).5
