Skip to main content
Transaction-centric decisioning

In my interview with Jim Ericson, I talked about turning processes around so instead having a process definition to drive the way a transaction was handled, use the data that comes in on the transaction to drive the processing. So what, exactly, does this mean.

Let's consider an example - processing an order. In a process-centric definition I lay out the steps in a process and then feed transactions in to the process in turn. Each is handled in a similar way, following a fixed set of steps. So far so good. This is nice and repeatable and I can monitor and improve it. Over time perhaps I decide to process orders from established customers with good payment history differently from other customers so I develop a branch in my process to handle these expedited orders and I add a decision service to decide who is an "established customer with good payment history". This works so well I think about segmenting my customers and their orders more and more precisely. At some point my process becomes overburdened with branches and options and I decide to split it up and have a decision service decide which sub-process to invoke - each of these processes may have additional decisions within them but the first step is a decision-making one.

At this point I have turned my process around - now, instead of being managed by a process definition, how I handle a transaction is determined by the data that comes in on the transaction and the decisions I make with that data. I might predict future profitability from it, assess risk of non-payment, check contractual terms or whatever but I am fundamentally using the information on the transaction to drive my processing. The data in the transaction, or metadata attached to it, would determine what scores my predictive models generate and the combination of these scores and data would determine which rules fired and that would decide which steps to take to complete the transaction. This let's you "invert" the process and have it flow from the customer to the organization.

Why is this a good thing?

  • It makes you more decision-centric; you're making decisions all the time about what this transaction wants, says and does. Otherwise the process is still in control.
  • It allows for more intense personalization, using the information that comes in on the transaction (or that can be found about you) to drive the way you are treated as an individual or as a company.
  • It lends itself better to an event-based approach to processing and supports complex event processing.
  • It lends itself to self-service as verifying the data for completeness at the start is likely sufficient to determine how/if it can be processed without human intervention.
  • Outsourcing elements of your processing can be done without impacting risk management or compliance as the key decisions are taken up-front, before the transaction is handed off.
  • Costs for inspections, reviews, third-party data and so on are reduced by making decisions earlier and not forcing all transactions through the steps in the process that incur these costs

Clearly some of these benefits can be gained by building a multi-path process but at some point it seems to me that inverting the process will be cleaner and more effective.

related posts