Experian has recently renovated their decision management platform – now called PowerCurve™. Experian’s clients generally need to achieve one of four goals – increase revenue through market share growth; controlling risk to manage exposure and reduce losses; increased operational efficiency; or compliance. These goals obviously drive you to using Decision Management Systems and to use both business rules and predictive analytics which are the core components of the PowerCurve platform. In particular, the platform is designed to support three key focus areas – identify and quantify opportunities, engage customers with offers and products, monitor and manage customer relationships and portfolios. This involves managing information, building analytic insight, making decisions based on analytics and business logic and executing this in an operational environment with workflow.
PowerCurve consists of a design environment (Studio); an integrated content gallery driven by a solution repository; assisted strategy design driven by an analytical data mart; and an operational environment or run-time. Monitoring and reporting reaches across both design and operational environments so data can be pulled from operations into the studio. PowerCurve is available as a development platform and is being used by Experian to develop lifecycle solutions across the whole lifecycle from originations to customer management to collections and recovery and fraud. Data connectivity and enrichment is available throughout (customer data, credit bureau data and other third-party data) as is optimization.
The Strategy Management Studio allows for strategy development, strategy monitoring and assisted strategy design. The studio is built on Netbeans so that different Studios can be developed for specific business solutions (like Originations say) and it is a typical IDE. It can connect to various repositories for content. The studio can be configured for different types of users.
Components are stored in repositories within which folders can be used to manage components. Complete components or templates can be reused as part of a new solution being developed. Component templates can have dependencies, that the studio will use to bring in additional components, and the components created from the templates are then managed locally. The ability to manage templates in a shared repository allows easier enforcement of development standards as well as localization/product-line specific implementations that reuse shared components while being able to specialize some pieces as required. This kind of specialization is common in decision management systems so support built into the repository is useful.
Decisioning flows are the key element of control – these are the things that are deployed –and allow a series of tasks to be grouped to make a decision. These flows can then be embedded into a workflow as a node. The decision flows can be built from a palette that allows analytic scorecards, decision or strategy trees, conditional branches and sub flows to be dragged on to the flow and linked into a sequence. Scorecard trees (decision trees with a scorecard for each node) and some other advanced decisioning nodes are supported as well as basic rulesets, decision trees that apply rules or script at each node, scripts, and decision tables. An overview window allows navigation and the diagram can be locked down so that it is just used for navigating to specific editors.
For flexibility during development, these flows can contain sketch nodes with no details as to what the node does except a comment, drawn nodes that say what kind of node they are but have no details or complete nodes with actual implementations. The ability to include sketch and drawn nodes in a flow makes it easier to iterate designs and to have business and IT collaborate as the overall decision structure can be defined without having to fill in the details. Templates can be applied from the repositories as objects are created and new templates can be created from existing objects for later reuse. Templates can contain partial configuration information based on the various kinds of nodes allowing a template that has a mixture of completely defined elements as well as “slots” for new content. A template might contain completely defined common corporate content, a regional component that was partially defined and a simple sketch of the local component so that developers knew where it was supposed to go, for instance.
Each node type has an editor suitable for its content. In general the outcomes for a decision are defined explicitly and then assigned to the rules, segments or table. Each outcome has a name and color coding as well as information about the specific outcome – a treatment or a scorecard, for instance. Treatments (the most common outcome of a decision) can be defined in a panel that is created very specifically using templates. Behind each treatment is a panel to configure it (build a UI) and a script that must be specified to use the values and map them to the underlying data. Typically, once the script is done the business users can simply fill out new data for additional treatments.
Within the flow, monitoring can be easily toggled on or off node-by-node. Once turned on the logging is automatically handled. This allows detailed information to be captured in some places, or at certain times, without requiring detailed information to be captured everywhere.
One nice feature is that data can be profiled through a node showing the number of cases that run through the various outcomes. Various calculated columns can be defined using the data in the data file being run through the node and these are displayed also. This use of data to review rules and decision flow is extremely powerful.
Data is also used in some decision tree growing algorithms for data-driven strategy design. The user can provide a dataset and then, for instance, ask for a next best split to see how to change a decision tree based on the data. This allows users to create a decision tree based on a mix of their own judgment and experience, regulatory or policy requirements, and data mining-style analytics. Policy might determine that the first split is between customers in good standing and those not but then the user might be interested in what makes for the most statistically significant sub-groups below that. This mix of analytic and business rules approaches is a particularly effective one when building decision or strategy trees.
Explicit support for Champion/Challenger splits is provided and these are then automatically monitored to allow results to be compared between the champion and the challenger(s).
The platform has a rich set of reporting and dashboards/visualization capabilities– especially executive dashboards – through a partnership with MicroStrategy. Data connectivity is important to Experian and the platform supports data access from alternative data sources beyond Experian and their integration into decision-making. Predictive analytic models can be deployed into the platform using PMML and work is continuing to streamline this process.
You can get more information on Experian Decision Analytics PowerCurve™ Platform here and Experian is one of the vendors in our Decision Management Systems Platform Technology report.
