From 'just support' to 'highly strategic' - the evolution of application maintenance and operations (AMO)
"Albatross". "Necessary evil". "Budget eater". Over the years, application maintenance and operations (AMO) has received many undeserving monikers. Beyond the CIO's office, AMO is an enigma - misunderstood and written off as cumbersome and constant re-tooling done by "those IT geeks". This is a pain shared by most CIOs across leading global organizations. And during my many interactions with some of these CIOs, they have shared their angst - no management buy-in for AMO, the perception of being a cost-center, and worst of all, the inability to see value beyond "keeping the lights on".
But over the course of many engagements, I have witnessed application maintenance and related operations evolve and manifest in various avatars. AMO has played a key role in simplifying processes and driving enterprise agility. That is one of the reasons I'm writing this blog post - as a rejoinder, as a myth-buster. Because for every ill-conceived notion about AMO, there is an equally conceivable and readily discernable fact. So we're going to engage in some fact vs. fiction. Where fiction is a common-heard fallacy, and fact is the reality as seen through the eyes of CIOs and technology consultants.
Fiction: AMO is purely about optimizing cost and incremental efficiency improvements.
Fact: AMO is an unsung hero, and is delivering value in areas you may not even have thought of.
CIOs have typically used interventions such as vendor negotiations, vendor consolidation, outsourcing, and off-shoring. When they started out with these, cost and efficiency was the driving factor. But today, there's more to the story. AMO is capable of putting business before technology, and not the other way around. The right partner and the right approach can help ensure that each application delivers the desired business value to their users. Think about a merger or acquisition - the first, and often most important step to connect the two organizations is AMO. Think about how "those minor tweaks" to applications help make transactions faster and safer, saving time and effort for business users.
Fiction: Our business processes keep changing because our applications keep changing.
Fact: An application changes owing to a business decision, and this change will standardize operations for the better.
Today's enterprise IT application landscape is constantly in flux. With new technologies to be leveraged, it obviously makes sense that business users expect more functionalities from their applications. So take the business process view -- for most parts, the underlying business process itself does not change dramatically as long as the business itself does not change dramatically.
Many enterprises periodically embark on large-scale process harmonization and standardization projects. Usually they leverage an enterprise-class package such as an SAP or Oracle to drive the standardization. The landscape is supposed to be simplified with "one version of the enterprise-level template". Unfortunately such a simplified landscape exists only for a short while, as business starts demanding change, and over a period of time the application landscape becomes complex once more.
Fiction: IT consultants optimize application without understanding process linkages.
Fact: There are consultants who think process instead of application or functionality.
Since applications are only a means to realize an underlying business process, it is important to get a handle on the process itself and its linkages to other processes in the business. Most AMO teams start with a detailed inventory of processes and applications that support the processes. When a new partner is taking over, AMO is usually a great time to do this base-lining exercise. Infosys for instance, has a comprehensive set of tools and methods to create a business process inventory and an application inventory. This allows the proper mapping of process to application, with mapping of dependencies.
Fiction: It's better to have decentralized AMO operations, so that each LOB / function can customize the same application to their need.
Fact: AMO is easier to manage with a single global team.
By having a single global team to support AMO for a given set of business processes one can minimizes the changes. If one team takes a business process view and runs AMO, then the implications of changes requested versus the change itself can be easily understood. More often than not the change requested is not a must-have change and even if it is a must-have change, it is easier to control the change process by with a global AMO hub. And if a similar change has been carried out at a different location, the same team can do it faster - they know just what needs to be done. And think about what this team could do in terms of enterprise-level standardization.
Fiction: AMO teams don't understand business - their interactions should be limited to the CIO's office.
Fact: AMO teams are capable of strong change management control.
To get the best out of the AMO process to drive standardization, the AMO team needs to be empowered by both business and IT. This will avoid costly rework and failure in the landscape.
At Infosys, we've been using our Global Delivery Model to deliver on all the above facts. Going beyond "what's expected" to "what's possible". What do you think? Do you have more "fact" to counter all the "fiction"? I welcome your views.