In any business that is subject to legal or regulatory controls, having a robust governance and auditing process is very important, if not mandatory. A typical example would be a bank that offers financial products, which has to comply with regulations set out by the Federal Reserve Board (FRB) in the US or the Financial Conduct Authority (FCA) in the UK. In many cases, if a financial institution such as a bank cannot demonstrate control over their decisions and processes, then the regulators can impose fines.
Consider the following example. A customer buys a financial product from a bank, and sometime later claims that it was improperly sold to them.
In order to prove or disprove the claim, the bank needs to determine the parameters of the sale: What customer information was collected and used in the decision? What additional information was augmented in the decision process, e.g. from external credit agency sources? What was the outcome of the decision? Why was the decision made in this way, and by whom, at the time the product was sold?
In a typical IT system, this can be very difficult, often with complaints handlers having to pull data in from disparate systems, sometimes with help from IT. Once the data has been collated, the next question is why was the product sold in this particular configuration? In systems that are maintained by the IT department, this would only be possible by trawling the change history in source control systems and somehow linking it back to original business requirements.
From an auditing point of view, it is important to know why the decision was made. This can only be determined if the system records not only the decision making process at the time, but why it was configured to make that decision, by whom and why. It may be that it was a legitimate decision at the time, but it might not have been. Having all of this information in a single place means that the complaint is handled not only quickly and, more importantly, accurately to ensure customer satisfaction.
HOW CAN A RULES ENGINE HELP? Rules engines, like IBM?s Operational Decision Manager (ODM), can be designed to make decisions with a granular and searchable audit trail. ?Importantly, the audit trail is not buried in the system?s log files for IT to ignore but presented to end users via an easy to use and navigate web interface.
Every rule change that is made records who made the change, what the change was, and why the change was made. This allows real time decisions to be traced back to the state of the rules at that point in time very easily. The auditing framework can be extended to allow business specific information to be collected against the changes, to link back to business requirements and change requests.
Making the correct decisions and protecting against from making the wrong ones in the first place, is where governance comes into play. Rather than allowing the business to just make arbitrary changes and put them into the production system, ODM can provide a decision change work-flow that allows multi-approval states across multiple users, and can be tailored to suit any required process.
ODM also has the capability of recording and querying the exact input message into the engine, as well as the rules that were fired and the decision outcome, from the calling systems in real-time. This allows the decision data to be used alongside customer data and records to provide that all important single view of the transaction.
[Editor's note: Justin hails from our new London office, and as this post reflects, his expertise in ODM is extensive.? ODM and BPM are critical aspects of better process management, look for more posts on ODM in the coming months]