In our daily personal interactions with businesses of all sizes we all experience sub-optimal business processes. How many times have you tried to buy an item of clothing only to find that the store doesn't have your size? Then when you ask the shop assistant, he responds that a new delivery is expected on Wednesday, but he doesn't know whether that particular item will be included. Check back on Wednesday? Familiar? Of course, we're all so used to these kinds of experiences that we accept them as normal.

From a business perspective, even if it's the norm, it's far from optimal, and the effects are significant: Customers feel that the organization doesn't value their business and that service is poor; products are replenished based on 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 sub-optimal business processes and their consequences: the revenues that are lost and the opportunities missed as a result. It's not hard to find many more examples in almost any business environment. You probably have your own personal pet frustrations that could fill this article.

So how can these kinds of processes become smarter? Before we answer that question, let's look more closely at the characteristics of an Intelligent Process.

Intelligent processes are created through the automation of repeatable, operational decisions by embedding business intelligence (BI) into those processes. But using BI tools to create intelligent processes is far from standard in most organizations today, where operational processes are typically disconnected from analytic processes.

Predetermined business rules and business process logic don't adapt automatically. When the business changes, the logic doesn't adapt. The business process isn't tailored to the individual process instance either, for example, treating different customers differently based on their unique behavior. The result: rigid policy-based approaches that don't treat different processes' instances in a relevant, personalized, or responsive way.

Intelligent Processes Defined
Intelligent processes are relevant, personalized, and responsive. To accomplish this, they need to draw on both real-time and historic data, evaluate the current in the context of the historic, and then trigger other processes.

You wouldn't drive your car with a fuel gauge based on the amount of fuel you had last week, or with a speedometer reading based on the average last month. However, that is exactly how business operations are run today.

Process steps must be relevant to the context of the specific process instance being executed. Since businesses are continuously changing, in practice this means that the process needs to provide real-time visibility to call on real-time data so the latest status can be used. This may include process-state data, such as a real-time measure of supply and demand, or a predicted value, such as a delivery date for a shipment of goods. This data needs to be completely up-to-date or "latest state."

By definition this is a real-time need; the data must be immediately accessible and available to any service that needs it. But to optimize operations, you need to measure at the lowest level of detail, monitor the measurements by comparing them to "normal" or predefined goals to immediately correct problems or automatically take action. This effectively eliminates traditional BI approaches from consideration for use in SOA environments because older tools rely on querying historic data in data warehouses.

To complement real-time data and put it into the proper context, processes also have to be aware of the history related to the customer, product, or supplier involved to be able to personalize the process. This historical data helps the BI service make real-time decisions about the best way to treat a particular customer or product.

For example, if a product is selling significantly faster than normal, the process needs to compare normal sales and the selling process with the latest values. Should the system adjust the reorder quantity? To make an appropriate determination, it has to be able to consider such factors as to whether there were shortages last week and if the spike in demand is temporary. Or it could be that the item is on sale. Factors such as these affect how the process should branch according to analysis of the situation.

Finally, processes must be automatically initiated when significant changes occur that affect any customer, product, or supplier. For instance, if a retail bank customer makes a series of unusual checking account deposits, this may signal an event such as a house purchase. This signal can then be used to trigger a cross-sell program for a mortgage. Or if a rental car company knows that large vehicles are renting faster than usual in one location, it can increase the price to capture higher revenues.

In practice, these three characteristics - relevance, personalized, and responsive - define how processes should use data or call on a BI service to make smarter decisions. This analysis capability has to be embedded as part of the decision-making workflow.

Building Smarts into Processes
The way that organizations build applications has gone from database-centric to middleware-centric. Reliance on middleware and other integration software is critical because it allows for the construction of loosely coupled, modular services that deliver real-time, integrated, flexible applications.

This fits well with the business case for investing in SOA, which is typically made around three key benefits: visibility into business operations, process agility, and real-time integration of business processes.

It's crucial that companies recognize, however, that simply building an SOA won't by itself make processes any smarter. Simply automating a dumb process means that the company now has an automated dumb process!

So before companies begin constructing an SOA, they have to consider how they're going to provide business intelligence and what kinds of BI services can integrate with the SOA environment.

Traditional BI strategies assumed the data warehouse was the source of data for analysis, but such approaches only allowed retrospective analysis of static data. Data warehouses are batch-based and rely on BI tools generating queries to fetch data. Not only are they out-of-date by the time data arrives, they usually don't contain process-state data and therefore make a poor starting point for in-process analytics.