Decision Management is an up-and-coming discipline as described by Carlos in an earlier post. We truly believe in its potential and what it will bring to Enterprises.
That being said, the road to greatness is paved with pebbles. We have seen over and over the same errors in its adoption and implementation.
I want to discuss one of the main issues I have seen first hand at some of our customers’ site. Many start Decision Management with a Business Rules implementation, mostly with Automation in mind. In order to process applications, claims or more generically transactions, new systems are built on top of Business Rules Management Systems (BRMS). Efforts being driven by IT, even if built for the Business side of the house, a few aspects are often overlooked.
User Interface… In your face…
Mike Gualtieri from Forrester has been stressing quite vocally this past year the importance of user experience. Good design could make the difference between success and failure. He is totally right.
Over and over, we have seen IT groups overlaying some business words on top of a rules language and calling it a business user interface. As a result, the user interface looks like a technical interface, where business users must create technical rules, following pretty much a technical syntax but with some business veneer. Some go as far as exposing IF-THEN point and click rule building screens with very little concern for the core concepts they map to. What follows?
In the best case:
- Frustration finding stuff
- Clumsy navigation
- Intellectual confusion
In the worst case:
- Incorrect codification of business concepts
- Rigid Business Rules that can’t express the nuances of the business
- Terrible performances
When the effort to design good rules is put on the shoulders of business users, their user interface adoption and success both end up being poor.
First they do not want to be turned into programmers. Not mentioning that they should not be turned into programmers… Business expertise is invaluable, why spend time teaching those guys how to write code? They do not like it, they will likely write sub-optimal routines. As a result only a few technical-minded business experts make the transition. Most others resist.
Second, if they can’t easily express their concepts, they lose faith. They deal day in and day out with product definition, pricing schemes, or legal regulations. Mapping those concepts to an IF-THEN format can be challenging. In many cases, one product definition will result in a bunch of business rules that may scattered in a project (eligibility criteria, product characteristics, etc.). In addition to the initial set up challenge, breaking down the elements of a Product into scattered business rules naturally adds complexity to the maintenance of those business rules. Finding those elements down the road might be difficult if not impossible. Business Rules capture should not be such a mind game.
And lastly, Management’s endorsement is a critical aspect for success but it may not last when codification mistakes and errors turn into very costly expenses. When codification of business rules is a mind game, it is unrealistic to expect that all business users will be able to perform consistently without tripping. Some verification or simulation tools might help catch those early but mistakes are bound to happen in this environment — like they are bound to happen in a business user / developer paradigm by the way. When business users have direct access to the Product box those (granted with Quality Control processes), there is an extra element of risk, new paradigms to get used to, new processes to set up. Complex mappings as jus described make this approach error-prone. It is bad enough that Enterprises mis-adopting BRMS do not rip the benefits of business user management as promised when well-designed, but they are at risk of pushing incomplete or incorrect business rules into their systems, errors that could translate into missed opportunities, terrible deals, or violation of legal regulations. All of them costing missed revenue or hefty compliance fees. One of those might be reason-enough for management to pull the plug on the technology when unfortunately technology is not the use, design is.
Are all BRMS implementations doomed? Of course not!
I want to bring your attention to the importance of a business user interface. Do not treat it as an afterthought. Do not focus 80% of your time on the technical implementation with a small effort to map that to the Business. Start your design with your Business in mind. Mapping to an implementation that works can always be done, the opposite is not true.
In some project we went as far as starting the implementation of the business user interface with no regard whatsoever for the back-end technical implementation. It provided a lot of flexibility for Agile development: fast feedback cycles, incremental approach, etc. The traditional rules first approach proved inflexible. I wish I got a dollar for every failed project that started “with only a technical interface”. The transition to a business interface almost never occurred. The Business Rues-first approach seems more effective although less understood out there by the vendors.
When focusing on business users, IT is forced to consider their concepts in a manner that makes sense to them. That is a great way to handle requirements, from the source. As a result the user experience is more effective for sure but also the quality of the underlying rules will be automatically improved. User experience includes many aspects though and all should be considered:
- The way business concepts are represented – different metaphors like decision tables or decision trees could be used for specific parts of the decisioning logic
- The way business rules are grouped together – packaging by ruleset, although natural to the IT implementor, is often foreign to the business user. There is no good business reason to display one rule at a time in the user interface and/or to co-locate business rules based on execution grouping. Grouping, linking and overall organizing should be done with as little focus on implementation in mind, only thinking about the actual user and his/her day-to-day activities
- The way users navigate through the business rules – Business rules are hardly isolated. It is very common that one rating table is selected as a result of some portfolio segmentation. It is also common that business rules are logically connected. For example, some rules may be State-level overrides to Nation-wide business rules. We see this pattern of additional non-structural navigation everyday as part of every system. As data gets huge, users need to navigate more dynamically. Amazon.com empowers shoppers with all sorts of links for fast access – product bundles, accessories, discussion forums, etc. Linkedin strings operations to preview a member profile from the invitations received in the inbox. Google gmail goes all the way to enabling structuring by tagging.
Regardless of the need, those kinds of user interactions are becoming natural as part of the web sites we interact with on a daily basis. They will become expected of the Enterprise systems as well. Per Mike’s recommendation, do not alienate your audience, design for them. Create the user experience that will make your project successful, Decision Management or not.
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
