IT people have been talking about agility for two decades now. How to create what the enterprise needs faster is fine. (How that fits with “the answer is someone else’s software, learn to live with it” is a separate question.)
But really, what we should be delivering is enterprise agility: the ability of the business to flex, bend, adapt, seize the moment.
From an IT point of view, this can’t be reached by our traditional means. You’d be forever anticipating potential future use cases, most of which would be unnecessary.
So, to that end, a few architectural methods to increase agile business.
Let steps be waived, skipped, etc. Most of our systems are designed to do the exact opposite: everything must be filled in (in sequence). But many elements of great customer service work precisely the other way.
“No, I don’t want to give you my postal code” (so the store can figure out its reach). “No, I don’t want any optional extras” (on my insurance policy, or as an after-market service plan). “Just get me there by 7 PM” (rebooking a flight at an airline counter). These are far more typical of a day at the coal face.
Call centre interactions (like websites) are the worst for this. Everything is so heavily scripted getting what you came to do done is frustrating.
So unlock your systems. If we were using scrap paper and pens, the clerk could grab a sheet and pick up an address change request in the middle of providing some other service — and handle that later. Meanwhile, having asked about extras, and been told no, no slips for those would ever be created. The customer got speed and is happy.
Our solutions need to work that way. Maybe you get there through decomposition (pull up what you need), maybe through a skip button, but make it possible for employees to work the way your customers do.
Let your systems flow. Banks (to take one example) have systems for your bank accounts, systems for your credit cards, systems for mortgages and credit lines, and systems for your investments. These were created (or sourced) independently.
The customer moves and wants to update their address. Is that a one step operation — or does it have to be done over and over again? Is their self-managed RSP or TFSA that contains a mix of savings, GICs, stocks, and mutual funds an account, or several?
Even when it does all look seamless to the customer (one update) you can create ill will simply because the underlying piece parts update slowly. (I moved at the beginning of this month, and it took Apple’s iTunes Store four days to stop sending invoices with my old address after
I updated it — worse, I’d get old after new as different services invoiced me.)
Data needs to flow into systems. That means passing messages and ticking off the updates.
Flow with demand. In this era of infrastructure on demand, bought as a service, there’s no excuse for putting anyone through a demand crunch (all of us standing, waiting and waiting, while our debit cards get processed in the Christmas season, know what I’m talking about).
Again, parallel handlers and message passers are the answer. Big monoliths are not (and most of our systems are).
These are three starting points to up your enterprise’s ability to prosper. Delivering value from IT begins here.
