James Taylor's Decision Management

How do you tell if your organization is ready for decision management? If not, what can you do to start laying the groundwork?

While there are many characteristics of an organization that might identify it as a good, or a poor, candidate for decision management, none of them prevent progress being made completely. Each organization needs to understand the different areas of readiness and decide how to leverage those things it does well and mitigate those things it does poorly. The five key areas are business and IT collaboration, data readiness, analytic understanding, willingness to change (both in terms of internal processes and customer-facing ones) and management focus on operations. In five posts this week I will try and cover each of them.

First, Business and IT collaboration

Automated operational decisions are perhaps the point in an application portfolio where information technology and the business came together most closely. Business decisions are, by their nature, intensely important to the business and to the customer-facing management. These decisions are often regulated in ways only certain business people understand, must conform to policies written by the business and must take account of fluctuations in the market - small and large, long-term and rapid. Insight from data, another key ingredient in decision services, is also highly dependent on the business context. No predictive model is worth anything if it does not predict something of interest to the business, at a level of accuracy useful to the business, early enough for some business response. Yet decision services must also manipulate corporate data, integrate with high volume systems and be on the critical path for customer-facing applications. IT departments have invested a great deal of time and money in making sure their applications meet performance and scalability requirements, privacy rules and so on. To build effective decision services, then, requires the business and IT to collaborate as never before.

While technologies for decision management can be selected, in part, to address these issues of collaboration, there is a still a cultural aspect to this issue. Some IT departments are simply not trusted by some business units and some IT departments return this suspicion. Part of any plan to move to Decision Management must be the resolution of these kinds of issues. This will require proof points - no amount of talking and promising will typically do as most organizations have too many issues with information systems in their recent past. Establishing trust and mutual respect by delivering a series of decision services that work and that can be controlled by the business and then having them not break the systems that IT manages when the business changes them is key.

One possible approach here is to pair business analysts and programmers (similar to pair programming approaches) and have them work on the same problem. With a rules-based approach that allows both to understand the core logic being "coded" this can work very effectively. Even if you don't go this far, it will be important to keep the business analysts and users engaged in the design process as it is easy for IT folks to design something which cannot be maintained by a business user, even if that was the intent. The way a programmer looks at a problem is often very different from how a business user or analyst will look at it. Designing for business user control of the decision service will only work if the business users understand how the service works and can map their understanding of the business to the design of the service in a way that let's them apply their business knowledge.

Some previous posts worth checking out on this topic:

Technorati Tags: BRMS, business agility, business rules, collaboration, decision automation, readiness