When I used to live in the world of SOA – business agility was all the rage. SOA would allow IT to respond at the speed of business, business rules could be re-worked and implemented in IT processes and systems in matters of weeks not months or years. Or so we promised.
The problem, is that true business agility lies in being able to handle an exception, as well as re-engineer the process. The main cultural challenge to this is control. Businesses put in systems and processes to reduce risk and ensure that everything is predictable and decisions are made according to well laid down principles.
But the world isn’t like that – it can be risky and unpredictable, and, whilst you do need systems and processes, you need to be able to account for the exceptions – which often happen more often than you think. The irony is, as SOA-type systems handle processes more and more effectively, it means that people have less to do with processes, and therefore get more involved with exceptions. The more processes get standardised the more costly exceptions become as a percentage of operating expense. Customer requirements, supply problems, pricing can move incredibly quickly, and an SOA architecture isn’t going to help you when the problem is not knowing who to call.
You need to overcome the cultural barrier of letting your employees think, rather than administering processes. The more you have invested in ‘standardisation’ the more time your employees will spend handling exceptions. Exceptions have be to embraced as a potential source of innovation rather than frowned upon as the 3 year ERP roll-out should have eliminated them.
From a technology point of view, employees need the social software tools required to resolve exceptions, and to disseminate the tacit knowledge that goes hand in hand with exception handling throughout the enterprise. You need to be able to quickly find the veteran who knows exactly what to do when a particular supplier drops the ball and you need to bypass standard procurement in order to meet a customer’s expectations. Once found, the resolution to that exception needs to be captured in a way that it can be found long after the veteran has retired.
I know of mobile phone retailers who have lost sales as recent post code changes (zip codes) have meant the ‘automated’ system failing to reconcile bank addresses with the UK Post Office database. The sales rep had to cancel the contract because he didn’t know who to call and felt that even if he did they wouldn’t be able to resolve the situation.
I know of software sales teams in large software organisations such as IBM, HP and Microsoft who rely exclusively on one individual who is an expert at the ‘special bid’ or discount process (discounting is such a common ‘exception’ in software sales processes I think list price is actually the ‘exception!)
I am not saying that SOA cannot deliver business agility – it can get you half way there by automating processes and integrating systems that previously could not be done, or would not have been cost-effective. But you’re only half way there if your business process integration strategy isn’t matched with a social software strategy to handle exceptions.