For several years now companies have sought increased agility.
What precisely does this mean? — and is it something that can be achieved easily?
In one sense, agility is simply the ability to reconfigure as events occur.
Reconfigure, as used here, means that the process can be reconstructed on the fly to give the customer the unique experience desired.
It can also mean reconfiguring to meet a challenger, to adapt to local conditions, to deal with a change in law or regulation.
To dig deeper into this concept, what agility really comes down to are three key things:
Much more flexible processes
Treating processes as “events”, “event fulfilment”, “connected events”, etc. allows for their decomposition into options.
This, in turn, can be used to empower employees to actually satisfy the customer’s real needs at the time, rather than fitting them into the process as it has been defined.
For early steps, find ways to take information in the customer’s — not the system’s — order; allow for multiple outcomes (such as taking back goods that are poorly documented, as does Nordstrom, or waiving change fees, as does WestJet); monitor employee changes to processes and treat these as learning experiences, not issues on non-compliance.
Most enterprise software does a very poor job of this.
It tends to be built on a model of the “best practice in this process”. Yes, you can optimise if you do that. No, you can’t be agile.
Ideally, instead of finding packages that implement other peoples’ practices, we’d find pieces that implement bits of processes, and string them together. Regular strings we might write some supporting code for. But the person on the front line is always able to use their own brain power to do things as they need doing situationally.
This notion of the “barely repeated process” lies at the heart of true enterprise agility.
Note as well that these components are small, and lightweight. Each does one job very well. They can be built using traditional development methods quite as well as with recursive or agile methods.
Using some services from the cloud intermixed with things running on your own servers is also well within reach, allowing for migrations back and forth as cost/benefit profiles change.
They do depend on doing the heavy lifting involved in information architecture rather than building a package architecture.
Much more collaboration
Treat an employee as a problem-solver and give them collaborative tools to reach out at the time information is needed (ranging from instant messaging to social directories for the firm) to help a customer or supplier.
Reward those who respond and help through recognition as well as for particularly good service delivered by the front-line employee.
Use other social networking tools (blogs, wikis) to transfer knowledge and encourage appropriate behaviour.
Managers should study what works and find out if customer delight is being created: if it is, do more of it.
What all this is designed to highlight is that how you deal with people and their contribution is as much a part of agility as is all the technology in the world.
How your enterprise manages, rewards, evaluates, hires, etc. is as important as anything “systems-related” that gets delivered.
Avoid the hierarchy and empower action
There are three kinds of decision: a right choice, a wrong choice, and the failure to choose.
Constantly appealing to those above you rather than deciding is the hallmark of the “frozen” organization.
Managers who are judged by their superiors on “knowing exactly what’s going on” cannot easily empower front line people.
Managers, in turn, have to put developing and collaborating with their people as job one.
Celebrate even wrong choices and use them for learning; celebrate those who take action rather than delay.
Really reward and celebrate those who not only act, but take the time to also communicate to others and thus spread behaviour you desire.
None of these initiatives require that you rip up your existing systems (although they can point to liabilities in your current implementations that you may want to take action on) nor do they require massive corporate expenditures to achieve.
They simply require that you be willing to exchange detailed control over employee actions for judgement as to whether actions have been effective (P&L improved) or ineffective (it did not).
Agility more than makes up for the occasional thing that “goes wrong” — a lesson top customer-focused organisations have always known. That’s why a Nordstrom takes back goods it never sold, a WestJet counter person waives change fees and makes sure you get going; Southwest Airlines fires customers to back up staff.
Agility is simply an ability to sense opportunity, respond to it, and seize returns for the firm.
It is exemplified in action, not in systems. Systems are the tools (be these human resource practices, information technologies, budgets that have room to breathe without seeking approvals, or an ease with mistakes).
If your overall results have improved, isn’t that worth it?
From a CIO’s viewpoint, therefore:
- You need a real information architecture and a roadmap to move toward it.
- You need a technology roadmap that’s cost/return based, not technology-based.
- You have to champion light compliance and control, and room to manoeuvre, do “just enough” to serve, etc.
- You want full data quality, but not necessarily data completeness (that slows you down).
- You want to get from large, inflexible package implementations to components that allow for “just enough repetition”.
- You want to fully integrate collaboration and “social” into the mix.
- You have to make IT itself a model of how to manage for agility.
That’s a good ten-year journey. Best be at it.