As I blogged earlier, at the SAS Global Forum this week some SAS speakers drew a distinction between Business Intelligence – BI – and Business Analytics. I worry that this is a distinction without a difference and that it fell short of what SAS can offer its customers. Neil Raden, on his blog, dismissed the difference as “all fluff” and suggested we use an old but very meaningful phrase “decision support”. Like Neil, I noticed that the word “decision” was conspicuously absent from the SAS framework. Neil wondered how “this framework leads to making better [decisions]” and this made me think – what could a company do to build on the SAS Business Analytics framework?
The first step would be to look at the analytics you are developing and ask the question “what decision is this assisting?” Understanding the decision-making of analytic users, those who see the reports or dashboards, would clarify what analytics you need to make further progress and make it obvious who was the true consumer of each analytic. Understanding, for instance, that the reason out of stock predictions are being added to a particular report is that the supply chain manager uses it to place replenishment orders would show that it this report is being used to decide if a particular product should be ordered this week or not. Knowing that this is the decision being supported – how your reports generate action – might show you that other formats, other analytics would also be helpful and would clarify the analytic sophistication of the consumers of the results.
Once you know what decisions are being supported you can ask yourself questions like:
- are there rules or constraints that also impact these decisions?
- how do the decision makers apply these rules – are they repeatable?
- does the decision maker have more productive things to be doing with their time than reviewing these reports and making these decisions – would it be worth offloading the decision to a system?
- if a system made this decision would it be made quicker (overnight rather than in the morning, for instance) and would that add any value?
- would the company run more effectively or efficiently if someone else controlled the way this decision was made?
- can I break up this decision into lots of micro-decisions and get more targeted, more personalized, more focused?
The answers to these kinds of questions help clarify where on the range of pure decision support to pure decision automation a given decision might fall.In our book, Smart (Enough) Systems, we use this graphic to explain how these range works.
Strategic low-volume, high individual value decisions tend to require decision support where an expert or knowledge worker needs interactive analytic tools. Tactical decisions tend to be higher volume and more standardized “business analytics” are called for. Decision automation, however, starts to add value because there are often repeatable steps or rules to follow also. Finally operational decisions, high volume decisions with low individual value, are those where reports and dashboards should be replaced with embedded analytic models coupled with business rules to implement policy and regulations, expertise and know-how. This decision automation may not deliver “the answer” – it may just restrict the allowed answers to a short list – but some or all of the decision making process is automated.
Using business analytics to deliver predictive reporting and predictive dashboards is a great way to build decision support systems but applying Decision Management so that analytics can also be applied when operational decisions call for decision automation will allow SAS customers to make every decision analytically based. Decision management puts predictive analytics to work whether decisions are made by machines or by busy people with too little time to read a report (such as most call center or retail staff, for instance) or by people with no particular skill at interpreting data.
