SeeWhy defines intelligent processes as the automation of repeatable, operational decisions by embedding business intelligence within business processes. So what does that mean? Most operational processes are disconnected
from analytic processes, resulting in rigid, policy based approaches. Different processes instances, individual customer transactions for example, are not treated in a relevant, personalized or responsive way.
In short, every process instance is treated uniformly, governed by a predetermined set of rules and business logic. These rules don’t adapt automatically either as the business changes or apply more tailored logic to each process step.
Intelligent Processes Driving competitive advantage from smart, automated business processes in Service Oriented Architectures A short product discussion paper published by SeeWhy Software Limited 2006 SeeWhy Software Limited. All rights reserved. Untitled Document Page 2 of 8 2006 SeeWhy Software Limited. All rights reserved. In many cases it makes more sense to perform analysis on transactions while the business process set is "in flight" rather than waiting until afterward. IDC Introduction Most processes today are not intelligent. Yet as leading organizations move to Service Oriented Architectures (SOA), they are building intelligence into their business processes and driving competitive advantage from their daily business operations. This paper shows you how you can embed smarts into your business processes. SeeWhy defines intelligent processes as the automation of repeatable, operational decisions by embedding business intelligence within business processes. So what does that mean? Most operational processes are disconnected from analytic processes, resulting in rigid, policy based approaches. Different processes instances, individual customer transactions for example, are not treated in a relevant, personalized or responsive way. In short, every process instance is treated uniformly, governed by a predetermined set of rules and business logic. These rules don t adapt automatically either as the business changes or apply more tailored logic to each process step. This is far from optimal, and the effects are significant: customers feel that their individual business isn t valued and that service is poor; products are replenished based on gross assumptions, leading to stock-outs, loss of revenue and customer frustration; prices are fixed even when demand is fluctuating wildly, leading to revenue not being maximized; customers churn due to unresponsive organizations that fail to react when poor service is delivered. These are just a few day to day examples of failing to make business processes intelligent. Their consequences the lost revenues, the opportunities missed are severe and it s not hard to find many more examples in every business environment. So how can these processes be made smarter? Before we answer this question, let s look more closely at the characteristics of an Intelligent Process. Untitled Document Page 3 of 8 2006 SeeWhy Software Limited. All rights reserved. What does an intelligent process look like? We can summarize what makes a process intelligent in three points: Intelligent processes are Relevant, Personalized and Responsive. " Relevant Process steps need to be relevant to the context of the specific process instance being executed this particular customer, that particular order. Since business is continuously changing, the process needs to call on real time data so that the latest status can be used. This might include process state data, i.e. the current status of a process, and say a real time measure of both supply demand plus a predicted value such as a delivery date for a shipment of goods inbound to the warehouse. This information needs to be the completely up to date, latest state. This is by definition a real time need and the data must be immediately accessible and available, on demand, to any service that needs it. This effectively eliminates approaches relying on querying historic data in data warehouses or heterogeneous data sources. " Personalized Processes need to be aware of history relating to the particular customer, product or supplier involved in order to personalize the process. This historical data provides critical context to allow real time decisions about the best way to treat, say a particular customer or product. So for example, if a particular product is selling significantly faster than normal, the process needs to compare historical normal sales and the normal selling price for that unique item with the latest values. The intelligence process should answer the question: should the system adjust the reorder quantity or not? It could be that there had been shortages last week and the spike in demand is temporary. Or it could be that the item is currently on promotion, which should show up in the latest selling price and the resulting demand. All of these factors affect how the process should branch according to analysis of the individual situation right now. " Responsive Processes need to be initiated automatically when significant changes occur affecting any customer, product, supplier or member of staff. This can only be done by monitoring each event in the context of history to determine what is significant for that unique customer. So for example, if a retail banking customer makes a series of deposits into their checking account which are unusual for him or her, then this may signal a life event such as a house purchase. Such a signal can trigger a cross sell program for a mortgage or cash deposit account. Untitled Document Page 4 of 8 2006 SeeWhy Software Limited. All rights reserved. Will your shiny new SOA anticipate the Business Intelligence needs of the business? " Smart processes " Visibility of business " Alerting & notification " Analysis triggered processes Equally, for a rental car company, if 4x4 vehicles are renting faster than usual in one location, an increase in the price could easily yield higher total revenues. In practice, these three characteristics, relevant, personalized and responsive define how processes should use data, or call on a Business Intelligence Service to make more intelligent decisions. This analysis capability needs to be embedded as part of the decision making workflow. Building intelligence into business processes The way we build applications has changed. Now we build using loosely coupled modular services to deliver a new generation of real time, integrated and flexible applications. This is a fundamental shift: from database centric architectures to middleware based applications often under an overarching umbrella of Service Oriented Architecture (SOA). The business case for the investment in SOA is often made around three key benefits: flexibility, reuse and real time integration of business processes. But having built your new SOA, will your processes be any smarter? Simply automating a dumb process means that you now have an automated dumb process. This is important to the project being perceived as successful by the business. Before embarking on your SOA you need to consider how you are going to provide Business Intelligence; you need to consider the types of BI service that could integrate with your SOA or BPM environment. Traditionally when we think about Business Intelligence, we think of the data warehouse as the source of data for analysis. But existing Business Intelligence infrastructures were built for retrospective analysis of static data not real time SOA environments. Data warehouses are batch based and rely on BI tools generating queries to fetch data; they use out of date data and usually don t contain process state data, making them a poor starting point for in-process analytics. Untitled Document Page 5 of 8 2006 SeeWhy Software Limited. All rights reserved. NoYesDon't KnowPercentage of SOA implementations where the BI requirement is addressed. Yes: 13% No: 79% Don t Know: 8% A BI tool can be presented as a Web Service, but this does not solve the problem that the underlying data is out of date and that the database still needs to be queried, with resultant unpredictable response times. Moreover, the types of analysis needed in SOA environments do not fit SQL well (see the section Stream Analysis below). Traditional BI architectures designed for reporting on a process do not fit well when, logically, the events themselves should be analyzed either in parallel to the flow, or as a process step. For these processes analysis of events should be event driven i.e. the analysis is of the event in context of history. To be embedded within a process, requires Business Intelligence to act rather differently. It needs to be both process and service oriented. Let s look at both in turn. " Process oriented Process oriented is not process based (where the process has to be explicitly modeled in a BPM tool), but oriented around optimizing the outcome of a particular process where the process itself may or may not be explicitly defined. This process orientation is a prerequisite of any closed loop business intelligence where actions are automatically driven from the results of analysis, or relevant operations staff alerted if the decision cannot be automated. So both closed loop and process orientation are key components of BI in service oriented environment. " Service oriented, event based Automated processes are essentially driven by events, and therefore it is implicit that in order to create smarter processes you need to analyze and interpret events. This means analyzing data, event by event, either in parallel with the business process, or as an implicit process step following a service request. Stream analysis Service oriented analysis is also fundamentally different to traditional query based analysis since it is sequential rather than batch based. Sequential analysis analyzes data as a stream in flight by comparing the Untitled Document Page 6 of 8 2006 SeeWhy Software Limited. All rights reserved. each event with historical patterns to determine whether a problem or opportunity exists. This type of analysis is particularly relevant to in-process decisions and typically difficult to achieve in a SQL based environment. A process might need to assess the impact of an individual event, a combination of events, or compare a current event with a historical normal all of which can be challenging with SQL. For example, a common requirement is to be able to detect when a particular customer is spending less than usual, for this hour and day of the week or month. To do this you need to calculate, say, the average order value for product X for customer Y in the last hour, for each hour of the day, and compare this with the average sales for customer Y over the previous three months for that hour and day. To do this calculation continuously for every customer transaction, in real time, where you might have 30,000 products and 10 million customers is clearly beyond the capabilities of SQL. Planning for BI in your SOA rollout All implementations of a Service Oriented Architecture will need some form of Business Intelligence. Lessons from recent history should remind us that we need to plan proactively for BI requirements. Business users were frustrated by the rollout of Enterprise Resource Planning (ERP) applications until Business Intelligence capabilities were added (in many cases as an afterthought). Similarly, when early adopters of Enterprise Application Integration (EAI) did their first implementations, in many cases no plan was made for Business Process Management making the implementation too fragile to easily add the capability later. Now with Business Intellligence for SOA, we need to avoid these mistakes and plan for BI capabilities to be incorporated into the environment from the outset. For example, if you need to analyze a sequence of service requests that make up a process chain, you ll need a common unique identifier in each service request. It is clearly much more efficient to build this in for BI purposes at design time, rather than retro fitting. You also need to consider your choice of Business Intelligence technology and supplier. Different products have different ways of interfacing with the other components of your SOA, so it pays dividends to consider how to integrate the different components. Untitled Document Page 7 of 8 2006 SeeWhy Software Limited. All rights reserved. BI for SOA with SeeWhy Just as application architectures have changed to embrace SOA, Business Intelligence (BI) is also changing by becoming a real time, event driven service; critical requirements for BI in a Service Oriented Architecture. In practical terms this means that you need to build in the capability to: " Initiate processes based on analysis For example, initiate a cross sell process based on the customer s latest actions, or respond automatically to subtle changes in demand. " Provide support for decision processes For example, provide a service that can answer complex questions in real time, such as: What s the current estimated delivery date for this shipment? SeeWhy is the first of a new breed of real time event driven Business intelligence platforms, designed from the ground up for Service Oriented Architectures (SOA). All SeeWhy products have been built themselves using a Service Oriented Architecture and are designed to be integrated into SOA applications and processes. Organizations use SeeWhy to automate decisions, initiate processes based on combinations of events and operations staff use SeeWhy to monitor detailed business operations. This might include monitoring customer transactions on a website, tracking shipments, alerting on systems and process performance, or analysing individual item sales passing through a point of sale system to detect an out of stock condition or fraud. Driven by business events and service requests, analysis with SeeWhy is automatic, continuous and real time. This event driven architecture makes it straightforward to provide in-process analytics: in short to make business processes intelligent by embedding Real time Business Intelligence directly into the business process workflow. This all happens in real time, automatically, and continuously. Intelligent processes use real time BI as part of their process to: 1. Publish events to SeeWhy for Monitoring Generate alerts. For example: Notify me to adjust pricing rules when demand changes Initiate a process based on analysis. For example: Detect a churn signal from a customer and initiate service call process Untitled Document Page 8 of 8 2006 SeeWhy Software Limited. All rights reserved. 2. Request information Provide decision support within a process. For example: Request the latest expected delivery time for a shipment in transit to the distribution center These two capabilities illustrate how SeeWhy enables business intelligence to be embedded in both automated and manual processes at run time. SeeWhy products SeeWhy is available in two versions, SeeWhy Community Edition and SeeWhy Enterprise Edition: " SeeWhy Community Edition SeeWhy Community Edition is designed to enable developers to have access to the latest Real time Business Intelligence technology. It is a downloadable version which is: -- Free to download -- Free to develop -- Free to deploy -- It is driven and supported by an active community of developers. SeeWhy Community is designed for developers and technical enthusiasts building small scale production deployments in non-critical environments. " SeeWhy Enterprise Edition SeeWhy Enterprise Edition is fully supported enterprise grade software designed for mission critical environments. Tested in deployments of hundreds to thousands of events per second, SeeWhy Enterprise scales across multi- processor and multi server environments to enable analysis of very high event stream volumes. For more information, contact: SeeWhy Software USA: 101 California Street, Suite 2450, San Francisco CA 94111 UK: 1 Victoria Street, Windsor, Berkshire, SL4 1YB www.seewhy.com All trademarks acknowledged. SeeWhy, the SeeWhy globe device, Adaptive Interpretation and Instant Insight are trademarks of SeeWhy Software Limited.