Cyril on Business Intelligence

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:

1. Identify the controllable business variables in your business environment
2. Determine the business processes, and relevant decisions, that impact those controllable variables
3. Identify the BI systems that support the business processes and decision contexts selected in Phase 2
4. 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
5. 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