Operational business intelligence (BI) has a focus on day-to-day operations and so requires low-latency or real-time data to be integrated with historical data. It also requires BI systems that are integrated with operational business processes. However, while operational BI might be part
and parcel of operational processes and systems, the focus is still on changing how people make decisions in an operational context. To compete on decisions, however, you must recognize that your customers react to the choices made by you, your staff and your systems, and that you must manage all the decisions you (or your systems) make – even the
very small ones. This is the basis for enterprise decision management or EDM. Five main areas of difference exist between operational BI and EDM – a focus on decisions (especially operational
ones), organizational integration, analytic technology change, adoption of additional technology and adaptive control.
In this article, I want to outline some steps organizations can take as they move from “traditional” BI towards operational BI and enterprise decision management. Some of these steps would be a good idea if operational BI was your goal. But hopefully you are more ambitious than that and want to really begin to compete on decisions.
It strikes me that many companies who think they have either a unique process or a lot of process variations actually do not - they have a standard set of activities that must be assembled dynamically based on the circumstances, customer etc. This leads to a rules-first approach to defining the process and much simpler processes. This is particularly useful when you start considering case management processes where using the rules to determine what state the case has reached and what, therefore, is the right next step is a clearly better approach.
As IBM absorbs ILOG it will be important that it continue to invest is this multi-platform approach. Not only are there some nice features in the .Net product (that I for one would like to see available to the Java product) but decision management with business rules is, for most companies, a multi-platform problem. The value of using business rules to decision management comes in part from making sure the same rules are used everywhere they are supposed to be used. While deploying business rules in Decision Services on SOA makes this easier, the best solution is to allow the rules to be packaged up and deployed as Java components, Web Services, .Net assemblies or COBOL code so that they can run natively on all the platforms that run the business.
The power of Decision Management in this kind of scenario is threefold.
Firstly it focuses on the decisions themselves - what decisions matter to the customer interaction. This ensures that the data being collected and used is that which will make a difference. Beginning with the decision in mind in this way focuses analytics and data gathering.
Secondly it allows the decision to be made consistently across channels so that customers get the same service from the agent at the gate, the call center, the service center or the kiosk. Operational BI assumes there is a person to make the decision and so cannot deliver this true cross-channel consistency.
Thirdly, Decision Management recognizes that policies and regulations matter as much, sometimes more, than data. Presenting the data and even its analysis to someone who then fails to follow procedure is not helpful. Decision Management combines the policy aspects of a decision with the analytic aspects in a way Operational BI does not.
I had an interesting chat with Miko Matsumura VP and Deputy CTO of Software AG the other day. While we ranged widely, the official topic was Software AG’s launch of AlignSpace. AlignSpace is a hosted “Social BPM” solution supporting collaborative process discovery. The idea is that it will combine:
Social networking (around process definitions)
Collaborative design of processes
Translation of a wide variety of process models
A process marketplace
There aren’t many specific details yet (the site has an overview of these things but no details) but Miko discussed some of the key characteristics he felt an offering would need to deliver on this idea of social BPM:
Easy to use, low barrier to entry so those with process know-how but not technical skills (in modeling for instance) can participate.
A pricing model that let’s people participate even those with a fairly small role
Widespread access so that everyone can participate
Independence so that companies are not excluded because of their technology or standards choices.
Community - it is not enough to have “social media” features, it must actually build a community around processes
A marketplace of experts, skills and information must be created so people can buy and sell process expertise.