Posted by Cyril Brookes in BI Requirements Definition, Decision Automation, General, Metadata management.
Barring a directive from on-high, i.e. the Executive Floor, so to speak, it can be difficult deciding which new projects, or old ones for that matter, will benefit from automation of business decision making. Selecting the right project candidates is critical. Obviously sophisticated automation of unimportant decisions is a waste of time, however interesting the technology might be.
This post follows on from that of May 17/18. I proposed a set of five project selection and implementation Phases for decision automation projects. This version gives more detail on the first three of these. A later post will deal with the last two.
This discussion is a work in progress. I’ve built several automated decision systems, but have not attempted to define a project management methodology for them. Any further suggestions are welcome, Dear Reader.
The Phases suggested in my last post have been modified in the light of comments and suggestions from many readers. They currently are:
- Identify the controllable business variables in your business environment
- Determine the business processes, and relevant decisions, that impact those controllable variables
- Identify the BI systems that support the business processes and decision contexts selected in Phase 2
- Design the business analytics that are the basis of the decision automation: business rules, predictive analyses, time series analyses wherever Phase 3 indicates potential value
- Evaluate feasibility and profitability of implementing the analytics created in Phase 4
Note: Phases 4 and 5 will be iterative.
Discussion on Phase 1
Phase 1 is, I believe, a novel idea in this context. Most authors writing on Decision Automation focus on decisions and business processes as their starting point, but I think this can result in poor project selection. Just because a business process is important to the enterprise does not mean that automating decisions that are critical to success is the right thing to do. Empowering managers to perform better with improved conventional BI systems may be an optimal answer.
As I see it, controllable variables are likely to be the least common denominators for automated BI. Decisions that can be automated must look to adjust, or consciously not-adjust, one or more of these. Unless it is feasible to monitor and adjust a particular controllable variable there is no point in making a decision that requires this; there’s nothing to do. I might decide that sailing a 50 metre yacht around the world is desirable, but without the funds to purchase it, or ability to sail it effectively, the decision is rather pointless. I may as well decide to fly to the moon.
Or in a business context, deciding to raise product prices when all our customers are on fixed price contracts would be equally useless.
Therefore, a portfolio of identified, automatically adjustable, control variables is an essential commodity in the business of decision making automation.
These adjustable variables are limited in number, because of the nature of business. Below I offer some examples of such control levers, drawn from a product manufacture and/or distribution business context. I chose this sector because it is somewhat different from the insurance or financial services examples that are usually presented in decision automation discourses.
It’s not a complete list, of course, but does demonstrate, I hope, that the gene pool for business process controllability is both limited and deterministic; and, therefore, is a good place to start a search for opportunities and new sources of sustainable competitive advantage. I’ve collated the examples into rough categories, similar to Porter’s Value Chain approach.
Controlling Input Logistics
- Ordering raw materials or manufacturing components
- Adjusting re-order criteria for raw materials or components
- Changing supplier preference rankings
- Cancelling, or modifying, outstanding orders, either to suppliers or from customers
Controlling Operations
- Customer order acceptance, modification or rejection
- Scheduling, and re-scheduling production operations due to quality, demand, raw material or other factors
- Staff short-term allocation to service points based on demand, profit maximization
- Staff longer-term rostering based on advance demand
Managing Distribution
- Re-allocating product during production from a scheduled customer to another based on quality, demand, priority or other criteria
- Scheduling and re-scheduling despatch operations based on production actualities
- Ordering and re-scheduling distribution capacity to meet customer or production imperatives
Setting Financial Variables
- Setting and re-setting prices dynamically on products and/or services
- Adjusting sales commissions or incentives based on demand, performance, or inventory
- Setting and re-setting inventory levels based on cash flow imperatives
- Issuing outstanding payment demand and collection procedures
Directing CRM Activity
- Changing customer credit or priority status
- Placing customers or suppliers on or off credit or other watch-lists based on order, supply and payment patterns
- Issuing outstanding payment demand and collection procedures
Supporting Management
- Adjusting alerting alarm parameters
- Activating these alarms
- Modifying financial or sales performance report or alert distribution lists
Managing Services
- Adjustment of spare parts inventory levels
- Movement of spare parts inventory to different locations based on usage statistics
- Automatic ordering of spare parts and adjustment to order quantities
- Re-allocation of service personnel to divisions or areas
This list should prompt similar candidates for other business sectors. Hopefully it will stimulate your ideas on where you may usefully introduce automatic decisions within the existing and potential BI systems, rather than simply report the facts and rely on management to take action.
Discussion on Phase 2
The aim of this Phase is to discover business processes, existing or planned, that contain and impact one or more of these candidate control parameters and may benefit from automation. Further, the relevant decisions that require adjustment of these control variables must be identified.
The same control variables are likely to appear in multiple business processes. For example, automatic price adjustment could impact BI systems supporting Order Entry, Production Scheduling, CRM, Inventory Management, etc.
In a comment to my last post, James Taylor, proposed that this Phase as originally proposed also required identifying the decisions that would be automated.
I accept that this is correct, we are making decisions to change the settings (or to leave them as they are, a non-decision) of one or more of these control variables. We must, however, realize that these control variables often impact more than one business process. Therefore, there is a very real danger of cross-coupling with unexpected side-effects of a decision, if we don’t check its impact on all business processes impacted by the relevant control variables.
I won’t attempt to list relevant business processes, and associated decisions, that contain or impact specific control variables. This is a blog post, not a text book. Also, any Dear Reader who has stayed with me this far is more than capable of doing his/her own assessment for his/her business.
Discussion on Phase 3
Having identified the candidate business processes, and associated decisions, that should benefit from decision automation, it should be relatively easy to determine the specific BI systems, existing or potential, that will provide the context for the automation.
In my experience, a BI system that contains decision automation components will also provide management information to support human executive decisions. At the very least, it will need to report on decisions taken automatically, and their impact. But, often the operational components that contain automation will also drive tactical and strategic information presentation – directly or indirectly.
Therefore, it will be necessary, before moving to design the business analytics, rules, etc., to determine scope and architecture of the BI system, just like a conventional, information reporting only, project. The metadata describing the character of the underlying data will need to be specified, otherwise the business rule and statistical analyses will become compromised, if not immediately then at some time in the future as green-field turns to brown-field.
Unfortunately, in the real world of system design, analysts prefer to concentrate on the interesting bits, and avoid the boring, housekeeping parts. Specifying business rules, designing trend and pattern matching algorithms, building forecasting models is usually very exciting and challenging stuff. But the enthusiasm for such pursuits has to be sublimated until the overall architecture and scope are determined.
Otherwise we may end up with efficiency at the expense of effectiveness. Not a good result.
In a later post I will discuss Phases 4 and 5; the interesting bits
Posted by Cyril Brookes in BI Requirements Definition, Decision Automation, General, Issues in building BI reporting systems.
Automated decision making for business is about flavor of the month. Most emphasis has been on automating business analytics, say, underwriting in the insurance industry and stock market program trading. But there are ample opportunities for incorporating automation in more conventional BI systems, especially corporate performance management, where there has been, so far, little discussion.
Tom Davenport’s recent work on business analytics has been widely reported and commented. The consultants and software marketers are circling the wagons.
To highlight opportunities and stimulate discussion among BI analysts this post explores how relevant BI system targets for automation might be identified.
Most BI analysts see their role as designers of systems to support management decision making through effective presentation of information. That is, of course, commendable and important. But is that all there is? That focus doesn’t preclude building automated decision making systems if the context is suitable. It’s just that it isn’t done often. We seem to be reluctant to try and replace managers, maybe it’s because they are our bread and butter?
There are three generally accepted classes of decisions in business; operational, tactical and strategic. It’s pretty obvious that automatic decision making is almost always associated with operational, and perhaps some tactical, contexts. If it’s strategic, then forget it. Since many BI environments serve a mix of strategic and operational users, the prevailing focus is almost always on information presentation, rather than active replacement of human decision makers.
This discussion reminds me of a 25 year prediction from a long forgotten business journal article of the 1960s “Boards of Directors will be retained for sentimental reasons; computers will make all the decisions….”. Didn’t happen, and won’t. A similar, but contrary, forecast in the HBR of June 1966 “A manager in the year 1985 or so will sit in his paperless, peopleless office with his computer terminal and make decisions based on information and analyses displayed on a screen…” There still seem to be a lot of executive assistants around!
My intention with this post is to suggest a methodology or process which demonstrates how BI analysts can effectively and efficiently identify opportunities beyond the passive aim of information presentation. Even if the resulting design only partially automates decision making, it is likely to be a better, more effective solution than its passive counterpart, simply because it will be the result of a more creative and challenging design process.
In the current spate of articles there are many examples of apparently successful automated business process systems. While these may whet the appetite of a designer they are not, in my view, useful guides when the task of synthesising a BI system incorporating is being undertaken. When your child is given his/her first bicycle, showing someone cycling down the street isn’t going to be much help in teaching how to ride. Hands-on synthesis is needed. Big pictures may create envy, but don’t instruct much.
I suggest that it will be worthwhile for a BI analyst and executive team to review the corporate BI environment, existing and planned, and assess the potential for including automated decision making in the BI systems supporting each business segment.
Further, such a review should use a project planning method which segments activities into several bite sized Phases. Here’s a suggested outline, with more detail on each Phase to follow.
Phase 1: Identify the controllable business variables in the target businesses, ignoring specific business processes
Most articles on automated decision making start with the business process and BPM analyses. I think this is the wrong initial focus. To me, the optimal review starting point is to identify the control parameters of typical business processes that are amenable to automatic adjustment. The number of business process control “levers” available to management is finite, quite small in fact, and the number that might be controlled automatically, with profit, is even smaller. Examples include: Automatic pricing adjustment, dynamic production scheduling, staff re-assignment.
A more complete discussion on identifying control variables follows in a later post. It is, I believe, the most important part of project selection and specification. Get this wrong and you will certainly miss out on the best opportunities.
Phase 2: Identify potential business processes, existing or planned, that utilize one or more of these candidate control parameters and may benefit from automation
The same control variables are likely to appear in multiple business processes. For example, automatic price adjustment could impact BI systems supporting Order Entry, Production Scheduling, CRM, Inventory Management, etc.
Phase 3: Identify components of the candidate BI systems that may profitably incorporate automated decision making
Management 101, since Herbert Simon’s day, tells us that there is a defined decision making process, with several component steps between becoming aware of a problem or opportunity, and deciding what action to take. Automating the decision process clearly requires that one or more of these steps should be performed without reference to a human.
It is relatively easy to consider each of these decision process components in turn, to determine the extent to which it/they can be automated. My later post will give more detail if you are interested, Dear Reader.
Phase 4: Design the business analytics; business rules, predictive analysis, time series analysis wherever Phase 3 indicates potential utility
This is the fun part. The software tools for business rules management are much improved since I first started playing with IF…AND…THEN….ELSE statements as the basis for automation, as are the forecasting and statistical analysis packages.
I leave it to you to work out the details, as they are always application dependent. But always be aware that rules change, sometimes quickly, so dynamic management, or decision making agility if you will, is important. Enjoy.
Also, note that Phase 4 will be an iterative process, with frequent Phase 5 reviews to ensure that business sense prevails, limiting the scope for white elephant projects; even though they can be fun.
Phase 5: Evaluation and feasibility reviews of the costs and benefits of automated decision making components within the BI system
Try not to let the excitement of creating rules and embedding predictive analytics in a BI system carry you away; well only a little bit anyway! To me, this is one of the most interesting and absorbing roles of being a BI analyst and designer; certainly it beats specifying reports.
Building automation into BI is highly recommended, especially if you are looking for a challenge!
