JT on EDM

Syndicated from BeyeNetwork

In 2005, Mr Ahmadinejad got 17 million votes and in 2009 he got 24 million.
The question is, where did all those extra votes come from?
The answer, according to this study, is not at all clear.

I don’t write political or personal posts and, despite first appearances, this is not one either. When I saw the BBC News post from which the quote above is taken (Iran: Where did all the votes come from?) I was inspired to blog not so much by the specifics of the situation as by the process followed by the folks who investigated the situation. They took a result, one in dispute, but then looked past the simple facts to see how likely the result was to be reasonable and a truthful representation of the voters’ intent.

For instance they went beyond the facts that the vote percentage for Mr Ahmadinejad only rose by 1% and that the poll some weeks before the election also showed him winning. They drilled in to ask questions like “how many more votes does this 1% swing represent” and “are the regional variations the same or similar in the two elections” and “how would voting patterns have to have changed to generate this result”. All these questions, and the statistical analysis that backs them, result in interesting conclusions.

But, like I said, this is not a political post about the election in Iran. What I want to ask you is how often you do this kind of analysis when someone presents a conclusion? How often is the data that has been used to base decisions in your company put through this kind of analysis? Is anyone asking the hard questions about the data that drives your company?

Yesterday Innovations Software Technology announced the latest release of Visual Rules – 4.5. This is the third in a series of related release and the enterprise components of Visual Rules (Team Server, Execution Server) have been the focus of the last few releases (4.3, 4.4 and now 4.5). I talked about 4.3/4.4 previously and got an update on 4.5 just recently.

First changes to Team Server, which now supports any relational database not just the one it ships with. Team Server – with a repository, support for the collaboration of many modelers, versioning etc. – has been significantly updated in 4.5. In particular, the development environment (Modeler) is very integrated with the Team Server and the new release makes it easy for analysts to interact from the modeler. A simple in-context menu uses more analyst-friendly terms for classic repository capabilities and these can be applied to the whole project or to models or pieces. With this release users can get direct access to Team Server activities and explore the repository. The activities tab shows you edited items, conflicting edits with other users etc. as well as what others are working on. It is a running tally of changes made and models edited etc. The explorer is pretty classic – shows tree structure, information, revisions and audit log. From this tab you can quickly get a nice visual compare (of a version with the current version for instance) to see how things have been changed.

Team Server also offers version-specific dependency management so that rule projects, artifacts and java components can be linked so that the server can generate code for a project. These dependencies as well as a move to execution artifacts allow the QA and deployment tools to add Maven support to their existing support of Ant. Plugins for Maven support QA and deployment tasks (generate code, check project etc) and are in addition to the existing Ant scripts and support integration deployment and testing.

Moving on to the Execution Server, 4.5 has added a number of features. While 4.4 made it easy to deploy rules as web services, decision services I would call them, 4.5 has made this easier. 4.5 also has the concept of various deployment artifacts and stores them in your choice of relational database. In addition, metadata associated with artifacts like effective dates is supported so that, for instance, multiple versions of a service could be deployed with different effective dates.

Execution reporting has also improved with activities and rule stats logged into the database. Users can click on a statistics button from within the Execution Server environment to collect the information on execution and display the statistics on the graphical representation of the rules (just as the test environment does with test data). The execution server can store a complete set of execution data that is used to produce this graphic and that could be used for further analysis.

Modeler has a new editor that allows you to specify dependencies and the tool manages those that can be inferred automatically. This allows artifacts managed in Modeler to have dependencies that allow code generation to pull in the dependent objects.

Test suites have been added to the Modeler. Individual tests are now bundled up into a test suite. Multiple tests can be run with a single click and the overall results are displayed. The visual debugger can also be started from within the test environment, allowing you to jump into the debugger from a test and then walk through the whole sequence of rules.

Service mocking was also added to support testing. This allows you to mock up a service during development to make it easier to develop the rule service independently and then test it even though a required service is either not built yet or not available for testing.

4.5 also allows the import of decision tables from Excel. The user can specify a sheet and a basic decision table is then created. Headers can be mapped to data and the decision table is then loaded ready to edit. This is intended as a one-way import not an Excel-based editing environment but will allow those with existing decision tables to rapidly put them to work in Modeler.

Two final usability features. Copy and Paste of values both individual and structured data has been added e.g. in properties tabs, and this is obviously useful for test development as it allows you to copy standard data structures between tests quickly and easily. Modeler also allows the auto creation of data elements in a way that allows you to change the type easily before creating. This makes the creation of data elements as you go more efficient.

Another session at Brainstorm, this time a case study from Genentech. Genentech has many policy documents that are interrelated, complex and lengthy and yet essential to operations – employees must understand them and follow them. As Genentech has made progress on its process management initiative it has found that getting the participants in the process to follow the policies is really hard. With this in mind they have looked for new ways to help people understand the policies. The processes involved tend not to be tasked-based but information-based – highly iterative, interactive processes. People performing these processes used all sorts of ways to try and find out what action to take, what decision to make – they called people, asked their staff to find out etc.

As an example, Genentech has over a thousand cost center managers. There is a wide range of policies relating to managing cost centers and compliance with these policies and regulations was a challenge. Training was not viable so they went out and sought a visual approach to this. To address this they looked for ways to improve the visual communication of the policies – not just words, but visuals too.

Just because the end result would be visual they could not avoid the analysis work – they still did a bunch of analysis to develop decision trees, role analysis, metrics, process maps etc. But the idea was to extract from this the key things a cost center manager had to do. After an interactive process with a real focus on simplifying whenever possible they found four key areas of activity – what to do when someone became a cost center manager, what to do when someone is added to your cost center etc. These four activities become the core navigation of the system while help/contacts, forms/tools and FAQs were common classifications of information. Each had a brief (10 second) animation and some content about the activity. Users could also view the big picture and see all the animations as a set.

A similar effort was focused on simplifying contracts – help people understand when they need a contract and which kind. Complex decision trees and process maps were built but the process remained complex – the master decision tree had more than 350 potential outcomes as well as many different groups for handling different kinds of contracts. And this really mattered at Genentech as they are very decentralized – lots of people can initiative contracts.

They built a short wizard – focused on asking the right few questions quickly – and in 4 steps of just a few choices each were able to identify if a contract was needed, who the right contract group was and payment details. Getting the order of questions right was crucial and making defintions (for goods v services, for instance) user context-sensitive helped people understand the definitions better. The first two questions then narrowed the range of exceptions so that the user could easily scan the list and say yes or no to the exceptions.

Of course contracting is part of a broader process – Procure to Pay. The process models are also displayed visually and each step links to some visual information of the policies that impact that step. The use of more visual representations has really helped people find and follow the policies. She referenced Vizthink a community on visual thinking and XPLANE, the company they worked with.

This last product sounds like the kind of interactive/reflexive questioning that rules vendors are adding to their products (notably Corticon, Blaze Advisor and Idiom). In both cases it seems to me that an opportunity exists for more automation of these decisions as well as visual support of them.

I presented on Using Business Rules to Make Processes Smarter, Simpler and More Agile at the Brainstorm conference. Here are my slides. I am going to record this one I think and post a recording soon also.

I am speaking at the Brainstorm conference in San Francisco and blogging a couple of sesssions. First up today is Michael Melenovsky (formerly of Gartner) on Accelerating BPM Adoption – creating a vision and establishing a roadmap. Michael made the great point that companies sometimes get started with BPM to try it out and then bog down because they don’t have a plan for getting to some defined future state – they don’t have a roadmap. Any roadmap requires an understanding of where you are and what direction you want to take.

Michael sees BPM initiatives starting in one of three areas – each with their own focus and challenges:

1. Executive Leadership – top down with an objective of strategic alignment and an increase in corporate performance. But this can only be pushed down so far creating a limit on its effectiveness.
2. Line of Business Management – bottom up with a focus on business unit productivity, reducing cost, increased agility. Can be a very long term approach and it can flag if there is no comprehensive approach.
3. Middle Management – middle-out focused on operational improvement and improving cross-departmental coordination. Process modeling and standard procedures dominate and the approach runs into problems of too many process maps and not enough buy-in from top and bottom.

Regardless of which approach is taken, the process layer makes explicit the role people and systems play in each step of the process. Instead of IT focusing on the system elements and the business on the people to people elements, the process layer gives both sides a common view. In doing so, it also allows non-technical folks to make changes to it. Lastly, and most important, the process model increasingly drives execution.

It is common to use the classic Michael Porter model of people, process and technology as supporting the business.  Line of business managers tend to believe that the people in an organization are the critical differentiation “our most important asset is our people”. IT organizations tend to believe that technology is the critical advantage. And this difference in belief systems is a big element in the business/IT gap. But process is a third leg with Six Sigma and other process people regarding that as the competitive differentiator. These folks are guiding people and technology and trying to make fact-based decisions. But if process is to be important, someone has to own it. Process ownership cannot be handed off to either IT or the business – it must be handed off to PROCESS people. This requires incentive and compensation processes to reflect this.

So, back to the roadmap. Michael argues that the value of BPM represents the vision. This can be defined in terms of  the value to the business and the value to the IT organization. First, the value to the business:

1. Deliver productivity increase
2. Ensure strategy execution
3. Create a more nimble, agile organization
4. Making possible greater innovation

Value to IT:

1. Significantly reduce development time
2. Create more comprehensive architecture
3. Greatly reduce application maintenance costs
4. Shift attention to higher value topics by eliminating firefighting

Given these values, and the implied vision, there are some critical success factors for accelerating BPM adoption the folks at Babson have identified 6 CSFs:

• Strategic alignment
  Continual linkage of organization priorities to processes – from strategy to process to applications and systems/tools.
• Culture and leadership
• People
  You must get people and groups to apply process related expertise.
• Governance
  Processes and policies for managing processes. The organizational structure must adapt to create process owners and process teams. Michael also believes that a process office and a process council/transformation steering committee make a huge difference.
• Methods
  Successful adoption requires a consistent set of methodologies and approaches. You must find the real process and exceptions (XMBL or IDS Scheer AVE), drive alignment (Balanced Scorecard, Rummler Brache), analyze performance (Six sigma), value continuous improvement (Lean), and finally optimize process (value stream).
• Technology

While these are pretty generic, and true for more than just process, any successful process implementation is going to need to focus on all of them. And even technology folks see culture and people issues as the major barriers. Addressing these CSFs requires cross-functional process teams involving business and IT.

Finally, crafting a roadmap involves critical steps:

1. Identify key stakeholders
2. Define BPM in terms of the benefits we expect to get
3. Determine the phases for delivering this value
4. Gap analysis using scenarios to see what will work
5. Develop a three year roadmap for BPM

I got a chance to catch up with the folks from IBM/Cognos to discuss their (fairly) recent announcement of a formal OEM relationship with SPSS for PASW Statistics (briefly reviewed here). I discussed their original, less formal, partnership previously. IBM Cognos has a long alliance history with SPSS, often working with them to co-sell into accounts. Feedback from IBM customers was that they wanted more and better statistical analysis in the Cognos platform, hypothesis testing, more advanced correlation and regression analysis, classification and scoring tools etc. Essentially customers were demanding advanced analytics to round out the platform.

IBM sees a distinct separation of algorithms between those that are descriptive algorithms and those that are predictive or more data mining-oriented. Descriptive analytics can typically be used against any kind of data to perform statistical analysis while more predictive ones need the person applying the algorithms to understand how the approach taken by the algorithm intersects with the problem domain so they can find a fit.

While there is clearly demand for both kinds of algorithm in their Cognos customer base they find that easy add-ons to the Cognos platform tend to sell better than “new” interfaces/skill sets. With this in mind the next major release of IBM Cognos BI will focus on bringing descriptive analytics and the associated graphs and statistics into the standard reporting/dashboard environment. This will have the lowest barrier to adoption both because the user interface is familiar and because these algorithms need not be trained or formally analyzed the way data mining algorithms must be.

The new OEM relationship with SPSS for PASW Statistics will allow users to apply the SPSS statistical libraries directly to data already being handled by Cognos. These routines will be applied to the data and displayed in the standard reports and dashboards with no new UI or expertise requirements.

There is a lot to like in BI / Performance Management tools adding more advanced statistical tools. Analytics, it has been said, simplify data to amplify its value and this is a good thing in a world with too many reports and, increasingly, too many gauges on too many dashboards! I remain intrigued by the potential for Cognos, ILOG and SPSS to interoperate more closely to deliver decision management applications but this is a nice step along the path. There is more on how Cognos and SPSS work together on the IBM site.

I saw ServiceBench when I presented at the Warranty Chain Management Conference and got a chance to get a more detailed presentation just recently. ServiceBench is aimed at the Service Supply Chain and is now part of NEW (who also presented at the conference). The service supply chain is often very complex because of the number of entities that are involved (i.e. retailer, service provider, manufacturer, TPA) and consumers often find it hard to determine where to go for help or service. It can also be very hard to determine who is responsible for the cost of the repair.  Once you figure out that a service call is necessary then you have to select someone to do the service, find the parts, get the customer, servicer and parts all in the same place at the same time etc. Everyone is trying to improve customer service, reduce their costs and simplify the business process for service providers.

ServiceBench creates a data hub for this information for service, repair, delivery, warranty, extended warranty. ServiceBench is a single internet-based system with access to a common set of data. It is designed to resolve more problems on first call and provide better and more complete data. This is all based on a common platform for Service Management and delivers what they call  Service Intelligence across the products.

• Service Call Management
  A subset of CRM call center functionality focused on service calls. Handles event capture, dispatch and ServiceLocator. Typically integrated with a major CRM system.
• Field Service Management
  Contracts, surveys based on statistical model developed for each, territory management, coverage analysis etc.
• Parts Management
  A lightweight product to make it easy to order parts from within the same portal. NEW is in the process of extending this to create a virtual inventory management product to handle shipping/ordering parts from one of several locations etc.
• Claims Management
  The core product capturing registrations, claims, returns, payments. Claims is often the first module and drives adoption. Claims data is often the cleanest and most complete. As a result it drives a lot of analytics in the service supply chain.

I am not going to try and describe all the capabilities of ServiceBench but will focus on the analytics it provides – service analytics. All the transactional applications run on a common Oracle database. Lots of data is collected about service calls and service call / claim quality. Most customers are focused on a weekly analysis cycle when the collected data is transformed for analysis. Everything is customizable for a customer but typically customers focus on financial, performance and quality analysis. Performance analysis might include part or service provider performance for example. Analytics often cover fraud warnings, travel costs, labor costs, parts costs, claim trending and internal process improvement. Customers define KPIs and can see the trends across periods – percentage of claims with a bad address, for example. Dimensions for slicing are defined based on the customer’s data e.g. product line or geography. The whole environment is very warranty and service focused and can be localized to a specific role. Besides this general analysis there is also a move to support pay for performance in the service supply chain. Pay for performance can be complex in terms of how service providers are rewarded. Others, like NEW itself, route more work to high quality service providers, using the analysis to identify those service providers who should get more work. While customers are not typically changing behavior from analytics directly they are updating data and rules based on analytics – the beginnings of a true analytic feedback loop.

ServiceBench also collects business rules as part of the setup. Some rules are only changed by the administrators e.g. those to keep data clean. Customers can change some rules, particularly thresholds like time allowed to submit claims. ServiceBench uses a proprietary rules engine and some coding to provide this environment.

One of the most interesting things about talking with NEW/ServiceBench was listening to them describe the sequence of their customers. ServiceBench is always trying to help its customers optimize their service supply chain. Most have never had this of the robust data organized in a manner that enables decision making, before so they often spend the first couple of years just exploring and learning about their data for the first time. As they get familiar with their data they begin to react to trends and analysis. Ultimately ServiceBench/NEW would like to see customers use analytics to drive behavior but it takes times for a company to trust the analytics and move to exception only reporting, for instance, and most begin by reviewing everything.

As an example, fraud analysis involves lots of data. Rarely can one find or claim fraud with a few points of data among thousands of warranty claims. To find the needle in the haystack you need to highlight trends and outliers. For instance a trend which involves increasing use of bad or unrecognized addresses (per the USPS) on claims can be a leading indicator of fraudulent behavior.  However it also could be an indication of a contractor working in areas with a lot of new construction.  ServiceBench warns those entering an address that it is unrecognized by the USPS and it can be edited or entered anyway. ServiceBench keeps track of this and many other points of data. Analysis includes identifying high rates of re-submission, regularly requesting greater reimbursement amounts than are approved, high incidence of labor only claims etc. As this data is collected and analyzed it can also be compared to data collected in customer surveys to find correlating information such as customers reporting that no work was done. ServiceBench in currently testing a beta product that pulls claims suspected of fraud into a work queue automatically based on this kind of analysis – the beginning of fraud decision management.

Just as it takes companies time to get used to trusting the analytics, it takes time to get used to queuing too. Queues get used for approvals, claims review etc. Lots of these are based on the company’s own rules. ServiceBench aims at 93-97% auto adjudication for claims – they want customers to let the system make decisions and it takes customers a while to accept this too. Initially customers want to see everything, even the claims being auto-adjudicated, and only over time will they move to reviewing just the queues of items needing review.

ServiceBench is an interesting example of a product moving along the decision management maturity curve. It is using rules, but not yet really exposing all of them to business users to maintain themselves yet. They are integrating data and providing analytics, that their customers use to change their behavior, but the analytic feedback loop is not yet automatic. And their customers need to be led gradually to accept high rates of auto-adjudication and to trust analytics.

A quick note to point out some newly available resources on decision management.

First, Claye Green of Technology Blue (a Decision Management Solutions partner) wrote a nice little piece on barriers to decision management success.

I have been busy too, writing some shorter briefs on Decision Management topics. These are available without registration from the Decision Management Solutions site. You can always find the current set at decisionmanagementsolutions.com/briefs and here are those already written:

• Adaptive Control
• Advantages of Business Rules
• Business User Rule Maintenance
• Decision Management Defined
• Decision Services Defined
• What is a BRMS

These are also being translated to Japanese and Korean by my partners in those countries so keep checking back if those languages are interesting to you.

Syndicated from BeyeNetwork

Timo Elliot had an interesting post Gartner on Collaborative Decision Making in which he discussed a report from Gartner called The Rise of Collaborative Decision Making (and thanks to Nic Smith of Microsoft for the link). This kind of ad-hoc, collaborative decision making is critical in companies and technology to support it is thin on the ground. In fact this was the topic of an Andrew McAfee post, The Diminishment of Don Draper in which he made the point that unsupported, gut, expert or oracular decisions have some serious limitations:

• Opaque – you can’t explain them
• Not amendable – they are take it or leave it propositions
• Not disconfirmable – there’s no explanation of how they are made that can be analyzed
• Not revisited – because there is no way to “edit” them

This prompts two thoughts. The first is that the kind of technology David Ullman has been working on (Accord, reviewed here) is worth considering for this kind of collaborative decision making. A decision supported by Accord would be transparent – you could see why you decided the way you did – as well as editable over time so that new data, or new options, could be integrated and evaluated.

The second is that these same characteristics are true of decision made by your front line staff when they interact with your customers. They often can’t explain them, not that anyone really asks, and they tend not to be amendable because the customer moves on afterward, happy or not. There is no way to analyze the thought process of these staff and so no way to revisit them to devise a better approach in the future. And these issues are more serious because we are not talking about the executive team (complete with lots of experience, assistants and analysts, deep business understanding etc) but about your least experienced, lowest paid staff.

In this second scenario one effective approach is to use Decision Management to put the decision making into your systems – into Decision Services that support your systems to be precise. Embedding the policies, regulations and best practices that you want applied as rules and using the data you have to drive analytic models with simply outputs (scores, for instance) gives better decisions to the front-line while ensuring transparency and an ability to analyze your decisions and learn what works so that you can constantly improve.

So figure out how to help your executives and managers collaborate around decisions effectively and use Decision Management to ensure you know what’s going on at the front line.

I wrote an article on customer decisioning – To Focus on Your Customer, Focus on Your Decisions – in Frost & Sullivan’s Customer Contact eBulletin. Enjoy