I caught up with DataInfoCom recently – a research-oriented software company headquartered in Austin, Texas. Their focus is on what they call Predictive Decision Management. Their software product, OSMOSYS, delivers predictive decisioning over the Internet – Decisions as a Service or DaaS as I call it. Their customers include a couple of well known, Fortune 50 corporations across a fairly broad range of solution areas (new product introduction, channel demand, field service, parts logistics, customer service, etc.). Like me, they see a need to make decisions based on the underlying predictions, not just deliver predictions. For instance, DataInfoCom can forecast demand for specific products at specific stores, so their customers can ship the right products, at the right price, and at the right time to avoid discounting or returns. In customer service, customer satisfaction, first contact resolution and brand loyalty (net promoter score) are predicted so that customer service can make the best up/cross-sell offers at the right time during the interaction.

OSMOSYS is an enterprise software product that contains models that predict what will happen, when and why. On top of these models are actionable recommendations as to how to avoid predicted issues and take advantage of predicted opportunities. To deliver on this they perform predictive analytics, root cause analysis, optimization and what-if simulations. It involves applied statistics, machine learning, operations research and business rules. They have built their own implementations of a wide range of analytic algorithms. The platform aims for automated and “touchless” decisions and allows business managers to easily build in their own specific constraints, business rules, etc.

The basic process goes like this:

• They use an extensive set of predictive analytics techniques (logistic regression, time series, decision trees, neural networks, etc.) to predict KPIs at different, future time horizons of interest.
• These predictions are then fed to a root cause analysis engine that assesses why the predictions are the way they are – it finds the top reasons with their contribution. These could be decision variables – knobs that the business can turn – or something outside the control of the business (managed using tags on input data and constraints).
• The optimization layer then varies the high impact decision variables to preempt a predicted issue or benefit from a predicted opportunity, while conforming to the constraints based on rules. Simplistic examples include maximization of value of an interaction given a cost constraint, or minimization of cost for a given customer satisfaction constraint.
• OSMOSYS recalibrates its algorithms continually to ensure accurate predictions and useful decisions as the process being governed by OSMOSYS changes.

When touchless or fully automated is not desirable they offer a what-if simulation environment that allows the various predictions, decision variables, etc. to be varied by an expert user to see what the impact on the affected KPIs would be.

Activating OSMOSYS takes 30 days of set up, data cleansing, data integration, model tuning and adding rules/constraints – fewer for areas where DataInfoCom has a lot of experience. As a DaaS solution there is no software to install, the recommended decisions are just fed into existing systems.

Syndicated from International Institute for Analytics

I wrote a post called “It’s time to industrialize analytics” for Smart Data Collective a little while ago and it prompted Tom to reply with Agile vs Industrialized.

To recap, the key point of my post was that we need to move away from analytics as a pure craft to one that has a more systematic focus. We need analytic teams that are focused on the end goal, whether that is a high-throughput operational system (a propensity model for use in a web marketing system for instance), a dashboard, report or visualization. Such a focus necessitates limitations on the freedom of the analytic team to use their favorite tools or bring whatever data seems helpful into the model. If we focus on the need to operationalize this model – to make it affect our business – then we will not be able to have total freedom in our analytic work. This is more true when models are being deployed into operational systems than when they are being deployed into more interactive, low-volume environments but it is always true at some level. Rolls Royce cars may be hand made in places but this work is still part of an industrial process – the need for it to fit into a finished product is still paramount. So it is with analytics – even when we are hand-tooling something, we should be aware of the “industrial” context in which we operate.

Tom’s follow-on point that industrialization is not appropriate for analytic discovery work is a valid one. Organizations often don’t know how analytics might be able to improve their business and must spend time and effort in a discovery phase. It is entirely appropriate to try new things, to do things one-off while figuring out what might be helpful. Analytics are not yet, in most companies, a standard part of the way they do business. Even if they are there will be times when the area being investigated is not well known enough to allow for a systematic approach – we will need to be agile about where and how to investigate. But remember, as I said in my original post

If the model is accurate but impractical to implement then it adds no business value and should, therefore, be considered a bad  model.

It does not matter if operationalization means putting the model into a high-volume process, an executive dashboard or sophisticated visualization. If you don’t impact business results then the model is no good. You can, and should, be agile about developing new analytics. But you should keep an eye on the end objective and make sure you can deliver business results.

Model Builder 7.0, Decision Optimizer 6.1, Blaze Advisor 6.9

Decision Management remains the core focus for FICO with both a Decision Management platform and decisioning applications. The applications are increasingly built on top of the platform, sharing execution and modeling infrastructure. FICO still sees business rules as the basis for decisions, being improved and extended with both optimization and predictive analytics.  These new releases of Model Builder, Decision Optimizer and Blaze Advisor are FICO’s most recent steps to an integrated Decision Management platform.

Model Builder 7.0 shipped earlier in 2010 and included analytic visualization and productivity tools as well as integration with Blaze Advisor. Decision Optimizer 6.1 shipped with more Model Builder integration as well as improved scenario management. Blaze Advisor 6.9 also shipped in the spring with a focus on business rules management for business users.

Model Builder 7.0 is a big step forward specifically focused on analytic productivity (visualization was a particular focus as well as reducing the learning curve) and enabling a white-box, full-fidelity model deployment in Blaze Advisor (reason codes, model, supporting elements in a shared repository). Model Builder is also the first 7.x product and showcases the go-forward integrated platform. Finally it supported extension by customers.

Model Builder 7.0 is all built on the Eclipse framework, the basis for all the planned 7.x products in the FICO platform. Model Builder has new features in both the access/prepare/explore process and in the discover/model/deploy process. For instance:

• Generating deployable Variable Libraries through integration with Blaze Advisor
  A new data browser allows easy access to the data and the first step is usually to extract potentially predictive variables. The new Variable Libraries are available in the interface in a hierarchical form and contain the logic (in SRL, the same syntax used by Blaze Advisor) that calculates the variable. These are little snippets of calculation that can be selected and then applied to an analytic dataset to add the new calculated fields to the dataset. These Variable Libraries integrate directly into a shared repository, allowing the model to be deployed into the business rules environment without recoding. Once in the repository they can be reused from project to project and managed using Blaze Advisor’s extensive repository facilities.
• Rapid scorecard development
  Better visualization of things like variable contribution, weight of evidence as part of developing the scorecard is integrated right into the scorecard development component. Also integrated is a history view that is maintained over time so that prior iterations and versions can be examined and selected. The analytic scripts that drive automation have been streamlined and made friendlier using Groovy. Scripts are maintained in the background behind the interactive editors and there is a certain amount of back and forth between the scripts and the editors.
• Instant deployment
  Deployment too is supported by the script environment. Execution object models can be generated from datasets and, more usefully perhaps, the execution object model being used in Blaze Advisor can be brought into Model Builder as the basis for a modeling exercise. Everything can be pushed into the repository shared with Blaze Advisor and accessed using rule maintenance like interfaces. This could be a platform repository or the repository behind TRIAD Customer Manager, Capstone Decision Accelerator or Debt Manager.

Blaze Advisor 6.9 brings new technology to the rule management/maintenance environments for non-technical users. A new and stronger API was developed as well as re-architecting the user interface. All based on the current repository structure. Drivers were for a faster means to generate more intuitive rule maintenance tools with more support for testing, validation, verification and bulk actions. In addition customizing the look and feel, adding 3^rd party components and adding Blaze Advisor rules maintenance components as widgets embedded in other applications all got easier.

The new rule maintenance applications work off the same repository as Model Builder 7.0, enabling shared models and variables to be accessed. Rule flows, the flow between rulesets within a decision, are fully integrated into this release and can be versioned, edited and compared. Groups of objects can be selected and manipulated as a group and the user interface for searches, filters and queries has been improved so these are more accessible.

The interface is skinned and allows the integration of external news feeds etc – a more open architecture for web-based editing and viewing of business rules. The ability to use Blaze Advisor widgets and link them with third party components using the API allows for rule maintenance to be pushed into a composite environment. This, to me, is the most important item as it allows rule maintenance to be delivered in the context of a business user’s work. For instance, allowing the rules behind a decision to be accessible within a dashboard that shows the results of that decision. Decision Simulator to follow in these footsteps and things like verification are integrated.

More PMML imports are supported and the way these imports are handled can be tweaked by customers, helping with the issues of multiple PMML versions and variable support by different modeling tools. Some of the changes mean that new versions of a model could be matched to existing variables that are being managed in Blaze Advisor, making it possible to do ongoing updates of models in a more practical way.

BA 6.9 is available on all FICO supported platforms (Java, .Net & COBOL).

I got an update from the folks at Alfresco recently. This company is an open source content management project, begun by a team that left Documentum some years ago. The project now has about 2M downloads and is a commercial open source company with 1,200 paying customers – mostly among those typically comfortable with open source (government, high tech, services, media and financial services). A while ago were looking at the components within Alfresco with respect to improving the component licensing – specifically to use Apache licensing. Unable to find a workflow engine that supported this license model they recruited Tom Baeyens from jBPM to built Activiti, a new BPMN 2.0 based BPMS.

Activiti is a wholly new product – they had to rewrite so they could use the Apache licensing and this also let them reconsider various design decisions. Not only are they releasing the BPMN 2.0 engine as open source, they are also releasing a modeler, a console and administration tools. The license model has helped them generate a lot more contributors for than jBPM had and with Springsource participating, it is easy for Java developers to contribute. The product has more of a focus this time on business users not just on developers. They also expect to support the building of whole solutions not just a technical environment for worklow.

One component is Activiti Cycle, which is being contributed by another company. This is designed to support the development cycle of process and rules. The tool creates an abstraction across multiple repositories – everything from files/documents repositories, the Signavio process modeler repository, software project repository etc. Activiti Cycle allows you to develop links across those different artifacts in a collaborative environment. This collaboration layer works over the various tools and from each element you can open editors as well as build links and have discussions. They are not trying to produce roundtrip engineering but collaboration. The tool will start with a small list of pre-integrated components and an API for bringing new ones in – have some consulting partners who care also and they will likely bring in some other elements. I liked the way this environment worked, as collaboration is really important when adopting decisioning technologies, and I look forward to seeing some explicit support for rule repositories and editing (Drools integration is apparently on the roadmap)

Alfresco plans to start using Activiti. This would allow, for instance, a spreadsheet of rules managed in Alfresco to be used as a decision table that drives processing in Acitiviti – this uses some open source libraries that allow the content of information in the repository to be used in the flow. This helps support a move from documents and file systems to Alfresco/Activiti without having to replace documents with databases, a nice feature as companies become more sophisticated over time.

I liked the potential of the collaboration environment to bridge the gaps when rules and process are both being used in a solution and I also liked the potential of applying content management to business rules. Interesting ideas both of them and I look forward to learning more.

I just scheduled and announced four new webinars for this fall:

• Simplifying over-complex processes
• Delivering customer centricity across multiple channels, multiple platforms
• Implementing analytics? You need business rules
• Decision analytics – more than BI and web analytics

You can find all my upcoming events in the Events Calendar.

Syndicated from Smart Data Collective

There’s a lot of talk about advanced analytics these days – the use of data mining and predictive analytics is growing rapidly so lots of articles, books (like Tom Davenport’s latest) and blog posts are being written. One of these was by Jeff Kelly over on TechTarget on Data analytics team’s needs and, while I agree with some of what was said, I am going to take issue with the idea that analytics is a cottage industry. There is a feeling that, because what analysts do is complex and hard for others to understand they should be allowed to swan around picking their own tools while being give lots of autonomy and plenty of freedom to experiment. This is, I believe, a very dangerous idea. It is time for organizations to take a stand and industrialize their advanced analytics efforts.

Data analysts really have to get over the “choose my own tool” thing. Allowing each analyst to pick their data mining or analytic tool results in lots of different tools being used. This means that common data cleansing routines or model elements are not, in fact, common. It means that any kind of collaboration between multiple analysts is problematic, because they can’t put their models into a common repository. And, most importantly, it means that operationalizing those models will be massively more complex.

This last is crucial as operationalization is key to generating business value. Modeling teams regularly find that 50-60% of the models that work, that would improve results if they were deployed, don’t make it into production. This means all that work was wasted and that business results are unnecessarily poor – bad for everyone. Organizations need to understand how you are going to get advanced analytic models into production – into operational systems, into reports, into dashboards – and need to pick modeling tools that support this. Otherwise you are just supporting academic investigation which, unless you are in fact an academic research institute, isn’t going to move the ball forward.

The basis for this tension between operational issues and constraining analytic tool choice is often that analyst think that they are done when the model is “right”. Many analysts seem to believe that they can declare victory and pat themselves on the back when the model is accurate, statistically valid, highly predictive etc. They will often talk about all sorts of statistical measures that “prove” the model is a good one. Yet, in fact, the only results that matter are business results. If the model is accurate but impractical to implement then it adds no business value and should, therefore, be considered a bad model. The approach discussed in the article of letting analysts have freedom to pick their own tools and, to some extent, do their own thing, can easily result in this kind of situation. One company I worked with hired someone to create an analytic group who took the traditional approach. End result was a great model that was going to take 9 months of hardcore programming to get into the company’s business. Lots of costs, lots of delay, not a lot of analytic value. Similarly, things that improve a model’s accuracy but make it harder to implement can rebound – it takes longer to get into production and that delay represents lost accuracy (most models degrade over time) and lost business value. For instance, too often analytic modelers will bring in new data sources to improve the accuracy of a model without considering the impact on implementation complexity. In theory the model is more accurate but in practice it is less valuable.

I also think that organizations need to be much more focused on directing analysts towards business problems. There is a tendency to let analysts explore the data, see what can be discovered. This can result in real breakthroughs, and most folks in the data mining/predictive analytic business have some examples of this. But organizations should not rely on this approach. Instead they should “begin with the decision in mind”. Find the decisions that are going to make a difference to business results – to the metrics that drive the organization. Then ask the analysts to look into those decisions and see what they might be able to predict that would help make better decisions. Of course you have to know what makes a decision good or bad and how a decision impacts your metrics before you focus on it. And you need your analysts to understand what is likely to be implementable – do you need something your CRM system can execute or something that can be embedded in a report, for instance. Again, think industrial not artisan.

Some other quick thoughts in this vein:

• Sandboxes for your analysts to play in are good but they are not generally going to be in the Data Warehouse. Most Data Warehouses don’t contain the transaction level data that analysts need so they are going to need to work from extracts from production applications.
• Centralization of analysts into a single team is a consequence of success with analytics not a precursor to it
• In general, don’t roll your advanced analytic effort into your BI initiative as BI/DW people and analytic people tend to work quite differently. BI/DW folks think about summaries and rapid access to daily/weekly/monthly results for reporting while analytic people think about transactions, days since something happened and predicting the future. They don’t always play nicely together.
• Grouping analytic folks by business problem and looking for business domain know-how when hiring analytic folks is a good idea. But the type of model they are developing/have developed in the past is also a good organizing principle. Neil Raden and I divided analytics into those supporting risk-centric decisions and those supporting opportunity-centric decisions, for instance.

Now perhaps you are only now getting started and think it will be OK to hire your first analyst, or contract with your first data mining consultant, without thinking about these things. It won’t be. You don’t need to industrialize your first project (obviously) but you do need to start as you mean to go on so think through this and make sure your first few projects don’t send you off in an unhelpful direction. Remember, precedent is policy unless you make sure it isn’t.

I first blogged about Clario about a year ago, when they were focused on delivering a data mining/predictive analytic workbench on the web. Developing a new workbench, even with a compelling differentiator like being cloud-based, is difficult. The maturity of the competitive, hosted products and the tendency of analytic developers to be very entrenched with a specific product create significant barriers to entry. While Clario has made some progress in this area, and still sells the general-purpose platform, they are now focusing their sales and marketing activities in a specific domain area – direct/database marketing.

The company has a lot of experience around database marketing and developed Clario Stream to help multi-channel merchants manage their printed direct mail. This product lets you reduce mailings by large numbers (creating a big saving) for a tiny reduction in results – all by focusing on the most likely to respond. Referring to this as demand optimization, they have been successful selling this cloud-based analytic solution and are closing in on 10 customers.

Clario Stream targets the huge amount of waste in direct marketing. Some estimate that 97% of direct marketing misses its target. Given that direct marketing has an overall 10x return, if you could focus only on the 3% that hits its target you could see a 400x return! As a result this is a very productive area. For most companies, 1% of expense reduction is significant as is just 0.1% improvement in effectiveness. Clario Stream is showing several percentage point reductions in expense (across print, phone, direct response for instance), making for very strong ROI.

Rather than just delivering a general purpose platform, Clario is focusing on providing a decisioning platform that can be the center of successful direct marketing. Delivering optimal marketing or increased marketing productivity, Clario is focused on a solution sale around Clario Stream while allowing customers to use the same platform (the Clario on-demand analytics workbench) for other analytic decisioning problems. Today Clario is delivering print optimization in production and testing email and telephone optimization. This set of three decisions – print, email and telephone – is what Clario call “Planned Event Optimization”. Next up in 2011 are Triggered Event Optimization across mobile and internet. All using the same Clario Analytics foundation, allowing companies to gradually expand which direct marketing decisions they want to optimize.

I see a lot of analytic and decisioning companies find this solution-focus works better – people want solutions that require analytic decisioning but aren’t yet always clear enough about how those solutions work to understand they need the underlying technologies/approach. With this new focus, and some near cloud-based analytic technology, Clario is on track to double revenue this year and has become profitable. I look forward to seeing more of them in the coming months.

I have blogged about Pervasive DataRush before and I got a quick update this week. Pervasive often talks about helping companies with “big data” issues and they see this as one dimension of difficulty – with the complexity of processing being done being the other dimension. So some folks, for instance, handle big data but don’t do very complex processing (web analytics for instance). Others have complexity but not so much data (typical enterprise computing). As enterprises move to more data and more complexity they have been forced to use sample data for their analytics (to reduce volume), run processes overnight, adopt expensive clustering technology or do very expensive custom development. Pervasive is focused on using multicore processors (32 or 48 core are under testing right now, for instance) to address these challenges by making the multicore processing power available to enterprises while taking advantage of the low TCO of multicore servers. Two areas of focus – data preparation (de-duping, matching, cleansing) and analytics (understanding, modeling, predicting). Key selling points remain scalability, throughput, cost efficiency, ease of implementation and extensibility. One such use of the extensibility has been their work with KNIME to integrate DataRush analytic functions into this open source workbench.

They have some great benchmarks like a Malstone-B10 benchmark for 10B rows and 1 TB data for web site logs. A published benchmark on a 20 node cluster (4 cores per node) took 14 hours vs. DataRush on a single 32 core machine which took 31 minutes. This is a26x improvement in time but also a massive reduction in running costs like electricity. Interestingly their work on this benchmark also showed some nice scalability – 3.2 hours for 4 cores, 1.5 hrs for 8, under 1 hr for 16, 31 minutes for 32. They have also worked on the Smith-Waterman algorithm (gene sequence alignment) and showed that code written for 8 core machine scaled up to 384 cores without any changes. This is a nice future-proofing example – companies can use Pervasive DataRush to build for their current machines, confident that this will scale as cores increase over time.

Since I spoke to them they have acquired significantly more real customers which is great. Some examples include a healthcare insurance provider who used a fuzzy matching algorithm based on DataRush to replace a bunch of stored procedures. This made it easier to target new prospects and meant that queries did not bring down the performance of the overall system. Another healthcare example was patient matching – data from multiple sources had to be integrated into a single customer data source. Initially this customer was concerned only about accuracy but they found that the increased speed let them iterate more rapidly, trying new fuzzy matching approaches (because it only took minutes to run rather than overnight). Third example was post-payment claims analysis on very large claims files (10s of millions of records).

The core DataRush Parallel Dataflow Engine is the base for the product, with a Java SDK on top. Pervasive have added Data Preparation and Core Analytics libraries (which you can extend) and then layered things like the KNIME and Data Matcher components on top. The KNIME integration provides a node for the drag and drop interface that uses DataRush under the covers. This allows an analyst to take advantage of DataRush without having to write any Java code – important as many analysts are not familiar with Java. Besides integration with KNIME and new operators, DataRush 4.4 has also added a Javascript scripting language to make it quicker and easier to use DataRush without having to write a bunch of Java code. DataRush 5 is adding multi-node support, more analytics and extensions to matching/data quality libraries.

I spoke at an IBM event in Paris recently on More intelligent processes – choices and results. You can see the video (with French slides but me speaking English) here. The English slides are on SlideShare below:

So the question you need to ask yourselves is this – how much like Dilbert’s company do I want my company to be?
… And when you decide, think about the decisions you make and how data (and analytics) could help you make them smarter….

Thanks for Greg for pointing it out.