The article’s value proposition—that prescriptive analytics is “the science of outcomes” and that it “tell[s] us what to do”—is vaguely accurate. Yet, if a reader had no additional knowledge of this subject, she would be left thinking that creating a prescriptive analytics model requires two major work streams:
Judging by the article, it seems the author’s knowledge of prescriptive analytics might be limited to just one aspect of prescriptive modeling: a rules-based methodology, possibly even learned from using just one software program.
The article omits what is often a much more beneficial approach: using mathematically tested optimization-based techniques. Importantly, this is where the “science of outcomes”, as the author phrased it, can be validated and measured in ways that just a rules-based approach normally cannot. ROI is always important, especially when considering something that can fundamentally change the enterprise’s business.
To be fair, even when using optimization-based modeling approaches, rules are important. But rules are just constraints that affect the desired outcome. For every rule implemented, something—potential profits, for example—might be forfeited. While it’s critical to properly model physical constraints, like the law of gravity, other constraints, like company policies, might need to be violated or even ignored when necessary. In some cases, they probably shouldn’t even be included in the model.
For example, United Parcel Service’s heralded ORION program, used for daily optimal route scheduling of truck deliveries, is driven by an import rule that drivers should not make left-hand turns. But even here, drivers retain the freedom to violate the no-left-turn rule, especially when unforeseen circumstances like traffic jams, bad weather, road construction, etc., dictate. Companies may have rules, but we see many instances where they would benefit from the ability to run scenarios where the rules are bent or ignored altogether.
By focusing on a rules-based approach—which, again, frequently provides suboptimal answers—the author makes an all-in statement that should not go unnoticed by the reader. The last paragraph in the first section states:
“Prescriptive models don’t just inform those involved in the decision-making process, they are the decision-making process. They articulate the best outcome, which can create friction among those who aren’t comfortable relinquishing their decision-making responsibilities to a machine.”In my experience, when a decision can be succinctly defined and must made frequently (e.g., hourly, by shift, by day, etc.), only then will humans allow answers from prescriptive models to become an automated part of their planning process. Such decisions typically include what to schedule on each line today? How to best load each delivery truck today? Which operating rooms should be scheduled for certain procedures today? In nearly every case it takes time for managers to gain that trust.
In the article, the author attempts to provide several examples to back up his statement that some managers defer the decision-making process to machines running algorithms. The first one is of an electronics manufacturer selecting optimum long-term customer contracts; the second of a healthcare service provider choosing near-term and long-term investment plans for optimal service delivery.
Do either of these examples seem like they would naturally lead to decisions made solely by machines? Decisions accepted and implemented as is without executive management approval? No!
Prescriptive models by themselves have not been, nor are likely to ever be, the decision-making process. Without a deep understanding of the best (and other comparison) solutions, and the potential financial and operational impacts on the organization at large, making tactical and strategic decisions in particular will always require some level of human interaction. The higher the importance and visibility placed on the decision, the more crucial it is that all stakeholders agree to the decision.
At my company, we believe the full value of prescriptive analytics is not realized until an Integrated Business Planning (IBP) process is engrained in the organization. IBP does not require every important decision to be modeled using every bit of information possible right from the start. Managers are encouraged to attack the most pressing needs first by developing a prescriptive model to enable those decisions. This can be achieved in just a few weeks by creating Proof-of-value (POV) models; maybe just focused on a single product family; one geography; a single hospital; etc. Value can be realized from a small team of people, which can then lead to much larger efforts when scaling out to the enterprise-level. Eventually, true IBP, with an open collaborative planning across departments can occur, but on a flexible schedule that makes sense for the entire enterprise. IBP will however never become an automated decision-making process.
Under “Playing by the (changing) rules”, the author states “When prescriptive analytics is applied, the process itself needs to include as much information as possible about the enterprise by creating a framework for interpreting the prescriptive results. That framework is built on business rules.”
The challenge when working in a rules-centric approach is that it’s the rules themselves that largely determine the outcome. Instead of inputting only first order data—e.g., throughput rates, raw material costs, labor cost per hour…things that are inherently defined by data and not policies—people charged with creating rules will frequently attempt to include all rules that govern the business—e.g., bias the model to make certain products at certain plants; don’t allow a 3rd shift or shifts on weekends; don’t allow right turns, etc.
Typically, the results out of such a system ends up being self-fulfilling. With so many rules, the degrees of freedom become diminished and the “optimal” path becomes narrower and narrower. It can become difficult—maybe even impossible—to measure the impact of deviating from such rules. If a rule says “we must maintain service level at 98%”, then what is the financial and operational impact of that solution? We might never know.
True scenario analysis has two important aspects: 1) in order to measure value, management must agree on important objectives, like to maximize profit, minimize inventory, or capture a larger market share. Only when such objective can be stated clearly will the need for key constraints and processes make sense; 2) scenario analysis cannot happen unless the before and after outcomes are easily analyzed side-by-side. This might seem like a mundane requirement, but it can be surprisingly difficult in many prescriptive modeling approaches.
In contrast, an optimization-based approach is ideally suited to lay out the alternatives using scenario analysis. It’s the fun part of the prescriptive modeling process, when management gets to ask questions like: What is the expected course of action if the enterprise continues under the current set of business rules? What are alternative outcomes (scenarios) if the business rules are altered? This could be changing policy to run additional shifts; it could be investments into new products or selling existing products into new geographies.
The author makes a few valid points regarding prescriptive analytics’ reliance on diverse data sources, what he calls the “hybridization of inputs into the prescriptive process”. Yes, true IBP-style modeling requires collecting and integrating various data. Yes, it can be cumbersome and expensive, as the author also noted. Data-immature companies typically are not ready for such ambitious efforts.
But the author’s claim of a need for “environmental,” unstructured data from Internet posts and white papers is just noise—or…it’s at least safe to say that the statement is focused on a very targeted use case. And it’s certainly not the business world that I make my living in. Any prescriptive analytics technology vendor or consultant who fails to ask the question “what data do you have now that is easily accessible?” is not acting in their customer’s best interest. Even a complete IBP implementation, which can take months or years, rarely requires “big data.” It does however require using existing data in new ways.
By using words like “daunting” and “off-putting”, the author ignores the fact that there are simple ways to realize value in relatively low-cost and minimally disruptive ways. Methodology, technology, human experience—these all matter a lot. In fact, if a company’s initial effort to adopt prescriptive analytics requires a serious investment—either in the company’s IT organization, hardware, software, etc.—then maybe they didn’t think it through carefully. There are optimization-based prescriptive analytics vendors today who provide code-free modeling in a cloud environment. Models created in those environments don’t consist of hard-coded business rules, but are defined as a flow diagram of the company’s business problem at hand, whatever it is that management decides they want to focus on.
As for the data needed to populate such a model? The best place to start is usually the easiest to obtain, which typically is Excel or database platforms like Sql Server or Oracle. The best technology can adapt to use whatever sources are available, and most companies have mature ERP, CRM, inventory tracking and other systems, so lack of data is rarely the problem.
I was left wondering exactly what the call to action was. Did the author just intend the article as a primer on prescriptive analytics? If so, it was incomplete at best.
Still, I give credit to the author for spreading the word on prescriptive analytics. It’s a big world and there’s room for many approaches under the prescriptive analytics umbrella. Rules-based approaches have their place, but it must be in the context of the enterprise’s goals with a measurable ROI. Without an objective function and a clearly stated goal—e.g., to maximize profits and return to shareholders—rules-based models can easily become a tool that decision-makers use to validate their own biased decisions; or eventually fade into disuse due to the high cost of maintaining code and a lot of messy big data.