Christian Plaichner wrote a nice article recently in DM Review about Agile Business Process Management with Sense and Respond. There's lots of good stuff in the article but I do think one "clarification" is called for.
In many cases it is not process change that I see happening in response to events. Many core processes are well defined and very stable, with lots of alternate branches defined for most if not all of the things that might happen. What must happen, however, is that a decision must be made as to how to respond to the event - will one of the existing processes or sub-processes work or must this be escalated? If it must be escalated then to whom? Christian defines agility as the ability to respond to unforeseen developments but I might add that it is also the ability to respond to foreseen but unpredictable developments. For instance, the DMV in California can foresee that there will be changes to regulations, and can design systems and processes on this basis, even though it does not know exactly what change will be requested.
Christian goes on to discuss how you need to adapt to customer demands and other information about how customers preferences are changing. I regard this kind of customer-centricity as decision-focused rather than process focused. For instance, a customer buying a product from me is unlikely to give me any clues that will cause me to change the basic process of ordering, fulfillment and billing. They might well, however, give me clues that lead my risk-based pricing decision to result in a different price or billing terms or that might cause me to make a different cross-sell decision. If the decision points within a process have been automated using a flexible, agile technology like business rules then often the process can be changed for a specific instance simply by having the decision rules pick up the additional context and route the transaction differently based on that.
As Christian develops some of the specifics of an SARI you can also see how injecting predictive analytics into a decision can help - if I can predict the likelihood of delay, say, based on data I have then I can right rules that decide when to re-route something. I don't need to wait for actual delays to occur.
I liked his diagram of an SARI but have a slight variation on it: